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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e95e8407f65e1cfb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-17 14:40:37 PST From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: Look what I caught! was re:Ada paper critic Date: Mon, 17 Jun 2002 23:40:19 +0200 Organization: JeLlyFish software References: X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 62.202.185.126 Message-ID: <3d0e5750_2@news.bluewin.ch> X-Trace: news.bluewin.ch 1024350032 62.202.185.126 (17 Jun 2002 23:40:32 +0200) X-Complaints-To: abuse@bluewin.ch Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!news-han1.dfn.de!news-stu1.dfn.de!news.belwue.de!news.tesion.net!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.bluewin.ch!not-for-mail Xref: archiver1.google.com comp.lang.ada:26187 Date: 2002-06-17T23:40:19+02:00 List-Id: "Alderson, Paul A." wrote: >Here's what I caught on my troll: :-) >1.) People who missed the point (maybe intentionally) of the big > chain of package names you end up with in some Ada packages. > >The point here is if your company has a policy against using >"uses" in their code, then you have to: > > A.) Use a renames > B.) Use the fully specified name. Like in SPARK. > C.) Ignore the standard and use use. And get "use"d to be fired. ;) >Now if you use a rename, then you introduce more work for the >code reviewer (remember code is written once and looked at many >times). Yes it is a small diversion, which only extends the >search a few seconds further. Still, it would depend on *how* you do it. >2.) People assumed I was the one that had the problems with using > global variables (even though the globals referred to were > actually package variables) and etc. > >If one lives in the Ada industry long enough you will find that >much of the embedded code written with Ada uses package variables >extensively. Why? Mostly because pushing and popping things >on and off stacks is time consuming. That thing hasn't anything to do with Ada. If you are forced to use global variables because of efficiency requirements, you'll be forced to use them in *any* language. >3.) Many people in this group seem to have a "write the code > and never look at it again" attitude. I got another impression from most Ada program(mer)s I've seen. My personal experience shows me that the *hurry, hurry fast, if it works, I'll never look at it again* approach is more wide-spread in other languages. > Writing code is only > one small aspect of the software development life cycle. About 10%, if not even less, I'd say. > This brings up my discussion on why not being able to tell > an array from a function is a problem. From the writing > of the code its nice to be able to change your mind on > the implementation of a function to array. But then again > why are you changing something like this? This is an > indication that proper design was not followed. No. A design you have can be implemented in at least 10 different ways. The design says very little about its implementation. > x := a.y(z); -- Purposefully descriptive names. > And we know z's range and if we knew it was an array > we could easily set values within "a.y". Unfortunately > we can't tell this with this language and have to > again perform the ole search of the code to find out what > a.y is. Well, hmm. Surely I miss something, but how can "y" be a function here? > Needlessly.... Yes its only a few seconds.... Well, considering how many of those few seconds I already hang around with C++ code to see how this or that function is declared and if it changes something, this sounds funny. In C++ I can even overload the [] operator, this changes the whole world. > I concede that replacing a function with and array would be > nice on the development end. Unfortunately when you do this > and the verification occurs (level - A) now all those tests > magically break and strangely enough the code didn't change! Well, try to place a simple "virtual" in C++ code at appropriate declarations of a class and strangely see, that although the code has not changed at all, it completely f***s up. In Ada the semantic does not change, if you switch the declaration from an array to a function or vice versa unless you do very nasty things. > Now what would have been a simple search and replace by the > developer is now a big search and destroy mission by the > verification team. Well, when does verification occur in the *normal* case? I'd guess at the end of a development phase. And I'd guess, the verification must occur again, if some of the code was changed. >4.) Some missed the point I was making about how Ada was not > designed to be purely a high level language. The point > that Ada uses integers is that an integer (no matter what > the size) is a hardware notion. Not really. Just that 'range is implementation defined. It says "nothing" about the hardware. > The language does allow > for pure ranges, but yet keeps its feet firmly tied to the > hardware. Oh well. What other kind of integers can you imagine? We use programing languages to program computers and computers *are* still hardware. And if I imagine a machine which only knows floating point registers, I'd guess, the meaning of Integer would be the same still although the hardware representation might be totally different. > Again how many instances do you really need > the full range of an int? Rarely...so why did the type > ever exist? For type compatibility reasons, I'd guess. Ada knows *sub*types. So you need a base type at least. Well, you could say, ok, so let the programmer define the base type, but that also means, he has to implement the arithmetic operations on that type. And how to do that if you don't have a type on where those operations are defined? > My guess is because at the time of its design > it was too far reaching to simply declare ranges and > making the compiler figure out the appropriate size. Well, the compiler normally does this. If the standard integer size is 16-bit and you declare a range of 0 .. 100_000 the compiler will probably implement is as a 32-bit value (or maybe 24 bits or so...). In the case of a range of 0 .. 10_000 the compiler will *probably* implement is as the most effective hardware abstraction - in 16 bit. But nothing stops the compiler from implementing it in 14 bits. So it is really not any view on the hardware in the language in that case. The compiler simply assures you that your range will fit in the chosen representation. With "for ... use" you are still able to override this (normally hidden) behaviour if you *have to* rely on a specific implementation. Still this declaration then should work on another machine with another default integer size in the *same* way. So I can't see no really hardware specific thing here. Perhaps one: Ada might rely on the machine to actually have integers at all. So it's certainly the wrong language for quantum probability computers or so... ;-) > The point here is that Ada is still tied to the hardware. That's simply wrong. Yes, the *compiler* normally tries to use the most effective representation on the specific hardware. And no, this hasn't anything to do with Ada being *tied* to hardware. > The pre-emptive counter point here was knowing people > would say they didn't have to use integers but are just > an option. Well, IMO you shouldn't use pure Integers without a good reason. They aren't good for anything other than deriving types *from* it. :-) What's wrong with specifying a range or even a modular type? > Which is why I said people didn't need to > use pointers in C either, yet it is scrutinized for its > pointer problem (Rightfully so). Well, look at the C runtime library and tell me, how many functions you could use without using pointers? Not to mention the nasty "array" thing... >5.) Yet another argument was that the language can help keep > bad programmers from doing bad things. I must agree > 100% on this and simply say that Ada doesn't do nearly > enough to do this. To this one I might agree. Although I'm still sometimes struggling with the compiler what's right. Damn, I *know*, I can assign this type of variable to another one, why is the compiler preventing me from doing this? ;-) So actually it does even prevent me from doing the right things if I don't express them the right way. I like that, no wonder, why this language is called after a woman. ;-) > (Yes I'm criticizing Ada in a vacuum...I don't care how > evil other languages are...I want it right dammit!) That's simple: *Do* it right. This is possible in either language, yes. The good thing with Ada is that the possibility to do it right has a greater probability. :-) >6.) Because I criticize the language people immediately think >that I'm saying another language is "better" than Ada. The original >poster simply asked for the bad things about Ada. I posted them... You can do bad things in Ada, yes. But some of the things you said, can't be prevented in any (procedurale) language. And some were simply wrong. >7.) Ada isn't taught anymore people...Its a general statement. But even with this stated generality: It's wrong. >8.) People seem to miss the point that no matter how great the > language is, if it has crappy compilers, crappy debugging > and a crappy IDE's then its going to be a interesting blip > on the software radar screen that fades out fast. Well, gcc has no IDE at all and I would state that it is one of the most widely used compilers in the world. And if the rumours are right, gcc3.1 does surprisingly include Ada95 (again?). > The > language itself can help with easy development of these > tools. Was it Ada's fault for the lack of these tools or > other issues? No idea... Well, I can't see the lack of tools. Might be there are less tools than for C or Java or $WHATEVER but in the end it simply boils down to using *one* tool. Actually *two*: an editor and a compiler. :-) >9.) Gimpel Lint - Very good piece of software for C programmers. Well, so it seems you need a *post*-processor to verify you did the right thing. And my question: how widely used is *that* one? > Can't do run-time checks - which if your language is > designed right from the start you don't need.... No. Its not a long time ago (was it in c.l.a.?) I read that C arrays are one element more on the right and left side because this becomes handy in using some algorithms that intentionally might get out of bounds. Such a design should make the code easier to write. Well, do you call that *right*? I would not. > (No main stream language exists YET that will allow > static analysis, thus eliminating run time checks.) It might be not possible at all, if you need data from a given environment or user out of the computer's small world. >10.) Just because I like having lists of ten! 8) > >And you thought you were SOOOOO RIGHT. Turns out you were only MOSTLY >RIGHT! SO THERE! 8) Well, I don't *think* I'm right. I *know* I am. 8-) ;-) Vinzent.