Friday, August 20, 2010

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.

Monday, August 2, 2010

I figure it's about time to update because I haven't lately. It turns out that you don't stop being busy just because you've stopped working for an employer that demands 20 overtime hour a week. You just get busy doing other stuff. I;m beginning to think that "busy" is either contagious or hereditary.

Mostly the stuff going on here is work on that clandestine project I mentioned a little while ago. Basically, I got to thinking that I really wanted to pick up D&D again. The really sad thing is that my group of friends is pretty geographically disparate, and we don't really feel like driving out for 6 hours to meet up for 8 hours of dice-rolling only to have to weather the drive back. That's not the type of ordeal you can undergo every two weeks.

My first thought was "ok, there has to be something that will let me and my friends play D&D online". I took a look around and found Virtual Tabletop (which has a pricing-system/website so bysantine that I rate their chances of putting together an intuitive in-game interface at very near zero), Open RPG (which has that typical open-source affliction of horrible UI, make-based installation and on top of that neglects OS X, which most of my friends use) and Web RPG (whose link doesn't go anywhere because the only evidence I could find of the project is a page talking about why, specifically, it sucks).

And that's the point at which I started hacking together my own little PLT Scheme app to let me play D&D with my friends. I've registered diecastgames.com (which currently goes to a godaddy parking page), and put together a development blog here in the meantime. It isn't at the point where I want anyone using it yet, but it should be up and running in beta form in the next little while. It'll be almost ugly as sin until I put the art together, at which point we're ready to go. Then I'll just have to convince one of my friends to DM.

Which shouldn't be hard, all things considered. If they get uppity about it, I can just point out that I built a friggin online D&D system from the ground up.)

Ruby and Erlang each come with their own modes, and recent Emacs versions ship with a built-in Python mode and shell. Smalltalk uses its own environment (though GNU Smalltalk does have its own mode), and I'd really rather not talk about PHP. If you're writing in it, chances are you're using Eclipse or an IDE anyway.