4 ms·

Steve Yegge regarding Clojure (2012): " For a few years I had been really excited to start learning Clojure, and my initial experiences with it were quite posi

Steve Yegge regarding Clojure (2012): " For a few years I had been really excited to start learning Clojure, and my initial experiences with it were quite positive. However, I eventually learned that the Clojure community is extremely conservative. That is is pretty unusual for a Lisp dialect. Lisp is widely regarded as one of the most liberal language families in existence. And Clojure has the superficial appearance of being a laissez-faire kind of language. It is quite expressive, including a -- ahem -- liberal dose of new syntax. And it eschews static type annotations and strong type modeling in favor of a small set of highly regular, composable data types and operations -- not unlike, say, Scheme or Python. But the resemblance to a liberal language ends there. Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types (lots of puns today!) who happen to recognize the benefits of Lisp's tree syntax. So under its expressive covers, everything about Clojure is strongly conservative, with a core overriding bias towards protecting programmers from mistakes." https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz https://plus.google.com/110981030061712822816/posts/KaSKeg4v... He defines conservative: "I hope you'll agree that this definition is minimally controversial. After all, the adjective "conservative" is more or less synonymous with caution and risk aversion. Financial conservatism is frequently (and intuitively) associated with age and with wealth. " My own feeling is that he misunderstands functional programming. I could say "functional programming offers safety from side-effects" and then he might say "Yes, that is what I mean by conservative" but who wants to have their code undermined by uncontrolled side effects? By his definition, "conservative" applies to every programmer; which makes me think his definition is useless.

agentultra 13y ago
Side effects are useful. We use them all the time: IO, graphics, sockets, signals, etc. We even use mutable data because in certain cases it's more efficient. So I think I agree with Yegge there wrt, "conservative."
- JDShu 13y ago
  Nobody said that side effects aren't useful, as Rich Hickey would be the first to remind you. Clojure has full support for side effects and mutable data structures if you need it for efficiency. The point is that in Clojure, there are easy and idiomatic ways to control complexity by minimizing side effects and use of mutability.
- codygman 13y ago
  Not sure if it was your intention to imply so, but neither Clojure nor Haskell* eschew side effects. However Haskell provides tools to manage side effects. I'm not sure about Clojure since I haven't dove into that pool yet. * I mention Haskell since there is a lot of FUD going around about Haskellers not using side effects.
danenania 13y ago
I think the combination of expressiveness, flexibility, and safety that Yegge describes is exactly what clojure is aiming for, so he's actually giving it a huge unintentional complement. He simply doesn't like the goals of the language.
johnwalker 13y ago
> And it eschews static type annotations and strong type modeling I don't know that this is true. core.typed is really solid. > Clojure's community came pre-populated with highly conservative programmers from the pure-functional world" What does he have against Haskell? ;) Haskell is ahead of its time. I agree with Ikrubner here, that his definition of conservative is quite desirable. Additionally, people with experience in Ruby/Javascript/CL/Python make up the majority of the community.
eigenrick 13y ago
The motivation of Clojure, to me, is making concurrency safe and easy. So far, the best way to reduce "risk" in concurrent systems is to constrain side effects, and not share mutable state between units of concurrency. If you're choosing to reduce the number of side effects, then a functional language is clearly the best suited for the job. The creators of Erlang knew this. The creators of Haskell discovered(?) this. In my opinion, the fact that Clojure is a lisp is completely irrelevant, personally I prefer ML-family syntax, but the consistent standard library of Clojure makes it too powerful to ignore. The focus on concurrent programming is also indicated by its relaxed stance of side effects. It is not a pure language, it only sets the constraint that you cant have side effects that leak state into other units of concurrency. If your mutations don't create a risk of data loss, then you are welcome to use them.
wes-exp 13y ago
I agree with Yegge on this: I think the true strength and weakness of Clojure is its FP safety, which is probably great for many specific applications but comes across to me as needlessly ceremonious and conservative for typical applications. I personally prefer something multi-paradigm like CL where I can happily use, for example, variable assignment (setf) and write "liberal" code.
mtdewcmu 13y ago
I posted that article to HN, but it didn't get any votes. I know very little about Clojure, but I think the conservative/liberal dichotomy he describes is very real. Liberalism and conservativism in software are closely related to liberalism and conservativism in politics. The description of conservativism in that quote is not terribly insightful, because he's obviously going out of his way not to offend anybody, so he made it excessively simple and superficial. To get a good handle on how conservativism manifests itself in software, ideally you'd need a subtle appreciation of how it manifests itself in politics; less in terms of dry theory and more in terms of the character traits and basic orientation toward life that precede adopting conservative views. Yegge speculates that someone could be a liberal in software and a conservative in politics or vice versa, but I kind of doubt this. If it does occur, it's probably in borderline cases, or in cases where somebody may be truly a conservative deep down, say, but is not engaged enough in politics to have realized it yet, or they side with the left politically as a result of specific issues rather than temperament (e.g. the person is a racial minority). You could say that conservatives, both in software and politics, tend to be sticklers for rules and structure. That may be enough to shed some light on the difference as a practical matter. But I think that doesn't really get to the essence. Liberals can also be for rules and structure. What differs is the nature of the rules and who they apply to. I think it's closer to the truth to say that conservatives generally distrust people. In politics this general distrust manifests as, e.g. opposition to social welfare programs, because of the belief that people will invariably take advantage and abuse them. In software, the distrust manifests as, e.g. opposing programming languages and language constructs that are too laid-back and give the programmer too much freedom. The belief is that programmers, in general, can't be trusted to make good choices, and will invariably write bad code if they're allowed to.

agentultra 13y ago

Side effects are useful. We use them all the time: IO, graphics, sockets, signals, etc. We even use mutable data because in certain cases it's more efficient. So I think I agree with Yegge there wrt, "conservative."

JDShu 13y ago
Nobody said that side effects aren't useful, as Rich Hickey would be the first to remind you. Clojure has full support for side effects and mutable data structures if you need it for efficiency. The point is that in Clojure, there are easy and idiomatic ways to control complexity by minimizing side effects and use of mutability.
codygman 13y ago
Not sure if it was your intention to imply so, but neither Clojure nor Haskell* eschew side effects. However Haskell provides tools to manage side effects. I'm not sure about Clojure since I haven't dove into that pool yet. * I mention Haskell since there is a lot of FUD going around about Haskellers not using side effects.

danenania 13y ago

I think the combination of expressiveness, flexibility, and safety that Yegge describes is exactly what clojure is aiming for, so he's actually giving it a huge unintentional complement. He simply doesn't like the goals of the language.

johnwalker 13y ago

> And it eschews static type annotations and strong type modeling I don't know that this is true. core.typed is really solid. > Clojure's community came pre-populated with highly conservative programmers from the pure-functional world" What does he have against Haskell? ;) Haskell is ahead of its time. I agree with Ikrubner here, that his definition of conservative is quite desirable. Additionally, people with experience in Ruby/Javascript/CL/Python make up the majority of the community.

eigenrick 13y ago

The motivation of Clojure, to me, is making concurrency safe and easy. So far, the best way to reduce "risk" in concurrent systems is to constrain side effects, and not share mutable state between units of concurrency. If you're choosing to reduce the number of side effects, then a functional language is clearly the best suited for the job. The creators of Erlang knew this. The creators of Haskell discovered(?) this. In my opinion, the fact that Clojure is a lisp is completely irrelevant, personally I prefer ML-family syntax, but the consistent standard library of Clojure makes it too powerful to ignore. The focus on concurrent programming is also indicated by its relaxed stance of side effects. It is not a pure language, it only sets the constraint that you cant have side effects that leak state into other units of concurrency. If your mutations don't create a risk of data loss, then you are welcome to use them.

wes-exp 13y ago

I agree with Yegge on this: I think the true strength and weakness of Clojure is its FP safety, which is probably great for many specific applications but comes across to me as needlessly ceremonious and conservative for typical applications. I personally prefer something multi-paradigm like CL where I can happily use, for example, variable assignment (setf) and write "liberal" code.

mtdewcmu 13y ago

I posted that article to HN, but it didn't get any votes. I know very little about Clojure, but I think the conservative/liberal dichotomy he describes is very real. Liberalism and conservativism in software are closely related to liberalism and conservativism in politics. The description of conservativism in that quote is not terribly insightful, because he's obviously going out of his way not to offend anybody, so he made it excessively simple and superficial. To get a good handle on how conservativism manifests itself in software, ideally you'd need a subtle appreciation of how it manifests itself in politics; less in terms of dry theory and more in terms of the character traits and basic orientation toward life that precede adopting conservative views. Yegge speculates that someone could be a liberal in software and a conservative in politics or vice versa, but I kind of doubt this. If it does occur, it's probably in borderline cases, or in cases where somebody may be truly a conservative deep down, say, but is not engaged enough in politics to have realized it yet, or they side with the left politically as a result of specific issues rather than temperament (e.g. the person is a racial minority). You could say that conservatives, both in software and politics, tend to be sticklers for rules and structure. That may be enough to shed some light on the difference as a practical matter. But I think that doesn't really get to the essence. Liberals can also be for rules and structure. What differs is the nature of the rules and who they apply to. I think it's closer to the truth to say that conservatives generally distrust people. In politics this general distrust manifests as, e.g. opposition to social welfare programs, because of the belief that people will invariably take advantage and abuse them. In software, the distrust manifests as, e.g. opposing programming languages and language constructs that are too laid-back and give the programmer too much freedom. The belief is that programmers, in general, can't be trusted to make good choices, and will invariably write bad code if they're allowed to.