But wait. I think we need more complex types than are even allowed. When we actually compute something on the back of an envelope, we have been taught to carry all the units along explicitly, but when we set it up for a really stupid computer to do it automatically, we are forbidden, almost always, from even mentioning the units. This seems quite reckless to me.
Why does it seem that no one cares that there are vast flaws in virtually every project? Why is no one concerned, in the most modern development techniques, with testing, step by step, what actually works with the people who have to use the resulting system? Why does the whole industry accept as normal that most large projects fail, and even those said to have succeeded are filled with cruft that never gets used? Aside from W. Edwards Deming, Tom Gilb, Jef Raskin, and me, I guess everybody thinks that as long as they get paid, everything is fine. Richard On Fri, Oct 8, 2010 at 7:57 PM, Casey Ransberger <[email protected]>wrote: > I think "type" is a foundationaly bad idea. What matters is that the object > in question can respond intelligently to the message you're passing it. Or > at least, that's what I think right now, anyway. It seems like type > specification (and as such, early binding) have a very limited real use in > the domain of really-actually-for-real-and-seriously mission critical > systems, like those that guide missiles or passenger planes. > > In the large though, it really seems like specifying type is a lot of > ceremonial overhead if what you need to say is really just some arguments to > some function, or pass a message to some object. > > It might help if you explained what you meant by type. If you're thinking > of using "class" as type, I expect you'll fail. Asking for an object's class > in any case where one is not employing reflection to implement a tool for > programmers reduces the power of polymorphism in your program. It can be > argued easily that you shouldn't have to worry about type: you should be > able to expect that your method's argument is something which sensibly > implements a protocol that includes the message you're sending it. If you're > talking about primitive types, e.g. a hardware integer/word, or a string as > a series of bytes, then I suppose the conversation is different, right? > Because if we're talking about machine primitives, we really aren't talking > about objects at all, are we? > > On Oct 8, 2010, at 3:23 PM, spir <[email protected]> wrote: > > > On Fri, 8 Oct 2010 19:51:32 +0200 > > Waldemar Kornewald <[email protected]> wrote: > > > >> Hi, > >> > >> On Fri, Oct 8, 2010 at 5:20 PM, Paul D. Fernhout > >> <[email protected]> wrote: > >>> The PataPata project (by me) attempted to bring some ideas for Squeak > and > >>> Self to Python about five years ago. A post mortem critique on it from > four > >>> years ago: > >>> "PataPata critique: the good, the bad, the ugly" > >>> http://patapata.sourceforge.net/critique.html > >> > >> In that critique you basically say that prototypes *maybe* aren't > >> better than classes, after all. On the other hand, it seems like most > >> problems with prototypes weren't related to prototypes per se, but the > >> (ugly?) implementation in Jython which isn't a real prototype-based > >> language. So, did you have a fundamental problem with prototypes or > >> was it more about your particular implementation? > > > > I have played with the design (& half-way) of a toy prototyped-based > language and ended thinking there is some semantic flaw in this paradigm. > Namely, models we need to express in programs constantly hold the notions of > "kinds" of similar elements. Which often are held in collections; > collections and types play together in my sense. In other words, type is a > fondamental modelling concept that should be a core feature of any language. > > Indeed, there are many ways to realise it concretely. In my sense, the > notion of prototype (at least in the sense of self or Io) is too weak and > vague. For instance, cloning does not help much in practice: programmers > constantly reinvent constructors, or even separated object creation and > initialisation. Having such features is conceptually helpful, practically > secure, but most importantly brings it as "common wealth" of the programming > community (a decisive argument for builtin features, imo). > > Conversely, class-based language miss the notion, freedom to create, of > individual objects. forcing the programmer to create a class for a chess > board is simply stupid for me, and worse: semantically wrong. This prevents > the program to mirror the model. > > > >> Bye, > >> Waldemar > > > > > > Denis > > -- -- -- -- -- -- -- > > vit esse estrany ☣ > > > > spir.wikidot.com > > > > > > _______________________________________________ > > fonc mailing list > > [email protected] > > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > -- Richard Karpinski, Nitpicker extraordinaire 148 Sequoia Circle, Santa Rosa, CA 95401 Home: 707-546-6760 http://nitpicker.pbwiki.com/ http://CureCancerNow.WetPaint.com/<http://curecancernow.wetpaint.com/> Mission: to bring known cancer cures to a clinic near you, soon.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
