Shared publicly  - 
 
Notes from the Mystery Machine Bus

I've spent the past eight years (starting back in June 2004) writing elaborate rants about a bunch of vaguely related software engineering issues.

I was doing all that ranting because I've been genuinely perplexed by a set of "bizarre" world-views held dear by -- as far as I can tell -- about half of all programmers I encounter, whether online or in person.

Last week, after nearly a decade of hurling myself against this problem, I've finally figured it out. I know exactly what's been bothering me.

In today's essay I'm going to present you with a new conceptual framework for thinking about software engineering. This set of ideas I present will be completely obvious to you. You will probably slap yourself for not having thought of it yourself. Or you might slap the person next to you.  In fact you probably have thought of it yourself, because it is so blindingly obvious.

But in my thirty-odd years as a programmer I'm pretty sure this way of thinking about things, if it already existed, has never been mainstream. That assertion is backed by what has to be at least ten Google searches that turned up nothing. So I'm pretty confident.

I'm going to make it mainstream, right now. Watch!

And I suspect this conceptual framework I'm giving you will immediately become, and forever remain, one of the most important tools in your toolkit for talking with -- and about -- other programmers.

The punch line, a.k.a. TL;DR

I won't keep you in suspense. Here is the thesis of this looooong essay. It is the root cause that motivated over half of my ranting all these years, starting at Amazon and continuing here at Google.

(Note: I Do Not Speak For My Employer. This should be patently obvious. When employers want someone to speak for them, they hire a person like the Mouth of Sauron, to make absolutely sure everyone knows they are speaking for the Employer.)

My thesis:

 1) Software engineering has its own political axis, ranging from conservative to liberal.

(Note: Technically, you could stop reading right here and be at pretty much 90% comprehension. In case you care.)

 2) The notions of "conservative" and "liberal" on this political axis are specialized to software engineering. But they exhibit some strong similarities to their counterparts in real-world politics.

 3) Everyone in the software industry who does stuff related to programming computers falls somewhere fairly precise on this political spectrum, whether they realize it or not.

Put another way, YOU are either a liberal or a conservative software engineer. You may be more of a centrist, or maybe an extremist, but you fall somewhere on that left/right spectrum.

Just as in real-world politics, software conservatism and liberalism are radically different world views. Make no mistake: they are at odds. They have opposing value systems, priorities, core beliefs and motivations. These value systems clash at design time, at implementation time, at diagnostic time, at recovery time. They get along like green eggs and ham.

I think it is important for us to recognize and understand the conservative/liberal distinction in our industry. It probably won't help us agree on anything, pretty much by definition. Any particular issue only makes it onto the political axis if there is a fundamental, irreconcilable difference of opinion about it. Programmers probably won't -- or maybe even can't -- change their core value systems.

But the political-axis framework gives us a familiar set of ideas and terms for identifying areas of fundamental disagreement. This can lead to faster problem resolution. Being able to identify something quickly as a well-defined political issue means we can stop wasting time trying to convince the other side to change their minds, and instead move directly into the resolution phase, which (just as in politics) generally boils down to negotiation and compromise. Or, you know, Watergate.

Are real politics and software politics correlated?

Does being a political conservative make you more likely to be a software conservative? I think all we have are hunches and intuition at this point. We'd need studies for an answer with any scientific basis.

But my hunch tells me that they are only loosely correlated, if at all. I suspect that the four possible combinations of political left/right and software left/right each contain around a quarter of the programming population, plus or minus maybe 8%. But that's a totally nonscientific hunch, and I'd love to see the real numbers.

The reason I suspect they're only loosely correlated is that I think a person's software-political views are largely formed by two forces:

 1) Their personal early/formative experiences as a programmer -- in particular, what kinds of decisions either burned them or made them wildly successful.

 2) The software-political core values of their teachers, professors, mentors, role models, and coworkers.

But there are some factors that could increase correlation between political orientation and software orientation. One is geographic/regional influence -- for instance, big tech universities being located primarily in red or blue states. Another might be basic personality traits that may incline people toward traditionally liberal or conservative value systems.

Regardless of how correlated they are, there are going to be a lot of programmers out there who are mildly shocked to find that they are political conservatives but software liberals, or vice-versa.

Isn't the 2-party system a flawed model?

Well, yeah. Mapping something as nuanced as political viewpoints onto a one-dimensional axis is a well-known gross oversimplification. For instance, some U.S. voters may self-identify as fiscally conservative but socially liberal, and as a result may wind up not having a strong tie to either majority political party. These "swing votes" tend to be the reason that political moderates more often wind up winning elections, even though studies have shown that people tend to assign more credibility to extreme opinions.

The influence of centrists or moderates is just as important in the software engineering world, and we'll explore it more in a bit.

But having a single axis still allows for a wide distribution on both the right and the left. As in real politics, a moderately right-leaning viewpoint may seem dishearteningly liberal to someone who lies even further toward the extreme right. I will illustrate with some well-known real-world programming language scenarios in the examples section.

All in all, despite its oversimplifications, I think 2-party model is a good starting point for educating people about the politics of software. It'll be a good frame of reference for refining the model down the road, although that's out of scope for this essay.

So what's a Software Liberal slash Conservative?

If you ignore specific real-world issues, and just focus on the underlying traits and values of real-world conservatives and liberals, it boils down to just a few themes. I'll argue that those underlying themes are also the basis for software politics.

It's easiest to talk first about conservatives, and then define liberals in terms of what conservatives are not. This is because conservatives tend to have a unified and easily-articulated value system, whereas liberals tend to be more weakly organized and band together mostly as a reaction to conservatism. This applies to both real-world and software-world politics.

So we'll start with an operational definition of conservatism, from Jost et al.:

 "We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear."

This theory is explored, re-tested and affirmed in a 2008 study from Garney et. al, "The Secret Lives of Liberals and Conservatives: Personality Profiles, Interaction Styles, and the Things They Leave Behind".

I hope you'll agree that this definition is minimally controversial. After all, the adjective "conservative" is more or less synonymous with caution and risk aversion. Financial conservatism is frequently (and intuitively) associated with age and with wealth. Companies tend to grow more conservative with age as they weather the storms of lawsuits, technical fiascoes, dramatic swings of public opinion, and economic downturns. We even have fables about ants and grasshoppers to teach us about conserving food for the upcoming winter.

Conservatism, at its heart, is really about risk management.

Similarly, liberal views are often associated with youth, with idealism, with naivete. In the corporate world, we think of startups as being prototypically liberal -- in part because they're setting out to change the world in some way (and liberalism is traditionally associated with change), and in part because they have to go all-out in order to hit their scheduled funding milestones, which can justify cutting corners on software safety.

Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised.

To be sure, conservatives think that's what they're maximizing too. But their approach is... well, conservative. Flexibility and productivity are still motivators, but they are not the primary motivators. Safety always trumps other considerations, and performance also tends to rank very highly in the software-conservative's value system.

The crux of the disagreement between liberals and conservatives in the software world is this: how much focus should you put on safety? Not just compile-time type-safety, but also broader kinds of "idiot-proofing" for systems spanning more than one machine.

Let's characterize this core disagreement with some example statements that would be rated with much higher importance by conservatives than by liberals:

1. Software should aim to be bug free before it launches. (Banner claim: "Debugging Sucks!") Make sure your types and interfaces are all modeled, your tests are all written, and your system is fully specified before you launch. Or else be prepared for the worst!

2. Programmers should be protected from errors. Many language features are inherently error-prone and dangerous, and should be disallowed for all the code we write. We can get by without these features, and our code will be that much safer.

3. Programmers have difficulty learning new syntax. We should limit the number of languages used at our company, so that nobody has to learn a new syntax when a system goes down in the middle of the night on Christmas Eve. And we should never permit features that allow defining new syntax, nor changing the semantics of existing syntax. (Common examples: no operator overloading, and NO metaprogramming!)

4. Production code must be safety-checked by a compiler. Any code that cannot be statically checked should in general be avoided. In specific cases where it is strictly necessary, uses of it must be approved by a central committee. (Examples: eval, dynamic invocation, RTTI).

5. Data stores must adhere to a well-defined, published schema. Relational databases must be in third-normal form and adhere to a UML or equivalent schema definition. XML should have a DTD. NoSQL databases and name/value stores -- both of which should be avoided in general -- must have a separate physical schema that defines all permissible keys and their corresponding value types.
 
6. Public interfaces should be rigorously modeled. Data should never be stored in strings or untyped collections. All input and output entities should be thorougly and explicitly specified via statically-checkable, ideally object-oriented models.

7. Production systems should never have dangerous or risky back-doors. It should never be possible to connect to a live production system via a debugger, telnet shell, nor any other interface that allows the developer to manipulate the runtime operation of the code or data. The only ports into a production system should be read-only monitoring channels.

8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production -- no matter how teams may cry and wail that they need it to make forward progress. (I'm talkin' to you, FUSE).

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. Otherwise it might not be fast enough. Avoid using languages or DSLs or libraries that have a reputation for being slow.  Even if they're fast enough for your current purposes, the requirements (or callers) could change, and suddenly the software would be too slow!

Of course these examples are meant to be illustrative rather than comprehensive. And obviously not all of them may necessarily be espoused by everyone who self-identifies as a conservative. But barring minor exceptions, they are all very common Conservative viewpoints.

To decide whether a system or a technology is liberal or conservative, just think of a bunch of independent "safety checkboxes". If a majority of them are checked, then the system is conservative as a whole. The more that are checked, the more conservative it is.

By way of comparison, here are the Liberal versions of the nine examples above. It might help to think of Scooby-Doo characters. The examples above are all from Fred, and the examples below are from Shaggy.

1. Bugs are not a big deal. They happen anyway, no matter how hard you try to prevent them, and somehow life goes on. Good debuggers are awesome pieces of technology, and stepping through your code gives you insights you can't get any other way. Debugging and diagnosing are difficult arts, and every programmer should be competent with them. The Christmas Eve Outage scenario never, ever happens in practice -- that's what code freeze is for. Bugs are not a big deal! (This belief really may be the key dividing philosophy between Conservative and Liberal philosophies.)

2. Programmers are only newbies for a little while. The steady state for a programmer's career is being smart, knowledgeable, creative, resourceful and experienced. Putting a bunch of rules in place to protect newbies from doing harm (or being harmed) is incorrectly optimizing for the transient case instead of the steady state.

3. Programmers figure stuff out amazingly fast when their jobs depend on it. People learn to read sheet music, braille, sign language, and all sorts of other semiotic frameworks. Hell, even gorillas can apparently do all that. Programmers don't need protection from syntax. They just need documentation and a little slack time to read up on it.

4. Succinctness is power. Code should be kept small. Period. If your static checking tools can't reason about the code, then the checking needs to be made smarter (e.g. by incorporating runtime data) rather than making the code dumber.

5. Rigid schemas limit flexibility and slow down development. Lightweight/partial/optional schemas are a better tradeoff. Moreover, the schema is often not well-understood until a lot of data is collected and a lot of use cases are thorougly exercised. So the schema should follow the code rather than precede it.

6. Public interfaces should above all else be simple, backward-compatible, and future-compatible. Rigorous modeling is just guessing at how the interface will need to evolve. It makes both forward- and backward-compatibility almost impossible, resulting in interface churn and customer unhappiness. Public interfaces should always do the simplest thing that could possibly work, and grow only as needed.

7. System flexibility can mean the difference between you getting the customer (or contract) vs. your competitor nabbing it instead. Security and safety risks in runtime production systems can be mitigated and controlled by logging, monitoring and auditing. There are plenty of existence-proofs of large systems with root-access backdoors and shells (e.g. RDBMS, online game servers) whose risk is controlled while still giving them world-class runtime flexibility.

8. Companies should take risks, embrace progress, and fiercely resist ossification. It doesn't matter how big your business is: it must grow or die. If you want to stay competitive, you have to make a conscious, often painful effort to take risks. Which means you'll need good recovery techniques for the inevitable disasters. But you need those even if you don't take risks.  So take risks!

9. Premature optimization is the root of all evil. Get the code working first, focusing on correctness over performance, and on iterative prototyping over correctness. Only when your customers list latency as the top priority should you begin performing profiler-driven optimizations.

There you have it: Shaggy vs. Fred.

Just as in real-world politics, software liberals are viewed by conservatives as slovenly, undisciplined, naive, unprincipled, downright "bad" engineers. And liberals view conservatives as paranoid, fearmongering, self-defeating bureaucrats.

Once again, although I don't think the two camps will ever agree, I do think that mutual understanding of the underlying value systems may help the camps compromise.

Or at the very least, the conservative/liberal classification should help the two camps steer clear of each other. I think it is probably better to have a harmonious team of all-liberals or all-conservatives than a mixed team of constantly clashing ideologies. It's a lot like how vehicle-driving philosophies can differ regionally -- it's OK if everyone drives in some crazy way, as long as they ALL drive that way.

So Security Engineers are the most conservative, then, right?

Wrong! The reality here goes against intuition, and I mention it to show how poorly our intuition fares when it comes to interpolating software-political views from job descriptions.

Security engineers are deeply concerned with risk assessment and attack-surface management, so you might well guess that they would naturally tend towards software conservatism.

In practice, however, security engineers tend to be keenly aware of the tradeoffs between caution and progress, since they have to spend big parts of their day meeting with software teams who are often too busy (not to mention woefully underinformed) to spend a lot of time on security. Security engineers learn quickly to make well-informed and practical risk-management decisions, rather than conservatively always trying to be as safe as humanly possible.

Hence many security engineers are in fact software liberals. Some just swing that way.

Many of the security engineers at Google happen to be fans of Ruby -- both as an intrinsically secure language, and also as a nice, expressive language for writing auditing scripts and other security analysis tools. It wound up being fairly easy for me to get security sign-off for using Ruby in production for my first project at Google. In contrast, it was almost career-endingly difficult for me to get the same sign-off from our highly conservative systems programmers.

The reality is that almost any programming specialization is going to be divided into liberal and conservative camps. There are left- and right-wing versions of web developers, persistence engineers, protocol engineers, serving-system engineers, and most other sub-genres of programming.

I'm hard-pressed to think of any domains that tend to be mostly-liberal or mostly-conservative, with the sole exception of Site Reliability Engineering, which is sort of by definition a conservative role. For most of the other domains that initially came to mind -- for instance, data analysts, which at first I thought were uniformly liberal -- I've been able to think of specific teams or subdomains composed entirely of one or the other.

So in the end I think it comes down to personal preference. That's it. I don't think it's as domain-driven as much as it is personality-driven. Some people are just liberal, and some are just conservative, and that's how they are.

BIG FAT DISCLAIMER

Before I continue, I will now issue the important disclaimer that I am a hardcore software liberal, bordering on (but not quite) being a liberal extremist.

This fact, by and large, is what has driven me to pen many of my most infamous and controversial rants, including (among others) "Execution in the Kingdom of Nouns", "Portrait of a N00b", "Rhinos and Tigers", "Code's Worst Enemy", "Scheming is Believing", "Tour de Babel", "Dynamic Languages Strike Back", "Transformation", "Haskell Researchers Announce Discovery of Industry Programmer Who Gives a Shit", and many others besides.

Sure, I sometimes write about other stuff. My in-progress "Programmers View of the Universe" series is motivated by an entirely different bugbear that has nothing at all to do with software politics. My "Universal Design Pattern" article is about a technique that transcends software politics and can be applied with equal effectiveness in either a conservative or a liberal manner. And I've written about video games, Japanese anime and random other stuff.

But I've come to understand that liberalism underlies a tremendous amount of my thinking. Even when I'm writing about management, I see that I am a liberal manager rather than a conservative one. And despite being both relatively old and relatively wealthy, I am also a political liberal -- both socially and fiscally.

Nevertheless I am going to try to represent both sides fairly and accurately in this essay. You know, mostly. I think it's most important for you to buy in to the left/right distinction itself. I think it's far less important whether you happen to agree with my particular side.

I'll consider this essay a success if a sufficient number of you agree that the liberal/conservative distinction is valid for software engineering, and that my particular left/right classification of various technologies and philosophies below seems intuitively reasonable. I'm fine with declaring success if we disagree on a few small details, as long as we agree on the overall picture.

Soooo... static typing enthusiasts are conservative, right?

Why yes. Yes, they are. Static typing is unquestionably one of the key dividing software-political issues of our time. And static typing is a hallmark of the conservative world-view.

In the conservative view, static typing (whether explicit or inferred) is taken on faith as an absolute necessity for modern software engineering. It is not something that one questions. It is a non-issue: a cornerstone of what constitutes the very definition of Acceptable Engineering Practice.

In the liberal's view, static typing is analogous to Security Theater. It exists solely to make people feel safe. People (and airports) have proven time and again that you can be just as statistically secure without it. But some people need it in order to feel "safe enough".

That's a pretty big difference of opinion -- one I'm sure you can relate to, regardless of how you feel about it.

I'm not going to try to defend my view here, since that's what all those old blog posts were for. If I haven't convinced you by now, then there's not much point in continuing to try. I respect your opinion. Well, now. And I hope you now have a little better understanding of mine.

I should, however, mention that there is an unrelated (i.e. politically-neutral) point on which both camps agree: namely, that static types yield better toolchain support. This is undeniably true today, and I have made it my life's work to ensure that it is not true tomorrow.

I have spent the last four years championing an initiative within Google called the "Grok Project", one that will at some point burst beyond our big walled garden and into your world. The project's sole purpose in life is to bring toolchain feature parity to all languages, all clients, all build systems, and all platforms.

(Some technical details follow; feel free to skip to the next section heading...)

My project is accomplishing this lofty and almost insanely ambitious goal through the (A) normative, language-neutral, cross-language definitions of, and (B) subsequent standardization of, several distinct parts of the toolchain: (I) compiler and interpreter Intermediate Representations and metadata, (II) editor-client-to-server protocols, (III) source code indexing, analysis and query languages, and (IV) fine-grained dependency specifications at the level of build systems, source files, and code symbols.

OK, that's not the whole picture. But it's well over half of it.

Grok is not what you would call a "small" project. I will be working on it for quite some time to come. The project has gone through several distinct lifecycle phases in its four years, from "VC funding" to "acceptance" to "cautious enthusiasm" to "OMG all these internal and even external projects now depend critically on us." Our team has recently doubled in size, from six engineers to twelve. Every year -- every quarter -- we gain momentum, and our code index grows richer.

Grok is not a confidential project. But we have not yet talked openly about it, not much, not yet, because we don't want people to get over-excited prematurely. There is a lot of work and a lot of dogfooding left to do before we can start thinking about the process for opening it up.

For purposes of this essay, I'll assert that at some point in the next decade or so, static types will not be a prerequisite for world-class toolchain support.

I think people will still argue heatedly about type systems, and conservatives may never be able to agree amongst themselves as to which type system approach is best for modeling program behavior. But at least I will have helped that discussion be ONLY about representations. The quality of the corresponding developer tools should no longer be a factor in the discussions.

Dividing up the Space

I'm going to go through and toss a bunch of random technologies, patterns, designs and disciplines each into one of six buckets: "apolitical", "conservative", "centrist", "liberal" buckets, plus two buckets that start Centrist and head Left or Right in the presence of overuse. One bucket per thingy. Hey, it's not an exact science. But it should help set the rough foundation for the more detailed use cases below.

Non-political Stuff: Algorithms, data structures, concrete mathematics, complexity analysis, information theory, type theory, computation theory, and so on. Basically all CS theory. These disciplines occasionally inspire tempest-in-a-teapot butthurtedness in academia, but when it happens, it's just similar fish in too small a tank biting on each other. It's to be expected. Overall, these essentially mathematical disciplines are timeless, and they are all equally applicable to both the Liberal and Conservative programming worlds.  Yes, even type theory.

Conservative Stuff: Provably sound type systems. Mandatory static type annotations. Nonpublic symbol visibility modifiers (private/protected/friend/etc.). Strict, comprehensive schemas. all-warnings-are-errors. Generics and templates. Avoidance of DSLs (XPath, regexps) in favor of explicit DOM manipulation and hand-rolled state machines.  Build dependency restrictions.  Forced API deprecation and retirement.  No type equivalence (i.e. no automatic conversions) for numeric types.  Checked exceptions.  Single-pass compilers.  Software Transactional Memory.  Type-based function overloading.  Explicit configuration in preference to convention. Pure-functional data structures.  Any kind of programming with the word "Calculus" in it.

Centrist (or flat-out Neutral) Stuff: Unit testing. Documentation. Lambdas. Threads. Actors.  Callbacks.  Exceptions.  Continuations and CPS.  Byte-compilation.  Just-in-time compilation.  Expression-only languages (no statements).  Multimethods. Declarative data structures.  Literal syntax for data structures.  Type dispatch.

Liberal Stuff: Eval. Metaprogramming. Dynamic scoping. all-errors-are-warnings. Reflection and dynamic invocation. RTTI. The C preprocessor. Lisp macros. Domain-specific languages (for the most part). Optional parameters. Extensible syntax. Downcasting.  Auto-casting.  reinterpret_cast.  Automatic stringification.  Automatic type conversions across dissimilar types.  Nil/null as an overloaded semantic value (empty list, empty string, value-not-present).  Debuggers.  Bit fields.  Implicit conversion operators (e.g. Scala's implicits).  Sixty-pass compilers.  Whole-namespace imports.  Thread-local variables.  Value dispatch.  Arity-based function overloading.  Mixed-type collections.  API compatibility modes.  Advice and AOP.  Convention in preference to explicit configuration.

Centrist Stuff that Becomes Conservative If Taken Far Enough: Type modeling. Relational modeling. Object modeling. Interface modeling. Functional (i.e., side-effect-free) programming.

Centrist Stuff that Becomes Liberal if Taken Far Enough: Dynamic class loading and dynamic code loading. Virtual method dispatch. Buffer-oriented programming.

Woah, that exercise was surprisingly fun! It's far from complete, but hopefully you get the idea.

Some natural themes arise here:

 -- implicit is generally liberal; explicit is generally conservative.

 -- performance-oriented is generally conservative; late-optimized is generally liberal.

 -- compile-time binding is generally conservative; runtime/late binding is generally liberal.

 -- concurrency and parallelism in general seem to be politically charged topics, but the disagreement is orthogonal to the liberal/conservative camps.

I'd love to keep going with the classification. But I'll stop here, since we've got higher-level stuff to discuss.

Examples and Case Studies

I'll walk you through a bunch of examples to show you how just widespread and deep-rooted this political phenomenon is.

Example 1: Languages

Here are some very rough categorizations. Note that within each language camp there are typically liberal and conservative sub-camps. But as a whole, language usage tends to be dominated by what the language makes possible (and easy), so the culture tends to follow the features.

This list is just a few representative examples to give you the flavor. I'm only listing general-purpose languages here, since DSLs and query languages are typically feature-restricted enough to be hard to categorize.

Assembly language: Batshit liberal.

Perl, Ruby, PHP, shell-script: Extremist liberal.

JavaScript, Visual Basic, Lua: Hardcore liberal.

Python, Common Lisp, Smalltalk/Squeak: Liberal.

C, Objective-C, Scheme: Moderate-liberal.

C++, Java, C#, D, Go: Moderate-conservative.

Clojure, Erlang, Pascal: Conservative.

Scala, Ada, OCaml, Eiffel: Hardcore conservative.

Haskell, SML: Extremist conservative.

These are my own categorizations based on my own personal experiences with these languages and their respective communities. Your mileage may vary. However, I'd be quite surprised if you chose to move any of these languages more than a step or two away from where I've positioned it.

One thing that jumps out is that a language doesn't have to be statically-typed or even strongly-typed in order to be conservative overall. More on that in a bit.

The next thing you might notice from the list is that the liberal and moderate languages are all pretty popular, and that popularity declines sharply as languages head into conservative territory.

I think this has a simple explanation: It's possible to write in a liberal language with a conservative accent, but it's very hard (and worse, discouraged) to write in a conservative language with a liberal accent.

For instance, it's straightforward to write JavaScript code in a way that eschews reflection, eval, most automatic type casting, prototype inheritance, and other dynamic features. You can write JavaScript that plods along as unadventurously as, say, Pascal. It doesn't have all the static type annotations, but you can replace them with assertions and unit tests and stereotypically stolid code organization.

But if you try writing your Haskell code with a bunch of dynamic features, well, you're in for a LOT of work. Haskell enthusiasts have managed to implement dynamic code loading and a ton of other ostensibly dynamic features, but it was only through herculean effort.

What's more, if you write your liberal-language code in a conservative way, people will just look at it and say: "Well, it's kinda boring, and you could have saved a lot of coding by using some dynamic features. But I guess it gets the job done. LGTM."

Whereas if you write your conservative-language code in a liberal way, you run the risk of being ostracized by your local language community, because... why are you doing all that dangerous dynamic stuff in the first place? I'll explore this cultural phenomenon further when I talk about Clojure below.

The last big, interesting observation from the list is that a lot of the most popular languages out there are only moderately conservative -- even if they think of themselves as quite conservative compared to their ultra-dynamic cousins.

I've said it before, and it bears repeating here: the reason C++, C# and Java have been particularly successful in the marketplace is that -- just like effective politicians -- they know how to play both sides.

C++ allows liberal-biased programmers to program in straight C, and it allows conservative-biased programmers to layer in arbitrary amounts of static type modeling, depending on how much work they want to expend in order to feel secure. Java?  Pretty much the same story.

Playing to both the fast-and-loose and lock-your-doors mindsets has proven to be a key ingredient to market success.  Also marketing, but it helps a LOT to be viewed as philosophically friendly by both the liberal and conservative camps.

There is a new crop of languages on the horizon (for instance, Google's Dart language, but also new specs for EcmaScript) that are deliberately courting the centrist crowd -- and also delicately playing to grab both the liberals and conservatives -- by offering optional static types. In principle this is a sound idea. In practice I think it will come down to whether the marketing is any good.  Which it probably won't be.

Language designers always seem to underestimate the importance of marketing!

Example 2: Tech corporations

Just for fun, let's contrast four similar-ish tech companies in their software-political outlook.

1) Facebook -- Diagnosis: Extremist Liberal. Despite their scale, they are still acting like a startup, and so far they've been getting away with it. They use primarily C++ and PHP, and they're prone to bragging about how their code calls back and forth from PHP to C++ and back into PHP, presumably bottoming out somewhere. Their datastore is memcached: just name-value pairs.  No schema. They dump the data and logs into a backend Hive store and run Hadoop mapreduces for offline data analysis.  They still hold all-night hackathons every other week or so, which will remain feasible for them as long as the majority of their programmers are very young males (as was the case last time I toured there) and their stock continues to promise great riches (as was not so much the case last I checked.)  As a company they are tightly knit and strongly biased for action, placing a high value on the ability of individual programmers to launch features to their website with little to no bureaucracy or overhead.  This is pretty remarkable for a company as big as they are, with as many users as they have.  Conservatives no doubt regard them with something between horror and contempt.  But Facebook is proving that programmers of any world-view can get a hell of a lot accomplished when they gang up on a problem.

2) Amazon.com -- Diagnosis: Liberal. Which is surprising, given how long they've been in business, how much money is at stake, how mature their Operations division is, and how financially conservative they are. But "Liberal" is actually quite a retreat compared to their early days. Back in 1998-1999 they were almost exactly like Facebook is today, with the sole exception that they put everything in relational databases and did a ton of up-front relational data modeling.  Well, except in Customer Service Apps, where we used a name/value store just to be flexible enough to keep up with the mad chaotic scramble of the business launches.  All part of my multi-decade indoctrination as a Liberal.  In any case, despite many corporate improvements with respect to work-life balance (which happened after several stock plunges and years of significant double-digit turnover in engineering), Amazon has retained its liberal, startup-like engineering core values.  Every team owns their own data and makes their own decisions, more or less like independent business units.  Amazon still launches and executes faster than just about anyone else out there, because they're still willing to take real risks (incurring occasional huge outages), and to make hard decisions in favor of launching early and often.  Above all else, Amazon has proven conclusively that after fifteen years, they can still innovate like nobody else.  They've still got it.

3) Google -- Diagnosis: Conservative. They began life as slightly liberal and have grown more conservative ever since. Google was only software-liberal in the very very early days, back when the search engine itself was written in Python. As they grew, they quickly acquired a software conservatism driven entirely by the engineers themselves.  Manifestos were written about the dangers of using multiple languages, and strict style guides were put in place to severely limit "risky" or "hard to read" language features of the few languages they did allow.  Google's JavaScript code is written in an extremely conservative style with extensive static type annotations, and eval is forbidden.  The Python style guide forbids metaprogramming and other dynamic features, which makes their Python look a lot like untyped Java.  And they have severely limited the use of many C++ language features, with C++11 support rolling out literally one feature every few weeks.  (There are over five hundred new features in C++11.)  In internal surveys, Google engineers commonly cite bureaucracy, churn and complexity as core obstacles to feature advancement and rapid launches.  Google has made serious attempts on several occasions to reduce this bureacracy, but they always get pushback from -- surprise -- the engineers themselves, who have grown so staunchly conservative that they actively (and even more often, passively) resist the introduction of more flexible stacks and technologies.  Most of the major technological shifts within Google over the past half-decade have been overtly conservative.  For a liberal like me, it has been a very sad process to observe.  But at least I've found myself a niche that's widely regarded (by both camps) as valuable, and within my own org we can still be pretty liberal and get away with it.

4) Microsoft -- Diagnosis: Batshit Conservative. Microsoft has two geese that lay golden eggs: Office and Windows. Microsoft has been reduced to a commercial farmer protecting the geese from all incursions.  The golden eggs still have value, because customers are locked into the platform by the cost-ineffectiveness of retraining their fleets.  But Microsoft can no longer innovate in Office or Windows precisely because of those corporate fleet retraining costs.  Their OEMs are stretched as thin as they can go.  Apple is dominating the handheld markets, and Microsoft is actively stifling their own innovation in Windows Phone because they're afraid it will cannibalize their core Windows business.  Microsoft has not had a successful product-level innovation in fifteen, maybe twenty years.  All of their successful products have been copies of competitors' products:  IE, XBox, C#, .NET, Bing, Windows Phone, and so on ad infinitum. All great implementations of someone else's ideas. Microsoft's playbook is to embrace, extend, and leverage their brand to crush the competition -- or at least it was, until the goverment put an end to that circa 2002.  Now the company genuinely doesn't know what the fuck to do with themselves, and what's more, instead of Bill Gates they now have a lunatic in charge.  Employees are leaving in droves, all citing the same internal "existential crisis" and unbearable corporate politics caused by competing business units actively sabotaging one another.  Microsoft has turned into a caricature of right-wing corporatism: sitting on their front porch with a shotgun cursing at passers-by, waiting for their government bribes to give them another few years of subsidies and shelters while they wait to die.  I've personally chatted with close to four hundred current and ex-Microsoft employees over the past seven years.  Oh, the stories I could tell you... someday, maybe.

5) Bonus company: Apple. Diagnosis: no idea, but they're so good at marketing that it's almost irrelevant. Would love to have more insight into their internal software culture, though.  Any takers?  Throwaway accounts?  AMA?

OK, that was a fun exercise too. But we need to move on! Almost done now.

Specific Case Study: The Clojure Language

I've been meaning to follow up on Clojure for a while now. Over a year, at least. But until recently I didn't have the conceptual tools to explain what I wanted to say about it.

Now I do!

Clojure is a new-ish Lisp dialect that runs on the JVM and .NET, and I was honored to write the Foreward to "The Joy of Clojure" a while back. For a few years I had been really excited to start learning Clojure, and my initial experiences with it were quite positive.

However, I eventually learned that the Clojure community is extremely conservative. That is is pretty unusual for a Lisp dialect. Lisp is widely regarded as one of the most liberal language families in existence. And Clojure has the superficial appearance of being a laissez-faire kind of language. It is quite expressive, including a -- ahem -- liberal dose of new syntax. And it eschews static type annotations and strong type modeling in favor of a small set of highly regular, composable data types and operations -- not unlike, say, Scheme or Python.

But the resemblance to a liberal language ends there. Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types (lots of puns today!) who happen to recognize the benefits of Lisp's tree syntax. So under its expressive covers, everything about Clojure is strongly conservative, with a core overriding bias towards protecting programmers from mistakes.

And the community follows suit. At a Clojure conference last year (or was it two years ago? time flies so fast these days...), there was a key presenter doing a talk on how Macros were basically harmful and should be avoided in modern Clojure code.

I trust that if you know anything about Lisp, your blood is basically boiling at this point. I know mine was.

But his argument is perfectly valid from the classic software-conservative's viewpoint. Macros allow you to invent domain-specific language abstractions. Those require documentation in order for users to figure out what they do, and what they mean. That means you can know Clojure and not really know enough to read someone's Clojure code without some documentation handy. Which is sort of the definition of a newbie. And there you have it. In a very real sense, conservatives fear being turned -- in the blink of an eye -- from masters into newbies by the application of macros.

It's sort of scary if you have a lot of your personal identity invested in knowing some shit. And wouldn't you know it, real-world politics conservatives are shown in study after study to be "staunch" in sticking to their world views rather than compromising. That means they have a lot of identity tied up in those views.

So while I liked a lot of what I saw in Clojure, as a hardcore software liberal I was inevitably and inexorably driven away from the language. And that's good for me, and it's good for Clojure. I mean, why should they compromise?

I think that my conceptual framework gives us an "out" -- a way to avoid being emotional about these subjects. Casting the problem as a clash between Liberalism and Conservsatism gives us the ultimate ticket for "agreeing to disagree".

Hopefully it will also help language designers and communities do a better job of targeted marketing. Right now just about every language out there makes a claim along the lines of "This language is the best choice for everybody!" But now we know that is very unlikely to be true -- or if it is, we can at least be assured that they're centrists, and they run the risk of being equally distasteful to everybody.

In the conservative/liberal framework, language designers can make more accurate, less bait-and-switchy claims; for instance: "Haskell is the best choice for every radical extremist conservative programmer!"

Well, we can work on the wording. But you get the idea.

Wrap-Up

I was thinking of going through a bunch more examples and stuff, but I see that I'm on my third (Editor's Note:  fourth) glass of wine, which means my typing is about to give out any minute.

So let's wrap it up!

There's one kinda key point I wanted to get across, but didn't see a good place for it. That point is this: please do not be alarmed that I am calling you a (software) Conservative.

I worry that politically left-leaning programmers will hear the term "conservative" and will immediately associate it with all of the... uh, politically-charged connotations associated with far right-wing conservatism in the United States political arena today. You know, racism, sexism, religious fundamentalism, homophobia, warmongering, bear-shooting, that kind of thing.

I'm not saying they're bad, at least not in this essay. I'm just saying nobody in their right mind wants to be associated even remotely with those embarrassing wingnuts. See what fine-grained, nuanced distinctions three (Editor's Note: four) glasses of wine can produce? But I'm not saying their views are bad. No. Not here.  I'm just observing that they're heavily politically charged viewpoints which have, for better or worse, recently come to be associated with the term "conservatism" in US politics.

So please do me a favor and try to dissociate those specific agendas and real-world political viewpoints from the generic term "Conservative", which here really just means "risk averse".

It's perfectly OK, and normal, to be a programming conservative. You don't have to shoot any bears. I would actually like to see the terms "liberal" and "conservative" to become badges of honor in the programming world. People should stand behind their beliefs. I mean, we do already, I think, so it shouldn't be much of a stretch to allow our beliefs to be given convenient labels.

Ah, me. I can see the Euphemism Treadmill rearing its ugly head already. We'll see.

Anyway, tell me what you think! I welcome any and all viewpoints and comments. Even from bears!

Special thanks to Writer's Block Syrah for reviewing this post for career suicide.

(Special Note to my fellow Googlers:  Yes, I meant to post this externally.  BOTH times.  No, I am not the Mouth of Sauron.)
1033
700
Nate Finch's profile photoJuraj Kirchheim's profile photoThiago Hirai's profile photoChris Gonnerman's profile photo
243 comments
Cade Roux
+
9
10
9
 
Not sure about all this. Risk aversion doesn't explain fadism and liberal language adherents seeming predilection for TDD. Will have to think on this.
 
Dynamic typing has been shown through research to reduce maintainability compared to static typing. Maybe tooling can fix that, but .... I doubt it, so until then I stick with static typing.

Overall, I think this distinction is utterly useless, except possibly for the purpose of provoking those that don't fall in the same camp as you (seriously, who would want to be called conservative?). In any case, trying to match this with real world political views is also futile - as a Norwegian I can say that I'm right winged, but from a US point of view, I'm batshit leftist extreme. In your software definition, I'm probably moderate. Or extremist conservative. Or liberal. Are there bonus points for being pragmatic?

If anything, your post seems to suggest that there is one tool (or one type of tool) that suits all usecases. Didn't you learn this in school? Right tool for the job! And most programmers outside of Silicon Valley probably ends up not actually changing that job all that often.
 
Not sure where I stand on the Liberal-Conservative spectrum, as I'm using JavaScript (Hardcore liberal) and C# (Moderate-conservative) to build a platform that allows anyone (i.e. business people not developers) to create their own non-trivial, web-based business applications.
 
It was a pleasure to read +Steve Yegge. I think you've got quite a fascinating analysis here and the left-right spectrum is certainly an interesting way of framing things. I really do appreciate you being willing to share this with us - glad to hear you're not the Mouth of Sauron and that this was intentional too. I'm guessing you typed this up in some word processor and then copied/pasted into G+ - maybe you'd be able to do some internal advocating for a G+ autosave feature :) Anyway, great job on the essay. 
 
Wonderfull essay, interesting analysis, right on the money I think. I will now go look for somebody's head to slap :-)
 
By your measure Google's Site Reliability Engineering is the GOP of software engineering organizations.
 
Yahoo! is quite liberal as well, in spite of hanging around all these years.
 
To be completely pedantic, green eggs and ham got along famously, except with Sam I Am.
 
+Lars Ivar Igesund I don't think he is referring to tooling, but rather to preference. Or in the case where two opposing views could both be chosen, which one you someone would likely choose based on their level of acceptable risk. Some developers are extremely risk averse and hate languages like Python and Javascript, even though they sometimes use them(whining all the way might I add).

I am curious about the study you mention. Do you have a link to it?

I've generally felt that static typing sometimes forces you to do weird things in exceptional situations, where you have to use generics and introspection coupled with terribly complicated code to do things that are much simpler in dynamic languages. I agree that there are serious problems with maintaining dynamic code, having myself maintained enterprise scale Python code, but much of the trouble I experienced was more down to other problems like inconsistent code or bad designs.
 
A lot of stuff, it might take a while to let everything sink in, but nonetheless - as always - really interesting. I do believe that being flexible, adaptable and have the ability to cope with different nuances is what makes a programmer smarter, so maybe we should be less afraid of changing our views on software engineering than we are of changing our political stands.
 
+jingbin wang: It's been such a long time since +Steve Yegge's last post, I guess it just had to be this long. :)

Great write-up Steve, I enjoyed reading it. And to add a data point for your record, I've embarked on the Clojure path (yes, I've been imbibing +Rich Hickey's Kool Aid), and in real life I'm a conservative as well (in the risk averse sense that you describe).
 
TL;DR but before it started I knew it was going to be another typing rant. I think you continue to present a false dichotomy on typing, as well as missing some of the reasons people desire it.

 In particular, I like typing as machine readable documentation, that makes IDEs simpler and more accurate in code navigation and refactoring. Dart in particular shows this false dichotomy really well, but having a type system for human and machine readable docs,  making the IDE experience far more pleasant, but which can be turned on or off. Unsound, untyped, programs can still run. Yes, dynamic languages can have nice IDEs too (Smalltalk), but they are harder to engineer.

 In terms of optimization, typing is a must for many types of hard real time programming. You can bet that the Mars Curiosity rover isn't using a garbage collected dynamic language. Nor are the inner rendering loops of most mobile games or console games. (Lua is another story when it comes to actual game logic) 

Lots of bold claims have been made for Javascript JITs for example over the years, include a lot of hype about tracing JITs, but the reality is, Javascript still doesn't even come close to native performance, and it's hideously slow on mobile platforms in comparisons, with basic, idiomatic programming (e.g. dictionaries with fields)  having terrible numeric performance. All this has actually served to threaten the Web with a native-takeover because we don't have a fast web language CPU and memory efficient on these devices.

I don't think that Tim Sweeney or John Carmack are prematurely optimizing when they decide to write a game engine(rendering) in C++, because experience has taught them that it is highly unlikely they'll be able to optimize a dynamic language implementation later to a satisfactory level.

I think many people use a mix of languages depending on the context. I certainly wouldn't write a web service in C++, nor would I write a 3D game in BASIC. I wouldn't use anything but Perl to masage text files, and I'd use R for data analysis. 
 
+Tjaart Blignaut, +Christian Lynbech: To start with, I'm not saying that static typing is the holy grail and certainly not that it makes anything easier, just that code written with static typing tends to be easier to maintain than similar code written with dynamic typing.

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.

Tjaart; Mr Yegge may not refer to tooling, although I think he did, but I was ;) If the editor every step of the way can tell you exactly what a given variable is at a given time, then and only then (assuming all editors used for the code include the functionality) maintainability may be possible to uphold, but since the language is in fact dynamic, and susceptible to semantic changes at runtime, it seems to me to be a hard problem.
 
+Lars Ivar Igesund I ask because the claim certainly did not jive with my own experience, and this is one of those areas where it is incredible difficult to get hard unbiased data.

In my experience, there is nothing better you can do for your software than to keep it short, and dynamic languages tend to be more expressive and hence enables programs to be more concise.

The operative word here is "enable". Better tools does not automatically give you better results. As it says in the Real Programmers article: real programmers code in Fortran and can do so in any language.

To get an example of how easy it is to get a skewed result, consider for instance Kenn Andersons epic analysis of the Fannkuch benchmark: http://openmap.bbn.com/~kanderso/performance/postscript/fannkuch.ps

Having seen far too many lisp-is-interpreted/garbage-collection-is-slow/C-is-fast Obviously Correct(TM) claims over the years, I easily get suspicious, especially when it comes to something as fuzzy as maintainability.
 
+F Lengyel  I guess that Steve may regret the choice of naming, although he tried to warn people of associating software conservatism with all the bad connotations that political conservatism has. In Steves post, conservative means risk averse and static typing is touted as a way to prevent programmers form making certain kinds of mistakes. The great appeal of static typing is, I think, that you can specify stuff in advance (statically, before any code is executed).

I fully agree that static typing will prevent some errors, I maintain however that the class of errors that they prevent are too limited to be of a real value (at least when we talking normal type systems like C and Java). What will hold up your development is not trying to add a number to string but when an index is one of or a pointer mysteriously became NULL. Yes, I know there are more subtle examples that a static type system will address, but one need also to factor in all the effort (both mentally and physically) that the programmer will spend maintaining types in a lot of places where it doesn't really matter all that much.

I fully believe that you have spend serious time hunting bugs in a dynamic language programs but I can assure that I have also seen very accomplished programmers spend equally silly amounts of time hunting bugs in statically typed language programs. 
 
Are dynamic languages really more expressive? Statically typed functional languages tend to be very concise (the infamous quicksort in 1 line of code example). It seems to me that it is not the types which make the language expressive or not, but the power of the language primitives. As you abstract the problem to higher and higher levels, you get shorter and shorter code. 

The famous "Why Functional Programming Matters" paper works whether the underlying language is typed or not.
 
This is the best attempt I have seen at creating (and explaining) a DSL for programmer core values — but it will of course still spur an unending list of very verbose conservative agitation, attempting to give equal marketing for all political opinions your preferences (and mine, FWIW) don't hold in favour.

Thank you for establishing this reusable terse nomenclature. I whole-heartedly agree people ought to be proud of their Vulcan conservatisms, or code monkey liberalisms, rather than trying to type cast all the others by flinging propaganda at them.
 
+Christian Lynbech Of course short and concise helps, but short isn't a golden grail either as a confuscation competition will show you :) There will be other things at play, such as the lifetime of the program. The shorter timespan a program is to be maintained, the less need there is for maintainability traits. The more programmers are to involved, the more maintainability traits you need, in the vein that +Ray Cromwell says it - static typing is a self-documenting feature, and I think there is little that can trump such features (assuming they are succinct enough). Also, the larger the program is (assuming it needs to be large), the more maintainability traits it needs. I've worked a lot with things that needs to be certified, and since that in itself is expensive, this is software that must live long, and unfortunately it must also often be complex since it is to solve complex tasks.

For what its worth, my background includes experience with mostly Java, Python, C++ and D. If I were to put those languages on a 2D scale (disregarding other issues like available libraries and toolchains) of usability/conciseness and maintainability, then D would trump the others in total, and Python would end at the bottom as it isn't much more concise than D, and much harder to maintain.

I totally agree that maintainability is vague, but neither dynamically typed languages nor statically typed languages are new inventions, and so I think that when people think that something helps maintainability (don't ask the common web developer, or the iOS developer, they haven't made anything with a long lifetime, and may not ever), then that is due to quite the collective experience rather than a whim.
 
+Christian Lynbech The real issue is not just catching simple errors, but navigating large codebases. At a company like Google, it's easy to get into a code base that has thousands of files. The types help tremendously as basic documentation and navigation.  And for performance critical applications (games, embedded processing, DSP, etc) there are big benefits to absolute determinism over memory layout, type used, etc.  If you imagine that the world only has websites and enterprisey type apps, then it's a moot argument, but we forget that's a huge amount of code out there running in our cars, in our radios, microwave ovens, etc
 
+Lars Ivar Igesund I have to agree with +Christian Lynbech . I'd imagine it at least difficult to measure maintainability. I would have to know the methods used by the study to be able to comment on it at all, but I can see where problems may come in.

Sticking with static typing in my opinion is a very one dimensional, and dare I say conservative approach. Dynamic languages can reduce development time drastically, and there is much more space to innovate easily, without having to try and conform to the typing system.

I feel that I have spent too much time wrestling with typing systems while trying to get an abstract idea to work. When my Python knowledge grew I had an aha moment when I felt that I could do almost anything complex, without having to have deep knowledge about a typing system. It's a great feeling.
 
+Lars Ivar Igesund I remain very sceptical of the collective experience. I think there is a lot of fashion in programming language choice. Especially in a corporate setting, in my experience, to keep doing what (we perceive) everybody else is doing. Nobody has ever been fired for buying IBM (as it was orginally) and programming is hard enough as it is; psychology of organisations means that one normally starts shooting at the most odd and controversial aspects first.
 
The problem is that getting to know a language well enough to truly understand what works and don't, is really hard work. This is not something you can do over a weekend with however well-meaning a guide in your hand. Hence, people will readily discount what they do not really know, often based on the same myths going around in circles. Despite Lisp being the second oldest PL(family), there are still a surprising number of people who think that it is slow and interpreted, neither of which has been true for something like 4 decades.
 
I know I am liberal. But somehow I would like to become conservative programmer. Somehow It just seems a better camp.

But when last time I have tried it, I have been passing insane amounts of function pointer arguments in C++ ...

And of course, I can't wait for that "Grok Project" to go public.
 
Now that this is slowly turning into a rant, I might as well continue.

I think that people are overly obsessed with popularity numbers of PLs, contributing the success of rockstars of a PL to some inherent quality in said language. If X million programmers use Java, Java must be really really good at what it does, th thinking seems to be.

This underestimates, I think, the role that chance generally plays in language popularity. I think that if the big push for Java had come a couple of years earlier or later, it would have joined the long of OO language experiments in those vast fields of oblivion. As it happened, Java came out at the exact right time of a web explosion and people flocked to this as the bearer of the next wave of more sophisticated web services. As this also happened at the height of the millenium bubble, meant that corporations went onboard as well and now Java has established itself as the new COBOL: the stuff you essentially choose beacuse everybody else is making the same choice.
 
+Ray Cromwell It is probably lack of experience, but I am not well aquainted with how static typing helps navigate big codebases.

One thing that is difficult for non-lisp programmers to fully appreciate is the immense power one gets gets from having an interactive programming environment (which is not exactly the same as dynamic typing, I know). This allows you not just to try out individual contructs against an execution of the program, but also allows you to actively query it for information.

While I am sure that accomplished IDEs will be able to infer a lot from the type information in the source files, I would not expect it to have for instance the equivalent of Emacs' appropos-value which allows you to find which variables currently hold a particular value.
 
Excellent writeup. I've thought along the same line about operations vs. development.

Now, once more with Freudian concepts!
 
REPLs are not the domain of dynamic programming languages a lone. ELisp, and Smalltalk are 'image based' environments, and yes, they do offer some advantages, but they also offer disadvantages. In particular, looking up current values is possible in IBEs because you are banging on a semi-persistent heap. 

However, IDEs like IntelliJ IDEA have operations like "Analyze Dataflow to Here", which can actually tell you every possible value a given variable can have, by statically analyzing the entire codebase, and tracing the dataflow to the memory. You get both literal values and expressions. 

Imagine however you are a new Google employee. You are told to work on a project that has maybe  1 million lines of code from transitive dependencies of which there's probably dozens of different people working on it. If you have a language where the code can be indexed like a search engine for links between things, they you can navigate the code base as if everything were hyperlinked. 

Statically typed languages make such indexing easier, but more importantly, correct. For example, a given method foo() can be analyzed to find all callers of that method. This is not so straightforward in a language like Javascript for example, you'll get lots of false positives and false negatives.
 
Thank you for this post, really a lot to think about.
 
+Tjaart Blignaut As +Ray Cromwell also says in this thread, static typing is not what makes or breaks your productivity. The sad state of affairs is that a lot of statically typed languages (C++ and Java included) have features that are hard to use, and lack features that would improve productivity. D has such features, and is a statically typed (and compiled) language that looks a lot like Java and C#, but that is incredibly productive. Go is similar in that respect, but not with a syntax that I like all that much.

So, productivity and maintainability are orthogonal traits. If your maintainance is mainly about writing new code, then I can see that static typing don't help much, but if maintaince is about figuring out why something written 2 or 5 or 10 years ago don't work, then it does help.

Maintainability is helped if you can easily see what type something is (even in statically typed language the programmer can bungle this by choice of style, but that is a different matter), and easily find its methods. With Python, a function call could change that definition, and the object that is returned to you doesn't necessarily do the same anymore (and if this is not documented, how are you to ever know?).

And yes, collective experience is a bit dubious, but still, I claim that most experienced programmers aren't really entrenched in some C++-fanboy reality, only the vocal ones are. Most programmers are pragmatic, and most experienced programmers have used a multitude of languages over the years. They do know the difference of the languages that they use. Where I am now, I will be the youngest programmer (and I'm 34) when the current youngest moves to Google during the next months. The average is someplace (possibly well) above 40.
 
+Lars Ivar Igesund I agree that programmers "do know the difference of the languages that they use" but the point was that it is really hard to really know much about something you do not use. You need to know lisp pretty well in order to appreciate the power of metaprogramming that it supports. When looking at it from the outsidfe it is all too easy to think: "what is the big deal about that? I can easily simulate that doing like this..." which leads us straight to Greenspuns 10. rule of programming.

People are easily fooled by the Church-Turing thesis. That all PLs are mathematically equivalent does not mean that there are not real differences in the experienced productivity in reaching the goal.

In this, however, computer programming is much more forgiving than say aeroplane contruction. Gravity is a hard and unforgiving master whereas even the biggest mess of a program can gradually be hammered into a sort of submission by throwing manhours at it.
 
depends what sort of "liberal" you mean if your not a serious wonk you should not start trying to apply fuzzy ill defined political anologies to techology.

Thi is the same falicy that techies who have less political nous that Sarah Palin try to aply SCS to parlimetry procedures insead of you know reading Citrine or Roberts
 
+Christian Lynbech Of course, but I'm claiming that people with decades of experience have gotten to know a good spread of languages. If you have experience with static typing in Java, then you can normally infer that static typing will do much the same in C++. Likewise, if you've experienced the lack if static typing in Python, then you can infer that you'll have the same or similar issues in Ruby.

The actual choice of language is down to part company regulation and available libraries and other things, and part a conscious choice of technology. I highly doubt that a company that is serious about what it do, will make this choice entirely because their programmers like a particular language - if that was true, I don't understand how C++ ever became popular ;) - I certainly haven't experienced such "uninformed" choices.
 
+Lars Ivar Igesund I wonder where the idea of 'maintenance' falls on the lib/con spectrum?  It seems, almost by definition, to be a conservative concern, but the definition of 'maintenance' may be different to different parties.
 
Sometimes the right metaphor helps to illuminate ideas. This is not one of those times. Using highly emotional imagery of liberal vs conservatives in an election year will shut down readers.

Yet this is a great way to get people to read your post and use G+. Success there.:)
 
+Michael Kimsal I think the lib/con spectrum as presented here is useless. I agree though that according to the above definitions, maintainance is probably conservative. In my eyes, maintainability is about reducing costs, while keeping quality, over time.
 
+Paul Waldschmidt I am very liberal, and I disagree with your  political assessment. There is no strong opposition between liberals and conservatives in the U.S.  The difference between the two are very slight, but some leaders want us to focus on the differences. So we end up wit caricatures of liberals and conservatives. The reality is that both sides love their country, want the best for their kids, and want to preserve liberty. This is not the place to continue this conversation, but if you wish to continue it, ping me :) 
 
+Lars Ivar Igesund "If you have experience with static typing in Java, then you can normally infer that static typing will do much the same in C++. Likewise, if you've experienced the lack if static typing in Python, then you can infer that you'll have the same or similar issues in Ruby."

I find this to be quite true, what I find interesting, and apparently +Steve Yegge  would be surprised at, is I would move Haskell at least into the Moderate camp here.   I don't think the Java/C++ type systems have much, if any, advantage over dynamic typing.  In my opinion there are bigger differences between Haskell and Java/C++ than between Java/C++ and Ruby/Python. 
Maybe my limited Haskell experience is in a Liberal ghetto surrounded by a dominantly conservative community, I don't really know.  But it seems to me that the Haskell community exhibits many more of Steve's liberal traits than it does conservative ones.  Yes, Haskell pushes many ideas in Static Typing to an extreme, but the focus is on making the compiler do 95% of the work for you.  As a result writing Haskell feels much the same as writing Ruby (just significantly less code, Ruby feels unbearably verbose now) but I get way more static safety than I do in Java/C++.
As a result every Haskell project maintainer I've come in contact with has the 'liberal' mentality of "move fast, break stuff, fix it".  The major difference is that the "fix it" part is very frequently during the "get it to compile" phase.
 
Maintenance.  Good question.  I'm a (programming) liberal, but also a pragmatist, and I have to maintain pretty much all my own code; Python has proven about the easiest for me to read when I come back to a program years later.  So perhaps the question of maintenance is another "orthogonal" issue?  Sure, ease of maintenance is a conservative issue (part of that whole "safety" thing), but easily fixing your code is also a liberal issue (it's hard to change the world with all those bugs in your way).
 
Type theory can give you more vocabulary and a stronger intuitive ground for what you are trying to express, especially cognitive functions. You can read up on them here: http://en.wikipedia.org/wiki/INFP#Cognitive_functions

The basic application of type theory to programming is that programming involves a lot of Ti, Te, and some Ni and Ne. Each of these has a different slant (toward exploration or towards organization), and different people have different strengths and affinities towards them. Your primary and secondary functions are what you will spend most of your time in.
 
I truly fear we'll get into debates of software conservatives vs. software liberals, and at some point some jackass will say "of course but <person x> is a researcher for <liberal/conservative> software engineering" as if it were a contest.

If that happens, I predict a fucking hellhole and I can only imagine myself leaving the industry at once.
 
As a side note I want to say that the talk mentioned was by Christophe Grand at the first Clojure Conj.  In watching it and talking with the presenter I don't think it was as dire as it's made out to be.  Regardless, I tried to present a counterpoint at the following Conj in my own talk, "The Macronomicon". I leave it up to the viewer to decide if I succeeded. http://blip.tv/clojure/michael-fogus-the-macronomicon-5970233

It's great to see another Yegge post!  As always a highly enjoyable read.
 
As in most things, though, the left-right single axis way of categorizing things just seems dangerously limited.  Even in politics, there is the fiscal mindset vs. the social mindset.  One can be a fiscal conservative and a social liberal or libertarian.  At a minimum, most personality evaluations have 2 axes.  

I wonder how the programmer behavior you are describing fits into the Meyers-Briggs personality types.  
 
Wow, +Rikard Ottosson, I'm impressed.  +Steve Yegge's post contained all the negative anti-conservative slurs, and your comment contains all the negative anti-liberal slurs.  FYI, I code 90% Python, 10% Javascript in my current project, and my Python code has a distressing tendency to, um, just work when I try it.  The Javascript code, not so much, mainly I think because I'm just better at Python.  I'm no rock star... I just stick to simple code that will fit in my head.  Static typing code wastes space in my mind that could be filled with actual executable code.  Your mileage, obviously, varies.  But let me point something out to you... you can't understand how liberal programming works, I get that.  But it DOES work.
 
This doesn't actually seem to be all that new of an argument: the debate in the 1960's through 1980's used to be about "craft" vs. "engineering" or between "software is math" and "software is mechanism".

For example of what's pretty close to a Yegge rant of the 1980's, see Edsger Dijkstra, "On the cruelty of really teaching computing science":  
http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html

It seems to be bemoaning similar problems in the software field, though from a very "conservative" perspective, since Dijkstra prefers that a formal proof should be required with every program, and one should completely avoid anthropomorphism in discussing software design.

Another thought that's crossed my mind: one of the reasons for the evolution of these approaches to politics and risk over the years has to do with the scale of impact. Liberally messing around with a social and economic systems can lead to widespread human disaster: China's Great Leap Forward comes to mind. How the software is used and how reliable it needs to be is an engineering tradeoff with regards to cost & time. This is often why you tend to see much more liberal approaches to software in smaller companies - the scale of impact is much smaller (in terms of customer base, and investment) when you cock up.

Now, it's clear that larger companies, particularly many IT shops, could learn a thing or two about being "progressive conservatives", as they've "conserved" for far too long and are caught in the trap of special interests (i.e. traditional vendors dependent on their cash). Fear of dynamic languages, open source, or cloud services, or non-waterfall development is mostly a reactionary ideology grounded with some kernels of truth - static typing DOES help codebases scale (but you shouldn't be proud of a large codebase), you can't just pick ANY open source library as some are DOA, or ANY cloud as some are unreliable, and tinkering with your delivery methodology can reduce your performance greatly due to confusion, plus there's plenty of cargo-cult agile consultants waiting to rope you in.

So, you need to think these things through. But that's not an excuse for avoidance. Perhaps that means I'm a software moderate.

(cross-posting to Hacker News)
 
I think the distinction wasn't intended to indicate good/bad, instead something to use to make communication easier. I think of it like MBTI personality types--if you know that the person you're having a debate with is a different type than you, you can change your approach. Same thing with knowing if a programmer you're working with is more conservative or liberal, in the programming sense.
 
Count me in as personally and deeply offended.
 
I'm trying to like the idea of a quasi-political axis explaining different programmers' points of view, but I just don't.  It doesn't match what I think I see.  I looked at your list of characteristic views held by "liberal" and "conservative" programmers, and I have a hard time identifying with either list.  When choosing between the paired opposites I find myself saying "well, it depends."

I'm going to propose some different axes that I find more useful in practice.

We all know Tannenbaum's characterization of computers in Structured Computer Organization as a hierarchy of levels, even if we don't know it by that name.  Every programming language presents a virtual machine implemented in terms of some lower-level virtual machine, and it all bottoms up in electricity.  And we all know that those virtual machines are imperfect--there are circumstances when you have to consider the next lower-level machine in order to figure out why something is going wrong.  So my first axis is this: there are people who understand these layers of virtual machines top to bottom, and there are people who do not.

You might think that only a bad programmer would not understand all the layers, but that simply isn't true.  People write great programs in Java without understanding how the JVM is implemented.  People write beautiful programs that run in web browsers without understanding the operating systems on which the browser runs.  The people who understand the whole stack spend a lot more time learning about things than the people who don't.  But when the bugs get weird, because the virtual machines are interacting in strange and unexpected ways, you need the people who understand the different levels to figure out the problems.  Or you just just skip it, use trial and error to patch things, and keep going.

In other words, there are people who are more interested in how it all works, and there are people who are more interested in getting things done at whatever level they happen to be working on.  These different kinds of people are better at different kinds of jobs.  When a programmer leans toward either end of this axis, giving them a job suited for the other end is a recipe for disaster: either nothing gets done, or the result is too fragile to actually use, depending.

To be clear, not every programmer has a real position on this axis.  Some people are flexible and know just what they need to know.  But some people do tend strongly toward one end or the other.


Here's another axis.  Some programmers are interested in the program itself: in expressing the problem in a way that is elegant and succint.  Some programmers are interested in getting things done, and don't care about the program.  A characteristic error of the former is over-generalization: a new object oriented framework for a toaster.  A characteristic error of the latter is unmaintainable code: code that is so tightly coupled that no one piece can be modified without touching the other pieces.  Few people are on the extremes on this axis, but many people are not at the center.  Again, a specific job is best done by the right sort of person.  And, again, this axis only describes some people.


Here's another one.  Some programmers like to work on tools.  Some programmers like to work on libraries.  It's a difference in degree, of course, but here's how you tell: consider the broad range of code that you touch in a year; does that code form a standalone program, or does it form a component of a larger program?  Some programmers have strong tendencies toward one side or the other.


I'm not going to try to really explain these different axes in full detail, because that's not my point.  My point is that I think you can usefully divide programmers in number of different ways.  I think you've described one way to do it, but I don't think it's the only way, and I don't think that your way hold significant explanatory power for the kinds of people that I work with.
 
So, the main message from the article (Despite the "Author"'s efforts to slant it othewise) is that bad design and programming practises should be called "liberal" as opposed to simply ignorant?
 
I am, I guess, a moderate-conservative programmer (I work mostly in C# and enjoy the language).  I would like to be a more liberal programmer, but have not had the opportunity or the education to be one. I know how to be a good conservative programmer, but I don't have enough experience in liberal programming to be as good.  I don't know all the gotchas and best practices... which means my code in python would likely be a lot lower quality than it would be if it was in C#.  

I think that most of the differences in conservatism / liberalism are just ones of education.  If you've never worked with someone who is an expert conservative/liberal programmer, then you probably have no idea how to write code that way... so when you go to do it, liberals find the static type systems slow and cumbersome, and conservatives find the dynamic type systems chaotic and hard to follow.  But if either learned from great programmers of that style, they'd see all the best practices that highlight the good points and diminish the bad points.

I do think that Steve was 100% on target about tooling being a major problem with dynamically typed languages.  Compare Visual Studio to umm... what's the preeminent ruby/python IDE?  Oh yeah, there isn't one.  
 
Langages are nothing than a tool. Developers are all politics. I read a lot of C code. I saw extremist anarchist and hardcore conservative in there
 
A note on macros - the conventional wisdom in the Clojure community to avoid them in the common case isn't for the sake of programmer safety, it's because macros aren't composeable - they aren't first-class entities in the language. 

If you write a function, chances are it will eventually be re-used as a higher-order function somewhere. If you decide to give me a macro instead, that's the end of it - I can't map or reduce with it, or send it to an agent.

So really, its in pursuit of a liberal value: flexibility and code reuse. Clojure definitely doesn't go out of its way to protect programmers (just look at its error messages!)
 
This is absurd. Everyone knows that the programmer thought divide isn't split between liberal and conservative, it's vi vs emacs.
Ken Dyck
+
1
1
2
1
 
"I'm hard-pressed to think of any domains that tend to be mostly-liberal or mostly-conservative, with the sole exception of Site Reliability Engineering, which is sort of by definition a conservative role."

Let me help you out with that. Here are a few domains that skew conservative:
- embedded software for implantable medical devices
- control systems for nuclear power stations
- avionics
- ROM images for Application Specific ICs
- guidance systems for military weaponry

There are several domains where the "Bugs are not a big deal" claim simply doesn't hold. Some bugs can result in millions of dollars of damage or the loss of life.
 
You need to stop complaining about the length.  Steve Yegge is a great writer and you should hope to aspire to write as many good sentences as are in this essay in your entire lifetime.

He is non-repetitive. There is little he can cut without losing the tone of the piece or breadth of ideas he covers. The flow is gripping, and I'm surprised he can write so well while drunk.
 
Steve Yegge, while I appreciate your idea I think the metaphor is terrible. Left/right is so charged that even despite your warning I found myself hoping I was "liberal" when I'm actually quite "(software) conservative".

I think I liked the terms "Bondage and Discipline (aka S&M)" programming versus "Free love" programming. One likes structure and is elaborately controlled the other is wild, free, free-form, and a little reckless.

All that said, I'm not sure in which camp you'd place strict followers of TDD or XP.
 
Sounds like the author is simply trying to defend their software practices.  Nothing to see here.
 
Great, another categorization scheme that I don't fit into.  Actually  I did enjoy the read, and I do think there is merit to this.  The Microsoft bashing was particularly amusing, and made reading the whole thing worthwhile.
 
> Bugs are not a big deal!

Missing out is the social dynamic of ship-and-jump-ship to next project. Bugs are not a big deal as long as it's not the buggy code author that has to maintain the mess.
 
I really hate this sort of thinking. there is a time and place for everything, some projects need more saftey than others, or more performance than others or more flexibility than others.

You only hold the positions you hold because you have found your self in a situation where they makes the most sense, but now you avoid situations that don't make sense, so your opinions are fairly stable.

That doesn't make them correct, though.

I think the worst thing about this article is how it encourages seperating different ways of thinging into two opposing camps. In actuality, these camps are interdependant.

For example, the correctness of a Dynamic Language's implementation. I would certainly be quite conservative if I was implementing one. Also, there are many projects that have benefited at some time or other from someone who has been like, "screw this" and fixed it in secret, going against all the organizational protocol. (once or twice, this has been me), that said. such a chaotic move often depends on other well defined parts of the system.

The ways of thinking you describe may be orthorganal, but they are not opposing. We are better off trying to learn from each other, than ignoring each other, which is in effect what you are advocating.
 
Appears to make sense, at least for basic discussion purposes.

Interestingly, I work at a place that would fall under the fairly conservative side and yet we HAVE had the Christmas Eve failure.  At the time I wasn't working there, but ended up coming in and spending 2 days (and missing all the family Christmas gatherings) cleaning up that mess.

As far as myself, that's where it gets muddy.  I enjoy Assembly, Lisp, Java, Clojure, and Ada.  :-)  I can't say I really have any fundamental style objections to any of them.  I like and work easily in all those environments.  I must be the Libertarian of the software political spectrum...  :-)
 
I agree that the left-right/liberal-conservative analogy seems to dilute the impact of the thesis, but it's still an interesting read.  However, the best programmers that I work with are in the "best tool for the job" camp.  

They may have a language that they use by default because it's their language du jour, but most projects begin with doing a little prognosticating for picking a software stack.  The factors include things like "what's going to be make this project get out the door faster", "what are the performance requirements", "what level of availability and recovery do we need", "what can I do to make sure that I'm not forced to maintain this thing forever", "what level of security does the data demand", etc etc etc.  

To give a concrete example:
There are absolutely huge performance gains (which is supposedly a conservative concern) to be had by choosing a NoSQL database for the proper use-cases (supposedly liberal solution).  For our project we have hard numbers to show that our development and runtime costs are lower since we switched certain datasets to NoSQL from an RDBMS.  But we didn't just get a new hammer and pretend everything in our environment was a nail.  There are plenty of things that stayed with our column store and RDBMS solutions because the NoSQL system wasn't the right tool for the job.

So if someone asks me "on this spectrum, what kind of developer are you?" I'd answer, "that depends, what kind of problem are you trying to solve?"
 
I like the analogy, keeping in mind it's not airtight. However, like the political analogy, I've noticed that I've gotten more conservative as I gotten older. I believe that's a consequence of increased responsibility. The things I do now affect more people so I get risk averse.
 
Great post, Steve.  One thing I'd add is that a culture can be impacted by who it hires.  For example, Boeing software engineers tend to be extremely risk averse, appropriately so.  And hiring Boeing software engineers into Facebook would yield culture clash and unhappiness immediately. 

Maybe I am going too far, but I wonder if Google's software engineering culture would have been different if it had hired less from Microsoft and more from Amazon.
 
Software is about information. The liberal/conservative divide is about people, specifically, whether the individual matters.
Thus, I reject your thesis outright, for all I must admit this was an entertaining rant. Your willingness to confuse people with software does mark you a liberal.
Cheers,
Chris
 
+Arthur Bugorski, I'd say that TDD itself is a fairly centrist approach. The split would be on how granular the tests are. Do you put in enough tests to make sure the app is basically doing what you told folks it would do, and wait to write more tests until you get actual bug reports? Do you try to come up with every possible exception and write a test for it before releasing?
 
I noticed this about a year ago, myself. Systems engineers - the good ones who don't rush into things unprepared - seem to be conservative by a large margin.
 
I like this metaphor not because it's totally accurate (it's not), but because as with liberals and conservatives the two groups of software developers are seemingly incapable of understanding how anyone could even defend the other group's viewpoint without being a terrible, terrible person.  This is fairly evident in reading the comments here.
 
+Steve Jones  Yegge's classification of a language necessarily apply to those using the language... his essay highlights that you can use a liberal language in a conservative way or you could be a liberal developer who has to use a more conservative language for a particular job. This is one thing I think Yegge didn't do enough to highlight: the liberal-conservative axis of programmers is not the same axis as the one for languages... assuming you buy any of Yegge's analysis at all, which I'm still contemplating. Certainly the marketing positioning of languages section caught my attention as "interesting observation."
 
Great essay but I think that your definition of conservatism is somewhat reductionist. Merely being risk averse doesn't seem to capture it. Adoption of the technologies you've classified as conservative also opens one up to other risks. I prefer to think of conservatives as those who wish to maintain (conserve) the status quo, therefore those who favor older practices.
 
Very painful to work through all that fluff, conjecture, incorrect understanding of political concepts and facts to even come to where you partially describe what you mean by conservative and liberal.  First, the political spectrum is from political science and refers to one's attitudes toward "change".  It is from left to right: Radical, Liberal, Moderate, Conservative, Reactionary.  On the far left, they want change to something new immediately.  On the far right, they want reversion to something old immediately.  The other version of the terms "conservative" and "liberal" may have derived from the scientific definitions on the spectrum but are by no means the same.  The definitions of "value systems" on management of risk is a flavor of the popular (mis)undestandings of the terms.  Americans tend to group people in one camp or the other, and stereo type (mostly inaccurate) beliefs to the other.  This is probably a consequence of our one-person one-vote electoral system, forcing participant to associate with one camp or the other, or be irrelevant...

Politically and I think in software development, people tend to be more liberal with more education.  Startups are made by both.  I think organizations grow more conservative with age in terms of bureaucratic traditions but become more financially wasteful and legally dangerous due to increased incompetence.      
 
+Chris Gonnerman said, "it's hard to change the world with all those bugs in your way". Would "bugs" be a euphemism for "other more conservative programmers"? :-)
 
Great essay, it consolidates a lot of perspectives that boil down to "software was better in the olden days". 

My only objection is the characterization of assembly language as "ultra-liberal".  It's actually the opposite, ultra-conservative.  When a programmer won't even trust a compiler to pick a register itself, that's a sign of deep-seated control issues.  Assembly programs are not small, per unit of functionality, and they provide optimization from the get-go, the essence of premature optimization.  There are only one or two "types" (binary and floating point) and hardware checks the validity of floating point.
 
This might be a useful way of characterizing a language/technology or even a particular programmer in the context of working on a particular project, but I don't agree that you can place a programmer on that scale in general.

I love rapidly prototyping things with dynamic languages and schemaless data stores. Just open up a REPL and go from zero to working proof of concept in no time flat. Bugs, edge-cases, and performance be damned. If I'm trying to grasp a new problem domain or figure out how to work with a new API, that's a fantastic way to work. If I just need to shuffle some stuff around on a machine or generate a report, a quick Perl script could be the way to go. 

But if I'm working on something that I expect other programmers to then build on top of, a library, framework, service, or tool, or if I'm working on an application that I expect to be running in production for a long time (I still maintain software that I wrote over a decade ago that gets daily use), my values change. Bugs, backwards incompatibilities and performance issues become NOT OK.  Static type checking, compiled languages, and enforced data schemas are my friends. It's worth slowing down and thinking things through because that care and attention will be amortized over the life of the software.

IME, good programmers with a fairly wide background will similarly adapt themselves to the needs of what they're working on. The programmers that I've known that could be reliably placed on that scale were either the type that spend all their time engaging in language flamewars rather than actually coding, or had a long career working in one specific niche that valued one end or the other of that scale (eg, a freelance PHP developer that needs to throw together small sites one after another in a hurry vs a programmer writing high speed trading software where sub-millisecond latency is a requirement and bugs could cost millions of dollars). 

The rest of us just try to use the most appropriate tool for the job and avoid dogmatic positions.
 
Well, like in politics, money (business) often has a detrimental effect. Also, Postel's law should be considered - "Be liberal in what you accept, and conservative in what you send." As a developer I'm liberal in areas and conservative in other areas. The closer my code gets to production I guess the more conservative it becomes in a way.
 
I am a centrist and proud of it! You are right about this being obvious.  I am now very much looking forward to learning more about Project Grok as well.
 
About marketing: change "conservative" to "formal" and I'll agree with you.
 
This is one of the most interesting and thoughtful pieces I've ever read about the cultural aspects of software development. I'm not sure if I'd agree with how you sort in Python and PHP. It's something that I've been thinking about for a while after realizing it in first place. PHP's Lerdorf is extremely liberal in the attitude towards its "baby" and the ecosystem, while Python's "benevolent dictator" is not. I can't help but notice how this affects the languages and their respective ecosystems: Python wants to be clean, consistent and reduced. PHP on the other hand is, from my point of view, kind of a mess (sorry, this is not to insult PHP devs). Just compare the different versioning philosophies (I remember having to deal with some difference in typing that changed in some minor version of PHP). 

Drawing from this example and quite a few others that come to my mind (just think of Apple design vs. rest of the market and how Apple does design) this leads to a bigger question: how do people organize themselves in society if they want to achieve something together (which ultimately is the very reason for us having become social during our evolution). I think it's very much valid to apply the principles of evolution of large software projects to our cultural evolution, as distributed software development is pretty much the highest intellectual but also cultural effort that self replicating and entropy defying molecules have ever taken. I'd be very much interested to hear some opinions. 

And btw, I'm an open web stack developer, I love the nature of Javascript, but I'm also fascinated by Scala and even more by Clojure. According to your list, that'd sum me up in real life pretty well ;-) Thanks for the great essay again. 
 
I just C-f'd bottom-up and top-down, and nothing. How would a liberal/conservative stand on those two desing philosophies? Instinctively, I would say that a liberal will rather go and code his primitives first; then slowly put those together, while the conservative will rather have his desing document ready before coding, and slowly work his way down until the primitives. I might be wrong, though. 
 
I don't think of myself as conservative, or unnecessarily risk averse; I'd rather get shit right the first time because while I can debug and diagnose defects, doing so can be a pain in the ass. As for static typing: my first language was C, so I still retain an irrational preference for static typing and curly braces.
 
It's a tempting thesis, but in the end I think it's no more accurate that the left/right spectrum in politics, which is to say, far too simplistic. Modeling along an axis is an interesting way of doing things, but one axis is simply not enough. (I admit it would be an interesting exercise to try to find an axis that would put most software people pretty close to it without any major outliers, but I doubt such an axis exists.)

On the static type front, though, IMHO you miss (by far) the most important point: it's not about safety, and it's not about tooling; it's about readability. If I'm trying to understand a huge foreign (to me) codebase, being able to immediately glean the type at any given point is a crucial timesaver; sure, I can always figure it out, but it will take more time, and I have better things to do.
 
It's called a false dichotomy, and it's a logical fallacy.  Moving on...
 
Bah! Impossible to get away from US election year crazyness even here. As anyone who has taken some linear algecra in college should know you can project any N dimensional system onto a 1 dimensional axis. If it helps you understand the system better then great. Never mistake the projection for the real system.
 
Re-visiting this again: Visual Basic really needs to be moved in with C# - even the earlier non-.NET versions are basically middle-of-the road with types and early binding.  It's fairly unambiguous, do not have any dynamic features (pre .NET dynamics) and not anything like the other languages on that end of the spectrum.  I'm not sure why assembly language isn't on both ends - it's completely conservative, because it's more strongly typed than anything, just the types are so primitive, they can just be reinterpreted at will (pointers are bytes).

Now tending to discount much of this analysis on this basis - suspecting there is more to it that this axis and some of the things you are seeing which put things on this axis might be deeper principles in the languages.
 
Sounds like a false dichotomy to me: liberals push features, while conservatives push correctness? Bzzt! No real conflict there, only a false conflict owing to poor software development process. It's all about the process. And the craftsmanship.
 
+Steve Yegge I would love to see a follow up post (or comment) wherein you match software luminaries with the analogous figure in U.S. politics. For instance. This post would've been substantially more entertaining had you described some well-known developer as "The 'Rush Limbaugh' of software development".
 
Not to your main point, but to a tangent I care particularly about:

As a Site Reliability Engineer, I agree that the role is fundamentally on the conservative side, but I think less so than is often perceived.  I believe the goal of SRE thinking is to identify all the reliability potholes, because once we know where they are, we can move at high speed and steer around them -- nothing slows you down more than losing an axle because you didn't see something coming.

It's the same reason the Guild Navigators in Dune need to be able to see the future; to move a giant starship faster than the speed of light without killing everyone inside, you need to see the obstacles before they happen.

Consider that SRE typically enforces regular software releases, and (depending on the product) that you can do a rolling update while the system is live; more conservative organizations tend to do infrequent, catastrophic updates that require taking the system out of service during the upgrade, and they sometimes get so far behind that they get stuck and can't upgrade.

SRE tools themselves, including some systems software, are typically written in liberal languages and paradigms, because so long as the steady state is rock-solid, the tool that imposes the change can follow a paradigm of "either work, or crash cleanly and blast out a stack trace SOS."
 
Pretty good article as a whole, but throwing in the additional, needlessly inflammatory claim of "[conservatism is an effort to control/manage fear]" messes it up.
Take that out completely, possibly replacing it with [effort to manage entropy], and then it would be better worthy of more widespread publication.
 
Um, the whole paragraph about Microsoft, while quite correct IMHO, doesn't talk about their programmers or development practices at all; this is a jarring switch of focus.
 
I suppose then that Coq users are software fascists. 
 
Rather simplistic analysis. You can be socially liberal but not want your code lashed together by hackers. Liberals can be good business people too and know how quality affects the bottom line.
 
+Lars Ivar Igesund Maintainability is a neutral concept. Maintenance through pre-planning, design, and static definition is a conservative concept. Maintenance through iteration and regression testing would be a liberal concept.

Also, as a scientist, if the study isn't published, it doesn't exist. Science does not trust that which it can't review.
 
What about pragmatic? I think anyone who adheres solely to one end of the upfront investment in quality dial is severely stunted.  Where you should turn it and even what specific bits to flip one way or another depend entirely on the nature of the product, the quality bar and the end goal.  If you can't adapt that means you're stuck in startup/greenfield/potentially deadend projects or mature/mission critical ones.  If you can't treat one-shot or life threatening situations like landing the mars rover or radiation treatment different from more reasonably iterative situations like blog/CMS software, you're in trouble.
 
Ah, so that's why Clojure doesn't have a good way to insert a REPL into running code à la Ruby and Pry.
 
I've experienced this working with Telco Engineers.
 
I was kind of hoping this post would blow me away, but I'm fairly disappointed. I don't think he actually managed to to define what I would consider conservative versus liberal software engineering.  From the description, I don't think you could succeed if you were solely conservative or solely liberal and the only people who would make good software engineers are centrists.  Anyone else agree/disagree?
 
I like your writing style. I think your theory rhymes with reality. I think with age and experience programmers should raise and lower their conservatism vs. liberal practices as needed. I program stuff that works with physics. Motion control, robotics, process control etc. Hap hazard approaches to programming can kill in some of these scenarios.  On the other side of the spectrum, programming games, you feature expectations are going to weigh heavier than your testing and risk adversity. Thus they use a more liberal coding approach.

I have always likened your observations to different plant species. Oak trees take decades to become mature manifestations. In the end they make very strong plants that you can build stuff out of. Kudzu code, on the other hand, is created as fast as organically possible. It can actually overtake the oak if they are in the same space. However when a hurricane hits. The oak stands while the Kudzu gets ripped to the four corners of the earth. 

I think your assessment of the companies is spot on. Successful companies make money. When they do the start to look more like banks than innovation houses. They wall up and try to keep their money and become risk adverse. It can be a sad turn watching a once very cool company continuously excuse itself out of its creative space.  And that is why we have start ups.  Thanks for you time and observations.
Ed Carp
 
Very long, with a lot of fluff and filler and free-form thoughts, but it can be simply distilled as conservative = risk-averse control freak, liberal = free-form speed is everything.  As Steve noted, there's room in the software development community for both.  If you're building safety-critical systems, you're a conservative - if you're rushing to market with the Next Big Thing, you're a liberal.  I thought it was pretty sinple for so many words...
 
You completely missed one of the defining features of conservatism - ignorance. In real life conservatives cluster in heavily religious and uneducated areas.

By that measure haskell/ml are the bastions of liberalism whereas java/c# are the most conservative, and python/ruby fall in the middle (road to liberalism).

Another measure is a social net. Liberalism is all about not letting people die/suffer from deceases/poverty. Heck they even let people recover from financial mistakes (housing bubble).

Again this directly correlates with haskell/ml providing the strongest and widest social net (strong type system) and dynamic languages being a "wild west" of programming industry. And Rubyists are of course the mormons of programming.

You got it ALL wrong :))
 
+Trevor Clarke Static typing has nothing to do with pre-planning and design. Static typing go just as well with iteration and regression testing. In fact, the combo is a killer.

Private research is typically for a private purpose, so I'm pretty sure the institution in question don't give a damn about what you think about science. I do agree with you though, and think it is unfortunate that it isn't published. But it did happen, and I know it to be thourough within its limits.
 
in the beginning i had trouble to understand the notions because conservative and liberal in politics have nothing to do with your definitions of software conservatives and liberals. from then on, it all makes sense and is quite a revelation. 

from that point, i can say that i'm a liberal in practice but conservative in heart. meaning,  *Haskell* and formal programming ( program Design by Calculation and algebra ) are really powerful mindsets for better code.  But daily, me being a web developer, i just need to make it work. 
 
I think that you may find your model accepted more readily if you managed to leave non-programming topics out of the discussion.  Politics are notoriously divisive (as you recognize in your essay), and some like myself may disagree with your use of inflammatory language with regard to social/economic conservatism, even though we agree with your thesis.
 
I don't want to be in one spot along your axis, I want to be in multiple, at the same time! I want my code to be both small, simple and expressive (liberal) and yet fast and robust (conservative). I have programs where some parts are conservative, and others are liberal, by design. Code that is exclusively liberal or conservative will always suck in some way.

More importantly, I don't think this is the strongest dividing axis between programmers. A much more indicative one to me is top-down (up front design, general architecture, complicated) vs bottom-up (refactoring, YAGNI, OAOO) style programming. There too, it is best to do both at once (top-down for what you fully understand, bottom-up for everything else), but programmers rarely do that.
 
Going through this list, I found myself flip-flopping, at times seeing myself as 80/20 conservative/liberal, given my ops background. But at other times, seeing myself as 20/80 conservative/liberal, given that in many environments I work in, flexibility, dynamic/changing environments, and exposure to new needs/code/etc. has me relying more on what the post describes as liberal concepts. 

I think there are multiple axis that can be applied here, one for one's core belief system, another for the role you are in(prod/ops) vs (dev/ops). 

Good post nonetheless.
 
+Steve Yegge your argument is flawed in assuming a binary or a one-dimensional spectrum works at all with political ideology, and therefore there is no conclusion that can be drawn from it. #politicsfail
 
Aside from flawed, I'm not sure if it's an ethical argument/opinion:

(that branch of philosophy dealing with values relating to human conduct, with respect to the rightness and wrongness of certain actions and to the goodness and badness of the motives and ends of such actions)
 
You ompare two very different processes/systems. There are completely different factors governing both. It's about as accurate as making a statement such as..
 
'Apple can be defined as a religion with Steve Jobs, it's god head'
 
It's obvious why you can't logically do that. You're an idiot if you think faith towards a product is comparable too, say a religious faith. It's been referred comically like that. Yet, no one seriously would write a research paper of it trying to be serious.
 
"Premature optimization is the root of all evil."
By this issue alone, I'm a software liberal.
 
The Development of management theory and philosophy considers the fundamental principles that underlie the formation and operation of a business enterprise; the nature and purpose of a business, for example, is it primarily property or a social institution; its role in society; and the moral obligations that pertain to it. The subject is important to business and management, and is closely related to business ethics and political economy. It is influenced significantly by philosophy, ethics, and economic theory.

One must draw an important distinction between the philosophy of business and business philosophy, which is an appellation that one often hears in the business world. More often than not, the latter designation is intended to denote a way of doing business or a business outlook, a popular use of the term philosophy, instead of its more formal, academic meaning, using the concepts and methods employed by philosophers. The latter meaning applies to the philosophy of business in this article. The phrase philosophy of business also might be used in the same way as business philosophy, for example, "Risk taking represents my philosophy of business." However, this is not the same sense that philosophy is used in this article.
https://en.wikipedia.org/wiki/Philosophy_of_business
 
I believe David West spent a good part of a book (Object Thinking) exploring this, but in there he wanted to contrast structured design with OO. He called old-school structured design people "formalists," while the other camp was in the post-modernist camp. 
 
It seems you are using 'liberal' in its old meaning which now means libertarian. Liberals (progressives) as currently defined in U.S. politics make more rules hindering "getting the job done" than conservatives. You were talking about getting the job done, right?
 
I would hate to see developers out of all the professions start to take sides in terms of political bias. Talk about 'Extreme Programming' It could get so heated it could have it's own reality show ;) I hope developers continue to work together.

I don't think a 'mindset' equates to 'belief'.. Neither white hat, nor black hat wants to get hacked yet, either hat may be liberal or conservative. I oppose only 2 sides, there should always be a 3rd party at least, keep the bastards honest! 

I wish I got to work at google, you get to wear all 3 hats... You get to voice your crazy yet perhaps interesting ideas (liberal) and then can still get paid for remaining more conservative. It's funny as Linus Tovlads used this approach in reverse to make a point to #Nvidia 

What result from this idea are you looking for anyway? Art?

"Rohit Kishore persuades that business can also be viewed to exist for the purpose of creative expansion. This is true from the perspective of multiple stakeholders. Successful firms like Google manage to align their activities towards the purpose of creative expansion from the perspective of all stakeholders, especially employees. This also validates the growing importance of innovation (aka creativity) as a core principle for business survival and success."
 
How about this: You should be able to do your job drunk and stoned.  If you agree with this (i.e. you have kids, want to do other things that code during the day), the conservative approach looks very attractive.
 
This conservative/liberal spectrum more or less boils down to expressiveness vs safety.  But that's a false dichotomy, which is why so many of your categorizations of languages strike me as weird.  Haskell and Scala are both expressive and safe.  More expressive than many of your "liberal" languages, I'd say.  I want it all, so what does that make me, a centrist?  Along with the C programmers who have neither safety nor expressiveness?
 
@James Rose  Ahh, dosn't #Facebook employ people on that basis, lol... so now, are they conservative or liberal? Conservative must be attractive, as I'm sure they don't use a drunken programming/hacking test anymore as an interview requirement! 

i wonder what happened to Buzz? Politics, Marketing, or other technology that was better, it was Facebook, right.... how does that fit in with how success works with your theory? Are you correct with this opinion, as that is the same as Buzz:

"Grok is not a confidential project. But we have not yet talked openly about it, not much, not yet, because we don't want people to get over-excited prematurely. There is a lot of work and a lot of dogfooding left to do before we can start thinking about the process for opening it up"
 
Funny how so many of the conservative programmers are grumpy about being labeled conservative.  I imagine Grumpy Smurf with his arms crossed saying:  "I hate being conservative."

But I should have guessed that quadrant would be a problem:  exactly 25% of all programmers (the ones who are politically liberal and software-conservative) were guaranteed to dislike the model.

They should be thankful I didn't use the dual-axis Dungeons and Dragons alignment system.  Although it would have made it easier to separate Lawful Evil programmers from Chaotic Evil programmers.

The simple fact is that even though conservative programmers may not think of themselves as conservative, everyone else thinks of them as conservative.  So the label is appropriate, and I'm afraid it's destined to stick.
 
No no no... I've see top-down vs. bottom-up and organic vs. inorganic in my 30+ years of programming, but liberal vs. conservative? I think partisanship is so woven into the American fabric of reality that people can't think straight anymore but it sure does make for lucrative deals that pander to idiots on both sides. So you thought you'd shoe-horn programming into it, why not, no reason you can't profit off idiots to. Now all you need is two aggregate sites, one with "liberal" programming news stories and one with "conservative" programming news stories and a handful of psychos that rant about both on Youtube and Sat radio.
 
I can't understand how you can derive a label such as conservative and software developer, and think they would be liberal in their belief.. 25% ? think about it... to be a good programmer you need to learn and innovate all the time. It's conservative to oppose innovation, unless, say, you are comparing mentality of programming to say, swimming laps up and down a pool. I don't think many programmers could afford that kind of outlook, maybe 20 years ago... I'm confused why you compare like this...
 
Programmers don't have faith in companies anymore either. Unlike the faith and sometimes unbreakable will a person gives towards a political side. Just look at how being the best programmer leads to getting early IPO's for switching sides. Is there even 1 programmer out there you actually think wouldn't change jobs for as little as 10k-20k a year, perhaps less.. perhaps some would even earn less money to be more liberal or conservative with there technical abilities and inherent innovation level..

If this was Buzz, I could draw a Venn Diagram for you, that would be cool!
 
The conflation of programmer preference and business practice is just confusing. Which are we trying to classify, here? I think it's a mistake to lump them together.

In regards to the programmer attributes alone, I do have a bias, but I think the set would be more clearly divided by "quality-oriented" vs. "other".

Focusing on quality promotes programmer practices like using static type checkers, defining things clearly and succinctly, eliminating bugs before release, and generally avoiding risks.

Focusing on other (quick money, time to market, minimizing amount of work, etc.) focuses instead on working fast, learning just enough to get by, rigidly defining as little as possible, and taking more risks with respect to the quality of the product.

Further, using your political party metaphor, I think liberals and conservatives that both care primarily about the quality of their products would have a lot more in common than quality-divided members of the same party, regardless of their respective methods.
 
This spectrum is a useful concept... for projects.  If you can identify a fixed position that you fall as a developer, I think you probably aren't very good.  You have to analyze the problem at hand and decide how conservative you should be.  Maybe you tend to prefer working on uber-conservative projects like NASA missions, or maybe you prefer to munge data with perl in a totally ad-hoc yet speedy fashion.  Great, but if you can't adapt to the needs at hand then I'd consider you more of an obsessive compulsive than a software craftsman.
 
Still in the process of reading, but are you seriously saying Bing is a successful product?  By what metric?  That it's still being kept alive in a persistent vegetative state?
 
Q. Why do people disagree about things?
A. Because we're so damn good at it.

[The Syrah may be good for writer's block, but it only helps reality map onto a one dimensional spectrum until the hangover kicks in ;) ]
 
Despite the electoral campaign, I feel this distinction confuses more than enlightens. For example, you sorted several programming languages onto this conservative-liberal continuum seemingly only on the basis of their type system. My own intuitions would sort them differently, taking into account age, use/appeal, complexity, etc. For example, I would probably group Lisp, Haskell, and SML closer together as newer or more academic languages (thus, more "liberal" in a sense) and COBOL, Visual Basic, and Java closer together as the more conservative enterprise languages.

Looking to the psychology of political, social, and religious conservatism and liberalism, the two personality variables most relevant are conscientiousness (typically higher in conservatives) and intellect or openness to experience (typically higher in liberals).

So the software engineer who is highly conscientious but not very open would be very self-disciplined, practicable and concrete, and quite concerned with carrying out the established processes. They would prefer to use widely supported, industry-standard languages and libraries. They may be less likely to learn something new unless there is some concrete gain of a pay raise, promotion, etc.

The software engineer who is lower in conscientiousness but high in openness/intellect would be more motivated by curiosity and a desire to push the boundaries and take less inherent pride in productivity for its own sake. Establishing and then following processes would be too constraining and simply bore them. They'd rather incorporate playfulness, exploration, and meaning into their work than mere money. They may lose interest in the more tedious aspects of a job, but they may also stumble upon a better solution while doing something completely unrelated or by incorporating ideas from a diverse range of knowledge. The more liberal software engineer would start learning a new programming language out of curiosity and maybe find a more practical use for it later.
 
This is a HUGE troll. It's completely wrong and provocative for the sake of it. Pointless.
 
Interesting article. I also was surprised to see the Haskell and Scala languages to be on conservative side (they bring many cool thing related to type system and in general the functional side is whole new dimension of looking at things) but it aligned with your criteria. So I think I am aligned to conservative side more. Also it cool that you mentioned optional type system as it look it good attempt to resolve old static vs dynamic languages debate because definitely tool support and documentation is main sticking point with dynamic languages. 
 
No update on videogame gun collecting?
 
Idea is ambitious but the detail is immature. Pretty interesting~ Thanks.
 
+Steve Yegge In my very limited understanding of political science, it's been claimed that most of the variance in political positions can be explained with two dimensions (one dimension is the traditional left-right axis, and the second has been variously identified as social/fiscal, populist/elitist, or north/south). See the literature on "ideal points" if this sounds interesting. So my question: if you added a second, orthogonal dimension to your model, what sorts of things would it explain?
david j
+
8
9
8
 
I find this pretty non-sensical.

Here is my system. 'Religious' programmers believe a methedology is inherently better or worse, regardless of project. 'Science' programmers believe certain methodologies are best used for certain situations. Looks like Yegge is religious.
 
+Steve Yegge you clearly don't know how Microsoft operates. I work for Microsoft and everything you said is not completely true. Microsoft these days is different, there is so much innovation and talent here it is remarkable. Everyone works hard, corporate structure gives us the freedom to shape this industry. Microsoft today is different. 
 
love this article but i'm a fan of Ruby and Haskell whom are on the ends of each scale. So am I bipolar? or is your system somewhat flawed? 
 
I want to say it's a well-written article, but the definitions of conservative and liberal don't make sense, and judging the reaction of the programmers, I'm on to something.
American conservatism is about preserving the Constitution and keeping the government subject to it (and as a result, the people of the US). It's more of a "don't tread on me" philosophy, which is why conservatives and libertarians get along so well.
Liberalism is about the government gradually becoming less subject to the Constitution and more about political bodies having control (and its by-product is people slowly become subject to their government). While there is some truth to this article, the bottom line is that conservatism puts political power in the hands of people, with government as the subject, whereas liberalism does the opposite; puts people subject to bureaucracy (and by default, politicians). This article misses this very obvious point, which is where it goes wrong.
 
I suspected at the very beginning that you were going to wind up defining Microsoft as a conservative company. Very good points.
 
I'm not sure it works to consider liberal/conservative as attributes of programmers.   Certainly I would describe most of my current work as being moderately-liberal in approach, but previous projects have been pretty conservative.   I'm comfortable with the idea that an engineering approach or even sometimes a project can be conservative (though I'd say cautious) or liberal (I might say flexible).   I agree with +John Reese's comment above about the nature of SRE (like John, I am one), too.   When making engineering decisions and considering trade-offs, yes, it's important to consider what happens when something goes wrong.   But it's also important to consider the costs arising from moving too slowly.  Not just in terms of delays to launch, but in terms of what other useful stuff folks could have got done if they'd finished the project/feature sooner.
 
After reading your post, I have to put myself in the "not a useful model" camp. I kept finding myself flipflopping between your liberal and conservative camps on almost every issue. It's certainly an interesting idea, but I don't think it pans out as useful. I would probably end up taking 90% of engineers and just calling them independent.
 
The model of dividing people between risk-averse and risk-taking is very useful and apt. It has limitations, but if you don't understand the word model, then you have bigger problems.
 
When you state that "The Christmas Eve Outage scenario never, ever happens in practice -- that's what code freeze is for. Bugs are not a big deal!", I suspect you are not offering to carry my project's pager over Christmas, New Years, etc.  Every major project I have been on has had a holiday pager schedule, and they all went off at times.  Sometimes over holidays, despite (in some cases) a three or four week freeze.

This is the heart of why I put up with the constraints implicit in style guides, mentoring new developers, reading most of my team's code reviews, readability, and all of the other overhead implicit in a multi-million line code base.  It makes me more confident that when I leave work, I will not have to come back at one in the morning because that is when the one customer with a four zillion megathingy account logs in for the first time in months.

I do not want that pager to go off.  It is not about time - I give a lot of time to my employer, and they reward me well and fairly for it. That said, I want some time for my family and friends.  I want sufficient sleep to be able to do my job well.  Heck, I want to be able to take a vacation without interruptions.  If a certain amount of inconvenience prevents a mandatory "all night hackathon", it seems a fair tradeoff.  Especially since the bug that causes me back in might not be mine - it might be generated by someone that has drawn that safety/reliability line in a different spot than I would have.

If we agree on the inconveniences we are willing to suffer mutually to avoid an outcome that we both would dislike, well, that feels a lot like negotiation. 
 
What about all those Haskell'ers that solve every problem with a DSL?   I think your dichotomy is broken.  

For the record my primary languages are Haskell, Mathematica, Python, C, and x86 assembly (ok, I mostly read x86).  Make what conclusions you will.
 
+Scott Ellsworth I don't have any conservative badges left to hand out, but you can rest assured that you get the first one in my next batch.  You've earned it.
 
+Brandon Niemczyk You're a conservative.  It was actually one of the easier conclusions I've had to draw today.
 
+Steve Yegge The distinction on how liberal vs conservative programmers perceive production bugs seems strange to me. I would argue that most programmers believe that serious production bugs are a Big Deal regardless of ideology. I think the more accurate distinction is not in how programmers perceive bugs, but rather their philosophy in how to reduce/prevent bugs. Doing a code freeze for example seems conservative and risk adverse, not liberal at all...
 
I think at Google you're bound to be in the company of way higher then 25% liberal / conservative types.  Hopefully that doesn't paint too dark of a picture for this distinction in your day to day life!  

Personally I like it despite self identifying as a (software) conservative and thinking that some of the liberal technologies and ideas you listed are essential.  That's more of a matter of classification than actual politics.  Mostly this is good because it's an opportunity to reflect on our own software values.
 
I think it's regrettable that people toss so much personal passion about politics into this discussion, but this was at least interestingly provocative; enoughso that I went through the trouble of blogging my evaluation of some of the statements.

I'd probably call myself a left-centrist systems programmer who programs mainly in Perl and C, but chooses to use a lot of discipline in the way I use both languages, with the exact level of discipline dependent on immediate needs. I think Perl's community style isn't nearly as your-term liberal as you paint it though, and there are plenty of people who go more structured yet. More detailed thoughts here:
http://dachte.livejournal.com/886858.html
 
+Noah Davis there is a forward and a backward looking part of perceiving. Here it's the forward looking.
 
+Anil Das it's a much needed update to the Gabriel article. I think this axis is definitely a pattern of software psychology and architecture. Great discussion, too!

It's worth noting that polyglot comments here recognize that knowing different languages gives you the feel for the pattern the language uses (software:conservative/liberal). 
Xah Lee
+
2
3
2
 
i got stoned for the first time in 30 years. I think it's related.
 
Sorry Steve, but you've jumped the shark with this metric ass-ton of nonsense.  This whole article is needlessly provocative (with it's political metaphor) and based on a false dichotomy.
 
Seriously, did you have to use so many words to say what you wanted?
 
This is one of the most ridiculous things I've ever read.
 
Well written and thought provoking as always, Steve. But even as a Lisp lover, I am not sure I agree with some of your classifications of languages.

For instance, in terms of syntax I think Lisp is the most conservative. with Python and Java right behind it. 

Also, I think you focused too much on static and dynamic typing in your classifications.

Where I think you went awry is equating liberalism with risk taking as opposed to advocating change and new ideas. To bring in back to the political spectrum, I think libertarians advocate taking the biggest risks with extreme libertarianism being the elimination of almost all government services (protections) and relying soley on capitalistic human tendencies to produce a just and fair society. In addition, libertarians essentially advocate a change to a government system that has never been practiced on a large scale.

In contrast, many liberal ideologies are focused around rights, protection, and safety nets for everyone, things like universal health care. 

Conservatives generally fall somewhere between libertarians and liberals in that they generally don't want sweeping changes but want the status quo or perhaps a return to policies of earlier times.

Based on this I would reclassify your languages with dynamic languages being more libertarian. Here you don't want the restriction of the compiler or types to get in your way of doing things. Libertarian languages give you the most unrestricted freedom to try things.

At the liberal end, I would classify languages like Haskell as extremely liberal. These languages embrace radical change (new concepts), like Software Transactional Memory and functional programming paradigms. Haskell also supports an incredible flexibility of syntax with the ability to change the fixity and the like. Most importantly, these languages are adopting new ideas to provide better protection and support for a wide range of tasks (concurrency).

Lastly, I think the most conservative languages are things like Java and C++. These have been around a long time and don't embrace new ideas very quickly.

In addition when you start classifying organizations, I think language use and style guides is only one component. For instance, I think Google is pretty liberal in some respects. They put out stuff for public consumption that is essentially beta. Also, there is quite a large amount of diversity in technology stacks teams are using.

 Admittedly, this may be changing some with the decommission of labs.
 
I find myself on both sides of the fence. I’m a language liberal, but a performance conservative. Oh well, I don’t fit either political party either.  But, I have noticed over the years, that my “moderateness” has changed. I used to try to embrace both sides. Over time I find myself decreasingly tolerant of them both  (in politics and programming). Dogmatic adherence to a predefined doctrine is intellectual laziness, and antithetical to progress. In my experience, anyone who is not a skeptic or at least ambivalent is selling something.

Props to Steve for his formulation and for looking at it from so many interesting angles!
 
An interesting analysis, and superficially it helps to frame some of the discussions I've had of late.  But, looking at your list, I haven't a faintest idea where I fall on your spectrum. :-)

I'm a PHP developer, working on Drupal.  Drupal is the last standing mostly-procedural PHP framework with significant marketshare.  Drupal 7 is built mainly around anonymous arrays as the uber-data structure because it's so crazy flexible, but virtually undocumentable.  All of that seems very very liberal.

Except that PHP has been drifting toward typed OO for years, with people constantly wanting typed primitives, too.  And I've been the main driver for more OO, software rigor, interface-driven-development, etc. in Drupal for years.  That would make me an oddball conservative in a liberal world.

Except that I was also the main driver for us to take a huge gamble and restructure Drupal around a 3rd party framework (Symfony2), a move that so far seems to be paying off.  That sort of major risk taking is, by your definition, a very liberal thing to do.

Except I am also giving a presentation in a week at a conference about functional programming, which you list as the height of conservatism.

Except I'm giving that talk on functional programming in PHP, which is a dynamic language feature, and thus liberal.

Except I've also argued for more use of formal design patterns in Drupal, which sounds pretty conservative.

Except I am also a strong supporter of TDD, which is, someone above argued, liberal (perhaps to compensate for the lack of automatic testing provided by type systems?)

Except I also argue for making life easier for new developers, through consistency, which you sya is conservative.

Except I argue for that consistency to be on something that I fully expect moderately intelligent people to be able to learn if they want to get anything done, which you say is liberal.

So yeah, I'm all over the map.

I think the problem you run into is that, just as in the real-political world, a one-axis distinction is simply inadequate to capture reality.  It's a convenient shorthand for defining an "us" and a "them" (for whichever "us" you belong to), but that doesn't make it accurate, and strict adherence to an over-simplified model is actually harmful to public discourse.

The better modeling tool for real-world politics is the Political Compass (http://www.politicalcompass.org/ and similar), which is a 2 axis model: Liberal/Conservative and Libertarian/Authoritarian. 

I'd be curious to see your theories mapped into a 2 axis model.  It could be a more interesting and insightful analysis.  As is, in your model I am at best schitzofrenic. :-)  (Which is fairly true of me in real world politics, too.)
 
Your language classification is interesting. Two of my favorite languages at the moment, JavaScript and Clojure, happen to be on opposite ends of the spectrum. I wonder what that says about me (and the language classification).
 
I think any taxonomy that attempts to pinpoint a programmer or programming language on a one-dimensional axis is doomed to failure.  I don't know what a good taxonomy would be, but I'm confident there must be more than one dimension involved.  Consequently, this post is a rather useless oversimplification with little predictive or even explanatory value. 

The case study on Clojure is a good example of how this analysis is fatally flawed.  First, it's simply not true that the community or the core development team is heavily populated by people coming from Haskell.  Clojure is certainly an unusual data point -- the language exhibits a strange blend of allow-the-programmer-to-do-anything and protect-the-programmer philosophies.  Meanwhile, the development team pushes forward on their own pet projects while resisting change on features asked for by many users, so some aspects of the language seem to rapidly evolve, whereas other areas are stagnating.  In any case, Clojure defies easy categorization, thus proving the point that one dimension is not enough.
 
Reading articles have apparently gotten very hard recently, considering that many of the comments seems to have desperately ignored what was actually said, the message and as a special prize; the gist. 
 
Could you do an essay comparing software engineers to musicians in a rock band next? Who is more like a guitarist vs a bassist? What's the deal with drummers?
 
Re Clojure, I'm sure this has been covered already, but I don't think it's conservative.  You're referring to Christophe Grand's 2010 Clojure Conj talk, which I was present for.  His point was not that macros are bad.  It was that DSL's don't necessarily need to be implemented as macros.
Dan B
+
3
4
3
 
Humans have an unfortunate tendency toward tribalism: we like to divide people up into "Us" and "Them", and then we like to think about how to support our ideas and defeat their ideas.  This is unfortunate because it distracts us from thinking about which ideas are better, in favor of which ideas are ours.

American politics is full of examples of people making their decisions based on whether ideas are more "conservative" or "liberal".  American politics is also something of a trainwreck, and probably not something we ought to model our decision-making systems on.

So, I don't necessarily disagree with your method of dividing programmers up into tribes, but I'm really hoping it doesn't become popular.
 
Guys... this is not about axis... or mapping programmers... that is a so simple and static point-of-view... come on! This is about evolution!

A pure conservative behaviour never evolves, even when contained on a liberal enviroment. Evolution starts with liberal (sometimes with a bunch of failures) behaviour. But, liberal behaviour should only be used under certain (maybe priviledged) circuntances.

This article made people think and promotes evolution. Well done Steve!
 
According tot this essay I am a conservative programmer, but according to hindsight, I would have been just as well off if I had never read this essay. 
 
meh. Essentially this was an overly elaborate and verbose way of saying "programmers like different stuff". Not a surprise. Rather than apply politically charged labels on those differences we'd be better off identifying how to reconcile them.
 
Reading through the comments, I think I'm taking something different from this to many others. Seems the article is not about left/right so much as taking that analogy for a walk to make the point that building software doesn't come down to correctness (which has a logical resolution), but to politics (where we may have to find ways to live together).

I think there is something very similar in agile vs. waterfall. Some of the 'conservative' dev aspects here also seem to militate towards a design-first waterfall-ish approach (which also attempts to manage risk, typically in the face of fixed price and scope).

Which makes me wonder whether this might also be related to age and length of experience? You say that the facebook devs are young (and so presumably haven't been exposed to waterfall approaches in their careers) - is it possible that Google hired enough engineers with decades of (pre-agile) experience under their belts, who set a different technical agenda in the corporation?
 
> Except I am also a strong supporter of TDD, which is, someone above argued, liberal

TDD is inherently about risk avoidance; hence it is a conservative tendency. The extreme liberal antithesis is to catch bugs as they arise without assuming that you can predict what they might be beforehand.

Given Steve's analysis I would speculate that this is why facebook does controlled region-specific releases first.

> (perhaps to compensate for the lack of automatic testing provided by type systems?)

Definitely.
 
Woah. That post is way too long. So Steve Yegge discovered that all aspects of how we make sense of the universe is influenced by (and contributes to) our ideology. Didn't Marx point that out a while back? It's Marx's most important work IMO. Here's a usefully abbreviated version:

http://www.btinternet.com/~glynhughes/squashed/marx.htm

OK, Americans are strongly discouraged from reading Marx from birth, a proscription which continues through childhood and is maintained throughout adulthood by continuous sprinklings of Hollywood's best propaganda. And I'd be surprised to see Marx mentioned in any comp.sci. literature so I suppose he may be forgiven.

It is an interesting idea, but needs a few more iterations. (Does that make me conservative or liberal?)

My biggest complaint with it, is the tidy reliance on the extremely narrow American mainstream ideological model, where the words "conservative" and "liberal" have become so hideously distorted that they are generally understood as almost opposite to their classical meaning. Worse, the American interpretations of these words are being exported to political commentary elsewhere. Nowadays, anglo-saxons everywhere have little clue what words like 'liberal' or 'radical' really mean.

Steve Yegge mentions that the single-axis ideological model is a simplification, but he does not seem too bothered that it is lacking essential variety, http://en.wikipedia.org/wiki/Variety_(cybernetics) I suppose (I hope) he is just opening the notion up for discussion.

As a result, he doesn't take the extra step of applying a multiple axis model to software practice. As a consequence, the requisite variety is missing, so any interpretations will be likely to suck somewhat.

An alternative inspiration might be the model offered by http://www.politicalcompass.org

This has left and right broadly mapped as left being collective and right being individualist. (These are indeed useful distinctions when discussion what kinds of programmers are out there).

But the political compass also has a north/south axis, where northmost is authoritarian and southmost is libertarian. This too is a useful distinction, almost entirely overlooked by the mass media. It also has insights for software development.

I've seen three- and even four-dimensional ideological models. All much more than the idiotic oversimplified left-right crap peddled by the media and vulgar political theorists.

So could a multidimensional ideological model fit software? I think there's a big overlap into the development process itself, rather than just code philosophy. Perhaps 'agile' software development is similar to anarcho-syndicalism. How does the notoriously strict Linux kernel development process fit the model? What about the paranoid 'hacker' cells? (e.g. the Demonoid guys) who refuse external assistance because they're terrified of being infiltrated.

Perhaps we could use this model to make a general observation:

http://en.wikipedia.org/wiki/Viable_system_model

... which should apply equally well to politics as software. 
 
I don't think you can call "Visual Basic" a "hard core liberal language". At least not in any iteration of the language from the past 12 years or so. Based on your framework, it's pretty conservative. 

VB tries REALLY REALLY REALLY hard to be statically typed. This includes running the lambda type inference rules it imported from Haskell. Many of it's dynamic features don't work very well, and are kind of just after thoughts that get bolted on at the end of the process when all it's attempts at staticness fail. Some of it's more useful abstractions, like extension methods, don't have any dynamic support at all. Other areas of the language try to pretend to be dynamic, but then fall short when it matters most, at runtime.

Consider, for example, it's rules for assigning function values to variables. I know you have no reasonable way of knowing this , but they are completely schizophrenic. The compiler will perform narrowing conversions when assigning a lambda to a variable, but only if the assignment is made at the moment the variable is declared. It does this too with arrays, although in that case it will be permissive enough to allow the assignment as long as their are no intervening writes between the line containing the declaration and the line containing the first assignment.  Sound confusing? That's because it is.

At runtime, it will allow dynamic conversions between delegate types, but in only cases that can be statically proved to be safe. That is, it allows narrowing delegate conversions only at compile time (including unsafe cases), and widening  conversions at runtime.

Compare this with Javascript (which you also list as "hardcore liberal"). It basically says "a function is a function is a function is an object". It does this without regard to any notions of static type at all. Given any function value f, and any variable v, f can be assigned to v.
Java script is liberal. VB isn't.

VB's identity crisis spreads to other areas as well. For example, you probably didn't know this, but VB has multimethods, although they were added by accident, and they don't actually look like multimethods. They exist mainly out of a desire to be static, rather than a desire to offer dynamic goodness. The language has the ability to toggle between ("be a conservative" (option strict on), and "be a liberal if you absouletely need to" (option strict off) modes). It's "libreral mode" is designed to be turned on without causing any controversy. Taking a program that compiles in "conservative mode" and compiling it in "liberal mode" will not change ANY bindings. That's roughly equivalent to saying "you can switch from being a conservative to being a liberal without modifying a single one of your political beliefs".If you take this approach you get overload resolution rules that look almost like multimethods, with a slight bias toward the receiver type. 

C#, which you have listed as more conservative than VB, is actually better at supporting dynamic dispatch. If you ask C# to do dynamic dispatch, it will "do dynamic dispatch". It won't try to apply a regeime of static typing first, and then say "oh alright, I guess" and fall back on dynamic dispatch.

Also, the implementation of dynamic dispatch in C# is FASTER than the implementation in VB.

So... any ways... VB isn't really that liberal....Although you could say it has liberal parents. 
 
You're definately on to something there Steve. But then again, you always are :-) Enjoyed it, as usual.
 
I don't think the idea of mapping programming languages to the liberal / conservative axis is accurate at all. I understand how people can be more liberal or conservative in project management. The hacker culture in Facebook is deeply liberal. Extreme programming and agile methodology does sound very liberal, whereas waterfall processes is more conservative. That all makes sense, but trying to determine whether a person, or even an organization is liberal or conservative based on what programming languages they use is just inaccurate.

The ancient war of statically vs dynamically typed languages is something completely orthogonal. A lot of people do fast-iterating agile development, using statically typed languages. Some other people will use dynamic languages, yet spend huge amount of time testing their code. Static vs dynamic is a matter of preference, and merely depends on whether the person is more langugage oriented, or tools oriented.
 
It looks like several commenters took Steve's post as an invitation to go on, and on (and on) about political issues.  Wonderful.  How 'bout everyone stick to the topic: programming.  
 
spectacularly gross oversimplification.  Political ideologies dont map to programming ideas at all.  "Conservatism, at its heart, is really about risk management."  and liberal views are often associated with youth, with idealism, with naivete".  Terrible analogy.
 
Also, a good programmer knows more or less where to cut corners and where not to.  Risk aversion is task based.  If you apply the exact same regimine to every task then you are not doing it right.
 
If Ruby people get ahold of clojure and can dominate… that would be a good thing for liberals… let the conservative devs have Scala. 
 
Guys, seriously, have you lost your minds? 

The Conservative - Liberal idea was a reference as was very clearly defined, in depth, in the actual post. Not, again, very explicitly, an attempt to tie programmer affinity to political specificity.

So throwing sticks at an imagined figure can be interesting, but doesn't involve anything that is actually being discussed.

KTHXBAI
 
Disclosure: I'm not a software engineer (though some of my best friends are). I would posit that Steve's classification can be applied with equal success to many other fields in tech R&D. I've done system engineering and analog HW myself (and a little algorithm design as well), and while reading the essay I could visually see how those same ideas apply to my past experience in those fields.

Can we develop a "unified theory of R&D politics" now?
 
Since the terms "liberal" and "conservative" (unsurprisingly) seem to distract some readers, maybe it's better to just talk about risk aversiveness?

As with everything else, the correct level of risk aversiveness is: it depends. If you're working on something where bugs endanger people's lives and you have little chance of getting patches out, then you should avoid risk. If you're working on an intranet site where outage is a nuisance and patching is painless, then you should take risks (been there, done both).

Anyone stuck in the same level of risk aversiveness for different projects is either a novice or an imbecille.
 
I guess I'm all camps :) - But maybe liberal, as I would use any language that I'm emotionally charged right now. I could do a batch file, or shell script for something, or put a perl code (and I hate perl), or pretend I'm writing very fast runtime code in "C", or use C++ STL somewhere in the tools code (and I hate STL, and C++ in general), and then have fun in lua/lisp. I guess I'm just chaotic... or apolitical... Hmm... and I'm still divided between gc or not gc, shared or message passing, explicit vs implicit.
 
Not sure how Erlang is Conservative when its mantra is "Let it Crash"?! Maybe I need to re-read!
 
Of course one can criticize the framework, I was just slapping my forehead at how many comments completely disregards what Steve actually writes, including caveats and details, and then goes full on about something that have already been covered originally as if it wasn't mentioned.
 
Putting all programming languages on a single linear scale in the hope  of actually saying something is a bad idea to start with, but modelling this scale after the political system of the USA, a country that has managed to attract so much spite all over this planet in the past 20 years is through the ignorant expectation of the whole world abiding to whatever absurd ideas of it might be currently prevalent within it's borders, bears an incredibly tragic irony.

Languages, language feature and programming paradigms are not conservative or anything. People are. Language designers arguably are, but their thoughts are usually far beyond the battle grounds on which religious wars are fought.

There is a quality of people that can indeed be put on a linear scale, if that is really what you're searching for: Their affinity/aversion for change. One extreme being people in constant need of surprise, change and uncertainty, to feed their relentless curiosity with. The other extreme wants rigid, stable, predictable situations to build their existence on. And this has nothing to do with politics. It may be out of utmost conviction, or it might as well be out of impatience or laziness respectively.

You will find this human quality has no actual connection to whether or not you like static typing for example. It's a matter of how you learned things, and that usually depends on when you learned them,  because the main stream usually has a stance on what's "hot or not". And since the main stream has a slow, constant flow, that's where the  change-averse people are to be expected.

While much of what you write is of questionable "truthiness" and your classification of languages doesn't even really match the criteria you defined (which begs the question how well you've researched this at all), it doesn't really matter IMHO, because your basic premise is leading nowhere.

If you do want to split people in the industry into two camps, here's an idea I'd like to share: there's the fundamentalists, who lead religious wars about everything, without actually getting anything done, and then there's software developers, who try carrying out their mission with pragmatism, which naturally entails qualities such as open-mindedness and humility.
 
It's an interesting idea, I like the article. Just a minor point, though - you shouldn't conflate liberal/conservative distinction (in your definition) with left/right distinction (which is better defined in terms of enforcing power and social equality in society). I know it's usually done in USA, nevertheless wrong.
 
As usual, Steve, I applaud your willingness to make a strong statement about your theory; I think it provokes a lot more debate, and thus more advancement of thinking, than some wishy-washy everyone-is-right-in-their-own-way blandness. I'd like to suggest that the D&D distinction of lawful vs. chaotic would be more appropriate here, both in terms of the aptness of the labels themselves (which are very clearly defined in a way that liberal and conservative are not), and in their ability to avoid giving offense where I believe none was intended.
 
Ha, I see now that you actually considered that. (Your comment was collapsed so it didn't show up when I searched through the comments to see if it had been mentioned.)
 
Read The Structure of Scientific Revolutions by Thomas S. Kuhn.  (Written 50 years ago, but still in print!)  Software and programming are merely following the same pattern as many other scientific and technological fields.
 
You've got it completely wrong +Steve Yegge. Left-wing thinking is about doing the right thing for others despite the trouble it might cause yourself and Right-wing thinking is about doing what's good for yourself in spite of others. In this context, strong typing belongs on the left.
 
+Steve Yegge Nice.  I came to this late, but very nice.  It sums up very well why I had to leave Google Kirkland after a year and a bit, and ended up pretty much immediately leading a RoR team at another company.  I wish I'd talked to you while I was there, I might have been able to find a way onto a more liberal team.  (I ended up writing a ton of good JavaScript at Google, which I'm proud of, at least.)

I tend to think of the liberal/conservative divide as the classic conception of mother/father, with one side focusing on nurturing, encouraging, and forgiving of failure, and the other side focused on discipline, obedience, and success.  (Not that any parents are divided like that anymore, but it is the prototypical image.)  It's helpful to have a mix of both, in the end.  That fits into the articles narrative pretty well, it seems.
 
Pretty please keep (re)posting these to your blog as well!  I vastly prefer Google Reader's interface to Google Plus's, and Google Plus doesn't export RSS feeds.  I didn't find out about this post until someone pointed me to it, and I hate being behind the curve like that!
 
Really good points Steve. 
I wonder if have you seen this ted talk: 
Jonathan Haidt: The moral roots of liberals and conservatives
http://www.ted.com/talks/jonathan_haidt_on_the_moral_mind.html

He basically finds 5 dimensions and then tests persons on them finding what characterizes conservatives and liberals.

Based on his suggestions I would say that political conservatives will also tend to be software conservatives.

And maybe you could find those five dimensions... that will help classify persons as software conservative / liberals.

PS: I'm a software liberal but I'm seduced by Eiffels pre / post /invariant condition checking ;-) 
 
Amazingly biased text. Does not matter if some programming language perfectly fits Steve's definition of "liberal" - Erlang:
- is dynamically typed
- has arity-based function overloading
- has RTTI
- has C-ish preprocessor
- has binaries and bit-syntax (which can be seen as an equivalent of bit fields, but combined with pattern matching turns out to be more convenient)
- supports dynamic code loading (AFAIK, the only language from Steve's list that actually has this feature built into the language itself)
- "let it crash" approach, anyone?

Still, it's labeled as "conservative". Why? I guess because it's syntax is not fancy/cool enough, and it was originally created as "enterprise" language/platform (which is of course very "uncool").

And, BTW, why pattern matching is not on the list of liberal/conservative properties of programming languages? Perhaps because it's obviously "liberal", and then you'll have to admit that all the "liberal" languages like Ruby, Perl and JavaScript are lacking that feature, but suddenly "conservative" Haskell would have it.

Also, why Twitter is not on the list of companies? Probably because it's a perfect example of epic technical failure of "extremist liberal" Ruby-on-Rails (great idea, but unmaintainable/unscalable implementation), and success of "hardcore conservative" Scala?...

But anyway, one aspect of this software/politics metaphor looks quite relevant. This separation into "little-endians" and "big-endians" allows to effectively ignore most important things about programming like algorithms, data structures and complexity theory by classifying them as "non-political" and focusing on "liberal/cool" vs "conservative/uncool" holy wars. Pretty much the same way western bi-polar democracy have been fooling people by letting them choose between liberal and conservative camps (like there's no other alternative), and NOT thinking about important stuff - realizing their objective class interests.
 
I identify as a Liberal and I find this quote: "whereas liberals tend to be more weakly organized and band together mostly as a reaction to conservatism"  not just wrong but insulting on multiple levels.
 
I would rephrase the conservative/liberal view, because I think it clouds the real issue. The political software engineering divide is really just a usage divide. When deciding between a more tried and true toolset and an experimental, potentially improved toolset, how critical is the project you're developing with that toolset?

In that context, it makes sense to use stupid old fogey languages like Java/C++: You want your billion dollar industry project (bank app, mmorpg, missile launcher) to fucking work. As long as your project's core needs are met, you don't want to experiment with new toolsets because you don't want the hassle--new syntax, new community, new textbooks.

Whereas in a project that is not as critical, and one you're more familiar with, you have the mental room to explore alternative toolsets--new languages, new databases, new UI designs. You can't reinvent every aspect of a mobile phone, because inventing requires too much time and energy. But you can reinvent a proper subset of its components, a proper subset of its manufacturing process. When know the territory; such as XORs, shifts, and number theory in cryptography; you can afford to explore new algorithms.

TL;DR: Where your project is plug & play, such as a physics engine or web authorization service, you can afford to experiment. Where your project relies on tried and true components, you will choose to be conservative.

Yes, there's an awful fucking culture of OO obsession, and it needs to go. I await the day when FP is an industry-wide obsession. But the model doesn't matter as much as we think, if it seems to suit our needs.

Haskell ftw, I'm out.
 
After a bit more thought, I see that my earlier response was a bit knee-jerk. Of course different environments lead to different levels of acceptable risk, and we should all adapt to the task at hand. What's interesting is what level of risk you're most comfortable with; what your natural style is.

The two categories described here align very much with the old neat vs scruffy distinction, which seems to be useful. What this post adds to the discusion then is the argument that the underlying force is risk taking vs risk avoidance. I don't really see any good arguments for that compared to, say, a general desire for orderliness. Care to elaborate on that?
 
"an unrelated (i.e. politically-neutral) point on which both camps agree: namely, that static types yield better toolchain support. This is undeniably true today..."

But but but Smalltalk had better toolchain support than most environments today, and was the inspiration for a lot of today's tools (code browsers, project managers, debuggers, refactoring tools, change managers, etc.)

"I do think that Steve was 100% on target about tooling being a major problem with dynamically typed languages.  Compare Visual Studio to umm... what's the preeminent ruby/python IDE?  Oh yeah, there isn't one.  "

But but but Visual Studio (and Eclipse) came from the Smalltalk browser...Eclipse directly so, VS indirectly.  And Python programmers mostly don't like IDE's, otherwise they'd have more than one.  (Which they do, Wing, Pycharm, PyDev plugin for Eclipse, etc.)

I scored as a moderate liberal on that online Yegge test, by the way.
 
Thanks for warning me away from Clojure. Nothing winds me up more than ML/Haskell cultists.
Bob Uhl
 
It would be better to say 'libertarian' and 'authoritarian,' and less politically-sensitive too.
 
Best read on G+ in a while. Especially relevant because I've been looking at Clojure recently. This definitely gave me somethings to think about and the comments even more so. As a student trying to compile their own understanding of the big picture, it is very, very useful to read posts like this that dump the inner contents of those deeply embedded within that picture. At the end of the day, [most] software engineering is done for the profit of a company and this is where I believe business politics spill into the realm of design.
 
great essay, thought provoking and has a lot of good points to take from. yes, as you said, most of it was so obvious and damn!, why I didn't realize this all along. However, few things are vague and contradictory too.. for instance why do you work for a conservative company when you tend towards a 'liberal extremist'? Along the same lines, I would say that it is perfectly ok for a software liberal to be inclined towards a conservative language as 'Clojure' .. there are subtle things that probably you have figured out but it would take years of experience for many of us who have just started our careers to reason about ... but again, this essay has a lot of good stuff which would be useful for programmers at all levels of experience .. awesome stuff, Yegge!
 
It reads to me like someone who sees things in black-and-white and really wants everyone to fit into one of two categories: his team, and the other team. (No surprise then that he sticks libertarians in with "moderates": he can't figure out what they are, but he figures they must exist on the one true political axis somewhere.)

Take static typing for example. To me, static typing is merely a way of expressing a certain class of invariant. I'm sure there are people who think it's magical and has the ability to prevent all bugs, but not everyone falls into the two categories "static typing is like a universal cure for cancer" and "static typing has no purpose at all". My problem with static typing is that it imposes a huge cost on the developer in terms of flexibility and time spent trying to work around the type system in order to do very natural things, all to get access to a pretty poorly-expressive set of invariants that have questionable utility.

But this doesn't mean that I'm against invariants in general or think they're fundamentally a bad idea: on the contrary, easy-to-express static invariants coupled with an analytical toolchain keeping them from being intrusive in the coding process could be really awesome. It's neither necessary nor natural for coders to write everything as self-modifying code, meaning that some level of static analysis is generally always going to be possible. And what developer who has been woken at 3am to deal with some stupid bug wouldn't want safety that comes at close to zero cost? Whether it's possible or not has no bearing on whether such a thing is desirable.

Then there's the observation that liberal programmers realize there are always going to be bugs no matter what.  Shocker! Dude, everyone already knows there's no way to prevent all bugs, but one can expend time, effort, and available tools to reduce the expected level of bugs to one that is acceptable for one's lifestyle and degree of irritation at having to deal with them.

I could go on for hours. Language creep? Sure, it's no problem for good software engineers to pick up a new language on the fly. But how about all the language bindings to common systems that need to be maintained over time? With existing toolchains, it's a lot easier to do this in (say) 3 languages than 15. All that maintenance is overhead, pure and simple, so there has to be some economic calculation on the part of a responsible person whether the benefits of allowing some new language into a corporate ecosystem outweighs the added overhead.

Production systems should not have dangerous or risky back doors? Absolutely: if you put in a back door with the username/password "luggage"/"12345" you should get your ass fired. That doesn't mean that such people think all run-time ability to poke, tweak, or otherwise modify a production system with adequate protections is bad: suggesting so is setting up a false dichotomy, much like the rest of this post.

Etc. Etc.

I think it would have been better had he stopped at the observation that some people really like debugging and others (like myself) prefer to pre-debug rather than get woken to deal with something that is preventable, but that observation isn't particularly profound, not really warranting a 5000-word screed on the grand unification of software engineer personality types.

Personally, I don't know that I have a clear defining philosophy on software engineering beyond "spend the least amount of time and effort writing code that gets the job done", where "the job" is some not-well-defined function of speed of deployment, maintainability, extensibility, and reliability. Whatever tools are available to help me reach that goal are fair game... and sometimes I'm even motivated to write them for myself when freely-available ones don't exist. I imagine this guy thinking circa 1995, "SSH? Keys? How the hell does this work? Telnet works just fine!" just before getting his machine pwn3d. That some people go overboard on safety does not mean there are therefore only two positions on the safety dial, 1 and 11.
 
As a framework for explaining real world phenomena, this can be considered to further understanding, but like many frameworks, expecting a perfect fit or being dogmatic about it can be harmful. Just like "animal mineral vegetable" was naive as a taxonomy, it still moved the state of science and knowledge forward.

To me, a key dimension in this conversation is the axis of science vs. engineering. They are closely related and borrow from each other, but I argue what the legions of programmers do at companies like Google, Facebook, Amazon and Apple is largely engineering. Much like a bridge must apply scientific principles, the goal is to have a solid, safe and cost effective system that solves a real world problem.

Whether they are liberal or conservative as argued here, engineers that forget this simple truth run the risk of producing software and systems that are out of alignment with the amount of risk and productivity a company needs out of its engineering teams.

There are a lot of ways to solve the problems our jobs throw at us. Ultimately the "right" solution is a complex formula that must take into account realities like "going to war with the army you have..." which includes the ability to build, support, maintain, debug, fix, test, and deploy. As professionals, I think we should eschew orthodoxy and recognize that there are simply degrees of "right-sized" or "good enough" to reach a state that, like a bridge, is sufficient to meet the design criteria of the problem it was intended to solve.
 
"instead of Bill Gates they now have a lunatic in charge" - brilliant! :))
 
ok, another voice from the dark quadrant: afaics there are very different motivations and justifications in life to take a risk, both valuable and insignificant. If you trust your fellow humans, you can be terribly disappointed, but mutual faith adds a quality to life which can hardly be achieved otherwise. If musicians in a performance focus more on expressivity than perfection, they may commit embarassing mistakes, but their play will be much more animated and emotional. If you defy against injustice, you may suffer, but you are a heroe. Otoh, if you drive a car without a safety belt, you are not a heroe, it's simply stupid. If a slater works on a steep roof without safety device, it is outright irresponsible.
What do you gain by disregarding safety in programming? A little speed and ease, nothing more. And, different from music, in mathematics and programming errors matter. An error in a formula makes the coolest and fanciest formula worthless. So what are the motivations? I think it is mostly this "Why deliberate? Let's try and see"-attitude. That means, impatience and laziness of thought.

PS: Nothing against dynamic languages. I like some of them.
 
+Frederick Ross Your use of the Big Triangle model focuses too narrowly on a single slice of the space -- in particular, static typing as a way of doing designs via formal specifications.  There are many polarizing issues in software design, and static typing is just one of them.  Even within non-statically-typed languages there is significant difference of opinion about safety, and what restrictions and hurdles should be put in place to try to protect programmers from errors.

The political divide happens even within the context of a specific language, and can happen with any language, even a language that is by default strongly liberal in its default settings and supported features.  You can talk meaningfully about liberal vs. conservative opinions within a single group of Perl programmers, for instance.  Groups of programmers will often be divided on whether certain language features should be used at all, based on how error-prone they have proven to be (or more often, are "felt" rather than proven to be).  The conservative viewpoint is that such features should never be used, or should be avoided, even if it results in the implementation being significantly worse in other dimensions of quality (e.g. performance, expressiveness, readability, toolchain support).

Your concern about the "loadedness" of the terms is misguided.  In software contexts, the terms "liberal" and "conservative" currently borrow meaning from politics, but under heavy usage they will diverge to stand for their "true" meanings in software.

And they need not be pejorative.  Say you have two people, Bob and Sue, independently planning vacations abroad.  Bob plans out every day of his vacation in 1-hour increments.  Sue just brings a credit card with her and "wings it" once she arrives.  If you ask 100 people on the street whether Bob is more liberal or more conservative than Sue in his planning, I'll argue that (A) people will not automatically assume the terms have political meanings, and (B) most people will say his planning is more conservative than Sue's.  And neither of them is "wrong" -- they're just doing what makes them happy, and they should probably not vacation together.
 
All models are wrong, but some of them are useful. The liberal/conservative dichotomy is a useful model, but the one thing that is more true of software than anything else is it's nonlinearity. If constructing an exception to a rule is possible, then we can automate it. If we can automate it, we can make it easy, and if we can make it easy, we can make it mainstream. In addition to describing the way things are, we also need to describe the way things should be.   Then make it happen.
 
Not sure if you're actually checking out the comments, +Steve Yegge , but if you haven't already, you should read Zen and the Art of Motorcycle Maintenance, which roughly tries to unify two philosophies similar to what you describe here (except he calls them classic and romantic world views) through the so-called metaphysics of quality. Interesting stuff; worth a read.
 
This analysis of languages is wrong on several counts. Let's start from the surface: accepting the criteria as stated, there are issues with the rank of languages supposedly based on the criteria. Clojure would perhaps be the strongest case for this and even the author himself feels obliged to defend his ranking of Clojure with extra remarks, but his arguments have nothing to do with the criteria he stated in advance. Clojure, by those criteria, would have to come out at the liberal side of the fence, and in fact quite a bit into the territory. Here the author undermines his own model in order to push some personal agendas regarding his attitude not towards Clojure the language, but towards its community.

Second, the model itself is immediately put to question with the resulting ranking. Consider the first entry: Assembly language. The "batshit liberal" ranking probably grates with the inner sense of many readers, and here's why: the liberal/conservative positioning comes from assessing the choices language designers made. There are next to no choices made for the assembly language---it's just the way the hardware works. Assembly language should therefore be outside the scope of this model.

Finally, I also feel there's something deeply wrong with classifying Haskell as Extremist conservative. This is the most evasive point, but I'll try to explain. Haskell is based on cutting-edge mathematical models and is in that sense a brave, forward-looking language. When static typing, pure functions, and non-strict evaluation are taken to their absolute, pure extremes, the resulting language may indeed be as risk-free as it gets, but the determination to even try creating such a language is pure CS bravery brimming with the can-do attitude that sits at the core of the liberal worldview.

+Steve Yegge dreams of a perfect debugger. A perfect debugger would be fully autonomous: it would execute your code for a while and come up with a detailed report on the code's wrongdoings. If such a debugger is ever made and used, it will be immediately recognized as providing exactly the same thing the compilers of static languages aim to provide. Haskell is a language that allows the compiler to know a lot about your code without running it, and a dynamic language needs a nondeterminitstic process of debugging to find out the same facts. Therefore we must realize that the goals are the same and the difference is only in the means. A model that classifies languages/programmers by the preference of means to the same end -- bug-free code -- is not very deep and informative.
 
Please pay attention where Steve says
  "So please do me a favor and try to dissociate those specific agendas and real-world political viewpoints from the generic term "Conservative", which here really just means "risk averse"."

By extension any other things that you have learned to associate with the Conservative/Liberal axis does not necesarily apply to this.  Haskell may be cutting edge, forward looking and all, but is risk adverse to a fault. Assembler does not give you any safety net at all, so it is in the opposite side of the universe of a risk adverse language.
 
Interesting how the comments confirm the point made by Steve (not read all of them, tho ...)
 
+Hugo Hernan Buitrago Rios If Steve really only meant "risk averse", he could just have said "risk averse". He deliberately uses the political term in order to bring in allusions. But that's another story... my points, both for assembler and Haskell, attack not the correctness, but fruitfulness of his classification. First of all, note that a language is not the entity that is either risk-seeking or risk-averse: these qualities apply to the language's users or possibly designers. But this is only a very specific kind of risk: for example, starting a new project in Haskell, without prior experience, is risk-seeking behavior at its highest. There are many risks about using a language than just getting it to compile and run. What if it doesn't scale? What if the target platform doesn't support it well? What about the maintenance cycle, including your dependencies? So, taken literally, Steve's classification is very, very narrow and fruitless.

However, that is definitely not the way Steve actually uses this term. He plays a bait-and-switch trick on the reader: up front he hangs a banner screaming with disclaimers but, once you're in, he proceeds to use the terms "conservative" and "liberal" with their usual load. How else can you explain Clojure, a dynamic language with macros, ending up deeply within the conservative camp? How can you explain Steve fuming with rage at the mention of an argument against macros (which he, BTW, completely misinterprets)? Is that a proper reaction to an emotionally neutral classification of a language?

The point about debuggers... what are they for? Risk reduction, maybe? Why would a risk-addicted liberal ever use such a thing? And if he uses it, how is that different from a risk-reducing compiler? Is that what all this ranting is about? Compiler is dead, long live the debugger? Deterministic checking is suddenly inferior to stochastic checking?
 
+Cade Roux I don't think TDD is inherently liberal. Sure in our .Net and New Orleans circles we hear it more from the ruby guys, but many of the loudest proponents (Dan North, Kent Beck, all of Thoughtworks) come from Java and Haskell guys sure as hell use it. If anything, TDD is probably conservative-leaning since it's a ceremonious anti-risk technique. I am all for TDDing (really), but presumably at some rarely-attained point you know the specs and toolsets well enough that you can faster just write it all right the first time.

I think .Net developers have an added wrinkle that we have Webforms and the whole RAD thing to contend with. While that cadre is no more conservative than MVC, it is more associated with Microsoft and so we implicitly - and somewhat unfairly, lump it in that category.  

I think this vocabulary is useful.
 
I guess I have a mix of software liberal and software conservative viewpoints, much like my political opinions. The languages I learned with are quite a mix (C, Python, SML, Scheme, x86 Assembly, Haskell).
 
+George Mauer
You might be able  to write it right, but are you sure you'll write it correctly? How about you write the smallest, most specialized code possible? I've found TDD specifically useful just for that.
 
Next up, software engineering along sexual axis - are you "straight" or are you "gay"? Straight engineers belief code and data go together. In contrast gay ones are happy to put data next to data, using "homo"iconic languages.
 
Then, of course, there is "Tabloid" technology writing - filled with hagiographic worship of celebrities from the startup scene, lurid and sensationalist coverage of the latest incidence of domestic violence between Microsoft and Google, and, of course, the page 3 pornographic spreads  of the technology world:- detailing the features of the newest and sexiest scripting language, all topped off by the sports coverage (hackathons), 

Plus an excessive use of dodgy and inappropriate metaphors. That too.
 
Have to say,even after a few months of thinking about much of this, I both agree and disagree strongly.

Particularly tenuous are the classifications of Clojure and Haskell (It can be seen that these seem to have drawn the most flak of the languages). This is an incredibly valuable post that succeeds even if only in starting the discussion.

The choice of analogies held enough friction the be distracting for some.. this is where I think sugar coating would help.


Grok seems like it can promise the expressiveness of dynamism with the determinism of static systems. Until then, I'm going to at least remain a conservative in denial; despising Haskell,Clojure, Io and Ruby/Lua the least.

Sussman called Haskell the "Most advanced of the obsolete languages".

His polarizing quip, is as astute as this post — effortless to misunderstand; concealing careful wisdom.

I think time will crack this all.
 
The equation of a voluntary, largely self-directed, highly creative activity, with what is at its essence, a mostly compulsory, regressive, and extremely destructive activity, is a fundamentally and deeply flawed premise.

There is nothing coherent about politics, except that it is the ritualistic dissembling employed around the institutional use of force and the threat of force, to impose personal preferences upon frightened individuals.

Software development is nothing of the sort.
 
+Greg Gauthier I think your view on software development is unrealistic. Commercial software development is affected mostly by the same politics that affect the entire office activity. Commercial software development is also compulsory - you don't get the luxury of working only on projects you like, or only when you feel like it. Even worse, if you read http://laputan.org/mud/, you'll find that in fact working on software in a commercial setup, constrained by resource limits and deadlines, can be in fact a highly destructive activity.

Non-commercial development on open source projects is affected by politics too - usually the initiator or a small group of core devs impose their opinions on everybody else - look at the evolution of the Gnome project for some textbook example of politics in action in open source projects.
 
I still long for Modula-2 it was just ahead of its time.
 
Dear steve Yegge,
How can I get in contact with people frm google that handles hardware/software engineering technology.
Add a comment...