CL21: An experimental project redesigning Common Lisp

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

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.

Yeah, I like car/cdr very much and use them where appropiate because of semantics. Indeed, car/cdr doesn't mean the same as first/rest or head/tail. E.g. head/tail makes sense only if you're talking about lists. But cons-cells can be used to compose different types of data structures.

As funny as it is, people whining about "car/cdr" and saying "language X did it better because it called them first/last, or head/tail" don't realize that it's the language X that lacks semantics to express anything else than lists using cons cells.

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

Three things I don't like about Common Lisp.

1. It has CLOS but it doesn't really embrace it in standard library. You have list, vector, hash-table, each with its own iterator function. You have lots of #with-xxx macro. All modern languages utilize the idea of common interface like #iterator or #dispoable. You can clearly see CLOS library and pre-CLOS library in CL. CL needs to eat its own dog food (CLOS) more.

2. It lacks basic practical API library, while another containing big complicate academic functions. Its #format function is probably Turing complete. It has function to format number in Roman numeral. But it doesn't have function to deal with datetime. No networking IO function. No Threading library.

3. Condition and Restart could take the idea from Dylan. Tying condition to available restarts, and making class hierarchy of them, is a better idea. This problem stems from CL not actually utilizing CLOS.

Also, PACKAGE should take the idea of LOCALE, allowing easier local package rename, and less symbol conflicts problem.