[Haskell-cafe] Language complexity & beginners

Gregory Guthrie guthrie at mum.edu
Sun Feb 7 13:58:47 UTC 2016


I liked this description, and isn't the term for this a "leaky abstraction"?

Where one should not have to know the underlying details of an implementation of an abstraction, but.. due to limitations in the ability to actually abstract out these details, they do have to see down a level into the virtual machine (implementation).

It seems like a theme of the discussion here is if users should need (want) to know the boxed/unboxed issues because it is part of the intended programming model (=good), or if they need to know it because of "details" of the underlying implementation and resulting usage effects (=baggage/complexity).

IMHO the Java need to understand this early on is just an unfortunate by-product of it being a mixed paradigm language. I could see later having more advanced introduction of a feature that allows one to utilize some specific underlying unboxed/primitive representations for performance reasons, but even then seems like it is just an apology for a language weakness, that might go away with future implementations, an abstraction that didn't quite work, "so let me explain the underlying reason and how to get around it..." to optimize your code.
-------------------------------------------
> 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. As a budding
> young programmer, reading about these details was a way to learn how computers operate, but
> it?s not information I would inflict on any of my current students.
> 
> 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. 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. 


More information about the Haskell-Cafe mailing list