4 ms·

This kind of blind zealotry kills innovation.

agentultra 13y ago
It's true and it happens on both sides. I've met Lisp programmers who came in by way of Clojure who openly criticize CL for its use of parentheses and its age. It's quite silly.
- hga 13y ago
  The age and more importantly stasis is a fair cop, especially if the Clojure programmer cares about SMP programming, where Common Lisp does not officially even have a story. Clojure was among other things designed with SMP and functional programming in mind, and thread safety is the rule rather than the exception. If the age is a reference to Common Lisp bearing almost all the warts of mainline Lisp (minus dynamic scoping) it's also a fair cop, Scheme inspired Lisp dialects like Clojure have gained tremendously by throwing away a lot of historical baggage. Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. On the other hand if you don't like CL's parens, I wonder how you can like Clojure? Almost all the special form syntax is parens, and old Lispers like me are somewhat annoyed by the vectors (first class syntax with square brackets, []) used by e.g. let. Are there very many Clojure programmers like this? Any prominent ones???
  - agentultra 13y ago
    > The age and more importantly stasis is a fair cop I don't see how threading makes "age" a valid argument. CL is a language defined by a specification. Implementations have provided threading APIs for a while now and library authors have written cross-implementation threading APIs. Without even mentioning threading in the specification it's trivial to write multi-threaded CL applications today and I think that's a strength. In a similar fashion, C++ hadn't included a threading API until C++11 (iirc). Yet implementations provided it and library authors had filled the gap for years until a standard API was adopted into the core standard library. If CL was a language defined by an implementation that hadn't been updated in 10 years I might agree with you. As for syntax it's odd. Rich Hickey himself has advocated the use of syntax-literals for data-structures citing legibility as a primary concern. One familiar with CL's access to the reader and read-table would allow the programmer to implement reader macros for the same effect without losing compatibility with the rest of CL (and the standard implements a few: #() for vectors for example, '() for (QUOTE ...) etc). Either way preference of syntax is superfluous when you have programmatic access to your language's parser and yet Cljoure programmers unfamiliar with this concept advocate that syntax-literals are the way of the future and CL's lack of syntax for various constructs is a weakness. It's a non-issue. I've written reader macros for various flavours of assemblers. It's quite versatile. Age isn't a very good criticism. A good specification is meant to withstand the years. CL's has done a pretty good job at that. wrt baggage though, I will concede that perhaps they specified too much in the filepath API. A conformant CL implementation today will have to support some very obscure filesystems... which can be daunting for prospective implementation developers.
    - hga 13y ago
      There's a BIG difference in ecosystems if a system starts out with pervasive threading or doesn't. In a slightly different domain, I saw this back when I was doing NT programming in the '90s. From the start it provided threads and plenty of thread safe stuff (and plenty not, including the MCV++ Standard Template Library in 1997, although that was mostly of an initial botch of the port from the HP? code), and this made quite a difference compared to trying to write threaded programs for UNIX(TM). If you're not going to limit yourself to copying paradigms like the Actor model I argue you're going to be in for a world of hurt, even as your ecosystem matures, because you'll almost certainly have non-thread safe stuff from the days when the community wasn't considering threading. So all I'm saying in this argument is that Common Lisp is traversing this painful path, and will never be as optimal as it might be, because when it was cast into concrete in 1984 threads weren't part of it. The Clojure argument for standard data structure syntax-literals, and strict limits on reader macros, is indeed legibility, defined as portability between humans. I think it's an issue, but one that I think we'll have to agree to disagree on. Although I don't see gaining CL compatibility as a goal, the foundations of the languages are too different (functional vs. multiparadigm including but not limited to functional). I agree that age itself isn't a good criticism, I was pointing out how Common Lisp's extreme age has resulted in issues, and "age criticisms" could be interpreted that way. This goes all the way back all the way to the very first late '50s LISP, e.g. while I personally like them, classic examples are Contents of the Address Register and Contents of the Decrement Register (car and cdr) of the vacuum tube IBM 704. More consequential are things like Lisp-2 vs. Lisp-1; maybe it's just a matter of taste and not having written enough macros in my career but I prefer the latter. Hmmm, to sum up, one argument for Clojure is that we now known enough to create a more restrictive dialect and benefit from the good taste of Rick Hickey and now others who are helping to carry the language's torch. Callow youth though he might be, mrottenkolber is spot on when he says it's an opinionated language, and that'll certainly mean among other things that it'll not be to many experienced Lisper's taste (probably easier if you're a Schemer, though). I harp on SMP programming because I find it, and the functional programming solutions to it, very interesting, not to mention it's just plain better for writing robust software. Closure seems to have done a good job using the latter to address the former, and gaining those other minor details guaranteed FP grants you.
  - lispm 13y ago
    > Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. 30 years ago, maybe Today nothing of Common Lisp is hard to implement on stock hardware.
    - hga 13y ago
      I mean hard to implement efficiently; that's still very possibly true on non-tagged hardware without custom microcode. But maybe not so we'd really notice outside of micro-benchmarks and extreme situations.
      - lispm 13y ago
        Since when was tagging on stock hardware was introduced by Common Lisp? Don't tell me other Lisp implementations were faster than CL, because of not using tagging. Today LispWorks, Clozure CL, SBCL, ... on my laptop run a thousand times faster than any other Lisp implementation ever did on a physical Lisp Machine. Actually they also run code much faster than Python, Ruby and most other popular scripting languages - often by a wide marging. I think you repeat myths from 1984 where some implementors were claiming problems on small 1984 CPUs. They detected early that there were no problems compared to the Lisp Machine. You know one of the reasons the Lisp Machine was no longer popular for Lisp users from 1988 onwards? Stock hardware was a fast for many cases and much cheaper. Implementations like Lucid CL, Allegro CL and LispWorks were on workstations very competitive. In reality, today on 64bit Intel chips, it runs just great. Even on something like an 32bit ARM, Clozure CL runs fine. For many cases, good native Common Lisp implementations will run faster than Clojure.

It's true and it happens on both sides. I've met Lisp programmers who came in by way of Clojure who openly criticize CL for its use of parentheses and its age. It's quite silly.

hga 13y ago
The age and more importantly stasis is a fair cop, especially if the Clojure programmer cares about SMP programming, where Common Lisp does not officially even have a story. Clojure was among other things designed with SMP and functional programming in mind, and thread safety is the rule rather than the exception. If the age is a reference to Common Lisp bearing almost all the warts of mainline Lisp (minus dynamic scoping) it's also a fair cop, Scheme inspired Lisp dialects like Clojure have gained tremendously by throwing away a lot of historical baggage. Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. On the other hand if you don't like CL's parens, I wonder how you can like Clojure? Almost all the special form syntax is parens, and old Lispers like me are somewhat annoyed by the vectors (first class syntax with square brackets, []) used by e.g. let. Are there very many Clojure programmers like this? Any prominent ones???
- agentultra 13y ago
  > The age and more importantly stasis is a fair cop I don't see how threading makes "age" a valid argument. CL is a language defined by a specification. Implementations have provided threading APIs for a while now and library authors have written cross-implementation threading APIs. Without even mentioning threading in the specification it's trivial to write multi-threaded CL applications today and I think that's a strength. In a similar fashion, C++ hadn't included a threading API until C++11 (iirc). Yet implementations provided it and library authors had filled the gap for years until a standard API was adopted into the core standard library. If CL was a language defined by an implementation that hadn't been updated in 10 years I might agree with you. As for syntax it's odd. Rich Hickey himself has advocated the use of syntax-literals for data-structures citing legibility as a primary concern. One familiar with CL's access to the reader and read-table would allow the programmer to implement reader macros for the same effect without losing compatibility with the rest of CL (and the standard implements a few: #() for vectors for example, '() for (QUOTE ...) etc). Either way preference of syntax is superfluous when you have programmatic access to your language's parser and yet Cljoure programmers unfamiliar with this concept advocate that syntax-literals are the way of the future and CL's lack of syntax for various constructs is a weakness. It's a non-issue. I've written reader macros for various flavours of assemblers. It's quite versatile. Age isn't a very good criticism. A good specification is meant to withstand the years. CL's has done a pretty good job at that. wrt baggage though, I will concede that perhaps they specified too much in the filepath API. A conformant CL implementation today will have to support some very obscure filesystems... which can be daunting for prospective implementation developers.
  - hga 13y ago
    There's a BIG difference in ecosystems if a system starts out with pervasive threading or doesn't. In a slightly different domain, I saw this back when I was doing NT programming in the '90s. From the start it provided threads and plenty of thread safe stuff (and plenty not, including the MCV++ Standard Template Library in 1997, although that was mostly of an initial botch of the port from the HP? code), and this made quite a difference compared to trying to write threaded programs for UNIX(TM). If you're not going to limit yourself to copying paradigms like the Actor model I argue you're going to be in for a world of hurt, even as your ecosystem matures, because you'll almost certainly have non-thread safe stuff from the days when the community wasn't considering threading. So all I'm saying in this argument is that Common Lisp is traversing this painful path, and will never be as optimal as it might be, because when it was cast into concrete in 1984 threads weren't part of it. The Clojure argument for standard data structure syntax-literals, and strict limits on reader macros, is indeed legibility, defined as portability between humans. I think it's an issue, but one that I think we'll have to agree to disagree on. Although I don't see gaining CL compatibility as a goal, the foundations of the languages are too different (functional vs. multiparadigm including but not limited to functional). I agree that age itself isn't a good criticism, I was pointing out how Common Lisp's extreme age has resulted in issues, and "age criticisms" could be interpreted that way. This goes all the way back all the way to the very first late '50s LISP, e.g. while I personally like them, classic examples are Contents of the Address Register and Contents of the Decrement Register (car and cdr) of the vacuum tube IBM 704. More consequential are things like Lisp-2 vs. Lisp-1; maybe it's just a matter of taste and not having written enough macros in my career but I prefer the latter. Hmmm, to sum up, one argument for Clojure is that we now known enough to create a more restrictive dialect and benefit from the good taste of Rick Hickey and now others who are helping to carry the language's torch. Callow youth though he might be, mrottenkolber is spot on when he says it's an opinionated language, and that'll certainly mean among other things that it'll not be to many experienced Lisper's taste (probably easier if you're a Schemer, though). I harp on SMP programming because I find it, and the functional programming solutions to it, very interesting, not to mention it's just plain better for writing robust software. Closure seems to have done a good job using the latter to address the former, and gaining those other minor details guaranteed FP grants you.
- lispm 13y ago
  > Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. 30 years ago, maybe Today nothing of Common Lisp is hard to implement on stock hardware.
  - hga 13y ago
    I mean hard to implement efficiently; that's still very possibly true on non-tagged hardware without custom microcode. But maybe not so we'd really notice outside of micro-benchmarks and extreme situations.
    - lispm 13y ago
      Since when was tagging on stock hardware was introduced by Common Lisp? Don't tell me other Lisp implementations were faster than CL, because of not using tagging. Today LispWorks, Clozure CL, SBCL, ... on my laptop run a thousand times faster than any other Lisp implementation ever did on a physical Lisp Machine. Actually they also run code much faster than Python, Ruby and most other popular scripting languages - often by a wide marging. I think you repeat myths from 1984 where some implementors were claiming problems on small 1984 CPUs. They detected early that there were no problems compared to the Lisp Machine. You know one of the reasons the Lisp Machine was no longer popular for Lisp users from 1988 onwards? Stock hardware was a fast for many cases and much cheaper. Implementations like Lucid CL, Allegro CL and LispWorks were on workstations very competitive. In reality, today on 64bit Intel chips, it runs just great. Even on something like an 32bit ARM, Clozure CL runs fine. For many cases, good native Common Lisp implementations will run faster than Clojure.