From: "Alderson, Paul A." <Paul.Alderson@avistainc.com>
Subject: Look what I caught! was re:Ada paper critic
Date: Mon, 17 Jun 2002 12:35:48 -0500
Date: 2002-06-17T12:35:48-05:00 [thread overview]
Message-ID: <mailman.1024335422.31035.comp.lang.ada@ada.eu.org> (raw)
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.
C.) Ignore the standard and use use.
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.
If you use the fully specified name the reviewer can immediately
start searching the Ada code for that package (not file).
Now why did the company forbid "use"? Probably because it leads
to possible errors and isn't being precise...which is why they chose
Ada.
For those who couldn't get past the case, change the case to your
liking and continue.
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. Secondly ...wait I'll
make this point #3...
3.) Many people in this group seem to have a "write the code
and never look at it again" attitude. Writing code is only
one small aspect of the software development life cycle.
When you start looking at verification on Level-A systems
the use of certain software structures becomes iffy. For
example if you don't use ANY global variables (You know
because global variables are bad!) Then one must insure
that the stack will not collide with heap or code space.
If you take some time to think about this, you'll not be
so quick to say globals are bad!
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. And
again the code will be viewed many more times than written
(hopefully anyway). So when reviewing and testing this
code one will see that:
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. Needlessly.... Yes its only a few seconds....
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!
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.
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. The language does allow
for pure ranges, but yet keeps its feet firmly tied to the
hardware. Again how many instances do you really need
the full range of an int? Rarely...so why did the type
ever exist? 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.
The point here is that Ada is still tied to the hardware.
The pre-emptive counter point here was knowing people
would say they didn't have to use integers but are just
an option. 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).
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. Yes...other languages are even worse.
The danger here is that MANY people believe Ada is
really good at preventing bad things from happening.
It prevents some of them, but really if redesigned could
be leaps and bounds better.
(Yes I'm criticizing Ada in a vacuum...I don't care how
evil other languages are...I want it right dammit!)
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...
and yes while no other language offers as much, we have a long way
to go.
7.) Ada isn't taught anymore people...Its a general statement.
Your suppose to get the idea behind it. For those
who are 100% literal. Ada is no longer being taught at
as many institutes of learning as it had been. In fact
very few places continue to teach it. If trends continue
as they are, Ada will be completely phased out from public
learning institutions in the near future. Latin is a dead
language, yet it is taught. Is it really "taught" however?
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. 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...
9.) Gimpel Lint - Very good piece of software for C programmers.
Style, pointer checks, type checks....
Can't do run-time checks - which if your language is
designed right from the start you don't need....
(No main stream language exists YET that will allow
static analysis, thus eliminating run time checks.)
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)
next reply other threads:[~2002-06-17 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-17 17:35 Alderson, Paul A. [this message]
2002-06-17 18:31 ` Look what I caught! was re:Ada paper critic Darren New
2002-06-17 21:40 ` Vinzent Hoefler
2002-06-17 23:14 ` Darren New
2002-06-18 14:49 ` Hyman Rosen
2002-06-18 22:36 ` Vinzent Hoefler
2002-06-18 13:28 ` Marin David Condic
2002-06-24 19:17 ` Vinzent Hoefler
2002-06-18 19:16 ` Kevin Cline
2002-06-18 22:36 ` Vinzent Hoefler
2002-06-19 14:29 ` Wes Groleau
2002-06-19 16:59 ` Darren New
2002-06-19 17:48 ` Wes Groleau
2002-06-19 17:56 ` Darren New
2002-06-19 17:11 ` Frank J. Lhota
2002-06-19 19:31 ` Robert A Duff
2002-06-19 20:02 ` Hyman Rosen
2002-09-24 15:23 ` Matthew Heaney
2002-06-19 19:37 ` Robert A Duff
2002-06-19 13:52 ` Ted Dennison
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox