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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 10261c,2e71cf22768a124d X-Google-Attributes: gid10261c,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: The Amorphous Mass Subject: Re: next "big" language?? (disagree) Date: 1996/06/05 Message-ID: X-Deja-AN: 158636980 distribution: world references: <4p3k86$k4a@btmpjg.god.bel.alcatel.be> x-sender: robinson@black.weeg.uiowa.edu content-type: TEXT/PLAIN; charset=US-ASCII organization: University of Iowa, Iowa City, IA, USA mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.misc,comp.lang.c,comp.lang.pascal.misc Date: 1996-06-05T00:00:00+00:00 List-Id: On 5 Jun 1996, Ian Ward wrote: > On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote > --- > > > Those of us lone programmers who put speed and space at a premimum > > are willing to go hunting for stray pointers as a necessary cost > > of using a small, fast language. > > If I hear the implication that Ada is not fast just one more time > 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. :-) [re: "reusable code modules"] > > They're also one of the great dangers of the future. I keep a fairly > > substantial library of useful little functions that I've written over the > > 3 or so years I've been programming in C, and their reusability is greatly > > enhanced by the fact that I can tweak the code a little for particular > > applications. By contrast, at work we're trying to get this souped-up OO > > development platform to talk to an edits package written in C (the > > development platform is written in C++) and we keep getting errors > > concerning classes that we didn't know existed, whose purpose is completely > > unknown to us and undocumented, apropos problems that no amount of > > debugging has revealed sofar, because the code and the interface is at > > such a high level that the programmer only has the most notional control > > over what's actually happening. The classes will doubtless get used > > over and over again, but too much of our development time consists of > > waiting for support to call back. > > I'm thus wary of the idea of "code reuse." Not dismissive, just wary. > > The first question, James, I must ask is, is C++ your idea of an alternative? 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. I was thinking more along the lines of Mercury or Miranda or even Delphi, or (arguably) the resurgent PL/I. This is not to say that C++ is not useful for development, but the programmer has to be very thorough and very careful. > You say that Ada is not the only big, safe, feature laden, industrial- > strength language, (mischien) but then go on to give actual real > evidence as why C++ isn't. You assume that I am comparing Ada to C++. I am not. Given the choice as a dev. platform, I would probably pick Ada. I was comparing Ada to C, which is an apples and oranges comparison, with the explicit intent of demonstrating that sometimes you want an apple and sometimes you want an orange. :-) > 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? --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 */