Comments on Software Engineering Radio

It's been so long since I posted to this blog that it probably qualifies as a slum but I'm still here. It hasn't been personal tragedy that has kept me from writing here but a large dose of personal busyness. Some of that has settled down to a dull roar -- and I've arrived at a bit of a milestone that bears marking in some way -- and this way seemed the best choice -- so the time has come to dust this blog off and write something, in this case, something a bit more substantive than Yet Another Haiku.

About six months ago, a colleague introduced me to the podcast from Software Engineering Radio, specifically mentioning Scott Meyers' interview regarding C++0x. When I saw that it was Episode 159, I decided to go back and listen to the rest of them: my travel times can be long, auditory input is good in the context of multi-modal commuting and more training in any form is always a good thing.

So now I've listened to the first 50 -- nearly the first 70 by now, actually -- and it's time I should mention my impressions. Here they are:

1. Given that the first episode is over five years old by now, these pod casts have aged quite well. The approach of sticking to just one topic for an hour-or-so or less allows for many things to be covered reasonably and well without becoming ponderous.
2. And where a topic can't be exhaustively covered in that time frame, going back to it again and again also gives the opportunity to cover them well.
3. Further, not necessarily going back to a large topic sequentially, again and again has kept the collection, so far, from being ponderous in that way either.
4. I found the rationale for choosing to podcast in English despite the fact that the original podcasters are all German speakers amusing: especially the part where most Germans wouldn't understand them because of their strong regional accents. On the question of accents, I was occasionally tempted to write a note about pronunciations, of "meat-ah-model" for instance, but five years on, someone else seems to have put in a word or two and it's been metamodel, properly for some time. My condolences go out to any ESL speaker to get English pronunciation right the first time. It's crazy to keep so much of our linguistic history alive in our orthography, but I digress.
5. Occasionally I have been put off (a very little) by blanket statements about how some thing is wonderful in Java, or Ruby, or with Spring or whatever whereas "you just can't do that in ..." C or especially C++. Particularly, when it comes to memory or object management (or indeed management of any kind of resource) stating that "it's just so hard in C++" again and again struck me as naïve about C++. Admittedly, it may be easier to do bad things in C++ (which has been my favourite language for about 10 years) but by the same token, it is often more possible and indeed cleaner to do the right thing in C++ than in Java, for instance. I have just begun using Java and I find the constant use of the acquire-try-doSomething-finally-release idiom really clunky. In C++ I would create an auto-release object around what I wanted to acquire and the destructor (whose invocation time is known precisely) would take care of releasing it at the point I would choose, without further ado. And Java is somehow better at that point? As for memory leaks, my impressions are that when Java programs leak, the leaks can be far harder to find than in otherwise well-written C++.
   
6. This being put off has gone the other way as well: along with denouncing what I find useful, the podcasts have sometimes praised things which when I have met them seem wrong-headed. In the Java work I have begun to do, I have been exposed to Spring's dependency injection. After hearing it praised so highly in the podcasts, I was disappointed to see that it was essentially a way to acquire the use of something implicitly, without the costs of instantiation and management being exposed to me. It's all very well to say "@Component" or "@Autowired" about some piece and have it magically instantiate at the right time and the right place, but it strikes me as the kind of thing that would encourage sloppy practices rather than make good practices easier. But to each his own. With the way that Java mashes up the interface with the implementation in an individual class, I can see the benefit of pushing away these details. I've just seen so many people do all kinds of things without understanding their costs that I am not by default convinced that this is the right approach.
   
7. At times, I have also been struck by the blind faith placed in garbage collectors (which have admittedly gotten a lot better since I saw someone showing off Smalltalk's wonders in the mid-80s) while conventional memory management, especially in C and C++ is maligned: inherently leaky etc. etc. Ten years ago, this would be a relative criticism that stuck but with good class library support (such as that in a modern version of Boost, for instance, with a good modern compiler) the explicit control given to these things through reference-counted pointers, auto pointers, strong and weak references etc. seems to me to be preferable by far to the periodic holiday that, for instance, my Java-based cellphone goes on at the mercy of its need to collect the garbage. Others may disagree, and indeed, I have said enough in the last three items to spark several religious wars. Don't get me wrong: I'm not saying that Java, Ruby or Spring are always "wrong" and C++ is always "right". I suppose I have fallen prey to the temptation to defend C++ to the death when hearing it falsely accused from other quarters. Add a grain of your favourite salt at this point and long live the free exchange of ideas!
   
8. At the time it was posted, one podcast was described as an experiment in a hands-on how-to in using meta models in developing a simple Java component. Even on a bus, far from a keyboard, this sounded interesting and one of these days I'd still like to sit down and test drive what they were talking about while listening to it again.
   
9. In the mean time, there have been many VERY profitable things to hear on the pod casts: discussions about various agile approaches to software development, basic topics (error handling) and more advanced ones (concurrency, ultra large scale systems), daily-use ideas (refactoring) and arcana (internals of GCC, C++0x and Corba -- all with people who actually knew what they were talking about!) as well as interviews with folks (whether as well known as Grady Booch, or not) whose ideas and/or tools we have been depending on for years: it's an impressive collection and has been profitable. I expect the rest of it will be as well.

I am very likely to continue listening to the podcasts because even where I disagree with the presenters, it's exposed me to ideas that I have not gotten from other directions. Some 18th or 19th century poetic piece said that "even fools have their story" and neither the SE-Radio team nor their guests are fools. I commend their work-product as an effective tool to continue enriching any professional software developer's toolbag, to continue exposing oneself to new ideas and not least to help realize that there are more ways of solving every day problems than the one vendor, system or language that one uses all the time.

Thanks, guys, ever so much, even as I finish with one more tiny critique: the ID tags of the MP3 files are occasionally very inconsistent, claiming, for instance to be by team@se-radio.bet or @se-radion.net but perhaps that, too, is something that has been taken care of in a more reliable way since the episodes I am currently listening to were put out four years or more ago.