[Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
jo at durchholz.org
Sun Feb 7 10:50:40 UTC 2016
Am 07.02.2016 um 09:26 schrieb Ben Lippmeier:
> It also feels like the same class of problem as what the segmentation
> registers in the x86 architecture try to address. Does anyone here
> know how the 8086 processor addresses more than 64k of memory with
> only 16-bit address registers? I sure wish I didn’t.
Yes I do, and yes I wish I didn't either.
For the Int/Int# concept, the approaches I have seen either ignore the
efficiency and let the machine figure out what to do (Smalltalk, Python,
pre-Int# Haskell), or they complicate the type system at the expense of
polymorphism (Java, Eiffel), or they complicate the type system even
more to regain some form of polymorphism (C++, today's Haskell).
I guess the world is still waiting for an approach that does not force
this choice on language designers.
Aside note: My own choice would be to have an annotation that tells the
compiler to keep something unboxed if it can, and if it cannot, have it
print a warning why not. Not seeing this choice in the wild means that
either language designers didn't find the right way to do this, or the
idea as such is dumb; I don't know which.
> With Int/Int#, public/private and x86 segmentation, the abstraction
> never really worked in the first place. However, because there
> weren’t any other obvious solutions at the time, these “features”
> were grandfathered into the culture of the technology.
As much as I agree that design misdecisions can perpetuate by becoming
part of the technology culture (see PHP's view on security, or C's
insistence on microoptimization), this did not happen for x86 16-bit
segment/offset addressing. Even Microsoft switched as fast as they
could, and that was in the old days when features were far more
important than security or even stability.
> For the
> disciples of a particular technology, the recognition of problems in
> the fundamental design of that technology tends to result in
> extensions to what they already have -- rather than backing up and
> reconsidering WTF they were thinking in the first place.
Problem is that it is possible to add features to existing language, but
almost impossible to remove them. Those working on practically useful
type systems want to solve an existing problem in an existing language,
so they don't have a motive to reconsider; even if they did, they'd
quickly drop the thought because whatever the change they'd want, it
would get rejected because it would break existing code left and right.
This seems to be a universal problem. Every language that I know has it,
including Haskell (which I don't really know well enough but the
discussion and options are just as with any other language).
More information about the Haskell-Cafe