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

[Ben Lippmeier]

> On 7 Feb 2016, at 2:32 am, Michał Antkiewicz <mantkiew at gsd.uwaterloo.ca> wrote:
> 
> Every programmer should understand the difference between boxed and
> unboxed values. Period. The fact that Haskell allows for levity
> polimorphism is something we should be proud of and leverage in
> teaching, not hide it or lie about it.


When I first read the “Unboxed values as first class citizens..” paper I felt smart, like learning the difference between Int and Int# was helping me understand how compilers worked under the hood. Now, ~15 years later, I already know all these details and having to constantly worry about the difference between Int and Int# when writing application code makes me feel dumb. When I then read people praising the advanced Haskell type system and the fact that we can now use advanced Haskell type system features to write polymorphic functions that work with both Int and Int# I feel even dumber. This isn’t a criticism of the work on levity polymorphism, more that it feels to me like a solution to a problem that should not exist in the first place.

In my own mind, the boxed/unboxed problem is in the same bucket as the problem that ownership typing tries to address in the OO world. Every OO programmer can recite the great engineering benefits of splitting the fields and methods of an object into public and private. However, in most OO languages, if a public method returns a reference to mutable private state, then the caller can then update the internal state of the object. Ownership typing is an advanced type system extension for OO languages to prevent this from happening. 

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. These days when I read papers about advanced type system extensions I typically feel smart for a few days, but then after reflecting on it a few weeks or months later I often feel dumb again. I’m not sure if that’s something to be proud of...

Ben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160207/2a8d7cad/attachment.html>