Looking for good Ada95 book

Looking for good Ada95 book

[Lars Lundgren]

Hello.

Can anyone out there recomend a good Ada95 book.
I would like to use it to learn the language as well as a reference. 

I would like it to be correct and complete. 

I have seen a list of ten good java books presented in comp.lang.java. 

Is there a corresponding list for Ada book?

/Lars L

Re: Looking for good Ada95 book

[Larry Kilgallen]

In article <32723F6A.54A3@dtek.chalmers.se>, Lars Lundgren <d95lars@dtek.chalmers.se> writes:

> Can anyone out there recomend a good Ada95 book.
> I would like to use it to learn the language as well as a reference. 
> 
> I would like it to be correct and complete. 
> 
> I have seen a list of ten good java books presented in comp.lang.java. 
> 
> Is there a corresponding list for Ada book?

http://www.adahome.com will lead you to a list of many Ada books,
and reviews for some of them. I would think it highly unlikely
that any author would have an Ada book published and neglect
to make sure it is listed on http://www.adahome.com.

Larry Kilgallen

Re: Looking for good Ada95 book

[Rapicault Pascal]

Hi, 
In my opinion, you must look at the John Barnes book.
Personnaly I have it for Ada 83.
					Bye.
						Scal.

Re: Looking for good Ada95 book

[Robert Dewar]

Fran Post says

"I would have to second the Barnes book.  Stay away from the Feldman books."

This seems like a type error to me (comparing values of different types).
The Feldman books are not Ada books, they are CS1/2 books that happen to
use Ada, and I find them well written for this purpose (I stil don't like
the horrible non-standard keyword/identifier style, but other than that ...:-)

The Barnes book IS an Ada book.

If you don't know how to design programs, and want to learn, and want to
learn using Ada, you will find Feldman's book much more appropriate than
Barnes. If you know how to design programs and want to learn specifically
about Ada, then the Barnes book is much more appropriate.

Re: Looking for good Ada95 book

[Michael Feldman]

In article <dewar.846630258@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Fran Post says

>This seems like a type error to me (comparing values of different types).
>The Feldman books are not Ada books, they are CS1/2 books that happen to
>use Ada, and I find them well written for this purpose (I stil don't like
>the horrible non-standard keyword/identifier style, but other than that ...:-)

Your characterization of the books is correct, Robert, though I think
it's going too far to describe the lexical style as "horrible." It
does what it is intended to do.

>The Barnes book IS an Ada book.

In the sense that it is intended for experienced programmers interested
in learning the language, per se. For this purpose, I agree that it is
an excellent book. My only quibble - which I've had since the first
edition back in the early 80's - is that it is full of fragmentary bits
of code, with VERY few full programs. Even experienced programmers
(in my experience teaching industry courses) get trapped by the 
"what-goes-where" problem and really value seeing full, compilable
programs. For full programs, I think Cohen's book, and Naiditch's,
do a better job.

>If you don't know how to design programs, and want to learn, and want to
>learn using Ada, you will find Feldman's book much more appropriate than
>Barnes. If you know how to design programs and want to learn specifically
>about Ada, then the Barnes book is much more appropriate.

I agree wholeheartedly. We have written for different sets of readers.
The biggest risk in practitioners using books like mine is that there
are _big_ chunks of the language that I don't breathe a word about.
With a 700 or 800 page limit, something's gotta give.:-)

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
WWW: http://www.adahome.com or http://info.acm.org/sigada/education
------------------------------------------------------------------------

Re: Looking for good Ada95 book

[Tom Pastuszak]

Robert Dewar wrote:

>The Barnes book IS an Ada book. If you don't know how to design >programs, and want to learn, and want to
>learn using Ada, you will find Feldman's book much more appropriate
>than
>Barnes. If you know how to design programs and want to learn >specifically
>about Ada, then the Barnes book is much more appropriate.

It is rather hard to avoid Barnes, for, as I recall, the Ada 95
Rationale is a primarily Barnes' written document (p. iii of the
Rationale).  In the past I have preferred Cohen's first book, using Ada
as a Second Language, although it is a bit large.  I have not yet the
heart to read his recent book, although I've had it checked out of the
library for a month.  Regarding Barnes, I do not understand his
committment to Ada 95, gathering from the introductory sections of his
recent Ada 95 book.  For example, he refers to all this recent focus on
OO as promoting "abstraction leak" -- whatever that means.  
  
I have achieved good success with the following:

1. Read the R. Riele articles in JOOP.  These are surgical introductions
to the important features of Ada 95.  They are on par with what the best
writers on C++ have done for that language.

2. Look at as much Ada 95 code as you can, and cross reference to the
LRM as required.

3.  Start reading the Ada 95 Rationale, and when you run out of wind,
don't fight it -- stop reading and code some examples with the attitude
"what can I do with this"? Don't wait until you have pigged out on a
bunch of information to set down some examples.  I use a random number
generator to determine which section of the Rationale to read each day. 
Otherwise it is rather laborious to plow throught the whole thing.  

4. The Lovelace tutorial can help.  It is good for relieving fear of the
language.

Tom Pastuszak
 
-- 
@Pastukhov Russian: patr. from the occupational term pastukh shepherd
(from pasti to graze (trans.) ultimately a cogn. of L pascere;
cf. PASTOR). Cogns.: Ukr.: Pastushenko (dim.). Beloruss.: Pastushik,
Pastushonok (dims.). Pol: Pastusiak; Pastuszko (dim.). -- Oxford
Dictionary of Surnames, p. 409.

Re: Looking for good Ada95 book

[Robert Dewar]

Mike said

'Your characterization of the books is correct, Robert, though I think
it's going too far to describe the lexical style as "horrible." It
does what it is intended to do.
"

No, I stick by my characterization of horrible. It means that you are
teaching students to use a style which is not the standard style that
we want to encourage for Ada use. People tend to stick with the style
they first learn, so this kind of nonstandard choice causes problems
later on.

The result in my class is that some people use the Feldman style and
some use the more standard style that I (and most other Ada programmers)
use.

I understand, but find unconvincing, Mike's arguments for this nonstandard
style (in which keywords are capitalized).

Obviously tastes vary, but for me this disadvantage is sufficient to 
look at competitive text books that follow a more standard style. This
is obviously a question on which opinions will differ, but for me variation
in lexical style is very annoying, and it is a great advantage if a language
has a pretty standard style, either enforced by the language (COBOL), or
by generally accepted convention (C).

In the case of Ada, the original RM encouraged an ALL_CAPS style for
identifiers that many adopted, but many found intolerable because they
FELT IT WAS LIKE SHOUTING! Consequently we had a big mixture of clashing
styles, even sometimes I saw employees plain refuse to follow company
standards.

With Ada 95, we have something approaching a real consensus on style (use
lower case for keywords and Capitalized_Identifiers_With_Underscores). I
think this consensus is valuable for the community, and I think it is
damaging for a text book in effect to wage a rear guard action against
this consensus.

Mike feels that UPPER case keywords are superior from a pedagogical point
of view. Even if this were true (I don't accept this), it is not enough
to make it acceptable to undermine consensus style issues. Certainly
I don't see people seriously arguing this as an issue in teaching C
(though of cours there are many other legitimate issues when it comes
to teaching C as a first language).

SO, horrible may be too far for Mike, but I stand by it!

Re: Looking for good Ada95 book

[Robert A Duff]

In article <dewar.846952540@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>No, I stick by my characterization of horrible. ...

I agree.  It would be a Good Thing if all Ada programmers could agree on
such trivial style issues as upper-case vs. lower-case reserved words.
The RM recommends lower case.  If I thought I could get away with it, I
would have made that a *requirement* in the RM.  But these issues are so
emotion-laden, that I never had any serious hope of getting away with
such a radical position -- I never even opened my mouth on the point.

- Bob

Re: Looking for good Ada95 book

[Matthew Heaney]

In article <dewar.846952540@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Mike said
>
>'Your characterization of the books is correct, Robert, though I think
>it's going too far to describe the lexical style as "horrible." It
>does what it is intended to do.
>"
>
>No, I stick by my characterization of horrible. It means that you are
>teaching students to use a style which is not the standard style that
>we want to encourage for Ada use. People tend to stick with the style
>they first learn, so this kind of nonstandard choice causes problems
>later on.

Mike, I agree with Robert here.

One thing that Robert didn't mention is that many language-sensitive
editors put the language keywords in a different color.  So that should
obviate the need for you to do anything special in the code (ie make all
uppercase) to call out keywords.

The other thing, too, is that studies have shown (see Ben Schneiderman's
book, Designing the User Interface) that humans read all-uppercase more
slowly than mixed case.  

And these days with "netiquette idioms" having emerged, all uppercase means
SHOUTING AT THE READER.  You don't want to shout at the poor reader of your
Ada source code, do you?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Looking for good Ada95 book

[Robert Dewar]

iRobert Duff said

"I agree.  It would be a Good Thing if all Ada programmers could agree on
such trivial style issues as upper-case vs. lower-case reserved words.
The RM recommends lower case.  If I thought I could get away with it, I
would have made that a *requirement* in the RM.  But these issues are so
emotion-laden, that I never had any serious hope of getting away with
such a radical position -- I never even opened my mouth on the point.
"

Well clearly the compatibility requirement would have stood in the way
of such requirements. However, the fact that we changed the style in the
RM, and the fact that the overwhelming majority of Ada programmers are
converging on one standard style (lower case keywords, and 
Mixed_Case_Identifiers) is definitely a Good Thing, and to be
encouraged wherever possible.

I certainly would like it if all Ada text books followed this model, and
consider it a weakness if they do not. 

Re: Looking for good Ada95 book

[Norman H. Cohen]

Robert Dewar wrote:

> In the case of Ada, the original RM encouraged an ALL_CAPS style for
> identifiers that many adopted, but many found intolerable because they
> FELT IT WAS LIKE SHOUTING! 

More important to me than any sense of being shouted at was the fact
that confining yourself to one case, when the language rules allow
either upper or lower case, is throwing away an opportunity for
expressiveness.

Why write CHANNELS_ALLOCATED_TO_CBS and make your reader wonder whether
you meant Channels_Allocated_To_CBS or Channels_Allocated_To_CBs?

(For those outside the US, CBS is a television network and CBs are
Citizens Band radios.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Looking for good Ada95 book

[Robert Dewar]

Michael says

"> I was not asked what my opinion was before forming this imaginary
> consensus, and I feel that we should reject all nonsense standards
> such as capitalization that take time away from making a program
> semantically correct (solving the problem correctly) and making
> it efficient."

(at least I hope it was Michael, sorry if I am confused).

In fact consistency of style is critical to producting reliable
maintainable programs. Sure, there are always some people who say
that they don't want to be constrained by such silly things as
petty consistency. I consider this viewpoint to be a menace since
it leads to notions of idiosyncratic personal style and code
ownership, which to me are anathema to realiable large scale
programming.

I think Michael's specific recommended style (lower case for everything)
does NOT lead to the most readable code, and I think it is a big
improvement that we are indeed seeing something like a general consensus
in coding style (I react here to the huge volume of Ada 95 code we receive
at report@gnat.com from thousands of users of GNAt, nearly all of whom adhere
to the lower case keywords, Mixed_Case_Identifier style. Not all, but nearly
all.

I know that one can have tools that automatically translate from one style
to another, but even if such tools work perfectly (they cannot in practice,
since naming often has semantic contnts, e.g. NOSC_Policy, not Nosc_Policy
may be preferred), they do not promote common interchange of code. It is
far better if, as in the C world, people converge on a single style that
everyone uses.

I think this convergence is much more important than what particular style
is chosen. As Tarski use to say, explaining why stanards are important,
it really doesn't matter if you drive on the left or the right, but it is
quite importnat that everyone agree.

I used to prefer the Ada-83 RM SHOUTING_IDENTIFIER style, since it is wht
I was used to, but after a painful transition, I now can't stand that
style any more. That's the real point, people get used to almost any
convention, so they might as well get used to a common comvention.

That is why Mike's book is disturbing, it creates a generation of Ada
programmers who have got used to a seriously non-standard style. Virtually
NO code that we see at report@gnat.com uses upper case keywords like BEGIN
and END. The only other use we see is SHOUTING_IDENTIFIERS, Ada 83 style, and
that is certainly disappearing fast.

Re: Looking for good Ada95 book

[Jerry Petrey]

Norman H. Cohen wrote:
> 
> Robert Dewar wrote:
> 
> > In the case of Ada, the original RM encouraged an ALL_CAPS style for
> > identifiers that many adopted, but many found intolerable because they
> > FELT IT WAS LIKE SHOUTING!
> 
> More important to me than any sense of being shouted at was the fact
> that confining yourself to one case, when the language rules allow
> either upper or lower case, is throwing away an opportunity for
> expressiveness.
> 
> Why write CHANNELS_ALLOCATED_TO_CBS and make your reader wonder whether
> you meant Channels_Allocated_To_CBS or Channels_Allocated_To_CBs?
> 
> (For those outside the US, CBS is a television network and CBs are
> Citizens Band radios.)
> 
> --
> Norman H. Cohen
> mailto:ncohen@watson.ibm.com
> http://www.research.ibm.com/people/n/ncohen


I agree with Norman on this but unfortunately automatic formatters and
many people will only write Channels_Allocated_To_Cbs, capitalizing
only the the first letter of each word even when some are acronyms
and should be in all caps.

In any case, I think Feldman's book is still a very good book for
its intended audience, in spite of this difference in style.
Other great books are: Norman's "Ada 95 as a Second Language",
Naiditch's "Rendezvous with Ada 95", Smith's "O-O Software in Ada 95"
and, of course, Barnes' "Programming in Ada 95".

-- 
=====================================================================
=  Jerry Petrey - Consultant Software Engineer  - Member Team Ada   =
=                 Rockwell Collins Avionics                         =
=  email: home - gpetrey@gate.net   work: gdp@mlb.cca.rockwell.com  =
=====================================================================








-- 
=====================================================================
=  Jerry Petrey - Consultant Software Engineer  - Member Team Ada   =
=                 Rockwell Collins Avionics                         =
=  email: home - gpetrey@gate.net   work: gdp@mlb.cca.rockwell.com 
=                                                                 =
=====================================================================

Re: Looking for good Ada95 book

[John English]

Lars Lundgren (d95lars@dtek.chalmers.se) wrote:
: Can anyone out there recomend a good Ada95 book.
: I would like to use it to learn the language as well as a reference. 

(Uh oh. An excuse to blow my own trumpet... :-)

You could have a look at "Ada 95: the Craft of Object-Oriented
Programming" by yours truly (Prentice Hall).  To get a flavour
of the book, visit http://www.comp.it.bton.ac.uk/je/adacraft
which gives you the table of contents, preface, three sample
chapters, and so on.

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------

Re: Looking for good Ada95 book

[Michael F Brenner]

    > With Ada 95, we have something approaching a real consensus on style (use
    > lower case for keywords and Capitalized_Identifiers_With_Underscores). I
    > think this consensus is valuable for the community,

I was not asked what my opinion was before forming this imaginary
consensus, and I feel that we should reject all nonsense standards
such as capitalization that take time away from making a program
semantically correct (solving the problem correctly) and making
it efficient. If a standard is going to become a consensus, it 
should capitalize like almost all languages on Earth that have
capitals do: only acronyms and the first letter of each computer
program are capitals, all others are small letters. But most 
importantly, do not make standards without the consent of the 
victims who will be subjected to the tyrrany of those standards. 
If I am not permitted input into the process, then the process
Must not be construed to effect me.

Re: Looking for good Ada95 book

[Larry Kilgallen]

In article <55kmtp$3s3@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
>     > With Ada 95, we have something approaching a real consensus on style (use
>     > lower case for keywords and Capitalized_Identifiers_With_Underscores). I
>     > think this consensus is valuable for the community,
> 
> I was not asked what my opinion was before forming this imaginary
> consensus, and I feel that we should reject all nonsense standards
> such as capitalization that take time away from making a program
> semantically correct (solving the problem correctly) and making
> it efficient. If a standard is going to become a consensus, it 
> should capitalize like almost all languages on Earth that have
> capitals do: only acronyms and the first letter of each computer
> program are capitals, all others are small letters. But most 
> importantly, do not make standards without the consent of the 
> victims who will be subjected to the tyrrany of those standards. 
> If I am not permitted input into the process, then the process
> Must not be construed to effect me.

Although adding underscores is problematic, it seems to me that
for programs on a computer letting each reader view them with
their preferred capitalization should be a trivial extension
to an editor which already does syntax coloring.

Larry Kilgallen

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

mfb@mbunix.mitre.org (Michael F Brenner) writes:

>I was not asked what my opinion was before forming this imaginary
>consensus

Actually, you were.  You just weren't listening.
There's no smiley on this, because it is literally true.
The old AQ&S guidelines invited comment.  Comments were also invited
for the Ada 9x revisions (which turned out to be Ada 95).  There was
quite a long time when people could have written in comments about
style.

>and I feel that we should reject all nonsense standards
>such as capitalization 

and then goes on to propose a standard for capitalisation

>that take time away from making a program
>semantically correct (solving the problem correctly) and making
>it efficient.

But you have this backwards.  _Following_ a capitalisation convention
*saves* time, because it eliminates unimportant decisions.

>If a standard is going to become a consensus, it 
>should capitalize like almost all languages on Earth that have
>capitals do: only acronyms and the first letter of each computer
>program are capitals, all others are small letters.

The first letter of each computer program?

I merely note that English and German have *different* capitalisation
rules, and pass on to the next point.

>But most 
>importantly, do not make standards without the consent of the 
>victims who will be subjected to the tyrrany of those standards. 
>If I am not permitted input into the process, then the process
>Must not be construed to effect me.

You can with good reason level this charge at Microsoft, whose weird
convention you _have_ to follow when using their C API.  But you cannot
level it at Ada, where there _was_ an opportunity for the general public
to provide input.  I read a lot of the documents, decided the people
working on them knew what they were doing, and waited impatiently for
the result.  I had paper stacked about a metre feet high with this stuff.

Did you notice, by the way, that if your claim about standards were
extended to national laws, you would feel yourself free to ignore almost
every law in the USA, certainly the Consistution would not bind you, and
you would not feel obliged to obey the laws of _this_ country (Australia)
and would merrily drive down the wrong side of the street.

I wish more people would stop screaming about the "THEY are infringing on
MY rights" side of things (in programming; screaming about rights is often
a good idea in politics) and think about the courtesy they owe to other
people who have to deal with their code.  The _real_ victims are the
people who have to maintain code written by someone who insisted on his
rights.  The whole point of Ada, after all, is to reduce costs over the
_whole_ lifecycle, including maintenance.


For what it's worth, I agree that a layout style should be based on
natural language, and the Ada Quality & Style Guidelines explicitly
mention that point.

Pursuing the reductio ad absurdum a bit further, nobody asked *me* what
the grammar, spelling, or vocabulary of English should be.  I suppose I
have a _right_ to "any reo I want patter", but I have no right to expect
other people to like it, or to hire me.  (I wonder how many people reading
this group understand the old English comedy line "How bona to vada your
dolly old eek" or the following sentence which most New Zealanders would
have understood before the impact of American TV:  "I need some kai in my
puku.")

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

Jerry Petrey <gpetrey@gate.net> writes:

>I agree with Norman on this but unfortunately automatic formatters and
>many people will only write Channels_Allocated_To_Cbs, capitalizing
>only the the first letter of each word even when some are acronyms
>and should be in all caps.

The free program 'aimap' can be used to fix that.
I have never used an automatic formatter for Ada (it would be _very_
nice to have one when marking student code), but I can't imagine why
a modern formatter _wouldn't_ do something like aimap here.

>In any case, I think Feldman's book is still a very good book for
>its intended audience, in spite of this difference in style.

Nobody denies _that_.  The pity is that it would be even _better_ if
it followed the AQ&S guidelines.  We teach Ada in 1st and 2nd year
here.  Feldman has done too much good to the Ada community for us to
be able to ignore him, _but_ we have such a hard struggle getting
students to follow any convention at all (they _will_ indent by 8s
even when you tell them "use ^T to indent in VIle, not ^I") that the
_last_ thing we need is a book *teaching* them to use a different,
and significantly uglier, style.

For what it's worth, there are elements of my *preferred* style which
differ from the AQ&S guidelines, and I have deliberately switched to
someone I like less because I don't think my "rights" to write as I
prefer outweigh the _students'_ rights to be presented with *consistent*
good examples.

I like Barnes' books a _lot_.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Wolfgang Gellerich]

In article <32723F6A.54A3@dtek.chalmers.se>, Lars Lundgren <d95lars@dtek.chalmers.se> writes:

|> Can anyone out there recomend a good Ada95 book.
|> I would like to use it to learn the language as well as a reference. 
|> 
|> I would like it to be correct and complete. 

How about "Programming in Ada 95" by John Barnes ?


Regards,

  Wolfgang


+----------------------------------------------------------------------------+
|Wolfgang Gellerich                    gellerich@informatik.uni-stuttgart.de |
|University of Stuttgart;                                                    |
|Informatics Department; Programming Languages Group;                        |
|Breitwiesenstrasse 20-22; D-70565 Stuttgart; Germany                        |
|Tel. +49-711-7816213  Fax +49-711-7816380                                   |
|(Amateur Radio : DJ3TZ@DB0RBS.#BW.DEU.EU)            ACM Member No. 4436341 |
+----------------------------------------------------------------------------+

Re: Looking for good Ada95 book

[Robert A Duff]

In article <55kmtp$3s3@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>I was not asked what my opinion was before forming this imaginary
>consensus, ...

Sure you were.  The Ada 9X process was public, and anybody was allowed
to comment.  We got *lots* of comments.

- Bob

Re: Looking for good Ada95 book

[Robert Dewar]

iMichael says

">But most
>importantly, do not make standards without the consent of the
>victims who will be subjected to the tyrrany of those standards.
>If I am not permitted input into the process, then the process
>Must not be construed to effect me."

Don't worry too much, at least from where I sit, you are the LAST person
I would try to impose any standards on, I avoid people with this kind
of attitude, regardless of their supposed skills (I say supposed, because
to me, the ability to follow consistent style guidelines without such
foolish objections is a critical part of professional competence in
the programming area).


You will find plenty of places where such views are considered aceptable,
though I suspect you may do better sticking to C and C++, isntead of
persuing Ada, if you have this kind of attitude :-)

Re: Looking for good Ada95 book

[James Thiele]

In article <1996Nov4.083416.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>In article <55kmtp$3s3@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
>>     > With Ada 95, we have something approaching a real consensus on style (use
>>     > lower case for keywords and Capitalized_Identifiers_With_Underscores). I
>>     > think this consensus is valuable for the community,
>> 
>> I was not asked what my opinion was before forming this imaginary
[snip]
>
>Although adding underscores is problematic, it seems to me that
>for programs on a computer letting each reader view them with
>their preferred capitalization should be a trivial extension
>to an editor which already does syntax coloring.

And when you print the program, do you use ink and paper which lets
each reader view it with their preferred capitalization?

--
James Thiele
james@cdac.com (work) or jet@eskimo.com (home)
http://www.eskimo.com/~jet

Re: Looking for good Ada95 book

[Stephen Leake]

James Thiele wrote:
> 
> In article <1996Nov4.083416.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> >In article <55kmtp$3s3@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> >>     > With Ada 95, we have something approaching a real consensus on style (use
> >>     > lower case for keywords and Capitalized_Identifiers_With_Underscores). I
> >>     > think this consensus is valuable for the community,
> >>
> >> I was not asked what my opinion was before forming this imaginary
> [snip]
> >
> >Although adding underscores is problematic, it seems to me that
> >for programs on a computer letting each reader view them with
> >their preferred capitalization should be a trivial extension
> >to an editor which already does syntax coloring.
> 
> And when you print the program, do you use ink and paper which lets
> each reader view it with their preferred capitalization?

Maybe I'm in a small minority, but since I'm blessed with a big screen,
it has literally been years since I've printed out code! So I don't give
much weight to "what will this look like when printed".

> --
> James Thiele
> james@cdac.com (work) or jet@eskimo.com (home)
> http://www.eskimo.com/~jet

-- 
- Stephe

Re: Looking for good Ada95 book

[Michael Feldman]

In article <327EA5BB.1EFD@gate.net>, Jerry Petrey  <gpetrey@gate.net> wrote:

[snip]

>In any case, I think Feldman's book is still a very good book for
>its intended audience, in spite of this difference in style.
>Other great books are: Norman's "Ada 95 as a Second Language",
>Naiditch's "Rendezvous with Ada 95", Smith's "O-O Software in Ada 95"
>and, of course, Barnes' "Programming in Ada 95".

I agree with you about all these books; each has its intended audience.
I'm delighted to run into someone who actually seems to be reading for
content, instead of trashing a book for a supposed "rear guard" against
a consensus lexical style.

Thanks for the support.

Mike Feldman

Re: Looking for good Ada95 book

[Michael Feldman]

In article <dewar.847123116@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

[snip]

>That is why Mike's book is disturbing, it creates a generation of Ada
>programmers who have got used to a seriously non-standard style. Virtually
>NO code that we see at report@gnat.com uses upper case keywords like BEGIN
>and END. The only other use we see is SHOUTING_IDENTIFIERS, Ada 83 style, and
>that is certainly disappearing fast.

I rest my case. (pun intended.) Even my freshmen are usually cool enough 
to use lower-case reserved words once they get to be sophomores. I even
suggest that they do so.

I also avoid use clauses, for the most part; GNAT sources use them all over
the place. Which of us is "right", Robert? Somehow my students - once they
understand what they are doing - manage to switch to a style that suits
them instead of me.

Maybe your freshmen are inherently smarter than mine; they need no emphasis
to help them distinguish reserved words. Fine.

Sheesh; this is really getting tiresome.

Mike Feldman

Re: Looking for good Ada95 book

[Michael Feldman]

In article <dewar.846952540@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>The result in my class is that some people use the Feldman style and
>some use the more standard style that I (and most other Ada programmers)
>use.

So, this is fine.
>
>I understand, but find unconvincing, Mike's arguments for this nonstandard
>style (in which keywords are capitalized).

Right - I borrowed it from a long line of Pascal-in-CS1 authors. I'm
really getting bored with fighting this battle repeatedly over something 
very small. The Pascal community went to the upper-case style because
it was a reasonable replacement for bold-facing, in teaching beginners.
>
>Obviously tastes vary, but for me this disadvantage is sufficient to 
>look at competitive text books that follow a more standard style. This
>is obviously a question on which opinions will differ, but for me variation
>in lexical style is very annoying, and it is a great advantage if a language
>has a pretty standard style, either enforced by the language (COBOL), or
>by generally accepted convention (C).

So use a different book... tastes vary.

>With Ada 95, we have something approaching a real consensus on style (use
>lower case for keywords and Capitalized_Identifiers_With_Underscores). I
>think this consensus is valuable for the community, and I think it is
>damaging for a text book in effect to wage a rear guard action against
>this consensus.

Rear-guard action? Gimmea break! Damaging to what? To whom? C'mon -
the RM leaves it up to individuals to set a lexical style. Why do you
feel the urge to be dictatorial? 

It's NOT a rear-guard action, merely a pedagogical technique. When I'm
writing for beginners, I use the capitalized style; when I'm not, I don;t.
Jeez - not everything has to be so _political_. I'm not opposed to
the "standard" style; I just bought in to teaching beginners using a
style adopted by hundreds of Pascal teachers.
>
>Mike feels that UPPER case keywords are superior from a pedagogical point
>of view. Even if this were true (I don't accept this), it is not enough
>to make it acceptable to undermine consensus style issues. Certainly
>I don't see people seriously arguing this as an issue in teaching C
>(though of cours there are many other legitimate issues when it comes
>to teaching C as a first language).

I beg your pardon - there are lots of style in writing C identifiers.
Some use lower case, others mixed case. 

C _requires_ reserved words to be in lower case, so everyone does it. 
Ada requires nothing of the kind.

You are right - there are lots of issues, so why do you persist in
fighting this battle? Maybe I'll change it in the next edition (Cohen
changed his...), maybe not. I find the students like it.

>SO, horrible may be too far for Mike, but I stand by it!

Robert, you're making a VERY big deal over something VERY small. 
Any student (beyond the first year) incapable of switching the case
of his reserved words to suit his teacher or manager had better get
out of CS.

If the lexical style is really sufficient reason to adopt or reject a
text, I'd say you're not reading for content...

Mike Feldman

Re: Looking for good Ada95 book

[Robert Dewar]

Lars says

"The argument is "egoless programming". If there is no ego involved
wouldn't one then be willing to, not only write, but also read other
styles than ones own?"

No, that's not right, it's not a matter of ego that makes it difficult
to both read and write multiple styles. You get used to one particular
style, and as a result it is both easier to read and write once you are
used to it. Maybe some programmers can read multiple styles completely
independently, but I never met anyone who claimed this ability.

In fact the typical thing is that people find it MUCH easier to read the
style they are used to, just as they are most at home listening to the dialect
of English they are most used to. 

And the resulting conclsuion is that it is desirable if everyone gets used
to the same style. You can get used to almost any style, so it is desirable
if everyone goes through the excercise of learning one style well for the
same style.

Mike thinks I am making a big deal out of it. Not surprising, he obviously
does not feel that consistency is important here, and thinks it is trivially
easy for people to change. OK, but I strongly disagree. I have seem too many
people adamantly hold on to the style they first learned and refuse to change.

And Mike, it is not that I am not reading the content of the book, which I
think highly of, but other things being equal I would choose a book using
standard style. One encouraging point is that now I have a number of Ada CS1
books to look at, and generally they are adopting the "standard" Ada style
of lower case keywords and Mixed_Case_Identifiers.

And no Mike, my students do not seem to need upper case keywords to know
what is a keyword and what is not. Furthermore I do not believe that there
has ever been a study showing the supposed pedagogical advantage of upper
case keywords. Historically, the reason this style is common in the Pascal
world is that it is a remnant of the notion of stropping in Algol. In Algol
and Algol60, keywords are in boldface, and a way has to be found to indicate
this. A common choice was to use upper case to represent bold, and that
common style in Algol-60 was imported into the Pascal world.

Mike, I know you think I am making a big deal out of a very small point, but
that IS the point, I do NOT think that consistency in style across the
Ada community is a small point at all, and I am not alone in this thinking.
I well remember a Tri-Ada at which one of the plenary speakers said that one
of his major objections to Ada was the habit of using upper case identifiers,
and there was *huge* applause. Now of course we are not talking about
UPPER_CASE_IDENTIFIERS here but just upper case BEGIN END etc, but I think
you will find a lot of Ada programmers find this upper case keyword style
highly distatesful. 

Others don't think it matters much.

What is a little unusual about Mike's position is that he thinks it is
a small point, but is still adamant in insisting on using this nonstandard
style in his books. Mike, you are allowed to be insistent on your position,
but if you are insistent, then surely it is NOT such a small point :-)

Re: Looking for good Ada95 book

[Lars Farm]

Michael Feldman <mfeldman@seas.gwu.edu> wrote:

> Robert, you're making a VERY big deal over something VERY small. 

The argument is "egoless programming". If there is no ego involved
wouldn't one then be willing to, not only write, but also read other
styles than ones own?


-- 
Lars Farm, lars.farm@ite.mh.se

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

mfeldman@seas.gwu.edu (Michael Feldman) writes:
>I rest my case. (pun intended.) Even my freshmen are usually cool enough 
>to use lower-case reserved words once they get to be sophomores. I even
>suggest that they do so.

Your freshmen are not our undergraduates.
Our undergraduates are hostile to the idea of a common coding style.
When I say "hostile", I am not exaggerating for effect;
the things I was called when I asked that C code be run through indent
(with a profile that I provided) just before sending it to me for marking,
they'd make your hair curl.  "Fascist" was the least of them.
I wasn't even asking that they _write_ in a particular style, only that
they _indent_ to that style just before posting!
And these are second-year students, not first year students.
I'm not sure what a sophomore[%] is, it's not a word we use, but these
are wise fools indeed.  This semester just past, students were told, by
the lecturer running the course, and repeated again in the published 
marking guide for each assignment, that they would lose marks if they
didn't follow the AQ&S guidelines for layout and naming.  Well, they
lost marks.

>Maybe your freshmen are inherently smarter than mine; they need no emphasis
>to help them distinguish reserved words. Fine.

First observation:  the AQ&S style *distinguishes* keywords from identifiers,
and very successfully at that.

Second observation:  from what I can see, our students are, um, rather
more academically challenged than yours.  They have mediocre to poor
literacy skills and essentially no common sense.  (For example, in a 2nd
year assignment about priority queues, I provided an implementation of
"leftist trees", they were told about the Feldman data structures, and
the very textbook they were using had a complete priority queue package,
and they were explicitly told they could use any one of these, yet most
of them wrote their own, and that badly.  Sigh.)  For many of them, the
art of using the index in a book is a black mystery.

Yet one thing our students have *no* trouble with is keywords.
Even our 1st year students.
The keywords tend to be in syntactically salient positions.

Let's face it, we are trying to teach a whole lot of things in a short
time.  (3 or 4 years is a short time.  It's taken me 20 years to learn
some of the things I try to teach.)  One of the things we are trying to
teach is that you do not write code to please yourself, but to communicate
to other people.  This is *amazingly* hard to get across; exposure to
computing in schools has convinced the students that programming is all
about one person telling one computer what to do, and it is heartbreakingly
difficult to change their minds about this.  One aspect of communicating
with other people is adopting a shared style; placing the benefit to other
people above one's own taste.   The students need to see *us* doing this,
which is why I have conformed my own style to the AQ&S.  (Semper reformanda;
the AQ&S does not yield all its wisdom in a single reading.)  The students
also need to see the textbooks doing the same thing, because when they see
a textbook author doing his own thing, they claim the same right.

By the way, I am co-supervising a masters student whose thesis bears on
the problem of evaluating whether first-year teaching choices actually
produce the outcomes they are supposed to:  if there is research which
shows that "KEYWORD Identifier" does actually work better with 1st-year
students than "keyword Identifier", I, the other supervisor, and the
student, would be most grateful to hear of it.

[%] The third dictionary I checked had it:  "a 2nd year student at an
American university".
-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Lars Farm]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

> What is a little unusual about Mike's position is that he thinks it is
> a small point, but is still adamant in insisting on using this nonstandard
> style in his books. Mike, you are allowed to be insistent on your position,
> but if you are insistent, then surely it is NOT such a small point :-)

I have seen so many styles over the years, and so many heated debates
about the subject that I am convinced that this is not a small point to
the individual. Most of us have strong opinions. You obviously have. I
do[1][2] and Michael Feldman seems to have opinions too. Interestingly
all three of us have different opinions on what is and is not readable.
There is no right or wrong. There is only opinion. There will never be
consensus over an entire user community. 

I have come to accept that this is the way of things. Look at C or C++.
A much larger user base and much larger diversity of styles and naming
conventions. This is not because of language (it requires lower case
keywords). This is because programmers are human. We want to keep them
human, don't we?

Allow different styles, learn to live with and even appreciate
diversity. This way ones own style will gradually evolve into something
better from external influences.

Differentiating between keywords, typenames, constants and other kinds
of names is something that programming editors do very nicely with
syntax highlighting, colour and other tools. Style conventions merely
for that, has become less of an issue or even a non issue.

 Lars


[1] For instance, I find Your_Mixed_Case_Identifiers harder to read than
all_lower_case_identifiers because lower case looks like ordinary text
and Mixed_Case_Identifiers_Looks_Like_Nothing_Else (possibly because no
one in his right mind would ever capitalize every word in a swedish
sentence - not even a book title - This_Is_Every_Bit_As_Much_Shouting as
ALL_UPPER_CASE). Neither can I stand Hungarian notation. Even so, if
there is a style guide for an employer or a project, I'll use it because
it's their money and the code I write is their code so they should have
their style. This doesn't mean that their style is my style.

[2] Of course, when confronted with that, most programmers deny any such
opinions and use other motives for enforcing their style on others.


-- 
Lars Farm, lars.farm@ite.mh.se

Re: Looking for good Ada95 book

[Marin David Condic, 561.796.8997, M/S 731-93]

Michael Feldman <mfeldman@SEAS.GWU.EDU> writes:
>
>If the lexical style is really sufficient reason to adopt or reject a
>text, I'd say you're not reading for content...
>
>
    I've read your book and I think the important thing is that it
    does something lots of Ada critics said couldn't be done: Teach
    beginning programming using Ada. (You know the criticsms - too
    complex, too much to know before you can write anything useful,
    etc, etc.)

    While I did find the format of the code a little disconcerting (I
    got used to the lower-case reserved words, SHOUTING_IDENTIFIERS
    common in Ada83) I didn't find it terribly distracting. The main
    thing I've found with formatting is simply to be consistent.
    (That, and taking the time to *DO* it makes you review and
    double-check your code!)

    Far more disturbing to me is code that is "organically grown". The
    sort of thing that happens when the programmer is thinking "If I
    stick this variable in this package then procedure X can write
    some data which function Y can read and update and I won't have to
    add new 'with' clauses..." All too often, bad formatting is a
    'leading indicator' that you're going to see organically grown
    code.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "That which belongs to another."

        --  Diogenes, when asked what wine he liked to drink.
===============================================================================

Re: Looking for good Ada95 book

[Robert Dewar]

Lars says

"I have seen so many styles over the years, and so many heated debates
about the subject that I am convinced that this is not a small point to
the individual. Most of us have strong opinions. You obviously have. I
do[1][2] and Michael Feldman seems to have opinions too. Interestingly
all three of us have different opinions on what is and is not readable.
There is no right or wrong. There is only opinion. There will never be
consensus over an entire user community."

How little you understand my position! I have no opinion on what is 

or is not readable. In my experience anyone can get used to anything.
My point is that we might as well all get used to the same style,
and luckily, as I see from a very large sample of Ada 95 users, the
great majority DO use a single style. In my opinion, those in the
minority should change -- I did!

As for putting up with differing styles, no, I won't. If anyone at
ACT insisted on using their own idiosyncratic style, I would tell
them they were welcome to do so elsewhere. I don't think the
particular style choice we make in the GNAT project is anyone's
personal ideal, but we all agree that complete consistency is
more important than personal ideal's in this area.

It is, for reasons that I have stated in detail before,
neither pratical nor desirable for a project to live with a variety
of styles if you want the highest possible quality code.

Re: Looking for good Ada95 book

[Mark Shaw]

IMHO I think that ada95 from the beginning by Skansholm is quite a good
book for begginers..........

Mark

----------------------------------------------------------------- 
Phrase of the week: 'If at first you succeed, don't take any more stupid 
chances.'
Mark Shaw is at Bradford University. He is studying computer science and
has a web page at http://www.brad.ac.uk/~msshaw and at 
http://www.geocities.com/TimesSquare/9995
He is helping with the UBU web pages and is a UBU councillor.

-----------------------------------------------------------------

Re: Looking for good Ada95 book

[Lars Farm]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

> As for putting up with differing styles, no, I won't. If anyone at
> ACT insisted on using their own idiosyncratic style, I would tell
> them they were welcome to do so elsewhere.

I agree. Different scopes. Organization and every user. When I say
"allow different styles", I mean the larger scope. One project /
organization / person should not impose its own preferred style on other
unrelated organizations / persons. I do not mean that you should accept
anything within a project / organization.

I can't see how my message could be interpreted like that. I said:

> if there is a style guide for an employer or a project, I'll use it
> because it's their money and the code I write is their code so they
> should have their style.

With the little English I know, this seems pretty clear. Perhaps my
English isn't good enough? 


-- 
Lars Farm, lars.farm@ite.mh.se

Re: Looking for good Ada95 book

[Michael Feldman]

In article <dewar.847671101@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

>world is that it is a remnant of the notion of stropping in Algol. In Algol
>and Algol60, keywords are in boldface, and a way has to be found to indicate
>this. A common choice was to use upper case to represent bold, and that
>common style in Algol-60 was imported into the Pascal world.

Correct. And many Pascal authors stuck with it because it works well
with beginners, especially if you want the printed code to look just
like the code the students see and write on terminals.

>Mike, I know you think I am making a big deal out of a very small point, but
>that IS the point, I do NOT think that consistency in style across the
>Ada community is a small point at all, and I am not alone in this thinking.

I find it interesting that out of a couple of dozen reviewers of the
two books we are discussing, NONE objected to the upper-case reserved
words. These were not Ada dummies; they saw the logic behind what I was
doing, and went along with it. Every reviewer was an active teacher of
Ada in intro courses.

>I well remember a Tri-Ada at which one of the plenary speakers said that one
>of his major objections to Ada was the habit of using upper case identifiers,
>and there was *huge* applause. Now of course we are not talking about
>UPPER_CASE_IDENTIFIERS here but just upper case BEGIN END etc, but I think
>you will find a lot of Ada programmers find this upper case keyword style
>highly distatesful. 

So they do not have to use it, just because a couple of intro books do.
Nobody is forcing them, and even the most elementary prettyprinter
(or even a decent editor macro) can change the case of reserved words
anyway.

>Others don't think it matters much.

I think it matters in dealing with first-term students. If the community
is THAT outraged, I'll certainly consider changing it in the next edition.
Obviously it won;t happen till then; one doesn;t make that kind of change
"on the fly".

>What is a little unusual about Mike's position is that he thinks it is
>a small point, but is still adamant in insisting on using this nonstandard
>style in his books. Mike, you are allowed to be insistent on your position,
>but if you are insistent, then surely it is NOT such a small point :-)

It's a small point in the larger community; I maintain it is a helpful
style for first-year students.

Mike Feldman

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

mfeldman@seas.gwu.edu (Michael Feldman) writes:

>So use a different book... tastes vary.

I think the thing that needs to be made plain is that Feldman's critics
on this topic are not enemies, but "disappointed lovers", people who
_want_ to use his books but for this reason _can't_.

>Rear-guard action? Gimmea break! Damaging to what? To whom? C'mon -
>the RM leaves it up to individuals to set a lexical style. 

But it uses a specific lexical style _itself_.

>It's NOT a rear-guard action, merely a pedagogical technique. When I'm
>writing for beginners, I use the capitalized style; when I'm not, I don;t.
>Jeez - not everything has to be so _political_. I'm not opposed to
>the "standard" style; I just bought in to teaching beginners using a
>style adopted by hundreds of Pascal teachers.

I note that the last textbook we used when we were teaching Pascal was
"Foundations of Computer Science" by Aho & Ullman.  I just checked.
Lower case keywords throughout.  Not even boldface.  What you see is
what you type.  Jensen & Wirth, of course, used lower case.  Kruse
uses lower case.  Fisher & Reges use lower case.  The UCSD Pascal
Handbook for the P-system (Clark & Koehler) uses lower case.  None of
this shows that lower case is a consensus amongst Pascal books, but
it _does_ show that upper case is _not_ a consensus for Pascal books.

>You are right - there are lots of issues, so why do you persist in
>fighting this battle?

Because people *want* to use your books, but because they don't fit in
with other valued books, including the LRM and the AQ&S guides and all
the other code the students are going to see, they fell they *can't.*

If I thought the books were bad books on other grounds, I for one
wouldn't _care_ about the style.

>If the lexical style is really sufficient reason to adopt or reject a
>text, I'd say you're not reading for content...

Unfair.  Not reading *JUST* for content, maybe.
Students in this part of the world use the style they were first
taught, and if a later lecturer wants something different, they regard
the _lecturer_ as incompetent and pedantic, and don't do it.  Now
that high fees and 'the era of accountability' are upon us, if a course
used inconsistent styles in two years, an internal audit would probably
demand a change.  I've just been at a meeting this morning where we
were told that lecturers no longer have autonomy in designing and marking
their subjects.

When I learned Fortran and Algol and COBOL and PL/I, nobody dreamed that
we might need special visual clues to help us tell which were the keywords;
the keypunches had a single case on their keyboards, the printers had a
single case on their drums or chains, and students were deemed to be
sufficiently literate to cope with a handful of special words that
occurred at the beginning of lines.  I have seen hundreds of students
successfully taught these programming languages with a single alphabetic
case and no "looks" variations.  When did students' brains rot so that
they needed _that_ particular crutch more than any other distinction that
case might make?

Once again, I reckon that our students are, by the standards of my youth,
pretty dim and helpless, but "which are the keywords" is something they
have *no* trouble with.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Robert Dewar]

Mike says

"It's a small point in the larger community; I maintain it is a helpful
style for first-year students."

OK, so, a claim that this is not just arbitrary, but that there is an
objective advantage. OK, Mike, what is the source of evidence for this
claim?

I have never heard anyone else make this claim, or seen any evidence
to back it up -- sure some Pascal books use this style, but as I explained
there is understandable historic precedent, and you cannot assume that
because a book uses this style that it agrees with the point Mike is
making.

P.S. Mike cannot say that he was completely unaware that anyone might
object to this style, he has known for a long time that I object, but it
is a fair point that no one else reviewing the book did.

So far on CLA, no one has actively supported the MF style, the contributions
to this thread are divided between those who agree with me that it is a pity
that the book is inconsistent with the most commonly recommended style, and
those who think it does not matter. It would be interesting to hear from
anyone else who agrees that the style of upper case keywords is preferable
for teaching.

In my class, I see that most students use the standard style (I encourage
but do not insist on it, I should have insisted). A few students who are
used to upper case keyword style in Pascal persist in using it, and
a few who are new to Ada and Pascal copy the style in the book. Some
other students know Pascal well, but have learned from books with lower
case keywords, so remain in that style (in general people tend to stick
with whatever style they learn first in my experience, even if imported
from another language).

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

lars.farm@ite.mh.se (Lars Farm) writes:
>I have seen so many styles over the years, and so many heated debates
>about the subject that I am convinced that this is not a small point to
>the individual. Most of us have strong opinions. You obviously have. I
>do[1][2] and Michael Feldman seems to have opinions too. Interestingly
>all three of us have different opinions on what is and is not readable.
>There is no right or wrong. There is only opinion. There will never be
>consensus over an entire user community. 

"Right" and "wrong" there may not be, but there _are_ "better" and
"worse", and for a given set of intended readers, which style is
more effective for communication can be objectively measured in fairly
obvious ways.

I note that my own personal *preference* is for lower_case_identifiers,
and for many years have stubbornly refused to follow the one-time C
convention of writing macro names in upper case.  However, when I write
Ada code I *do* follow the AQ&S guidelines, my own preferences notwithstanding.
Why?  Because when I write C code, I am writing for myself, but when I write
Ada code, I am writing to be *read* by other people who have access to the
AQ&S, so following the style in the LRM and SQ&S helps me communicate with
LRM-and-AQ&S-readers.  I would certainly expect the entire Ada community to
be aware of the AQ&S guidelines:  the price is unbeatable and the advice of
_all_ kinds (not just layout and capitalisation) is *extremely* handy.  I
can think of no Ada programmers who would *not* benefit from reading the
AQ&S.

It's a bit like natural languages.  There are "prestige" dialects, and
there are perfectly good dialects which nevertheless confine you to the
comic stage.  In the Ada community, there is only one "style" dialect
which enjoys "prestige", and that is the AQ&S dialect.

Write in lower_case, and people say "oh, you're a C hacker, aren't you?"
Write in UPPER_CASE, and if you're _lucky_, people will say "didn't you
know that the revised AQ&S dropped that recommendation as a mistake;
nowadays Ada programmers use Mixed_Case".
(Put every letter in lower case except for the first in a file and the first
after each semicolon, and you will have a consistent defensible style which
will confine you to the comic stage.  I have seen this style once.)

>I have come to accept that this is the way of things. Look at C or C++.
>A much larger user base and much larger diversity of styles and naming
>conventions. This is not because of language (it requires lower case
>keywords).

Actually, it _is_ because of language.  Ada is not case sensitive, so it
is possible to use the AQ&S conventions when _using_ a package whatever
convention was used to _write_ the package.  C is case sensitive, so the
case convention used by a module author is enforced on the module user,
like it or not.

>Allow different styles, learn to live with and even appreciate
>diversity.

P.J.O'Rourke, where are you when I need you?

Touchy-feely is all very well when you are talking about works of art,
although even then, the extreme artist-centred nature of Modernism
resulted in a lot of works of little or no appeal to anyone else.

We must never lose sight of the fact that programming languages
are *not* natural languages, they are artefacts built to serve a
very specific purpose:  a programming language is supposed to help
human beings communicate algorithmic intentions to other human
beings and to machines.  Anything which helps this is good.  Anything
which harms this is bad.  The kind of diversity here harms communication,
for several reasons.  One obvious point is that if X -vs- Y is left as
a matter of stylistic variation, then X -vs- Y is not available for
*communication*.

I once worked on an assembler that was worked on by four other people at
the same time.  We were using Burroughs Algol.  For almost any line in
that file, you could tell who wrote it.  In fact, since I changed my
style during that time, you could tell _when_ parts of it were written.
People indented by 2, 3, 4, or 5.  Some people wrote "f(x)" for function
calls, some wrote "f (x)", some "f( x )", and some "f ( x )".  And so it
went.  Well, there are more effective ways of keeping track of who wrote
what (like your initials punched in the last few columns of the card).

I agree that there is room for the personal in programming, but why not
spend the creativity on writing first-class comments instead?

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

mfeldman@seas.gwu.edu (Michael Feldman) writes:
>I find it interesting that out of a couple of dozen reviewers of the
>two books we are discussing, NONE objected to the upper-case reserved
>words. These were not Ada dummies; they saw the logic behind what I was
>doing, and went along with it. Every reviewer was an active teacher of
>Ada in intro courses.

There is a non-sequitur here.
From the fact that they did not *object*,
you *cannot* infer that they saw your logic,
or that they "went along with it".
If they specifically *said* in their reviews that they
saw the logic or were happy with the result
(as opposed to reluctantly accepting it because of the
book's other merits) then you can infer these things.
The most you can infer from silence is that they didn't
consider it _enough_ of a problem to object about.

I also note a little bit of selection here.
Concerning the book "Ada 95 Problem Solving and Program Design",
which is the only CS1 book of yours I've seen,
one reviewer did *not* see the logic, did *not* go along,
and *did* complain.  I know, because that was me.
Perhaps you are referring to pre-publication reviewers.

Again, I must stress that Feldman's books have great merits.
My position is like the Frenchman in the 18th century who was
about to propose to a woman when he saw a louse crawl out of
her wig.  Sometimes small things loom large.

>I think it matters in dealing with first-term students. If the community
>is THAT outraged, I'll certainly consider changing it in the next edition.

There are three issues here, and they are different.
(1) Will protest die down if you make a change?
(2) Will more people buy your books if you make a change?
(3) Will students learn better if you make a change?
You are insisting on your present scheme because of (3), and you are
exactly right in your attitude.  If you are *factually* right as well;
if someone can come up with good-looking *evidence* that putting keywords
in caps is better for our students than putting keywords in lower case;
then I will switch to your still and beg you to stick to it.

If.

>It's a small point in the larger community; I maintain it is a helpful
>style for first-year students.

I can't speak for anyone else, but you can silence me *completely* on
this topic and convert me to your style *by showing me the experimental
evidence*.  It should be a fairly straightforward experiment to perform.
(Although double-blind is clearly out of the question...)

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Richard Pattis]

Since this discussion is still ongoing (and civil), I'd like to support Mike's
position on capitalized reserved words with the following observations, as
a long time CS1 instructor. I'll try to be short and non-redundant; but I
have read only most, not all the messages on this topic.

1) On the Ada Standard for reserved words (my LRM has been in moving boxes
for 4 months and won't be available for another 3): If I remember correctly,
the reserved words are not only lower case, but appear in bold face. Thus, the
intent is that they stand out. If most Ada IDEs (used by CS1 students) support
a bold face convention (both in the editor and when printing source files)
then I'd say to use that style; but if not (I haven't written Ada for 2 years,
so I'm not up on the technology), all caps is a good way to make reserved
words stand out.

2) And, reserved words do need to stand out in CS1. Much of the course
concerns learning the meanings of these words, which also act as roadmaps
to beginners for understanding code - because much of CS1 concerns algorithms
embodied in (nested) control structures. As students progress, abstractions
start to play a larger role, and the importance of reserved words diminishes,
and so can their prominence.

3) Final comment to all CS1 instructors: show these discussions to your
students. Personally, I'm less interested in the outcome of the discussion
(who wins) than seeing Ada luminaries (and passionate ones at that) marshaling
their mental powers to debate issues of style, and increase our awareness of
the importance of writing readable code.

  I frequently tell students that for individual projects, I don't care what
style they use, so long as it is consistent and can be defended - and I do
ask them to defend theirs and criticize mine when the styles diverge. Again,
I am less interested in who is "right" and more interested in whether the
students can present a well reasoned argument about the appropriatensess of
the style they selected. That skill is more important than learning the
"right" style in CS1.


Rich

PS: I'm now in Pittsburgh (although I still read newsgroups at UW, where I
happened to see this post) where my e-mail account is pattis@cs.cmu.edu

Re: Looking for good Ada95 book

[Michael Feldman]

In article <56paj4$bu0$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:

>There is a non-sequitur here.
>From the fact that they did not *object*,
>you *cannot* infer that they saw your logic,
>or that they "went along with it".

Some were silent; others explicitly said the choice was OK.

>If they specifically *said* in their reviews that they
>saw the logic or were happy with the result
>(as opposed to reluctantly accepting it because of the
>book's other merits) then you can infer these things.

Right.

>The most you can infer from silence is that they didn't
>consider it _enough_ of a problem to object about.

Right, and they were paid (by the publisher) to object if they 
saw anything worth objecting about.

>I also note a little bit of selection here.
>Concerning the book "Ada 95 Problem Solving and Program Design",
>which is the only CS1 book of yours I've seen,
>one reviewer did *not* see the logic, did *not* go along,
>and *did* complain.  I know, because that was me.
>Perhaps you are referring to pre-publication reviewers.

Yes, sorry - I thought it was obvious. Post-publication reviews
are good feedback for the next edition, but next editions typically
happen several years apart.

>Again, I must stress that Feldman's books have great merits.
>My position is like the Frenchman in the 18th century who was
>about to propose to a woman when he saw a louse crawl out of
>her wig.  Sometimes small things loom large.

True enough, and I've certainly heard everyone's points here.
In a published book (as opposed to, say, a web site:-)) major
changes happen with each new _edition_. Typos get fixed when
the book is _reprinted_ (and the book is now in its 3rd
printing), but a wholesale change like the keyword capitalization
is not a typo.

>There are three issues here, and they are different.

>(1) Will protest die down if you make a change?

There will always be something to complain about in a book. We'll have to
wait a couple of years to see, because that's how long it'll be till
there's any change.

>(2) Will more people buy your books if you make a change?

Dunno. We'll see how the various competitors make out. Certainly if
some current or potential adopter says "we're switching to Mr. <name>'s
book, and Feldman's horrible shouted keywords is an important reason",
that will be pretty good evidence to answer yes to your question.

While I am certainly happy when individual programmers buy my stuff
in Borders or other "trade bookstores", they are not the main market 
for a book like this. CS1 books are written for higher-ed courses,
and it's the _teachers_ that adopt them for their classes, not the
students.

>(3) Will students learn better if you make a change?

This cries out for a controlled study, but I'll leave that to someone
else. Meanwhile, I've explained _why_ I made the choice I did, so we
might as well move on to more interesting things because no change
will happen for a couple of years anyway.

>You are insisting on your present scheme because of (3), and you are
>exactly right in your attitude.  If you are *factually* right as well;
>if someone can come up with good-looking *evidence* that putting keywords
>in caps is better for our students than putting keywords in lower case;
>then I will switch to your still and beg you to stick to it.

As I said, many Pascal teachers have used this style, and not just for
historical reasons. I'm following that tradition (at least in this
edition).

>I can't speak for anyone else, but you can silence me *completely* on
>this topic and convert me to your style *by showing me the experimental
>evidence*.  It should be a fairly straightforward experiment to perform.
>(Although double-blind is clearly out of the question...)

Well, it would be pretty hard, actually, because you'd need two 
otherwise-identical versions of all the materials, including the book -
one with my keyword style, the other with lowercase. In a controlled
study (I've done some...) one needs to be careful to hold everything
constant but the variable you're measuring. It's a nice idea, but
in this case it's logistically intractable.

Can we put this issue to bed, finally?

>Mixed Member Proportional---a *great* way to vote!

I agree, and I like Australia's compulsory voting, especially after
our ridiculously low turnout here. I'd settle for a none-of-the-above
line on the ballot. More than 50% here voted that line by staying home.:-)

>Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Mike Feldman

Re: Looking for good Ada95 book

[Do-While Jones]

Rich makes the valid point:

>
>2) And, reserved words do need to stand out in CS1. Much of the course
>concerns learning the meanings of these words, which also act as roadmaps
>to beginners for understanding code - because much of CS1 concerns algorithms
>embodied in (nested) control structures. As students progress, abstractions
>start to play a larger role, and the importance of reserved words diminishes,
>and so can their prominence.
>
>

That is certainly true from a student/instructor point of view.  But I say, 
"Different strokes for different folks."  As a maintainer of software, I 
would rather have the reserved words fade into obscurity.  That is, I prefer

procedure VIRUS is
begin
  DESTROY_THE_DISK;
end VIRUS;

to 

PROCEDURE virus IS
BEGIN
  destroy_the_disk;
END;

From my point of view, reserved words are just noise that must be removed 
to obtain the information.  When reserved words are emphasized I must 
expend more effort to ignore them.

One of the wonderful things about Ada is that she doesn't put programmers 
in a style straitjacket.  You can use whatever style emphasizes the 
things that are important to you.

Do-While Jones





-- 
            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

Re: Looking for good Ada95 book

[John English]

Richard Pattis (pattis@cs.washington.edu) wrote:
: Since this discussion is still ongoing (and civil), I'd like to support Mike's
: position on capitalized reserved words with the following observations, as
: a long time CS1 instructor. I'll try to be short and non-redundant; but I
: have read only most, not all the messages on this topic.
: [...snip...]

OK, here's another contrary view to keep the pot boiling.
If you use all-caps, procedure HELLO_WORLD might be mistyped
near-invisibly as procedure HELL0_W0RLD which would give rise
to some very puzzling (to a beginner) errors. However, procedure
Hello_World and procedure Hell0_W0rld are visibly distinct...
(Oh well, I suppose I ought to make the counter-argument for
fairness' sake: procedure HELLO is easy to distinguish from
procedure HE110... :-)

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------

Re: Looking for good Ada95 book

[Larry Kilgallen]

In article <56uqhq$5tf@saturn.brighton.ac.uk>, je@bton.ac.uk (John English) writes:

> OK, here's another contrary view to keep the pot boiling.
> If you use all-caps, procedure HELLO_WORLD might be mistyped
> near-invisibly as procedure HELL0_W0RLD which would give rise
> to some very puzzling (to a beginner) errors. However, procedure
> Hello_World and procedure Hell0_W0rld are visibly distinct...
> (Oh well, I suppose I ought to make the counter-argument for
> fairness' sake: procedure HELLO is easy to distinguish from
> procedure HE110... :-)

Both of those possibilities make me prefer languages which do not
declare variables behind my back in response to a reference...

...and of course prefer compilers which provide more than
a binary indication regarding whether errors were found in
my program :-)

Larry Kilgallen

Re: Looking for good Ada95 book

[FerretWoman]

pattis@cs.washington.edu (Richard Pattis) wrote:

>1) On the Ada Standard for reserved words (my LRM has been in moving boxes
>for 4 months and won't be available for another 3): If I remember correctly,
>the reserved words are not only lower case, but appear in bold face. Thus, the
>intent is that they stand out.
 Yes, I believe they are in bold in the LRM

>2) And, reserved words do need to stand out in CS1. Much of the course
>concerns learning the meanings of these words, which also act as roadmaps
>to beginners for understanding code - because much of CS1 concerns algorithms
>embodied in (nested) control structures. As students progress, abstractions
>start to play a larger role, and the importance of reserved words diminishes,
>and so can their prominence.

>3) Final comment to all CS1 instructors: show these discussions to your
>students.

As a student currently learning Ada, I must admit that I really do
like having the reserved words in capital letters.  It makes it easier
to not only remember the words, but also what order to put them and
what they do in the program.

We are required to use capital letters for reserved words in any code
we turn in.

Re: Looking for good Ada95 book

[Richard A. O'Keefe]

Ferretwoman@worldnet.att.net (FerretWoman) writes:
>As a student currently learning Ada, I must admit that I really do
>like having the reserved words in capital letters.  It makes it easier
>to not only remember the words, but also what order to put them and
>what they do in the program.

>We are required to use capital letters for reserved words in any code
>we turn in.

This is perhaps the most valuable posting so far; we now have *evidence*
that one student benefits from upper case keywords.

However, one thing is not clear.  I take it that you have never been taught
Ada using the LRM/AQ&S "keywords are lower case, everything else is Mixed"
style.  Why do you say it is "being in upper case" that helps, rather than
"being visibly distinct"?  In the LRM/AQ&S style, keywords and other words
never ever look alike:  all and only keywords begin with a lower case letter.
What exactly _is_ the style you are being taught with?
If keywords are upper case, and other words are Mixed case, I would have
expected that to be *harder*, because then you have to look at the 2nd
letter to see whether it's a keyword or not, whereas with the LRM/AQ&S
style, it is always enough to look at the 1st letter.

Also, you do not tell us what editor(s) you use to view/modify/create Ada
code.  On the black and white screens I use, editors can put keywords in
bold or underline them.  On the colour screens many students use, editors
can put keywords in a special colour.  We have an Ada->HTML filter so that
all the Ada code I handed out to 2nd year students were printed with bold
keywords &c, and could be viewed on-line the same way.  (Or, with lynx,
with underlined keywords.)

Nor do you tell us whether the style you were using was the same as the
style in the textbook, or whether you were ever shown code in the LRM/AQ&S
style.

So it is a little bit hard to figure out what exactly your evidence is
evidence _of_.  Does it, for example, mean that

	- someone being taught from a textbook with upper case keywords
	- using only non-colouring editors (e.g. not Emacs, not Alpha,
	  not an IDE)
	- and not ever being shown material in the LRM/AQ&S style
	- finds *some* visible distinction between keywords and other words
	  useful, and doesn't know whether some other distinction might be
	  as good or better?

Please don't take this as an attack.  I think your posting was an excellent
thing, and I really would be grateful if you would fill in a bit more detail.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Looking for good Ada95 book

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>If keywords are upper case, and other words are Mixed case, I would have
>expected that to be *harder*, because then you have to look at the 2nd
>letter to see whether it's a keyword or not, whereas with the LRM/AQ&S
>style, it is always enough to look at the 1st letter.

People don't read one letter at a time.  If you show someone a word for
a very brief time period, my guess is that they will probably have more
chance of noticing whether the word is in ALL UPPERCASE than they have
of telling you whether the first letter was uppercase.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.