Hacker News new | ask | show | jobs
by SeanLuke 2172 days ago
> If your new Lisp is designed by anything less than a committee with people like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you will end up with something worse.

Nonsense. It's trivial to design a new Lisp better than this committee did, regardless of how well a job they did, because hindsight is 20/20, and this is 50 years of hindsight. Step 1: take Common Lisp. Step 2: fix the obvious design flaws and warts which have proven themselves irritating to everyone over the years. And there are many, everything from a lack of standard character set, to nods to ancient versions of Lisp (caddddr, association lists and property lists, grotesque mistakes in EQUALP and EQUAL, lack of basic functionality in hash tables and arrays -- broken equality testing, and seriously, you have to write your own function to copy an array or hash table? -- missing literals for standard data types, huge numbers of unfortunately named symbols, on and on and on). Step 3: done.

1 comments

while we are at it, let's also fix the obvious design flaws in C and UNIX/LINUX, especially the huge number of unfortunately named functions and commands.
That's not the point. He said it wasn't possible to improve on the committee. But of course it is.

But while we're on the subject: both C and UNIX are actively being updated and improved even now. The Common Lisp standard hasn't changed in any significant way since the 1980s. In Lisp everyone is just adopting ad hoc standards, agreeing under the table that everyone should use a certain networking package, threading mechanism, or Unicode standard for Lisp characters. That's the worst of many possible ways to deal with the problem.

One can claim that C is best improved by replacing it with a new languages. See Rust, D, and others. Lisp, too. -> Clojure, Julia, Racket, ...

The 'step 1' 'take Common Lisp' is already hopeless, because there are few people interested in that for various reasons.

I don't think it's 'trivial' to fix a fading large niche language like Common Lisp, which was designed at a different time, with had much more design power back then. It's actually far from trivial.

> But while we're on the subject: both C and UNIX are actively being updated and improved even now

Given the contents of ISO C17 and POSIX at Open Group it doesn't look like it.

Unless we have different understandings of improvement.

What the ISO C people are doing can be called vandalism.