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

21–30 of 60 posts

Re: Common Lisp in the 21st Century

#21

Post by lispm »

jlarocco wrote: post #18
adwf wrote: post #14

Earlier quoted context omitted.

I assume that historically it's because they were trying to keep function names short to help save memory, don't forget Lisp in one form or another has been around for a loooong time. A lot of the time there are more descriptive alternatives: car -> first, cdr -> rest, elt -> nth, etc... However, these are also complained about by a lot of people as unnecessarily bloating the language! (plus, elt/nth manage to invert…

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 few hundred core words of a programming language is not such a huge hurdle.

Re: Common Lisp in the 21st Century

#22

Post by mcn »

mjn wrote: post #13
orthecreedence wrote: post #9

Earlier quoted context omitted.

I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.

I think this comes down to some historical baggage around the original idea that people would just use association lists ("alists") by default, while hashtables would be an advanced feature used mainly in the optimization phase, when profiling indicated that alist lookups were a bottleneck. The alist literal is a lot friendlier: '((name . "andrew") (location . "sf")) (Incidentally, you probably don't really want 'nam…

I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with.

It's not a lot of code or too complex to do that, but it's not obvious either and some people got it wrong or do it differently and I think that made reader modifications less common than they otherwise might have been.

I haven't looked too closely at the details but some of cl21's changes look like they might try to address this issue.

Re: Common Lisp in the 21st Century

#23

Post by brudgers »

jlarocco wrote: post #18
adwf wrote: post #14

Earlier quoted context omitted.

I assume that historically it's because they were trying to keep function names short to help save memory, don't forget Lisp in one form or another has been around for a loooong time. A lot of the time there are more descriptive alternatives: car -> first, cdr -> rest, elt -> nth, etc... However, these are also complained about by a lot of people as unnecessarily bloating the language! (plus, elt/nth manage to invert…

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

That car and cdr can be aliased easily by any Lisp programmer might lead a person to wonder why they survive and are even included in more modern Lisps such as Racket.

The reason is the expressive power of their extended versions - e.g. caadr or cdaar don't have easily derived equivalents from first and rest and those that can be derived are at best equally bad or worse...ffirest and reffst anyone?

Re: Common Lisp in the 21st Century

#25

Post by Derbasti »

brudgers wrote: post #23
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

That car and cdr can be aliased easily by any Lisp programmer might lead a person to wonder why they survive and are even included in more modern Lisps such as Racket. The reason is the expressive power of their extended versions - e.g. caadr or cdaar don't have easily derived equivalents from first and rest and those that can be derived are at best equally bad or worse... ffirest and reffst anyone?

What's wrong with "second"?

Re: Common Lisp in the 21st Century

#26

Post by AnimalMuppet »

Derbasti wrote: post #25
brudgers wrote: post #23

Earlier quoted context omitted.

That car and cdr can be aliased easily by any Lisp programmer might lead a person to wonder why they survive and are even included in more modern Lisps such as Racket. The reason is the expressive power of their extended versions - e.g. caadr or cdaar don't have easily derived equivalents from first and rest and those that can be derived are at best equally bad or worse... ffirest and reffst anyone?

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".

Re: Common Lisp in the 21st Century

#27

Post by brudgers »

Derbasti wrote: post #25
brudgers wrote: post #23

Earlier quoted context omitted.

That car and cdr can be aliased easily by any Lisp programmer might lead a person to wonder why they survive and are even included in more modern Lisps such as Racket. The reason is the expressive power of their extended versions - e.g. caadr or cdaar don't have easily derived equivalents from first and rest and those that can be derived are at best equally bad or worse... ffirest and reffst anyone?

What's wrong with "second"?

Nothing and Common Lisp includes second. But that's not caar. It returns the first element of the first element of a list - the extended forms of car and cdr are for nested lists and nested lists can be used to implement many different data structures [and are also the data structure containing Lisp programs].

The extended forms of car and cdr provide a form of expression which is not obvious based on the construction of common non-Lisp languages even those that have very flexible lists and dynamic typing.

Re: Common Lisp in the 21st Century

#28

Post by tsm »

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.

At least with CL there's a certain logic to it. getf => get form, setf => set form, setq => set quote, etcetera. All languages are guilty of this—I used to be bothered by Python's len() and Ruby's .uniq() and so on and so forth, but you get used to it after a while. Except for PHP. You never get used to PHP...

Re: Common Lisp in the 21st Century

#30

Post by 6d0debc071 »

orthecreedence wrote: post #9
johnwalker wrote: post #7

Earlier quoted context omitted.

The functions are basically inconsistent in both name and argument order. I think that's one of the problems they're working on correcting (a generic elt/getf), and more obvious ways of creating and using non-list data structures.

I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.

Or you can write a function for it and do something like:

(let ((myhash (make-hash-table :test 'equal))) (add-hash-entry (("name" "Andrew") ("location" "sf")) myhash)

Which seems, to me, easier than having more special-case syntax to learn.

But I suspect this may be one of the drawbacks of Lisp, (indeed, it may turn out to be a problem with any powerful programming language.) It's so absurdly easy to do things like that, that incremental advances can be retarded by virtue of the steps along the way not being shared. And then when someone has to come along and use what you've written, without having been there for the steps along the way, the base level of abstraction they have to build up from is too low.

Post reply on HN