The title of this blog post is a bit provocative. I think that Embarcadero is doing well with Delphi and I am excited about XE4. I have been using it. But I need to complain today.
I get paid to write Windows applications, and Delphi is still the best tool for that job. But it needs some improvements. Here are the improvements that I believe would benefit everybody using Delphi. Delphi's speed issues slowed me down today, and that's not acceptable. I work with large applications in Delphi, some of which approach 1.5 million lines of code. Delphi just doesn't handle them well.
1. Ditch the Microsoft Document Explorer. Even Microsoft has ditched it.
2. Give me F1 context sensitive help that is faster than Googling or searching Stack Overflow.
3. Get rid of the 3-5 second delay popping down the Edit menu when you have a large project open.
4. Fix the useless Error-Insight compiler. Get rid of all the various parsers in your product and replace them all with one new one that can do all the parsing you need done. The differences in the parser's support for various Delphi language features added between Delphi 7 and XE4 has resulted in the broken mess of code-insight, error-insight, and code-completion, not to mention code-formatting glitches.
5. Learn from all the Java and C++ IDEs out there about using a background process to do do scans of the edit buffer so that it does not freeze up the editor, ever. It's never okay to block the user from inputting text while you have a big fat think. Never. Fix anything that freezes the editor long enough to cause users to lose data because the IDE is frozen while they were typing code. This slowed me down and caused me to lose a good chunk of my productive working time today.
6. Some of my forms and data modules take 8 to 10 seconds to open and become editable on a Xeon computer with 8 cores. This is just not cool. What kind of stupid algorithms are you doing at DFM load time that could take 10 seconds to parse a DFM? I could compile 100 megabytes of Delphi code in that time from the command-line compiler.
7. Make one checkbox in the preferences that says "Make it fast". Turn off all the slow stuff with that one checkbox, so that when what I need is an editor that has Delphi syntax highlighting, and a compiler and error list, it gets that right, and forgets everything else.
As cool as the Mac stuff is, and I will blog about how cool it is soon, what I want is a fast Delphi.
I get paid to write Windows applications, and Delphi is still the best tool for that job. But it needs some improvements. Here are the improvements that I believe would benefit everybody using Delphi. Delphi's speed issues slowed me down today, and that's not acceptable. I work with large applications in Delphi, some of which approach 1.5 million lines of code. Delphi just doesn't handle them well.
1. Ditch the Microsoft Document Explorer. Even Microsoft has ditched it.
2. Give me F1 context sensitive help that is faster than Googling or searching Stack Overflow.
3. Get rid of the 3-5 second delay popping down the Edit menu when you have a large project open.
4. Fix the useless Error-Insight compiler. Get rid of all the various parsers in your product and replace them all with one new one that can do all the parsing you need done. The differences in the parser's support for various Delphi language features added between Delphi 7 and XE4 has resulted in the broken mess of code-insight, error-insight, and code-completion, not to mention code-formatting glitches.
5. Learn from all the Java and C++ IDEs out there about using a background process to do do scans of the edit buffer so that it does not freeze up the editor, ever. It's never okay to block the user from inputting text while you have a big fat think. Never. Fix anything that freezes the editor long enough to cause users to lose data because the IDE is frozen while they were typing code. This slowed me down and caused me to lose a good chunk of my productive working time today.
6. Some of my forms and data modules take 8 to 10 seconds to open and become editable on a Xeon computer with 8 cores. This is just not cool. What kind of stupid algorithms are you doing at DFM load time that could take 10 seconds to parse a DFM? I could compile 100 megabytes of Delphi code in that time from the command-line compiler.
7. Make one checkbox in the preferences that says "Make it fast". Turn off all the slow stuff with that one checkbox, so that when what I need is an editor that has Delphi syntax highlighting, and a compiler and error list, it gets that right, and forgets everything else.
As cool as the Mac stuff is, and I will blog about how cool it is soon, what I want is a fast Delphi.
I agree. Plus, I would also like to see them take a gap year (or atleast 6 months) just fixing IDE, VCL & RTL bugs and performance issues. Clear out as much QC items as possible. A bit of a cut & polish to the IDE wouldn't go astray either.
ReplyDeleteAbout losing work: why don't they turn auto-save on by default?
ReplyDeleteNobody will complain about finding backups that need to be cleaned, but people shout and swear when they find out that their work is lost when the IDE crashes.
I will! Don't you dare litter my project with random files and directories I didn't ask for. Why the F would you want a feature like that on by default. Only to work around a problem of your broken tool?? Use a better tool instead!
DeleteMeanwhile at the Emb sales staff prelaunch meeting.
ReplyDeletehttp://i.imgur.com/k4iJtRZ.png
That's why (among other things) I've moved to VS 4 years ago, and never looked back.
ReplyDeleteVS is hardly fast
DeleteAgreed. I could write a rant about visual Studio that has 100x more complaints. Starting from Visual Studio 6.0 to 2012 there is a long and sordid history of things that should have worked and don't. Visual Studio 2012 is a mix of nice things and horrible things.
DeleteYou switched from Delphi to VS for speed?
DeleteHave you tried loading VS recently or do you keep it running at all times?
Personally I dread having to load it, and as for source code security, dotPeek does a better job at exposing your code and methods than DeDe did with Delphi 1.
I agree whole heartedly with your comments. The problem is that EMBT gets no revenue from bug fixes and performance enhancements, and it's the marketing and finance team that is driving the company. Just look at QC if you want to find an endless number of bugs and performance problems, and enhancement suggestions. Then look at how old the reports are. Even new bugs like the Find "feature" introduced in a recent release, has not been fixed. The only way to change this is to change key players. They need someone from outside the company to turn it around, and it's not going to be Marco.
ReplyDeleteI personally think bug bounties are the way to go. Let developers put up real money to be paid when their issues are fixed. Then we would finally have a vote (not the messed up QC votiong mechanism), and some accountability from EMBT as their customers. They get revenue, we get a better product, and perhaps they get new customers as a result.
It kind of works like that, except that when big bugs don't get fixed after five releases, people walk away and stop paying for SA, and stick with their old delphi version until they can retire their products or rewrite them in .Net or Java. I have seen dozens of companies do this, and as a person who relies on Delphi-jobs existing this makes me really sad.
DeleteMaybe correct in time sale that bugfixes don't pay at short time scope.
DeleteBut, that is a heavy boomerang when the programmer learns that bugs are seldomly fixed unless you pay for 2 or more upgrades as XEn+1 and XEn+2 and XE(n+m) they quit and Embarcadero in end loose most customers.
But maybe too late by now??
- Error Insight is embarrassing. How many years have we been hearing the same tired excuses for its failures? Fix it or kill it.
ReplyDelete- For many of us whose work remains Windows desktop apps, the past few releases have been less than exciting. Engineering work clearly has been focused in areas we do not use. That makes XE2, XE3, and XE4 look like expensive bug-fix releases. No, wait, with the reports I have heard, I'm not sure they fixed the things in XE which get in my way.
- I do not normally find Delphi slow. However, I do sometimes find that it goes into some weird state, and the only fix is to shut it down and restart. Sometimes with the help of the Task Manager. The apps I build in Delphi do not behave that way....
I'm curious how many LOC is your largest project? I have seen this only on projects where the total project source code line count exceeds 1 million and where there are units that use other units, in a chain that exceeds 400KLOC. So unit A uses units B through Z, and AA through ZZ, for a total nearing half a million lines of code just to parse all the unit interfaces, plus the large currently focused editor unit that is around 40,000 lines or more.
DeleteYes, people should break up those units. But no, they're not always free to do that in a large production app.
Over a million lines of code. Promiscuous uses clauses (a maze, in truth, which I try to simplify, when I can). I am relatively free to do what I wish, but this is a product in active use, and with frequent updates, so if I screw something up, there are real and immediate consequences.
DeleteWell I am happy to say that Delphi XE2 rarely crashes on me, but that 2007 crashes all the time, and that old apps that cannot be Unicode converted (yet) are a pain to work on. What version are you using that goes into a non-responsive state permanently? XE3? The XE3 debugger issue is the worst issue in XE3 and is the reason I am still using XE2.
DeleteIt is incorrect to say that EMBT gets no revenue from bug fixes; customer loyalty is, in part, the result of maintaining the product at a high level of quality. When longtime users depart for VS, as in Arturo's case, that does affect revenue.
ReplyDeleteEMBT (and our whole business economy) is suffering from the short-term ROI blues. A terminal inability on the part of managers to consider that the long term health of the company is a function of long term investment in its products, not the latest press release.
Software assurance revenue year over year is guaranteed to be 10x to 20x the revenue from new sales. Therefore, it will cost Embarcadero dearly to ignore their installed base. Marco is a smart guy, that's why I'm talking directly to him.
ReplyDelete"Make it fast" checkbox = disable Code and Error Insight
ReplyDeleteOh Stefan, if only that was true. The IDE editor will still churn for 15 to 40 seconds after every key press on very large units. There are clearly other things going on than just Code and Error insight that sometimes have very high runtime costs.
DeleteI'm using C++Builder XE5 and just opened a project (a rather small project at that). All I did was hover the mouse over a DataModule reference and had the "WaitCursor" display for about 4 seconds and disappear. Then I hovered over the ClientDataSet reference of that DataModule and had the "WaitCursor" display for about 2 seconds and immediately the IDE crashed. REALLY EMBT!
DeleteAnd I just restarted the IDE, opened the same project and unit, and hovered over the DataModule reference again. Again, the "WaitCursor" displayed for about 6 seconds, but this time, it immediately crashed the IDE. Really irritated right now. I fell in love with Delphi back with Delphi 3 through 7. Then, I transitioned to VS when Delphi 8 came out. Now trying to get back to my roots and trying to return to my favorite IDE and language. But, these types of things just don't happen in VS. I agree VS has issues, but the editor, code completion, and parameter insights are really good and fluid.
DeleteThere is poasible to turn off the autocomplete, and activate it only with ctrl + space on settings > options.
ReplyDeleteIt turns is very fast.
Warren, if as you say, SA revenue is such a large figure, then truly, the path they have been on is bizarre. Defects persist for years, and new (and all too often buggy) features get priority. It surpasses all understanding.
ReplyDeleteEmbarcadero appreciate SA revenue not for the fact that it reflects on-going business from their customers, only that it is bankable revenue in exchange for promises, not delivery.
DeletePeople who pay for their upgrades decide whether that upgrade is worth it at the time. This places the responsibility to deliver something useful and worthwhile on Embarcadero. They hate that.
People who take out SA do so thinking that they are "supporting" their supplier and in the belief that the revenue will pay for quality and features that otherwise the supplier might not commit to developing. But the supplier has no obligation to provide these benefits. It is a trust relationship.
Embarcadero ?
Trustworthy ?
That's a bad joke.
This is not unique to Embarcadero. It's a disease infecting the entire industry.
ReplyDeleteIn many different markets, the lure of increased market share is ALWAYS going to make it difficult to prioritize existing customers. However, that is also the #1 way that software companies fail; By not listening to their customers.
Borland saw a shiny opportunity called "ALM", and had a really great quarter, and then abandoned everything to chase the shiny new market opportunity. Now what are they? They're a division of Microfocus, a cobol compiler company. Because compilers don't matter at all they sold their compilers to Embarcadero. Guess what, the compiler business matters. The IDE business matters. Embarcadero is smart and they know this.
The potential market share for Delphi on cross platform is HUGE, and that's why they're going for it. I applaud them and support them and think it's the right move. And now that they have taken a step with the left foot, it's time to take a step with the right foot, or they will only walk in circles.
>Borland ... abandoned everything to chase the shiny new market opportunity.
DeleteI don't see it that way at all. Borland saw that development tools were becoming commodities and were smart enough to try to transition the company to a more lucrative market that wasn't dying or had a monopoly running amok in it. They didn't necessarily pick the right one, nor did they succeed, but it's quite clear they were correct about getting out of the development tool business.
>Now what are they? They're a division of Microfocus, a cobol compiler company.
>Because compilers don't matter at all they sold their compilers to Embarcadero. Guess
>what, the compiler business matters. The IDE business matters. Embarcadero is smart
>and they know this.
I disagree with every word in that paragraph. :-) I believe the Borland ALM division completely failed at Microfocus and it's been abandoned. The compiler business doesn't matter. What do you want, C, C++, Java? Are you into retro - FORTRAN, COBOL? Math - Octave (matlab clone), R? Exotic - Haskell, OcamL, Erlang? You can download them all for free. IDEs? Plenty of choices, including Eclipse. Version control? Git, Mercurial, many others. Enterprise-grade RDBMS? How about PostgreSQL with SQLite for local/embedded? Big data - you're in luck - ALL of the big data solutions are open source! You can even have an open source OS, desktop and server, to run it on. Oh, and what isn't open source is controlled by a slowly dying (but still powerful) monopoly. What sane company wants their market to look like that????? And developers like open source and the ability to shape the future development of their own tools, submit their own bugfixes, etc.
>The potential market share for Delphi on cross platform is HUGE,
I think you're dreaming. :-) Name any development language that has ever had a resurgence (Y2K bug doesn't count). NONE that I can think of ever came back. The market doesn't work that way. The market saw Delphi; the market passed up Delphi. We have cross-platform C++, C# and Java... what does it need Delphi for? We have Qt, which actually works and runs on more platforms - what do we need FireMonkey for? The market would probably prefer to port existing languages to new platforms than return to an outdated language in the early days of functional programming, type inference, design by contract, JIT, and a host of new language features slowly trickling out of academia and into production languages. The enterprise isn't going to embrace something that doesn't have an army of developers waiting in the wings and hinges on the fate of one private firm.
> And now that they have taken a step with the left foot, it's time to take a step
>with the right foot, or they will only walk in circles.
That's the problem though... they just don't have the resources to do it *right*. Digia brought 125 developers from Nokia when it bought Q, adding about 90 of their own to bring it up to about 210 (!!!). Delphi is widely believed to have somewhere around 15-21. Interbase is down to 1 developer. They just don't have the manpower to work on the language, TWO frameworks - VCL and Firemonkey, an IDE, a database, etc. RemObjects can concentrate on their language; MS concentrates on .Net, JetBrains concentrates on their IDEs... EMBT can't do it all and possibly hope to succeed. You'll see more bugs, more problems, more rushed code, then more layoffs, which'll lead to worse problems and a death spiral. Instead of doing something like embracing FreePascal (the entry level option they lack) and integrating their compiler with Delphi's IDE (or Eclipse) and focusing on just the framework or something, they view everyone as "competitors" instead. Heck, they could have made Delphi language bindings for Qt and let Qt become the new cross-platform framework. There's a lot of ways they could have played this, but didn't.
Xamarin is selling a lot using a hybrid open-source (for part of their code) and closed-source (licensed/activated) strategy with Xamarin Studio + Xamarion.iOS/Xamarin.Android. The desktop IDE market is stagnant, with the lion's share still going on Windows to microsoft.
DeleteInterbase is the least of my concerns; That ship sailed when the open source movement hit. Interbase will never even catch up to firebird let alone to MySQL or Postgres. Will Delphi continue to matter or will some enterprising group of open sourcers build their own pascal-over-clang/llvm and their own next-generation VCL equivalent? That's the interesting question to me.
The tired old "There are no delphi developers because there are no delphi jobs, and vice versa" fud is a bit tired.
No, Delphi isn't going to be bigger than C# ever. Nor bigger than C++, nor bigger than Java. But it can matter, and in terms of Delphi, it could be big enough (with sales of cross platform) to increase the team from about 20 to about 40 people.
Warren
"Guess what, the compiler business matters. The IDE business matters. Embarcadero is smart and they know this."
ReplyDeleteWith respect, the last three releases leave considerable room for doubt, IMHO. Just as in the past, resources were thrown at the chimera of a commercial tools market for Linux, they have lately been thrown at the so far unproved market for non-Apple development tools for the Mac and the iPwhatever. Compared to Windows, the Mac market is small, and this is another case of cold-call initial sales, rather than support of established market share.
On the mobile front, there may be more room to hope, but I think that remains unproved. And if it does have potential, then surely equal attention should be given to the Android side.
The potential market share for Delphi on cross-platform is arguable. If the existing base is ill-served in the meantime, they will not evangelize for that market. I am uncertain whether they have sufficient resources for what they are trying to do. If they pursue cross-platform at the continued expense of progress on the Windows side, then I am not hopeful.
They have to be able to be aggressive on all fronts, not sequentially, but simultaneously.
You don't feel the ability to experience identical bugs and half-implemented features on a wide variety of platforms is a competitive advantage? :-) :-) :-)
DeleteTotally agree... Hope Marco is reading this! They're adding things I don't need and ignoring (ie not fixing) those I do. I think I'll wait for XE9
ReplyDeleteMarco read and responded, so I give Embarcadero full points for customer service.
Delete@Warren Postma
ReplyDeleteIn your blog title you say "Here's how to fix Delphi" but in your blog you actually don't provide any solutions instead you just point what needs to be fixed and request the ability to disable some buggy features.
Disabling features isn't the same as fixing them but only avoiding bugs in them.
Besides I'm sure that Marco is hearing complaints about theese tings everywhere and since he is also a programer like us he has probably encountered theese buggy features many times himself.
So now instead of just complaining I will provide what I belive could be a solution for many Code Editor problems:
Based on my observation the main problem of "Error-Insight" is that it is constantly reevaluating all the code below your cursor point and becouse of this there can be big delays when you have lots of code beneath the cursor.
This can also be seen when you have some folded code beneth your cursor and you write some code with error in its syntax. It will unfold all the code below that syntactical error.
So my suggestion is to limit syntax checking of "Error-Insight" only to scope of current block of code and of course parent block of code to be able to check for variable and type declarations. This will reduce the amout of code it needs to be checked and therefore reduce the time to do so.
I was always wondering why does Delphis editor treat its code as one block of code and not as several blocks of code. Isn't the main advantage of OOP language to divide the code into multiple blocks of code?
I do agree that the help system should be changed. I can't even say how many times I sweared becouse of it being so slow.
But the other problem in Delphi's help documentation is that it is verry poorly written. If you check Delphi 7 help documentation writen by Borland and newer Delphi help documentation writen by Embarcadero you will clearly see what I mean.
On my opinion adding support for other platforms is nice and by today thrends almost necessary but it shouldn't have bigger priority as fixung current bugs. Why? Becouse current bugs can be preventing your from sucsessfully implementing new features.
Actually I did give a specific technical recommendation. I happen to know that many issues like Error Insight are caused by multiple parsers each of which have a different ad-hoc subset of the full Delphi grammar supported. If you know anything about parsing and compilers, you should know that's a bad thing.
DeleteSo, your comments above don't really indicate to me that you understand how Delphi works. A unit of compilation (.pas) is a big block. That's how units of compilation work. Do you know what a compiler is Silvo? A compiler takes a unit of compilation (a file) as input, and writes a binary object file (in Delphi's case a DCU file) as output.
There are very good reasons why Delphi is not going to incrementally compile one little procedure at a time, and that's not going to change. However they could do a better job of parsing and editing text files without slowdowns.
Visual Studio is not my idea of a goal to shoot for as Visual Studio is kind of crappy in many ways. A goal to shoot for would be XCode level of speed, or even better, IntelliJ Idea or IntelliJ AppDev level of quality. (In short, awesome.)
I know they can do it.
W
>There are very good reasons why Delphi is not going to incrementally compile one
Delete>little procedure at a time, and that's not going to change. However they could do a
>better job of parsing and editing text files without slowdowns.
I don't believe the original poster was talking about compiling; he was talking about limiting the scope of the parsing you were talking about.
Oh, and technically there's very good reasons to incrementally compile one little procedure at a time: it's called just-in-time (JIT) compilation. :-) It's been argued that once computers are somewhat faster that the future belongs to tracing interpreters, global static analysis for type inference and JIT compilation to provide the expressiveness of dynamic typing with the speedup of static typing (where possible). Algorithms are being developed today to find areas where the type of dynamic variables can be determined from analyzing the code and JIT compile those code segments for signficant acceleration.
Not that this has anything to do with Delphi... unfortunately.
>I know they can do it.
Not being sarcastic here... what have you seen from the developers that remain at EMBT that lets you know they can do it?
Someone reported being told off the record that an EMBT developer told them the underlying Code Insight code needs to be completely rewritten but management continues to refuse to sign off on the time required to do it, so it remains broken. Even when things can be done at the bottom, it seems there's no will at the top. :-(
Oh, and the absolutely obvious solution??? Let Delphi become a flavor of JetBrain's IDEs and then EMBT won't have to worry about the IDE anymore. I'm not sure JetBrain would consider the market large enough, though, and then EMBT's perception of itself might collide with reality.
I couldn't agree more regarding the speed of the newer IDE when it comes to large projects. Recently had to port a large project from D6 to XE3 with about 800k lines of code. Torture with the compiling time. There's something rancid in the IDE that just bursts out when you're dealing with a large project. Error insight? Forget it, turn that shit off before the IDE is overwhelmed by that single core threading. Code Insight? You wish, better buy that SSD.
ReplyDeleteRunning 3rd party like Cnpack , priceless;
Delphi IDE has become more or less a joke and needs a year or two just for a complete overhaul. Unfortunately from what I've read Embarcadero is in the toilet, not only are they far behind on the tech bumwagon (Going for iOS support over Android first?) but they seriously lack some talented people (HTML5 Builder for real? Possibly the worst developing program I've ever used).
Half of the time that I spend developing or porting Apps is dealing with IDE or compiler bugs(fatal error anyone? - yeah gl with that sh**).
Windows VCL Styles? More like "Written in two months without any debugging" Styles. Lost two weeks of actual developing just fixing bugs in that shit f*** feature. If you want to see a full turd application using VCL styles without doing any fix, just check HTMl5 builder, I shit you not, rancid, especially on a mid-low end computer.
(The FM version is a lot better).
There's so much to complain about, but overall I still think it's a great tool for development.
{$sarcasm ON}
But hey, it's ok to let the IDE turn in a sh**hole aslong that we get that TStringHelper or not having to call Free on that Object instance, wupidu!
{$sarcasm OFF}
@Ghoy: 'If you want to see a full turd application using VCL styles without doing any fix, just check HTMl5 builder'
DeleteYou sure about that? Last time I looked, HTML5 Builder used a third party VCL skinning solution.
@delphihaven,
DeleteI automatically came to the conclusion that HTML5 Builder uses VCL styles utility because:
- html5 builder uses the Carbon VCL style
- I've noticed most rancid VCL style bugs all around such as improper window and VCL controls msg, paint handling
- I don't think that they would opt in for a 3rd party styling solution when already having a solution on their own, considering the release dates being somewhat more then a year apart it wouldn't make sense to opt for a 3rd party. And if they did, what kind of a message sends that to the Delphi developer community?
Personally I didn't find any significant info that would say otherwise, please enlighten me if you have some readable information on the matter.
Either way, 3rd party or not, a bit more then a month ago I was asked to create a certain android application and it was a good reason to give HTML5 Builder a try. I was very disappointed. VERY.
I have no doubt that stuff might have been fixed by now, but at that time Html5 builder was more or less:
a Giant turd collection of 3rd party frameworks implemented in an IDE which is essentially Delphi IDE - VCL Carbon styled, all stashed in a badly implemented PageControl navigated by what seems to be a slightly Style-modified TButtonGroup.
@Ghoy: I have used HTML5Builder though only casually and I found it a very nice product. I also happen to know the lead developer and architect and I call him a friend, and believe he's a smart and capable developer. But beyond the fact that I know and like the guy, I disagree with you about HTML5Builder completely. I think it's an exciting product. PHP is not my favorite language in the world, but it has its role and is an important part of the HTML5/Web world, and I am glad that this product exists.
DeleteWarren
Most of what I said and of my frustration was directed at the implementation of the HTML5 Builder VCL styling and interface on general, I did use the tool for a solid week and while I have no doubt that the tool is in a way better condition now as it was back then I simply can't ignore that I had a very bad experience and that's all that I'm coming out with here.
DeleteAgain, most of my frustration and bad experience was based on the clunkiness of the VCL Styling INTERFACE and not the actual engine behind the scene.
Infact considering the framework, it's a worthy application where I was able through the power of HTMl5, javascript and php produce a mobile application in a rather small time frame and that's what I originally set to do, even if I lost it a few times due to the interface.
@Warren Postma,
DeleteI would just like to say one more thing regarding HTML5 Builder that I haven't clarified yet,
My Interaction with the HTML5 Builder was based on developing a Client-Side App and not a server side one, so my engagement with the tool was simply on the HTML5, javascript side as oppose to PHP.
I said that my frustration was primarily focused towards the laggy Interface, but a large portion of it went also towards the experience of creating a client side application which was a pretty bad one and let me explain that.
I was big into website development about two years back and I mostly worked in ASP.NET and javascript. I'm sure you've heard of Adobe Dreamweaver, it's a very popular tool for both client and server side development. Anyway, after being so well accustomed to that tool, migrating to HTML5 Builder was a total shock.
Developing a Client side mobile application on HTML5 was horrible because :
- The Interface was incredible slow due to improper VCL Styles Implementation, especially improper handling with what seems to be a TPageControl to switch between content.
- The Code Editor for Javascript offers no Code Error Insight or Syntax check and the build tool if you can call it that was a freaking joke. Even if you made an unvalidated language remarks it would build it anyway.
- The Code Editor by itself was a lagfest while typing
- The Tool Palette was a complete joke because in the version of the HTML5 Builder that I downloaded at that time, if you interacted with the Tool Palette(which is something like a TCategoryPanel) it would sooner or later start duplicating all the panel/buttons, like instead of having 10 you would get 20 and so on and so on. How can anyone not get frustrated by that? It certainly shows that all about nobody but the developer on this project tested this Application. seriously.
- And last but what I think the most important bug for me was that while in design mode, if you changed the visual style of a component it would automatically brake the entire design and reset most of the stuff you've done in the design mode.
This are not all the bugs or issues I encountered but it's the ones that I remember and my freaking memory isn't all that great.
Overall I can forgive some bugs because it's a new application but some are just too retarded to pass on.
Right now I see no reason to use HTML5 Builder over either Dreamweaver or basically NetBeans with an addon that not only allows me to create Android applications faster but also more stable and guess what, it doesn't cost 400 euros like HTMl5 Builder.
:/
@Ghoy: keep in mind the timing - VCL Styles, like FMX, originate with the KSDev acquisition. HTML5 Builder uses 'AlphaSkins' IIRC (this is just by looking at the executable when I tried the trial - I have no special knowledge of the product's development [*]). That said, given skinning native Win32 controls can is inherently a hack, I'm not surprised the two solutions share similar bugs.
Delete[*] https://forums.embarcadero.com/thread.jspa?threadID=77220
Thanks for the link, it was an interesting read tho I have to say I'm far from convinced that HTML5 Builder uses AlphaSkins.
DeleteI went to download AlphaSkins and the good folks at AC offer a compiled Demo which includes all the free skins + Skin Editor, as well as a Full trial package.
My conclusion after fiddling with the AlphaSkin tools for an hour was that it's a far better, less buggy, way more evolved but also harder to implement version of Delphi Win32 VCL styles.
Considering that HTML5 Builder uses Carbon style which is by my understanding a dedicated VCL and FM style (I couldn't locate a similar sample style using AlphaSkins),
and considering, that in order to use AlphaSkins you have to use custom controls(they even offer a converter that edits the .dfm file),
it's all but very unlikely that they opted for AlphaControls over VCL styles.
I've been doing a lot of work with VCL styles since XE3 and when it comes down to guessing I would say that HTML5 builder uses VCL Styles, now as far as that packet info in the release, I propose that Warren Postma who seems to be a friend of the lead developer on HTML5 builder to simply ask the guy if in fact the tool is using 3rd party skinning solution.
If he is up for it ofc, I would sure like to know, please :)
I agree that the IDE improvements you are asking for are important and will benefit all of our customers, old and new, whatever their platform. Some of the things you mention are also on our radar, partially in terms of cleaning one bug after another in an area, and partially in terms of redoing specific implementations with a brand new one.
ReplyDeleteAs company we need to balance investment on new features (currently new platforms, so there is some extra effort), fixes of existing issues, and core improvements. As someone mentioned in the comments, having a lot of customers on maintenance for a company implies the ability to be less "new features dependent", while if your business is focused on selling updates, there is less push to re-engineer an existing feature which has structural issues, because it is very hard to "sell" it.
It is not always trivial to strike a balance. Would you rather have a new compiler feature even if code insight doesn't fully get it, or give up the compiler feature until everything around it works perfectly?
Finally, I have no problem getting complains for things that are wrong in Delphi, but would like to have an equally strong push from customers about what we do right. Including the bugs we do fix, for example.
There's always going to be more bashing going on then prase in the comment section of such a blog post, doesn't mean that's the general opinion.
DeleteNo offense but I find your whole balance between a working code insight or new features to be concerning. I don't know about everyone else but if I implement something major in a program, and that implementation doesn't work properly and breaks the overall working environment for my customers, I don't just shrug my shoulders and continue building upon that implementation just because I'm too behind on schedule or too behind the popular technology. Especially not for 3 straight years.
Who here actually uses Code or Error Insight on large projects? It's something that works when you don't care but fails when you need it the most.
Overall I think that Embarcadero is on the right path, everyone knows you can't ignore the largest growing market afterall it's a business, aslong that you don't over estimate the patience of your existing customers which by the way are still waiting for major IDE improvements across the board.
This comment has been removed by the author.
DeleteIndeed, it’s tricky to find the balance point of the developing new and fixing the errors. Being a long term Delphi programmer, I have to say, Delphi missed the Internet opportunity (except some third party VCL, but being Delphi programmers, we did not benefit any from this RAD when web based apps were in high demanding in the market), hope it can catch the mobile and tablet train this time. So, many of us agree that current direction of single code to multi device is absolutely correct. I also hope Android bit is coming faster as well because iOS seems losing its past glory as current Apple is wobbling. It is hard to predict who will be the big brother in OS market in the coming years. Cloud service is just like its name to me, really far and vague above the sky, may be it will be a jackpot for those who know how to transfer the cloud into train, for me, at the moment I would rather see some improvement with Bug fixing.
DeleteBear in mind, Delphi is a tool. New feature of the tool is certainly attractive, but will you be comfortable to use a new released tool with rusty, broken parts, or sometimes having a snap when you really need it working faster? So, after Android feature, EMBT really need pay a full attention to all the past bugs. If new IDE or complier is on their way coming, these can be ignored, all other bugs should be fixed asap. One headache problem for me the find pair of begin and end. I guess all other IDEs should have such simple pairing and highlighting function, but not with RAD. For large unit, it is always the pain,
Another question, if we buy it now, what would cost me when android feature implemented in the RAD XE 5? Anyone knows?
> I implement something major in a program, and that implementation doesn't work properly and breaks the overall working environment for my customers, I don't just shrug my shoulders
DeleteHonestly I don't think this is the scenario. If the help is slow to show, Error Insight becomes of little use (generally until you compile) on larger programs, compiling apps with millions of lines of code from the IDE (but not from the command line) these are serious issues we want to address ASAP. And there have been fixes in recent updates and in XE4 in this direction. But I disagree this "breaks the working environment".
We are putting effort in fixing these and other issues, improving the overall IDE, but not to the point to stop new development. That won't serve our users at the best, imho. As I mentioned, we are trying to have the right balance, but if making a structural fix for one of the issues requires rewriting a significant part of the IDE, that might have to wait. Everything else, can be worked on right away... and some IDE issues are being fixed as we discuss.
PS. Not all IDE issues are equal. I guess we should figure out which are the ones really bothering most. Is it Code Insight delays? It is the help engine? Is is the slow opening of very large projects?
marco why not get a customer's Very Large Application and give it to one of your engineers and ask them to anonymize it and turn it into a Very Large TestCase.
DeleteAlternatively I think I could write a generator that would generate some arbitrary complexity cyclic graphs of pascal source code that would choke the IDE completely.
@ Marco Cantu,
Deletesince you quoted me I would like to explain what I said in more detail.
Personally myself I've stopped using Code Insight a long time ago because on most large projects the IDE would simply hang itself or just take a very loooong time to come back around and that is unacceptable from a developers point of view, I'm sure nobody will dispute that.
So when I said what I said, it was directed at Code Insight because that feature does not work for me and therefor by freezing or slowing down the IDE, it breaks my working environment.
I could be wrong about this but with my Code Insight experience I would say that it has substantually more problems with applications that were ported from older Delphi versions as oppose to applications that aren't very old but still contain just as much lines of code.
Either way one thing remains true, Code Insight is always slow on large projects regardless of which IDE version it originated from.
Regarding Error Insight, I had to turn that off because it was creating unnecesary lag in the IDE editor, it got to a point where it just got too annoying so I switched it off.
Same thing with code completion, I actually switched to Cnpack and I use their code completion implementation as well as most of their features because well, they work, faster. If there was ever an addon to learn from then that's Cnpack.
So many good features that would make Delphi a better development tool.
--------
On the end what I can say is that nobody expects you to switch focus to the IDE at this time, I think that everyone here understands what a major Mistake it would be to hinder the progress of mobile application development in any way.
What we are however trying to do is to make sure that these existing IDE problems are not completely forgotten, and personally I'm satisfied enough with the fact that these problems are acknowledged officially and by the fact that you listen to your customers, that's more then rare today.
Cheers.
Thanks for responding Marco.
ReplyDeleteI will reiterate that I am absolutely 100% positive that Embarcadero is going in a good direction. I feel some people's pain when they wish that Embarcadero would focus more on the core (Win32) area of the product, but the thing is that right now is a fantastic market opportunity, and Embarcadero would be dumb not to go for it. People attribute all sorts of motives to companies when they can't see what's going on, but as I used to work for Embarcadero, some people are going to accuse me of being "too much biased". Sorry, all I can say is I am a fan of Delphi and I am a fan of Embarcadero. If other people want to be negative, fine. Show me something better than Delphi.
Can't do it? I thought so.
Warren
I agree 100% on the fact that the focus had to change towards the mobile industry, but what Microsoft is now in the field of mobile hardware race, Embarcadero is the equivalent of that in the mobile software development.
DeleteToo late, too Slow.
I'm sorry for coming here with this negativity, frankly I'm a big Delphi fan and I just don't think being a big beacon of support is going to help, much.
Sometimes I would think that a bit of hard truth telling is preffered in order to keep things moving in the right direction. That does not mean that they should put any less focus on the mobile side of development, infact I myself can't wait to actually develope mobile applications in native Delphi language.
I had been working for Embarcadero, and I can agree that at least initially Embarcadero had (and I think that still have) a better iterative process than the original Borland/CodeGear had. This means that the quality of Delphi is a bit better that would likely be with CodeGear hands, but Embarcadero as it had a small team did make it's share of mistakes and the product is a bit (to say mildly) behind C#/Java counterparts. I think the biggest technical debt that Delphi has is: Delphi language (as I posted on the same topic). It is clearer to read, and decent performance and somewhat good interaction with the underlying platform, but this is also true today for C#. Delphi doesn't have today good features (that were true against C/C++, but are not true against either Java languages or .Net ones) like: static code analysis (it has metrics, but look for tools like R#, XamarinStudio semantic code analyzer which works on-the-fly etc.) that is functional and fairly low cost. An issue that to some extend makes me wonder is: why not LLVM to the desktop product? Or to compile Delphi itself? Why no automatic reference counting for Delphi too? Both of these features will produce probably more memory leaks (as reference counting implies that at times people will leak because they create cycles), but it also imply that fewer code repetitions with: try ... finnaly list.Free; end; that makes big code to be I think 30% longer. Using LLVM probably will speed up to some extend the Delphi IDE itself (even the compilation will be a bit slower), so it will provide at the end some tangible performance. Other things that I would love to see in Delphi are basically the minimal parts that .Net offer like main key features: async/await (or at least a Thread Library that is easy to work with UI), some form of Linq (no SQL syntax, but a fluent-API). At last, as I said in the other topic, when they have them mostly working, don't advertise them as "production ready", but use them for one release, and in the 2nd release, make the as a main feature. Like FM: in XE2 name it "preview" and in XE3/FM2 make them ready. In this way people will be aware of using "preview" code, but also it will mean more time to stabilize the codebase.
DeleteThis comment has been removed by the author.
ReplyDeleteI'm just back to Delphi, bringing some legacy D6 apps back up to date. I've been in and around delphi since the glorious first days, from D(1) onwards, when everyone was commenting on Delphi's weaknesses, bugs, and quality problems. Reading all the comments here feels quite nostalgic.
ReplyDeleteI've no idea what Firemonkey is actually like, in terms of performance and quality, but it is clearly the way to go, and there is no one else close to it.
One thing I would emphasise is that product expectations these days are so much greater than they were. Whereas you could get away with some crappy VB developed products in the 90s, that's just a complete non starter these days. If the compiled programs have real performance, then I'm not bothered about compiler speed, or any of that stuff.
BTW, has anyone seen some 3rd party reviews of XE4? Were any of the Delphi beta testers writing reviews. waiting for the launch?
I'm hopeful about it, even given the grim views of XE3
I am glad to get from work a XE3 licence and speed is a different kind of concern to me, the real tooling that comes with Delphi is an issue:
ReplyDelete- language is slow to code in, really C++ 11 is shorter and can be written more clear with QtCreator
- you write a simple for, you have to declare the variable. You create a class, you have to put into try/finally/free block, which is overly-verbose. I found time and time again a copy/paste that failed to be done correctly
- circular units are terrible to be used, so people rely on big units which are prone to errors as they have a lot of logic
- Castalia (if you use it) is terribly slow on big units, even slower than Delphi. I don't blame the author, but I think that not having a good code analyzer is a miss that is not acceptable in this year of glory. Xamarin Studio/SharpDevelop has semantic code checking for free that is not CPU expensive.
So to resume it: make language fast to write in, and less error prone. Things like: auto (or var in C#), automatic free in desktop products and static code analysis (yeah, I know, there are metrics, which are so well hidden, that no one uses them) are the way to go, and ah, I forgot: after this thing is done to some extend: write Delphi's code with them, so they can iron out the problems without making users as beta-testers
This post is fantastic! You said it all!
ReplyDeleteI bother with these same issues every single day.
Congratulations.
Now we have upgraded from XE5 to XE7 Ultim .... I'm so angry ... so disappointed. Opening a Project in XE7 or better opening some Form-Files is slooooow and now try to enter something into the source.
ReplyDeleteWhy we have payed something? EMB forces me to be an "Delphi Hater" ...
oh my oh my ...
XE7 is FASTER than XE4, XE5, or XE6.
ReplyDeleteMy XE5 feels like double as fast as XE7. Now i have disabled the code-insight ... but its programming like in notepad ;-)
Delete... makes me think about the good old assembler times...
XE7 might be faster (I'm coming from D7), but with my 500K+ line project, the lag with error-insight turned on was 1-2 seconds PER KEYSTROKE! CPU Usage would hit 100% and often the IDE would crash. Glad I found this post or I'd still be trying to figure out what to turn off.
Delete