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.
Posts
5 comments:
Firstly, you mentioned somewhere that a 40% saving in loc that you got from comments in a previous post. I suspect that you misread my comment where I stated a 4% saving. Minor but important difference.
Joel's comments are aimed at new programmers who get taught .net and java. They would benefit from exposure to c.
For delphi programmers, it is slightly different. We already need to know about many of the things (eg memory management) that .ent/java programmers don't. The main things c will teach you is how nice native strings are, and how to read c (quite a useful skill admittedly).
Instead delphi programmers should look at learning a different class of language; eg .net/java, scripting or functional. That would provide an entirely different set of knowledge and skills.
Learning a new programming language can be a good way to broaden your view and make you rethink how you solve a given programming problem in Delphi.
C is a very minimalistic language, e.g. there is no string type in C, there just exist a standard library of functions that can work on an array of chars. So each string carry the same complexity as pointer operations, making it easy to write beyond the space allocated for a given string. (*1)
This can be good for an exercise in how memory is organized, but terrible when you have to debug an app with a million lines of code.
As an alternative way to understand how the CPU execute your programs and handle memory I suggest to learn some assembler programming. In Delphi it is also easy to practice assembler right in the middle of your Delphi code, changing just one function at a time.
Also, a good exercise low level programming and in how Windows work, is to write a Delphi Windows app that do not make use of the VCL, but call the Win32 API directly.
(*1) Kerningham and Richie: The inventors of the buffer overflow error. Cursed daily by millions of users with crashed applications.
"Everybody seems to love garbage collection, and it seems to be the number one must have feature for Delphi."
I don't know where you got this idea from.
In the days of stack objects in Turbo/Borland Pascal, objects automatically deleted when they went out of scope.
Have people never heard of "lint"? Am I that old?
Good analogy with Latin.
Post a Comment