What we really need is a sort of stress-strain curve for each of the
major languages. Since Haskell is a typed language, we can have one
curve for types and one for values:
VARIABLE TYPE VALUE
-------------------------------------------------------------------
stress | effort to learn language | coding effort/time required
-----------|---------------------------|----------------------------
strain | ability to solve problems | marginal rate that problem
| | is being solved
-----------|---------------------------|----------------------------
yield | knowledge needed to write | boilerplate code needed
strength | "Hello World" program |
-----------|---------------------------|----------------------------
modulus of | semantic power of | productivity once boring
elasticity | language syntax | stuff has been written
-----------|---------------------------|----------------------------
ultimate | expressive power | NONE
strain | of the language |
-----------|---------------------------|----------------------------
ultimate | NONE | point at which code
strength | | is getting beyond you
-----------|---------------------------|----------------------------
failure | NONE | point at which code is
point | | broken and indecipherable
--------------------------------------------------------------------
Each language will be strong in one part of the curve. Haskell is
superior in those parts of the curve where it matters most in real
tasks, at the high strain end of the graph, both in type (there's always
something more to learn, so no programmer burn-out) and in value (one
person can manage more complexity with less effort).
The PR problem is that newcomers to Haskell are being asked either to:
1) Trust me (but President Bush has strained that argument past failure)
2) Sample the curve at the low end (benchmarks, toy problems) and
extrapolate the higher end, giving a very false impression
The only answer is to provide a positive marginal interest at each point
in the language acquisition process to entice the learner to keep
sampling as (s)he progresses individually up the curve. This is the real
benefit (and most noble purpose) of haskell-cafe. And of course the
justification for this strained material science metaphor! :)
Dan Weston
Philippa Cowderoy wrote:
On Wed, 10 Oct 2007, Andrew Coppin wrote:
(I'm less sold on whether you really need to learn a particular dialect
well enough to *program* in it...)
If you don't then you won't be able to see how complicated things actually
get done. It's also an important exercise in abstracting things and
keeping something understandable when the system you're building is
fighting back against it.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
