Saturday, 18 April 2009

Generics in Delphi 2009

I've now had Delphi 2009 installed on my machine for about a month, and have been refactoring some code to take full advantage of Generics and Anonymous methods. I really like generics, but am beginning to feel really uncomfortable with the Delphi implementation. It just doesn't feel 100% stable. I get the occasionaly internal error, which then dumps you somewhere at the very beginning or very end of a file, with no indication about what you have done wrong. Try adding the overload keyword to a method in a generic class, without actually overloading the method for example. Code completion is a bit of a mess, sometimes working, and sometimes not. I won't even mention the TDictionary class, which is practically useless, as it is riddled with bugs. Well perhaps not riddled, but there are a few, making it unusable. Try using the enumertors for example.

Why release it when it clearly needed a little more work? When is it going to be fixed?

Friday, 3 April 2009

Component ITunes

Delphi’s strength has always been the VCL, and it’s extensibility. You always got a lot out of the box, but the knowledge that whatever you wanted to do, there was a component somewhere out there that would do it for you was an incentive to use Delphi. I could, and did spend days on the Delphi Super Page, just downloading components and trying them out.

Borland (and now Codegear) have always been careful not to step on the feet of their third party vendors, so always left some gaps for them to fill in. And rightly so. That’s why Delphi was such a success.

Unfortunately, the third party vendor scene has not been as vibrant as it once once. Sadly, the number of vendors producing quality components has decreased greatly since the glory days.

The freeware and shareware scene was also beyond compare. Now almost all freeware and open source components have not been updated since Delphi 7. The Delphi super page sometimes feels like a museum. With the advent of Delphi 2009, this problem can only get worse, because while before, a simple recompile would suffice, now you have to do some extra work.

I think Borland were 100% right in leaving the market open to third party vendors, and stepping back and letting others fill the void. It made Delphi popular, and it made the vendors happy.  But times have changed, and perhaps now it’s time for Codegear to step in, and help it along a bit.

My suggestion is for Codegear to setup an ITunes for Delphi components (you know what I mean!). Somewhere, vendors, developers and Codegear themselves can sell (or give away) quality components. Codegear could approve anything deemed worthy to be on there. There is a lot of abandon-ware out there that could be resurrected and brought up to date for Delphi 2009, endorsed, and offered up by Codegear. There’d be one central place where Delphi developers go for all their component needs.

The remaining third party vendors would be happy, because they’d have another outlet for their products. New vendors would be happy, because they have a customer base ready, and waiting, and hungry for new components.

If Apple can do it with music, why can’t we do it with components?

Saturday, 28 March 2009

When did the internet become so essential?

Next week I’m going into hospital for a knee operation. I’m not worried about the pain, or the months of rehabilitation afterwards. I’m worried about how I’m going to live five days without an internet connection.

I’d gladly exchange painkillers for a wifi connection. When we get the occasional problem with our broadband connection at home, I go crazy worrying that it’s going to be days or even weeks before we get it back.

I don’t know if it’s just me, but I’d gladly give up TV, telephones, game consoles, (some) food, warmth, comfort rather than lose my  internet connectivity. At what point did connectivity become so important? I know there are people out there without connections, but it astounds me. I guess there are more important things, especially in developing countries, but in the first world, it’s quickly becoming essential to be within a metre or two from a computer with a connection. I guess with the advent of devices such as the IPhone, we’re going to be even closer to that connection than ever before. And we’ll subsequently fret even more when we’re cut off.

Friday, 27 March 2009

Catch 22

I’ve just read Marco Cantu’s comments about a few of my posts. (I’m honoured Marco!). The crux of Marco’s comments is that Delphi developers fall in to two distinct camps. Those who want Unicode and those who don’t. Therefore Codegear had to make a choice on whether to make it easy for camp 1 or camp 2.

There are a few problems with this hypothesis.

  1. There are more than two camps. I fall under neither for example. I want Unicode. I really do. I wanted (or rather needed) it so much in fact, that I implemented Unicode support using Delphi 2006. I would like to be able to move to Delphi 2009 (after all it is the latest and greatest, and where I can expect the most support, and where I hope migration to 64bit will be easiest), without having a major dip in the quality of my software.
  2. By choosing to change the meaning of PChar and String and all those methods that ultimately called Ansi versions of windows functions, what Codegear did was make it difficult for everybody. Those that are not interested in Unicode have work to do, and those that are interested in it also have work. Anybody who’s done the conversion knows that the biggest problems are places where PChar has been used as a pointer to a byte. Buffers and bookmarks in dataset descendents for example. So it’s never just a re-compile.
  3. All those who are defending Codegear’s decision, keep saying it’s easy to make the move. It’s x days work, it’s no big deal etc etc. That maybe the case, but experience tells me that making such a change will result in a far greater hit to the testing burden than actual development time.

I’m almost ready with my migration to D2009. It was probably harder (ironically) than most, because my application already was Unicode compatible through use of Widestrings and TNT unicode components, but it still wasn’t that bad. The thing is though I know for a fact that my application has gained a few (only a few mind you, I’m optimistic) bugs. It’s inevitable. And because most of the problems were to do with buffers and pointers, it’s those subtle, “it was ok on my machine” type of bugs. The testers are not going to be too happy. The first thing they ask when they receive a build is what should they concentrate on. My answer this time is everything. I’ve touched every single piece of functionality. Most (if not all) their automated tests are probably broken (I haven’t told them that bit yet!), so not only do they have a lot of testing to do, they have a lot of test code to migrate. And at the end of all this what does our application gain. Nothing. At least those who have Ansi applications can say we now have Unicode support. We can’t, we had that already!

I think Codegear had a dilemma, and quite a few people must have had a few sleepless nights trying to figure out what the best thing option was. Whatever they had chosen, would have caused someone, somewhere grief. Had they gone for any other option, I’d probably be writing a post complaining about it. I’m like that!