Philosophy and "for" loops — more from Go and Rust [LWN.net]

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 19:40 UTC (Wed) by Frej (guest, #4165)
In reply to: Philosophy and "for" loops — more from Go and Rust by b7j0c
Parent article: Philosophy and "for" loops — more from Go and Rust

Is haskell really more complex, or is it just (especially) industry inertia?

to post comments

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 20:17 UTC (Wed) by b7j0c (guest, #27559) [Link] (1 responses)

well, where there's smoke there's fire. enough people talk about the barrier to entry that we might as well admit it is there.

learning about the real implications of lazy evaluation, monadic IO, currying, AGDTs etc are a stretch for most developers. this is not to say they aren't valuable lessons that will help anyone become a better coder, but they do require a time commitment.

Philosophy and "for" loops — more from Go and Rust

Posted Jul 4, 2013 8:21 UTC (Thu) by Frej (guest, #4165) [Link]

I'm not saying it's haskell is simple, far from. I'm claiming it is just as complex and difficult to learn and master. Control flow is a really complex issue, being it iterative loops or recursion.

I'm sure if you ask those who teach comp.sci introductory courses, they will tell you the same, but maybe they just brainwashed me ;) Many universities have chosen a functional language for the intro course (such as SML) exactly because of this. They claim it is easier to learn, especially for those who haven't programmed before.

For lazy evaluation as the default, yes it might have been a mistake. It makes figuring out time complexity of a program unnecessary hard.

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 22:09 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

My experience with Haskell has been that the syntax, execution model, and standard libraries aren't particularly difficult to pick up, but learning to write idiomatic Haskell code (i.e. not all in the IO and/or State monads) to solve common problems can take a long time, particularly when your reference material is assuming a procedural language with mutable variables. Some of the algorithms and data structures frequently used in procedural programs do not translate well to languages where data is immutable by default. The trade-off, of course, is that immutable data eliminates many of the more common kinds of programming errors.

Debugging can also be an issue, a common problem for non-strict languages, though Haskell does have some useful tools in that area--and is known for having less need for debugging to begin with thanks to its expressive type system.