I've seen my errors in production code. I'm doing a forensic analysis of some "embedded" software I shipped to a customer. By embedded I mean there is no UI and it is supposed to run unsupervised 24x7.
Server (Cloud) software often meet this criteria, but sometimes we cheat and log in (to see how things are going) or restart the OS when things aren't quite right.
But, that's not quite embedded. By embedded I mean "It has to run without me or the user intervening." and "There is no such thing as rebooting to fix a problem."
Now, I love developing code in Lua, so this isn't a Lua criticism, but when I review my daemon logs and see that the process died because I was trying to add a number to a "nil" value, I cringe.
On this same system I have a Haskell process also running. The only time I saw it had died was when I didn't handlebeing fed bad data from a corrupt database. Not exactly the same class of bug...
The Lua code problem could have been caught with unit tests or code review (maybe), but I am sort of a lazy programmer. I can fall back on lazy habits such as "this is so obvious it can't be wrong".
Haskell doesn't let me do this. It won't let me go on tossing untyped variables here and there . It won't let me assume that I never pass a string as a number (or vice versa). It forces me to be precise.
Compiling modern C++ (C++11) with warnings on (in clang++ or g++) is similar.
I hate to say this, but after continually abandoning C++ (in cycles: 1992, 1997, 2002, etc), I am back again and I like what I see in C++11.
I'm writing deliverable code at work using C++11 and I just tried my hand at using it, *instead* of a scripting language, to do some configuration file handling. C++11 for scripting? Yes. And it seems to work. Not a pointer in sight. (Actually that would be the only sane way to do this in C++: rely on RAII.)
All that being said, and especially to any potential employer who may be reading this: I am not really a lazy programmer.
No comments:
Post a Comment