12th
Whither programming?
Point, from the Reinvigorated Programmer:
A huge part of my job these days seems to be impedence-matching between big opaque chunks of library software that sort of do most of what my program is meant to achieve, but don’t quite work right together so I have to, I don’t know, translate USMARC records into Dublin Core or something. Is that programming? Really? Yes, it takes taste and discernment and experience to do well; but it doesn’t require brilliance and it doesn’t excite. It’s not what we dreamed of as fourteen-year-olds and trained for as eighteen-year-olds. It doesn’t get the juices flowing. It’s not making. …
Instead of designing beautiful data-structures and elegant algorithms, we’re looking up the EnterpriseFactoryBeanMaker class in the 3,456-page Bumper Tome Of Horrible Stupid Classes (Special Grimoire Edition), because we can’t remember which of the arguments to the createEnterpriseBeanBuilderFactory() method tells it to make the public static pure virtual destructor be a volatile final abstract interface factory decorator.
Counter-point, from Matt Legend Gemmell:
Our art (that of software engineering) is not in making it work. If you see it as a significant success that you managed to name some methods, or write code that compiles and runs (or implemented a heap sort, or found the bounding box for a set of points, or parsed some XML), then your career goals are low indeed. Anyone in this industry can do that stuff, including any reasonably proficient final-year undergraduate in Computing Science. That’s core-skillset, vocational learning. You’re not aiming high enough.
I’m with Gemmell. I have to time to create kick-ass (not just functional) software, and write unit tests, and A/B test interfaces, and more—-all because I can write string foo = bar + "a", and not worry about malloc() and strcat() and weak typing; and I can use regular expressions, not hard-coded state machines and oh-crap-does-pcre-return-a-struct-or-a-struct-pointer. I can take advantage of the great leaps of MVC and testing because of Django and ASP.NET-MVC. The best libraries—-maybe not the PHP stdlib or god forbid the C++ stdlib—-give me the building blocks I need to get work done, not debug stack corruption because even on my top-of-the-line computer, buffer overruns can happen.
Sometimes it is frustrating. Sometimes I’m frustrated that C# doesn’t have macros, or that python’s lambda’s can only be one expression. But why would I trade jQuery—-backed by developers and testers far more talented than I—-for the trouble of writing a JS library? So I can say that it’s mine? It’s certainly not so I can put it, and all of the bugs it’ll have, into production. I’d rather spend my time speccing, designing, and implementing an awesome new feature for Kiln.
What’s great about libraries (at least the well-designed ones) is that they are a framework for building on—-more a palette than a paint-by-numbers. If I realize that Piston’s request handling is too coarse, I can fall back to Django; if I need processing that Django doesn’t provide, I can get write an extension or fall back to straight python; if python’s too slow I can use Unladen Swallow or drop down to node.js. But each time I leave a library, I lose abstractions that help me make the things I want to make.
The making going on here is at a higher level. That’s where we’ve worked and fought to be, and that’s where I’m staying.
