Google's Go language and "goroutines"
in [TCL]
|
Prev: tcl ssh extension library?
Next: Expect spawn expect
From: Alexandre Ferrieux on 16 Nov 2009 09:13 On Nov 16, 2:25 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > On 16 Nov, 12:41, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> > wrote: > > > And talking about hierarchies, Tcl_ObjTypes display absolutely > > zero null nada ability for polymorphism, which is a longstanding itch > > of mine. > > You're only getting antsy about this because you're thinking of a > Tcl_Obj as an object. It's not. It's a value, but Tcl_Value was taken > for something else at the time. There's simply no type hierarchy > involved with the basic value types. It's just that some operations > understand multiple types (well, that's also inaccurate, but not > nearly as bad as what you were saying). I know there's no type hierarchy :) I was just arguing it would be cool to be able to extend a type instead of duplicating. For example, a BitSet type backed by a bit array but exposing the List API [lindex/lset]. -Alex
From: Donal K. Fellows on 16 Nov 2009 09:49 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? > For example, a BitSet type backed by a bit array but exposing the List > API [lindex/lset]. Not really; that's really just type abuse given that nobody currently has an expectation of such restricted types in Tcl right now. For example, "But I can't use [lset] to put a dictionary in that 'list'! Something's wrong with it!" Just because it would be technically possible to do such things doesn't mean that I believe it to be a good idea... (I might relax a bit sometime in the future when it comes to arrays. I have some ideas there, though they're not really "types" so much as "storage/mapping models".) Donal.
From: Andreas Otto on 16 Nov 2009 11:12 well not only "go" try to improve parallel processing, JAVA too ... -> http://www.ibm.com/developerworks/java/library/j-jtp11137.html I like that the steady work on libmsgque ... -> http://libmsgque.sourceforge.net/ has a very small impact on the state of the art SW industry mfg Andreas Otto
From: tom.rmadilo on 16 Nov 2009 13:55 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. 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.
From: Donal K. Fellows on 16 Nov 2009 16:57
tom.rmadilo wrote: > I have an essentially organic distaste for type extensions so it is > somewhat difficult for me to explain via rational argument. I should mention that I'm not keen on changing Tcl's type system. > 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. I understand, and the impact of Alexandre's idea (it's not mine!) would be substantive and paid by everyone, and yet there's not much certainty of payoff commensurate with that clear cost. > 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. You lost me there (but did put in my mind how people used to work with Minix before the rise of Linux...) > 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. I must respectfully disagree. A *good* type hierarchy does indeed model the world, and I know a number of colleagues of mine who have specific training in performing that modeling step. However, one of the key things is that the "is-a-specialized-kind-of" relationship (the foundation of a type hierarchy as classically understood) is only one of the relations that can be used to couple the categories and instances of ones model; there are many others too. Object Oriented Analysis and OO Design teach the same thing (since they're really all facets of the same general problem area; how to model the real world). Alas, many people get it wrong and misuse the subtype relationship badly. If all your 3-year-old has is a hammer, watch out for the furniture. > 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. Are you thinking in terms of a whole-part (a.k.a. container-component) relationship here? That's totally different. If not, you're getting a bit too metaphysical for me to grasp it. :-) > 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. I don't hold my breath waiting for (most[*]) directors and authors to write high-quality programs or type hierarchies either. It's not a helpful point. ;-) To return to my real point from earlier though, a lot of (and in fact unfortunately far too many) programmers massively abuse the subtype relationship to do all sorts of nasty things. (We'll draw a gentle veil over what C++ does with templates.) This is often because it is easier to do so at first due to language support; mainstream language designers have been largely fixated on subtypes for a few decades now. (Maybe Go is marking a shift away from this approach? Time will tell...) Donal. [* As it happens, I personally know some exceptions; people exist who are both decent programmers and directors. It just goes to show that ones job is not actually a fundamental characteristic, but rather just a role. OTOH, the fact of their humanity *is* (so far as anyone can really prove) a fundamental characteristic, as is the history of what jobs they have worked in. ] |