[Haskell-cafe] Type Directed Name Resolution

[Richard O'Keefe]

On 11/11/2010, at 4:02 PM, Sebastian Fischer wrote:

>  Why blame languages instead of writers?

We _find fault_ with programming languages
and we _blame_ their designers.
A programming language is a tool.
A saucepan whose handle keeps falling off is defective,
and if someone who didn't realise the dangers gets a
pan of boiling water over their feet, we find fault
with the saucepan and blame its designer.

A programming language can help in the production of
working software in several ways:
 - making it easier to do the right thing
 - making it easier to find mistakes
 - making it harder to make mistakes
 - making it easier to read the result.

For some tasks, C makes it very easy to do the right thing.
It also makes it horribly easy to make mistakes and hard to
find them.

The amount of time spent maintaining a program is much higher
than the amount of time spent creating it initially.  That
means that if you have a tradeoff between ease of writing and
the other virtues of a language, ease of writing *matters* less.

Consider the vexed question of repeating all or part of the
record name in the field name.  Yes, this *is* a burden on
the person writing it.  But it is a **help** to the person
reading it.  The same applies to using module prefixes
(possibly abbreviated ones).  If I see 'length' in a
Haskell program, I am for sure going to think it is the one
from the prelude.  If I see 'B.length', I know that I need
to remember what B is (probably some kind of ByteString, these
days).

When people enthuse about how the compiler can figure it all
out, I shudder.  How am *I* going to figure it all out without
heavy machine assistance?

If length, map, and so on had always been part of a Sequence
typeclass, people would not now be talking about
>> a lot of value in locally saying 'this particular invocation
>> should be ad-hoc overloaded' for common functions like 'length',
>> 'map', 'lookup', etc.

I expected more use of type classes in the Prelude for Haskell'.