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

11–20 of 60 posts

Re: Common Lisp in the 21st Century

#11

Post by johnwalker »

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

Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.

Re: Common Lisp in the 21st Century

#12

Post by orthecreedence »

[deleted] wrote: post #8

[deleted]

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.

Re: Common Lisp in the 21st Century

#13

Post by mjn »

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

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 'name and 'location to be strings.)

It's curious that no quasi-standard reader macro for hash literals developed, though.

Re: Common Lisp in the 21st Century

#14

Post by adwf »

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

Re: Common Lisp in the 21st Century

#15

Post by martinflack »

[deleted] wrote: post #8

[deleted]

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.

Re: Common Lisp in the 21st Century

#16

Post by emiljbs »

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

Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.

Huh? No you don't... Maybe I don't get what you mean.

Here's the code for basic hashtable syntax:

https://gist.github.com/ejbs/8924773

Re: Common Lisp in the 21st Century

#17

Post by ruricolist »

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

One could make the argument (I think so, at least) that if the number of associations you are dealing with is small enough to write out literally, then using a hash table is a mistake. It might be one of Common Lisp's strengths that is has ways to represent small tables efficiently and thus avoids the "hash addiction" that haunts languages where hash tables are used for everything.

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")
with a compiler macro that produces exactly the above code.

Re: Common Lisp in the 21st Century

#18

Post by jlarocco »

adwf wrote: post #14
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 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

Re: Common Lisp in the 21st Century

#19

Post by lispm »

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.

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.

Re: Common Lisp in the 21st Century

#20

Post by brudgers »

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 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.
Post reply on HN