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

[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

[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 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

[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

[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

[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

[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

Silliness (was: Looking for good Ada95 book)

[Adam Beneschan]

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! 

Gee, this thread is making me feel old.  Old, because I used to work
as a COBOL programmer, back when our programs had to be put in on
punch cards, which couldn't handle lower case at all.  So from having
to work for three years with listings that were constantly shouting at
me, I should have gone deaf years ago.

But then again, the programs never seemed like they were shouting,
because COBOL programmers were always polite and put periods at the
end of their sentences.  Even when we got mad and wanted to end our
sentences with an exclamation point, or two or nine, 

    ADD A TO B GIVING C, DAMMIT!!!!!!!!!

the compiler would never accept this, always sending us back error
messages like "Don't raise your voice with me or I'm going to reject
your whole program".  So we kept ourselves in check and programmed
politely, even though we had to program in loud voices due to a
deficiency in the computer's auditory system that prevented it from
hearing lower-case.

On the other hand, Ada programmers tend to end all their statements
with semicolons, which means they aren't really statements at all,
since a semicolon implies that there's a second half of the sentence
coming up; but that never seems to happen in Ada.  You can read a
whole program and keep seeing semicolons, which means there's more to
come, but then you hit the last semicolon and there's nothing more
after it and you end up wondering, did the programmer intend to say
something more and just forget?  So you're just left there hanging.
Oh, well.  I suppose there are worse things; after all, ending a
sentence with a semicolon isn't half as wishy-washy as ending one with
an ellipsis . . .

:)
                                -- Adam

Re: Silliness (was: Looking for good Ada95 book)

[Richard A. O'Keefe]

adam@irvine.com (Adam Beneschan) writes:

>Gee, this thread is making me feel old.  Old, because I used to work
>as a COBOL programmer, back when our programs had to be put in on
>punch cards, which couldn't handle lower case at all.  So from having
>to work for three years with listings that were constantly shouting at
>me, I should have gone deaf years ago.

Actually, this is wrong.  Punched cards can handle lower case just fine.
Maybe your card _punch_ couldn't, but the punched _cards_ could, and so
could the reader.  I still have a couple of old S/370s quickrefs somewhere
(a yellow one and a green one) and they list card codes for all the EBCDIC
characters.  That's for 80-column cards; the 96-coumn cards used ASCII.
The problem was most likely your printer.  When I was an undergraduate I
used a B6700, which used EBCDIC, so it was quite straightforward to enter
lower case, but our line printers couldn't _print it_.

A convention that is appropriate when you have only one case is not
appropriate when you have more than one case.  I look at some of my
old listings, and wonder "how did I ever cope with this stuff"?


>    ADD A TO B GIVING C, DAMMIT!!!!!!!!!

>the compiler would never accept this, always sending us back error
>messages like "Don't raise your voice with me or I'm going to reject
>your whole program".

For COBOL, this is a joke.  For Intercal, the occasional "PLEASE" modifier
_is_ demanded by the compiler, and it _will_ reject your program without
them!

>On the other hand, Ada programmers tend to end all their statements
>with semicolons, which means they aren't really statements at all,

No, it just means they are _clauses_, not _sentences_.

Burroughs "NDL" (Network Definition Language) was a special purpose
language for programming the attached Datacom Processor.  Broadly
speaking, the syntax was _very_ close to Algol 60, except that statements
ended with full stops.  Theoretically, an entire source file in a language
like Ada or C or Pascal is a single "sentence" in the grammar; I suppose
we should prefer Pascal because Pascal sentences _do_ end with a full stop!

 (:-) (:-) (:-) (:-) (:-)

-- 
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

[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

[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

[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

[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

[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

[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

[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

[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

[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: Silliness (was: Looking for good Ada95 book)

[Chris Morgan]

In article <55mcmd$63c@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes:

   On the other hand, Ada programmers tend to end all their statements
   with semicolons, which means they aren't really statements at all,
   since a semicolon implies that there's a second half of the sentence
   coming up; but that never seems to happen in Ada.  You can read a
   whole program and keep seeing semicolons, which means there's more to
   come, but then you hit the last semicolon and there's nothing more
   after it and you end up wondering, did the programmer intend to say
   something more and just forget?  So you're just left there hanging.
   Oh, well.  I suppose there are worse things; after all, ending a
   sentence with a semicolon isn't half as wishy-washy as ending one with
   an ellipsis . . .


But you are forgetting about the requirement to link the program. Various
units can be linked as the main program, and indeed multiple units can be
visible to the compiler each of which could be linked. Whilst there is some
uncertainty, they all naturally break off mid-sentence in case they are
merely library units to be linked with some other main unit.

So, you do a link and tell it to use, say, my_main_proc as the main
unit. The never-ending sentence you mention is terminated by this
nomination, so conceptually the linker puts a full stop (period for
Americans) in place of the last semicolon of this unit and then completes
the link with a nice well-formed program sentence.

Chris
-- 
Chris Morgan                   
http://www.mihalis.demon.co.uk/

Re: Silliness (was: Looking for good Ada95 book)

[bill.williams]

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

> adam@irvine.com (Adam Beneschan) writes:
> 
> >Gee, this thread is making me feel old.  Old, because I used to work
> >as a COBOL programmer, back when our programs had to be put in on
> >punch cards, which couldn't handle lower case at all.  So from having
> >to work for three years with listings that were constantly shouting at
> >me, I should have gone deaf years ago.
> 
> Actually, this is wrong.  Punched cards can handle lower case just fine.
> Maybe your card _punch_ couldn't, but the punched _cards_ could, and so
> could the reader.  I still have a couple of old S/370s quickrefs somewhere
> (a yellow one and a green one) and they list card codes for all the EBCDIC
> characters.  That's for 80-column cards; the 96-coumn cards used ASCII.
> The problem was most likely your printer.  When I was an undergraduate I
> used a B6700, which used EBCDIC, so it was quite straightforward to enter
> lower case, but our line printers couldn't _print it_.

I'm feeling pretty ancient today as well. When I was young and foolish
we had hand card punches - a button, attached to a blade for each
row on the card. This gives you two reasons for not using lower case:
first the printer won't print it anyway, and second your fingers get
tied (even more :-) trying to punch the right code.

Bill

-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 242003

Re: Silliness (was: Looking for good Ada95 book)

[Michael Feldman]

In article <RALW.96Nov8143820@vulcan.gecm.com>,
 <bill.williams@gecm.com> wrote:

>I'm feeling pretty ancient today as well. When I was young and foolish
>we had hand card punches - a button, attached to a blade for each
>row on the card. This gives you two reasons for not using lower case:
>first the printer won't print it anyway, and second your fingers get
>tied (even more :-) trying to punch the right code.

In Montgomery County, Maryland, and many other places in the US,
we use a voting system that uses hand-powered card punches very
similar to the ones you remember. Move the pointer to the column
you want, press down on the lever, presto - a hole in a punch card!

These things are quite inexpensive, and make it much faster to vote.
Before they switched to this system, a polling place had 2-4 big
voting booths with big machines in them. Now my polling place has
about 20 little booths with the card punches. No more queues!

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

[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

[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]

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

[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

[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

Capitalization Entropy (was: Looking for good Ada95 book)

[Scott James]

I do hate to introduce mere technical (sort of) details into this
political discussion on capitalization but it is interesting (to me at
least) that a subset of these different styles can be analyzed from an
information point of view.  For my measure of information, I use
*intended* capitalization.  The three styles in question, summarized
by Lars are:

   (1) all_lower_case_identifiers (with intended capitalization)
   (2) Mixed_Case_Identifiers     (with intended capitalization)
   (3) ALL_UPPER_CASE             (well... you get the idea)

The claim is that case (1) contains the most information according to
the intended capitalization metric.  Examples of this have already
been given in this very thread but I will summarize quickly with an
example:

  (1) this_is_an_IO_package_I_got_from_Fred 
  (2) This_Is_An_IO_Package_I_Got_From_Fred 
  (3) THIS_IS_AN_IO_PACKAGE_I_GOT_FROM_FRED 

This has consequences when converting between the styles.
Assume the obvious (simplest) conversion programs between (1),(2),(3).

Going from (3) --> (?) --> (3) we arrive at the same data.
Going from (2) --> (1) --> (2) we arrive at the same data.
Going from (2) --> (3) --> (2) we lose the capitalization of "IO"
Going from (1) --> (2) --> (1) we lose the capitalization of "I" and "Fred"
Going from (1) --> (3) --> (1) we lose the capitalization of "I","IO","Fred"

Thus, these styles are well ordered according to capitalization
entropy (any Comp Sci looking for a Master's Thesis?  You can
borrow my phrase, ... just kidding ... I hope), that is, one may
convert without losing information in only one direction.   


     But while we are on the topic of politics   :-) ...


begin Lars: 

   ... 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.

end Lars:

This quite hits the nail on the head as it were.  The point being
really whether this whole thread has been about:

(a) it's good to have in house discipline and accept conventions

(b) it's good that *all* Ada programmers follow the Mixed_Cap 
    convention.

Personally, I can't agree with (a) more, but (b) seems a bit hard to
swallow (for entropic and readabily issues).  I thus wonder how many others
out there are a bit leary when they see:

begin Dewar:

   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!

end Dewar:

Incidentally, is it my imagination or was there a dissenting
capitalization opinion in the Ada83 style guide?  I seem to
have misplaced mine and now only have Ada95 style guides.

Re: Capitalization Entropy (was: Looking for good Ada95 book)

[Robert A Duff]

In article <56dodr$alf@client3.news.psi.net>,
Scott James <james@sandy.mcci-arl-va.com> wrote:
>Incidentally, is it my imagination or was there a dissenting
>capitalization opinion in the Ada83 style guide?  I seem to
>have misplaced mine and now only have Ada95 style guides.

RM83 recommended lower-case reserved words, and ALL_CAPS_IDENTIFIERS.
RM95 recommends lower-case reserved words, and Mixed_Case_Identifiers.
Both use bold-face for reserved words, but both recognize that lots of
folks don't have such fancy editors, as can do bold face.

Colonel William Whittaker (now retired) strongly objected to the "new"
capitalization style in RM95.  So the change was not agreed upon
unanimously.  But pretty close -- I don't remember *anybody*
recommending all lower-case identifiers, and I don't remember anybody
other than Col Whittaker recommending sticking with the Ada 83 ALL_CAPS
style.  I do remember some people insisting on freedom -- i.e. that the
RM recommendation should be (merely) a recommendation, so they could do
what they like.

I also know that Smalltalk programmers don't fight these silly battles.
Class names *must* start with a capital letter, and method names *must*
be lower case, and compilers enforce these things, and nobody complains.
In Smalltalk, it's not a "style" issue.

If project-wide conventions are good, surely language-wide conventions
are better?  (I mean, when we're talking about LITTLE things, like
case-conventions, where it's got nothing to do with application areas,
and everything to do with personal preference, and what people are used
to.)

The nice (;-)) thing about this issue is that everybody can understand
it, and so everybody has an opinion.  If you ask people about whether
unconstrained-generic-formal-discriminated-task-aggregates ought to be
fungified, then you'll get less contention.

- Bob

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

[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

[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 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

[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.

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

[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

Testing teaching belief?

[Richard A. O'Keefe]

I wrote
>>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...)

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

>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?

I have changed the subject line, because I now think we have reached
something we can agree on and that is worth discussing further.

What I think we can agree on is that

 - it is better to have evidence that what we do in teaching works

 - evidence about what some teachers for a different language have
   fashionably done (especially when books *not* following that
   fashion seem to be as common as ones that don't) is evidence
   about what _teachers have done_, not about what _students have learned_
   or _how well_ they learned it

 - perhaps the things most urgently in need of experimental testing
   are the prejudices we _share_, rather than the prejudices we dispute,
   because at least the latter undergo rational/critical discussion.

 - if it were economically feasible to perform such a test on this or
   any other topic, it would be worth doing.

But there is something here that we disagree about.  I believe that it
should be fairly straightforward to perform this experiment, and Feldman
believes it would be "pretty hard".  I hope that the only reason we
disagree about this is that it never occurred to me that subjects in
such a test would be using the publisher-bound version of a book.
What I have in mind is taking the source form of all materials the
students see, which would be
   (La)TeX for the book, or possibly SGML
   .adb and .ads files for the code
   .html files for other on-line documentation
and automatically generating the two variants from the common sources.

With respect to the book, I would expect the markup to look something
like this:
	Ada word	(La)TeX		SGML? (suggest better use!)
	keyword		\kw{keyword}	<kw>keyword</kw>
	Attribute	\atb{Attribute}	<atb>Attribute</atb>
	Variable	\var{Variable}	<var>Variable</var>
	Type		\typ{Type}	<typ>Type</typ>
	Subprog		\fun{Subprog}	<fun>Subprog</fun>
	Package		\pkg{Package}	<pkg>Package</pkg>
which one would certainly want to do so that attributes, types, and
subprograms could be automatically indexed.  From a source with markup
like this, it is easy to automatically produce a variant with whatever
capitalisation and looks you want.

If one of the variants happens to correspond to the published version
of a book, the students using that variant are still given a locally
printed and bound version of the material.  (If we did that here, it
would probably be CHEAPER for the students than buying an overseas book.)

With respect to the compilable sources, programs like aimap and my own
a2h already manage this translation in everything except the comments,
and putting markup in the comments in the master version of the sources
from which the student-visible sources are derived is tedious rather than
difficult.  A sufficient markup would be \ada{text} or <ada>text</ada>
in many cases.

With respect to on-line documentation, one would use markup as outlined
above, and would automatically generate appropriate variants in standard
HTML.

All of this applies to extra handouts and of course examination scripts
as well.

If you want to test N style variants, you need one properly marked up
master copy of everything, and N automatically derived variants, so
the disc space required is (N+1) times that required for a single
variant.  If students use a UNIX system, it is possible to give each
student a symbolic link to the appropriate directory, so that each
student sees ~/CS100 as the place to look for CS100-related documents.
Nothing else in the computer administration needs to vary between
students.  If students use a NOVELL server from DOS boxes, it is
possible to set things up so that each student has a drive, K: say,
bound to the right directory on the server.

If you already have enough students to need to run several streams,
there are your groups ready for your several treatments.  (You may
not be able to randomly assign students to groups, but you _can_
randomly assign _treatments_ to groups, which might be enough.)

A wild guess of the cost of performing such an experiment, over and
above the normal costs of running a CS1 course, might be on the order
of A$20 000.  I already know that the cost of converting all the Ada
sources for such a course is on the order of two working days, say A$300.
Converting a book that is already in (La)TeX or SGML form would be
rather more expensive, but might be worth it.  I note, for example,
that  "Ada 95 Problem Solving and Program Design" does not have a
separate index of Packages, Subprograms, or Types, things that
definitely help when you're trying to find your way around an 814 page book.
Some of the printing costs might be recovered from the students, which
sounds unfair until you realise that it might actually save them money.

So you see I _have_ thought about this and don't see anything
"logistically intractable" about it.  

If someone who has actually _done_ some experimental studies of this
sort can point out things I've missed and suggest a more realistic cost,
I think we may make progress.

Personally, I think upper case keywords are ugly and almost unreadable;
they are one of the reasons I have never bothered downloading and trying
Modula 3.  If the consensus were that we ought to use upper case keywords
in Ada, I would lose some of my motivation to oppose the proposed switch
to Java as a first year language.  But I ought not to let my personal
tastes, or the unsupported tastes of earlier textbook writers, stand
against evidence about what is really best for the students, and if it
_is_ practically possible to get such evidence one way or the other, I
want to see it happen.  (If there were evidence that upper case keywords
was better for first year students than lower case, I would be able to
use that to fight off Java!)

So I would really appreciate it if we could have a thread on what would
be involved in doing a credible experiment to get evidence about keywords.
If we can come up with a plausible design, maybe it can be taken to a
funding agency and someone can actually try it.  (This is not a promise
to do it myself, because I am not in a position to make such promises.
All I can do is nag.  Count it as a promise to nag.)

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

Re: Testing teaching belief?

[Robert Dewar]

Richard says

"But there is something here that we disagree about.  I believe that it
should be fairly straightforward to perform this experiment"

If you think it is fairly straightforward to perform this kind of experiment,
I can only guess that you have little experience with attempts to evaluate
teaching of this kind. They are *very* difficult to perform for a whole
host of reasons, and there is a large literature that discusses this
difficulty. The fundamental problem is that there are too many variables,
and people are too easily influenced. If you think otherwise, please
cite comparable studies that you think prove your point. Note that the
issues are not statistical here .....

Re: Testing teaching belief?

[Robert Dewar]

With regard to Richard's experimental design, it is missing a HUGE element.
Students learn from the teacher as well as the text book. There is no way
that you can normalize the teaching effect in a case like this, without
doing hundreds of parallel experiments.

Even then, there is an asymmetric quality that may fundamentally bias
your results. Those who think that it is important to emphasize keywords
with upper case letters have a particular view of how to teach a language.
I for example find that emphasizing keywords as important is totally
unnecessary, I regard that as a minor syntactic detail, and my teaching
of any programming language does not focus on the syntax.

This means that the whole business of upper case keywords may reflect
a fundamental difference in approach and style, and I don't see how to
normalize that. Yes, you could try to minimize the effects by having
Feldman teach from a lower case keyword book and still furiously
emphasize the keywords, and having Dewar teach from an upper case
keyword book, using the style of underplaying syntactic emphasis.

Or you could have Feldman teach from both books, promising not to let the
fact that he finds one book preferable influence what he says.

But in either case, the outcome would more likely depend on the exact
extent to which the teachers managed to neutralize other factors, 
something that you cannot measure easily, if at all.

The call for objective evaluation in teaching methodologies is of course
a common one, but that does not make it easy to meet.

Rather than focus on such a small issue, why not address the more 
interesting issue. How can you show that teaching Ada is or is not
better than teaching C++ to first year students?

That's also a very hard question, but more interesting to answer! Here again
the trouble is that you get different inputs from the teachers. Those
teaching Ada tend to me more enthusiastic than those teaching C. That's
because generally you won't see Ada adopted as a first teaching language
unless at least one faculty member is enthusiastic about Ada, but you
will see C++ adopted by default with no one enthusiastic about it.

Even if you tried to find two equally enthusiastic teachers, you would find
that you were more likely to be measuring skill and enthusiasm of the
teachers than inherent pedagogical value of the language vehicle.

Re: Testing teaching belief?

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>With regard to Richard's experimental design, it is missing a HUGE element.
>Students learn from the teacher as well as the text book. There is no way
>that you can normalize the teaching effect in a case like this, without
>doing hundreds of parallel experiments.

What you are saying, in effect, is that we can *never* have
experimental evidence for *any* aspect of programming teaching.

I didn't mean to imply that it would be easy to do a *perfect*
experiment, only that it should be straightforward to do an
experiment from which something could be learned. 

Is it entirely impossible, for example, to find a teacher who is genuinely
open-minded about this issue?

And would a null result (which is what I actually expect) be uninformative?

>Even then, there is an asymmetric quality that may fundamentally bias
>your results. Those who think that it is important to emphasize keywords
>with upper case letters have a particular view of how to teach a language.
>I for example find that emphasizing keywords as important is totally
>unnecessary, I regard that as a minor syntactic detail, and my teaching
>of any programming language does not focus on the syntax.

>This means that the whole business of upper case keywords may reflect
>a fundamental difference in approach and style, and I don't see how to
>normalize that.

But the issue under question is not "whether to emphasise keywords or not"
but "whether to distinguish keywords by making them upper case or by
making them lower case".  It's precisely a teacher who *DOES* believe that
distinguishing keywords is important, but has an open mind about the best
way to do it, that we want.  I agree that "whether to emphasise keywords
or not" is an important question, but it is a *different* question from
the one I'm asking.  Let's spell it out:

	ASSUMING that it helps beginners to distinguish keywords
	H0: it makes little difference whether you consistently use
	    the LRM/AQ&S highlighting method (all and only keywords
	    are entirely lower case) or the UPPER highlighting
	    method (all and only keywords are entirely upper case;
	    I don't know what happens to acronyms).
	H1: using the LRM/AQ&S style improves concept learning
	H2: using the UPPER style improves concept learning.

(My prediction:  H0 cannot be rejected.)

I would expect people who don't think it important to highlight keywords
to have no trouble with adopting the LRM/AQ&S style.  All of the proponents
of upper case keywords for beginners we've heard from so far have said that
their reason for preferring a non-LRM/AQ&S style is in order to highlight
keywords (which the LRM/AQ&S style *does* make visibly distinct).

>The call for objective evaluation in teaching methodologies is of course
>a common one, but that does not make it easy to meet.

Well, enlarging the question beyond the original proposal can always make
it look well-nigh impossible.

>Rather than focus on such a small issue, why not address the more 
>interesting issue. How can you show that teaching Ada is or is not
>better than teaching C++ to first year students?

I was thinking of a very limited question, where the factors you've
mentioned might possibly be controllable.  Now *you* are asking an
extremely general question.  People who select C++ have a very different
idea of what programming is about than people who select Ada.

Believe it or not, as I've mentioned before, I am co-supervising (with Dr
Isaac Balbin as principal supervisor) a Masters student who is addressing
a closely related but different question:

	- how can we tell whether our choice of first year language
	  is producing the benefits we hoped for?

He has surveyed a _lot_ of CS education literature, and found a great deal
on the reasons people give for why they chose or are about to choose a
particular language, but almost nothing on whether it actually _worked_.

>Even if you tried to find two equally enthusiastic teachers, you would find
>that you were more likely to be measuring skill and enthusiasm of the
>teachers than inherent pedagogical value of the language vehicle.

This is actually something we are aware of, which is one reason I was asking
about a limited experiment where only the particular _means_ of achieving an
agreed end in a single language and teaching style was to be tested.

For what it's worth, we do not expect this student to produce the final
answers, only to produce a thesis surveying what the _questions_ are and
providing a basis for further study.

It's a bit like software engineering:  it's hard to improve the product
without also improving the process.  We want very much to improve our
product, so we are looking at all sorts of ways of improving our process.
With strong pressure from C++ (it's hard to fight the "it won't get me a
job" belief, whatever truth there is in it) and growing pressure from
Java (it's also hard to fight the "new and sexy" effect; COBOL succumbed
to "how can we hope to be taken seriously as a university if we teach
COBOL?") we really would like to have _grounds_ for persisting with Ada.


For what it's worth, my own prejudice is that a heavy stress on keywords
is a very bad thing for students, because the next language they meet
will use different keywords.  I well remember the confusion of Pascal-with-
emphasis-on-keywords students meeting C.  They didn't understand "bounded
loop", they understood 'for', and C's 'for' was different, and of course
the difference between Pascal's 'case' and C's 'case' didn't help any.

There is, for example, a certain amount of keyword/concept confusion in
Feldman & Koffman, where p33 says "In Ada a program is called a PROCEDURE".
This text consistently uses italics when it introduces new technical terms,
and there are capitals in that sentence, not italics.  (Of course, some Ada
programs are implemented as functions, using quite a different keyword, so
the concept is the important thing.)  p39 says "There are many different
Get statements in the input/output libraries", but what the libraries offer
is Get _procedures_.  That's a similar confusion, but I think it has the
same cause.

[When I commented on the US-centric bias of this book before, I hadn't read
chapter 2 in detail.  It's _very_ strong in chapter 2.]

This may look like an attack on Feldman's book.  I hasten to point out that
the reason I picked it for comment here is that I *have* it, and I needed a
*good* book to make my point.

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

Re: Testing teaching belief?

[Debora Weber-Wulff]

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

: But the issue under question is not "whether to emphasise keywords or not"
: but "whether to distinguish keywords by making them upper case or by
: making them lower case".  It's precisely a teacher who *DOES* believe that
: distinguishing keywords is important, but has an open mind about the best
: way to do it, that we want.  I agree that "whether to emphasise keywords
: or not" is an important question, but it is a *different* question from
: the one I'm asking.  Let's spell it out:

I use the following rule in teaching Ada:
1) Thou shalt differentiate keywords and identifiers.
2) Thou shalt be consistent.

So I take off oints for mixing schemes, but let everyone do what
they want, as long as it is the same. In Software Engineering I make
the students state in a coding style sheet which style they will use.

In class, I tend to pass out copies of Feldman's programs (slightly
altered to get around that terrible US-centric touch ;-) using his
style. I thought it was ugly at first, but it grows on you - I've
used both his books (the CS1 and the CS2 one) now.

: [When I commented on the US-centric bias of this book before, I hadn't read
: chapter 2 in detail.  It's _very_ strong in chapter 2.]

: This may look like an attack on Feldman's book.  I hasten to point out that
: the reason I picked it for comment here is that I *have* it, and I needed a
: *good* book to make my point.

Must say he has GREAT exercies and EXPLAINS stuff at a level of detail that
actually sinks in - I have the feeling that the students are actually
learning something... 'course I can't prove this experimentally, but
just the same :-)

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

--
Debora Weber-Wulff (Professorin fuer Softwaretechnik und Programmiersprachen)
Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 
13353 Berlin, Germany        email: weberwu@tfh-berlin.de   
<http://www.tfh-berlin.de/~weberwu/> 

Re: Testing teaching belief?

[Robert Dewar]

Richard says

"In class, I tend to pass out copies of Feldman's programs (slightly
altered to get around that terrible US-centric touch ;-) using his
style. I thought it was ugly at first, but it grows on you - I've
used both his books (the CS1 and the CS2 one) now."


And that is a perfect example of my point. Yes, sure it grows on you.
ANY style grows on you, and with enough exposure becomes your preferred
style. It is harder than you think to make the transition from one style
to another once you get used to once style. I have seen experienced
programmers threaten to quit rather than change their style, and I have
seen managers acquiesce to such threats.

That is *precisely* why I prefer elementary text books to use a standard
style, I do not want a non-standard style "growing" on my students!

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

[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

[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

[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

[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.
===============================================================================