From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,9d58048b8113c00f X-Google-Attributes: gidf891f,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public X-Google-Thread: 10261c,2e71cf22768a124d X-Google-Attributes: gid10261c,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: ian@rsd.bel.alcatel.be (Ian Ward) Subject: Re: next "big" language?? (disagree) Date: 1996/06/07 Message-ID: <4p8nbt$3rj@btmpjg.god.bel.alcatel.be> X-Deja-AN: 158943238 distribution: world organization: Alcatel Bell Telephone reply-to: ian@rsd.bel.alcatel.be newsgroups: comp.lang.ada,comp.lang.misc,comp.lang.c,comp.lang.pascal.misc Date: 1996-06-07T00:00:00+00:00 List-Id: On June the ?sixth?, James Robinson wrote : > On 5 Jun 1996, Ian Ward wrote: > > On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote snip.... > > I think I will scream. > I was not implying that Ada executables are slow (although your > complaint is understandable -- I should have said "a language that > allows for a small, fast environment"). I was trying to say that the > environment and compile times for Ada would be big and/or slow, for the > simple reason that the language offers a great deal more support than C > does. As I have said in this thread I'm sure Ada is just as subject to > efficient compiling and optimizing techniques as other languages are, and > almost as fast as C. :-) Of course, the time taken for the compiler to spot syntactic errors is much less than that which a person takes. In fact, if the langauge syntax is cunningly enough design such that different constructs look sufficiently different, it will also wipe out a large proportion of unwitting semantic (&functional) errors as well. This feature more than makes up for compile times, which is one of the reasons languages such as the Pascal family is twice as quick in terms of man hours to get down to any arbitrary level of bugs. (It stands to reason, if one does not have to worry about the syntax, one has more time to work on the semantics.) > [re: "reusable code modules"] > > > They're also one of the great dangers of the future. I keep a fairly snip... > > I'm thus wary of the idea of "code reuse." Not dismissive, just wary. snip... > No. C++ is great fun to play with but I don't consider it an > attractive alternative because it's far too easy to shoot yourself in > the foot, and because it's a write-your-own-language language that can > make reading or modifying someone else's code a nontrivial exercize. Concur. Like Mother, like Daughter. > > Software reuse is not the problem, and neither is Object oriented > > design. In this case of yours, it appears that it is a bad implementation > > of C++ that seems to be behind it. Of course, at this point we can go > > into how it came to be a bad implementation. > It's a perfectly fine, even ingenious implementation.If anything, it's > a sterling example of a well-written C++ application. When you > work within its parameters it runs beautifully, even distributed across > platforms running 4 different OSs. When you try to stretch its > capabilities (which is what we're doing) then you start to see all the > stuff that's supposed to be 'transparent.' That was my point, and that > _is_ a problem with software reuse, and a risk with OO design. > > I am not going to though, I will simply say that if I were to end up > > using software, where in the background, side effects of it were > > detrimentally affecting mine, that I could not even find, then I WOULD > > use something else. Bruce Lee said, "If it works, use it." It clearly > > is not working. Anything else must be better? Why are you not trying > > to convince your boss to use something else? Anything else? > Frankly, I can't think of anything better. We looked all over, and > this is the best there was. Remember, the problem is not that it fails > to work as advertized, and it is not that it is unstable or buggy or > unpredictable. The problem is that if you try to do something a little > bit different from what it's designed for it stops being friendly and > starts being obscure. By contrast, if I want one of my C libraries > to do something a bit different, I just go in and modify them. > Does my argument make more sense to you now? Yes, I was miles off track with what I thought you were talking about. It is at this point that I have to concur with what you are saying, there are two different types of software reuse. 1. Reusing software, to do the same job for which it was designed. - Such as I/O utilities, this usually works well, provided the interfaces are well defined. 2. Trying to reuse software for different purpose than it was originally defined. - This can be tragic, if one has no ability to examine the works, then one has no idea what side effects may present themselves; in the worst cases of this it may be better to write one's own. - If, of course, one has the sources, it may better to modify them to suit one's own needs, after all, they were not designed to do the job for which they will be used, disk space is cheap, and one will have at the end two pieces of software which gives a better chance in the future that when a component is needed, then there will be a closer match, in a library, somewhere. It is at this point, modification, where code readability comes into its own, trying to modify write only languages can be an exercise in frustration to say the least. Of course, programmer time is the least expensive component of software engineering.... or did I dream it? > --James Robinson (robinson@cs.uiowa.edu -or- james-robinson@uiowa.edu) > /* Indeed, C++ is a bit of an oddball of a language ... given the way that * > * it requires private parts to be visible. This increases the strength of * > * coupling dramatically... -- Dr. Rich Artym */ Best regards, Ian. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be It's "burgled" Mr. President, not burglarised.