Steven? I Disagree.

Ok, yes, I know the last time I disagreed with Yegge, I wound up eating my own hat, but I hereby suggest that partitioning the software industry into Libs vs. Cons is a stupid idea, and gains us nothing. In any sense.

Firstly, because those terms are already loaded with enough political and emotional baggage that people are going to have a hard time letting go[1], and that's going to lead to[2] the same kind of partisan garbage that US politics is well known for.

Secondly, because partitioning any group of people into two explicit, conflicting sides is hands down the worst way of easing/preventing/reducing conflict within that group. Ostensibly, that's what he's trying to do with the thought framework; point out that certain things are a matter of preference rather than points of debate, and that we should therefore stop arguing about them. Something tells me the actual effect of this conceptual framework will lead to a different outcome[3]. I've read comments calling the opposition to this classification scheme "weird", and I have to wonder why. It's divisive, pretty much by definition. The fact that certain pieces of it are correct doesn't make it worth keeping in its entirety, and in any case...

Thirdly, the underlying properties he presents are, for the most part, not a matter of preference. He sort of presents them that way, but I disagree at that level. Hell, lets do a blow by blow. here are the points he defines as principles of software conservatives.

1. Software should aim to be bug free before it launches...
2. Programmers should be protected from errors...
3. Programmers have difficulty learning new syntax...
4. Production code must be safety-checked by a compiler...
5. Data stores must adhere to a well-defined, published schema...
6. Public interfaces should be rigorously modeled...
7. Production systems should never have dangerous or risky back-doors...
8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production ...
9. Fast is better than slow. Everyone hates slow code. Code should perform well. You should engineer all your code for optimum speed up front, right out of the box...

The software liberals supposedly have the inverse principles. He makes them explicit in his entry, but I won't bother to quote them here. Note that points 1, 4, 5, 6, 7, 8 and 9 have not a fucking thing to do with personal preference. They're things that make sense in some contexts, and not in others. Some programmers really, really like having error prevention in the form of a restricted language (#2), and some really hate learning new syntax (#3), but the rest of these "principles" involve trade-offs that sometimes make sense and are sometimes retarded. Should All software aim to be bug free? Should production code All be checked by a compiler? Should production systems Never have back-doors? We actually can't know the right answer in general, from a static analysis at least. At the risk of being painted as a godless, sissy liberal in the wake of Yegge's proposal, we need to take a look at the run-time environment.

Your high-frequency trading software or your Air-Data/Inertial Reference Unit, or your cardiac implant firmware had damn well better be bug free, and rigorously modeled AND compiler checked AND free of back-doors AND not allowed anywhere near production if they're even suspected of incorrectness. When the stakes are billions, or lives, eating the cost of a more extensive and rigorous development process makes sense[4]. On the flip-side, when we're dealing with a situation where the software is replacing an already buggy manual process that no lives or life savings depend on, no one is going to care about a complication. Likewise, there isn't a benefit to taking weeks to prevent a bug that you can hotfix in days or hours. Finally, if the cost of a rollback or upgrade is close enough to trivial, you can be forgiven for taking more risks than you otherwise would.

This is not what a preference looks like; it makes sense sometimes and not others, and a correct one can be chosen based on context. A preference is something that there really isn't a "correct" way of thinking about. Something that we have to accept because it's atomic. So even if globally bifurcating the industry would lead to some new insight[5], and even if that insight would improve inter-programmer relations[6], these aren't the axes to do it on.

So there.

Steven... I disagree. And I won't be adopting your thought framework until you consider filtering out your projections.

---

Footnotes

1 - [back] - If you take a look at the HN, /. and G+ discussions, you'll already see people conflating the political meanings with the proposed software-oriented labels. Less so on slashdot, where most seem to simply dismiss the point of view, but there's a comment on the Google Plus page that reads

Dynamic typing has been shown through research to reduce maintainability compared to static typing. Lars Ivar Igesund

Which is, near as I can tell, Utter Horseshit™©. If you bother reading on, when someone asks for a citation, the response is

The research was done by a friend of mine while working at one of those famous, private research centers (yes, one you've heard of), but to my knowledge it has not been released. I don't remember the statically typed language used in the study, but I Imagine it was Java. The dynamically typed language was Ruby. This I can't point you to it, I just hope that you believe me when I tell you the conclusion of it. It certainly jives with mine experiences.Lars Ivar Igesund

That's about what I was expecting; "This guy I hang out with told me my opinion was totally right". Oh, by the way, 16 upvotes, or plusses, or whatever the fuck. Never-mind the fact that a methodology isn't outlined, or that the definition of "maintainability" isn't mentioned, or that the languages involved are "I Imagine ... Java" and Ruby, or that we don't know if/how the researcher controlled for differences among teams/programmers/projects or (in case this was a single team doing to separate projects) the teams' innate preferences/learning over the course of the experiment.

2 - [back] - Actually, as you can see by the previous note, "is already leading to" would be more accurate. Hell, there's already a guy out there calling himself a "Software Libertarian", and we haven't even gotten through Software Ayn Rand yet. That's some leapfrogging right there.

3 - [back] - I believe that may be the second time I've linked that comic this month.

4 - [back] - In a similar vein, it's interesting to note that NASA's Mars rovers have "dangerous or risky back-doors" capable of modifying the systems' programming and data. Presumably it was too risky to send them out without the possibility of an in-flight bugfix?

5 - [back] - I doubt it will.

6 - [back] - Again, severely doubt it.

Please Don't Listen to Jeff Atwood

On my bus ride back from work[1], I've been thinking about how to make the response to this precise and thorough.

The stuff I was going to come out with included a reference to this Sussman talk from Danfest, which concludes by highlighting the title of a Minsky paper; "Why Programming is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas". I won't link you to the actual point in the talk wherein this happens, because it's only about thirty minutes long and well worth your time in its entirety. The gist is that by forcing yourself to describe a process or concept well enough that a very stupid machine (a computer) can understand it, you can iron out the unnoticed gaps and assumptions in your own knowledge. This is particularly relevant when dealing with other humans, who by and large aren't stupid, but merely missing some piece of information that you've begun to take for granted, or perhaps only ever learned by rote.

That would have segued naturally into the point that learning to think precisely can help humans communicate more effectively with each other, and not just with machines. The rebuttal would have continued with a short, faux-op-ed from an early scribe claiming that literacy is completely overrated and unnecessary in most peoples' every-day lives (claiming in all seriousness that hunters really just need to worry about is not breaking their spear arms, and that the farmers should focus exclusively on their plowshares). He'd conclude by asking you to refuse to learn how to read and write, because frankly, he's sick enough of his current colleagues' grammatical errors without you adding your own cock-ups to the mix.

Then I was going to point out this video from the MIT 600 Computer Science course[2], wherein Harold Abelson explains to the fresh class that "Computer Science" is not about computers in the same sense that Physics is not about particle accelerators, or that Biology is not about microscopes and petri dishes. What Computer Science is about, he claims, is formalizing certain types of formerly intuitive knowledge. In this case, imperative knowledge. How to do things. For a finale, I'd point out that, while Jeff was talking about coding where I'm making an argument for something more generally useful, humans might find it easier getting to the latter after going through the former. Seibel's Coders at Work[3] shows that one of the two[4] peculiar things about people who become good programmers is that they had early exposure to computers and coding, at a time when that wasn't really the typical experience.

I was going to write that, but on second reading, his latest piece seems to have the paradoxical message of

1. You shouldn't bother learning things that won't directly and obviously make you better at the tasks in your job description[5]
2. You shouldn't learn to program just for the money[6]

I'm not too familiar with the "everyone should learn to code" movement, but I doubt its core message is that everyone should become a professional programmer. Hell, I know how impossible that proposition is, and I've talked about it before. The thing is, unlike plumbing[7], programming[8] does teach those who study it a lot about communicating precisely, thinking clearly, and solving problems in general. So it at least seems like a believable candidate for "the next literacy".

So, yes, please, do learn to program. Don't avoid it just because you can grow turnips, or answer phones, or sit in meetings fine without it.

Go beyond

10 PRINT "HELLO"
20 GOTO 10

Begin to understand how to think precisely, and communicate clearly with entities who don't have a lot of knowledge in common with you. Don't worry that you'll never actually use this at your day job, and certainly don't expect to be a highly paid programmer in just 7 days. But do learn, because it will be interesting, and fun, and useful in places you might not expect.

---

Footnotes

1 - [back] - As a Lisp programmer at a small Toronto company, just in case my bias wasn't obvious enough already.

2 - [back] - (better known as SICP)

3 - [back] - (author's talk here)

4 - [back] - (the other is that most of them use Emacs)

5 - [back] -

To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can't see it.-Jeff Atwood

(emphasis his).

I think my response is obvious from what I've said already, but just in case. "Programming" is not "variables and functions, pointers and recursion". It is a way to describe a process or concept so well that things which don't even share your biology can understand it. This is useful when dealing with things that do share your biology, but not quite all of your knowledge, and it is useful when explaining fundamental concepts to the uninitiated.

6 - [back] -

Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. -Jeff Atwood

7 - [back] - Which deals with a very specific, physical system, isn't particularly fun, isn't particularly social, and only ever needs to be practised when something goes wrong.

8 - [back] - Which deals with a wide variety of at least partially imaginary systems, is fun, is mostly social, and can be applied in situations that don't involve water spraying out from under your sink.