I still don't get Lisp. Why does there need to be an endless amount of dialects? Doesn't this completely needlessly fracture the ecosystem into hundreds of pieces making it impossible to effectively support?
Isn't the point of Lisps to be endlessly customizable, making the invention of a new dialect less necessary?
The only Lisp I'd consider for a real project is probably Clojure and I'd even be hesitant about that. Sure, you can make a simple web project with Arc (HN), but it seems like you get 0 libraries, 0 interfaces with other systems and 0 tooling. Why would I bother with that?
For the same reason as there are many algol-like languages.
The production-ready lisps are:
- Common Lisp: this one is standardized and the ecosystem is NOT fractured. Many implementations exist and work in parallel: SBCL, CCL, LispWorks, ECL, ABCL…
- Clojure (though there is also ABCL and I keep hearing good things about LispWork's Java interface)
- Schemes: some coming from university, with a fractured ecosystem.
Of course, nobody uses Arc for serious stuff (but we can have its syntax in CL and probably in Racket too).
> Why does there need to be an endless amount of dialects?
Because any time someone makes an (operator arg1 arg2 ...) language, they either put Lisp in the name, or else state elsewhere that it's a Lisp dialect.
Why does there need to be an endless progression of C-like dialects? They don't get called C, or rarely so.
The semantic differences between things called Lisp can be as large as between C++, Java, Javascript and Awk.
Many programming languages have been modeled on Algol; why are there so many Algols and why aren't they called that way? A lot of it is because of syntactic differences.
In the Lisp world, there are some mainstream languages that have the most users; if that's important to someone, they can stick with those and pretend the rest don't exist.
It's another example of the ~800 volume work titled "Where the indirection go?" A solid 90% of the variation you see in the programming world is moving indirection higher or lower, inside or outside, like moving food around on a plate. When you compound these choices, you get a combinatorial explosion that's both intimidating and absurd. And the clearest indication yet that, despite our pretensions, software engineering is, in fact, software alchemy awaiting systemization. We need Lavoisier and Mendeleev for software, stat!
There is an endless amount of Lisps because the core to get one working is one page of code. So many people make one as a pet project. Aside from the small unused versions, the rest of the dialects have a lot of differences between them, some of which would be difficult to implement in an existing implementation. Common Lisp is a fairly complex specification to achieve, so few even approach it, and of those that do most aren't fully compliant.
Getting a Lisp to run efficiently and effectively is more difficult than just writing an interpreter. I consider work on this problem to still be incomplete. For example, it should be possible to implement generic functions even more efficiently in Common Lisp implementations than is currently the case, in a way that preserves the ability to redefine the functions (and the classes they work with) dynamically. Robert Strandh has been working on general mechanisms supporting this and other improvements.
There are a lot of dialects because its core is one of the easiest programming languages to understand and implement, and once implemented, it's one of the easiest languages to extend. That's all there is to it, pretty much.
Anyone who is interested in the design of programming languages will find it easy to make their own Lisp and try out any ideas that seem congenial to them. The natural and obvious consequence is a lot of Lisps.
Why are there multiple dialects of real-world languages?
LISP is pretty minimal and simple. It's less of a language than a set of constructs for computation. Computers are made of abstractions on top of abstractions, so it makes sense for Lisp-based languages to evolve continuously. No one is better than the other, each target to their own niche. Just like other prog. languages, or real-world dialects.
Dozens. The standard language has been through numerous revisions (C++ 2.0, 98, 03, 11, 14, 17, 23), with no doubt many more to come - each version is a dialect. And there have been dozens of compilers, all of which define extensions to the standard - some of those extensions are copied by other compilers (and may eventually end up in the standard), others are unique to that implementation - so each compiler (even each of its successive major releases) can be viewed as a dialect. And then there are dialects defined, not by the core language features, but by which features are used, by which external libraries are used, etc. One C++ programmer is addicted to esoteric template metaprogramming, another avoids templates and treats C++ as a slightly improved version of C. One C++ programmer uses every Boost library they possibly can, another refuses to use any third party dependencies. One uses exceptions and RTTI heavily, the other always turns them off. Aren’t those all effectively different dialects, even if they are both using the exact same version of the same tools?
And then there are entire languages defined as extensions of C++, such as Apple’s Objective C++, or Microsoft’s Managed Extensions for C++ and then C++/CLI and C++/CX - and also more modest extensions such as OpenMP
Considering C++ is an object-oriented extension to C, it belongs alongside other such extensions - most notably Objective C and D (and even, to a lesser degree, Java and C#) - and there have been other attempts at that which weren’t successful - aren’t they all (in a sense) C dialects?
A large factor in the push for C# was that MS was sued by Sun for their not-totally-compliant Java dialect, Visual J++, and had to drop it as part of a settlement.
They also had Visual J# which ran on .NET, allowing Visual J++ and Java programs to target that platform.
There is also a non-Microsoft open source implementation of Java on top of .NET, IKVM.NET - I was sad to see it die when its original developer lost interest (although I just learnt it has since been revived by others)
> Isn't the point of Lisps to be endlessly customizable, making the
invention of a new dialect less necessary?
A great question. Maybe everything should have been built on Scheme
once . and . for . all But people and the world aren't like that. We
are restless souls.
When they sort out the spec issue (R7RS) we will reach programming nirvana and world peace. But I doubt humanity will live long enough to see that day.
Isn't the point of Lisps to be endlessly customizable, making the invention of a new dialect less necessary?
The only Lisp I'd consider for a real project is probably Clojure and I'd even be hesitant about that. Sure, you can make a simple web project with Arc (HN), but it seems like you get 0 libraries, 0 interfaces with other systems and 0 tooling. Why would I bother with that?