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.
The big problem is that reasoning about non-strict evaluation is quite non-intuitive (although not impossible.) It's quite easy to write code which seems inefficient that runs in no time at all, and equally easy to write code that seems efficient that takes a long time to run. It requires a rough understanding of how your compiler is optimizing your program and what the resulting code is doing, which can be tricky. Laziness also (not surprisingly) interacts with side-effects in a complicated way, so much work has been done to alleviate the problems with lazy IO, e.g. iteratees [3].
So, yes, sometimes it's a great thing, and sometimes it's a problem. The position of the Haskell community is that the exploration of how to properly leverage laziness is worth the tradeoff, but there is indeed a tradeoff.
[1]: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev...
[2]: Infinite data structures (i.e. codata) can be written/created in a strict language, but the ability to write them falls out of laziness quite naturally, and a lot of people experience them for the first time in a lazy context.
Laziness also makes the language more foreign and harder for many people to learn initially, but I think that fundamentally does not matter. Learning Haskell is a constant cost where the benefits are at least O(n) (and plausibly more) to how much you program with it, so any learning costs are quickly dominated as you use the language.
Unless you're trying to use Haskell to compete with C (and some people are), laziness is a net gain. Take a look at the "Why Functional Programming Matters" paper for a good case in favor of laziness.
Now, laziness does have some downsides over strict evaluation; I just believe the upsides easily outweigh them.
The reason you read about problems with laziness is because the problems are encountered before many of the benefits by people learning the language and because the problems are easier to articulate than the advantages. Also, Haskell is the only common lazy language, so that particular aspect stands out.
Simon concedes the troubles with laziness and his biggest item of support for laziness is that it keeps you honest in terms of side-effects. I don't buy it. We can control side effects with the type system -- we don't need complete laziness (some laziness is actually quite easy to hand to otherwise eager languages).
P.S. The other major contribution Haskell made to PL was type classes, can't believe I forgot it.
The decision of its designers to create so-called pure-functional language is nothing but a fancy term and it deceived lots of people. Machine code it produces isn't pure or somehow different. And, of course, I can do the same functional programming in, say, Lisp. Or ML.
Laziness is also not a silver bullet, you could have lazy evaluation in Scheme or even CL on demand if you wish.
So, Haskell is nothing special because it just another ML-family language, over-hyped and over-sold.
> 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"?
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.
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?
I assumed that's what the OP was talking about by saying Haskell was "more mathematical". The situation is analogous to ad-hoc databases vs. those firmly rooted in the relational model.
Since when? Mathematics was originally founded on the study of the natural numbers. The mathematics I find most valuable (eunmerative combinatorics) still uses the natural numbers as its foundation and not type theory.
Let S be the set {a,b} and let T be the set {c,d}. There are two bijections S -> T between these two sets {(a,c),(b,d)} and {(a,d), (b,c)}. These two sets are isomorphic to one another because they have the same cardinality.
The isomorphism classes of sets are cardinalities which are themselves the natural numbers 0,1,2,3,... and infinity. In combinatorics we can just focus on the study of these isomorphism classes rather then sets themselves.
We can enumerate binary relations: ([],[0],[1],[[0 0],[0 0]],[[0 0],[0 1]],[[0 0],[1 0]],[[0 0],[1 1]],[[0 1],[0 0]],[[0 1],[0 1]],[[0 1],[1 0]],[[0 1],[1 1]]). Logical disjunction [[0,1],[1 1]] is equal to 10 in this enumeration.
Using the enumeration of binary relations the entire field of study of graph theory can be described in terms of natural numbers without any need for sets. As a result, graph theory is considered to be a branch of combinatorics. We only need to have sets mathematically when dealing with cardinalities like aleph one that emerge from uncountable sets.
Since analytic number theory deals with the uncountable set of real numbers and abstract algebra deals with operations on sets including the real numbers, these two fields are indeed founded on set theory. Algebraic combinatorics and combinatorial number theory are the branches of these two fields that focus on countable sets.
> And set theory is what mathematics calls type theory.
No it isn't. Just look up differences of type theory from set theory on wikipedia [1]. You almost never hear the word "type" spoken in math courses. According to John Shutt "I took some tolerably advanced math courses in college and graduate school. One thing I never encountered in any of those courses, nor that-I-recall even in the THUG talks, was a type. Sets aplenty, but not types" [2].
[1] Type theory differences from set theory http://en.wikipedia.org/wiki/Type_theory#Difference_from_set...
[2] Where do types come from http://fexpr.blogspot.com/2011/11/where-do-types-come-from.h...
You misread me. What I said was that "set theory" is the general mathematical framework exactly equal to what we computer scientists call "type theory". We have completely different ontologies for what are essentially the same thing (the differences listed on Wikipedia are superficial/conventional and IMHO of no relevance here or in the article).
Mathematicians deal with sets, countable or otherwise, algebraic manipulations of them, bijective mappings, etc. Computer scientists operate on domains (types), their operators, functions, etc. These are different terminology for the exact same thing.
That makes more sense. I am coming from a mathematical background and not a computer science background myself.
> Mathematicians deal with sets, countable or otherwise, algebraic manipulations of them, bijective mappings, etc.
That is true. As a combinatorist I am one of those people who mainly focuses on countable sets. The isomorphism classes of sets (the counting numbers) are at the foundation of everything I do in combinatorics but other areas of mathematics (e.g topology) have very different approaches.
I guess you could say that there's nothing "special" about Haskell, but the same would be true of Arc. I think Racket is the real champion in Arc -- a truly flexible programming language laboratory.
Inside a computer everything is a number - sometimes a number represent itself, sometimes it is a pointer (a number of a byte, an offset) and sometimes it is a code, a number of an unicode character, etc.
The key idea there is that a pointer points to everything, value has a type, not a pointer. There are no pointers-to-integers along with pointers-to-booleans and pointers-to-strings. There are only numbers here.
Having one kind of pointer for all is the semantics of untyped lamda calculus. We could cons everything with everything, we could have heterogeneous lists, tuples, whatever.
Well, it seems that untyped lambda calculus are good-enough.) Perfection is achieved when there is nothing to remove, and not adding features is sometimes more wise.
I guess English is not your native language. http://grammar.about.com/od/words/a/latergloss.htm: Use later when referring to time. Use latter when referring to the second of two persons or things mentioned previously.
So, grammatically, 'the later' would refer to the language that was created later, and that's Clojure. </pedantic>
I cannot explain it in a few sentences, I have tried few times, but I'm sure that it is better to learn the classic Lisps first, so you could be able to appreciate their elegance and simplicity (a few selected ideas put together) and then you could compare it with what you have in Clojure.
It is also important to learn how Lisp programmers used to build almost everything they wish out of conses (except arrays and hash-tables, of course) how they reason about access patterns for list structures, learn simple and elegant classic functions, such as map, filter, reduce, etc in their natural environment.)
It short, compared with even CL Clojure is a mess.
I can't see how this is true. IIRC Common Lisp has more standard data types than core Clojure does — it's just that Clojure has reader support for more of them and uses them a bit more freely. It is still homoiconic.
> It violates a general evaluation rule - one for every expression with a very few special forms, etc.
I assume you meant to write something like "one list for every expression". Clojure has essentially the same rule. In general, the things you are probably thinking of that omit lists where most Lisps use them (like Clojure's let and cond using juxtaposition rather than lists to group things) are macros, which could be written in any other Lisp just as well. These are done for convenience, much like Common Lisp's loop.
[1] This is the hard to explain part.
Yes, Clojure isn't exactly like older Lisps. Why should it be? Those Lisps are all different from each other as well. If new Lisps can't introduce new ideas, what is the point?
But I would describe Clojure as "not Lispy" because its behavior seem to fall into the compilation idea more than the interpretive idea. I would execute `lein run` and a failure would drop me out into the Linux shell. An equivalent command in CL would throw a condition and drop me into an interactive mode to patch it up. I fully acknowledge that my tool use may not have been ideal, of course. But my Clojure was giving me a compile-run-test cycle as opposed to the the interactive editor/repl cycle of CL. Errors in the source would cause exceptions and crashing in the compile phase; errors in the runtime would cause a crash.
I want to hone in on the second point you made, in terms of new ideas. New ideas are good (c.f., Kernel). New ideas should be aggressively pursued. I draw the line when someone has a slightly varied idea and wants to fork out something & get a community going just for that slight variance. That's just annoying and forks effort. If the new idea is really radical and can't be reconciled with extant tools, of course it deserves to be a new thing. Lisps are an insanely awesome tool for exploring semantics and I hope they keep getting created and churned on for decades to come. I just hope that the ideas which are reconcilable to production systems are reconciled so that we don't fragment further.
Porting code between these is relatively easy or even trivial when only the core is used.
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.)