As Yegge mentioned in his post, this is a bit of an oversimplification. As a simple illustration, choosing a statically typed language like Java over Python is certainly a conservative trait. But then choosing Python over Haskell is exactly the same, just with the whole difference translated towards the liberal end of the spectrum.
Put another way, it's the political liberals who came up with OSHA (I hope--I'm somewhat ignorant of the actual history :P). A liberal or conservative outlook is not characterized by some particular processes or tools--it's characterized in an entirely relative way. The conservative approach is in choosing the familiar over the novel and in avoiding change. The familiar could be safer--Java vs Python--or it could be less safe--Java vs Haskell. I've talked to some ardent Java adherents, and they have lucid cases for not going over to Python or Ruby or Clojure or what have you. But--critically--these cases are virtually identical to their cases against going over to Haskell or Scala. There are differences in details, of course, but it's a difference in degree rather than kind.
Another even more extreme example is TDD. In particular, the arguments people have against adopting TDD are essentially exactly the same as I've seen from TDD supporters against using formal methods. Once again, some details differ, but the core idea seems to remain: some people are inherently wary of change.
It's also interesting to note how Yegge categorizes certain concepts in multiple "buckets". Either he's just being inconsistent (which is plausible) or he's making a deeper point: it's not about the particular concept, it's about the philosophy behind it. If he wasn't making that point, I've made it for him :).
That is, anything called "something calculus" is conservative, but lambdas (e.g. lambda calculus) aren't. Type-based functions overloading (like type classes, I guess) is conservative, but Scala implicits are liberal.
In my view, the languages that are the most conservative (at least in my part of the world) are Java and Python. Why? Simple: they are the default language for almost everyone I know. You're at an enterprisey company? You're probably using Java. You're at a startup? You're probably using Python. You're using C or Scheme or Haskell or Erlang? You're crazy. (I should note that I don't know very many people in systems or embedded programming, so my view is obviously rather biased.)
All this rambling (I certainly see why Yegge always writes long posts) has left me with a fairly concise conclusion. Namely, mapping programmer attitudes to a spectrum vaguely inspired by politics is a reasonable idea. Sure, the reality is that there is no total ordering so a one-dimensional representation is fundamentally lacking. However, it's good enough to give some insight.
But I would not map technologies there based on the technologies' innate traits. Rather, I would map them there based on the thinking behind the people who use them. This is similar to how--if you don't know the background--it's hard to guess which political party supports which regulation. Gun control is the opposite of liberal, but it's exclusively heralded by liberals; deregulation seems liberal but, of course, isn't. Yet, on other issues, people on either end of the spectrum behave as expected!
This is why I think languages like Java and Python are fairly conservative. Not because they try to offer some sort of safety but because they are safe choices. This is also why I would probably place C# as significantly more "liberal" than Java--it may be the most "conservative" .NET language, but it is far less afraid of embracing new ideas than Java. So that end is simple: at least for enterprisey companies and startups, it's populated with Python and Java. But what about the other end? I think this is where the languages that most people consider too crazy to use go. Haskell, Scheme, Erlang and so on. Only very brave--very liberal--companies are going to use Haskell or Scheme in actu...
From the wikipedia[1]: "Congress established the agency under the Occupational Safety and Health Act, which President Richard M. Nixon signed into law on December 29, 1970."
Nixon[2] also tried to get Universal Health Care for all low-income and employed Americans, but it was blocked by Senator Edward Kennedy and other Democrats. Maybe politics[3] is just the art of getting the state to delegate property rights, even intellectual property, rather than itself productive pursuit.
I postulate[4] that discussions in political spectrum are no more a valuable expenditure of time and resources than painting styles being be a point of reference for programmers.
In summary this topic is an "Unknown or expired link" to me.
Nixon was a Pre-Reagan Establishment Conservative. Such Republicans are not tolerated by the modern GOP, as Nixon's record regarding OSHA, the EPA (which he also created), and Universal Health Care will demonstrate.
Political parties evolve over time, sometimes quite drastically, as the political makeup of the country as a whole shifts and changes.
Just because people don't act rationally, that doesn't mean that their emotions are not consistent, or can not be understood.
Emotions are not intentional, nor do they lead to rational behavior. (by definition). The translation of an emotion into a point-of-view depends purely on the context: it can swing any direction.
A conservative might be against war, because he/she is afraid it will make the world dislike the US more, and hurt his/her security more.
A progressive might be in favor of war, because he/she is afraid that without it, the world is worse off, and the potential for a better world is lost.
And from that perspective, I do consider the stated 'political' dimension a potentially relevant categorization of programmers' mentality.
But without knowing their background, there is no way to predict how they actually feel about specific approaches.
I would probably place C# as significantly more
"liberal" than Java
Only if you look at these languages in isolation from their virtual machines and operating systems on top of which they run, also disregarding the communities around them.
Java as a language is more conservative, definitely, but the Java ecosystem is definitely more liberal. As proof, compare Java's open-source community with .NET. Or compare the maturity of alternative JVM languages (e.g. Scala, Clojure, JRuby), with the alternatives running on top of .NET ; or compare the web frameworks available for each.
This is the reason why, when faced with a choice, a "liberal" developer will most likely pick Java over C#, even if C# as a language is more liberal.
Only very brave--very liberal--companies are going to
use Haskell or Scheme in actual production
I do not think this is an issue of liberals versus conservatives. It's actually an issue of pragmatism versus idealism.
I'm pretty sure that many people wanted to use Haskell or Scheme in production, but then they'd shoot themselves in the foot, because the available libraries and tools for a language are far, far more important than the language itself. That's why Perl was so successful in the first place, because Perl hackers were getting shit done, then contributing to CPAN, which allowed other hackers to get their own shit done, and so on.
On the other hand I'm seeing lots of startups trying out and even using Clojure and Scala in production, at least for parts of the project. That's because these languages have all the Java libraries at their disposal, even if the languages themselves are still immature.
Don't mistake pragmatism for conservatism. That would be a mistake.
How much of the difference between the C# and Java ecosystems is due to the age of the language? Of course, I agree with you, too, because we have a "liberal" language (C#) tied to an extremely "conservative" company/platform (Microsoft), and that will always be a limiting factor in the growth of the ecosystem.
Has almost nothing to do with the age. Most dotnet shops wait for MS to give them what they need. Java developers are more inclined to create (and share) their own solutions. It also doesn't help that MS actively cannibalizes and rebrands open source projects.
What he wrote about Microsoft is completely unrelated to the rest of his post. It says nothing about the company's culture and software development processes.
He could have saved himself the embarrassment of writing that.
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.
In the examples given, Dart with its optional type system (and with type-checking that only triggers warnings) would actually fall in the liberal camp.
You can bet that the Mars Curiosity rover isn't
using a garbage collected dynamic language
It's using 2.5 million lines of C. C is not a strongly typed language. C can't really be classified as dynamic or static. C is just low-level assembly with some structure attached.
I don't think that Tim Sweeney or John Carmack
are prematurely optimizing ...
These people's jobs are building engines, not games. If you want to build a game, especially if you don't have their resources and knowledge, you're far better off by starting with friendlier tools, such as PyGame.
It's much cheaper to validate your idea that way and in the process you might end up with a hit like Angry Birds, which runs in the browser just fine.
1. Dart is less liberal than JS. For example, it is early bound. This fact alone allows the IDEs to do a much better job with less complexity.
As I mentioned, Carmack and Sweeney make engines, the artist interface is UnrealScript, or Lua, etc. But that's besides the point: performance matters. Carmack isn't trying to build yet another Box2D casual game (the Iphone Angry Birds uses a C implementation of Box2D, and Lua for game logic)
For someone like John Carmack, they are trying to push the state of the art, and starting off implementing say, idTech 7 in Python would yield unrealistic data if you're trying to see how feasible a given new rendering technique works on the large scale.
C is a typed language, there's no getting around it. It is in fact, a manifestly typed language, the types aren't optional. The fact that you can freely cast your way out of any situation doesn't really make it a dynamic language, anymore than Java reflection or bytecode rewriting makes Java a dynamic language.
The basic fact remains, the Mars rover is a highly performance critical piece of software with hard real time requirements, and it's simply not going to be written in a language that doesn't allow precise control over numeric types and memory allocation behavior. It's really those guarantees that many people associate with strongly typed systems programming languages, not the compile time checking.
Game programmers are very liberal, they want to escape straight jackets, and get deterministic and low level control over everything, often breaking the rules of the system. And in this regard, dynamic languages often taken away some freedom -- the freedom to control memory, stack, and cache behavior. They are conservative in a way.
"C is a typed language, there's no getting around it. It is in fact, a manifestly typed language, the types aren't optional. The fact that you can freely cast your way out of any situation doesn't really make it a dynamic language, anymore than Java reflection or bytecode rewriting makes Java a dynamic language."
C is statically and weakly typed language. That doesn't make it dynamic in the same sense as python or ruby, but it does make it a heck of a lot less safe, a heck of a lot more flexible, and thus a lot more liberal.
> I don't think that Tim Sweeney or John Carmack are prematurely optimizing ...
Well, this is where the rant misses the mark, I think. Whether some programming thing is Liberal or Conservative really depends on the context, how much is at stake and where you're currently pushing the envelope.
The code for the Mars Rover has to be ridiculously safe and conservative, since it cost billions, is deployed in a harsh environment and if it crashes you've lost the lot.
If you're hacking and validating some startup idea, then something that's bloated and poorly tested is fine, since it's likely to be wrong at first, and speed of development is more important than safety.
Both of these are safe choices, and they're the choices that you'd make, but they're at opposite ends of the spectrum... but you're the same developer.
He has 9 points for each side, but my take is that they're all true.
> that makes IDEs simpler and more accurate in code navigation and refactoring
IMHO, that's one the OP's main arguments, that for example there is a whole class of (liberal?!) people to which IDEs don't matter at all, so that someone (a conservative?!) arguing "hey, this static typing thingie makes IDEs more easy to use" doesn't matter. So it makes sense to at least know on which side of the fence each of us sits, so that we won't argue as much :)
(just to be clear, I'm trying to use the concepts "liberal" and "conservative" as they're defined in the article)
The reason it made me smile is that whilst I find myself agreeing with the whole conservative/liberal thing (I despise JavaScript, and yet fall firmly into the Hardcore liberal camp), my mind is still screaming "I'm unique/unclassifiable/obviously an outlier," and had to wonder how much a). my experience and b). my liking for Steve Yegge influences that juxtaposition.
It seems very subjective (and somewhat arbitrary) to assign labels of "conservative" or "liberal" to languages based largely on type safety. If this random blog post is taken as the definitive source of "conservative" vs "liberal" we get the following:
Twitter and Tumblr using Scala are "Hardcore conservative", while guys writing assembler for IBM mainframes are "Batshit liberal" ?
Exactly! I think assembly language falls through the cracks in this way of classification - languages themselves can be liberal/conservative, and the communities using them can be liberal/conservative. In the majority of cases, these two will be aligned. But in assembly code, there are a lot of different ways to screw things up (batshit liberal purely based on the risk profile of the language), so if you want code that works, you need to be extremely risk averse (conservative) from the outset.
I think it has less to do with the language and more with how you use it.
I would venture to say that anyone writing assembler would almost have to be completely conservative to make it work.
Something like Python could be written in conservative fashion (like the article alludes to with Google's style of python) or could be liberal in it's more idiomatic form.
"A measurement of length of a piece of writing, particularly when indicating a length excessive for the genre. A Yegge is approximately 4000 words or 25 kilobytes.
Named for well known programmer and technical blogger Steve Yegge, whose blog up to about 2009 was notorious for entries of approximately 1 or 2 Yegges in length, vastly exceeding the typical length of blog entries in the genre."
I was thinking about this sort of thing a few weeks ago. I think it's more about 'control' rather than 'safety'.
Heres my take:
fiscally conservative politician = tight control on spending
fiscally liberal politician = loose control on spending (just throw money at whatever, who cares)
fiscally conservative programmer = tight control over code (refactoring, design patterns, documentation, tests)
fiscally liberal programmer = loose control over code (who cares if it's spaghetti code, as long as it runs)
socially conservative politician = tight control over people (no abortions/gay marriage/legal weed for anyone)
socially liberal politician = loose control over people (let people do what they want)
socially conservative programmer = tight control over people (heavy process, waterfall)
socially liberal programmer = loose control over people (light process, agile, "just write good software")
I'm a socially liberal, fiscally conservative programmer. At my last job everyone was fiscally liberal and socially conservative. I did not last long at that job.
Honestly, I can't see it that way. People that I met and I know how they work and think don't fit in this axis at all. The distinction that I do see is between people that trusts experience of what works and what doesn't (and still willing to test new ideas when it makes sense) and people that rigidly adheres to policies or dogmas.
The type of tools they use and like are circumstantial. It's more of a empiricists vs. authority thing.
In the beginning I too wanted to write that I don't agree with this split. Then I come to conclusion that he met far more programmers then I so he probably knows better.
Anyway I'm not sure were to put myself on this axis. My behavior changes depending on other variables(what consequences would bug have/how many times code is going to be executed etc).
FE: critical part of commercial software (like money calculation) would be written in a way that would try to make it obvious that there are no errors, in language with type checking with unit tests and if possible even with mathematical proof of correctness. With code review and QA thrown at it afterwards. To sum up very conservative(and costly) approach.
On the other hand my holiday photos got completely different treatment. Short python script, that would batch their HDR process in a way specific for their content and with a lot of dependencies to my current desktop setup, without any unit tests(script thrown up few temporary files making it easy for manual debug, had backup of my photos in case script ate them). The only conservative thing that I could think of in this setup was that I made it concurrent to use 4 cores because it was only one line change and 4time speed up in lengthy process was worth it.
Can someone suggest were on liberal-conservative axis am I?
I think as a Ruby (and occasionally C) programmer I stand firmly in the liberal camp, but is it weird that I sort of like Haskell too? I find the idea of expressing the semantics of my program through types to be useful sometimes.
Then again my actually political views tend to span the liberal/conservative spectrum so I suppose this is not surprising.
Haskell is more liberal than ruby (functional programming)
C is more liberal than Haskell (weak typing)
Also, I am apparently a radically conservative programmer, but my political views in real life tend toward radical liberalism. I think any correlation says more about age than it does about politics.
> Not according to the article, which is what my comment was in response to.
I see. Yes, Haskell meets all the criteria for a conservative language, emphasizing safety, and verifiability, and automated testing. However, purely anecdotally, I can't think of a single person I've worked for that uses C++ approving of Haskell because it is so radically different. But perhaps this doesn't matter.
I tend to agree, on my own personal scale of liberal/conservative (which has little to do with type systems), I'd rank Haskell as fantastically liberal. You could probably enumerate the companies that use it in production on one hand.
Political talk and thinking is poisoned by the ideas of "left" and "right" even though those phrases haven't had a connection to reality since the French First Republic.
It'll probably be fine. Politics is in many respects a zero-sum game, and polarises participants into two camps. Software isn't like that.
The ideas expressed in the article ring fairly true to me. I wouldn't have couched them in political terms, because as you point out there is too much emotion in that arena. I tend to think of it as Engineers vs Artists. On the one hand you have Linus' think it through, do it right. On the other hand you have PG's explore, discover, express yourself style. Each method is valid in different situations.
So, this is the culmination of 8 years of rants and blog posts? This is what he's been trying to say all that time? What a peak he has reached. What an insight.
I'm trying to think of an apt analogy for this post that doesn't involve vomit or defecation, but it's hard. From the introduction proclaiming how readers will be stunned by how clearly and resoundingly true the revelation revealed within will be, to the literary diarrhea it's followed by... it's like a little kid proudly telling his parents he finally used the toilet properly only for them to find he completely missed the bowl. Yeah, I failed.
If the political spectrum is deeply flawed, as he said, then why even try to hack it onto something completely unrelated, made of individual technical points where each programmer may have a different approach?
I don't know, I like a lot of his past posts, but I don't dig this one. I don't think it provides any useful insight whatsoever.
I get the feeling his essay is setting the scene for more to come, most likely around Project Grok. The name is well suited, Yegge really understands how code works.
Why hack on it? Because it's what hackers do. Steve only pushes it further and hacks the philosophy of it. I love his essays as food for thought, and I respect him for publishing his in-process thoughts about the matter to let the idea out.
To me, this post was quite entertaining and broadened my perspective a little bit again. The only downside, as is the case with most of his other essays, is that it definitively wasn't long enough.
Go read the first comments from a sixteen year old social outcast who just read Atlas Shrugged for the first time. It's that, but with Yegge as the pimply protagonist and American politics playing the role of Objectivism.
Clojure is tied very strongly to the Java toolchain (note "toolchain" rather than "ecosystem"). The packaging system and package managers use Maven and Java jars instead of a clojure-based one.
This means that promising projects like Clojure CLR have no chance of taking off the ground, unlike say Ruby vs Jruby vs Ruby EE vs Rubinius.
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.
So this is the project that Yegge mentioned would turn "all code [...] into Wikipedia." Man, my ongoing project is more similar to it than I thought.
I find it curious that he would even bother to mention (IV) though. (IV) falls right out if you start from the correct data representation, which I would have assumed from (A). I wonder if he's still listing dependencies explicitly.
I think that a better parallel dichotomy would be features vs quality, in a world where they are mutually exclusive. However, I think Yegge wasted too much thought on this. It is the software that dictates how conservative a piece of software is: bugs and stability are generally tolerated in user-facing software because at worst the user has a bad experience. However, a database better be as close to 100% reliable as possible, which in turn leads to testing and static analysis, meaning typing... It is not really negotiable.
I think there are way too many variables for a linear scale to provide meaningful comparison.
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 arc...
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)
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.
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.
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.
> 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.
As much as some commenters are (weirdly?) railing against this classification scheme I think the underlying idea that software conservatism is about risk aversion is essentially accurate.
Perhaps another way of framing this is to ask the question: are you optimizing for the best case or the worst case? This ultimately is a form of risk management. And I'm not talking in the algorithmic sense, meaning complexity expressed as the asymptotically worst case. I'm talking about people, software and ecosystems.
Let me illustrate this idea with Java.
- C++ has operator overloads. Java does not? Why? Because people might abuse them. That's optimizing for the worst case (ie bad or inexperienced programmers). Properly used, operator overloading can lead to extremely readable code;
- Java has checked exceptions and uses them liberally (pun intended). C#, as one example, only has unchecked exceptions. Why? Philosophically the Java language designers (and many of its users) feel that this forces callers to deal with exceptions. Pragmatically (IMHO) it does not and leads to more cases of exceptions being simply swallowed. But again this is optimizing for the worst case ie programmers who should deal with a particular error condition but won't;
- Java has no multiple inheritance. Same story: it can be abused ("it is known"). But also mixins can be a powerful metaphor.
- Rinse and repeat for duck typing, extension methods, etc.
Putting Python two steps from Ruby strikes me as an interesting choice. I'd say the difference is at most one.
I'll also agree that Google as a company (based on my own much more limited experience than Yegge's) is firmly conservative. The style of writing Javascript that he refers to is about writing Google Closure code with all sorts of directives to aid the Closure Compiler (I describe Closure as putting the Java back into Javascript).
I also see a lot of Python code that isn't really Python. It's Java expressed in Python syntax rather than idiomatic Python and that is kind of sad.
Which isn't to say that any of this is necessarily bad (or good). It's just a (software) political viewpoint you need to be comfortable with (or at least can tolerate) or (to quote the South Park meme) "You're gonna have a bad time".
One of the comments linked Worse is Better [1], which is worth a read too.
I don't think Yegge is arguing anywhere that the language choice you make is tied into your overall corporate software "liberalness" or "conservativeness".
The "software liberal" companies he lists - Facebook and Amazon - both make heavy use of C++ (a "moderate-conservative" language to Yegge) and Amazon also uses Java heavily (another "moderate conservative" language.
Amazon's a bit lighter on the C++ these days and has quite a bit of Ruby.
As usual with Amazon, though, this is an area where it makes more sense to talk in terms of individual teams than the company as a whole. Some teams build almost everything in Ruby and are open to new languages. Others are pure Java shops. Other than Infosec approval, it's really up to teams to decide for themselves.
Tumblr and Twitter use Scala to solve their nice-to-have scalability problems using a services-based architecture. This is "core functionality must protected at all costs" conservatism.
They still have PHP and Rails (respectively) up front. This is "we like to roll out new user-facing features regularly" liberalism.
I don't think the main problem with operator overloading is "abuse"; I think it's that there's absolutely no way to know what a given clause of code might mean, even if the overloading has been defined by excellent coders.
I think it has more to do with expected outcomes. It's hard to argue that a + operator on a string or matrix class is a bad idea, because the outcome is intuitively obvious. For the other extreme see boost spirit for C++, which I'm sure was written by excellent coders.
Actually, it's not at all obvious what a + operator on a string does. Some languages think it means string concatenation. Others think it means convert the strings to numbers and add them.
It's pretty obvious what it means: + means call the + function. Well what does that mean? Probably something additive. Just like if it were called "add". You don't really know in either case unless you read the function.
The risk is that programmers might start using symbols in a way that is not obvious, but what is obvious is highly contextual. I'd prefer it not be the language designer who decides which operators are obvious enough to be allowed in my context.
Yegge took a massive shit on technical discourse, and if not countered, the ramifications thereof could be felt for years. His influence is disproportional to his value, and I am extremely disappointed to see anyone here taking his emotional arguments seriously.
Unless firmly censured, I expect to see Yegge's ridiculous viral meme of "liberal vs. conservative" spread and repeated by inexperienced developers indefinitely.
If I had any respect for Yegge, I entirely lost it here. The question of how to write software should be founded in careful consideration of specific problem domains, experience and research, and studied approaches. It should not be founded in some gross politicized and emotional argument.
Yegge is not just wrong, his reframing of engineering decision making is dangerous, and his ridiculous and viral engineering-as-politics meme makes people dumber for having simply read it. I'm disgusted with it, as well as any debate that seriously approaches his irrational appeal to emotion.
But look at all those comments Yegge is getting. He has long been an engaging, comedic writer with a very technical slant, but this really pushes him into the mainstream. People will look forward to the Steve Yegge show providing them entertainment in the same way Mike Daisey provides entertainment through The Agony and the Ecstasy of Steve Jobs.
From reading his other essays, it's obvious the guy has a broader perspective on programming than most software developers.
I believe it's experienced developers who will spread this because it takes experience in many different languages and paradigms to really understand what Steve described. I have different coding styles for Lisp, Haskell, D, Ruby and CoffeeScript for instance.
The foundations of software development are generally not well understood. Otherwise the vast majority of software out there would be more robust by a few orders of magnitude.
Steve at least offers a classification for the different styles found in programming communities today. He may not be right on spot, but at least it's a start.
The two-axis political classifications discards all reason and nuance in favor of us-vs-them media sound bites.
The idea of applying two-axis classification to software development would laughable if it wasn't so dangerous in its attractiveness as an oversimplified tribal mental model.
> Steve at least offers a classification for the different styles found in programming communities today. He may not be right on spot, but at least it's a start.
No. It's not a start. It's a dangerous, dangerous viral meme that threatens to replace rational dialog with ridiculous emotionally-driven opinionated politicized tribalism, and I can't help but wonder if that's his intent.
It's a play out of cable news' playbook, and I for one don't want an environment for engineering discourse modeled on American politics.
I couldn't think less of Yegge as an engineer and a thinker than I do now.
Ridiculous emotionally-driven opinionated politicized tribalism is already all over the place in software development. Compared to the other engineering disciplines, programming doesn't even fit this title most of the time.
What he describes doesn't introduces anything new to current behaviours, American Politics are already everywhere. While it's a gross overestimation to place whole languages in buckets just like that, it doesn't mean things have to fall in one bucket only.
For the Mars Rover, you want mission critical batshit conservative programming practices. The JPL coding standards do the job perfectly for that. On the other end of the spectrum, you've got Joe's webpage.
I completely agree with you about the bad image of american politics and the incomplete one dimensional line view. However, I do believe software development practices can be classified, it just needs to be in a tree or a graph instead.
In order to stop the current meaningless fights over using/doing something or not, lines have to be drawn somewhere. People don't know what these lines are and the industry is plagued with projects having to live with the wrong decisions.
He clearly mentions it's not like american politics and I agree on that. It can be useful to actually educate the industry on what exists so they use the right tool for the right job, which currently only rarely happens.
It doesn't encourage "good enough" practices, it promotes knowing when to use what. He got the idea right, he only omitted to mention that these line can split multiple dimensions.
My view may be colored by the fact that I'm a raging pragmatist about these sorts of issues who thinks that the right type of solution depends on the project and on the team (i.e. the right solution for mission-critical bank financial transaction processing is likely not also ideal for a high-velocity startup), but my impression was that the idea was for such an axis to be considered as a spectrum, not a simple dividing line for an us-vs-them holy war.
When interviewing and considering joining a team, envisioning a spectrum like this allows you to ask questions to see where a potential employer tends to fall on this spectrum, and thus determine whether it seems like a good fit for how you prefer to work and what you want to do.
And no, this is certainly not the only axis along which one can plot software development, and I doubt Mr. Yegge's goal was to propose that it was. At most it is an axis, and the goal would be for it to be a useful one when leveraged in the right context.
Can people take interesting ideas and horribly abuse them? Well, obviously. One might even argue that an idea that can't be abused by someone so inclined must not be very interesting at all.
I swear to God if someone ever asks me about political interests related to the way I develop software in an interview I'm going to take a dump on their desk.
Your comment about cable news made me think. The fact that he chose a political axis, and later
mentioned working on a project to make typing unecessary almost make me wonder if the choice of political axis was intentional (to stir discussion or push an agenda later).
Why not choose less loaded terms like formal/expressive like art uses?
> Steve at least offers a classification for the different styles found in programming communities today. He may not be right on spot, but at least it's a start.
Yeah, he really saved us there. Up until now we had no way of classifying different styles of programming...
I'm wondering how many other people read his essay and immediately thought of this:
I strongly agree: the article comes across as an attempt to solidify an emotional division between different kinds of software developers, and that never brings out the best in humanity.
Most people with any programming talent can learn to write software idiomatically in different styles if they try; making out there are different teams you have to support just makes that more difficult, and for no good reason.
Of course, said careful analysis of specific problem domains is then thrown around with wild abandon in an attempt to influence totally unrelated issues, causing confusion and havoc for years to come.
I don't see where you're getting "emotional arguments" from, the entire piece seemed more about scratching an intellectual itch more than anything else. On the other hand, it seems quite apparent he pushed the wrong emotional button on your end.
I mean his reframing is "dangerous"? Seriously? Who is in "danger"? And in danger of what? Having a contradictory viewpoint?
> I mean his reframing is "dangerous"? Seriously? Who is in "danger"? And in danger of what?
Danger of breaking down rational discourse and forward progress by reframing the debate in terms that leave no room for rational discourse. He's not discussing cost/benefits or reasoned analysis; he takes those as a given and attempts to recast engineering discussion as a political left vs right, with all the emotional baggage that comes with it.
It's dangerous because ideas have the power to transform minds, and irrational ideas that appeal to emotion and preconceptions are very powerful.
None of that has any meaning to me. "Leaves no room for rational discourse". How? What does that even mean? How is he blocking anyone? It's his opinion, he's not stopping anyone from making a counterpoint. "Cost/Benefit analysis". Have you done one? What would it even mean in this context? Would such an exercise even be meaningful? (Not snark, honest question)
You obviously disagree with his viewpoint/conclusion. Cool. So do I, somewhat, for very different reasons. Calling it "dangerous" just adds a lot of hyperbole that doesn't need to be there.
Would you be happier if he'd used different words? If, instead of talking about "politics" between "liberals" and "conservatives", he had made the same post about "differences in taste" between "caution-focused" and "momentum-focused" programmers? Because, you know, he could have said it that way, and it would have made as much sense, while probably being a hell of a lot less controversial -- but it would be the same blog post!
(Personally, I think I would have been happier if he'd used different words to say the same thing.)
He'd still have been wrong, since he argued from simplistic conclusions colored strongly by his own preconceived biases, and provided nothing to justify those conclusions.
There aren't just two 'sides', and the qualities proposed by Yegge can not be ascribed to just two sides. Different words would have made the post less insidious, but no less disingenious and intellectually stunted.
Most technical discourse turns into religious zealotry, and I think Yegge's observations are relatively true.
For instance, look at all the debates on static typing versus dynamic typing. If you break it down, it boils down to aesthetics and fuzzy feeling. It really does.
Interestingly, as I've aged, I've realized that our tools don't matter. All code turns into shit. At the end of the day thou, once you pick your tools, then it's the technologists job to ship products. How we ship products doesn't matter. All that matters is that we ship.
Do customers care if the technologists were "conservative" or "liberal"? They don't.
> For instance, look at all the debates on static typing versus dynamic typing. If you break it down, it boils down to aesthetics and fuzzy feeling. It really does.
It boils down to cost vs benefit, actual studies, and mathematical axioms, not aesthetics or feelings.
> How we ship products doesn't matter. All that matters is that we ship.
Engineering tools affect both how you ship, what you can ship, and when you can ship it. The choice isn't arbitrary, and choosing involves careful reasoned thought, informed by real experience -- not flippant arbitrary choices backed by feel-good platitudes that all approaches the same.
>It boils down to cost vs benefit, actual studies, and mathematical axioms, not aesthetics or feelings.
Its not quite that simple. Well performed studies that are actually relevant to a particular project are _difficult_ to come by. By well performed, I mean free of biases and misattributions and relevant to your particular use case. For example, most of the links in the answers here (http://programmers.stackexchange.com/questions/10032/dynamic...), a question specifically requesting studies them don't have any significant empirical data. Further, if you dig deeper its also clear that studies often contradict each other. Further, lets say you try to do a cost-benefit analysis. How? Try to estimate how many hours a particular technique will save you and you run into the same problem people have been trying to deal with for years. Estimating the time it takes to do a project is _hard_. Add to that how rapidly things are changing in this space and how dependent the structure of code is on the application of that code, and its clear that we really don't have objective metrics for this kind of thing.
>Engineering tools affect both how you ship, what you can ship, and when you can ship it. The choice isn't arbitrary, and choosing involves careful reasoned thought, informed by real experience
This is far more revealing of how these decisions are actually made. Your experience and thought process may very well be arbitrary when contrasted with real data. It might as well be aesthetics and fuzzy feeling.
"our tools don't matter. All code turns into shit " - most hilarious phrasing. I've recently adapted this philosophy and this helps me ship !!
ps : any chance of getting to see your blog archives ?
pps : this whole response thread has turned very religious !!!
I couldn't agree more. I shudder to think of a near future in which discussions include this "libral" or "conservative". I don't think it is nonsense because I think "it's a bad dichotomy for politics." I think it is bad because it is a poorly formed idea that reminds me of a high schooler learning some new thing and trying to apply it all over the place and see it everywhere like a psychoanalyst.
But the worst part about this is it is a pretty useless discussion despite the claims that this is some revolutionary culmination of a series of wildly over blog posts.
> I expect to see Yegge's ridiculous viral meme of "liberal vs. conservative" spread and repeated by inexperienced developers indefinitely.
It's worse than that. Just look at this thread. I'd say most HNers aren't inexperienced developers, and yet they seem to be taking Yegge's sophistry seriously.
And I don't think his post necessarily "makes people dumber" for having read it. That's only the case if people accept it without a modicum of critical sense. And if so that's their own damn fault.
So I agree that that post is of very low quality. But still, I admire Yegge. His genius here is to frame the discussion so that it disarms the natural geek propensity to read technical discussions with a critical sense.
> I'd say most HNers aren't inexperienced developers, and yet they seem to be taking Yegge's sophistry seriously
Bullshit. To the latter half, I mean, not the former. HN sees posts of more or less this type (the "make an essentially meaningless metaphor and see how far we can push it" type) quite often, plays with it for at most a couple weeks, and then forgets it ever happens. The "taking [it] seriously" you see here is likely to be that case again: HNers like playing around with basically any classification that anyone presents (cf. the math/corn post where even I felt compelled to throw in a quick comment) and then moving on to the next classification system someone presents. It doesn't mean they're going to now make all of their life decisions based on the classification of the week; it's just a bit of harmless fun.
Now, it's true that sometimes this does spread and gets to really silly levels but I see no reason to suspect that this is going to be in that camp rather than the "harmless fun" area.
He right about it being political, and about there being different contexts. The liberal & conservative labels unfortunately misframe the discussion in to a political context, and a bi-partisan one. Worse, he did it in the midst of election fever (gee, you think that is a coincidence?).
Basically, you can write off intelligent discourse for the next few months, but this too shall pass.
Yegge's discourse wasn't technical, and therefore shouldn't be countered. Your opinion of his value is subjective. And that pretty much demonstrates the validity of Yegge's "discourse" - writing software is a technical undertaking, but is performed by people. Who are social, and political.
I have never agreed more with a HN comment than this time.
This has to be the worst post by Yegge in terms of the negative impact it can have on software engineers and engineering.
He took a technical topic and labelled his belief system as "liberal" and the others as conservative. When some one proposes a technical approach he doesn't like, he can simply call him a "conservative-not that there is anything wrong with that".
Yegge is an average programmer at best. He wasn't able to maintain a simple 2D game and very easily blamed Java for it. It was a clear case of PEBKAC. It is absurd and unsurprising at the same time, that the simple act of blogging can some how elevate a programmer to expert status.
Yegge clearly has no idea what he is talking about. I am currently working with Scala which is apparently Hardcore conservative. Look at his characteristics of liberal languages.
1. Eval. - scala has a REPL, so u can do an eval if you wish.
2. Metaprogramming - scala macros
3. Dynamic scoping - No
4. all-errors-are-warnings - Meaningless bullet point, all languages encounter statements that it cannot meaningfully interpret. This statement just shows you Yegge's massive PL understanding deficit.
5. Reflection and dynamic invocation. RTTI - Scala has these.
6. The C preprocessor - Nope
7. Lisp macros - scala macros.
8. Domain-specific languages (for the most part). Optional parameters. Extensible syntax. Downcasting. Auto-casting. reinterpret_cast. Automatic stringification. Automatic type conversions across dissimilar types.
- all yes for scala. Infact, you can provide your own casts for any 2 types and import/export casts as you wish.
9. Nil/null as an overloaded semantic value (empty list, empty string, value-not-present) - Yes and No, Option[T] is generic. If you want to know if any container(including strings) is empty, you say container.isEmpty(). But not container == null.
10. Debuggers. Yes Scala has debuggers. At this point one has to ask - what is this guy smoking. If your language has a debugger it is a liberal language? WTF??
11. Bit fields - No
12. 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.
Yes, yes, yes for scala.
13. API compatibility modes. Advice and AOP. Convention in preference to explicit configuration.
These are fairly vague properties and you could say yes/no.
I recently converted a "liberal" perl project into "conservative" scala and the code size fell by an order of magnitude, but apparently I live in alternate universe where "conservative" languages are somehow more succinct.
This guy is just suffering from verbal diarrhoea and he gets way too much attention for his uninformed commentary. I haven't seen a more bogus classification in ages, it is quite amazing how he politicized a purely technical topic.
It is fairly clear what his issue is
1. He likes dynamically typed languages. You have to type less and lower error checking is tolerated by the community.
2. He is uncomfortable with more advanced PL concepts, cannot decipher compiler error messages when working languages like Haskell. He would much rather let the program run and crash with a run time stack, where he can jump in and examine the value or operation that caused the failure. The Haskell compiler error message makes him feel stupid and he does not like it. This also probably explains why he wants to dump clojure into conservative territory, too much of STM and Parallel Haskellish stuff going on.
3. He is not a big fan of java/C++.
There is nothing peculiar about the set of biases he has, in fact it is fairly typical. People who favor Java/C++ simply need high performance code that would need to be maintained/refactored for a long time. It is not a religious choice but a pragmatic decision in the face of constraints. I have never seen "conservatives" write build scripts in C++ or "liberals" write OS kernels in Ruby.
Maybe you are unaware, but Java's checked exceptions are generally seen as a mistake (only slightly less so than C++'s checked exceptions), and really only made sense for Java's originally intended purpose: embedded systems.
I'm trying to think of what anti-macros Clojure talk by a "key presenter" he might be referring to. I'm only familiar with the talks from Clojure/conj, so the only one that I can think of is Christophe Grand's (not= DSLs macros) talk from 2010[1]. If so, I think his summary mischaracterizes the content of that talk, but it could be another talk he's thinking of.
I'm fairly certain that's the one he's talking about. Having watched it live and on video, its message is not as dire as it's often made out to be. Regardless, it touches on a point of pride for Lisp programmers and as a result is viewed in a negative light by some. I offered a mild rebuttal at the following Conj called "The Macronomicon" (http://blip.tv/clojure/michael-fogus-the-macronomicon-597023...).
I think Christophe's is the talk, and Yegge seriously misunderstood it, if he even bothered to watch it. Christophe's point was that basing the underpinnings of a DSL on macros was frequently a mistake, vs a data + functions approach that "leads to greater dynamicity". It is inarguable that macros are less flexible than functions (e.g. they can't be applied) and less composable. Christophe's argument wasn't against macros, but that they should be the last layer of sugar, not the core mechanism of a DSL. This approach has been advocated and practiced by Lispers forever. Ditto the advice to not use a macro when a function will do.
And for Yegge to imply that more serious Clojure devs like Christophe are macro averse because they are afraid they might not understand someone else's macro code shows his complete lack of familiarity with Christophe's macro skills and other work of the community.
Taking potshots at things you don't understand and people you don't know (while leaving out the link so others could verify) smells like a FOX-news rhetorical approach to me. Ditto political labeling (though in the programming community the negative tag is "conservative", whilst in politics it is "liberal"). Tag the thing you don't like with the negative label, then rationalize, and spew misinformation. "Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types": surveys[0][1] say... nope.
He even ignores the bulk of his own criteria in his labeling exercise. Clojure has almost none of the things on his "Conservative Stuff" list except STM (huh, is GC conservative too?) and almost all of the things on his "Liberal Stuff" list. None of his 1-8 conservative points apply to Clojure (and I see nothing wrong with conservative about speed - Common Lisp has always pursued it, and its pursuit always involves risk), and all of his 9 liberal points apply to Clojure.
Clojure devs are liberals that want their programs to work.
If Yegge doesn't like Clojure, fine. But to rationalize like this is weak.
So, in 2008, you made a comment (below, emphasis mine) about reader macros (yes, which I realize are not identical to macros; please understand that I use a couple reader macros in my day-to-day coding process and am not naive as to their implementation or function) that, at least to me, pretty strongly supports the narrative that Steve is painting: that the goal I somehow "have fewer features that people are less likely to use wrong as otherwise it gets confusing".
> I am unconvinced that reader macros are needed in Clojure at this time. They greatly reduce the readability of code that uses them (by people who otherwise know Clojure), encourage incompatible custom mini-languages and dialects (vs namespace-partitioned macros), and complicate loading and evaluation.
FWIW, this is the same argument that comes up often, from many different members of the community. The namespacing argument is commonly included and sounds technical, but is also trivially solvable; as in, was already solved in a comment during the primary-cited discussion of reader macros on the #clojure IRC channel, but was then dismissed due to the real reason: that reader macros make your code less understandable to other people who know Clojure (the exact same form of argument Steve is talking about, one layer removed).
This is a brilliant move by Yegge. Now if you call him wrong, you're just like the guy who attacks Aunt Marge's politics at the family dinner.
Unfortunately, your business is not Aunt Marge. You need to be able to make the tough calls and say that, no, banning the color yellow is not a viable policy. Software engineering and programming languages are both seriously-studied disciplines, and all too often, the evidence comes down conclusively in favor of one position.
To pick an easy target, in many languages like Java and C++, null can be passed in place of (almost) any type. But
1) Empirical studies show that values intended to be non-nullable are more common...
2) ...which means that many method definitions are cluttered with is-null checks (to cut down the exponentially-increased state space)...
3) ...and it's just as easy to provide a feature to turn it on when it's wanted (option types/Maybe monad)...
4) ...which many companies hack into C++/Java anyway (various annotations and preprocessors)
This is a pretty solid case. Liberals win -- it's less code. Conservatives win -- there are fewer bugs. Sometimes things really are that one-sided.
Some of the tendencies depend upon the nature of the organization. Startups tend liberal (want to change the world). Corporations tend conservative (want to avoid major mistakes). The selection of tools does not always reflect this immediately though.
Also some classification of technology as conservative or liberal depends upon the competing technology it is running against. I was a bit surprised to see Python classified as liberal - but it makes sense when comparing it to Java. If it is being compared with Ruby it is very conservative ("do things one way").
There are some non technological risks that influence technology decisions. Visual Basic may be "Hardcore Liberal" from a language perspective, but it is pretty conservative politically (backed by Microsoft, lots of available experienced programmers).
Steve as usual has interesting insights. I am not sure that this is a paradigm that completely fits - but it does provide a perspective for understanding fundamental beliefs that can lead to disagreements in software projects.
The general risk-adverse vs. change-oriented paradigm makes a lot of sense. The problem is that it not limited to the technical realm in most organizations. Technology decisions often need to be justified by management who don't necessarily use purely technical criteria for their choices.
Some rather simple criteria can be used to group languages - age and popularity. Perl, JavaScript, Java, Visual Basic are conservative in that they are popular, well known, established languages (even though they cross the Yegge's whole spectrum). Haskell, while extremely conservative technically, is extremely liberal in many organizations - where there are no currently implemented projects using the language and no programmers experienced using it.
Now i understood why i love Common Lisp and hate Clojure.
It has nothing to do with Community or language. Its about Me. I'm a liberal. Knowing that i'm a liberal liberated me.
Hidden inside this fascinating screed is an announcement about the "Google Grok" project, which appears to be something of an Eclipse-killer for dynamic languages. It's good to hear that Google is working on this problem, and I'm interested to see what they come up with.
That was the most interesting point for me too. Mobile development has reminded me of the significant tooling benefits of static languages but also the verbosity and awkwardness of said languages. If I could have an IntelliJ-level IDE for Ruby or Python or JS I'd be very happy.
Steve's almost got it right that there are axes, but I think he tried too hard to fit it into a two party system.
I think instead there are the axes of safety, efficiency (which is almost the same as the next, but is more in the context of the C vs. C++ argument), speed/load of system (and tendency to develop to handle more load than is needed vs. less for the particular application), development speed/cleverness (typically dynamicism vs. static these days), clarity (which is not the opposite of cleverness), and verbosity.
185 comments
[ 3.0 ms ] story [ 138 ms ] threadPut another way, it's the political liberals who came up with OSHA (I hope--I'm somewhat ignorant of the actual history :P). A liberal or conservative outlook is not characterized by some particular processes or tools--it's characterized in an entirely relative way. The conservative approach is in choosing the familiar over the novel and in avoiding change. The familiar could be safer--Java vs Python--or it could be less safe--Java vs Haskell. I've talked to some ardent Java adherents, and they have lucid cases for not going over to Python or Ruby or Clojure or what have you. But--critically--these cases are virtually identical to their cases against going over to Haskell or Scala. There are differences in details, of course, but it's a difference in degree rather than kind.
Another even more extreme example is TDD. In particular, the arguments people have against adopting TDD are essentially exactly the same as I've seen from TDD supporters against using formal methods. Once again, some details differ, but the core idea seems to remain: some people are inherently wary of change.
It's also interesting to note how Yegge categorizes certain concepts in multiple "buckets". Either he's just being inconsistent (which is plausible) or he's making a deeper point: it's not about the particular concept, it's about the philosophy behind it. If he wasn't making that point, I've made it for him :).
That is, anything called "something calculus" is conservative, but lambdas (e.g. lambda calculus) aren't. Type-based functions overloading (like type classes, I guess) is conservative, but Scala implicits are liberal.
In my view, the languages that are the most conservative (at least in my part of the world) are Java and Python. Why? Simple: they are the default language for almost everyone I know. You're at an enterprisey company? You're probably using Java. You're at a startup? You're probably using Python. You're using C or Scheme or Haskell or Erlang? You're crazy. (I should note that I don't know very many people in systems or embedded programming, so my view is obviously rather biased.)
All this rambling (I certainly see why Yegge always writes long posts) has left me with a fairly concise conclusion. Namely, mapping programmer attitudes to a spectrum vaguely inspired by politics is a reasonable idea. Sure, the reality is that there is no total ordering so a one-dimensional representation is fundamentally lacking. However, it's good enough to give some insight.
But I would not map technologies there based on the technologies' innate traits. Rather, I would map them there based on the thinking behind the people who use them. This is similar to how--if you don't know the background--it's hard to guess which political party supports which regulation. Gun control is the opposite of liberal, but it's exclusively heralded by liberals; deregulation seems liberal but, of course, isn't. Yet, on other issues, people on either end of the spectrum behave as expected!
This is why I think languages like Java and Python are fairly conservative. Not because they try to offer some sort of safety but because they are safe choices. This is also why I would probably place C# as significantly more "liberal" than Java--it may be the most "conservative" .NET language, but it is far less afraid of embracing new ideas than Java. So that end is simple: at least for enterprisey companies and startups, it's populated with Python and Java. But what about the other end? I think this is where the languages that most people consider too crazy to use go. Haskell, Scheme, Erlang and so on. Only very brave--very liberal--companies are going to use Haskell or Scheme in actu...
Nixon[2] also tried to get Universal Health Care for all low-income and employed Americans, but it was blocked by Senator Edward Kennedy and other Democrats. Maybe politics[3] is just the art of getting the state to delegate property rights, even intellectual property, rather than itself productive pursuit.
I postulate[4] that discussions in political spectrum are no more a valuable expenditure of time and resources than painting styles being be a point of reference for programmers.
In summary this topic is an "Unknown or expired link" to me.
[1] https://en.wikipedia.org/wiki/Occupational_Safety_and_Health...
[2] https://en.wikipedia.org/wiki/Richard_Nixon
[3] https://en.wikipedia.org/wiki/Politics
[4] http://dictionary.reference.com/browse/postulate
Political parties evolve over time, sometimes quite drastically, as the political makeup of the country as a whole shifts and changes.
Emotions are not intentional, nor do they lead to rational behavior. (by definition). The translation of an emotion into a point-of-view depends purely on the context: it can swing any direction.
A conservative might be against war, because he/she is afraid it will make the world dislike the US more, and hurt his/her security more.
A progressive might be in favor of war, because he/she is afraid that without it, the world is worse off, and the potential for a better world is lost.
And from that perspective, I do consider the stated 'political' dimension a potentially relevant categorization of programmers' mentality.
But without knowing their background, there is no way to predict how they actually feel about specific approaches.
Java as a language is more conservative, definitely, but the Java ecosystem is definitely more liberal. As proof, compare Java's open-source community with .NET. Or compare the maturity of alternative JVM languages (e.g. Scala, Clojure, JRuby), with the alternatives running on top of .NET ; or compare the web frameworks available for each.
This is the reason why, when faced with a choice, a "liberal" developer will most likely pick Java over C#, even if C# as a language is more liberal.
I do not think this is an issue of liberals versus conservatives. It's actually an issue of pragmatism versus idealism.I'm pretty sure that many people wanted to use Haskell or Scheme in production, but then they'd shoot themselves in the foot, because the available libraries and tools for a language are far, far more important than the language itself. That's why Perl was so successful in the first place, because Perl hackers were getting shit done, then contributing to CPAN, which allowed other hackers to get their own shit done, and so on.
On the other hand I'm seeing lots of startups trying out and even using Clojure and Scala in production, at least for parts of the project. That's because these languages have all the Java libraries at their disposal, even if the languages themselves are still immature.
Don't mistake pragmatism for conservatism. That would be a mistake.
>>Or compare the maturity of alternative JVM languages I will not list Scala, Clojure and IronRuby, but IronPython is very mature. And: F#.
F# in my opinion is more mature than Scala.
OSHA, like the EPA, was started under/by Nixon.
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.
It's much cheaper to validate your idea that way and in the process you might end up with a hit like Angry Birds, which runs in the browser just fine.
As I mentioned, Carmack and Sweeney make engines, the artist interface is UnrealScript, or Lua, etc. But that's besides the point: performance matters. Carmack isn't trying to build yet another Box2D casual game (the Iphone Angry Birds uses a C implementation of Box2D, and Lua for game logic)
For someone like John Carmack, they are trying to push the state of the art, and starting off implementing say, idTech 7 in Python would yield unrealistic data if you're trying to see how feasible a given new rendering technique works on the large scale.
C is a typed language, there's no getting around it. It is in fact, a manifestly typed language, the types aren't optional. The fact that you can freely cast your way out of any situation doesn't really make it a dynamic language, anymore than Java reflection or bytecode rewriting makes Java a dynamic language.
The basic fact remains, the Mars rover is a highly performance critical piece of software with hard real time requirements, and it's simply not going to be written in a language that doesn't allow precise control over numeric types and memory allocation behavior. It's really those guarantees that many people associate with strongly typed systems programming languages, not the compile time checking.
Game programmers are very liberal, they want to escape straight jackets, and get deterministic and low level control over everything, often breaking the rules of the system. And in this regard, dynamic languages often taken away some freedom -- the freedom to control memory, stack, and cache behavior. They are conservative in a way.
C is statically and weakly typed language. That doesn't make it dynamic in the same sense as python or ruby, but it does make it a heck of a lot less safe, a heck of a lot more flexible, and thus a lot more liberal.
Well, this is where the rant misses the mark, I think. Whether some programming thing is Liberal or Conservative really depends on the context, how much is at stake and where you're currently pushing the envelope.
The code for the Mars Rover has to be ridiculously safe and conservative, since it cost billions, is deployed in a harsh environment and if it crashes you've lost the lot.
If you're hacking and validating some startup idea, then something that's bloated and poorly tested is fine, since it's likely to be wrong at first, and speed of development is more important than safety.
Both of these are safe choices, and they're the choices that you'd make, but they're at opposite ends of the spectrum... but you're the same developer.
He has 9 points for each side, but my take is that they're all true.
To make it clearer: By the standards of the article, C is quite liberal indeed. C++ is significantly more conservative.
IMHO, that's one the OP's main arguments, that for example there is a whole class of (liberal?!) people to which IDEs don't matter at all, so that someone (a conservative?!) arguing "hey, this static typing thingie makes IDEs more easy to use" doesn't matter. So it makes sense to at least know on which side of the fence each of us sits, so that we won't argue as much :)
(just to be clear, I'm trying to use the concepts "liberal" and "conservative" as they're defined in the article)
In my estimation, if the answer here is unclear, then this metaphor breaks hard.
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
Woud be nice to overlap James Iry's chart[1] with it...
[1] from http://james-iry.blogspot.com/2010/05/types-la-chart.html
The reason it made me smile is that whilst I find myself agreeing with the whole conservative/liberal thing (I despise JavaScript, and yet fall firmly into the Hardcore liberal camp), my mind is still screaming "I'm unique/unclassifiable/obviously an outlier," and had to wonder how much a). my experience and b). my liking for Steve Yegge influences that juxtaposition.
Twitter and Tumblr using Scala are "Hardcore conservative", while guys writing assembler for IBM mainframes are "Batshit liberal" ?
I would venture to say that anyone writing assembler would almost have to be completely conservative to make it work.
Something like Python could be written in conservative fashion (like the article alludes to with Google's style of python) or could be liberal in it's more idiomatic form.
"A measurement of length of a piece of writing, particularly when indicating a length excessive for the genre. A Yegge is approximately 4000 words or 25 kilobytes.
Named for well known programmer and technical blogger Steve Yegge, whose blog up to about 2009 was notorious for entries of approximately 1 or 2 Yegges in length, vastly exceeding the typical length of blog entries in the genre."
Heres my take:
fiscally conservative politician = tight control on spending
fiscally liberal politician = loose control on spending (just throw money at whatever, who cares)
fiscally conservative programmer = tight control over code (refactoring, design patterns, documentation, tests)
fiscally liberal programmer = loose control over code (who cares if it's spaghetti code, as long as it runs)
socially conservative politician = tight control over people (no abortions/gay marriage/legal weed for anyone)
socially liberal politician = loose control over people (let people do what they want)
socially conservative programmer = tight control over people (heavy process, waterfall)
socially liberal programmer = loose control over people (light process, agile, "just write good software")
I'm a socially liberal, fiscally conservative programmer. At my last job everyone was fiscally liberal and socially conservative. I did not last long at that job.
The type of tools they use and like are circumstantial. It's more of a empiricists vs. authority thing.
Anyway I'm not sure were to put myself on this axis. My behavior changes depending on other variables(what consequences would bug have/how many times code is going to be executed etc).
FE: critical part of commercial software (like money calculation) would be written in a way that would try to make it obvious that there are no errors, in language with type checking with unit tests and if possible even with mathematical proof of correctness. With code review and QA thrown at it afterwards. To sum up very conservative(and costly) approach.
On the other hand my holiday photos got completely different treatment. Short python script, that would batch their HDR process in a way specific for their content and with a lot of dependencies to my current desktop setup, without any unit tests(script thrown up few temporary files making it easy for manual debug, had backup of my photos in case script ate them). The only conservative thing that I could think of in this setup was that I made it concurrent to use 4 cores because it was only one line change and 4time speed up in lengthy process was worth it.
Can someone suggest were on liberal-conservative axis am I?
Then again my actually political views tend to span the liberal/conservative spectrum so I suppose this is not surprising.
Haskell is more liberal than ruby (functional programming)
C is more liberal than Haskell (weak typing)
Also, I am apparently a radically conservative programmer, but my political views in real life tend toward radical liberalism. I think any correlation says more about age than it does about politics.
Not according to the article, which is what my comment was in response to.
> I think any correlation says more about age than it does about politics.
Quite possible, I'm 26.
I see. Yes, Haskell meets all the criteria for a conservative language, emphasizing safety, and verifiability, and automated testing. However, purely anecdotally, I can't think of a single person I've worked for that uses C++ approving of Haskell because it is so radically different. But perhaps this doesn't matter.
Political talk and thinking is poisoned by the ideas of "left" and "right" even though those phrases haven't had a connection to reality since the French First Republic.
It'll probably be fine. Politics is in many respects a zero-sum game, and polarises participants into two camps. Software isn't like that.
I'm trying to think of an apt analogy for this post that doesn't involve vomit or defecation, but it's hard. From the introduction proclaiming how readers will be stunned by how clearly and resoundingly true the revelation revealed within will be, to the literary diarrhea it's followed by... it's like a little kid proudly telling his parents he finally used the toilet properly only for them to find he completely missed the bowl. Yeah, I failed.
If the political spectrum is deeply flawed, as he said, then why even try to hack it onto something completely unrelated, made of individual technical points where each programmer may have a different approach?
I don't know, I like a lot of his past posts, but I don't dig this one. I don't think it provides any useful insight whatsoever.
Why hack on it? Because it's what hackers do. Steve only pushes it further and hacks the philosophy of it. I love his essays as food for thought, and I respect him for publishing his in-process thoughts about the matter to let the idea out.
To me, this post was quite entertaining and broadened my perspective a little bit again. The only downside, as is the case with most of his other essays, is that it definitively wasn't long enough.
Conservative: the existing system must not break!
Progressive: we must add new features!
This means that promising projects like Clojure CLR have no chance of taking off the ground, unlike say Ruby vs Jruby vs Ruby EE vs Rubinius.
So this is the project that Yegge mentioned would turn "all code [...] into Wikipedia." Man, my ongoing project is more similar to it than I thought.
I find it curious that he would even bother to mention (IV) though. (IV) falls right out if you start from the correct data representation, which I would have assumed from (A). I wonder if he's still listing dependencies explicitly.
I think there are way too many variables for a linear scale to provide meaningful comparison.
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 arc...
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.
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.
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)
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.
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.
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.
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.
This manifesto, I believe I'll be pulling quotes out of it, for years to come.
Perhaps another way of framing this is to ask the question: are you optimizing for the best case or the worst case? This ultimately is a form of risk management. And I'm not talking in the algorithmic sense, meaning complexity expressed as the asymptotically worst case. I'm talking about people, software and ecosystems.
Let me illustrate this idea with Java.
- C++ has operator overloads. Java does not? Why? Because people might abuse them. That's optimizing for the worst case (ie bad or inexperienced programmers). Properly used, operator overloading can lead to extremely readable code;
- Java has checked exceptions and uses them liberally (pun intended). C#, as one example, only has unchecked exceptions. Why? Philosophically the Java language designers (and many of its users) feel that this forces callers to deal with exceptions. Pragmatically (IMHO) it does not and leads to more cases of exceptions being simply swallowed. But again this is optimizing for the worst case ie programmers who should deal with a particular error condition but won't;
- Java has no multiple inheritance. Same story: it can be abused ("it is known"). But also mixins can be a powerful metaphor.
- Rinse and repeat for duck typing, extension methods, etc.
Putting Python two steps from Ruby strikes me as an interesting choice. I'd say the difference is at most one.
I'll also agree that Google as a company (based on my own much more limited experience than Yegge's) is firmly conservative. The style of writing Javascript that he refers to is about writing Google Closure code with all sorts of directives to aid the Closure Compiler (I describe Closure as putting the Java back into Javascript).
I also see a lot of Python code that isn't really Python. It's Java expressed in Python syntax rather than idiomatic Python and that is kind of sad.
Which isn't to say that any of this is necessarily bad (or good). It's just a (software) political viewpoint you need to be comfortable with (or at least can tolerate) or (to quote the South Park meme) "You're gonna have a bad time".
One of the comments linked Worse is Better [1], which is worth a read too.
[1]: http://www.stanford.edu/class/cs240/readings/worse-is-better...
The "software liberal" companies he lists - Facebook and Amazon - both make heavy use of C++ (a "moderate-conservative" language to Yegge) and Amazon also uses Java heavily (another "moderate conservative" language.
As usual with Amazon, though, this is an area where it makes more sense to talk in terms of individual teams than the company as a whole. Some teams build almost everything in Ruby and are open to new languages. Others are pure Java shops. Other than Infosec approval, it's really up to teams to decide for themselves.
They still have PHP and Rails (respectively) up front. This is "we like to roll out new user-facing features regularly" liberalism.
The risk is that programmers might start using symbols in a way that is not obvious, but what is obvious is highly contextual. I'd prefer it not be the language designer who decides which operators are obvious enough to be allowed in my context.
Unless firmly censured, I expect to see Yegge's ridiculous viral meme of "liberal vs. conservative" spread and repeated by inexperienced developers indefinitely.
If I had any respect for Yegge, I entirely lost it here. The question of how to write software should be founded in careful consideration of specific problem domains, experience and research, and studied approaches. It should not be founded in some gross politicized and emotional argument.
Yegge is not just wrong, his reframing of engineering decision making is dangerous, and his ridiculous and viral engineering-as-politics meme makes people dumber for having simply read it. I'm disgusted with it, as well as any debate that seriously approaches his irrational appeal to emotion.
Yegge should be ashamed.
From reading his other essays, it's obvious the guy has a broader perspective on programming than most software developers.
I believe it's experienced developers who will spread this because it takes experience in many different languages and paradigms to really understand what Steve described. I have different coding styles for Lisp, Haskell, D, Ruby and CoffeeScript for instance.
The foundations of software development are generally not well understood. Otherwise the vast majority of software out there would be more robust by a few orders of magnitude.
Steve at least offers a classification for the different styles found in programming communities today. He may not be right on spot, but at least it's a start.
The idea of applying two-axis classification to software development would laughable if it wasn't so dangerous in its attractiveness as an oversimplified tribal mental model.
> Steve at least offers a classification for the different styles found in programming communities today. He may not be right on spot, but at least it's a start.
No. It's not a start. It's a dangerous, dangerous viral meme that threatens to replace rational dialog with ridiculous emotionally-driven opinionated politicized tribalism, and I can't help but wonder if that's his intent.
It's a play out of cable news' playbook, and I for one don't want an environment for engineering discourse modeled on American politics.
I couldn't think less of Yegge as an engineer and a thinker than I do now.
What he describes doesn't introduces anything new to current behaviours, American Politics are already everywhere. While it's a gross overestimation to place whole languages in buckets just like that, it doesn't mean things have to fall in one bucket only.
For the Mars Rover, you want mission critical batshit conservative programming practices. The JPL coding standards do the job perfectly for that. On the other end of the spectrum, you've got Joe's webpage.
I completely agree with you about the bad image of american politics and the incomplete one dimensional line view. However, I do believe software development practices can be classified, it just needs to be in a tree or a graph instead.
In order to stop the current meaningless fights over using/doing something or not, lines have to be drawn somewhere. People don't know what these lines are and the industry is plagued with projects having to live with the wrong decisions.
He clearly mentions it's not like american politics and I agree on that. It can be useful to actually educate the industry on what exists so they use the right tool for the right job, which currently only rarely happens.
It doesn't encourage "good enough" practices, it promotes knowing when to use what. He got the idea right, he only omitted to mention that these line can split multiple dimensions.
When interviewing and considering joining a team, envisioning a spectrum like this allows you to ask questions to see where a potential employer tends to fall on this spectrum, and thus determine whether it seems like a good fit for how you prefer to work and what you want to do.
And no, this is certainly not the only axis along which one can plot software development, and I doubt Mr. Yegge's goal was to propose that it was. At most it is an axis, and the goal would be for it to be a useful one when leveraged in the right context.
Can people take interesting ideas and horribly abuse them? Well, obviously. One might even argue that an idea that can't be abused by someone so inclined must not be very interesting at all.
Why not choose less loaded terms like formal/expressive like art uses?
Yeah, he really saved us there. Up until now we had no way of classifying different styles of programming...
I'm wondering how many other people read his essay and immediately thought of this:
http://www.youtube.com/watch?v=p20GYzCnfr0
Most people with any programming talent can learn to write software idiomatically in different styles if they try; making out there are different teams you have to support just makes that more difficult, and for no good reason.
I mean his reframing is "dangerous"? Seriously? Who is in "danger"? And in danger of what? Having a contradictory viewpoint?
Danger of breaking down rational discourse and forward progress by reframing the debate in terms that leave no room for rational discourse. He's not discussing cost/benefits or reasoned analysis; he takes those as a given and attempts to recast engineering discussion as a political left vs right, with all the emotional baggage that comes with it.
It's dangerous because ideas have the power to transform minds, and irrational ideas that appeal to emotion and preconceptions are very powerful.
You obviously disagree with his viewpoint/conclusion. Cool. So do I, somewhat, for very different reasons. Calling it "dangerous" just adds a lot of hyperbole that doesn't need to be there.
(Personally, I think I would have been happier if he'd used different words to say the same thing.)
There aren't just two 'sides', and the qualities proposed by Yegge can not be ascribed to just two sides. Different words would have made the post less insidious, but no less disingenious and intellectually stunted.
For instance, look at all the debates on static typing versus dynamic typing. If you break it down, it boils down to aesthetics and fuzzy feeling. It really does.
Interestingly, as I've aged, I've realized that our tools don't matter. All code turns into shit. At the end of the day thou, once you pick your tools, then it's the technologists job to ship products. How we ship products doesn't matter. All that matters is that we ship.
Do customers care if the technologists were "conservative" or "liberal"? They don't.
It boils down to cost vs benefit, actual studies, and mathematical axioms, not aesthetics or feelings.
> How we ship products doesn't matter. All that matters is that we ship.
Engineering tools affect both how you ship, what you can ship, and when you can ship it. The choice isn't arbitrary, and choosing involves careful reasoned thought, informed by real experience -- not flippant arbitrary choices backed by feel-good platitudes that all approaches the same.
Its not quite that simple. Well performed studies that are actually relevant to a particular project are _difficult_ to come by. By well performed, I mean free of biases and misattributions and relevant to your particular use case. For example, most of the links in the answers here (http://programmers.stackexchange.com/questions/10032/dynamic...), a question specifically requesting studies them don't have any significant empirical data. Further, if you dig deeper its also clear that studies often contradict each other. Further, lets say you try to do a cost-benefit analysis. How? Try to estimate how many hours a particular technique will save you and you run into the same problem people have been trying to deal with for years. Estimating the time it takes to do a project is _hard_. Add to that how rapidly things are changing in this space and how dependent the structure of code is on the application of that code, and its clear that we really don't have objective metrics for this kind of thing.
>Engineering tools affect both how you ship, what you can ship, and when you can ship it. The choice isn't arbitrary, and choosing involves careful reasoned thought, informed by real experience
This is far more revealing of how these decisions are actually made. Your experience and thought process may very well be arbitrary when contrasted with real data. It might as well be aesthetics and fuzzy feeling.
But the worst part about this is it is a pretty useless discussion despite the claims that this is some revolutionary culmination of a series of wildly over blog posts.
> I expect to see Yegge's ridiculous viral meme of "liberal vs. conservative" spread and repeated by inexperienced developers indefinitely.
It's worse than that. Just look at this thread. I'd say most HNers aren't inexperienced developers, and yet they seem to be taking Yegge's sophistry seriously.
And I don't think his post necessarily "makes people dumber" for having read it. That's only the case if people accept it without a modicum of critical sense. And if so that's their own damn fault.
So I agree that that post is of very low quality. But still, I admire Yegge. His genius here is to frame the discussion so that it disarms the natural geek propensity to read technical discussions with a critical sense.
Bullshit. To the latter half, I mean, not the former. HN sees posts of more or less this type (the "make an essentially meaningless metaphor and see how far we can push it" type) quite often, plays with it for at most a couple weeks, and then forgets it ever happens. The "taking [it] seriously" you see here is likely to be that case again: HNers like playing around with basically any classification that anyone presents (cf. the math/corn post where even I felt compelled to throw in a quick comment) and then moving on to the next classification system someone presents. It doesn't mean they're going to now make all of their life decisions based on the classification of the week; it's just a bit of harmless fun.
Now, it's true that sometimes this does spread and gets to really silly levels but I see no reason to suspect that this is going to be in that camp rather than the "harmless fun" area.
Basically, you can write off intelligent discourse for the next few months, but this too shall pass.
This has to be the worst post by Yegge in terms of the negative impact it can have on software engineers and engineering.
He took a technical topic and labelled his belief system as "liberal" and the others as conservative. When some one proposes a technical approach he doesn't like, he can simply call him a "conservative-not that there is anything wrong with that".
Yegge is an average programmer at best. He wasn't able to maintain a simple 2D game and very easily blamed Java for it. It was a clear case of PEBKAC. It is absurd and unsurprising at the same time, that the simple act of blogging can some how elevate a programmer to expert status.
Yegge clearly has no idea what he is talking about. I am currently working with Scala which is apparently Hardcore conservative. Look at his characteristics of liberal languages.
1. Eval. - scala has a REPL, so u can do an eval if you wish.
2. Metaprogramming - scala macros
3. Dynamic scoping - No
4. all-errors-are-warnings - Meaningless bullet point, all languages encounter statements that it cannot meaningfully interpret. This statement just shows you Yegge's massive PL understanding deficit.
5. Reflection and dynamic invocation. RTTI - Scala has these.
6. The C preprocessor - Nope
7. Lisp macros - scala macros.
8. Domain-specific languages (for the most part). Optional parameters. Extensible syntax. Downcasting. Auto-casting. reinterpret_cast. Automatic stringification. Automatic type conversions across dissimilar types. - all yes for scala. Infact, you can provide your own casts for any 2 types and import/export casts as you wish.
9. Nil/null as an overloaded semantic value (empty list, empty string, value-not-present) - Yes and No, Option[T] is generic. If you want to know if any container(including strings) is empty, you say container.isEmpty(). But not container == null.
10. Debuggers. Yes Scala has debuggers. At this point one has to ask - what is this guy smoking. If your language has a debugger it is a liberal language? WTF??
11. Bit fields - No
12. 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. Yes, yes, yes for scala.
13. API compatibility modes. Advice and AOP. Convention in preference to explicit configuration. These are fairly vague properties and you could say yes/no.
I recently converted a "liberal" perl project into "conservative" scala and the code size fell by an order of magnitude, but apparently I live in alternate universe where "conservative" languages are somehow more succinct.
This guy is just suffering from verbal diarrhoea and he gets way too much attention for his uninformed commentary. I haven't seen a more bogus classification in ages, it is quite amazing how he politicized a purely technical topic.
It is fairly clear what his issue is
1. He likes dynamically typed languages. You have to type less and lower error checking is tolerated by the community.
2. He is uncomfortable with more advanced PL concepts, cannot decipher compiler error messages when working languages like Haskell. He would much rather let the program run and crash with a run time stack, where he can jump in and examine the value or operation that caused the failure. The Haskell compiler error message makes him feel stupid and he does not like it. This also probably explains why he wants to dump clojure into conservative territory, too much of STM and Parallel Haskellish stuff going on.
3. He is not a big fan of java/C++.
There is nothing peculiar about the set of biases he has, in fact it is fairly typical. People who favor Java/C++ simply need high performance code that would need to be maintained/refactored for a long time. It is not a religious choice but a pragmatic decision in the face of constraints. I have never seen "conservatives" write build scripts in C++ or "liberals" write OS kernels in Ruby.
All...
On the other hand Python culture is ridiculously more conservative than Ruby culture.
[1] http://blip.tv/clojure/christophe-grand-not-dsl-macros-45407...
And for Yegge to imply that more serious Clojure devs like Christophe are macro averse because they are afraid they might not understand someone else's macro code shows his complete lack of familiarity with Christophe's macro skills and other work of the community.
Taking potshots at things you don't understand and people you don't know (while leaving out the link so others could verify) smells like a FOX-news rhetorical approach to me. Ditto political labeling (though in the programming community the negative tag is "conservative", whilst in politics it is "liberal"). Tag the thing you don't like with the negative label, then rationalize, and spew misinformation. "Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types": surveys[0][1] say... nope.
He even ignores the bulk of his own criteria in his labeling exercise. Clojure has almost none of the things on his "Conservative Stuff" list except STM (huh, is GC conservative too?) and almost all of the things on his "Liberal Stuff" list. None of his 1-8 conservative points apply to Clojure (and I see nothing wrong with conservative about speed - Common Lisp has always pursued it, and its pursuit always involves risk), and all of his 9 liberal points apply to Clojure.
Clojure devs are liberals that want their programs to work.
If Yegge doesn't like Clojure, fine. But to rationalize like this is weak.
Yawn.
[0] http://cemerick.com/2010/06/07/results-from-the-state-of-clo...
[1] http://cemerick.com/2012/08/06/results-of-the-2012-state-of-...
A bit of historical context from the last time this came up:
http://groups.google.com/group/seajure/browse_thread/thread/...
> I am unconvinced that reader macros are needed in Clojure at this time. They greatly reduce the readability of code that uses them (by people who otherwise know Clojure), encourage incompatible custom mini-languages and dialects (vs namespace-partitioned macros), and complicate loading and evaluation.
https://groups.google.com/forum/m/?fromgroups#!topic/clojure...
FWIW, this is the same argument that comes up often, from many different members of the community. The namespacing argument is commonly included and sounds technical, but is also trivially solvable; as in, was already solved in a comment during the primary-cited discussion of reader macros on the #clojure IRC channel, but was then dismissed due to the real reason: that reader macros make your code less understandable to other people who know Clojure (the exact same form of argument Steve is talking about, one layer removed).
Unfortunately, your business is not Aunt Marge. You need to be able to make the tough calls and say that, no, banning the color yellow is not a viable policy. Software engineering and programming languages are both seriously-studied disciplines, and all too often, the evidence comes down conclusively in favor of one position.
To pick an easy target, in many languages like Java and C++, null can be passed in place of (almost) any type. But
1) Empirical studies show that values intended to be non-nullable are more common...
2) ...which means that many method definitions are cluttered with is-null checks (to cut down the exponentially-increased state space)...
3) ...and it's just as easy to provide a feature to turn it on when it's wanted (option types/Maybe monad)...
4) ...which many companies hack into C++/Java anyway (various annotations and preprocessors)
This is a pretty solid case. Liberals win -- it's less code. Conservatives win -- there are fewer bugs. Sometimes things really are that one-sided.
Also some classification of technology as conservative or liberal depends upon the competing technology it is running against. I was a bit surprised to see Python classified as liberal - but it makes sense when comparing it to Java. If it is being compared with Ruby it is very conservative ("do things one way").
There are some non technological risks that influence technology decisions. Visual Basic may be "Hardcore Liberal" from a language perspective, but it is pretty conservative politically (backed by Microsoft, lots of available experienced programmers).
Steve as usual has interesting insights. I am not sure that this is a paradigm that completely fits - but it does provide a perspective for understanding fundamental beliefs that can lead to disagreements in software projects.
Some rather simple criteria can be used to group languages - age and popularity. Perl, JavaScript, Java, Visual Basic are conservative in that they are popular, well known, established languages (even though they cross the Yegge's whole spectrum). Haskell, while extremely conservative technically, is extremely liberal in many organizations - where there are no currently implemented projects using the language and no programmers experienced using it.
The company behind IntelliJ already makes IDEs for Ruby, Python and JS:
Python: Pycharm http://www.jetbrains.com/pycharm/
Ruby: RubyMine http://www.jetbrains.com/ruby/
JS: Webstorm http://www.jetbrains.com/webstorm/
I think instead there are the axes of safety, efficiency (which is almost the same as the next, but is more in the context of the C vs. C++ argument), speed/load of system (and tendency to develop to handle more load than is needed vs. less for the particular application), development speed/cleverness (typically dynamicism vs. static these days), clarity (which is not the opposite of cleverness), and verbosity.