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

Common Lisp in the 21st Century

github.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Common Lisp in the 21st Century

#31

Post by mcn »

lispm wrote: post #21
jlarocco wrote: post #18

Earlier quoted context omitted.

Actually, car and cdr in particular were named after the instructions used to implement them in IBM 704 assembly language. [1] The cryptic naming and backwards compatibility with completely out dated 40 year old systems are just a few things that drive me crazy about Lisp. [1] https://en.wikipedia.org/wiki/CAR_and_CDR

Why should we throw away old code? In your own code, you can use FIRST and REST for lists. But if you want to program you need to deal with that. Stuff was there before you and has a history. Changing things has a benefit, but also a cost. For a small community like Lisp, constantly rewriting code because some names change is not such a good idea. Given that we can remember thousands of words in natural languages, a…

Another issue is old books. I recently got value out of PAIP and On Lisp, and I still see people recommend A Gentle Introduction to Symbolic Computation. Stepping beyond CL for a second, car and cdr have even deeper roots; for example if someone is introduced to the wider lisp-like world through SICP they will also have to become comfortable with car and cdr.

Re: Common Lisp in the 21st Century

#33

Post by frou_dh »

AnimalMuppet wrote: post #26
Derbasti wrote: post #25

Earlier quoted context omitted.

What's wrong with "second"?

I presume you mean as opposed to "rest". The problem is, it really is "rest" instead of "second", at least in the usual case. Yes, a cons cell can contain pretty much any two things, but the most-frequently-used case (or so I believe) is that of a list. In that case, "car" means "first element of the list", and "cdr" means "the entire rest of the list", not "the second element of the list".

Personally I have found it useful to keep in mind that it's the pair that's fundamental and not the list. IIRC it was pg that made the point somewhere that car and cdr are acceptable because there really aren't any slam-dunk general terms for the parts of a pair.

Re: Common Lisp in the 21st Century

#34

Post by AnimalMuppet »

frou_dh wrote: post #33
AnimalMuppet wrote: post #26

Earlier quoted context omitted.

I presume you mean as opposed to "rest". The problem is, it really is "rest" instead of "second", at least in the usual case. Yes, a cons cell can contain pretty much any two things, but the most-frequently-used case (or so I believe) is that of a list. In that case, "car" means "first element of the list", and "cdr" means "the entire rest of the list", not "the second element of the list".

Personally I have found it useful to keep in mind that it's the pair that's fundamental and not the list. IIRC it was pg that made the point somewhere that car and cdr are acceptable because there really aren't any slam-dunk general terms for the parts of a pair.

True, and if you're thinking of them as a pair, then "first" and "second" are appropriate. But if you're using them to implement a list, then "second" is misleading.

Re: Common Lisp in the 21st Century

#35

Post by ScottBurson »

Huh. These all seem like minor details.

I think (shameless plug) that my FSet functional collections library helps modernize CL quite a bit more than this does. I've had a couple of people tell me that FSet has changed the way they program. That's a high compliment.

I'd be the first to admit that FSet takes some getting used to, but if you're willing to put in the work to learn to think this way, there are substantial benefits. It greatly expands one's opportunities to write CL code in a functional style. (Those already familiar with the functional style will find it fairly natural.)

Re: Common Lisp in the 21st Century

#36

Post by johnwalker »

ScottBurson wrote: post #35

Huh. These all seem like minor details. I think (shameless plug) that my FSet functional collections library helps modernize CL quite a bit more than this does. I've had a couple of people tell me that FSet has changed the way they program. That's a high compliment. I'd be the first to admit that FSet takes some getting used to, but if you're willing to put in the work to learn to think this way, there are substantia…

That's really cool. I've wanted your library for a long time!

Re: Common Lisp in the 21st Century

#37

Post by frou_dh »

AnimalMuppet wrote: post #34
frou_dh wrote: post #33

Earlier quoted context omitted.

Personally I have found it useful to keep in mind that it's the pair that's fundamental and not the list. IIRC it was pg that made the point somewhere that car and cdr are acceptable because there really aren't any slam-dunk general terms for the parts of a pair.

True, and if you're thinking of them as a pair , then "first" and "second" are appropriate. But if you're using them to implement a list, then "second" is misleading.

I'd probably go with "left" and "right" to get away from the implication of priority. I didn't type this using my first and second hands.

(bikeshedding acknowledged)

Re: Common Lisp in the 21st Century

#38

Post by coldtea »

lispm wrote: post #19
ryeguy wrote: post #4

One of the annoyances of CL is the absolutely nonsense function names. Just looking at these examples, I have no idea what princ (something to do with print, i assume), getf, or elt (element?) mean.

What does tar mean? ls? df? gunzip (something with guns?)? Every language old enough will assemble some naming problems. If you look at newer languages, even there naming is still the old problem. Clojure: What does fnext do different than nnext? Can you guess what rseq does? With larger software systems, you'll see that you will need to look up documentation quite often. On my old Lisp Machine there are 60000+ symbo…

>What does tar mean? ls? df? gunzip (something with guns?)?

How are MORE bad examples an argument against what he says? If anything they reinforce his statement.

Plus, the thing with "tar" and "ls" is that they've been tar and ls in all Unices for decades. If you learn "ls", and maybe "dir" if you want to use Windows, you're golden. Whereas every language seems to use its own names for "princ", "setf" etc, both before and after CL.

Re: Common Lisp in the 21st Century

#39

Post by coldtea »

lispm wrote: post #21
jlarocco wrote: post #18

Earlier quoted context omitted.

Actually, car and cdr in particular were named after the instructions used to implement them in IBM 704 assembly language. [1] The cryptic naming and backwards compatibility with completely out dated 40 year old systems are just a few things that drive me crazy about Lisp. [1] https://en.wikipedia.org/wiki/CAR_and_CDR

Why should we throw away old code? In your own code, you can use FIRST and REST for lists. But if you want to program you need to deal with that. Stuff was there before you and has a history. Changing things has a benefit, but also a cost. For a small community like Lisp, constantly rewriting code because some names change is not such a good idea. Given that we can remember thousands of words in natural languages, a…

>Why should we throw away old code?

For the same reason we move forward and left Algol in the past, relegated Cobol to some niche areas, etc.

Re: Common Lisp in the 21st Century

#40

Post by johnwalker »

brudgers wrote: post #20
ryeguy wrote: post #4

One of the annoyances of CL is the absolutely nonsense function names. Just looking at these examples, I have no idea what princ (something to do with print, i assume), getf, or elt (element?) mean.

The thing to realize about Common Lisp is that it's not built to accommodate new users in the manner that Scheme was. Common Lisp is entirely intended to be a language for working professional programmers. Implicit in its specification is the idea that any feature that a programmer does not like will be changed, Renaming functions is largely a trivial exercise.

Although this project renames functions, that isn't all that it does. Accomodating new users is very necessary for adoption of any language, library or project, especially by having reasonable defaults. All working professional programmers were once beginners. Of course, it's another argument that this project succeeds at any of these.
Post reply on HN