
Dialects of Lisp - mwillmott
http://programmers.stackexchange.com/questions/55284/is-lisp-still-useful-in-todays-world-which-version-is-most-used/188048#188048
======
orthecreedence
I've seen Common Lisp start to make a great comeback in the past few years. I
started programming in it seriously about a year and half ago, and since then
the packaging system (quicklisp) and libraries for it are maturing very
rapidly. A lot of people are making useful libraries for practical purposes.

A lot of people say the language's timing was off. I couldn't agree more.
However, it's starting to get a second chance. There are several open-source
implementations that compile to machine code and/or support
threading/networking/etc. Deployment is essentially free. For every feature
that an implementation has that's not in the standard, there's a library that
creates a standard, cross-implementation interface for it (for instance
threading and the "bordeaux-threads" library).

The language is screaming fast, extremely expressive and powerful (insert
mandatory macro hype here), and becoming "standardized" all over again via its
libraries. I use it (Clozure CL) in production and haven't ever had an issue.

~~~
rayiner
> The language is screaming fast

I don't disagree, but that's an interesting change in the CW.

~~~
jdale27
(CW == conventional wisdom?)

There are probably a few reasons for that. Many more programmers these days
probably get their start with "scripting" languages like Python, Ruby, Perl,
PHP, and JavaScript. Compared to these other dynamic, high-level languages,
you probably could call Common Lisp "screaming fast". (Of course, I'm aware
that there is very active implementation work going on for several of those
languages that is probably doing a good deal to close the gap.) On average,
though, CL is probably in the same ballpark as Java, and can sometimes be made
as fast as C or C++ with a lot of effort.

Also, note that Common Lisp is very much a many-implementation language (in
contrast to languages like the ones above that, for most of their history,
were defined by their single implementation), and different implementations
make difference performance trade-offs. For much of recent history, the very
high performance CL implementations have been somewhat out of reach of the
typical student, hobbyist, or other weekend hacker that probably makes up most
of the Lisp community. Commercial CLs are quite expensive, and high-
performance free CLs like CMUCL have historically not been too friendly to
beginners. When I came to Lisp, it seemed much easier to get started with
CLISP (an extremely portable bytecode-compiled implementation) than with
CMUCL. More recently, SBCL (an offshoot of CMUCL) and Clozure CL have made a
lot of progress towards providing a go-to open source CL implementation with
very good performance.

------
brudgers
If I were to bet, I'd place my money on Clojure as the 100 year language. It
is as unbound by hardware in regard to cross platform development as any other
likely candidate, it has good access to libraries meeting contemporary
expectations, and is likely to continue to have access to new libraries
written to meet future expectations - all due to its interaction with the JVM
(and .NET).

Of course I am adopting PG's premise that the 100 year language is a LISP
while ignoring his premise that it is not a bit kludged up by practical
considerations (i.e. the ugliness of its dependence on the JVM).

(/edit) Clojure also has an evangelist in Rich Hickey whom people seem to
respect independently of Clojure.

~~~
ema
Clojure is currently my favorite language, partly for the pragmatic choices it
made, but these pragmatic choices will limit its continued use.

Hygienic macros often prevent one from shooting oneself into the foot, but
they prevent also some truly elegant code. Having lists and vectors with a
common interface is cool, but that the semantics of conj is different for both
is annoying. Easy java interop is worth a lot, but it prevents call/cc.

It's probable that i will gladly use Clojure for the next 10, maybe even 20
years, but it won't be the programming language my grandchildren will ask me
to shut up about.

~~~
Tyr42
I am curious, what do you think hygienic macros break? I'm a fan of Racket,
and I haven't yet found anything that it's macros can't do.

~~~
nbouscal
I'm still too new to Lisp to answer this question, but I have seen the book
Let Over Lambda recommended as having answers to that and similar questions.

------
Locke1689
I'm not familiar with a lot of other dialects, but the information on Racket
is _terrible._ I wouldn't trust any of the other responses.

Racket is _not_ an R6RS scheme, it's... Racket. R6RS is an available
language/library in Racket, but it's not what you usually use[1].

Racket has also _always_ been a language laboratory, not just a scheme. I'd
also wager that it's the most popular scheme used today, maybe even the most
popular lisp.

[1] The Racket primary language is specified with #lang Racket, R6RS is
specified with #lang r6rs. R5RS is specified with #lang r5rs.

------
jrajav
This answer references Chicken Scheme, which compiles to C - I'm curious, is
there any work on a Scheme that compiles to LLVM? (A brief search didn't
reveal anything that's been updated in the last 4-5 years.)

~~~
bitwize
Gambit is getting backends that include x86 and JavaScript Real Soon Now.
There has been LLVM work, but I don't think it progressed very far.

~~~
mark_l_watson
+1 for mentioning Gambit-C. I don't use Gambit-C anymore, but I used to use it
a fair amount for writing small utility programs. Gambit-C can be used to
build very small and efficient executables. Gambit-C doesn't have the huge
library that Racket or Chicken have but it is great for building small command
line utilities, etc.

------
fosap
I wonder if Arc is finished or dead. I like it it seems the ecosystem is
missing.

------
leke
No mention of NewLisp?

~~~
mahmud
NewLisp is to Lisp what ramen noodles is to Italian cuisine.

~~~
mghan
Urban Dictionary about Ramen Noodles: "Quite possibly one of the most all time
best foods ever to be found in the United States of America."

------
derleth
Why don't people do things like this for Dialects of Algol? Is it because most
of them got new names, like Java, C, and so on?

~~~
groovy2shoes
I was actually thinking about this same question earlier. There are dialects
of Lisp and dialects of BASIC, but most other languages are not considered
dialects of anything similar. How different do two programming languages have
to be before they're no longer considered dialects?

It seems like Scheme and Common Lisp, for instance, have more differences than
Java and C# have from each other. Why wouldn't C# be considered a Java
dialect? Visual Basic is very different from BASICA, yet they are both
considered BASIC dialects. Why shouldn't Pascal and Ada be considered ALGOL
dialects?

The line-drawing process seems completely arbitrary.

~~~
jfb
"The line-drawing process seems completely arbitrary."

The real world cannot be exhaustively described with a single taxonomy.

------
dschiptsov
The way is Scheme -> Common Lisp -> Arc.

Scheme comes first because it is more refined and there are excellent courses
and books.

CS61A probably the best introductory course. After that it is good to watch
original SICP lectures by the two magicians and read the book. Then it is
necessary to take a look at what HtDP team is teaching.

 _After_ this there will be no trouble with Common Lisp. Classic books are
these by pg and Norvig. CLtL is just a reference.

Then, with all the knowledge so far one could understand arc.arc and
appreciate what have been done there.)

With this background you will understand what Clojure really is and why, or
what is Haskell, and why there is nothing special in it.

btw, there is a brilliant course by Dan Grossman on coursera covering FP. He
is very clever and consistent. After this you will smile at Haskell guys.)

Update:

I forgot Emacs Lisp. _An Introduction to Programming in Emacs Lisp_ is an
excellent book that covers all the basic principles and gives a perspective
how to use lisp in a real-world project.)

~~~
tikhonj
The idea that there is nothing special about Haskell, or that Haskell is all
that closely related to lisp, is patently absurd. Haskell comes from a
different, more mathematical background with a _much_ more extensive
underlying theory than lisp.

I actually came from the background you advocate--61A (which really was an
awesome class) was my first CS course in college. (Unfortunately, they have
since ruined it.) I certainly appreciate lisp and have actually used Racket in
a practical setting. That said, I've found Haskell and OCaml to stand out both
from purely pragmatic and theoretical considerations.

Haskell is the only moderately popular language that lets you control side-
effects globally. That by itself is extremely special. This makes writing
maintainable code easier and gives the compiler considerable freedom in
optimizing code.

Haskell has an incredible but also surprisingly simple type system. You can't
just ignore that. There is nothing in lisp--not even typed Racket--that even
comes close to Haskell's type system.

Even aside from language qualities that make Haskell special--which I haven't
even come close to covering--it also stands out because of its community. Not
only is the community particularly nice and welcoming, it's also special in
not being afraid of a bit of math. This doesn't mean _you_ as a programmer
have to know much math, but it does mean libraries tend to be simpler and more
self-consistent because they rely on very well defined mathematical
abstractions with simple algebraic rules. These abstractions also allow for
significantly more general code.

Haskell comes from a different theoretical background and philosophy than
lisp. It has different practical advantages and a very different philosophy.
So claiming that it's nothing special and that you will understand all of it
just coming from lisp is completely wrong.

~~~
jhuni
I like having access to mathematical semantics, simple algebraic rules, and
all the other things you mentioned but combining these features with a non-
homoiconic syntax spoils the whole thing for me.

> _Not only is the community particularly nice and welcoming, it's also
> special in not being afraid of a bit of math._

The Lisp community has never been afraid of math. John McCarthy had a PHD in
mathematics and the earliest computer algebra systems were developed in Lisp.
The Macysma computer algebra system (now developed as Maxima) predates Haskell
by decades.

> _Haskell has an incredible but also surprisingly simple type system. You
> can't just ignore that. There is nothing in lisp--not even typed Racket--
> that even comes close to Haskell's type system._

The most important thing for me is having the ability to describe cardinality
(especially in terms of machine bits such as 2^8, 2^16, etc) and enumerations
(like the ASCII character encoding). What aspect of Haskells type system is
that Lisps need to "come close to"?

~~~
tikhonj
My point with math is that Haskell libraries and code use mathematical
abstractions (like various sorts of algebraic structures) far more than lisp;
I was not taking about what people do with Haskell but rather how they do it.

The type system does quite a bit more than just describe cardinality. The
single most important feature is typeclasses; you simply can't replicate some
of what typeclasses can easily do without a similar type system.

Apart from that, you also want the type system to let you control "effects"--
not just state and IO but also things like error management and non-
determinism. You also want a good way to reuse the type system to enforce your
own domain-specific invariants; this is what GADTs are for.

The only serious effort I know for adding a type system to lisp is typed
Racket, and I don't think it does anywhere near as much as Haskell. It
certainly does not have typeclasses, and I think it ends up having union types
everywhere which are more awkward and bug-prone than the usual sum types
languages have. (This is a necessary compromise to integrate well worth normal
Racket, but it's still a compromise.)

Beyond that, most people don't use typed Racket at all, so I suppose the main
way lisp can come close to Haskell's type system is in having one at all.

As far as homo-iconic syntax goes, I sometimes miss it, but not too often.
Having a flexible syntax that can look like math is far more important
usually, and Haskell gets most of the way there without being too complicated.
I personally think that seething like Agda's mixfix syntax is the best option
overall.

~~~
jhuni
> _The type system does quite a bit more than just describe cardinality. The
> single most important feature is typeclasses; you simply can't replicate
> some of what typeclasses can easily do without a similar type system._

In the C programming language types are mainly used to describe cardinalities.
For example, char is the cardinality of the smallest addressable unit of
memory of the machine (often 256). We don't need more then machine
cardinalities as entire operating systems have been written in assembly and C.
What advantages do type classes and GADTS have that make them worth adopting?
Is there any evidence that they make programs more safe and reliable?

> _My point with math is that Haskell libraries and code use mathematical
> abstractions (like various sorts of algebraic structures) far more than
> lisp; I was not taking about what people do with Haskell but rather how they
> do it._

I am building a computer algebra system with Lisp in my free time. There are
many Lisp computer algebra systems that I have learned a lot from like Maxima,
Reduce, and Axiom. One of my favorite computer algebra systems is GAP and it
is written in C and not Haskell. I am not convinced that Haskell uses more
mathematical abstractions and algebraic structures and I am not familiar with
any well maintained computer algebra system written in Haskell.

> _Having a flexible syntax that can look like math is far more important
> usually, and Haskell gets most of the way there without being too
> complicated._

Math doesn't look like anything. Mathematics is about abstract concepts
(especially the natural numbers) not representations. You mean that Haskell is
meant to look like math does on paper, but whats so important about using a
paper syntax when we have keyboards?

