11 ms·

One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}

One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that. Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print? A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to clean up the syntax.

TeMPOraL 12y ago
Honestly? Mostly because Lisp conventions predate "the rest of the programming world". As for while-let1, it's a while-let with just one variable binding (I guess I'd prefer them to stick with just while-let). There's usually a very good reason behind all those "unusual names" of Common Lisp. I don't think that dumbing things up so that they look more similar to everything else in a language that is already different from anything else is the way to go.
- chrisduesing 12y ago
  I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school programmers (who won't use it anyway) a few keystrokes, it is to throw away the cruft of decades of "a very good reason" decisions for something simpler and better thought out. I really like the direction of this project, but I agree with the parent comment, it doesn't go far enough.
  - bad_user 12y ago
    I don't know German, but I have a huntch that Romanian, my native language, is more complex than German, except that Romanian has firm roots in latin, therefore more people unfamiliar with both will have an easier time with Romanian, since we have a significant portion of our vocabulary similar to Italian or Spanish, plus we borrowed words from French, along with many neologisms coming straight from English. Just because a language is unfamiliar, that does not make it hard or complex, just because you're not speaking it. Consequently, just because a language seems superficially familiar, that doesn't make it easy to learn - for programming languages it takes weeks to understand the basic necessities, whereas it takes years to become a master, regardless of the programming language you're talking about. Also, Erlang's Prolog-like syntax sucks, not because it's unfamiliar, but because it objectively sucks.
    - chaoky 12y ago
      This. Arguing that Common Lisp sucks because the names of functions are not sufficiently python/C/Algol-like is like arguing Chinese languages are never going to become widely accepted because they aren't sufficiently like European languages. People who argue against car/cdr are the same people who will blindly accept printf, strlen, scanf (wtf?), __le__, zip. They accept those names because they actually learned the language and discovered those were trivial details and don't judge something so superficially. (also, ~95% of common lisp names are more like with-open-file, or define-setf-expansion, or make-load-form, or most-positive-float, or standard-input, instead of, what mkStr, <stdin>, isalnum, fprintf, ? :, and the like)
      - chrisduesing 12y ago
        No one is arguing that CL sucks, but that if you are going to re-skin the whole thing with learnings from modern languages, with features like string interpolation, then you might as well make the function names more intuitive while you are at it. The specific example is talking about doing away with the format function in favor of the princ function. What is the argument against calling it print? No one is suggesting fprintf by the way. You and the parent are also citing spoken languages, and certainly if you are a Chinese speaker then the difference between princ and print is going to be nominal to you. However, if you are a native English speaker, not so much. Really though, once you learn one programming language with standard library function names in English, then the second will be easier to learn if it uses similar names. Back to the subject at hand, the case being made here is that most modern languages choose things a bit easier for the brain to parse; they aren't overly shortened, they aren't Hungarian notation, etc.. The reason for that is that it requires enough brain power to learn a new language, its structure, libraries and quirks without also having to memorize strange sequences of consonants. Here is some code I wrote yesterday. Even if you never saw Ruby before in your life, don't know what blocks are, and have no idea what the array/enum functions are, you can probably figure out what this code is doing. invoices = @organization.subscriptions.collect{|s| s.invoices}.flatten current_invoices = invoices.select {|i| i.invoice_period_begin_date <= Date.today && i.invoice_period_end_date > Date.today } current_paid_invoices, current_unpaid_invoices = current_invoices.partition {|i| i.paid?} and THAT is why if you are designing a new language from scratch, you should strongly consider using intuitive function names.
  - rudiger 12y ago
    Erlang, despite its fusty syntax, already feels like the future for anyone using it.
- gaius 12y ago
  Things that made perfect sense in the 1970s, are not set in stone for all time.
  - yarrel 12y ago
    In the case of Lisp those things, from the 1950s to the 1990s, have rationales. Updating the names to 2010s fashions just means we'll have something that people can't understand in the 2020s and that they can't check the history of.
    - chrisduesing 12y ago
      So in 2020 people will have forgotten the etymology of print or format, rendering them nearly meaningless while princ, car and cdr endure? That's rhetorical, you don't need to reply.
      - TeMPOraL 12y ago
        So you think we're better off just giving up on a perfectly good reason for these naming conventions and call "princ" "print" just because some poor language without the concept of Read-Eval-Print Loop named its function that way and then everyone else blindly followed? Seriously, Lisp has long history and had half the "new amazing features of today" 30 years ago. There is a rationale for naming conventions. Just because you're free to call a string-spitting function "print" in Ruby or Pascal or whatever doesn't mean you can do it in a language with a proper REPL.
        chrisduesing 12y ago
        Yes. Of course I wouldn't characterize it as blindly following so much as being able to rationally step back with some perspective and identify some trends as positive. Lisps are a beautiful and powerful family of languages, but you are conflating the implementation with the idea. The names of functions from 30 years ago are not what makes Lisp special.
        Morgawr 12y ago
agumonkey 12y ago
As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents
- desdiv 12y ago
  car/cdr also enables things like caar/cadr, which I personally find much clearer than "headHead" or "headOfHead".
- chc 12y ago
  @desdiv: If you happen to read this, you appear to have been hellbanned. Not sure why. Just a friendly heads-up.
  - desdiv 12y ago
    Thank you so much for letting me know! I've emailed the admins about it.
- jerf 12y ago
  As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be far better off shipping "first" & "rest" and whispering to the old hands that you're sure they know how to "fix" the problem in their code, than presenting new people with car & cdr and then try to wedge an explanation into a brain that just threw an exception and went "Wait, what?"
  - coliveira 12y ago
    first and rest are already part of the language, no change necessary. You just need to use books that teach using first and rest instead of car and cdr.
gongador 12y ago
Because PRINT also exists, and doesn't do the same thing PRINC does. http://www.lispworks.com/documentation/lw61/CLHS/Body/f_wr_pr.htm http://www.lispworks.com/documentation/lw61/CLHS/Body/f_wr_p...
phabian 12y ago
Common Lisp has several "print" functions.See: http://www.lispworks.com/documentation/HyperSpec/Body/f_wr_pr.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_wr_p...
bane 12y ago
Yeah, lots of this is just swapping out one awkward keyword for another. If I were doing this I'd also get rid of the * around the hash keyword and either just go with the keyword 'hash' or replace it all together with an operator. It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Why not switch the parens to something that's a single keystroke? Why not get rid of the parens in most cases? In some cases this seems to make the parens problem with lisp even worse? (loop for key being each hash-key of *hash* using (hash-value val) when (< (length key) 2) do (format t "~A~%" val)) with 5 sets of parens turns into (doeach ((key val) *hash*) (when (< (length key) 2) (princ #"${x}\n"))) six sets the former also required fewer shift-character keystroke combinations ( ) * < " ~ % while the new syntax ends up with ( ) * < # " $ { } this feels like my hands are wrestling, not typing this just seems to be moving things around, not really improving anything I'm not a lisper, so somebody correct me if I'm wrong
- agentultra 12y ago
  > Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enabled, surprise of surprises, by Common Lisp because it was designed to be extensible. My theory is that if your language of choice needs to change its grammar rules to introduce new features you're basically admitting that you should have added macros programmatic access to the reader. > It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Well syntax is at a minimum in Common Lisp. It tends to avoid syntactical short-hand. The most common I know of being QUOTE, BACKQUOTE, UNQUOTE, UNQUOTE-SPLICE, and FUNCTION: ' ` , ,@ and #' respectively. If you read the preface to the first edition of Structure and Interpretation of Computer Programs I think you will find an enlightening explanation of, Why Lisp?. To paraphrase a brief summary: there are very few ways to form compound expressions and hardly any syntax at all so that the programmer can get to the problem at hand within an hour: the language disappears. The longer names are chosen stylistically based on the maxim that computer programs are meant for humans to read and only incidentally to be executed by a computer. Lisps are not, contrary to popular mythology, list-processing languages. It's a symbolic language. The relationship between symbol and data allows the programmer to think primarily about the transformations to data without the abstractions becoming weak. > Why not switch the parens to something that's a single keystroke? You could. Common Lisp gives you access to the reader. You can write a more fitting syntax you are more comfortable with. I've written reader macros to parse assembler instructions for an emulator I wrote in Common Lisp. > this just seems to be moving things around, not really improving anything That's my impression too. These sorts of experiments are worth trying from time to time in order to see if something can come from them. Maybe something will come out of this. But ultimately people bike-shed over "car/cdr" and specialized functions for specific data-types (ie: AREF, GET-HASH, etc). You can write higher-order functions to abstract away sequence access and iteration if you want: people have and there are good libraries for it. The standard hasn't changed AFAIK because: 1. It'd be expensive and nobody wants to fund another ANSI committee. 2. There haven't been any significant proposals the necessitate revisiting the specification. People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementations for quite some time. We even have good libraries that provide a cross-platform layer to things like threading.
jimbokun 12y ago
"In spite of this, it has not had much success (at least in Japan)." From this and the author's name (Eitaro Fukamachi), I wonder if he is not a native English speaker. This could shed light on differences in aesthetic choices about function names. Difference between "princ" and "print", or awkwardness of "while-let1" may not resonate as much for a non-native speaker.

TeMPOraL 12y ago

Honestly? Mostly because Lisp conventions predate "the rest of the programming world". As for while-let1, it's a while-let with just one variable binding (I guess I'd prefer them to stick with just while-let). There's usually a very good reason behind all those "unusual names" of Common Lisp. I don't think that dumbing things up so that they look more similar to everything else in a language that is already different from anything else is the way to go.

chrisduesing 12y ago
I do. There is a reason for the success of Ruby and Python, and why Elixir is dragging Erlang in to the present. It turns out you don't just have to write your language in the shape of the machine/vm but it can be a tool conformed to the mind of the programmer. "princ" is not easy to remember, read or associate to other things one already knows. The point of a project like this should not be to save old school programmers (who won't use it anyway) a few keystrokes, it is to throw away the cruft of decades of "a very good reason" decisions for something simpler and better thought out. I really like the direction of this project, but I agree with the parent comment, it doesn't go far enough.
- bad_user 12y ago
  I don't know German, but I have a huntch that Romanian, my native language, is more complex than German, except that Romanian has firm roots in latin, therefore more people unfamiliar with both will have an easier time with Romanian, since we have a significant portion of our vocabulary similar to Italian or Spanish, plus we borrowed words from French, along with many neologisms coming straight from English. Just because a language is unfamiliar, that does not make it hard or complex, just because you're not speaking it. Consequently, just because a language seems superficially familiar, that doesn't make it easy to learn - for programming languages it takes weeks to understand the basic necessities, whereas it takes years to become a master, regardless of the programming language you're talking about. Also, Erlang's Prolog-like syntax sucks, not because it's unfamiliar, but because it objectively sucks.
  - chaoky 12y ago
    This. Arguing that Common Lisp sucks because the names of functions are not sufficiently python/C/Algol-like is like arguing Chinese languages are never going to become widely accepted because they aren't sufficiently like European languages. People who argue against car/cdr are the same people who will blindly accept printf, strlen, scanf (wtf?), __le__, zip. They accept those names because they actually learned the language and discovered those were trivial details and don't judge something so superficially. (also, ~95% of common lisp names are more like with-open-file, or define-setf-expansion, or make-load-form, or most-positive-float, or standard-input, instead of, what mkStr, <stdin>, isalnum, fprintf, ? :, and the like)
    - chrisduesing 12y ago
      No one is arguing that CL sucks, but that if you are going to re-skin the whole thing with learnings from modern languages, with features like string interpolation, then you might as well make the function names more intuitive while you are at it. The specific example is talking about doing away with the format function in favor of the princ function. What is the argument against calling it print? No one is suggesting fprintf by the way. You and the parent are also citing spoken languages, and certainly if you are a Chinese speaker then the difference between princ and print is going to be nominal to you. However, if you are a native English speaker, not so much. Really though, once you learn one programming language with standard library function names in English, then the second will be easier to learn if it uses similar names. Back to the subject at hand, the case being made here is that most modern languages choose things a bit easier for the brain to parse; they aren't overly shortened, they aren't Hungarian notation, etc.. The reason for that is that it requires enough brain power to learn a new language, its structure, libraries and quirks without also having to memorize strange sequences of consonants. Here is some code I wrote yesterday. Even if you never saw Ruby before in your life, don't know what blocks are, and have no idea what the array/enum functions are, you can probably figure out what this code is doing. invoices = @organization.subscriptions.collect{|s| s.invoices}.flatten current_invoices = invoices.select {|i| i.invoice_period_begin_date <= Date.today && i.invoice_period_end_date > Date.today } current_paid_invoices, current_unpaid_invoices = current_invoices.partition {|i| i.paid?} and THAT is why if you are designing a new language from scratch, you should strongly consider using intuitive function names.
- rudiger 12y ago
  Erlang, despite its fusty syntax, already feels like the future for anyone using it.
gaius 12y ago
Things that made perfect sense in the 1970s, are not set in stone for all time.
- yarrel 12y ago
  In the case of Lisp those things, from the 1950s to the 1990s, have rationales. Updating the names to 2010s fashions just means we'll have something that people can't understand in the 2020s and that they can't check the history of.
  - chrisduesing 12y ago
    So in 2020 people will have forgotten the etymology of print or format, rendering them nearly meaningless while princ, car and cdr endure? That's rhetorical, you don't need to reply.
    - TeMPOraL 12y ago
      So you think we're better off just giving up on a perfectly good reason for these naming conventions and call "princ" "print" just because some poor language without the concept of Read-Eval-Print Loop named its function that way and then everyone else blindly followed? Seriously, Lisp has long history and had half the "new amazing features of today" 30 years ago. There is a rationale for naming conventions. Just because you're free to call a string-spitting function "print" in Ruby or Pascal or whatever doesn't mean you can do it in a language with a proper REPL.
      - chrisduesing 12y ago
        Yes. Of course I wouldn't characterize it as blindly following so much as being able to rationally step back with some perspective and identify some trends as positive. Lisps are a beautiful and powerful family of languages, but you are conflating the implementation with the idea. The names of functions from 30 years ago are not what makes Lisp special.
      - Morgawr 12y ago

agumonkey 12y ago

As odd as it may seem, I ended up prefering car/cdr over anything else (except when access to pattern matching and destructuring). I know first/rest, head/tail or even fst/snd are clearer names, but car/cdr ended up as symbols having precisely this meaning in LISP idioms (recursion over cons-cell based lists). My 1.5cents

desdiv 12y ago
car/cdr also enables things like caar/cadr, which I personally find much clearer than "headHead" or "headOfHead".
chc 12y ago
@desdiv: If you happen to read this, you appear to have been hellbanned. Not sure why. Just a friendly heads-up.
- desdiv 12y ago
  Thank you so much for letting me know! I've emailed the admins about it.
jerf 12y ago
As a non-Lisper, I can assure you beyond a shadow of a doubt that having "car" & "cdr" show up in the first few sections of a tutorial is not something that wins people over to Lisp. I don't mean that I don't understand it. I even know they come from assembler instruction names. And they still look weird to me and still have no meaning despite having read what the abbreviation expands to three or four times. You'd be far better off shipping "first" & "rest" and whispering to the old hands that you're sure they know how to "fix" the problem in their code, than presenting new people with car & cdr and then try to wedge an explanation into a brain that just threw an exception and went "Wait, what?"
- coliveira 12y ago
  first and rest are already part of the language, no change necessary. You just need to use books that teach using first and rest instead of car and cdr.

gongador 12y ago

Because PRINT also exists, and doesn't do the same thing PRINC does. http://www.lispworks.com/documentation/lw61/CLHS/Body/f_wr_pr.htm http://www.lispworks.com/documentation/lw61/CLHS/Body/f_wr_p...

phabian 12y ago

Common Lisp has several "print" functions.See: http://www.lispworks.com/documentation/HyperSpec/Body/f_wr_pr.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_wr_p...

bane 12y ago

Yeah, lots of this is just swapping out one awkward keyword for another. If I were doing this I'd also get rid of the * around the hash keyword and either just go with the keyword 'hash' or replace it all together with an operator. It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Why not switch the parens to something that's a single keystroke? Why not get rid of the parens in most cases? In some cases this seems to make the parens problem with lisp even worse? (loop for key being each hash-key of *hash* using (hash-value val) when (< (length key) 2) do (format t "~A~%" val)) with 5 sets of parens turns into (doeach ((key val) *hash*) (when (< (length key) 2) (princ #"${x}\n"))) six sets the former also required fewer shift-character keystroke combinations ( ) * < " ~ % while the new syntax ends up with ( ) * < # " $ { } this feels like my hands are wrestling, not typing this just seems to be moving things around, not really improving anything I'm not a lisper, so somebody correct me if I'm wrong

agentultra 12y ago
> Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enabled, surprise of surprises, by Common Lisp because it was designed to be extensible. My theory is that if your language of choice needs to change its grammar rules to introduce new features you're basically admitting that you should have added macros programmatic access to the reader. > It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Well syntax is at a minimum in Common Lisp. It tends to avoid syntactical short-hand. The most common I know of being QUOTE, BACKQUOTE, UNQUOTE, UNQUOTE-SPLICE, and FUNCTION: ' ` , ,@ and #' respectively. If you read the preface to the first edition of Structure and Interpretation of Computer Programs I think you will find an enlightening explanation of, Why Lisp?. To paraphrase a brief summary: there are very few ways to form compound expressions and hardly any syntax at all so that the programmer can get to the problem at hand within an hour: the language disappears. The longer names are chosen stylistically based on the maxim that computer programs are meant for humans to read and only incidentally to be executed by a computer. Lisps are not, contrary to popular mythology, list-processing languages. It's a symbolic language. The relationship between symbol and data allows the programmer to think primarily about the transformations to data without the abstractions becoming weak. > Why not switch the parens to something that's a single keystroke? You could. Common Lisp gives you access to the reader. You can write a more fitting syntax you are more comfortable with. I've written reader macros to parse assembler instructions for an emulator I wrote in Common Lisp. > this just seems to be moving things around, not really improving anything That's my impression too. These sorts of experiments are worth trying from time to time in order to see if something can come from them. Maybe something will come out of this. But ultimately people bike-shed over "car/cdr" and specialized functions for specific data-types (ie: AREF, GET-HASH, etc). You can write higher-order functions to abstract away sequence access and iteration if you want: people have and there are good libraries for it. The standard hasn't changed AFAIK because: 1. It'd be expensive and nobody wants to fund another ANSI committee. 2. There haven't been any significant proposals the necessitate revisiting the specification. People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementations for quite some time. We even have good libraries that provide a cross-platform layer to things like threading.

jimbokun 12y ago

"In spite of this, it has not had much success (at least in Japan)." From this and the author's name (Eitaro Fukamachi), I wonder if he is not a native English speaker. This could shed light on differences in aesthetic choices about function names. Difference between "princ" and "print", or awkwardness of "while-let1" may not resonate as much for a non-native speaker.