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