Hacker News Reader

Comment by chaoky | Hacker News Reader

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)

View on HN

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.

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

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.

> You know the term REPL, right?

Yes, and notice how it doesn't stand for Rrepl-Evl-Princ Loop.

> There is a good rationale behind those names.

No, there is a good rationale for having separate functions, there is no logical rationale for prin1, princ and pprint.

Let's take "prin1 produces output suitable for input to read." from the link you provided. Since we are redesigning the language anyway, let's call that evalable-print or readable-print, or anything else in the world that semantically captures it's meaning. Because when you have a language with hundreds of obtusely named library functions it requires an unnecessary amount of cognitive load added to the already taxing act of programming. Functions that are easier to remember are directly related to code that is easier to read and understand.

Well, those functions are pretty much obsolete. No one uses them. They are only in the standard for backwards compatibility (and don't use that as an argument because that is a legitimate reason and those names are easily ignored. they are not taking up a precious name-space). Everyone binds special variables like * print-readably* , * print-circle* , * print-base* which, would you look at that, have nice comprehensible names. Prin1 doesn't have any cognitive load on beginners at all since no code written after 1984 has prin1. I guarantee you that all the names _you_ would find esoteric in Common Lisp have less esoteric equivalents. (car => first, cdr => second etc..) And pprint? well, that's a commonly accepted name even in the python world for pretty-print. I guess most of the names you complain about is things that you haven't seen in Ruby and aren't familiar with. On the other hand, I can easily argue that in your code snippet above that {|i| ...} looks like garbage to me since every language _I've_ encountered uses lambda(x) = x ... or x, y => ... for something as fundamental as lambda functions. Of course, this would be ridiculous for me to argue since every language has their differences in names and syntax that simply don't matter compared to the actual concepts themselves.

Is there a reference somewhere about what functions are no longer used by modern Common Lisp programmers? That would be very valuable for someone wanting to learn more about the state of the language today, instead of accidentally stumbling upon outdated practices.

Reply on news.ycombinator.com