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

71–80 of 91 posts

Re: Practical Common Lisp (2009)

#71

Post by justinhj »

jlg23 wrote: post #56
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.

> 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... (e…

It's not really about just saving characters, it's about the fact that vector, set and to some extent map can be used in Clojure code as if they are an equal citizen in the syntax to list. It saves valuable mental cycles that can be used on your actual problem instead.

Re: Practical Common Lisp (2009)

#72

Post by sedachv »

patrec wrote: post #61
m0skit0 wrote: post #10

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

Common Lisp advantages: - "more interactive" resumable exceptions, better code reloading functionality - multiple values (cumbersome to use for superficial reasons, but with much better semantics than in e.g. scheme, for sure and probably also Lua) - compiler macros - readtable macros (although the design leaves to be desired) - more sophisticated pretty printer - more "target platforms"; with clojure it's basically…

You have a lot of very wrong opinions on Common Lisp.

> multiple values (cumbersome to use for superficial reasons

How so?

> Common Lisp has no eco system to speak off

False. https://www.quicklisp.org/beta/ https://cliki.net/

> the language is frozen/dead

False. Extensions are being done through libraries and in the implementations.

> career suicide, even compared to clojure

I only ever get positive attention for having been a professional Common Lisp (and Scheme) programmer. Never had trouble finding freelance or full-time work.

> no high quality free implementations (for example sbcl has a rather poor garbage collector compared to java, go and other widely used languages)

How do you go from "SBCL's GC is slower than Java's" (which is a nonsensical statement, because different JVMs have different GCs), to "no high-quality free implementations?" There are three Free Software ones to choose from: SBCL, CCL, and ECL.

> single precision is de-facto the default floating point type

False. Where do you even pick up a ridiculous idea like that? http://www.lispworks.com/documentation/HyperSpec/Body/t_shor...

> built around cons cells which are a terrible data structure

Ignoring how dumb labeling the linked list a "terrible data structure" is, you do realize that data structures are something that you implement in a language, not something that you have to build into one? There are libraries for all kinds of data structures.

> no out of the box support for laziness

There is no reason to make it built in at the language level when you have closures.

> no concurrency or parallelism abstractions

That is handled by implementations and libraries.

> no good standard pattern matching library

Just a bunch of really great ones.

> brain drain: very few smart people doing interesting things left (most left by the 90ies)

You don't seem to know anything or anyone from the Common Lisp world. The best techniques for using the language (advanced use of closures, read macros, the condition system, and applications to domain-specific languages and transpilation) have only started coming out in the past 15 years, from people like Edi Weitz, Doug Hoyte, and Tobias Rittweiler. The only thing relevant from the 1990s is Paul Graham's On Lisp. Norvig's PAIP is very overrated.

Re: Practical Common Lisp (2009)

#73

Post by kamaal »

m0skit0 wrote: post #10

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

One thing I tend to miss in Clojure is lack of TCO. Most people(like me), come to Lisp from SICP, The Little Schemer and PG's books. Where recursion is not just emphasized, you are actually trained to think recursively.

I found lack of TCO to be a little like a stick in the neck when it comes to both Clojure and Emacs Lisp. It prevents you from thinking in the way you have been thinking in other Lisps.

I understand Clojure depends on JVM and JVM doesn't do tail call eliminations yet, and Rich Hickey is right in thinking that method calls are too much a platform thing and we shouldn't be working around this limitation with a hack. However lack of TCO in Emacs Lisp is a little not easy to live with. From what I understand patches have been submitted to Emacs to make this happen but haven't made it to the upstream.

TCO is very important for any language that sells functional programming these days. Apart from the performance advantages, Recursion is a thought framework. Limitations are not easy to live with.

I hope some day Clojure and Emacs Lisp get TCO.

On a tangential note, JVM is a great platform, its a also a widely used platform, so changes are going to come in very slowly. So I'm not holding my breath waiting for TCO.

Re: Practical Common Lisp (2009)

#74

Post by kamaal »

sedachv wrote: post #72
patrec wrote: post #61

Earlier quoted context omitted.

Common Lisp advantages: - "more interactive" resumable exceptions, better code reloading functionality - multiple values (cumbersome to use for superficial reasons, but with much better semantics than in e.g. scheme, for sure and probably also Lua) - compiler macros - readtable macros (although the design leaves to be desired) - more sophisticated pretty printer - more "target platforms"; with clojure it's basically…

You have a lot of very wrong opinions on Common Lisp. > multiple values (cumbersome to use for superficial reasons How so? > Common Lisp has no eco system to speak off False. https://www.quicklisp.org/beta/ https://cliki.net/ > the language is frozen/dead False. Extensions are being done through libraries and in the implementations. > career suicide, even compared to clojure I only ever get positive attention for hav…

>>The best techniques for using the language

That is good, but availability of Libraries are better.

Let's face it. Most people can't use even basic programming features well. When programming went mainstream we traded art for plumbing. What matters now is being able to talk to http end points, working with databases, message buses and myriad of other backend interfaces.

To have widespread adoption you have to do library stuff well, and then may be other features will matter.

Perl is an interesting use case in this regards. The language is very 'functional programming language like' in nature but has a very practical focus for common people, while providing the powerful features for advanced users.

Re: Practical Common Lisp (2009)

#75

Post by kamaal »

peatmoss wrote: post #55
FPGAhacker wrote: post #36

Earlier quoted context omitted.

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 t…

Well that's the problem isn't it.

Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build.

Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison.

So it makes sense to make sacrifices(if needed) to re use all that Java work that has been done and has been going on over the years.

Clojure is the best thing that has happened to Lisp in years.

Re: Practical Common Lisp (2009)

#76

Post by patrec »

sedachv wrote: post #72
patrec wrote: post #61

Earlier quoted context omitted.

Common Lisp advantages: - "more interactive" resumable exceptions, better code reloading functionality - multiple values (cumbersome to use for superficial reasons, but with much better semantics than in e.g. scheme, for sure and probably also Lua) - compiler macros - readtable macros (although the design leaves to be desired) - more sophisticated pretty printer - more "target platforms"; with clojure it's basically…

You have a lot of very wrong opinions on Common Lisp. > multiple values (cumbersome to use for superficial reasons How so? > Common Lisp has no eco system to speak off False. https://www.quicklisp.org/beta/ https://cliki.net/ > the language is frozen/dead False. Extensions are being done through libraries and in the implementations. > career suicide, even compared to clojure I only ever get positive attention for hav…

Wrt brain drain: Edi Weitz is a smart guy, but not in the same league as e.g. Henry Baker, Jeffrey Mark Siskind, David Moon, Bill Gosper, Guy Steele, Marvin Minsky, Peter Norvig etc. There are still several people worth following left, even if you're not a common lisp fanboi (e.g. paul khuong), but hardly a lot which are moving the state of computing forward to the extent it was the case for many decades.

Dough Hoyte wrote Let over Lambda which is strong on the same breathless prose gracing its blurp:

> Let Over Lambda is one of the most hardcore computer programming books out there. Starting with the fundamentals, it describes the most advanced features of the most advanced language:

but IMO much weaker than PAIP on the actual "hardcore" programming. I can see why it would appeal to you more.

Wrt single precision being the default floating point type in practice:

   * *read-default-float-format*
   SINGLE-FLOAT
   * (cos 355/113) 
   -1.0 
   * (cos (/ 355 113.0))
   -1.0
   * (cos (/ 355 113d0))  ; get a more accurate answer by using double float literal
   -0.9999999999999645d0
The only practical implementation which diverged from this for some time was CCL (which used doubles), and they gave up because of friction with the rest of the community. I don't have time to address all your other claims that what I wrote is ridiculously false right now, so if it makes you feel better you can tell yourself that you still showed me wrong on 9 out of 11 points.

Re: Practical Common Lisp (2009)

#77

Post by lispm »

kamaal wrote: post #75
peatmoss wrote: post #55

Earlier quoted context omitted.

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 t…

Well that's the problem isn't it. Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build. Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison. So…

> Clojure is the best thing that has happened to Java in years.

FTFY

Re: Practical Common Lisp (2009)

#78

Post by [deleted] »

lispm wrote: post #77
kamaal wrote: post #75

Earlier quoted context omitted.

Well that's the problem isn't it. Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build. Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison. So…

> Clojure is the best thing that has happened to Java in years. FTFY

[deleted]

Re: Practical Common Lisp (2009)

#79

Post by lispm »

kamaal wrote: post #73
m0skit0 wrote: post #10

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

One thing I tend to miss in Clojure is lack of TCO. Most people(like me), come to Lisp from SICP, The Little Schemer and PG's books. Where recursion is not just emphasized, you are actually trained to think recursively. I found lack of TCO to be a little like a stick in the neck when it comes to both Clojure and Emacs Lisp. It prevents you from thinking in the way you have been thinking in other Lisps. I understand C…

Most mainline Lisps either never did support TCO or only in some restricted way. The reason for that is that it clashes with other widely used language features in typical Lisps. There is a cost to supporting TCO - also a less nice debugging experience. Many CL compilers tend to support it with some restrictions - CL interpreters often not. Lisp Machines did not support it. CL on the JVM does not support it. https://0branch.com/notes/tco-cl.html

I started with Scheme and Lisp (Standard Lisp, ZetaLisp, CL, ...) and wrote/used TCO a lot. I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read. I tend to like either higher-order iterative constructs or powerful iteration constructs like CL's ITERATE: https://common-lisp.net/project/iterate/

I find the Clojure hack ugly.

Re: Practical Common Lisp (2009)

#80

Post by kamaal »

lispm wrote: post #79
kamaal wrote: post #73

Earlier quoted context omitted.

One thing I tend to miss in Clojure is lack of TCO. Most people(like me), come to Lisp from SICP, The Little Schemer and PG's books. Where recursion is not just emphasized, you are actually trained to think recursively. I found lack of TCO to be a little like a stick in the neck when it comes to both Clojure and Emacs Lisp. It prevents you from thinking in the way you have been thinking in other Lisps. I understand C…

Most mainline Lisps either never did support TCO or only in some restricted way. The reason for that is that it clashes with other widely used language features in typical Lisps. There is a cost to supporting TCO - also a less nice debugging experience. Many CL compilers tend to support it with some restrictions - CL interpreters often not. Lisp Machines did not support it. CL on the JVM does not support it. https://…

>>I tend to view the use of TCO for basic iteration as a mistake, which makes code harder to read.

I understand some one like you is far more experienced and has been around for a long time. So obviously you know better than I ever will. And you are right. Even with very minimal Lisp exposure, after using Scheme and Common Lisp, Clojure's TCO thing feels unacceptable.

In fact after using Common Lisp, and I'm a novice, even some one like me feels Common Lisp to be a far superior language compared to other Lisps around.

The issue is, like I said, I started learning lisp starting with Scheme, and I started recently. First book was SICP, second was 'The Little Schemer', third was 'The Seasoned Schemer'. At that point your brain is hard programmed to think in terms of recursion, and whenever I see loops my mind moves to recursion automatically. You have to trust me when I say this, when I read PG's ANSI Common Lisp book , I skipped the sections on iterations and loops, because I thought I would never use them anyway.

I have to say those Schemer books do their job really well.

May be I just need more practice, so I will develop more stuff in Clojure, now that its not even possible to do that Clojure, eventually that TCO addiction should go away.

:)

Post reply on HN