31–40 of 91 posts
This is a great book, but the subject of dealing with mp3s looks painfully dated.
Earlier quoted context omitted.
Common Lisp has the advantage of being much more stable in terms of language changes. You can pretty much take CL code from the last two decades and run it. It's also got a better native compilation story. I like Clojure for bringing maps and vectors into first class language constructs with simple syntax and the fact that it runs on the JVM means I have access to the entire Java ecosystem of libraries and tools.
I wonder where the vector myth comes from. Common Lisp always had a vector data type and syntax for it. Just not [], but #(). Actually Common Lisp has multi-dimensional arrays, bitvectors, ... Vector: CL-USER 102 > (map 'vector #'char-code "foobar") #(102 111 111 98 97 114) CL-USER 103 > (reduce #'+ #(102 111 111 98 97 114)) 633 Bitvector: CL-USER 105 > (reduce #'+ #*10101001010101) 7 2d-Array CL-USER 106 > (aref #2a…
Earlier quoted context omitted.
I wonder what would be a great replacement topic nowadays. Ruby on Rails era was the blog in 5 minutes. What is "the project" now?
For front-end the community seems to have landed todo lists as "the project".
Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?
- Compiles to native
- Superior REPL experience/interactivity
- Easier C FFI
- Smaller ecosystem, not as many libraries.
- Dated tooling.
- Inferior support for multi-threading/multi-core.
- Not as homoiconic. Only lists are by default.
- Standard is abandoned. No new versions since 1994. Some CDRs till 2013.
- Leans towards OOP and imperative mutability over Functional and immutable.
- Doesn't have unified abstractions over datastructures.Note that while this is one of the really good books on Common Lisp it is not new. The copyright is 2003-2005.
Has anything really changed, though? QuickLisp, I guess, but that feels like about it.
Earlier quoted context omitted.
(Mostly talking about SBCL) Mature native code compilation (including runtime assembler), type declarations that lead to optimizations in generated code, SBCL compiler can use declared types for compile-time type checks, read/compiler macros, extremely easy interface to C (JNI is a pain in the ass), multi-paradigm and doesn't prematurely optimize like Clojure (I have no need for STM or immutable data structures in 99…
I do like Clojure for some of its opinions (immutable by default, strong encouragement of functional programming, convenient abstractions for collections, tasteful syntactic sugar). But, I too am not necessarily a huge fan of the ecosystems that Clojure is presently tied to. I'd love to see an SBCL implementation of Clojure or (especially) an LLVM based Clojure. I'm grateful when Clojure offers me an out from writing…
It’s a glue language for assembling components, most of which are written in Java.
Timothy Baldridge wrote a python based language heavily inspired by clojure called Pixie. That gives a feel for what clojure is like without the ecosystem. Basically it means reinventing many many wheels.
Earlier quoted context omitted.
I wonder where the vector myth comes from. Common Lisp always had a vector data type and syntax for it. Just not [], but #(). Actually Common Lisp has multi-dimensional arrays, bitvectors, ... Vector: CL-USER 102 > (map 'vector #'char-code "foobar") #(102 111 111 98 97 114) CL-USER 103 > (reduce #'+ #(102 111 111 98 97 114)) 633 Bitvector: CL-USER 105 > (reduce #'+ #*10101001010101) 7 2d-Array CL-USER 106 > (aref #2a…
I didn't say CL has no vectors or syntax, just that in Clojure using sets, maps and vectors, is much more similar to using lists than it is in CL.
This is a great book, but the subject of dealing with mp3s looks painfully dated.
The point of it is to discuss handling and parsing binary data. You could replace it with any binary format you want and have similar pedagogic value. FLAC, Vorbis, h.264, Matroska, etc.
Another example could metadata in image (jpg, ...) files for example.
Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?
I'd say pros: - Compiles to native - Superior REPL experience/interactivity - Easier C FFI I'd say cons: - Smaller ecosystem, not as many libraries. - Dated tooling. - Inferior support for multi-threading/multi-core. - Not as homoiconic. Only lists are by default. - Standard is abandoned. No new versions since 1994. Some CDRs till 2013. Neutral: - Leans towards OOP and imperative mutability over Functional and immuta…
Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?
I'd say pros: - Compiles to native - Superior REPL experience/interactivity - Easier C FFI I'd say cons: - Smaller ecosystem, not as many libraries. - Dated tooling. - Inferior support for multi-threading/multi-core. - Not as homoiconic. Only lists are by default. - Standard is abandoned. No new versions since 1994. Some CDRs till 2013. Neutral: - Leans towards OOP and imperative mutability over Functional and immuta…
Common Lisp also has full language interpreters: these are implementations of Common Lisp which interpret s-expression level code - not byte code.
Common Lisp can easily dump images and make them executable. Saving and starting them is quick.
Common Lisp has implementations mostly written in Common Lisp - including the compiler and large parts of the runtime.