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

41–50 of 60 posts

Re: Common Lisp in the 21st Century

#41

Post by PuercoPop »

melipone wrote: post #32

CL in the 21st Century is Clojure.

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.

Re: Common Lisp in the 21st Century

#42

Post by brudgers »

johnwalker wrote: post #40
brudgers wrote: post #20

Earlier quoted context omitted.

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.

Although this project renames functions, that isn't all that it does. Accomodating new users is very necessary for adoption of any language, library or project, especially by having reasonable defaults. All working professional programmers were once beginners. Of course, it's another argument that this project succeeds at any of these.

I wasn't criticizing the project, just responding to comments.

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

Re: Common Lisp in the 21st Century

#44

Post by UNIXgod »

lispm wrote: post #19
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+ symbo…

tape archive.

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

Re: Common Lisp in the 21st Century

#45

Post by _pmf_ »

coldtea wrote: post #38
lispm wrote: post #19

Earlier quoted context omitted.

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+ symbo…

> What does tar mean? ls? df? gunzip (something with guns?)? 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 befo…

Maybe his/her point was that this is not a problem that is specific to Common Lisp.

Re: Common Lisp in the 21st Century

#46

Post by Derbasti »

brudgers wrote: post #27
Derbasti wrote: post #25

Earlier quoted context omitted.

What's wrong with "second"?

Nothing and Common Lisp includes second . But that's not caar . It returns the first element of the first element of a list - the extended forms of car and cdr are for nested lists and nested lists can be used to implement many different data structures [and are also the data structure containing Lisp programs]. The extended forms of car and cdr provide a form of expression which is not obvious based on the construct…

I know, so do (head (second list)), or if you must, (head2 list) or even (head list 2) or something. Still much more readable than cadr

Re: Common Lisp in the 21st Century

#47

Post by waveman2 »

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 reflects one of the fallacies that people from other languages bring to Lisp. They think that all languages are more or less immutable.

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

Re: Common Lisp in the 21st Century

#49

Post by lispm »

coldtea wrote: post #38
lispm wrote: post #19

Earlier quoted context omitted.

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+ symbo…

> What does tar mean? ls? df? gunzip (something with guns?)? 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 befo…

> How are MORE bad examples an argument against what he says? If anything they reinforce his statement.

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)
    foo

Re: Common Lisp in the 21st Century

#50

Post by lispm »

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

That's two different things. The thing below is literal syntax for hash-table objects.

It's easy to add to CL, btw.

Post reply on HN