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

1–10 of 60 posts

Re: Common Lisp in the 21st Century

#3

Post by adwf »

I've always thought that CL needed a set of common libraries to be strongly recommended. The problem is that it has been tried before, but never really taken off.

However, given the recent rise of quicklisp for managing libraries, it's entirely possible that a project of this type will be much more successful. I hope so!

I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself, just because it was glaringly missing from the CL core spec.

Re: Common Lisp in the 21st Century

#4

Post by ryeguy »

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.

Re: Common Lisp in the 21st Century

#5

Post by orthecreedence »

adwf wrote: post #3

I've always thought that CL needed a set of common libraries to be strongly recommended. The problem is that it has been tried before, but never really taken off. However, given the recent rise of quicklisp for managing libraries, it's entirely possible that a project of this type will be much more successful. I hope so! I still remember the first time I looked at the Alexandria library and realised I'd already imple…

> I still remember the first time I looked at the Alexandria library and realised I'd already implemented a good 1/4 of the functionality myself

Yeah, same here. I have a bunch of utilities lying around from when I started that Alexandria would have completely obliterated.

I'm interested in cl21's use of symbol partitioning. I've always thought the `cl:` package was really, really bloated and somewhat confusing to newcomers. Something that divides everything into "this is for math" "this is for primitive data types" etc would make things a bit easier to manage.

I know /r/lisp didn't really like it for the most part, but since the spec is frozen it's nice to see people who are involved in lisp actively trying to make it better. The world is littered with successful projects that started out with people saying "You're wrong, don't bother doing this." I wish Mr. Fukamachi well and look forward to progress.

Re: Common Lisp in the 21st Century

#6

Post by orthecreedence »

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.

Yeah, you're right. A lot of people are turned off by it and a lot of the old-guard just say "deal with it!!" After getting used to a lot of the symbols (`car`, `cadr`, etc) you kind of stop being too annoyed and don't even notice them anymore. It's like learning another language, there's not always a 1:1 mapping of words. That said, it's much better to recognize a problem and try to fix it that say "It has worked fine for 50 years!! Leave it!"

That definitely seems to be one of the goals of this project: to give CL a face that makes a bit more sense.

Re: Common Lisp in the 21st Century

#7

Post by johnwalker »

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

Re: Common Lisp in the 21st Century

#9

Post by orthecreedence »

johnwalker wrote: post #7
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 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"}`.

Re: Common Lisp in the 21st Century

#10

Post by mjn »

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.

I find that mildly annoying as well, though since I came to Lisp after Unix/C, it didn't make a huge impression on me. It's possibly more grating in CL just because it doesn't fit the rest of the aesthetic: in user-written code it's idiomatic to write functions with names like sort-database, not like srtdb. While with Unix + C you don't really expect utilities or functions to have anything but cryptic names. I think some of it may relate to Lisp coalescing over many years: some of those old cryptically named functions were named in the 1950s or 1960s, when every language of the time, from ALGOL to FORTRAN to LISP (not to mention assemblers), used identifiers like that— in all caps, of course.
Post reply on HN