[Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

[Joachim Durchholz]

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.

Word.

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).

Regards,
Jo