Comment by pcr910303 | Hacker News Reader

Comment by pcr910303 | Hacker News Reader

Common Lisp folks should really start designing a more modern version of CL.

I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a great feature', 'There are lots of new dialects', and while they are right in some aspects, Common Lisp isn't appealing to anyone these days. (I mean, even C and C++ is improving. Why shouldn't CL?)

Even for people who 'get' the ideas of s-exps and macros, there are too many quirks in CL to appeal to people, and most go to Clojure (where the interactive experience is at best moderate, debbuging support/error handling is a mess, e.g.).

I believe the hypothetical CL++ should at least:

* Straight out incompatibilites between implementations, especially the numerous opinions to make an image or binary, and the FFI parts.

* Design a better CLOS system. CLOS feels like an object system thought after (well, after all it is a system thought after) and bolted on CL with duct tape. I would appreciate a CLOS-based type system (based on macros much like CLOS) that integrates well with CL.

* Remove unused functions, and fixing some inconsisties in the standard library

* Bigger, much much bigger standard library. Crucial, community-standard libraries like asdf & uiop, syntax-sugar like the arrow/diamond macros, and reader macros that allow infix syntax (this currently exists in the standard but nobody uses it partly because most Lisp users don't really care about infix, partly because it's extensiblity is bad) should be in the std.

* A compatibility layer. Providing a 'cl' and 'cl-user' package with the usual CL symbols will be sufficient.

to appeal to the users.

This really isn't sufficient for the hypothetical CL++ itself; there really should be beginner materials that isn't PCL; Lispers shouldn't hate infix reader macros or syntax-sugar like LOOP(IMHO these show the real power of macros, after all, macros are another tool to write readable code with great abstractions) and beginner materials should use, or at least introduce them(infix reader macros and other syntax sugar).

Just a rant about the language after reading the post and becoming sad.

I absolutely love developing in Common Lisp, and I agree with you.

Some suggestions:

- Get rid of upcasing; 21st-century languages should be case-sensitive and case-preserving. Allegro’s modern mode is the Right Thing™ here IMHO.

- Fix things like order-of-argument inconsistencies in the standard library.

- Consider adding type to streams to indicate whether they are input, output or both and character, byte or both.

- Base the package system off of Go’s.

- More fully specify pathnames.

- Specify a standard library roughly equivalent to Go’s. At this point I think it’s the gold standard (Python’s used to be, but no longer).

On upcasing:

    (setf *print-case* :downcase)

Oh definitely — that is a must! But it doesn’t do you any good if e.g. you want to turn read symbols into shell commands. You can play some games with :invert, but at the end of the day it’s a hack.

I don’t blame them for upcasing back in the 90s, but … it’s not the 90s anymore.

Not downcase, modern. I.e case-preserving and case-sensitive. E.g. to be able to define native ffi calls into CamelCase functions. Downcasing is destroying information, Modern is keeping the original symbol names

Some bits are here:

- https://github.com/alex-gutev/generic-cl/ gives generic equality, predicates and other base functions.

- the https://lispcookbook.github.io/cl-cookbook/ has nice topics and is growing.

- there is also http://cl21.org/, which works©, but is staling.

- to make an image, I think asdf:make is all one needs (see the Cookbook).

- Coalton is bring ML-types on top of CL.

- …

and I love CLOS.

> there are too many quirks in CL to appeal to people

I saw quirks at first. What was part of the learning process, I do wonder.

Last, there are many things we cannot do in Julia, like the Next browser :) https://github.com/next-browser/next

I have doubts. In particular, from my vantage, what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even.

What it has, is a ton of people that are more than willing to voice what they don't like about it. Which most languages have. Just doesn't have folks also posting good blogs about it often.

> what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even.

I believe CL can thrive even without sponsors, most of the new languages in the town don’t have sponsors. (Like Julia, Nim, Ruby, e.g.)

> a ton of people that are more than willing to voice what they don't like about it.

The CL community can ignore people that just whine about the ((parens)). What the CL community shouldn’t is constructive criticism from itself.

(For the record, I use CL as my side-project language, and use Clojure as my main language.)

> Just doesn't have folks also posting good blogs about it often.

IMHO, the CL community is too small to have much. The percentage of people who blog about CL is quite high; but the denominator is too small.

My doubts were meant as specifically against your points.

CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd.

Cruft in the standard library? Examples would be good here. But, this is hard to get behind. Nobody would be really sad to see Java date leave. That said, many of us are happy we don't have to touch some code that is working fine with it.

And this is next to a demand for a bigger standard library. Which will only lead to more cruft.

Not sure what you mean about the compatibility layer. Care to expand?

My point was if CL had the press of any of the alternatives to gave, that would put weigh the negatives you gave. Instead of chasing removal of stuff, marketing would make more of a difference.

> CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd.

CLOS is awesome, better than the rest. But there are some weird seems between types and classes. And in places CLOS doesn’t go far enough — e.g. it’d be nice to specialise methods based on element types.

But this criticism wants a new system. Not just fixing some areas. That sounds off.

I'd be interested in seeing some of the extensions you have in mind. I've only dabbled in clos. And I have to confess structures fit my case way better.

> new languages in the town don’t have sponsors. (Like Julia, Nim, Ruby, e.g.)

I thought Julia was coming from MIT research (financed with various research money) and moved now to Julia Computing, Inc.

https://economictimes.indiatimes.com/small-biz/startups/why-...

The employees of Julia Computing, Inc. need to be paid somehow... ;-) Looks like they have a good start:

https://juliacomputing.com/about-us

Maybe it lacks now, but it DID have heavy sponsors (Carmegie Melon University and Nasa are two that come to mind). The implementations we have now are based on this work.

I would have said they were involved, but they didn't market it. So, sponsor isn't right. I'm specifically thinking how Sun pushed Java.

That said, I cede I could just be wrong here on history. :(

Original Lisp vendors (Lucid, Symbolics, TI, LMI, Xerox, Franz, Harlequin, Goldhill, ...) and other companies selling CL (HP, DEC, IBM, Apple, SUN, Tektronix, ...) did market it, but that ended in the mid 90s with many of them exiting the business.

I don't want to ruin the language just so that it appeals to some people, it's already fine for me.

> ruin the language just so that it appeals to some people

May I ask why this can be considered ‘ruin’ing? These sort of changes will be useful for all CL users IMO.

> it's already fine for me

Maybe to you, but not for me or many, many people who went to Clojure apparently.

I don't mean this in a hostile way, but seriously, just go, then. If Clojure is best for you, vaya con dios :)

Okay, maybe I should clarify. I’m not a Clojure-lover; I use CL as my side project language and I love CL. I was just suggesting a way that CL can be more appealing language so that CL can reach more adoption (as CL has it’s strengths that Clojure can’t follow along).

Speaking as another Lisper, I am glad that you're sticking with Lisp, not moving to Clojure.

… and maybe someday you can propose your own project, something like CL21!

> I don't want to ruin the language just so that it appeals to some people, it's already fine for me.

To an outsider his comments seem pretty reasonable. Why would they ruin Common Lisp?

* There are larger incompatibilities between implementations in other popular languages, like C, C++ and Java.

* It's easy to suggest designing an OO system better than CLOS. It's harder to point out any examples tho.

* Remove unused functions, what?

* "Make FOO standard" but a bunch of popular languages don't even have a spec, why is this an issue even?

That other languages are worse than Lisp is no reason not to improve.

I didn't read him as suggesting that CLOS be replaced, but that it be embraced.

I have no idea what he meant about unused functions. My experience has been that when I think something in Common Lisp is pointless … I'm wrong.

One of the great advantages of Lisp in the 90s was that it standardised things that other languages left undefined (indeed, this is still an advantage Common Lisp has over Scheme). It seems like a good idea to keep on expanding the standardised area, as we gain experience & understanding.

All good points but well.. this discussion appears to be about possible reasons people migrate to other languages. And I just can't see how addressing these (rather arbitrary) points would reverse it.

Some people just don't like CL much, despite solid foundation and steady progress with community projects. That's okay, we all have one or another language we are not very fond of.

That's exactly the way I feel about it :)

Don't forget a package installer/dependency manager as in NPM/PIP/CPAN. Nowadays I cannot look to a programming language without one of those... it is just too painful to look for libraries, download them, set in a separate folder, etc...

There is quicklisp [1], works fine for me.

[1] https://www.quicklisp.org/beta/

I thought that it's not official and that it was largely criticized due the lack of test cases, and other problems.

It's fine and you'd know that if you ever used it.

I guess there are some metrics by which you could criticise it, but not if NPM or CPAN are your yardsticks.

Quicklisp is great (and better than npm/pip) because it works with distributions, aka releases. It's more stable, I never had dependencies of dependencies that break because they were not pinned carefully. Upgrade when you want. If you want to do otherwise, see Qlot and Ultralisp (a distribution that builds every 5 minutes).

Reply on news.ycombinator.com