4 ms·

The author asks WHY hasn't clojure caught on if it is great. I think I have a better answer than his conclusion that it aint popular because people shun things

The author asks WHY hasn't clojure caught on if it is great. I think I have a better answer than his conclusion that it aint popular because people shun things that aren't popular. (1) coding when EVERYTHING is immutable by default is a royal pain in the arse. (2) Coding directly in Abstract Syntax Trees is not pretty, there is a reason why most programming languages don't look like lisp.

eropple 9y ago
> coding when EVERYTHING is immutable by default is a royal pain in the arse Not sure I'd agree with that. Scala is a pain to write at times, but it's not because of the immutable data structures--indeed, the APIs are structured such that it's pretty painless. And while under the hood Kotlin's "immutable lists" aren't actually immutable (they're just ArrayLists, the interface is more akin to C#'s IReadOnlyList<T>), the API they present on top of it makes this pretty straightforward. In both cases, you can do mutable things, but it's extra work. I tend to think it's more of a Clojure-specific thing, and I think your #2 is more to the point: people don't use Clojure because it looks funny and is foreign to read for people who don't already know Lisps, that's all. (I've used Clojure, but I don't claim to "know" Clojure. YMMV.)
js8 9y ago
I have a different theory about this. Most people are practical and don't like too much abstractions. So any language that lets you make abstractions, no matter how beautiful it is internally, and no matter how useful they can be in coding, such as Lisp, Forth, Scheme, Haskell, Clojure.. (you name it) will not be popular, sadly. Weird thing is that functions are, for the most part, also a tool to make abstractions, but for some reason, the perception of them is different. I came to this conclusion after discussions with people I know who don't like these languages, and I now think it comes down to this.
dozzie 9y ago
> (1) coding when EVERYTHING is immutable by default is a royal pain in the arse. Is it really? Because I haven't noticed writing my Erlang.
TeMPOraL 9y ago
> (2) Coding directly in Abstract Syntax Trees is not pretty, there is a reason why most programming languages don't look like lisp. I think it is, but I'm biased :). Still, I don't think this is the reason. I believe it's simply because, due to accidents of history, C won the popularity contest, and most languages followed with (incrementally altered) C syntax to stay close to what's popular.
kazinator 9y ago
Coding in nearly the cleanest possible notation for abstract syntax trees is simply breathtaking. The reason a lot of programing languages don't look like Lisp is that most programming languages don't have anything interesting semantically going on. Their authors' primary source of intellectual pride is the work that went into the syntax. Part of it is CS education. It is drilled into the heads of CS undergraduates that programming language design involves tokenizing, and parsing with LALR(1) or what have you. The idea that you're going to have those pieces there if you design any language for any purpose is deeply ingrained, like the idea that no matter what you will be coding, you're going to have modules with functions that have local variables, and that there will be a edit-compile-debug cycle, and so on.

eropple 9y ago

> coding when EVERYTHING is immutable by default is a royal pain in the arse Not sure I'd agree with that. Scala is a pain to write at times, but it's not because of the immutable data structures--indeed, the APIs are structured such that it's pretty painless. And while under the hood Kotlin's "immutable lists" aren't actually immutable (they're just ArrayLists, the interface is more akin to C#'s IReadOnlyList<T>), the API they present on top of it makes this pretty straightforward. In both cases, you can do mutable things, but it's extra work. I tend to think it's more of a Clojure-specific thing, and I think your #2 is more to the point: people don't use Clojure because it looks funny and is foreign to read for people who don't already know Lisps, that's all. (I've used Clojure, but I don't claim to "know" Clojure. YMMV.)

js8 9y ago

I have a different theory about this. Most people are practical and don't like too much abstractions. So any language that lets you make abstractions, no matter how beautiful it is internally, and no matter how useful they can be in coding, such as Lisp, Forth, Scheme, Haskell, Clojure.. (you name it) will not be popular, sadly. Weird thing is that functions are, for the most part, also a tool to make abstractions, but for some reason, the perception of them is different. I came to this conclusion after discussions with people I know who don't like these languages, and I now think it comes down to this.

dozzie 9y ago

> (1) coding when EVERYTHING is immutable by default is a royal pain in the arse. Is it really? Because I haven't noticed writing my Erlang.

TeMPOraL 9y ago

> (2) Coding directly in Abstract Syntax Trees is not pretty, there is a reason why most programming languages don't look like lisp. I think it is, but I'm biased :). Still, I don't think this is the reason. I believe it's simply because, due to accidents of history, C won the popularity contest, and most languages followed with (incrementally altered) C syntax to stay close to what's popular.

kazinator 9y ago

Coding in nearly the cleanest possible notation for abstract syntax trees is simply breathtaking. The reason a lot of programing languages don't look like Lisp is that most programming languages don't have anything interesting semantically going on. Their authors' primary source of intellectual pride is the work that went into the syntax. Part of it is CS education. It is drilled into the heads of CS undergraduates that programming language design involves tokenizing, and parsing with LALR(1) or what have you. The idea that you're going to have those pieces there if you design any language for any purpose is deeply ingrained, like the idea that no matter what you will be coding, you're going to have modules with functions that have local variables, and that there will be a edit-compile-debug cycle, and so on.