Common Lisp in the 21st Century (opens in new tab)

I assume that's:

http://common-lisp.net/project/fset/

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

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+ symbols naming tens of thousands functions. So naming becomes important. When Lisp was small, there were functions which print something, then variations were added and people tried to keep the names short. After a while there were so many functions and memory was larger. People started to use longer names. CALL-WITH-CURRENT-CONTINUATION (in Scheme) or SET-DISPATCH-MACRO-CHARACTER were the results. ;-) Now we got nice descriptive names, but we need completion during input.

There is no way other than to learn a certain base vocabulary. Since the printer is essential in Lisp, you'll need to learn functions like princ or print to read older code. In your own code you can just use WRITE, which is a general interface into the printer.

Fortunately enough, the documentation of these functions is just a keypress away in any good Lisp implementation.

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.

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 their argument order, doh...)

So it's kind of a no-win situation really. But I like this attempt to provide a common substrate and hope that it will succeed where others have failed.

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.

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.

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

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

Damn right, I love how clojure hosted semantics import all the great features of their host. Like how clojurescript has only floating point numbers and coerces string to numbers when using the + operator.

In all seriousness, I mad love to Clojure, but is a different language with different sensibilities/tradeoff. Not a 'better' CL. For example, I imagine that interfacing with c code using cffi should be way easier and simpler than using JNI and then exposing that to clojure. Or having defined semantics for numerical computations.

Inexplicable stack traces caused by mediocre tools?

cause, in Lisp OO is done right ;)