Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[John Woodruff]

>>>>> "Pat" == Pat Rogers <progers@NOclasswideSPAM.com> writes:
In article <712r19$rs5$1@supernews.com> "Pat Rogers" <progers@NOclasswideSPAM.com> writes:

    > Ehud Lamm wrote in message ...
    >> On Mon, 26 Oct 1998 dennison@telepath.com wrote:

    > <good points all>

    >> Still - Remember you can achieve all the run time checking
    > functionality
    >> in any language. It is just that in some languages you have to
    >> code
    > it
    >> explicitly. But you want your code to be of quallity - you just
    > have to do
    >> it.


    > Explicitly coded checks come at a price, though, that
    > language-defined checks may be able to avoid.  ......

Another consideration occurs when the programmer offers to code his
(her) own checks, in defense against the kind of errors that Ada's
checking prevents:

    > ...... In Ada, the fact
    > that the check is defined by the language means that we don't
    > explicitly write the it ourselves, and the optimizer then has
    > freedom to help us with performance.  Ironic, isn't it?

The programmer is setting out to write additional code, and that code
itself is susceptible to some defects.  Shouldn't we worry that these
defects injected into the *checking* code might lower the quality of the
product?

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

John Woodruff wrote in message ...
>>>>>> "Pat" == Pat Rogers <progers@NOclasswideSPAM.com> writes:
>In article <712r19$rs5$1@supernews.com> "Pat Rogers"
<progers@NOclasswideSPAM.com> writes:
>
>    > Ehud Lamm wrote in message ...
>    >> On Mon, 26 Oct 1998 dennison@telepath.com wrote:
>
>    > <good points all>
>
>    >> Still - Remember you can achieve all the run time checking
>    > functionality
>    >> in any language. It is just that in some languages you have
to
>    >> code
>    > it
>    >> explicitly. But you want your code to be of quallity - you
just
>    > have to do
>    >> it.
>
>
>    > Explicitly coded checks come at a price, though, that
>    > language-defined checks may be able to avoid.  ......
>
>Another consideration occurs when the programmer offers to code his
>(her) own checks, in defense against the kind of errors that Ada's
>checking prevents:
>
>    > ...... In Ada, the fact
>    > that the check is defined by the language means that we don't
>    > explicitly write the it ourselves, and the optimizer then has
>    > freedom to help us with performance.  Ironic, isn't it?
>
>The programmer is setting out to write additional code, and that
code
>itself is susceptible to some defects.  Shouldn't we worry that
these
>defects injected into the *checking* code might lower the quality
of the
>product?

Yes, any "extra" code is unfortunate, since it is just that much
more that can go wrong.

One does have to be careful, though.  Consider:

  function Next( This : Some_Discrete_Type ) return
Some_Discrete_Type is
  begin
    return Some_Discrete_Type'Succ(This);
  exception
    when Constraint_Error =>
      return Some_Discrete_Type'First;
  end Next;

Although the language will check that we don't "go off the end of
the world" when This is Some_Discrete_Type'Last, if some poor
maintenance programmer comes along and suppresses the check we are
in for Trouble.  In such cases the explicit, hand-coded check is
preferable, IMHO:

  function Next( This : Some_Discrete_Type ) return
Some_Discrete_Type is
  begin
    if This = Some_Discrete_Type'Last then
      return Some_Discrete_Type'First;
    else
      return  Some_Discrete_Type'Succ(This);
    end if;
  end Next;

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ehud Lamm]

On Wed, 28 Oct 1998, Pat Rogers wrote:

> One does have to be careful, though.  Consider:
> 
> function Next( This : Some_Discrete_Type ) return
> Some_Discrete_Type is
> begin
>   return Some_Discrete_Type'Succ(This);
> exception
>   when Constraint_Error =>
>     return Some_Discrete_Type'First;
> end Next;
> 
>  In such cases the explicit, hand-coded check is
> preferable, IMHO:
> 
> function Next( This : Some_Discrete_Type ) return
> Some_Discrete_Type is
> begin
>   if This = Some_Discrete_Type'Last then
>     return Some_Discrete_Type'First;
>   else
>     return  Some_Discrete_Type'Succ(This);
>   end if;
> end Next;
> 

In this example, I for one would think both approaches are viable. Maybe I
would even prefer the IF approach. 

This is not the example for misusing valdity checks. 

What I find ugy is things like this:

i:integer

if i<0 then <some error handling>

instead of
 i:Natural

This kind of coding style doesn't allow the reader to stop checking for
himself the i is indeed always non negative.

Ehud Lamm     mslamm@mscc.huji.ac.il

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[R. Kerr]

Rick Smith (ricksmith@aiservices.com) wrote:

> Of the comments attributed to Dijkstra, I have never heard a comment
> that was favorable toward any language! Is there a language that Dijkstra
> liked?

> Of which features of any language did Dijkstra make favorable comments?

> Based upon his comments, what languages might Dijkstra like today?

> Would Dijkstra have favorable comments for the OO languages, in
> particular?

I suppose Dijkstra, as one of the holy triumvirate who wrote the
seminal "Structured Programming" in 1972, did not find too abhorrent
the language used by co-author Ole-Johan Dahl in his chapter
"Hierarchical Program Structures".  That language was SIMULA, the most
influential ancestor of all OO languages.

Cheers....Ron

------------------------------------------------------------------------
 Ron Kerr, Computing Service,  Newcastle University, NE1 7RU, England.
 Tel. +44 191 222 8187  Fax. +44 191 222 8765  E-mail r.kerr@ncl.ac.uk
------------------------------------------------------------------------

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Matthew Heaney]

"R. Kerr" <R.Kerr@ncl.ac.uk> writes:

> I suppose Dijkstra, as one of the holy triumvirate who wrote the
> seminal "Structured Programming" in 1972, did not find too abhorrent
> the language used by co-author Ole-Johan Dahl in his chapter
> "Hierarchical Program Structures".  That language was SIMULA, the most
> influential ancestor of all OO languages.

This statement is a bit misleading.

Although the book "Structured Programming" credited to O.J. Dahl,
E.W. Dijkstra, and C.A.R. Hoare, Dijkstra only wrote the first chapter,
called "Notes on Structured Programming."
 
The third chapter, "Hierarchical Program Structures," was co-authored by
Dahl and Hoare.  Dijkstra was NOT a co-author of that chapter.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[R. Kerr]

Matthew Heaney (matthew_heaney@acm.org) wrote:
> "R. Kerr" <R.Kerr@ncl.ac.uk> writes:

> > I suppose Dijkstra, as one of the holy triumvirate who wrote the
> > seminal "Structured Programming" in 1972, did not find too abhorrent
> > the language used by co-author Ole-Johan Dahl in his chapter
> > "Hierarchical Program Structures".  That language was SIMULA, the most
> > influential ancestor of all OO languages.

> This statement is a bit misleading.

> Although the book "Structured Programming" credited to O.J. Dahl,
> E.W. Dijkstra, and C.A.R. Hoare, Dijkstra only wrote the first chapter,
> called "Notes on Structured Programming."
>  
> The third chapter, "Hierarchical Program Structures," was co-authored by
> Dahl and Hoare.  Dijkstra was NOT a co-author of that chapter.

A trifle pedantic methinks.  I meant that Dijkstra was co-author of
the book and, according to the English parsing rules I was taught, in
"Ole-Johan Dahl in his chapter", "his" should be bound to Dahl, not
Dijkstra.  I did not, therefore, suggest that Dijkstra was co-author
of chapter 3.

Cheers....Ron 
(another pedant when provoked :-)) 

Re: Software landmines (was: Why C++ is successful)

[adam]

In article <6renh8$ga7$1@nnrp1.dejanews.com>,
  ell@access.digex.net wrote:

> A 'return', at least in C/C++/VB, returns you to the place the current
> procedure was called from.  'goto' control flow can be endlessly channeled
> here and there and never has to return to where the initial linear control
> flow was originally diverted.  That seems to be a huge advantage of 'return'
> over 'goto'.

No, to me this seems to be a huge advantage of "return" over "using too many
goto's in your code that go every which way so that your code ends up looking
like spaghetti."  No one is supporting the idea of using that many goto's,
the way programmers used to.  Those who think goto's are OK think they should
be limited to certain specific situations, and your objection really doesn't
apply when goto's are used in that sort of careful, disciplined fashion.  Of
course, "goto" can be dangerous in the hands of an inexperienced programmer;
but so, for that matter, can every other construct of every language.

In the 22 years or so since programmers have started treating "goto" as an
evil, I've seen some pretty strange arguments purporting to explain *why*
goto's were bad.  The most bizarre one I've seen argued that if your code is
structured as follows:

         Transformation-1;  goto L;  Transformation-2;  L: ....

where Transformation-1 and Transformation-2 are sequences of statements or
something else that transform your current program state from one thing to
another, then the presence of "goto" in effect means that your code contains
the inverse function of Transformation-2, which cancels the effect of
Transformation-2.  The author offered this as an explanation why "goto" makes
code harder to understand.  I don't remember exactly where I read this, but it
was in one of the ACM publications.

Of course, this is nonsense.  There are good reasons why a researcher might
want to think of a "program" as a sequence of mathematical transformations on
the program state, but an ordinary programmer trying to write correct code,
or to read or maintain someone else's code, isn't going to think about things
that way.  That's why I'm skeptical about most of the arguments I see about
why GOTO IS EVIL.  There often seems to be an implicit assumption that
mathematical purity, or an aesthetically beautiful program structure, or
something similar, equals readability, but that isn't the case.  So when I
see statements like "'goto' control flow can be endlessly channeled here and
there and never has to return to where the initial linear control flow was
originally diverted", my reaction is, "So what?"  This argument contains no
explanation *why* this makes programs harder to work with.

So, personally, I think arguments against "goto" (or against any other
construction) should demonstrate things from the programmer's point of view.
That is, how does this EVIL NASTY construct actually make it harder for a
programmer to understand what's going on, or make it easier for a programmer
to miss something and write incorrect code?  If the argument doesn't address
the issue from that angle, it's worthless, IMHO.

Now, here are a couple arguments on the other side:

(1) Say you want to avoid the EVIL NASTY "goto" by putting the code into a
subroutine and using "return".	Well, you have to give the subroutine a name.
In place of the nested "if" causing the problem, you'll have a call to this
subroutine.  Now, when a programmer looks through the main line of code,
she'll see a call to this subroutine, and she'll have to know what it does. 
Can you give the subroutine a name that will make it obvious to the
maintenance programmer what's going on?

Sometimes you can.  But if all you're doing is extracting some code and
sticking it in a subroutine, most of the time you can't give it a good
descriptive name, since it reflects just a random sequence of statements and
not a concept that can be easily compartmentalized.  So in this case, IMHO
doing this is worse than using "goto", since it makes the program less clear.
 Of course, you can probably figure out a way to redesign the code to make it
clear, and your code will be more readable since it has smaller, more compact
subroutines that perform a well-defined purpose.  But this just illustrates
the importance of good design in general; a programmer who simply says
"RETURN is a lot better than GOTO" and moves code around just to avoid the
GOTO is unlikely to end up with a more readable and maintainable program.

(2) (This one is about "continue", since Charles Hixson later argued that this
was also superior to "goto" for the same reasons.)  If you have a loop that
looks like:

     while (blah-blah) {
          some-if-statements...
          some-more-if-statements...

          xxx;
          yyy;
          zzz;
     }

someone reading the program might assume that xxx, yyy, and zzz are always
going to happen before the loop repeats.  So if there's something new that
needs to be done during every loop iteration, it looks like you can just add
it to the end of the loop, after zzz.  If there's a "continue" statement
somewhere above that, this assumption is incorrect and your modification may
well be wrong.	If you replace the "continue" with a "goto", at least there
will be a label somewhere toward the bottom of the loop, alerting you to the
fact that you will have to decide whether to put the new code before or after
the label, or look for the place where this label is goto'ed.  In fact, this
is exactly why I stopped using "continue" when I was a C programmer.  (I
didn't replace them with goto's, I used Boolean flags instead.)

Now all of this may be a matter of how each individual programmer tends to
think when they look at programs.  The point is that, based on my experience,
arguments about "returning to where the linear control flow was diverted" and
"restricted compass" don't make a whole lot of sense in the real world.  GOTO
can be used in ways that enhance readability or in ways that impair it, and
so can every other feature of every language.

				-- Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[Dan Higdon]

adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>...

<snip prelude>

>Now, here are a couple arguments on the other side:

<snip point 1>


>(2) (This one is about "continue", since Charles Hixson later argued that
this
>was also superior to "goto" for the same reasons.)  If you have a loop that
>looks like:
>
>     while (blah-blah) {
>          some-if-statements...
>          some-more-if-statements...
>
>          xxx;
>          yyy;
>          zzz;
>     }
>
>someone reading the program might assume that xxx, yyy, and zzz are always
>going to happen before the loop repeats.  So if there's something new that
>needs to be done during every loop iteration, it looks like you can just
add
>it to the end of the loop, after zzz.  If there's a "continue" statement
>somewhere above that, this assumption is incorrect and your modification
may
>well be wrong. If you replace the "continue" with a "goto", at least there
>will be a label somewhere toward the bottom of the loop, alerting you to
the
>fact that you will have to decide whether to put the new code before or
after
>the label, or look for the place where this label is goto'ed.  In fact,
this
>is exactly why I stopped using "continue" when I was a C programmer.  (I
>didn't replace them with goto's, I used Boolean flags instead.)

So, you've actually changed the algorithm of your code, added an unnecessary
data item and added yet another compare/branch to avoid a well understood
(IMHO) construct of the C language?  Perhaps I'm the only one who thinks
writing
code that will execute efficiently is equally important as writing readable
code.
If I didn't care about efficiency, I sure wouldn't be using a 3rd generation
procedural
language (OO or not) - there are (IMHO) many more succinct and
mathematically
rigorous languages out there than C or Eiffel (ML and Haskell come to mind,
niether of which have gotos, fwiw).

I'm not trying to start a language war - I'm pointing out that gotos and the
implicit
goto forms (break, continue, etc) are a tool of the language.  They wouldn't
be
there if you NEVER needed them.  So if you have a case that warrants their
use,
you should use them, rather than trying to hamstring yourself with hokey
constructs.
If you *need* that boolean value later, then by all means add it.  But I
think that
using a boolean flag to erase a GOTO is not contributing to the solution,
just
adding inefficiency into the generated code, and one more symbol for the
programmer to have to track.

----------------------------------------
hdan@charybdis.com
"Throwing fire at the sun"

Re: Software landmines (was: Why C++ is successful)

[adam]

In article <l5HC1.6840$wN.1856764@news.giganews.com>,
  "Dan Higdon" <hdan@charybdis.com> wrote:

>
> adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>...
>
> <snip prelude>
>
> >Now, here are a couple arguments on the other side:
>
> <snip point 1>
>
> >(2) (This one is about "continue", since Charles Hixson later argued
> >that this was also superior to "goto" for the same reasons.)  If
> >you have a loop that looks like:
> >
> >     while (blah-blah) {
> >          some-if-statements...
> >          some-more-if-statements...
> >
> >          xxx;
> >          yyy;
> >          zzz;
> >     }
> >
> >someone reading the program might assume that xxx, yyy, and zzz are
> >always going to happen before the loop repeats.  So if there's
> >something new that needs to be done during every loop iteration, it
> >looks like you can just add it to the end of the loop, after zzz.
> >If there's a "continue" statement somewhere above that, this
> >assumption is incorrect and your modification may well be wrong. If
> >you replace the "continue" with a "goto", at least there will be a
> >label somewhere toward the bottom of the loop, alerting you to the
> >fact that you will have to decide whether to put the new code
> >before or after the label, or look for the place where this label
> >is goto'ed.  In fact, this is exactly why I stopped using
> >"continue" when I was a C programmer.  (I didn't replace them with
> >goto's, I used Boolean flags instead.)
>
> So, you've actually changed the algorithm of your code, added an
> unnecessary data item and added yet another compare/branch to avoid
> a well understood (IMHO) construct of the C language?  Perhaps I'm
> the only one who thinks writing code that will execute efficiently
> is equally important as writing readable code.  If I didn't care
> about efficiency, I sure wouldn't be using a 3rd generation
> procedural language (OO or not) - there are (IMHO) many more
> succinct and mathematically rigorous languages out there than C or
> Eiffel (ML and Haskell come to mind, niether of which have gotos,
> fwiw).

Well, I might have used GOTO if I had to do it over again.  My early
training taught me to avoid them, and this avoidance has become kind
of ingrained.  I still probably wouldn't use "continue", however.

However:

#1: Adding a flag in the manner I've described does not change the
algorithm, it merely changes the way the flow of control is expressed.
Unless you adopt a definition of "algorithm" that is so strict as to
be useless except to an academic.

#2: How important efficiency is depends on what you're writing.  If
you're working on time-critical code, it's very important, but if
you're working on an application where most of the program's time will
be spent waiting for the user to type in some input, a few hundred
microseconds isn't anything to worry about.

#3: A good optimizing compiler wouldn't do a compare/branch.  It might
set the flag, then notice that the next thing done is to test it, so
it would blow off the test and just branch to wherever the "continue"
statement was going to branch anyway.  An even better optimizing
compiler would then figure out that the flag is never actually tested,
so it would just get rid of it.

#4: Programmers don't always get to choose which language they use.

#5: In this thread, we're arguing about readability and
maintainability.  If you have a situation where every nanosecond is
critical, fine, but most of us are willing to give up a few
nanoseconds in order to save time debugging and maintaining programs.
If you've ever written a subroutine that was called at only one point
in the rest of the program, instead of coding it inline so that you
can avoid an unnecessary procedure call with all the stack pushes and
pops, then certainly you have to admit that readability is worth
sacrificing a couple machine cycles for, sometimes.


> I'm not trying to start a language war - I'm pointing out that gotos
> and the implicit goto forms (break, continue, etc) are a tool of the
> language.  They wouldn't be there if you NEVER needed them.

There are lots of language constructs that aren't really "needed".
And there are plenty of cases where an individual programmer, or a
programming department, adopts a policy of avoiding a particular
construct, which is fine as long as the prohibition isn't 100%
absolute.  A long time ago, I programmed in COBOL, and most of the
programmers around me agreed that the ALTER statement was just a bad
idea and shouldn't be used.  I'll bet few would disagree with such a
policy.

                                -- Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (loops)

[Nick Leaton]

I have just done a quick check through some Eiffel code. 

Out of 633 loops, just 1 needed a flag for early termination of the
loop.

-- 

Nick

Re: Software landmines (loops)

[Matthew Heaney]

Nick Leaton <nickle@calfp.co.uk> writes:

> I have just done a quick check through some Eiffel code. 
> 
> Out of 633 loops, just 1 needed a flag for early termination of the
> loop.

My own experience is quite different from yours.  Although I haven't
counted, I use early loop termination ALL THE TIME.

For example, I routinely implement an equality test (say, for a stack)
as

function "=" ... return Boolean is
begin
...

  for Index in Positive range 1 .. L.Depth loop
     if L.Items (Index) /= R.Items (Index) then
        return False;
     end if;
  end loop;

  return True;

end "=";


If my loop termination depends on a value I just read, then exit from
the middle is the simplest solution:

loop
   Get (N);

   exit when N = 0;

   <process N>
end loop;

For example, this is a simplest way to tokenize a lexeme.  You exit the
loop in the middle, after determining that the character just consumed
isn't part of the current token.

Exiting is how you terminate passive iteration early:

procedure For_Every_Item (Stack : in Stack_Type) is
 
   Done : Boolean := False;

begin

   for Index in reverse Positive range 1 .. Stack.Top loop
      Process (Stack.Items (Index), Done);
      exit when Done;
   end loop;

end For_Every_Item;


Searching is also implemented using early loop termination:

function Get_Position
  (C : Character; 
   S : String) return Natural is
begin
   for Index in S'Range loop
      if S (Index) = C then
         return Index;
      end if;
   end loop;

   return 0;
end Get_Position;
   

No auxilliary variables or flags are required.

Below is a portion of my response to another thread on comp.lang.ada re
the goto statement.

Matt

(start of quote)
Any theory about using (or not using) a programming construct needs to
be tested against observation, by performing an empirical study that
measures the defect rates of programmers using the construct.

If theory says use a construct, but observation reveals that programmers
who use the construct produce more errors, then the theory needs to be
thrown out.

For example, there's a pernicious myth that exiting (or returning) from
the middle of a loop is bad, and that the only proper way to write a
loop is to state the termination condition explicitly, as a predicate
appearing at the top of the loop.

This theory was indeed put to the test, and guess what?  Programmers
using a test-and-exit from the middle of the loop produced fewer errors
than those programmers who tried to put the test at the top of the loop.
The researchers found that the exit-from-the-middle construct had a
better "cognitive fit" than the other constructs.

If you want to read the gory details, the article is

Cognitive Strategies and Looping Constructs: An Empirical Study
Soloway, Bonar, Ehrlich
CACM, Nov 83, Vol 26, No 11, p 853-860

The goodness of a language construct should not be determined by
doctrinaire computer scientists or mathematicians.  The only thing that
matters is whether working programmers think it's easier to understand,
and whether by using the construct programmers inject fewer errors into
the code.

I think it was Stroustrup who said, "Programming is a human activity.
Forget that, and all is lost."
(end of quote)

Re: Software landmines (loops)

[Robert Martin]

Matthew Heaney wrote in message ...

>If theory says use a construct, but observation reveals that programmers
>who use the construct produce more errors, then the theory needs to be
>thrown out.

All else being equal, that would be so.  But when observation shows that the
construct reduces the overall cost of maintaining the program, regardless of
its initial cost, then it ought not be thrown out.

>For example, there's a pernicious myth that exiting (or returning) from
>the middle of a loop is bad, and that the only proper way to write a
>loop is to state the termination condition explicitly, as a predicate
>appearing at the top of the loop.

Yes.  That pernicious myth is called "structured programming".

>This theory was indeed put to the test, and guess what?  Programmers
>using a test-and-exit from the middle of the loop produced fewer errors
>than those programmers who tried to put the test at the top of the loop.

>Cognitive Strategies and Looping Constructs: An Empirical Study
>Soloway, Bonar, Ehrlich
>CACM, Nov 83, Vol 26, No 11, p 853-860

Do you know if the citing is on line?  Was the experiment controlled?  Did
the experiment measure long term cost?  Were the participants engineers who
had been used to min-loop exits, and were strugging with a new concept?

My own experience is counter to the results of this study.  It is far easier
to understand a loop if the looping criteria are present in one place; and
the loop has a single, well known, exit.

>The researchers found that the exit-from-the-middle construct had a
>better "cognitive fit" than the other constructs.

"Cognitive fit" is probably not a very good criterion for good engineering.
GOTO has a very good cognitive fit.  So does a flat Earth.

>The goodness of a language construct should not be determined by
>doctrinaire computer scientists or mathematicians.  The only thing that
>matters is whether working programmers think it's easier to understand,
>and whether by using the construct programmers inject fewer errors into
>the code.

And whether or not the construct is maintainable over the long term.  There
are lots of constructs that make writing the initial program easy, but make
maintaining it hard.  The practice of using such constructs, i.e. ignoring
long term effects, is sometimes called "hacking".
>
>I think it was Stroustrup who said, "Programming is a human activity.
Forget that, and all is lost."


Precisely!  Programming is an activity of human creativity and human
frailty.  Forget either part, and all is lost.

Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[Andrew Hussey]

In <m3af4mq7f4.fsf@mheaney.ni.net> Matthew Heaney <matthew_heaney@acm.org> writes:

>I can almost live that.  The real problem, however, is that using an
>extra flag to terminate VASTLY complicates the predicate.  In fact, the
>flag doubles the number of states I have to think about when mentally
>evaluating the predicate!  That's the real source of the loop
>termination errors.

>(I shouldn't have to remind anyone, but just in case: George Miller did
>a famous study about human cognitive limits, and found that people can
>remember about 7 things, plus or minus 2.  That's why complex predicates
>make a programmer's head spin, and why he often gets loop termination
>wrong.)

>Using an exit from the middle avoids the headaches (literally)
>engendered by using an extra flag in the predicate.  When you want to
>exit, you just say that you want to exit, directly.  No mental
>gymnastics are required in order to determine whether you'll "really"
>exit, as would be the case using the flag approach.

That's brilliant, now your code is much easier to write!
Now let's see who has an easier time *testing* their code.
I think you'll find the control-flow errors you introduce
in the spaghetti you produce will more than make up for
any gain you have from rapid coding.  

A.
 

Re: Software landmines (loops)

[Gerry Quinn]

In article <904556531.666222@miso.it.uq.edu.au>, ahussey@it.uq.edu.au (Andrew Hussey)
 <m3af4mq7f4.fsf@mheaney.ni.net> wrote:

>>Using an exit from the middle avoids the headaches (literally)
>>engendered by using an extra flag in the predicate.  When you want to
>>exit, you just say that you want to exit, directly.  No mental
>>gymnastics are required in order to determine whether you'll "really"
>>exit, as would be the case using the flag approach.
>
>That's brilliant, now your code is much easier to write!
>Now let's see who has an easier time *testing* their code.
>I think you'll find the control-flow errors you introduce
>in the spaghetti you produce will more than make up for
>any gain you have from rapid coding.  
>

A characteristic of 'spaghetti' is that the strings both start and 
finish in unpredictable places, leading to a tangled mass.

Multiple exits to a single destination are not spaghetti.

- Gerry

----------------------------------------------------------
  gerryq@indigo.ie  (Gerry Quinn)
----------------------------------------------------------

Re: Software landmines (loops)

[Robert Martin]

Gerry Quinn wrote in message <6sgror$je8$3@news.indigo.ie>...

>Multiple exits to a single destination are not spaghetti.


Spaghetti is not a well defined term.

However, multiple exits to a single destination represent a problem.  The
two exits come from two different states within the algorithm.  If the
single destination must do some work that depends upon that state (or if in
the future, that single destination must be modified to do work that depends
upon that state), then the code in the single destination is going to get
pretty ugly.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[mfinney]

In <6sh3qn$9p2$1@hirame.wwa.com>, "Robert Martin" <rmartin@oma.com> writes:

>However, multiple exits to a single destination represent a problem.  The
>two exits come from two different states within the algorithm.  If the
>single destination must do some work that depends upon that state (or if in
>the future, that single destination must be modified to do work that depends
>upon that state), then the code in the single destination is going to get
>pretty ugly.

I have been following this thread for a while (or at least part of the thread),
and it seems to me that the basic argument is between the use of structured
programming which requires a single entry and single exit and of tree-
structured programming which allows multiple-level breaks/continues, but
not arbitrary jumps into blocks.

It turns out that tree-structured programming covers almost all of the flow
graphs actually encountered by compilers which are not undecomposable 
and provides the necessary flow graph assurances for optimization (I do
have a reference on that, but have just finished moving and everything
is in boxes, so regrettably I can't provide it at this time).  Multiple exits from
a block do require the compiler to add extra control flow paths to a single
exit point for some algorithms, but that is trivial control flow transformation
by the compiler -- but not for the programmer because modern languages do
not generally provide adequate control structures (other than goto) to
represent the extra control flow paths.

I personally feel that structured programming is a very good idea, but like
most things is an extreme which is better with a little compromise.  I see
tree-structured programming as that compromise.  It is true that multiple
exits arrive from different states -- but presumably they all satisify the
exit postcondition, and that is what should be used for subsequent
programming (assuming that the exit postcondition is clearly stated).  In
a routine such as the one being used for an example, it seems clear that
multiple exits do not harm and actually improve code readability.

It has been suggested that the need for maintenance is a reason to twist
the code unnaturally -- but that is where using a multiple level exit
instead of returns would solve the problem (true, C/C++ does not directly
provide multiple level exits, but they can be "faked").

It has been suggested that mid-loop exits (which can still be considered
structured code because they have a single entry and a single exit, even
if the exit is not at the top or bottom of the loop) are not good because
the loop is not executed an integral number of times.  On the contrary,
that is the best possible reason to use a mid-loop exit because many
programs do not naturally map to an integral number of iterations.  It is
always better to allow the control structure map as closely as possible
to the problem.  So "twisting" a mid-loop exit to make it a top or bottom
exit, and possibly duplicating code will make code readability harder.

It has also been stated that when multiple exits are allowed, it is
necessary for the programmer to actually *read* the code to be able
to understand it!  Well surprise -- do you really want somebody
modifying your code *without* reading it?  Sorry, but I don't think so!

It also seems to me that this argument has no resolution.  Those who
are strictly in favor of the orginal, unadulterated structured programming
aren't going to give ground to those who favor a more relaxed view of
structured programming.

And, as far as maintainability is concerned, I strictly use tree-structured
programming and have *never* found it to be a maintenance problem.
Sure, sometimes code transformations are required during maintenance,
but they are sometimes required during coding.  So what?  There is no
way to write code that never requires code transformations during
maintenance, and trying to do so just makes the code harder to
understand and ultimately increases maintenance cost.  Far better is
to endevour to reach 0 bugs so that maintenance is never required.
Not easy, perhaps, but it is getting closer and closer every day.  I 
personally am running somewhere around 0.0001 and 0.0002 errors
per line of code --  prior to quality assurance getting the code.


Michael Lee Finney

Re: Software landmines (loops)

[Robert Martin]

mfinney@lynchburg.net wrote in message ...

>And, as far as maintainability is concerned, I strictly use tree-structured
>programming and have *never* found it to be a maintenance problem.
>Sure, sometimes code transformations are required during maintenance,
>but they are sometimes required during coding.  So what?  There is no
>way to write code that never requires code transformations during
>maintenance, and trying to do so just makes the code harder to
>understand and ultimately increases maintenance cost.  Far better is
>to endevour to reach 0 bugs so that maintenance is never required.
>Not easy, perhaps, but it is getting closer and closer every day.  I
>personally am running somewhere around 0.0001 and 0.0002 errors
>per line of code --  prior to quality assurance getting the code.


Reaching zero bugs may not have that big an impact on maintenance, since
much of maintenance has to do with changes to the requirements.

In any case, I note that in this thread nearly every article that advocates
multiple exits evokes either readability, complexity, or naturalness as the
justification.  I contend that these are highly subjective things, that are
not shared by all programmers alike.  Indeed, what is readable, natural and
simple to me, may be opaque and convoluted to you.  I also contend that
these issues are somewhat emotional, as evidenced by the terms such as
"twist", "warp", "bend", "religious argument", etc. that have also been used
in this thread.

Finally, I contend that the factors in favor of using a
single-entry/single-exit style are, on the other hand, quite concrete and
demonstrable.  It has been shown that adhering to a structured style
facilitates both resource management and error processing.   It has also
been shown that a multiple exit style is vulnerable to redundant code, and
code for recovery of state.

So, it seems what we have here is "gut feelings" warring against empirical
data.  I can understand why the gut reaction is so strong; multiple exits
are *eaiser* to write; and are, for some, easier to read.  But those are not
the only, or even the most important, criteria for evaluating the quality of
a design.  Maintainability is an issue too, and sometimes an overriding one.

In the end, the decision to use a structured style is a tradeoff.  There are
benefits, and there are costs.  And there are certainly situations in which
the costs outweight the benefits (e.g. quick an dirty programs that have
short lifetimes and require little maintenance during their life).  It is
also true, however, that for a very large set of circumstances, the benefits
outweigh the costs.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan




Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[Ell]

On Wed, 2 Sep 1998 00:44:08 -0500, "Robert Martin" <rmartin@oma.com>
wrote:


>In any case, I note that in this thread nearly every article that advocates
>multiple exits evokes either readability, complexity, or naturalness as the
>justification.  I contend that these are highly subjective things,

This may be true, though I don't thinks so, but adherence to the dogma
you made up about "single entry and single exit" doesn't make things
clearer as most see it in this case.

>Finally, I contend that the factors in favor of using a
>single-entry/single-exit style are, on the other hand, quite concrete and
>demonstrable.  It has been shown that adhering to a structured style

You have not shown at all that "single entry, single exit" is a
general coding maxim of structured programming. 

And you should be ashamed of yourself for asserting that it is when
after recently being challenged on it, you failed to prove that it was
a general coding heuristic of structured programming.  Why do you
think you have a right to lie, and make false assertions contrary ti
the facts?

>facilitates both resource management and error processing.   It has also
>been shown that a multiple exit style is vulnerable to redundant code,
>code for recovery of state.

Not at all.  It has been shown that in this and many other cases the
difference in state at each exit point matters little.

>So, it seems what we have here is "gut feelings" warring against empirical
>data.

It seems we have a masochistic task master adhering to his own
unnecessary dogma trying to make others suffer as well by palming his
dogma off as some kind of officialdom.  Further, he can't prove it as
officialdom and it wouldn't matter if it was because the
appropriateness of all heuristics depends on specific concrete
circumstances.

Elliott

Re: Software landmines (loops)

[Robert Martin]

Ell wrote in message <35eeea9b.2174586@news.erols.com>...
>On Wed, 2 Sep 1998 00:44:08 -0500, "Robert Martin" <rmartin@oma.com>
>wrote:
>
>
>>In any case, I note that in this thread nearly every article that
advocates
>>multiple exits evokes either readability, complexity, or naturalness as
the
>>justification.  I contend that these are highly subjective things,
>
>This may be true, though I don't thinks so, but adherence to the dogma
>you made up about "single entry and single exit" doesn't make things
>clearer as most see it in this case.

"clearer", again, is subjective IMHO.  In any case, I have not been
recommending aherence to dogma. Rather I have been describing a cost/benfit
trade-off.  On at least two occasions, in this thread, I have said that
there is a time and place for multiple returns; but that such times and
places need to be chosen well based on a real assesment of the costs; an not
a subjective evaluation of what "feels good".
>
>>Finally, I contend that the factors in favor of using a
>>single-entry/single-exit style are, on the other hand, quite concrete and
>>demonstrable.  It has been shown that adhering to a structured style
>
>You have not shown at all that "single entry, single exit" is a
>general coding maxim of structured programming.

Well, that's your opinion.  But I have cited the section of Dijkstra's book
"Structured Programming" that talks about this; and have quoted the page
where it is elaborated; and have summarized the discussion.  It's quite
difficult for me to understand how anyone could read the cited section and
not agree that single-entry/single-exit is a core concept of structured
programming.  I also note that no one else has challenged that assertion.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[Ell]

On Wed, 2 Sep 1998 08:52:36 -0500, "Robert Martin" <rmartin@oma.com>
wrote:

>
>Ell wrote in message <35eeea9b.2174586@news.erols.com>...
>>
>>You have not shown at all that "single entry, single exit" is a
>>general coding maxim of structured programming.

>Well, that's your opinion.

It's a *fact*!

>But I have cited the section of Dijkstra's book
>"Structured Programming" that talks about this;  
>and have quoted the page where it is elaborated;

That single fragment of a sentence, or at most single sentence, about
*flowcharting* in no way made the case that *coding* in the structured
paradigm should generally adhere to "single entry and single exit".

You are being ultra disengenuous to support your fantasies about
structured programming.

>I also note that no one else has challenged that assertion.

Because no one else is confident enough to challenge you on the point
doesn't ipso factso mean that you are right.  What kind of logic is
that?

Elliott

Re: Software landmines (loops)

[Robert Martin]

Ell wrote in message <35f055a5.1431187@news.erols.com>...
>On Wed, 2 Sep 1998 08:52:36 -0500, "Robert Martin" <rmartin@oma.com>
>wrote:
>
>>
>>Ell wrote in message <35eeea9b.2174586@news.erols.com>...
>>>
>>>You have not shown at all that "single entry, single exit" is a
>>>general coding maxim of structured programming.
>
>>Well, that's your opinion.
>
>It's a *fact*!

You are entitled to that opinion.

>
>>But I have cited the section of Dijkstra's book
>>"Structured Programming" that talks about this;
>>and have quoted the page where it is elaborated;
>
>That single fragment of a sentence, or at most single sentence, about
>*flowcharting* in no way made the case that *coding* in the structured
>paradigm should generally adhere to "single entry and single exit".

The point of the citing, and the quotation, was to guide you to read it for
yourself.  I'm not going to reproduce two or three pages of text for your
benfit.  The cited section is very unambiguous in its recommendation of
single-entry and single-exit.  The section was not about *flowcharting*,
rather it used four different generic flowcharts (all with single entry and
single exit) to describe the fundemental building blocks of structured
programming.

Elliott, you really ought to read the book.  I've given you enough pointers.
Do your homework.

Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[Ell]

In comp.object Robert Martin <rmartin@oma.com> wrote:

: Ell wrote in message <35f055a5.1431187@news.erols.com>...
:>On Wed, 2 Sep 1998 08:52:36 -0500, "Robert Martin" <rmartin@oma.com>
:>wrote:
:>
:>>
:>>Ell wrote in message <35eeea9b.2174586@news.erols.com>...
:>>>
:>>>You have not shown at all that "single entry, single exit" is a
:>>>general coding maxim of structured programming.
:>
:>>Well, that's your opinion.
:>
:>It's a *fact*!

: You are entitled to that opinion.

:>
:>>But I have cited the section of Dijkstra's book
:>>"Structured Programming" that talks about this;
:>>and have quoted the page where it is elaborated;
:>
:>That single fragment of a sentence, or at most single sentence, about
:>*flowcharting* in no way made the case that *coding* in the structured
:>paradigm should generally adhere to "single entry and single exit".

: The point of the citing, and the quotation, was to guide you to read it for
: yourself.  I'm not going to reproduce two or three pages of text for your
: benfit.  The cited section is very unambiguous in its recommendation of
: single-entry and single-exit.  The section was not about *flowcharting*,
: rather it used four different generic flowcharts (all with single entry and
: single exit) to describe the fundemental building blocks of structured
: programming.

: Elliott, you really ought to read the book.  I've given you enough pointers.
: Do your homework.

If you had quotes showing that "single entry single exit" was supposed to
be a key maxim of the structured paradigm you would quote it.  At lesast
you should.  

Because all you've shown is Flowcahrt 101, that of course a flowchart
should have only one entry and one exit point on the *page*! 

I've taken 4 formally named "Structured COBOL" courses so I've already
done my homework.  It's your assertion which is groundless fanatasy.

Rules about laying out flowcharts on page, as some kind of proof about the
nature of structured *coding*.  Indeed!  Gives us a darn break would 'ya?! 

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Software landmines (loops)

[Robert Martin]

Ell wrote in message ...

>If you had quotes showing that "single entry single exit" was supposed to
>be a key maxim of the structured paradigm you would quote it.  At lesast
>you should.

Elliott, if Dijkstra had provided a nice one liner, I'd be glad to give it
to you.  And, after all, maybe he did and I just haven't found it.  So what?
The chapter is only a few pages long, the book is certain to be available at
a nearby library or bookstore, so look it up.

>Because all you've shown is Flowcahrt 101, that of course a flowchart
>should have only one entry and one exit point on the *page*!

I have no idea how you could have drawn that interpretation.  First, I've
never heard of such a convention. Second, it has nothing to do with the
discussion in the cited chapter.   The chapter is about structuring the flow
of control.  Dijkstra is making the point that unrestricted flow of control
(i.e. goto) is harmful.  He then shows four flowcharts that demonstrate the
cannonical forms of flow control in structured programming.  They are,
sequence, decision, top exit iteration, and bottom exit iteration.  He then
goes on to recommend that all software be constructed of assemblages of
these four control forms; and nothing but these four control forms.  He then
describes the four forms as having a single entry and a single exit.

I strongly recommend that before you respond further to this thread, you
read Dijkstra's material.

>I've taken 4 formally named "Structured COBOL" courses so I've already
>done my homework.

Twenty-three years ago I was *teaching* "Structured COBOL" courses.
Fortunately, we are not discussing the contents of structured COBOL courses.
We are discussing the contents of Dijkstra's book "Structured Programming".
If your courses failed to teach you about single-entry/single-exit, then I
suggest you ask for your money back, because you got reamed.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Software landmines (loops)

[Joe Gwinn]

It seems to me that there is an unspoken assumption in the long debate
about GOTOs and spaghetti code:  It doesn't follow that presence of GOTOs
makes code spaghetti, or that code without GOTOs is always clear and easy
to understand, write, and maintain.  

The issues are in my experience quite independent.  I have seen lots of
spaghetti code with nary a GOTO, and perfectly clear code with many GOTOs.

I would submit that good programmers write clear, simple code, regardless
of the nature of the language or language constructs used.  (With the
possible exception of APL, which was known as the write-only language.)  I
have seen the same effect in the design of digital hardware.  The key
issue is clarity of thought; lost-puppy engineers will do the oddest
things, at length.  It can be painful to watch, and hard on the engineer.

So, the whole 1970s debate about structured programming (and thus GOTOs)
reduced to the fond hope that if we tied the hands of those lost-puppy
programmers, they would no longer be lost, and would then think ahead and
write good code.

By that same token, if we take a hard-to-use tool away from a rough
carpenter, he will suddenly become a cabinetmaker.


Joe Gwinn

Re: Software landmines (loops)

[Charles Hixson]

Joe Gwinn wrote:
> 
> It seems to me that there is an unspoken assumption in the long debate
> about GOTOs and spaghetti code:  It doesn't follow that presence of GOTOs
> makes code spaghetti, or that code without GOTOs is always clear and easy
> to understand, write, and maintain.
> 
> The issues are in my experience quite independent.  I have seen lots of
> spaghetti code with nary a GOTO, and perfectly clear code with many GOTOs.
> 
... 
> Joe Gwinn

I suppose that it is possible to write spaghetti code without using
goto's, I've never tried.  I do know that with goto's INSTEAD OF while,
until, elsif, begin...end, etc. it was very difficult NOT to write
spaghetti code, and since there was originally the theory said that the
best code economized on the number of CPU cycles, rather than optimized
intelligibility, there was every reason TO write code that took
short-cuts.  Actually, there was a second optimization which said that
code should use the minimum amount of core memory, so sometimes
instructions would modify other instructions, so that blocks of code
wouldn't need to be repeated with only slight changes.

Spaghetti code didn't mean multiple return statements to the same
location in the first 10 lines of the routine.  O my no.

I used to use several different colors of pen so that I could keep track
of which direction the flow of control was going on the current branch. 
And seven levels wasn't unusual.  My usual code was blue for down, green
for up, red for a branch to an error exit, and black for a format
statement reference.

I BELIEVE in structured programming.  I'm just not sure that se/se
actually captures what it's really about.  And I'm sorry, but even if
Dijkstra did invent it, I don't feel that he necessarily understood what
he was inventing.  So quotes about what he said strike me as beside the
point.  YES, it was VERY important for him to say it.  YES, he made
great improvements in the art of programming.  YES, he is one of the
founders of what modern programming IS.  This doesn't make him perfect
and omniscient and omnipotent.

Early returns from routines frequently make them easier to understand. 
And maintain.  Se/se is something that is worth moderate efforts.  It
is, however, related to something else.  Something that I don't yet have
words to wrap around, but lots of other people on this list seem to also
feel it.

Code should be easy to understand AND to maintain.  Both need to be
optimized.  Somehow.

Re: Software landmines (loops)

[adam]

In article <35F252DD.5187538@earthlink.net>,
  Charles Hixson <charleshixsn@earthlink.net> wrote:

> I suppose that it is possible to write spaghetti code without using
> goto's, I've never tried.

Sigh . . . does anyone *try* to write spaghetti code?  The thing is, someone
who's inexperienced and hasn't read enough code to know whether code is
readable or not, is certainly capable of writing unreadable, convoluted code
without using GOTO.  I can't say whether I've written any such code (because
if I did, I would have been too inexperienced to recognize it...), but I do
know that I've *seen* plenty of convoluted code written by people brought up
in the "GOTO is evil" religion.  Maybe it shouldn't be called "spaghetti
code" since the control doesn't wind up over itself; maybe "rotini code" is
more appropriate since although the different parts aren't entangled, they're
all completely twisted within themselves.  But if the goal is to write code
that doesn't give  a migraine to someone who tries to understand it, rather
than merely to identify which form of pasta is appropriate to a particular
piece of code, then Joe is absolutely right that it's possible to write code
without GOTO that is just as twisted as the unstructured, GOTO-loaded code
that older programmers used to write.

> I do know that with goto's INSTEAD OF while,
> until, elsif, begin...end, etc. it was very difficult NOT to write
> spaghetti code

How could it be that difficult?  I found it quite easy.  I used to work in
COBOL in the late 1970's, before COBOL had decent control structures, and I
learned that in many cases, it seemed better to *avoid* PERFORM .. WHILE,
since it took important chunks of code out-of-line and made it more difficult
for readers to understand.  So, instead of PERFORM..WHILE, I often wrote code
like

    START-OF-LOOP.
        IF some-condition THEN GOTO LOOP-END.
    BODY-OF-LOOP.
        ... do whatever
        GOTO START-OF-LOOP.
    LOOP-END.

(Usually with more appropriate paragraph names.)  This is well-structured, and
not difficult to write, and should be easy enough to understand for anyone who
has a clue what WHILE loops do in the first place.  So I can't imagine what
would merit calling this "spaghetti code", unless you belong to the
"GOTO-Is-Evil" religion (St. Edsger's Church) and believe that spaghettiness
can be determined by counting the number of GOTO's.

> and since there was originally the theory said that the
> best code economized on the number of CPU cycles, rather than optimized
> intelligibility, there was every reason TO write code that took
> short-cuts.

Ummm, I don't see how this has anything to do with Joe's point.  Sure, if
you think GOTO's are fine *AND* one of your prime motivations is to eliminate
as many cycles as possible, you're more likely to write unintelligible code;
but Joe is only questioning the assumption about GOTO's, and is saying nothing
whatsoever about nanosecond-squeezing code.

				-- Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (loops)

[Gerry Quinn]

In article <6t4dge$t8u$1@nnrp1.dejanews.com>, adam@irvine.com wrote:
>In article <35F252DD.5187538@earthlink.net>,
>  Charles Hixson <charleshixsn@earthlink.net> wrote:
>
>> I suppose that it is possible to write spaghetti code without using
>> goto's, I've never tried.
>
>Sigh . . . does anyone *try* to write spaghetti code?  The thing is, someone
>who's inexperienced and hasn't read enough code to know whether code is
>readable or not, is certainly capable of writing unreadable, convoluted code
>without using GOTO.  

I agree - in fact I would argue that if you are carrying a flag for 
deciding when to exit, the flag is part of the flow of control - with 
all the potential pasta that entails.

- Gerry

----------------------------------------------------------
  gerryq@indigo.ie  (Gerry Quinn)
----------------------------------------------------------

Re: Software landmines (loops)

[Biju Thomas]

Giovanni 8 wrote:
> 
> > Gerry Quinn wrote:
> >> adam wrote:
> >> Sigh... does anyone *try* to write spaghetti code?
> >> The thing is, someone who's inexperienced and hasn't read
> >> enough code to know whether code is readable or not, is
> >> certainly capable of writing unreadable, convoluted code
> >> without using GOTO.
> 
> > I agree - in fact I would argue that if you are carrying a
> > flag for deciding when to exit, the flag is part of the
> > flow of control - with all the potential pasta that entails.
> 
> Spaghetti code is in the eye of the beholder.
> 
> Some people find jumps or gotos, written in their own
> particular style, to be much more elegant and clear
> than the so-called control structures.  Others really
> like flags popping up in one place & then not being
> seen through vast piles of listing until, layers removed,
> they are used again (even in a different context with
> different conceptual significance for the values of
> the flag).  I've seen people, brows furrowed, puzzled
> over code that was the epitome of structured design,
> who could follow the jumps of assembly language with
> ease.

Reminds me of what Dijkstra told about the effect of COBOL and BASIC on
minds:

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."

"It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC; as potential programmers
they are mentally mutilated beyond hope of regeneration"

Biju Thomas

Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Rick Smith]

Biju Thomas <"Biju Thomas"> > wrote in message <35FFE58C.5727@ibm.net>...
>Reminds me of what Dijkstra told about the effect of COBOL and BASIC on
>minds:
>
>"The use of COBOL cripples the mind; its teaching should, therefore, be
>regarded as a criminal offense."
>
>"It is practically impossible to teach good programming style to
>students that have had prior exposure to BASIC; as potential programmers
>they are mentally mutilated beyond hope of regeneration"
>
Of the comments attributed to Dijkstra, I have never heard a comment
that was favorable toward any language! Is there a language that Dijkstra
liked?

Of which features of any language did Dijkstra make favorable comments?

Based upon his comments, what languages might Dijkstra like today?

Would Dijkstra have favorable comments for the OO languages, in
particular?

-------------------------------
Rick Smith
e-mail: < ricksmith@aiservices.com >

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Markus Kuhn]

Rick Smith wrote:
> Of the comments attributed to Dijkstra, I have never heard a comment
> that was favorable toward any language! Is there a language that Dijkstra
> liked?

I thought that Dijkstra wrote years after his famous criticism on Ada,
which basically killed interest on Ada in the academic community for
many years, a quite nice foreword for an Ada 83 textbook by Jean Ichiba.
I guess, his aversion against Ada were softened once he saw what
monsters more recent languages such as C++ have become, compared
to which Ada in Dijkstra's criteria should be a very nice language. I
never understood his criticism that Ada is much too complex, and
attribute it just to his inexperience with language specifications
written down as ISO standards, because today even the C 9X standard
is longer and much more difficult to read than the Ada standard. If
you doubt that, get it from <http://wwwold.dkuug.dk/JTC1/SC22/WG14/>
and read the definition of C's "restrict" type qualifier!!!
I would like to see Dijkstra's comments on C 9X and then a
comparison with Ada.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

Markus Kuhn wrote in message <3600E72E.24C93C94@cl.cam.ac.uk>...
>Rick Smith wrote:
>> Of the comments attributed to Dijkstra, I have never heard a
comment
>> that was favorable toward any language! Is there a language that
Dijkstra
>> liked?
>
>I thought that Dijkstra wrote years after his famous criticism on
Ada,
>which basically killed interest on Ada in the academic community
for
>many years, a quite nice foreword for an Ada 83 textbook by Jean
Ichiba.

Perhaps you are thinking of that by C.A.R. Hoare.  A very similar
situation, after his Turing Award lecture.  The book is "Ada
Language and Methodology".  In the foreword Hoare says of Ada, among
other nice things:

"... the language incorporates many excellent structural features...
...one can now look forward to a rapid and widespread improvement in
programming practice, both from those who use the language and from
those who study its concepts and structures. ..."

Authors: Watt, David; Wichmann, Brian; Findlay, William
Prentice-Hall International Series on Computer Science, 1987
ISBN 0-13-004078-9


-- pat

Patrick Rogers
progers@acm.org
http://www.neosoft.com/~progers

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dewarr]

In article <6trcar$nq1$1@uuneo.neosoft.com>,
  "Pat Rogers" <progers@acm.org> wrote:

> Perhaps you are thinking of that by C.A.R. Hoare.  A very similar
> situation, after his Turing Award lecture.  The book is "Ada
> Language and Methodology".  In the foreword Hoare says of Ada, among
> other nice things:


By the way, I think it is worth rereading Hoare's TA lecture.
I often quote from it because he says some very positive
things about Ada. In particular, he says something like

"it is possible to select a safe and reliable subset of Ada
..."

Since real programs are always written in an appropriate
subset, this seems a most positive statement!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[David C. Hoos, Sr.]

Pat Rogers wrote in message <6trcar$nq1$1@uuneo.neosoft.com>...

<snip>
>In the foreword Hoare says of Ada, among
>other nice things:
>
>"... one can now look forward to a rapid and widespread improvement in
>programming practice, both from those who use the language and from
>those who study its concepts and structures. ..."
>
I guess that means "widespread" is limited to the few of  "those who use the
language and from those who study its concepts and structures", since most
who pontificate on Ada seem to have neither used or studied it.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dewarr]

In article <3600E72E.24C93C94@cl.cam.ac.uk>,
  Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:

> I thought that Dijkstra wrote years after his famous criticism on Ada,
> which basically killed interest on Ada in the academic community for
> many years, a quite nice foreword for an Ada 83 textbook by Jean Ichiba.

This boggles the mind. I have no idea what "famous criticism"
of Ada you are talking about by EWD, but for sure JDI
never wrote any textbook on Ada, with or without a forward
from EWD.

Perhaps you are talking about AH's Turing address, which
certainly did not "kill interest on Ada in the academic
community" [after all at least two major Ada vendors playing
today have their roots in academic research efforts]. AH did
also write a nice forward for a book by Brian Wichman.

If it is really this that you are referring to, please check
facts -- it is easy to see how urban legends get established
:-)

EWD did write criticisms of the four colored languages, but
actually I found these criticisms fairly mild, basically he
gave the impression that he generally liked this sort of
level of language, but had nits to pick with each of the
colors!



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Biju Thomas]

dewarr@my-dejanews.com wrote:
> 
> EWD did write criticisms of the four colored languages, but
> actually I found these criticisms fairly mild, basically he
> gave the impression that he generally liked this sort of
> level of language, but had nits to pick with each of the
> colors!

Pardon my ignorance, but, what are colored languages? Haven't heard such
a term before...

Biju Thomas

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dewarr]

In article <36018F49.9E3360E3@ibm.net>,
  bijuthom@ibm.net wrote:
> dewarr@my-dejanews.com wrote:
> >
> > EWD did write criticisms of the four colored languages, but
> > actually I found these criticisms fairly mild, basically he
> > gave the impression that he generally liked this sort of
> > level of language, but had nits to pick with each of the
> > colors!
>
> Pardon my ignorance, but, what are colored languages? Haven't heard such
> a term before...
>
> Biju Thomas

The four competitors in the original Ada design competition
were dubbed red, green, blue and yellow. Green won and became
Ada. Actually what happened is that first blue and yellow
were discarded, leaving red (intermetrics) and green
(honeywell) and then green won that two way competition.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Markus Kuhn]

dewarr@my-dejanews.com wrote:
> The four competitors in the original Ada design competition
> were dubbed red, green, blue and yellow. Green won and became
> Ada. Actually what happened is that first blue and yellow
> were discarded, leaving red (intermetrics) and green
> (honeywell) and then green won that two way competition.

What did red, yellow, and blue roughly look like? Where they
also essentially luxury versions of Pascal like Green/Ada, or
where they something radically different? Did they also have
tasking, exceptions, variant records, etc.?

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Matthew Heaney]

dewarr@my-dejanews.com writes:

> In article <3600E72E.24C93C94@cl.cam.ac.uk>,
>   Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> 
> > I thought that Dijkstra wrote years after his famous criticism on Ada,
> > which basically killed interest on Ada in the academic community for
> > many years, a quite nice foreword for an Ada 83 textbook by Jean Ichiba.
> 
> Perhaps you are talking about AH's Turing address, which
> certainly did not "kill interest on Ada in the academic
> community" [after all at least two major Ada vendors playing
> today have their roots in academic research efforts]. AH did
> also write a nice forward for a book by Brian Wichman.

I have to disagree with you, Robert.  It is my opinion that it was
Hoare's Turing Award speech that single-handedly derailed the Ada
language effort.  He essentially argued that by using Ada, "the fate of
mankind" was at stake.  

People listened to him.  Lots of people listened to him.  To this day,
people still quote the Hoare speech (among them, Bertrand Meyer) in
order to back up their own criticisms of Ada.  (The argument goes
something like, "See, Tony Hoare said Ada was bad, so it must be so.")

It's the kind of thing that probably prompted C.B. Jones to remark that:

"Subsequent to this publication, Hoare and Wirth consulted for SRI on
their 'Yellow' language response to the 'Tinman' requirements.  Their
consistent advice to simplify even this language was unheeded - but the
final Ada language (the 'Green' proposal) was even more baroque."

(excerpted from Chap 13, "Hints on programming language design", in
Essays in Computing Science, by Hoare and Jones).

In his speech, Hoare argued that "Ada was doomed to succeed."  This
hardly sounds like a hearty endorsement.  And his tepid remarks in the
forward of David Watt's book seem only perfunctory.
 
> If it is really this that you are referring to, please check
> facts -- it is easy to see how urban legends get established
> :-)
> 
> EWD did write criticisms of the four colored languages, but
> actually I found these criticisms fairly mild, basically he
> gave the impression that he generally liked this sort of
> level of language, but had nits to pick with each of the
> colors!

Again, my reading of his critique is quite different from yours.  In his
summary of the DoD-I language effort, Dijkstra writes:

<<My overwhelming impression is that, in particular in combination with
the Revised IRONMAN Requirements ... the compstitive situation in hich
the four design groups had been placed, had been disastrous.  Instead of
trying to design the most adequate programming language, they have all
four tried to get the next contract, and that is a completely different
thing!...

Firstly the four reports I studied were all an almost inextricable
mixture of technical documentation and salestalk, and that made their
study unnecessarily difficult and unpleasant.  It made the reading
unpleasant because quite often the saletalk was so close to dishonesty
or nonsense that my ability to approach the design with feelings of
sympathy was severely strained.>>

The rest of the paper lists some valid criticisms of the IRONMAN
Requirements.  (His comments really apply to the specification of any
set of requirements, so they make a good read.)

Towards the end he recalls the text of a letter he sent to a friend re
his reviews:

<<"... But I was not propared for such junk as I have seen.  Isn't this world a
disappointing, depressing place?  Do these people not know how much care
such a design requires?...

"I have now done two of them [reviews of the languages], but need one or
two days off, to collect some courage, before I dare embark on the
third."

In his answer [to Dijkstra's letter] he discussed the phenomenon that,
compared to PASCAL (with all its imperfections and shortcomings taken
into account), the proposed languages are such a gigantic step
backwards.>>

He concludes by saying that 

<<And this concludes a month of most depressing work.  Why does the
world seem to persist so stubbornly in being such a backward place?  Why
do people refuse to learn from the past and why do they persist in
making the known and well-identified mistakes again?  It is all very
saddening.

Of ALGOL 60 C.A.R. Hoard once remarked that it was a significant
improvement over almost all of its successors.  What can we do to
prevent PASCAL from sharing that fate?>>


I would argue that Dijkstra's comments comprised more than mere "nits."

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4680 bytes --]

Matthew Heaney wrote in message ...
>dewarr@my-dejanews.com writes:
>
>> In article <3600E72E.24C93C94@cl.cam.ac.uk>,
>>   Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
>>
>> > I thought that Dijkstra wrote years after his famous criticism
on Ada,
>> > which basically killed interest on Ada in the academic
community for
>> > many years, a quite nice foreword for an Ada 83 textbook by
Jean Ichiba.
>>
>> Perhaps you are talking about AH's Turing address, which
>> certainly did not "kill interest on Ada in the academic
>> community" [after all at least two major Ada vendors playing
>> today have their roots in academic research efforts]. AH did
>> also write a nice forward for a book by Brian Wichman.
>
>I have to disagree with you, Robert.  It is my opinion that it was
>Hoare's Turing Award speech that single-handedly derailed the Ada
>language effort.  He essentially argued that by using Ada, "the
fate of
>mankind" was at stake.
>
>People listened to him.  Lots of people listened to him.  To this
day,
>people still quote the Hoare speech (among them, Bertrand Meyer) in
>order to back up their own criticisms of Ada.  (The argument goes
>something like, "See, Tony Hoare said Ada was bad, so it must be
so.")

<snip>

>In his speech, Hoare argued that "Ada was doomed to succeed."  This
>hardly sounds like a hearty endorsement.  And his tepid remarks in
the
>forward of David Watt's book seem only perfunctory.

Interesting thought that his later favorable comments in the
foreword would be considered "perfunctory".  I agree that, in
comparison, his foreword has nowhere near the excesses of his TA
speech, and without question, nowhere near the effect of the speech,
but they are nevertheless strongly favorable statements.  In
particular, they are sufficiently positive as to be incompatible
with the TA speech; they cannot both be right.  Since the foreword
was written later, I have to believe that he changed his mind.  The
alternative is to assume that he wrote something he didn't believe,
which is a very serious charge against an academic, as they have no
professional identity without credibility.  (That's why plagiarism
is so major a sin in the academic world.)  Worse, he would have had
to have written something he didn't believe for money (he was the
Series Editor).  I am not prepared to believe these can be true,
without further proof.*

I include the foreword for the sake of comparison:

From the foreword by C.A.R. Hoare to a book titled �Ada Language and
Methodology� by David Watt,
Brian Wichman and William Findlay, published by Prentice-Hall
International, 1987:

�I enjoyed reading the Algol 60 report; it taught me a lot about
programming.�  This is the comment of a
data processing manager of a major motor manufacturing company, who
had no conceivable prospect of
ever using the language to program a computer.  It is a most
perceptive comment, because it describes an
important goal in the design of a new programming language: that it
should be an aid in specification,
description, and design of programs, as well as in the construction
of reliable code.

This is one of the main aims in the design of the language which was
later given the name Ada.  As a result,
the language incorporates many excellent structural features which
have proved their value in many
precursor languages such as Pascal and Pascal Plus.

The combination of many complex features into a single language has
led to an unfortunate delay in
availability of production-quality implementations.  But the long
wait is coming to an end, and one can now
look forward to a rapid and widespread improvement in programming
practice, both from those who use
the language and from those who study its concepts and structures.

I hope that this book will contribute directly to these ideals,
which have inspired many of the other books in
the same series.  It continues the tradition of the series in that
it describes how the language can be used as
the target of a sound programming methodology, embracing the full
life cycle of a programming project.  It
explains not just the features and details of the language, but also
their purpose and method of effective use.

The complexities and difficulties are not glossed over; they are
explained within the appropriate context,
with hints on how to avoid any consequent problems.  I hope the book
will be useful, both to those who
have the privilege or obligation to use the language, and to those
who have the interest and curiosity to
understand and appreciate its rationale.


-- pat

Patrick Rogers
progers@acm.org

* Oh sure, I know it happens, but this isn't just anybody we're
talking about here.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Jay Martin]

Matthew Heaney wrote:
> 
> dewarr@my-dejanews.com writes:
> 
> > In article <3600E72E.24C93C94@cl.cam.ac.uk>,
> >   Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> >
> > > I thought that Dijkstra wrote years after his famous criticism on Ada,
> > > which basically killed interest on Ada in the academic community for
> > > many years, a quite nice foreword for an Ada 83 textbook by Jean Ichiba.
> >
> > Perhaps you are talking about AH's Turing address, which
> > certainly did not "kill interest on Ada in the academic
> > community" [after all at least two major Ada vendors playing
> > today have their roots in academic research efforts]. AH did
> > also write a nice forward for a book by Brian Wichman.
> 
> I have to disagree with you, Robert.  It is my opinion that it was
> Hoare's Turing Award speech that single-handedly derailed the Ada
> language effort.  He essentially argued that by using Ada, "the fate of
> mankind" was at stake.
> 
> People listened to him.  Lots of people listened to him.  To this day,
> people still quote the Hoare speech (among them, Bertrand Meyer) in
> order to back up their own criticisms of Ada.  (The argument goes
> something like, "See, Tony Hoare said Ada was bad, so it must be so.")

Who or what has the power to make a language popular in this field?
I don't see CS computer language academics anywhere close to the driver
seat.  In fact, I don't even think that software engineering language
design is a viable academic field.  It seems to me that most of CS 
even scoffs at software engineering, let alone SE language design.
CS academia doesn't really care about programming, thus academia just
follows industry or whatever is available.  So, academia being apathetic
to the whole question, didn't really care what Hoare said (not their
field).

I don't think industry takes what crackpot academics say seriously, thus
I don't think they cared what Hoare said. 

IMO Ada died because:
  -- A lot of programmers scoff at anything the miltary does and the
     whole defense industry. In fact, defense workers are high tech lepers.
  -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....
  -- Ada was not C, thus perceived worthless for Unix and Windows.
  -- Mismanagement by the DOD.
  -- No hyped technology that it could be piggybacked on. (Like C, Java)
  -- Winning cold war sucked most of the life out of the defense field.

So it was more like "Ada sucks! and ... this Hoare guys says so too!".

Jay

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

Jay Martin wrote in message <361DBC60.C153BBAD@earthlink.net>...
<snip>

I know (think) you're reporting reasons rather than asseting them,
but some cry out for a reponse.


>IMO Ada died because:

The fly-by-wire Boeing 777 uses a dead language?

An OOP language younger than Java (Ada 95) is dead?

Granted, Ada isn't the most popular language, but I cannot agree
that it is dead.  Nobody (credible) said it was supposed to be the
last language, or the most widely used.

>  -- A lot of programmers scoff at anything the miltary does and
the
>     whole defense industry. In fact, defense workers are high tech
lepers.

Yes, I've heard that.  But didn't DARPA found and fund what grew
into the Internet?  What do these programmers, who no doubt use the
Internet all the time, think the 'D' stood for?

>  -- Ada compilers were late, buggy, slow, too expensive, no
libraries, ....

That was indeed a problem.  Was.  Libraries are still an issue,
compared to Java.

>  -- Ada was not C, thus perceived worthless for Unix and Windows.

Yup.

>  -- Mismanagement by the DOD.

IMHO this is the big one.  DoD has abandoned any pretense of
managing their software expenses.  Are they not still the biggest
customer of software?  They wasted a good technology for lack of
will, and have released any grip on the controllng development
costs.  Instead of a comparatively simple policy of "Here's the
default language.  Use it unless there's a provable cost benefit to
using something else on this project.", which was ignored, we now
have "Do an analysis to see which language is the best for this
project.", which will also be ignored.

>  -- No hyped technology that it could be piggybacked on. (Like C,
Java)

Yes.

>  -- Winning cold war sucked most of the life out of the defense
field.

Yes again.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Dave Wood]

Jay Martin wrote:
> 
> IMO Ada died because:
>   -- A lot of programmers scoff at anything the miltary does and the
>      whole defense industry. In fact, defense workers are high tech lepers.
>   -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....
>   -- Ada was not C, thus perceived worthless for Unix and Windows.
>   -- Mismanagement by the DOD.
>   -- No hyped technology that it could be piggybacked on. (Like C, Java)
>   -- Winning cold war sucked most of the life out of the defense field.

An accurate portrayal of perceptions, circumstance,
and past history.  Well done.

But, the premise is wrong.  I have a *very* long customer
list to prove it wrong.

I think you'd be hard-pressed to find a language with a 
longer list of substantive, recent project wins, other 
than the ubiquitous C/C++ and Java (and I'm not sure
just how many Java wins would qualify as "substantive"
at this point, but presumably the Java list is building).  
Yet, where is the talk of all the *other* languages out 
there being "dead"?  What of the long line of languages
that are very fashionable, but used by essentially no
one for real projects?  Are they dead, or are they
just cool?

What is the basis for attaching such a stigma to Ada?  
Is this self-fulfilling prophecy?  If enough people say 
it, maybe it will become true?  I find such talk rather 
reminiscent of contemporary Washington politics.

I wish to publicly thank the DoD for dropping its
ludicrous and unenforced "mandate".  My product sales
have increased 30% per year for the past three years,
thank you very much.

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[last.first]

Jay Martin wrote:
> 
> Matthew Heaney wrote:
> >
> > dewarr@my-dejanews.com writes:
> >
> > > In article <3600E72E.24C93C94@cl.cam.ac.uk>,
> > >   Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> > >
<snip>
> IMO Ada died because:

Is it dead?  I thought that the current fly-by-wire commercial
offerings from Boeing (and military/commercial Lockheed-Martin
Hercules/C-130) used ADA for the flight control and other
safety-of-flight/life-critical system software?

>   -- A lot of programmers scoff at anything the miltary does and the
>      whole defense industry. In fact, defense workers are high tech lepers.

Pity, isn't it, that some of the self-declared moral-high-ground volk
[nasty overtones of self-appointed ubermensch philosophy intentional]
see people who work/worked in defense industry as lepers?  

Bigger pity that people who implement late, unpredictable, unreliable,
and sometimes unsafe systems are not looked upon as lepers instead.

Consider:  in the defense industry, a fair number of engineering staff
were/are habituated to the idea that if you don't do things right,
property is damaged or people die unnecessarily, and that is a BAD
THING.  

Thus a few of them might actually be inclined to design and produce
products which 
a)  degrade gracefully rather than fail catastrophically, 
b)  have internal fault tolerence/detection/recovery, 
c)  build products assuming long service lifetimes (inevitably, since
software is used much longer than anyone expects or wants), so MAKE
the products maintainable from the start of the design process.

>   -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....

And commercial Fortrans and Pascals were not?  For some reason, ADA
became a bete noir;  I suspect mostly because the CUSTOMER wanted it
and the vendors didn't want to spend any money on learning to do it. 
Longterm thinking be dammed, what's the quarterly bottom line?

>   -- Ada was not C, thus perceived worthless for Unix and Windows.

I've been of the opinion that compilers need to add internal error
checking since I got into this business:  the standard "buffer
overflow"/"stack overflow" exploits in things like webservers just
demonstrates that even if the people who write the code probably KNOW
BETTER, they don't reliably implement error checks.  

Does this mean that C and C++ are bad per se?  

No:  it just means that a lot of code goes into production systems
that does not implement error checking that freshman computer science
101 demanded one design and build in.
The idea of designing/building error checking into your code, at least
in CS101, has been pretty consistent over the years;  the idea of not
bothering, since "it's just an irrelevent academic exercize, has also
been pretty common to language specific training over the years, too.

[The first time I took CS 101 was 1974, using PL1; I've retaken
selected CS, IS, and SE courses ever since:  including the
introductory CS101 in 1991 (ISO Pascal), 1995 (Microsoft C), and 1997
(JAVA) and noted that EVERY TIME they emphacized writing error
detecting/error tolerent code.]

ADA (and Pascal and Eiffel and half a dozen other unfashionable
languages) was a step in the direction of moving some of the neglected
portions of the software design/engineering/implementation process out
of the hands of the coder and into the realm of the automated tool
(i.e., the language's syntax forces it or the compiler does it for
you).

>   -- Mismanagement by the DOD.

No argument there:  establish a requirement and then arbitrarily
waiver the requirement is mismanagement.

>   -- No hyped technology that it could be piggybacked on. (Like C, Java)

What's the relevance?  

The announced intent of ADA was to provide a way to produce better
(reliability/maintainability sense) code that could be reused.  

That the industry was/is still driven by coders using handicraft
worker's perspectives and by some (or most) upper management with a
"don't spend a penny that you don't have to since everything is based
on quarterly profit" perspective rather than not isn't exactly a
glowing review of the industry.

>   -- Winning cold war sucked most of the life out of the defense field.

Maybe.  Or maybe the lack of QRC program quick-fixes every 14 months
for mission critical threats isn't relevant.  

> 
> So it was more like "Ada sucks! and ... this Hoare guys says so too!".
>
Sure:  and we're still floundering on in an industry where pre-1970
techniques such as DOCUMENTATION and VERSION CONTROL seem to be mostly
regarded as wasteful, unnecessary, or pointless.
>
> Jay

-- 
Standard disclaimer.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Gautier.DeMontmollin]

pluto1@choice.net (Brian Mueller) writes:

[much snipped]
> Well, it's 1998, I'm in C.S. 101 at the University of Cincinnati, RWC
> and we're learning how to badly code ADA (i.e. forget about code
> errors, concentrate on "design documents")
> 
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  Anyone
> wonder why the object ADA compiler and GUI program is written in C?
> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.

It won't be "a bit", unless you are a super-human, never distracted...

For the "FASTER" it depend on the compiler. Maybe it's true for Object Ada.
Try to compare C code with equivalent Ada code having Inline pragmas at the
right places, compiled by GNAT with options like "-O2 -gnatpn"...

For learning GREAT C, surf the Net! You'll find _plenty_ of portable,
memory-model independant, readable C code, with clear, simple headers
structured like Ada specifications...

-- 
Gautier

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Brian Mueller]

On 13 Oct 1998 00:12:49 GMT, last.first@domain.nul wrote:

<...snip...>
>
>>   -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....
>
>And commercial Fortrans and Pascals were not?  For some reason, ADA
>became a bete noir;  I suspect mostly because the CUSTOMER wanted it
>and the vendors didn't want to spend any money on learning to do it. 
>Longterm thinking be dammed, what's the quarterly bottom line?

Damned straight, freakin ObjectADA that I got for school has got to be
the slowest thing I've ever worked with, and it frequently
crashes....very frequently.

>
>>   -- Ada was not C, thus perceived worthless for Unix and Windows.
>
>I've been of the opinion that compilers need to add internal error
>checking since I got into this business:  the standard "buffer
>overflow"/"stack overflow" exploits in things like webservers just
>demonstrates that even if the people who write the code probably KNOW
>BETTER, they don't reliably implement error checks.  
>
>Does this mean that C and C++ are bad per se?  
>
>No:  it just means that a lot of code goes into production systems
>that does not implement error checking that freshman computer science
>101 demanded one design and build in.
>The idea of designing/building error checking into your code, at least
>in CS101, has been pretty consistent over the years;  the idea of not
>bothering, since "it's just an irrelevent academic exercize, has also
>been pretty common to language specific training over the years, too.

I disagree, shit in my C.S. 101 programming class (which is guess
what, ADA) my instructor took points OFF my first two projects because
I implemented Error checking and handling (for constraint and invalid
input errors).  I would have to say that I said "fuck errors" for my
third design.  Well, they just taught me that error checking isn't a
good thing.

>
>[The first time I took CS 101 was 1974, using PL1; I've retaken
>selected CS, IS, and SE courses ever since:  including the
>introductory CS101 in 1991 (ISO Pascal), 1995 (Microsoft C), and 1997
>(JAVA) and noted that EVERY TIME they emphacized writing error
>detecting/error tolerent code.]

Well, it's 1998, I'm in C.S. 101 at the University of Cincinnati, RWC
and we're learning how to badly code ADA (i.e. forget about code
errors, concentrate on "design documents")

Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
teach my how not to screw up C so I could write anything.  Anyone
wonder why the object ADA compiler and GUI program is written in C?
Because with a bit of extra work FASTER programs can be written in C
that do the same thing that ADA will do.

>
>ADA (and Pascal and Eiffel and half a dozen other unfashionable
>languages) was a step in the direction of moving some of the neglected
>portions of the software design/engineering/implementation process out
>of the hands of the coder and into the realm of the automated tool
>(i.e., the language's syntax forces it or the compiler does it for
>you).
>
>>   -- Mismanagement by the DOD.
>
>No argument there:  establish a requirement and then arbitrarily
>waiver the requirement is mismanagement.
>
>>   -- No hyped technology that it could be piggybacked on. (Like C, Java)
>
>What's the relevance?  
>
>The announced intent of ADA was to provide a way to produce better
>(reliability/maintainability sense) code that could be reused.  
>
>That the industry was/is still driven by coders using handicraft
>worker's perspectives and by some (or most) upper management with a
>"don't spend a penny that you don't have to since everything is based
>on quarterly profit" perspective rather than not isn't exactly a
>glowing review of the industry.
>
>>   -- Winning cold war sucked most of the life out of the defense field.
>
>Maybe.  Or maybe the lack of QRC program quick-fixes every 14 months
>for mission critical threats isn't relevant.  
>
>> 
>> So it was more like "Ada sucks! and ... this Hoare guys says so too!".
>>
>Sure:  and we're still floundering on in an industry where pre-1970
>techniques such as DOCUMENTATION and VERSION CONTROL seem to be mostly
>regarded as wasteful, unnecessary, or pointless.
>>
>> Jay

Now that you bring that up, I got into trouble for having too many
comment blocks in my code, WFT is this?  I could have handed my
project to anyone in that room and they would have been able to read
it and understand what I was doing easily from my comments.  I've
always been told, the more, the better.  I hate my C.S. class, can't
wait until the spring when I get to take C (which I know a bit), and
learn how to do it RIGHT.


All my points have been based on my own experience, yours may differ,
my point was.  In my C.S. class I'm being told NOT to do error
handling, we'll cover error handling in a few quarters, that's not
until chaper 45.....etc.  And that commenting your source is bad (he
wants one comment block at the top of the program, with name, date,
version, short description, that's it.  It's not all us, it's our
teachers, who are just about 80 years old, and want us to follow
exactly what they did.

PLUTO of ilL
	pluto1@choice.NOSPAM-NOSPAM.net

C-ya

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[midlamD]

I think I can safely say (as a 62-year old) that being anti-documentation
has nothing to do with age.  Most of the programming peers that I most
respected were serious inline documenters (I respected them for their
solutions, not their comments <g>.)  
I don't know what your perfesser's problem is, but it sounds to me like he
just doesn't want to deal with a lot of paper -- he knows what the "right"
code is and he doesn't want to have to look hard to find it.

Brian Mueller <pluto1@choice.net> wrote in article
<3630b064.23189339@news.supernews.com>...
> On 13 Oct 1998 00:12:49 GMT, last.first@domain.nul wrote:
> 
> <...snip...>
> >
> >>   -- Ada compilers were late, buggy, slow, too expensive, no
libraries, ....
> >
> >And commercial Fortrans and Pascals were not?  For some reason, ADA
> >became a bete noir;  I suspect mostly because the CUSTOMER wanted it
> >and the vendors didn't want to spend any money on learning to do it. 
> >Longterm thinking be dammed, what's the quarterly bottom line?
> 
> Damned straight, freakin ObjectADA that I got for school has got to be
> the slowest thing I've ever worked with, and it frequently
> crashes....very frequently.
> 
> >
> >>   -- Ada was not C, thus perceived worthless for Unix and Windows.
> >
> >I've been of the opinion that compilers need to add internal error
> >checking since I got into this business:  the standard "buffer
> >overflow"/"stack overflow" exploits in things like webservers just
> >demonstrates that even if the people who write the code probably KNOW
> >BETTER, they don't reliably implement error checks.  
> >
> >Does this mean that C and C++ are bad per se?  
> >
> >No:  it just means that a lot of code goes into production systems
> >that does not implement error checking that freshman computer science
> >101 demanded one design and build in.
> >The idea of designing/building error checking into your code, at least
> >in CS101, has been pretty consistent over the years;  the idea of not
> >bothering, since "it's just an irrelevent academic exercize, has also
> >been pretty common to language specific training over the years, too.
> 
> I disagree, shit in my C.S. 101 programming class (which is guess
> what, ADA) my instructor took points OFF my first two projects because
> I implemented Error checking and handling (for constraint and invalid
> input errors).  I would have to say that I said "fuck errors" for my
> third design.  Well, they just taught me that error checking isn't a
> good thing.
> 
> >
> >[The first time I took CS 101 was 1974, using PL1; I've retaken
> >selected CS, IS, and SE courses ever since:  including the
> >introductory CS101 in 1991 (ISO Pascal), 1995 (Microsoft C), and 1997
> >(JAVA) and noted that EVERY TIME they emphacized writing error
> >detecting/error tolerent code.]
> 
> Well, it's 1998, I'm in C.S. 101 at the University of Cincinnati, RWC
> and we're learning how to badly code ADA (i.e. forget about code
> errors, concentrate on "design documents")
> 
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  Anyone
> wonder why the object ADA compiler and GUI program is written in C?
> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.
> 
> >
> >ADA (and Pascal and Eiffel and half a dozen other unfashionable
> >languages) was a step in the direction of moving some of the neglected
> >portions of the software design/engineering/implementation process out
> >of the hands of the coder and into the realm of the automated tool
> >(i.e., the language's syntax forces it or the compiler does it for
> >you).
> >
> >>   -- Mismanagement by the DOD.
> >
> >No argument there:  establish a requirement and then arbitrarily
> >waiver the requirement is mismanagement.
> >
> >>   -- No hyped technology that it could be piggybacked on. (Like C,
Java)
> >
> >What's the relevance?  
> >
> >The announced intent of ADA was to provide a way to produce better
> >(reliability/maintainability sense) code that could be reused.  
> >
> >That the industry was/is still driven by coders using handicraft
> >worker's perspectives and by some (or most) upper management with a
> >"don't spend a penny that you don't have to since everything is based
> >on quarterly profit" perspective rather than not isn't exactly a
> >glowing review of the industry.
> >
> >>   -- Winning cold war sucked most of the life out of the defense
field.
> >
> >Maybe.  Or maybe the lack of QRC program quick-fixes every 14 months
> >for mission critical threats isn't relevant.  
> >
> >> 
> >> So it was more like "Ada sucks! and ... this Hoare guys says so too!".
> >>
> >Sure:  and we're still floundering on in an industry where pre-1970
> >techniques such as DOCUMENTATION and VERSION CONTROL seem to be mostly
> >regarded as wasteful, unnecessary, or pointless.
> >>
> >> Jay
> 
> Now that you bring that up, I got into trouble for having too many
> comment blocks in my code, WFT is this?  I could have handed my
> project to anyone in that room and they would have been able to read
> it and understand what I was doing easily from my comments.  I've
> always been told, the more, the better.  I hate my C.S. class, can't
> wait until the spring when I get to take C (which I know a bit), and
> learn how to do it RIGHT.
> 
> 
> All my points have been based on my own experience, yours may differ,
> my point was.  In my C.S. class I'm being told NOT to do error
> handling, we'll cover error handling in a few quarters, that's not
> until chaper 45.....etc.  And that commenting your source is bad (he
> wants one comment block at the top of the program, with name, date,
> version, short description, that's it.  It's not all us, it's our
> teachers, who are just about 80 years old, and want us to follow
> exactly what they did.
> 
> PLUTO of ilL
> 	pluto1@choice.NOSPAM-NOSPAM.net
> 
> C-ya
> 
> 
> 
> 
> 
> 
> 

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ell]

"midlamD" <MidlamD@abacustech.com> wrote:

>I think I can safely say (as a 62-year old) that being anti-documentation
>has nothing to do with age.  Most of the programming peers that I most
>respected were serious inline documenters (I respected them for their
>solutions, not their comments <g>.)  
>I don't know what your perfesser's problem is, but it sounds to me like he
>just doesn't want to deal with a lot of paper -- he knows what the "right"
>code is and he doesn't want to have to look hard to find it.

Though I consider a major aspect of good commenting to be keeping
comments as "out of the way" as possible.

Elliott
--
                :=***=:   VOTE  NO  TO  MODERATION!   :=***=: 
CRAFTISM SHOULD NOT USE USENET RESOURCES TO AVOID CRITICISM!
              MODERATORS SHOULD NOT HAVE LIFETIME TERMS!
        :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                      Hallmarks of the best SW Engineering
  Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
    Copyright 1998 Elliott. exclusive of others' writing. may be copied
      without permission only in the comp.* usenet and bitnet groups.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Arun Mangalam]

There are practically only two reasosn why Brian Mueller would reply this way:

1) His teacher is complete moron who doesn't comment anything and does
barely any error-checking with Ada.
2) Brian does not know how to listen or understand what the professor is
trying to do or say.

The first case is probably not very credible, since most professors are
not imbeciles not able to see error-checking is valuable and commenting is
extremely valuable.

The second case sounds very possible, since the professor might have
wanted the students to learn the compile-time error-checking of Ada and
how Ada synatx comments itself. This is especially true because many of
the students are used to other relatively unreadable languages such as C,
where they are somewhat under the impression that shorter names are more
efficient. If this is the case, which it probably is, it's very
disheartening to see how many non-thinking monkeys there are running
around claiming to know something.

I, myself, am learning Ada and find it's compile time error checking
completely awesome. I make so many mistakes in C where Ada would have
either had a simpler way to do it or would show me I'm making a mistake
before the program crashes. I just wish Ada had some free frameworks as
comprehensive as that for C for developing GUI applications under the
Macintosh or, maybe, Windows. PowerPlant in Ada would be fantastic. :)

In article <3630b064.23189339@news.supernews.com>, pluto1@choice.net
(Brian Mueller) wrote:

>On 13 Oct 1998 00:12:49 GMT, last.first@domain.nul wrote:
>
><...snip...>
>>
>>>   -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....
>>
>>And commercial Fortrans and Pascals were not?  For some reason, ADA
>>became a bete noir;  I suspect mostly because the CUSTOMER wanted it
>>and the vendors didn't want to spend any money on learning to do it. 
>>Longterm thinking be dammed, what's the quarterly bottom line?
>
>Damned straight, freakin ObjectADA that I got for school has got to be
>the slowest thing I've ever worked with, and it frequently
>crashes....very frequently.
>
>>
>>>   -- Ada was not C, thus perceived worthless for Unix and Windows.
>>
>>I've been of the opinion that compilers need to add internal error
>>checking since I got into this business:  the standard "buffer
>>overflow"/"stack overflow" exploits in things like webservers just
>>demonstrates that even if the people who write the code probably KNOW
>>BETTER, they don't reliably implement error checks.  
>>
>>Does this mean that C and C++ are bad per se?  
>>
>>No:  it just means that a lot of code goes into production systems
>>that does not implement error checking that freshman computer science
>>101 demanded one design and build in.
>>The idea of designing/building error checking into your code, at least
>>in CS101, has been pretty consistent over the years;  the idea of not
>>bothering, since "it's just an irrelevent academic exercize, has also
>>been pretty common to language specific training over the years, too.
>
>I disagree, shit in my C.S. 101 programming class (which is guess
>what, ADA) my instructor took points OFF my first two projects because
>I implemented Error checking and handling (for constraint and invalid
>input errors).  I would have to say that I said "fuck errors" for my
>third design.  Well, they just taught me that error checking isn't a
>good thing.
>
>>
>>[The first time I took CS 101 was 1974, using PL1; I've retaken
>>selected CS, IS, and SE courses ever since:  including the
>>introductory CS101 in 1991 (ISO Pascal), 1995 (Microsoft C), and 1997
>>(JAVA) and noted that EVERY TIME they emphacized writing error
>>detecting/error tolerent code.]
>
>Well, it's 1998, I'm in C.S. 101 at the University of Cincinnati, RWC
>and we're learning how to badly code ADA (i.e. forget about code
>errors, concentrate on "design documents")
>
>Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
>teach my how not to screw up C so I could write anything.  Anyone
>wonder why the object ADA compiler and GUI program is written in C?
>Because with a bit of extra work FASTER programs can be written in C
>that do the same thing that ADA will do.
>
>>
>>ADA (and Pascal and Eiffel and half a dozen other unfashionable
>>languages) was a step in the direction of moving some of the neglected
>>portions of the software design/engineering/implementation process out
>>of the hands of the coder and into the realm of the automated tool
>>(i.e., the language's syntax forces it or the compiler does it for
>>you).
>>
>>>   -- Mismanagement by the DOD.
>>
>>No argument there:  establish a requirement and then arbitrarily
>>waiver the requirement is mismanagement.
>>
>>>   -- No hyped technology that it could be piggybacked on. (Like C, Java)
>>
>>What's the relevance?  
>>
>>The announced intent of ADA was to provide a way to produce better
>>(reliability/maintainability sense) code that could be reused.  
>>
>>That the industry was/is still driven by coders using handicraft
>>worker's perspectives and by some (or most) upper management with a
>>"don't spend a penny that you don't have to since everything is based
>>on quarterly profit" perspective rather than not isn't exactly a
>>glowing review of the industry.
>>
>>>   -- Winning cold war sucked most of the life out of the defense field.
>>
>>Maybe.  Or maybe the lack of QRC program quick-fixes every 14 months
>>for mission critical threats isn't relevant.  
>>
>>> 
>>> So it was more like "Ada sucks! and ... this Hoare guys says so too!".
>>>
>>Sure:  and we're still floundering on in an industry where pre-1970
>>techniques such as DOCUMENTATION and VERSION CONTROL seem to be mostly
>>regarded as wasteful, unnecessary, or pointless.
>>>
>>> Jay
>
>Now that you bring that up, I got into trouble for having too many
>comment blocks in my code, WFT is this?  I could have handed my
>project to anyone in that room and they would have been able to read
>it and understand what I was doing easily from my comments.  I've
>always been told, the more, the better.  I hate my C.S. class, can't
>wait until the spring when I get to take C (which I know a bit), and
>learn how to do it RIGHT.
>
>
>All my points have been based on my own experience, yours may differ,
>my point was.  In my C.S. class I'm being told NOT to do error
>handling, we'll cover error handling in a few quarters, that's not
>until chaper 45.....etc.  And that commenting your source is bad (he
>wants one comment block at the top of the program, with name, date,
>version, short description, that's it.  It's not all us, it's our
>teachers, who are just about 80 years old, and want us to follow
>exactly what they did.
>
>PLUTO of ilL
>        pluto1@choice.NOSPAM-NOSPAM.net
>
>C-ya

-- 
asmang@CRAZYSPAMmail.wm.edu
remove the CRAZYSPAM to reply.
These spamming buggers are really annoying.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[DPH]

Arun Mangalam wrote:

> There are practically only two reasosn why Brian Mueller would reply this way:
>
> 1) His teacher is complete moron who doesn't comment anything and does
> barely any error-checking with Ada.
> 2) Brian does not know how to listen or understand what the professor is
> trying to do or say.
>
> The first case is probably not very credible, since most professors are
> not imbeciles...

Aha! There you have it.  PROFESSORS!  Who says the guy even HAS a professor teaching
his class!

Been to a University in the last few years?  I took a course at IUPUI (Indiana
University Purdue University at Indianapolis) and signed up for C++.  They hired
some ya-hoo from private industry as an "associate" professor.  The guy wouldn't
answer questions, wouldn't teach the subject, and spent fully 3 of the 12 or so
weeks of the course showing off how he could derive the level at which a sphere of a
given density floated in a liquid of greater density via the calculus.  Meanwhile,
he used foul language, and was generally either a hinderance to the learning
process, or at least of no help.  Oh, yeah, he started off teaching C instead of
C++, and a little over halfway thru the course asked if we'd mind if he just
finished the course by teaching C only.  When all three of us from the Naval Air
Warfare Center, Aircraft Division, Indianapolis objected, he finally got on the
stick and got into the teaching of C++, but it was a much less educational
experience than it could have been.

There were others like him, from the horror stories I was getting from those that
took other classes.  The University goes out and gets these guys from some local
private industry office that want to make a buck in the evening, and don't
necessarily have a clue about actual software engineering or niceities such as
commenting code, etc., but are up to their eyeballs in their own code all day,
possibly wondering why they can't figure out the uncommented coded they made 3 years
ago that they have to modify now.

Soooo....  maybe this guy's "professor" really is a moron in terms of software
design or with respect to playing the role of educator...

DPH

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Michael Stark]

DPH wrote:
> 
> Arun Mangalam wrote:
> 
> > There are practically only two reasosn why Brian Mueller would reply this way:
> >
> > 1) His teacher is complete moron who doesn't comment anything and does
> > barely any error-checking with Ada.
> > 2) Brian does not know how to listen or understand what the professor is
> > trying to do or say.
> >
> > The first case is probably not very credible, since most professors are
> > not imbeciles...
> 
> Aha! There you have it.  PROFESSORS!  Who says the guy even HAS a professor teaching
> his class!
> 
> Been to a University in the last few years?  I took a course at IUPUI (Indiana
> University Purdue University at Indianapolis) and signed up for C++.  They hired
> some ya-hoo from private industry as an "associate" professor.

<horror story snipped>

> There were others like him, from the horror stories I was getting from those that
> took other classes.  The University goes out and gets these guys from some local
> private industry office that want to make a buck in the evening, and don't
> necessarily have a clue about actual software engineering or niceities such as
> commenting code, etc., but are up to their eyeballs in their own code all day,
> possibly wondering why they can't figure out the uncommented coded they made 3 years
> ago that they have to modify now.

This is waaaaaaaaaaaaaaaaaaaaay overgeneralized!  I have had courses
taught by full-time professors, by grad students, by post-docs, and by
part-time instructors.
I have had horrible professors, and I have had solid instructors (and
vice-versa).

For me, two predictors that you can use early in the semester are

1)  Is the syllabus clear?  Does it tell you how many homeworks and
projects there
will be (or at least a good approximation)?  Does it give you a schedule
of when
exams are and when projects (or interim steps in semester-long projects)
are due?
Does it give you a breakdown of how your final grade will be determined?

2)  Does the teacher work clear examples in class, or just talk in
generalities?
Obviously (to me), most of the learning is done in the work outside of
class, but
clear examples in lecture make your studying sooooo much easier.

My guess is that the professor that the original poster is whining about
(maybe
with justification ;) does not meet these criteria.  The other option is
that the
student is to blame, but I would never assume this without evidence.

Whether the professor, student, or TA is at fault, it is clear to me
that the programming language isn't.  My personal preference would be to
use a language such as Pascal or Ada in the first course, and introduce
trickier languages such as C++ in more advanced courses.  I disagree
with any program that builds around a single language.
In my current grad program I've (so far) used LISP, C, C with Oracle
calls embedded,
Visual Basic, Matlab, C++, and am about to start learning Tcl for a GIS
project.  I'm
expecting to use Java in at least one of my courses next semester.
> 
> Soooo....  maybe this guy's "professor" really is a moron in terms of software
> design or with respect to playing the role of educator...
> 
> DPH

-- 
Michael Stark
Goddard Research & Study Fellow
University of Maryland, College Park
e-mail: mstark@cs.umd.edu
phone: (301) 405-2721
"Godspeed, John Glenn"

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ell]

pluto1@choice.net (Brian Mueller) wrote:

>I disagree, s[**[t in my C.S. 101 programming class (which is guess
>what, ADA) my instructor took points OFF my first two projects because
>I implemented Error checking and handling (for constraint and invalid
>input errors).  I would have to say that I said "fuck errors" for my
>third design.  Well, they just taught me that error checking isn't a
>good thing.

My experience was just the opposite, my CS teachers would take off
more for not implementing error checking than they would for the
program not fulfilling one of the use case requirements.

Elliott
--
                :=***=:   VOTE  NO  TO  MODERATION!   :=***=: 
CRAFTISM SHOULD NOT USE USENET RESOURCES TO AVOID CRITICISM!
              MODERATORS SHOULD NOT HAVE LIFETIME TERMS!
        :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                      Hallmarks of the best SW Engineering
  Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
    Copyright 1998 Elliott. exclusive of others' writing. may be copied
      without permission only in the comp.* usenet and bitnet groups.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Dave Wood]

Brian Mueller wrote:
> 
> >And commercial Fortrans and Pascals were not?  For some reason, ADA
> >became a bete noir;  I suspect mostly because the CUSTOMER wanted it
> >and the vendors didn't want to spend any money on learning to do it.
> >Longterm thinking be dammed, what's the quarterly bottom line?
> 
> Damned straight, freakin ObjectADA that I got for school has got to be
> the slowest thing I've ever worked with, and it frequently
> crashes....very frequently.

I'm sorry for your unpleasant experience.  However, I have
to differ on this issue.  The ObjectAda compiler is quite
fast - faster than a lot of C compilers I've used.  Most
likely, you have an inefficient configuration.  In fact,
given a proper configuration, the only part of the build 
cycle that I would classify as slow is the linker, which
is from Microsoft.  Presumably written in C or assembler.

Regarding crashes, on Windows who can say?  DLL conflicts
maybe.  Probably you are also using an out-dated release
of the product.  The free download version is 3 revs old
(next release is this Dec/Jan.)  This is now a mature and
robust product - I have 10's of thousands of users and
not a lot of complaints about either performance or 
crashes.  If you're serious about this, I suggest you
properly document the instances and submit them to our
on-line support address, adasupport@aonix.com, where they
will be logged and reviewed.

>> 
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  

I've written quite a lot of C.  Much more than Ada.  
In fact, I'm quite good at it.  But, best way to teach not 
to screw it up is to not use it other than in well-defined
circumstances.  IMHO, of course.

> Anyone
> wonder why the object ADA compiler and GUI program is written in C?

No need to wonder.  I'll tell you why.

First of all, the compiler front-end is written in C++ because
at the time it was written there were no validated Ada 95
compilers.  The back-end is written in Ada.  The runtime is
written in Ada (and some assembly).  The GUI Builder is
written in Visual Basic.  As you can see, we don't believe
in taking a religious view on languages - use the one(s)
that make the most sense when all factors are taken into
consideration.

> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.

Odd comment here - previously you complained that the
compiler is too slow, and here you imply that C results
in faster programs, and that the compiler is written in
C. All of these can't be logically true at the same time,
can they?

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Dale Stanbrough]

Brian Mueller wrote:

"Now that you bring that up, I got into trouble for having too many
 comment blocks in my code, WFT is this?  I could have handed my
 project to anyone in that room and they would have been able to read
 it and understand what I was doing easily from my comments.  I've
 always been told, the more, the better.  I hate my C.S. class, can't
 wait until the spring when I get to take C (which I know a bit), and
 learn how to do it RIGHT."


Not commenting on your particular situation, but definately there can be
such a thing as too many comments. The one comment per line of code 
is definately the wrong thing to more often than not.

It seems to me you have a problem with the staff and/or course, rather 
than Ada.

Dale

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ehud Lamm]

On Fri, 23 Oct 1998, Brian Mueller wrote:

> On 13 Oct 1998 00:12:49 GMT, last.first@domain.nul wrote:
> I disagree, shit in my C.S. 101 programming class (which is guess
> what, ADA) my instructor took points OFF my first two projects because
> I implemented Error checking and handling (for constraint and invalid
> input errors).  I would have to say that I said "fuck errors" for my
> third design.  Well, they just taught me that error checking isn't a
> good thing.

In most cases it is a GOOD THING. :-)
> 
> 
> Well, it's 1998, I'm in C.S. 101 at the University of Cincinnati, RWC
> and we're learning how to badly code ADA (i.e. forget about code
> errors, concentrate on "design documents")
>
How sad. Some insturtors can be bad. How surprising...
 
> 
> Now that you bring that up, I got into trouble for having too many
> comment blocks in my code, WFT is this?  I could have handed my
> project to anyone in that room and they would have been able to read
> it and understand what I was doing easily from my comments.  I've
> always been told, the more, the better.I hate my C.S. class, can't
> wait until the spring when I get to take C (which I know a bit), and
> learn how to do it RIGHT.
> 

As I said teachers may be fools as much as the next guy. But sometimes
they do have a point. I am grading ADA assignments right now, and when one
student goes against my explicit instructions, without even attempting to
explain why - I usually take points off. I say "I want a comment at the
beggining of the program telling what its about". No comment - I take
points of. It is the fair thing to do, as other students bother to do what
I ask them to. I try to be reasonable, and if someone explains himself
convincingly I am the first one to cheer him. 

One other thing I don't like and I think other intstructors usually share
my view. When the exercise is about chapter 2, don't use stuff from
chapter 10 (or stuff that is outside the scope of the course alltoghter).
It is then hard to compare your code to others, in order to grade it
fairly. You also usually miss the concepts you were supposed to strugle
with, since you avoid them by using more advanced techniques. In exercises
I expect you to stick to what was taught, unsless you get specific
premission otherwise. Projects are different in the respect since they are
larger and go to show indepenent work.

Maybe these are the resons your instructors took points off, maybe they
had different reasons, and maybe they are simply jerks. I do not see how
this goes to show you anything about C or ADA as languages. I doesn't even
give you any real basis for comparing the C and ADA "philosophies", as
oppsoed to the languages themselves.

Write generic code in C (not C++). Then comapre it to ADA... There are
many other examples. But this may belong to another thread.

Ehud Lamm     mslamm@mscc.huji.ac.il
 

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Dave Wood]

Brian Mueller wrote:
> 
> >And commercial Fortrans and Pascals were not?  For some reason, ADA
> >became a bete noir;  I suspect mostly because the CUSTOMER wanted it
> >and the vendors didn't want to spend any money on learning to do it.
> >Longterm thinking be dammed, what's the quarterly bottom line?
> 
> Damned straight, freakin ObjectADA that I got for school has got to be
> the slowest thing I've ever worked with, and it frequently
> crashes....very frequently.

I'm sorry for your unpleasant experience.  However, I have
to differ on this issue.  The ObjectAda compiler is quite
fast - faster than a lot of C compilers I've used.  Most
likely, you have an inefficient configuration.  In fact,
given a proper configuration, the only part of the build 
cycle that I would classify as slow is the linker, which
is from Microsoft.  Presumably written in C or assembler.

Regarding crashes, on Windows who can say?  DLL conflicts
maybe.  Probably you are also using an out-dated release
of the product.  The free download version is 3 revs old
(next release is this Dec/Jan.)  This is now a mature and
robust product - I have 10's of thousands of users and
not a lot of complaints about either performance or 
crashes.  If you're serious about this, I suggest you
properly document the instances and submit them to our
on-line support address, adasupport@aonix.com, where they
will be logged and reviewed.

>> 
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  

I've written quite a lot of C.  Much more than Ada.  
In fact, I'm quite good at it.  But, best way to teach not 
to screw it up is to not use it other than in well-defined
circumstances.  IMHO, of course.

> Anyone
> wonder why the object ADA compiler and GUI program is written in C?

No need to wonder.  I'll tell you why.

First of all, the compiler front-end is written in C++ because
at the time it was written there were no validated Ada 95
compilers.  The back-end is written in Ada.  The runtime is
written in Ada (and some assembly).  The GUI Builder is
written in Visual Basic.  As you can see, we don't believe
in taking a religious view on languages - use the one(s)
that make the most sense when all factors are taken into
consideration.

> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.

Odd comment here - previously you complained that the
compiler is too slow, and here you imply that C results
in faster programs, and that the compiler is written in
C. All of these can't be logically true at the same time,
can they?

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Tucker Taft]

Dave Wood (dpw@cts.com) wrote:

: ...
: First of all, the compiler front-end is written in C++ because
: at the time it was written there were no validated Ada 95
: compilers.  

Actually, the AdaMagic/ObjectAda front end is written in a mixture of C 
and Ada 95.  There is no use of C++.  C++ is used in parts of the browser 
GUI, I believe.  It is true that at the time we started writing the
front end, there were no validated Ada 95 compilers.  We could
have written in Ada 83, but our desire was to be able to license
this front end to compiler vendors who might or might not be
familiar with Ada, and who might be building a cross-compiler rather
than a native compiler, perhaps on a host where Ada 83 was not
available.  Furthermore, we were building only a front end, not
a full compiler, so bootstrapping was not an option.
(Note that the ObjectAda backend is bootstrapped.)

Now that we have a version of our front end that generates
ANSI C as an intermediate language, we have begun to use
Ada 95 in the front end itself, while still delivering just
ANSI C to our licencees.  In particular, parts of our new
front end optimizer are written in Ada 95.

In any case, I'm sorry to hear that the ObjectAda compiler
installed at the University of Cincinnati is slow.  It might
be helpful to know what version it is (if less than version 7,
it is the "old" technology), and what kind of computer it
is running on.  Our experience is that ObjectAda is quite
fast, approximately the same as Visual C++ on a PC.

ObjectAda is generally faster than C if you compile a number of files in a 
single execution of the compiler, because it is able to cache information
on "with"ed packages, while C/C++ include files can't easily be cached due
to possible preprocessor tricks.

: -- Dave Wood, Aonix
: -- Product Manager, ObjectAda for Windows
: -- http://www.aonix.com

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Bill Ghrist]

Brian Mueller wrote:
 
<snip>

> Damned straight, freakin ObjectADA that I got for school has got to be
> the slowest thing I've ever worked with, and it frequently
> crashes....very frequently.
> 

<snip>

> 
> Wish they would just teach me C, teach me GOOD C, teach me GREAT C,
> teach my how not to screw up C so I could write anything.  Anyone
> wonder why the object ADA compiler and GUI program is written in C?
> Because with a bit of extra work FASTER programs can be written in C
> that do the same thing that ADA will do.
> 

Hmmm; a little inconsistency here?  I haven't used ObjectAda, but I've
been using GNAT a little to teach myself Ada.  I haven't found that it
is particulary slow or that it crashes.  GNAT is written in Ada.  If you
are correct that ObjectAda is written in C, is slow, and crashes, what
does that say about which language can produce efficient error-free
code? 

Regards,
Bill Ghrist

P.S.  BTW, it's Ada, not ADA.  ADA is the Americans with Disabilities
Act.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ell]

Bill Ghrist <ghristwd@pgh.net> wrote:

>P.S.  BTW, it's Ada, not ADA.  ADA is the Americans with Disabilities
>Act.

It's tempting, but I *won't* say it.   :-}

Elliott
--
                :=***=:   VOTE  NO  TO  MODERATION!   :=***=: 
CRAFTISM SHOULD NOT USE USENET RESOURCES TO AVOID CRITICISM!
              MODERATORS SHOULD NOT HAVE LIFETIME TERMS!
        :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                      Hallmarks of the best SW Engineering
  Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
    Copyright 1998 Elliott. exclusive of others' writing. may be copied
      without permission only in the comp.* usenet and bitnet groups.

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dewarr]

In article <36351218.1353826@news.erols.com>,
  ell@access.digex.net wrote:
> Bill Ghrist <ghristwd@pgh.net> wrote:
>
> >P.S.  BTW, it's Ada, not ADA.  ADA is the Americans with Disabilities
> >Act.


At SGI, Tom Quiggle has a nice poster with President Clinton saying
something about counting on you to fulfill the promises of ADA :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Bertrand Meyer]

I'd like to clear up the chronology and Hoare references.

Matthew Heaney wrote:
> 
> dewarr@my-dejanews.com
	[I assume this is Robert Dewar but couldn't find a confirmation -- BM]
> writes:
 
> !! [...] Perhaps you are talking about AH's [I assume this is Tony Hoare -- BM]
> !! Turing address, which
> !! certainly did not "kill interest on Ada in the academic
> !! community" [...] [Tony Hoare] did
> !! also write a nice [foreword] for a book by Brian Wichman.

[Matthew Heaney:]
 
> I have to disagree with you, Robert.  It is my opinion that it was
> Hoare's Turing Award speech that single-handedly derailed the Ada
> language effort.  He essentially argued that by using Ada, "the fate of
> mankind" was at stake.
> [...]
> It's the kind of thing that probably prompted C.B. Jones to remark that:
> 
> "Subsequent to this publication, Hoare and Wirth consulted for SRI on
> their 'Yellow' language response to the 'Tinman' requirements.  Their
> consistent advice to simplify even this language was unheeded - but the
> final Ada language (the 'Green' proposal) was even more baroque."
> 
> (excerpted from Chap 13, "Hints on programming language design", in
> Essays in Computing Science, by Hoare and Jones).
> 
> In his speech, Hoare argued that "Ada was doomed to succeed."  [...]

What is not clear is that you are talking about two separate papers from
Hoare. The remark by C.B. Jones is in chapter 13 of his collection of Hoare
papers (Essays in Computing Science, edited by Hoare and Jones, Prentice Hall).
This is the paper entitled "Hints on Programming Language Design", dating back
to 1973 (although the version republished in the book is from 1974).

The Turing lecture ("The Emperor's Old Clothes", chapter 1 in the
Hoare-Jones collection), which contains the strongly critical comments
on Ada, including the "doomed to success" remark, is quite posterior: 1980.

I have no doubt Mr. Heaney understands this, but the above extract is unfortunate:
if you haven't read the book, then when you see Cliff Jones's comment cited above
("Subsequent to this publication, Hoare and Wirth consulted
for [the] Yellow language"), you will almost certainly think that
it implies the consulting was "subsequent to the Turing lecture of 1980",
whereas Jones of course meant "subsequent to the 1973 paper 'Hints on
Programming Language Design'".

So the chronology is:

	1973: Paper on "Hints on Programming Language Design" (revised 74).

	1975-1978 (approximate dates): Hoare consults on the "Yellow" language
	proposal.

	1978 (I think): DoD chooses "Green" and "Red" languages  as finalists.

	1978-1979 (or 1980): Hoare consults for the Green team (Jean Ichbiah).

	1980: DoD chooses Green as the winning language design for Ada.

	1980: Hoare's Turing lecture, "The Emperor's Old Clothes", includes
	strongly critical comments on Ada.

By the way, whatever you think of Ada and Hoare's 1980 view of it, which occupy
only a few paragraphs towards the end of the article, "The Emperor's
Old Clothes" should be required reading in any computing science curriculum.

	(When you write something like that someone is bound to ask:
	"Where do I find the full text on the Web?". So I ran a search but the
	only copy I found is on the home page of a graduate student and doesn't
	say whether the copy is authorized, so I am not publishing the URL here.
	Suffice it to say that I found it on Sunday morning PDT by running
	the query "Hoare emperor's old clothes Ada" at Highway61.

	In any case any university library will have Communications of the ACM,
	vol. 24, no. 2, February 1981, pp. 75-83, where the paper first appeared,
	and probably the Hoare-Jones volume as well.)
	
-- 
Bertrand Meyer, Interactive Software Engineering
ISE Building, 2nd Floor, 270 Storke Road Goleta, CA 93117 USA
805-685-1006, Fax 805-685-6869,
<Bertrand.Meyer@eiffel.com>, http://eiffel.com

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Rod Chapman]

Bertrand Meyer wrote:

>         1980: Hoare's Turing lecture, "The Emperor's Old Clothes", includes
>         strongly critical comments on Ada.
>
>

We should also bear in mind that Hoare's comments were on the 1980 incarnation ofthe
Green language, not on Ada83.  In particular, the 'Failure exception (a kind of
inter-task  remote exception) was not included in Ada83, and I have an impression
(although I cannot remember where it came from) that Hoare particularly objected
to that feature of Green.  (Oddly, "remote exceptions" briefly raised their
ugly head during the 9X mapping process, and were quickly squashed - we got
nested ATC instead :-) )
 - Rod Chapman
Praxis Critical Systems

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

Bertrand Meyer wrote in message <3620FA1A.AC761584@eiffel.com>...

<good points re: chronology>

>So the chronology is:
>
> 1973: Paper on "Hints on Programming Language Design" (revised
74).
>
> 1975-1978 (approximate dates): Hoare consults on the "Yellow"
language
> proposal.
>
> 1978 (I think): DoD chooses "Green" and "Red" languages  as
finalists.
>
> 1978-1979 (or 1980): Hoare consults for the Green team (Jean
Ichbiah).
>
> 1980: DoD chooses Green as the winning language design for Ada.
>
> 1980: Hoare's Turing lecture, "The Emperor's Old Clothes",
includes
> strongly critical comments on Ada.


<snipped comments>

1987: Hoare writes a very favorable foreword to an Ada
language-specific book:

"... the language incorporates many excellent structural features...
...one can now look forward to a rapid and widespread improvement in
programming practice, both from those who use the language and from
those who study its concepts and structures. ..."

Author: Watt, David; Wichmann, Brian; Findlay, William
Title: Ada Language and Methodology
Publisher: Prentice-Hall International, 1987
ISBN 0-13-004078-9


-- pat

Patrick Rogers
progers@acm.org

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Robert I. Eachus]

In article <3620FA1A.AC761584@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

  > I'd like to clear up the chronology and Hoare references.

  > So the chronology is:

  >  1973: Paper on "Hints on Programming Language Design" (revised 74).
  >  1975-1978 (approximate dates): Hoare consults on the "Yellow" language
  >  proposal.
  >  1978 (I think): DoD chooses "Green" and "Red" languages  as finalists.
  >  1978-1979 (or 1980): Hoare consults for the Green team (Jean Ichbiah).
     1979: (Date corrected) DoD chooses Green as the winning language
           design for Ada. 
     June  1979 Preliminary Ada Manual published (Ada 1979)
     early 1980 Ada Reference Manual Released.

  >  1980: Hoare's Turing lecture, "The Emperor's Old Clothes", includes
  >  strongly critical comments on Ada.

     Dec. 1980 Ada approved as DoD-1815 (Ada 80).  
     July 1982 Draft ANSI Ada Standard published (Ada 82).  Major
          revisions from Ada 80.
     Jan. 1983 ANSI/Mil Std 1815A published (Ada 83)

   I could go on, but the point I am trying to make is that, at best,
Hoare's Turing Award lecture referred to a non-final version of Ada
80.  There were lots of things wrong with even the final version of
Ada 80 that went away as people acutally tried to implement the
blasted thing.

   In fact, that is how I got involved in Ada language lawyering.  I
was working on the front end of an Ada compiler at Honeywell, and
Honeywell (and later Alsys) had the development contract for Ada.  So
I was often in a position to be the first implementor to scream that
something was unimplementable.  Robert Dewar was a Distinguished
Reviewer and also working on AdaEd at NYU, Gary Dismukes then at
Telesoft, Ron Brender at Digital, and Gerry Fisher were others who
strongly took the side of the compiler implementor during the
standardization process.  This doesn't mean that we were anti-user, in
fact the most vociferous complaint was often, "How can I explain that
in an error message?"

   In closing I would like to quote from the forward of the Ada 83 RM:
"Several persons had a constructive influence with their comments,
criticisms and suggestions.  They include P. Brinch Hansen, G. Goos,
C.A.R. Hoare, Mark Rain, W.A. Wulf, and also..."  Jean Ichbiah would
not have listed Tony Hoare in that group unless he had made a
substantial impact on the design of the language. 
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[bengt]

In article <3600E72E.24C93C94@cl.cam.ac.uk>, Markus Kuhn
<Markus.Kuhn@cl.cam.ac.uk> wrote:

>Rick Smith wrote:
>> Of the comments attributed to Dijkstra, I have never heard a comment
>> that was favorable toward any language! Is there a language that Dijkstra
>> liked?
>
>I thought that Dijkstra wrote years after his famous criticism on Ada,
>which basically killed interest on Ada in the academic community for
>many years, a quite nice foreword for an Ada 83 textbook by Jean Ichiba.
>I guess, his aversion against Ada were softened once he saw what
>monsters more recent languages such as C++ have become, compared
>to which Ada in Dijkstra's criteria should be a very nice language. I
>never understood his criticism that Ada is much too complex, and
>attribute it just to his inexperience with language specifications
>written down as ISO standards, because today even the C 9X standard
>is longer and much more difficult to read than the Ada standard. If

Perhaps he had had a look at the Scheme standard, and then thought that
anything more complex would also have to be more powerful to be
acceptable?
--

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Gautier.DeMontmollin]

> IMO Ada died because:
          ^^^^
You should have written IMHO - even IMVHO ...

>   -- A lot of programmers scoff at anything the miltary does and the
>      whole defense industry. In fact, defense workers are high tech lepers.
So you suppose that the military only are using Ada. Tsssss

>   -- Ada compilers were late, buggy, slow, too expensive, no libraries, ....
... and now some are fast, reliable, free, with full libraries & bindings,
    providing optimizations (cross-package inlining) that can only be
    simulated with macros in old-fashioned languages.

>   -- Ada was not C, thus perceived worthless for Unix and Windows.
You're right, in these language wars, it's rather perception than reflexion !

>   -- Mismanagement by the DOD.
You're maybe right; fortunately it's no more a military affair...

>   -- No hyped technology that it could be piggybacked on. (Like C, Java)
>   -- Winning cold war sucked most of the life out of the defense field.
Hurra: Ada users don't have to fear from mismanagement by the DOD anymore...

Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Van Snyder]

In article <3621BCD7.CDB33E8F@praxis-cs.co.uk>, Rod Chapman <rod@praxis-cs.co.uk> writes:
> Bertrand Meyer wrote:
> 
> >         1980: Hoare's Turing lecture, "The Emperor's Old Clothes", includes
> >         strongly critical comments on Ada.
> 
> We should also bear in mind that Hoare's comments were on the 1980 incarnation
> of the Green language, not on Ada83....

In a seminar at JPL in March of this year, Niklaus Wirth spoke of Oberon.
Somebody in the audience asked which language he'd use for a large mission
critical system.  Without hesitation, he answered "Ada."

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[biocyn]

Van Snyder wrote:

> In a seminar at JPL in March of this year, Niklaus Wirth spoke of Oberon.
> Somebody in the audience asked which language he'd use for a large mission
> critical system.  Without hesitation, he answered "Ada."

At the expense of getting fried by the community, I have been a disciple
of Wirth's work for a long time.  I have been working in C and its
derivatives longer than Pascal and its derivatives (Object Pascal, Ada,
Modula, Oberon, and Component Pascal), but I cannot help but believe
that strongly-typed, restrictive languages are superior to permissive
languages like C and C++ when it comes to developing good as opposed to
working software.  The beauty of these languages is that if the code
compiles, it usually runs without error.  With C and C++, you never know
what you are going to get because it takes only one undisciplined team
member to ruin everyone's day; thus, I have found that C and C++ require
much more in-depth code inspection than the Pascal derivatives.

Mark

-- 
--------------------------------------------------------------------
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, Sec. 227,
any and all nonsolicited commercial E-mail sent to this address is
subject to a download and archival fee in the amount of $500.00 US. 
E-mailing denotes acceptance of these terms.                        
--------------------------------------------------------------------

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ehud Lamm]

On Thu, 22 Oct 1998 biocyn@erols.com wrote:

> The beauty of these languages is that if the code
> compiles, it usually runs without error.  With C and C++, you never know
> what you are going to get because it takes only one undisciplined team
> member to ruin everyone's day; 

This is a very common view. However I find it a little too extreme. Buggy
code can be written in any language. Many errors result from not sticking
to what was designed, using flawed algrotihms etc. You can do this in any
language. 

I guess many people here teach ADA. We see buggy code that compiles each
day...

This is not to say I am against storng static type checking. I am all for
it.

Ehud Lamm     mslamm@mscc.huji.ac.il
http://www2.cybercities.com/e/ehud E-List & ADA & SE

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Tucker Taft]

Ehud Lamm (mslamm@mscc.huji.ac.il) wrote:

: On Thu, 22 Oct 1998 biocyn@erols.com wrote:

: > The beauty of these languages is that if the code
: > compiles, it usually runs without error.  With C and C++, you never know
: > what you are going to get because it takes only one undisciplined team
: > member to ruin everyone's day; 

: This is a very common view. However I find it a little too extreme. Buggy
: code can be written in any language. Many errors result from not sticking
: to what was designed, using flawed algrotihms etc. You can do this in any
: language. 

: I guess many people here teach ADA. We see buggy code that compiles each
: day...

I think the real point is that a good software engineer will find Ada more
productive, because the compiler and the run-time constraint checking
catch a larger percentage of the inevitable minor mistakes we all make.
This means that if you make it through the "gauntlet" of the stringent
compile-time and run-time checks, your program is likely to have many
fewer lurking errors than with a language which has weaker compile-time
and run-time checking.

: This is not to say I am against storng static type checking. I am all for
: it.

But you make a good point, that a language can't make a good programmer
out of a bad one.  It can help make a good programmer more productive, in
my experience.

: Ehud Lamm     mslamm@mscc.huji.ac.il
: http://www2.cybercities.com/e/ehud E-List & ADA & SE

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dennison]

In article <F1Fz6p.Lx2.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Ehud Lamm (mslamm@mscc.huji.ac.il) wrote:
>
> : On Thu, 22 Oct 1998 biocyn@erols.com wrote:
>
> : This is a very common view. However I find it a little too extreme. Buggy
> : code can be written in any language. Many errors result from not sticking
> : to what was designed, using flawed algrotihms etc. You can do this in any
> : language.
>
> I think the real point is that a good software engineer will find Ada more
> productive, because the compiler and the run-time constraint checking
> catch a larger percentage of the inevitable minor mistakes we all make.
> This means that if you make it through the "gauntlet" of the stringent
> compile-time and run-time checks, your program is likely to have many
> fewer lurking errors than with a language which has weaker compile-time
> and run-time checking.

The part that I find tres' cool is that the run-time checks tend to make a
buggy program bomb very close to the true source of the problem. Without it,
bugs surface randomly. On a large networked system It can take weeks just to
find the source of such a "random" bug.

I've seen one instance where a C array bounds indexing bug caused garbage to
get passed through 2 intermediate machines, processed, and sent to a third
which blew up trying to dereference the pointer it got by using the resultant
garbage as another array index into an array of poiners. Two engineers were
flown into the customer site and put up in hotels for 2 weeks while they
tried to figure out what was going on. Of course if it were written in Ada, a
range check would have caused the program to bomb at the line where the
invalid index was first used. A decent compiler will then print a stack dump
with the error, routine, and line number. We could probably have fixed it
over the phone in less than a day. It only takes one bug like that to
completely erase any cost savings you thought you were getting by using that
cheap C compiler.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ehud Lamm]

On Mon, 26 Oct 1998 dennison@telepath.com wrote:

> In article <F1Fz6p.Lx2.0.-s@inmet.camb.inmet.com>,
> I've seen one instance where a C array bounds indexing bug caused garbage to
> get passed through 2 intermediate machines, processed, and sent to a third
> which blew up trying to dereference the pointer it got by using the resultant
> garbage as another array index into an array of poiners. Two engineers were
> flown into the customer site and put up in hotels for 2 weeks while they
> tried to figure out what was going on. Of course if it were written in Ada, a
> range check would have caused the program to bomb at the line where the
> invalid index was first used. A decent compiler will then print a stack dump
> with the error, routine, and line number. We could probably have fixed it
> over the phone in less than a day. It only takes one bug like that to
> completely erase any cost savings you thought you were getting by usingthat
> cheap C compiler.

Run time checking is extremely important. The ususal reason not to do it
is that it has a performence impact. My experience is that in most cases
this cost is negligable, and worth it.

One thing lacked by ADA is a real DBC mechanism like Eiffel. This makes
run time checks even more powerful.

Still - Remember you can achieve all the run time checking functionality
in any language. It is just that in some languages you have to code it
explicitly. But you want your code to be of quallity - you just have to do
it.

Ehud Lamm     mslamm@mscc.huji.ac.il
http://www2.cybercities.com/e/ehud 

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Pat Rogers]

Ehud Lamm wrote in message ...
>On Mon, 26 Oct 1998 dennison@telepath.com wrote:


<good points all>

>Still - Remember you can achieve all the run time checking
functionality
>in any language. It is just that in some languages you have to code
it
>explicitly. But you want your code to be of quallity - you just
have to do
>it.


Explicitly coded checks come at a price, though, that
language-defined checks may be able to avoid.  The array indexing
example (snipped) illustrates the issue: sure, we can write our C++
(for example) array class to throw an exception if the index bounds
test fails, but will the optimizer be able to remove the
explicitly-coded test for static index values (i.e. those that can
be checked at compile-time)? I don't see how.  In Ada, the fact that
the check is defined by the language means that we don't explicitly
write the it ourselves, and the optimizer then has freedom to help
us with performance.  Ironic, isn't it?


---
Pat Rogers                          Training & Development in:
http://www.classwide.com    Deadline Schedulability Analysis
progers@acm.org                 Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dennison]

In article
<Pine.A41.3.96-heb-2.07.981026223340.101470B-100000@pluto.mscc.huji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:

> Run time checking is extremely important. The ususal reason not to do it
> is that it has a performence impact. My experience is that in most cases
> this cost is negligable, and worth it.
>
> Still - Remember you can achieve all the run time checking functionality
> in any language. It is just that in some languages you have to code it
> explicitly. But you want your code to be of quallity - you just have to do
> it.

If it has to be done manually, then one could be overlooked or forgotten
about. If that is a possiblity, then I can't count on it. If I can't count on
it, then a lot of its advantage is lost.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Dave Wood]

dennison@telepath.com wrote:
> 
> The part that I find tres' cool is that the run-time checks tend to make a
> buggy program bomb very close to the true source of the problem. Without it,
> bugs surface randomly. On a large networked system It can take weeks just to
> find the source of such a "random" bug.

Wow, if this doesn't hit close to home!  I just spent
many agonizing days tracking down such a problem in a
voice mail system I developed in C.  Even using every
compiler check and a third-party bounds-checking tool
(Memcheck), I was still unable to detect the source
of the problem (although I did find another array
overrun problem that did not have an immediate 
negative effect - this particular problem would have
been found at compile time in Ada.)  The problem *only* 
manifested itself when the system was installed in the 
telco CO while it was processing 100,000+ calls a day,
and even then it happened at an unpredictable time
approximately once a day, causing a total system
crash.  Telephone companies aren't real happy with
an MTBF of 24 hours!  It's very hard to take the
system off-line or produce diagnostics without
making it unusable by the end-customers or making
it impossible to create the proper malfunction
conditions.  This is like the physics Uncertainty 
Principle: examining the problem changes the conditions 
sufficiently such that the problem can't be found!

In the end, we found the problem by sheer blind
luck - when an OS parameter was changed to 
accidentally low value, we noted that the same
kind of crash occurred at a higher frequency.
The smoking gun!

I grant you, with exceptionally good and clean 
engineering, this should not happen, even in C.
But the world is positively exploding with lousy
programmers (like me, although in this case the bug
was introduced by someone else, which no doubt made
it that much harder for me to find.)

Had a decent Ada development environment existed for 
the PC platform back when this project started (1989) 
I never would have used C in the first place.  On the
bright side, I guess you could say it gave me a
mission in life - to help bring such an environment
to market.

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[norm]

In article <3636952F.1FA6206B@cts.com>, Dave says...
>
 
>I grant you, with exceptionally good and clean 
>engineering, this should not happen, even in C.
>But the world is positively exploding with lousy
>programmers

SUre, there are bad programmers, but I say the blam all go on the
bad MANAGERS. Managers who are managing software projects and who have no
software engineering understanding. heck, you even have software managers
who never even programmed before in their life, and may be written 2 lines
of code.

I've been told by my managers a number of times not to spend too much 
time on analysis and design and to start coding. Managers who do 
not demand design documents and analysis and functional requirments 
from their programmers.  How many times have you see a manager tell 
a programmer to show them the design documents they have for the 
program the programmer is working on?

so, yes, the world is full of bad programmers, but it is more full of bad
managers. Many software projects will run better without such managers on it.

Norm.
 

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[bill]

In article <712i5t$9i$1@nnrp1.dejanews.com>, dennison@telepath.com says...
 
>
>The part that I find tres' cool is that the run-time checks tend to make a
>buggy program bomb very close to the true source of the problem. Without it,
>bugs surface randomly. On a large networked system It can take weeks just to
>find the source of such a "random" bug.
>

you can use asserts in C or C++ (or any langauge I suppose). 

when an assert fires, it can print a line number and nice message 
pointing exactly to the line when the bug was. an assert is
a human inserted run-time check. only difference is that Ada run-time checks
are like asserts that allready inserted for you without you having to
do it. Then can be great advantage, but the point is that one can use
asserts in C/C++ to achive something like what Ada run-time checks
does. 

Bill.
 

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[dewarr]

In article
<Pine.A41.3.96-heb-2.07.981026131810.53604A-100000@pluto.mscc.huji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> On Thu, 22 Oct 1998 biocyn@erols.com wrote:
>
> > The beauty of these languages is that if the code
> > compiles, it usually runs without error.  With C and C++, you never know
> > what you are going to get because it takes only one undisciplined team
> > member to ruin everyone's day;
>
> This is a very common view. However I find it a little too extreme. Buggy
> code can be written in any language. Many errors result from not sticking
> to what was designed, using flawed algrotihms etc. You can do this in any
> language.
>
> I guess many people here teach ADA. We see buggy code that compiles each
> day...
>
> This is not to say I am against storng static type checking. I am all for
> it.


Well obviously this is a matter of degree. It is certainly possible to design
a language in which it is impossible to write an incorrect program (e.g. the
programming systems derived from Martin Lof Logic systems), but the use of
such languages is to restrictive to be pragmatically useful (at least so far).

Otherwise it is a matter of degree. I first ran across the "well it's hard
to get it through the compiler but once you do, it has a good chance of
being right first time" in connection with Algol-68, and it simply reports
an empirical observation. I do indeed here people repeating this thought in
connection with Ada frequently -- I have never heard a C or C++ programmer
make a similar statement, although I am sure there must be exceptions out of
my earshot.

The point is that this is not some kind of absolute guarantee, of course it
is possible to write buggy programs in typical languages (Martin Lof Logic
systems do NOT lead to typical languages -- indeed these systems are
inpenetrable to most ordinary folk unless you have Dave Turner at hand to do
his truly brilliant tutorial :-)

The claim is different, it does not say always, just that people often have
the experience of struggling with the compiler, and then when they get out
all the compiler errors, things work first time. The other day I put in a
rather complex change to GNAT affecting many units (a change to optionally
allow debugging of the expanded -gnatdg source code). There were many compile
errors the first time around, but when all of them were fixed, this quite
tricky feature did indeed work first time -- very pleasing.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops))

[Ehud Lamm]

On Tue, 27 Oct 1998 dewarr@my-dejanews.com wrote:

> The claim is different, it does not say always, just that people often have
> the experience of struggling with the compiler, and then when they get out
> all the compiler errors, things work first time. The other day I put in a
> rather complex change to GNAT affecting many units (a change to optionally
> allow debugging of the expanded -gnatdg source code). There were many compile
> errors the first time around, but when all of them were fixed, this quite
> tricky feature did indeed work first time -- very pleasing.
> 

Mazel Tov. 

The point is, that getting this help for the language depends itself on
how well you understand the problem domain, and the language features. I
have some student with C background, that simply insist (though I told
them many times not to) on using Integer all over the place. Now when an
error occurs, which makes a variable which has to be a positive number
into a negative one - the error isn't caught and is propagated all over
the place. 

Since they still think in C, they think this is a problem with not using
enough input error checking etc. It is hard to make them grasp the fact
that it is a TYPE USAGE error. To make them see that using the right type
would have eliminated cases where their code produces bogus results.

This is to iterate my point, that it all boils down to whether the
programmer knows how to use the language and understands the problem he is
trying to solve.

Ehud Lamm     mslamm@mscc.huji.ac.il