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.)
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+ 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'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.
> 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.
It's general purpose. It's a high-level language that has OS-level threading, can be functional/imperative, compiles to machine code, has powerful macros which completely cut down code repetition and allow syntax expansion, can call out to C without compiling wrappers. About the only thing it's missing are coroutines, and even those can be mimicked by macros to some extent. Really, a better question is what can't lisp do. It's probably not the best choice for an embedded device or something like that, or anywhere you need tight control over memory/resources. I'd say it's an extremely decent complement to C in a lot of respects. If you can get passed some of the oddly-named symbols, it's a great language that has made leaps and bounds in the past 10 years as far as third-party libraries and implementation features.
Well, it's amazing for rapid prototyping. The same could be said for Ruby/Perl etc but the addition of the REPL, CLOS, Macros, etc make it slightly better. As long as the libraries exist for CL upon which to build, which can be a sticking point.
To give the more canonical answer, though... CL is the programmable programming language, so it's not suited for a task per se; rather you lay down a base that's suited to your problem domain, and then you solve your problem in your newly-created "language". It's hard to explain but true if you get it right.
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.
[+] [-] emiljbs|12 years ago|reply
http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lis...
[+] [-] ScottBurson|12 years ago|reply
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.)
[+] [-] e12e|12 years ago|reply
http://common-lisp.net/project/fset/
[+] [-] johnwalker|12 years ago|reply
[+] [-] ryeguy|12 years ago|reply
[+] [-] lispm|12 years ago|reply
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.
[+] [-] mjn|12 years ago|reply
[+] [-] adwf|12 years ago|reply
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.
[+] [-] brudgers|12 years ago|reply
[+] [-] orthecreedence|12 years ago|reply
That definitely seems to be one of the goals of this project: to give CL a face that makes a bit more sense.
[+] [-] tsm|12 years ago|reply
[+] [-] johnwalker|12 years ago|reply
[+] [-] adwf|12 years ago|reply
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.
[+] [-] orthecreedence|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] orthecreedence|12 years ago|reply
[+] [-] martinflack|12 years ago|reply
To give the more canonical answer, though... CL is the programmable programming language, so it's not suited for a task per se; rather you lay down a base that's suited to your problem domain, and then you solve your problem in your newly-created "language". It's hard to explain but true if you get it right.
[+] [-] melipone|12 years ago|reply
[+] [-] PuercoPop|12 years ago|reply
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.
[+] [-] stewbrew|12 years ago|reply
[+] [-] vseloved|12 years ago|reply
[deleted]
[+] [-] kenbot|12 years ago|reply
[+] [-] vseloved|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]