[Haskell-cafe] Toy application advice wanted

[mikeb at manor.org]

On Tue, 4 May 2004, Bill Walsh wrote:

> I am amazed that you can even think of doing anything in a week.
> I have been at it for at least 15 years: one project; one dead set
> proof-of-concept .

Well I'm sure you're doing something much more useful/worthwhile than I!
=)

I understand that the example program I initially thought of is rather,
well...typically imperative.  That's sort of the reason I chose it.  Not
only does it have real-world ramifications to my customer (the problem
domain is similar) but it will hopefully show me the worst of the best.
I.e., Haskell is a beautiful language [disclaimer: this comes from me not
really being a Haskell programmer, but admiring it from afar if you will]
and can express some unbelievably advanced concepts elegantly, but is it
really nasty doing "normal" software crap like loading a bunch of data,
popping up GUI windows, etc. etc.?

I was hoping that I can piece together something fairly quickly within two
weeks in those three languages.  They don't have to be robust, or even
beautiful.  In fact, I can guarantee they won't be.  But the real point of
the exercise is for me to figure out which environment is the easiest for
me to get along with.

> I will follow your progress with intense interest.
> Your are obviously an experienced programmer, but it is your analytical
> skills which interest me most.

Well, I am an experienced programmer, but certainly not in the same class
as most lambda-junkies as yourselves.  I have a long sordid history of
programming in imperative languages and I've been bitching about switching
for long enough that it's time to put my money where my mouth is, so to
speak.  I've dabbled in Scheme and Erlang and ML.

To be frank, I've all but discarded Erlang as a viable language.  Don't
get me wrong...it's got some great features; I just think that I could
easily implement Erlang in Scheme or Haskell and be quite happy.  (At some
point in the future when I'm smarter =)

So to me, the real question is:  Haskell, the pure, or Scheme, the dirty?

Haskell is lazy all the time.  That's awfully nice...I'm not sure if
there's a performance penalty somewhere, but assuming there isn't, kudos
to it.  Scheme lets you be selectively lazy with macros.  At least it's
highly customizable (for instance, pattern matching can be implemented in
Scheme with macros, whereas other languages that have fixed special forms
are quite limited).

But Scheme lets you change things if you want to!  (The Haskell
afficianados gasp).  Let's face it...in most long-running applications,
data changes a lot during the lifetime of a program.  So somehow, you have
to manage the repercussions of state changes.  Haskell does this with
monads.  (I'm still wrapping my brain around them, but...)  Apparently
monads plus some syntactic sugar are like functions that return a value
and the next function, which in turn returns a value and the next
function, etc. so that referential transparency is maintained.  This is a
heckuva lot of work to do (set! foo 'bar).  I hope I'm not far off base
with this.

I guess it boils down to this:  Haskell ensures that your bindings are
never ever ever corrupted, and thus the sematic value of your program is
never compromised from the outside.  The cost of this is a sharp learning
curve, and quite possibly a performance hit.  Scheme lets you tromp all
over stuff (well, you get the picture), in effect letting you still have
control over when you really need to do something imperative for
performance or simplicity reasons.

I'm not sure which I *like* better.  So far neither is visually appealing,
mostly because I'm not familiar with them.  Scheme seems to have a
slightly bigger population than Haskell, which of course means squat
because if I really cared about how many programmers of language X there
are out there I'd just code in Java (which, sadly, I'm doing now).

Anyway, I'm starting to ramble, but I talked to a friend who has similar
feelings but is actually pretty good at Common Lisp.  He suggested I
refocus my energies, and I agree:  instead of biting off more than I can
chew, and having to learn a whole wad of APIs that aren't really about the
language (read: wxHaskell or gtk2hs/the like, or audio packages etc.),
just code some really simple problems.

Like the Sieve of Eratosthenes, in all three languages.  Or a simple
publish/subscribe framework with a "master" state holder and many slaves.
Or quicksort.  Etc. etc.

So I'm going to head down that path right now, and try to get a feel for
the languages in a slightly more pure fashion.  I'll still try to get
performance metrics out of them, but I'm not going to bang my head against
the wall learning new languages, GUI toolkits, and FFIs all in two weeks.

=)

Thanks for the replies so far, I really appreciate them.

--
Mike J. Bell                                This is all just my opinion.
"Outside of a dog, a book is man's best
friend.  Inside it's too dark to read."                  mikeb at manor.org