Live data from Hacker News

Practical Common Lisp (2009)

gigamonkeys.com

51–60 of 91 posts

Re: Practical Common Lisp (2009)

#51
post #43

Earlier quoted context omitted.

reading and reducing a list: CL-USER 109 > (reduce #'+ (read)) (1 2 3) 6 reading and reducing a vector: CL-USER 110 > (reduce #'+ (read)) #(1 2 3) 6 I've changed only the opening bracket.

Did you change from map to reduce because map needs to be told what kind of sequence to create? In Clojure the literal syntax avoids that. In addition there is this caveat about the literal vector syntax in Common Lisp: You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-AR…

The literal syntax has nothing to do with MAP. I can define a MAP which returns a vector or a list, depending on the input:

  CL-USER 111 > (defun maps (function sequence)
                  (map (type-of sequence) function sequence))
  MAPS

  CL-USER 112 > (maps #'1+ '(1 2 3))
  (2 3 4)

  CL-USER 113 > (maps #'1+ #(1 2 3))
  #(2 3 4)
I can also write a compiler macro, so that the implementation is chosen at compile time, when a literal data object is used... stuff which a Common Lisp implementation already might do for MAP.

Common Lisp chose to define the basic MAP to always specify the result sequence I want to create or NIL for no sequence.

> You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-ARRAY to create vectors you plan to modify.

That's not different for lists and vectors. For both I need to know which I want to modify. Common Lisp has generic operations to create and copy sequences for that: I can call COPY-SEQ to copy the literal sequence or call MAKE-SEQUENCE to create the sequence type I want.

Here (and in many other places) Common Lisp is a low-level language, which exposes these things to the programmer.

Re: Practical Common Lisp (2009)

#52
post #10

Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?

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 guess I should also mention on Clojure's side, the immutable by default data model and pattern matching.

Re: Practical Common Lisp (2009)

#53
post #44

Earlier quoted context omitted.

I have looked heavily at FSet :). I'm at a cross roads now with whether I try and push the Lisp block into the Clojure hole in my brain, or whether I should try and learn Lisp as it is and it's idioms. FSet is really cool and I'll probably end up using it in conjunction with https://github.com/fiddlerwoaroof/cl-edn

When learning new languages I think it's always beneficial to drink the kool-aid and go as full idiomatic as you can, then step back and reflect once you're competent enough. (That may take a while with CL if you're not doing it professionally, there's a lot in there! I'm still on my own plodding journey to CL competence...) My reasons are for the personal side that doing so should help maximize the "learn new langua…

> mind blowing differences that is Lisp's condition system

It's similar mind-blowing when you think about this: that people wrote and used an operating system in the 70s/80s in Lisp, where the condition handling system was in full effect throughout the whole user experience (for example when using the file system, the network, the development environment, etc). With all the pros and cons...

Re: Practical Common Lisp (2009)

#54
post #10

Can anyone please comment what advantages and short-comings Common LISP has over "modern LISP" (i.e. Clojure)?

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.

[deleted]

Re: Practical Common Lisp (2009)

#55

Earlier quoted context omitted.

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…

Clojure isn’t really worth anything without the jvm/js ecosystem. 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.

I don’t know—there are certainly some interesting / different things in Clojure as compared to other lisps. Even if you can technically do much of what Clojure can do in other lisps, idiomatic Clojure has a feeling that is distinct from CL, Scheme, or even Racket.

If Clojure offers nothing without the large JVM/JS ecosystems, then we could say the same about most languages (that aren't the size of Java/JS).

If it’s that the distinct cocktail of features and ideas in the language aren’t worth anything, then I’d respectfully disagree. But at that point we’d simply be arguing aesthetic preferences.

Re: Practical Common Lisp (2009)

#56
post #37

Earlier quoted context omitted.

Common Lisp reads and writes vectors, has a simple syntax for them and provides a sequence abstraction over lists and vectors.

Operations that in Clojure require only changing the kind of brackets, in Common Lisp are more verbose and explicit. If you don’t see the clean syntax and simple utility in that then fair enough, but I do.

> If you don’t see the clean syntax and simple utility in that then fair enough, but I do.

I see a "cleaner syntax in the example" but the fragments of code you don't like, the literals, are something that you won't see in production code except for a few constants maybe. The difference in ~"characters to change" for switching from list to vector is far smaller than the amount of characters spent on this thread... (edit: even over the lifetime of a programmer)

Re: Practical Common Lisp (2009)

#58

I want to learn Clojure but every time I try I get bogged down thinking I need to learn Common Lisp first. I’m sure that’s silly but it seems like it would be important. Am I wrong?

Common Lisp is a very different language, I doubt it will help you to learn Clojure. Clojure is a smaller language than Common Lisp in a lot of ways, so learning it first, then Common Lisp later might actually be the faster approach.

Re: Practical Common Lisp (2009)

#59
post #41
post #2

Note that while this is one of the really good books on Common Lisp it is not new. The copyright is 2003-2005.

It's new for those who haven't read it. ;-) There are a bunch of oldish Lisp books, but which might be read with some benefit even today. I'd would for example mention Performance and Evaluation of Lisp Systems (benchmarking Lisp), Keene's CLOS book, PAIP (writing classical non-trivial code and optimizing it), AMOP (meta-objects, extensible architecture), On Lisp (macros), Land of Lisp (fun&games), Common Lisp Recipe…

In general, Lisp books were generally so far ahead of the state of the art at the time they were written, they remain very relevant and timely today.

And very likely tomorrow. :)

Re: Practical Common Lisp (2009)

#60
post #34
post #10

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…

Where do you get the "inferior support for multi-threading/multi-core" from? SBCL and ClozureCL (among others) support both with no issues.

Dated tooling? Not if you compare it to Clojure tooling, SLIME is lightyears ahead in terms of robustness. I've lost track of the Clojure REPLs (nrepl, CIDER, inf-clojure, ...) that still suck.

Re: "smaller ecosystem, not as many libraries", surely you are joking or not at all aware of things like the CMU Common Lisp repository. If we disregard Java libraries, Clojure doesn't even come close to CL code that has been made available over the last few _decades_.

One doesn't need CDRs or another (expensive, time consuming) standardization process when there are great portability libraries (FFI, threads, sockets, convenience macros, ..) or one can pick a defacto standard implementation that offers all of the above.

Post reply on HN