Common Lisp in the 21st Century(github.com) |
Common Lisp in the 21st Century(github.com) |
http://www.reddit.com/r/lisp/comments/1vtueu/cl21_common_lis...
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.)
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.
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.
list directory contents.
display free space.
gunzip's not posix( though is neither tar or cpio and pax wasn't even in the original).
man(1), intro(2), intro(4), intro(8)
(recursive-documentation? man man)
% man man
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 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_CDRThat definitely seems to be one of the goals of this project: to give CL a face that makes a bit more sense.
(let ((myhash (make-hash-table :test 'equal)))
(setf (gethash "name" myhash) "andrew"
(gethash "location" myhash) "sf"))
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.
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.
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.
These are not bad examples. It is just normal to use short identifiers in many programming languages and command interfaces.
princ is in Lisp for decades. Emacs Lisp:
ELISP> (princ 'foo)
fooAnd I appear to have said "new users" when I really meant "beginners".
Experienced programmers as new users will stick if the language is appropriately expressive. Beginners will stick for different reasons and the only people who really seem to have a handle on beginner programmers from a professional standpoint is the PLT group of Racketeers. Pretty much everything else I see about beginning programmers is based on anecdote and personal opinion not the quality of data Felleissen has collected.
In all seriousness, I hope you're not suggesting Common Lisp, never mind a non-standard version of it, as a beginning programming language in the typical case when much more suitable Lisps are available and under active development.
Just give them a fun book like Land of Lisp.
If I was going to move away from Scheme and Racket for vocational reasons but stay within the Lisp family I'd give strong consideration to eLisp since it touches on toolmaking. Clojure would be a second choice because it touches on imperative programming and library use.
'((name . "andrew") (location . "sf"))
It's curious that no quasi-standard reader macro for hash literals developed, though.
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.
But even if a more compact way of constructing hash tables is called for, why a literal syntax instead of a more compact constructor? E.g. you could write
(dict "name" "andrew" "location" "sf")
(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.
Here's the code for basic hashtable syntax:
If something annoys you (like funky function names) you can alias them or add whatever you think is missing to the language.
E.g. You could define second as something like
(defun second (list) (nth 1 list))
and use it forever, just as if it were in the base language.
As an example I have a function L2HT which takes a list and returns a hash table:
(l2ht '((1 "one") (2 "two)))
(You can override the hash table type with various parameters if you like).
It's easy to add to CL, btw.
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.
For the same reason we move forward and left Algol in the past, relegated Cobol to some niche areas, etc.
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?
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.
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".
But I moved then to Common Lisp and think that learning Common Lisp from the beginning is much better. Common Lisp is much better suited to write software than Scheme or even Racket. A good Common Lisp implementation has much better tools.
At the University we had a site license of Allegro CL from Franz, Inc.. Every student had access to it via the SUN cluster. That was a revelation to me. These tools were so much better to use and for learning.
I've never explored Franz/Allegro because CCL and SBCL etc. carry less baggage because of their FOSS pedigree...it's a bias more against demo/evaluation versions than closed source.
(bikeshedding acknowledged)