Hacker News new | past | comments | ask | show | jobs | submit login

I think I'm a software libertarian.

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

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

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

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

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

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

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

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




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

I agree with this.

At the end of the day, all I want is software that is both modular and portable. Unfortunately, in this day and age, that itself is controversial enough that some people consider it an extreme viewpoint.

This is why the Unix philosophy is so powerful - each individual tool is a black box, so it can be ignored for convenience, but each tool is also so small in its scope that it can be removed when rechaining without worry.

Unfortunately, Windows remains POSIX non-compliant, but for any -nix, not only should most projects port directly, but rechaining for equivalently-functional tools should be trivial. If it's not, that signals a problem with project organization. (Example: I include a Makefile even in pure Python projects, because nobody should have to figure out whether I used nosetests or another library until and unless they want to switch it out).

If everyone followed this mindset, I don't think any 'political spectrum' would need to exist. So you prefer statically typed languages and heavy use of IDEs? Doesn't matter - your Scala program written using IntelliJ still takes in input through a unix pipe and passes it to my Python or C program seamlessly. Why should I know or care how the tools work if I don't want to modify them?

My choice of tools should be viewed as the implementation, not the interface. If my tools preclude your project, that's a sign that your project isn't abstracting well.

This is only one small part of the larger argument, but it's the part I notice the most, and I think it abstracts well to the larger issue.


write good, legible code

What conservatives consider good, legible code is very different from what liberals do. From the article:

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.


Wow.

This manifesto, I believe I'll be pulling quotes out of it, for years to come.


That was beautifully written. Thanks!


> I'm conservative because I dislike complexity

Except a lot of conservatism as defined here is all about complexity in terms of 'big design up front' methodology and, really, having a big methodology in the first place, along with having a lot of testing and static analysis tools.

Ada is a conservative language. C is extremely, red-diaper liberal.


Sure. I think that Yegge has hit on something real, but I don't agree with where he's drawn the lines. Haskell and Lisp developers have more in common with each other than with "best practices" Java developers.

A lot of this is about risk assessment. Business people and engineers don't agree on how to define and measure risk. Business people think Java is the low-risk choice, because the risks are hidden. Engineers know that these over-ambitious, 20-person Java projects are actually a lot riskier. Putting 20 people on a 5-person project doesn't make it less risky, but more. Business types fundamentally don't get this. They have no idea what is wrong with Big Code methodologies, because they don't experience the externalized costs (of long-term maintenance and diminished morale). They get promoted and move on to the next (usually bigger) project.

Familiarity comes into the mix, too. Lisp is rejected because it's foreign and weird and macros can create a lot of undesirable complexity, but SpaghettiVisitorFactory patterns in so-called "best practices" Java are just as bad. They're a lowbrow spin on the same theme: obfuscation through indirection. There's a lot of indirection and abstraction that is done prematurely because it's the "smart" thing to do, but reflexively doing the "smart" thing is pretty stupid because often the "dumb" thing is more elegant and easier to use. That's called cargo cult programming, which seems to be business as usual in typical Java codebases.


>Haskell and Lisp developers have more in common with each other than with "best practices" Java developers.

Like in actual politics the emotion and the response, do not always match up rationally. That's why its called an emotion.

For example, preventive wars do not make one safer. But they sure make you feel like you are safer. Going out there, dealing with potential threats.

Likewise, Java can be very dynamically typed (depending on your perspective), yet feel 'conservative' (stick with what we know). Haskell is very statically typed, yet feel 'progressive' (explore new grounds).

Emotion is not an intentional thing, therefor its application is never rational.

To get back to real politics. If a person is both sane, yet fearfull of his or her security, they would not want a bigger military machiene, they would want a bigger worldwide PR machiene.

I tend to put the two extremes differently though: a liberal fears being wrong, a conservative fears being right. Which is why progressives go out of their way to be right, and conservatives go out of their way to be wrong. (jk)


I think probably the most important thing to understand about this essay is that "conservative" on Mr. Yegge's spectrum does not correspond to "neophobic", and "liberal" does not correspond to "neophilic."

People who like try different languages are likely to find both Ruby and Haskell interesting -- because they are. And both are interestingly different from the sort of mainstream traditionalist programming embodied by Java, C++, and Pascal.

But if you were doing a new project start on an important project, the gap between the reasons that would lead you to build it using hardcore Ruby metaprogramming with hefty dollops of dynamic dispatch and the reasons that would lead you to build it in Haskell with carefully defined type systems, monadic programming, and purely functional implementation that would allow you to reason more easily about what's going on -- that gap is vast. Which one appeals to you more given a real world problem to solve where the solution matters to you -- that says a lot about you.


A lot of this is about risk assessment. Business people and engineers don't agree on how to define and measure risk. Business people think Java is the low-risk choice, because the risks are hidden. Engineers know that these over-ambitious, 20-person Java projects are actually a lot riskier. Putting 20 people on a 5-person project doesn't make it less risky, but more. Business types fundamentally don't get this.

Business people are concerned with continuity, engineers are concerned with completion.

Putting more people on a project reduces the risk of losing key people, and staffing is really the only tool at business peoples' disposal to protect (the perception) of continuity.

Engineers consider the risk to be related to the project actually being complete: if that be functionally complete or shippablly complete, etc. Actually spending time working on the project efficiently is how engineers want to manage that risk.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: