Re: Google's Go language and "goroutines"

On Nov 16, 6:49 am, "Donal K. Fellows"
<donal.k.fell...@xxxxxxxxxxxxxxxx> wrote:
On 16 Nov, 14:13, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>

I was just arguing it would be cool to be able to extend a type
instead of duplicating.

Extending? Adding new operations?

I have an essentially organic distaste for type extensions so it is
somewhat difficult for me to explain via rational argument.

My first issue is that you need to support additional language
features to create a type extension, so you get automatic language
bloat and measurable technical complication.

As a consequence of this first issue, there are two modes of
programming: direct programming and programming by diff/patch. To
understand the problem of programming by diff/patch, imagine if you
had to update source code by typing in the diff of the original code
and what you want the new code to look like. This is what programming
via diff/patch is like.

On top of the programming issues, readers of source code must read via
diff/patch. You have to perform mental gymnastics to replace what
appears on paper/monitor with the actual in-memory structure of the

My second issue is that I don't think the real world supports type
hierarchies. They are a logical construct which "does not model" the
real world. Unlike most models, type hierarchies add complications to
the model which do not exist in the real world. Usually models
simplify reality, but this is not the case with type hierarchies.

Note that "type hierarchies" are different from "object hierarchies".
One example of an object hierarchy is type restriction, or filters, or
subsets. Although objects don't exist in a physical hierarchy, it is
easy to pick subsets of any group of objects based upon an arbitrary

Of course I have a lot of respect for developers who can do all the
mental gymnastics required to work with type hierarchies, I just hope
they don't start directing movies or writing novels.