Monday, 14 December 2009

Is Embarcadero working on a Garbage Collector for Delphi?

Or is Barry Kelly (Compiler Guy at Embarcadero) just doing some bedtime reading? If he’s not working on this, I hope he’s working on the 64-bit compiler! Actually, I think he’s refactoring c to c++ code!

Jokes aside, I don’t care how many road-maps we get from Embarcadero, or reassurances of the health of Delphi from the powers that be. The one thing that gives me hope for Delphi’s future is having really talented and genuinely clever people working on Delphi. And I don’t really care much for IDE enhancements, but the compiler stuff, that’s where Delphi can make a difference. So it’s good to see Barry’s posts on his blog and on stackoverflow. For the time being, the compiler seems to be in good hands!

Monday, 21 September 2009

Delphi Community Edition

I’ve just read Jolyon Smith’s post on a Delphi Community Edition. All good stuff, and something I have been clamouring for, for quite a while. The thing is, I don’t think it will happen. Embarcadero are in the business of making money, not giving things away. Incidentally, I think they’d probably make more money in the long run if they did give some things away, but playing the long game can be very difficult.

So here’s a suggestion which is a mix of both the long and short game. I’ve suggested something like this before. Here it is slightly refined.

  1. Create a Delphi Community Edition/Turbo Editon, call it what you want, but the most important thing is it’s price. Yep, it’s free, or perhaps even better make it $99. (For some reason people think free stuff equates to poor quality)
  2. Do all the things Jolyon suggested. Digital Watermarking for example.
  3. Create an app-store on the Embarcadero website, that can accept apps/components from the Community Edition. Embarcadero get a percentage of all sales. (and perhaps they have some utility to remove the watermark when sold through the store)

So users get their cheap edition, but they also get a reason to use it. Why do people put them selves through the hassle of learning Objective-C and Cocoa for the IPhone when it’s arguably easier to develop for Windows Mobile? There’s money in it, that’s why!

Embarcadero get their $99 for the IDE and their 5-10% cut of sales, but more importantly they get a new user. Someone who would have used C# Express Edition, but saw an opportunity. Apple do have the advantage of a closed system, so perhaps it wouldn’t work for Delphi, but Embarcadero would not lose a thing by trying. The developers who currently would buy Delphi Professional, are not the target, and if done right, would still want the Professional version. Your target is that new developer about to download C# Express.

Thursday, 10 September 2009

Customer Care

I was browsing Delphi tagged questions in stackoverflow yesterday, when I encountered this question. It’s all about generics in Delphi 2009. Whether they are actually usable. Here are a few clips from the answers :

 

I'm using generics extensively in Delphi 2009, and I can say it's not easy as you are often required to work around an ICE

All this trouble seems to be gone in Delphi 2010

Bottom line: if you want to use them, upgrade to 2010.

 

I have also personally mentioned before that the IDE just doesn’t seem to recognise the existence of generics (try any refactoring or code completion). So basically what we are saying is that if you bought Delphi 2009, and you want to use generics in any meaningful way, you need to fork out more money and get Delphi 2010.

Does anyone else find that disturbing? Let me give you a comparison. Let’s say you have just bought a Dell laptop. It cost about the same as Delphi 2009. The (fictional) Dell Longitude 2009. Among it’s many features, is built-in wifi. When you got the laptop, wifi kind of worked, but the laptop didn’t really recognise it had wifi, and you had to do a lot of manual stuff to get it working. When you did get it working, you noticed in some circumstances, it just refused to work, and in others it only kind of works. You complained to Dell, and they released update 2 and update 3 (some kind of bios update), which made things a lot better, and you were kind of happy. Less than a year later, Dell release the Longitude 2010. It looks like they’re not going to fix the existing wifi problems in the Longitude 2009, but if you have a 2009, they’ll give you a special price on a brand new 2010.

Would you buy Dell again? Would you not expect Dell to fix your Longitude 2009? And if they can’t or won’t, don’t you expect a refund?

I’m not singling out Embarcadero here, it is apparently industry practice. What other industry could get away with it though?

What worries me is that I have to go to my boss and ask to upgrade to Delphi 2010. I am lucky, that I work for a company that has no problems in giving us the latest tools, whatever the cost. And in the grand scheme of things, to even a small company, the price of Delphi is insignificant. However, my boss will definitely ask the question, What does Delphi 2010 give us? I can wax lyrical about increased IDE productivity, and improved RTTI, but at some point I’ll have to add the line. Well, we had a few problems with generics in D2009, but it’s all been sorted out in D2010. What kind of confidence does a line like that instil?

Friday, 21 August 2009

W32/Induc-A are you worried?

Over the last few days there have been a flurry of posts about this virus. I’m not going to repeat what it is or what it does, as I’m sure any self respecting Delphi developer has read the same posts that I have.

Are Embarcadero worried about this development? If not, they should be! (To be fair, they are aware of it, and thinking about it)

It’s all well and good telling us that

  1. It only affects Delphi 4-7, so get the latest version!
  2. It is a rather benign virus, and doesn’t cause any harm, so don’t worry unduly.

Unfortunately the cat is out of the bag, and you can’t put it back. I think (and somebody correct me if I’m wrong), there is nothing in the current version of Delphi that prevents this being replicated for later versions. My guess is the virus writer is one of those who hasn’t upgraded, and it’s only a matter of time before someone replicates this for Delphi 2009. Secondly, who knows what the next virus might do? This maybe just a warning, the next one may cause untold havoc.

How long before clients start asking what tool we use for our development, and refusing to buy applications written in Delphi. I need to be able to tell clients that this cannot happen with the tool we currently use. Is that even possible?

Time for new project type?

I’m not a web developer. While I did do some classic ASP earlier in my career, it’s mostly been about classic (Delphi) Win32 applications for me. So recently I thought I’d have a look at ASP.NET. At the same time, I thought I’d also have a look at ASP.NET MVC since that seems to be the in thing at the moment. Now I have no bias either way. I’m fairly new to both, but I just loved the simplicity of ASP.NET MVC. I’m not sure if simplicity is the word I need here, because actually, classic ASP.NET is perhaps the easier option for an inexperienced developer, as it uses abstractions to make Web development a drag and drop affair. Still, ASP.NET MVC just felt more natural to me. I’m sure had I looked at it 10-12 years ago (and had ASP.NET and ASP.NET MVC been around), I would have loved ASP.NET, and wondered why they even bothered with MVC.

This got me thinking about my day job. Since Delphi 1 we’ve opened up the IDE and clicked on New VCL Forms Application, got our empty form and started dropping components on the surface. We drop a few more components, create a few bindings, write a few event handlers, and hey presto we have an application. I bet every Delphi developer started out that way, and it works, but as you get more experienced, you begin to realise that for any real-world, half decent application, this sort of coding style just doesn’t scale well, and more importantly doesn’t maintain well. So you add a datamodule, and move all your database components to it, and feel happy for all of about 3 minutes. Something still bothers you though, so you get rid of the datamodules, and get rid of the data aware components, and perhaps write a framework, or even get a third party one. You read the book on design patterns, and see how many of them you can fit into your application.

Now that’s all well and good, and your framework may be great, but it’s different than my framework. Actually, I keep changing my framework of choice depending on what article or book I read last. My point is, that there is no consistency. So while the data-aware component model works well for beginners, and I would not advocate getting rid of it, I think Delphi is more than mature enough to have a new model. Sure we can look at third-party vendors for this model, or we can write it ourselves, but if we want real consistency, it needs to be in the IDE right next to Create New VCL Forms Application, and everybody needs to have it in their IDE. That way, when that new developer outgrows the 100 components per form model, and he or she is ready for the next level, there’s a clear path.

So how about it Embarcadero? Perhaps it’s time for Delphi to grow up a bit. I dunno, some kind of MVC pattern perhaps. Perhaps Passive View. Why not more than one? Wouldn’t you like to see this in the menu under File|New

New Passive View Project

Or maybe it’s just me!

Monday, 17 August 2009

Now I’m excited!

I’ve just read about attributes and RTTI in Delphi 2010. As someone who has used RTTI extensively and looked at reflection in .NET enviously, I can say I’m really looking forward to playing with the new RTTI model.

As for attributes, I’m sure a whole new array of interesting ways of doing certain things is going to be possible. There are currently lots of tools and frameworks which use RTTI to do certain things. Up until now, one of the main drawbacks to this was you could only work on published properties and methods.

One example that comes to mind is a small tool supplied with a third party component that prepares Delphi components and classes for use in a scripting solution. This tool works great, and parses classes to produce the boiler plate code needed for setting up the runtime environment for scripting. Unfortunately, it can only work on published properties and methods. If you want to expose any public properties, you have to do it manually.

These kind of things excite me more than IDE enhancements or ribbon controls. Having said that, I hope the IDE keeps up with these new compiler innovations. Does code completion still work with custom attributes for example?

Wednesday, 12 August 2009

Productivity versus Excitement

Many of the commentators in my two recent posts pointed out that the IDE additions and fixes in the forthcoming Delphi 2010 will increase productivity. I have no doubt about that. There’s one in particular I can see saving me quite a bit of time, and that’s the uses units. I use that little tool all the time, and could never understand why it automatically always put the unit in the implementation’s uses clause by default. Why can’t I choose? Well apparently now I can.

One particular comment went on to say that compiler changes, the thing I said might just excite me, could in fact decrease productivity. It takes time to learn new stuff, and if you are spending more time learning, than actually doing things, then you’d not getting things done.

That got me thinking about the Microsoft world, and how it seems that you hardly have started looking at one new technology, before it’s superseded by another. You’ve just about got your head around Winforms, and they spring WPF on you, then you jump on to that bandwagon, and suddenly it’s Silverlight out of the browser that’s the new in thing. Oh wait a minute, WPF and Silverlight doesn’t seem to be doing so good, perhaps we should stick with Winforms. Same on the web development side of things. You start with ASP.NET, get comfortable with ViewState and postbacks, and bam, they bring out ASP.NET MVC and tell you to forget all that (Actually they say they’re keeping both, so you need to decide which is for you). To make things worse, they offer you Silverlight as well. It’s the same wherever you look. Linq to SQL? Well apparently Microsoft now prefer Entity Framework. Well they did. I’m not quite sure anymore.

So yeah, all these new innovations to the language and new technologies do have an effect on your productivity, especially if you are trying them all out. The thing is, it’s human nature to want something new and shiny. Look at mobile phones. Most people use their mobile phones for making and receiving calls and that’s it. Oh, they might try a few of the new features when they first get the phone. Maybe take the occasional photo with their phone, but for the most part, they just make calls. So why do they change their phone every 6 months or so? The phone they had 5 years ago still works great for making those calls. The phone manufactures know it’s human nature to always want the new model. So they oblige and keep churning them out.

Microsoft also know that they can’t just rest on what they’ve got. They’ve got to keep their audience excited. Keep throwing as much new exciting stuff as is possible to keep them coming back for more. So while I agree, I’m as productive as a Microsoft developer who is using C# and Visual Studio, I admit I do go green with envy when that get some new toy!

Monday, 10 August 2009

Delphi Love

I was rather surprised at the comments to my last post. Some were pretty heated. Delphi developers are extremely protective of their baby, but I knew that already. I didn’t actually think my post was that provocative, but perhaps it was.

A good number commented that what has been released so far is only the tip of the iceberg, and that beta testers were not allowed to reveal more yet. That’s all well and good, but I can only comment on what I have seen. When more is revealed, I no doubt will add further comments.

Actually, I never said 2010 sucks. I just said that I’m not that excited yet. I didn’t say others wouldn’t be excited. I just said that I, personally, in my humble opinion, need more than IDE changes to get my blood stirring.

Each release of Delphi Prism excites me for example. They seem to be forever adding little goodies to the compiler. Perhaps it’s easier to do with the .NET platform?

Saturday, 8 August 2009

Delphi 2010

I know I’m supposed to get excited and all that, but I’m not. Improvements to the IDE, no matter how useful or needed just don’t do it for me. I guess it’s analogous to an accountant getting excited at improvements to his favourite calculator. (although I guess accountancy is so boring that a few new buttons on a calculator might just warm an accountant’s cockles!)

I get excited at real innovation. Improvements to the language for example. Ability to do things with my preferred language that’s either impossible or difficult to do with any other language. Innovation to the underlying Compiler etc etc

I guess I’ll have to wait until Delphi 2011 comes out.

Wednesday, 29 July 2009

Delphi Generics

Generics was or is one of the flagship features of Delphi 2009. Probably up there with unicode. Unfortunately, I don’t think the time was been put into the feature that it deserves. It feels like a badly implemented third party component. There doesn’t seem to be much in the way of communication with the ide. Code completion doesn’t work with generics. Same with class completion. Why not? Refactoring falls over as well.

This was all annoying, but we could almost live with it. Unfortunately we’ve now got a problem, which means we can’t use generics at all. Most of our automated testing is done with Automated QA’s Test Complete. Since we’ve moved to Delphi 2009, we’ve had a major problem, in that the debug information from our Delphi application was not being read properly from Test Complete 7. Here’s my question about it on Stack Overflow. Automated were baffled. We tried writing small test applications, but we couldn’t reproduce the problem. There was something about our application, Test Complete didn’t like. After months of investigation, we finally came to the conclusion that generics was the problem. Luckily, we had actually refactored some of our code to use generics, so it was easy to go back to the previous version. And hey presto, Test Complete is now totally happy.

Automated are now looking at it. I wonder if it’s a Test Complete problem, or is it generics messing up the debug information in the executable?

Sunday, 10 May 2009

Consumer Protection

The European Commission is proposing wants to make developers, liable for their own code. When they say developers, I guess they mean the actual company that releases the software, rather than the individual developer.

I have mixed feelings about this. As a developer, this would mean a fundamental change in the way we do things. It will probably stifle innovation, as new developments will become increasingly expensive. As a user, I’d welcome it. No more security holes in Microsoft browsers, and more importantly to me, no more bugs in my favourite IDE, Delphi. At the very least, companies would have to be more responsive with their bug fix updates (hint, hint Codegear. I’m still waiting for update 3. At this rate though, the EC will have passed their law, and Codegear will have to release their update!)

Is this a good thing, or a bad thing? Have we, as developers, had it too easy? Have we relied on our users to find our bugs?

Sunday, 3 May 2009

Quality?

I’ve been using Delphi 2009 for about a month now, and for the most part I’m happy. Unfortunately that’s only because when you’ve been disappointed so many times, you’re grateful when you get an IDE that doesn’t crash every 5 minutes. Seriously though, so far so good. (one thing is driving me nuts though. I’ll post about it later)

So there are a few bugs. I’m a developer, and I’ve been around long enough to know that every piece of software, however good the process and the people behind it, has bugs. So I’m under no illusions here. While no bugs would be nice, I know it’s not realistic. But here’s my gripe of the day! Why does it take so long to fix the bugs?

Whilst I expect bugs in a product, I don’t expect to wait 6 months after it’s release, for those bugs to be fixed. Some of the bugs I’ve found in TDictionary lead me to believe the code was not tested. Already not a very good sign. But hey, things fall through the cracks, we’re only human right? The thing is some of those bugs are so easy to fix, that any junior developer, just out of college, could find them, and fix them in an afternoon. So why 6 months later, are we still waiting? I don’t understand it?

And it’s not like Codegear don’t know about these bugs. They’ve been reported in Quality Central for a while. Oh and that’s another thing. If you’re going to charge me for your software (fair enough), and then use me as a tester,  please, oh please make it easy for me to tell you about bugs in your software. I have to go to the Codegear website. If I’m lucky, I’ve got my username and password written on a piece of paper somewhere, if not, I have to click on the lost password link. Wait for the email, fish it out from my spam folder. Then I’m not sure what you have to do, because I never got that far. Why can’t I just highlight some code in Delphi, right click, and choose report a bug. Put in a little description, and that’s it? You have my details as I use a registered copy.

As you can tell, I’m impatiently waiting for update 3? Where is it guys?

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!

Tuesday, 24 March 2009

Google is NOT the internet. Is it?

As I’ve mentioned before, I’ve been working late nights on my wife’s website, and I’ve been having a few browser problems. I kind of expected those, and have got round some of the problems, and fixed others. What I didn’t expect was my users not finding the site.

As beta testers, I used some friends and family. Basically, I sent them the link in an email.

I assumed that they’d click on the link and get the site on their default browser, or at worst, they’d cut and paste the link into the address bar of the browser of their choice. I know you should never assume anything when it comes to users, but it seemed a safe assumption to make.

Anyway, a few days later, one particular person said they couldn’t get to the website. I checked, and the site was up. I told her to try again, and she said, it’s not working. Baffled, I went away, and checked some more. It was there. To cut a long story short, I interrogated her again, and found out she was cutting and pasting the url into Google, and doing a search. She just doesn’t use the address bar. The site now comes up first with the url as the search text, but 1 or 2 days after I’d gone live, the Googlebots hadn’t got round to it yet.

This user was baffled as to how she couldn’t find it. I explained about the address bar, and that Google is NOT the internet, but just a search engine, and that it happens to search a database it maintains of the internet. And the internet being a fluid thing, the database is by necessity just a snapshot of the internet. She just couldn’t understand it. To her, if it isn’t on Google, then it’s not on the internet. Am I the only one feeling slightly uncomfortable about this? I’m sure this person is not the only person in the world who thinks that Google is the internet. That’s an awful lot of power in the hands of one company.

Misunderstood. Who me?

My last post generated exactly the type of comments I expected it to. In fact I could have written them myself as I knew what was coming. Here’s a sample, and my reaction to them.

The US are only 5% of the world population. That means that 95% of all Delphi users need Unicode.

I never said I didn’t want unicode. In fact our application is already Unicode compatible, but I still wanted reference counted unicode strings. I just didn’t want my existing code to break. I would have preferred the choice of when I decide to move to UnicodeStrings to be in my hands, and not forced upon me. (well not forced, I could always stick with D2007, but you know what I mean)


I adapted my app within 2 or 3 hours.

Great, you now have a unicode version of the Hello World application. In the real world, applications are a little more complicated, and take a little longer. If you managed to upgrade your application in 2 or 3 hours, your application is either very small, or you’re a genius!


...why should I write new code with special TEditW lines - who needs pure ANSI code today?

Ok, why should the quality of my code suddenly take a nose dive, just because of a compiler upgrade? And again, I’m not arguing against Unicode and in favour of Ansi. I’m just questioning how the move was made.


You don't think this (Delphi 2007 compatibility switches) has been considered, do you?

I’m pretty sure it was, or at least I hope it was. Was the right decision made? I don’t know, but I’m pretty certain from a technical point of view, the right decision would have been the least number of breaking changes as possible. On the other hand, this would definitely have pushed the release date back quite a bit, so you also have commercial considerations. I’m a technical person, not a salesman, so I ignore the commercial considerations. I’m sure Codegear can’t afford to.


Apart from all the above comments, I got quite a few agreeing with my point of view. These actually surprised me more than the ones above. I originally thought perhaps I was being a little harsh, but it seems I’m not the only one slightly annoyed.

 

Anyway, the actual conversion is going pretty well. Biggest problems have been third party components. I now have an application that compiles, but ironically, while it handled Unicode with no problems in Delphi 2007, the Delphi 2009 version is struggling. We need to do a lot more work to get to the same quality point we were before. We will have touched probably 70-80% of the units. That’s a major test burden in of itself.

And the thing is, in the eyes of our users, our application hasn’t gained a thing.

Monday, 23 March 2009

Breaking Existing Code

We finally decided last week to have a go and try and move one of our applications from Delphi 2006 to Delphi 2009. Most of our other applications had been moved to Delphi 2007, this one, due to unfortunate timing, remained with Delphi 2006. I say try, because we are wary of the changes, and if it’s too much upheaval, we just may decide it’s not worth it.

It’s taken us a while to decide on whether we should make the move or not because this application had been made fully unicode compatible using widestrings and TNT components. We don’t actually need Delphi 2009’s unicode support, although we realise the difference between widestrings and Unicodestrings. The fact we’d done that work actually worked against us in this case.

Now I’ve done many of these upgrades. I’ve gone from Delphi 1 to Delphi 2, 2 to 3 so on and so forth, so I’m in a position to compare the experience. So far it hasn’t been easy. We use quite a few third party components which are no longer actively maintained, so we’re not getting a Delphi 2009 version anytime soon. Luckily, we have the source (actually luck doesn’t come into it, we’d never use a component if we didn’t have source!). Now the convention for creating buffers has always been to use PChar. This obviously doesn’t work anymore, and while our code isn’t too bad in this respect, the third party components we use are riddled with PChar buffers, pointer arithmetic etc etc

Now, I got to thinking. How could Codegear have made my life easier? Well for starters, they shouldn’t have broken my existing code! If PChar was a pointer to a (single byte) character, then it should stay that way! If a string is  an Ansistring, then it should have stayed that way. In fact I should have been able to recompile my code in Delphi 2009, and my application should have worked exactly the way it did in Delphi 2007 (I’d accept it if older code didn’t completely work first time, but Delphi 2007 code should more or less work the same) Unicode support is a great thing, and hats off to Codegear for implementing it in Delphi 2009, but I would have done it differently. I’d have left a string as an Ansistring, and created a new string for unicodestrings, PChar would’t have changed, and TEdit would still be, in essence a TAnsiEdit. They would then have created a parallel VCL, and appended say a W to the names (TEditW) for the unicode equivilents. So anyone who wants a unicode application needs to do a little work. Not too much, but hey, nothing comes for free. Those who don’t want it, and there must be a few out there who don’t really care, get a compiled application which behaves exactly as it did in Delphi 2007. They can upgrade to unicode, if they wish, at their own pace.

If Codegear had really wanted to be helpful, I guess they could have gone the extra mile and added some compiler directives. D2007 compatibility on or off. That way everybody is happy.

Codegear, and Borland before them, keep making the same mistake. They keep assuming that technology alone can create these magic buttons. Press them, and you get this wonderful transformation. That would be nice, but it just doesn’t work that way in the real world. They tried it with Kylix (just compile your existing Win32 code in Kylix, and you have a Linux application) and it didn’t work, they tried it with Delphi for .NET (just compile your existing Win32 code with Delphi 8, and you have a .NET application) and it didn’t work, and they’ve tried it again with Unicode support (just compile your existing non-unicode code with Delphi 2009, and you have full unicode support), and in my opinion it hasn’t worked either. Sure it works with a contrived example, but try it with any decent sized, real world application, and you are in trouble pretty quick.

I’m sure there’s many out there who have compiled their existing Delphi 2007 code in Delphi 2009, and with a little tweaking here and there have been able to get it to work. I just think it should be the developer’s decision when to introduce Unicode support. I guess it still is our decision, but currently ,if we decide that completely changing the way our code behaves is a step too far, our only option is to remain with Delphi 2007. And if that happens, Codegear are one step closer to losing a another customer.

Wednesday, 18 March 2009

Shiny Chrome

I haven’t posted in a while as I’ve been setting up a website for my wife. Nothing special, just some static html. God, do I hate HTML. It’s so illogical! It’s not real programming. I also made the mistake of assuming that modern browser’s are now more or less all compatible. It’s only my second ever website, so I could be forgiven. As I was developing, I was testing using Chrome, my default browser. I love Chrome, it’s fast, and does what you expect it. Once I was finished, I tried the site in IE7. ARRGGHH. What a mess. Firefox and Opera were slightly different, in rendering the pages, but IE was completely off. I had to compromise, to get IE to work, and then it still isn’t great. Why do people still use IE?

And don’t get me started on Dreamweaver. It keeps moving text around. I gave up on it, and used a text editor, Notepad++. Give me Delphi or Visual Studio development any day!

The site, if you are interested, is Chez Piron. We renovated an old barn, and my wife will be looking after letting it out as holiday accommodation.

Wednesday, 25 February 2009

Pointers to Pointers

When you first learn about pointers, it takes a little while to get that aha moment. They're a bit like recursion and closures in that respect. Then, just when you think you've got it, get shown pointers to pointers. You understand the concept, but can't really figure out where they'd be useful. So you look at the examples, but you still can't see their use. The examples are just so contrived, that you're left thinking, I'm never really going to need to pointers to pointers.

Delphi does a pretty good job of hiding anything to do with pointers from you, and you can go for years without using a pointer if you really didn't want to. I resort to pointers quite often, but I can't really remember a time when I really needed a pointer to a pointer. That is until this weekend.

I was looking at the jclExprEval unit in the Jedi Code Library. Now the code as it stands make it very easy to add variables.

var
A : Double;
B : Double;
...
...
begin
ExprEval.AddVar('A', A);
ExprEval.AddVar('B', B);
CompiledExpression := ExprEval.Compile('A+B');
Result := CompiledExpression;

The variables A and B are internally stored as pointers to double. This is all well and good, and this works fine. Now what I wanted to do was to be able to compile an expression once, and repeat it multiple times over an array of values. Actually each variable in the formula is an array. I wanted to do something like


var
DataA : array of double;
DataB : array of double;
A : pDouble;
B : pDouble;
...
begin
A := @DataA;
B := @DataB;
ExprEval.AddVar('A', A);
ExprEval.AddVar('B', B);
CompiledExpression := ExprEval.Compile('A+B');
i := Length(Result);
while i>0 do
begin
Result[i] := CompiledExpression;
Inc(A);
Inc(B);
Dec(i);
end;

I thought initially I'd just override AddVar so it can take a pointer to a double, and store it directly. That was before I thought about it properly. When I did think about it, I realised it wouldn't work. Since the variable internally is stored as a pointer to a double it is basically a copy of A. at least initially it is.


Pointer to double

Incrementing the pointer A just gives you the following

Increment pointer 

As soon as you see the picture the solution is obvious.

Pointer to a pointer 

A pointer to a pointer! We can manipulate A anyway we like, and our internal copy still points to the right place. Whereas before to get to the value of our variable we'd de-reference the pointer once, now we have to be careful and do it twice. I had to write quite a few classes and methods (basically replicate the whole structure that handled pointers to handle pointers to pointers) to get this to work, but as I said before, the code is well written, and extending it to do what I want was really easy. So while pointers to pointers and even simple pointers are not essential (as I'm sure a load of C# developers will tell me) they do have a place in a Delphi programmers toolbox.

Monday, 23 February 2009

My definition of good code

Following on from my post regarding JclExprEval of the Jedi Code Library, Barry Kelly, left me a comment that in fact the unit had been documented, and he gave me a link to it.

I don't think I'm going to even bother downloading it. I can't really see what the documentation can give me that looking at the code hasn't (although being a curious fellow, I no doubt will). The is self documenting. Considering it was all new code to me, it took me no more than a few minutes to make the necessary changes to it to get it to work in my situation.

So while I have said before that to describe what good code is is rather difficult, my new definition for good code is any code which is discoverable and maintainable without resorting to documentation (because be honest, who reads the manual?) is good code. I probably should add it should also do what it's supposed to, but that's a given, no?

Without flattering Mr Kelly too much, JclExprEval fits that description perfectly. Now, back to the awful code that I was labouring with on Friday, which certainly doesn't fit that description.

What did you learn today?

Do you ever wonder how accountants manage to get out of bed every day and go to work? Apart from the occasional, new tax law, their profession has basically stayed the same for hundreds of years. An accountant is basically doing the same thing today, that he did yesterday.

I think we're in a profession that by definition is interesting every day. You don't even have to swap technologies every couple of days to learn something new. I've been doing Object Pascal and Delphi for a long time now, but I learnt something new in Delphi today, and today is no exception. In fact the days I learn nothing are few and far between.

Some nights I can't sleep because I've just figured out a way for the algorithm I've been toiling over to work 50% faster than I had been currently implementing it. I actually wake up most mornings, eager to fire up Delphi. I think we're lucky.

The great thing is, that no matter what I learnt or did today, tomorrow will be much better. One of the questions I answered on Stack Overflow, was What was the first program you wrote, and you were proud of? I thought about this for while, and each time I thought of something cool I wrote, I immediately thought of something cooler I did a little later. So finally I answered thus :

I always think the software I wrote yesterday sucks, the software I'm writing today is cool, and the software I'm going to write tomorrow will rock!

I wonder if on accountant forums (do they exist) anybody ever asks What's the first balance sheet you did, and you were proud of? It just doesn't have the same ring to it, does it?

Sunday, 22 February 2009

Faith Restored..

..in mankind that is. Well at least in developer-kind. After Friday's travails with that awful code, I was beginning to think it was impossible to pick up someone else's code and run with it. Well, today I was messing around with expression parsing and evaluation, and asked a question on stack overflow regarding the subject. One of the answers was from Barry Kelly, who works for Codegear on the compiler team. (maybe he IS the compiler team, I don't know) More often than not, it's Barry who answers my questions, I don't know why I don't just ask him for his phone number. Anyway, he pointed me in the direction of the Jedi Code Library and more specifically the JclExprEval unit. Apparently he wrote this a few years ago. It's everything that the code I was struggling with on Friday was not. It's will written, simple to read and understand, even though there is no documentation. Very easy to use, and should I ever need to debug it, I'm sure I'd have no problems. I can understand exactly what the developer had in mind, and can use it as is, or take away what I need with very little effort.

It's not always easy to describe what makes good code and what makes bad code. The thing is though, you always know good code from bad as soon as you see it. You also can tell so much about the developer who wrote it even though you've never met him or her.

Friday, 20 February 2009

See what I mean?

I recently posted about the difference between developers and good developers. The point I made is being confirmed to me on a little application I've been asked to have a look at. The application in question is written in Delphi, by someone in the organisation who is not a developer. I knew this before I saw the code, but I can confirm the fact now that I have.

This is what happens when you have someone who thinks How hard can it be? That's the problem with Delphi, it makes it look so easy. And it is very easy to write your Hello World applications. In my opinion, it's easier than .NET (although that is not too hard to get started in either)

The problem is we don't have enough Delphi developers. Someone needs a small application. It's one form, spread over two tabs, less than a weeks work. All developers are tied up, and the conversation goes :

Manager 1 - Didn't Joe do some VB programming a few years back?

Manager 2 - Yes, I believe he did.

Manager 1 - Jolly good, get him to write that new application we need.

(The names have been changed to protect the guilty)

That's where the problems started. When it was ready, the testers noted there were a lot of bugs, and the more that were fixed, the more cropped up. That's where I come in. I have to try and salvage something from this mess.

So what do I have? A small application with a lot of Access Violations is what I have.. Some when you start it up, others when you press certain buttons, and a few more when you close it down. I had a quick look at the code, and found that while the developer (and I use the word in the loosest possible way) seems to know about classes and objects as he/she has created a hierarchy of classes, he doesn't really understand it. It's not all drag and drop (oh how I wish it was) It goes down hill from there. He/she has evidently not heard of encapsulation. All variables are exposed as public (glorified globals). Forget polymorphism, and someone forgot to tell him/her that Delphi has no garbage collector. Mix all of that together and you get a mess. Most of the time he/she has made no attempt to free objects. A few times, he/she has tried, but thought that setting an object instance to nil would do the trick. variables are declared (publicly) in base classes and then created when needed. Sometimes multiple times, thus leaking memory like a sieve. I could go on and on, but I don't want to cry and short my keyboard.

So would garbage collection have made a difference? Not really, it would still have been a mess, just a different type of mess.

Thursday, 19 February 2009

Twitter. I just don't get it.

..and I have really tried. Everybody seems to be twittering and everybody seems to be raving about Twitter. I just can't get excited about it. Maybe I'm getting old. I think of Twitter as the online equivalent of SMS, and since I've probably only ever sent five SMS's in my life, no wonder I don't get Twitter.

It seems like such a waste of time. More digital interference. I have enough of that with Email and RSS. Take for example Stephen Fry. Apparently the most popular Twitterer (is that even correct nomenclature?) out there. Now, I really like Stephen Fry, he's witty, funny, and all in an ultra-intelligent way, but do I really need to know when he gets stuck in a lift?

I've also tried following some of my favourite bloggers, but all I see is a whole load of inane tweets about what they're currently looking at on the web (sometimes useful, but for every decent tip, I have to wade through a whole load of rubbish), or what they're currently cooking etc etc. I guess for someone like me, who works from home, it replaces the idle chatter of the office environment. Since I always thought that was a big waste of time anyway, why should digital idle chat be any different?

While Stephen Fry was stuck in his lift, and Jeff Atwood was struggling with his servers, I was earning a living, or spending time with my daughter, or working on the house. In other words I was living in the real world. I just don't have time for Twitter, and I bet all those raving about it will realise soon enough that they don't have much time for it either.

You ask a question, you get an answer!

I recently asked, who or what are Embarcadero's target customer. I think Embarcadero have answered. Look at this press-release. Embarcadero All Access.

So, it's the Enterprise then. Maybe Embarcadero know something I don't. Maybe they'll target the medium to small businesses with some other scheme at a later date. I wait with bated breath.

Monday, 16 February 2009

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.

Sunday, 8 February 2009

Who's your target customer?

Right, before I write this post, a little disclaimer. I have nothing against Nick Hodges, I've never met him, but he sounds like a really nice guy, and someone who I'd have a lot in common with. The reason I say this, is I've noticed that quite a few of my posts have been about something he's either said, or written about. I hope he can take some of what I write about as constructive criticism.

Where was I? Ah, my friend Nick! I'll keep this one short. Isn't rule one of any business, to know who your target audience is? Does Codegear know who it's target audience is? I'll go back to Nick's appearance on show #13 of the Startup Success Podcast.

Is your market the large enterprise level companies?

I quote :

  • Each region prices the product based upon the market in that region.
  • If you think the prices should be lower, provide that feedback to your sales representative.
  • Contact your sales guy, and we'll see what we can do?

Or is it more the small to medium size business and hobbyist market?

I quote :

  • We don't have a huge number of enterprise level sales.
  • We keep our focus on developers.

So which is it? Regional pricing, a sales force, and the fact that it seems (may or may not be true, but it sounds like it) to get the best price, you need to speak to a sales person are all perhaps what the Enterprise expects, but something everybody else seems to hate!

If you're aiming for the developer, the small to medium sized businesses, and the micro ISVs and the hobbyists, take it from me, they don't like pricing per region, and they absolutely hate talking to a sales guy. All they want, is to get the best price possible. Save the money you pay that sales guy (and pass on the saving to us of course), and just put the product somewhere where we can buy it with a minimum number of clicks, and at a reasonable price, one which is the same whether I'm in Angola or Alaska!

By all means target both groups, but have a distinct strategy for each.

Again, sorry Nick, I'm on your side.... Honest!!!!

Saturday, 7 February 2009

Should we really learn C?

I'm referring to something Joel Spolsky keeps telling Jeff Atwood (both of Stackoverflow) Joel says that even if you are not going to be programming in C, learning it will stand you in good stead. As much as I hate C (hate is perhaps too strong a word), I kind of agree with him. I was thinking about this in the context of garbage collection. Everybody seems to love garbage collection, and it seems to be the number one must have feature for Delphi. I guess the theory goes, if you don't have to think about freeing your objects, then your code will have less bugs in it, and thus by default you are a better programmer. Does it work that way? Not really. I recently had the misfortune to have a look at some Delphi code written by someone who clearly didn't know that objects were his responsibility. Objects were being created left, right and centre, and not being freed after use. There were a few attempts at freeing objects, but this was just a misguided assignment of nil to various objects. It was a mess, and the application leaked like a sieve (a colander for you Americans out there!) Would garbage collection have made his code any better? To be honest, I don't think it would. Ok, it would have freed the developer from the responsibility of freeing his objects, but he just didn't get the basics of being a programmer. His code would still have sucked. It would have leaked a little less for sure, but it would still have been a maintenance nightmare. And you know what, garbage collection would have probably masked the fact this guy didn't know what he was doing. His application would have worked. We'd perhaps have noticed further down the line when it is much more expensive to fix. Delphi wasn't as forgiving, and rudely protested with multiple access violations.

So, yes, garbage collection is cool, saves time and typing (40% I'm told), but I fear we're growing a generation of script kiddies (apologies to script gurus, who know what they are doing), who can get an application (albeit a small one) up and running, but have created an albatross around the neck of the next guy to inherit their code. So, yeah, C maybe a dying language, and pointer manipulation and managing your own memory maybe dying concepts, but learning the basics of how to program is essential, and it's these languages and concepts that best help you do that.

There's a perfect analogy in the world of (real)languages. Latin is a dead language, but for years, it was taught in schools, and students hated it, because it was of no use to them in every day life, or so they thought. The thing is though, so many modern languages are based on Latin, that anyone with a knowledge of Latin, is automatically a better linguist. His English, Italian, French, Spanish etc etc will automatically be so much better for having learnt Latin.

So by all means, let's have garbage collection, let's have all these coder aids, but let's not forget how to program.

Thursday, 5 February 2009

When did we all get so lazy?

There seems to be a movement towards writing less code. I see it all the time.

  1. You have C and C# evangelists who can't stand Pascal because they can do in two key strokes, what Pascal does in nine ({ and } as opposed to begin and end;) This one's a personal preference issue. Personally I find begin and end 100 times more readable, but I also understand that others may prefer their curly braces.
  2. In my post about garbage collection, some of the commentators reminded me that if you use Delphi, because it doesn't have garbage collection, you have to write 40% more code (all those silly try..finally clauses). Again, you may have valid reasons to want garbage collection, and I respect those reasons. But don;t tell me writing less code is a good reason.
  3. The push towards functional programming is another one. I'm told that using a functional programming language for certain problems would result in me writing a lot less code. Look Ma, I wrote all that code in one line! I may be a bit harsh here, as some of the functional constructs are really elegant, but what I'm getting at is that use something by all means if it results in your code being more readable, and not because it results in a few less lines.
  4. Pascal requires an interface and an implementation section. You declare a class twice. It must be bad right? Like I've said before, for me, a Pascal class is immediately readable. The interface has no clutter. To achieve the same thing with say, a C# class you need code folding.

I could go on and on. I think the theory goes that if you can type, say 70 wpm, and that you can't physically type faster than that, then the only way to churn applications out faster is to use languages and constructs that need less typing. The theory implies that if you are writing 40% less code than I am, (and we both type at the same speed), then you're producing 40% more work than I am. What the theory conveniently ignores is that I may think 40% faster than you. I'm not saying that writing less code is a bad thing. I will always write less code if I can, but never at the expense of clarity. I will add begin and end where the compiler doesn't need them if I think it makes the code less ambiguous. I'll not use the with construct , and retype the object or record instance each and every time, if I think the code is more readable for it (it always is). The important thing to remember is the speed a developer can write good maintainable code is rarely due to the number of characters he/she can churn out. A lot of it is to do with the thought that goes into producing the code, when the hands are no where near the keyboard. It's to do with the cost of maintenance of that code. This all reminds me of those C competitions where C enthusiasts would vie to write the shortest piece of code that actually does something. It doesn't matter that you had to sit down with pen and paper for a few hours to figure out what his little program did. Aim for clarity and eliminate ambiguity. If that means you end up writing a bit more code, so be it, in the long run you'll actually save time.

How do I make the case for Delphi?

At work we use Delphi. We have for several years, and it has never failed us. The last few years we have had major problems finding good Delphi developers, so the developers we have hired have either been bad Delphi developers (who have since moved on), or .NET developers who have been persuaded to try their hand at Delphi. Most have been persuaded because they were promised that migration to .NET was on the horizon. We've got to the point were the C# and VB.NET evangelists outnumber us poor Delphi guys.

We are moving closer and closer to becoming a Microsoft shop. There's no valid technical reason for this. I suspect a lot of developers want C# and .NET on their CVs.

So, as the Delphi evangelist, how do I make the case for Delphi? The noises that keep coming out of Embarcadero are that Delphi is the best solution for creating Win32 native applications for Windows. I won't argue with that, but it's just not enough to stop the tide. I keep repeating that to the powers that be, but they can't find the staff with the skills to use the tool, so it doesn't matter how good it is. That's why I keep going on about academic licences, cheaper versions, anything to get the new breed of developers started on Delphi. What Embarcadero need to realise is that no matter how good their product is (again I agree it's good!), if the next generation are not using it, then Delphi shops like ours will move to what are perhaps inferior products, because at least they have a chance of recruiting the right staff. It's a shame, but it's true.

Wednesday, 4 February 2009

Born Again Delphi?

I've just read an extremely interesting (and long) article about the future of Delphi. The catalyst for the article was Nick Hodges post on the future of Delphi. Some interesting things on the wish list for the new Delphi.

Compiler Speed

For most of my professional life I have used Delphi, and Turbo Pascal before that. I take the compiler speed for granted, and compile my code often, just because I can. I think I'd notice if the Delphi compiler was to all of a sudden take a lot longer to produce the goods, and I would not be happy!

Interface/Implementation

I'm all for typing less code, but not at the expense of clarity. Having to declare the class in the interface section, and the implement it in the implementation section may seem like a waste of time, but it makes Pascal so much more readable than say C#. Even if we didn't have shortcuts such as ctrl+c (complete class) or ctrl+shift+up and ctrl+shift+dn (toggle between interface and implementation), I'd still want a separate interface and implementation section.

Declare Inline Variables

I've started using these in Delphi Prism, and they rock. Now this is one place where you write less code (albeit a little less), but clarity improves.

for var i : Integer := 0 to 20 do

Case Sensitivity

No. No. No. Why? Why? Why? I don't get it. If I have two variables test and Test, in the same scope, then I've just introduced an ambiguity. Which one do I use? Which one did I mean to use last year?

No. No. No.

With Statement

I don't like it, I don't use it, and I think people who write code such as :

with MyObject, HisObject, TheirObject do

Should be shot! (yes I have seen code like that)

Smart Pointers and Garbage Collection

The author is basically for some form of smart pointers and against garbage collection. I'm on the fence here. As long as anything is optional in this area, then go for it. I'll make my decision after I've seen it in action.

There were a few other points, but the ones above were the interesting ones. I just hope the rewrite of the Delphi compiler is the right thing to do. Look what happened to Netscape when they decided to rewrite their flagship product!

Monday, 2 February 2009

The Nick Hodges Podcast

I have just listened to latest podcast over at the Startup Success Podcast, with our very own Nick Hodges as the guest. I have to say it was rather disappointing. I guess for someone who laps up every mention of Delphi on the web (does the web sometimes seem very small to you?), these kind of things are always disappointing, because you never learn anything you don't already know. The disappointing thing though was every (well the really juicy ones at least) question was answered with a "I can't say more than that" or "I can't confirm when" etc etc I'm not trying to criticize Nick. While to a long time Delphi developer like myself, at first sight, Nick seems to have a dream job, if I really think about it, I'd have to say he's got a really difficult job. He's kind of stuck in the middle. The public face of Delphi, with his hands tied behind his back.

I was particularly waiting for his answer to a question I had suggested on Bob's Facebook page. The one about Embarcadero's Bizspark equivalent. I've blogged about this before, and I've since had a change of heart. It's more of a softening of stance really. Yes I'd like access to Delphi for a paltry sum, but Embarcadero are in the business of making money, not making me happy. I still think they seriously need to find some way to attract new developers, but doing a Bizspark equivalent, is just not going to work for Embarcadero. Even so, Nick didn't really answer that question either.

I have a suggestion for Embarcadero. A cut price Delphi, call it Turbo Delphi if you will, with a bare minimum of components. Just enough to get you started. Basic database access, a button, and edit box etc etc. Then have an ITunes like shop front for selling individual components(singles) or packs of components (albums). Somehow marry those components to a single licence. Buying all the components individually would cost more than buying the full product, but at least it allows users a lower entry cost, and who wants all 2321 components anyway? The store could be expanded to third party offerings. Could it work? Or would people just buy the cut price version and use freeware components? If they did, would it be a bad thing?

Monday, 19 January 2009

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.

Monday, 12 January 2009

Is Google your cup of tea?

I've just read a report that says that every time you do two Google searches, it produces the same amount of carbon dioxide as boiling a kettle for a cup of tea. Wow. That's a lot of tea. Or rather a lot of carbon dioxides!

The problem is we're addicted to Google(replace the search engine of your choice here). Not addicted in a "a little bit of a therapy, and I can give it up" kind of way, but the "I just can't live without it" way.

Just today, I was trying to install CruiseControl.NET. I installed IIS, then installed Cruise Control, then tried to bring up the Web Dashboard.

Prism12-01-2009-19.19.25

Now what? Well, 2 minutes and half a cup of tea later I had my answer. It's a problem with IIS when installed after the .NET framework. Just run the following command in the framework folder (my case c:\windows\microsoft.net\framework\v2.0.50727)

aspnet_regiis -i

This apparently resets all the necessary registry keys. I tried this, and viola, it worked.

What did we use to do before the Internet and Google? I don't think they used to pay us enough for the job we did. I would have had to go out, to the local bookstore, and find a book about Continuous Integration, buy it, and hope it covered that particular problem. How many cups of tea would that have involved?

I say we should just give up on tea!

Sunday, 11 January 2009

Working from home

As I approach the fifth anniversary of working from home, I'm starting to think about the pros and cons of working remotely. Joel Spolsky has said many times on his blog and his podcast that he thinks developers should be in the office, and not work from home. Jeff Atwood his co-conspirator on the Stack Overflow podcast meanwhile is currently working from home on Stackoverflow.com, with another two developers, who are also working from home (and I don't mean his home!). He obviously thinks it's a good idea. So do I.

I get my own room, with a closing door, something I would not have at the office. I start working in the morning completely fresh, as opposed to being worn out from the hour commute. On top of all that, I'm happier than ever, because I get to see my daughter growing up. A happy developer is a contented developer is a productive developer.

Ok, so what's the catch? Well, I'm sure not everyone is cut out for working from home. It can get lonely I guess, but I have my own social life, and it never did revolve around the geeks I worked with. (no offence, I'm a geek too, just prefer the company of non-geeks to try and keep sane!) I have a fast broadband connection, with vpn access into the network at work. So I'm just in an office with a long network cable. I checkout, I commit, I do all the usual things I would do if I was in the office. Some cite communication, or lack of it as a problem. I guess it can be, but I can discuss things over the phone (for some reason, company policy prohibits Skype), I can "look over someone's shoulder" using VNC or Webex. I regularly review code with both developers and testers. It works well.

Not to be 100% biased, I would say there are two major problems, and unless you can overcome them, they might make working from home difficult. The first is motivation. Or rather lack of it. I've been doing this for so long now, that I get up in the morning, and just 'go to work'. That happens to be down the hall from the bedroom, but it's where I work. There are times when you just can't concentrate, and there are other times when you can't stop concentrating. It's the same when you're in an office, it's just that in the office, your boss is around, so you pretend to work. At home, I know that if I'm not concentrating now, I'll be productive later. So I'll do something else. The work get's done. That's the main thing. The second problem is paradoxically, the opposite of the first one. Knowing when to stop! Separating work from home life. I confess that I have more problems with this one than the first. I have no real solution for this one, except perhaps a nagging wife!

Thursday, 8 January 2009

Delphi Prism Web Templates

I've been trying to do a few Silverlight examples with Delphi prism, and I keep getting all kinds of errors when creating the projects. I've noticed though, that it only happens if I try and create an ASP.NET test project for the Silverlight application. Then I noticed I have no ASP.NET template for Prism. Does anybody know why Delphi Prism (my copy at least) has no web templates? I think Oxygene did have them, but I can't remember for sure?







Can I get the templates from somewhere?

What is it about Garbage Collection?

I've been looking at some of the questions that people have been sending Bob Walsh to ask Nick Hodges (See my previous post) Apart from the clamour for a 64-bit compiler, by far and away the most popular question is "Why doesn't Delphi have garbage collection?" What is it about garbage collection that so excites the masses? Ok, you can create objects and forget about them. But seriously, Delphi developers, have you ever found it a major problem? I mean this isn't C++ (or God forbid C). If you're disciplined, and we're not talking military discipline here, then I don't see the problem.

I see all these comments like "With garbage collection, I can get on with solving the problem at hand rather than waste time managing memory."

How much of our time is wasted managing memory?

Tuesday, 6 January 2009

Do you want to ask Nick Hodges a question?

If anyone is interested in asking Nick Hodges a question, Bob Walsh of 47 hats fame will be interviewing him on Friday. Go here to suggest a question or two? Most of the questions so far are the usual fare (Where’s 64-bit support?), but since most of the readers of the Business of Software forum are probably not Delphi developers, it may be a interesting to see what those on the outside think. It’s also an opportunity to ask some intelligent questions that perhaps encourage a few non-Delphi users to migrate.

I know, I know. One post I’m bemoaning the state of the Delphi world, and my next I’m trying to drum up support. What can I say, Delphi is in my blood.

Thursday, 1 January 2009

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.