* Re: code partitioning (was: Future with Ada)
@ 2002-03-13 6:09 Christoph Grein
2002-03-13 11:50 ` Larry Kilgallen
2002-03-13 14:11 ` Wes Groleau
0 siblings, 2 replies; 15+ messages in thread
From: Christoph Grein @ 2002-03-13 6:09 UTC (permalink / raw)
> From: Wes Groleau <wesgroleau@despammed.com>
> case Animal is
snip
> end case (Animal); -- yet another way of
> -- naming a case statement
Nonono
case [expression] is
...
end case;
So how about
case Some*weird*and/long+expression is
...
end case Some*weird*and/long+expression;
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-13 6:09 code partitioning (was: Future with Ada) Christoph Grein
@ 2002-03-13 11:50 ` Larry Kilgallen
2002-03-13 14:15 ` Wes Groleau
` (2 more replies)
2002-03-13 14:11 ` Wes Groleau
1 sibling, 3 replies; 15+ messages in thread
From: Larry Kilgallen @ 2002-03-13 11:50 UTC (permalink / raw)
In article <mailman.1015999862.11331.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.com> writes:
>> From: Wes Groleau <wesgroleau@despammed.com>
>> case Animal is
> snip
>> end case (Animal); -- yet another way of
>> -- naming a case statement
>
> Nonono
>
> case [expression] is
> ...
> end case;
>
> So how about
>
> case Some*weird*and/long+expression is
> ...
> end case Some*weird*and/long+expression;
I prefer:
case Some*weird*and/long+expression is
...
end case; -- Some*weird*and/long+expression
since it requires no vendor action and I have resigned myself to
the fact that successful programming can never be entirely devoid
of self-discipline.
I have found that so long as _every_ end case has such a comment,
I am unlikely to get them interchanged.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-13 11:50 ` Larry Kilgallen
@ 2002-03-13 14:15 ` Wes Groleau
2002-03-13 15:21 ` Kevin Cline
2002-03-13 15:24 ` Pascal Obry
2 siblings, 0 replies; 15+ messages in thread
From: Wes Groleau @ 2002-03-13 14:15 UTC (permalink / raw)
> I prefer:
>
> case Some*weird*and/long+expression is
> ...
> end case; -- Some*weird*and/long+expression
>
> since it requires no vendor action and I have resigned myself to
> the fact that successful programming can never be entirely devoid
> of self-discipline.
That's the argument C fans use for rejecting Ada.
We should check everything ourselves, we should never
tolerate a compiler that checks things for us.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-13 11:50 ` Larry Kilgallen
2002-03-13 14:15 ` Wes Groleau
@ 2002-03-13 15:21 ` Kevin Cline
2002-03-13 15:24 ` Pascal Obry
2 siblings, 0 replies; 15+ messages in thread
From: Kevin Cline @ 2002-03-13 15:21 UTC (permalink / raw)
Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<DPweFozQbILl@eisner.encompasserve.org>...
> In article <mailman.1015999862.11331.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.com> writes:
> >> From: Wes Groleau <wesgroleau@despammed.com>
> >> case Animal is
> snip
> >> end case (Animal); -- yet another way of
> >> -- naming a case statement
> >
> > Nonono
> >
> > case [expression] is
> > ...
> > end case;
> >
> > So how about
> >
> > case Some*weird*and/long+expression is
> > ...
> > end case Some*weird*and/long+expression;
>
> I prefer:
>
> case Some*weird*and/long+expression is
> ...
> end case; -- Some*weird*and/long+expression
>
> since it requires no vendor action and I have resigned myself to
> the fact that successful programming can never be entirely devoid
> of self-discipline.
>
> I have found that so long as _every_ end case has such a comment,
> I am unlikely to get them interchanged.
I prefer
meaningful_name := some * weird * and / long + expression;
case meaningful_name is
end case; -- meaningful_name
Introducing local variables can improve readability.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-13 11:50 ` Larry Kilgallen
2002-03-13 14:15 ` Wes Groleau
2002-03-13 15:21 ` Kevin Cline
@ 2002-03-13 15:24 ` Pascal Obry
2 siblings, 0 replies; 15+ messages in thread
From: Pascal Obry @ 2002-03-13 15:24 UTC (permalink / raw)
Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> I have found that so long as _every_ end case has such a comment,
> I am unlikely to get them interchanged.
"You have found" and "your are unlikely"... what about a project with 20 or
more developpers ? I really think that rules MUST be checked otherwise they
will be violated at some point... speaking from experiences :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-13 6:09 code partitioning (was: Future with Ada) Christoph Grein
2002-03-13 11:50 ` Larry Kilgallen
@ 2002-03-13 14:11 ` Wes Groleau
1 sibling, 0 replies; 15+ messages in thread
From: Wes Groleau @ 2002-03-13 14:11 UTC (permalink / raw)
> case [expression] is
> ...
> end case;
>
> So how about
>
> case Some*weird*and/long+expression is
> ...
> end case Some*weird*and/long+expression;
Exactly. "Animal" is just a wierd and short expression.
See my other post for more details.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
@ 2002-03-14 5:41 Christoph Grein
2002-03-16 15:46 ` Jacob Sparre Andersen
2002-03-17 13:19 ` Nick Williams
0 siblings, 2 replies; 15+ messages in thread
From: Christoph Grein @ 2002-03-14 5:41 UTC (permalink / raw)
> I prefer
>
> meaningful_name := some * weird * and / long + expression;
> case meaningful_name is
> end case; -- meaningful_name
>
> Introducing local variables can improve readability.
This is not the point. Of course this is sensible. My proper point against this proposal is:
Since a case statement has an expression syntactically, the expression would
have to be repeated at the end
case expression is
..
end case expression;
and this is against the spirit of repeating only a short identifier (the
defining_designator etc.) at the end.
Thus the proper way would be a {case_}statement_identifier:
[{case_}statement_identifier:]
case expression is
...
end case [{case_}identifier];
[The curly braces stand here for what is printed in italics in the RM.]
This is the only form I would like to see as a future syntax enhancement. We
already have this for loops and blocks, so why not for ifs and cases (and
selects).
We do not need weird new syntax rules.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-14 5:41 Christoph Grein
@ 2002-03-16 15:46 ` Jacob Sparre Andersen
2002-03-17 13:19 ` Nick Williams
1 sibling, 0 replies; 15+ messages in thread
From: Jacob Sparre Andersen @ 2002-03-16 15:46 UTC (permalink / raw)
Christoph Grein wrote:
> Thus the proper way would be a {case_}statement_identifier:
>
> [{case_}statement_identifier:]
> case expression is
> ...
> end case [{case_}identifier];
Agreed. And this would actually be a nice way to clarify
code a bit. On the other hand, should if statements also
have this possibility?
I would like to be allowed to include the name of the
defined record type after "end record". I am aware that
record definitions, unlike case statements can not be
nested, so this is not nearly as important.
> We do not need weird new syntax rules.
Generally not.
Jacob
--
"The current state of knowledge can be summarised thus:
In the beginning, there was nothing, which exploded."
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-14 5:41 Christoph Grein
2002-03-16 15:46 ` Jacob Sparre Andersen
@ 2002-03-17 13:19 ` Nick Williams
2002-03-17 19:41 ` Robert A Duff
1 sibling, 1 reply; 15+ messages in thread
From: Nick Williams @ 2002-03-17 13:19 UTC (permalink / raw)
Well, the reason for having labels on loops is fairly clear; to allow an
exit statement to exit from a loop other than the innermost enclosing one.
So there's obviously a concrete 'why' for loops - its not as clear for
blocks (although I can see that it might be nice to have a construct which
allows a new declarative region to be nameable).
On the other hand, allowing this for if and case statements sounds a lot
more like simple syntactic sugar. I don't really think it's sufficient to
say 'language construct A has this additional syntax; so why not B?', rather
the question should be 'why does language construct A have this additional
syntax, and does language construct B benefit from it in a consistent way?'.
Cheers,
Nick.
"Christoph Grein" <christoph.grein@eurocopter.com> wrote in message
news:mailman.1016084642.17231.comp.lang.ada@ada.eu.org...
> This is the only form I would like to see as a future syntax enhancement.
We
> already have this for loops and blocks, so why not for ifs and cases (and
> selects).
>
> We do not need weird new syntax rules.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-17 13:19 ` Nick Williams
@ 2002-03-17 19:41 ` Robert A Duff
0 siblings, 0 replies; 15+ messages in thread
From: Robert A Duff @ 2002-03-17 19:41 UTC (permalink / raw)
"Nick Williams" <nickw@acm.org> writes:
> Well, the reason for having labels on loops is fairly clear; to allow an
> exit statement to exit from a loop other than the innermost enclosing one.
> So there's obviously a concrete 'why' for loops - its not as clear for
> blocks (although I can see that it might be nice to have a construct which
> allows a new declarative region to be nameable).
I think the reason blocks can have names is so you can use them in
expanded names -- eg Block_Name.Object_In_Block. Hardly essential, but
it seems like a nice property. I think the 1983 RM has a note pointing
out that if you name all your blocks, you can always refer to anything
via a full expanded name (assuming Standard is not hidden). This
implies that JDI thought this was a nice property for the language to
have.
I never put a name on a loop, unless there is an exit that refers to
that name. And such an exit is always nested inside another loop.
That is, the existence of the name lets the reader know that something
unusual is going on (an exit from a more-nested loop) -- assuming the
reader knows I'm using this style, of course.
The visibility rules for these things are weird, especially if you
compare them to loop parameters. The compiler has to jump through some
annoying hoops. For example:
procedure P is
begin
for X in 1..10 loop
X: -- Illegal; loop name X is not visible here.
while ... loop
null;
end loop X;
end loop;
end P;
- Bob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Future with Ada
@ 2001-11-09 17:59 Michal Nowak
2002-02-26 4:12 ` Jim Rogers
0 siblings, 1 reply; 15+ messages in thread
From: Michal Nowak @ 2001-11-09 17:59 UTC (permalink / raw)
To: comp.lang.ada usegroup->mailing list gateway
Some month ago I discovered Ada and found it a greatest programming
language among the common programming laguages taught at universities
(Pascal, C++, Java and others). I started play with Ada a bit and
experienced all benfits of using Ada (everyone here knows what they
are, so no need to write it).
During reading some posts here and looking through some job services
I found that Ada is not so widely used as C++ or Java nowadays.
I serioulsy think about catching a job in Ada after I finish my studies
(I'm on last year now). If to work as a programmer I would like to
write in Ada. I looked through some job offers at Ada Information
Clearinghouse. I did not browsed all, because I'm on dial-up connection,
but lots of them required at least 1-2 experience. I haven't found any
company in my country (Poland) who may need an Ada prorammer (especially
inexperianced newbie), so I cannot gain experience here.
It comes time to write my M. Sc. diploma and I am on a crossroads now.
I may use Java or Ada for it. I talked with my leading promotor and
told him, that I will prefer to use Ada. After explaining him all benefits
from using Ada he agreed with me. Considering facts given above I came to
two scenarios:
1. Use Ada for my M.Sc. diploma. This will allow me to gain some additional
experience in Ada (I know it does not count, but it is better to use it here
than nowhere).
2. Use Java or C++ for my diploma and use Ada for self-needed programs or
for pleasure. I will get more Java C++ experience here which will allow
me to catch better job at least my country.
It will be not commercial project, by it will be not typical student project
also. Doing it well from the beginnig to the end will help me to gain
some experience.
Of course the better scenario for me is the first one. Here comes my final
questions. Is there a possibility for inexperienced Ada programmer to
find a job? I suspect that there is, but where or how to seek it? Is
there a possibility to find somewhere such offers (for example job
services, which allow browsing offers sorted by years of experience
required)?
Thank you for your time,
regards,
Mike
-----------------------------------------
____|
\%/ |~~\
O |
o>> Mike Nowak |
T |
/ > vinnie@inetia.pl |
http://www.geocities.com/vinnie14pl _|__
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
@ 2002-02-26 4:12 ` Jim Rogers
2002-02-27 17:51 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 15+ messages in thread
From: Jim Rogers @ 2002-02-26 4:12 UTC (permalink / raw)
Michael Card wrote:
> I was wondering why it is perceived as undesirable to train new
> programmers in Ada? Certainly hiring an experienced S/W engineer who
> has only done C++ or Java, for example, would not require a significant
> additional investment to train them in Ada? If teh language really
> offers benefits, wouldn't those benefits more than offset the
> relatively small cost of buying 2-3 weeks of intense Ada training for
> the programmers?
I agree. I have found good C++ programmers to be trainable.
I watched one pick up the basics of Ada in about 2 weeks with the
help of "Ada as a Second Language". He was using the Aonix
compiler and wanted to use the latest Visual Studio for his IDE.
No problem. He simply customized Visual Studio and proceded to
happily program in Ada. He was amused to discover that the Aonix
compiler worked better with the Microsoft debugger than did
Visual C++. He found he was able to display more detailed information
about arrays when using Aonix.
Jim Rogers
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-02-26 4:12 ` Jim Rogers
@ 2002-02-27 17:51 ` Warren W. Gay VE3WWG
2002-02-28 17:45 ` Michal Nowak
0 siblings, 1 reply; 15+ messages in thread
From: Warren W. Gay VE3WWG @ 2002-02-27 17:51 UTC (permalink / raw)
Jim Rogers wrote:
> Michael Card wrote:
>> I was wondering why it is perceived as undesirable to train new
>> programmers in Ada? Certainly hiring an experienced S/W engineer who
>> has only done C++ or Java, for example, would not require a significant
>> additional investment to train them in Ada? If teh language really
>> offers benefits, wouldn't those benefits more than offset the
>> relatively small cost of buying 2-3 weeks of intense Ada training for
>> the programmers?
>
> I agree. I have found good C++ programmers to be trainable.
> I watched one pick up the basics of Ada in about 2 weeks with the
> help of "Ada as a Second Language". ...
While I can only speak about my own experience here (ie. learning
Ada95), I would suggest that picking up the language in about 2 weeks
is about right.. but...
I found it took a while longer before I could properly
design applications from scratch in Ada95. This is because the
entire framework is considerably different than C/C++ from a
number of viewpoints, most notably from a visibility point of
view, not to mention standard packages et. al.
Ada's package design, its restrictions on visibility etc., can
lead to a lot of head-scratching to a C/C++ designer.
In C/C++ I was always able to obtain pointers to something,
declare a new friend function, whatever. Ada requires you to
more carefully think about all these relationships before hand,
or you wind up moving/rewriting parts of your application
later as you get those "you can't get there from here" messages
from your favourite Ada compiler.
In this regard, I think somewhere between 3 months to a year
is required in order to gain the sufficient level of experience
to get it nearly right the first time. Even then, I believe
that the new Ada programmer still gets burned on what can
and cannot be done (in a given way) with generics for example.
The language is large enough that it takes time to gain enough
experience with all of these elements. For example, just the
"use" clause is hotly debated as to how and when
it should be used. I am still tinkering with how I want to
use "use", even though some advise against using it at all.
A new user of it is likely to abuse it, only to learn from
that lesson later on. ;-)
So while I agree that an experienced programmer can quickly
embrace Ada and *maintain* existing code, I do believe you
want someone with a bit more experience if he is designing
major subsystems from scratch. Otherwise, you'll have to
allow time for that programmer more time to learn from
his mistakes ;-)
Just my $0.02 worth.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-02-27 17:51 ` Warren W. Gay VE3WWG
@ 2002-02-28 17:45 ` Michal Nowak
2002-02-28 18:53 ` Hyman Rosen
0 siblings, 1 reply; 15+ messages in thread
From: Michal Nowak @ 2002-02-28 17:45 UTC (permalink / raw)
On 2002-02-27 at 17:51 Warren W. Gay VE3WWG wrote:
>While I can only speak about my own experience here (ie. learning
>Ada95), I would suggest that picking up the language in about 2 weeks
>is about right.. but...
>
>I found it took a while longer before I could properly
>design applications from scratch in Ada95. This is because the
>entire framework is considerably different than C/C++ from a
>number of viewpoints, most notably from a visibility point of
>view, not to mention standard packages et. al.
[cut the rest]
I fully agree with you. I had similiar experiences when I started
Ada (although to pick up the basics I had several hours - just one
lecture - which was in fact enough (but I really mean the basics)).
Paradoxically learning Ada came much easier to me than for example Java.
I think, that was because there is so much difference between Ada and C++.
This maybe similiar to comparing colours - it is harder to distinguish
white and yellow than white and blue (for example). Java has differrent
concept than C++, but uses C++ notation, what (I suppose) made me often
confused. It also caused, that I wrote C++ like code in Java, what rather
hasn't good effects ;-) (not to mention mixing C nad C++)
Another issue when learning a programming language is if the learner
likes it. Maybe that is why learning Ada came rather easily to me.
Even if language is hard to learn and somebody likes it, he will
learn it easily, he will not learn it properly, no matter how easy the
language is, if he dislikes it. Some of my university colleagues did
not wanted to learn another, a bit different language, that they already
knew. No matter how good features Ada has to offer, it seemed impossible
to convince them to learn Ada. "Ada is bad, I don't like it" - and that
was all I heard. In this cases, even if they had a whole year to spent, it
won't have any positive results.
Just my remarks,
Mike
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-02-28 17:45 ` Michal Nowak
@ 2002-02-28 18:53 ` Hyman Rosen
2002-03-01 17:26 ` Jeffrey Carter
0 siblings, 1 reply; 15+ messages in thread
From: Hyman Rosen @ 2002-02-28 18:53 UTC (permalink / raw)
Michal Nowak wrote:
> Another issue when learning a programming language is if the learner
> likes it. Maybe that is why learning Ada came rather easily to me.
I know I have a visceral dislike for the Pascal-style languages.
Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
way when I look at them. It's hard for me to appreciate that Ada
is intended to be reader-friendly when my brain is going "yuck"
whenever I look at some code.
Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
thing :-)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-02-28 18:53 ` Hyman Rosen
@ 2002-03-01 17:26 ` Jeffrey Carter
2002-03-03 8:26 ` Hyman Rosen
0 siblings, 1 reply; 15+ messages in thread
From: Jeffrey Carter @ 2002-03-01 17:26 UTC (permalink / raw)
Hyman Rosen wrote:
>
> I know I have a visceral dislike for the Pascal-style languages.
> Pascal, Modula-N, Oberon, Ada - they all just rub me the wrong
> way when I look at them. It's hard for me to appreciate that Ada
> is intended to be reader-friendly when my brain is going "yuck"
> whenever I look at some code.
>
> Hmm. Wirth, Ichbiah, you - maybe it's some sort of Europe/America
> thing :-)
No, it's primarily the difference between coders and software engineers.
--
Jeffrey Carter
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-01 17:26 ` Jeffrey Carter
@ 2002-03-03 8:26 ` Hyman Rosen
2002-03-03 17:47 ` Chad R. Meiners
0 siblings, 1 reply; 15+ messages in thread
From: Hyman Rosen @ 2002-03-03 8:26 UTC (permalink / raw)
Jeffrey Carter wrote:
> No, it's primarily the difference between coders and software engineers.
You mean because software engineers value conciseness and economy
of expression, they prefer braces, while coders, who get paid by
the line, prefer the wordier languages and begin/end?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-03 8:26 ` Hyman Rosen
@ 2002-03-03 17:47 ` Chad R. Meiners
2002-03-04 16:30 ` Hyman Rosen
0 siblings, 1 reply; 15+ messages in thread
From: Chad R. Meiners @ 2002-03-03 17:47 UTC (permalink / raw)
Ah, there is that evil word, "concise". Often thought of as a holy
objective by computer scientist and mathematician alike. The danger here is
that people often equate conciseness with clarity. This of course is an
incorrect assumption. Concise expressions, theorems, definitions, etc are
valued since because they allow you to refresh your memory quickly. The
problem is that they do not make good teaching material without the
accompaniment of an introduction and explanation. The "curly braced
languages are concise hence better" argument is malformed at best and
perverse at worst since the mathematical symbols curly braced languages
adopted are meant for a completely different type of communication.
I know you most likely meant to include a smiley in your statement, Hyman,
but if you didn't perhaps the above will establish why many have preferences
opposite of yours.
-CRM
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C81DF1F.9000503@mail.com...
> Jeffrey Carter wrote:
> > No, it's primarily the difference between coders and software engineers.
>
> You mean because software engineers value conciseness and economy
> of expression, they prefer braces, while coders, who get paid by
> the line, prefer the wordier languages and begin/end?
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-03 17:47 ` Chad R. Meiners
@ 2002-03-04 16:30 ` Hyman Rosen
2002-03-05 1:41 ` Richard Riehle
0 siblings, 1 reply; 15+ messages in thread
From: Hyman Rosen @ 2002-03-04 16:30 UTC (permalink / raw)
Chad R. Meiners wrote:
> The problem is that they do not make good teaching material without the
> accompaniment of an introduction and explanation.
I find it difficult to believe that { } needs an introduction and
explanation that begin/end or if/end do not. On the other hand,
braces are light and airy and nicely set off and separate pieces
of program text which are more wordy, guiding the eye towards seeing
the structure of the code.
It's a religious issue, and a matter of taste. How many times, after
all, has this topic been discussed in the past?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-04 16:30 ` Hyman Rosen
@ 2002-03-05 1:41 ` Richard Riehle
2002-03-05 21:35 ` Wes Groleau
0 siblings, 1 reply; 15+ messages in thread
From: Richard Riehle @ 2002-03-05 1:41 UTC (permalink / raw)
Hyman Rosen wrote:
> Chad R. Meiners wrote:
> > The problem is that they do not make good teaching material without the
> > accompaniment of an introduction and explanation.
>
> I find it difficult to believe that { } needs an introduction and
> explanation that begin/end or if/end do not. On the other hand,
> braces are light and airy and nicely set off and separate pieces
> of program text which are more wordy, guiding the eye towards seeing
> the structure of the code.
>
> It's a religious issue, and a matter of taste. How many times, after
> all, has this topic been discussed in the past?
Actually, curly braces would not be so bad if the C/C++/Java compilers
were able to detect a name at the end of them. For example,
LabelName: {
source code
} LabelName
One reason I prefer Ada to the C family of languages is that the compiler
allows me to document my code blocks with names and actually checks
that the block I started corresponds to the name with which I ended it. Of
course, this is probably a religious issue and has very little to recommend
it
as a model for self-documenting code.
Richard Riehle
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-05 1:41 ` Richard Riehle
@ 2002-03-05 21:35 ` Wes Groleau
2002-03-05 22:04 ` Marin David Condic
0 siblings, 1 reply; 15+ messages in thread
From: Wes Groleau @ 2002-03-05 21:35 UTC (permalink / raw)
> Actually, curly braces would not be so bad if the C/C++/Java compilers
> were able to detect a name at the end of them. ....
>
> One reason I prefer Ada to the C family of languages is that the compiler
> allows me to document my code blocks with names and actually checks
> that the block I started corresponds to the name with which I ended it. Of
> course, this is probably a religious issue and has very little to recommend
One minor thing I've always thought odd about Ada is the
inconsistency where some ends require a name, some
forbid it, and some don't care.
Also, some demand a keyword match (end record) and some don't.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-05 21:35 ` Wes Groleau
@ 2002-03-05 22:04 ` Marin David Condic
2002-03-06 16:36 ` Georg Bauhaus
0 siblings, 1 reply; 15+ messages in thread
From: Marin David Condic @ 2002-03-05 22:04 UTC (permalink / raw)
To toss in yet another stink-bomb... :-)
Why not allow the labeling of all structures that have an "end"? You can
name a loop with a label and it helps find which "end" you mean if you've
got nested loops. Same with declare blocks. Why not for "if" statements and
"case" statements? Maybe also records - but the record already has a name
and aren't nested so it would probably look inconsistent.
It probably wouldn't amount to a major syntax change & might be mildly
useful. But not having thought about it thoroughly, there may be issues.
(What would you do if you had lots of "elsif" parts?) Anyway, its just an
idea to think about....
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C853A04.34826F39@despammed.com...
>
> One minor thing I've always thought odd about Ada is the
> inconsistency where some ends require a name, some
> forbid it, and some don't care.
>
> Also, some demand a keyword match (end record) and some don't.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-05 22:04 ` Marin David Condic
@ 2002-03-06 16:36 ` Georg Bauhaus
2002-03-06 17:27 ` Marin David Condic
0 siblings, 1 reply; 15+ messages in thread
From: Georg Bauhaus @ 2002-03-06 16:36 UTC (permalink / raw)
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
:
: Why not for "if" statements
Hmm, are you suggesting that you feel comfortable with if
statements that span more than say 12 lines and/or are nested
to some unspeakable level of say 3 or more? :-)
- georg
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-06 16:36 ` Georg Bauhaus
@ 2002-03-06 17:27 ` Marin David Condic
2002-03-07 16:04 ` Georg Bauhaus
0 siblings, 1 reply; 15+ messages in thread
From: Marin David Condic @ 2002-03-06 17:27 UTC (permalink / raw)
"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a65gj5$n73$1@a1-hrz.uni-duisburg.de...
> Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
> :
> : Why not for "if" statements
>
> Hmm, are you suggesting that you feel comfortable with if
> statements that span more than say 12 lines and/or are nested
> to some unspeakable level of say 3 or more? :-)
>
Why, "yes". What's your point? :-) Sometimes a big case or if is a perfectly
good way of reflecting what's going on. (Think of lots of "when" or "elsif"
parts, for example.) Things should be made as simple as possible, but no
simpler.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-06 17:27 ` Marin David Condic
@ 2002-03-07 16:04 ` Georg Bauhaus
2002-03-07 16:42 ` Marin David Condic
0 siblings, 1 reply; 15+ messages in thread
From: Georg Bauhaus @ 2002-03-07 16:04 UTC (permalink / raw)
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
: Sometimes a big case or if is a perfectly
: good way of reflecting what's going on. (Think of lots of "when" or "elsif"
: parts, for example.) Things should be made as simple as possible, but no
: simpler.
yes, sometimes, highest speed dfa in inner loops, say?.
my point was that this need not be reflected in "big" if, in a sense.
With inlined subprograms, tag magic, ... you can do a lot to reduce
the "textual length" of an if or case statement, without much or any
loss in performance. At the expense of increased expressiveness,
sometimes :-)
I'm saying this remembering a 500 lines program consisting of one
procedure, nested ifs and some state variables named state1 etc,
no comment, no layout, produced by a human.
Even at only 500 lines this wasn't exactely a pleasure, and it
turned out that the program worked by accident.
- georg
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-07 16:04 ` Georg Bauhaus
@ 2002-03-07 16:42 ` Marin David Condic
2002-03-11 20:02 ` Wes Groleau
0 siblings, 1 reply; 15+ messages in thread
From: Marin David Condic @ 2002-03-07 16:42 UTC (permalink / raw)
Oh... I probably wouldn't do it out of concern for speed. I'd do it if it
seemed that constructing subprograms to squeeze something into some
arbitrary line or nesting limit was going to make the code less intuitively
obvious to the casual observer. Say you have an enumeration with 20 values
and a case statement handling it with 10 statements per enumeral. That's 200
lines + overhead, right? Would you create something like:
case (var) is
when First_Enum =>
Do_Ten_Lines_Of_Stuff ; -- I wouldn't generally object to this...
maybe
when others =>
Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
end case ;
procedure Do_Another_Case_In_A_Procedure (var : in var_type) is
begin
case (var) is
when Second_Enum =>
Do_Ten_Lines_Of_Stuff ;
when others =>
Do_Yet_Another_Case_In_A_Procedure (var) ;
end case ;
end Do_Another_Case_In_A_Procedure ;
And so on, and so on, and so on... Just to avoid a 200 line case statement
where and "end case Identifier;" might help you see what you were ending? I
guess I've written enough code where I've exceeded a screen's worth of lines
or had two or three levels of nesting and thought it would be useful to
identify what the "end" parts came from. If that's bad code by some
definition of "bad" then I guess I'll just have to live with the stigma.
(Bad Programmer! No Cookie! :-)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a6831k$3ls$1@a1-hrz.uni-duisburg.de...
>
> yes, sometimes, highest speed dfa in inner loops, say?.
> my point was that this need not be reflected in "big" if, in a sense.
> With inlined subprograms, tag magic, ... you can do a lot to reduce
> the "textual length" of an if or case statement, without much or any
> loss in performance. At the expense of increased expressiveness,
> sometimes :-)
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-07 16:42 ` Marin David Condic
@ 2002-03-11 20:02 ` Wes Groleau
2002-03-11 23:56 ` Marin David Condic
0 siblings, 1 reply; 15+ messages in thread
From: Wes Groleau @ 2002-03-11 20:02 UTC (permalink / raw)
> when others =>
> Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to this.
I would, too. But I would probably NOT object to
when others =>
Default_Var_Handling (voo);
Matter of fact, whether by nesting or by calling,
I would object to a case choice on a variable that
dispatches to a case on the same variable.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Future with Ada
2002-03-11 20:02 ` Wes Groleau
@ 2002-03-11 23:56 ` Marin David Condic
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
0 siblings, 1 reply; 15+ messages in thread
From: Marin David Condic @ 2002-03-11 23:56 UTC (permalink / raw)
I *think* we're on the same wavelength. I was trying to say I don't object
to something like:
case (Var) is
when Enum_01 =>
Something_01 ;
when Enum_02 =>
Something_02 ;
when Enum_03 =>
Something_03 ;
when Enum_04 =>
Something_04 ;
when Enum_05 =>
Something_05 ;
when Enum_06 =>
Something_06 ;
when Enum_etc =>
Something_etc ;
when others =>
Something_Others ;
end case ;
And I would find attempts to go through gyrations to make this shorter just
to fit some kind of "Don't make a case statement longer than twentysomething
lines" rule a bit silly. My original illustration was to show a
stupid-code-trick needed to bust up the case statement to make it shorter.
Can you think of a way to make a case statement like this shorter that
doesn't look silly? (Assuming you've got 20 or so enumerals for some
reason - op-codes maybe? Lexical elements of some language you're parsing?
Reserved words in Ada? Not hard to imagine a fairly long list of enumerals,
eh?)
Once that case statement gets longer than a screen, I'd find it handy to
have a name at the end of it reminding me of what I'm ending. Of course, one
could always encase the case in a procedure that did nothing more than
provide the name for the check - and I'd think that was a good thing. But
would you try to make that procedure into three procedures if the case was
75 lines long just to shorten it up into 25 line segments?
Maybe I've run into similar things with if statements or nesting of
structures and didn't want to start making subprograms that had no
identifiable function other than to encapsulate some arbitrary chunk of code
& avoid some arbitrary nesting or line length limit. If I can write a
subprogram name like: "Is_Device_Ready" or
"Check_Employee_Payroll_Deductions" then I'm more than fine about taking
that nested if or long stream of code and hiding it in there. If I have a
hard time writing a good name for it and start resorting to
"Run_Some_Long_Block_Of_Code_To_Avoid_The_Nesting_Police", then I know I'm
better off leaving it the way it was. :-) (It reminds me of stunts pulled to
get subroutines under some arbitrary line limit - divide the routine you
have by the number of lines in the arbitrary limit and just find convenient
places to cut along those breaks. One 400 line subroutine becomes four 100
line routines with a "main" to call each in sequence, eh? :-)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C8D0D70.BB09F3DA@despammed.com...
>
> > when others =>
> > Do_Another_Case_In_A_Procedure (var) ; -- I *would* object to
this.
>
> I would, too. But I would probably NOT object to
>
> when others =>
> Default_Var_Handling (voo);
>
> Matter of fact, whether by nesting or by calling,
> I would object to a case choice on a variable that
> dispatches to a case on the same variable.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-11 23:56 ` Marin David Condic
@ 2002-03-12 16:47 ` Wes Groleau
2002-03-12 17:56 ` Marin David Condic
0 siblings, 1 reply; 15+ messages in thread
From: Wes Groleau @ 2002-03-12 16:47 UTC (permalink / raw)
> I *think* we're on the same wavelength.
Yes, I agree. No splitting things up except on
"logical" boundaries so that the parts can have
meaningful names.
> And I would find attempts to go through gyrations to make this shorter just
> to fit some kind of "Don't make a case statement longer than twentysomething
> lines" rule a bit silly. My original illustration was to show a
Without actually endorsing this, here's a sort of
borderline situation:
case Animal is
when Horse | Tiger | Elephant | Whale | Mouse |
Dog | Gorilla | Platypus | Koala | Dingo =>
Classify_Mammal (Animal);
when Lizard | Snake | Alligator | Tortoise =>
Classify_Reptile (Animal);
......
when others =>
Classify_Some_Really_Wierd_Thing (Animal);
-- gratuitous demo of
end case (Animal); -- yet another way of
-- naming a case statement
-- to bring it back to the original topic
-- now that I've updated the subject line :-)
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
@ 2002-03-12 17:56 ` Marin David Condic
2002-03-14 15:27 ` John R. Strohm
0 siblings, 1 reply; 15+ messages in thread
From: Marin David Condic @ 2002-03-12 17:56 UTC (permalink / raw)
Well, yea, I could see that - even breaking it up into a "when mammal ...
when others..." case in something like this. It kind of goes to my original
point: You ought to keep ifs and cases short and as unnested as may make
sense for the problem at hand, but don't go crazy.
You've got to use some judgment, thinking "Shortness and non-nestedness are
good things taken from The Book Of Devoutly To Be Desired Results, but lets
not forget that the spirit of the law is to make things readable and
comprehensible" If statements nest for three or four levels or span several
dozen lines, yet remain comprehensible (being a natural reflection of the
problem at hand) and breaking them up would require unnatural acts of
contortion, then don't fight it. Programming is often an "art" that requires
an "artistic eye" rather than an exact science... much like other writing
and communication skills.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C8E3110.F36F2DC8@despammed.com...
>
> Without actually endorsing this, here's a sort of
> borderline situation:
>
> case Animal is
>
> when Horse | Tiger | Elephant | Whale | Mouse |
> Dog | Gorilla | Platypus | Koala | Dingo =>
>
> Classify_Mammal (Animal);
>
> when Lizard | Snake | Alligator | Tortoise =>
>
> Classify_Reptile (Animal);
>
> ......
>
> when others =>
>
> Classify_Some_Really_Wierd_Thing (Animal);
>
> -- gratuitous demo of
> end case (Animal); -- yet another way of
> -- naming a case statement
>
> -- to bring it back to the original topic
> -- now that I've updated the subject line :-)
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-12 17:56 ` Marin David Condic
@ 2002-03-14 15:27 ` John R. Strohm
2002-03-15 14:15 ` Ted Dennison
0 siblings, 1 reply; 15+ messages in thread
From: John R. Strohm @ 2002-03-14 15:27 UTC (permalink / raw)
Well, yes, in theory that is all true.
In practice, in thirty years of slinging bits, both as student and as
professional, I have seen exactly one procedure that NEEDED to be more than
one printer page of code and that COULDN'T easily be factored down any
further. (For the record, it was the photon torpedo routine in the old
Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)
"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a6lfgd$gj6$1@nh.pace.co.uk...
> Well, yea, I could see that - even breaking it up into a "when mammal ...
> when others..." case in something like this. It kind of goes to my
original
> point: You ought to keep ifs and cases short and as unnested as may make
> sense for the problem at hand, but don't go crazy.
>
> You've got to use some judgment, thinking "Shortness and non-nestedness
are
> good things taken from The Book Of Devoutly To Be Desired Results, but
lets
> not forget that the spirit of the law is to make things readable and
> comprehensible" If statements nest for three or four levels or span
several
> dozen lines, yet remain comprehensible (being a natural reflection of the
> problem at hand) and breaking them up would require unnatural acts of
> contortion, then don't fight it. Programming is often an "art" that
requires
> an "artistic eye" rather than an exact science... much like other writing
> and communication skills.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas www.pacemicro.com
> Enabling the digital revolution
> e-Mail: marin.condic@pacemicro.com
> Web: http://www.mcondic.com/
>
>
> "Wes Groleau" <wesgroleau@despammed.com> wrote in message
> news:3C8E3110.F36F2DC8@despammed.com...
> >
> > Without actually endorsing this, here's a sort of
> > borderline situation:
> >
> > case Animal is
> >
> > when Horse | Tiger | Elephant | Whale | Mouse |
> > Dog | Gorilla | Platypus | Koala | Dingo =>
> >
> > Classify_Mammal (Animal);
> >
> > when Lizard | Snake | Alligator | Tortoise =>
> >
> > Classify_Reptile (Animal);
> >
> > ......
> >
> > when others =>
> >
> > Classify_Some_Really_Wierd_Thing (Animal);
> >
> > -- gratuitous demo of
> > end case (Animal); -- yet another way of
> > -- naming a case statement
> >
> > -- to bring it back to the original topic
> > -- now that I've updated the subject line :-)
> >
>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-14 15:27 ` John R. Strohm
@ 2002-03-15 14:15 ` Ted Dennison
2002-03-16 10:37 ` Kevin Cline
0 siblings, 1 reply; 15+ messages in thread
From: Ted Dennison @ 2002-03-15 14:15 UTC (permalink / raw)
"John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> In practice, in thirty years of slinging bits, both as student and as
> professional, I have seen exactly one procedure that NEEDED to be more than
> one printer page of code and that COULDN'T easily be factored down any
> further. (For the record, it was the photon torpedo routine in the old
> Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)
I once had a command decoding and dispatching routine that had a >50
branch case statement. Not only was it really big, but it completly
blew by our MacCabe complexity target (somewhere around 4 or 5 I
belive). There was no cleaning that baby up.
But you are right that this is a rare exception.
--
T.E.D.
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/dennison/Ted/TED.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: code partitioning (was: Future with Ada)
2002-03-15 14:15 ` Ted Dennison
@ 2002-03-16 10:37 ` Kevin Cline
0 siblings, 0 replies; 15+ messages in thread
From: Kevin Cline @ 2002-03-16 10:37 UTC (permalink / raw)
dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0203150615.4282773b@posting.google.com>...
> "John R. Strohm" <strohm@airmail.net> wrote in message news:<9F6CC4A4404878F6.5B5BBAA9D5258CDF.AA7E4D06ED4F8781@lp.airnews.net>...
> > In practice, in thirty years of slinging bits, both as student and as
> > professional, I have seen exactly one procedure that NEEDED to be more than
> > one printer page of code and that COULDN'T easily be factored down any
> > further. (For the record, it was the photon torpedo routine in the old
> > Matuszek-Reynolds-McGehearty-Cohen STARTRK game.)
>
> I once had a command decoding and dispatching routine that had a >50
> branch case statement. Not only was it really big, but it completly
> blew by our MacCabe complexity target (somewhere around 4 or 5 I
> belive). There was no cleaning that baby up.
I have done this a few times in different ways:
* Use yacc or a similar tool to generate the code. I did this when
I wrote an Ada program to parse Ada-83 package specifications.
* Convert the code to data. During initialization,
create a tree with nodes labeled by commands and subcommands,
with functions at the leaves.
* Embed the Tcl interpreter into the application.
This gives the users a lot scripting functionality for free.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-03-17 19:41 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-13 6:09 code partitioning (was: Future with Ada) Christoph Grein
2002-03-13 11:50 ` Larry Kilgallen
2002-03-13 14:15 ` Wes Groleau
2002-03-13 15:21 ` Kevin Cline
2002-03-13 15:24 ` Pascal Obry
2002-03-13 14:11 ` Wes Groleau
-- strict thread matches above, loose matches on Subject: below --
2002-03-14 5:41 Christoph Grein
2002-03-16 15:46 ` Jacob Sparre Andersen
2002-03-17 13:19 ` Nick Williams
2002-03-17 19:41 ` Robert A Duff
2001-11-09 17:59 Future with Ada Michal Nowak
2002-02-26 4:12 ` Jim Rogers
2002-02-27 17:51 ` Warren W. Gay VE3WWG
2002-02-28 17:45 ` Michal Nowak
2002-02-28 18:53 ` Hyman Rosen
2002-03-01 17:26 ` Jeffrey Carter
2002-03-03 8:26 ` Hyman Rosen
2002-03-03 17:47 ` Chad R. Meiners
2002-03-04 16:30 ` Hyman Rosen
2002-03-05 1:41 ` Richard Riehle
2002-03-05 21:35 ` Wes Groleau
2002-03-05 22:04 ` Marin David Condic
2002-03-06 16:36 ` Georg Bauhaus
2002-03-06 17:27 ` Marin David Condic
2002-03-07 16:04 ` Georg Bauhaus
2002-03-07 16:42 ` Marin David Condic
2002-03-11 20:02 ` Wes Groleau
2002-03-11 23:56 ` Marin David Condic
2002-03-12 16:47 ` code partitioning (was: Future with Ada) Wes Groleau
2002-03-12 17:56 ` Marin David Condic
2002-03-14 15:27 ` John R. Strohm
2002-03-15 14:15 ` Ted Dennison
2002-03-16 10:37 ` Kevin Cline
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox