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

81–90 of 91 posts

Re: Practical Common Lisp (2009)

#81

Post by peatmoss »

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…

Agreed, regarding the effort required to compete on completeness. However, somewhere in between “fad language of the week” and “let’s use nothing but C, because nothing will ever compete” I do think there’s room for new languages.

I’m old enough to remember a time when Java and JavaScript didn’t exist. They, for better or worse, climbed Mt. Improbable to become widespread. Ditto Python. I’d sure love to believe that a better set of languages could also climb that mountain.

Clojure has certainly gotten a leg up by grafting itself onto Java’s ecosystem, but as you point out, there are sacrifices (stack traces, and inability to support things like TCO for two). Ultimately, I’d love to see a combination of two things happen:

- More libraries that work across all implementations of Clojure

- At least one or two implementations of Clojure where the mismatch between the host platform and Clojure is minimized to useful effect.

On the last point, I’d love to see Clojure hosted on Common Lisp. I don’t hold much hope for this given the toxic reaction that many Common Lispers have for Clojure, but I can see benefits in both directions.

For Clojurists, CL has the benefit of running in lots of different contexts with some useful performance characteristics in some cases (SBCL, I’m looking at you). I also believe a Clojure-on-CL implementation would have the possibility of good stack traces.

For Common Lisp, rather than Clojure just being a mindshare theif, pure-Clojure libraries would become usable to the CL community.

Sadly, I think we’ve already achieved peak collaboration between the Clojure and CL communities. The people who liked what Clojure was about already enthusiastically left, and the remainder seem to mostly harbor sour grapes.

Re: Practical Common Lisp (2009)

#82

Post by lispm »

kamaal wrote: post #80
lispm wrote: post #79

Earlier quoted context omitted.

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…

The plain self-recursion part is not that great - especially one needs to write code in that TCO style. General TCO is a bit more - every tail call is a jump. I find it for example useful to have TCO code as low-level target for example for macros.

You have read a good selection of Scheme books. It's very useful to explore that style of programming and be able to really understand. Take it only as a hint, that there is more out there and that different styles and approaches exist. One can program with functions, one can program with linguistic abstractions, ... McCarthy called his paper: 'Recursive Functions of Symbolic Expressions and Their Computation by Machine' - this hints that one programs with recursive functions - but it enables also to compute with symbolic expressions - not only as data, but also as code. The evaluator as a recursive function, which implements Lisp.

Re: Practical Common Lisp (2009)

#83

Post by sedachv »

patrec wrote: post #76
sedachv wrote: post #72

Earlier quoted context omitted.

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…

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

The only relevant example in your list is the fact that irrational functions coerce rational arguments to single floats (http://clhs.lisp.se/Body/12_acc.htm). Why do you think that dividing an integer by a single float should produce a double float?

Re: Practical Common Lisp (2009)

#84

Post by patrec »

sedachv wrote: post #83
patrec wrote: post #76

Earlier quoted context omitted.

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…

> Wrt single precision being the default floating point type in practice: The only relevant example in your list is the fact that irrational functions coerce rational arguments to single floats ( http://clhs.lisp.se/Body/12_acc.htm ). Why do you think that dividing an integer by a single float should produce a double float?

Well, at least I appear to have got half the point across so let me spell out the other half: unlike all mainstream languages (apart from Fortran, depending on your definition of mainstream) Common Lisp interprets "normal" floating point literals as single precision floats. Technically the standard does not specify this, but in practice all implementations do it this way these days. To be precise the standard says that SINGLE-FLOAT is the default, but implementing SINGLE-FLOAT as IEEE double precision float is allowable, because only a minimum precision and exponent size are suggested for each float type. CCL used to do this, using SHORT-FLOAT for IEEE single precision floats and, IIRC, both SINGLE-FLOAT and DOUBLE-FLOAT for double precision.

If you don't want this (and I almost never do), you either need to explicitly specify that you want double precision, using d as an exponent marker in your literals or ensure READ-DEFAULT-FLOAT-FORMAT is bound to DOUBLE-FLOAT (not it's default SINGLE-FLOAT) when you read them (which can go wrong more easily, so the former is typically better). The coercion problem is harder to work around.

So in the light of these facts what exactly is false and ridiculous about my claim that single precision floats are the default floating point type in practice in Common Lisp?

Re: Practical Common Lisp (2009)

#85

Post by sedachv »

patrec wrote: post #84
sedachv wrote: post #83

Earlier quoted context omitted.

> Wrt single precision being the default floating point type in practice: The only relevant example in your list is the fact that irrational functions coerce rational arguments to single floats ( http://clhs.lisp.se/Body/12_acc.htm ). Why do you think that dividing an integer by a single float should produce a double float?

Well, at least I appear to have got half the point across so let me spell out the other half: unlike all mainstream languages (apart from Fortran, depending on your definition of mainstream) Common Lisp interprets "normal" floating point literals as single precision floats. Technically the standard does not specify this, but in practice all implementations do it this way these days. To be precise the standard says th…

You don't understand what IEEE floating point numbers are.

IEEE 754 specifies a binary representation. There is no "normal" floating point literal notation. There are numbers in decimal or scientific notation, nothing about which will tell you what kind of internal representation the number should have (not even whether it should be floating point or not). You have to add syntax extensions (this is how Common Lisp does it: http://clhs.lisp.se/Body/02_cbb.htm) or pick an arbitrary representation. Is setting a variable to pick a representation more troublesome or "can go wrong more easily" that setting any other kind of variable for you, or is there something special about that particular variable? You might as well complain that the default Common Lisp reader/printer does not handle C99 hex float literals.

Re: Practical Common Lisp (2009)

#86

Post by kamaal »

lispm wrote: post #82
kamaal wrote: post #80

Earlier quoted context omitted.

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

The plain self-recursion part is not that great - especially one needs to write code in that TCO style. General TCO is a bit more - every tail call is a jump. I find it for example useful to have TCO code as low-level target for example for macros. You have read a good selection of Scheme books. It's very useful to explore that style of programming and be able to really understand. Take it only as a hint, that there…

What books would you recommend as further reading?

Re: Practical Common Lisp (2009)

#87

Post by [deleted] »

sedachv wrote: post #85
patrec wrote: post #84

Earlier quoted context omitted.

Well, at least I appear to have got half the point across so let me spell out the other half: unlike all mainstream languages (apart from Fortran, depending on your definition of mainstream) Common Lisp interprets "normal" floating point literals as single precision floats. Technically the standard does not specify this, but in practice all implementations do it this way these days. To be precise the standard says th…

You don't understand what IEEE floating point numbers are. IEEE 754 specifies a binary representation. There is no "normal" floating point literal notation. There are numbers in decimal or scientific notation, nothing about which will tell you what kind of internal representation the number should have (not even whether it should be floating point or not). You have to add syntax extensions (this is how Common Lisp do…

[deleted]

Re: Practical Common Lisp (2009)

#88

Post by todd8 »

armitron wrote: post #50
Jach wrote: post #44

Earlier quoted context omitted.

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

Yes, the evolution of Lisp was guided by brilliant people. I regret throwing out so many of my old Computer Science related books over the years (e.g. the Interlisp Reference Manual) because the few that remain remind me of the history of programming that has occupied so much of my life.

While being nostalgic about the early days of programming languages, I am not as pessimistic about the current state of the art. There were plenty of old programming languages that have faded away despite being important in their day (IBM's PL/1) and lots of work on new languages is pushing in interesting directions (Haskell, Idris).

Common Lisp has hung on and perhaps survivor bias has made it seem special, but to me, it is special. While working with it I feel that I am working with a language of the future from the past.

The landscape of calculation is much bigger than it was half a century ago, when I started programming. It is populated by an enormous ecosystem of processing units from tiny to enormous, embedded to networked across the planet, with single processors to high performance multiprocessors. All of this is controlled by programming and the programmers that wrestle the world of computing into submission. In this Hobbesian ecosystem some languages have prevailed for many years, like Java and C, others have survived even longer like FORTRAN and LISP, and some have simply proliferated rapidly, like Python, all for reasons that are complex and involve human abilities and computer architectures. Not all of them are beautiful, Lisp is, but all of them have a place even if only to reveal what does and doesn't work.

Re: Practical Common Lisp (2009)

#89

Post by kazinator »

sedachv wrote: post #85
patrec wrote: post #84

Earlier quoted context omitted.

Well, at least I appear to have got half the point across so let me spell out the other half: unlike all mainstream languages (apart from Fortran, depending on your definition of mainstream) Common Lisp interprets "normal" floating point literals as single precision floats. Technically the standard does not specify this, but in practice all implementations do it this way these days. To be precise the standard says th…

You don't understand what IEEE floating point numbers are. IEEE 754 specifies a binary representation. There is no "normal" floating point literal notation. There are numbers in decimal or scientific notation, nothing about which will tell you what kind of internal representation the number should have (not even whether it should be floating point or not). You have to add syntax extensions (this is how Common Lisp do…

> You have to add syntax extensions (this is how Common Lisp does it: http://clhs.lisp.se/Body/02_cbb.htm) or pick an arbitrary representation.

If an unadorned numeric token such as 2.7 generates a single-precision float (32 bit IEEE 754), that is a problem. There are good justifications why the default representation should be the 64 bit double.

The 32 bit single precision has too small a range and precision for general use; it is suitable mainly for saving space in large arrays.

We shouldn't have to use an extra suffix to indicate that we don't want that type, but rather the common double.

Even C gets this right.

Re: Practical Common Lisp (2009)

#90

Post by vram22 »

lispm wrote: post #48
vram22 wrote: post #46

Earlier quoted context omitted.

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.

Interesting, thanks.
Post reply on HN