Hacker News Reader

I agree with much of what you wrote there but you should remember that the single most distinguishing feature of Haskell (aside from its predecessor Miranda) is laziness. Almost everything unique you described about Haskell was not accidental, but necessary to build a wholly lazy language.

From reading what Haskell related articles I've seen around HN and other places over the last few months, the always-on laziness seems to actually be a problem a chunk of the time, correct? Well, not so much a problem, as not always a good thing.

Yeah. Personally, I think it was an extraordinarily interesting experiment that didn't pan out. However, the corralling of side-effects (which was necessary for a lazy language) turned out to be one of the best innovations in the space, so that reinforces that we learn as much from mistakes as from successes.

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.

Laziness (or, properly, non-strictness) enables a radically different style of programming, and combined with functional purity, also enables kinds of code transformation that are not valid in strict, effectful languages [1]. Almost any dynamic programming algorithm is trivial in Haskell, c.f. packrat parsing, which is embarrassingly easy to implement using a table of lazy values, and you can also trivially write control structures and infinite data structures [2].

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.

[3]: http://www.haskell.org/haskellwiki/Iteratee_IO

What kind of purity and laziness cannot be done in Scheme?)

Unrestricted beta reduction. You really should know that if you want to take a position of authority on the differences between programming languages.

I have no such intention.

Many people in the Haskell community like laziness. It can be a problem for performance reasons, sometimes. On the other hand, it's a boon to making the language more flexible and expressive. It helps write better, more modular code.

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.

As far as I know, Haskell is just a ML-family language. It is a dialect of ML, we could day.

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.

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"?

Most Lisps are untyped. Typed-Racket and Qi seem to be the standouts. Other than that I would agree that there's not "more mathematical" background.

Type theory and accompanying first-order logic is the foundation upon which mathematics is built. This gives strongly typed languages a much more firm foundation which has the potential t be exploited by theorem-proving programs reasoning about and modifying other programs (e.g, compilers).

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.

> Type theory and accompanying first-order logic is the foundation upon which mathematics is built.

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.

Number theory/abstract algebra, which is the study of natural numbers among other things, is a form of set theory. And set theory is what mathematics calls type theory.

> Number theory/abstract algebra, which is the study of natural numbers among other things, is a form of set 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...

> No it isn't ... You almost never hear the word "type" spoken in math courses.

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.

> 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".

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.

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.

> 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?