Christopher Smith wrote:
In addition, "you have to think the Haskell way to be efficient" smacks
of "you have to think the XXX way to be efficient". Generally, I find
that argument means "We're not very flexible. We fit a certain class of
problems and ignore the rest". That's not necessarily a bad thing, but
people should be aware of it.
I disagree with this pretty strongly. It is a common problem with
porting solutions from one language/framework to another. If you just do
a straight translation you almost inevitably end up with an inefficient
system.
Agreed.
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.
However, the Haskell people need to swallow that or adjust the language
a bit.
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.
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.)
That's a major learning curve.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
