6 ms·

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

by ryeguy 13y ago

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.

mjn 13y ago
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.
orthecreedence 13y ago
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.
johnwalker 13y ago
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.
- orthecreedence 13y ago
  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"}`.
  - johnwalker 13y ago
    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.
    - emiljbs 13y ago
      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 https://gist.github.com/ejbs/8924773
  - mjn 13y ago
    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.
    - mcn 13y ago
      I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with. 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.
adwf 13y ago
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.
- jlarocco 13y ago
  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
  - lispm 13y ago
    Why should we throw away old code? 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.
    - mcn 13y ago
      Another issue is old books. I recently got value out of PAIP and On Lisp, and I still see people recommend A Gentle Introduction to Symbolic Computation. Stepping beyond CL for a second, car and cdr have even deeper roots; for example if someone is introduced to the wider lisp-like world through SICP they will also have to become comfortable with car and cdr.
    - coldtea 13y ago
lispm 13y ago
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.
- coldtea 13y ago
  >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 before and after CL.
  - _pmf_ 13y ago
    Maybe his/her point was that this is not a problem that is specific to Common Lisp.
  - lispm 13y ago
    > 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
brudgers 13y ago
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.
- johnwalker 13y ago
  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.
  - brudgers 13y ago
    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.
    - lispm 13y ago
      Where is this fear of Common Lisp from? Just give them a fun book like Land of Lisp.
      - brudgers 13y ago
        As a beginning language Scheme and especially Racket are better designed languages. There's nothing of significance in Common Lisp that's better for a beginner and much in Scheme and Racket that is. 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.
tsm 13y ago
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...

by ryeguy 13y ago

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.

mjn 13y ago

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.

orthecreedence 13y ago

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.

johnwalker 13y ago

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.

orthecreedence 13y ago
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"}`.
- johnwalker 13y ago
  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.
  - emiljbs 13y ago
    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 https://gist.github.com/ejbs/8924773
- mjn 13y ago
  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.
  - mcn 13y ago
    I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with. 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.

adwf 13y ago

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.

jlarocco 13y ago
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
- lispm 13y ago
  Why should we throw away old code? 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.
  - mcn 13y ago
    Another issue is old books. I recently got value out of PAIP and On Lisp, and I still see people recommend A Gentle Introduction to Symbolic Computation. Stepping beyond CL for a second, car and cdr have even deeper roots; for example if someone is introduced to the wider lisp-like world through SICP they will also have to become comfortable with car and cdr.
  - coldtea 13y ago

lispm 13y ago

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.

coldtea 13y ago
>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 before and after CL.
- _pmf_ 13y ago
  Maybe his/her point was that this is not a problem that is specific to Common Lisp.
- lispm 13y ago
  > 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

brudgers 13y ago

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.

johnwalker 13y ago
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.
- brudgers 13y ago
  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.
  - lispm 13y ago
    Where is this fear of Common Lisp from? Just give them a fun book like Land of Lisp.
    - brudgers 13y ago
      As a beginning language Scheme and especially Racket are better designed languages. There's nothing of significance in Common Lisp that's better for a beginner and much in Scheme and Racket that is. 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.

tsm 13y ago

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