First of all, let me tell you that I don’t care about Delphi as a product by itself. But I do care about our users.
In fact, I was a very convinced assembly guy at the beginning. I didn’t like ZX Spectrum’s Basic, neither the Commodore’s, neither CP/M’s (sorry, guys, perhaps your mileage may vary). Always I tried to please the others and Basic didn’t gave me the power to do this.
In the days of Turbo Pascal I was quite distant from the product because… I thought: “How can I do something really useful with this?” (of course, I don’t mean now that Turbo Pascal was useless, just mentioning my perception from then) – then it was the ages of Clipper and FoxPro – tools with which one can achieve more quickly some concrete results. And, of course, always was C/C++ which was a quite unsafe language for my taste. Very easy you can shoot on your foot if you aren’t with your eyes split on four parts.
Delphi was the first language / environment which really fulfilled my needs (or rather the needs of my user base) – because I discovered that the fun in programming consists exactly in this point: to please your user base. Of course, the things are much easier if the ‘user base’ are exactly you, the programmer. But let’s pass…
As you see, I wasn’t from the beginning a Pascal / Delphi developer (also I skipped other languages of lesser importance in my career). So while I had very happy days using Delphi I kept an eye on what was going on in the field…
And then was Java. Slow. Clumsy. Big runtime. The GUI was… aaaarrrrggghhh… Used with the very complex and high-performance GUI programing in Delphi the Java’s… how to call it? GUI rendering? was a little bit ‘odd’, you know. But it was cross-platform. And this made sense, even if this ‘cross-platform’ thing wasn’t so perfect as the advertisements tried to convince us. But again it made sense: Sacrifice (almost) everything for an (almost) workable cross-platform.
Since, Windows had (and still has) more than 90% from Desktop and we since do desktop applications we stayed with Delphi. But even if we knew pretty clear why Java was/is inferior, we understood why Java appeared.
After this .NET appeared. Also, Borland at that time thrown on the market the infamous Delphi 8 – a .NET only version full of bugs (read: unusable). I do think that this was the Borland’s biggest mistake ever: to validate a new, immature platform of his competitor by a unusable version of its flagship product – thing which clearly said that: ‘The future is .NET, but we cannot do it’ And of course, many went with Microsoft.
We thought: Borland is dead. I knew team members which went Google, Microsoft, VMWare etc., the product was transformed in a ‘Cash Cow’ on the altar of the ‘Open ALM’ (yeck!), the Microsoft marketing machine was working in full…
But we do care about our users. They must receive from our hands the best program as possible. And we started to evaluate .NET… And we found that: it is slow because the Garbage Collector kicks in whenever it wants. It is slow because it has a Language Runtime /a Virtual Machine / a bunch of DLLs to load (call them as you like…) – yes I know that the thing can be JITed or NGen but it seems that oh-so-long-awaited optimizations at the place of execution still don’t deliver the promised speedup – it is slow because the GUI uses GDI Plus for rendering which is not hardware accelerated, it is slow because the have a rooted type system (a thing which is good in itself) and you must pay this. We did some benchmarks, also other guys did same thing, and we found, for example that strings processing in Delphi is several times faster (5-7 times) compared with .Net. Yes, we know about String Builder.
Also, it is very easy to reverse engineer the program, assemblies etc. – obfuscation has its quirks and sometimes makes the things even slower isn’t?…
Also, because “the world” still uses Windows XP we must deploy huge runtimes which require Administrator rights to install… no thanks, even if perhaps we can workaround the ‘rights’ part.
And when we found how non-visual is to program in .Net when one wants to implement a real-world interface – almost every programmer with which we spoke about XAML said that ‘if you want to do serious things, forget about designer, do it by hand’ – we said, no way!
But the odd part was: Ok, Java, has sacrificed so many things, but at least they achieved something. .NET? What they achieved? A market? Yeah, I think so. Because many went with .NET to be ‘safe’, to be ‘trendy’ – one of them said to me several years ago: ‘We go with .Net because this is the market trend. Yes, we know that the Delphi is better but mind you, in the times of Visual Studio 6 the product was unusable and they had the market. What now when .NET is an acceptable thing?’ But it seems that meanwhile he had a second thought…
…and this because .Net is a giant with legs of mud. There is a very big innovation effort in the area but, of course, they cannot overcome the initial compromises, even if they sacrifice the compatibility as it was between .Net 1.1 and .Net 2.0 and between VB and VB.Net.
That’s why they had the ‘Longhorn reset‘ – search in the linked page about Cairo.Net – and now they even pay you big prizes (!), just to give a successful example of using .Net (see here) – not quite encouraging for a “successful” platform, isn’t? And even if they pay you in big, (a car!?! whoah!) their showcase isn’t so impressive like Delphi’s even if nobody payed for submissions and even if this was set up in just some days.
And while .Net ship asks for examples of usage, Delphi has a very strong comeback even if there’s still a lot of work to do.
And I’m asking myself:
If we convert, we’ll do more effort for less outcome?
Yes. But no, we will not do the conversion.
If we start a new project, .Net will be a better choice?
No. The Delphi programs are way faster, way smaller than .Net’s and written in less time.
Yes, we know, one must ask in forums, search on the internet for answers and code. But, the same thing is on .Net and, still, the Delphi development is faster than in .Net. Experienced hands-on.
After so many years, .Net didn’t convinced us that we should give a real try. Java? Yes, cross-platform. But first we wait for Project X to see what will bring us.
Wings of Wind Software 
Delphi lost out due to management simply not understanding what their engineers built nor how to market it. At one time a true VB killer and way ahead of the curve to which no IDE has caught at least in terms of WinForms, now Delphi and its engineers have fallen behind. Android, iPhone, OSX, etc are the fertile ground for development yet no serious CodeGear product to be found on those platforms. Had Android a development environment as rich as Delphi, it would be a huge win for both the company building the IDE and Android itself as anyone who uses Eclipse will likely tell you.
Today, Delphi is “dieing” because it is resume irrelevant. In todays market, you need Javascript along with corresponding web development experience. Attrition is Delphi’s greatest enemy now.
The biggest problem with .net, is that it is Windows-only. Delphi/Native has the same problem, but it seems that Google may come to the rescue for Delphi/Native, with Google NaCl, freeing Delphi from the closed world of Microsoft.
You’re making the same error Borland made, then CodeGear, then Embarcadero: Delphi competitor was not VB and is not .NET. Its natural competitor is C/C++. Those who look for a fast and simple language won’t use Delphi – to try to catch them you have to cripple Delphi power and lower it to that kind of user expectations.
That’s unluckily what they made in the past years, and still trying to do. Partly because they didn’t want it to overlap with C++ Builder, partly because they thought (and still thinks) the money are in the VB/.NET market, where they were not able to succeed anyway because it is the wrong product for that kind of market – people there don’t care about inline assembler, low level memory manipulations and the like. They just want to write code that should work without much effort, and don’t blow in unskilled programmers hands. A tool to “encapsulate” the programmer….
If properly improved, Delphi could play a role for those who need power but are hesitant to dive into C++.
Delphi is about productivity, about flexibility, about power, about safety, and about high-performance executables. From all the above keywords more applies to .NET rather than C/C++. That’s why the biggest part from the ones who left, left to .NET and not to C++. You know that this is true. And they left when Delphi tried to mimic the .NET not when Delphi tried to mimic / compete with C++. So, in order to (re)gain ground the must distinguish (have clear distinctive features) from .NET and not from C++.
* “flexibility”: what is more flexible than C/C++? Are Java and .NET as much flexible? No, they aren’t.
*power: what is more powerful than C/C++?
*safety: Delphi is not safe at all. You can easily fire in your feet if you’re not careful. It’s a little safer than C/C++, but there’s no Java/.NET protections – thanks to heaven
*high-performance executables: again what do you use when you need high performance C/C++ or Java/.NET?
All the above keywords apply to C/C++, not Java or .NET but “safety”. People went to .NET when they no longer perceived any advantage using Delphi compared to .NET – BorCodeDero efforts to cripple Delphi and avoid to exploit its most powerful side resulted in a product that had no competitive advantage for db frontends and web applications, and with a far smaller “specific weight”.
*productivity: that’s would be the Delphi advantage over C/C++, if BorCodeDero had exploited the potential of Delphi as a powerful native compiler and language.
“, in order to (re)gain ground the must distinguish (have clear distinctive features) from .NET and not from C++.”
Exactly – and how do you do it? Moving towards the high-end native development, or crippling it more?
🙂
…not responding (not needed, imho) because we agree that Delphi needs to have distinctive features from .NET.
“and how do you do it?”
– cross-platform
– productivity
– high-performance executables
– no runtime
– visual, intuitive, programming
(yes, some of them can be found on .Net)
* cross-platform: that’s IMHO the most risky effort. Because it could save Delphi, or doom it. Delphi could become a “jack-of-all-trades-and-master-of-none”, and I hope that won’t be the “distinctive feature”. Meanwhile, this effort is slowing down Windows improvements. It will also need a larger team – or see how Kylix first and .NET later stalled development for seven years. But nobody was ever able to deliver a very good native xplat solution including Windows yet, let’s see.
* productivity: every tool aims to be productive – productivity is both the IDE and the libraries available – if it is easier to code but one has to write more code himself… and again, here .NET, Java and C/C++ have a big advantage. Again, this require a larger team, especially if they had more platforms. And BorCodeDero should stop releasing half-baked libraries – Datasnap is a good example of this. Take longer, but deliver better – it’s not nice when the libraries do enough well the 80%, but coding the remaining 20% becomes a nightmare…
* performance: I am awaiting eagerly the new compiler… that’s a side that has been too long overlooked. Also libraries too were not much optimized, and here most improvements came outside the company. There’s a drawback, this area does not pay much in marketing sheets, unless the perfomance is really spectacular.
* no runtime: hope the xplat approach won’t require some “runtime”…
* visual programming: I believe this approach shouldn’t be brought too far. The risk is it can easily become inflexible. Sometimes IMHO is better to write some lines of code more, and retain flexibility, than having a nice visual tool that forces you to work one way only.
You need to check out with Daniel Appleman the owner of http://www.desaware.com.
He has got very detailed speed chart comparint .NET with other true compiled exes
A link to his homepage is not very helpful. I dug around for 10min without finding the analysis you refer to.
@Lars D
plz visit http://www.mono-project.com
How to use an inferior .NET platform “just because”?
BTW, an order of magnitude is, by definition, x10. Two orders of magnitude would be x100. Three, x1000.
Nice post. I agree with your sentiments. Thanks.
I agree with LDS. It makes much more sense to compare Delphi with C/C++. I use Delphi because since Turbo Pascal in middle 80s I am a big Pascal language fan. Pascal is easy to write and easy to read.
to anon
One of my firends has big project in mono and he said that mono is all good in theory, but in real world it has a lot of problems (it’s still a hack).
Even if you leave that out: mono (probably) violates microsoft patents, which means that once they decide to force them you’re projects are f*cked.
So no mono is not really a option for the serious software.
I’ve heard good things about java and .net speed improvments in last years. Then again in real world (and not in benchmarking world) London Stock Exchange abandoned .net platform because it wasn’t good enough for the mission-critical applications (you can google it).
.Net is specially designed to assure the supremacy for Windows. So, you’re right, Mono never will be on par with .Net. If Mono will became “dangerous”, Microsoft will take care of that. We have experience about ‘undocumented APIs’ and ‘features’ when it comes to play in their courtyard. Of course, if Mono will became a more influential project than .Net, then the things will change. But really I cannot see this happen in the foreseeable future.
Mono is rather well covered when it comes to patents. Please don’t spread FUD.
http://www.mono-project.com/Licensing
http://www.microsoft.com/interop/cp/default.mspx
“Mono is rather well covered when it comes to patents.”
Sure. I didn’t meant that. I meant the long history behind Microsoft in which they didn’t play fair when it comes to competing products (see the C/C++ compilers saga, WordPerfect’s case etc.). I don’t think that it will be a legal battle between the two – Ms dragging Mono on curt or something similar – they always play with gauntlets. Mono will appear ‘broken’, ‘unable to adapt’ etc.
I do agree with part of what you’re saying. Delphi is great for GUI development. .NET and XAML just stinks. But as a software engineer who uses both techniques, I know how to combine the strengths of both development systems, by using .NET 3.5 to build a web service and Delphi to develop client applications.
While it is possible to build complete web applications in Delphi, it’s much easier to do in ASP.NET, combined with Linq, the Entity Framework and RESTful services. Design a database and let .NET create an Entity Framework around it. Then use .NET to write a RESTful service around the Entity Framework. With a minimum number of lines of code that you need to write, you can give any client application immediate access to the database content on a remote web server. Of course, you can also just use the Entity Framework itself in your application, using Linq queries to work with all the data it contains.
When developing server-side applications, you don’t have to worry about the operating system of the client. You’re in control over the hardware and the software that’s running on this hardware. Sure, you need to install this huge runtime, but it only needs to be installed just once. (That is, if your Windows system doesn’t already have it installed.) There might be conflicts with the .NET versions but these need to be resolved just once. When doing this kind of server-side development, .NET is clearly a very powerful option, much better than what Delphi offers.
But when you’re developing client or desktop applications, I continue to think Delphi is a lot better. And this brings me to conclude that you’re right: it all depends on the needs of your users. If users are [leased with a client-server architecture, they will get this: A Delphi client with a .NET server. It’s a great combination!
I agree with you, if you mean by ‘server-side’ the server side of web applications. But if you want to have a custom server on an eg. LAN and/or you have scalability problems then you must (again) rely on a compiled solution (Delphi / C / C++) due of speed and memory concerns. Also, there are enough n-Tier communication layers for Delphi (one of them very powerful, imho), including DataSnap which is shipped with Delphi. So you’ll write the server (or any tier for that matter) almost just like you’ll write the client – of course, architectural decisions are excluded here.
Isn’t Delphi written in .NET? Why do I have to install the runtime?
-_-“
No it isn’t written in .NET. Or perhaps do you mean the IDE? About Galileo (Delphi’s IDE nowadays), there’s a long story. The biggest part written in .Net is the modeling engine which was a separate product (Together) which Borland (at that time) bought. It was written in Java, converted to J# under .Net and embedding in the , hoping to be somewhat cross-platform between Eclipse and Galileo. The thing didn’t succeeded as they wanted it and now they’re rewriting it in Prism (another .Net language of course, but better than J# and C#) because one of the biggest pains which one programmer can have is to convert a code base which depends on a garbage collector (ie a .Net one) to a code base which has explicit memory control (like Delphi / C++).
I don’t use Together.
How can I install Delphi without Together and thus prevent the .NET installation?
Superbly ilultinaming data here, thanks!
One big problem with D2010 is the sheer size of the download. This could be reduced by getting rid of .NET
Incidentally, Together and Modelling (UML?) are good examples of features that could be left out of a Delphi Basic/Standard version.
And a Delphi Basic/Standard version is interesting to precisely those people that likely will not have a fast internet connection, so a smaller download size would be welcome.
I raised a similar point some time ago about why we’ll never switch to .net.
http://delphidisciple.blogspot.com/2007/07/do-you-have-net-version.html
I remember at a Delphi Conference here in the UK back in about 2002/03, Lino Tadros saying “it isn’t IF you’ll move to .NET, it is WHEN”.
A rare case of him getting it wrong.
Yep, nice post. Also the comments are interesting. About Lino, I think that he was under the same (psychological) pressure which Microsoft marketing machine did at that time. I must admit that it was an impressive marketing effort from Ms’s side to hide the compromises and to stress the advantages, either real either not.
on the net subject: the performance for net application on a hand-held device (not as fast as desktop pc) is just USELESS! the vm will take forever to load a medium complexity form for the first time, most likely due to JIT compilation. huge mistake for our company to convert the main product from c++ to c#(with c++ talking to hardware) based on the idea of how difficult to find a good c++ developer maintaining our product, easier to design a form and very easy to find c# developer (we even recruited a just graduated student for this). at the end, our product now running a lot way more slower than previous version, requires more memory to run (sometimes will crash with out of memory exception) and full of bugs introduced by inexperienced developer!!!
on the c++ subject: just learned a nice new technique called specialization template. yes, c++ is very complex, dirty and easy to code wrongly but of course if you are not experienced enough to use it.
about net on handhelds: …perhaps this is one of the reasons for which Windows Mobile is dying? (iphone, gphone anyone?)
gphone is java based platform. so how can gphone can over throne windows mobile phone if both applications must run on top of vm with a slow processor?
Actually, Android on Google’s phone uses a non-Java VM (called Dalvik – http://en.wikipedia.org/wiki/Dalvik_virtual_machine ) which is designed for low-processor, low-memory machines – it has no JIT and uses its own bytecode format. Just because the code is Java, doesn’t mean the executable will be 🙂
Good point.
Of course, the executable will never be Java. Java will either be translated to Java bytecode, some other bytecode, or even compiled into machine code. I understand your point. I’m just being picky (again!).
Yup, it seems like running the so called ‘native’ application on top of Dalvik also struggling with a performance issue. Based on my experience, there is no way writing application without using a TRULY REALLY native way can perform fast enough on a slow processor.
http://www.infoq.com/news/2007/11/android-java
Delphi was never a true competitor to C++ simply because those that use it are devoted and the libraries were/are vast. If you have been working in C++ for years, have years of libraries for it there needs to be a really big reason to move. Aside from the GUI and DB ability, developers had little reason to move on to it. Most OSes and related source are in C++ so why move on there? Games are another C++ stronghold and neither need a strong GUI environment. Delphi couldn’t crack the Linux market in part because of this. The DB market is where Delphi was strongest because it had no real competitor. VB was horrid for any real developer and PowerBuilder was/is seriously buggy and difficult to use.
Had Borland focused on real native database connectivity (dumping the BDE out of the gate), created an easy to use middle-tier similar to ASTA or RemObjects, fixed their database (going case insensitive, lowered the per seat to something way less than SQL Server) and supported the individual developer they probably would have done very well early on. They needed to be a Google for dbase development. Fast, easy deployment and inexpensive (as in free for non-commercial usage and very cheap for single developers).
Good comments about C++ vs Delphi. However there is another reason to move away from C++. It is its lack of safety due of many reasons, ranging from its extensive use of pointers till its relative lack of readability (its classic preference for different typographic symbols, abbrvs in cmds one mre cryptc thn othr… :-))
About BDE… Internally BDE is called “the technology which doesn’t want to die”. There are enough legacy systems which relies on it. And they consider this important.
There’s another huge reason to not use C++ – as I’m speaking, I’m waiting for the freaking g++ compiler to build and link my application. Those turnaround times just suck….
Oh, noo!!! This is the real advantage of C++! With Delphi you cannot even count to 2 (two) till a compile is made. See here 🙂
We have never faced such a problem with g++ compiler. That is astonishing.
Only first time build seems to take ages but not after that.
Actually it’s a combination of the compiler, a super slow linker and libtools that cause the slowdown. We’re linking everthing statically to ease deployment, and that doesn’t exactly speed up things either. It’s really slowing us down, despite having superfast Core7 machines…
I never though that actual C/C++ developers would move to Delphi. But there is an exploitable area between C/C++ development and .NET/Java one. Developers needing easier GUI development but still enough raw power to manage their data properly.
Database connectivity is no longer an advantage, many database application moved to web frontends, and Delphi is not well suited for web development.
@Cameron,
Now with advent of QT I have to say that there are not reasons for a long time C++ developer to switch to Delphi or any other language as QT supports both easy GUI building as well as easy DB!
Delphi by itself have a lot of suckyness also the .NET overcomes nicely.
* Binary compatibility between versions, upgrade to the newest Delphi is a pain on the ass if you don’t have the source of the components you use, and even you have those sources debug and manteined your self is not attractive. Mayor downsize of Delphi.
* Modular applications in Delphi are another pain, the bpl development is a nighthmare when you try to use multiple idles for the same modular applications, bpl are designed to be to atached to the IDE that is not fun at all.
* Good luck with remoting, you’ll have to rely in RemObjects or RealThinClient for something that at this times it should come with the development enviroment.
* The RAD culture, the “Use the designer for everyting” mantra, it have creates a culture of bad developers and the “copy and paste” culture that althought it uses Delphi for a living, doesn’t know how to write an OOP applications, and that’s why there are to much prefabricated components in Delphi, because the lag of “Rad culture” in the Delphi community. Im not saying everyone does that, but most of them do.
* No standarization of the Pascal languaje, Free Pascal and Delphi more different everyday.
a
* The lack of vision, while I see how Qt and .NET has done a more in 5, Delphi has done very litle the last 10 years, is still stuck to the win32 deprecated appi.
* Very few institutions are teaching Delphi. A good Delphi developers is a rare gem these days and is getting worse.
* The exagerated price of the IDE, is not worthy when you have a lot of competition, get Qt creator and you have the same plus multiplatform support.
And im sure there are a lot more.
1. Delphi has a way better reputation to be compatible at source-code level than Microsoft. See the VB -> VB.Net damage as well as Net 1.1 to Net 2.0. Why one should have binary compatibility? This means in fact, lack of optimizations in the generated code isn’t it?
2. “To use multiple IDE’s for the same modular applications” – do you build applications for different Delphi IDEs??? If this is the case, then you can use for the Galileo IDE (the IDE of Delphi 8, 2005, 2007, 2009, 2010) the OTAPI interfaces which in contrast with Native API, allows you to have a single bpl for ‘any’ IDE. And OTAPI is, of course, backwards compatible. Are you aware of all these things, aren’t you?
3. Remoting. DataSnap is shipped with Delphi from many years. (although in the lower-end SKUs isn’t present). And it is used heavily. Why do you say so?
4. Oh, I think that’s exactly the opposite. Delphi community today is formed by very skilled developers (because of various factors). I will not comment on this anymore, because it is very subjective.
5. “No standarization of the Pascal languaje” – Why? Give me a reason to became bound to standards. Do you want to switch? If Free Pascal wants to borrow from Delphi or Delphi to borrow from FPC (or from anywhere else) so far so good.
6. The lack of vision – Yes, but I think that this period is going away. Anyway, today .Net is rather a bunch of feature creep thing with (again) legs of mud – see my post. “Deprecated API” – Because (again) of .NET’s legs of mud we stuck with Delphi, not because we love Delphi very much. See my first sentence in the above post.
7. “Very few institutions are teaching Delphi.” True. They must fix this. “A good Delphi developers is a rare gem these days…” you must know where to search. Go to forums.embarcadero.com and post there a job request, even in .non-technical. “…and is getting worse.” – No, since few years (since CodeGear) the things are slowly slowly get better.
8. The exagerated price of the IDE – not ‘exagerated’, I would say ‘big price’. “get Qt creator and you have the same” – well, I don’t think so. It just isn’t on par. Qt Creator has nice things but they aren’t just on par.
For the record, when I say binary compatibility I mean .NET binary compatibility, the day I can install a bpl component made with delphi 7 in delphi 2010 let me know, mean while is a mayor downsite. I can write an assembly with .Net 2003 and it will be isable Visual studio 2010, that’s what I mean.
I use multiple IDEs for work in the same project, but since one IDE looks the bpls the other get all the erros and this is because the bpls depend to much of the IDE.
DataSnap is not what I want or need, it is a bloated way to pass datasets between for n tier applications. I need to pass objects and call services.
I won’t discuss points 5,6 and 7 but about the price let me tell you one thing, Delphi ships with a lot of stuff nobody needs and we get charged for it, make a slim down vertions and sell it. But meybe they live from the other overpriced products.
“it is slow because the GUI uses GDI Plus for rendering which is not hardware accelerated”
Excuseme but, what tha heck is Delphi using if is not GDI plus?
Depends what you want.
From start, it can use:
– the plain-vanilla GDI which it paints way faster than GDI Plus (why? – don’t ask me – Imho, is one of the most inexplicable decisions at Msft).
– Delphi 2010 can use Direct2D and/or DirectX on the systems which it is supported. (with all the stuff – headers, classes etc.). See my older posts here in “Delphi 2010 reviews” category. On the older versions you can have only the DirectX but as a separate (free) download from a 3rd party which now is included OOTB.
Also if you want you can also use the free (stunning) GLScene library to have a very easy Object Oriented programming against OpenGL. (Yeah, It is very easy imho, I’m not a graphics programmer and I really enjoyed working with it – of course ymmv).
All useless if you are using a db aplication that doesn’t need directx, .NET has WPF and does the same.
Nope. There are many complaints about WPF grids painting very slow. Saw the last one just few days ago. The solution? One said that disabling the hardware acceleration of his Graphics card helped him. Go figure…
Oh, and let me add to the list the pathetic state of internet components in Delphi, indy is ti buggy and you have to rely in providers like Clever Internet Suite to do the job, this is almost 2010, internet everywhere but Delphi is stuck to buggy indy components.
Sorry, but we use Indy quite a lot in the last period and (at least) now and (at least) for our purposes it woks very well. Disclaimer: We use the latest version with Delphi 2010.
And I’d really like to known in what way, the last time I tried to do a simple form post to a webpage with https enabled it didn’t work, the information in forums was that you needed and newer version of an external library indy uses, it didn0t wokr eather, not for production use.
All that details make it suck.
We dropped indy and use ICS for non-blocking server implementation classes that we need to write.
For cases where the “drop it on and use it” crowd needs to “get something done fast”, Indy is still a great solution. For those of us who find that the getting that last 10% done takes 190% of the time, with Indy, I am glad to have dropped Indy completely from all my applications, and ported everything to ICS.
W
And um, MS doesn’t use other vendor’s code? Oh, no, that’s right – they just buy the company and make it part of MS. Ahhh…
That’s why I still think the future is assembly programming!
Assembly is complex for big projects. But of imho it will not disappear and it will have its domain of applications for sure. Anyway, I took your comment with a grain of salt… 🙂
Maybe your friend didn’t know that the collections binded to the grid needs to implement the IObservable interface, if not it will repaint itself every time the collection gets rebinded, even if the order of the collection changes, I have an application that uses a WPF list that is updated every second, it is a 24/7 appliacation that is deployed in a 5 years old server wih windows 2003 and a modest graphics card w/o the problems you describe.
But anyway, that’s not the point, if you use Direcxt with Delphi, what grid will you use, you’ll need to handwrite the components you need because Dorectx is not used in the VCL where is needed.
Just curious, not seeking for flamewar:
On that grid…
– do you have complex painting on many fields based on multiple conditions (colors, images, other components, fonts change, grouping etc.)?
– every second updating is a slow thing, you know. Can you go to the top of the dataset (assuming that your grid covers the entire screen) and keep pressed the Page Down key?
…about the old graphics card. It seems that this helps. Don’t ask why – it is something which comes from experience (mostly other’s experience)
For grids – we never had a problem in Delphi using any graphic card and doing any painting – and believe me we did/do very complex conditional painting using just the simple GDI. No need to investigate other rendering engines for DB-aware applications.
The application is for a gas station. It will be monitoring the all the gas pumbs and it will be updated every second, the state of the pumb will be reflected in the monitor with different gradients color depending of the state of the pumb and it will show the ammont of gas charged every second.
You may say the painting is complex, but you write the XAML and WPF will do the hard work for you, you just need to understand datatriggers and control templates. The update is fast because WPF is hardware accelerated and if you know to use collections with IObservable it will be faster.
The collection is a query to a FirebirdDatabase, the results are put into a List collection, the ordering and logic is manged there, it is fast.
For grids in Delphi I never had a painting problem but I could benevr do what I can do with WPF with it.
Oh, and btw, datasets sucks, use queries and collection, decople your logic from DB components, honestly, is the biggest misstake you can do and is what every Delphi developer do, I know cause I did it my self.
I didn’t meant necessarily TDataSet descendants in the way in which you see it. Yes, we do use queries.
People tend to pick one thing to compare Delphi too (C++ or .NET). The interesting thing about Delphi is you get enough reflection/RTII/VeryHighLevel language features with Delphi to get cool things like RAD to work smoothly (RAD with C#.net is also very smooth), as well as having fast compilation (faster than C++), and faster final target code performance (orders of magnititude faster than C#, and usually always as fast as C++, and for many individual cases, even faster than C++ apps run).
This is the sweet spot. There are three criteria that I care about:
1. RAD capability – speed to develop a Gui. (C++ falls apart most here)
2. Acceptable Performance at runtime – is your code compute-bound artificially because of the overhead of your platform (.net guilty here).
3. Ability to get down close to bare Win32 essentials of the platform (.net guilty here).
If I cared about portability, then perhaps Delphi wouldn’t be so perfect for me.
W
Pingback: Tweets that mention Why we didn’t convert to .Net. And perhaps we never will… « Wings of Wind Software -- Topsy.com
Pingback: …On the Wings of the Software Wind « Delphi básico: Lo más básico de Delphi
Just curious, did you ever consider or evaluate Eclipse RCP for Java or just Swing? I’ve never used Delphi, but I have tried .NET Forms, and I much prefer the “batteries-included” frameworks in RCP as well as the true portability.
ALM wasn’t such a bad thing (as an idea). The reason why it was not successful in Delphi IMHO was they have bought some 3rd party companies, wasted big money for products written in Java (or .NET), slow and not fitting into fast and nice Delphi IDE.
Now with ALM tool going to Visual Studio 2010 I believe we will see it also in future Delphi version, this time much faster, written in Delphi and fitting with the rest of the IDE.
My first attempt in creating GUI’s for W indows was Delphi 5. It was very easy to create a good looking GUI, no need to use an installer (like Visual Basic 6) for deployment and many books where available. I was very happy with this IDE and created many products for different customers. During the years, I followed the productline, so i worked with Delphi 6 .. up to .. 2005 . The last one was the point where i said “it’s enough with that crap”. Meanwhile i changed to Java, as a Borland-Fanboy i used JBuilder 9, which was a very good IDE. Sadly, Borland changed the platform to Eclipse with the release of JBuilder 2005. This was the end of the second great productline.
Borland had not listen to their community, build products which no one wanted and lost the market. Changing the company name does not solved the problem. The good years are over, Delphi (and Borland) is slowly dying. The market is dominated by .NET and Java. The most of my customers want to migrate away from old stuff (Delphi, C/C++, VB) to .NET or Java. They said that this is the future. To earn my money i cannot recommend them to use Delphi for their apps, the future are Web-Apps – not Desktop-Apps, and for this you need platforms like .NET or Java, but not Delphi.
The future is web apps. Call me unconvinced. Fat client, thin architecture is still in my mind the dominant design in my world of big apps a preferred architecture. I have been hearing for a decade that web apps are the future and just around the corner with .Net then and Silverlight now. IMO, the browser is cumbersome, another layer and multi-platform (IE, Chrome, Firefox, etc) that is a PIA to support. I will believe web apps are the true future when the majority of game companies and enterprise applications abandon fat client architecture. As it is now having friends at large development shops such as HP and working in enterprise applications myself, all I hear from the .Net crowd is how garbage collection is killing them, .Net doesn’t scale well and how limited they feel with their controls and this is almost ten years later. Web apps are good for the small to mid stuff, but when you start running a few TB through them you can really see the cracks in the foundation and unfortunately like all wipe-your-butt technologies there is no where to go when the pavement ends. I guess that is why the vast majority of MS products are still C++.
As for Delphi not having good developers anymore. I have to completely disagree. For years now Delphi has some of the best programmers out there. We still have one of the best sourced libraries of any GUI based development system. Ask a Delphi question and you usually get a high level answer. Search for a Delphi solution and you will usually find one quickly. Search for a .Net one and you get a bunch of yahoos that came from VB that don’t really understand OOP or functions beyond basics more often than not. Searching for .net is a PIA as well since punching “.net” or “dotnet” into Google usually ends badly.
I do love .Nets data architecture though. It is what Delphi should have done years ago. Oh and Java sucks. I am reminded of this every time I power up Eclipse to play with Android development. How that language ever moved forward has always been a surprise to me. I think I would rather use Smalltalk which is just slightly less annoying.
The problem is “web apps” are becoming fatter and fatter, just native apps using client side WebOSes – browser, flash, silverlight, air, whatever. To run some applications you may have to install four browser and seven plugins. After a while native apps start to become appealing again. At least the usually have a common interface, and not a different paradigm, UI and widgets each.
Actually, while the future may be the Internet, client web apps are increasingly “fat” but by a different nature.
1) When was the last time you visited a web site not running one of the following, oh by the way, requiring you to download something before using it: Flash, Acrobat, .Net (all versions), Shockwave, active X controls, COM Controls, you get the point.
2) Updates. Sigh all the updates, degrading system performace, reaking havoc on IT maintenance schedules and ensuring future programs, oh more updates.
Sure, the data is remote and not local – so it is with Delphi. I have yet to write an application, since 1990 anyway, where data was not on the local machine.
Meanwhile, oh, wait, I have to download something else to get this applicaiton to run on my machine.
No, the Internet is a tool. .Net is a tool. Delphi is a, wait for it, a tool. The former requiring without regard to users desires, a download of what, a fat buch of DLLs, COMS, and what not. Delphi, on the other hand, may or may not require such bloatware, depending on the needs of the application and development tools used by the Programmer.
I choose .Net when and if it is a better choice for the given situation. More often than not, I do not choose it.
Maybe you’re just too much of an early adopter? 🙂 …too early that when you tried things out, it was still full of quirks 🙂
Java right now is a monster and had tons of performance improvement with 1.5, and now with 1.6 (and in the near future, with 1.7).
Why is Nebeans still so slow then? I mean it would be a fantastic IDE if it wasn’t so slow. I blame it on Java.
Well, I understand you decision to a point. I hope you don’t have to go looking for a job, because you will be up the creek without a paddle.
Great post. We use delphi for creating desktop (reasonably thin clients ~ 3mb) and application servers (including web servers) and it just rocks (especially when combined with Rem Objects, DevEx and UniDac). Note that we also use Visual Studio/C# for creating/maintaining a CMS – so we are familiar with .net’s capabilities and do use it (to me the only good thing about .net is asp.net – I wish they could decouple it from .net). I used to think .net had a real place on servers (never on the desktop mind you), but having gone through so many .net updates and getting wierd error messages because someone built their latest update using .net software for service pack x and the server has service pack w or whatever and there isn’t an easy way to even know what service pack you have (go to windows/microsoft.net and look at which folders are there and or right click on mscore – are you kidding me?). It is VB dlls all over again – in fact I think it is even worse. Add to this the performance issues (go ahead and run server applications (e.g., a website) that all use different versions of .net which is not uncommon – then you have .net 1.1, 2.0, 3.0, 3.5, etc all running at once).
I’ve been a borland customer for 19 years and I think embarcadero has done a great job since purchasing Delphi (thank goodness!).
Go Embarcadero (I liked CodeGear better as a name though).
FYI
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
very, very good post about delphi vs .net, the truth is that web apps, web services and every thing related to them are what the market requires, let’s face it, the market is moving to the web 2.0 and delphi is weak in this point; i think this is what Embarcadero tries to managed with delphi prism, but on the other hand desktop’s apps are way easier to develop with delphi.
@Lars: .NET is *NOT* only for windows. It runs on *nix flavors and some set top boxes via mono. Delphi is ok, but do business end users really care about small executables that are faster via bench mark stats? No. They don’t. .NET is fast enough to handle the largest web sites, the largest business applications, etc. I have never seen one customer, engineer, etc… complain about it’s speed.
Delphi is dead. Maybe .NET is so huge because it’s just that good. I think it’s funny when people make all kinds of excuses for something rather than giving it the credit it deserves. Also, the productivity boost you get from using the VS.NET tools is HUGE. Another advantage to developers with clients with massive expectations to get their vision to market as quickly as possible.
What about things like linq? Delphi (to my knowledge) does not have anything like this (lambdas). What about the fact that multiple languages can target the .NET CLR? In turn this means that no matter what language you are comfortable with, you are can write code for the target platforms without having to learn any new language tied to the platform.
Java sucked and .NET would not have been here if Sun had not sued M$ over thier extensions to Java. Thank God they did. Otherwise we’d all be running on that horrible thing they call a JVM. Great for the *nix world though… well, until mono came out.
“I have never seen one customer, engineer, etc… complain about it’s speed.”
FYI, There were once enough complaints about ATI’s Control Panel (writen in .NET). Nowadays the same phenomenon is seen with Nero (rewritten in .NET).
Also, for your other affirmations can you back them up with some hard data?
Hi Wings of Wind.
Have you changed your mind 8 Years later?
Have you heard about Intraweb 17?
Up to know I´m scared about having to use an ORM.
Although there are some advantages in something like MVVM(not as much as they say),
I´m up to see something more productive than Delphi until today.