Linked by Amjith Ramanujam on Fri 19th Sep 2008 21:00 UTC, submitted by Ward D
General Development Computerworld chats to Simon Peyton-Jones about the development of Haskell. Peyton-Jones speaks in depth about his desire to 'do one thing well', as well as interest in lazy functional programming languages and their place in a world with rapidly increasing multi-core CPUs and clusters.
Thread beginning with comment 331056
To read all comments associated with this story, please click here.
Haskell sucks.
by axilmar on Mon 22nd Sep 2008 11:09 UTC
axilmar
Member since:
2006-03-20

It sucks because programming is 99% about "side effects" than mathematical formulas.

Please note the use of quotes for 'side effects'. They are called 'side effects', although they are the most interesting part of programming. It's the part that things happen inside a computer that change the world.

Haskell makes it really difficult to write useful code (where useful means 'with side effects').

They may show you how to create 'infinite' number sequences and process them.

Cool. Ask them to make a Model-View-Controller application in Haskell, where the model is a tree of nodes. Trivial in imperative languages, hard as hell in Haskell: you have to use the Zipper monad, mix the useful code with visitation to the tree code, because the only way to modify tree node links in Haskell is via local parameters...

RE: Haskell sucks.
by cale on Wed 24th Sep 2008 21:09 in reply to "Haskell sucks."
cale Member since:
2008-09-24

Actually, you're dead wrong. Model-view-controller is not only easy in Haskell, much of the design is enforced! Typically, the model will consist primarily of pure functions, in your case, some pure functions manipulating a tree of nodes. The view and controller, on the other hand, will (at least in part), be in the IO monad, since they're required to do input and output. This gives you a lot of the required restrictions on how the model communicates with the view and controller for free.

Of course, there are details like how you're going to store the tree. You could possibly use a zipper (not necessarily a monad), if that suits your application, but also quite possibly a straightforward tree data structure will do. If the manipulations you're doing are very graph theoretic in nature, with lots of rewiring of edges, representing the tree as, say, a Data.Map from vertices to sets of vertices might work better. (More or less equivalent to using sets of pointers to build a mutable tree in a lower-level language.)

If you'd like help with a specific program, or more details about how this works, come and talk to me on IRC. I'm Cale in #haskell on freenode.irc.net. If I'm not there, someone else will be happy to help you, I'm sure.

Haskell is not a particularly difficult language to use, but it requires a little bit of mental rewiring in terms of the way you think about programming, which makes the learning curve steeper for those who are already intimately familiar with the imperative programming model.

Reply Parent Bookmark Score: 1