[vegai_]

I was slightly surprised to learn how well Common Lisp had implemented its types. I keep wondering why CL almost completely failed to break into the minds of people in early 2000s. That was about the time I first learned about python, which kind of seemed to be everywhere. It took 5-10 years before I even heard of Common Lisp.

And now it seems to me that the Common Lisp which was pretty much fixed in 90s is superior in many ways (runtime, programming environments, typing -- to mention a few) to even the revised python3 of 2021. And then Javascript, essentially a bad clone of Lisp, got popular? Makes absolutely no sense.

[mbrock]

I’m also surprised by this and I continue to love Common Lisp over all other languages. But I think one reason is that languages aren’t just languages. The amazing parts of Common Lisp were all standardized in 1992 or whatever. By people who are not at all involved in any kind of Unix, Linux, open source, web, scripting, etc. It’s like a beautiful cultural legacy that’s maintained by some enthusiasts and a couple of insular commercial vendors. Now what I really wonder is why nobody outside of some Scheme dialects have stolen the restartable condition system, which is so amazing and straightforward to implement.

[lispm]

> By people who are not at all involved in any kind of Unix, Linux, open source, web, scripting, etc.

Common Lisp on UNIX appeared in the mid 80s, long before the ANSI CL standard.

Scott Fahlman was one of the five designers of the early Common Lisp. He headed the CMU CL project, which was a) on UNIX since around 1984 and b) public domain. Code from CMU CL was used in a dozen other implementations.

Other well known CL implementations for UNIX which were developed before 1994, when the ANSI CL standard was published: Allegro CL, GNU CLISP (free), (A)KCL (no cost, free, later renamed to GNU Common Lisp), LispWorks, Lucid CL, ...

Three large commercial implementations of CL were developed initially exclusively for UNIX and were available end 80s: Allegro CL, Lucid CL and LispWorks.

Generally the language came out of well funded research labs and companies and was designed to be portable across a large variety of operating systems (like UNIX variants, VMS, LISPMs, DOS/Windows, Mac OS, ...).

[ngcc_hk]

First issue : Access for simple project …

Ex a simple programming web site: if you want to use your iphone, working copy on you Gh-pages, edit test and publish a web pages with js,css&html —- you can. With full version control and even use library external if you have to.

Second issue : external integration which python as script and c (and c++) as os level “script” …

Third issue : hard to use it’s package system.

I am not anti-lisp, just spend $700 to get a Casio ai-1000 and trying to use ulisp.

Just not main stream like.

God’s programming language as said not used God and by mortal.

[Blackthorn]

> Makes absolutely no sense.

Well, for me, it's just not ergonomic. Unlike something like Python.

I solved this year's Advent of Code in Common Lisp in an attempt to learn it better. I determined in the process that the language was awful by 2021 standards and if you wanted a Lisp that was actually usable, go with Clojure or a decent Scheme.

[vegai_]

I can see how Python is clearly more ergonomic than Common Lisp, but I really don't see any significant differences between CL, Clojure and Schemes. Just ergonomic micro-optimizations.

Clojure's native thread-safe data structures are a significant difference, though.

[Blackthorn]

My biggest issues with Common Lisp were:

* Absolutely nothing is consistent. When you mutate something, is the place it goes the first or last argument? No consistency here. * When you pass a value to a function, is it by value or by reference? Who knows? Rules are non obvious, do not follow the principle of least surprise. * Lisp-2 just makes working with higher order functions obnoxious.

One thing it has going for it though is the loop macro, that's admittedly pretty neat.

[kazinator]

There is no "by reference" in Common Lisp; everything is a value. Some values have reference semantics. This makes no difference unless you're mutating, or making unwarranted assumptions about the eq function.

To understand most code, you can just pretend that all values have reference semantics. If mutation is going on and/or the eq function is being used, you have to prick up your ears and pay attention to that detail.

[Blackthorn]

> Some values have reference semantics. This makes no difference unless you're mutating, or making unwarranted assumptions about the eq function.

That's pretty damn far from "no difference"! Once again, rules are non obvious, do not follow the principle of least surprise.

[kazinator]

If you're mutating any object, it is necessarily a value with reference semantics, period. Objects that do not have reference semantics are immutable.

Some objects that cannot be mutated (like numbers) can have reference or value semantics depending on how they are implemented. For instance, a bignum integer always has reference semantics. Small integers usually have value semantics: they fit into a machine word with no heap part. In that case, all instances of the number 0 or 1, and some range beyond that in both directions, will always be the same object according to eq.

If you're mutating an object (and, thus, something that has reference semantics), the difference that the reference semantics makes is that other parts of your program may hold a reference to that object; your code has not received a copy. If you haven't accounted for that, you probably have a bug.

Sure, this stuff isn't obvious; unless you already know another dynamic language like Ruby, Javascript, Python, ...

Complete neophytes have to be taught it from the fundamentals.

[slim]

Maybe the reason is Marketing ?