Friday, 21 November 2008

Can you read c#?

I've just found another very good reason for using Delphi Prism over c#. I’ve never really used c# in anger, but the little I have used it, case sensitivity just drove me nuts. It’s too easy to make a mistake. A simple piece of code such as

Foo foo = new Foo();
int64 FOO = 20;

is just not readable. It’s all too easy to get them mixed up and try to call a method on the class rather than on the object. Ok, the compiler helps, but that’s all lost time.

That’s a pretty simple example, I’m sure you could get yourself into all sorts of trouble. I don’t see the point in case sensitivity. It’s just another small thing that makes c# unreadable when compared to Delphi Prism. I guess you probably get used to it. I bet c and c++ developers coming to c# just love it, whilst Delphi/Pascal and VB developers loathe it.

Monday, 17 November 2008

Anonymous Methods

Both Delphi 2009, and the upcoming Delphi Prism have support for anonymous methods. Now while I am very excited about other features, notably generics, I just couldn’t get excited about anonymous methods. I just didn’t get them. I understood the syntax, but to me they looked like inline methods. My biggest question was why should I use an anonymous method, and not a procedural types, like we’ve always done in Delphi? Ok, I save having to write a separate method, but what’s wrong with separate. It’s probably more readable that way anyway.

I read blogs the blogs and articles.  I studied examples, which always seemed to be artificial, or just too complicated to actually explain the concepts. I read the Wikipedia entry on closures, which are what everybody else seems to call them, but still no joy. All I really want is to be able to understand the concept, enough that during my everyday work, I can identify areas where an anonymous methods would fit nicely, and where they would be the best choice.

Being a recent convert to, I asked a question there. Can someone explain Anonymous methods to me? I got quite a few answers, some with yet more code examples. I still couldn’t see how any of this was going to make my day to day coding any easier, or even a little bit more exciting! That is until I got one answer which made me go Aha. Actually it was one line within that answer.

Just think of typical callback code where you need to have data available to the callback.

So I looked at some code I’d recently written, which used a callback, and replaced that callback(literally a method pointer) with an anonymous method.  The code I had recently written was an implementation of a Direct Acyclic Graph. Basically a way to represent a number of objects (vertices), and the relationships(edges) that exist between those objects. Think cities(the vertices) with possible flights between them(the edges). Then using certain well-defined algorithms, you can traverse those vertices in various ways. So going back to the cities and flights example, it would be possible to find the shortest route between any two cities for example.

I’d originally implemented these traversals using procedural types.

TTraversalMethod = procedure(v: TVertex);

TGraph = class(TObject)
procedure LinearTraversal(aMethod :

procedure TGraph.LinearTraversal(aMethod :
v : TVertex;
for v in Vertices do

So basically LinearTraversal does nothing special except traverse all the vertices in a linear fashion. Not too exciting. So let’s say we now have a graph and we want to display the vertex names as a string, which we’ll implement using a TStringList;

procedure TMyClass.TraverseMethod(v : TVertex);

procedure TMyClass.ShowGraphAsText(aGraph : TGraph);

You’ll notice that we need two methods, one to actually prepare the call, and the other is the function called on each vertex. We also need a stringlist which must be visible from both methods. Unfortunately even if we make it private to the class, it’s still visible to all other methods in the class. What if some other method is expecting some other list to be stored in that stringlist? A year down the line how can we possibly remember not to touch that stringlist?

What would be ideal is if we could make the stringlist local to the ShowGraphAsText method. Well it turns out we can. I’m going to rewrite the above using anonymous methods. I’ll use Delphi Prism/Oxygene as that’s what I’ve got at hand, but Delphi 2009 would work just as well.

  TTraversalMethod = public method(v : TVertex);

  TGraph = public class
   method LinearTraversal(aMethod : TTraversalMethod);

method TGraph.LinearTraversal(aMethod : TTraversalMethod);
for each v in Vertices do //the type of v is inferred

The actual code for the traversal looks pretty similar. There are a few Delphi Prism constructs. method instead of procedure, and for each in instead of for in. Also note the type inference in the LinearTraversal method.

It’s the calling code that things get interesting.

method TMyClass.ShowGraphAsText(aGraph : TGraph);
var s: StringBuilder := new StringBuilder(‘’);
method(v : TVertex);

We now only have one method (well strictly speaking two), and more importantly we have our local helper variable.

And that was my aha moment. It’s not the actual fact that you can inline an anonymous method where you need it that makes them so powerful, it’s the capture of local variables of the outer method inside the anonymous method. When you look at it like that, you see them in a whole new light. Now I can go back to all those examples I’ve seen and understand them better.

Sunday, 9 November 2008

The TIOBE Programming Index

I’m sure a lot of you (that is if anyone is reading this) are familiar with the TIOBE Programming Index. Basically, it’s an index which claims to gauge the popularity of programming languages according to how many times the term language programming (for Delphi that would be Delphi Programming) appears in various search engines. Some in the Delphi community are very excited to see that Delphi is at #8 snapping at the heels of C#. Take a look at Jim McKeeth’s post on the subject here. Now I’m a big fan of Jim’s blog and podcasts, but I can’t get as excited as he is about this.

First of all, does it seem realistic to you that Delphi is only 0.02% behind C#? I’d love it to be true, but all other evidence points to C# being much more popular than Delphi. Unrightly so in my opinion, but true nevertheless. I’m not saying that the TIOBE index is fixed or anything, but it must be fatally flawed somewhere.

So I thought, what could we use as an index of programming language popularity? Someone mentioned job-listings, which is probably a very good indication, but jobs vary geographically, and usually job-listings are specific to a country or region. So for example, looking at a US job listing site would not give you the true state of a particular language in the world. There has to be something more relevant.

Then I thought, how about For those not familiar with, have a look at my last post. If we could count the number of questions for a given language, wouldn’t we get a fair idea of the current popularity of a language? If people are asking questions about a language, it’s because that language is being used. It has to be a better indication of current use than how many times a search engine can find some particular words.

So here it is. I’ve taken the top 20 languages from the TIOBE Index, and extracted the number of questions for that particular language from by looking at the corresponding tags for that language. I’ve had to use several tags for some of them. For example for Delphi, I took Delphi, Delphi2009, Delphi7 and Delphi-programming.  I may have missed a few tags, but I think I managed to get all the main ones. I also took only the top 20 and not all 50 languages in the list, as it seemed like too much hard work.

Position TIOBE Position Language Stackoverflow Ratings
1 7 C# 26.381%
2 1 Java 15.933%
3 3 C++ 12.126%
4 10 Javascript 9.239%
5 5 PHP 8.560%
6 6 Python 7.988%
7 11 Ruby 4.887%
8 2 C 4.764%
9 4 (Visual) Basic 4.438%
10 9 Perl 1.893%
11 8 Delphi 1.770%
12 18 Actionscript 1.449%
13 13 PL/SQL 0.262%
14 20 Lua 0.166%
15 17 COBOL 0.064%
16 14 SAS 0.027%
17 15 ABAP 0.027%
18 16 Pascal 0.027%
19 12 D 0.000%
20 19 Logo 0.000%

Why has C# gone from 4% to 26%? Well, may just be a magnet for .net developers. Actually, I think it was seeded from a .net questions and answers forum which used to live on the Joel On Software page. I still think C# should be closer to the top than the TIOBE index gives it credit for.

Why is Delphi so strong on the TIOBE index, and not so strong on Perhaps the Delphi community just hasn’t found out about yet. Perhaps Delphi is easier to use, and you simply don’t have the same number of questions needing answers. Maybe other Delphi resources, be they web sites or books or whatever, are so good that we don’t need as much as say Java developers do. Or it could simply be the fact that there are more C# and Java developers out there than there are Delphi developers.

I think it is a whole lot more complicated than this, but the Stack Overflow Index just seems a whole lot closer to what I would have guessed the list to look like than the TIOBE index does. It could be improved. If we could create some algorithm that takes into accounts answers or perhaps even votes as well as questions, we may get a better picture of the current state of each language.

What do you think?

Stack Overflow

I was programming long before the internet, and long before Google. I sometimes wonder how we managed it before we had that great resource. I guess we read lots of books, and perhaps solved more problems ourselves. Or perhaps we just didn’t have as many problems as we do today. Whatever it is we used to do, I couldn’t do my job today without Google.

Well now we just may have something that in a few years time we’ll be wondering how we ever used to do our job without it. is that something. What is It’s a site where you can go and ask any programming question, and get an accurate answer pretty quickly. The genius of the site though, is how it gets developers to answer questions.

To get people to do anything, you either need to give them money, or you have to cater to their ego. Funnily enough, people will usually respond more to having their ego stoked, than if you were to wave money in front of their face. So back to that genius master stroke. has a system of reputation and badges. You earn reputation for asking and answering questions. Other developers can vote your entries up or down depending on how good they think your effort was. That causes your reputation to go up and down. Reputation is like a video game score, and if you spend any time on, it starts to feel like a game. The badges are awarded for attaining certain milestones such as giving an answer with 10 up votes (Nice Answer) or leaving 10 comments (Commentator) etc etc. I’m not so sure about the badges, but gaining reputation is addictive. The more reputation you gain, the more status you have, and the more status you have, the more administrator rights you gain over the site as a whole.

There are downsides to the site though. One is that it is very addictive. The other is that it can get depressing, as you begin to realize how little you really know. When you realize that there are over 40,000 questions,  and you can only answer a handful of them, it can get you down a bit.

So if you have a programming question you need answering, try out

The Future of Delphi

It may seem a little presumptuous to claim to know the future. I don’t know the future, and I’m not presumptuous. This is just my guess as to what may happen to Delphi.

I’ve been working with Delphi, since Delphi 1, and with Turbo Pascal before that, I have used every version of Delphi except Delphi 8 (some may say I haven’t missed anything there!) Delphi’s demise has been predicted since about Delphi 3, and that seems like a long time ago. I’m a Delphi developer through and through. Some would say a fan (as in fanatic). So if I was to write about how I see a rosy future for Delphi, you’d instantly, and correctly, think I’m biased. Well, I have taken off those rose-tinted glasses to bring you this post.

Technically I can’t fault Delphi. It makes creating Windows applications so easy. At the same time it’s as powerful as you need it to be. It’s the best of both worlds. Unfortunately, in this world excellence doesn’t guarantee anything, and perhaps in our business more than any other.

At work I use Delphi exclusively. Currently Delphi 2006 and 2007, and no doubt we’ll upgrade to 2009 in the not too distant future. We have a lot of Delphi code, so it makes sense. The trouble is, it’s only that legacy code which keeps us from moving to something else. It’s a combination of things. Probably the most compelling reason is that we just can’t find any good Delphi developers. We can’t even find any bad ones. So recent recruits have been mostly Microsoft developers willing to “downgrade” to Delphi with the promise that we’ll be moving to .NET as soon as possible. The more of these types of developers we recruit, the more clamour there is to ditch Delphi. It’s a vicious circle. We’re in it, and there’s no way out.  I bet many Delphi developers are in the same boat. some perhaps further down the line. With Delphi already consigned to the recycle bin of history.

So what can Emarcadero do to reverse this trend? I guess if I knew, I’d have a job waiting for me at Emarcadero. I don’t have any magic solution, but I do have a few ideas. Let’s look at the .NET strategy (some, more cynical than myself would say “what strategy”) So we have Delphi Prism coming up. Delphi Prism is basically Remobjects Oxygene dressed up as a Codegear product. I’ve messed around with Oxygene, and I’m impressed, but as I said, this is not about technical excellence. My guess is that Remobjects have done this because they’re not selling as much as they hoped they would. If they were wildly successful, they’d have politely declined any overtures from Emarcadero. The fact they didn’t tells me they’re not (wildly successful). On the other hand, I think for Emarcadero to go down this route also means they can’t have been that successful with their previous strategy. If they were, they would have continued down the same road. So it’s a win-win situation. Remobjects get’s more exposure and credibility. Emarcadero get a foot in the .NET world without having to do any work, and have more time to dedicate to native compilers. What does this mean for us Delphi developers? Can somebody (perhaps from Codegear) give me one good reason why anyone would use Delphi Prism over C'# to produce .NET applications? I can’t see any reasons. Some will point to Delphi Prism’s extra language features. Others will say the Pascal language is much cleaner. And guess what I agree. But my manager doesn’t care about futures; He doesn’t care about indexed properties;  He doesn’t care that begin and end and much cleaner than {} All he cares about is that he can find 100s of C# developers when he’s recruiting, and that the industry standard for .NET is C#. In fact if I think with my head and not with my heart, even if it was my decision to make (which it aint!), I’d go for C# (better developers than me have made that decision, so I’m in good company, think Anders, Danny, et al) In fact the only way Delphi for .NET could ever work is if the native compiler is successful. If the native compiler is successful (again) then you have lots of developers who prefer begin and end to {}, and if you’re writing native code in Object Pascal, it makes sense to stick with the same syntax in .NET.

So how do we make Delphi successful again? Can it even be done? What made Delphi successful in the first place? Before Delphi came out, and I was developing DOS applications using Turbo Pascal, my most treasured development tool was my pad with a grid of squares! I’d divide it up into 80 columns and 25 lines, and build my UI. Can you imagine what a radical difference Delphi was? That’s what made it popular. It was just so different. You could create a Windows Application in seconds. No other tool at the time could do that. Not with so much ease, and not with so much power. So innovation was the first reason it was successful. You have to stand out.

The second reason was that most developers coming out of school were Pascal developers. Delphi felt comfortable. I think even if Delphi 1 hadn’t been so good, it would still have been a hit. What do kids learn in school nowadays? Java perhaps! Why has this changed? Turbo Pascal doesn’t exist anymore except in museums. Ok, I’m sure Borland had their academic licences, but I bet it wasn’t easy to get. What they really needed was a version of Delphi that retailed for $49.99. Hey, even that’s expensive. Let’s make it free. I know they tried with their Turbo Delphi range, but it all seemed so half hearted. Borland took their eye off the ball. They thought could get into corporate America through the front door. There’s only one way in, and it’s through the back door. Make Delphi so popular with students and hobbyists that the development world is flooded with Delphi developers creating Delphi applications and components. Basically bring Delphi back to the foreground. I bet a lot of developers think the last Delphi version was Delphi 7, and that Delphi is dead. Hell, I bet a lot of younger developers have never heard of Delphi.

Let me finish on a positive note. Codegear can emulate Delphi’s early success, and can both innovate, and appeal to students/hobbyists. The upcoming 64-bit version of Delphi, may just be that innovation, but it better be good. Create academic versions, and hobbyist versions. Give them away for free or practically nothing . You’ve got to speculate to accumulate. Even if I don’t get to use Delphi professionally, I’d love to carry on writing open source software using Delphi, but not if it costs $899 dollars(just a guess, please don’t email me to tell me it’s cheaper. All I know is that I can’t afford it) Go to schools. Give them free copies.  Make Delphi the choice of up and coming developers. If Codegear can do that, then success with Delphi Prism will follow. It won’t be easy, and if I was a betting man, which I’m not, I wouldn’t put any money on them succeeding. The odds are just stacked against them. But, I wish them well anyway.