I respect the author's directions -- and Clojure is a fine language -- but I was a little put off by this assertion:
I’m only really getting at the fact that even the ultra-flexible of Common Lisp wasn’t written to handle all computing scenarios.
This came after he noted that Lisp includes destructive functions and implementation-specific multithread schemes. Sure, on the one hand, the CL standard is a little long in the tooth, but on the other hand...
(1) "Pure functional" is less flexible than "functional plus features for imperative programming". It was weird that he cited destructive, efficient functions as a negative, that they contributed to Lisp not supporting "all computing scenarios". We can happily debate functional approaches as being less bug-ridden and all that jazz, and those advantages come with the tradeoff of being less flexible.
(2) A Turing-complete language supports all computing scenarios.
(3) Okay, sure, you want access to some OS services, not just academic completeness, and that does end up being implementation-specific. Fortunately, CL gives us an out: you can implement layers that detect the implementations and do whatever specific thing was provided. Every modern CL implementation supports multithreading in one form or another. There are several packages contributed by Lispers that show different approaches to multithreaded and multiprocessing apps. There is no one true way with that. Clojure provides several approaches, and there are several libraries for Lisp that provide several approaches.
Over Clojure, CL continues to provide some advantages, at least to me... Less syntax; compiles to machine code; mature; no special functions required for recursion, recursive iteration, or trampolining; and not limited by the JVM. A couple of those end up being Clojure's advantages, too, depending on your perspective (syntax, JVM).
Both fine languages. Just a weird comment in the middle of a good essay.
I’m only really getting at the fact that even the ultra-flexible of Common Lisp wasn’t written to handle all computing scenarios.
This came after he noted that Lisp includes destructive functions and implementation-specific multithread schemes. Sure, on the one hand, the CL standard is a little long in the tooth, but on the other hand...
(1) "Pure functional" is less flexible than "functional plus features for imperative programming". It was weird that he cited destructive, efficient functions as a negative, that they contributed to Lisp not supporting "all computing scenarios". We can happily debate functional approaches as being less bug-ridden and all that jazz, and those advantages come with the tradeoff of being less flexible.
(2) A Turing-complete language supports all computing scenarios.
(3) Okay, sure, you want access to some OS services, not just academic completeness, and that does end up being implementation-specific. Fortunately, CL gives us an out: you can implement layers that detect the implementations and do whatever specific thing was provided. Every modern CL implementation supports multithreading in one form or another. There are several packages contributed by Lispers that show different approaches to multithreaded and multiprocessing apps. There is no one true way with that. Clojure provides several approaches, and there are several libraries for Lisp that provide several approaches.
Over Clojure, CL continues to provide some advantages, at least to me... Less syntax; compiles to machine code; mature; no special functions required for recursion, recursive iteration, or trampolining; and not limited by the JVM. A couple of those end up being Clojure's advantages, too, depending on your perspective (syntax, JVM).
Both fine languages. Just a weird comment in the middle of a good essay.