?

Log in

No account? Create an account
Semiformalishmaybe

Software conservativism and Software liberalism

I thought this essay on the differences in software development philosophies was bril. I also find myself moderate with left leanings, strongly opposed to both the far left and the far right on this scale. This isn't that surprising; I do see programming as being significantly a literary/expressive task, and while I like tools that help us be more sure that software does what it's supposed to do, I want them to be optional helpers rather than mandatory, and I want to be able to decide how disciplined to be at every point, rather than pick a language which forces inappropriate discipline. A few thoughts on the specifics of his framework (mainly as they pertain to me; how do they pertain to you if you sling code?):

  • My early/formative experiences as a programmer happened over a very large span of years. My first language was BASIC on the Apple II when I was 5 or 6, my second language was assembly, and my third main language was C. Learning Perl, Common Lisp, ObjC, and Scheme, all within a short span of years, really was kind of rough (but definitely worthwhile).
  • When I was in middle/high school, my mentors and role models were people who wrote viruses, cracked software, and occasionally wrote gritty social media platforms (Cleveland Free-Net, bulletin board software, etc). Oh, there was also my father, but he mainly wrote mathematical software that I didn't understand until much later. In college, the CS weed-out courses were run by software engineering types who really geeked out over software reuse and reliability and had this toy dialect+framework of C++ they pushed.
Moving on to those statements that he calls conservative:
  • Software should aim to be bug free before it launches - Aim to be, sure. I don't believe that models are the best way to do this, but making a good effort to constrain the space of possible bugs helps. A system doesn't need to be fully specified though, and rough edges, so long as they're known as such, are ok
  • Programmers should be protected from errors - Not usually. Programmers should probably have an initially safe set of features and enable dangerous features as they see fit.
  • Programmers have difficulty learning new syntax - Languages arn't just syntax. Having sane limits on language use makes sense, but those limits should have enough room and be loose enough to allow individual judgement, knowing that justification might be required. Language features that define new syntax are ok, if justifiable. Operator overloading and the like are fine when used responsibly.
  • Production code must be safety-checked by a compiler - Not necessary. Languages that can offer better warnings that your code might be bad in various ways are welcome though. Safety-checking is just a solution to one kind of potential problem, and there are times you won't want it.
  • Data stores must adhere to a well-defined, published schema - 2NF or 3NF strike me as sensible for databases. I don't think a formal schema definition for databases, with the charts and diagrams and the like, is necessary. XML probably should have a DTD if it's being used for anything serious. I agree that NoSQL should be avoided except when really justifiable, but I have no opinion on the proposed requirement.
  • Public interfaces should be rigorously modeled - Probably, although the way this is phrased seems to rule out XML serialisation, which seems generally reasonable to me for some purposes
  • Production systems should never have dangerous or risky back doors - No. This constraint is usually too restraining, although the backdoors should still be secure and people should avoid doing things that they're not absolutely sure won't break things unless the main site is either down or they've tested it on a test server
  • If there is any doubt as to the safety of a component, it cannot be allowed in production - No, and fuck you. People have real needs, and guidelines must generally be able to bend to those needs. It's good to have people always looking for problems in these things though, and to try to learn what things are likely to lead to them
  • Fast is better than slow - It's not always possible to know when/where speed is important, and that weekly shell script that processes your backups doesn't need every ounce of speed. When you know you need speed, make it part of the design, and if speed doesn't come at a significant complexity cost, go for it. Otherwise, think about speed if/when it comes up.
And commentary on the proposed liberal parallels:
  • Bugs are not a big deal - Depends on the bug, and while debuggers are great, they don't work on some kinds of software. Often you find the process of tracking something down is best done by both writing unit tests and debugging, working from both ends inwards. Bugs can be embarassing, and they can be made less frequent with good practices.
  • Programmers are only newbies for a little while - Yes, although some features are dangerous even for experts. Doing a lot of string handling in C will produce memory errors unless people arn't using the standard functions, even if the coders are expert. Avoiding that language for some kinds of tasks really helps. It all comes down to judgement
  • Programmers figure stuff out amazingly fast when their jobs depend on it - Sure, but let's not toss obstacles in their way without reason, and occasionally problems are deep when concepts don't line up that well. Subtle gotchas can burn days.
  • Succinctness is power - This really depends.
  • Rigid schemas limit flexibility and slow down development - That's okay in a database. It's less okay in code. I recognise that designing things upfront is often wrong because problems become clear when one begins to tackle them, but at some point things need to come together into something that can be reasoned about
  • Public interfaces should be simple, backward compatible, and future compatible - I think the simplicity is normally a good idea. I'm not sure about the backward and future compatibility though.
  • System flexibility can mean the difference between you getting the customer vs your competitor nabbing it instead - Maybe, but I've never thought much about coding in that way. It's an art, not engineering nor business. Still, flexibility is important (within reason)
  • Companies should take risks, embrace progress, and fiercely resist ossification - Probably? This is not really software development philosophy though.
  • Premature optimisation is the root of all evil - I like the general intuition here, but sometimes you know something will need to be fast, and if that's the case, design it to be fast. Making a prototype that's slow that will be useful for testcases can be a good idea, but you'll know it's a prototype.
I tend to agree that the static typing pushers are off, for most of the reasons he provides, but I also like typechecking as an optional language feature or tool.

On dividing up the space:

  • I think he's roughly on WRT the non-political stuff.
  • On his "conservative stuff" portions, I wonder if the speed focus he places in the conservative camp fits well with the mention of a category that includes relational calculus (something I'm a big fan of)
  • I generally like the centrist stuff he mentions well. Some of the liberal stuff he mentions makes me nervous, the conservative stuff generally strikes me as excessively square.
As for languages:
  • I used to be really into assembly, but now I find it too hard to maintain, and I've stopped using any assembly at all. I haven't coded in the language for many years and would be weirded out to see people using it broadly
  • I love perl but program fairly conservatively in it. Perl isn't as extremist liberal as it has a reputation for if the perl community style is followed, and I generally do that plus add my own discipline features as-needed.
  • PHP is crap and never should've been invented, and shell scripts that go very far beyond the things one would do interactively should be perl scripts instead. Ruby seems pretty okay to me except in ways that are just syntactic preferences I hold
  • Javascript seems ok but kind of primitive, Visual Basic is a toy, and Lua is possibly useful to add dynamism to something you unwisely chose to program in C.
  • Python is ok except for my syntactic preferences, but is not actually any less liberal than Perl when Perl is programmed in using reasonable discipline. CLISP is grand, as is Smalltalk.
  • I like C and ObjC and Scheme for some purposes, but rarely find myself needing to program in them nowadays. I would probably do more with ObjC if I had a Mac or if GNUStep were more mature. C is too low-level for many tasks unless you want to reinvent the wheel
  • C++ is an ugly hack that never should've been. Java's pretty good. Csharp is a cheap knockoff of Java, and Go is just uninteresting introduction of failurescauce onto a C-like base.
  • I avoid the lannguages he considers more conservative than that; they're seriously not my style, even as I see SML as being potentially interesting as a domain-specific toy language.
As he acknowledges, people like me write in a liberal language with a moderately conservative accent. I like this because it's always as-needed, and I get to choose the flavour of conservativism that's appropriate to the task. My bigger bits of Perl use some of the disciplined programming modules I wrote, while my smaller projects don't. And so on. I don't want my programming language or tool or employer making that choice; it should be made responsive to immediate needs.

I intentionally don't comment on the validity of his framework. I don't have an opinion on that at this time.

Comments

My thoughts on the whole thing are that it's an interesting and useful framework, but probably not complete or even entirely accurate. At the very least it's good to provoke thought about this stuff, which Yegge is good at.


You might consider revisiting Javascript, such as with Crockfords "Good Parts" book. It's not nearly as primitive as its longtime reputation holds. Prototypal inheritance is pretty powerful, as are its objects themselves.

PHP5.3 is still crappy, but it's become a semi-reasonable language, unlike PHP4. They even have a form of lambdas now, though they're confused about closures. And 5.4 even has a reasonable array-literal syntax, finally. (Argh.)

I think the idea of liberal/conservative when applied to Perl and Python is that Perl allows you to do crazy things and gives no inherent structure ("liberal"), while Python forces structure ("conservative"). Those Perl guidelines and discipline you mention are a way of programming Perl in a conservative way, but don't make Perl itself more conservative.

Java could be considered a knockoff of C++, attempting to learn from C++'s mistakes. C# in turn tried to learn from Java's mistakes, and from what I've heard is actually a better language (albeit stuck in a semi-proprietary runtime).


I'd also call myself moderate with liberal leanings on this scale, but I'm not sure if the scale is right.