C# Native Compiler

I was wondering the other day about all the (failed) attempts by Borland/Inprise/Borland/Codegear/Embarcadero (that list there says a lot just by itself) at diversifying their native Delphi compiler. You had Kylix (Delphi for Linux), Delphi for .NET, and C# Builder. All of them not really what you would call successful. Now they are working on a cross-platform compiler, which will be the next version of Delphi. (I still don’t get why they think this is more urgent that a 64-bit compiler)

Has anyone ever contemplated a native C# compiler? I don’t mean something that could take existing C# projects and compile them for Win32. Delphi for .NET showed that the two platforms are just too different for that to ever work in either direction. No, what I’m thinking about is a C# native compiler built on the VCL and the Delphi IDE. I think we all agree that there is a place for native development. There’s a load of C# developers out there though, who would never contemplate Delphi, but if they needed to write some native code, they would certainly look at a C# native compiler.

If that worked, it would definitely save Delphi. As long as the VCL was alive, and you had the same kind of compatibility you now have between C++ builder and Delphi, then Delphi would be back in the limelight.

Just a thought.

Wood from the trees!

When I first picked up Delphi 1, I was amazed. I could kick up a decent application in no time. Prior to Delphi 1, we designed user interfaces on 80x25 squared paper. Delphi was that big a leap! I found it really easy. I was a Turbo Pascal programmer before Delphi, so the syntax was familiar. The RAD, drag and drop paradigm was easy to pick up and run with. I had it made.

So, here I was creating applications with an Object Oriented programming language and tool, therefore I was an OO programmer. Right? Well, the only classes my applications had were the form classes created by Delphi when you add a new form to the application. My first applications were a mess, multiple forms, with 100s of components stuck on then. I didn't know better. When anyone in those days demonstrated the power of Delphi, they would open a form, put a menuitem, a few dialogs and a memo, then they'd write a line or two of code, and voila, they had created notepad. Wow. I can do that I thought, and I did.

As time passed, and  moved to Delphi 2, I got better. First I moved all my database components to datamodules, but it was still a mess. No classes of my own to speak of, and global variables scatter everywhere. It was an improvement, but not by much. I was still writing procedural code. Moving onto Delphi 3, I discovered objects and classes. I ditched data-aware components, and learnt a bit about inheritance and polymorphism. I dabbled with interfaces, and started applying sound principles. Nowadays, I like to think I know what I'm doing, but still to this day I continue to learn. It amazes me that there is still so much to learn, but that's ok, it keeps it interesting.

So where am I going with this? Well, just because someone uses an object oriented language, it doesn't make them an Object Oriented programmer. The language, and the framework are just tools. It doesn't matter how good those tools are, in the wrong hands, they can cause havoc.

I've mentioned before in a few of my blog posts about the inexorable move towards .NET and away from Delphi at my place of work. I'm a lone voice in the wilderness pushing for Delphi, but when minds have been made, it's difficult to un-make them. One of the main reasons put forward by the .NET band, is that we'll find it easier to find developers if we ditch Delphi and go for .NET. It's true that each time we advertise for a Delphi developer post, we only get a few responses. It feels like we're scraping the barrel. It takes a long time to find a good Delphi developer. There's not many of us (notice how I subtly included myself in that statement!) Will it be easier to find C# developers? I'm sure for each post we advertise, we'll get 10s if not 100s of responses. Will they be any good? I don't know, but there will be a good percentage of them who, because they know a bit of C# will think they are .NET programmers. I think it's going to be just as difficult to find good .NET developers as it is to find good Delphi developers. We'll just have more CVs to throw away, and more interviews to go through, until we find the right people.

Some are more equal than others!

I've been trying to evaluate some scripting solutions for a Delphi application I'm working on. One of the things we do a lot of is repetitive calculations. So we wrote a small test example to try this out. It's a very contrived example, but it should give us an idea of how fast these solutions are. We basically nested two loops, and did some random mathematical functions inside the inner loop and put the results into an array of doubles. The details are not too important, but the first thing that stood out is how blindingly fast Delphi is. And by contrast how excruciatingly slow these scripting solutions can be. Some were better than others, but all were magnitudes slower than the native code. I kind of expected that, but not by such a margin. The best solution was surprisingly VBA at five times slower than native Delphi. Not sure if Microsoft still licence it though. I guess we may have to rethink how scripting will work in our application.

Now to the title. What's equal to what? Well, I was wondering how fast the same code would be if I wrote it in .NET. I chose C#, and was surprised to find it marginally faster than native Delphi code. Well, not that surprised. I expected it to be fast, maybe as fast as, but not faster than Delphi though. It wasn't by a lot, but it was impressive nonetheless. I guess the optimisation's that are now possible when using a JIT compiler are beginning to outweigh native codes inherent speed. I'm sure there are some things always suited to native code, but for most things, the fear that .NET is going to be slow is unfounded.

Just for the sake of it, I decided to rewrite it in VB.NET, expecting the same result. Wow, almost twice as slow. I wonder why. And the executable is more than twice the size of the C# equivalent. Ok, now I was really interested, so I wrote the whole thing in Delphi Prism. Syntax wise, apart from the usual begins and ends, the Delphi Prism version feels more like the C# version than the .NET version, and the performance is almost exactly the same as the C# version. The executable is 4 times the size of the C# one though. I managed to get it slightly smaller by getting rid of the icon, but it's still larger. Why? I'll investigate later with reflector.

Finally, I wanted to try and use the asynchronous features of Delphi Prism. Nothing too complicated. So I just split up the outer loop into ranges, and used Delphi Prisms async keyword.

var x := async ExecuteIt(0, 2000);
x; //Waits for the async method to execute

Since I was timing how long the whole process took, I used the waitable result of the asynchronous statement to make sure each of my chunks were ready before I stopped the clock (but I made sure they didn't wait on each other). On my dual core CPU, the resultant application ran almost twice as fast as the synchronous version. The extra method call, plus switching overhead making sure it wasn't exactly double. Pretty cool stuff, and I've only just touched the surface.

Positive Delphi Post

I’ve been a bit negative towards Delphi in my last two posts, here and here. Actually they were negative towards Codegear/Emarcadero and not to Delphi. Delphi has been good to me, so here’s a positive post.

One of the major reasons people/companies say they can’t use Delphi for any new work is the uncertainty of where Delphi will be in a year. They say things like “What if Borland/Inprise (remember that?)/Codegear/Ebarcadero are not here in a year’s time?” All pretty good questions, but ones I’ve been hearing since about Delphi 4. The thing is Delphi may actually be in a better place than Microsoft technologies! No, here me out!

If I’d have started a project a year ago, and chose Delphi, I’d have used Delphi 2007. Right now I’d be upgrading to Delphi 2009, and adding Unicode goodness to my application and looking good for the future. Now, if I’d have decided to write my application in C# or VB.NET. I’d have probably gone for a Winforms application, and have used Linq to SQL to get to SQL Server. Well guess what, Winforms and Linq to SQL have been superseded. You’re supposed to use WPF and Entity Framework from now on, even if those two technologies feel decidedly beta at the moment. Who knows what they’ll have replaced them with in a year or two. There just doesn’t seem to be any plan there.

Happy New Year.

The Hypothetical just became Categorical

My last post was about Microsoft’s Bizspark program. When I started that post, it’s entire premise was built on the hypothesis that I would want to start a Micro ISV. As I wrote more and more of it, I kept saying to myself, why not? Give it a go? You’ve got no excuse now.

Now don’t get me wrong, it wasn’t just the cost of Delphi that kept the idea just that, an idea. There are other things, but the fear of failure is a really strong deterrent. I guess that fear is still there, but if I do fail, I won’t have spent a few thousand Dollars/Euros/Pounds setting up my development environment.

I’ve got a few ideas for products. Some of them pretty good. I figure whatever I do, I’ll be learning, and that’s always a good thing. So I signed up for Bizspark. I thought I’d have to go through hoops. I thought it would be hard. In fact it was really easy. I just found a partner willing to back me, and I’m in, I’m now a Bizspark member.

I’m slipping slowly away from my Pascal roots. It does hurt, but I have to follow my head and not my heart. At work we are moving away from Delphi, I’ve got to keep up, and start thinking more like a .NET developer, and less like a Delphi one.

A few of the comments to my previous post, said forget licenses, use a pirate copy of Delphi 2009. Well, that just doesn’t feel right to me. Ironically though, Codegear get no money from those pirates, but they get no money from those of us who just can’t afford the price of their product either. Nobody wins.

I’m sure I’ll be using Delphi for a few more years to come (First smile since the start of this post). It’s what I’m paid to do. But the decision has been made at work. Sooner or later I’ll be doing C# full time.

Program Structure – Code Folding

You know how in Delphi 2005 (could have been Delphi 8, but who actually used that?) Object Pascal was introduced to the world of code folding. Code folding, is where the IDE lets you hide certain parts of your code. Either it automatically chooses certain areas, or you can add further areas of your own.

Great, we all said. We have the same feature they have in C# and Visual Studio. Honestly though, have you ever used it in Delphi? I did initially, just because it was there, but I soon realised I just didn’t need it. Object Pascal with it’s interface and implementation sections allows you to look at a class’s declaration, and understand what it does at a glance. C# on the other hand, mingles the declaration with the implementation, which makes classes unreadable if they get above a certain size.

You can look at this from two angles.

1. Object Pascal, while verbose is much more readable. With things like class completion and jumping between method declarations and implementation, the verbosity is not that big a deal, and anyway, I’d rather type a little more code if it makes it more readable.
2. C# encourages you to make classes small. That’s a good thing. With Object Pascal, you can create very large classes, and still maintain readability, whereas with C#, you are forced early on to keep classes small.

So I guess the conclusion I came up with is that code folding is bad. If you need to fold code to make it readable, then your classes are probably too big. If you ignore code folding, C# actually may have an advantage here, because you are forced to some extent to keep classes small, whilst Object Pascal encourages (or at least doesn’t penalise) you to use large classes.

I think I’m going to call it a draw!