Andrew Lentvorski wrote:
I've seen it when translating from almost any language to any
other. To get efficiency, you inevitably have to give up assumptions
about of efficiency that apply to the old tool and embrace new ones that
apply to the new tool.
However, even with the help of the big Haskell gurus, they couldn't
recast that problem into a Haskell-friendly form. That's not "not
giving up assumptions". That's "language doesn't work for the problem."
Again. That's not necessarily an issue. I don't use C if I'm
munching text. I don't use Python if I'm writing a device driver.
C can efficiently munch text quite efficiently. It just tends to be time
consuming and error prone. ;-)
I say this as I work on a project that does tons of text processing and
is implemented in C. :-(
However, the Haskell people need to swallow that or adjust the
language a bit.
It is hard to blame people for trying to broaden the applicability of
their tool of choice unless in so doing they rob the tool of any of its
value. I don't exactly see this happening on the Haskell side. Arguably,
they are doing quite the opposite.
This may be some of the gripe a lot of programmers have with "pure"
languages like Haskell. You have to move a long way up the learning
curve to do anything useful. In Haskell, you must understand Monads
before being able to handle I/O. That's a slog even for functional
programmers with some decent experience.
Monads aren't that bad.
... for simple things.
Once I start needing monads to manage TCP connections, my head starts
to hurt.
That's 'cause you haven't grokked monads yet. ;-)
A simple TCP server jumps up to Shared Transactional Memory and atomic
operations.
See: http://sequence.complete.org/node/258
(Aside: If there's an easier solution than this, please point it out
to me. I'm certain I'll need it sometime.)
http://dada.perl.it/shootout/echo_allsrc.html
Provides a comparison of an echo server and client in a lot of
languages, including Haskell. The Haskell one compares pretty well with
the Erlang one in terms of lines of code (which actually surprises me...
I should look more closely at his Erlang solution to see if it can be
simplified).
That's a major learning curve.
He's not trying to demonstrate the simplest echo server in Haskell. He's
trying to demonstrate a technique, and the benefits of that technique
are dubious in the context of something as trivial as an echo server.
I'm sure this problem was selected because it made it easier to focus on
the technique. When applied to more complex problems, the technique
actually results in easier to manage code.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
