Grunt factor

Grunt factor

[Ted Holden]

From: munck@COMMUNITY-CHEST.MITRE.ORG (Bob Munck)
Subject: Techniques for Automatically Ignoring Ted Holden


>As a public service, I am preparing a series of short notes on ways you
>can cause messages from Ted Holden <ted@grebyn.com> to be flushed
>automatically, such that you need never again be aware that he exists.
>Karl's recent note to the contrary, Holden's other liabilities are not
>balanced by the slapstick humor.

... as if achieving such an effect were complicated.  I'd just hit the "n"
key myself...

>Of course, you could use "munck@mitre.org" and "Bob Munck" in the above
>to get rid of stuff from me.  But why would you want to?

Why indeed?  Again, simpler just to hit the "n" key.  But then, if I
did that, I'd miss out on lots of great articles, such as:

......................................................................

>From: munck@COMMUNITY-CHEST.MITRE.ORG (Bob Munck)
Subject: Use of "C/Ada" -- the C dialect of Ada


>We've all run into "FORTRAN/Ada" or "JOVIAL/Ada" in which FORTRAN or
>JOVIAL programmers forced to use Ada continue to write their "native
>language" but using the Ada equivalent and syntax.  It's usually
>worth the derision we give it.

those who live in glass houses...

>HOWEVER, I've run into a project of significant importance and cost in
>which the <grunt> programmers simply cannot, for reasons of contracting,
>schedule, and cost, be taught Ada the way we like to do it: teaching
>software engineering principles and incidentally using Ada.....

Your programmers have a skill which will still be saleable a year and a
half down the road;  the same is nowhere near obvious in your
case.  Face it, Bob; between yourself and your programmers, you're the
grunt.

By the way, I notice that most of you "Ada gurus" use the terms "software
engineering" and Ada as if they were synonyms;  you only need to read any
real software engineering book (such as Bertrand Meyer's 'Object-Oriented
Software Construction') past the first few pages to see Ada mentioned as
a sort of a first shot which fell short: a bad example.

>It occurred to me that there might be possible to get Ada from the
>initial development by having them use a C/Ada dialect.  Perhaps we
>could give them a handbook or pop-up HELP system in their editor that
>gives the Ada equivalent for the various C constructs that they might
>use.  Also, there could be Ada code skeletons, packages and generics,
>and coding guidelines.  I know, some things that are done in C can't be
>done easily or at all in Ada...

Some things which are done by aeroplanes cannot be done easily or at all
by trucks;  is there some reason why that should seem strange?  C is a
more powerful language than Ada, especially for dealing with UNIX systems,
which will soon include everything other than PCs and imbedded systems
(for which Ada doesn't work anyhow).  Suppose the boss flipped you the keys
to the truck and told you to drive over to Muenchen and pick up a load of
beer kegs.  Would you just start driving or would you think "Gee!, maybe
I'd better tell the boss about aeroplanes?"

>The situation is such that it would probably be possible to hire one or
>two Real Ada Gurus to set things up, write the pre-packaged stuff, and
>help the C programmers express themselves in simple Ada throughout the
>project.  Does this ring a bell with anyone out there?

Lots of em, unfortunately for taxpayers.  Sounds like another Ada screw-up
about to happen.


........................................................................


>>From: jnixon@andrew.ATL.GE.COM (John F Nixon)
>Subject: Re: Use of "C/Ada" -- the C dialect of Ada


>>munck@COMMUNITY-CHEST.MITRE.ORG (Bob Munck) writes:
>>
>>
>>>We've all run into "FORTRAN/Ada" or "JOVIAL/Ada" in which FORTRAN or
>>>JOVIAL programmers forced to use Ada continue to write their "native
>>>language" but using the Ada equivalent and syntax.  It's usually
>>>worth the derision we give it.
>>>HOWEVER, I've run into a project of significant importance and cost in
>>>which the grunt programmers simply cannot, for reasons of contracting,
>>>schedule, and cost, be taught Ada the way we like to do it: teaching
>>>software engineering principles and incidentally using Ada.

>>Well, I'm glad to know that there are things "of significant importance"
>>which aren't worth doing well.  *sigh*

>>If this is your honest evaluation of the prospects for the system, I suggest
>>you consider the alternative of simply not doing it.  There are plenty of
>>bad systems out there now; with this type of a start, I'm sure you will just
>>add to the total.  However, if you expect the best out of people, you just
>might get it.  Maybe the problem isn't "grunt programmers", but "grunt


Afraid we lost the article at this point.  The adjective noun pair needs to
be something like "grunt regulations", or "grunt yuppie pseudo-sciences,
such as software-engineering (Ada variant)", or some such.



Ted Holden
HTE

Re: Grunt factor

[Kim Shearer]

I was a hard core C fan, and still am, however I was forced in
the course of my job to program in ADA. I would have to say that
for large projects that do not make extensive use of the low
level facilities of C, One would be brain damaged to choose C
rather than ADA as the implementation language.

It may be difficult to hach in ADA but as a large system 
language it has some great ideas.

Looking forward to ADA 9X to see if it gets better, or worse.
I think an open mind is the name of the game.

Re: Grunt factor

[David Schneider]

In article <1533@wacsvax.OZ> kim@wacsvax.OZ (Kim Shearer) writes:
>
>I was a hard core C fan, and still am, however I was forced in
>the course of my job to program in ADA. I would have to say that
>for large projects that do not make extensive use of the low
>level facilities of C....It may be difficult to hach [sic] in ADA but....

I've found that bit-twiddling in Ada is fun, if that is what you're
referring to.  Of course, the twiddling I did was non-portable
(some ways are), but that's ok since they were highly specific
to the hardware (I was providing hw support for the OS).

I'm also very fond of being able to figure where something's declared
without having to grep an entire source database.  I ran across this
problem while maintaining some C code where I didn't have access to
a tags file.

I'm not really sure what you do mean by low-level facilities,
although my imagination runs away at certain uses of 'switch' and
'for'.

And while Ada forces you to be explicit about how other code accesses
you, there is nothing that prevents the code behind an interface
from showing a life of its own (that's a humorous way of describing
drastric changes).  *Of course, some people have critized the
explicit-interface idea as freezing a design too early.
They feel that you're unlikely to get an interface right at the
start of a project, and there's some merit to that idea,
but I don't find Ada's specification system as a handicap to changing
an interface, but rather a tool that ensures it is changed uniformly.

Well, I'd better step away from the soapbox before I turn into
kill-file fodder.

					Dave Schneider
					Friday before vacation, 3.16.90

*I've a feeling that Elements of Style calls for a paragraph break here,
but I'll risk damnation to avoid reformatting in vi when I should be
going home.  Imagine someone whose religion includes both Emacs and Ada.

					dps

GNU EMACS & Ada religions.

[Karl A. Nyberg]

In article <631@intelisc.nosun.UUCP> snidely@nosun.UUCP (David Schneider) writes:
> Imagine someone whose religion includes both Emacs and Ada.

I'll take that one as maintainer of the gnu-emacs-ada mailing list. If
there's anybody else interested in the elisp that has been written to
support Ada development with GNU emacs (particularly at the moment geared to
VADS on UNIX machines), drop a line to gnu-emacs-ada-request@grebyn.com.

-- Karl --

The only thing vi is good for is editing emacs configuration files... :-)