I think I'm a software libertarian.

If you like dynamic typing and can write good, legible code in a language like Python or Lisp, do it. If you like static typing, knock yourself out. If you want to use an IDE, go for it. If you want to use emacs, do it. Hell, if you like object-oriented programming, try it out. I think 95% of "object-oriented" programming (as currently practiced) is junk, but the other 5% is legitimately valuable. If you have the taste to pick from that 5%, go ahead.

What you shouldn't have the right to do is impose complexity on other people. Use whatever environment you like, but if your code depends on your environment, that's bad. If people can't get work done because they're cleaning up your messes, that's bad. Be as liberal and as kinky as you want in your own sandbox, but don't impose your wacky, untested DSL on everyone else.

That said, I like statically typed languages. ML is the only language I've encountered where reading average-case code is enjoyable. (Scala's a great language, but average-case code is ugly due to the Java influence. There's a fair amount of spaghetti code written in it due to the cultural legacy of the SpaghettiFactoryFactory Java culture. I can't speak for Haskell because I haven't seen enough.) I think that's neat and very rare in the programming world. How much code is enjoyable to read? 1 percent, maybe? In Ocaml, that number is a lot higher. Probably around 50%. 50 percent of Java code isn't even legible. Being able to actually read other peoples' code is nice, and it's one thing I miss about working in Ocaml.

I'm probably more in line with the hard-line conservative camp in terms of my view of complexity: avoid it unless you need it. The Unix philosophy works. Religious X-oriented programming doesn't. Big Code leads to fail. Small-program methodology's little programs (Unix philosophy) are written to solve problems: do one thing and do it well. Ambitious projects should be structured and respected as systems, not all-or-nothing, massive single-program megaliths with no clear communication policy among modules. Small-program development works. Big Software is written to get promotions. That produces the next generation's legacy horrors. Also, structuring your company around 17-day "iterations" is stupid. Et cetera.

I also tend to think that a lot of the features that scare typical software conservatives are genuinely worthwhile. Macros in Lisp are important and can be very beneficial-- if used conservatively. Cleverness for its own sake is bad, but there are times when macros are very useful. Document what you're doing, and make sure it's tasteful and makes sense before you let anyone else depend on the work, but go ahead and do it. I wouldn't have learned what not to do with macros had I not made a few mistakes when I first encountered them.

So, with a mix of opinions from the "conservative" and "liberal" camps, I can't say where I fall. I like macros (when used by disciplined people) but I also like static typing. Both turn out to be very useful tools. Consequently, I find that I like a lot of different languages and insist not on a specific one, but on small-program methodology so that people can use the right tool for the job.

I'm conservative because I dislike complexity (I think "software liberals" are OK with complexity as long as it's under the hood-- most metaprogramming involves extremely complex solutions that, when they work and the abstractions don't leak, although this is rare, allow clean interfaces-- whereas I'm not comfortable making that distinction) but I (a) understand that liberalism is essential to driving innovation, and (b) can't classify myself as a conservative because management is inherently conservative and is, in software, almost never the solution to the problem. Usually, it is the problem. Most companies fall to shit not because they have some difficult code-- every codebase has some crap in it-- but because management mandates that they use the bad code (often for political reasons, like the original architect being a crony of the manager) as-is instead of taking the time to understand or replace it. I'd like to see how Valve evolves over the next 5 years, because I think management in software is usually a source of undesirable complexity, rather than the safeguard against complexity that it thinks it is being. If Valve can give us a determination either way on whether software can work without managers in the first place, that'd be incredibly useful information.

Not surprisingly, software politics also has a lot of individual inconsistencies and hypocrisy. Corporatism (in politics, not software) is neither socialism nor capitalism but a system designed to give the best of both worlds to a well-connected elite and the worst of both to everyone else. (Consider air travel as a microcosm: Soviet experience and service quality and comfort, mean-spirited and capricious-- but very capitalistic-- pricing.) I think the same exists in software politics and the typical managerial conservatism. People and organizations can identify in name with liberalism or conservatism, but tend to pick and choose as suits them. (For an example of this inconsistency: Google, a bastion of software conservatism, allowed GCL to exist.) What makes 90 percent of software jobs so fucking miserable isn't those rock star, "undisciplined" Rails liberals or stodgy gray-haired conservatives. Rather, it's a corporatist "crony capitalism" state where people who win managerial blessing get liberalism (i.e. the autonomy to do whatever they want and freely impose complexity downstream) while the rest of the drones get stonewalled with a supposedly stiff-lipped conservatism (e.g. "you can't [fix that codebase | use that language | pursue that side project] because we can't afford the risk") that is presented as principled, although the drones see managerial favorites getting through that wall on a daily basis, so they aren't fooled.