[Haskell-cafe] clonetype

[Sven Panne]

Am Mi., 26. Sep. 2018 um 16:50 Uhr schrieb Harendra Kumar <
harendra.kumar at gmail.com>:

> 1) Nobody has pointed out what kind of bugs (with specific examples) will
> arise if we have something like clonetype. Are those bugs more dangerous or
> will consume more time compared to what we are trying to avoid in the first
> place? I am just trying to learn more about it, not claiming that this is
> better.
>

I think the main danger here is that it is totally unclear what actually
gets derived. Is there a written specification of what actually should be
derived? How would such an extension interact with other already existing
extensions and separate compilation/instances added at a later time? If
this can't be specified exactly, concisely and intuitively, you *will* have
a maintenance nightmare, just like with all implicit things.

>
> 2) It is a real unsolvable problem that people take shortcuts when
> available,
>

No, this is not unsolvable. People, especially newcomers to writing SW,
must be educated, otherwise they will have to repeat the mistakes already
made by lots of other people (a.k.a. "learning the hard way"):

   * What initially looks like a good cunning idea and/or like a shortcut
will almost always turn out to be a nightmare later during maintenance and
debugging.

   * Explicit is better than implicit. Note that this doesn't necessarily
mean that you have to repeat yourself.

   * Only a tiny amount (I think I've read 5-10% several times) of time is
actually spent programming things, the rest is spent understanding the
problem, reading code (from other people or often even worse: your former
past ;-), debugging and extending existing SW. Trying to optimize for the
tiny fraction doesn't look like a good idea. This manifests in the mantra:
"A good programming language doesn't make it easy to write correct SW, it
makes it hard to write incorrect SW."


> people will be people; this is also one of the reasons why Haskell is not
> so successful, other languages are easy in the short run. If we accept that
> this a fact of life, [...]
>

This shouldn't easily be accepted, quite the opposite. A lot of users of
"easy" and "concise" programming languages have learned the hard way that
their beloved language doesn't scale at all, leading to the development of
TypeScript (extending JavaScript), mypy (extending Python), Hack (extending
PHP), etc.  What can be accepted as a fact of life is that there is often a
tempting short route which is totally fine for throw-away scripts, quick
hacks, etc., and there is a longer route, investing into the future. You
have to choose...

Coming back to the problem at hand: Even if we find a way to factor out the
deriving-clauses to stay explicit, e.g. via the deriving synonyms proposal,
I am not so sure if this is a good idea. How can you be sure when changing
such a synonym that *all* affected types should really be changed? This
would again be a maintenance nightmare.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180926/7ff79aff/attachment.html>