6 ms·

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

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.
    - TeMPOraL 12y ago
      > What is the argument against calling it print? No one is suggesting fprintf by the way. Very simple, actually. You know the term REPL, right? It stands for Read-Eval-Print Loop, and originates with Lisp. Actually, every Lisp gives you read, eval and print functions which work closely together. In particular, you expect read to be able to understand what print outputs, because they work in a loop. So print is already taken. As for other prin* functions, see here: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_writecm_p_rintcm_princ.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec.... There is a good rationale behind those names. And no one uses princ for interpolated string output anyway. As for your code, things like princ or while-let1 are more-less equivalent of @, |sth|, ?, etc. in your code - i.e. there are some basics you have to learn with every language. > 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. Well, you don't get closer to that goal than with Lisp and the majority of its naming conventions. From make-instance to destructuring-bind to multiple-value-bind to update-instance-for-redefined-class, most of the things are named pretty well and readable for a programming language. I can't help but see these arguments about "intuitive names" as finding just another excuse not to learn something new.
- Retra 12y ago
  Familiarity makes it easier to learn, not easy. Just as long as you don't betray anyone's expectations about what they already know. I remember struggling with Haskell because there is a function called 'nub', which wasn't anywhere near what I would have called the function if I had named it. Hoogle says "(The name nub means `essence'.)" In Lisp it is called 'remove-duplicates.' In Python it is list(set(x)). In SQL it is 'select distinct.' So what advantage does nub pose? Not one of clarity, but of convenience for those "in the know." (Which is not those who are learning the language.)
  - bsummer4 12y ago
    nub is widely recognized to be a terrible function; it's not indicative of anything
    - Retra 12y ago
      It's not? Then I suppose princ is a fine name for a print function.
      - bsummer4 12y ago
        Unfortunately, name, `nub`, is the best thing about this function. It has horrible (O(n^2)) performance, and only works with lists.
rudiger 12y ago
Erlang, despite its fusty syntax, already feels like the future for anyone using it.

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.
  - TeMPOraL 12y ago
    > What is the argument against calling it print? No one is suggesting fprintf by the way. Very simple, actually. You know the term REPL, right? It stands for Read-Eval-Print Loop, and originates with Lisp. Actually, every Lisp gives you read, eval and print functions which work closely together. In particular, you expect read to be able to understand what print outputs, because they work in a loop. So print is already taken. As for other prin* functions, see here: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_writecm_p_rintcm_princ.html http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec.... There is a good rationale behind those names. And no one uses princ for interpolated string output anyway. As for your code, things like princ or while-let1 are more-less equivalent of @, |sth|, ?, etc. in your code - i.e. there are some basics you have to learn with every language. > 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. Well, you don't get closer to that goal than with Lisp and the majority of its naming conventions. From make-instance to destructuring-bind to multiple-value-bind to update-instance-for-redefined-class, most of the things are named pretty well and readable for a programming language. I can't help but see these arguments about "intuitive names" as finding just another excuse not to learn something new.
Retra 12y ago
Familiarity makes it easier to learn, not easy. Just as long as you don't betray anyone's expectations about what they already know. I remember struggling with Haskell because there is a function called 'nub', which wasn't anywhere near what I would have called the function if I had named it. Hoogle says "(The name nub means `essence'.)" In Lisp it is called 'remove-duplicates.' In Python it is list(set(x)). In SQL it is 'select distinct.' So what advantage does nub pose? Not one of clarity, but of convenience for those "in the know." (Which is not those who are learning the language.)
- bsummer4 12y ago
  nub is widely recognized to be a terrible function; it's not indicative of anything
  - Retra 12y ago
    It's not? Then I suppose princ is a fine name for a print function.
    - bsummer4 12y ago
      Unfortunately, name, `nub`, is the best thing about this function. It has horrible (O(n^2)) performance, and only works with lists.

rudiger 12y ago

Erlang, despite its fusty syntax, already feels like the future for anyone using it.