3 ms·

> I'm conservative because I dislike complexity Except a lot of conservatism as defined here is all about complexity in terms of 'big design up front' methodol

by derleth 14y ago

> I'm conservative because I dislike complexity Except a lot of conservatism as defined here is all about complexity in terms of 'big design up front' methodology and, really, having a big methodology in the first place, along with having a lot of testing and static analysis tools. Ada is a conservative language. C is extremely, red-diaper liberal.

michaelochurch 14y ago
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.
- ralfn 14y ago
  >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)
- thwarted 14y ago
  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.
- tesseractive 14y ago
  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.

by derleth 14y ago

michaelochurch 14y ago

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.

ralfn 14y ago
>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)
thwarted 14y ago
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.
tesseractive 14y ago
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.