Monday, 29 December 2008

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.

Friday, 26 December 2008

Bizspark – Where’s Embarcadero’s equivalent?

Let’s imagine a hypothetical situation. It’s hypothetical because I’m just speculating, but it’s one that could happen, and I’m sure happens all the time.

Right, I’m a Delphi developer. I’ve been working 9-5 for the boss for a long time. I have had a great idea for a product, and would like to try and develop that product independently, and market it. Being a Delphi developer, I naturally would like to develop that product in Delphi. Makes sense. Ok, so what do I need? I have a pc (or 3), so I now need the IDE. Ok so what are my options? I’d like the latest, and greatest. No point in making my mouth water with features such as Generics and Anonymous methods and expect me to settle for less. So  I go to the Codegear (UK) website, and check out the prices. WOW. £979 excluding VAT (currently 15%). I may be able to get a better deal somewhere, but it’s not going to be much cheaper. My product idea is great and all that, but you never know. I need to keep my costs down, and £979 (don’t forget the VAT) is a lot of money for something which may or may not succeed. There’s no such thing as a free lunch you say!

Well maybe there is. Let’s look at the competition. In particular Microsoft. Microsoft have what they call Bizspark. Basically, they’ll give you a whole load of their products, for free if you are a startup. If your revenues are less than a million dollars a year, and you’ve been in business for less than three years that is. Well, if my product starts making a million a year, then I wouldn’t mind paying £979, but right now that’s a little too much. So if I choose to use C# instead of Delphi, I can save myself £979. Actually it’s a lot more than that, because not only do I get Visual Studio, but I also get a whole lot more than that. In fact it will cost me a simple $100 after 3 years. I’ll have tried my product idea with little or no risk, and Microsoft have gained a developer for a cost of $100 to them. By giving me thousands of dollars worth of software for a measly $100, they haven’t lost any sales, because I would never have bought them in the first place.

I mean forget Bizspark. If I really want I can go and download Visual C# Express, and use SQL Server Express as my backend. That’s more than enough for my product. What has Codegear to offer? Turbo Delphi? That’s Delphi 2005 I think. Whatever it is, it’s not Delphi 2009. What about Prism? Do they have a Delphi Prism Express? Nope, not that I can see. Not much of a decision really, is it? I’m a Delphi developer, but C# holds absolutely no fears for me. Codegear have just lost another developer. More importantly, maybe my product idea is a success. Maybe in a year’s time I need to employ a few developers. Codegear have just lost a few more developers. Ok, my product is now really successful. I can afford the £979 for each of my 10 developers. Am I going to switch? Somehow I doubt it?

So Delphi, which used to be the obvious choice for your one man startups, is no longer a viable option. It has always been expensive, but when compared to the opposition, it was still value for money. It no longer is. How much of Codegear’s sales are Delphi 2005/2006/2007 shops upgrading to the latest, and how much are new developers? Or old developers branching out? My guess is that it’s very close to 100% Delphi shops looking to go to the latest offering.

If by some chance, Codegear do have some Bizspark equivalent, well done, but if that’s the case, then it’s very well hidden. I appreciate that Microsoft can afford to give away their products. Can Codegear afford not too?

Monday, 22 December 2008

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!

Sunday, 21 December 2008

Do I really need to be a touch Typist?

I’ve just read Lars blog post regarding programmers and touch typing. I’ve been meaning to write about this for a while as I’ve read quite a few blog posts and heard quite a few podcasts where programmers insist that touch typing is a must have skill for programmers. Now, before I comment, I have to stress that I’m not a touch typist in the true sense, in that I do not use all my fingers. I probably use around 2 or 3 fingers per hand. My speed is around 70-80 wpm and I only occasionally need to look at the keyboard.

Now for the controversial bit. I think that touch typing is not a must for a programmer. So what if you can touch type at 120 words per minute? Can you think that fast? Can you code in your head that fast? Speed of coding has absolutely nothing to do with speed of typing, but rather the speed at which you can solve problems. As I said above, my typing speed, at full tilt, approaches the 80 wpm, but if you were to count the number of words I type in a whole day of coding, and divide it by the number of hours I worked, you’re unlikely to get anything near 80 wpm. That’s because typing is just the end-result of what we do. It’s the bit that communicates what’s in our heads to our machines. It’s not typing which makes us good at what we do, it’s the brain behind it.

When someone says  a programmer must be a touch typist, I assume they are talking about speed. They assume that if you are a touch typist you are fast. And I agree, you are fast. You are fast at typing words. It doesn’t mean you are a fast coder, and it certainly doesn’t mean you are a good coder. It’s a bit like saying an artist must be quick with his brush. Does it make the final painting better?

Lars states that Touch typists are usually able to involve themselves in a discussion about something else, while touch typing. That may be true, but coders need to concentrate. They’re not just typing words, they’re writing code. If you can solve problems whilst whilst holding a discussion with someone about something completely unrelated, then your brain works differently than mine. (Not even women can multi-task where coding is involved!)

(No offence to Lars, I’ve been meaning to write this for a while!)

Thursday, 18 December 2008

Delphi Prism – Class Contracts

One of the new features of Delphi Prism, which you may not have heard about is native support for Class Contracts. Class Contracts are Delphi Prism’s implementation of design by contract.

The whole premise of Design by Contract is that components of a software system interact with each other on the basis of mutual obligations (a contract). Therefore a method of any class may :

  • Insist that any client calling the method must adhere to a certain pre-condition.
  • Guarantee a certain post-condition on exit.
  • or will commit to maintain a certain property (Invariants).

Pre-Conditions

A pre-condition frees the method from having to maintain any checking code as it can be certain that the pre-condition will be met. Delphi Prism implements pre-conditions using the require keyword.

method MyClass.ToString(const aIndex : Integer) : string;
require
aIndex >= 0;
begin
result := fStrings[aIndex];
end;


Pre-Conditions are evaluated before the method is executed.


Post-Conditions

A post-condition ensures that the client knows what to expect from the method after it has executed. Delphi Prism implements post-conditions using the keyword ensure.


method MyClass.ToString(const aIndex : Integer) : string;
require
aIndex >= 0;
begin
result := fStrings[aIndex];
ensure
result.Length > 0;
end;


The old scope prefix can be used in the ensure section for local variables and parameters,  and refers to the values as they were before the method executed.


method MyClass.Add(aValue : string);
require
aValue <> ‘’;
begin
fStrings.Add(aValue);
ensure
Count = old Count+1;
end;

The old construct is only supported for integers and value types of both parameters and local variables. The compiler saves the value before execution of the method.


Class Invariants

Class invariants ensure that certain properties or fields of an object comply with a fixed state. Class invariants may be either private or public. We need to be careful here, as the way these work may initially seem counter intuitive. Public invariants, are checked after every public method only. (Actually, after the ensure clause, if it exists), while private invariants, are checked after both public and private methods. Another point to make is that both public and private invariants have access to all fields of the class. The public and private scope modifiers only indicate on which methods the invariants will apply.



  TestClass = public class
private
fValue : Integer;
private invariants
fValue > 0;
public invariants
fValue > 35;
public
//public methods
end;

Since public fields can be accessed from outside the class, they cannot be used in invariants as there is no way to restrict what goes on outside of the class. Having said that, public fields are never advisable anyway, so it’s not that much of a restriction

If any of the contracts above are not upheld, an assertion is raised. Assertions are by default enabled for the debug configuration, and disabled for the release configuration.


The Future

So what could be added in future to make class contracts even more useful than they already are?


  • Pre and Post conditions for interfaces

ITest = interface
method Test(const aValue : Integer) : string; requires aValue >= 0 ensures result <> '';
end;

With this syntax, we not only specify what the implementation must look like, but we also specify how it must behave.


  • Exceptional Post-Conditions

The ability to specify what exceptions a method can/should raise.


method Test; raises System.OverflowException;

  • Frame Conditions

Frame conditions restricts what a method can modify. Sample syntax could look like

  method Test; modifies fValue; 

Conclusion

Class constructs are not one of those features that you cannot live without. You could happily go on writing code and never use them once. However, by adding class contracts to your code, you make it clearer what the class does, and how it does it. Class contracts remove some of the ambiguity and a lot of the guessing. Up until now, we have used method signatures to indicate how class users can go about using our classes. We have also had to document a lot of other information so the user knows what is expected of him/her, and what he/she can expect from the class. With class contracts, a lot of that documentation is now part of the class, and can be checked at run-time to ensure the application is doing what we intended it to do in the first place.

Saturday, 13 December 2008

Do all great programmers start young?

I was recently hearing one of the Stackoverflow podcasts, where Jeff and Joel were interviewing Steve Yegge from Google. Jeff mentioned how he started programming at the age of around 13, and how the developers he has the most affinity with are also those who started at around 13, and were largely self-taught. Steve agreed with him (being one of those who started young), and insisted that the best developers are those who start young and are self-taught. And I have to agree! Well I would, since I started at 13 too.

I remember my parents bought us a Texas Instruments TI 99/4A, when we couldn’t find any Sinclair Spectrums (I think they were called Timex in the US) in stock anywhere. It was Christmas 1981, and I was 12 going on 13. The first thing I did when we got the computer home, was to type out one of those game listings you’d find in video game magazines. I’d actually bought the magazine before the computer. After spending a few hours typing it in (my typing skills were non existent then!), I typed in run, and waited. It kind of worked, but the score at the top right hand corner of the screen was not working. Disaster! I must have typed something in wrong. So I roped in my little brother to read me line by line, while I checked for any typos. After another few hours, we finally concluded, that we had typed it in correctly. I don’t know what drove me, but I had to fix it. It was a graphical score, with each digit independent of the others. So with every increase in score, you’d increment the units column, until it were at 9, in which case, you’d set it back to 0, and increment the tens column, and so on and so forth. Seems trivial now, but it took me a few days to figure out TI-BASIC, and fix it. But boy what elation when I ran it, and it finally worked. The subsequent month’s magazine printed the bug-fix, but I had fixed it on my own. I was officially a programmer. Luckily due to a hardware quirk, while my friends played fast machine code games on their Commodore 64s and Spectrums, the TI99/4A had some drab Basic and Extended Basic games available or wildly expensive (well to a 12 year old they were)cartridges. So if you had a TI99/4A, you either learnt to program, or you made friends with the neighbours and their Commodore! I started writing games, and even advertised and sold a few tapes. (storage was on plain old audio tapes) …and so began the love affair with computers.

So when did you start programming?

Friday, 12 December 2008

WPF like effects in your Win32 forms

Are you still developing native applications? Would you like to do some cool tricks with your forms? How about making your windows fade in and out?

The Win32 API to the rescue! The function AnimateWindow can be used to blend in and out the form. To the FormShow event handler, add the following code :

AnimateWindow(Self.Handle, 1000, AW_ACTIVATE or AW_BLEND);

To reverse the effect, add the following code to the FormClose event :

AnimateWindow(Self.Handle, 1000, AW_HIDE or AW_BLEND);


You can also get the form to slide in, rather than blend, by changing the flags to AW_SLIDE or AW_HOR_POSITIVE to get the slide to come in from the left for example.



The same approach can be used in Delphi Prism, when using WinForms. While Delphi Win32 imports the AnimateWindow method for you, in windows.pas, in Delphi Prism you have to do it yourself using P/Invoke. (As you would with C# or VB.NET may I add). So in your WinForm, add the following code to the private declaration :



private
const AW_HIDE = $10000;
const AW_ACTIVATE = $20000;
const AW_HOR_POSITIVE = $1;
const AW_HOR_NEGATIVE = $2;
const AW_SLIDE = $40000;
const AW_BLEND = $80000;
[DllImport("user32.dll", CharSet := CharSet.Auto)]
class method AnimateWindow(hwand : IntPtr; dwTime : Integer; dwFlags : Integer) : Integer;external;


Remember to add System.Runtime.InteropServices to the uses clause of your form. Now, you can add the same code as before (it's all object pascal, so the same syntax), to the Load and FormClosing events of your form.



  method MainForm.MainForm_Load(sender: System.Object; e: System.EventArgs);
begin
AnimateWindow(Self.Handle, 1000, AW_ACTIVATE or AW_BLEND);
end;

method MainForm.MainForm_FormClosing(sender: System.Object; e: System.Windows.Forms.FormClosingEventArgs);
begin
AnimateWindow(Self.Handle, 1000, AW_HIDE or AW_BLEND);
end;

So there you have it, forms that fade in and out.

Tuesday, 9 December 2008

Virtual Conferences

A few weeks back, I attended quite a few sessions of Emarcadero/Codegear’s Coderage III virtual conference. I’ve been to a few live conferences before, and have always found them very useful. This was my first virtual conference, and I must say I found it was almost as good as the real thing. There were a few audio issues, but nothing too distracting. As with all conferences, be they live or virtual, some of the sessions were great, others not so great, but I suppose that depends on what interests you. On the whole the sessions I attended were well presented, and hit the mark. I’m going to make a few observations though, so that perhaps Coderage IV might be even better.

  • Time Zones. There were a lot of sessions I’d have liked to attend, but at 4 in the morning, I also like to sleep. Now I know however you play this, there’s always going to be someone who’ll complain that 4 in the morning is time they should be in bed, but since the sessions were recorded, why not repeat them twice, even three times so that anyone in any time zone can find a decent timeslot? I know that you can get the replays after the event, but not the same thing..
  • I felt the sessions were slightly too short. Or perhaps the subjects that were covered were just too vast for the time allotted. I’m sure there’ll be someone who says the sessions were too long though.
  • Attendance was a little disappointing. Does that reflect a decline in the popularity of Delphi, or just the fact that a lot of people don;t like virtual conferences? Has anyone ever attended other virtual conferences? If so, how was the attendance there?

Another thing I noticed during this conference. From a technical point of view, being a trainer is much easier than being a day to day developer. I’m not saying the presenters at Coderage did not know their stuff. I’m sure that they do. It’s just that when giving a session of 45 minutes, you are forced to basically present glorified Hello World applications. You just scratch the surface.

I’m just trying to say that the technical side of things, while important (you can’t do a 45 minute session about something you know nothing about), is only a small part of what you need, to be a successful presenter. In my opinion, one of the best presenters I’ve ever had the pleasure of listening to, was Lino Tadros. His sessions, while having the requisite technical knowledge, had that X factor, that made them interesting, whatever the subject covered. The sign of a good teacher.

Does he still do Delphi, or has he completely gone over to the dark side? If so, he’s sorely missed!

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 Stackoverflow.com, 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.


type
TTraversalMethod = procedure(v: TVertex);

TGraph = class(TObject)
private
public
procedure LinearTraversal(aMethod :
TTraversalMethod);
end;

procedure TGraph.LinearTraversal(aMethod :
TTraversalMethod);
var
v : TVertex;
begin
for v in Vertices do
aMethod(v);
end;

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);
begin
  fStringList.Add(V.Name);
end;

procedure TMyClass.ShowGraphAsText(aGraph : TGraph);
begin
  fStringList.Clear;
  aGraph.LinearTraversal(TraverseMethod);
  ShowMessage(fStringList.Text);
end;

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.


type
  TTraversalMethod = public method(v : TVertex);


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

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

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);
begin
var s: StringBuilder := new StringBuilder(‘’);
  Graph.LinearTraversal(
method(v : TVertex);
begin
s.Append(v.Name);
end
  );
  MessageBox.Show(s.ToString);
end;

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 StackOverflow.com. For those not familiar with StackOverflow.com, 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 StackOverflow.com 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, StackOverflow.com 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 StackOverflow.com? Perhaps the Delphi community just hasn’t found out about StackOverflow.com 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 StackOverflow.com 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.  Stackoverflow.com is that something. What is Stackoverflow.com? 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. Stackoverflow.com 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 Stackoverflow.com, 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 Stackoverflow.com.

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.