[ I think this is off topic, but what the hell, this is the USENET after all ]
In article <3170514704312...@naggum.no>, Erik Naggum wrote: > Not the first time around. I'm subtracting some in the precision > department due to the visibly limited English skills of the author.
>| Dream On! Do you imply that you are able to write bug free code?
> I find comments scornful of quality indicative of incompetence
And you can judge quality? Or even I? How? Who?
> bordering on the criminal. When repeated, it was no accident.
Indeed. But you totally missed my point and clearly it was not my incompetence on English. More, it was you being ready to fire at me, since you disliked my comment.
> People who are _unable_ to write bug-free code should wake up and > smell the coffee and do the world a favor by just abstaining from > writing any more buggy code. We have enough people who write buggy > code who are at least _able_ to write bug-free code...
I am uncapable of many things. Writing code is not one of them. And of couse when I write code that is more than say 100 lines, then it is probable that bugs will be in it. Even if I stick to procedures. After all, we all are humans.
Yes, I wrote ``Java programmers are bug free'' and this was to be taken as a humorous comment. s/Java/the-language-you-like/g and you will get my point.
...But instead you chose to flame the ``visibly limited in English skills'' Greek who dared to post to your newsgroup, expressing in a harsh way something you do not like.
Using the same logic as you, I might be able to conclude that assuming twice that I cannot write code is no mistake: You too cannot write code, although you think you can.
But I am wrong, ain't I?
So please, lets end it here and read something usefull to both of us. -- ${talks}
In article <3170518698876...@naggum.no>, Erik Naggum wrote: > "USENET" is what each one of us makes of it. Judging by your > comments, I don't want what you want to make of it, so end the > meta-discussion if you want me to respond to you. If not: EOD.
If it makes your ego feel better, I appologize for not standing up to your standards. And I appologize to the group as a whole.
Boy, you are surely a tough man to live with (if you behave the same IRL).
* Yiorgos Adamopoulos | [ I think this is off topic, but what the hell, this is the USENET | after all ]
"USENET" is what each one of us makes of it. Judging by your comments, I don't want what you want to make of it, so end the meta-discussion if you want me to respond to you. If not: EOD.
#:Erik -- If this is not what you expected, please alter your expectations.
> | Dream On! Do you imply that you are able to write bug free code?
> People who are _unable_ to write bug-free code should wake up and > smell the coffee and do the world a favor by just abstaining from > writing any more buggy code. [...]
If that were to happen, it would leave the world with approximately zero programmers. Honestly Erik, you sound like you have never written a program of any realistic size. Whenever you enter the real world you will be in for a very big shock.
"PCM" <p...@netspace.net.au> writes: > If that were to happen, it would leave the world with approximately zero > programmers. Honestly Erik, you sound like you have never written a program > of any realistic size. Whenever you enter the real world you will be in for > a very big shock.
let me first assure you that Eriks software, from what I've heard of it, works and solves quite hard problems in the very real business world.
But otherwise, I agree with you - I don't like the word "bug-free". Maybe it would be better to talk about more and less bug-infested code. As someone (who was that?) once put it: "A completely bug-free program is either uninteresting or outdated". -- (espen)
> > | Dream On! Do you imply that you are able to write bug free code?
I didn't write this. Yiorgos Adamopoulos did. And I'm actually very sympathetic to Eric Naggum's point about scorn toward quality, although I think he overreacted. The complexity of the task of programming and the already established low standards of quality should not lull us into expecting software to be buggy. (And I don't believe for a second that Yiorgos' use of "programmers" in place of "programs" was an intentional attempt at humor.)
> > People who are _unable_ to write bug-free code should wake up and > > smell the coffee and do the world a favor by just abstaining from > > writing any more buggy code. [...]
> If that were to happen, it would leave the world with approximately zero > programmers. Honestly Erik, you sound like you have never written a program > of any realistic size. Whenever you enter the real world you will be in for > a very big shock.
Thant Tessman <th...@acm.org> writes: > The complexity of the task of programming and > the already established low standards of quality should not lull us into > expecting software to be buggy.
I couldn't agree more, but I still think a little care should be taken before using the word "bug-free", although a certain rich man from Washington State dares to use it when speaking about software that others know is notoriously bug-infested.
>> If that were to happen, it would leave the world with approximately zero >> programmers. Honestly Erik, you sound like you have never written a program >> of any realistic size. Whenever you enter the real world you will be in for >> a very big shock.
>let me first assure you that Eriks software, from what I've heard of it, >works and solves quite hard problems in the very real business world.
>But otherwise, I agree with you - I don't like the word "bug-free". >Maybe it would be better to talk about more and less bug-infested code. >As someone (who was that?) once put it: "A completely bug-free program >is either uninteresting or outdated".
And many would consider outdated a bug.
-- Kenneth P. Turvey <kt-...@SprocketShop.com> http://www.tranquility.net/~kturvey/resume/resume.html -------------------------------------------------------- The optimist thinks this is the best of all possible worlds. The pessimist fears it is true. -- Robert Oppenheimer
* "PCM" <p...@netspace.net.au> | If that were to happen, it would leave the world with approximately | zero programmers. Honestly Erik, you sound like you have never | written a program of any realistic size. Whenever you enter the | real world you will be in for a very big shock.
How come you guys who obviously want everybody to be _unable_ to write bug-free code of _any_ complexity all have to attack _me_?
Could there be a relation between the inability to write code that is actually _correct_ and the ability to _think_ and _argue_? Nah.
#:Erik, disgusted -- If this is not what you expected, please alter your expectations.
pete@nowhere writes: > In article <87hfav1oan....@quadium.net>, vsync says...
> >Anyway, I think Java is a great language for certain things. However, > >the features that can make it simple and fairly easy to use, such as > >single inheritance only, clearly defined namespaces, and a strict > >security model, can also make it very difficult to use for more > >complex programs.
> Wow, the guys talks as if he knows what he is talking about. > Show an example where single inhertitance only can make it difficult > to write those compelex applications you are talking about?
Well, for example, mixins. Suppose you want to have a piece of behaviour which is exhibited by a range of different objects with different anticedents.
In Java, you define an interface, and every class that implements the interface must have a complete copy of the code required to implement that interface - even if the code is actually identical.
With multiple inheritence, you just inherit from the mixin class. You don't have to reinvent the wheel, and you substantially reduce the probability of subtle inconsistencies of behaviour.
Simon Brooke <si...@jasmine.org.uk> writes: > In Java, you define an interface, and every class that implements the > interface must have a complete copy of the code required to implement > that interface - even if the code is actually identical.
> With multiple inheritence, you just inherit from the mixin class. You > don't have to reinvent the wheel, and you substantially reduce the > probability of subtle inconsistencies of behaviour.
Yes, but then you're stuck with MI in your language, and if you believe that MI is a misfeature, then you haven't really made progress.
You can get the benefits of MI with the simplicity of SI if you redesign your language slightly. See a proposal that shows what this design would be in the Java context.
You can use a similar style of programming in PLT Scheme, but you don't get all the same name access benefits. To illustrate why this form of mixins is especially powerful in the context of a good module system, see
Shriram Krishnamurthi <shri...@cs.rice.edu> writes: > Yes, but then you're stuck with MI in your language, and if you > believe that MI is a misfeature, then you haven't really made > progress.
I'm curious about why you thing multiple inheritance is a misfeature. I looked at the first few pages of the paper (the TR version) and didn't find much of an argument against MI, other than the fact that the C++ version was not taught much. In as much as I consider MI hopelessly braindead (a sentiment I believe is shared by many Common Lispers), this hardly seems like an overwhelming argument.
Common Lisp has well-defined semantics for class combination and method dispatch, as well as a MI analogy to Java's super.method() invocation.
-- Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
On 22 Jun 2000 10:08:30 -0500, Shriram Krishnamurthi <shri...@cs.rice.edu> wrote:
>Yes, but then you're stuck with MI in your language, and if you >believe that MI is a misfeature, then you haven't really made >progress.
If you believe that MI is a misfeature... why not just avoid using it? I don't really understand the aversion to MI. It does make things somewhat more complicated if it is used without thought, but I miss it in Java when nothing else is really as satisfactory.
It seems like a lot of Java programming is working out ways to mimic MI without really using it.
-- Kenneth P. Turvey <kt-...@SprocketShop.com> http://www.tranquility.net/~kturvey/resume/resume.html -------------------------------------------------------- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
> > Yes, but then you're stuck with MI in your language, and if you > > believe that MI is a misfeature, then you haven't really made > > progress.
> I'm curious about why you thing multiple inheritance is a misfeature. I > looked at the first few pages of the paper (the TR version) and didn't > find much of an argument against MI, other than the fact that the C++ > version was not taught much. In as much as I consider MI hopelessly > braindead (a sentiment I believe is shared by many Common Lispers), this
^ | | in C++
> hardly seems like an overwhelming argument.
> Common Lisp has well-defined semantics for class combination and method > dispatch, as well as a MI analogy to Java's super.method() invocation.
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
> Well, for example, mixins. Suppose you want to have a piece of > behaviour which is exhibited by a range of different objects with > different anticedents.
> In Java, you define an interface, and every class that implements the > interface must have a complete copy of the code required to implement > that interface - even if the code is actually identical.
> With multiple inheritence, you just inherit from the mixin class. You > don't have to reinvent the wheel, and you substantially reduce the > probability of subtle inconsistencies of behaviour.
If the code is really identical, couldn't you bundle it up into something like:
-------------------------------------------------------------------------- Bernhard Pfahringer Dept. of Computer Science, University of Waikato G1.25, 838 4041 bernh...@cs.waikato.ac.nz --------------------------------------------------------------------------
Bernhard Pfahringer <bernh...@cs.waikato.ac.nz> writes: > Simon Brooke <si...@jasmine.org.uk> writes:
> > Well, for example, mixins. Suppose you want to have a piece of > > behaviour which is exhibited by a range of different objects with > > different anticedents.
> > In Java, you define an interface, and every class that implements the > > interface must have a complete copy of the code required to implement > > that interface - even if the code is actually identical.
> > With multiple inheritence, you just inherit from the mixin class. You > > don't have to reinvent the wheel, and you substantially reduce the > > probability of subtle inconsistencies of behaviour.
> If the code is really identical, couldn't you bundle it > up into something like:
Of course you can work around missing MI, but the point of much of OO was to express certain concepts more concisely, so this seems to defeat this intent pretty cleverly.
Also note that the behaviour of the mixin might be distributed across a large number of generic functions, which will get you a certain explosion of functions and stub methods. Furthermore the added behaviour for a certain GF might want to invoke call-next-method (or might indeed want to be a :before/:after or :around method), in which case your approach would have to use macros, which aren't available in Java. But there is still cut'n'paste, which always comes to the rescue of languages that are not capable of directly expressing what you want to express... ;)
In languages where MI has properly useful semantics (i.e. not the brain dead C++ semantics), I have used MI without problems, but with big success, since it often is the most natural way to express implementation mixins:
Take for example the case of resources in an HTTP server: They implement a protocol which includes GFs that determine whether an access is allowed, perform the access, etc. In this case you might have classes that implement the access itself, like e.g.
- static-resource which statically returns a pre-computed entity, or - dynamic-resource which calls out to a user specified function to compute the entity to be returned, or - automagic-resource which is a user-defined resource class which does even more intricate application-specific processing to compute a response entity.
OTOH you might have classes that perform certain auxilliary tasks:
- base-authentication-mixin to provide for basic authentication via a fixed user/password - ldap-authentication-mixin to provide for basic authentication via an LDAP user database - standard-logging-mixin to provide for standardized logging of requests - performance-logging-mixin to provide for optimized logging of requests - session-leader-mixin and sessioned-resource-mixin to provide for the tracking of user sessions and corresponding session-data across requests (e.g. via cookies, or other means).
Now it seems both natural and elegant to create the final resource classes by mixing together a certain number of the above classes.
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
>> c++ programmers think they know more and smarter than any one else, >> becuase their language is more complicated, they think this is good >> to have more complicated mess to work with, they think using a simpler >> language means one is not as smart as they are.
>You're posting to a Scheme group. Around here, arguing that Java is >better than C++ is like arguing that grasshoppers taste better than tree >bark.
>-thant
Grasshoppers definately taste better ... particularly when fried 8^)
In article <3170605039717...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>* "PCM" <p...@netspace.net.au> >| If that were to happen, it would leave the world with approximately >| zero programmers. Honestly Erik, you sound like you have never >| written a program of any realistic size. Whenever you enter the >| real world you will be in for a very big shock.
Um, I think Erik is in the real world.
> How come you guys who obviously want everybody to be _unable_ to > write bug-free code of _any_ complexity all have to attack _me_?
The obvious answer:
I, at least, cannot write bug-free code of significant complexity. This is not for lack of trying, tools, or formal techniques. Everybody who has told me whether they write bug-free code or not either admits to being unable to write bug-free code, appears to me to be completely unreliable, is named Erik, or some combination of the first two (the last category may become intermingled, should I meet another Erik).
This means that, when you imply that a competent programmer should be able to write bug-free code, you imply that a whole lot of us out here are incompetent. Naturally, some people perceive that as an attack and react accordingly.
> Could there be a relation between the inability to write code that > is actually _correct_ and the ability to _think_ and _argue_? Nah.
You are correct with the "Nah". Since approximately everybody I know is unable to write bug-free code*, there would be no statistical validity in any correlation based on that.
*Actually, everybody except one guy in Norway who write large programs, apparently of high quality, and claims he writes them bug-free.
In article <871z1o3egq....@orion.dent.isdn.cs.tu-berlin.de>, Pierre R. Mai <p...@acm.org> wrote:
>In languages where MI has properly useful semantics (i.e. not the >brain dead C++ semantics), I have used MI without problems, but with >big success, since it often is the most natural way to express >implementation mixins:
FWIW, Metrowerks built an application framework in C++ for the Macintosh that depends heavily on multiple inheritance to use mixins. It is very successful, and lots of Mac applications are built on it. Any attempt not to use MI in Powerplant would either make things more difficult to use, or push lots of stuff into a towering class hierarchy that would include a whole lot of unused functionality for any given object.
Not that MI is implemented without flaw in C++, but it is useful, for some of the same reasons it is in Lisp.
In article <394E987B.620A5...@ncgr.org>, David Hanley <d...@ncgr.org> wrote:
> Listen. YOU don't understand the example. If you put a instance > of class 'carrier' inside of class 'car' how are you going to pass > that object to a function which wants a 'carrier?' You're going > to have to have abstract interfaces for 'car' and 'carrier' and > implements all those interfaces in your encapsulating class. Then > if you add a method to the base, you've got to find all those > proxies and manually extend them, instead of doing no work > at all in the MI case.
He. And you don't even have C's sorry excuse for a macro system.. [Of course not having such trash is comparatively "right"]
Well, maybe all the hard work of the Dylan folks will eventually be useful after all :->
Someone I could not identify to Erik (after the thread lost track):
> Dream On! Do you imply that you are able to write bug free code?
Throughout the course of the last few years Erik has published countless code snippets (among other things), and as far as I looked at them and remember, only one or two of them had any bugs. It's a good ratio, given that most snippets weren't trivial at all, and they demonstrated an expressive and compact coding style.
In article <3954141E.7075A...@fisec.com>, Robert Monfera wrote: >I found the pun from Yiorgos quite funny.
>Someone I could not identify to Erik (after the thread lost track):
>> Dream On! Do you imply that you are able to write bug free code?
>Throughout the course of the last few years Erik has published countless >code snippets (among other things), and as far as I looked at them and >remember, only one or two of them had any bugs. It's a good ratio, >given that most snippets weren't trivial at all, and they demonstrated >an expressive and compact coding style.
Whereas I never published any. Correct, since he has proven his competence. But I replied to the one (obviously Erik) that said something along the lines (leave us who write bug free code alone).
We are all humans, and as such, prone to error no matter what. We are prone to error, even if all our prior work is bugless. That is why I found this statement annoying and I replied in the harsh way that I did (not that Erik's answers were smoother).
-- I've got a problem solver and his name is revolver --Dr. Dre
mike555@NOSPAM wrote: > In the real world, and I have been programming for zillion years, I > have never ever once had a need for MI of implementation.
I have seen quite a few unimaginative programmers in the real world(tm), and you fight hard to demonstrate you are one of them. (Or maybe you don't need OO at all to write device drivers or whatever, but then why would you care to make comments on MI.)
To give you an example: maybe you have a class hierarchy of financial instruments covering deposits, loans and derivatives. There are specific ways to calculate their balances. Another classification specifies if you implement caching for balance calculations. It is only beneficial if the response time gains outweigh caching costs, so you would only mix in the cached-class for instrument classes whose balance computation is time-consuming. If you want your variable rate based deposits cached, you can successfully do so via multiple inheritance. It would result in compact code with a clear distinction between financial logic and performance optimization scheme.
Similarly, a financial instrument class may be the subclass of several other classes, like investment, discount or derivative. Your savings account would inherit from investment, interest-earning and variable-rate classes.
You should also discover multiple argument dispatch and other mechanisms that keep your code expressive.
Java now simply does not provide abstraction tools like MI, which are essential for non-trivial application development. This is not surprising, given the roots of the Java/Oak language (embedded code for appliances).
