I think it's finally time to record my thoughts on the new workplace (and in the process muse over some things that have been on my mind lately). And yeah, that bleak sounding title is the reason I'm about twice as satisfied here as I was back at I Love Rewards.
First things first, full disclosure, my first project here was in PHP. And they do their share of .NET programming (and I suspect that a lot of the driver work gets done in C or maybe even Assembly, but that's unverified). They interact with the Postscript standard a lot, but no one does it by hand. Because we serve the medical industry, there's also large parts of CCR and HL7 slung around on a regular basis. That's particularly bad if you understand what those acronyms mean. CCR is an XML-based standard circa 1998, and it exemplifies everything that eventually made sane minds give up that markup for today's light-weight formats. It's the only data standard I've seen that, and I promise I'm not making this up, you have to pay in order to get a copy of. It seems like that would defeat the purpose. HL7 is what you would expect out of a Unix shop from the early ninties. It's a pipe-delimited text stream whose definitions document runs to a hundred pages or so.
OS-wise, I'm in the minority with one other developer who thinks we ought to be using linux-based servers, and I'm actually the only one electing to go with Linux + Emacs for my desktop needs. The place is thick with MSVS and the like. Finally, I'm the only one who uses source control (and it's GIT, as if you had to ask by this point).
So why am I happy in the face of these conditions? It's because, for the most part, I've been hacking Scheme and Elisp through the past few months, and using whatever additional tools I wanted to.
Scheme? At a place that also potentially uses Assembly? Well, yeah. It turns out that no one outside of IT is religious in the least about what languages, tools or systems you choose to use. They really only care that the result is business-applicable in some way, cheap and fast. So as long as you hit those, they don't particularly care. I couldn't get away with this at many other places. Being a Linux-toting, Emacs-using Scheme hacker in the middle of a vast Windows ecology, I mean. There are remarkably few job openings in the field, especially in the bustling, skilled-programmer-metropolis of Toronto. If you want a capitol-J Job here, you need to know (and be willing to work with) Java or C#, the COBOLs of the modern world. Every once in a while someone wants a Python or PHP hacker for some contract work.
But apathy has an upside, like I said, and I'll take it.
It's really interesting to me that once again, passionate, caring (but woefully uninformed) MBAs seem to fuck everything up. If Ken was a hands-on leader, I'd probably have had to learn Java or C# too, or at the very least content myself with constant PHP. This is the Paul Graham effect in full swing; big companies use languages and tools that get sold to the management, not to the devs (and to be fair, if the devs got to pick, we'd all probably be working in C++ and it would be worse). Little companies use the juice that gives the the highest ratio of miles to millileters.
This is the crux of the problem though. The decisions here are such that most people have no idea what the right answer is. Most business people pick what's advertised; thay want to go with the flow. Most devs pick what's fastest in the machine sense; once they're done writing reams of code for their hello world, they want the machine to execute as fast as possible (Contractors seem to want what gives them as many billable hours as possible while not raising too many eyebrows, but that's far from unique to the IT business so I'm disregarding it). It's pretty obvious to the reasoned observer that neither are the correct answer. They might accidentally yield correct answers, but there's nothing about either thought process that makes the right answer more likely than (or even equally likely as) the wrong one. The specific answer depends on the specific situation, granted, but I put forth that in all cases, the correct answer is the most expressive language that will fit on the target hardware. You do want to optimize speed, but not from the machine's perspective. Code needs to be fast and easy to make and maintain, rather than run, which means that you want as little a gap between what you can express and what you want to express. The complaint that gets levelled at non-C languages is that they're slow, which is true until you consider that ~2.4 gH dual-cores and 6gb ram setups are now common on the home market. If you're working on the latest 8-bit IC from Atmel, ok, yes, use C or Forth and constrain yourself to either manual bit-twiddling or the stack. If you're on the desktop, or god help you, a fucking server cluster and still managing memory yourself, then someone (and it may have been you) has made a poor choice on your behalf. This is the sort of obsesive behaviour whose logical conclusion is hand-counting your cereal flakes every morning to make sure you're getting precisely 1024 of them. I think we can agree that the sane thing to do is fill the bowl, hoping the offsets average out in the long term, and getting on with your day.
It seems that democracy doesn't really work here either, because as I hinted above, I doubt that most programmers would pick the most expressive language. They'd either pick what they know just because they happen to know it already, or they'd pick a language that let them code as close to the metal as possible. So how do I know they're wrong, as opposed to me being wrong? Well, that's where the issue goes to shit. The reason I know they're wrong is that I've worked with the low-level languages (C and Forth), I've worked with what I'll call the mid-level languages (Python, Ruby, Java, C#, PHP), and I've worked with four or five LISPs (which I stereotypically place at the top of the progression). As per PG's Blub Paradox, I know that the non-lisps are missing some crucial features that I find myself using on a fairly regular basis (not even macros, interestingly. The prefix notation itself seems to pack a lot of the punch on its own). Also, I've clocked myself as "fast" with some of these languages and "slow" with others. The reason the issue goes to shit here is that this argument will only convince people who have already given several LISPs a fair try and have worked in some other languages from accross the continuum. Those people don't need convincing; if they've come that far, it's a good bet that they've stuck with LISP in some form, or that they're one of the few, vocal pessimists around, loudly proclaiming "all languages suck balls". The people that need convincing are the ones that are currently convinced that C# or Java alone represents the limits of "programming", or the ones that look upon learning new languages as procrastinating.
It's ironic to consider, but it seems like it might just be easier to sell Scheme to the managers and let the traditional pyramid bear the change out. Managers understand the argument "this way is faster", and don't particularly care about the rest as long as you can prove that. There's trouble this way too, though. You see, it's fairly easy to make the argument "this way makes me faster", as long as it's true and you can demonstrate this. But the argument "This will make you faster" is another matter entirely. For starters, in a shop of C programmers, it's patently false. It'll take months of genuine practice to get to a higher level of productivity if your team doesn't already know LISP. There's exactly one other way to go, and that's competing at the company level. In other words, start a bunch of Scheme/CL shops and watch them out-compete the ever-loving fuck out of the Algol descendants. Watch them driven before you, and blah blah blah. It seems like it would work, as long as we stop the AI winter thing from happening again, which looked like it was the result of promising too much, delivering too little, while focusing too much on the math and linguistics and not enough on the business end.
In other words, LISP for business logic instead of research. I think I can do it. I'm certainly in a position to. Even if not, I'll try my hardest and let you know how it goes.
