6 ms·

Massive problem? That's news to me. But what do I know, I've only been writing Lisp for more than a decade. On the other hand, the Clojure kids seem to reinven

Massive problem? That's news to me. But what do I know, I've only been writing Lisp for more than a decade. On the other hand, the Clojure kids seem to reinvent programming badly while maligning other Lisps (see blog post), so maybe they do have a massive problem with trivial things like indentation.

dan-robertson 6y ago
I think the Clojure people tend to be pretty thoughtful about language design and doing things in ways that will be functional and composable. Common Lisp is a language with a lot of warts where many features were tacked on but not properly integrated with everything else. It also suffers from the concerns and technology of the 1980s (a big focus on mutability, no multithreading in the spec, the pathnames library, no immutable maps, to name a few.) Scheme is minimal and that can be an advantage but Clojure has different goals to scheme
- bluefox 6y ago
  I think the Clojure people tend to produce unreadable mess, which tells me the design of their language is down in the gutter. Common Lisp is a language with a lot of warts, sure, but typical Common Lisp code is way, way, way more tasteful than typical Clojure code. We like our multiparadigmness, thank you very much. That includes being able to mutate things. We also like that the language is stable, and that means no changes to the spec, and that means it won't cover everything. That's OK, because our spec covers more than enough. We have less stable libraries and implementation-specific interfaces to cover the rest. We are still pretty conservative with those, too. Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since no real Clojure programs can run on it, because JVM is part of Clojure, really...) and once things are documented they either stick forever or break. I wouldn't say Clojure has warts; it has massive oozing injuries that keep on spreading indefinitely. So yeah, we'd rather live with the warts from the 90s, the 80s, the 70s, and the 60s. We like our tradition, and we like our programs not breaking. We have a stable base that we can build 2020, 2030, 2040 stuff on.
  - dustingetz 6y ago
    typical clojure is a mess because it actually gets used in industry by junior devs and such
    - bluefox 6y ago
      If true, that is a point for Clojure. It keeps the inexperienced on a distinct path where some day, when they're battle-worn and wise and had enough of it, they may find it was a road to Lisp after all.
      - dustingetz 6y ago
        i think you're looking for the principle agent problem aka middle management wrecking everything
    - didibus 6y ago
      > typical clojure is a mess That's a claim that would need to be substantiated first. My experience is that typical Clojure is quite descent actually.
  - m45t3r 6y ago
    > Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since no real Clojure programs can run on it, because JVM is part of Clojure, really...) It is true that Clojure doesn't have a spec, but it is very stable. I saw some very minor breaking changes in Clojure, and most code just works after a update (including very big projects). Clojure is very conservative in general, and this is something that Rich says as a explicit design goal. BTW, are you referring to ClojureScript? Because ClojureScript is far from a toy language, it works well and we use in production. Sure it have some warts, but they're mostly workable and while I am not a fan, I am not a fan of frontend in general so this is probably part of the problem.
    - bluefox 6y ago
      I was thinking about ClojureCLR. While my argument could be applied to ClojureScript, I did not think it was fair because ClojureScript calls itself a (proper) subset of Clojure, which is fine and no one expects it to run actual Clojure programs. Again, I apologize for undue harshness.
- reikonomusha 6y ago
  I really consider your comment to be FUD about Common Lisp. The language is not so aesthetic in many places, but the language was very certainly thoughtfully designed and iterated on. Features by and large work surprisingly well together to form a cohesive language. I don’t agree about things being “tacked on”, which is voluminously evidenced in the discussions about each and every feature. The standard could have been bigger and more comprehensive. But it’s just a non-problem most of the time. Threading is de facto standard and extremely well understood in its interactions with Common Lisp as defined. Common Lisp is an extremely capable language to get things done cleanly. It just does things in a way that simply feels different from later languages. If you want to talk about bolted on features, look no further than the plethora of Scheme libraries.
  - dan-robertson 6y ago
    I’ve written a lot of Common Lisp and I while there was obviously a lot of thought that went into its design, I wouldn’t call it cohesive. Why are streams not CLOS objects (in the spec; I know about gray-streams)? Why can’t equality operators be extended to user-defined types? Why does the language even need so many equality operators and specialised functions like sbref? Why have both setf function names and a load of functions like rplca? Why is a setf function name invalid as the car of a form, even though only expressions (apart from atoms and lambdas) are disallowed? Why can’t the user make hash tables work for their own data-types? Why aren’t structs a first-class part of the object system like classes (unless you have the MOP)? Why can’t you have anonymous classes even though you can have anonymous functions and objects whose class was replaced with a new definition? Why can’t the user extend the sequence functions like map with their own sequences? Why are arrays so custom compared to the rest of the object system? Why pathnames? Why do so many things have bad names (e.g. getf and putf vs setf, set and get and setq, ...) If your answer is performance or compatibility with 1980s operating systems or lisp implementations, then sure that’s a reason for the design but it doesn’t make the design cohesive, complete and composable. I think CL is a good language despite this rather than because of it and I would suggest that your claim of it working “surprisingly well” supports that.
    - kazinator 6y ago
islon 6y ago
It's such a "massive" problem I've been doing CLojure full time for the past 8 years and only heard about it now.
- bluefox 6y ago
  I believe you, and apologize for the hyperbole. I also think Rich Hickey is intelligent and wish him and his project the best.
m45t3r 6y ago
> massive problem with trivial things like indentation. Nope, someone wrote an article arguing for fixed formatting and Bozhidar Batsov decided to reply, but pretty much what he said is what is accepted by Clojure community anyway.

dan-robertson 6y ago

I think the Clojure people tend to be pretty thoughtful about language design and doing things in ways that will be functional and composable. Common Lisp is a language with a lot of warts where many features were tacked on but not properly integrated with everything else. It also suffers from the concerns and technology of the 1980s (a big focus on mutability, no multithreading in the spec, the pathnames library, no immutable maps, to name a few.) Scheme is minimal and that can be an advantage but Clojure has different goals to scheme

bluefox 6y ago
I think the Clojure people tend to produce unreadable mess, which tells me the design of their language is down in the gutter. Common Lisp is a language with a lot of warts, sure, but typical Common Lisp code is way, way, way more tasteful than typical Clojure code. We like our multiparadigmness, thank you very much. That includes being able to mutate things. We also like that the language is stable, and that means no changes to the spec, and that means it won't cover everything. That's OK, because our spec covers more than enough. We have less stable libraries and implementation-specific interfaces to cover the rest. We are still pretty conservative with those, too. Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since no real Clojure programs can run on it, because JVM is part of Clojure, really...) and once things are documented they either stick forever or break. I wouldn't say Clojure has warts; it has massive oozing injuries that keep on spreading indefinitely. So yeah, we'd rather live with the warts from the 90s, the 80s, the 70s, and the 60s. We like our tradition, and we like our programs not breaking. We have a stable base that we can build 2020, 2030, 2040 stuff on.
- dustingetz 6y ago
  typical clojure is a mess because it actually gets used in industry by junior devs and such
  - bluefox 6y ago
    If true, that is a point for Clojure. It keeps the inexperienced on a distinct path where some day, when they're battle-worn and wise and had enough of it, they may find it was a road to Lisp after all.
    - dustingetz 6y ago
      i think you're looking for the principle agent problem aka middle management wrecking everything
  - didibus 6y ago
    > typical clojure is a mess That's a claim that would need to be substantiated first. My experience is that typical Clojure is quite descent actually.
- m45t3r 6y ago
  > Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since no real Clojure programs can run on it, because JVM is part of Clojure, really...) It is true that Clojure doesn't have a spec, but it is very stable. I saw some very minor breaking changes in Clojure, and most code just works after a update (including very big projects). Clojure is very conservative in general, and this is something that Rich says as a explicit design goal. BTW, are you referring to ClojureScript? Because ClojureScript is far from a toy language, it works well and we use in production. Sure it have some warts, but they're mostly workable and while I am not a fan, I am not a fan of frontend in general so this is probably part of the problem.
  - bluefox 6y ago
    I was thinking about ClojureCLR. While my argument could be applied to ClojureScript, I did not think it was fair because ClojureScript calls itself a (proper) subset of Clojure, which is fine and no one expects it to run actual Clojure programs. Again, I apologize for undue harshness.
reikonomusha 6y ago
I really consider your comment to be FUD about Common Lisp. The language is not so aesthetic in many places, but the language was very certainly thoughtfully designed and iterated on. Features by and large work surprisingly well together to form a cohesive language. I don’t agree about things being “tacked on”, which is voluminously evidenced in the discussions about each and every feature. The standard could have been bigger and more comprehensive. But it’s just a non-problem most of the time. Threading is de facto standard and extremely well understood in its interactions with Common Lisp as defined. Common Lisp is an extremely capable language to get things done cleanly. It just does things in a way that simply feels different from later languages. If you want to talk about bolted on features, look no further than the plethora of Scheme libraries.
- dan-robertson 6y ago
  I’ve written a lot of Common Lisp and I while there was obviously a lot of thought that went into its design, I wouldn’t call it cohesive. Why are streams not CLOS objects (in the spec; I know about gray-streams)? Why can’t equality operators be extended to user-defined types? Why does the language even need so many equality operators and specialised functions like sbref? Why have both setf function names and a load of functions like rplca? Why is a setf function name invalid as the car of a form, even though only expressions (apart from atoms and lambdas) are disallowed? Why can’t the user make hash tables work for their own data-types? Why aren’t structs a first-class part of the object system like classes (unless you have the MOP)? Why can’t you have anonymous classes even though you can have anonymous functions and objects whose class was replaced with a new definition? Why can’t the user extend the sequence functions like map with their own sequences? Why are arrays so custom compared to the rest of the object system? Why pathnames? Why do so many things have bad names (e.g. getf and putf vs setf, set and get and setq, ...) If your answer is performance or compatibility with 1980s operating systems or lisp implementations, then sure that’s a reason for the design but it doesn’t make the design cohesive, complete and composable. I think CL is a good language despite this rather than because of it and I would suggest that your claim of it working “surprisingly well” supports that.
  - kazinator 6y ago

islon 6y ago

It's such a "massive" problem I've been doing CLojure full time for the past 8 years and only heard about it now.

bluefox 6y ago
I believe you, and apologize for the hyperbole. I also think Rich Hickey is intelligent and wish him and his project the best.

m45t3r 6y ago

> massive problem with trivial things like indentation. Nope, someone wrote an article arguing for fixed formatting and Bozhidar Batsov decided to reply, but pretty much what he said is what is accepted by Clojure community anyway.