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>
wrote:

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

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

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



Relevant Pages

  • Re: Googles Go language and "goroutines"
    ... programming: direct programming and programming by diff/patch. ... On top of the programming issues, readers of source code must read via ... but this is not the case with type hierarchies. ... to do so at first due to language support; ...
    (comp.lang.tcl)
  • Re: Googles Go language and "goroutines"
    ... programming: direct programming and programming by diff/patch. ... Subtyping means simply creating a new type that permits at least the same set of operations as the base type. ... but this is not the case with type hierarchies. ...
    (comp.lang.tcl)
  • Re: Googles Go language and "goroutines"
    ... My first issue is that you need to support additional language ... programming: direct programming and programming by diff/patch. ... You are confusing subtyping and inheritance. ... languages which support type hierarchies obviously have ...
    (comp.lang.tcl)
  • Re: Creationist software engineering? A frightening possibility!
    ... He seems keen to try and pretend that all programming ... Randy Howard may be safely ignored. ... "any decent C compiler". ... It was ooohhhh so troll-like to publish source code and conduct ...
    (comp.programming)
  • Something has to be tested and maintained was Re: GoTo in Java
    ... to translate it to Java, and get something not too bad. ... Source code translations have been tried for several decades and they ... Because of its COBOL and procedural programming roots, ... Encapsulate functionality and reuse it. ...
    (comp.lang.cobol)