Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Common Lisp (2009)

gigamonkeys.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Practical Common Lisp (2009)

#41

Post by lispm »

todd8 wrote: 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 Recipes (Lisp lore), ... and also the Lisp Machine Manual ...

For a bunch of, often old, Lisp related books see my list: https://www.librarything.com/catalog/lispm&tag=lisp

Re: Practical Common Lisp (2009)

#42

Post by justinhj »

lispm wrote: post #37
justinhj wrote: post #32

Earlier quoted context omitted.

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.

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.

Re: Practical Common Lisp (2009)

#43

Post by lispm »

justinhj wrote: post #42
lispm wrote: 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.

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.

Re: Practical Common Lisp (2009)

#44

Post by Jach »

lilactown wrote: post #30
ScottBurson wrote: post #26

Earlier quoted context omitted.

If you want to use functional (immutable) collections in Common Lisp, try FSet [0]. (It's QuickLisp-loadable.) FSet greatly expands the space of programs that can naturally be written in a functional style in CL. [0] https://github.com/slburson/fset

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 language to change how you think about programming"¹ side-effects and on the social side doing so should help understanding and interacting with other users and code in that community. It can be really frustrating to me when I read Python code written by a career Java developer who never bothered to understand what "Pythonic" is. I don't want to be that guy for someone else.

¹Incidentally this http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h... is my favorite high-level article around one of those potentially mind blowing differences that is Lisp's condition system, written by someone who has spent a lot of time considering fundamentals of programming like what it means to be in an exceptional situation and how to handle it.

Re: Practical Common Lisp (2009)

#45

Post by vram22 »

didibus wrote: post #34
m0skit0 wrote: 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…

>I'd say cons:

I'll raise you a car.

Re: Practical Common Lisp (2009)

#46

Post by vram22 »

lispm wrote: post #40
didibus wrote: post #34

Earlier quoted context omitted.

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 compiles to much more than just 'native'. Like C, LLVM, DLLs, ... and a has a bunch of exotic stuff like whole-program-to-C compilers, Common Lisp on the metal or Common Lisp on top of Prolog https://github.com/TeamSPoon/wam_common_lisp . 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…

Is this point of your parent commenter right?

> - Not as homoiconic. Only lists are by default.

Re: Practical Common Lisp (2009)

#47

Post by justinhj »

lispm wrote: post #43
justinhj wrote: post #42

Earlier quoted context omitted.

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.

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-ARRAY to create vectors you plan to modify.

Re: Practical Common Lisp (2009)

#48

Post by lispm »

vram22 wrote: post #46
lispm wrote: post #40

Earlier quoted context omitted.

Common Lisp compiles to much more than just 'native'. Like C, LLVM, DLLs, ... and a has a bunch of exotic stuff like whole-program-to-C compilers, Common Lisp on the metal or Common Lisp on top of Prolog https://github.com/TeamSPoon/wam_common_lisp . 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…

Is this point of your parent commenter right? > - Not as homoiconic. Only lists are by default.

I read that, too. But I'm not sure what he means by 'Only lists are by default'. If he means that only lists have a literal representation, then it would be slightly wrong - since Common Lisp has literal representations for various numbers, symbols, characters, strings, vectors, arrays, structures, pathnames, ...

Plus the s-expression syntax is user-extensible - making it as 'homoiconic' as the user needs it.

Re: Practical Common Lisp (2009)

#49

Post by nextos »

m0skit0 wrote: post #10

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

I love Common Lisp (and I miss its frequent discussions on HN a decade ago). That trend seems to be resurfacing now.

The main advantage of Common Lisp is standardization. There's very few languages that can run old code across so many platforms and implementations. But that also holds the language back a bit in terms of progress. Libraries feel like they have been falling a bit behind. It's also one of the few practical languages that has a great multi-paradigm support.

The main advantage of Clojure is implementing lots of modern functional programming ideas. It's main disadvantage is being excessively tied to the JVM. That allowed initial rapid growth, but it brings some side-effects such as ugly stack traces. Aside from JavaScript, there are no alternative platforms.

Racket will now run on top of Chez Scheme. That's another major Lisp worth considering.

Lastly, Julia shows some of the multiple dispatch ideas in CLOS can lead to really efficient code generation when paired with LLVM or a similar backend.

I wish someone put all these interesting ideas in a blender and implemented them on top of Common Lisp, or as a new language. Something functional, with great typing (like Shen), static analysis and an LLVM-like backend are really worth pursuing. We need better languages to address modern challenges, like merging symbolic and probabilistic AI.

Re: Practical Common Lisp (2009)

#50

Post by armitron »

Jach wrote: post #44
lilactown wrote: post #30

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…

It is illuminating to read the output of such minds as Kent Pitman, Dan Weinreb, David Moon, Richard Gabriel, Rodney Brooks, Guy Steele and what they have to say about Common Lisp and the standardization process, in places such as comp.lang.lisp (the entire archive can be found online) and elsewhere. The depth and clarity of thought, the foresight, the attention to detail and the guiding principle of trying to find the "right" vs the "easy" solution (this is beautifully illustrated in "worse is better" by RPG).

Compare and contrast with the designers of today's popular programming languages. There is something severely lacking in the minds behind PHP/Javascript/Python/Ruby and other languages where projected popular appeal and "easy" is the prime design consideration.

Are we worse off? I think so, not just for technical reasons, but because we have lost something greater that can not be easily put into words.

Post reply on HN