Weekly Edition
Return to the Press page
| |||||||||||||
Translate Haskell into English Manually (Linux Journal)
Linux Journal looks
at the Haskell programming language. "Have you ever tried to
learn Haskell and hit a brick wall? Have you tried to read the main
tutorial, "A Gentle Introduction to Haskell", and found it to be about as
gentle as a Pan Galactic Gargle Blaster? Did you have to learn about
monads before you could even write your first non-trivial Haskell program?
Have you noticed that unless you already know Haskell, it's even less
readable than Shakespeare? Have you searched for an example of a
nontrivial Haskell program only to find you can't understand it?"
(Log in to post comments)
Translate Haskell into English Manually (Linux Journal) Posted Jun 21, 2006 16:24 UTC (Wed) by b7j0c (subscriber, #27559) [Link] great to see this here. i would love to see haskell (and functional tools in general) hit a tipping point. these tools offer excellent relative performance with some nice added safety features and most importantly, new ways of thinking.
Translate Haskell into English Manually (Linux Journal) Posted Jun 22, 2006 9:25 UTC (Thu) by micampe (guest, #4384) [Link]
Functional tools are already hitting that tipping point, just not in the form you're looking for them, but in the form of great features in slightly more traditional languages.
static analysis and parallelism considered helpful Posted Jun 23, 2006 4:26 UTC (Fri) by xoddam (subscriber, #2322) [Link] Unfortunately the two languages cited, while they make excellent use offunctional *notation*, are incapable of making the kinds of guarantees that are required to get the full advantage of functional programming. It's theoretically possible that some kind of type inference system could run over a completed Python or a Ruby program so a compiler can know where exceptions *can't* occur, but unconstrained runtime polymorphism and extensibility make such a guarantee impossible in general. And more to the long-term point, support for concurrency in traditional imperative languages is little better, in practice, than pthreads. In general mutable objects can be altered from any thread of execution, therefore no guarantees can be made about their integrity without serialisation, in the form of unrollable transactions or locks. Concurrency is a hard problem. Making good use of numerous threads of execution is much, much easier if changes to shared mutable objects are kept to an absolute minimum. Languages like Haskell which only grudgingly acknowledge the theoretical possibility of a mutable object are potentially very useful in this regard; though hard to learn for us old C hackers :-)
Translate Haskell into English Manually (Linux Journal) Posted Jun 25, 2006 21:10 UTC (Sun) by fergal (subscriber, #602) [Link] Functional tools are already hitting that tipping point, just not in the form you're looking for them, but in the form of great features in slightly more traditional [python] languages [ruby]. I know almost nothing about ruby but people tell me it's very functional. However, I'm forced to use python every day and it has little support for functional programming. It's only relatively recently that it's had lexical closures and they require some serious hoop-jumping. lambdas are extremely limited almost to the point of uselessness. Also Guido wanted to get rid of (will get rid of?) map, filter and reduce. That is definitely not compatible with support for functional programming.
Currying, lazy argument evaluation Posted Jun 26, 2006 11:54 UTC (Mon) by ringerc (subscriber, #3071) [Link] Perhaps even more importantly, there's no real support for currying and uncurying functions (though at least it's not too hard to layer on top). The biggest problem to my mind is that arguments are not lazily evaluated. You can fake it with generators, but it's pretty clumsy compared to just passing [ 1 .. ] .
Translate Haskell into English Manually (Linux Journal) Posted Jun 21, 2006 19:38 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] I've been working through Hudak's book, The Haskell School of Expression.http://www.powells.com/biblio/4-0521644089-0 Moreso than other languages, perhaps due to its tersity, Haskell is really one you want to speak aloud while trying to puzzle out the syntax. But not when others are in earshot.
Translate Haskell into English Manually (Linux Journal) Posted Jun 21, 2006 22:25 UTC (Wed) by b7j0c (subscriber, #27559) [Link] i have been reading this too. its good, but i wish he wrote his code segments as real code (literally type the chars i should type). he sort of does, but its somewhat annoying.
Translate Haskell into English Manually (Linux Journal) Posted Jun 21, 2006 23:42 UTC (Wed) by stephenjudd (subscriber, #3227) [Link] So it's not just me. Coincidentally I pulled this book off the shelf over the weekend. It's not easy to follow the examples on your own when there's no explanation of how Hugs actually works or how you run the code samples in Hugs.
Translate Haskell into English Manually (Linux Journal) Posted Jun 22, 2006 5:19 UTC (Thu) by b7j0c (subscriber, #27559) [Link] i have moved to ghci for 'repl' like development. i am not qualified to say if it is better than hugs, but it seems easier to deal with.
Translate Haskell into English Manually (Linux Journal) Posted Jun 22, 2006 20:15 UTC (Thu) by dwheeler (guest, #1216) [Link] Haskell for C Programmers is also a good place to start for traditional developers. The "Gentle" introduction is gentle for those who are already steeped in functional programming; the problem is that it is a terrible introduction for most programmers, who are not steeped in it.
|
|||||||||||||