Google's Go language and "goroutines"
in [TCL]
|
Prev: tcl ssh extension library?
Next: Expect spawn expect
From: Larry W. Virden on 19 Nov 2009 10:27 On Nov 19, 7:33 am, "Larry W. Virden" <lvir...(a)gmail.com> wrote: > One of the recent articles mentioned the fact that the Android > platform either is currently, or expected to be by the end of year (I > don't remember the exact quote) the largest Linux platform in > existence. Well, technically, I guess, this article (which I think I was remembering when I wrote that) http://www.computerworld.com/s/article/9141037/Opinion_The_future_of_Linux_is_Google?source=CTWNLE_nlt_os_2009-11-19 is talking about Google's OS. However, the thrust of the article was about google and linux, so I guess if Google's OS becomes one of the largest platforms, that might make it the largest Linux platform. Anyways, I wanted to point to the article that I had been remembering.
From: tom.rmadilo on 19 Nov 2009 16:02 On Nov 19, 4:27 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote: > tom.rmadilo wrote: > > On Nov 16, 6:49 am, "Donal K. Fellows" > > <donal.k.fell...(a)manchester.ac.uk> wrote: > >> On 16 Nov, 14:13, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > >> 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. > > You are confusing subtyping and inheritance. Subtyping means simply > creating a new type that permits at least the same set of operations as > the base type. It says nothing about how these are implemented. > Inheritance is then a specific mechanism for reusing code to implement > subtyping, which corresponds to your notion of programming by > diff/patch, but is not the only approach by a long way. No I'm not confusing anything. You might be, can't really tell. First, you can use words like subtyping, inheritance or extension, it makes no difference. My point is that "flat" hierarchies obviously don't need language features to support inheritance. This should be obvious. So, languages which support type hierarchies obviously have at least two completely different mechanisms in which to define types: directly and by reference to some other type. The by reference is much more complex than the direct method. Adding additional methods in which to support and define type hierarchies does not make programming any simpler, this should also be obvious. But, some people like the complexity, I don't. It isn't only difficult to do correctly, but the resulting model is often contrived. (Not always, as others have said: it is just difficult to get right). > > > 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. > > Are you advocating a form of Platonic realism, in which there is some > objective "real world" out there which corresponds directly to some > natural approach to modelling? Personally, I believe that the intended > interpretation and application has quite an impact on what models make > sense (cf. the definition of "model" in logical semantics). > > As a case in point, do you believe there is a relationship between the > concepts of "chair" and "furniture"? If you were coming up with a model > of "objects in my house", Object in my house = a collection > then you'd almost certainly say "yes, there is > a kind-of (subtype) relationship between them". Ah, this is the problem: the relationship is also a "type". Using a static subtype (pointer) relationship to a collection requires a map. Simple, but relatively limited since every mapping is identical. If the relationship is also a type, you can create a triple (Me<->Mine<- >Stuff) or (Chair<->Kind Of<->Furniture) When you make a static "kind-of" relationship between chair and furniture, you cannot reuse that relationship like this: (Furniture<->Kind Of<->Stuff). With the type of relationships above, I can say that this is legal: (Me<->Mine<->Chair), since I can own "Stuff", I can own "Chair". And if that relationship is valid, I know that (Me<->Mine<->Furniture) is true, and I can ask what other "Kind Of" furniture are "Mine". Note there is no type inheritance here. There are no type hierarchies, but there are object hierarchies. But just because two types can be connected through a "Kind Of" relationship does not mean they need to share "any" internal structure. > If you were instead > modelling the morphology of words in the English language, then you may > instead prefer not to model such a relationship, but instead to model > "chairs" and "chair" as related to the lexeme "CHAIR". This is completely different. Now you are talking about a combination of mappings/tagging and an ordered hierarchy of "same typed" objects. For instance, in a directory structure, subdirectories are not "subtypes" of the parent. Permissions on the directories are just local tags (or consider them part of the directory object).
From: Neil Madden on 20 Nov 2009 06:25 tom.rmadilo wrote: > On Nov 19, 4:27 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote: >> tom.rmadilo wrote: >>> On Nov 16, 6:49 am, "Donal K. Fellows" >>> <donal.k.fell...(a)manchester.ac.uk> wrote: >>>> On 16 Nov, 14:13, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> >>>> 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. >> You are confusing subtyping and inheritance. Subtyping means simply >> creating a new type that permits at least the same set of operations as >> the base type. It says nothing about how these are implemented. >> Inheritance is then a specific mechanism for reusing code to implement >> subtyping, which corresponds to your notion of programming by >> diff/patch, but is not the only approach by a long way. > > No I'm not confusing anything. You might be, can't really tell. > > First, you can use words like subtyping, inheritance or extension, it > makes no difference. These two statements are contradictory. > My point is that "flat" hierarchies obviously > don't need language features to support inheritance. This should be > obvious. So, languages which support type hierarchies obviously have > at least two completely different mechanisms in which to define types: > directly and by reference to some other type. The by reference is much > more complex than the direct method. Do you have any evidence to support this assertion? > Adding additional methods in > which to support and define type hierarchies does not make programming > any simpler, this should also be obvious. > > But, some people like the complexity, I don't. It isn't only difficult > to do correctly, but the resulting model is often contrived. (Not > always, as others have said: it is just difficult to get right). > >>> 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. >> Are you advocating a form of Platonic realism, in which there is some >> objective "real world" out there which corresponds directly to some >> natural approach to modelling? Personally, I believe that the intended >> interpretation and application has quite an impact on what models make >> sense (cf. the definition of "model" in logical semantics). >> >> As a case in point, do you believe there is a relationship between the >> concepts of "chair" and "furniture"? If you were coming up with a model >> of "objects in my house", > > Object in my house = a collection > >> then you'd almost certainly say "yes, there is >> a kind-of (subtype) relationship between them". > > Ah, this is the problem: the relationship is also a "type". Using a > static subtype (pointer) relationship to a collection requires a map. Eh? In what way is a relationship a type? And why would this require a map? > Simple, but relatively limited since every mapping is identical. If > the relationship is also a type, you can create a triple (Me<->Mine<- >> Stuff) or (Chair<->Kind Of<->Furniture) Yes, you can express arbitrary relationships with triples, cf. RDF, but what does that have to do with anything? > > When you make a static "kind-of" relationship between chair and > furniture, you cannot reuse that relationship like this: > > (Furniture<->Kind Of<->Stuff). Umm... sure you can. > > With the type of relationships above, I can say that this is legal: > > (Me<->Mine<->Chair), since I can own "Stuff", I can own "Chair". The only valid reason for making that assertion would be if you also knew that all chairs are stuff -- i.e., that your logic has some notion of subsumption/subtyping. And > if that relationship is valid, I know that (Me<->Mine<->Furniture) is > true, and I can ask what other "Kind Of" furniture are "Mine". [...] > >> If you were instead >> modelling the morphology of words in the English language, then you may >> instead prefer not to model such a relationship, but instead to model >> "chairs" and "chair" as related to the lexeme "CHAIR". > > This is completely different. Now you are talking about a combination > of mappings/tagging and an ordered hierarchy of "same typed" objects. > For instance, in a directory structure, subdirectories are not > "subtypes" of the parent. Permissions on the directories are just > local tags (or consider them part of the directory object). That was my point. You cannot make blanket statements like "type hierarchies are unnatural" without first stating what your domain of interest is. Sometimes they're useful, sometimes they're not. -- Neil
From: tom.rmadilo on 20 Nov 2009 14:26 On Nov 20, 3:25 am, Neil Madden <n...(a)cs.nott.ac.uk> wrote: > tom.rmadilo wrote: > > My point is that "flat" hierarchies obviously > > don't need language features to support inheritance. This should be > > obvious. So, languages which support type hierarchies obviously have > > at least two completely different mechanisms in which to define types: > > directly and by reference to some other type. The by reference is much > > more complex than the direct method. > > Do you have any evidence to support this assertion? Why don't you give an example which proves the assertion wrong. It would be impossible for me to "prove" by example the assertion, but you can easily disprove it with one example. > > Object in my house = a collection > > >> then you'd almost certainly say "yes, there is > >> a kind-of (subtype) relationship between them". > > > Ah, this is the problem: the relationship is also a "type". Using a > > static subtype (pointer) relationship to a collection requires a map. > > Eh? In what way is a relationship a type? And why would this require a map? Well, below you know about RDF, so I assume you know that each part of the triple is an object of some type. > > Simple, but relatively limited since every mapping is identical. If > > the relationship is also a type, you can create a triple (Me<->Mine<- > >> Stuff) or (Chair<->Kind Of<->Furniture) > > Yes, you can express arbitrary relationships with triples, cf. RDF, but > what does that have to do with anything? Everything. Independent object/type creation. The relationship (Kind Of) is also a type. > > When you make a static "kind-of" relationship between chair and > > furniture, you cannot reuse that relationship like this: > > > (Furniture<->Kind Of<->Stuff). > > Umm... sure you can. > Only if "Kind Of" is a type. > > > With the type of relationships above, I can say that this is legal: > > > (Me<->Mine<->Chair), since I can own "Stuff", I can own "Chair". > > The only valid reason for making that assertion would be if you also > knew that all chairs are stuff -- i.e., that your logic has some notion > of subsumption/subtyping. That is not true. You dynamically create the relationships. You don't "know" anything until you ask. Your system might have the following triples: (Me<->Mine<->My Chair) (My Chair<->Kind Of<->Chair) (Chair<->Kind Of<->Furniture) (Furniture<->Kind Of<->Stuff) The "language" does not have a notion of subtyping, just creating triples. > That was my point. You cannot make blanket statements like "type > hierarchies are unnatural" without first stating what your domain of > interest is. Sometimes they're useful, sometimes they're not. So I should write a book instead? I'm not saying that all type hierarchies are unnatural, I just wish someone would present a natural one as an example. Even if such an example emerges, why do the subtypes need to be constructed via this formal mechanism? Copy/Paste & Edit is great way of creating a new subtype. I know that my terminology is loose. Is there a difference between data subtypes and class/object subtypes which include behaviors? How about inheritance vs. extensions vs. implementations? All of these are different, yet pretty much the same thing: they all require language support to get from the original thing to the new thing. But I would like to separate out one type of "subtyping" that seems easy for me to understand (amazing!), and produces subtypes whose members are a true subset of the original type. The definition still requires language support, but the subtype mechanisms are pre-defined. Not sure if there is an actual name for it, but in XML-Schema they call it derivation by restriction. Although not required in the XML- Schema system, one additional requirement I would add is that type derivation cannot span more than one namespace, in other words, start with the primitive types in XML-Schema/programming language and derive new types in the target namespace, no imports. Also, once a simple type is used in a complex/structural type, it can't be further restricted. There is an article which almost gets at my general distaste for subtyping: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html (Why Extends is Evil) Interfaces are probably my favorite abstraction. They are built from the ground up and hide potentially vast technical differences behind a common model. Two well known interfaces are "unix files": everything is a file, and a URI. Or more on topic: tcl channels.
From: Bruce Hartweg on 20 Nov 2009 16:22
tom.rmadilo wrote: > So I should write a book instead? I'm not saying that all type > hierarchies are unnatural, I just wish someone would present a natural > one as an example. Look at the java.util Collection hierarchies plenty of natural and useful examples > Even if such an example emerges, why do the > subtypes need to be constructed via this formal mechanism? Copy/Paste > & Edit is great way of creating a new subtype. > It's a great way of creating a mess, and doesn't provide the same results. If a type B is a "subtype" of A that is just a copy of the code and new stuff tacked on, then even though type B can do everything an A can other areas can't treat B as an A since they are different. and maintainance would be a disaster - you would end up with multiple copies of bugs all over the place. Bruce |