[Haskell-cafe] Investing in languages
cdsmith at gmail.com
Wed Jul 11 17:39:30 UTC 2018
I think it's important to keep in mind that the correct trade-off for one
situation is not the correct trade-off for another. This is a great
example! On one side of the spectrum, you've got situations where Idris or
Agda are good fits, where it's critically important to know that code is
correct, even at the expense of significant complexity or time. But there
is another side of that spectrum. It's probably best characterized by
education: there are no users, bugs that aren't found don't matter at all,
and even when you know for sure that something is wrong, it would be great
if you can let it fail and *watch* it go wrong; stopping someone who's
learning to tell them they got something wrong before they understand WHY
is bad teaching.
I've been working for years now on using (a variant of) Haskell in early
education, as young as 10 to 11 years old. Looking at this experience, I
agree whole-heartedly that regardless of what's best in a professional
setting, there's still something about Haskell that's far more difficult to
learn than Python and Java. It's not about the incidental complexity of
the language, which can usually be avoided. It's about the way everything
just looks so easy once it's written, but new programmers struggle mightily
to figure out how to get started in writing it. People don't understand
how to build things compositionally.
As an aside: I know it's popular among the functional programming world to
hypothesize that this is because people have used imperative languages
first. I can tell you, though, that the hypothesis is wrong. I spend a
good bit of my time teaching students with no previous programming
experience in any language. They also struggle with it, but they
understand imperative programming intuitively. Mathematics teachers also
know this, and it's why they so often fall back to teaching step-by-step
processes instead of talking about subexpressions having meaning. Think
about how you learned the "order of operations", which obviously should be
understood as a question of parsing and identifying subexpressions, but is
always taught as "you multiply before you add" because that's what gets
correct answers on exams.
Incidentally, realizing this makes me more determined to teach Haskell and
compositional thinking at a younger age. It might not be easy, but you
don't get far in mathematics without grasping the idea of building up
abstract objects through composition. This shift from thinking about "how
to get it done" to thinking about "what it means" is a huge step toward
understanding the world around us, and should be pretty far up on the
priority list. So I'm not badmouthing Haskell here. I'm just saying we
should realize that there's a very real sense in which it is legitimately
HARDER to understand. No use being in denial about that.
On Wed, Jul 11, 2018 at 11:10 AM Stefan Monnier <monnier at iro.umontreal.ca>
> > but functional programming is harder.
> There's no doubt that languages like Haskell go through extra efforts to
> make it *harder* to write incorrect code, and along the way they also
> make it harder to write code at all.
> So maybe it will take your guy a week to get the code written in
> Haskell, whereas a couple days were sufficient in Java. But that's
> without counting the subsequent month during which the Java code will
> have to be debugged before it actually works ;-)
> IIRC it was Bob Harper who said a good programming language should be
> hard to write (but easy to read, of course)?
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe