or: How I learned to stop worrying and love the bomb
For a very long time, I was a Delphi only programmer. Between 1996 and 2008, I exclusively coded Delphi, and I loved it. I made the switch to C# in august 2008 and I haven’t looked back since.
I was recently asked how I felt about the switch, and I thought I’d document my answer here, in case someone else was thinking about making the switch.
It seems to me that Delphi and C# are the only two interesting alternatives for Windows Application development. Java… well… the applications look horrible…
Why move from being a “master” in one field to being a “noob” in another field?
Ok, so maybe I was never a master, but at least I had 12 years of experience, and with C#, I’d be a noob (newbie/new user) again. That did scare me for some time, but in the end, learning new stuff is what being a developer should be all about – it’s the reason why I’ve stayed a consultant instead of taking a steady gig.
Switching was a chance to learn new stuff, to grow a bit. And being a noob isn’t all that bad – the fact that I have been coding since 1986 helped a lot, I’d say I’m pretty proficient at C# by now – though there’s sooo much more to learn.
Let go of the fear, study the arguments for and against instead…
Delphi is Dying
Let’s face it, Delphi has been dying for a very very long time. It might not be dead yet, but it sure smells funny. I doubt Embarcadero will be able to turn the ship around, especially since Microsoft is investing so much in C# / Visual Studio development.
Microsoft don’t even need to make money of Visual Studio – the fact that they attract developers to their environment is win for them either way; it’s a lock in factor for them. Their main business is in the OS/SQL Server/Office sectors. Visual Studio is an enabler, enabling corporations to use their other platforms.
Embarcadero must make money from their products, that’s how they make a living. How can they compete with Microsoft in the long run? I doubt Microsoft even considers them a competitor, they probably view Delphi as irrelevant.
So there will be fewer and fewer new projects developed using Delphi, and maintenance programming is not for me. Any project comes with a certain amount of maintenance, but it’s in new development my heart lies.
When I left Delphi, there was talk about when, oh, when will the 64bit version arrive? Will it ever arrive? It seems this debate is still raging. Not a problem with C#/Visual Studio…
C# is ALIVE
C# is very much alive, with “new” stuff like Generics and lambda programming (more on this later). Most Delphi programmers considered that Delphi 2005 was the first useful version of Delphi since Delphi 6, and Delphi 6 was years and years and years old by that time.
In the Visual Studio community, people seem to be looking forward to the next release, but the Delphi community usually just shrugged about new releases for Delphi.
So, Delphi performs better than C#, right? I’d assume so, I’ve never benchmarked the two. Since Delphi compiles code to native binaries, it ought to be faster. And I’ll grant that maybe it is, even though a good JIT compiler can optimize the binaries for the actual CPU you’re using – not some generic CPU most people are likely to use, which is what Delphi does.
But that’s largely irrelevant, hardware is cheaper than coding time, so developer productivity is far more important than raw performance. If system A is 10% more efficient than system B, but system B is 10% faster to code for – go with system B and buy a faster computer!
I used to worry a lot about this, because I ran lengthy simulations. Now I just don’t care, let the simulation finish an hour later, if I can spend an hour less time coding it up. My time is precious, my computers time isn’t. And to be frank, I’m not sure the execution difference is that significant.
Performance typically comes down to the algorithm you use, anyway. If your program is slow, don’t try to squeeze out 10% more performance out of your current algorithm, try a different algorithm! Try hashing, skip-listing, pre-compiling, caching, lock free structures, spatial partitioning, try anything except re-ordering your operations to squeeze out a liiiitle more.
But for bare-metal coding, you can’t beat Delphi, there, I said it.
Garbage collection is strange, we had it with the VIC64, but it wasn’t any good so people gave up on it. And all of a sudden, now it’s good again? I can collect my own garbage, I can manage my own memory de-allocations, no need for the system to do that for me… except, I can’t trust other tool developers to do it correctly. If I use someone else’s software in my solution, a memory leak in their software might crash my software! Also, time spent making sure my structures are de-allocated is time not spent doing something more productive.
Don’t worry about it, it just works. Spend your time doing other wonderful stuff instead!
For real time applications, clearly, garbage collection is a dangerous thing, because your application might become unresponsive at exactly the wrong time. I don’t do real time applications, so that’s not a problem for me.
Productivity is what’s really important to me, my time is precious, my computers time isn’t. So if I can spend less time coming up with the same stuff, then I’m all for that. And with C#, I’m way more productive. I’ll try to explain why.
The Delphi environment is ok, nothing wrong with it, especially if you use some of the plugins for it. The Visual Studio environment is better and it has better plugins (Resharper). Refactoring your code using Resharper is a bliss.
But for me, productivity isn’t a property of the the environment, it’s mainly a property of the language.
Having gotten over the differences between the Delphi and the C# syntax, I’m far more productive with C# than with I ever was with Delphi. Now, when I left, Delphi didn’t have Generics, but I understand that it does now. So in my examples, I’m comparing an older version of Delphi with the current version of C#, not particularly fair, but there you are.
I must have implemented a thousand descendants from Delphis List, containing my own objects. I hope I never have to do that again. With generics, that just works out of the box. Anyway, I’m laying
public void FireAll()
List<Employee> employees = GetAllEmployees();
foreach (Employee employee in employees)
And I must have written 10000 loops in Delphi, for i := 0 to List.Count-1, I could do that in my sleep. I hope I never have to do it again. Foreach is now part of Delphi as well, but even that’s too much work for my taste! Here’s where the wonderful world of Lambda comes into play. I just love it to pieces. I’m naming my name kid Lambda;
public void FireAll()
GetAllEmployees().Foreach(employee => employee.Fire());
Or, even more cryptic
public void FireAll()
I must have written 3365 different for loops where I was looking for a particular item in a particular list, an item that matched a particular constraint, a predicate. No more, no more I say;
What used to be (it would look very much the same in current Delphi);
public Supplier GetSupplier(List<Supplier> suppliers, int supplierId)
foreach(Supplier supplier in suppliers)
Would now be;
public Supplier GetSupplier(IQueryable<Supplier> suppliers, int supplierId)
.SingleOrDefault(supplier => supplier.SupplierID == supplierId);
How’s that for productivity?
I need to find sum up the sales figures for all suppliers in a specific region? Here’s the code;
public decimal GetSalesForRegion(IQueryable<Supplier> suppliers, string region)
.Where(supplier => supplier.Region == region)
.SelectMany(supplier => Order_Details)
.Sum(order_detail => order_detail.Quantity * order_detail.UnitPrice);
I can’t tell you how many times (actually, it’s 37.4) I’ve wished that I could use something like SQL to query my objects – why must it be so much harder in code than it is in SQL? Now all of a sudden, it isn’t!
Oh, and both those code snippets would work against lists of objects. But they would also work against objects in the database, because my Supplier object is a LINQ to SQL object. Both queries would automatically be converted to SQL statements that run against the database!
It’s like magic!
I’ve spend months writing code to bridge between my database and my client/business side code. No more! NO MORE!
Btw, I trust that you’re aware that 74.8% of all statistics are actually made up?
With C#, I save time on;
- declarations (generics)
- serialization/deserialization for local storage or transportation (Serializable/DataContract)
- loops (lambda and generics)
- database access (LINQ to SQL)
- mapping from db to code and back again (LINQ to SQL)
- rendering my objects to on the GUI (WPF)
- communicating between by business layer and my client layer (WCF)
I feel that where Delphi lacks vision, having tried to follow C# into .NET and what not, C# is a powerhouse when it comes to vision. Even though I’m doubtful about .NET 4.0 and all this Dynamics stuff. C# guys, please don’t make the mistake of adding everything you can come up with to the language…
If you ship C# projects, you must make sure your customers have the appropriate .NET framework installed. This used to be a huge problem, but most people have most frameworks installed already, so it’s not a major problem anymore. It’s still a consideration. With Delphi applications, no gigantic download is required.
Silverlight and the Web
What to do? Silverlight to the rescue, Silverlight allows you to write business applications with C# code that execute on the the web (in a browser). It doesn’t currently work for Linux (though that’s planned), but it works for Windows and MacOSX.
I can write a program in Visual Studio for Windows – which is great for rapid prototyping, then use the exact same code for Silverlight! The same GUI, the same logic, the same…
Well, that’s not totally true, but if you work within certain guidelines, you can re-use your code with some minor reworks. For instance, you need to use a different assembly (project in Delphi lingo) even though that assembly can contain the same files. That’s because the assembly compiles to a different binary.
For me, C# is my choice going forward. Mainly for the productivity, the vision and the ability to create RAD business applications for web deployment.