5 ms·

I love Clojure, and I use it in every project where I have control over the technology, but I do agree with the points raised by Ashton Kemerling. Clojure is b

I love Clojure, and I use it in every project where I have control over the technology, but I do agree with the points raised by Ashton Kemerling. Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. In some sense, you could say this is what happened to Ruby, though there the allowance of "special cases" was more deliberate. I recall, back in 2003, reading the interview between Matsumoto and Bill Venners: http://www.artima.com/intv/ruby.html http://www.artima.com/intv/ruby.html -- and I thought that Ruby had a beautiful philosophy. But having worked with Ruby for many years, I now see how much it is undermined by the many special cases it allows, and the wild ambushes that its most imaginative features allow (monkey patching). I don't want to see Clojure go down that path. I want Clojure to remain beautiful, and that means the implementations must also be beautiful. There is a limit on how much the core team can say "That bug is only an implementation detail". If you take away all the implementation details, then Clojure is only a theory, not a real technology that can be used by real people to do real things. In a truly ideal world, Clojure could be the practical Lisp that pushes itself to bring in as much of the experimental Lisp's beauty as is practical. I would love to see the best ideas from Racket and what Fogus refers to as the Fluchtpunkt Lisps: http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/ http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/ These are ideas that can make the world better. I have high hopes that Clojure will be the project that makes some of these beautiful ideas practical. I will be very sad if Clojure ends up like Ruby or Groovy or Scala, becoming a bit too muddy to reach its full potential.

agumonkey 10y ago
I kinda despise non dogfooding projects. Like realizing that IBM rarely ever uses it's own modeling tools and principles to develop internal or commercial software (at least arount that time). And yes I liked lisp because of its underlying beauty. Scheme did one step further. It reuses itself in many ways. That clojure implementation isn't leveraging it's own quality feels unlispy but alas... it's also a huge effort to blend an immutable first lisp onto a JVM ecosystem. Reminds me of Scala a bit.. one lead dev quit over frustration about the state of the compiler. Maybe seeking 'beauty' is just an immature phase and after a while whatever works enough for you to sell ...
- daxfohl 10y ago
  Well there's a difference between dogfooding and self-hosting. The Clojure team uses Clojure all the time. They just don't use all aspects of Clojure on Clojure itself. For quite some time golang specifically set self-hosting as a non-goal. The rationale was that C beat go in many areas that were important to compilers (raw speed, I would guess, initially). It's only recently that they started self-hosting. So just because you can self-host doesn't mean you should. The benefits have to outweigh the cons. Like any project, choose the best language for the job. That said, I have no idea whether the Clojure system would be better off using more of its own features or not.
catnaroek 10y ago
I don't see what Ruby's “beautiful philosophy” is. Here are some examples of philosophies I actually consider beautiful, regardless of the result they led to: (0) Lisp, Scheme, Forth: “A small extensible core language beats a fixed large language.” (While Common Lisp is actually pretty large, there's a rather small subset of it from which the rest can be built.) (1) ML, Haskell: “Let's see how much we can do using types as our primary abstraction enforcement mechanism.” (2) C++, Rust: “Abstraction isn't at odds with efficiency and fine-grained control.” (Runtime enforcement is, though.) What does Ruby have to offer? Matsumoto claims to prioritize “developer happiness”, but allowing arbitrary modifications to arbitrary parts of any program doesn't make everyone happy. And, even if it did, “developer happiness” isn't a technical criterion anyway.
- ZenoArrow 10y ago
  > "And, even if it did, “developer happiness” isn't a technical criterion anyway." It's a guiding principle, it doesn't have to be a technical one. For what it's worth, I'd say Elm also has this philosophy, possibly Elixir too (though I'm not as familiar with Elixir).
- rauljara 10y ago
  I'll bite. Ruby has a beautiful and consistent object / module system, a beautiful integration of functional and object oriented programming paradigms, and extreme powerful metaprogramming. All of those things are pretty wrapped up in its design philosophy which contains a whole bunch more than developer happiness. Yes, Ruby has warts. So do all the other languages you listed. It is helpful to be able to see both the good and bad in languages and not get hung up battling them against each other.
  - catnaroek 10y ago
    > Ruby has a beautiful and consistent object / module system, I don't program much with objects, so I don't know what to expect from them, but after programming in a language that treats modules seriously (Standard ML), I can't accept anything less than the following from anything that calls itself a “module system”: (0) Implementor-side abstraction: Fine-grained control over which implementation details are exposed to different parts of a program. (1) Client-side abstraction: The ability to define a module as a function of another, yet to be supplied, module. Ruby's “module system” doesn't quite cut it. > a beautiful integration of functional and object oriented programming paradigms Functional programming in Ruby is possible, but a gigantic pain: (0) Partially applied functions are mildly inconvenient. (1) Higher-order functions that recursively pass themselves a modified version of their function argument(s) are not so mildly inconvenient. (2) Now imagine actually debugging such beasts when you make a mistake. Unit tests don't help because they overemphasize the concrete cases, when higher-order functions are all about abstracting as much as possible. At a more fundamental level, functional programming is value-oriented, and programming with compound values (not the same thing as compound objects) in Ruby isn't the path of least resistance, to put it mildly. > Yes, Ruby has warts. So do all the other languages you listed. I wasn't commenting on the languages themselves, but rather the philosophy of their designers. C++ has more than “warts” - the language as a whole is a monstrous abomination, but the philosophy of not accepting unneeded performance overheads is aesthetically pleasing IMO.
_pmf_ 10y ago
> Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. A bit like communism. Whenever I watch one of Rich Hickey's signature talks, I'm enthused, but actually looking and using the concepts leaves a rather stale taste compared to the promise.

agumonkey 10y ago

I kinda despise non dogfooding projects. Like realizing that IBM rarely ever uses it's own modeling tools and principles to develop internal or commercial software (at least arount that time). And yes I liked lisp because of its underlying beauty. Scheme did one step further. It reuses itself in many ways. That clojure implementation isn't leveraging it's own quality feels unlispy but alas... it's also a huge effort to blend an immutable first lisp onto a JVM ecosystem. Reminds me of Scala a bit.. one lead dev quit over frustration about the state of the compiler. Maybe seeking 'beauty' is just an immature phase and after a while whatever works enough for you to sell ...

daxfohl 10y ago
Well there's a difference between dogfooding and self-hosting. The Clojure team uses Clojure all the time. They just don't use all aspects of Clojure on Clojure itself. For quite some time golang specifically set self-hosting as a non-goal. The rationale was that C beat go in many areas that were important to compilers (raw speed, I would guess, initially). It's only recently that they started self-hosting. So just because you can self-host doesn't mean you should. The benefits have to outweigh the cons. Like any project, choose the best language for the job. That said, I have no idea whether the Clojure system would be better off using more of its own features or not.

catnaroek 10y ago

I don't see what Ruby's “beautiful philosophy” is. Here are some examples of philosophies I actually consider beautiful, regardless of the result they led to: (0) Lisp, Scheme, Forth: “A small extensible core language beats a fixed large language.” (While Common Lisp is actually pretty large, there's a rather small subset of it from which the rest can be built.) (1) ML, Haskell: “Let's see how much we can do using types as our primary abstraction enforcement mechanism.” (2) C++, Rust: “Abstraction isn't at odds with efficiency and fine-grained control.” (Runtime enforcement is, though.) What does Ruby have to offer? Matsumoto claims to prioritize “developer happiness”, but allowing arbitrary modifications to arbitrary parts of any program doesn't make everyone happy. And, even if it did, “developer happiness” isn't a technical criterion anyway.

ZenoArrow 10y ago
> "And, even if it did, “developer happiness” isn't a technical criterion anyway." It's a guiding principle, it doesn't have to be a technical one. For what it's worth, I'd say Elm also has this philosophy, possibly Elixir too (though I'm not as familiar with Elixir).
rauljara 10y ago
I'll bite. Ruby has a beautiful and consistent object / module system, a beautiful integration of functional and object oriented programming paradigms, and extreme powerful metaprogramming. All of those things are pretty wrapped up in its design philosophy which contains a whole bunch more than developer happiness. Yes, Ruby has warts. So do all the other languages you listed. It is helpful to be able to see both the good and bad in languages and not get hung up battling them against each other.
- catnaroek 10y ago
  > Ruby has a beautiful and consistent object / module system, I don't program much with objects, so I don't know what to expect from them, but after programming in a language that treats modules seriously (Standard ML), I can't accept anything less than the following from anything that calls itself a “module system”: (0) Implementor-side abstraction: Fine-grained control over which implementation details are exposed to different parts of a program. (1) Client-side abstraction: The ability to define a module as a function of another, yet to be supplied, module. Ruby's “module system” doesn't quite cut it. > a beautiful integration of functional and object oriented programming paradigms Functional programming in Ruby is possible, but a gigantic pain: (0) Partially applied functions are mildly inconvenient. (1) Higher-order functions that recursively pass themselves a modified version of their function argument(s) are not so mildly inconvenient. (2) Now imagine actually debugging such beasts when you make a mistake. Unit tests don't help because they overemphasize the concrete cases, when higher-order functions are all about abstracting as much as possible. At a more fundamental level, functional programming is value-oriented, and programming with compound values (not the same thing as compound objects) in Ruby isn't the path of least resistance, to put it mildly. > Yes, Ruby has warts. So do all the other languages you listed. I wasn't commenting on the languages themselves, but rather the philosophy of their designers. C++ has more than “warts” - the language as a whole is a monstrous abomination, but the philosophy of not accepting unneeded performance overheads is aesthetically pleasing IMO.

_pmf_ 10y ago

> Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. A bit like communism. Whenever I watch one of Rich Hickey's signature talks, I'm enthused, but actually looking and using the concepts leaves a rather stale taste compared to the promise.