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?