[Haskell-cafe] Haskell versus Lisp

[Cale Gibbard]

On 16/09/05, Mark Carter <mcturra2000 at yahoo.co.uk> wrote:
> This is not a troll, honest, so please bear with me ...
> 
> I'm a C/C++/VBA programmer (although the former 2 are several years old
> for me), with a sprinkling of Python. Needless to say, I was looking to
> see if there were any better ways of doing things. I've given things
> like Ruby and Scheme a bit of peck, and failed to get particularly
> enthusiastic about them. Two very interesting choices, though, appear to
> be Lisp and Haskell. It struck me that Lisp was, perhaps, the Ultimate
> Programming Language, the One True Language to rule them all; except
> that I always kept  abandoning it for one reason or another (fiddly
> installation, lack of libraries, compatability problems,  cost, possible
> license issues, etc.). My current foray in Haskell seems encouraging.
> wxHaskell installed a breeze, and seems quite usable (even though I'm a
> raw n00b to the language, and admittedly haven't grokked the semantics,
> and all this  <cid:part1.01000702.09000407 at yahoo.co.uk> IO a -> IO ()
> business). On the one hand, it  seems kinda academic, but on the other,
> it looks like it wants to be practical, too.
> 
> Bearing this in mind, and hoping you can see where I'm coming from, I
> think my question is: shouldn't you guys be using Lisp?
> 
> 

Well, there are a number of reasons which people might have for
choosing one over the other. I think you'll find that many Haskellites
are familiar with one or more variants of lisp and ML.

I'll try to provide some reasons that I find Haskell a fun and
pleasant programming language to write things in. (Actually, a fair
bit moreso than any other language that I've come across.)

One is that Haskell is lazily evaluated, and I really find that a lot
more natural than strict evaluation. It opens up a lot of ways of
writing code and thinking about code which would otherwise be
unavailable. In a strict language, you have to jump through some hoops
whenever infinite or very large amounts of data come along. You tend
to have to use different methods than you would for small data
structures in order to compute only small parts at any one time, and
throw away the parts that you're done with explicitly. In a lazy
language, a list is a list, and a tree is a tree, and the same
functions and techniques apply to them. Even if your data are
moderately sized, there are often times that the easiest algorithm to
write involves a large intermediate data structure, though you'll only
look at it one piece at a time, and maybe won't look at all of it.
With lazy evaluation, you're not penalized for doing things that way.

Of course, there are times when you really want strict evaluation, and
Haskell has ways to provide that. I find that they are relatively
rare.

Another reason is that it is statically type checked. The type system
in Haskell is quite expressive, and I find that it helps to catch bugs
to an incredible extent, and also to structure the way that you think
about code. With algebraic datatypes and the collection of standard
data structures in the libraries, you also don't lose very much
flexibility over dynamically typed structures.

The type system also helps you jump into unfamiliar code. People tend
to write Haskell code which uses types in order to distinguish and
catch those things which are obviously incorrect. When trying to sort
out how a piece of code works, or how to extend it, there is a
somewhat more restricted way that things could be fitting together at
any one point, so it's easier to figure out what's going on, and pin
down the places where you might want to extend things. You can often
go quite a long way in understanding code just by looking at the
types.

I also find that just through using Haskell, and being around the
Haskell community, I expose myself to a lot of exciting computer
science research. I'm still quite impressed that category theory has
found practical applications so quickly. :) Haskell people in general
seem to be experimenting with new kinds of abstractions and seeing how
far they can be taken in being put to practical use. Haskell itself
seems to be developing in directions which serve this experimentation,
and at the same time is becoming more and more practical.

Anyway, these are just some highlights of what I find fun about it,
and of course none of this is meant in any way to detract from all the
other great languages out there. Exploring different programming
languages is a lot of fun and can really expand the way that you think
about code. I encourage you to do so as much as possible.

 - Cale