4 ms·

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, m

by tikhonj 14y ago

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.

Locke1689 14y ago
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.
- BystanderX 14y ago
  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.
  - Locke1689 14y ago
    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.
  - andolanra 14y ago
    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-evaluation-in.html 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 http://www.haskell.org/haskellwiki/Iteratee_IO
jhuni 14y ago
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"?
- Locke1689 14y ago
  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.
  - maaku 14y ago
    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.
    - jhuni 14y ago
      > 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.
dschiptsov 14y ago
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.

by tikhonj 14y ago

Locke1689 14y ago

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.

BystanderX 14y ago
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.
- Locke1689 14y ago
  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.
- andolanra 14y ago
  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-evaluation-in.html 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 http://www.haskell.org/haskellwiki/Iteratee_IO

jhuni 14y ago

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

Locke1689 14y ago
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.
- maaku 14y ago
  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.
  - jhuni 14y ago
    > 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.

dschiptsov 14y ago

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.