Re: Any research putting c above ada?

Re: Any research putting c above ada?

[Jon S Anthony]

In article <Pine.SGI.3.95L.970514190923.17085C-100000@tower.york.ac.uk> T Wheeley <tw104@york.ac.uk> writes:

> On 2 May 1997, Jon S Anthony wrote:
> 
> > In article <3369FCAF.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:
> > 
> > > "We're teaching Computer Science here.  If you want engineering, go to
> > > an engineering school."  That's the prevailing attitude with many of the
> > > CompSci programs at small liberal arts colleges.  They teach the
> > > "science" of programming almost as a subfield of Mathematics.  The
> > 
> > This is actually very apropos to the problem.  Most of what passes as
> > so called "computer science" is just watered down mathematics -
> > discrete mathematics (asymptotic algorithm analysis is fundamentally
> > various techniques of counting, i.e., a bit of combinatorics) and some
> > bits of formal logics (which is where the oft mentioned "halting
> > problem" and such comes from.)  Take this away and you don't have much
> > left - unless you have the _application_ of that mathematics, i.e.,
> > software engineering.
> > 
> > Well, there is the AI camp, but there too, if you look at what much of
> > this is, it's being/been covered by philosophers and CogScis (and
> > often with rather more perspicacity).
> 
> Well then let's not bother teaching computer science at all!  Why not just

Sounds like a good idea to me.


> make people do Maths + Philosophy degrees.  Yes it's the same stuff, but
> don't Physics and Chemistry both cover atoms and electron shells?  Don't
> both Biology and Chemistry cover Biological Chemistry?

Incorrect analogies.  These are all sciences which have their own core
subject which is well delineated.  The fact that they borrow from
ideas in other related sciences is irrelevant.  The point is that CS
has no such core subject area - _all_ it has is borrowed and then
watered down from other disciplines.


> The fact is that a CS degree combines all these factors into a single
> degree related to the study of computers, and puts them in the correct
> context.

This would be the start of something that made sense if the core
subject was _engineering software artifacts_.


> Yes the idea of dominance in sequences is part of computer science,
> but they way I was taught it in maths is not particularly relvant to
> the complexity of algorithms.

This sounds irrelevant.  _Counting_ is the core of complexity analysis
and that is a part of Combinatorics.  _Applying_ the various relevant
results of Combinatorics to _engineering_ problems in software is
perfectly sensible.  Attempting to dream up new ways of counting or
more sophisticated ways, or ways that handle new situations or
whatever is Combinatorics - not CS.


> Unless you have a very good understanding of the principles behind
> the maths in a maths degree, it will take you a lot of experience to
> become a good programmer (e.g. Knuth)

I seriously doubt this (as it is written).  As an example, exactly how
does understanding the ideas behind the proof of Quadratic Reciprocity
help you in "programming"??  How does an understanding of the topology
of the linear continuum needed to understand a proof of the FTC help
you in "programming"?  As far as that goes, how does a understanding
of the notions underlying FTC help?  Schroder-Bernstein theorem?  No
other engineering discipline needs this sort of understanding.  Heck,
no other _science_ needs this level of understanding.

 
> Of course there is a strong element of theory in CS degrees -- they want
> to get good research students to boost the department's standing against
> other universities, but you would have to have a poor department or be a
> poor student if you didn't pick up some of the fundamentals of good
> software design.

I think you just crossed over into Jay Martin flamage land - prepare
to be blow torched! :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <JSA.97May14201336@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>> Well then let's not bother teaching computer science at all!  Why not just
>
>Sounds like a good idea to me.

Yeah, why don't we just burn those computer science texts, too!
We can start with that _Introduction to Algorithms_, by Cormen, Leiserson
and Rivest and thrown in some Knuth and Sedgewick for good measure.

>This would be the start of something that made sense if the core
>subject was _engineering software artifacts_.

This anti-intellectual claptrap romanticizing is getting rather tiresome.

Heck, I propose that we do away with learning all together. We should instead
hold retreats in the woods to get in touch with those engineers inside of us
that are just yearning to be set free!  Only then will we develop better
software, in the most natural way. 

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5le6vf$15p@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >> Well then let's not bother teaching computer science at all!  Why not just
> >
> >Sounds like a good idea to me.
> 
> Yeah, why don't we just burn those computer science texts, too!

OK, :-)


> >This would be the start of something that made sense if the core
> >subject was _engineering software artifacts_.
> 
> This anti-intellectual claptrap romanticizing is getting rather tiresome.

I'm unclear on why you think this is "anti-intellectual".  It's simply
getting your tasks better and more clearly organized.  So what if
there is no "science" per se' associated with computers?  Why should
this bother you?  Why is this a big issue?  And why is engineering
somehow "anti-intellectual"???  You think you can just go touchy-feely
when engineering an aircraft wing?  Or the combustion chamber head in
an ICE??  Or a throttlable rocket engine???? or ...  Come on - your
credibility just dropped to zero.


> Heck, I propose that we do away with learning all together. We

Well this is very odd.  I think it is pretty clear that I have a high
belief in the value of learning and apprpriate and highly rigorous and
formal disciplines.  For crying out loud - my formal background is in
theoretical mathematics.  I've merely pointed out that CS is largely
redundant (at best) with several other disciplines.


> should instead hold retreats in the woods to get in touch with those
> engineers inside of us that are just yearning to be set free!  Only
> then will we develop better software, in the most natural way.

Very interesting.  This really does seem to indicate that you don't
think engineering disciplines have any value.  That they are all just
a bunch of "new age" touchy feely rubbish.  And if CS became an
engineering discipline it would apparently become:

Anti-intellectual

A hodge-podge of simple minded, non-formal, non-rigorous rubbish

A place for artsy-fartsy types.


Wow.  Definitely odd...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <01bc6189$b074f500$LocalHost@xhv46.dial.pipex.com>,
Nick Roberts <Nick.Roberts@dial.pipex.com> wrote:
>
>
>Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
><5le6vf$15p@bcrkh13.bnr.ca>...
>[...]
>> Heck, I propose that we do away with learning all together. We should
>instead
>> hold retreats in the woods to get in touch with those engineers inside of
>us
>> that are just yearning to be set free!  Only then will we develop better
>> software, in the most natural way. 
>
>
>Kaz, this approach may well produce crap software, but it sounds like a lot
>of fun for the programmers :-)

I don't know what I was ranting about. It was sort of my sarcastic reaction to
all this ``computer science bad, experience good'' business. My point is that
in other engineering fields (if SW engineering can indeed be considered one) 
practitioners do not denigrate the theoretical underpinnings. Computer science
is a good thing, even if the pure theoretical foundations don't teach you
how to construct software.

I believe that CS programs should stand on their own.  A good CS education
offers things that are not quite covered in engineering or mathematics
programs, even though there are sometimes significant overlaps.

At my alma mater, there was an interesting situation: some of the upper
division computer science courses had precise electrical engineering
counterparts.  If a student somehow took both counterparts, credit would have
been awarded for just one, and either one counted as an equivalent prerequisite
to other courses or for graduation requirements. Among these courses were intro
to operating systems, computer graphics and computer architectures. The
consensus among the students was that the CS versions of these courses were far
more challenging and interesting, with better lecturers. As a result, we
had quite a few engineers in these classes.

A lot of CS subject matter just doesn't fit into engineering or mathematics,
though it could fit if the school of engineering had a specific deparment
for software engineering.

Should an engineering school teach compiler construction, distributed systems
or artificial intelligence courses? Should a mathematics department?

There are schools which have folded computer science and engineering
departments together, and it does seem to work.

>Then again, maybe Microsoft got there first?

:)
>Nick.
>

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5li53d$irf@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> I don't know what I was ranting about. It was sort of my sarcastic
> reaction to all this ``computer science bad, experience good''
> business. My point is that in other engineering fields (if SW
> engineering can indeed be considered one) practitioners do not
> denigrate the theoretical underpinnings.

I don't think anyone disagrees with this.  In fact, if anything, that
is sort of the point.  It is not at all about "theoretical stuff is
'bad'" (whatever that might mean), it's that the "theory" is CS is
basically redundant with other disciplines, but in large measure, CS
as a discipline stresses this theory.  So, CS - as currently
constituted - is largely irrelevant redundancy.  If it were
reorganized as focusing for the most part on the discipline of
engineering software artifacts (systems, components, whatever), then
basically noone would/could have much of anything negative to say in
this context.


> I believe that CS programs should stand on their own.  A good CS education
> offers things that are not quite covered in engineering or mathematics
> programs, even though there are sometimes significant overlaps.

Well, the point is, the parts that aren't in mathematics (or cogsci or
philosophy or...) are engineering aspects centered on a new _kind_ of
engineering.  So, just make the thing an engineering discipline and
let the theoretical stuff stay where it naturally belongs.  And just
_use_ the results.  If you are really interested in these aspects - go
be a mathematician, ...

> to other courses or for graduation requirements. Among these courses
> were intro to operating systems, computer graphics and computer
> architectures. The consensus among the students was that the CS
> versions of these courses were far more challenging and interesting,
> with better lecturers. As a result, we had quite a few engineers in
> these classes.

This all sounds like engineering to me.


> A lot of CS subject matter just doesn't fit into engineering or
> mathematics, though it could fit if the school of engineering had a
> specific deparment for software engineering.

OK - such as?


> Should an engineering school teach compiler construction,
> distributed systems

Well of course they should - when CS migrates to SE.  That's what this
stuff is.

> or artificial intelligence courses?

No - and neither should CS.  This is Neuro Science, CogSci and
Philosophy.  What makes you think CS has anything to offer here???

>Should a mathematics department?

Of course not.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Nick Roberts]

I note that this thread is in the C, C++, and Ada language newsgroups. I
think it's a very interesting discussion, and I'd like to make a
contribution, but is there another newsgroup more suitable? It's not really
a language topic.

Nick.

NOT about "c above ada"

[W. Wesley Groleau (Wes)]

Nick Roberts wrote:
> I note that this thread is in the C, C++, and Ada language newsgroups. I
> think it's a very interesting discussion, and I'd like to make a
> contribution, but is there another newsgroup more suitable? It's not really
> a language topic.

For that matter, several somebodies should have edited their subject
lines about a week ago...

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
----------------------------------------------------------------------

Re: Any research putting c above ada?

[Michael Norrish]

jsa@alexandria (Jon S Anthony) writes:

> It is not at all about "theoretical stuff is 'bad'" (whatever that
> might mean), it's that the "theory" is CS is basically redundant
> with other disciplines, but in large measure, CS as a discipline
> stresses this theory.  So, CS - as currently constituted - is
> largely irrelevant redundancy.

This is simply not true.  However one wants to value theoretical
computer science as to usefulness, there are parts of it that simply
do not get done elsewhere.  Who else except computer scientists care
about compiler construction and the attached theory of language
parsing?

Where else is the theory of communicating processes (things like CSP
and CCS by Hoare and Milner respectively) going to live except in
computer science?  There's plenty of theoretical work out there, that
is NOT just maths, or just engineering.   

My own work is theoretical (a formal model of C), and is not something
I could do anywhere except in a computer science setting.  

> Well, the point is, the parts that aren't in mathematics (or cogsci
> or philosophy or...) are engineering aspects centered on a new
> _kind_ of engineering.  So, just make the thing an engineering
> discipline and let the theoretical stuff stay where it naturally
> belongs.  And just _use_ the results.  If you are really interested
> in these aspects - go be a mathematician, ...
 
Maths departments tend not to be interested in semantics
(denotational, operational &c), in programming language design, the
theory of objects...

As a theoretical computer scientist, I am sure that there is no better
name for what my peers do.

Michael.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <yvsaflrrfka.fsf@albatross.cl.cam.ac.uk> Michael Norrish <mn200@cl.cam.ac.uk> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > It is not at all about "theoretical stuff is 'bad'" (whatever that
> > might mean), it's that the "theory" is CS is basically redundant
> > with other disciplines, but in large measure, CS as a discipline
> > stresses this theory.  So, CS - as currently constituted - is
> > largely irrelevant redundancy.
> 
> This is simply not true.  However one wants to value theoretical

Shrug - IMO, it is true.

> computer science as to usefulness, there are parts of it that simply
> do not get done elsewhere.  Who else except computer scientists care
> about compiler construction

That falls under engineering.

> and the attached theory of language
> parsing?

Linguists, mathematicians (formal languages), and philosophers.  Where
do you think this stuff came from?  The standard "language hierarchy"
used as the basis for recognizers is from Chomsky - a linguist, not a
CSer.


> Where else is the theory of communicating processes (things like CSP
> and CCS by Hoare and Milner respectively) going to live except in
> computer science?

Engineering again.  Other than how this works in actual software
systems, who cares?


> There's plenty of theoretical work out there, that
> is NOT just maths, or just engineering.   

Maybe - haven't seen it yet...


> My own work is theoretical (a formal model of C), and is not something
> I could do anywhere except in a computer science setting.  

Maybe, but I suppose that's because a formal model of C is completely
uninteresting outside the context of how it can/should/was intended
(or not) to be used to write programs.  But in reality, this sort of
thing is done by linguists (models of languages...)


> As a theoretical computer scientist, I am sure that there is no better
> name for what my peers do.

Somehow, this doesn't surprise me.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <JSA.97May19211413@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>> computer science as to usefulness, there are parts of it that simply
>> do not get done elsewhere.  Who else except computer scientists care
>> about compiler construction
>
>That falls under engineering.

In your opinion. There are schools that incorporate computer science
programs entirely into their engineering faculty. Others don't do this. But
compiler construction is still compiler construction.

I'd hate to see people have to enrol into engineering faculties if
they are really interested in computer science.

>> and the attached theory of language
>> parsing?
>
>Linguists, mathematicians (formal languages), and philosophers.  Where

In general, these people don't particularly care for constructing programming
language compilers, however.

>do you think this stuff came from?  The standard "language hierarchy"
>used as the basis for recognizers is from Chomsky - a linguist, not a
>CSer.

You could easily say that Chomsky has a good deal of a computer scientist
in him.

>> Where else is the theory of communicating processes (things like CSP
>> and CCS by Hoare and Milner respectively) going to live except in
>> computer science?
>
>Engineering again.  Other than how this works in actual software
>systems, who cares?

Most engineering professors (at least the types I have known) would butcher
and operating systems course. I went to a school where certain upper level
CS courses had precise counterparts in Engineering. The engineering
versions of these courses were so poor that smart engineering students 
signed up for the CS versions.

``other than how this works in actual systems'' --- typical engineering
attitude. To heck with abstraction, where is the iron?

>> My own work is theoretical (a formal model of C), and is not something
>> I could do anywhere except in a computer science setting.  
>
>Maybe, but I suppose that's because a formal model of C is completely
>uninteresting outside the context of how it can/should/was intended

A formal model of C might be of value to engineers who wish to more-less
formally verify the semantics (and hence the correctness) of programs written
in that language.

>(or not) to be used to write programs.  But in reality, this sort of
>thing is done by linguists (models of languages...)

Uh, yeah, whatever. I can just see some artsie linguist formalizing the
C language!  If there is such a linguist, I'd like to be introduced
to him or her.

To begin with, linguists tend to scoff at artificial languages of any sort.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5lrbnv$iaj@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >> computer science as to usefulness, there are parts of it that simply
> >> do not get done elsewhere.  Who else except computer scientists care
> >> about compiler construction
> >
> >That falls under engineering.
> 
> In your opinion. There are schools that incorporate computer science

Absolutely.  All of this is just "opinion".


> >Linguists, mathematicians (formal languages), and philosophers.  Where
> 
> In general, these people don't particularly care for constructing programming
> language compilers, however.

Absolutely.  That is where the _application_ of this stuff comes in,
i.e., software engineering dealing with computerized automated
recognition of formal languages.


> >do you think this stuff came from?  The standard "language hierarchy"
> >used as the basis for recognizers is from Chomsky - a linguist, not a
> >CSer.
> 
> You could easily say that Chomsky has a good deal of a computer scientist
> in him.

Well, you can always try to play Humpty Dumpty.  But, you have to
realize that it just confuses things.


> >> Where else is the theory of communicating processes (things like CSP
> >> and CCS by Hoare and Milner respectively) going to live except in
> >> computer science?
> >
> >Engineering again.  Other than how this works in actual software
> >systems, who cares?
> 
> Most engineering professors (at least the types I have known) would butcher
> and operating systems course. I went to a school where certain upper level

Not if they were _software_ engineering professors.  I am not saying
that you should have EE profs or something doing this.  I am
suggesting that there be a real (new) software engineering discipline
formed which would basically absorb what is now CS and ensure it has
the proper engineering bent that (IMO) it should have.


> ``other than how this works in actual systems'' --- typical engineering
> attitude. To heck with abstraction, where is the iron?

Well, sure - for EEs and CEs and such.  But that's not what I'm
talking about.

> Uh, yeah, whatever. I can just see some artsie linguist formalizing
> the C language!  If there is such a linguist, I'd like to be
> introduced to him or her.

Wow.  Have you ever looked into formal linguistics?


> To begin with, linguists tend to scoff at artificial languages of
> any sort.

Really?  Where'd you get this from?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Michael Norrish]

jsa@alexandria (Jon S Anthony) writes:

> > Where else is the theory of communicating processes (things like CSP
> > and CCS by Hoare and Milner respectively) going to live except in
> > computer science?
 
> Engineering again.  Other than how this works in actual software
> systems, who cares?

Theoretical computer scientists, that's who.  Show me an engineering
department that cares in the slightest about the pi calculus.  I, on
the other hand can show you an entire research group at the Computer
Lab here that does.

At a stretch you could call some of this stuff mathematics (it's
abstract in the way that much of maths is abstract), but when push
comes to shove, mathematicians don't do it; they're not interested.
Theoretical computer science is perhaps even a branch of mathematics,
but that doesn't mean maths departments do it.  

Michael.

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <yvsd8qm4isl.fsf@merganser.cl.cam.ac.uk>,
Michael Norrish  <mn200@cl.cam.ac.uk> wrote:
>jsa@alexandria (Jon S Anthony) writes:
>
>> > Where else is the theory of communicating processes (things like CSP
>> > and CCS by Hoare and Milner respectively) going to live except in
>> > computer science?
> 
>> Engineering again.  Other than how this works in actual software
>> systems, who cares?
>
>Theoretical computer scientists, that's who.  Show me an engineering
>department that cares in the slightest about the pi calculus.  I, on
>the other hand can show you an entire research group at the Computer
>Lab here that does.
>
>At a stretch you could call some of this stuff mathematics (it's
>abstract in the way that much of maths is abstract), but when push
>comes to shove, mathematicians don't do it; they're not interested.
>Theoretical computer science is perhaps even a branch of mathematics,
>but that doesn't mean maths departments do it.  

I would go as far as saying that ``software engineering'' is a hoax.
Developing a correct program is much more akin to theorem proving than
engineering activity. There are enough superficial similarities to make the two
seem the same from a project management perspective. Both the ``software
engineer'' and the real engineer have to have some creativity, both have
requirements and deadlines, both work in teams, both assemble systems out of
more elementary components many of which are designed and built by others and
so forth.

Their fundamental activities are miles apart, however. Software engineering
merely means the application of the same levels of rigor to software design
that engineers apply to the design of electrical, mechanical or structural
systems, and the same standards of quality, accountability and so forth.

From this it does not follow that we should absorb computer science into
engineering. Phooey!

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> I would go as far as saying that ``software engineering'' is a hoax.

Right _now_ I'd say that SE is kind of a "hoax".  But that's because
no one's actually tried to define it in a rigorous way analogous to
the activity in other engieering disciplines.

> Developing a correct program is much more akin to theorem proving
> than engineering activity.

Well, here you are really climbing out on a (weak) limb.  The "micro
level" aspect of programming is somewhat related to theorem proving:
stuff like what Gries presents in _The Science of Programming_.  And
this is important stuff basic stuff.  Kind of like how an aeronautical
engineer needs to know about fluid dynamics and such.  Or how an EE
needs to know (at a kind of cookbook level) basic QM stuff.

But as everyone knows, this is just the starting point for any
_realization_ of such "micro level" pieces.  And it does not have much
to say about how these pieces can be fit together into a whole which
will function, perform and be useable at the proper levels in the real
world context they are to live in.


> There are enough superficial similarities to make the two seem the
> same from a project management perspective. Both the ``software
> engineer'' and the real engineer have to have some creativity, both
> have requirements and deadlines, both work in teams, both assemble
> systems out of more elementary components many of which are designed
> and built by others and so forth.

You missed the true heart of the stuff: real engineers use an
application of science and mathematics to derive first level _ideal_
approximations of the desired end result.  Then you have to face
reality, as it were, and then try to get a _real_ result which comes
in reasonably close to the ideal and which is actually _useable_ in
the desired context.  This is kind of like a sophisticated constraint
based reasoning and experimentation effort.

The point is: software artifacts (applications, components, whatever)
have to live in the real world just like hardware artifacts (engines,
wings, ICs, whatever).  And there is as much of difference in _kind_
between ideals in software construction as ideals in real engineering.
And this major fact is what seems to be lost on most software people.


> Their fundamental activities are miles apart, however. Software
> engineering merely means the application of the same levels of rigor
> to software design that engineers apply to the design of electrical,
> mechanical or structural systems, and the same standards of quality,
> accountability and so forth.

IMO, this is a) a very odd idea of what SE should be and b) one that
is probably shared by most software people.


> From this it does not follow that we should absorb computer science
> into engineering. Phooey!

This is rather telling.  Why is there such an emotional reaction to
this???

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <JSA.97May20172344@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:

>The point is: software artifacts (applications, components, whatever)
>have to live in the real world just like hardware artifacts (engines,
>wings, ICs, whatever).  And there is as much of difference in _kind_
>between ideals in software construction as ideals in real engineering.
>And this major fact is what seems to be lost on most software people.

What are the ideals in software construction? I don't see it.

I understand what an ideal fluid or gas may be, or what an idealized structural
member is like and so forth. What is the idealized stuff in software? Reams of
textbook pseudo-code? 

>> From this it does not follow that we should absorb computer science
>> into engineering. Phooey!
>
>This is rather telling.  Why is there such an emotional reaction to
>this???

Because in my personal experience, engineering courses were ``sleepers'' the
passage of which was based primarily on examsmanship whereas computer science
courses were mostly stimulating and exciting (okay, there were some sleepers
too, naturally; but even the sleepers had half decent assignments and
projects).

Which is no more or less valid than any other claims based on background
experience that I have seen in this thread.

We've seen, for instance, complaints from those who went after the prestige of
ivy league computer science for whatever reasons, and then realized that they
didn't learn software engineering. To that I say: what did you expect?
Vocational training at an institution for privileged children? Of what
practical use are software engineering skills to someone who can afford to go
these schools? I sure as heck couldn't have coughed up $25K+ per year to go to
school, I had to work to get by. When I graduated, I didn't go on a world tour;
I found a programming job within two or three weeks.

I'd like to say that _at the university where I completed my studies_, the
recommendations you are making would probably not be a good idea, even though
there is a great deal of synergy between engineering and CS, particularly EE.
Every school is unique. Some CS departments could use a swift kick in the
pants, others perhaps not.

Re: Any research putting c above ada?

[Craig Franck]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:

>I would go as far as saying that ``software engineering'' is a hoax.

Or as some would say "a myth and a scam". :-)

>Developing a correct program is much more akin to theorem proving than
>engineering activity. 

I don't agree at all. The metaphor I use for programming is construction.
You literally build a program. I am working on a simulation of a lottery
terminal that will have the same sort of interface (keyboard, screen 
layout) so you can learn to use the terminal with your PC. It will even 
have a mode where it can play customer and ask you for tickets. Anyway,
right now it doesn't do much. The keyboard is all layed out, but there is
only one game and a few reports implemented. When you hit a key that hasn't
been "wired up yet" it will say "Game not active" or "Report not available".

The goal is to have a compilable version at all times. You start with the
framework and add functionality as you go. It works from just about the 
start, and you flesh it out by adding new games and reports and other 
various whatnots to it.

To me, this seems like constructing the frame of a house and adding the 
interior as you go. Checking the program for correctness consists of
critically reading the code, stepping through it in the debugger, and, yes,
actually running it to see how badly it screws up. None of this seems like
theorem proving. I don't know how to prove that the program is correct 
other than reading the source very critically and testing the heck out
of it with various aids. When it performs correctly it is ready. "Getting
into states where it's behavour is undefined" (my favorite software 
euphemism) means there is work to be done. The correctness is demonstrated
by its behavour; there could *always* be a bug lurking. Sitting down and 
reading several thousand lines of code and then "proving" it is correct is 
quite a bit to do. Some things become so complex that the only way to test
them is to simulate them, which is another way of saying "build it and see
what it does".

>There are enough superficial similarities to make the two
>seem the same from a project management perspective. Both the ``software
>engineer'' and the real engineer have to have some creativity, both have
>requirements and deadlines, both work in teams, both assemble systems out of
>more elementary components many of which are designed and built by others and
>so forth.

I don't think that is superficial. At some fundamental level you are doing
the same thing.

>Their fundamental activities are miles apart, however. Software engineering
>merely means the application of the same levels of rigor to software design
>that engineers apply to the design of electrical, mechanical or structural
>systems, and the same standards of quality, accountability and so forth.

That is true, but even an incompetent programmer blundering his way
through the construction of a program is constructing something; how well
it is engineered is another question (I think this is your point).

>From this it does not follow that we should absorb computer science into
>engineering. Phooey!

Well, I don't think it belongs in the hard sciences either! I think if you
grasp how much software and hardware have to interact, there would be some 
justification for creating an interdisciplinary field.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Robert I. Eachus]

In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > I would go as far as saying that ``software engineering'' is a hoax.

    Huh?

  > Developing a correct program is much more akin to theorem proving than
  > engineering activity...

    Ah, programming is not software engineering.  Software engineering
is all that other stuff which successful projects do that results in
projects being successful.

    We had an interesting case a few weeks ago here.  A project
manager wanted to know if switching from X to Y at this point in the
project made sense.  (X and Y here are irrelevant to the discussion.)
He ended up talking to five people who really are software engineers.

    The first person gave him a lot of advice that basically amounted
to do NOTHING to change the specifications for build one, but start a
small scoping activity to make sure that all functions of the current
system are scheduled for build two, and anything else that can be
moved to build three, is.  Then once build two is complete come back
and discuss X vs. Y.

    The project manager thought that this was good advice, but didn't
really answer his X vs. Y question, so he called someone else.  Got
the same answer.  Tried a third person, got the same answer, called
me.  I went over to his office, looked at his schedule charts, and
gave the same answer.  At this point he was suspecting a conspiracy,
because the answers were almost identical and didn't address his
question.  I suggested a fifth person who had been in meetings all
morning, but was familar with the project.   The project manager used
his speaker phone and after asking a few questions got basically this
reply:

    "The thing you have to understand is that even asking the design
team to look at this at this point will cause at least a three month
slip, and you can't afford that, because you are tied to the (system
Z) deployment schedule.  In fact, it is not clear that build three
will be ready by then in any case, so you should make sure that any
functionality provided by the current system is provided in build two.
If it looks like build two will meet your current schedule, then you
can evaluate this question in that context."

    PM: "But is this BETTER in the long run?  That is what I want to
know."

    In chorus: "Trying to answer that now will kill the project."

    All of this had NOTHING to do with actual programming, but
everything to do with software engineering.  Software engineering is
all about knowing the difference between want and need, and keeping
the focus on meeting requirements, whether they relate to cost,
schedule, maintainability, or even to actual product functionality.
The usual stock in trade of the software engineer is managing
complexity, because we know that the project staff can only deal with
so much at a time, and any attempt to exceed that real world limit can
result in disaster.
--

					Robert I. Eachus

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

Re: Software Engineering and Dreamers

[Nick Roberts]

Robert I. Eachus <eachus@spectre.mitre.org> wrote in article
<EACHUS.97May22113850@spectre.mitre.org> an excellent example of the
necessity for realism in software engineering.

This sense of realism is excellent, and is frequently the one thing that
makes the difference between a project that succeeds, and one which fails.
And let's face it, the software industry has had its fair share of failed
projects, has it not?

However, I would argue that there is sometimes a flip side to this realism,
in the engineering sciences in general, and computer science in particular.
All (or almost all) the really great leaps forward in computer technology
have come not from great, expensive, laboratories, engaged in highly
directed (commercially orientated) research, but instead from a motley
collection of scatter-brained individuals who had _imagination_.

These 'dreamers' may never have been practical or realistic. But they
invented the science.

If someone says "what if...?", it is fine to say "nice idea, but not
today", but at the same we should not get into the habit of 'stepping on'
those who suggest ideas. I don't suppose Robert was trying to give this
impression at all, but I hope nobody wrongly gets this impression. We need
our dreamers.

Nick.
(PS: I get a bit poetic this time of night)

Re: Software Engineering and Dreamers

[Tom Moran]

> All (or almost all) the really great leaps forward in computer technology
> have come not from great, expensive, laboratories, engaged in highly
> directed (commercially orientated) research
  After thinking of Visicalc and Apple (which acually came after Wang,
Basic 4, et al), I start drawing blanks on who outisde a great expensive
lab developed great leaps forward.  Some examples, please?

Re: Software Engineering and Dreamers

[Robert Dewar]

Tom asks

<<  After thinking of Visicalc and Apple (which acually came after Wang,
Basic 4, et al), I start drawing blanks on who outisde a great expensive
lab developed great leaps forward.  Some examples, please?>>


Algol-60
B-trees
parallel computing (Illiac)
time sharing 
virtual memory (U Manchester)

That's just a few off the top of my head, there are undoubtedly lots more ...

Re: Software Engineering and Dreamers

[David Ray]

> 
> <<  After thinking of Visicalc and Apple (which acually came after Wang,
> Basic 4, et al), I start drawing blanks on who outisde a great expensive
> lab developed great leaps forward.  Some examples, please?>>
> 
> 

How about Donald Knuth?  You think maybe he made a little contribution?

Re: Software Engineering and Dreamers

[Robert I. Eachus]

In article <01bc66fa$ee7910e0$LocalHost@xhv46.dial.pipex.com> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

  > This sense of realism is excellent, and is frequently the one thing that
  > makes the difference between a project that succeeds, and one which fails.
  > And let's face it, the software industry has had its fair share of failed
  > projects, has it not?

  > However, I would argue that there is sometimes a flip side to this realism,
  > in the engineering sciences in general, and computer science in particular.
  > All (or almost all) the really great leaps forward in computer technology
  > have come not from great, expensive, laboratories, engaged in highly
  > directed (commercially orientated) research, but instead from a motley
  > collection of scatter-brained individuals who had _imagination_.

   Another facet of software engineering, and actually demonstrated in
the project above.  The synchronization problem is with a new system,
and build 2 needs to provide all the capabilities of the currently
fielded system AND integrate with the new system.  Enough complexity
that you don't want any more.  But build three has room for all the
customer wants, and new technology.

   So in this case the build one design has to support evolution,
build two is required to integrate with a system that does not yet
exist, and build three has room for all the bells and whistles that
the original design allows.  Quite a spectrum, and a need to keep
focused on today's goal.

  > These 'dreamers' may never have been practical or realistic. But they
  > invented the science.

   Noting wrong with dreaming, and in fact the project manager was
reacting to features/hooks in the design which are there to support
evolution.  Our job was to convince him that they were needed--but
were for use much later.
--

					Robert I. Eachus

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

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <EACHUS.97May23174831@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>   Another facet of software engineering, and actually demonstrated in
>the project above.  The synchronization problem is with a new system,
>and build 2 needs to provide all the capabilities of the currently
>fielded system AND integrate with the new system.  Enough complexity
>that you don't want any more.  But build three has room for all the
>customer wants, and new technology.

That's another pet peeve of mine: using ``technology'' with reference to
software. I've noticed that some hardware manfuacturers have been using the
term ``hardware technology'' in their marketing propaganda since it's no
longer understood what the word really means.

Software is not technology; the stuff that it runs on is technology.

Re: Software Engineering and Dreamers

[jason hummel]

Kaz Kylheku wrote:
> 
> That's another pet peeve of mine: using ``technology'' with reference to
> software. I've noticed that some hardware manfuacturers have been using the
> term ``hardware technology'' in their marketing propaganda since it's no
> longer understood what the word really means.
> 
> Software is not technology; the stuff that it runs on is technology.

i don't think so. take a look at COM and DCOM.
like that or not, it is a technology, a binary one at that.

jason hummel
-- 
/*----------------------------------------------------*/
 kill the ".++" in the reply to address.
/*----------------------------------------------------*/

Re: Software Engineering and Dreamers

[Robert Dewar]

Kaz said

<<That's another pet peeve of mine: using ``technology'' with reference to
software. I've noticed that some hardware manfuacturers have been using the
term ``hardware technology'' in their marketing propaganda since it's no
longer understood what the word really means.

Software is not technology; the stuff that it runs on is technology.>>

Well, like Humpty Dumpty in Alice in Wonderland, you can declare that
"words mean what I want them to mean" [not a literal quote :-)]
but in normal English usage, technology is a very broad word. For example,
the definitions in the OED are:

1. A discourse or treatise on an art or arts; the scientific study of the
practical or industrial arts.

2. The terminology of a particular art or subject; technical nomenclature.

So if in your lexicon it applies to hardware and not software, you are
using the word in a peculiar idiosyncratic way, which others will not
understand unless you warn them of this idiosyncrasy!

Certainly you cannot have a pet peeve that others do not share this
non-standard viewpoint!

Re: Software Engineering and Dreamers

[Craig Franck]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:
>In article <EACHUS.97May23174831@spectre.mitre.org>,
>Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>>   Another facet of software engineering, and actually demonstrated in
>>the project above.  The synchronization problem is with a new system,
>>and build 2 needs to provide all the capabilities of the currently
>>fielded system AND integrate with the new system.  Enough complexity
>>that you don't want any more.  But build three has room for all the
>>customer wants, and new technology.
>
>That's another pet peeve of mine: using ``technology'' with reference to
>software. I've noticed that some hardware manfuacturers have been using the
>term ``hardware technology'' in their marketing propaganda since it's no
>longer understood what the word really means.
>
>Software is not technology; the stuff that it runs on is technology.

I think you have a real bias against software; you could have just as
easily have said "software runs technology". There may be a symbiotic
relationship with software and hardware. Say you have a tic-tac-toe 
game. Now, they have hardware tic-tac-toe processors (one made out of
tinker toys is at The Computer Museum, in Boston). You can also use 
software to create on. If you did a sort Turing test with the two, you 
would not be able to tell the hardware one from the software one. You
can look at the software as sort of an abstraction of the hardware. 
Then, it would represent a technological break through (just as the 
stored program concept was). So, software as a whole *has* to be 
technological. 

In addition, every software program could be recomposed as hardware.
It would not be modifiable (I don't just mean firmware EPROMs, but 
that actual logic gates and analog systems could, in theory, replace 
any program) but you could have a hardware equivalent. In my mind, 
this makes the whole software/hardware distinction somewhat artificial.
Future generations may even start to view technology as being primarily 
*software* and basically "virtual" in nature.

You can define technology to mean just hardware, but software may just
be plastic hardware. A lot of network and data communications algorithms
and protocols get wired up as hardware for speed, in which case there is 
no software to discriminate against at the lower levels.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <5m859v$2qr@mtinsc04.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:

>I think you have a real bias against software; you could have just as
>easily have said "software runs technology". There may be a symbiotic

I don't think I have a bias against software! You might only perceive
that if you think that hardware is somehow superior, in that the job
of a hardware designer carries more prestige.

>You can define technology to mean just hardware, but software may just
>be plastic hardware. A lot of network and data communications algorithms
>and protocols get wired up as hardware for speed, in which case there is 
>no software to discriminate against at the lower levels.

Digital logic still isn't technology. It's really a form of software. You can
change the underlying technology without changing the logic, and obtain the
same behavior, modulo a difference in performance. A data register made of flip
flops or an address decoder made from combinational logic can be done up in
TTL, CMOS, ECL, vacuum tubes or using water pipes and valves.  The essential,
abstract behavior is totally separate from the implementation technology.

Unless you work in marketing, you wouldn't call an OR gate ``disjunctive
technology''. You see what I'm getting at? Sort of?  :)

Re: Software Engineering and Dreamers

[Robert Dewar]

Kaz says

<<Digital logic still isn't technology>>

Since you are using the word technology in such a bizarre and unsual way,
perhaps you could post your definition so we have some chance of understading
what you are talking about.

P.S. Please do NOT expect other people to use the word in the same way, go
to the dictionary to understand the way that everyone else uses the word!

Re: Software Engineering and Dreamers

[Jon S Anthony]

In article <dewar.864687070@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Kaz says
> 
> <<Digital logic still isn't technology>>
> 
> Since you are using the word technology in such a bizarre and unsual way,
> perhaps you could post your definition so we have some chance of understading
> what you are talking about.

I second this!  Kaz, just what in the world do you _mean_ by
"technology" anyway????


> P.S. Please do NOT expect other people to use the word in the same way, go
> to the dictionary to understand the way that everyone else uses the word!

Exactly...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering and Dreamers

[Dann Corbit]

[relevant discussion about technology snipped]
I agree with Kaz from one standpoint [in software engineering being
separate from other engineering disciplines].  In electrical engineering
(for instance) we have measured, known tolerances and capacities for the
devices we use.  Consider a resistor of 150 ohms with a 5% tolerance.  We
know how it behaves and what the accuracy is.  We also know what the
failure rate is for a given brand. We know how much power will definitely
cause it to fail.  When we build a circuit board from the design
specification we know how the circuit behaves and what its failure rate is,
for the entire board, for each component and for all acceptable inputs [we
also should know what those are].  In software engineering, we have not
progressed very far beyond the schematic.  We do not know how the circuit
performs for all possible inputs.  With complex IC's, we may not always
validate every input [as the Intel 80 bit float an the infamous divide bug
shows] but even in those cases testing is [or should be] done which
explains the inputs and outputs from a probability basis.

Consider some examples:
1.  Booch components (Ada)
2.  C Standard Library (C)
3.  STL (C++)

for an object in one of the above repositories, do we know how it will
behave for all inputs?  Do we know how it will behave, at least as far as a
probability basis?  If we should happen to know for some component, how is
this documented?  We can't pick up the spec sheet like we would for an IC
and see what the permissible voltages are and what the performance curve is
like and what probability of failure is.  When a component fails [e.g.
given an address outside of the user's allowed bounds] how does the
component behave?  Are failure modes uniform or even documented?

Tested components tend to be stamped "PASS/FAIL" and as new problems arise
are corrected.  This reactionary approach to software design can hardly be
termed 'engineering'.

I suggest that software could become an engineering discipline by formation
of a database of components, performance, accuracies and tolerances.  This
database would contain the component, the test driver, and definitions for
which environment it was tested under.  This database does not exist right
now.
-- 
Anonymous ftp sites for C-FAQ:
ftp://ftp.eskimo.com ftp://rtfm.mit.edu ftp://ftp.uu.net
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Looking for something?  Software?  Algorithms?  Publications?
http://www.altavista.digital.com or http://www.infoseek.com

Re: Software Engineering and Dreamers

[Craig Franck]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:
>In article <5m859v$2qr@mtinsc04.worldnet.att.net>,
>Craig Franck  <clfranck@worldnet.att.net> wrote:
>
>>I think you have a real bias against software; you could have just as
>>easily have said "software runs technology". There may be a symbiotic
>
>I don't think I have a bias against software! You might only perceive
>that if you think that hardware is somehow superior, in that the job
>of a hardware designer carries more prestige.

I think they are both equally important. I just thought of "real" 
technology as being more important (like "real" science as opposed
to say, political science or some branches of psychology that don't
get the same amount of respect.)

>>You can define technology to mean just hardware, but software may just
>>be plastic hardware. A lot of network and data communications algorithms
>>and protocols get wired up as hardware for speed, in which case there is 
>>no software to discriminate against at the lower levels.
>
>Digital logic still isn't technology. It's really a form of software. You can
>change the underlying technology without changing the logic, and obtain the
>same behavior, modulo a difference in performance. A data register made of flip
>flops or an address decoder made from combinational logic can be done up in
>TTL, CMOS, ECL, vacuum tubes or using water pipes and valves.  The essential,
>abstract behavior is totally separate from the implementation technology.
>
>Unless you work in marketing, you wouldn't call an OR gate ``disjunctive
>technology''. You see what I'm getting at? Sort of?  :)

That you do not feel digital logic is technology is telling. Perhaps it
is more a matter of technique or represents progress of some other sort.

(I don't think calculus is "technology" but represented an advancement of
mathematics when it was invented by Newton (or that Leibnitz fellow)). 

So, a NAND gate is not technology, but transistors and the ability to 
photograph millions of them on to something the size of your thumb is.
If that is what you mean, I think I can grasp the distinction. (We just
need to come up with some other word or catchy phrase for the ad people.)
:-)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <5md5q8$slo@mtinsc04.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:

>That you do not feel digital logic is technology is telling. Perhaps it
>is more a matter of technique or represents progress of some other sort.

Yes, it's telling. The underlying fabrication of the hardware is technology.
But the abstract functioning of the circuit is not.

Look, you don't even have to comprehend simple Ohm's law to design a logic
circuit to spec.

On the other hand, there is a fabrication technology in which such circuits
are implemented.

>(I don't think calculus is "technology" but represented an advancement of
>mathematics when it was invented by Newton (or that Leibnitz fellow)). 

That's true. And that's not to say that we are deriding calculus. Only
to a technocrat is it derisive to say that something is not technology.

>So, a NAND gate is not technology, but transistors and the ability to 
>photograph millions of them on to something the size of your thumb is.

Right! A nand gate is just an abstract box that performs the service of
computing not (X and Y). It can be implemented in a variety of technologies.
This is far less true of, say, a transistor, of which there are countless
varieties whose precise behavior depends on the underlying method of
fabrication and choice of materials.

>If that is what you mean, I think I can grasp the distinction. (We just
>need to come up with some other word or catchy phrase for the ad people.)

Nah, let them stick with technology.

Now let me return to debugging some pointer dereference technology. :))

Re: Software Engineering and Dreamers

[Fritz W Feuerbacher]

Craig Franck (clfranck@worldnet.att.net) wrote:

: (I don't think calculus is "technology" but represented an advancement of
: mathematics when it was invented by Newton (or that Leibnitz fellow)). 

: So, a NAND gate is not technology, but transistors and the ability to 

Isn't "technology" a relatively new word?

Re: Software Engineering and Dreamers

[Craig Franck]

fwf27775@pegasus.cc.ucf.edu (Fritz W Feuerbacher) wrote:
>Craig Franck (clfranck@worldnet.att.net) wrote:
>
>: (I don't think calculus is "technology" but represented an advancement of
>: mathematics when it was invented by Newton (or that Leibnitz fellow)). 
>
>: So, a NAND gate is not technology, but transistors and the ability to 
>
>Isn't "technology" a relatively new word?

I would imagine. The concept of technology and its diffusion through
society started in Europe in the 16th century. This is from "The 
Reenchantment of the World" by Morris Berman: "Technology was hardly
new in the sixteenth century, of course, but the level of its diffusion
and the insistence on its being a mode of cognition were novel, and
these events inevitably began to have an impact on scientists and 
thinkers. No longer restricted to such devices as catapults and water
mills, technology became an essential aspect of the mode of production,
and, as such, it began to play a corresponding role in human conscious-
ness. Once technology and the economy became linked in the human mind,
the mind started to think in mechanical terms, to see mechanism in 
nature. Thought processes themselves were becoming mechanico-mathematico-
experimental, that is to say, "scientific". The merger of scholar and 
craftsman, geometry and technology, was now occuring within the 
individual human mind."

[He is a very interesting author and is sort of a scientific philosoper.
He feels that people today are quite literally hypnotized into believing
a view of the world that is false, and cannot be maintained for more than
a few more hundred years before it is replaced with something else, or
we annihilate the planet and ourselves along with it. Basically, every-
thing was fine for about 50,000 years or so, and in the last 3,000 years
all hell has broken loose. Needless to say, his work is not for everybody.]
:-)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Software Engineering and Dreamers

[Robert Dewar]

i<<>Isn't "technology" a relatively new word?>>

relatively recent -- the first OED quote is 1614, and there are several
other 17th century and 18th centuray quotes. This in the scale of English
words probably qualifies as relatively new, but I have a feeling the author
of the above question might have a more recent timeframe in mind :-)

Re: Software Engineering and Dreamers

[Fritz W Feuerbacher]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:

: Software is not technology; the stuff that it runs on is technology.

So the concept of Software Engineering Technology is not a technology?  I
believe your wrong.

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <5mcp5o$ei7$3@news.cc.ucf.edu>,
Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
>Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
>
>: Software is not technology; the stuff that it runs on is technology.
>
>So the concept of Software Engineering Technology is not a technology?  I

The concept of software engineering is flawed to begin with. Engineering is
the application of physics to produce technology. 

If physics is not involved, you aren't producing technology, nor are you
doing engineering.

Examples: writing software is not engineering, and the result is not
technology, because principles of physics are not required to understand the
internal semantics of software systems. Designing a pure logic circuit isn't
engineering either, except when you have to solve implementation problems
related to heat dissipation, capacitive or inductive coupling and other
artifacts related to the _technology_.

Re: Software Engineering and Dreamers

[tstcroix]

> 
> Examples: writing software is not engineering, and the result is not
> technology, because principles of physics are not required to understand the
> internal semantics of software systems. Designing a pure logic circuit isn't
> engineering either, except when you have to solve implementation problems
> related to heat dissipation, capacitive or inductive coupling and other
> artifacts related to the _technology_.

It may not be semantically correct to refer to 'software engineering
technology'
but the programming metaphor forces the issue...

tim

Re: Software Engineering and Dreamers

[Robert Dewar]

tim says

<<It may not be semantically correct to refer to 'software engineering
technology'
but the programming metaphor forces the issue...>>


Of course it is semantically correct. You can refer to the technology
of graphology, or the technology of basket weaving, or anything else.
Technology is a *very* general word in normal English usage. Kaz is
pushing his own remade lexicon, but do not get confused by it. The trouble
with this kind of discussion of the meaning of words is that a lot of
readers of CLA are not native English speakers. It is not helpful to anyone,
but especially not helpful to that group, to use English words in a 
non-standard manner!

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <dewar.864731403@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>tim says
>
><<It may not be semantically correct to refer to 'software engineering
>technology'
>but the programming metaphor forces the issue...>>
>
>
>Of course it is semantically correct. You can refer to the technology
>of graphology, or the technology of basket weaving, or anything else.

Yes, you can. But by stretching the words too thinly, so to speak, they
lose their ability to discern.

>Technology is a *very* general word in normal English usage. Kaz is
>pushing his own remade lexicon, but do not get confused by it. The trouble

I don't think that the lexicon is remade. And in any case, I'm not going to
resort to the lowly tactic of changing the definitions on the fly.

>with this kind of discussion of the meaning of words is that a lot of
>readers of CLA are not native English speakers. It is not helpful to anyone,
>but especially not helpful to that group, to use English words in a 
>non-standard manner!

Such as using technology or engineering to refer to software.

Engineering is the application of *physics* (and derivative hard sciences close
to physics) to create technology. This is seems to be perfectly clear to
everyone except a minority of computer weenies who suffer from engineer envy. I
know real engineers who _laugh_ at the term software engineering.

This definition steps on some people's toes, because they can no longer fancy
themselves to be engineers. The problem is with their complex, not with my
lexicon. 

Perhaps their father wanted them to become an engineer and they have
disappointed him by becoming ``mere'' computer programmers. I have known such
cases.

Re: Software Engineering and Dreamers

[Robert Dewar]

Kaz says

<<Such as using technology or engineering to refer to software>>

Rubbish! Kaz, you really should read a dictionary. I don't know if you are
a native speaker of English or not. I certainly do not know where you got
your extremely odd ideas about the meaning of the word technology. Both
from its classical roots, and from the definition in any dictionary,
technology is a VERY general word that can be applied to virtually any
systematic set of knowledge or terminology about a specific field.

Somehow, you have picked up a very bizarre view of what this word means.
Please look in the dictionary to figure out how the world uses this
word. You might particularly study the historical references in OED II.

I think you will make your arguments much more clear if you try to say
what you mean directly, rather than complaining about other people's
use of terminology.

The issue is not whether "software technology" is an OK term, that is
just an argument about words. Presumably you are trying to say
"software is different from hardware in a fudnamental way, ....
and this is significant because ....."

By concentrating on the .... you will make your point clearer.

Re: Software Engineering and Dreamers

[Nick Roberts]

Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
<5meuvm$hpf@bcrkh13.bnr.ca>...
[...]
> Engineering is the application of *physics* (and derivative hard sciences
close
> to physics) to create technology. This is seems to be perfectly clear to
> everyone except a minority of computer weenies who suffer from engineer
envy. I
> know real engineers who _laugh_ at the term software engineering.
> 
> This definition steps on some people's toes, because they can no longer
fancy
> themselves to be engineers. The problem is with their complex, not with
my
> lexicon. 
> 
> Perhaps their father wanted them to become an engineer and they have
> disappointed him by becoming ``mere'' computer programmers. I have known
such
> cases.


With respect, Kaz, you couldn't be more wrong if you were to say the moon
were made of cheese.

Would you say that a modern motor car represented a feat of engineering? I
think most people would. There are a great many problems of physics and
chemistry to overcome, as well as problems of human physiology, human
psychology, and all manner of 'hard' sciences.

And yet, a typical piece of software has _thousands of times_ as many
working parts as any car (since every single instruction in a piece of
software is a working part (yes it really is)). In fact, cars nowadays have
a considerable amount of software in them, to run the engines, the air
conditioning, the ABS braking (as well as the navigation system, the
telephone, the radio/CD player, etc, etc, etc). Does a computer inside a
car engine not count as engineering? What do you think the engine's design
engineers (that is their official job title) would say?

The design and construction of software is as much an engineering task as
building a bridge, or an office block, or a motor car. It involves the
understanding and negotiation of the laws of nature (in the form of logic
and mathematics) as much as building physical things requires similar
skills with regard to the physical laws of nature. It involves exactly the
same processes of specification, design, refinement, and testing. It
usually involves much of the same knowledge of human characteristics
(mostly psychological) as most physical engineering does.

In short, the skills of software engineering are remarkably similar to
those of other branches of engineering. These professions have come from
differing traditions (some much older than others), but thoughtful people
are realising these days that building software is really almost the same
business as building anything else. The only difference is that the
software inhabits a non-physical nether-world, and tends to be vastly more
complex; there are precious few other real differences.

Nick.

Re: Software Engineering and Dreamers

[Jon S Anthony]

In article <01bc6d40$96100ca0$LocalHost@xhv46.dial.pipex.com> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> And yet, a typical piece of software has _thousands of times_ as many
> working parts as any car (since every single instruction in a piece of
> software is a working part (yes it really is)). In fact, cars nowadays have

I've always been surprised when people make this utterly bogus
argument.  If you are going to include "all the instructions or all
the statements, or whatnot", then in any reasonable comparison you
need to include all the _molecules_ of the car.  Of which there are,
ahem, quite a few more than all the software "instructions" ever
written (and probably ever likely to be written in total).  This seems
completely reasonable: all the materials engineering and chemistry is
an effort to get the actual physical stuff to work/behave/function as
required.


> In short, the skills of software engineering are remarkably similar to
> those of other branches of engineering. These professions have come from

Agreed.  But, unfortunately, there has been no exploration of the
analog of such engineering for software artifacts.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering and Dreamers

[Ralph Silverman]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: In article <dewar.864731403@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: >tim says
: >
: ><<It may not be semantically correct to refer to 'software engineering
: >technology'
: >but the programming metaphor forces the issue...>>
: >
: >
: >Of course it is semantically correct. You can refer to the technology
: >of graphology, or the technology of basket weaving, or anything else.

: Yes, you can. But by stretching the words too thinly, so to speak, they
: lose their ability to discern.

: >Technology is a *very* general word in normal English usage. Kaz is
: >pushing his own remade lexicon, but do not get confused by it. The trouble

: I don't think that the lexicon is remade. And in any case, I'm not going to
: resort to the lowly tactic of changing the definitions on the fly.

: >with this kind of discussion of the meaning of words is that a lot of
: >readers of CLA are not native English speakers. It is not helpful to anyone,
: >but especially not helpful to that group, to use English words in a 
: >non-standard manner!

: Such as using technology or engineering to refer to software.

: Engineering is the application of *physics* (and derivative hard sciences close
: to physics) to create technology. This is seems to be perfectly clear to
: everyone except a minority of computer weenies who suffer from engineer envy. I
: know real engineers who _laugh_ at the term software engineering.

: This definition steps on some people's toes, because they can no longer fancy
: themselves to be engineers. The problem is with their complex, not with my
: lexicon. 

: Perhaps their father wanted them to become an engineer and they have
: disappointed him by becoming ``mere'' computer programmers. I have known such
: cases.


	the problem of making
		an automaton
	which can defeat
		a ( human )
		 world chess champion
	at chess
	would seem to be 
	an engineering problem ...
	if achievable  !
	( re.  recent 'deep blue' events ... )

	moreover ...
	much of 'hard science' and 'engineering'
	is now a kind of branch of
	computer science ...
	due to prevalence of
		computer aided design
	and
		simulation
	...

	moreover ...
	regarding vehicles ...
	such as
		automotive
	and
		aviation
	...
	fundamental operability
	now frequently depends on
		programming ...

	certainly at least some programming
	may,  with reason,  be viewed as
		engineering
	!

--

Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Software Engineering and Dreamers

[Jon S Anthony]

In article <5md1fl$9f4@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> The concept of software engineering is flawed to begin
> with. Engineering is the application of physics to produce
> technology.  If physics is not involved, you aren't producing
> technology, nor are you doing engineering.

Well, that's a mighty odd constraint of the term.  What about chemical
engineering?  Or genetic engineering?  These strke me as eminently
appropriate examples of real engineering.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering and Dreamers

[Robert I. Eachus]

In article <JSA.97May27162012@alexandria> jsa@alexandria (Jon S Anthony) writes:

  > Well, that's a mighty odd constraint of the term.  What about chemical
  > engineering?  Or genetic engineering?  These strke me as eminently
  > appropriate examples of real engineering.

  Give it a break guys!  (Most of) you are correct that technology can
be applied to computer hardware, computer software, or even
phrenology.  In my original use, if you care, I was thinking of new
database technology, in particular OODBMSs.

  But I think it is time to put this topic to bed, or to move it to
some other newsgroup.


--

					Robert I. Eachus

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

Re: Software Engineering and Dreamers

[system]

kaz@vision.crest.nt.com (Kaz Kylheku) writes:
>Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
>>Kaz Kylheku (kaz@vision.crest.nt.com) wrote:

>>: Software is not technology; the stuff that it runs on is technology.

>>So the concept of Software Engineering Technology is not a technology?  I

>The concept of software engineering is flawed to begin with. Engineering is
>the application of physics to produce technology. 

>If physics is not involved, you aren't producing technology, nor are you
>doing engineering.

Never heard Chemical Engineering, eh?

From The American Heritage Dictionary of the English Language:
(somebody care to dig out the OED?)

Technology: 
1. The application of science, esp. in industry or commerce.
2. The methods and materials thus used.

Engineering: 
1. The application of scientific principles to practical ends at
	the design, construction and operation of efficient and
	economical structures, equipment, and systems.

Science:
1. [snip] investigation and theoretical explanation of natural
	phenomena
4. Knowledge, esp. knowledge gained through experience.

Is Computer Science a science?  Well, in the purest sense I suppose CS
is more akin to mathematics than Science (TM).  OTOH is anyone here
willing to cross a large bridge designed by somebody who doesn't
have a good grasp of trig.?

I am sure there are plenty of computer programmers who are closer to
bricklayers than to engineers, but there are plenty of bio grads who 
are glorified bottle washers too. (for a while anyways)

Face it Kaz, you misstepped.

Robert
specify the e-mail address below, my reply-to: has anti-spam added to it
Morphis@physics.niu.edu
Real Men change diapers

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <5mfcg8$n1o@corn.cso.niu.edu>,
 <system at physics.niu.edu.nospam> wrote:
>kaz@vision.crest.nt.com (Kaz Kylheku) writes:
>>Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
>>>Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
>
>>>: Software is not technology; the stuff that it runs on is technology.
>
>>>So the concept of Software Engineering Technology is not a technology?  I
>
>>The concept of software engineering is flawed to begin with. Engineering is
>>the application of physics to produce technology. 
>
>>If physics is not involved, you aren't producing technology, nor are you
>>doing engineering.
>
>Never heard Chemical Engineering, eh?

In fact I have known chemical engineers.  Chemistry is a hard natural science,
subordinated to physics. You might go as far as saying that it's a branch of
physics in some way. In a refinement of the definition, I have already included
physics as well as hard sciences related to it.

>From The American Heritage Dictionary of the English Language:
>(somebody care to dig out the OED?)
>
>Technology: 
>1. The application of science, esp. in industry or commerce.
>2. The methods and materials thus used.

Software is not the result of application of science, hence it's not
technology, according to point 1. In any case, software isn't mentioned
anywhere in the definitions, so we can only guess at the writer's
intent to include it.

>Engineering: 
>1. The application of scientific principles to practical ends at
>	the design, construction and operation of efficient and
>	economical structures, equipment, and systems.

Software is not the application of scientific principles, but mathematical
and logical principles at best. Anyway, primitive dictionary definitions are
insufficient for an erudite debate. What on earth are scientific principles? It
sounds like some dictionary authors just pulled out informed-sounding jargon
out of their hats.

The scientific method involves the formation of hyptheses that are verified
with experiment. In this sense, the current state of software development is,
ironically, somewhat scientific (picture the end user as a laboratory ``guinea
pig'', or the prototyping of software as an experiment. No engineer would build
a skyscraper as an experiment to see whether it would stand up, and hope to
debug it later).

>Science:
>1. [snip] investigation and theoretical explanation of natural
>	phenomena

We have no investigation of natural phenomena in computer science. Even
this primitive dictionary recognizes that CS is a misnomer.

>4. Knowledge, esp. knowledge gained through experience.

This is vague. There is all kinds of experienced knowledge that isn't related
to science. I won't even bother to cite examples. This definition 
is too porous to retain liquid.

>Is Computer Science a science?  Well, in the purest sense I suppose CS
>is more akin to mathematics than Science (TM).  OTOH is anyone here

According to the definitions you have just posted, CS is certainly not a
science.

>willing to cross a large bridge designed by somebody who doesn't
>have a good grasp of trig.?

I certainly wouldn't cross a bridge designed by someone who didn't have a good
grasp of trig, unless the design was independently verified to be sound and
I badly needed to get across.

Verification of software is also possible, of course, but it isn't based
on physical laws.

Re: Software Engineering and Dreamers

[Rich Miller]

In article <5mfjd9$1q9@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>
> Software is not the application of scientific principles, but mathematical
> and logical principles at best....  We have no investigation of natural
> phenomena in computer science.

You have chosen a narrow view of software, which feels like it comes
out of the 1950's and 1960's -- a time when smart people honestly
believed that mathematics and logic were the essence of computer
science. But these paradigms are of limited help with some interesting,
larger problems, e.g. omnifont, self-training optical character
recognition systems coupled with full English speech synthesis --
especially when graceful degradation in the presence of errors (so as
to let the human listener's brain help correct any errors) is required.

> No engineer would build a skyscraper as an experiment to see whether
> it would stand up, and hope to debug it later....

Designing buildings and bridges is much more of an art than you
seem to realize.  Engineering failures are closely examined by
engineers so as to improve their designs; but the accumulated
knowledge of design, plus powerful analytic tools, didn't prevent
such mis-designs as the Tacoma Narrows bridge ("Galloping Gerty")
and Boston's John Hancock Building ("The Plywood Palace" -- a
skyscraper named for the plywood sheets used to temporarily replace
popped-out windows).  You might read Levi and Salvadori's engineering
book, "Why Buildings Fall Down".

> I certainly wouldn't cross a bridge designed by someone who didn't
> have a good grasp of trig, unless the design was independently
> verified to be sound and I badly needed to get across.

Not to beat a dead horse -- but you might reflect on the grace and
endurance of Europe's numerous, many-centuries-old cathedrals.

-- Rich Miller

Re: Software Engineering and Dreamers

[Bryce Bardin]

Rich Miller wrote:

> Not to beat a dead horse -- but you might reflect on the grace and
> endurance of Europe's numerous, many-centuries-old cathedrals.
> 

However, you might also take note that those graceful flying buttresses
were invented to cure the problem of wind loading causing the high thin
walls of the first cathedral designs to fall down.

Bryce Bardin

Re: Software Engineering and Dreamers

[Lawrence Kirby]

In article <338C5770.4E1E@westdat.com> BBardin@westdat.com "Bryce Bardin" writes:

>Rich Miller wrote:
>
>> Not to beat a dead horse -- but you might reflect on the grace and
>> endurance of Europe's numerous, many-centuries-old cathedrals.
>> 
>
>However, you might also take note that those graceful flying buttresses
>were invented to cure the problem of wind loading causing the high thin
>walls of the first cathedral designs to fall down.

Wind isn't the real problem, the forces in an arch cause the uprights to
buckle outwards. Tall thin arches need the buttress to counteract this
and for general stability.

What the software engineering equivalent is I'm not quite sure! :-)

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Software Engineering and Dreamers

[Nick Leaton]

Lawrence Kirby wrote:

> >However, you might also take note that those graceful flying buttresses
> >were invented to cure the problem of wind loading causing the high thin
> >walls of the first cathedral designs to fall down.
> 
> Wind isn't the real problem, the forces in an arch cause the uprights to
> buckle outwards. Tall thin arches need the buttress to counteract this
> and for general stability.

Wind is a major force on gothic catherals. You are right too about
the buckling.

-- 

Nick

Re: Software Engineering and Dreamers

[Matthew S. Whiting]

Lawrence Kirby wrote:
> 
> In article <338C5770.4E1E@westdat.com> BBardin@westdat.com "Bryce Bardin" writes:
> 
> >Rich Miller wrote:
> >
> >> Not to beat a dead horse -- but you might reflect on the grace and
> >> endurance of Europe's numerous, many-centuries-old cathedrals.
> >>
> >
> >However, you might also take note that those graceful flying buttresses
> >were invented to cure the problem of wind loading causing the high thin
> >walls of the first cathedral designs to fall down.
> 
> Wind isn't the real problem, the forces in an arch cause the uprights to
> buckle outwards. Tall thin arches need the buttress to counteract this
> and for general stability.
> 
> What the software engineering equivalent is I'm not quite sure! :-)

How about C++ "tools" such as Bounds Checker... :-)

-- 
Remove question marks (spam repellent) from address to reply.

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <338C5770.4E1E@westdat.com>,
Bryce Bardin  <BBardin@westdat.com> wrote:
>Rich Miller wrote:
>
>> Not to beat a dead horse -- but you might reflect on the grace and
>> endurance of Europe's numerous, many-centuries-old cathedrals.
>> 
>
>However, you might also take note that those graceful flying buttresses
>were invented to cure the problem of wind loading causing the high thin
>walls of the first cathedral designs to fall down.

Yes, those graceful and enduring cathedrals are here because of a sort of
darwinian survival of the fittest. Some ad hoc designs turned out OK, the bad
ones collapsed. That's kind of how a lot of software gets developed.

Re: Software Engineering and Dreamers

[Fritz W Feuerbacher]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: In article <5mcp5o$ei7$3@news.cc.ucf.edu>,
: Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
: >Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: >
: >: Software is not technology; the stuff that it runs on is technology.
: >
: >So the concept of Software Engineering Technology is not a technology?  I

: The concept of software engineering is flawed to begin with. Engineering is
: the application of physics to produce technology. 

So I guess driving a train is not 'engineering' either?  I think your hung
up on semantics.

Re: Software Engineering and Dreamers

[Robert Dewar]

Kaz says

<<The concept of software engineering is flawed to begin with. Engineering is
the application of physics to produce technology.>>

OK, so finally we have the most peculiar Kaz definitions of these two words.
They bear of course absolutely no relationship with the normal English
meaning of these words that you will find in a dictionary.

For example, in OED2, we have

Engineering. The work done by, or the profession of, an engineer.
Engineer. One who contrives, designs, or invents, an author, designer.
Technology. A discourse or treatise on an art or arts; the scientific
study of the practical or industrial arts.

Now you are perfectly free to use your own peculiar definitions -- you
might want to write them in some special way, perhaps <<engineering>>

to remind us all not to read them in the usual sense. But you are NOT
free to complain about other people failing to use the words in your
peculiar way!

Re: Software Engineering and Dreamers

[Kaz Kylheku]

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

>For example, in OED2, we have
>
>Engineering. The work done by, or the profession of, an engineer.
>Engineer. One who contrives, designs, or invents, an author, designer.

This is vague. I invented a new recipe for making pancakes this morning,
hence I'm an engineer.

>Technology. A discourse or treatise on an art or arts; the scientific
>study of the practical or industrial arts.

Thus, since software is neither a treatise, discourse nor a study, it's not
technology.

I'm certain that this definition is what every english speaker naturally
associates with the word technology. For example, the NT operating system from
Microsoft is a ``new treatise or discourse on an art'', hence ``new
technology''.

Re: Software Engineering and Dreamers

[Vibrating Bum-Faced Goats]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: In article <5mcp5o$ei7$3@news.cc.ucf.edu>,
: Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
: >Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: >
: >: Software is not technology; the stuff that it runs on is technology.
: >
: >So the concept of Software Engineering Technology is not a technology?  I

: The concept of software engineering is flawed to begin with. Engineering is
: the application of physics to produce technology. 

: If physics is not involved, you aren't producing technology, nor are you
: doing engineering.

: Examples: writing software is not engineering, and the result is not
: technology, because principles of physics are not required to understand the
: internal semantics of software systems. Designing a pure logic circuit isn't
: engineering either, except when you have to solve implementation problems
: related to heat dissipation, capacitive or inductive coupling and other
: artifacts related to the _technology_.

My take is this:

Science, be it physics, chemistry, biology or whatever, is an attempt to 
discover the laws and principles which govern the existence of "things". 
"Things" can be natural phenomena or a phenomenon exhibiting certain  
behaviour which is defineable at whatever level. It's basically an 
attempt to explain the way things, any things, work. 

Engineering is the design and manufacture of "things" to suit a 
pre-defined need. "Things" can be physical objects designed to harness 
natural phenomena or they can be software operating in a man made 
environment such as a computer. If the evolution of a "thing" coming into 
existence involved a specification, a design process and an 
implementation then by my definition one could say it has been 
'engineered'. 

Mathematics exists in the mind alone. It is the process of discovering 
and describing precisely by symbolic means various kinds of facts and 
relationships. It is the process of implementing a rich "language" which 
enables scientists to express their ideas and engineers to model the 
behviour of their phenomena-harnessing implementations of those ideas.

In short:

The mathematician builds the hammer, the scientist writes the instruction 
manual and the engineer just likes to sit there maniacally hitting things 
with it. :^)

I would say, however, a computer scientist / engineer doesn't fit quite so 
easily into any of the above pidgeon holes. Civil engineers, electrical / 
electronic engineers, etc all have to work with the physical environment 
as it exists. A guy who builds a bridge cannot decide that he wants 
gravity to work sideways and save money on those nuts for the horizontal 
bolts. If a computer scientist / engineer decides that, to suit his or 
her specification best, a different architecture or operating system 
philosophy is required then that option is always open. 

I've forgotten who I'm agreeing with now. :^)

--
Chris Russell           | Bradford Bulls - Wembley 1997
Electronic Imaging Unit | 
University of Bradford  | Tough on St.Helens
TEL: +44 1274 385463    | Tough on the causes of St.Helens.

Re: Software Engineering and Dreamers

[Robert Dewar]

<<Science, be it physics, chemistry, biology or whatever, is an attempt to
discover the laws and principles which govern the existence of "things".
"Things" can be natural phenomena or a phenomenon exhibiting certain
behaviour which is defineable at whatever level. It's basically an
attempt to explain the way things, any things, work.
>>

I object to this solution. It smacks of searching for Truth with a 
capital T. Science is about constructing theories that are consistent
with observations, and which have the capability of predicting the
outcome of observations not yet made. 

"*the* way things work"

no

you are looking for *a* theory, not *the* theory!

Re: Software Engineering and Dreamers

[Jon S Anthony]

In article <dewar.865041126@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> <<Science, be it physics, chemistry, biology or whatever, is an attempt to
> discover the laws and principles which govern the existence of "things".
> "Things" can be natural phenomena or a phenomenon exhibiting certain
> behaviour which is defineable at whatever level. It's basically an
> attempt to explain the way things, any things, work.
> >>
> 
> I object to this solution. It smacks of searching for Truth with a 
> capital T. Science is about constructing theories that are consistent
> with observations, and which have the capability of predicting the
> outcome of observations not yet made. 

It is worth pointing out though, that this sort of view _only_ came
about around 60-70 years ago and can be pinned squarely on the back of
Bohr.  The notion of "complimentarity" was the birth of this sort of
view in physics (and it seems to have "infected" other branches as
time went along) in an attempt to _somehow_ come to grips with the
epistemological problems of the "quantum fix".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering and Dreamers

[Mathew Hendry]

In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

: <<Science, be it physics, chemistry, biology or whatever, is an attempt to
: discover the laws and principles which govern the existence of "things".
: "Things" can be natural phenomena or a phenomenon exhibiting certain
: behaviour which is defineable at whatever level. It's basically an
: attempt to explain the way things, any things, work.
: >>
: 
: I object to this solution. It smacks of searching for Truth with a 
: capital T. Science is about constructing theories that are consistent
: with observations, and which have the capability of predicting the
: outcome of observations not yet made. 

Imagine that you have produced a theory about the movements of the planets,
basing it upon Newtonian dynamics. I provide a competing theory, based upon
the exploits of invisible crocodiles.

The two theories give exactly the same predictions.

Given your claim that theories are judged only on their consistency with
observations, how do you choose between these two theories?

-- Mat.

Re: Software Engineering and Dreamers

[Craig Franck]

scampi@dial.pipex.com (Mathew Hendry) wrote:
>In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
>: <<Science, be it physics, chemistry, biology or whatever, is an attempt to
>: discover the laws and principles which govern the existence of "things".
>: "Things" can be natural phenomena or a phenomenon exhibiting certain
>: behaviour which is defineable at whatever level. It's basically an
>: attempt to explain the way things, any things, work.
>: >>
>: 
>: I object to this solution. It smacks of searching for Truth with a 
>: capital T. Science is about constructing theories that are consistent
>: with observations, and which have the capability of predicting the
>: outcome of observations not yet made. 
>
>Imagine that you have produced a theory about the movements of the planets,
>basing it upon Newtonian dynamics. I provide a competing theory, based upon
>the exploits of invisible crocodiles.
>
>The two theories give exactly the same predictions.
>
>Given your claim that theories are judged only on their consistency with
>observations, how do you choose between these two theories?

Look to your weltanschauung and let it guide you.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I don't pretend to understand the universe, it is
a great deal bigger than I am. -- Thomas Carlyle

Re: Software Engineering and Dreamers

[Matthew S. Whiting]

Mathew Hendry wrote:
> 
> In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
> : <<Science, be it physics, chemistry, biology or whatever, is an attempt to
> : discover the laws and principles which govern the existence of "things".
> : "Things" can be natural phenomena or a phenomenon exhibiting certain
> : behaviour which is defineable at whatever level. It's basically an
> : attempt to explain the way things, any things, work.
> : >>
> :
> : I object to this solution. It smacks of searching for Truth with a
> : capital T. Science is about constructing theories that are consistent
> : with observations, and which have the capability of predicting the
> : outcome of observations not yet made.
> 
> Imagine that you have produced a theory about the movements of the planets,
> basing it upon Newtonian dynamics. I provide a competing theory, based upon
> the exploits of invisible crocodiles.
> 
> The two theories give exactly the same predictions.
> 
> Given your claim that theories are judged only on their consistency with
> observations, how do you choose between these two theories?
> 
> -- Mat.

Coin toss?  ;-}

-- 
Remove question marks (spam repellent) from address to reply.

Re: Software Engineering and Dreamers

[Spaceman Spiff]

> Mathew Hendry wrote:
> > Imagine that you have produced a theory about the movements of the planets,
> > basing it upon Newtonian dynamics. I provide a competing theory, based upon
> > the exploits of invisible crocodiles.
> >
> > The two theories give exactly the same predictions.
> >
> > Given your claim that theories are judged only on their consistency with
> > observations, how do you choose between these two theories?

You missed this one by a mile (kilometer).
The competition between Relativity and quantum physics, suffered from 
those same arguments.
You choose by the one that fits observation, can predict formerly
unknown
behavior, and has the least assumptions (things that are accepted,
unproven,
like invisible crocks and magnetic fields).

Anyone with a slight background in science should know that.

-Scotty

Re: Software Engineering and Dreamers

[John Winters]

In article <19970602.562B58.2B32@ai110.du.pipex.com>,
Mathew Hendry <scampi@dial.pipex.com> wrote:
>In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
>: <<Science, be it physics, chemistry, biology or whatever, is an attempt to
>: discover the laws and principles which govern the existence of "things".
>: "Things" can be natural phenomena or a phenomenon exhibiting certain
>: behaviour which is defineable at whatever level. It's basically an
>: attempt to explain the way things, any things, work.
>: >>
>: 
>: I object to this solution. It smacks of searching for Truth with a 
>: capital T. Science is about constructing theories that are consistent
>: with observations, and which have the capability of predicting the
>: outcome of observations not yet made. 
>
>Imagine that you have produced a theory about the movements of the planets,
>basing it upon Newtonian dynamics. I provide a competing theory, based upon
>the exploits of invisible crocodiles.
>
>The two theories give exactly the same predictions.
>
>Given your claim that theories are judged only on their consistency with
>observations,

Errr, what else do you imagine they could be judged on?

>how do you choose between these two theories?

You devise tests which should produce different results depending on
which of the two theories is true.  Then you apply the tests, observe
the results and discard whichever theories are disproven.

There really is *no* other way you can do it.  This is the whole
essence of scientific enquiry.

John
-- 
John Winters.  Wallingford, Oxon, England.

Re: Software Engineering and Dreamers

[Mathew Hendry]

In comp.lang.c++ John Winters <john@polo.demon.co.uk> wrote:
: In article <19970602.562B58.2B32@ai110.du.pipex.com>,
: Mathew Hendry <scampi@dial.pipex.com> wrote:
: >In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
: >
: >: capital T. Science is about constructing theories that are consistent
: >: with observations, and which have the capability of predicting the
: >: outcome of observations not yet made. 
: >
: >Imagine that you have produced a theory about the movements of the planets,
: >basing it upon Newtonian dynamics. I provide a competing theory, based upon
: >the exploits of invisible crocodiles.
: >
: >The two theories give exactly the same predictions.
: >
: >Given your claim that theories are judged only on their consistency with
: >observations,

: Errr, what else do you imagine they could be judged on?

On their explanatory power.

: >how do you choose between these two theories?

: You devise tests which should produce different results depending on
: which of the two theories is true.  Then you apply the tests, observe
: the results and discard whichever theories are disproven.

Since the above theories make the same predictions, no experimental test can
distinguish between them. And yet no right-minded scientist would believe my
crocodile theory. Why not?

-- Mat.

Re: Software Engineering and Dreamers

[Martin C. Carlisle]

In article <19970602.433020.144E5@ai078.du.pipex.com>,
Mathew Hendry <scampi@dial.pipex.com> wrote:
>In comp.lang.c++ John Winters <john@polo.demon.co.uk> wrote:
>: >: capital T. Science is about constructing theories that are consistent
>: >: with observations, and which have the capability of predicting the
>: >: outcome of observations not yet made. 
>: >
>: >Imagine that you have produced a theory about the movements of the planets,
>: >basing it upon Newtonian dynamics. I provide a competing theory, based upon
>: >the exploits of invisible crocodiles.
>: >The two theories give exactly the same predictions.
>: >
>
>Since the above theories make the same predictions, no experimental test can
>distinguish between them. And yet no right-minded scientist would believe my
>crocodile theory. Why not?

Well, the reason is called Occam's razor.  Simply stated, given two 
theories that make the same predictions, favor the simpler.  Unfortunately
deciding which is simpler is based on personal bias.  So, although you
might think invisible crocodiles aren't much of a leap of faith =), most
others probably disagree.

--Martin

-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.

Re: Software Engineering and Dreamers

[Joe Charlier]

What does it matter which one I choose.  They both give me the correct
answer, so who cares.

-- 
	Joe Charlier
	=======================
	Aepryus Software
	http://www.Aepryus.com/

Re: Software Engineering and Dreamers

[Robert Dewar]

Martin said

<<Well, the reason is called Occam's razor.  Simply stated, given two 
theories that make the same predictions, favor the simpler.  Unfortunately
deciding which is simpler is based on personal bias.  So, although you
might think invisible crocodiles aren't much of a leap of faith =), most
others probably disagree.
 
--Martin
 >>


Actually I don't think there is any issue of personal bias here. The two
theories, as I noted before are

Newton
newton + crocodiles

It is objectively clear in this case which of these two is simpler. A similar
situation arises if you consider the contrast between theories based on:

1) standard "laws" of physics
2) standard "laws" of physics presided over by a God who is free to change them

These have similar predictive powers, but on a purely scientific basis, it
does not increase the predictive powers to choose 2, and it adds complexity,
so we don't generally explicitly choose 2 when we select a theory.

Nevertheless, many scientists do in fact select 2 for their own personal
belief systems, and that does not particularly affect what they do, but
this is in the realm of faith, not science.

As far as I can tell, the crocodiles are playing *exactly* the role that
God plays in a more conventional discussion. In other words, the bottom
line on the crocodiles is that you are free to believe in them if you want,
but it is irrelevant from a scientific point of view to explicitly include
the presence of crocodiles in the theory.

Re: Software Engineering and Dreamers

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.865870047@merv>...
> Actually I don't think there is any issue of personal bias here. The two
> theories, as I noted before are
> 
> Newton
> newton + crocodiles
> 
> It is objectively clear in this case which of these two is simpler. A
similar
> situation arises if you consider the contrast between theories based on:
> 
> 1) standard "laws" of physics
> 2) standard "laws" of physics presided over by a God who is free to
change them
> 
> These have similar predictive powers, but on a purely scientific basis,
it
> does not increase the predictive powers to choose 2, and it adds
complexity,
> so we don't generally explicitly choose 2 when we select a theory.
> 
> Nevertheless, many scientists do in fact select 2 for their own personal
> belief systems, and that does not particularly affect what they do, but
> this is in the realm of faith, not science.
> 
> As far as I can tell, the crocodiles are playing *exactly* the role that
> God plays in a more conventional discussion. In other words, the bottom
> line on the crocodiles is that you are free to believe in them if you
want,
> but it is irrelevant from a scientific point of view to explicitly
include
> the presence of crocodiles in the theory.


At this juncture I feel I must relate the story handed down to me from
University, about a famous mathematician - names are omitted to protect the
innocent - who was lecturing there at the time. After giving an annual open
lecture about the cosmos etc, an old lady came up to him, and said "You
know, what you said about the Earth being round is all wrong." Startled, he
asked "Really, madam, in what way?"
"Well, you see," she replied, "really the Earth is flat, and spins on the
back of a giant tortoise."
Thinking he could outwit this one, he swiftly replied "Ah, but then what
does the _tortoise_ stand on?"
"Very clever, young man," came the reply, "but it's tortoises all the way
down!" Game, set, and match.

Nick :-)

Re: Software Engineering and Dreamers

[John Winters]

In article <19970602.433020.144E5@ai078.du.pipex.com>,
Mathew Hendry <scampi@dial.pipex.com> wrote:
>In comp.lang.c++ John Winters <john@polo.demon.co.uk> wrote:
>: In article <19970602.562B58.2B32@ai110.du.pipex.com>,
>: Mathew Hendry <scampi@dial.pipex.com> wrote:
>: >In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>: >
>: >: capital T. Science is about constructing theories that are consistent
>: >: with observations, and which have the capability of predicting the
>: >: outcome of observations not yet made. 
>: >
>: >Imagine that you have produced a theory about the movements of the planets,
>: >basing it upon Newtonian dynamics. I provide a competing theory, based upon
>: >the exploits of invisible crocodiles.
>: >
>: >The two theories give exactly the same predictions.
>: >
>: >Given your claim that theories are judged only on their consistency with
>: >observations,
>
>: Errr, what else do you imagine they could be judged on?
>
>On their explanatory power.

Define.

>: >how do you choose between these two theories?
>
>: You devise tests which should produce different results depending on
>: which of the two theories is true.  Then you apply the tests, observe
>: the results and discard whichever theories are disproven.
>
>Since the above theories make the same predictions, no experimental test can
>distinguish between them. And yet no right-minded scientist would believe my
>crocodile theory. Why not?

Given the facts exactly as you describe them, no right-minded scientist
would have any excuse for preferring one theory over the other.  Show
me a scientist who - if there genuinely is *no* observable reason
for rejecting a theory - nonetheless rejects it, and I'll show you
an incompetent scientist.  However the facts never are quite as you
describe them.  What makes an outlandish theory outlandish is that it
doesn't fit the observable facts.  The skill of the scientist is in
devising tests which allow them to separate the good theories from the
bad ones.

John

-- 
John Winters.  Wallingford, Oxon, England.

Re: Software Engineering and Dreamers

[Volker Hetzer]

Mathew Hendry wrote:
> 
> In comp.lang.c++ John Winters <john@polo.demon.co.uk> wrote:
> : In article <19970602.562B58.2B32@ai110.du.pipex.com>,
> : Mathew Hendry <scampi@dial.pipex.com> wrote:
> : >Imagine that you have produced a theory about the movements of the planets,
> : >basing it upon Newtonian dynamics. I provide a competing theory, based upon
> : >the exploits of invisible crocodiles.
> : >
> : >The two theories give exactly the same predictions.
> : >
> : >Given your claim that theories are judged only on their consistency with
> : >observations,
> : Errr, what else do you imagine they could be judged on?
> On their explanatory power.
My understanding of "explanatory power" is how much things
get explained how simple. This basically boils down to what he said plus
occams razor.

> 
> : >how do you choose between these two theories?
> 
> : You devise tests which should produce different results depending on
> : which of the two theories is true.  Then you apply the tests, observe
> : the results and discard whichever theories are disproven.
> 
> Since the above theories make the same predictions, no experimental test can
> distinguish between them. And yet no right-minded scientist would believe my
> crocodile theory. Why not?

Actually, you haven't made any predictions. You only stated that your
theory
WOULD make the same predictions. And it's not enough to make
predictions,   
you also have to explain why, according to your theory, the prediction
should be
true.                                                             
So, just think about some crocodilic reasons for orbits, about
what         
keeps your crocodiles behind the planets (gravity/centrifugal forces
are    
conventional theory), what they feed on, how they push the planets
while    
feeding,...                                                                  
And then we will try to devise tests of your theory. Or check it against
more fundamental theories.

Volker

Re: Software Engineering and Dreamers

[Mathew Hendry]

In comp.lang.c Volker Hetzer <hetzer.abg@sni.de> wrote:
: Mathew Hendry wrote:
: > In comp.lang.c++ John Winters <john@polo.demon.co.uk> wrote:
: > : In article <19970602.562B58.2B32@ai110.du.pipex.com>,
: > : Mathew Hendry <scampi@dial.pipex.com> wrote:
: > : >how do you choose between these two theories?
: > 
: > : You devise tests which should produce different results depending on
: > : which of the two theories is true.  Then you apply the tests, observe
: > : the results and discard whichever theories are disproven.
: > 
: > Since the above theories make the same predictions, no experimental test can
: > distinguish between them. And yet no right-minded scientist would believe my
: > crocodile theory. Why not?

: Actually, you haven't made any predictions. You only stated that your
: theory
: WOULD make the same predictions.

It does make predictions, namely that the observable phenomenon behaves in
exactly the same way as that predicted by the Newtonian theory. The crocodiles
know that theory, and behave accordingly.

If science were only about prediction (as has been claimed in this thread and
numerous times elsewhere), the crocodile theory would be as valid as the
Newtonian one.

But science is not, so the crocodile theory is not.

: And it's not enough to make
: predictions,   
: you also have to explain why, according to your theory, the prediction
: should be
: true.                                                             

Exactly.

-- Mat.

Re: Software Engineering and Dreamers

[Robert Dewar]

Mat said

<< 
If science were only about prediction (as has been claimed in this thread and
numerous times elsewhere), the crocodile theory would be as valid as the
Newtonian one.
 
But science is not, so the crocodile theory is not.
 >>


Science is only about formulating theories and making predictions (at least
that is the late 20th century post-Heisenberg viewpoint).

But let's look at the two theories here

Newtonian explanation

Crocodiles using the Newtonian theory pushing things around (as best I
understand the MH alternative theory).

Occam's Razor clearly selects the simpler form sans crocodiles, so your
theory, while not predictively inferior, gets rejected solely on this
basis (and on no other!)

Re: Software Engineering and Dreamers

[Craig Franck]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>Mat said
>
><< 
>If science were only about prediction (as has been claimed in this thread and
>numerous times elsewhere), the crocodile theory would be as valid as the
>Newtonian one.
> 
>But science is not, so the crocodile theory is not.
> >>
>
>
>Science is only about formulating theories and making predictions (at least
>that is the late 20th century post-Heisenberg viewpoint).
>
>But let's look at the two theories here
>
>Newtonian explanation

He can predict, but he has no *explanation*. The whole thing reeks of
some sort of cabalistic mumbo jumbo. (The last passage of his I read
had him sort of "divining the mind of God through mathematics", blah,
blah, blah...

>Crocodiles using the Newtonian theory pushing things around (as best I
>understand the MH alternative theory).

Nope. All matter interacts by exchanging virtual crocodiles. When a
crocodile "hops" from one particle to the next, they can be said to
be interacting. (An alternative theory has them pushing things around
with their snouts: the math comes out the same either way.)

>Occam's Razor clearly selects the simpler form sans crocodiles, so your
>theory, while not predictively inferior, gets rejected solely on this
>basis (and on no other!)

But, the crocodile theory explains more because it has a method of 
interaction; the Newtonian theory *never* explaines *why* gravity
works. Gravity works by exchanging virual crocodiles. (You can also
think of it in terms of snout waves as well. In fact, we are all
immersed in a sea of snout-waves.)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I don't pretend to understand the universe, it is
a great deal bigger than I am. -- Thomas Carlyle

Re: Software Engineering and Dreamers

[Jason Shankel]

Craig Franck wrote:
> But, the crocodile theory explains more because it has a method of
> interaction; the Newtonian theory *never* explaines *why* gravity
> works. 

That's why it's weak as a scientific theory.  Superstring theory has
this same problem.  Yes, it explains much.  Yes, it seems to work.  But
it requires a 10 dimensional universe with 7 of those dimensions wrapped
too tightly to be perceived.

The crocidile theory stipulates the existence of crocodiles.  If these
crocodiles cannot be detected by any means and simpler explanations for
alleged crocodile activity cannot be disproven, then the theory isn't
very useful.

For "crocodile" read "string".

Jason Shankel

Re: Software Engineering and Dreamers

[Robert Dewar]

Jason said

<<The crocidile theory stipulates the existence of crocodiles.  If these
crocodiles cannot be detected by any means and simpler explanations for
alleged crocodile activity cannot be disproven, then the theory isn't
very useful.>>

No, it's stronger than that, if something cannot be detected by any means,
then from a scientific point of view, it simply cannot be part of any theory.

Re: Software Engineering and Dreamers

[John G. Volan]

I can't believe you folks are still beating this ... "subject" ... to
death. It's quite embarrassing.

You know, you can get help for this. There's a 12-step group for people
who just can't drop a thread. It's called On-and-On-and-On Anon.

:-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Software Engineering and Dreamers

[Robert Dewar]

John Volan says

<<I can't believe you folks are still beating this ... "subject" ... to
death. It's quite embarrassing.
 
You know, you can get help for this. There's a 12-step group for people
who just can't drop a thread. It's called On-and-On-and-On Anon.
 >>


And I can't believe John is still reading the thread if he feels this way.
What's the matter John, don't you know how to kill a thread?

Re: SE, Dreamers, and on and on and on ....

[W. Wesley Groleau (Wes)]

> > You know, you can get help for this. There's a 12-step group for people
> > who just can't drop a thread. It's called On-and-On-and-On Anon.
> 
> What's the matter John, don't you know how to kill a thread?

Is there such a thing as a kill file for Netscape News?
(Yes, Netscape stinks.  But for News, my other choices are worse.)

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Software Engineering and Dreamers

[John G. Volan]

Robert Dewar wrote:
> 
> And I can't believe John is still reading the thread if he feels this way.
> What's the matter John, don't you know how to kill a thread?

Well, I was trying for humor, but if you want a serious response:

I haven't been reading this thread, but I have been "watching" it.  I do
know how to kill a thread but generally I don't bother with a killfile;
if I get fed up with the latest messages in a thread, I'll tell Netscape
to mark the thread as read, collapse the tree, and go on.

But, irrespective of one's kill preferences, a useless or off-topic
thread, especially one that is cross-posted to multiple newsgroups like
this, wastes Internet bandwidth and host resources and just contributes
to the world wide wait. Also, remember that in the case of
comp.lang.ada, everything posted there is echoed on the info-ada mailing
list. If one has chosen to receive digests from info-ada, there's no way
to "kill" threads.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Software Engineering and Dreamers

[Robert Dewar]

<<But, irrespective of one's kill preferences, a useless or off-topic
thread, especially one that is cross-posted to multiple newsgroups like
this, wastes Internet bandwidth and host resources and just contributes
to the world wide wait. Also, remember that in the case of
comp.lang.ada, everything posted there is echoed on the info-ada mailing
list. If one has chosen to receive digests from info-ada, there's no way
to "kill" threads.
 >>


Cross-posting does not increase bandwidth
The total bandwidth taken up by comp newsgroups is absolutely negligible
in terms of the wwwait compared with the binaries in alt.sex.
If the digesting process cannot kill threads, it is defective.
The ability of people to follow off-topic threads obviously appeals
to a lot of people. As long as a thread is easily killable, I see no
measurable disadvantage.

Finally, the most useless of messages are like yours and this one here,
that waste time discussing whether some other thread should exist or not.
You can never kill a thread by telling people to stop contributing. Instead
you just dd irrelevant junk to the thread :-)

Re: Software Engineering and Dreamers

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

> << 
> If science were only about prediction (as has been claimed in this thread and
> numerous times elsewhere), the crocodile theory would be as valid as the
> Newtonian one.
  
> But science is not, so the crocodile theory is not.
>  >>

> Science is only about formulating theories and making predictions (at least
> that is the late 20th century post-Heisenberg viewpoint).

> But let's look at the two theories here

> Newtonian explanation

> Crocodiles using the Newtonian theory pushing things around (as best I
> understand the MH alternative theory).

> Occam's Razor clearly selects the simpler form sans crocodiles, so your
> theory, while not predictively inferior, gets rejected solely on this
> basis (and on no other!)

I disagree that you need Ockham's razor to lay the so-called "Crocodile
Theory" to rest.  As near as I can tell, the "Crocodile Theory" can
be stated this way:  "There are these invisible crocodiles, and 
they move the planets around in some arbitrary way."  (The competing
theory is:  "The planets move in a gravitational field according to
the nature of that field.")

However, crocodiles moving planets around in some unstated arbitrary way
is useless to make predictions from.  Therefore, the theory makes no
predictions at all about planetary "behavior" (one could argue that it
cannot---after all, what happens if the crocodiles change their mind
about how to move the planets?)

And before that fool writes me another email, no I'm not going to accept
"they know about those other laws and always follow them" as a description
of which arbitrary way they move the planets.  I can derive the Newtonian
laws of planetary motion from the nature of the gravitational field.
What can you derive from the crocodiles?  Other than soup, stew, etouffee, 
and so forth, I mean.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Software Engineering and Dreamers

[Mathew Hendry]

In comp.lang.c Jonathan Guthrie <jguthrie@brokersys.com> wrote:
: I disagree that you need Ockham's razor to lay the so-called "Crocodile
: Theory" to rest.  As near as I can tell, the "Crocodile Theory" can
: be stated this way:  "There are these invisible crocodiles, and 
: they move the planets around in some arbitrary way."  (The competing
: theory is:  "The planets move in a gravitational field according to
: the nature of that field.")

: However, crocodiles moving planets around in some unstated arbitrary way
: is useless to make predictions from.  Therefore, the theory makes no
: predictions at all about planetary "behavior" (one could argue that it
: cannot---after all, what happens if the crocodiles change their mind
: about how to move the planets?)

: And before that fool writes me another email, no I'm not going to accept
: "they know about those other laws and always follow them" as a description
: of which arbitrary way they move the planets.

The predictions of the theory are the same, whether you accept it or not. Its
predictions follow directly from its stated assumptions, as with any other
theory, valid or not.

Obviously, you would be a fool if you did accept the theory, but that's hardly
the point. My intention was to illustrate the fact that theories are not
simply blind prediction engines.

Since you have done so well at picking holes in the _explanation_ given by the
theory - rather than its predictions, which are, by definition, sound - you
seem to have proved my point. Your resorting to personal insults is an added
bonus, of course.

-- Mat.

Crocodiles [was: Re: Software Engineering and Dreamers]

[Anonymous]

<JSA.97May14201336@alexandria> <19970602.562B58.2B32@ai110.du.pipex.com>
<5n1261$qj6@polo.demon.co.uk> <19970602.433020.144E5@ai078.du.pipex.com>
<33983ABE.26B2@sni.de> <19970606.49CA70.12B91@ae124.du.pipex.com>
<dewar.865813029@merv> <5nh0th$dam$1@news.hal-pc.org>

There is one prediction the Croc o' Dile theory makes that Newtonian
physics doesn't: The Croc o' Dile theory predicts the existence of the
invisible crocodiles that cause the motion of the planets. ALL
predictions made by a scientific theory MUST be subject to potential
disproof; therefore, if the Croc o' Dile theory is a scientific theory,
there must be some possible experiment or observation that would
disprove this prediction if the theory is incorrect. If no such disproof
is possible, the theory is not science, and will be dismissed by
scientists.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Off topic: Crocodiles

[Mukesh Prasad]

Anonymous wrote:
[snip]
> 
> There is one prediction the Croc o' Dile theory makes that Newtonian
> physics doesn't: The Croc o' Dile theory predicts the existence of the
> invisible crocodiles that cause the motion of the planets. ALL
> predictions made by a scientific theory MUST be subject to potential
> disproof; therefore, if the Croc o' Dile theory is a scientific theory,
> there must be some possible experiment or observation that would
> disprove this prediction if the theory is incorrect. If no such disproof
> is possible, the theory is not science, and will be dismissed by
> scientists.

Actually, there is no reason for it to be particularly
"dismissed", it simply is not useful.  It may or
not represent some kind of reality, but is not
concerned with measurable and observable reality.

If a crocodile theory were to include Newtonion mechanics,
it would be a useful way for making predictions.
But then, there is already a successful theory
for making predictions of this kind, so it would
have to differentiate itself from Newtonion
mechanics.

Now if invisible crocodiles were to provide
a good theory for something not properly
understood, Good scientists will investigate
this theory.

Most scientists would not.  But notice the
capitalization of good.  In practice
most scientists would not because it could
jeopardize their grants, and might make them
look foolish.  (At least until everybody
else and the popular journals started to talk
about crocodiles.)

Most people would believe crocodile theories
if they were a part of the culture, or if
it made them feel better to believe in
crocodiles.  A high part of a meme's survival
ability is how good it makes the believer
feel.

Re: Off topic: Crocodiles

[Robert Dewar]

Mukesh said

<<Actually, there is no reason for it to be particularly
"dismissed", it simply is not useful.  It may or
not represent some kind of reality, but is not
concerned with measurable and observable reality.>>

The notion of unobservable reality is not only irrlevant to science, but
often actively harmful. Scientists do better not to start believing in
any "reality" at all, but rather to concentrate on what is observable and
what is not. Once scientists start "believing" anything, they are prone
to unscientific inflexibility :-) As I mentioned before Al Matson, the
physicist from UT, has explored this issue very effectively.

Re: Off topic: Crocodiles

[Mukesh Prasad]

Robert Dewar wrote:
> 
> Mukesh said
> 
> <<Actually, there is no reason for it to be particularly
> "dismissed", it simply is not useful.  It may or
> not represent some kind of reality, but is not
> concerned with measurable and observable reality.>>
> 
> The notion of unobservable reality is not only irrlevant to science, but
> often actively harmful. Scientists do better not to start believing in

Yes, but it would be rather hard to find human beings who
do not believe in anything which is unprovable!

Many scientists are known to be devout believers in some
religion or other outside of their working lives.  While
it is true that any belief is going to constrain some areas
of exploration (e.g. any scientists working on consciousness
or related issues, who are through some accident or other,
constrained by some set of religious beliefs -- are not
only useless, but indeed actively harmful to the progress
of such work if individually or collectively in an influential
position), there need not be such connections in all cases.
E.g. a chemist should be able to afford to believe in aliens, which
may be outside of observable and measurable phenomenon, yet do
not come into play in her work.

Re: Off topic: Crocodiles

[Jon S Anthony]

In article <dewar.866051313@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Mukesh said
> 
> <<Actually, there is no reason for it to be particularly
> "dismissed", it simply is not useful.  It may or
> not represent some kind of reality, but is not
> concerned with measurable and observable reality.>>
> 
> The notion of unobservable reality is not only irrlevant to science, but
> often actively harmful. Scientists do better not to start believing in
> any "reality" at all, but rather to concentrate on what is observable and
> what is not.

You have just crossed over into quicksand.  First, "unobservable" is
ill-defined.  Second, even if you allow some notion of this based on
some current set of capabilities, you have just pitched out the window
all "hidden variable" theories as "unscientific".  I don't think so.
Third, if _all_ you are concerned with is "observation" (i.e., all
knowledge is strictly empirically based) then you have to solve the
problems presented by Hume (et.al, but Hume gives the most
consistently relentless version).

I suppose you could try saying that, "No, not all knowledge is
empirically based, but all _scientific_ knowledge is".  Perhaps, but
that just side steps the issue.


> to unscientific inflexibility :-) As I mentioned before Al Matson, the
> physicist from UT, has explored this issue very effectively.

Shrug.  So have a host of others.  For example, both Popper and
Lakatos rather vehemently disagreed with this sort of position.  It
all goes back to Bohr, Complimentarity and the Copenhagen
Interpretation for QM.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Crocodiles [was: Re: Software Engineering and Dreamers]

[Spam Hater]

> There is one prediction the Croc o' Dile theory makes that Newtonian
> physics doesn't: The Croc o' Dile theory predicts the existence of the
> invisible crocodiles that cause the motion of the planets. ALL
> predictions made by a scientific theory MUST be subject to potential
> disproof; therefore, if the Croc o' Dile theory is a scientific theory,
> there must be some possible experiment or observation that would
> disprove this prediction if the theory is incorrect. If no such disproof
> is possible, the theory is not science, and will be dismissed by
> scientists.

I really _thought_ I was out of this thread....

Do you allow "prediction" to refer to the past?  If so, most of the
"predictions" of Darwinian evolutionary theory can be neither proved
nor disproved, and so "the theory is not science, and will be 
dismissed by scientists."

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Crocodiles [was: Re: Software Engineering and Dreamers]

[Anonymous]

<19970609.5A1DA0.14F78@an194.du.pipex.com>
<199706111259.OAA29188@basement.replay.com>

On Wed, 11 Jun 1997 18:18:00 GMT, Spam Hater <no.such.user@no.such.com>
wrote:

> > There is one prediction the Croc o' Dile theory makes that Newtonian
> > physics doesn't: The Croc o' Dile theory predicts the existence of the
> > invisible crocodiles that cause the motion of the planets. ALL
> > predictions made by a scientific theory MUST be subject to potential
> > disproof; therefore, if the Croc o' Dile theory is a scientific theory,
> > there must be some possible experiment or observation that would
> > disprove this prediction if the theory is incorrect. If no such disproof
> > is possible, the theory is not science, and will be dismissed by
> > scientists.
> 
> I really _thought_ I was out of this thread....

Sorry!

> 
> Do you allow "prediction" to refer to the past?  If so, most of the
> "predictions" of Darwinian evolutionary theory can be neither proved
> nor disproved, and so "the theory is not science, and will be 
> dismissed by scientists."

Since evolution has been observed in action, the predictions of the
theory (in the future) have had opportunities of disproof, but were not
disproved. No theory can be proved.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Software Engineering and Dreamers

[Jonathan Guthrie]

Okay, the "personal attacks" (calling you a "fool" in public hardly
qualifies as a personal attack on Usenet, referencing the brouhaha
on various newsgroups over an article by Ousterhout as an example of
what I'm thinking of) are uncalled for, so here's what I really think.  

In comp.lang.ada Mathew Hendry <scampi@dial.pipex.com> wrote:
> : However, crocodiles moving planets around in some unstated arbitrary way
> : is useless to make predictions from.  Therefore, the theory makes no
> : predictions at all about planetary "behavior" (one could argue that it
> : cannot---after all, what happens if the crocodiles change their mind
> : about how to move the planets?)

> The predictions of the theory are the same, whether you accept it or not. Its
> predictions follow directly from its stated assumptions, as with any other
> theory, valid or not.

You don't seem to understand.  I will attempt to explain better.

The positions of the planets, which is all you seem to be talking about,
can be determined by Kepler's laws.  Those laws can be derived from
Newtonian dynamics while it is a postulate with this "crocodile
theory."  While it is possible to make other predictions than the future
positions of the planets from Newtonian dynamics, it is not possible to
predict ANYTHING using the theory that crocodiles move the planets by
whim and their knowledge of Kepler's laws EXCEPT the future positions
of the planets,

This is true "whether you accept it or not."

Therefore, your "crocodile theory" is inferior in predictive power to
Newton's theory of universal gravitation, which is what you seem to
be comparing it to.

Now, if you were to expand your "crocodile theory" to be something like
a "theory of universal crocodiles", I would point out that 

A) Newton doesn't attempt to explain where gravity comes from or how
it works so I'm as willing to accept your theory of gravitation as any
other that I've seen
and 
B) Changing the name isn't an explanation.

> Obviously, you would be a fool if you did accept the theory, but that's hardly
> the point. My intention was to illustrate the fact that theories are not
> simply blind prediction engines.

I know what you're point is.  That's why I started with a statement that
Ockham's razor isn't needed.  Ockham's razor is needed to select which
theory is preferred when you have theories of equal predictive power.  To
invoke it is to concede your point.  However, you have not demonstrated
to my satisfaction that your theory is equal in predictive power to the
laws of Newtonian mechanics (simply stating that it is won't fly---I'd
just as soon believe that someone always tells you the truth because they
say they do) and I am attempting to explain WHY that I'm not satisfied
with your "proof."

In a nutshell, it's because the "crocodile theory" only explains the
motions of the planets, while Newtonian mechanics governs EVERYTHING.

Well, okay, there is one other reason I don't like your example.  
It's really bogus to wave your hands by saying "you get the same
answers, okay?"  How do you know?  Are you psychically linked to
these crocodiles, or what?  What RAW DATA are you using to create
your theory with?  Where does it come from?  (This IS what you're
trying to demonstrate, which is why it's the "other reason.")

With all the competing theories out there, and all the very real
examples you could make of competing theories making identical
predictions with one being favored for emotional reasons, you came
up with a hypothetical one.  It just so happens that I agree with
you:  The value of theories is based upon more than their predictive
power.  Ockham's razor, for better or for worse, makes that sort of
selection a formal part of science.  However, I could come up with
a better example with my eyes closed.

In fact, you seem to be so attached to the hypothesis that I have an
emotional attachment to Newtonian mechanics that I might use your
posts to ME as an example of what you're trying to demonstrate.  

Further deponant sayeth not.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Software Engineering and Dreamers

[Mathew Hendry]

Jonathan Guthrie <jguthrie@brokersys.com> wrote:
: With all the competing theories out there, and all the very real
: examples you could make of competing theories making identical
: predictions with one being favored for emotional reasons, you came
: up with a hypothetical one.  It just so happens that I agree with
: you:  The value of theories is based upon more than their predictive
: power.  Ockham's razor, for better or for worse, makes that sort of
: selection a formal part of science.  However, I could come up with
: a better example with my eyes closed.

Maybe, but the "crocodile theory" is vaguely related to a real debate.
Replace crocodiles with a god, the proponents of the crocodile theory
(i.e. me ;) with the Roman Catholic Church, and most other contributors to
this thread with Galileans, and you might begin to see a shaky connection.

The argument from "my" side would be that a god moved the various celestial
bodies relative to a stationary Earth _as if_ they followed Gallilean laws.
But that hypothesis was eventually rejected as a scientific explanation,
because its additional postulates are redundant and untestable, and the
Galilean version was later explained more fully by other theories.

A more recent example might be arguments surrounding the theories of "parallel
universes". Which is the better explanation - that objects at quantum scales
behave _as if_ they were influenced by invisible objects, through the device
of probabilistic wave functions; or that those ghost objects _really do_ exist
elsewhere, and _really do_ interact with the objects in "our" universe?

-- Mat.

Re: Software Engineering and Dreamers

[Nick Roberts]

Good boots.

Re: Software Engineering and Dreamers

[Lawrence Kirby]

In article <19970606.49CA70.12B91@ae124.du.pipex.com>
           scampi@dial.pipex.com "Mathew Hendry" writes:

>It does make predictions, namely that the observable phenomenon behaves in
>exactly the same way as that predicted by the Newtonian theory. The crocodiles
>know that theory, and behave accordingly.

The problem with the crocodile theory is that it is based on hidden
knowledge, not scientific axioms. It may be valid but doesn't deal with
the fundamentals. And of course the crocodiles might change their minds or
die out, so the crocodile theory is not as strongly founded.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Software Engineering and Dreamers

[W. Wesley Groleau (Wes)]

> The problem with the crocodile theory is that it is based on hidden
> knowledge, not scientific axioms. It may be valid but doesn't deal with
> the fundamentals. And of course the crocodiles might change their minds or
> die out, so the crocodile theory is not as strongly founded.

No, the problem with the crocodile theory is that its axioms 
(the existence of invisible crocodiles) are offensive to 
"right-thinking scientists."

An axiom is an unproven starting point from which the rest of
a formal system is derived.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Software Engineering and Dreamers

[Robert Dewar]

Wes says

<<No, the problem with the crocodile theory is that its axioms 
(the existence of invisible crocodiles) are offensive to 
"right-thinking scientists."
 >>


As a practical description of how some scientists think, this is probably
accurate, but as a description of how they SHOULD think it is flawed. 
The history of science is full of incidents of scientists rejecting
superior (in a predictive sense) theories because they find them
offensive (e.g. Einstein's objections to Heisenberg's theories), but
such non-scientific reactions often stand in the way of progress. if
the crocodile theory had superior predictive capabilities, then it
should immediately be accepted by all scientists. In fact, the theory
does NOT have superior predictive capabilities, and is unnecessarily
complex, in that it proposes elements that cannot be deduced as useful
from observations, and which are therefore junk.

Re: Software Engineering and Dreamers

[W. Wesley Groleau (Wes)]

> <<No, the problem with the crocodile theory is that its axioms
> (the existence of invisible crocodiles) are offensive to
> "right-thinking scientists."
>  >>
> 
> As a practical description of how some scientists think, this is probably
> accurate, but as a description of how they SHOULD think it is flawed.

Yes.  The quote-marks were a reminder that "right-thinking" was not 
_my_ phrase.  :-)

> [snip] .... if
> the crocodile theory had superior predictive capabilities, then it
> should immediately be accepted by all scientists. ....

But it won't be.  Scientists, being human, have just as much tendency
(as a group) to pig-headedness as the rest of us (as you suggested in
what I snipped).  A modern example:  Some doctors are claiming that
there is empirical evidence that prayer improves a patient's chances
of recovery.  Some say this evidence does not exist.  But a large
number are blasting their colleagues for even suggesting such an 
unscientific thing.

Having fanned the flames of all the bigots on both sides of
the religion issue, I now bow out of this thread.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Software Engineering and Dreamers

[Robert Dewar]

Mat said

<<Since the above theories make the same predictions, no experimental test can
distinguish between them. And yet no right-minded scientist would believe my
crocodile theory. Why not?
>>

We have not seen your crocodile theory, so guesses as to whether or not it
might be accepted are silly. Note that in using the word crocodile, you are
appealing to an informal notion of reality which might or might not be
helpful. Perhaps it would be better to call it your crocjunk theory to
avoid unnecessary associations (though sometimes these associations are
useful).

We choose between theories on the basis of predictive power, and if we have
two competing theories then we choose the simpler one in Occam's sense.

Re: Software Engineering and Dreamers

[Mathew Hendry]

In comp.lang.c Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: Mat said

: <<Since the above theories make the same predictions, no experimental test can
: distinguish between them. And yet no right-minded scientist would believe my
: crocodile theory. Why not?
: >>

: We have not seen your crocodile theory, so guesses as to whether or not it
: might be accepted are silly.

Okay, here it is again. There are some crocodiles. They know everything about
current theories of dynamics. They move objects around accordingly.

:                              Note that in using the word crocodile, you are
: appealing to an informal notion of reality which might or might not be
: helpful.

My terminology is irrelevant. I have provided the predictions, which you seem
to think are all that can be _required_ from a theory.

:            Perhaps it would be better to call it your crocjunk theory to
: avoid unnecessary associations (though sometimes these associations are
: useful).

Again, irrelevant. But please, give the theory the name which you think will
help your argument the most.

: We choose between theories on the basis of predictive power, and if we have
: two competing theories then we choose the simpler one in Occam's sense.

Then you agree with me. Prediction alone is not enough.

-- Mat.

Re: Software Engineering and Dreamers

[Ed Prochak - Woodland Consultants]

This has certainly gone off the languages thread, but I'll toss
out one comment here.

John Winters (john@polo.demon.co.uk) wrote:
: In article <19970602.562B58.2B32@ai110.du.pipex.com>,
: Mathew Hendry <scampi@dial.pipex.com> wrote:
: >In comp.lang.c++, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
: >
: >: <<Science, be it physics, chemistry, biology or whatever, is an attempt to
: >: discover the laws and principles which govern the existence of "things".
: >: "Things" can be natural phenomena or a phenomenon exhibiting certain
: >: behaviour which is defineable at whatever level. It's basically an
: >: attempt to explain the way things, any things, work.
: >: >>
: >: 
: >: I object to this solution. It smacks of searching for Truth with a 
: >: capital T. Science is about constructing theories that are consistent
: >: with observations, and which have the capability of predicting the
: >: outcome of observations not yet made. 
: >
: >Imagine that you have produced a theory about the movements of the planets,
: >basing it upon Newtonian dynamics. I provide a competing theory, based upon
: >the exploits of invisible crocodiles.
: >
: >The two theories give exactly the same predictions.
: >
: >Given your claim that theories are judged only on their consistency with
: >observations,

: Errr, what else do you imagine they could be judged on?

: >how do you choose between these two theories?

: You devise tests which should produce different results depending on
: which of the two theories is true.  Then you apply the tests, observe
: the results and discard whichever theories are disproven.

: There really is *no* other way you can do it.  This is the whole
: essence of scientific enquiry.

: John
: -- 
: John Winters.  Wallingford, Oxon, England.


There is one tool used in this situation: Occam's razor.
Of two theories which differ in assumptions,
but result in the same predictions ,
and match the same observations,
keep the one with the fewer and simpler assumptions.

granted real theories are not easily recognizable as
clearly simpler than another (consider the fundamental physics
theories like "strings" and its competitors)

But to at least keep this thread to software, I'd say this is
clearly an Engineering type field. Our jobs are to get something
working. There obviously is some Computer Science to back us
up, even though it is not always codified in clearcut equations.
Analysis of algorithms are one tool to help. Reusable components
(libraries, objects, whatever) are another part of an Engineering
approach. Appropriate programming languages should be another.

Enough for now. I've got work to do.

  ed

Re: Software Engineering and Dreamers

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.865041126@merv>...
> <<Science, be it physics, chemistry, biology or whatever, is an attempt
to
> discover the laws and principles which govern the existence of "things".
> "Things" can be natural phenomena or a phenomenon exhibiting certain
> behaviour which is defineable at whatever level. It's basically an
> attempt to explain the way things, any things, work.
> >>
> 
> I object to this solution. It smacks of searching for Truth with a 
> capital T. Science is about constructing theories that are consistent
> with observations, and which have the capability of predicting the
> outcome of observations not yet made. 
> 
> "*the* way things work"
> 
> no
> 
> you are looking for *a* theory, not *the* theory!


This brings the theory of multiple realities into play. A concept I think
most people find a bit hard to grasp (or swallow or whatever [maybe grasp
in one universe and swallow in another?]). 

Nick ;-)

Re: Software Engineering and Dreamers

[Robert Dewar]

Nick Roberts said

<<This brings the theory of multiple realities into play. A concept I think
most people find a bit hard to grasp (or swallow or whatever [maybe grasp
in one universe and swallow in another?]). 
>>

Actually the concept of even *one* reality is quite irrelevant to science in 
the view of many philosophers. Indeed Al Matson argues that it is a detriment
for a scientist to believe in the notion of reality, because it will tend to
cloud pure abstract thinking about what theories match observations.

Re: Software Engineering and Dreamers

[Jon S Anthony]

In article <5mmvgj$61k@squire.cen.brad.ac.uk> cgrussel@bradford.ac.uk (Vibrating Bum-Faced Goats) writes:

> Mathematics exists in the mind alone.

You would get some pretty heated disagreement over this from many
mathematicians and philosophers (you would also get a number lining up
on your side...)  Of course, this just punts the problem to the issue
of "what is mind" - which is even more inflammatory.


> It is the process of discovering and describing precisely by
> symbolic means various kinds of facts and relationships.

<playing one of those who would disagree with the above bit>: OK, so
what do these "facts" and "relationships" concern?  What are they
about?  Of what are they facts and relationships??  Sounds like
something "out there"...


> I've forgotten who I'm agreeing with now. :^)

:-)!!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[H. Blakely Williford]

Dann Corbit wrote:
> (Vibrating Bum-Faced Goats) writes:
> >
> > > Mathematics exists in the mind alone.

can you look at a sun rise and say this?

the way the particles in the upper atmosphere refract the light?

-- 
H. Blakely Williford             | Men never do evil so completely and
Systems Administrator/Programmer | cheerfully  as when they do it from
The Fuller Brush Company         | religious conviction.     -- Pascal

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Craig Franck]

"H. Blakely Williford" <blakew@fuller.com> wrote:
>Dann Corbit wrote:
>> (Vibrating Bum-Faced Goats) writes:
>> >
>> > > Mathematics exists in the mind alone.
>
>can you look at a sun rise and say this?
>
>the way the particles in the upper atmosphere refract the light?

You are not helping the cause any. Color arises from how are brains
process light, and does not exist independently of our perceiving it.
Because of this, it is clearly only in our minds even more than math
is. I think Mr. Goats point can be made clearer once you realize that 
math is about symbols and how you can transform them into one another.
"2 + 2 = 4" seems to be expressing a relationship of some sort that 
exists externally in nature, but what it means and how we interpret 
is actually quite close to how we process langauge. You wouldn't say 
English exists in nature, and is not solely the product of our brains, 
just because you can point to a big leafy green thing and say "tree".
It is not like the word "tree" was laying about, just waiting to be
discovered, any more than the symbol "2" was. In this sense (and in
many others as well) math is a product of our brains.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I don't pretend to understand the universe, it is
a great deal bigger than I am. -- Thomas Carlyle

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spaceman Spiff]

Craig Franck wrote:
> "H. Blakely Williford" <blakew@fuller.com> wrote:
> >the way the particles in the upper atmosphere refract the light?
> 
> You are not helping the cause any. Color arises from how are brains
> process light, and does not exist independently of our perceiving it.

Sorry, Craig, you got this wrong.
Light of different colors is light of different frequencies.
The frequency of light emitted by some atom, does, in fact, 
exist independent of our brains. It's called hertz.

Using your argument, only the word "color" is dependent upon
out brains to interpret it (as you point out below).

> Because of this, it is clearly only in our minds even more than math
> is. I think Mr. Goats point can be made clearer once you realize that
> math is about symbols and how you can transform them into one another.
> "2 + 2 = 4" seems to be expressing a relationship of some sort that
> exists externally in nature, but what it means and how we interpret
> is actually quite close to how we process langauge. You wouldn't say
> English exists in nature, and is not solely the product of our brains,
> just because you can point to a big leafy green thing and say "tree".
> It is not like the word "tree" was laying about, just waiting to be
> discovered, any more than the symbol "2" was. In this sense (and in
> many others as well) math is a product of our brains.
> 
> --
> Craig
> clfranck@worldnet.att.net
> Manchester, NH
> I don't pretend to understand the universe, it is
> a great deal bigger than I am. -- Thomas Carlyle

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <3394E51B.7A5A@flash.net>,
Spaceman Spiff  <csweber@flash.net> wrote:
>Craig Franck wrote:
>> "H. Blakely Williford" <blakew@fuller.com> wrote:
>> >the way the particles in the upper atmosphere refract the light?
>> 
>> You are not helping the cause any. Color arises from how are brains
>> process light, and does not exist independently of our perceiving it.
>
>Sorry, Craig, you got this wrong.
>Light of different colors is light of different frequencies.

That is false, Spiff.  Colors can be perceived as a result of a pure frequency
or as a result of the mixture of two or more frequencies. The eye only responds
to two or three different regions of the spectrum. This is why only three
different kinds of phosphor elements in a CRT display are able to reproduce
such a wide variety of hues.

>The frequency of light emitted by some atom, does, in fact, 
>exist independent of our brains. It's called hertz.

From this it does not follow that every brain perceives color in the same way,
or that color exists independently of the observer. I don't see the necessary
connection between frequency and the sensation of color.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Robert Dewar]

spaceman says

<<Sorry, Craig, you got this wrong.
Light of different colors is light of different frequencies.
The frequency of light emitted by some atom, does, in fact, 
exist independent of our brains. It's called hertz.
 
Using your argument, only the word "color" is dependent upon
out brains to interpret it (as you point out below).>>


That's wrong. Wavelength is wavelength, color is color. There is a relation
but it is not nearly as close as you seem to think. Color is definitely
about perception. You can perceive color even though no light of the
relevant wavelength is present. the Land two color experiments (and many
other similar experiments) show this conclusively.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Ceri Stagg]

|> > Because of this, it is clearly only in our minds even more than math
|> > is. I think Mr. Goats point can be made clearer once you realize that
|> > math is about symbols and how you can transform them into one another.
|> > "2 + 2 = 4" seems to be expressing a relationship of some sort that
|> > exists externally in nature, but what it means and how we interpret
|> > is actually quite close to how we process langauge. You wouldn't say
|> > English exists in nature, and is not solely the product of our brains,
|> > just because you can point to a big leafy green thing and say "tree".
|> > It is not like the word "tree" was laying about, just waiting to be
|> > discovered, any more than the symbol "2" was. In this sense (and in
|> > many others as well) math is a product of our brains.

I think a distinction should be made between NUMBERS and NUMERALS. Our
mathematical system's rules are not arbitrary, they have been chosen
because of their mapping to the laws of numbers we see in nature,
e.g. if we have 4 things (I mean the number 4, not the numeral) and
remove 2, we clearly have only 2 remaining. Admittedly, maths is not a
science per se because most of it deals with platonic ideas that
cannot be directly seen or touched, making it trickier to get a handle
on in these areas than e.g. physics, but I think it's wrong to suggest
that something like the Mandelbrot set doesn't exist outside people's
minds.....surely the Mandelbrot set is a discovery, not an invention?
I don't think mathematical systems can have the arbitrariness of
languages. The numerals and symbols can be arbitrary, but their
transformation rules MUST consistently map onto and track the
relationships of numbers. But getting your head around the
verifications involved in this is indeed tricky stuff......


        ____
   ____/....\____	C.P.Stagg
  |____	Ceri ____|      ------------------
    /  \____/  \	ceris@dai.ed.ac.uk
  """"""""""""""""	

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Philip Brashear]

OK, I finally got sucked into this maelstrom.

Why are people talking about numbers so much?  There seems to be a strong
impression that mathematics = the study of numbers.  No, that's 
arithmetic.

Mathematics is the study of logical implication: one puts up a set of
postulates and studies the theorems (implications) that result.

Some of these postulates concern these "number" things (like Peano's
postulates).  Others concern these "geometric" things (like several
people's attempts to perfect Euclid's postulates).  Others concern
things with no obvious relation to observable reality.  (The latter
are often the most interesting and turn out to have great impact on
the "real" world.  Talk about serendipity!)

When I was working on that elusive Ph.D. in math, my field was
topological algebra (as distinguished from algebraic topology).
I REALLY didn't deal with numeric concepts.

Phil Brashear

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Shmuel (Seymour J.) Metz]

Philip Brashear wrote:
> 
> When I was working on that elusive Ph.D. in math, my field was
> topological algebra (as distinguished from algebraic topology).

So do you crack a smile when the Unix folks talk about filters?

> Phil Brashear

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Vibrating Bum-Faced Goats]

Craig Franck (clfranck@worldnet.att.net) wrote:
: "H. Blakely Williford" <blakew@fuller.com> wrote:
: >Dann Corbit wrote:
: >> (Vibrating Bum-Faced Goats) writes:
: >> >
: >> > > Mathematics exists in the mind alone.
: >
: >can you look at a sun rise and say this?
: >
: >the way the particles in the upper atmosphere refract the light?

: You are not helping the cause any. Color arises from how are brains
: process light, and does not exist independently of our perceiving it.

<SNIP>

: It is not like the word "tree" was laying about, just waiting to be
: discovered, any more than the symbol "2" was. In this sense (and in
: many others as well) math is a product of our brains.

That's exactly what I'm trying to say. 

--
Chris Russell           | Bradford Bulls - Wembley 1997
Electronic Imaging Unit | 
University of Bradford  | Tough on St.Helens
TEL: +44 1274 385463    | Tough on the causes of St.Helens.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Vibrating Bum-Faced Goats]

Dann Corbit (dcorbit@solutionsiq.com) wrote:
: Jon S Anthony <jsa@alexandria> wrote in article
: <JSA.97Jun2174143@alexandria>...
: > In article <5mmvgj$61k@squire.cen.brad.ac.uk> cgrussel@bradford.ac.uk
: (Vibrating Bum-Faced Goats) writes:
: > 
: > > Mathematics exists in the mind alone.
: > 
: > You would get some pretty heated disagreement over this from many
: > mathematicians and philosophers (you would also get a number lining up
: > on your side...)  Of course, this just punts the problem to the issue
: > of "what is mind" - which is even more inflammatory.

Oh dear. In an attempt to give my view of an apparant stretching of a 
word's definition I seem to have done the same thing. :^)

: Here is some real flame bait [addressed primarily to Mr. 'Vibrating' ;-)]: 

Actually Vibrating is my first name. You may call me Vibrating but for 
correctness above it would be Mr.Goats. :^)

: If math exists in the mind alone, does a stupid person and a smart one have
: a different set of mathematics rules that apply to them?  What about a
: planet with no people on it, and we are not aware of it?  Must it plummet
: into its star, since there is no math available to make it obey the inverse
: square law?  

Well, I recently posted this in another newsgroup 
(rec.sport.rugby.league, strange as it may seem) which may answer the 
question:

>> <Pedantic mode on>
>>
>> Immeasurable phenomena do not disappear with a puff of logic, they remain
>> unquantifiable (if there is such a word) until such time as a means of
>> measuring that phenomena is discovered.
>>
>> <Pedantic mode off>

In otherwords, just because we do not know of something or are unable to 
comprehend it does not mean such a thing does not exist. 

<Dogs doing calculus in their heads to catch balls snipped for brevity ;^) >

Now then, the defintion I attribute to mathematics I laid out like 
this: 

>> Mathematics exists in the mind alone. It is the process of discovering 
>> and describing precisely by symbolic means various kinds of facts and 
>> relationships. It is the process of implementing a rich "language" which 
>> enables scientists to express their ideas and engineers to model the 
>> behviour of their phenomena-harnessing implementations of those ideas.

What I'm trying to say here is that it could be argued (by me amongst 
others) that the relationships between objects and phenomena exist 
anyway. Mathematics is the ongoing creation of a extraordinarily rich and 
diverse language which enables us to express those relationships. A 
mathematician is creating a tool for scientists and engineers alike. It 
may require a mathematician to make use of that tool at times but, at 
it's very core, tool creation is what I believe to be the essence of maths.

I don't see it as being different from any other language in that it 
enables us to get a particular idea or point of view across. It often 
does so with more success than I do with English, but there I digress. :^)

Distant unknown planets do not crash into their sun because no one there 
has *discovered* the inverse square law. That relationship continues 
to exist in a form unexpressable to the local inhabitants. 

That is what I meant by saying "Mathematics exists in the mind alone". 
The relationships and properties are already there but the language 
used to describe them is a human creation.

: The universe does not revolve around the human race.  The human race is a
: miniscule part of the universe.  We do not manufacture the mathematical and
: physical laws.  Why must people constantly place themselves as the bright,
: shining core of existence?

I do not, not by any stretch of the imagination. I'm quite sure that my 
comprehension of the universe we live in is inexplicably small in 
relation to the size of that universe. As such I'm quite happy to be 
talked out of a point of view if I can be convinced I'm on the wrong 
track. 

Cheers,
Chris.

--
Chris Russell           | Bradford Bulls - Wembley 1997
Electronic Imaging Unit | 
University of Bradford  | Tough on St.Helens
TEL: +44 1274 385463    | Tough on the causes of St.Helens.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[�Stephen!]

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


Vibrating Bum-Faced Goats wrote:
> 
> Dann Corbit (dcorbit@solutionsiq.com) wrote:
> : Jon S Anthony <jsa@alexandria> wrote in article
> : <JSA.97Jun2174143@alexandria>...
> : > In article <5mmvgj$61k@squire.cen.brad.ac.uk> cgrussel@bradford.ac.uk
> : (Vibrating Bum-Faced Goats) writes:
> In otherwords, just because we do not know of something or are unable to
> comprehend it does not mean such a thing does not exist.

	Little kids don't know what gravity is, but when they fall down...

> What I'm trying to say here is that it could be argued (by me amongst
> others) that the relationships between objects and phenomena exist
> anyway. Mathematics is the ongoing creation of a extraordinarily rich and
> diverse language which enables us to express those relationships. A
> mathematician is creating a tool for scientists and engineers alike. It
> may require a mathematician to make use of that tool at times but, at
> it's very core, tool creation is what I believe to be the essence of maths.

	I like to think of mathematics as a means of expressing the
relationships between numbers. The angles of a square, the lengths of
the sides of a pentagon, even the relationships between musical notes
can be expressed as a pattern of numbers. C4 is 12 notes from C5 is a
perfectly valid mathmatical statement. Programming is merely a way of
expressing the relationships between a computer and the outside world.

<snip>

> 
> That is what I meant by saying "Mathematics exists in the mind alone".
> The relationships and properties are already there but the language
> used to describe them is a human creation.

	One is a totally arbitrary name. It may be called "Throbene" for all it
matters, it is merely a way of expressing the number. The names for the
numbers are a human invention, the numbers themselves are not.

<snip>

	Math is similar to English in this respect. The object exists whether
you call it "water", "aqua", etc. To quote Shakespeare "A rose by any
other name smells just as sweet..."

-- 
�Stephen!
Maintainer of the Punk and Metal Midi Archives
	http://www.geocities.com/SiliconValley/4063/index.html

"Just the thoughts of a disillusioned teen..."

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Kaz Kylheku]

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


In article <3395FF96.107E@ionaprep.pvt.k12.ny.us>,
�Stephen! <99borns@ionaprep.pvt.k12.ny.us> wrote:
>	I like to think of mathematics as a means of expressing the
>relationships between numbers. The angles of a square, the lengths of

Not broad enough. There exist plenty of abstract mathematical entities with
interesting formal properties that are nevertheless not numbers.

>	One is a totally arbitrary name. It may be called "Throbene" for all it
>matters, it is merely a way of expressing the number. The names for the
>numbers are a human invention, the numbers themselves are not.

You are making a mere philosophical hypothesis here.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Volker Hetzer]

Kaz Kylheku wrote:
> =

> In article <3395FF96.107E@ionaprep.pvt.k12.ny.us>,
> =A1Stephen! <99borns@ionaprep.pvt.k12.ny.us> wrote:
> >       One is a totally arbitrary name. It may be called "Throbene" fo=
r all it
> >matters, it is merely a way of expressing the number. The names for th=
e
> >numbers are a human invention, the numbers themselves are not.
Try to see it that way:
Without minds to think, there would be no numbers. Of course there would
still be one earth, but the abstcraction from the planet to the number 1
would
not be made. But that abstraction is what mathematics is about.
Therefore: No mind, no mathematics.

Volker

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spam Hater]

> Question #1: What does a tree do when it falls and someone IS around 
> to hear it?
> Answer: It makes a sound.

Define Sound.

> Question #2: How does the presence or absence of an observer affect 
> the falling tree?
> Answer: It doesn't make a bit of difference.

Do you have empirical evidence for this?

Is this getting ridiculous or what?

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spaceman Spiff]

Spam Hater wrote:

> > Question #1: What does a tree do when it falls and someone IS around
> > to hear it?
> > Answer: It makes a sound.
> 
> Define Sound.

A wave of compression a rarefration of gas molecules caused by
any mechanical action.
 
> > Question #2: How does the presence or absence of an observer affect
> > the falling tree?
> > Answer: It doesn't make a bit of difference.
> 
> Do you have empirical evidence for this?

He can't, there was no one to observe it.
 
> Is this getting ridiculous or what?

Yes, it is.
When you know what happened to Schrodinger's cat, 
then let us know...

-Scotty

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Stephan Wilms]

Spaceman Spiff wrote:
> 
> Spam Hater wrote:
> 
> > Is this getting ridiculous or what?
> 
> Yes, it is.
> When you know what happened to Schrodinger's cat,
> then let us know...

It was abducted by aliens and adopted by Elvis

Stephan

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spam Hater]

Spaceman Spiff wrote:
> 
> > Is this getting ridiculous or what?
> 
> Yes, it is.
> When you know what happened to Schrodinger's cat,
> then let us know...

Schrodinger fastened a piece of toast to the cat's back and dropped it.
Since a cat must always land on its feet, and a piece of toast must
always land buttered side down, the only way to resolve the impasse
was for the cat (without the fiddle) to follow the cow to the moon.

With hopes of antigravity, Schrodinger tried to duplicate the
experiment, with another cat, but so far has been unable to get a cat
to hold still long enough.


-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Mukesh Prasad]

Spam Hater wrote:
> 
> > Question #1: What does a tree do when it falls and someone IS around
> > to hear it?
> > Answer: It makes a sound.
> 
> Define Sound.

Good point.  Here are a couple (not too good, complete or
elaborate) definitions:

1)  Molecular vibrations of a particular type.  (Typically in air.)
Implication:  Tree does make a sound.

2)  A human experience which all humans (who are
    not deaf) know about.

Implication:  Tree does not make a sound.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Philip Hindman]

Phil Berman wrote:
> 
> My response to this question has always been this:
> Question #1: What does a tree do when it falls and someone IS around to
> hear it?
> Answer: It makes a sound.
> 
> Question #2: How does the presence or absence of an observer affect the
> falling tree?
> Answer: It doesn't make a bit of difference.
> 
> Conclusion: The tree makes a sound when it falls.

Yes, but how do you _know_ someone the presence or absence of a 
human being does not affect it?  See Heisenberg's uncertainty 
principle.  
-- 
-----------------------------------------------------------------
| Philip Hindman      |  "We _mock_ what we do not understand." |
| Cylon@ou.edu        |                        Dan Akroyd       |
| The not-so-newbie   |                        "Spies Like Us"  |
| student programmer  |                                         |
-----------------------------------------------------------------

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Craig Franck]

"Phil Berman" <madivaan@gte.net> wrote:

>My response to this question has always been this:
>Question #1: What does a tree do when it falls and someone IS around to
>hear it?
>Answer: It makes a sound.
>
>Question #2: How does the presence or absence of an observer affect the
>falling tree?
>Answer: It doesn't make a bit of difference.

What if it hits the observer?

>Conclusion: The tree makes a sound when it falls.

When a tree falls in the woods and crushes a deaf-mute, is there a sound? 
And in the same vein, what must the initial velocity of a cow being flung
from a catapult be in order to achieve orbit?

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
"Thinking is highly overrated." -- Zippy the Pin Head

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spaceman Spiff]

Craig Franck wrote:
> >
> >Question #2: How does the presence or absence of an observer affect the
> >falling tree?
> >Answer: It doesn't make a bit of difference.
> 
> What if it hits the observer?

ROFL!!
 
> When a tree falls in the woods and crushes a deaf-mute, is there a sound?

*GISH*

> And in the same vein, what must the initial velocity of a cow being flung
> from a catapult be in order to achieve orbit?

6.92 miles per sec. 
Now what is the airspeed of an unladen swallow?

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Steve Howard]

Spaceman Spiff wrote:
[snip]
> Now what is the airspeed of an unladen swallow?

African or European?
-- 
Steve Howard           | Lockheed Martin Ocean, Radar & Sensor Systems
Software Engineer      | P.O. Box 4840 EP-7 MD 63
(315) 456-7579         | Syracuse, New York 13221

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Anonymous]

<JSA.97May14201336@alexandria><EACHUS.97May23174831@spectre.mitre.org>
<5m57nu$7si@bcrkh13.bnr.ca><5mcp5o$ei7$3@news.cc.ucf.edu>
<5md1fl$9f4@bcrkh13.bnr.ca><5mmvgj$61k@squire.cen.brad.ac.uk>
<JSA.97Jun2174143@alexandria>
<01bc7042$609289e0$cb61e426@DCorbit.solutionsiq.com>
<5n45ou$cio@squire.cen.brad.ac.uk> <01bc7a5b$9ccdd900$21320f9b@mindlin>
<5o7ahj$oos$1@news12.gte.net> <5o9v30$kg0@mtinsc05.worldnet.att.net>
<33A88408.1ECC@flash.net>

On Thu, 19 Jun 1997 08:27:16 -0400, Steve Howard <howard@syr.lmco.com>
wrote:

> Spaceman Spiff wrote:
> [snip]
> > Now what is the airspeed of an unladen swallow?
> 
> African or European?

It doesn't matter. The answer is 42.

Now I just have to get the units right.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spam Hater]

Spaceman Spiff wrote:
> Craig Franck wrote:
> > And in the same vein, what must the initial velocity of a cow being flung
> > from a catapult be in order to achieve orbit?
> 
> 6.92 miles per sec.

But orbit is not good enough.  The cow should jump over the moon.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Spaceman Spiff]

Spam Hater wrote:
> 
> Spaceman Spiff wrote:
> > Craig Franck wrote:
> > > And in the same vein, what must the initial velocity of a cow being flung
> > > from a catapult be in order to achieve orbit?
> >
> > 6.92 miles per sec.
> 
> But orbit is not good enough.  The cow should jump over the moon.

That, sir, it "Udder Lunacy"!!

HA!!!

-Scotty

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[root]

On Fri, 20 Jun 1997 22:02:22 GMT, Spam Hater
<no.such.user@no.such.com> wrote:

>Spaceman Spiff wrote:
>> Craig Franck wrote:
>> > And in the same vein, what must the initial velocity of a cow being flung
>> > from a catapult be in order to achieve orbit?
>> 
>> 6.92 miles per sec.
>
>But orbit is not good enough.  The cow should jump over the moon.

Well, what is the required velocity (magnitude and direction), if said
launch should take place in central Iowa?
>
>-- 
>----------------------------------------------------------------------
>    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
>Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
>                    wwgrol AT pseserv3.fw.hac.com
>
>Don't send advertisements to this domain unless asked!  All disk space
>on fw.hac.com hosts belongs to either Hughes Defense Communications or 
>the United States government.  Using email to store YOUR advertising 
>on them is trespassing!
>----------------------------------------------------------------------

My address is corrupted to reduce spam.  If you can't 
figure out my true address from the corrupted one I 
don't want to receive email from you anyway.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Alicia Carla Longstreet]

Spaceman Spiff wrote:
> 
> Craig Franck wrote:
> > >
> > >Question #2: How does the presence or absence of an observer affect the
> > >falling tree?
> > >Answer: It doesn't make a bit of difference.
> >
> > What if it hits the observer?

That doesn't have much of an impact on the tree, only the stupid
observer.  Of course, according to the Hiesenberg Uncertantity
Principal, the observer either alters the location of the tree or alters
the motion of the tree, depending on whether the observer is measuring
the speed of the tree or determining its location.
 
> ROFL!!
> 
> > When a tree falls in the woods and crushes a deaf-mute, is there a sound?

No. Sound is a cranial occurance.  The motion of the tree produces
compressions and refactions in the atmosphere, it requires and ear and a
certain minium congnitive ability to convert the compressions and
rarefactions into sound.  A deaf mute does not have the requisite ear. 
Of course, almost any animal could be present to make the needed
conversion.
 
> *GISH*

Tha is my Aunts favorite bid at bridge.
 
> > And in the same vein, what must the initial velocity of a cow being flung
> > from a catapult be in order to achieve orbit?
 
> 6.92 miles per sec.
> Now what is the airspeed of an unladen swallow?

The cow would not be able to acheive orbit, but you would have an
interesting phenomona, a meteorite rising from the Earth's surface.  Not
to mention, a very well done roast, somewhere.

-- 
********************************************
* Alicia Carla Longstreet     carla@ici.net
********************************************
Knowledge Sir, should be free.
    Harry Mudd from "I, Mudd"
****************************************
Knowledge is free..., 
but you do have to pay me for my time and effort 
in presenting the knowledge in a manner that 
makes it easier for you to learn.

You are free to reinvent the wheel anytime you please.

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[Stephan Wilms]

Craig Franck wrote:
> 
> "Phil Berman" <madivaan@gte.net> wrote:
> 
> >My response to this question has always been this:
> >Question #1: What does a tree do when it falls and someone IS around to
> >hear it?
> >Answer: It makes a sound.
> >
> >Question #2: How does the presence or absence of an observer affect the
> >falling tree?
> >Answer: It doesn't make a bit of difference.
> 
> What if it hits the observer?

It makes a different sound (more squashy).

> >Conclusion: The tree makes a sound when it falls.
> 
> When a tree falls in the woods and crushes a deaf-mute, is there a sound?

Yes, but it doesn't help him.

> And in the same vein, what must the initial velocity of a cow being flung
> from a catapult be in order to achieve orbit?

0 (Zero) ! A cow on a catapult does not move much. This changes when the
catapult is enganged. And yes, it makes a sound, even if the cow is
deaf.

Stephan

Re: Off topic response to an off topic message--> was:Re: Software Engineering and Dreamers

[David Thornley]

In article <5o9v30$kg0@mtinsc05.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:
>"Phil Berman" <madivaan@gte.net> wrote:
>
>And in the same vein, what must the initial velocity of a cow being flung
>from a catapult be in order to achieve orbit?
>
As somebody pointed out, let's use the velocity of the cow after it's
flung from a catapult, rather than the initial velocity (0, and remains
so until we fire the catapult).

It can't go into Earth orbit without a course correction, since if
it were in an orbit it would return to the last point delta-V
was nonzero, which corresponds to the catapult.  It will likely
have left due to Earth's rotation, but that's still deep in atmosphere.

So, we come up with the following questions:

What's the terminal velocity of an unladen cow?

Will the cow burn up in re-entry?  Or will there be parts only
medium well?

Is this an African or a European cow?

If it burns up on re-entry, wouldn't it also burn up on leaving the
catapult?

What does any of this have to do with comp.lang.c?

David Thornley
(So how about *solar* orbit?)

Re: Software Engineering and Dreamers

[Fritz W Feuerbacher]

Jon S Anthony (jsa@alexandria) wrote:
: In article <5mmvgj$61k@squire.cen.brad.ac.uk> cgrussel@bradford.ac.uk (Vibrating Bum-Faced Goats) writes:

: > Mathematics exists in the mind alone.

This is one of the unanswered questions in mathematics.  Does all the math
already exist only for man to discover it, or man invent the math so it
can exist?

I doubt you'll be answering this very soon.

Re: Software Engineering and Dreamers

[Joe Charlier]

Define Mathematics
Define Mind
Define exists in
Define alone

then let's talk
-- 
	Joe Charlier
	=======================
	Aepryus Software
	http://www.Aepryus.com/

Re: Software Engineering and Dreamers

[S. Norby]

Kaz Kylheku wrote:
> 
> In article <5mcp5o$ei7$3@news.cc.ucf.edu>,
> Fritz W Feuerbacher <fwf27775@pegasus.cc.ucf.edu> wrote:
> >Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
> >
> >: Software is not technology; the stuff that it runs on is technology.
> >
> >So the concept of Software Engineering Technology is not a technology?  I
> 
> The concept of software engineering is flawed to begin with. Engineering is
> the application of physics to produce technology.
> 
> If physics is not involved, you aren't producing technology, nor are you
> doing engineering.
> 
> Examples: writing software is not engineering, and the result is not
> technology, because principles of physics are not required to understand the
> internal semantics of software systems. Designing a pure logic circuit isn't
> engineering either, except when you have to solve implementation problems
> related to heat dissipation, capacitive or inductive coupling and other
> artifacts related to the _technology_.

~~~~~~~~~~~~~
from WWWebster Dictionary:

Main Entry:(1) engineer
Function: noun
Etymology: alter. of earlier enginer, from Middle English, alteration 
  of enginour, from Middle French engigneur, from Old French engignier 
  to contrive, from engin
Date: 14th century
1 : a member of a military group devoted to engineering work
2 obsolete : a crafty schemer : PLOTTER
3 a : a designer or builder of engines b : a person who is trained in 
  or follows as a profession a branch of engineering c : a person who 
  carries through an enterprise by skillful or artful contrivance
4 : a person who runs or supervises an engine or an apparatus 

Main Entry:(2) engineer
Function: transitive verb
Date: 1843
1 : to lay out, construct, or manage as an engineer
2 a : to contrive or plan out usually with more or less subtle skill 
  and craft b : to guide the course of
3 : to modify or produce by genetic engineering <grain crops engineered
  to require fewer nutrients and produce higher yields>

Main Entry: engineering
Function: noun
Date: 1720
1 : the activities or function of an engineer
2 a : the application of science and mathematics by which the 
  properties of matter and the sources of energy in nature are made
  useful to people b : the design and manufacture of complex
  products <software engineering>
3 : calculated manipulation or direction (as of behavior) <social
  engineering> -- compare GENETIC ENGINEERING 

Main Entry: technology
Function: noun
Inflected Form(s): plural -gies
Etymology: Greek technologia systematic treatment of an art, from 
  technE art, skill + -o- + -logia -logy
Date: 1859
1 a : the practical application of knowledge especially in a particular
  area : ENGINEERING 2 <medical technology> b : a capability given by
  the practical application of knowledge <a car's fuel-saving
  technology>
2 : a manner of accomplishing a task especially using technical
  processes, methods, or knowledge <new technologies for information
  storage>
3 : the specialized aspects of a particular field of endeavor
  <educational technology>
- technologist /-jist/ noun 

~~~~~~~~~~~~



-- 
Suzette N.

\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Software Engineering and Dreamers

[Vibrating Bum-Faced Goats]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:

: That's another pet peeve of mine: using ``technology'' with reference to
: software. I've noticed that some hardware manfuacturers have been using the
: term ``hardware technology'' in their marketing propaganda since it's no
: longer understood what the word really means.

: Software is not technology; the stuff that it runs on is technology.

Surely a technology is an abstract label given to a means used to achieve an 
aim:

	Certain building technologies stop bridges from falling down.

	Certain electronic technologies allow communication between
	remote persons.

	Certain software technologies allow given sets of data to be 
	stored and retrieved in an efficient manner.

All seem worthy of the title to me.

--
Chris Russell           | Bradford Bulls - Wembley 1997
Electronic Imaging Unit | 
University of Bradford  | Tough on St.Helens
TEL: +44 1274 385463    | Tough on the causes of St.Helens.

Re: Software Engineering and Dreamers

[Mark Allen Framness]

In message <01bc66fa$ee7910e0$LocalHost@xhv46.dial.pipex.com> - "Nick Roberts"
<Nick.Roberts@dial.pipex.com> writes:
:>


:>These 'dreamers' may never have been practical or realistic. But they
:>invented the science.
:>
:>If someone says "what if...?", it is fine to say "nice idea, but not
:>today", but at the same we should not get into the habit of 'stepping on'
:>those who suggest ideas. I don't suppose Robert was trying to give this
:>impression at all, but I hope nobody wrongly gets this impression. We need
:>our dreamers.

Yeah sure this is all true, but we can not lose fact of the sight that science
is much closer to EVOLUTION rather than REVOLUTION, you do say this but I want
to pull out that salient point.  Scientific revolutions do happen but they are
far and few in betweeen.


Take Care!

postmaster@[127.0.0.1]  
^^^^^^^^^^^^^^^^^^^^^^^^^
Spam booby trap!!!

FROM:  Mark Allen Framness
HOME:  framness@.NO_SPAM.EMIRATES.NET.AE
                           ^^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.
WORK:  m477@NO_SPAM.ugru.uaeu.ac.ae
                     ^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.

HTTP:  http://netnet.net/~farmer/index.html

To send me e-mail use the above address and delete NOSPAM from the one in the
reply field.


All standard disclaimers apply.  Anyone who says likewise is itching for a
fight!
Visit my homepage and answer the Trivial Troubles question!

/************** NOTE NOTE NOTE NOTE NOTE NOTE ***********************/
For a fee of $500.00 I will proofread your unsolicited commercial e-mail.
Mailing me commercial e-mail constitutes acceptance of the above terms.

Re: Software Engineering and Dreamers

[Kaz Kylheku]

In article <5m3ptf$lfp@ns2.emirates.net.ae>,
Mark Allen Framness <framness@NOSPAM.EMIRATES.NET.AE> wrote:
>In message <01bc66fa$ee7910e0$LocalHost@xhv46.dial.pipex.com> - "Nick Roberts"
><Nick.Roberts@dial.pipex.com> writes:
>:>
>
>
>:>These 'dreamers' may never have been practical or realistic. But they
>:>invented the science.
>:>
>:>If someone says "what if...?", it is fine to say "nice idea, but not
>:>today", but at the same we should not get into the habit of 'stepping on'
>:>those who suggest ideas. I don't suppose Robert was trying to give this
>:>impression at all, but I hope nobody wrongly gets this impression. We need
>:>our dreamers.
>
>Yeah sure this is all true, but we can not lose fact of the sight that science
>is much closer to EVOLUTION rather than REVOLUTION, you do say this but I want
>to pull out that salient point.  Scientific revolutions do happen but they are
>far and few in betweeen.

Read much Kuhn? :)

Re: Software Engineering and Dreamers

[Mark Allen Framness]

In message <01bc66fa$ee7910e0$LocalHost@xhv46.dial.pipex.com> - "Nick Roberts"
<Nick.Roberts@dial.pipex.com> writes:
:>


:>These 'dreamers' may never have been practical or realistic. But they
:>invented the science.
:>
:>If someone says "what if...?", it is fine to say "nice idea, but not
:>today", but at the same we should not get into the habit of 'stepping on'
:>those who suggest ideas. I don't suppose Robert was trying to give this
:>impression at all, but I hope nobody wrongly gets this impression. We need
:>our dreamers.

Yeah sure this is all true, but we can not lose fact of the sight that science
is much closer to EVOLUTION rather than REVOLUTION, you do say this but I want
to pull out that salient point.  Scientific revolutions do happen but they are
far and few in betweeen.

In general all scientists are dreamers (the same can not be said about
engineers though).  The very nature of science demands a creative approach to
problems.  Engineering typically is a much more pragmatic discipline.  I
studied math & physics at the University.  I complained to an engineer friend
about all of the canned formulas they use and how if they would just use first
principles they can derive those and would not have to memorize all of that
stuff by rote.  His response was simply:  we do not have the time to do that,
which is true.

Pretty soon I would guess we will see the title "computer science" become a
lot less significant.  Most people will no longer work for a BS in Computer
Science, but in Computer Engineering instead.  Most computer science programs
will become servant programs to the Computer Engineering programs and those
who are studying computer science as an undergraduate plan to work for a MS or
a PhD in computer science.


Take Care!

postmaster@[127.0.0.1]  
^^^^^^^^^^^^^^^^^^^^^^^^^
Spam booby trap!!!

FROM:  Mark Allen Framness
HOME:  framness@.NO_SPAM.EMIRATES.NET.AE
                           ^^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.
WORK:  m477@NO_SPAM.ugru.uaeu.ac.ae
                     ^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.

HTTP:  http://netnet.net/~farmer/index.html

To send me e-mail use the above address and delete NOSPAM from the one in the
reply field.


All standard disclaimers apply.  Anyone who says likewise is itching for a
fight!
Visit my homepage and answer the Trivial Troubles question!

/************** NOTE NOTE NOTE NOTE NOTE NOTE ***********************/
For a fee of $500.00 I will proofread your unsolicited commercial e-mail.
Mailing me commercial e-mail constitutes acceptance of the above terms.

Re: Software Engineering and Dreamers

[Bill Anderson]

Well, as one who spends copious amounts of time in dream states, I must
wholeheartedly agree. Software engineering may forever be a mixture of
art and science, and if true gains are to made, this is as it should be.
Art and science are intertwined to a much greater extent than most
realize, or care to admit.

Just my 2 cents.

Bill Anderson
http://www.nakedhoof.com/

Spam protection - send email to brain@nakedhoof.com

Nick Roberts wrote:
> 
> All (or almost all) the really great leaps forward in computer
> technology
> have come not from great, expensive, laboratories, engaged in highly
> directed (commercially orientated) research, but instead from a motley
> collection of scatter-brained individuals who had _imagination_.
> 
> These 'dreamers' may never have been practical or realistic. But they
> invented the science.
> 
> If someone says "what if...?", it is fine to say "nice idea, but not
> today", but at the same we should not get into the habit of 'stepping
> on'
> those who suggest ideas. I don't suppose Robert was trying to give
> this
> impression at all, but I hope nobody wrongly gets this impression. We
> need
> our dreamers.
> 
> Nick.
> (PS: I get a bit poetic this time of night)

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Jeff Carter]

Robert I. Eachus wrote:
> 
> In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
> 
>   > I would go as far as saying that ``software engineering'' is a hoax.
> 
>     Huh?
> 
>   > Developing a correct program is much more akin to theorem proving than
>   > engineering activity...
> 
>     Ah, programming is not software engineering.  Software engineering
> is all that other stuff which successful projects do that results in
> projects being successful.

[Excellent example deleted.]

I find that programming and software engineering are often confused,
even by those who teach them. Anyone can learn to program, but only
about 2% can become software engineers (in my experience). This is not a
problem in and of itself. But I find that many organizations think that
anyone who can program is qualified to specify requirements, architect
and design software, and so on. That is a problem.

I also find that many organizations expect a new graduate to be able to
do these things "out of the box." The same organizations expect to have
to train new graduate engineers in other disciplines for a year or more
before they can do the equivalent.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply-to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[William M.Gordon]

> I would go as far as saying that ``software engineering'' is a hoax.


I'm what I consider to be a software engineer and I only spend about
10-15% of my time writing software.  The rest of it is to do with
documentation, design, version control, project management, bug reports,
etc etc.   At home though I'm a programmer!

------------------------------
William M. Gordon

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Kaz Kylheku]

In article <3385B67B.1439@msim.co.uk.spamstop>,
William M.Gordon <gordon@msim.co.uk.spamstop> wrote:
>> I would go as far as saying that ``software engineering'' is a hoax.
>
>
>I'm what I consider to be a software engineer and I only spend about
>10-15% of my time writing software.  The rest of it is to do with
>documentation, design, version control, project management, bug reports,
>etc etc.   At home though I'm a programmer!

Hoax is the wrong word, and I must apologize for it. It's rather ``oxymoron'',
not unlike ``computer science''.

There are those who feel that their software development development position
doesn't carry the enough prestige, so they prefer to be called software
engineers. It's no different from ``sanitary engineer'', ``certified Novell
engineer'' etc. It's a facetious title.

I much prefer terms like software developer, software designer: at least these
convey what the job is about. 

I recognize that I don't have a degree in any sort of engineering and certainly
don't belong to an association of professional engineers, hence have no claim
to a ``P. Eng'' title. If I wanted that, I would have studied engineering and
joined the local association, and obtained that iron ring. 

Real engineers _build_ a product, they don't _write_ it. The end products of
real engineering can't be transmitted over data networks nor duplicated ad
nauseum onto magnetic media.

This realization doesn't make me uncomfortable. I accept the inherent validity
and legitimacy of what I do.

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[John Bode]

In article <5m4idq$oc4@bcrkh13.bnr.ca>, kaz@vision.crest.nt.com (Kaz
Kylheku) wrote:

> In article <3385B67B.1439@msim.co.uk.spamstop>,
> William M.Gordon <gordon@msim.co.uk.spamstop> wrote:
> >> I would go as far as saying that ``software engineering'' is a hoax.
> >
> >
> >I'm what I consider to be a software engineer and I only spend about
> >10-15% of my time writing software.  The rest of it is to do with
> >documentation, design, version control, project management, bug reports,
> >etc etc.   At home though I'm a programmer!
> 
> Hoax is the wrong word, and I must apologize for it. It's rather ``oxymoron'',
> not unlike ``computer science''.
> 

I wouldn't call "computer science" an oxymoron -- most of the *theory* is
based on solid mathematical principles.  It's just when we try to write
something useful that we wind up blowing it.

The problem with using the term "software engineering" is that the practice
of programming is still more art than science.  Computer programs are not
like transistors, or gears, or steel I-beams that show up in real-world
engineering.  We're not dealing with physical principles, but with the
codification of thought.  Programming (in its current form) is more
comparable to composing a symphony or writing a novel than building a
bridge or designing a computer chip.  

And I feel it will always be that way.  We can attempt to streamline the
process with OOP, with dynamic languages, with visual programming, but it
is still a codification of thought, and humans do not tend to think
logically.

> There are those who feel that their software development development position
> doesn't carry the enough prestige, so they prefer to be called software
> engineers. It's no different from ``sanitary engineer'', ``certified Novell
> engineer'' etc. It's a facetious title.
> 

Regardless of what title I have (analyst, developer, software engineer), I
am first and formost a programmer, because that is what I actually do.

-- 
John Bode
"Paranoia is just reality on a finer scale" -- Strange Days

To email me directly, remove the 'nospam.' from my address.

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Robert Dewar]

John said

<<I wouldn't call "computer science" an oxymoron -- most of the *theory* is
based on solid mathematical principles.  It's just when we try to write
something useful that we wind up blowing it.>>

Hard to see how anyone could use that word here, I don't see any intended
literary effect in the juxtaposition of the words computer and science. Now
it may be that there is a contradiction in terms, but even there the issue
to me is not whether there is a contradiction in terms but merely whether
CS is indeed a science. My education is in "real" science (all my degrees
are in chemistry), and I must say I don't see much in CS that I would
normally consider to be science, in particular, there seems to be almost
no place for empirical observation and the application of the scientific
method to generate new theories matching current observations. To me CS
is much more similar to classical engineering fields (which of course
are also based on "solid mathematical principles"). 

P.S. yes, I know, some American dictionaries these days allow the usage
of oxymoron to simply mean "contradiction in terms", but it seems a pity
to lose its original meaning!

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Craig Franck]

jfbode@nospam.mail.earthlink.net (John Bode) wrote:

>I wouldn't call "computer science" an oxymoron -- most of the *theory* is
>based on solid mathematical principles.  It's just when we try to write
>something useful that we wind up blowing it.

The book learning part is easy; it is the practical application that 
is difficult. Also, I don't think anyone ever came up with a precise
mathematical definition or representation of "user friendly".

>The problem with using the term "software engineering" is that the practice
>of programming is still more art than science.  Computer programs are not
>like transistors, or gears, or steel I-beams that show up in real-world
>engineering.  We're not dealing with physical principles, but with the
>codification of thought.  Programming (in its current form) is more
>comparable to composing a symphony or writing a novel than building a
>bridge or designing a computer chip.  

Then you would be a "software author" or "instruction composer". You
write software. If you write novels or symphonies, your main goal may
be to communicate something of the human experience. You aren't doing
that with software. The essence of what you compose would be algorith-
matic in nature. (Game programmers may feel different, but designing
a game, and coding it are not the same thing. The person who decides
what artwork should go in a level is not always the person who wrote
the game engine.)

As far as comparing yourself to the person who composed a computer 
chip, I would say your relationship to him would be to evoke behavior
from the chip, and system as a whole. You can pick up a chip, or a 
transistor, and throw it against the wall; you can't pick up "behavior"
and physically throw it. Instead, you're a conjurer, or animator, of 
machines. A sort of re-animator of dead hunks of metal. "With these lines 
of code, I breath life into this creation. Yes! Yes! It's alive! It's
alive!" (Sorry, we just watched "Young Frankenstein"...)

>Regardless of what title I have (analyst, developer, software engineer), I
>am first and formost a programmer, because that is what I actually do.

Which is really a hodgepodge; for example, you must be able to analyze
algorithms and develop a strategy to organize your program, and time
spent programming.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Jon S Anthony]

In article <jfbode-ya023380002305972146180001@news.earthlink.net> jfbode@nospam.mail.earthlink.net (John Bode) writes:

> > Hoax is the wrong word, and I must apologize for it. It's rather ``oxymoron'',
> > not unlike ``computer science''.
> > 
> 
> I wouldn't call "computer science" an oxymoron -- most of the *theory* is

It's an oxymoron because the two words don't fit sensibly together.
Well, that's the point, and IMO, that is pretty accurate in this case.

OTOH, I don't see how "oxymoron" can be plausibly applied to "software
engineering".  Well, maybe as a joke! (i.e., as currenty done, they
don't fit sensibly together).


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering is not a hoax...

[Laurent Gasser]

In article <jfbode-ya023380002305972146180001@news.earthlink.net>, jfbode@nospam.mail.earthlink.net (John Bode) writes:
 
> The problem with using the term "software engineering" is that the practice
> of programming is still more art than science.  Computer programs are not
> like transistors, or gears, or steel I-beams that show up in real-world
> engineering.  We're not dealing with physical principles, but with the
> codification of thought.  Programming (in its current form) is more
> comparable to composing a symphony or writing a novel than building a
> bridge or designing a computer chip.  
> 
> And I feel it will always be that way.  We can attempt to streamline the
> process with OOP, with dynamic languages, with visual programming, but it
> is still a codification of thought, and humans do not tend to think
> logically.
> -- 
> John Bode
> "Paranoia is just reality on a finer scale" -- Strange Days

In the domain of codification of thought, computer scientist have made progress.
In my daily work, I sometimes encounter very old Fortran 77 code, not respecting
the principles of structured programming.  Once, it took me one hour on a 100 LOC
procedure to be sure that they simply were overlapping a IF-THEN block with a 
WHILE-REPEAT block thanks a GOTO.  It looked something like

label_1  CONTINUE
         CALL read_formatted_file(..., istat)
         IF (istat == 0) THEN
           statements
           :
           :
           GOTO label_1
         END IF
         statements

The equivalent code in Ada (or in Fortran 90 in my case) could be

loop
  read_formatted_file(..., istat)
  if (istat /= NoError) then exit; endif;
  statments
  :
  :
end loop


I am pretty sure that in 15 years from now, a programmer looking at code will
immediatly complain if the module is not following the principles of OO or is
not designed as an Abstract Data Type.

Another science (namely mathematics) has been able to codify thinking.  I admit
that production of great works has always been a question of creativity.  But you
rarely see mathematicians fighting against the Aristotelian principles of logic 
(true or false exclusively, no third case; logic of predicates).
-- 
Laurent Gasser (lga@sma.ch)
Computers do not solve problems, they execute solutions.

Re: Software Engineering is not a hoax...

[Kaz Kylheku]

In article <5mc1a2$icf$1@dbs1.sma.ch>, Laurent Gasser <lga@sma.ch> wrote:

>I am pretty sure that in 15 years from now, a programmer looking at code will
>immediatly complain if the module is not following the principles of OO or is
>not designed as an Abstract Data Type.

What? I would complain about that _today_! In fact I did complain recently; in
a letter to Matt Blaze I criticized the implementation of CFS (cryptographic
file system) for having switch() statements branching on the encryption type in
several places instead of having the obvious virtual switch (i.e. table of
structures containing function pointers) with registered encryption drivers.
It's a pain to add a new encryption type, and the inherent assumption that all
cipherblocks are eight bytes wide doesn't exactly help either! :(

Re: Software Engineering is not a hoax...

[Scott Stanchfield]

Laurent Gasser wrote:

> In the domain of codification of thought, computer scientist have made progress.
> In my daily work, I sometimes encounter very old Fortran 77 code, not respecting
> the principles of structured programming.  Once, it took me one hour on a 100 LOC

[snip]

> 
> I am pretty sure that in 15 years from now, a programmer looking at code will
> immediatly complain if the module is not following the principles of OO or is
> not designed as an Abstract Data Type.

I'd say this is more akin to "using acceptable grammar" than applying
engineering techniques.

Think about "Ugh! Me Kronk" versus "Hello, my name is Scott."  Did I
engineer that sentence?  I applied grammatical rules, but I wouldn't say
that it was engineered.

The problem I have with the notion of Software "Engineering" is when
people say software development is just like building cars.
That's just a plain bad analogy.  Think about car production.  Cars do
one thing -- transport.  Sure, some can be more fun than others, some
may be better at towing, some may carry more people, but they are all
basically the same.  The parts used to make them are basically the same.

Car production is basically doing the same thing over and over and over
and over.  Things get a bit better and specialized sometimes, but it's
still building something to do the same task.

I've never written more than one program to do exactly the same task
(unless I'm rewriting it to improve it.)  Each time I sit down to code
something the goal is different.  This, in turn, implies the combination
of parts needed to construct it, and the order in which those parts are
put together is different. (These "parts" I refer to are language
constructs, known algorithms and simple reusable objects like
containers.  Nothing too big, or you're getting into doing the same task
again.) 

Sure, we can use common algorithms and objects such as containers and
math packages.  But the overall product is not something that has been
done before, and therefore, there is no proven, repeatable method to
"engineer" that work.

This leads to my belief that SW development is an art, rather than a
science, and is a highly creative field.  As in painting, for example,
we use common techniques and styles, and we use standard tools.  But
we're not painting the same picture over and over.  We need creative
thought to produce the painting we seek.  The same is true for
programming.

Yes, techniques are useful.  Yes, some pieces can be reused.  (In a
painting, I'd say this relates to the "paint" with which the piece is
composed -- the reusable parts are small, atomic chunks like algorithms
and simple containers.)  But unless you're writing the same program over
and over, and can have a "cookie cutter" or mold to produce the code,
you're not engineering it.   You're creating it.  And that's not a bad
thing.

-- Scott

-- 
Scott Stanchfield
(The opinions expressed herein are not necessarily those of MetaWare)

Re: Software Engineering is not a hoax...

[Kaz Kylheku]

In article <338B2118.41C67EA6@metaware.com>,
Scott Stanchfield  <scotts@metaware.com> wrote:

>> I am pretty sure that in 15 years from now, a programmer looking at code will
>> immediatly complain if the module is not following the principles of OO or is
>> not designed as an Abstract Data Type.
>
>I'd say this is more akin to "using acceptable grammar" than applying
>engineering techniques.

I'd say that it's more, because the technique has a definite impact on the
verifiablity and maintainability of the program. Abstract data types and OO
are more than just mere terms. I would agree with that they aren't
_engineering_ techniques.

>Think about "Ugh! Me Kronk" versus "Hello, my name is Scott."  Did I
>engineer that sentence?  I applied grammatical rules, but I wouldn't say
>that it was engineered.

I see what you are getting at. Since a program is an utterance in a programming
language, it's not a product of engineering but of abstract symbol
manipulation. Good point!

>The problem I have with the notion of Software "Engineering" is when
>people say software development is just like building cars.
>That's just a plain bad analogy.  Think about car production.  Cars do
>one thing -- transport.  Sure, some can be more fun than others, some
>may be better at towing, some may carry more people, but they are all
>basically the same.  The parts used to make them are basically the same.

But we can have reusable components. Different models of car are similar in the
same kinds of ways as two different red-black tree implementations.  Their
parts are not interchangeable, yet they are basically the same.

I would not go as far as saying that there are no useful similarities between
engineering and software development, or that some of the rigorous techniques
in engineering can be applied to software, in particular, the technique of
formal verification. In engineering, designs are verified. For example, a truss
will undergo analysis in which the tensile or compressive stresses in each
member are determined under given load conditions. Nobody will build the bridge
without having done such an analysis. To apply this principle of verification
to software, every component of a software project should be formally verified
for correctness. 

>Car production is basically doing the same thing over and over and over
>and over.  Things get a bit better and specialized sometimes, but it's
>still building something to do the same task.
>
>I've never written more than one program to do exactly the same task
>(unless I'm rewriting it to improve it.)  Each time I sit down to code
>something the goal is different.  This, in turn, implies the combination
>of parts needed to construct it, and the order in which those parts are
>put together is different. (These "parts" I refer to are language
>constructs, known algorithms and simple reusable objects like
>containers.  Nothing too big, or you're getting into doing the same task
>again.) 
>
>Sure, we can use common algorithms and objects such as containers and
>math packages.  But the overall product is not something that has been
>done before, and therefore, there is no proven, repeatable method to
>"engineer" that work.

Then again, many engineering designs are also unique. Think of unique
structures in the world: dams, buildings, bridges and so on.  There are proven,
repeatable ways to locally verify the designs, one component at a time.
E.g. there are methods to analyze any truss network to see whether it will
hold up, but you can still be very creative in designing the truss.
In engineering, the creativity is checked by applying laws derived
from natural science. <insert some Robert Pirsig quote here about motorcycle
gears having buddha nature :) >

Re: Software Engineering is not a hoax...

[Scott Stanchfield]

Kaz Kylheku wrote:
> 
> In article <338B2118.41C67EA6@metaware.com>,
> Scott Stanchfield  <scotts@metaware.com> wrote:
> 
> 
> >Think about "Ugh! Me Kronk" versus "Hello, my name is Scott."  Did I
> >engineer that sentence?  I applied grammatical rules, but I wouldn't say
> >that it was engineered.
> 
> I see what you are getting at. Since a program is an utterance in a programming
> language, it's not a product of engineering but of abstract symbol
> manipulation. Good point!
Thank you!

> 
> >The problem I have with the notion of Software "Engineering" is when
> >people say software development is just like building cars.
> >That's just a plain bad analogy.  Think about car production.  Cars do
> >one thing -- transport.  Sure, some can be more fun than others, some
> >may be better at towing, some may carry more people, but they are all
> >basically the same.  The parts used to make them are basically the same.
> 
> But we can have reusable components. Different models of car are similar in the
> same kinds of ways as two different red-black tree implementations.  Their
> parts are not interchangeable, yet they are basically the same.
> 
> I would not go as far as saying that there are no useful similarities between
> engineering and software development, or that some of the rigorous techniques
> in engineering can be applied to software, in particular, the technique of
> formal verification. In engineering, designs are verified. For example, a truss
> will undergo analysis in which the tensile or compressive stresses in each
> member are determined under given load conditions. Nobody will build the bridge
> without having done such an analysis. To apply this principle of verification
> to software, every component of a software project should be formally verified
> for correctness.

Guess my point got missed here.
In cars, common parts are assembled in pretty much the same manner for
any given car.  Testing a car is similar from car to car.
Same domain for each "overall" test.  (Car testers -- please do not be
offended -- I'm not saying your job is simple...)

(How did we move into testing?)

In programming, each new program presents a different domain.  In order
to test, you have to think in that domain and create new tests within
it.  Sure, there are similarities, but no "checklist" that says what
things to think of when testing a car.

(I also believe it has been proven that program correctness is, in
general, unprovable.  There are simple subsets that can be proven
correct, but as program size grows, the probability of proving
correctness diminishes.)



[snip re I don't write the same thing twice]
> 
> Then again, many engineering designs are also unique. Think of unique
> structures in the world: dams, buildings, bridges and so on.  There are proven,
> repeatable ways to locally verify the designs, one component at a time.
> E.g. there are methods to analyze any truss network to see whether it will
> hold up, but you can still be very creative in designing the truss.
> In engineering, the creativity is checked by applying laws derived
> from natural science. <insert some Robert Pirsig quote here about motorcycle
> gears having buddha nature :) >
Again, unsure how we got into testing, but...
From what I recall of my Naval-Architect roomie's ramblings on
structural analysis, I think it's somehow related to physics ;)
Science vs. art, and ya know where I stand...

Anyway, certain parts of programs can be tested with common program
testing techniques, just as certain parts of programs implement common
algorithms and data structures.  But, I think that developing the proper
test for a propgram is just as unique as writing the program to begin
with.  It's a matter of figuring out the right combinations of common
tests and new tests to get the "warm fuzzies" or, better still, complete
confidence in the correct operation of a program.  (In that respect,
verification of design of some structures is a creative process as
well.)  Think about geometric theorem proving.  You have a set of
"knowns" and an "unknown."  You have to think out the correct
combination of "knowns" to prove your unknown.  No engineering technique
can tell you how to combine them, though you can learn useful patters
that can help get the job done.

(This is the most intellgent discussion of this topic that I've heard in
a while -- very interesting...)
-- Scott


-- 
Scott Stanchfield
MetaWare Incorporated
Santa Cruz, CA
(The opinions expressed herein are not necessarily those of MetaWare)

Re: Software Engineering is not a hoax...

[Dean Runzel]

I'm picking up this thread very late but I'd like to join in with a
few simple ideas:

1) Engineering is basically the application of techniques to solve
   problems. One of my EE instructors (long, long ago) said we would
   be lucky to ever actually use something we learned in college
   in a real world situation. Instead, he insisted that the school's
   primary role was to teach problem solving techniques i.e. breaking
   a problem down, combining techniques, etc.
2) Given the above, Electrical Engineering becomes the practice of 
   applying techniques to solve problems involving electricity, 
   Automotive Engineering => problems in the automotive field, etc.
3) For example, several years ago, no one studied air bags in an 
   Automotive Engineering class because they simply didn't exist. Some
   engineers were tasked with solving a safety problem and invented the
   air bag as the solution.
4) So basically my definition of "engineering" includes things like 
   problem statement, requirements, research, brainstorming, designing
   a solution, implementation, testing and cycling back through the 
   process. 
5) Reuse enters this process at the requirements stage (yes, even 
   requirements can be reused) and continues through at least the
   testing phase.
6) Now, note that my definition makes no reference to hardware, physics,
   or any particular science. Engineering is a *process*.
7) As such, software engineering is a valid term if and only if a 
   process is followed to solve a problem related to software.

That's the simplest explanation I can come up with. Note that I've 
worked in Mechanical Engineering, Electrical Engineering, Electro-
Optical Engineering, and now Software Engineering in my career. 

The opinions expressed are my own and belong to no one else.

Dean Runzel

Re: Software Engineering is not a hoax...

[Scott Stanchfield]

Dean Runzel wrote:
> 
> I'm picking up this thread very late but I'd like to join in with a
> few simple ideas:
> 
> 1) Engineering is basically the application of techniques to solve
>    problems. One of my EE instructors (long, long ago) said we would
>    be lucky to ever actually use something we learned in college
>    in a real world situation. Instead, he insisted that the school's
>    primary role was to teach problem solving techniques i.e. breaking
>    a problem down, combining techniques, etc.
An enlightened fellow, I must say...  That's the kind of teaching we
need!

RE the rest of your note: I guess the whole "engineering" issue depends
of the definition of engineering.

By your definitions, I would tend to agree that SW Engineering is a
"valid" term.  The problem is that by the same definition, one could
call a certain field of art "Painting Engineering."  (Applying
techniques to solve problems involving painted pictures.)

I think there's a "line" somewhere between art and science, albeit a
very fuzzy and very thick one.  They say that half the brain is
"logical" while the other half is "creative."  I get the feeling that
neither half is ever really "asleep."

SW Development (as I refer to it) involves several creative processes. 
But it also involves several logical processes as well.  It's a good
mix.

But like I said in an earlier post, I think the problem comes when
people characterize it like a field that clearly falls on the
"mechanical production" side of the line.  What I mean here is the
assembly-line analogy that "we have parts we just plop them together."
Personally I don't think SW development can ever become that.

And if it did I know I'd be looking for another line of work...

- Scott

-- 
Scott Stanchfield
MetaWare Incorporated
Santa Cruz, CA
(The opinions expressed herein are not necessarily those of MetaWare)

Re: Software Engineering is not a hoax...

[Kaz Kylheku]

In article <338D1244.6324@mail.mco.bellsouth.net>,
Dean Runzel  <drunzel@mail.mco.bellsouth.net> wrote:
>I'm picking up this thread very late but I'd like to join in with a
>few simple ideas:
>
>1) Engineering is basically the application of techniques to solve
>   problems. One of my EE instructors (long, long ago) said we would
>   be lucky to ever actually use something we learned in college
>   in a real world situation. Instead, he insisted that the school's
>   primary role was to teach problem solving techniques i.e. breaking
 >   a problem down, combining techniques, etc.

I think that this technology(1) is getting to be too long drawn out and
pointless, and has to cease.

--
(1) To be clear, by technology I mean ``discourse on an art or arts'', rather
than the other definition: ``scientific study of the practical or industrial
arts''.

Re: Software Engineering is not a hoax...

[Robert Dewar]

Kaz says

<<I think that this technology(1) is getting to be too long drawn out and
pointless, and has to cease.>>

Since you are the one who is doing the long-drawn-out'ing, it is certainly
simple for you to make it cease :-)

Re: Software Engineering is not a hoax...

[John G. Volan]

Robert Dewar wrote:
> 
> Kaz says
> 
> <<I think that this technology(1) is getting to be too long drawn out and
> pointless, and has to cease.>>
> 
> Since you are the one who is doing the long-drawn-out'ing, it is certainly
> simple for you to make it cease :-)

Yes, please. And this is coming from someone who's not allergic to
chewing a topic up thoroughly (when it is _warranted_). Watching this
thread, I've been mystified as to what, if anything, it has to do with
either Ada, C, or C++ (the newsgroups it's been cross-posted to).  The
participants in this discussion have demonstrated that there is an
abundant supply of cerebral power available to be tapped out there, but
could we please redirect the sheer torque of this mental dynamo back to
leveraging the _technology_ in question here: [insert your favorite
language]? :-) Thank you.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Software Engineering is not a hoax...

[Lord Shaman]

--------------0C14BC5F91EC4D83173BC443
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ah yes, I remember engineering at high school...

Day one, teacher enters the classroom and writes the following on the
board:

  1. If it looks right, it is right.
  2. If it doesn't look right, fudge it until it does.
  3. Remember that this will be assembled by an ape, so make it simple
     to put together.

Ah.. those were the days.

--------------0C14BC5F91EC4D83173BC443
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Ah yes, I remember engineering at high school...

<P>Day one, teacher enters the classroom and writes the following on the
board:
<OL>
<LI>
If it looks right, it is right.</LI>

<LI>
If it doesn't look right, fudge it until it does.</LI>

<LI>
Remember that this will be assembled by an ape, so make it simple to put
together.</LI>
</OL>
Ah.. those were the days.</HTML>

--------------0C14BC5F91EC4D83173BC443--

Re: Software Engineering is not a hoax...

[Dan Evens]

Scott Stanchfield wrote:
> I've never written more than one program to do exactly the same task
> (unless I'm rewriting it to improve it.)  Each time I sit down to code
> something the goal is different. 

Hrm.  Have you never solved the same *kind* of problem twice?
Automobiles don't all go *exactly* the same place twice. Never
set up a searchable index twice? Never set up a database twice?
Never made a linked list twice? And so on.

> Sure, we can use common algorithms and objects such as containers and
> math packages.  But the overall product is not something that has been
> done before, and therefore, there is no proven, repeatable method to
> "engineer" that work.

There are certainly subtasks which appear repeatedly in recognizably
identical fashion. This is why books like _Design Patterns_ by
Gamma et al. are useful and instructive books to read. The "one off"
mind set is clearly counter productive most of the time.

-- 
Standard disclaimers apply.
I don't buy from people who advertise by e-mail.
I don't buy from their ISPs.
Dan Evens

Re: Software Engineering is not a hoax...

[Scott Stanchfield]

Dan Evens wrote:
> 
> Scott Stanchfield wrote:
> > I've never written more than one program to do exactly the same task
> > (unless I'm rewriting it to improve it.)  Each time I sit down to code
> > something the goal is different.
> 
> Hrm.  Have you never solved the same *kind* of problem twice?
> Automobiles don't all go *exactly* the same place twice. Never
> set up a searchable index twice? Never set up a database twice?
> Never made a linked list twice? And so on.
Sure -- those are the small algorithms and containers to which I refer. 
These are the pieces that can be reused, but they're small compared to
the overall program.

When I say I don't code the same thing twice, I overall product.  I
don't write several C++ compilers, or several database manglement
engines...

> 
> > Sure, we can use common algorithms and objects such as containers and
> > math packages.  But the overall product is not something that has been
> > done before, and therefore, there is no proven, repeatable method to
> > "engineer" that work.
> 
> There are certainly subtasks which appear repeatedly in recognizably
> identical fashion. This is why books like _Design Patterns_ by
> Gamma et al. are useful and instructive books to read. The "one off"
> mind set is clearly counter productive most of the time.
Ahh, but "Design Patterns" are stylistic issues, not solutions to
problems.  They are very effective (I use them frequently, nice book!)
but they don't tell me what code to write to create a word processor. 
They give me good tools to arm myself to the task.  (Think of them as
better paint brushes...)

Don't get me wrong -- I think we learn good techniques from books and
past experience, but I don't think this makes our programs
"engineered."  Just like an artist who learns new techniques, our works
become more and more attractive.

-- Scott

-- 
Scott Stanchfield
(The opinions expressed herein are not necessarily those of MetaWare)

Re: Software Engineering is not a hoax...

[Alan Bowler]

In article <5mc1a2$icf$1@dbs1.sma.ch> lga@sma.ch writes:
>
>Another science (namely mathematics) has been able to codify thinking.  I admit
>that production of great works has always been a question of creativity.  But you
>rarely see mathematicians fighting against the Aristotelian principles of logic 
>(true or false exclusively, no third case; logic of predicates).

Maybe.  My first year calculus prof refused to cover the proof of the
chain rule.  He accepted the chain rule, but did not feel the standard
proof was valid, and felt we did not have sufficient background to
handle the proof he accepted.  My 4th year logic prof mentioned some
disagreements he had with other schools of logicians.
I think the reason that you don't see "mathematicians fighting against
the Aristotelian principles" is that they don't consider them
"principles", rather, like the chain rule case, they are rules derived
from more basic principles, and they do fight over what those are.

Re: Software Engineering is not a hoax...

[Jon S Anthony]

In article <EAwIwE.1LC@thinkage.on.ca> atbowler@thinkage.on.ca (Alan Bowler) writes:

> In article <5mc1a2$icf$1@dbs1.sma.ch> lga@sma.ch writes:
> >
> >Another science (namely mathematics) has been able to codify thinking.  I admit
> >that production of great works has always been a question of creativity.  But you
> >rarely see mathematicians fighting against the Aristotelian principles of logic 
> >(true or false exclusively, no third case; logic of predicates).
> 
> Maybe.  My first year calculus prof refused to cover the proof of the
> chain rule.  He accepted the chain rule, but did not feel the standard
> proof was valid

"Standard" here refers to the typical way it is handled in first year
calculus.  I wouldn't say it is not valid - rather more like
incomplete, and so, some say, misleading (which is probably why your
prof. didn't want to say much about it).


> , and felt we did not have sufficient background to handle the proof
> he accepted.

Unless you were/are a Ramanujan or something, he is quite right.  You
need quite a bit more advanced analysis or topology beyond first
semester Calculus to get there.


> My 4th year logic prof mentioned some
> disagreements he had with other schools of logicians.

> I think the reason that you don't see "mathematicians fighting against
> the Aristotelian principles"

Actually, IMO "Aristotelian principles of logic" are in general
irrelevant to mathematical logicians.  Those principles are naive and
don't have the necessary rigor to offer much.  Of course, what
expressivity they have has been easily and much more precisely
captured.


> from more basic principles, and they do fight over what those are.

Indeed.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Robert I. Eachus]

In article <5m4idq$oc4@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > ...Real engineers _build_ a product, they don't _write_ it.

   Agreed.

 > The end products of real engineering can't be transmitted over data
 > networks nor duplicated ad nauseum onto magnetic media.

   Disagree.  Even electrical, mechanical, and civil engineers produce
end products that can be transmitted over networks and duplicated ad
nauseum.  This is because the end product of the engineering effort is
the design, not the actual product.  For example an EE might design a
new chip, test prototypes, then send the design to Taiwan for
production.

   And I am working on a new philosophy/approach for software
engineering which does realize that the "end product" is not the
exectuable code.  The end product includes the source code,
documentation, scripts, make files, test plan, test code, test
results, etc.  All the pieces that are needed to build the executable,
and will be reused in the next build and the one after that.  If I can
"push a button" to build a release, then I haven't built a release, I
have built a release building machine, which is a much more useful
thing.

--

					Robert I. Eachus

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

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Jon S Anthony]

In article <EACHUS.97May23172550@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <5m4idq$oc4@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
> 
>   > ...Real engineers _build_ a product, they don't _write_ it.
> 
>    Agreed.

Actually, I don't think I agree.  Real engineers typically do not
_build_ what they _design_.  And this latter bit is very often
"writing" of some sort (including sketches, calcualtions, and even CAD
excursions).  Someone else typically ends up building the thing (this
is quite true for prototypes and such as much as for the end mfg
result).


> nauseum.  This is because the end product of the engineering effort is
> the design, not the actual product.

Hey, that's what I just said - so how come you agreed up there??


> exectuable code.  The end product includes the source code,
> documentation, scripts, make files, test plan, test code, test
> results, etc.

Isn't this similar (or even basically the same as) the "reuse whole
product" scheme??

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[W. Wesley Groleau (Wes)]

Kaz Kylheku wrote:
> There are those who feel that their software development development position
> doesn't carry the enough prestige, so they prefer to be called software
> engineers. ..... It's a facetious title.

It's true that some "software engineers" are falsely so-called,
either by themselves or others.
And many "real" software engineers sometimes engage in "mere
programming"  Those facts don't deny either activity "prestige".
(Nor is "prestige" worth anything in the grand scheme of things.)

> Real engineers _build_ a product, they don't _write_ it. 

Now you're drifting a little wide.  A lot of Civil Engineers,
Mechanical Engineers, Electrical Engineers, etc. specify and 
design _things_ that are actually built by "skilled trades".  
Explain how that is qualitatively different from specifying
and designing _behaviour_ that is performed by computers.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Not A Real Engineer (Kaz said so)                  Tool-smith Wanna-be

Send me your advertisements!  I'll proofread and return them for only
$50.00 (US) per hundred words (plus a small fee per correction). For
full details, use a subject line of "Re: Proofreading Offer" on a
message of less than ten lines.
----------------------------------------------------------------------

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Fritz W Feuerbacher]

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:

: I much prefer terms like software developer, software designer: at least these
: convey what the job is about. 

I prefer to be called a Software Engineer.  I worked my ass off getting my
dregree and I feel I am an engineer of software.

: Real engineers _build_ a product, they don't _write_ it. The end products of
: real engineering can't be transmitted over data networks nor duplicated ad
: nauseum onto magnetic media.

Computer Engineers are the ones that designed that network or floppy drive
to enable the copying of data.

: This realization doesn't make me uncomfortable. I accept the inherent validity
: and legitimacy of what I do.

The words are a method of differentiating a professional position.  We
could all call ourselves hackers but most of our customers would tend to
look elsewhere.

Re: Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[Robert Dewar]

William said

<<I'm what I consider to be a software engineer and I only spend about
10-15% of my time writing software.  The rest of it is to do with
documentation, design, version control, project management, bug reports,
etc etc.   At home though I'm a programmer!>>

I can only understand this if you replace "writing software" with
"coding". To me documentation, design, version control, project management,
bug reports etc etc are an *integral part* of what writing software is
all about.

Re: Software Engineering is not a hoax...

[Keith Shillington]

Ahem.  Amen.  Agreed.

In fact, I'd swing out onto the thin ice on the skinny branches and say
that to "code" more than that breeches the boundaries between software
engineering and, well, let's not mince terms here, hacking.  And, home is a
great place to hack.  I don't want to knock hacking.  I love to hack. 
There's something wonderful about tinkering, like writing HTML in VI; like
counting the number of clock cycles in a loop to see if some blindingly
fast operation can be made faster; not because it needs to be, but because
it can be.  This, on the other hand, tends to be inappropriate in an
environment where the software you (I, we) are writing ultimately will wind
up on someone elses plate to be maintained.

Robert Dewar pontificated:
| William said:
| 
| <<I'm what I consider to be a software engineer and I only spend about
| 10-15% of my time writing software.  The rest of it is to do with
| documentation, design, version control, project management, bug reports,
| etc etc.   At home though I'm a programmer!>>
| 
| I can only understand this if you replace "writing software" with
| "coding". To me documentation, design, version control, project
management,
| bug reports etc etc are an *integral part* of what writing software is
| all about.

Re: Software Engineering is not a hoax...

[Kaz Kylheku]

In article <01bc7746$c7475c50$fc00af88@godiva>,
Keith Shillington <keith@sd.aonix.com> wrote:
>Ahem.  Amen.  Agreed.
>
>In fact, I'd swing out onto the thin ice on the skinny branches and say
>that to "code" more than that breeches the boundaries between software
>engineering and, well, let's not mince terms here, hacking.  And, home is a
>great place to hack.  I don't want to knock hacking.  I love to hack. 
>There's something wonderful about tinkering, like writing HTML in VI; like
>counting the number of clock cycles in a loop to see if some blindingly
>fast operation can be made faster; not because it needs to be, but because
>it can be.  This, on the other hand, tends to be inappropriate in an
>environment where the software you (I, we) are writing ultimately will wind
>up on someone elses plate to be maintained.
>
>Robert Dewar pontificated:
>| William said:
>| 
>| <<I'm what I consider to be a software engineer and I only spend about
>| 10-15% of my time writing software.  The rest of it is to do with
>| documentation, design, version control, project management, bug reports,
>| etc etc.   At home though I'm a programmer!>>
>| 
>| I can only understand this if you replace "writing software" with
>| "coding". To me documentation, design, version control, project
>management,
>| bug reports etc etc are an *integral part* of what writing software is
>| all about.

I disagree that things like project management are the integral characteristic
of engineering. Does this mean that without managers, engineering would not
be possible? ;)

Here is an interesting little quote from the writing of one Robert Baber:

	I should emphasize at this poitn that by `software engineering' I mean
    an approach to the preparation for, and practice of, our vocation which
    engineers in other fields would recognize as exhibiting basic
    characteristics typical of their fields. Some of the topics subsumed today
    under the term `software engineering' do not satisfy this criterion.
    Systematizing work in a restricted technical sense, using well-honed tools,
    applying management principles (e.g. relating to project management) to the
    organization of our work, etc., useful as these may be, do not represent
    the essence of engineering  and are not sufficient to transform our
    occupation into a professional engineering field. Among other things,
    practitioners must acquire and apply to their work an extensive knowledge
    based on a thorough undrstanding of fundamental, immutable principles of a
    mathematical and theoretical nature and of lasting validity, and they must
    be willing to accept responsibility for the correctness of their designs.
    [_The Spine of Software: Designing Provably Correct Software: Theory and
    Practice_, Baber, Robert Laurence, John Wiley & Sons Ltd, 1987, P. 14]

Re: Software Engineering is not a hoax...

[brucemo]

Keith Shillington wrote:

> There's something wonderful about tinkering, like writing HTML in VI; like
> counting the number of clock cycles in a loop to see if some blindingly
> fast operation can be made faster; not because it needs to be, but because
> it can be.

This latter case is not just bad software engineering, it is bad hacking :-)

bruce

Re: Software Engineering is not a hoax...

[Richard Turner]

brucemo wrote ...
> Keith Shillington wrote:
> 
> > There's something wonderful about tinkering, like writing HTML in VI;
like
> > counting the number of clock cycles in a loop to see if some blindingly
> > fast operation can be made faster; not because it needs to be, but
because
> > it can be.
> 
> This latter case is not just bad software engineering, it is bad hacking
:-)

"Bad"? What's bad about it? If it's bad, what moral principle does it
offend?

Re: Software Engineering is not a hoax...

[Spam Hater]

> > > There's something wonderful about tinkering, like ...
> > > counting the number of clock cycles in a loop to see if some 
> > > fast operation can be made faster; ...
> >
> > This latter case is not just bad software engineering, it is bad hacking
> 
> "Bad"? What's bad about it? If it's bad, what moral principle does it
> offend?

OK, how about "waste of time and money" ?  OTOH, as Robert Dewar 
pointed out, fanatic adherence to "rules" can be counter-productive.
If your program spends 98% of its time inside that loop, and it
is not meeting its timing requirements, ....

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Software Engineering is not a hoax...

[Richard Turner]

Spam Hater wrote ...
> OK, how about "waste of time and money" ?  OTOH, as Robert Dewar 
> pointed out, fanatic adherence to "rules" can be counter-productive.
> If your program spends 98% of its time inside that loop, and it
> is not meeting its timing requirements, ....

But "waste" is at best relative to something else.

Bumming instructions out of a loop might be a waste today but might yield
some saving (of time or money or both) tomorrow.

Re: Software Engineering is not a hoax...

[Ralph Silverman]

con.com> <3385B67B.1439@msim.co.uk.spamstop> <dewar.864448217@merv> <01bc7746$c7475c50$fc00af88@godiva>
Organization: SEFLIN Free-Net - Broward
Distribution: 

Keith Shillington (keith@sd.aonix.com) wrote:
: Ahem.  Amen.  Agreed.

: In fact, I'd swing out onto the thin ice on the skinny branches and say
: that to "code" more than that breeches the boundaries between software
: engineering and, well, let's not mince terms here, hacking.  And, home is a
: great place to hack.  I don't want to knock hacking.  I love to hack. 
: There's something wonderful about tinkering, like writing HTML in VI; like
: counting the number of clock cycles in a loop to see if some blindingly
: fast operation can be made faster; not because it needs to be, but because
: it can be.  This, on the other hand, tends to be inappropriate in an
: environment where the software you (I, we) are writing ultimately will wind
: up on someone elses plate to be maintained.

: Robert Dewar pontificated:
: | William said:
: | 
: | <<I'm what I consider to be a software engineer and I only spend about
: | 10-15% of my time writing software.  The rest of it is to do with
: | documentation, design, version control, project management, bug reports,
: | etc etc.   At home though I'm a programmer!>>
: | 
: | I can only understand this if you replace "writing software" with
: | "coding". To me documentation, design, version control, project
: management,
: | bug reports etc etc are an *integral part* of what writing software is
: | all about.


	what is
		hacking
	:
	just
		software engineering
	without a license
	?

--

Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Software Engineering is not a hoax...

[Michael Tippach]

Ralph Silverman wrote:
[...]
 
>         what is
>                 hacking
>         :
>         just
>                 software engineering
>         without a license
>         ?

Still wondering what sort of grass he's smoking.

Regards
Wuschel

Re: Software Engineering is not a hoax...

[Paul Mesken]

>
>
>	what is
>		hacking
>	:
>	just
>		software engineering
>	without a license
>	?
Darn! You need a *LICENSE* for programming?

  "I _know_ what partial register stalls are but I
   want my compiler to know it as well!"

  usurper@euronet.nl Paul Mesken aka Technocrate 

Re: Any research putting c above ada?

[Jon S Anthony]

In article <yvsd8qm4isl.fsf@merganser.cl.cam.ac.uk> Michael Norrish <mn200@cl.cam.ac.uk> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > > Where else is the theory of communicating processes (things like CSP
> > > and CCS by Hoare and Milner respectively) going to live except in
> > > computer science?
>  
> > Engineering again.  Other than how this works in actual software
> > systems, who cares?
> 
> Theoretical computer scientists, that's who.  Show me an engineering
> department that cares in the slightest about the pi calculus.  I, on

Well, if they had a widely recognized software engineering discipline,
then this would not be an issue.  I'm not saying you can just drop CS
and not replace it with something and then try to get the relevant
bits and bobs from EEs and CEs and such.

> Theoretical computer science is perhaps even a branch of mathematics,
> but that doesn't mean maths departments do it.  

Well, yes, this is similar to what I've said.  A chunk of so called CS
is really some bit of mathematics.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Les Hazlewood]

I've just spent a very disappointing 20 mins trying to find any research
that puts C above Ada in this thread. Looking at the last dozen or so
posts I couldn't find *any research* on *any topic* !!!

Could someone tell me why posters don't start new threads when what they
have to say has nothing (or at the most charitable, very little) to do
with the current tread title?

Les Hazlewood

Re: Any research putting c above ada?

[Jason A Cunningham]

Les Hazlewood (hazlewlj@aston.ac.uk) wrote:
: Could someone tell me why posters don't start new threads when what they
: have to say has nothing (or at the most charitable, very little) to do
: with the current tread title?

Topic drift is sort of a tradition in this newsgroup.

----------
Jason Cunningham
cunningh@cs.ucdavis.edu

Re: Any research putting c above ada?

[Stephan Wilms]

Jason A Cunningham wrote:
> 
> Les Hazlewood (hazlewlj@aston.ac.uk) wrote:
> : Could someone tell me why posters don't start new threads when what they
> : have to say has nothing (or at the most charitable, very little) to do
> : with the current tread title?
> 
> Topic drift is sort of a tradition in this newsgroup.

Ehem, *what* newsgroup ?

Stephan
[posting from c.l.c]

Re: Any research putting c above ada?

[Jason A Cunningham]

Stephan Wilms (Stephan.Wilms@CWA.de) wrote:
: Jason A Cunningham wrote:
: > 
: > Les Hazlewood (hazlewlj@aston.ac.uk) wrote:
: > : Could someone tell me why posters don't start new threads when what they
: > : have to say has nothing (or at the most charitable, very little) to do
: > : with the current tread title?
: > 
: > Topic drift is sort of a tradition in this newsgroup.
: 
: Ehem, *what* newsgroup ?
: 
: Stephan
: [posting from c.l.c]

I forgot that I was posting to more than one group.  I meant comp.lang.c,
although I see this sort of thing in almost all newsgroups.

----------
Jason Cunningham
cunningh@cs.ucdavis.edu

Newsthread integrity

[Nick Roberts]

Les Hazlewood <hazlewlj@aston.ac.uk> wrote in article
<hazlewlj-2005971331020001@ljh-14.aston.ac.uk>...
> I've just spent a very disappointing 20 mins trying to find any research
> that puts C above Ada in this thread. Looking at the last dozen or so
> posts I couldn't find *any research* on *any topic* !!!
> 
> Could someone tell me why posters don't start new threads when what they
> have to say has nothing (or at the most charitable, very little) to do
> with the current tread title?


Usenet seems to be a highly flammable zone. Always has done. It may, I
suppose, be something to do with the (apparent) anonymity of the medium
exciting more outspoken responses than would come from people in other
circumstances. Doubtless this phenomenon will be the subject of numerous
theses in the future ;-)

Of course, one suggestion is that if a respondent changes the subject, they
should change the subject line. Ne ce pas?

Nick.

Re: Any research putting c above ada?

[T Wheeley]

On 15 May 1997, Jon S Anthony wrote:

> > > > "We're teaching Computer Science here.  If you want engineering, go to
> > > > an engineering school."  That's the prevailing attitude with many of the
> > > > CompSci programs at small liberal arts colleges.  They teach the
> > > > "science" of programming almost as a subfield of Mathematics.  The
> > > 
> > > This is actually very apropos to the problem.  Most of what passes as
> > > so called "computer science" is just watered down mathematics -
> > > discrete mathematics (asymptotic algorithm analysis is fundamentally
> > > various techniques of counting, i.e., a bit of combinatorics) and some
> > > bits of formal logics (which is where the oft mentioned "halting
> > > problem" and such comes from.)  Take this away and you don't have much
> > > left - unless you have the _application_ of that mathematics, i.e.,
> > > software engineering.
> > > 
> > > Well, there is the AI camp, but there too, if you look at what much of
> > > this is, it's being/been covered by philosophers and CogScis (and
> > > often with rather more perspicacity).
> > 
> > Well then let's not bother teaching computer science at all!  Why not just
> 
> Sounds like a good idea to me.

So how do you intend teaching people to use computers then?  Through
osmosis?  Or do you think that computer science is like car mechanics --
bit of experience and you've got it.  After all, we don't need car
mechanics degrees as that'd just be physics and mechanical and electronic
engineering, wouldn't it?

Then again, maybe there's a bit more to computer science; maybe all the
people who design cars went to university to study mechanical and
electronic and even chemical engineering.

> Incorrect analogies.  These are all sciences which have their own core
> subject which is well delineated.  The fact that they borrow from
> ideas in other related sciences is irrelevant.  The point is that CS
> has no such core subject area - _all_ it has is borrowed and then
> watered down from other disciplines.

Of course it is!  CS didn't exist 50 years agao; it had to come from
somewhere -- namely maths and electronics.  All the early computer
scientists were either mathematicians, elec engineers or both.  It is a
developing field, and I would say the core subject area is programming and
algorithm design.  Algorithms are like mechanical parts -- designedby
specialists in that area, with the *aid* of mathematics, not as a part of
maths.

> > The fact is that a CS degree combines all these factors into a single
> > degree related to the study of computers, and puts them in the correct
> > context.
> 
> This would be the start of something that made sense if the core
> subject was _engineering software artifacts_.
> 
> 
> > Yes the idea of dominance in sequences is part of computer science,
> > but they way I was taught it in maths is not particularly relvant to
> > the complexity of algorithms.
> 
> This sounds irrelevant.  _Counting_ is the core of complexity analysis
> and that is a part of Combinatorics.  _Applying_ the various relevant
> results of Combinatorics to _engineering_ problems in software is
> perfectly sensible.  Attempting to dream up new ways of counting or
> more sophisticated ways, or ways that handle new situations or
> whatever is Combinatorics - not CS.

You are repeating what I was saying.  Engineering degrees present Calculus
in the correct manner for Engineering, and so Computer Science presents
Combinatorics in the relevant manner for alg analysis.

> > Unless you have a very good understanding of the principles behind
> > the maths in a maths degree, it will take you a lot of experience to
> > become a good programmer (e.g. Knuth)
> 
> I seriously doubt this (as it is written).  As an example, exactly how
> does understanding the ideas behind the proof of Quadratic Reciprocity
> help you in "programming"??  How does an understanding of the topology

Most people doing a maths degree, especially in the early stages, will not
know the principles well enough to extend them to and Ada program, for
example.  We are taught these things as how it is done, but thinking up
`how it is done' is difficult.

> of the linear continuum needed to understand a proof of the FTC help
> you in "programming"?  As far as that goes, how does a understanding
> of the notions underlying FTC help?  Schroder-Bernstein theorem?  No
> other engineering discipline needs this sort of understanding.  Heck,
> no other _science_ needs this level of understanding.

Your name-dropping is very impressive.  I am truly humbled.

> > Of course there is a strong element of theory in CS degrees -- they want
> > to get good research students to boost the department's standing against
> > other universities, but you would have to have a poor department or be a
> > poor student if you didn't pick up some of the fundamentals of good
> > software design.
> 
> I think you just crossed over into Jay Martin flamage land - prepare
> to be blow torched! :-)

I will stand by that paragraph as being self-evident.

:sb)

Re: Any research putting c above ada?

[Jon S Anthony]

In article <Pine.SGI.3.95L.970516131141.17326B-100000@tower.york.ac.uk> T Wheeley <tw104@york.ac.uk> writes:

> > > Well then let's not bother teaching computer science at all!  Why not just
> > 
> > Sounds like a good idea to me.
> 
> So how do you intend teaching people to use computers then?  Through

Assuming by "use" you mean "program", the answer is simple: this stuff
is covered by the engineering discipline for constructing software
artifacts (systems, libraries, whatever).


> osmosis?  Or do you think that computer science is like car mechanics --

No, as I've repeatedly pointed out, I think the non-redundant bits are
like engineering.


> bit of experience and you've got it.  After all, we don't need car
> mechanics degrees as that'd just be physics and mechanical and electronic
> engineering, wouldn't it?

Wrong analogy.  I suppose, for car mechanics, you would need to
substitute "programmer" or some such.  Someone who clearly knows
what's going on, but not at the level of the engineer.


> > Incorrect analogies.  These are all sciences which have their own core
> > subject which is well delineated.  The fact that they borrow from
> > ideas in other related sciences is irrelevant.  The point is that CS
> > has no such core subject area - _all_ it has is borrowed and then
> > watered down from other disciplines.
> 
> Of course it is!  CS didn't exist 50 years agao; it had to come from
> somewhere -- namely maths and electronics.  All the early computer

What's that have to do with it?  Back in 1953 or so, Aeronautics
didn't exist 50 years ago.  But just because they found they really
could make use of differential equations and discrete analysis and
such didn't make them run off thinking they should be developing the
_theory_ of this stuff.  No, they used the results in the new
engineering discipline.


> scientists were either mathematicians, elec engineers or both.  It is a
> developing field, and I would say the core subject area is programming and
> algorithm design.  Algorithms are like mechanical parts -- designedby
> specialists in that area, with the *aid* of mathematics, not as a part of
> maths.

Hmmm, maybe this is part of the disagreement.  I don't see algorithms
like mechanical parts at all.  I see them as much more like basic
results in DiffEq or discrete analysis.  First, they can be used
completely outside programming or computers at all.  So, they clearly
have no dependence on these things.  Algorithm invention, construction
and such has always been, and will always be, a part of mathematics
(of particular relevance here is discrete mathemantics).  So, what
really is the point of saying: hey CS wants to do that too!  Second,
in programming, they are _used_ in the _design_ of the analog of
mechanical parts: components or some such.


> > > The fact is that a CS degree combines all these factors into a single
> > > degree related to the study of computers, and puts them in the correct
> > > context.
> > 
> > This would be the start of something that made sense if the core
> > subject was _engineering software artifacts_.
> > 
> > 
> > > Yes the idea of dominance in sequences is part of computer science,
> > > but they way I was taught it in maths is not particularly relvant to
> > > the complexity of algorithms.
> > 
> > This sounds irrelevant.  _Counting_ is the core of complexity analysis
> > and that is a part of Combinatorics.  _Applying_ the various relevant
> > results of Combinatorics to _engineering_ problems in software is
> > perfectly sensible.  Attempting to dream up new ways of counting or
> > more sophisticated ways, or ways that handle new situations or
> > whatever is Combinatorics - not CS.
> 
> You are repeating what I was saying.  Engineering degrees present Calculus
> in the correct manner for Engineering, and so Computer Science presents
> Combinatorics in the relevant manner for alg analysis.

Perhaps we are in more agreement than not.  Maybe we are even in
"violent agreement" and the only problem is that we are just using
different terms to refer to the same thing.  I guess, the only point
left, would be, well then, why not just say CS is really a branch of
engineering, put it in the engineering school, and treat it as such.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5le6vf$15p@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >> Well then let's not bother teaching computer science at all!  Why not just
> >
> >Sounds like a good idea to me.
> 
> Yeah, why don't we just burn those computer science texts, too!

OK, :-)


> >This would be the start of something that made sense if the core
> >subject was _engineering software artifacts_.
> 
> This anti-intellectual claptrap romanticizing is getting rather tiresome.

I'm unclear on why you think this is "anti-intellectual".  It's simply
getting your tasks better and more clearly organized.  So what if
there is no "science" per se' associated with computers?  Why should
this bother you?  Why is this a big issue?  And why is engineering
somehow "anti-intellectual"???  You think you can just go touchy-feely
when engineering an aircraft wing?  Or the combustion chamber head in
an ICE??  Or a throttlable rocket engine???? or ...  Come on - your
credibility just dropped to zero.


> Heck, I propose that we do away with learning all together. We

Well this is very odd.  I think it is pretty clear that I have a high
belief in the value of learning and apprpriate and highly rigorous and
formal disciplines.  For crying out loud - my formal background is in
theoretical mathematics.  I've merely pointed out that CS is largely
redundant (at best) with several other disciplines.


> should instead hold retreats in the woods to get in touch with those
> engineers inside of us that are just yearning to be set free!  Only
> then will we develop better software, in the most natural way.

Very interesting.  This really does seem to indicate that you don't
think engineering disciplines have any value.  That they are all just
a bunch of "new age" touchy feely rubbish.  And if CS became an
engineering discipline it would apparently become:

Anti-intellectual

A hodge-podge of simple minded, non-formal, non-rigorous rubbish

A place for artsy-fartsy types.


Wow.  Definitely odd...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[tmoran]

In <JSA.97May2135942@alexandria> Jon S Anthony said:
>Why was the "record" bit even there?  It's not a big deal, but IMO the
>"record" part even is rather misleading - tagged things are very
>different in all sorts of ways from regular old record types and
  It's interesting then that in Java there is *no* "regular old record
type" - only what Ada would call a tagged type.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5kftur$lua@lotho.delphi.com> tmoran@bix.com writes:

> In <JSA.97May2135942@alexandria> Jon S Anthony said:
> >Why was the "record" bit even there?  It's not a big deal, but IMO the
> >"record" part even is rather misleading - tagged things are very
> >different in all sorts of ways from regular old record types and
>
>   It's interesting then that in Java there is *no* "regular old record
> type" - only what Ada would call a tagged type.

That's true, but I don't understand the relevance...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

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

Al Christians <achrist@EASYSTREET.COM> writes:
>BTW, I've heard something about a new set of Ada development tools
>coming from
>Lockheed for 32-bit Windows development.   Does anyone have any info on
>what's coming, when, what it will cost, and if it's going to be any
>good?
>
    Lockheed? When did Lockheed get into the Windows/Ada development
    tool business? (Other than internal tool building that we all
    pretty much engage in.) I'd be interested in knowing what they're
    making generally available to the public out of their IR&D in
    software tools.

    BTW: More on topic... My understanding of Microsoft Compiler
    Economics is that they pretty much give them away at a tremendous
    loss in order to get people developing software for their OS -
    which is where the *real* money is at. (We do similar stuff with
    jet engines - the money is in the spare parts & maintenance.)
    Hence, someone who is selling an Ada compiler and expecting to
    make a buck at it is going to have a hard time competing with
    Micro$oft.

    Still, the price of Ada compilers is down at a semi-reasonable
    level where an average individual or small business can easily
    afford to get into it. (And there's always Gnat - which is a very
    solid tool - if a little bare-bones in the GUI-building business.)
    The Comp-USA arguement only proves what's selling the most, not
    what's good or what's usable for a given task. I personally have
    bought some pretty terrible compilers from mass-market software
    chains and discovered that they wouldn't do my job...

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
West Palm Beach, FL                             Internet:   CONDICMA@PWFL.COM
===============================================================================
    Glendower: "I can call spirits from the vasty deep."
    Hotspur: "Why so can I, or so can any man; but will they come when
    you do call for them?"

        -- Shakespeare, "Henry IV"
===============================================================================

Re: Any research putting c above ada?

[tmoran]

In <u912rj925.fsf@kastle.com> Richard Krehbiel said:
>Here's a bit of research you can do yourself.
>
>Can you go to the computer store and buy Microsoft Visual Ada 5.0?
>Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
>compiler at the local Comp USA store?  No.
  To which the obvious response is: Can you skip going to the computer
store and instead simply download for free Microsoft or Borland or
Watcom's C or C++ for PCs (DOS, Windows, or OS/2) and various Unix's?
(see ftp cs.nyu.edu pub/gnat)
  But hopefully not too many *professionals* decide on their tools
based on what Home Depot or Comp USA or Microsoft is pushing today.

Re: Any research putting c above ada?

[Richard Krehbiel]

tmoran@bix.com writes:

> In <u912rj925.fsf@kastle.com> Richard Krehbiel said:
> >Here's a bit of research you can do yourself.
> >
> >Can you go to the computer store and buy Microsoft Visual Ada 5.0?
> >Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
> >compiler at the local Comp USA store?  No.
>   To which the obvious response is: Can you skip going to the computer
> store and instead simply download for free Microsoft or Borland or
> Watcom's C or C++ for PCs (DOS, Windows, or OS/2) and various Unix's?
> (see ftp cs.nyu.edu pub/gnat)

Yes, I know about GNU Ada.

I don't mean to disparage Ada as a language in any way.  When I get
the time, I'd love to learn it and do some tinkering.  There is
apparently a lot to admire about the language, and it may well be the
better language.  It's too bad getting into the language is as
difficult as it is.  I'd really welcome Borland Turbo Ada myself.

>   But hopefully not too many *professionals* decide on their tools
> based on what Home Depot or Comp USA or Microsoft is pushing today.

In fact many professionals must look at what's being "pushed"
("pulled" really; the market demands C and C++ more than it does Ada,
and vendors are responding to demand) and choose tools with better
support, wider availability, and larger experience base.

-- 
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
rich@kastle.com (work) or richk@mnsinc.com (personal)

Any research putting c above ada?

[Konstantin B. Goldin]

Hello,

Is there any research out there, that, comparing c and ada, (or c++ and
ada), gives advantage to the c side? 

This is very important for my school work, so far everything proves that ada
is better.

Please e-mail me, I am not a frequent visitor to this group.

P.S. the comparison has to be done by some one (or some org) with
respectfull name.

Thank you

Re: Any research putting c above ada?

[Matthew Heaney]

In article <5ih6i9$oct$1@waldorf.csc.calpoly.edu>,
kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) wrote:

>Hello,
>
>Is there any research out there, that, comparing c and ada, (or c++ and
>ada), gives advantage to the c side? 
>
>This is very important for my school work, so far everything proves that ada
>is better.

Well, you should quantify what you mean by "better," but yes, Ada _is_ a
better language.

I know of one paper that gives only lukewarm support for Ada's cost
effectiveness.  Don Reifer, a consultant and former AJPO head, published
data demonstrating that Ada and C/C++ are all better than 3GL's, but his
data doesn't show that Ada (83) is any more cost effective than C and C++. 
His paper is online at:

<http://www.stsc.hill.af.mil/crosstalk/1996/jul/quantify.html>
<mailto:d.reifer@ieee.org>

He did state, however, that Ada does hold a cost advantage in airborne and
spaceborne avionics, and that the jury was still out on Ada 95 because of
the newness of the standard.  (I can state from my personal experience,
though, that Ada 95 is a most bitchin' language.  Finally, we have silenced
the silly debates about Ada not being "truly" object-oriented.)

Steve Zeigler of Rational did a fascinating study that showed Ada was
clearly more cost effective than C:
 
<http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html>

John McCormick is a SUNY professor who teaches a real-time programming
class.  When he switched from teaching the class in C to teaching it in
Ada, a significantly greater number of teams were able to complete the
projects:

<http://www.acm.org/sigada/news/suny.html>

These papers present _facts_ and _data_.  Be cautious of rock-throwing
programmers who dismiss Ada by citing specious
can't-buy-a-compiler-at-CompUSA arguments, and who haven't actually _tried_
Ada.  These poor souls just don't _get_ it, and prefer to spend their time
programming instead of constructing working systems.

Visit the ammunition link at the Home of the Brave Ada Programmers for
lot's more examples that demonstrate Ada's efficacy.

<http://www.adahome.com/Ammo/>

Ada simply allows the software engineer to practice software engineering. 
If you are not a software engineer, then of course Ada won't help you.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Any research putting c above ada?

[Bob Stout]

I think there was some work published by a fellow name Nudds... <g&d>

-------------------------------------------------------------
MicroFirm: Down to the C in chips...
FidoNet 1:106/2000.6
Internet rbs@snippets.org
Home of SNIPPETS - Current release:
      ftp://snippets.org/pub/snippets/snip9611.zip & snip9611.taz (.tar.Z)
      http://www.snippets.org/ 
      juge.com:/c/snip9611.lzh
      PDN nodes (SNIP9611.RAR) and SimTel mirror sites

Re: Any research putting c above ada?

[Thomas Aho]

I saw an investigation on Rationals site the ohter day, where they
compared C and ADA.

Check out http://www.rational.com

	/Thomas

Re: Any research putting c above ada?

[Richard Krehbiel]

kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:

> Hello,
> 
> Is there any research out there, that, comparing c and ada, (or c++ and
> ada), gives advantage to the c side? 

Here's a bit of research you can do yourself.

Can you go to the computer store and buy Microsoft Visual Ada 5.0?
Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
compiler at the local Comp USA store?  No.

-- 
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
rich@kastle.com (work) or richk@mnsinc.com (personal)

Re: Any research putting c above ada?

[Philip Brashear]

In article <u912rj925.fsf@kastle.com>,
Richard Krehbiel  <rich@kastle.com> wrote:
>kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:
>
>> Hello,
>> 
>> Is there any research out there, that, comparing c and ada, (or c++ and
>> ada), gives advantage to the c side? 
>
>Here's a bit of research you can do yourself.
>
>Can you go to the computer store and buy Microsoft Visual Ada 5.0?
>Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
>compiler at the local Comp USA store?  No.


Of course, you can't find a Bentley or Rolls at a Hyundai dealership,
either.  Does this prove anything?

Konstantin, the big advantage Ada has over these C dialects and Java
thingies and Visual Basics is that it was designed to make large 
software systems easier to get right -- not necessarily easier to
get on the market, but easier to GET RIGHT.  There IS a language
standard (which is not the case for C++, Java, or Visual Basic),
there ARE certification procedures for Ada compilers, and Ada compilers
help the programmer avoid certain common errors.

As an example, look at the current Communications of the ACM. There's an
article on "bugs" that cites a few examples.  Two-thirds of the examples
would have been prevented by any certified Ada compiler.  Interestingly,
the author seemed to assume that all software was written in C or one of
its derivatives.  His point wasn't that we needed help in avoiding these
bugs, but help in locating them after they've been created.  The whole
special issue part of this issue talks about the disgraceful state of
debuggers, as if these common bugs are unavoidable and must always be
found AFTER the fact.

Don't listen to the argument that Ada loses because it's not popular.
It's arguably the best language for producing software that works
right.

Phil Brashear
CTA INCORPORATED
On my way to EDS
and
Adjunct faculty member at the University of Dayton (which uses Ada as its
core CS language)

None of these organizations take any responsibility for my opinions, nor
I theirs.

Re: Any research putting c above ada?

[CubanPete]

On 10 Apr 1997 14:20:08 -0400, brashear@ns1.sw-eng.falls-church.va.us
(Philip Brashear) wrote:


>
>Don't listen to the argument that Ada loses because it's not popular.
>It's arguably the best language for producing software that works
>right.
>
>Phil Brashear
>CTA INCORPORATED
>On my way to EDS

Come on now Phil.  There is no language that produces software that
works "more right" than another.  Software is either right or it is
not.   Ada may have a great debugger but VMS types will argue all day
about how much better the debuger is on the VAX but I dont see tons of
UNIX folks in VMS classes.

The only reason Ada still exists at all is that someone pushed the
pentagon brass a few years back and convinced the military that it was
such a good thing, and that ada was the wave of the future.   I've
seen just as buggy code come from ada programmers as I have from
fortran programmers.  C programmers of course dont write buggy code 
-ever-


>and
>Adjunct faculty member at the University of Dayton (which uses Ada as its
>core CS language)
>

Adjunct means that your not qualified to be hired full time?? 

Re: Any research putting c above ada?

[John Thomas Apa]

CubanPete <haggedk1@ulysses.jhuapl.edu> wrote in article
<334d3da5.14386594@aplcen.apl.jhu.edu>...
> On 10 Apr 1997 14:20:08 -0400, brashear@ns1.sw-eng.falls-church.va.us
> (Philip Brashear) wrote:
> 
> 
> >
> >Don't listen to the argument that Ada loses because it's not popular.
> >It's arguably the best language for producing software that works
> >right.
> >
> >Phil Brashear
> >CTA INCORPORATED
> >On my way to EDS
> 
> Come on now Phil.  There is no language that produces software that
> works "more right" than another.  Software is either right or it is
> not.   Ada may have a great debugger but VMS types will argue all day
> about how much better the debuger is on the VAX but I dont see tons of
> UNIX folks in VMS classes.
> 
> The only reason Ada still exists at all is that someone pushed the
> pentagon brass a few years back and convinced the military that it was
> such a good thing, and that ada was the wave of the future.   I've
> seen just as buggy code come from ada programmers as I have from
> fortran programmers.  C programmers of course dont write buggy code 
> -ever-

And if you believe that I think you miss your ride on the space ship!

One of Rational's VP did a study on c vs Ada a few years ago. They produce
IDEs for both languages so don't claim they have a vested intrest one way
or the other. It showed that _good_ engineers can write good code on
anything. However when it came to software that had to be maintained and
reliable Ada won hands down. That was c vs Ada83, if you have bothered to
keep abreast of the technology you would know how much better Ada95 is than
Ada83 and about anything else I've seem. I've done C, fortran, ada, asm,
and a few other languages on many platforms. I've researched Ada95 and
found that it provides a wealth of features to help my design remain robust
and maintainable. I don't have to fight the language to get the design
architecture that I want. Plus with gnat (validated and wonderful) it's
cheap, can you say free? I knew you could.

Enough said.

> 
> 
> >and
> >Adjunct faculty member at the University of Dayton (which uses Ada as
its
> >core CS language)
> >
> 
> Adjunct means that your not qualified to be hired full time?? 
> 

Re: Any research putting c above ada?

[Tom Wheeley]

In article <u912rj925.fsf@kastle.com> rich@kastle.com "Richard Krehbiel" writes:

> kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:
> 
> > Hello,
> > 
> > Is there any research out there, that, comparing c and ada, (or c++ and
> > ada), gives advantage to the c side? 
> 
> Here's a bit of research you can do yourself.
> 
> Can you go to the computer store and buy Microsoft Visual Ada 5.0?
> Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
> compiler at the local Comp USA store?  No.

Although I want to stay neutral in this discussion, the above argument is the
most facile I have seen for quite some time.

Can you buy `gcc' in CompUSA?  I should think that for a lot of people,
`gcc' vs. `gnat' would be a better comparison.  (even though they are really
more similar than you might think :-)

--
:sb)

Re: Any research putting c above ada?

[Richard Kenner]

In article <860706551snz@tsys.demon.co.uk> tw104@york.ac.uk writes:
>Can you buy `gcc' in CompUSA?

Sure.  It's part of every Linux system sold.

Re: Any research putting c above ada?

[Daniel P Hudson]

clines@airmail.net (Kevin Cline) wrote:
>tomw@tsys.demon.co.uk (Tom Wheeley) wrote:


>>Can you buy `gcc' in CompUSA?  I should think that for a lot of people,
>>`gcc' vs. `gnat' would be a better comparison.  (even though they are really
>>more similar than you might think :-)

>No, g++ vs. gnat would be fairer.

gcc is now a C and C++ compiler, the g++ program merely calls gcc
with the C++ specific parameters needed.

Re: Any research putting c above ada?

[Stephen Leake]

Daniel P Hudson wrote:
> 
> clines@airmail.net (Kevin Cline) wrote:
> >tomw@tsys.demon.co.uk (Tom Wheeley) wrote:
> 
> >>Can you buy `gcc' in CompUSA?  I should think that for a lot of people,
> >>`gcc' vs. `gnat' would be a better comparison.  (even though they are really
> >>more similar than you might think :-)
> 
> >No, g++ vs. gnat would be fairer.
> 
> gcc is now a C and C++ compiler, the g++ program merely calls gcc
> with the C++ specific parameters needed.

By that argument, with GNAT installed, gcc is a C and C++ and Ada
compiler!
-- 
- Stephe

Re: Any research putting c above ada?

[Andrew Dunstan]

Richard Krehbiel (rich@kastle.com) wrote:
: kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:

: > Hello,
: > 
: > Is there any research out there, that, comparing c and ada, (or c++ and
: > ada), gives advantage to the c side? 

: Here's a bit of research you can do yourself.

: Can you go to the computer store and buy Microsoft Visual Ada 5.0?
: Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
: compiler at the local Comp USA store?  No.

What a facile argument. (Of course, I don't _have_ a local Comp USA
store here in aus :-) In fact, I have seen the Walnut Creek Ada CD,
including the superb Gnat compiler, in stores even here. And you can
go out on your local internet and get Gnat FREE. Check out
http://www.gnat.com/ 

I can't get a Rolls Royce at my local car dealer, but that doesn't
make it worse than the Ford product :-)

By all means let us debate merits, but not on this sort of ridiculous
basis. In fact, people on comp.lang.ada are a bit tired of this sort
of debate ... it is usually fruitless and generated more heat than
light.  

cheers

andrew 

--

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

Re: Any research putting c above ada?

[James Youngman]

In article <u912rj925.fsf@kastle.com>, rich@kastle.com says...
>
>kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:
>
>> Hello,
>> 
>> Is there any research out there, that, comparing c and ada, (or c++ and
>> ada), gives advantage to the c side? 
>
>Here's a bit of research you can do yourself.
>
>Can you go to the computer store and buy Microsoft Visual Ada 5.0?
>Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
>compiler at the local Comp USA store?  No.

And Richard Krehbiel thinks that this means that C is better than Ada in what 
way exactly?   CompUSA pushers will say anything to justify their religion.


( :-) for those who haven't had their first cup of coffee of the day yet )
-- 
James Youngman       VG Gas Analysis Systems  The trouble with the rat-race 
Before sending advertising material, read     is, even if you win, you're 
http://www.law.cornell.edu/uscode/47/227.html         still a rat.

Re: Any research putting c above ada?

[Steve Summit]

In article <5il225$8e3$9@halon.vggas.com>, JYoungman@vggas.com
(James Youngman) writes:
>In article <u912rj925.fsf@kastle.com>, rich@kastle.com says...
>>kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:
>>> Is there any research out there, that, comparing c and ada, (or c++ and
>>> ada), gives advantage to the c side? 
>>
>> Here's a bit of research you can do yourself.
>> Can you go to the computer store and buy Microsoft Visual Ada 5.0?
>> Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
>> compiler at the local Comp USA store?  No.
> 
> And Richard Krehbiel thinks that this means that C is better than Ada
> in what way exactly?   CompUSA pushers will say anything to justify
> their religion.

Grin.

Seriously, though (and this is probably so obvious I don't even
need to post it), the can-you-buy-it-at-your-local-computer-
"super"store test proves nothing.  Or if anything (and bear in
mind when I say this that I'm about as big a C pusher as they
come) it proves that Ada is superior.  Where can you get the
better kitchen tools or appliances, at K-mart or at a big-city
downtown restaurant supply?  Where can you get the better hand
and power tools, at the local cheapie hardware store or at Sears
or at an equipment wholesaler deep in the heart of the industrial
district that only the tradesmen know about?  (Hey, Crafstman
tools are good, but if you want a good Milwaukee 1/2 inch drill,
or one of their insane sawzalls, you're probably not going to
find it at Sears.  If only I had hundreds of dollars to blow on
power tools...)

I'm always pleasantly surprised to see a C compiler in a computer
store, or a C book in a general bookstore, but I wouldn't blame
either of these stores for not carrying C titles (let alone Ada),
because they're not exactly mass-market.

					Steve Summit
					scs@eskimo.com

Re: Any research putting c above ada?

[Dave Wood]

Steve Summit wrote:
> 
> I'm always pleasantly surprised to see a C compiler in a computer
> store, or a C book in a general bookstore, but I wouldn't blame
> either of these stores for not carrying C titles (let alone Ada),
> because they're not exactly mass-market.

Indeed, CompUSA and their ilk will carry *anything* so long
as the supplier is willing to be extorted into buying
shelf space away from products from Microsoft and other
quasi-monopolies.  

Ada suppliers know that their marketing and distribution 
dollars are better spent on direct sales channels, because, 
as Mr. Summit correctly points out, compilers aren't exactly 
mass market items.  Can you imagine trying to get serious 
technical information from some CompUSA drone?  Selling a 
sophisticated development environment to real engineers with
complex needs and questions is a different beast from selling 
Reader Rabbit or TurboTax.

In fact, while retail megastores are likely to carry some
C compilers, they're much less likely to carry some of 
the subsidiary tools you will want in your arsenal, like
CM tools, object modeling tools, and (for C/C++ anyway)
tools to help you track down the sources of trashed
memory.  As such, you most likely need to go to a more
direct channel anyway to get what you really need, or at
least to a specialty mail order source (who again, can't
answer tough questions.)

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Any research putting c above ada?

[Chris Lomont]

On Sat, 12 Apr 1997, Dave Wood wrote:

> Steve Summit wrote:
> > 
> > I'm always pleasantly surprised to see a C compiler in a computer
> > store, or a C book in a general bookstore, but I wouldn't blame
> > either of these stores for not carrying C titles (let alone Ada),
> > because they're not exactly mass-market.
> 
> Indeed, CompUSA and their ilk will carry *anything* so long
> as the supplier is willing to be extorted into buying
> shelf space away from products from Microsoft and other
> quasi-monopolies.  
> 

Where does this nonsense idea come from? Most retail stores stock what 
sells, whether it's from Microsoft or from HomeBoys Software. Why would 
CompUSA care where the product comes from, if it sells? Can you state any 
facts along these lines?

Chris Lomont

Re: Any research putting c above ada?

[Dave Wood]

Chris Lomont wrote:
> 
> On Sat, 12 Apr 1997, Dave Wood wrote:
> 
> > Steve Summit wrote:
> > >
> > > I'm always pleasantly surprised to see a C compiler in a computer
> > > store, or a C book in a general bookstore, but I wouldn't blame
> > > either of these stores for not carrying C titles (let alone Ada),
> > > because they're not exactly mass-market.
> >
> > Indeed, CompUSA and their ilk will carry *anything* so long
> > as the supplier is willing to be extorted into buying
> > shelf space away from products from Microsoft and other
> > quasi-monopolies.
> >
> 
> Where does this nonsense idea come from? Most retail stores stock what
> sells, whether it's from Microsoft or from HomeBoys Software. Why would
> CompUSA care where the product comes from, if it sells? Can you state any
> facts along these lines?

Have you tried doing it then?  It would be interesting for you
to share the experience.

In fact, retail shelf space is quite limited, even at the local
grocery store.  You might ask Mom 'n Pop Cola how easy it is to
take space away from Coke and Pepsi.

Interesting theory, that they stock what sells.  They also sell
what they stock.  Which is your chicken, and which your egg?  How
do you think that someone new or different convinces the retailer
to give up the shelf space held by an incumbant?  If your guess
is that this involves something green, you're getting warm.  Unless
your product is truly mass market, you'd better think long and hard
about this gambit (unless of course your name is Gates, in which
case the shelf space is a lock.)

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Any research putting c above ada?

[Steve Jones - JON]

haggedk1@ulysses.jhuapl.edu (CubanPete) writes:

[snip]
> Come on now Phil.  There is no language that produces software that
> works "more right" than another.  Software is either right or it is
> not.   Ada may have a great debugger but VMS types will argue all day
> about how much better the debuger is on the VAX but I dont see tons of
> UNIX folks in VMS classes.
On my last project we use C and Ada, the bug count in the Ada code was
over 1/3 that of the C code. And tracking down bugs in Ada is much easier,
the code falls over it tells you the brief reason (eg constraint error) and
the line at which the error was raised and the stack trace.  You can then add
exception handlers et al to secure the system. It provides in built range
checking and strong typing.

In C assigning to an unitialised pointer will cause either a crash or
wild behaviour and never tell you, in Ada it will crash and tell you why.
In Ada you can restrict the user from assigning between incompatible types,
you can data hide etc etc.

The bug count and cost of Ada is much less than that of C, just because some
of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?) cannot
be done in Ada.  Both Ada and C can produce correct programs but IME it is
easier to do in Ada, the same would go for Eiffel v C++, a HLL v a MLL presents
similar advantages to a MLL over a LLL.

I know C, I know Ada and various languages besides, if I was writting a quick
check or hack I'd use C, if writting a large system I'd use Ada.  The advantage
of Ada isn't in the debugger but in the compiler, eg

C:
typedef int cleared_flight_level;
typedef int airspeed;

airspeed a = 4;
cleared_flight_level cfl = 5;

...

cfl = a;

...

This is a silly example as why would anyone _want_ to do it.  But Ada would
prevent you ever doing it.  It is here that the power comes in, with tools
like generics and a proper tasking model, decent hardware access is included
and data protection, all of these things make it harder to mess up, and easier
to check, if the range of an enumeration in C is changed a switch statement
will not care if the new value is not included, in Ada the compiler will fail
the code.

C is popular, it is quick and dirty, but I wouldn't like to trust my life to
it.

[snip]
-- 
|Un Loup en France  | Bully deification Party. One Party, one issue.     |
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song----------|
|----The above opinions rarely reflect my own and never my employers'----|
|Do not add me to mailing lists violations will be billed for time.      |

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <2senchydgk.fsf@hpodid2.eurocontrol.fr>,
Steve Jones - JON  <jon@hpodid2.eurocontrol.fr> wrote:

>On my last project we use C and Ada, the bug count in the Ada code was
>over 1/3 that of the C code. And tracking down bugs in Ada is much easier,
>the code falls over it tells you the brief reason (eg constraint error) and
>the line at which the error was raised and the stack trace.  You can then add
>exception handlers et al to secure the system. It provides in built range
>checking and strong typing.
>
>In C assigning to an unitialised pointer will cause either a crash or
>wild behaviour and never tell you, in Ada it will crash and tell you why.

Decent C compilers will diagnose when you have used an unitialized variable
rather than crashing at run time.

>In Ada you can restrict the user from assigning between incompatible types,
>you can data hide etc etc.

This is true of C as well. Assigning between incompatible types is a constraint
violation which *requires* a diagnostic. It's all in ISO 9899:1990.

>The bug count and cost of Ada is much less than that of C, just because some
>of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?) cannot

I believe it, but you are not describing the actual advantages of Ada over C.

>be done in Ada.  Both Ada and C can produce correct programs but IME it is
>easier to do in Ada, the same would go for Eiffel v C++, a HLL v a MLL presents
>similar advantages to a MLL over a LLL.

I would say that the same would also go for Eiffel v. Ada. Compared to Eiffel,
Ada is still a cryptic, implementation-oriented high level assembler
like C, Pascal, Modula, et al. 

>I know C, I know Ada and various languages besides, if I was writting a quick
>check or hack I'd use C, if writting a large system I'd use Ada.  The advantage
>of Ada isn't in the debugger but in the compiler, eg
>
>C:
>typedef int cleared_flight_level;
>typedef int airspeed;
>
>airspeed a = 4;
>cleared_flight_level cfl = 5;
>
>...
>
>cfl = a;

What is your point here? The two types here are compatible. You have only
created an alias name for int. In other words, C has structural equivalence
for types (other than structs).

Why don't you see a type violation in the very declarations? 

It could easily be said that

    a = 4;

is a type violation. After all, 4 is an integer, and a is an airspeed. A
decent, safe language would require a special conversion operator to be done on
the 4 to construct an airspeed from an integer. Does Ada require that?

In C you can do this:

    typedef struct airspeed { int i } airspeed;
    typedef struct cleared_flight_level { int i } cleared_flight_level;

There you go. The two are no longer assignment compatible with each other or
with the int type. You can still assign an airspeed to an other airspeed, and
pass it in and out of functions by value. The .i operation converts
an airspeed to an int.



>...
>
>This is a silly example as why would anyone _want_ to do it.  But Ada would
>prevent you ever doing it.  It is here that the power comes in, with tools
>like generics and a proper tasking model, decent hardware access is included
>and data protection, all of these things make it harder to mess up, and easier
>to check, if the range of an enumeration in C is changed a switch statement
>will not care if the new value is not included, in Ada the compiler will fail
>the code.

Ada may have the advantage that this is required behavior. But a quality C
compiler (such as the GNU C compiler) will warn you if one or more of the
members of an enumeration are not mentioned in the switch statement. 

Where C messes up is in those types of errors that _cannot_ be diagnosed
or cannot be diagnosed easily.  Other than that, a C implementation can be
retrofitted with all kinds of diagnostics that are not required by the
language. True, this lack of a requirement is a disadvantage, but it's
not a major obstacle.

>C is popular, it is quick and dirty, but I wouldn't like to trust my life to
>it.

I wouldn't trust my life to any computer system, especially if it had ``Intel
inside''. There are too many things that can go wrong _beside_ programming
errors. There is buggy hardware. There is also correct hardware which fails to
be fault tolerant. The sheer component count in a modern computer system is
astounding, as is the small size of the individual components. Would you trust
your life to a system in which an alpha particle emission can cause
unpredictable behavior?

Re: Any research putting c above ada?

[Tom Wheeley]

In article <5im3an$3dv@bcrkh13.bnr.ca>
           kaz@vision.crest.nt.com "Kaz Kylheku" writes:

> I wouldn't trust my life to any computer system, especially if it had ``Intel
> inside''. There are too many things that can go wrong _beside_ programming
> errors. There is buggy hardware. There is also correct hardware which fails to
> be fault tolerant. The sheer component count in a modern computer system is
> astounding, as is the small size of the individual components. Would you trust
> your life to a system in which an alpha particle emission can cause
> unpredictable behavior?

You'll never fly in an Airbus then?

-- 
:sb)

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <01bc46be$fb54cae0$3f6700cf@default>,
Larry J. Elmore <ljelmore@montana.campus.mci.net> wrote:
>Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
><5im3an$3dv@bcrkh13.bnr.ca>...
>> I wouldn't trust my life to any computer system, especially if it had
>``Intel
>> inside''. There are too many things that can go wrong _beside_
>programming
>> errors. There is buggy hardware. There is also correct hardware which
>fails to
>> be fault tolerant. The sheer component count in a modern computer system
>is
>> astounding, as is the small size of the individual components. Would you
>trust
>> your life to a system in which an alpha particle emission can cause
>> unpredictable behavior?
>
>I take it you never fly? Nor do you live near an airport? Or have a modern
>car?

Nope. Well, I have a modern car, but it's unlikely that its computer is very
large and complex. It's probably programmed in assembly language. Also,
the car is not ``drive by wire'' even if a computer is involved. If the
computer fails, the car will not seriously malfunction or crash! At worst, it
will exhibit poor performance. Hence I'm not trusting my life to the
computer in any way.

>Actually, as far as I know, modern computerized planes are a good deal
>safer, on the whole, than they were back in the days when _everything_ was
>mechanical. I guess you wouldn't want to trust your life to any mechanical
>system, either? Especially since components _can_ fail and hidden
>manufacturing defects show up at just the wrong moment...

Actually, I would trust a mechanical system far more. There are ways to inspect
mechanical systems for signs of wear and damage due to stress.  You can also
build mechanical systems to within certain tolerances; e.g.  you can make a
load bearing beam twice as strong as it needs to be by making a trivial change
to its thickness.

Is there any evidence that modern computerized planes are indeed safer? If they
are, can the extra safety be directly attributed to the use of on-board
computers? 

Re: Any research putting c above ada?

[Craig Franck]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:
>In article <01bc46be$fb54cae0$3f6700cf@default>,
>Larry J. Elmore <ljelmore@montana.campus.mci.net> wrote:

>>I take it you never fly? Nor do you live near an airport? Or have a modern
>>car?
>
>Nope. Well, I have a modern car, but it's unlikely that its computer is very
>large and complex. It's probably programmed in assembly language. Also,
>the car is not ``drive by wire'' even if a computer is involved. If the
>computer fails, the car will not seriously malfunction or crash! At worst, it
>will exhibit poor performance. Hence I'm not trusting my life to the
>computer in any way.

Well, actually, most modern cars have microcontrollers at least 
as complex as an 8088. Also, the engine will not run at all on
most if the controller for the fuel injection system becomes 
disabled. If this happens when you are driving (as it did 
recently to me) the vehicle will stall. Stearing and brakes are
mostly mechanical, but you may lose power assist or antilock.

Anyway, Kaz, the odds of you dying do to another motorist's poor
judgement or weather conditions are far greater than that do
to computer malfunction. (It is interesting how some people
assess risk. I have a friend who drinks excessively, never 
exercises, eats junk, and drives his snowmobile like a complete
lunatic after having six or eight beers. You know what he worries
about dying from? Getting AIDS from a mosquito bite!)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
Man is the only animal for whom his own existence is
a problem which he has to solve. -- Erich Fromm

Re: Any research putting c above ada?

[James S. Rogers]

Matthew Givens wrote:
> 
> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
> >
> <<<<< SNIP >>>>>
> >
> >There is a subtle difference you are missing here.  In Ada, any type
> >_difference_ will cause a compile time error.  In C, the type
> >_incompatibilities_ are the only things to be caught.  What is the
> point
> >of defining different types if you can freely assign between them?
> >Different types are used for different purposes.  Removing that
> checking
> >eliminates the structure that makes Ada so much easier to debug.
> >
> 
> Hmmmmm, the other side of that coin is that an integer is an integer,
> whether it's called an integer or "timer" or whatever other name the
> programmer selected for the new type.  If both types can contain the same
> data, then why shouldn't you be able to mix these types?  It's a matter
> of preferences.  Some prefer a rigid, well-enforced environment, and
> others prefer a looser one.

Even in C it is not a good thing to assume an integer is an integer.
A pointer value is an integer.  No experienced C programmer would 
multiply a vote count with a pointer value, assigning the result to
the pointer.  Speaking of pointers as integers, what about that special
pointer value 0?  Why are there no negative pointer values?  After all,
an integer is an integer.

Why is there a difference in the C specification between characters and
longs?  Certainly they are both forms of integers in C.  They must,
by your logic, be completely inter-convertable.

Why does C++ not allow the implicit conversion between enum types and
int which is allowed in C?  The reason is that such a conversion will
easily and quickly lead to undefined results for the enum type.  Such
undefined results cannot be easily caught by a C compiler.  Even lint
is of little use in detecting this error.

Of course there are different types which use any integer-like
representation.  That does not make the types even approximately 
compatible.  Incompatible types should not be masked by using one
single integer representation for all of them.  

Strong typing as found in Ada can be difficult to deal with.  It can
be difficult because it forces the designer to understand the 
behavior and limitations of the design in great detail.  Weak typing
allows the designer to ignore many behavior and limitation details.
When design ignores behavior and limitation details the door is opened
for catastrophic failure.  It is usually very difficult to detect these
problems in formal testing, leaving major defects in the delivered
product code.  Such defects are more and more frequently exposing
software developers to serious legal actions including criminal charges
and civil suits.

Jim Rogers
Colorado Springs, Colorado
--------------------------
Team Ada

Re: Any research putting c above ada?

[Matthew Givens]

clines@airmail.net (Kevin Cline) wrote:
>
>>I've always hated that level of "problems" discovered in code review.  

>>It's an integer, right?  Why put a type declaration around an integer?  

>>It seems to me that a code review is supposed to discover major errors 

>>that actually affect the functionality of the code.  Burdening the 
>>programmer with a lot of cosmetic alterations that don't change the 
>>functionality is self-defeating, IMHO.
>>
>
>Wow!  I'm not a big Ada fan, but I'm sure glad I don't have to maintain 
your
>code.  I would hate to have to go through it and figure out which fours 
needed
>to be changed to eights, and which needed to be left alone.

What does a type declaration have to do with changing a 4 to an 8?  
Constant values, being part of the algorythm, would be looked at.  But 
why force a type declaration that isn't needed to compile correctly?  
Also, on the 4 to 8 change you brought up, I usually use constants (such 
as max_trucks) set to the desired value (in this case 8) instead of the 
integer 8.  Why?  Easier to maintain, modify, and debug.

>
>
>>
>>And are written to a higher set of standards then, say, an accounting 
>>package. Take into account the different situations, please.
>>
>
>An accounting package that produced erroneous results could cost
>someone a lot of money.  The standards for commercial accounting 
packages
>are pretty high.

Hmmmmm, compare losing money to losing lives, and see which should have 
the higher standards.  I know what I would choose.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Dale Stanbrough]

Matthew Givens writes:

"  In fact, I argue the opposite quite a lot.  C is good at what 
 it does, very good.  Try writing a compiler or OS in Ada.  You can do it, 
 certainly, but it's easier and  more natural in C.  Why?  Because that's 
 what C was designed to do!"

The Gnat Ada compiler _is_ written in Ada. What makes it so hard to do 
in Ada? What makes it easier and more natural in C? You've really got
my curiosity piqued!

Dale

Re: Any research putting c above ada?

[Matthew Givens]

Tom Moran <tmoran@bix.com> wrote:
>
>> assumes that the programmer WANTS the strict typing.  I rarely do, 
>> and I rarely run into problems with it.
>If you are dealing only with counting apples, then certainly all your
>counts should be of the same type, which is no more difficult in Ada
>than in C.  Only if you are counting both apples and oranges, and do 
not
>wish to accidentally compare apples and oranges, do you need multiple,
>distinct, types.  That's much less conveniently done in C than Ada.  
Ada
>gives you convenient tools for both situations, C only for the simple
>situation.

If I'm counting apples and oranges (both countable by integers), why 
should I have different data types?  The variable names used to 
accumulate the results are quite adequate to distinguish the difference 
between the two.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Tom Moran]

> why should I have different data types?  The variable names used to 
> accumulate the results are quite adequate
   Certainly you can make long names that include the type - that's
partly what Hungarian notation is about.  You can also enclose simple
int's in structs.  The C programmer who's willing to be very verbose
*can* do all this in C with no difficulty offered by the compiler.  But
an Ada compiler actively *helps* the programmer so he needn't verbosely
do it all himself.  (This is bizarre, since C used to sold as 'short and
elegant and fewer keystrokes'.  I guess that all goes away when you want
to be careful.)

Re: Any research putting c above ada?

[Nick Roberts]

In answer to the questions about putting different fruits in the same
array, have a gander at this:

-----------
type Kind_Of_Fruit = (Apple, Orange, {other kinds});

type Fruit_Descriptor(Kind: Kind_Of_Fruit) is
   record
      case Kind is
         when Apple =>
            AV: Apple_Variety;
            {other components}
         when Orange =>
            OV: Orange_Variety;
            {other components}
         {etc for other kinds}
      end case;
   end record;

type Fruit_Reference is access Fruit_Descriptor;

...

FA: array (Location_In_Bowl) of Fruit_Descriptor;

...

begin
   FA(1) := new Fruit_Descriptor'(Apple,Golden_Delicious,...);
   FA(2) := new Fruit_Descriptor'(Orange,Satsuma,...);
   ...
end;

------------
Thus one might (want to) have different fruits in the same array.

The above can be done in C++ using classes, but in order to get the
equivalent of Ada's automatic deallocation, the appropriate destructor has
to be declared. This is not difficult, but it's easier (and less
error-prone) in Ada.

To do this in C is not directly possible. The deallocation has to be done
specifically, and the correct size has to be specified when allocating each
fruit (since the size of an apple descriptor may be different to that of an
orange, and other fruits). In addition, nothing prevents apple data and
orange data being mixed up accidentally (lint can only check static
contraventions). This is really a pain, and illustrates how C is not very
suitable for large-scale software.

Nick.

Re: Any research putting c above ada?

[Matthew Givens]

"James S. Rogers" <JimMaureenRogers@worldnet.att.net> wrote:
>
>
>Even in C it is not a good thing to assume an integer is an integer.
>A pointer value is an integer.  No experienced C programmer would 
>multiply a vote count with a pointer value, assigning the result to
>the pointer.  Speaking of pointers as integers, what about that special
>pointer value 0?  Why are there no negative pointer values?  After all,
>an integer is an integer.

If you look closer, a pointer is NOT a strict integer value, especially 
when dealing with the segmented PC architecture.  And the compiler 
enforces that with the "different levels of redirection", I believe the 
message goes.  Then again, I haven't gotten that message in quite a while.
  Luck?  No, just that advanced use of pointers is second nature to a 
proficient C programmer.  And care when using pointers is the first thing 
taught.  Although I might (and have) get pointers pointing to weird 
places, I don't try and do mathematical calculations with them.

>
>Why is there a difference in the C specification between characters and
>longs?  Certainly they are both forms of integers in C.  They must,
>by your logic, be completely inter-convertable.

Again, a character is a different creature from a long integer.  Yes, you 
can mix them, and there's nothing wrong (in and of itself) with doing so.


So far, you've proved my point.  All your arguments assume that the 
programmer works well in a rigid, strongly-typed environment.  I do not.  
I work much better when I can mix and match the types as I need to do so, 
without a lot of extra programming to make it work.  Different 
personalities, different capabilities, different languages.

>
>Of course there are different types which use any integer-like
>representation.  That does not make the types even approximately 
>compatible.  Incompatible types should not be masked by using one
>single integer representation for all of them.  

Of course not, and I don't.  But judicious use of type mixing is fine.  
My favorite example is converting to lower case: 'A' + 32.  Simple and 
easy, in C.

>
>Strong typing as found in Ada can be difficult to deal with.  It can
>be difficult because it forces the designer to understand the 
>behavior and limitations of the design in great detail.  Weak typing
>allows the designer to ignore many behavior and limitation details.
>When design ignores behavior and limitation details the door is opened
>for catastrophic failure.  It is usually very difficult to detect these
>problems in formal testing, leaving major defects in the delivered
>product code.  Such defects are more and more frequently exposing
>software developers to serious legal actions including criminal charges
>and civil suits.

Blaming such problems on the language is short sighted, don't you think?  
I used to know a guy who couldn't write "hello world" in basic without 
crashing the computer, but could write rings around me in C.  Good 
programmer, with good programming and debugging habits.  And that's what 
it's all about, right?  We should all develop good programming habits in 
whatever language we choose.

Jim, my point is that diversity is a good thing, not a bad one.  The C 
language has it's place, as does Ada.  Don't make the mistake of trying 
to classify one as "good" and the other as "bad", because it's all in 
your assumptions.  My assumptions are that ease of use, versatility, and 
a relaxed environment are good.  Yours are that a rigid environment helps 
the programmer avoid stupid errors and concentrate on writing programs.

Well, my assumptions work for me, and yours work for you.  Why try and 
muck things up by tagging one "better" than the other?

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Kenneth Almquist]

NKSW39B@prodigy.com (Matthew Givens) wrote:
> "James S. Rogers" <JimMaureenRogers@worldnet.att.net> wrote:
>> Of course there are different types which use any integer-like
>> representation.  That does not make the types even approximately 
>> compatible.  Incompatible types should not be masked by using one
>> single integer representation for all of them.  
>
> Of course not, and I don't.  But judicious use of type mixing is fine.  
> My favorite example is converting to lower case: 'A' + 32.  Simple and 
> easy, in C.

Not a terribly convincing example, from my perspective.  First, there
is rarely reason to do this.  C and Ada provide library routines for
case conversion.  Calling them is "simple and easy," and they handle
the local character set, so that code which uses them is portable to the
systems using different character sets.

Second, the Ada equivalent to your example is not that complex:

	Character'val(Character'pos('A') + 32)

This is more verbose because of the conversions, but the conversions
provide a clue to anyone who has to port the code.  If you are writing
throw-away code, sticking in the conversions is no big deal.  If the
code you are writing is going to have to be maintained years from now
(either by you or someone else) it is probably worth making the dependency
on the character set a little more conspicuous than the C code does.
				Kenneth Almquist

Re: Any research putting c above ada?

[Matthew Givens]

ka@socrates.hr.lucent.com (Kenneth Almquist) wrote:
>
>
>Not a terribly convincing example, from my perspective.  First, there
>is rarely reason to do this.  C and Ada provide library routines for
>case conversion.  Calling them is "simple and easy," and they handle
>the local character set, so that code which uses them is portable to 
the
>systems using different character sets.

Of course it's not convincing.  It was intended to be an example of data 
mixing with a purpose.  It was the first one that sprang to mind, so I 
used it.

>Second, the Ada equivalent to your example is not that complex:
>
>	Character'val(Character'pos('A') + 32)

Yes, I know, but why take extra effort to "code around" something, then 
call that a benefit?

>This is more verbose because of the conversions, but the conversions
>provide a clue to anyone who has to port the code.  If you are writing
>throw-away code, sticking in the conversions is no big deal.  If the
>code you are writing is going to have to be maintained years from now
>(either by you or someone else) it is probably worth making the 
dependency
>on the character set a little more conspicuous than the C code does.

And if adding explicit type conversions to that simple example is going 
to make it easier to maintain, then you are employing the wrong 
programmers.
>				Kenneth Almquist

-
If at first you don't succeed, destroy all evidence that you ever tried. 
<< Iceman >>

Re: Any research putting c above ada?

[Alan Brain]

Matthew Givens wrote:

> And if adding explicit type conversions to that simple example is going
> to make it easier to maintain, then you are employing the wrong
> programmers.

It seems to me that all the arguments for C over Ada can be duplicated
in
any good Macro Assembler over C.

Thus LDM =A,h10 is close to the machine level, terse, flexible (in
assembler you can multiply floats by booleans! ) is as efficient as it
can be, and by using the proper tools, can be made portable and safe.
Obviously C is for wimps who can't hack Assembler, just as Ada is for
wimps who can't hack C. Any language can be used. It's all a matter of
opinion and what you're used to.  Real programmers would of course write
03707 instead of that LDM guff (it's terser). Heck, the meaning of
0011010010000101 is OBVIOUS to the meanest intelligence, and it tells
you exactly which parts of the CPU are being used, and uses a reduced
character set which an expert can use most efficiently!
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Matthew Givens]

Alan Brain <aebrain@dynamite.com.au> wrote:
>
>
>It seems to me that all the arguments for C over Ada can be duplicated
>in
>any good Macro Assembler over C.
>
>Thus LDM =A,h10 is close to the machine level, terse, flexible (in
>assembler you can multiply floats by booleans! ) is as efficient as it
>can be, and by using the proper tools, can be made portable and safe.
>Obviously C is for wimps who can't hack Assembler, just as Ada is for
>wimps who can't hack C. Any language can be used. It's all a matter of
>opinion and what you're used to.  Real programmers would of course 
write
>03707 instead of that LDM guff (it's terser). Heck, the meaning of
>0011010010000101 is OBVIOUS to the meanest intelligence, and it tells
>you exactly which parts of the CPU are being used, and uses a reduced
>character set which an expert can use most efficiently!
>

Ahhhh, this is the tactic my wife uses sometimes.  Take what I say, 
amplify it until you've reached ridiculousness, then claim that's what I 
meant.

You did it well.  Not real well, but good enough.

However, I don't believe I ever said anything about Ada being for wimps 
who can't hack C.  You said that, not I.  I didn't even imply that.

But you'll never believe that, will you.  So, continue to battle truth 
with ridicule whenever possible.  It works, sometimes, so why not?

-
"What is the speed of dark?"
Matthew A. Givens

Re: Any research putting c above ada?

[Alan Brain]

Matthew Givens wrote:
> 
> Alan Brain <aebrain@dynamite.com.au> wrote:
> >
> >
> >It seems to me that all the arguments for C over Ada can be duplicated
> >in
> >any good Macro Assembler over C.
> >
> >Thus LDM =A,h10 is close to the machine level, terse, flexible (in
> >assembler you can multiply floats by booleans! ) is as efficient as it
> >can be, and by using the proper tools, can be made portable and safe.
> >Obviously C is for wimps who can't hack Assembler, just as Ada is for
> >wimps who can't hack C. Any language can be used. It's all a matter of
> >opinion and what you're used to.  Real programmers would of course
> write
> >03707 instead of that LDM guff (it's terser). Heck, the meaning of
> >0011010010000101 is OBVIOUS to the meanest intelligence, and it tells
> >you exactly which parts of the CPU are being used, and uses a reduced
> >character set which an expert can use most efficiently!
> >
> 
> Ahhhh, this is the tactic my wife uses sometimes.  Take what I say,
> amplify it until you've reached ridiculousness, then claim that's what I
> meant.
> 
> You did it well.  Not real well, but good enough.

Oops. Actually, not my intention. Though looking at my post, your
conclusion seems inescapable. Mea Culpa.
Please look at the initial sentence... I would greatly appreciate your
elucidation of some technical arguments about the merits of C as opposed
to Ada which cannot also be adduced for a Macro Assembler vs C.
Really. 

> However, I don't believe I ever said anything about Ada being for wimps
> who can't hack C.  You said that, not I.  I didn't even imply that.

Fair enough, I unreservedly apologise for the imputation, which was the
result of my own carelessness. I guess I wasn't really replying to your
post so much as many of the posts expressing _similar_ opinions. Not
yours neccessarily ( and in this case, not yours at all, right?)
 
> But you'll never believe that, will you.  So, continue to battle truth
> with ridicule whenever possible.  It works, sometimes, so why not?

Because winning is not the issue. I'm perfectly willing to believe I'm
wrong - I have been many times in the past - but on this issue I have a
large amount of evidence, as well as personal experience, to show that
Language DOES matter (as does IPSE, possibly even more so). And I'm
looking for more evidence, for or against. And trying (unsuccessfully it
seems) to be rational about it. So... please forgive my poor expression,
and give a serious answer to what was meant to be a serious question,
not some asinine dielectical game ploy.

Over 2 U.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Matthew Givens]

Alan Brain <aebrain@dynamite.com.au> wrote:
>
>Because winning is not the issue. I'm perfectly willing to believe I'm
>wrong - I have been many times in the past - but on this issue I have a
>large amount of evidence, as well as personal experience, to show that
>Language DOES matter (as does IPSE, possibly even more so). And I'm
>looking for more evidence, for or against. And trying (unsuccessfully 
it
>seems) to be rational about it. So... please forgive my poor expression,

>and give a serious answer to what was meant to be a serious question,
>not some asinine dielectical game ploy.
>
>Over 2 U.

Fair enough.  There are enough slurs, accusations, and wild claims that I 
sometimes jump at shadows.

Okay.  First, language does matter.  I agree.  It would be stupid to use 
Fortran for an interactive, GUI application.  It might be possible, but 
it's not the best choice.  C (C/C++) shines in many applications, from 
system software to graphics intensive games, or any situation requiring 
small and swift executables.  Not to mention portability.

C also has it's weaknesses.  Among these are steeper learning curves, 
higher maintenance costs, occasionally inexact floating point math 
(unless you use a special library or have a good compiler), and so forth. 
 

Ada has it's own strengths.  Embedded systems, for example.  It handles 
tasking well, although it's not a terribly simple procedure to follow.  
It enforces strict adherence to things like typing, for example.  All in 
all, a rigid programming environment that is good at what it does best.

Ada also has it's weaknesses.  We're using it to develop GUI based Oracle 
applications on a Sun system.  The compiled code for the executables is 
tryuly enormous, in comparison with the executable generated for similar 
programs using C.  On my own initiative, I once wrote the "Hello World" 
program in both C and Ada on a 3B2 running Unix.  This was a while ago, 
like three or four years.  The C app was under 5K, if I remember right, 
while the Ada app was almost 50K.  Ummmm, that's a factor of 10.  And I 
am referring to the amount of memory used by the app, not the size of the 
file.  To be sure, I can run the test again.  I'm interested to see what 
the results are in the current system I'm using.

Anyway, size of executables is one problem (I wrote one that had an 
executable size of almost 600K, and that was just a report generator, not 
a GUI app).  Others include indequate programming tools for the language 
and tasking problems (Ada tasking won't work with the graphic front-end, 
no work-around possible, they tell me).  Not Ada per se, I understand, 
but the tools used with the language are important.

Another thing about Ada that I deplore is generics.  A nice concept, but 
when the same procedure has eight different bodies, it's a bit confusing 
to debug (which body had the bug in it???).  Or optional parameters.  Ugh,
 I hate the concept.  To me, no parameter to a procedure should ever be 
optional.  At any time.  But I guess that's just the neanerthal C 
programmer peeking out.  (grin)

Now, step back a bit.  I said earlier that the language matters, and it 
does.  But so does the programmer.  Have you ever known a programmer who 
did good in one language, but just couldn't handle another?  And not 
because he didn't try, but because the concepts were just not twigging 
something in his brain.  When I was teaching C, I had this problem with 
Cobol programmers taking the class.  If it was their only language, and 
sometimes even if it wasn't, they had the most HORRIBLE time learning C.

That's what I'm talking about.  Not everyone can be equally good in both 
C and Ada.  Like me.  I program in both, but am infinitely more 
comfortable in C. The code I turn out is better, and I can do it quicker. 
 Forcing me to use Ada will produce results, but won't be as productive.

So.  You must pick the language that fits the application and the 
programmers.  Both must be taken into account, although probably not 
equally.  

It's getting late, so instead of continuing this essay, I'll shut down 
and let you respond.  If I have more to say  I'll say it later.

-
"What is the speed of dark?" << Iceman >>

Re: Any research putting c above ada?

[Tom Moran]

> Ada tasking won't work with the graphic front-end, 
> no work-around possible, they tell me
Perhaps you have an unfortunate implementation (sounds like it from the
size of the executables).  CLAW (Class Library for Ada and Windows) uses
Ada tasking harmoniously with Windows 95/NT tasking.  In fact the same
source code works with compilers that map 1 task to 1 thread and
compilers that map all Ada tasks to a single Windows thread (much
cheaper task switching, but no overlapped IO on Win95).  Clearly that
took a bit of care, but no contortions.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <337002B4.26F5@bix.com> Tom Moran <tmoran@bix.com> writes:

<CLAW working harmoniously with Win95/NT GUIs with tasking on>

The following is the interesting bit!

> In fact the same source code works with compilers that map 1 task to
> 1 thread and compilers that map all Ada tasks to a single Windows
> thread

Now, that is pretty nice.  Excellent.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kevin Cline]

NKSW39B@prodigy.com (Matthew Givens) wrote:

 Others include indequate programming tools for the language 
>and tasking problems (Ada tasking won't work with the graphic front-end, 
>no work-around possible, they tell me).  

I think they are lying.  It should be possible to map Ada tasks to Solaris
threads.  But it may not be simple given the other constraints imposed by the
existing compiler and run-time library, and the vendor may simply not have
fiscal justification for the undertaking.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5kopik$1jos@newssvr01-int.news.prodigy.com> NKSW39B@prodigy.com (Matthew Givens) writes:

> (Ada...) all, a rigid programming environment that

Not particularly - certainly not really in comparison to C or C++.
Definitely true in comparison to Lisp, ST, and such.


> Ada also has it's weaknesses.  We're using it to develop GUI based Oracle 
> applications on a Sun system.  The compiled code for the executables is 
> tryuly enormous, in comparison with the executable generated for similar 

I have a bad feeling you are doing this using some Ada83 impl...


> Anyway, size of executables is one problem (I wrote one that had an
> executable size of almost 600K, and that was just a report
> generator, not a GUI app).

If you instantiate a lot of generics all over the place (especially if
you don't organize things sensibly) and you implementation does not
have generic code sharing, then sure, you can wind up with code bloat.
Generally, I've found this has more to do with poor understanding of
how this stuff should be used.  Typical example is instantiating
Integer_IO or whatever all over the place when one is just fine.


> Others include indequate programming tools for the language and
> tasking problems (Ada tasking won't work with the graphic front-end,
> no work-around possible, they tell me).

Well, X just plain has problems here (assuming you are using X).  But
even X works fine (as much as can be expected) with tasking built on
the OS threads.  For example, default GNAT on Solaris with X/Motif
makes multiple user sessions trivial with tasking.  I've done it.  If
the GUI has at least _some_ thread sense, then this will not be a
problem if you have any idea of how concurrent systems work.


> Not Ada per se, I understand, but the tools used with the language
> are important.

All sounds way out of date and irrelevant.


> Another thing about Ada that I deplore is generics.  A nice concept, but 
> when the same procedure has eight different bodies, it's a bit confusing 
> to debug (which body had the bug in it???).

Easy.  It is the name of the instantiation unit.  Trivial even in GDB.
Works fine.  Generics are actually very important for anything even
attempting to provide multiple setting abstractions.  They're in C++,
Eiffel, Modula-3, Clu, etc.  They are really passe' in this respect:
"everyone knows these things are vital in a statically typed language".


> Or optional parameters.  Ugh, I hate the concept.  To me, no
> parameter to a procedure should ever be optional.  At any time.
> But I guess that's just the neanerthal C programmer peeking out.

Misunderstanding.  There are no "optional" parameters.  There can be
*default* parameters, but not optional ones.  I suppose you can say,
"whatever", but this really is a big difference.


> That's what I'm talking about.  Not everyone can be equally good in
> both C and Ada.  Like me.  I program in both, but am infinitely more
> comfortable in C. The code I turn out is better, and I can do it
> quicker.  Forcing me to use Ada will produce results, but won't be
> as productive.

This argument is the only one you give that is semi-plausible.  There
really are good reasons why you would choose one language instead of
another, and Ada is certainly and obviously not "perfect for all
scenarios".  But the issues you raise are really irrelevant to this
question.  Things like, "I need a dynamic language here [Lisp or
something]", or "I need to have true vectorization of all this
computation [Fortran]" are the sorts of questions that really count in
this context.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Matthew Givens]

clines@delete_this.airmail.net (Kevin Cline) wrote:
>
>NKSW39B@prodigy.com (Matthew Givens) wrote:
>
> Others include indequate programming tools for the language 
>>and tasking problems (Ada tasking won't work with the graphic front-end,
 
>>no work-around possible, they tell me).  
>
>I think they are lying.  It should be possible to map Ada tasks to 
Solaris
>threads.  But it may not be simple given the other constraints imposed 
by the
>existing compiler and run-time library, and the vendor may simply not 
have
>fiscal justification for the undertaking.

If you'll look back, I said Ada tasking won't work WITH THE GRAHPHIC 
FRONT END.  We use something called Screen Machine to develop screens, 
and it uses a tasking system to handle things (although I've never seen 
why).  All attempts at implementing tasking in one of the Screen Machine 
screens fails.  No lying, and it has nothing to do with Solaris threads.  
Just Screen Machine.

Re: Any research putting c above ada?

[Robert S. White]

In article <5l20s7$2oso@newssvr01-int.news.prodigy.com>, NKSW39B@prodigy.com 
says...
>
>clines@delete_this.airmail.net (Kevin Cline) wrote:
>>
>>NKSW39B@prodigy.com (Matthew Givens) wrote:
>>
>> Others include indequate programming tools for the language 
>>>and tasking problems (Ada tasking won't work with the graphic front-end,
> 
>>>no work-around possible, they tell me).  
>>
>>I think they are lying.  It should be possible to map Ada tasks to 
>Solaris
>>threads.  But it may not be simple given the other constraints imposed 
>by the
>>existing compiler and run-time library, and the vendor may simply not 
>have
>>fiscal justification for the undertaking.
>
>If you'll look back, I said Ada tasking won't work WITH THE GRAHPHIC 
>FRONT END.  We use something called Screen Machine to develop screens, 
>and it uses a tasking system to handle things (although I've never seen 
>why).  All attempts at implementing tasking in one of the Screen Machine 
>screens fails.  No lying, and it has nothing to do with Solaris threads.  
>Just Screen Machine.

  OK....it sounds like Screen Machine is functioning as its own
tasking executive.  Do you disable Ada tasking (possible link
time switch) with your Ada 83 compiler?   This has often been
done when using an Ada 83 compilier with a RTE that offered more
features and finer control than the simple Ada 83 tasking.  When
you do this the Ada 83 compiler has no major advantage over C for
tasking purposes (but no disadvantage either).  Your Screen Machine
library hopefully offers routines to Signal Events, Wait for Events,
and guard data with some type of Reserve/Semaphore mechanism.

_____________________________________________________________________
Robert S. White                  -- an embedded sys software engineer

Re: Any research putting c above ada?

[Kevin Cline]

NKSW39B@prodigy.com (Matthew Givens) wrote:

>clines@delete_this.airmail.net (Kevin Cline) wrote:
>>
>>NKSW39B@prodigy.com (Matthew Givens) wrote:
>>
>> Others include indequate programming tools for the language 
>>>and tasking problems (Ada tasking won't work with the graphic front-end,
> 
>>>no work-around possible, they tell me).  
>>
>>I think they are lying.  It should be possible to map Ada tasks to 
>Solaris
>>threads.  But it may not be simple given the other constraints imposed 
>by the
>>existing compiler and run-time library, and the vendor may simply not 
>have
>>fiscal justification for the undertaking.
>
>If you'll look back, I said Ada tasking won't work WITH THE GRAHPHIC 
>FRONT END.  We use something called Screen Machine to develop screens, 
>and it uses a tasking system to handle things (although I've never seen 
>why).  All attempts at implementing tasking in one of the Screen Machine 
>screens fails.  No lying, and it has nothing to do with Solaris threads.  
>Just Screen Machine.

Since you didn't mention any specific product by name, I assumed you were
using the generic front-end for Solaris, i.e. X-Windows.

Re: Any research putting c above ada?

[brad.balfour]

[I'm posting this on behalf of Bill Beckwith here at OIS -- Brad]

In article <5l20s7$2oso@newssvr01-int.news.prodigy.com>,
          NKSW39B@prodigy.com (Matthew Givens) wrote:
> If you'll look back, I said Ada tasking won't work WITH THE GRAHPHIC
> FRONT END.  We use something called Screen Machine to develop screens,
> and it uses a tasking system to handle things (although I've never seen
> why).  All attempts at implementing tasking in one of the Screen Machine
> screens fails.  No lying, and it has nothing to do with Solaris threads.
> Just Screen Machine.

Many OIS customers have successfully used tasking with Screen Machine.
Screen Machine protects the otherwise threading-unfriendly Motif.
There are several tasking examples that ship with the product.  All of
the data structures are not protected in the product in order to keep
performance high.  This requires that you need to understand the
Screen Machine tasking model.

If you have purchased support for the product, you can send e-mail
to support@ois.com for more help.

--
Brad Balfour  === Note new company, e-mail,& phone number ===
Director of Technology Services
OIS, Inc.
Brad.Balfour@ois.com
703/295-6533

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Any research putting c above ada?

[T Wheeley]

On 7 May 1997, Matthew Givens wrote:

> Another thing about Ada that I deplore is generics.  A nice concept, but 
> when the same procedure has eight different bodies, it's a bit confusing 
> to debug (which body had the bug in it???).  Or optional parameters.  Ugh,
>  I hate the concept.  To me, no parameter to a procedure should ever be 
> optional.  At any time.  But I guess that's just the neanerthal C 
> programmer peeking out.  (grin)

I suppose I must be used to generics.

The two things that continue to bug me in Ada though, happen to be

a) String support

Inbuilt strings are a nightmare to use, especially I/O.  I eventually
wrote my own package to read arbitrary length strings.  The actual
functions for manipulating strings are quite good, the absract Translate()
procedure is quit nice, for example.  Another problem with Ada strings is
tyhat the language is continually encouraging you to copy them all over
the place, which may be easy but it doesn't seem to be very efficient,
imho, almost like BASIC.  You have to delve into the depths of the
language to control the memory allocation properly.

b) WHY can't functions have out / in out parameters?

All this means is that for example a Stack.Pop or
Binary_Heap.delte-min subprogram has to be implemented as a procedure with
an extra local variable, making things more difficult.  It doesn't
restrict the language particulalry, just annoys programmers.  Of course
you can get around it by making your stack variable a pointer (for
example), and having the pop subprogram edit the information referenced by
the pointer...

Other than that it's not too bad; apart form being too big of course.

:sb)

Re: Any research putting c above ada?

[Tom Wheeley]

In article <5j18h3$1564@newssvr01-int.news.prodigy.com>
           NKSW39B@prodigy.com "Matthew Givens" writes:

> Of course not, and I don't.  But judicious use of type mixing is fine.  
> My favorite example is converting to lower case: 'A' + 32.  Simple and 
> easy, in C.

And non-portable.  Try using tolower('A') next time.

-- 
:sb)

Re: Any research putting c above ada?

[Matthew Givens]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:
>
>
>You can't freely assign between different types in C.  For example, you 
can't
>assign an pointer type to a structure type, or an integer type to a 
pointer
>type, or a pointer to an incompatible pointer. Despite being an Ada 
programmer,
>you have to recognize that C does have a strong type system and does 
demand
>that type constraints be diagnosed. It's a myth that ``anything goes'' 
in C,
>promoted by people who don't understand the language and who think that
>diagnostics are mere annoyances.

That's true, and only a fool would deny it.  On the other hand, more 
conventional assignments are perfectly okay, such as:
int   x;
char C;

C= '5';
x= C - '0';

Easy, painless, and useful.  The same idea works for converting between 
lower and upper case letters by adding or subtracting 32.  These are 
mundane examples, but indicative.

>
>As an anticipated counter-argument to this, I could say that since you 
are
>programming a computer, why not let the computer help you? Since the 
computer
>can easily enforce the type distinctions inherent in the design, it 
ought
>to do so.

Yes, but it's my choice as to what level I want the type-checking 
performed at. I prefer a low level, giving me maximum flexibility.

>
>How often are there computer problems that don't make it into the news?
>I have no idea. Since the media thrives on sensationalizing the macabre, 
you
>only hear about the spectacular failures that cause a crash.

Agreed.  Whenever a PC fails and causes someone tobe injured or die, we 
hear about it forever, don't we?  Or just let a virus run loose...

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5j4ijn$3ta1@news.knox.edu>, root <root@linux_pc.org> wrote:
>>Not part of my daily life. I run a reliable operating system. Then again, one
>>need only thumb through one of those little booklets published by Intel which
>>outline various ways in which their Pentium processors don't live up to their
>>own architectural specs. There are at least 20 or so _known_ ways, for
>>instance,  in which a dual Pentium system can lock up, due to flaws in the
>>hardware rather than operating system software.  My dual P100 could lock up,
>>and I could conveniently point the finger at Intel.
>
> You won't find many safety-critical apps entrusted to P-whatevers either.

Consider this:

    Intel products are not intended for use in medical, life saving, or
    life sustaining applications. 

This quote is taken from _Pentium Processor Specification Update_ from Intel,
January 1997. It is in the very first disclaimer paragraph on the inside front
cover.

It doesn't just say ``Pentium processors are not intended for...'', but *all*
Intel products.

It's debatable whether a flying aircraft can be dubbed a life sustaining
application; in some sense it is! :)

Re: Any research putting c above ada?

[Tim Behrendsen]

Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article <5j5kqf$adm@bcrkh13.bnr.ca>...
> In article <5j4ijn$3ta1@news.knox.edu>, root <root@linux_pc.org> wrote:
> >>Not part of my daily life. I run a reliable operating system. Then again, one
> >>need only thumb through one of those little booklets published by Intel which
> >>outline various ways in which their Pentium processors don't live up to their
> >>own architectural specs. There are at least 20 or so _known_ ways, for
> >>instance,  in which a dual Pentium system can lock up, due to flaws in the
> >>hardware rather than operating system software.  My dual P100 could lock up,
> >>and I could conveniently point the finger at Intel.
> >
> > You won't find many safety-critical apps entrusted to P-whatevers either.
> 
> Consider this:
> 
>     Intel products are not intended for use in medical, life saving, or
>     life sustaining applications. 
> 
> This quote is taken from _Pentium Processor Specification Update_ from Intel,
> January 1997. It is in the very first disclaimer paragraph on the inside front
> cover.

The reason is probably that the medical market is so puny that they
figured it wasn't worth being dragged into a lawsuit if a medical
manufacturer was sued.  That sounds like lawyer-speak to me.

-- 
==========================================================================
| Tim Behrendsen (tim@a-sis.com)        | http://www.cerfnet.com/~timb   |
| "Judge all, and be prepared to be judged by all."                      |
==========================================================================

Re: Any research putting c above ada?

[Steve Doiel]

I've read a lot of worthless argument on this thread (preaching to the
alreay converted - regardless of which way you are converted) but...

I missed the answer... Has any research found C to be more effective for
development or long term maintenance than Ada?

Please email me only if you are aware of such research, I'd like to know
and don't want to get into a language debate.

Steve Doiel
steved@pacifier.com

Re: Any research putting c above ada?

[Jay Martin]

steved@pacifier.com (Steve Doiel) writes:

>I missed the answer... Has any research found C to be more effective for
>development or long term maintenance than Ada?

>Please email me only if you are aware of such research, I'd like to know
>and don't want to get into a language debate.

Sorry, in general no such language effectiveness research exists as no
academic field has been formed or has taken responsibility to study this
area.  The result is that software and language design are basically sewers.

Jay
 

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <33552C53.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:

  > Can you give me an example of when faulty software has crashed an
  > airplane?  I can't think of one myself (though I won't presume to
  > deny that it has happened.)

    At least a dozen.  The worst cases were the A320 Airbus crashes.
At least one was due to a software specification bug, and there is
some suspicion that all of them were due to that bug or some related
bugs.  (But the real, probably never to be duplicated, specification
bug in the A320 is that the pilot can't override the flight control
system in an emergency.)  Other cases not so clear include the A340
prototype--there was a software failure during a test flight, but the
command pilot didn't override soon enough, and the X-29 prototype.
The X-29 crashed when a pitot tube iced up.  The electrical heater for
the pitot tube had been disconnected for a test, and apparently the
aircrew were unaware of this fact.  In any case, once the tube iced
up, the software assumed an airspeed of zero and the plane crashed.
Assuming an airspeed above stall could have avoided the crash.

  > The critical systems are not allowed to cause an airplane crash,
  > according to the standards.  As a result, they are backed up by
  > redundancy and alternate systems.  However, I do not deny that there
  > could have been a problem caused by faulty software which caused an
  > airplane crash.  I just don't know if it has happened.  I don't happen
  > to keep those statistics fresh in my mind.

  > Roy A. Grimm
  > Rockwell Collins Avionics
  > Cedar Rapids, Iowa
  > ragrimm@cca.rockwell.com

   Please get a subscription to AvLeak, and read the dry, technical
reports of the probable cause hearings printed there.  Anyone involved
in avionics should do that.

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Roy Grimm]

Kaz Kylheku wrote:
>
> >In Ada you can restrict the user from assigning between incompatible types,
> >you can data hide etc etc.
> 
> This is true of C as well. Assigning between incompatible types is a constraint
> violation which *requires* a diagnostic. It's all in ISO 9899:1990.

There is a subtle difference you are missing here.  In Ada, any type
_difference_ will cause a compile time error.  In C, the type
_incompatibilities_ are the only things to be caught.  What is the point
of defining different types if you can freely assign between them? 
Different types are used for different purposes.  Removing that checking
eliminates the structure that makes Ada so much easier to debug. 
 
> >The bug count and cost of Ada is much less than that of C, just because some
> >of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?)
> >cannot
> 
> I believe it, but you are not describing the actual advantages of Ada over C.

What would you rather do?  Develop software or chase after bugs? 
Personally, I'd rather spend my time productively producing instead of
explaining to my boss why I spent two weeks on an array index that went
out of bounds.  Wouldn't you consider that an advantage?
 
> >C:
> >typedef int cleared_flight_level;
> >typedef int airspeed;
> >
> >airspeed a = 4;
> >cleared_flight_level cfl = 5;
> >
> >...
> >
> >cfl = a;
> 
> What is your point here? The two types here are compatible. You have only
> created an alias name for int. In other words, C has structural equivalence
> for types (other than structs).

That's just the point.  The types are not compatible.  They use numbers
to represent two completely different things that _must_ be separated at
a conceptual level.  If you've ever worked on a mission critical system,
such as a flight computer, you would understand what is being talking
about.

> Why don't you see a type violation in the very declarations?

Because numerical constants which are not typed can be assigned to
numerical variables.  The numerical constant is assigned a type at
compile time when it is being assigned to a particular variable. 
Besides, the declarations probably wouldn't make it through code
review.  The team would make the programmer go back and put in type
defined numerical constants.

> In C you can do this:
> 
>     typedef struct airspeed { int i } airspeed;
>     typedef struct cleared_flight_level { int i } cleared_flight_level;
> 
> There you go. The two are no longer assignment compatible with each other or
> with the int type. You can still assign an airspeed to an other airspeed, and
> pass it in and out of functions by value. The .i operation converts
> an airspeed to an int.

Why take the long road every time?  Why not use a C compiler which
enforces the additional required structure?  It would make life so much
easier.

> >C is popular, it is quick and dirty, but I wouldn't like to trust my life to
> >it.
> 
> I wouldn't trust my life to any computer system, especially if it had ``Intel
> inside''.

Have you flown on any major commercial airplanes in the last 10 years? 
If so, you were trusting your life to Intel components.  Their ICs have
been running inside avionics equipment for years, with an extremely high
success rate.  Granted, the components which go into the systems are not
the commercial grade chips you find in a PC, but the mil-spec version of
those parts are in the flight computers world wide.

> There are too many things that can go wrong _beside_ programming
> errors. There is buggy hardware. There is also correct hardware which fails
> to be fault tolerant.  The sheer component count in a modern computer system
> is astounding, as is the small size of the individual components. Would you
> trust your life to a system in which an alpha particle emission can cause
> unpredictable behavior?

You think that modern flight computers are put on airplanes without
undergoing an entire suite of rigorous tests, including pushing them
beyond their limits to test the design?  Do you think that the potential
problems of the computers aren't planned for with redundant systems and
other forms of backup?  The systems can't be perfect.  But stop and
consider this:  You hear of PCs crashing every day.  It's an accepted
part of daily life.

Now ask yourself this:  How often do you hear of an airplane having a
computer problem?  How often do you see it on the news?  How often do
you hear of an avionics computer crashing and causing a plane crash? 
Once or twice a year?  Maybe less?  How many hours do planes spend in
the air compared to the problems they have?

Most of the computers on those airplanes have software developed in Ada.


--------------------------------------------------------------------
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Terry Colligan]

Steve Jones - JON <jon@hpodid2.eurocontrol.fr> wrote:

>haggedk1@ulysses.jhuapl.edu (CubanPete) writes:
>
>[snip]
>> Come on now Phil.  There is no language that produces software that
>> works "more right" than another.  Software is either right or it is
>> not.   Ada may have a great debugger but VMS types will argue all day
>> about how much better the debuger is on the VAX but I dont see tons of
>> UNIX folks in VMS classes.
>On my last project we use C and Ada, the bug count in the Ada code was
>over 1/3 that of the C code. And tracking down bugs in Ada is much easier,
>the code falls over it tells you the brief reason (eg constraint error) and
>the line at which the error was raised and the stack trace.  You can then add
>exception handlers et al to secure the system. It provides in built range
>checking and strong typing.
>
>In C assigning to an unitialised pointer will cause either a crash or
>wild behaviour and never tell you, in Ada it will crash and tell you why.

  A checking C environment will stop and tell you, as well.  Just
  because most C environments don't do much checking doesn't mean it
  can't be done.  Any assignment using an uninitialized pointer in our
  InstantC incremental environment will tell you nicely that you have
  just tried to use an uninitialized pointer.

  I am not offering any data or opinion about Ada vs C, since I don't
  use Ada -- I'm just saying C can be made pretty safe, if you choose
  to.

>In Ada you can restrict the user from assigning between incompatible types,
>you can data hide etc etc.
>
>The bug count and cost of Ada is much less than that of C, just because some
>of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?) cannot

  Similarly, this kind of error will be trapped at run-time in
  InstantC.

>be done in Ada.  Both Ada and C can produce correct programs but IME it is
>easier to do in Ada, the same would go for Eiffel v C++, a HLL v a MLL presents
>similar advantages to a MLL over a LLL.
>
>I know C, I know Ada and various languages besides, if I was writting a quick
>check or hack I'd use C, if writting a large system I'd use Ada.  The advantage
>of Ada isn't in the debugger but in the compiler, eg
>
>C:
>typedef int cleared_flight_level;
>typedef int airspeed;
>
>airspeed a = 4;
>cleared_flight_level cfl = 5;
>
>...
>
>cfl = a;

  We don't check for this, yet, but it has been done by at least
  one interpreter for C.

  Just because many/most C programmers chose to not use a checking
  environment doesn't mean C can't be quite safe.  When we wrote the
  standard, we made sure that checking was allowable, although not
  required.  It's a matter of philosophy and choice.

---------------------------------------------------------
Terry Colligan, President             terryc@tenberry.com
Tenberry Software, Inc.           http://www.tenberry.com

*InstantC C interpreter/incremental compiler for Windows:
         More reliable C code developed in half the time!

info@tenberry.com  phone:(508)653-6006  fax:(508)655-2753

Re: Any research putting c above ada?

[Larry J. Elmore]

Terry Colligan <terryc@tenberry.com> wrote in article
<33636746.328095140@client.ne.news.psi.net>...
> Steve Jones - JON <jon@hpodid2.eurocontrol.fr> wrote:
> 
> >haggedk1@ulysses.jhuapl.edu (CubanPete) writes:
> >
> >[snip]
> >> Come on now Phil.  There is no language that produces software that
> >> works "more right" than another.  Software is either right or it is
> >> not.   Ada may have a great debugger but VMS types will argue all day

The fact is that most Ada implementations don't need (or have) "great"
debuggers because a _lot_ less debugging is needed compared to C/C++. The
bugs are hardly ever as obscure and difficult to find as with C/C++.

> >On my last project we use C and Ada, the bug count in the Ada code was
> >over 1/3 that of the C code. And tracking down bugs in Ada is much
easier,
> >the code falls over it tells you the brief reason (eg constraint error)
and
> >the line at which the error was raised and the stack trace.  You can
then add
> >exception handlers et al to secure the system. It provides in built
range
> >checking and strong typing.
> >
> >In C assigning to an unitialised pointer will cause either a crash or
> >wild behaviour and never tell you, in Ada it will crash and tell you
why.
> 
>   A checking C environment will stop and tell you, as well.  Just
>   because most C environments don't do much checking doesn't mean it
>   can't be done.  Any assignment using an uninitialized pointer in our
>   InstantC incremental environment will tell you nicely that you have
>   just tried to use an uninitialized pointer.

Sure, it can be done. Just flip through any programming magazine like DDJ
or something similar and just _count_ how many (expensive) tools and
packages there are to catch all kinds of _extremely common_ C/C++ bugs.
It's better to use a language that helps one avoid the bugs in the first
place...

>   I am not offering any data or opinion about Ada vs C, since I don't
>   use Ada -- I'm just saying C can be made pretty safe, if you choose
>   to.

With how many hundreds of dollars of add-on tools?
Assembly language can be just as safe with a suitably highly-skilled,
highly-disciplined programmer. The point is that it is easier for the
average, run-of-the-mill programmer to write higher-quality code with Ada
than with C. Code that works right the first time.

-- 
-----------------------------------------------------
Larry J. Elmore
Bozeman, Montana

"And they shall beat their swords into plowshares."
--Isaiah 2:4

"History teaches us that those who beat their swords into plowshares
usually end up plowing for those who kept their swords."
--Anon.

Re: Any research putting c above ada?

[Terry Colligan]

"Larry J. Elmore" <ljelmore@montana.campus.mci.net> wrote:

>Terry Colligan <terryc@tenberry.com> wrote in article
><33636746.328095140@client.ne.news.psi.net>...
>> Steve Jones - JON <jon@hpodid2.eurocontrol.fr> wrote:
>> 
>> >haggedk1@ulysses.jhuapl.edu (CubanPete) writes:
>> >
>> >[snip]
>> >> Come on now Phil.  There is no language that produces software that
>> >> works "more right" than another.  Software is either right or it is
>> >> not.   Ada may have a great debugger but VMS types will argue all day
>
>The fact is that most Ada implementations don't need (or have) "great"
>debuggers because a _lot_ less debugging is needed compared to C/C++. The
>bugs are hardly ever as obscure and difficult to find as with C/C++.

 <snip>

>> >In C assigning to an unitialised pointer will cause either a crash or
>> >wild behaviour and never tell you, in Ada it will crash and tell you
>why.
>> 
>>   A checking C environment will stop and tell you, as well.  Just
>>   because most C environments don't do much checking doesn't mean it
>>   can't be done.  Any assignment using an uninitialized pointer in our
>>   InstantC incremental environment will tell you nicely that you have
>>   just tried to use an uninitialized pointer.
>
>Sure, it can be done. Just flip through any programming magazine like DDJ
>or something similar and just _count_ how many (expensive) tools and
>packages there are to catch all kinds of _extremely common_ C/C++ bugs.
>It's better to use a language that helps one avoid the bugs in the first
>place...

  Most of us don't have a choice as to the language that we use --
  or if we did, we made that choice long ago, and now have 400,000
  lines of investment tying us to the choice we made.

  It may well be that Ada is more effective at producing bug-reduced
  code than is C (the stories are impressive!), but I'm not is a
  position to use Ada, so it's kind of like saying that sex
  with Claudia Sheiffer is better than with your wife -- it may be
  true, but it doesn't do you a lot of good! ;-)

>>   I am not offering any data or opinion about Ada vs C, since I don't
>>   use Ada -- I'm just saying C can be made pretty safe, if you choose
>>   to.
>
>With how many hundreds of dollars of add-on tools?

  Who cares, if the problems can be solved?  All of the tools are
  *very* cheap, compared to the price of programmers.

>Assembly language can be just as safe with a suitably highly-skilled,
>highly-disciplined programmer. 

  Actually, probably not.  But even if it were true, there are no
  tools available to make assembly language safer, while there are
  for C.

>The point is that it is easier for the
>average, run-of-the-mill programmer to write higher-quality code with Ada
>than with C. Code that works right the first time.

  It might be true, but so far the average consumer of C is worried
  about other things, particularly available tools, compatability,
  performance, etc.

  When 1) C programmers' managers make quality the most important
  issue and 2) Ada is widely believed to be more effective at quality,
  the C community will add more Ada-like features to C.

  In the meantime, if people would like a nice, safe, checking C
  environment, I know where they can get a great one!

---------------------------------------------------------
Terry Colligan, President             terryc@tenberry.com
Tenberry Software, Inc.           http://www.tenberry.com

*InstantC C interpreter/incremental compiler for Windows:
         More reliable C code developed in half the time!

info@tenberry.com  phone:(508)653-6006  fax:(508)655-2753

Re: Any research putting c above ada?

[James S. Rogers]

Kevin D. Quitt wrote:
> 
> I've written bullet-proof code for spacecraft and medical systems, code
> that must not under any circumstances fail in any but known and controlled
> ways.  I've done it FORTRAN, C, C++, and assembler (not necessarily
> combined).  It's not the language or the compiler that makes it safe, it's
> the programmer.

Yes, this is the common rebuttal from C and C++ people.  This approach makes
software development a lot like juggling knives.  It is completely safe as long
as you are very good and your attention does not wander.

Jim Rogers
Colorado Springs, Colorado
--------------------------
Team Ada

Re: Any research putting c above ada?

[Danette & Murray Root]

On Fri, 11 Apr 1997 22:38:29 -0600, "James S. Rogers"
<JimMaureenRogers@worldnet.att.net> wrote in comp.lang.c:

=> Kevin D. Quitt wrote:
=> > 
=> > I've written bullet-proof code for spacecraft and medical systems, code
=> > that must not under any circumstances fail in any but known and controlled
=> > ways.  I've done it FORTRAN, C, C++, and assembler (not necessarily
=> > combined).  It's not the language or the compiler that makes it safe, it's
=> > the programmer.

=> Yes, this is the common rebuttal from C and C++ people.  This approach makes
=> software development a lot like juggling knives.  It is completely safe as long
=> as you are very good and your attention does not wander.

Re-read. This is not a 'C and C++' rebuttal, this is a software engineer's
rebuttal. Safe programs can be written in almost any language, as long as the
system is DESIGNED and CODED to be safe, without depending on the
compiler/assembler/whatever to catch the errors. It is the difference between
'software engineering' and 'programming'.


<><><><><><><><><><><><><><><><><><><><>

Wizard's First Rule:
    People are stupid.
Wizard's Second Rule:
    Never depend on the first rule.

<><><><><><><><><><><><><><><><><><><><>

Re: Any research putting c above ada?

[Steve Summit]

[posted and mailed]

In article <334F11C5.F7B@worldnet.att.net>, "James S. Rogers"
<JimMaureenRogers@worldnet.att.net> writes:
>Kevin D. Quitt wrote:
>> I've written bullet-proof code for spacecraft and medical systems, code
>> that must not under any circumstances fail in any but known and controlled
>> ways.  I've done it FORTRAN, C, C++, and assembler (not necessarily
>> combined).  It's not the language or the compiler that makes it safe, it's
>> the programmer.
> 
> Yes, this is the common rebuttal from C and C++ people.  This approach
> makes software development a lot like juggling knives.  It is completely
> safe as long as you are very good and your attention does not wander.

So, while we're putting words in each other's mouths, may I
categorize yours as a common rebuttal from Ada people claiming
that mission-critical software written in a safety-enforcing
language is bound to be perfectly safe even if written by
careless, ignorant programmers?

					Steve Summit
					scs@eskimo.com

[P.S. No, I don't believe that "mission-critical software
written in a safety-enforcing language is bound to be perfectly
safe," nor do I believe that this is a "common rebuttal" from
"Ada people."]

Re: Any research putting c above ada?

[David Weller]

In article <3359e813.340466234@news.pacificnet.net>,
Kevin D. Quitt <Kevin@Quitt.net> wrote:
>ways.  I've done it FORTRAN, C, C++, and assembler (not necessarily
>combined).  It's not the language or the compiler that makes it safe, it's
>the programmer.
>
Kevin,
Nobody has any doubt that you've written safe, effective software in
FORTRAN, C, or C++, or even assembler.  

I think your implication that Ada developers lean entirely on the
compiler is specious.  A careful comparison of C++ to Ada 95 would
yield these observations:

	1) There is more compiler-generated checking in Ada 95 than in
	C++.  These checks are typically things that are commonly
	overlooked in software development, particularly in large
	systems.  These compile-time checks have no effect on the
	efficiency of the generated code.

	2) Ada95 has _significantly_ more run-time checking than C++
	has.  Any run-time check obviously has an impact on
	efficiency, but when you field a system in Ada, you simply
	turn those run-time checks off (if you so desire).

	3) Because of the increased amount of compile-time checking
	(as well as a few other factors), Ada95 compilers are much
	more capable of generating efficient code compared to C++.
	Before you (or anybody else) challenges such assertions, I
	will add that there has yet to be (to my knowledge) such a
	comparison made, but it can be discerned by analysis of the
	two languages.

	4) You will generally write no more, if not less, code in
	Ada95 than you would to accomplish the same task in C++. (This
	is heresy to many, but the simple truth.  It was also
	certainly the opposite, in some cases by an order of
	magnitude, when comparing Ada_83_ to C++).  My general
	observations is that your Ada95 code can be up to around 10%
	smaller than equivalent C++ code, give or take 10%.  I don't
	think having code 10% smaller really _proves_ much, but it
	dispels the perception Bjarne Stroustrup prepetuated in his
	book, "The Design and Evolution of C++" (an excellent book, by
	the way, should be part of any computer scientists library),
	where he indicated the Booch Components in Ada83 took 125K
	lines of code, and the C++ version took ~12K of code.  The Ada
	95 version of the Booch Components will take ~10K, and that's
	from a faithfully direct translation of the C++ version.
	Those numbers I have on very good authority, since the author
	of the Ada95 components is a close personal friend of mine :-)

	5) Speaking of tasking...nah, never mind, that's a separate
	subject.

Carefully note that NONE of my points above are saying: Individually,
if you use language X, you'll be a better programmer than in language
Y.  It is quite possible to do "unsafe" things in Ada95 and to
circumvent the _support_ that the compiler and run-time environment give
you, but those "circumventions" practically stand up and scream at
others that see the code.  I've learned, over years of programming in
both Ada95 and C++, that I find MUCH more errors in my code during
execution with my C++ code than I do my Ada code.  I'm not a shoddy
programmer in either.  It doesn't really take a rocket scientist to
understand that it's easier to find and fix problems that the compiler
catches than it is to become an expert on reading stack traces from
core dumps.

Nuf sed.  I'm sure I'll start a flame war now with the crossposting
going on.

-- 
Booch Components Homepage: www.rivatech.com ||Ada Homepage: www.adahome.com
------NOTICE-----NOTICE-----NOTICE-----NOTICE-----NOTICE-----NOTICE--------
My new e-mail address is dweller@imagin.net.  The dweller@dfw.net address will 
	   terminate _totally_ (no forwarding) at the end of April  

Re: Any research putting c above ada?

[Dave Wood]

Kevin D. Quitt wrote:
> 
> On 11 Apr 1997 14:02:35 +0200, Steve Jones - JON
> <jon@hpodid2.eurocontrol.fr> wrote:
> >C is popular, it is quick and dirty, but I wouldn't like to trust my life to
> >it.
> 
> I wouldn't trust my life to software that was written in such a way that
> it required the compiler to guarantee that it was safe.  If you can write
> safe software, you don't need to have the compiler covering your ass.
> I've seen more bad code written because "the compiler will catch it".
> 
> I've written bullet-proof code for spacecraft and medical systems, code
> that must not under any circumstances fail in any but known and controlled
> ways.  I've done it FORTRAN, C, C++, and assembler (not necessarily
> combined).  It's not the language or the compiler that makes it safe, it's
> the programmer.

It's all of the above and more (don't forget the operating system/
kernel
and operating environment.)

But this isn't really the point.  A very small fraction of software is
actually built according to the highest safety critical standards (level
A, where an error results in loss of life), even when it should be.
Look at the pathetic automotive industry, for example.

Further, even where safety criticality is not at issue, we still want
our software to be highly reliable.  Even for an ATM, spreadsheet, or
for that matter a game.  We pay good money for these things or spend
good time working with them, and we want them to be highly reliable.

But most software is hacked by average programmers with ordinary tools, 
not in a rigorous environment implied by your anectdotal bullet-proof
code.

It seems to me we are much better off in a world where our tools improve
the average and raise the lowest common denominator which ultimately 
causes an across-the-board improvement in our minimal standards and
expectations.

You can argue that Ada doesn't accomplish this goal comparative to C
or C++ (having spent a lot of time developing in all three, I have to
heartily disagree, but never mind.)  However, I can't see how one can
argue that we aren't all better off having better tools in everyone's
toolchest to give us a better chance of solving more problems 
satisfactorily.  You may be the world's finest programmer, but unless
you personally write all software that will ever effect your life, 
then you are better off if the tools (and methods, and operating
systems, and languages, etc.) used by the computing community improve
to reduce the introduction of as many errors in as many situations
as possible.

I can cook very well if I take the time and effort to do it right,
but sometimes I want to go to a restaurant.  I will eat with more
pleasure knowing that the kitchen has been certified to meet the
proper standards for water temperature (for cleaning), for 
cleanliness, for food storage, that they buy their food from
the best and freshest sources, and that they have the best
equipment to do the job.  Of course, I also want the cook to be
well trained and innately talented, but that in and of itself isn't 
quite enough, at least to ensure that I won't walk away feeling
sick or dissatisfied.

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Any research putting c above ada?

[Dave Wood]

Kevin D. Quitt wrote:
> 
> On Sat, 12 Apr 1997 23:51:47 -0700, Dave Wood <dpw@aonix.com> wrote:
> >It seems to me we are much better off in a world where our tools improve
> >the average and raise the lowest common denominator which ultimately
> >causes an across-the-board improvement in our minimal standards and
> >expectations.
> 
> I have a real problem with this.  It's a nice idea to have tools that help
> us.  It's nice for the bad and mediocre programmers that certain language
> features and tools can help them turn out better-quality code than they
> themselves are capable of.  But I think it's bad for everybody else.  No
> automated tools or language can *make* a programmer turn out high-quality
> code.  And while these tools may help prevent bad code, they present the
> illusion that the code turned out is therefore *good*; this illusion is
> dangerous.

Of course tools can't make a bad programmer a good one.  This isn't the
point.  The point is, even the best programmers make mistakes, sometimes
stupid little ones and sometimes insidious big ones.  To the extent that
our languages and tools can help us to reduce these, everybody wins.

The opposite notion, that having better tools will lead to laziness
and poorer quality, is sheer fantasy.  

> Don't get me wrong, I don't think we should all program in assembly
> language or the apocryphal "cat >a.out".  I like strong typing (as long as
> it can be overridden) and I love prototyping.  But any language that does
> not allow me to override the safety features is not useful.  Any system
> that does not let the programmer take responsibility for bypassing the
> safes is *wrong*.

Ada certainly permits you to do just about any stupid thing you want
to do, however unlike C/C++ stupidity is not the default.  Generally 
speaking, you must actively and knowingly enact the stupidity.

> >...you are better off if the tools (and methods, and operating
> >systems, and languages, etc.) used by the computing community improve
> >to reduce the introduction of as many errors in as many situations
> >as possible.
> 
[snip about arianne]
>
> There is nothing in any language, or any tool, that can prevent this kind
> of problem, because it's not a programming problem.  It's a design problem
> that comes from people who don't bother to design what they're doing.
> They just program.

Right.  And the less focus that needs to be on the niggling details of
proper programming, the more focus can be spent where it helps the most:
nailing down the real requirements and laying out the best design.

You set up a little red herring there, because I wasn't arguing that
a better language would have prevented the arianne explosion.  Clearly
not.  What I was arguing is that to the extent that technology exists
to help us reduce a certain class of errors (in this case programming
and runtime errors) we will do well to use it.  Arianne was of course
a screw-up of a different class of errors, however design and management
flaws were not the thread to which I was responding.  Let's stay on 
topic.

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Any research putting c above ada?

[David Hanley]

Dave Wood wrote:
>  I recall listening a few years ago
> to a learned fellow (ironically enough, one of the "big names" in
> the Ada community) describing that debuggers were a Bad Thing and
> should never be used, because they lead programmers to laziness and
> complacency.  A proper programmer, he argued, would not make mistakes
> where a debugger would be needed.
> 
> While interesting in an academic context (the exact context where
> the argument was made, actually), I find the idea absurd in any
> practical sense, and I have to think nearly everyone out there
> would agree.

	I also think that debuggers are bad, but not that hey should 'never'
use used.  I think that they are hardly ever necessary if the code is
properly designed.  Either the bug will not occur, or it will obviously
be in module 'x'  function 'y' because of the resultant incorrect
behaviour.

	You mileage may vary, of course.  

>  Any tool that helps me to locate, identify, and
> eliminate errors, so that I can spend more time focusing on the
> problem space rather than the implementation, is a tool I want in
> my arsenal.  This would be true regardless of the programming
> language involved.

	True.  My objection is that many programmers use the debugger to watch
what their code is doing as a replacement for understanding it.  

	dave

Re: Any research putting c above ada?

[Nick Roberts]

David Hanley <david@nospan.netright.com> wrote in article
<3357C6C5.27F@nospan.netright.com>...
[...]
> 	I also think that debuggers are bad, but not that hey should 'never'
> use used.  I think that they are hardly ever necessary if the code is
> properly designed.  Either the bug will not occur, or it will obviously
> be in module 'x'  function 'y' because of the resultant incorrect
> behaviour.
> 
> 	You mileage may vary, of course.  
> 
[...]
> 	True.  My objection is that many programmers use the debugger to watch
> what their code is doing as a replacement for understanding it.  


My own feeling, observing (quite a number of) other programmers learning to
program, is that a good (and it is extremely important that it is good)
symbolic debugger can aid the learning process tremendously, because it
illuminates what is really going on as a result of the source code written.
Of course, students who don't understand the underlying machine
architecture very well tend to get confused. But then, they tend to make
very little progress anyway, until they start learning about how computers
really work (i.e. machine code).

Many highly experienced, and truly productive, programmers I have worked
with swear by debuggers, and would be lost without them. Personally, I
never use a debugger, in any language. I actually find them more trouble
than they're worth. Instead, I usually (almost subconsciously) insert
debugging code into the source code, in the (always correct) anticipation
that it will be needed. It gets excised when it is no longer needed. I have
written some truly big software this way, so I think that proves, well
enough, that debuggers do not _have_ to be used.

On the other hand, I don't think a sensible compiler vendor would even
dream of attempting to market a product (Ada or other) which didn't have
debugging facilities. I think it would be wrong to do so, anyway: as I have
said, there are some excellent programmers out there to whom a debugger is
as mother's milk. It seems to me that this emphasises a great truism that
programming is still (and will be for a long time to come) an essentially
_human_ activity. We all know how different people tend to be: it would
surely be surprising if it were not the case that different programmers
tend to have radically different approaches to the art of programming.

Nick.

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3373409f.494266577@news.pacificnet.net>,
Kevin D. Quitt <Kevin@Quitt.net> wrote:

>I have a real problem with this.  It's a nice idea to have tools that help
>us.  It's nice for the bad and mediocre programmers that certain language
>features and tools can help them turn out better-quality code than they
>themselves are capable of.  But I think it's bad for everybody else.  No
>automated tools or language can *make* a programmer turn out high-quality
>code.  And while these tools may help prevent bad code, they present the
>illusion that the code turned out is therefore *good*; this illusion is
>dangerous.

This is absolutely true. We have to remember that the purpose of a tool
is not to ensure that correct code is produced, but to _reject_ code which
is obviously incorrect. You can cut fat away from a steak, but there will
always be some left behind, even if it's in between the muscle fibers! If
you cut too much, you will throw out the meat with the fat, and yet still
leave fat behind. (*) 

>You've seen some of it above.  Turning a bad programmer into a mediocre
>one serves nobody and nothing.  I'd rather it just be know the
>programmer's bad, and weed them out.

That's a good point. Just because the tool has forced you to fix some
``trivial'' error doesn't mean that you understood why it had to be fixed.
Poor programmers will just hack and slash a program until it is accepted
without complaint -- for example by inserting clever coersion operators when
the translator complains of type mismatches (it's not like Ada doesn't have
coersion!). To someone (e.g. in management) who trusts compilability as an
indication of program correctness, such a tool eradicates the difference
between a poor, mediocre or good programmer.

--
(*) This stupid analogy is not to be construed as an implication that
I'm a flesh eater. Those Venn diagrams did always look like rib-eye
steaks to me, though.

Re: Any research putting c above ada?

[Robert S. White]

In article <3373409f.494266577@news.pacificnet.net>, Kevin@Quitt.net says...

>I would much rather have a development environment like UNIX where
>dereferencing a NULL pointer is going to dump, than MS-DOS, where you
>*might* get a message when the program exits.  I *don't* like systems that
>can fail silently.  On the other hand, I don't want to have to incur the
>overhead in continual run-time checking.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>But any language that does
>not allow me to override the safety features is not useful.  Any system
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>that does not let the programmer take responsibility for bypassing the
>safes is *wrong*.

   But every Ada compiler that I have used DOES let us deliberately 
turn off the run time checks!  So what is your point here?  We leave
the checks on during unit level tests and early integration tests.  
Then the project librarian/project engineer can choose to turn checks
off on the high rate realtime tasks if the through-put benefits are
required.

  Have you ever really used Ada?
_____________________________________________________________________
Robert S. White                  -- an embedded sys software engineer

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5is19p$g3i@flood.weeg.uiowa.edu>,
Robert S. White <WhiteR@CRPL.Cedar-Rapids.lib.IA.US> wrote:
>In article <3373409f.494266577@news.pacificnet.net>, Kevin@Quitt.net says...
>>But any language that does
>>not allow me to override the safety features is not useful.  Any system
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>that does not let the programmer take responsibility for bypassing the
>>safes is *wrong*.
>
>   But every Ada compiler that I have used DOES let us deliberately 
>turn off the run time checks!  So what is your point here?  We leave

So every C compiler I have used lets me ignore compiler time diagnostics
that don't lead to translation failure.  I think Kevin was talking about
static safety features, though, and language features that let you override
these features (rather than compiler options).

>the checks on during unit level tests and early integration tests.  

Such tests often don't have full coverage. A good language would force the
run-time checks to remain in the production code. Or are you saying that safety
should take a back seat to speed when it comes time to ship the code? Maybe Ada
programmers are not that different from other programmers after all.

>Then the project librarian/project engineer can choose to turn checks
>off on the high rate realtime tasks if the through-put benefits are
>required.

Ah I see. ``The code is too slow! Checking be damned''.  :)

Re: Any research putting c above ada?

[Robert S. White]

In article <5itlph$1k9@bcrkh13.bnr.ca>, kaz@vision.crest.nt.com says...

>So every C compiler I have used lets me ignore compiler time diagnostics
>that don't lead to translation failure.  I think Kevin was talking about
>static safety features, though, and language features that let you override
>these features (rather than compiler options).

  I am talking about compiler options (just like setting Visual C for a 
"release build").  Again I am confused, what exactly is your point here?
I still don't see the diff using Ada.  What are "language features that 
let you override >these features (rather than compiler options)"?

>Such tests often don't have full coverage. A good language would force the
>run-time checks to remain in the production code. Or are you saying that 
>safety should take a back seat to speed when it comes time to ship the 
>code? Maybe Ada programmers are not that different from other programmers 
>after all.

  Why FORCE extra stuff at runtime that might already have been thoroughly
tested?  If your can afford it, OK, let the good tool/language do it.  If
you can't...test it properly and then turn off the runtime checks.  Duh!

>>Then the project librarian/project engineer can choose to turn checks
>>off on the high rate realtime tasks if the through-put benefits are
>>required.
>
>Ah I see. ``The code is too slow! Checking be damned''.  :)

  No...It is although a deliberate design tradeoff...we have to give
up on the Ada runtime checks after all the normal testing has been 
conducted to find (hopefully all) the errors in the code and it is 
neccessary to turn off checks to meet runtime deadlines or data 
latencey requirements.  Welcome to the cold hard world!  But it is 
silly to give up on a good tool and not let it continue to help you 
when it does not add TOO much burden.  Only turn off checks when you 
HAVE TOO not "Checking be damned".  Catch my drift?
_____________________________________________________________________
Robert S. White                  -- an embedded sys software engineer

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5ivtcu$puv@huron.eel.ufl.edu>,
Daniel P Hudson <afn03257@stuff.afn.org "Dan"> wrote:
>>  I am talking about compiler options (just like setting Visual C for a 
>>"release build").  Again I am confused, what exactly is your point here?
>>I still don't see the diff using Ada.  What are "language features that 
>>let you override >these features (rather than compiler options)"?
>
>Kaz's soul point is to not let you prove that there is ever a condition
       ^^^^ that's sole. But don't take my word for it, I'm just an immigrant.

>in which C should NOT be used. He is just like Scott Nudds, but follows
>a different God that failed.

Say, didn't you just troll with this bit of nonsense, referring to the
IBM PC:

->   Perhaps you knew of a better micro-processor for systems that could
->   fit on the average desktop? It just so happens that the 8086 was
->   state of the art back then.

Can you say, MC68000?

Re: Any research putting c above ada?

[Byron]

Kaz Kylheku wrote:
> 
snip..
> 
> Say, didn't you just troll with this bit of nonsense, referring to the
> IBM PC:
> 
> ->   Perhaps you knew of a better micro-processor for systems that could
> ->   fit on the average desktop? It just so happens that the 8086 was
> ->   state of the art back then.
> 
> Can you say, MC68000?

I believe you've got one too many zeros - it was the MC6800.

-- 
Byron

Re: Any research putting c above ada?

[John Winters]

In article <3354C4D5.22ED@lmtas.lmco.com>,
Byron  <Byron.B.Kauffman@lmtas.lmco.com> wrote:
>Kaz Kylheku wrote:
>> 
>snip..
>> 
>> Say, didn't you just troll with this bit of nonsense, referring to the
>> IBM PC:
>> 
>> ->   Perhaps you knew of a better micro-processor for systems that could
>> ->   fit on the average desktop? It just so happens that the 8086 was
>> ->   state of the art back then.
>> 
>> Can you say, MC68000?
>
>I believe you've got one too many zeros - it was the MC6800.

That depends on what "it" is.  The MC6800 was an MC6800 and the MC68000
was (and is?) an MC68000.  Oh, if only IBM had used the 68000 for their
PC.  (The MC68000 was introduced in 1979.)

John

(Note follow-ups)
-- 
John Winters.  Wallingford, Oxon, England.

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5j31dt$o3j@huron.eel.ufl.edu>,
Daniel P Hudson <afn03257@stuff.afn.org "Dan"> wrote:
>
>kaz@vision.crest.nt.com (Kaz Kylheku) wrote:
>
>Damn, I'm gonna have to expand your twit scope to all usenet newsgroups,
>I see. It is so peaceful not reading you or Peter, or Craig's flames
>on poor unsuspecting newbies who make a simple mistake. Too bad people
>reply to them or I'd never see that much.

If you note, most comp.lang.c flames are directed at cocky, yet incorrect
attempts to answer newbie questions and those unsuspecting newbies who want
their homework served on a silver platter. Most of the c.l.c regulars
in fact act as champions for the downtrodden newbie, defending them from
misinformation.
 
>>>Kaz's soul point is to not let you prove that there is ever a condition
>>       ^^^^ that's sole.
>
>At least you don't deny it. BTW you do know what grammar/spelling
>flames are considered by that precious netiquette [the one you're
>always bitching about people not following] of your's don't you?

Look whatever. A spelling flame is still one notch above some low blow like
comparing someone to Scott Nudds, isn't it? That's where I draw the line. :)

>Actually that post got sent out without my control, the system crashed
>in the middle of my writing, you know how AIX gets sometimes, It just
>stops accepting input for no apparent reason and then does all sorts of
>crazy stuff. It also resent out the message with the edited version
>later on, I'm told. What can you expect from something written in C. ;-)

Ah, right! And you conveniently forgot the digital signature. Well, you know
what? I didn't write that spelling flame either. In fact, I'm not the
author of this very article; it was just written by someone _called_ Kaz. :)

>>->   Perhaps you knew of a better micro-processor for systems that could
>>->   fit on the average desktop? It just so happens that the 8086 was
>>->   state of the art back then.
>
>>Can you say, MC68000?
>
>Can you say cost effective?
>
>The i8088, more specifically than the i8086, was small, technologically
>and advancement over previous CPU's [4004 etc..] and cost efficient.
>
>The Motorolla MC68000 was small, technologically advanced, and TWICE
>the cost. PC's were expensive enough already, thank you. Plus, the 68000

Well, twice the cost of a processor doesn't necessarily translate to twice
the cost of the whole box: the processor cost is amortized over the the whole
unit. Also, remember that the 68K is easier to interface.  The 8088 had to
carry an external address decoder, for instance, due to its multiplexing of
data and address lines. This multiplexing saved 8 data pins, but three
additional lines had to be used to decode the state of the 8088. Thus, a total
saving of 5 pins bought by adding a bunch of other logic!

On the other hand, there wasn't an 8 bit version of the 68K yet (I don't
think): you needed a 16 bit data bus and that was that. This was probably
significant---after all they did choose 8088 in favor of 8086.

>was an extremely slow chip, even compared to the 8086/8088. Add to that

I doubt that. The clock cycle counts for many 68K instructions are about on par
with 8086 instructions. But the 68K instructions do more.

>the additional cost in memory chips, and its easy to see why IBM choose
>Intel. Why? They are a business and Intel offered the best deal. As to

I suspect it was more because of existing assembly language software written
for the i8080 that, though not binary compatible, could be translated at the
source code level to 8086 code. It was all in the spirit of good old
backward compatibility coupled with a lack of foresight, rather than technical
innovation.  Did the IBM team not originally plan to bundle some CPM/86 type
thing with the PC? My recollection is hazy. 

Thanks to IBM, the comp.lang.c newsgroup still fields questions like ``Help, I
have 32 megs of RAM, but I can't make arrays bigger than 64K, and halloc()
craps out at 500K!''

>proof of the success over using Intel over Motorolla, look at Apple and 
>IBM clones [Obviously IBM makes more than PC's] and compare. Clones
>are growing at a rate of at least 50% a year [Gateway 2000 is 100%]
>and Apple is, oh that's right, down sizing. I asked for a reasonable
>replacement, not one that would have put IBM under, Kaz.

So now you are saying that it was the Motorola processor that is responsible
for Apple's failings? If IBM had gone with the 68K, the PC would have gone
under? Interesting hypothesis, and so conveniently untestable, too!

Re: Any research putting c above ada?

[David Thornley]

In article <5j31dt$o3j@huron.eel.ufl.edu>,
Daniel P Hudson <afn03257@stuff.afn.org "Dan"> wrote:
>
>>->   Perhaps you knew of a better micro-processor for systems that could
>>->   fit on the average desktop? It just so happens that the 8086 was
>>->   state of the art back then.
>
>>Can you say, MC68000?
>
>Can you say cost effective?
>
>The Motorolla MC68000 was small, technologically advanced, and TWICE
>the cost. PC's were expensive enough already, thank you. Plus, the 68000
>was an extremely slow chip, even compared to the 8086/8088. Add to that
>the additional cost in memory chips, and its easy to see why IBM choose
>Intel. Why? They are a business and Intel offered the best deal. As to
>proof of the success over using Intel over Motorolla, look at Apple and 
>IBM clones [Obviously IBM makes more than PC's] and compare. Clones
>are growing at a rate of at least 50% a year [Gateway 2000 is 100%]
>and Apple is, oh that's right, down sizing. I asked for a reasonable
>replacement, not one that would have put IBM under, Kaz.

IBM went with the lowest-cost option, the 8088, that could use more
than 64K of memory.  (I've read that they almost went with the 6502!)
The 8086 was slightly more expensive, and required sixteen RAM
chips minimum (one for each line on the data bus), as opposed to
the 8088 which required eight chips.  An additional attraction of the
8086/8088 series was that 8080 assembler code could be retargetted
for the 8086/8088, with the added attraction that Microsoft Basic,
when it came out, ran slower on an IBM PC than on a nice Cromenco
box, with its mighty 4 MHz Z80.

The 68000, by the way, was not a slow chip.  When it started to
get popular, it was considered the approximate equivalent of an
80286 of the same clock speed.  Miserable by today's standards, but
fantastic at the time.  IBM produced some small computers based on
the 68000, which got critical acclaim, if not commercial success.

It is interesting to speculate on what might have happened if IBM
had gone for a chip of modern architecture, as opposed to one
constrained by the need for assembler source compatibility with
the 8008 (yes, those 8s and 0s are in the right order).

Nor is the success of the PC architecture due to its technical
merits, but rather to the initials on the box (for its first
several years) and to the slapdash way it was designed, making
it easy to copy (after that).  Apple, BTW, no longer uses 68Ks,
suffered from over a decade of boneheaded management, and is
primarily laying off people not involved in computer and OS
production.  Production of computers using the Mac OS continues
to rise, although Apple's market share is declining (last I saw,
it was still the largest individual market share, though).

This only leaves two main undiscussed questions:  Will I be lynched
by c.l.c. regulars for referring to porting assembler source, and
what does any of this have to do with C?

char *name = "David Thornley";

Re: Any research putting c above ada?

[Alan Bowler]

In article <338a1835.439086993@news.pacificnet.net> Kevin@Quitt.net writes:
>
>Business people hear "computer" and think "IBM".  It comes from the
>mainframe days where IBMs machines, while much less capable than the
>competition, and just as prone to break down, had a technician on-site 24
>hours a day, with two hours to escalate if the problem wasn't fixed.  The
>IBMs went done just as often, but they were up sooner.

The IBM systems also required the customer have twice as many systems
people to run the machine.  So a shop with two equivalent powered
machines had 2/3's of its employees tied to IBM skills.  This "breeds
experts" situation has occurred in a number of situations where a
somewhat technically inferior product tramples its competition in the
marketplace.  

Re: Any research putting c above ada?

[Daniel P Hudson]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

>Daniel P Hudson <afn03257@freenet2.afn.org> wrote in article

>There was another contender: the Zilog Z8000 (yes, with three noughts).
>This was their 16-bit follow-up to their spectacularly successful Z80. It

And what was its cost relation to the i8088? I'm asking because
I don't ctually know about this one. I do know the one Kaz
mentioned would have jacked the price of a PC up by about
$300-$1000.

>flopped. Not for technical reasons, but simply because the marketing muscle
>of such a (relatively) small company couldn't compete. The _real_ reason

If you have a product that is obviously technically superior or
technically equivalent and cheaper, large corporations will
gladly hear your plea.You just have to take the initiative to
get off your ass and discuss it with them.

>why IBM went for the Intel processor is because the No. 2 at IBM at the
>time - the instigator of the PC project - was friends with the CEO of Intel
>at the time (they were at college together). This is what is meant by "the
>power of networking."

You can believe what you want, but the pure and simple fact is
in business, friendship means nothing, IBM went with the best 
deal, not with the closest friend. IBM might have been willing
to pay a penny or two more per chip, but that wasn't the
difference between Intel's and most of the other competitors.
I have friends that own car dealers, but I don't buy from them
because they don't offer me the best deal. Now having a friend
at Intel may have gotten IBM the chips cheaper and thus both
proffited, but price was the ultimate reason the Intel
CPU's were chosen. That and the ease of which they fit into
existing system designs [the i8088 that is, the i8086 had 
problems].

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5jeh0n$7jg@huron.eel.ufl.edu> afn03257@freenet4.afn.org (Daniel P Hudson) writes:

   > "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

   > >Daniel P Hudson <afn03257@freenet2.afn.org> wrote in article

   > >There was another contender: the Zilog Z8000 (yes, with three noughts).
   > >This was their 16-bit follow-up to their spectacularly successful Z80. It

   Technically, there was no such beast.  The two major Z8k chip
families were the Z8001 and Z8002, which addressed different amounts
of memory.  There was also a Z800 which was much more of a competitor
to the i8088. 

  > And what was its cost relation to the i8088? I'm asking because
  > I don't ctually know about this one. I do know the one Kaz
  > mentioned would have jacked the price of a PC up by about
  > $300-$1000.

  Get your story straight.  The 68k family member that would be
comparable to the 8088 was the 68008, with an 8-bit data path.  IBM
made a calculated decision based on availability.  The Intel delivery
promise on the 8088 was much better than from Motorola on the 68008.
It would have been nice if IBM had twigged to the real market, since
the 8-bit memory access was only an advantage if you had less than 64K
of memory.  Very few early PCs were sold with less, and IBM for
marketing reasons quickly upped the minimum configuration sold to
128K.

  > If you have a product that is obviously technically superior or
  > technically equivalent and cheaper, large corporations will
  > gladly hear your plea.You just have to take the initiative to
  > get off your ass and discuss it with them.

   I was in the business at the time, and the four way competition was
a real horse race. (The other early player for the 16-bit market was
National with the 16000, later named the 32000 series.)  National lost
out by being late with necessary support chips, and Zilog spent too
much effort on the Z800, which no one wanted, instead of on support
chips for the Z8000 family.  Intel and Motorola were neck and neck for
over a decade.  (Actually, they still are.  But Intel's RISCy designs
the i860 and i960, never got the internal support needed, while
Motorola got IBM (huh?) and Apple to commit to the PPC family.)

   Intel had PC clones for a volume driver, Motorola had Sun and later
Apple, Stratus, and Commodore.  (More 68K family processor chips went
into Amigas than into Macs, in part because Apple shifted to the Power
PC family, and in part because many Amigas had two 68K processors in
them, including the one I am typing this on, and the one I use at
home.)  Stratus was important only because of the volume of 68K
processor chips in one "computer."  The 600 series had 18 68010's per
processor board, two processor boards per logical processor, and often
several logical processors per system.  Much later, and still today,
the 68K family shows up in process control sytems.

  > You can believe what you want, but the pure and simple fact is
  > in business, friendship means nothing, IBM went with the best 
  > deal, not with the closest friend. IBM might have been willing
  > to pay a penny or two more per chip, but that wasn't the
  > difference between Intel's and most of the other competitors.

   CPU chip cost was a non-issue.  Delivery of the volume of chips IBM
needed was a major driver.  When the 80286 (IBM PC/AT) and 80386 chips
started shipping IBM was gobbling most of Intel's production for the
first year.  I don't remember the statistics on the 8088, but you
could ask Intel or IBM, since it is now a history question.  I seem to
remember that IBM bought over two-thirds of the 8088s made.

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Stephen Leake]

Kevin D. Quitt wrote (in part):
> 
> I would much rather have a development environment like UNIX where
> dereferencing a NULL pointer is going to dump, than MS-DOS, where you
> *might* get a message when the program exits.  I *don't* like systems that
> can fail silently.  On the other hand, I don't want to have to incur the
> overhead in continual run-time checking.
> 

I recently ported some code from AIX (IBM's UNIX variant) to cygwin32
(Cygnus' POSIX layer for Win32). Under the AIX C libraries,
dereferencing a NULL pointer does NOT always cause a dump; it is often
handled in the way I would have if I had written the code correctly. But
under cygwin32 and the Cygnus C library, it does usually cause an access
violation. So is Win32 better than UNIX in this regard? I prefer the
Cygnus behavior, but it is just as permitted by the ANSI C standard as
the AIX behavior.

The lesson I get from this is that I want a well defined library. Ada
gives me that; C does not. There is an ANSI C library definition, but it
is vague on error handling, and there is not a widely used validation
method. The Ada library defines the error semantics, and has a widely
used validation suite.

> Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
> Per the FCA, this email address may not be added to any commercial mail list

-- 
- Stephe

Re: Any research putting c above ada?

[Larry Kilgallen]

In article <33508283.56DD@aonix.com>, Dave Wood <dpw@aonix.com> writes:

> Further, even where safety criticality is not at issue, we still want
> our software to be highly reliable.  Even for an ATM, spreadsheet, or
> for that matter a game.  We pay good money for these things or spend
> good time working with them, and we want them to be highly reliable.

And we pay good money to have the phone answered if the user of our
software has a problem with the software.  Such problems will always
exist, but minimizing them is an important goal so resources can be
spent in other areas.

Larry Kilgallen

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3359e813.340466234@news.pacificnet.net>,
Kevin D. Quitt <Kevin@Quitt.net> wrote:
>On 11 Apr 1997 14:02:35 +0200, Steve Jones - JON
><jon@hpodid2.eurocontrol.fr> wrote:
>>C is popular, it is quick and dirty, but I wouldn't like to trust my life to
>>it.
>
>I wouldn't trust my life to software that was written in such a way that
>it required the compiler to guarantee that it was safe.  If you can write
>safe software, you don't need to have the compiler covering your ass.
>I've seen more bad code written because "the compiler will catch it".

We take a lot of checking for granted, on the other hand. What if your compiler
did not perform type checking? What if it could not even properly diagnose the
use of undefined names or even pinpoint syntax errors? (I've recently worked
with such a language/implementation---believe me, I developed some checking
tools in a hurry!)

A language should be designed so that an implementation could catch as
many trivial errors as possible.  That way, we can focus on making spectactular
logic errors! :)

Re: Any research putting c above ada?

[Richard Riehle]

The contention is, by some, that one can develop safe software
as well in C or C++ as in Ada.  This is probably true if, in addition
to the C compiler, you also use the "checking" tools such as those
from Pure Software or Parasoft, or ... 

Ada is design to to the maximum possible checking at compile time, and
further checking at run-time.  The Ada type model, the distinction
between scope and visibility, the strict differentiation between parameter
modes, and the rigorous rules for safe pointers, all contribute to
improved software quality.  Also, Ada design practices tend to be more
like engineering than programming because the language structure leads
a software practitioner to focus early on architectural issues instead
of programming issues.  

To understand Ada, one typically needs to take an engineering view of the
software process.  Most programmers are not trained in engineering and
that lack of training manifests itself in the defect-ridden software
that populates the shelves of software stores, causes medical-devices
to crash during operating-room procedures, and jeopordizes the at-large
community daily.

Someone constrained by a lifetime of blindness will have difficulty
comprehending color.  A programmer with no understanding of engineering
may not see the difference between an engineering view of the software
process versus a computer-science view.  To really understand the value of
Ada, one must approach the software process from that engineering view.
This is not true of most other languages.  Therefore, it is easy to
learn C or C++ or Visual Basic and crank out reasonably effective software
which, when it crashes, is not lethal.  

Ada is the language of choice when failure is not an option.

Richard Riehle

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <Pine.GSO.3.95.970427131344.138C-100000@nunic.nu.edu>,
Richard Riehle  <rriehle@nunic.nu.edu> wrote:

>Someone constrained by a lifetime of blindness will have difficulty
>comprehending color.  A programmer with no understanding of engineering
>may not see the difference between an engineering view of the software
>process versus a computer-science view.  To really understand the value of

What is a computer-science view and how is it incompatible with a software
engineering view? Do I detect a slight bias against computer science folk?

Have you ever seen code written by engineers with no understanding of
computer science? :))

Re: Any research putting c above ada?

[Roy Grimm]

Kaz Kylheku wrote:
> 
> In article <Pine.GSO.3.95.970427131344.138C-100000@nunic.nu.edu>,
> Richard Riehle  <rriehle@nunic.nu.edu> wrote:
> 
> >Someone constrained by a lifetime of blindness will have difficulty
> >comprehending color.  A programmer with no understanding of engineering
> >may not see the difference between an engineering view of the software
> >process versus a computer-science view.  To really understand the value of
> 
> What is a computer-science view and how is it incompatible with a software
> engineering view? Do I detect a slight bias against computer science folk?

If I'm not mistaken, you may have just illustrated his point.

I was trained in the computer-science paradigm.  When I arrived at
Rockwell and started working on engineering projects, I was astounded to
see the difference between how I had done things before and how I had to
do them here.  At my previous position, we cranked out code.  Here, we
design and build software.  The focus here is on the design process and
how we can build software to meet the design.  At my former employer, we
were simply asked to crank out some code that did the job.  If it wasn't
quite right, we'd throw some fixes into it and release it again, and
again, and again until we either got it close enough or the buyer wanted
something completely different.  That kind of slip shod programming
doesn't fly very far here.

> Have you ever seen code written by engineers with no understanding of
> computer science? :))

I have.  Let me tell you, the code is atrocious.  However, it is only
slightly worse that code written by "computer scientists" with no
understanding of software engineering.  In both cases, I find that the
code is hacked together to fit what the person felt the design should
be.  The only real difference is that the computer scientis uses more
efficient algorithms than the engineer.

Almost any schmuck with a smattering of computer knowledge can crank out
code.  It takes a lot of good training and experience to become an
effective software engineer.

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <33674E4C.446B@cca.rockwell.com>,
Roy Grimm  <ragrimm@cca.rockwell.com> wrote:
>> What is a computer-science view and how is it incompatible with a software
>> engineering view? Do I detect a slight bias against computer science folk?
>
>If I'm not mistaken, you may have just illustrated his point.

I'm not sure how, by asking a mere question!

>I was trained in the computer-science paradigm.  When I arrived at
>Rockwell and started working on engineering projects, I was astounded to
>see the difference between how I had done things before and how I had to
>do them here.  At my previous position, we cranked out code.  Here, we
>design and build software.  The focus here is on the design process and
>how we can build software to meet the design.  At my former employer, we
>were simply asked to crank out some code that did the job.  If it wasn't
>quite right, we'd throw some fixes into it and release it again, and
>again, and again until we either got it close enough or the buyer wanted
>something completely different.  That kind of slip shod programming
>doesn't fly very far here.

That is slip-shod, but it doesn't seem to relate to my own computer science
background and experiences.

What was the focus of your computer science training? Was it largely
theoretical, or did it involve a lot of ``hands on'' work?

I remember one school project that I never even implemented. It was just a
paper outlining requirements and design. There weren't many software
engineering courses in the program, but there were two tough ones. One
two-semester long team project, and a course focusing on various topics
in software engineering. I've never been encouraged to just code something;
design was always the focus. We learned to admire an elegant design, rather
than implementations. There were courses in which one cranked out code;
the upper level courses were very oriented toward implementation, although
there was a large gap between the implementation assignments and the 
``theory'' matter which was the subject of examinations making up most of
the mark. The assignments did encourage a lot of coding in little time 
simply because of the time constraints of the curriculum and the overall
hurried pace. It could well be that some people took this too seriously, and
got the wrong message as a result.

Throughout school, I hustled my own contract work. I've always insisted on
going through a requirements analysis with the clients, as well as walking
through some of the less technical aspects of the design. I thought that this
was what computer scientists were supposed to do, and since I was trying to
become one, I emulated the behavior. I actually find that I even looked for
ways in which computers can be _avoided_ rather than blindly advocating their
use for every problem or subproblem. You don't just throw code at
everything in sight!

However, over the years I've had the chance to talk to a few graduates from
other computer science programs and was surprised at the diversity of
experiences. One student complained that his whole undergraduate career was
``all theory'' geared toward further studies. He never got to do any projects
involving real implementation.  He claimed to have gained next to no experience
with things like networking, graphical interfaces or concurrent programming. I
was shocked when he revealed to me that he allegedly studied at MIT!

It's hard to say anything about the nature of computer science training,
since it seems to vary a great deal from institution to institution.

>> Have you ever seen code written by engineers with no understanding of
>> computer science? :))
>
>I have.  Let me tell you, the code is atrocious.  However, it is only

I was only joking, and playing on the multiple meanings of ``engineer''.
It's clear that the discussion is about software engineers, not civil or
electrical engineers! :) These latter guys tend to write 500 line procedures
with repeated code that is not factored into subprograms. (This is just an
observation based on a limited sample, not meant to generalize to all
engineers. :)

>slightly worse that code written by "computer scientists" with no
>understanding of software engineering.  In both cases, I find that the
>code is hacked together to fit what the person felt the design should
>be.  The only real difference is that the computer scientis uses more
>efficient algorithms than the engineer.

How is that? Are you saying that the computer scientist had a very rigid
design, and hacked the code to fit that design rather than going through a more
iterative approach to find a more suitable or flexible design? Or perhaps the
fellow didn't spend enough time on the design, and ended up with something
having a narrow scope.  Rather than indicating no training in software
engineering, that could simply indicate a training in old-style software
engineering, whereby a team is supposed to go through through requirements,
design, implementation and testing stages in one swoop, leaving behind a
massive paper trail of inconsistent documents and inflexible program text.

Re: Any research putting c above ada?

[Jay Martin]

kaz@vision.crest.nt.com (Kaz Kylheku) writes:

>That is slip-shod, but it doesn't seem to relate to my own computer science
>background and experiences.

>What was the focus of your computer science training? Was it largely
>theoretical, or did it involve a lot of ``hands on'' work?

>I remember one school project that I never even implemented. It was just a
>paper outlining requirements and design. There weren't many software
>engineering courses in the program, but there were two tough ones. One
>two-semester long team project, and a course focusing on various topics
>in software engineering. I've never been encouraged to just code something;
>design was always the focus. We learned to admire an elegant design, rather
>than implementations. 

Two tough software engineering courses, actual full-year team projects, 
taught to admire elegant design.... what kind of clown computer science
department did you go to???  

>Throughout school, I hustled my own contract work. I've always insisted on
>going through a requirements analysis with the clients, as well as walking
>through some of the less technical aspects of the design. I thought that this
>was what computer scientists were supposed to do, and since I was trying to
>become one, I emulated the behavior. 

No real Computer Scientists are supposed to be incorrigible hackers or
just so theoretically spaced-out as to be useless.  You obviously
don't have want it takes to be a "real" Computer Scientist.

>However, over the years I've had the chance to talk to a few graduates from
>other computer science programs and was surprised at the diversity of
>experiences. One student complained that his whole undergraduate career was
>``all theory'' geared toward further studies. He never got to do any projects
>involving real implementation.  He claimed to have gained next to no experience
>with things like networking, graphical interfaces or concurrent programming. I
>was shocked when he revealed to me that he allegedly studied at MIT!

Ditto for UCLA which teaches practically no software. In fact, it
seems the higher the CS dept is rated the more theoretically
masturbatorial or hack oriented it becomes. My undergrad institution,
UC Irvine, is much lower rated in CS but its attention to the software
education was/is vastly superior.

>It's hard to say anything about the nature of computer science training,
>since it seems to vary a great deal from institution to institution.

The problem is that the most prestigious (visable) ones are the most
rotten with respect to software engineering.  Thus you get a steady
stream of brilliant software idiots.

Jay

Re: Any research putting c above ada?

[Samuel A. Mize]

Jay Martin wrote:
> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
...
>>I thought that this
> >was what computer scientists were supposed to do, and since I was
>> trying to
> >become one, I emulated the behavior.
> 
> No real Computer Scientists are supposed to be incorrigible hackers or
> just so theoretically spaced-out as to be useless.

I agree with this statement, exactly as punctuated.  No real
Computer Scientist is supposed to be either of those things.

Unfortunately, a lot of those people call themselves Computer
Scientists, and/or Software Engineers.

I've noted that academics and engineers both believe that all
the ignorant, careless people are in the other group.

I always understood that:

1) Computer Science is research into how to make computing work
   (way-out, useless things like multitasking and fault tolerance,
   15 years ago);

2) Software Engineering is applying Computer Science to real
   system design and development, selecting the best approach
   to provide the needed functions within the resource constraints
   (like any engineering);

Some "real" engineers (hardware/EE engineers) who write code often
don't care about quality so long as it works, but there are
genuine software engineers -- even computer scientists -- in
that discipline too.

The trouble is that most universities have a CS Department, but
no distinct Software Engineering department.  This is like having
the Physics department teach Civil Engineering, or vice versa.

Sam Mize


-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: Any research putting c above ada?

[Roy Grimm]

> I always understood that:
> 
> 1) Computer Science is research into how to make computing work
>    (way-out, useless things like multitasking and fault tolerance,
>    15 years ago);

Hmmm...  If I'm not mistaken, multitasking has been done since the mid
1960's.  If I remember right, the IBM System/360 was one of the first
"multitasking" systems.  The mid 60's was 30 years ago (unless my math
is wrong).  And fault tolerance?  Do you honestly think that computers
are the first systems to have fault tolerance engineering applied to
them?  The science of fault tolerance predates computers by a very large
margin.

Just because the PC operating systems are finally picking up the ball on
multitasking and fault tolerance doesn't mean that it's an entirely new
science.  Multitasking and fault tolerance are always being studied, but
they had already been put into practical applicaiton in the early 80's
and had been there for years.

> 2) Software Engineering is applying Computer Science to real
>    system design and development, selecting the best approach
>    to provide the needed functions within the resource constraints
>    (like any engineering);

Now that, I will agree with you on.  I think you pretty much summed up
what software engineering is in relation to computer science.

> Some "real" engineers (hardware/EE engineers) who write code often
> don't care about quality so long as it works, but there are
> genuine software engineers -- even computer scientists -- in
> that discipline too.

In any group (computer scientists, software engineers, other engineers)
you will find people who are meticulous enough to do it right the first
time, but you will also find people who aren't.

> The trouble is that most universities have a CS Department, but
> no distinct Software Engineering department.  This is like having
> the Physics department teach Civil Engineering, or vice versa.

I couldn't agree with you more.  However, I think we will all have a
battle to get the engineering colleges to admit that software
engineering should be another course of study in their schools.  There
are some who will agree and some who will not.  I believe that we will
see software engineering programs implemented in time.  There are
already some institutions which offer a software engineering "track" in
addition to a normal program in CompSci.  (I've seen it in the
literature for the University of Iowa's graduate program in Computer
Science.)

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <336DF13F.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:

  > I couldn't agree with you more.  However, I think we will all have a
  > battle to get the engineering colleges to admit that software
  > engineering should be another course of study in their schools.  There
  > are some who will agree and some who will not.  I believe that we will
  > see software engineering programs implemented in time.  There are
  > already some institutions which offer a software engineering "track" in
  > addition to a normal program in CompSci.  (I've seen it in the
  > literature for the University of Iowa's graduate program in Computer
  > Science.)

   There are some colleges and universities which have tried this.
But such programs seem to fail for a very interesting reason.  The
craft of software engineering is learned in two ways.  One by making
the classic mistakes and seeing the consequences, the other by
mentoring by master software engineers.  While some of those mentors
can be found in universities, the current reality is that there aren't
enough in any one university location to create a school in the
original meaning of the word.

   Those software engineering programs which have worked have been
co-operative arrangements between academia and industry and tend to
rely on one individual on each side of the fence to keep the program
going.  When someone dies, retires, or transfers, for whatever reason,
the program eventually falls apart.

   I have felt for years that if we want to create a profession of
software engineering that the current engineering school model won't
work.  My guess is that we need a guild structure with masters,
journeymen and apprentices.  Even if apprentices are normally expected
to get a batchelor's degree in some field, (today everything is a
related field) with some CS courses, the real professional recognition
has got to be based on journey pieces and masterworks.

   You may not like some of the features of my programming style, just
as I don't like some of Mahler's musical idioms.  But there is a huge
and recognizable gulf between the products of good software engineers
and the dreck you normally see in CS1.

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Jay Martin]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <336DF13F.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:

>  > I couldn't agree with you more.  However, I think we will all have a
>  > battle to get the engineering colleges to admit that software
>  > engineering should be another course of study in their schools.  There
>  > are some who will agree and some who will not.  I believe that we will
>  > see software engineering programs implemented in time.  There are
>  > already some institutions which offer a software engineering "track" in
>  > addition to a normal program in CompSci.  (I've seen it in the
>  > literature for the University of Iowa's graduate program in Computer
>  > Science.)

>   There are some colleges and universities which have tried this.
>But such programs seem to fail for a very interesting reason.  The
>craft of software engineering is learned in two ways.  One by making
>the classic mistakes and seeing the consequences, the other by
>mentoring by master software engineers.  While some of those mentors
>can be found in universities, the current reality is that there aren't
>enough in any one university location to create a school in the
>original meaning of the word.

>   Those software engineering programs which have worked have been
>co-operative arrangements between academia and industry and tend to
>rely on one individual on each side of the fence to keep the program
>going.  When someone dies, retires, or transfers, for whatever reason,
>the program eventually falls apart.

I think the problem is that Computer Science is ignoring Software
Engineering and thus there are not enough (or zero) slots at CS
departments to hire such faculity.  The programs fall apart because
the academics don't give a f*ck about software .  Thus, until CS
moderates the theoretical masturbation and ARPA Prostitution, I see no
hope for a software education especially at the more established CS
departments.

>   I have felt for years that if we want to create a profession of
>software engineering that the current engineering school model won't
>work. 

Hmm, seems like a cop out.

>My guess is that we need a guild structure with masters,
>journeymen and apprentices.  Even if apprentices are normally expected
>to get a batchelor's degree in some field, (today everything is a
>related field) with some CS courses, the real professional recognition
>has got to be based on journey pieces and masterworks.

Interesting, but come to think about it where are the recognized
"masterworks" of software?  

Jay

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5kpgfu$ju4@uni.library.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:

>I think the problem is that Computer Science is ignoring Software
>Engineering and thus there are not enough (or zero) slots at CS
>departments to hire such faculity.  The programs fall apart because

That generalization is false. The school that I attended had excellent liasons
between industry and the CS department, and a thriving ``co-op'' program, as
well as a mandatory software engineering course and eight month long team
project.

>the academics don't give a f*ck about software .  Thus, until CS

Again, you are generalizing from a small sample to the larger population.

>moderates the theoretical masturbation and ARPA Prostitution, I see no

Theory should be avoided because, like masturbation, it may cause you to go
blind or to grow hair on the palms of your hands.

Re: Any research putting c above ada?

[Jay Martin]

kaz@vision.crest.nt.com (Kaz Kylheku) writes:

>In article <5kpgfu$ju4@uni.library.ucla.edu>,
>Jay Martin <jmartin@cs.ucla.edu> wrote:

>>I think the problem is that Computer Science is ignoring Software
>>Engineering and thus there are not enough (or zero) slots at CS
>>departments to hire such faculity.  The programs fall apart because

>That generalization is false. The school that I attended had excellent liasons
>between industry and the CS department, and a thriving ``co-op'' program, as
>well as a mandatory software engineering course and eight month long team
>project.

>>the academics don't give a f*ck about software .  Thus, until CS

>Again, you are generalizing from a small sample to the larger population.

Unfortunately I believe the small sample I am talking about is the top
rated Computer Science programs.  Thus, the most influential
departments are the most rotten with respect to software and have
basically declared the subject as unworthy of study. Since they all
agree... they must be right.  I suspect your CS dept is way down the
rankings list, if it is actually concerned about SE education.

Jay. 

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5kpgfu$ju4@uni.library.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:

  > Interesting, but come to think about it where are the recognized
  > "masterworks" of software?  

   Would you like me to start a list?  Hmmm.  (Most names omitted, to
make it sort of a test.  Can you put names to these papers, books, or
products?  For Early's and Strassen's algorithms, what it does and how
fast gets full credit, I'll give you the authors as a freebie.)

   Quicksort  (AFIAK, the first masterwork in software, certainly
               recognized as such at the time.)
   Heapsort   (A few months later, and also recognized as such.)

   The PDP-1 symbolic assembler.  (The final version was written as an
self assembling macro, and ran about four columns in the manual,
excluding tables.  The PDP-6 and later PDP-10 macro assemblers were
actually bootstrapped using the PDP-1 assembler with different
tables.)

   The paper on THE operating system.  (Extra points if you can spell
the name of the school and the authors without looking them up.)

   A Discipline of Programming.

   The Revised report on Algol 60.

   Unix curses.

   Elisa.

   Zen and the Art of Motorcycle Maintenance (and I don't think the
word software appears anywhere in the book.)

   Early's Algorithm.
 
   Strassen's Algorithm.

   Emacs  (Gosling?  Gnu?  Multics?  All of the above? For that matter:)

   Multics.

   On the decomposition of software into modules.

   TeX (and later LaTeX).

   The Florida algorithm for resolving overloading in Ada.

   The CORDIC algorithm.

   Several factoring algorithms, including P-1, Number Field Sieve,
and all of the Quadratic Sieve variations.

   I considered and eliminated a few others as out of domain: Euclid's
algorithm, the Simplex algorithm for solving linear programming
problems, the fast Fourier transform, the ChirpZ transform, and all
the work on NP completeness.  They were all originally considered to
be applied or theoretical mathematics...
--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Kevin Cline]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>In article <5kpgfu$ju4@uni.library.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:
>
>  > Interesting, but come to think about it where are the recognized
>  > "masterworks" of software?  
>
>   Would you like me to start a list?  Hmmm.  (Most names omitted, to
>make it sort of a test.  Can you put names to these papers, books, or
>products?  For Early's and Strassen's algorithms, what it does and how
>fast gets full credit, I'll give you the authors as a freebie.)
>
>   Quicksort  (AFIAK, the first masterwork in software, certainly
>               recognized as such at the time.)
>   Heapsort   (A few months later, and also recognized as such.)
>
>   The PDP-1 symbolic assembler.  (The final version was written as an
>self assembling macro, and ran about four columns in the manual,
>excluding tables.  The PDP-6 and later PDP-10 macro assemblers were
>actually bootstrapped using the PDP-1 assembler with different
>tables.)
>
>   The paper on THE operating system.  (Extra points if you can spell
>the name of the school and the authors without looking them up.)
>
>   A Discipline of Programming.
>
>   The Revised report on Algol 60.
>
>   Unix curses.
>
>   Elisa.
>
>   Zen and the Art of Motorcycle Maintenance (and I don't think the
>word software appears anywhere in the book.)
>
>   Early's Algorithm.
> 
>   Strassen's Algorithm.
>
>   Emacs  (Gosling?  Gnu?  Multics?  All of the above? For that matter:)
>
>   Multics.
>
>   On the decomposition of software into modules.
>
>   TeX (and later LaTeX).
>
>   The Florida algorithm for resolving overloading in Ada.
>
>   The CORDIC algorithm.
>
>   Several factoring algorithms, including P-1, Number Field Sieve,
>and all of the Quadratic Sieve variations.
>
>   I considered and eliminated a few others as out of domain: Euclid's
>algorithm, the Simplex algorithm for solving linear programming
>problems, the fast Fourier transform, the ChirpZ transform, and all
>the work on NP completeness.  They were all originally considered to
>be applied or theoretical mathematics...
>--

Most of these are essentially mathematical breakthrough. I think the original
poster was looking for masterworks in software engineering -- programs or
systems that have enjoyed a long lifetime, been extremely useful and useable,
and have also been relatively inexpensive to maintain.  I think the UNIX
operating system would fall in this category, although not every feature or
utility ever written.

Re: Any research putting c above ada?

[Kevin Cline]

jmartin@cs.ucla.edu (Jay Martin) wrote:

>Interesting, but come to think about it where are the recognized
>"masterworks" of software?  
>
>Jay

Hard to tell what's on the inside, but here are three nominations based on
usefulness and usability:

Quicken
GNU-Emacs
The TENEX operating system

Obviously I spend a lot more time writing software than running it.

Re: Any research putting c above ada?

[Alan Brain]

Kevin Cline wrote:

> >Interesting, but come to think about it where are the recognized
> >"masterworks" of software?

> Hard to tell what's on the inside, but here are three nominations based on
> usefulness and usability:
> 
> Quicken
> GNU-Emacs
> The TENEX operating system
> 
> Obviously I spend a lot more time writing software than running it.

I'd certainly add LINUX. Not that I consider any form of Unix to be all
that great in the 90's (in the 70's it was Magic).
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[deafen]

Roy Grimm (ragrimm@cca.rockwell.com) wrote:

[ interesting and informative discussion of CS vs. SE snipped ]

[ I don't know who wrote this part; the attribution was previously snipped ]

: > The trouble is that most universities have a CS Department, but
: > no distinct Software Engineering department.  This is like having
: > the Physics department teach Civil Engineering, or vice versa.

: I couldn't agree with you more.  However, I think we will all have a
: battle to get the engineering colleges to admit that software
: engineering should be another course of study in their schools.  There
: are some who will agree and some who will not.  I believe that we will
: see software engineering programs implemented in time.  There are
: already some institutions which offer a software engineering "track" in
: addition to a normal program in CompSci.  (I've seen it in the
: literature for the University of Iowa's graduate program in Computer
: Science.)

Actually, ghod willing, I'll be graduating this december with a degree in
CIS (Computer Information Systems) through the College of Business at ASU. 
It's not exactly what you're describing as a software engineering track,
but it covers nearly all of the areas you describe.  Furthermore, for
geeks like me, they offer several technically-oriented electives (Unix 
Network and Systems Programming, e.g.) and several cross-program 
electives through the College of Engineering.

Some of the areas in which that I've taken courses include systems 
analysis and design, database design and management, application 
analysis, and the like; these are required courses.  Other required 
courses are standard College of Business things like uses of accounting 
information, fundamentals of finance, managerial communication, group 
communication, principles of marketing, operations and logistics 
management, and the like.  The more technical areas are things like COBOL 
(yeah, ick), C *and* C++, object-oriented analysis and design, and ESQL 
(both in C/C++ and COBOL environments).

IMHO, it's a pretty cool program, with a good balance between 
fundamentals of IT, fundamentals of business, and tech-y stuff.

So yes, these programs do exist; seek ye the CIS program in Ye Olde 
Businesse Colleje.

OBC: My final project in CIS430 was to implement an email system using 
SYSV message queues in K&R style.  No prototypes allowed.  Icky.

--
Hal Haygood :: PC/Network/Unix technician, Sterling Pacific Assets
hal@suncap.com  ::  deafen@asu.edu  ::  deafen@netwrx.net
My opinions and those of my employer rarely, if ever, coincide.

Re: Any research putting c above ada?

[Roy Grimm]

deafen@imap2.asu.edu wrote:
> Actually, ghod willing, I'll be graduating this december with a degree in
> CIS (Computer Information Systems) through the College of Business at ASU.
> It's not exactly what you're describing as a software engineering track,
> but it covers nearly all of the areas you describe.  Furthermore, for
> geeks like me, they offer several technically-oriented electives (Unix
> Network and Systems Programming, e.g.) and several cross-program
> electives through the College of Engineering.

I would describe CIS and other MIS related programs the anthesis of
software engineering.  From my experience with business majors and
computers, I find they are worse than straght CompSci people.  If there
was ever a department that shouldn't train people how to run computer
systems, it's the business department.  Managers with business degrees
have a hard enough time managing regular businesses as it is.  It has
been my experience that a vast majority of people with business degrees
are not capable doing any real systems work.

I will grant that some individuals (possibly yourself included) have
some technical ability and/or take some electives to learn technical
ability.  However, a majority of business students couldn't do the real
administration tasks required to run a real computer network.

Beyond that, most business students don't know how to program their way
out of a paper bag, much less develop real software in an engineering
department.  I have seen some people pretentious enough to apply for an
engineering position with a business degree.  However, their resume
rarely makes it through the cut to get to resume review, and the
applicants usually don't make it to real interveiws.  Business schools
simply do not teach students how to engineer software.  They teach
students how to approach business from an academic viewpoint, much like
CompSci schools teach students how to approach programming from an
academic and theoretical viewpoints.  Neither approach is appropriate
for a software engineering position.

> Some of the areas in which that I've taken courses include systems
> analysis and design, database design and management, application
> analysis, and the like; these are required courses.

Those classes are fine for systems administrators and business
application programmers.  However, when you need someone who knows how
to develop safety-critical embedded systems software that tracks other
airplanes in the area and tells a pilot when one is getting too close, I
guarantee there won't be too many database administrators working on the
project.

>  Other required
> courses are standard College of Business things like uses of accounting
> information, fundamentals of finance, managerial communication, group
> communication, principles of marketing, operations and logistics
> management, and the like.

I fail to see how any of these courses would make anyone a better
software engineer.

>  The more technical areas are things like COBOL
> (yeah, ick), C *and* C++, object-oriented analysis and design, and ESQL
> (both in C/C++ and COBOL environments).

You're getting warmer, but I bet you only really learned the syntax of
the languages and the theoretical aspects of OO design.  I'd bet you
didn't spend much time learning software develoment techniques.

> IMHO, it's a pretty cool program, with a good balance between
> fundamentals of IT, fundamentals of business, and tech-y stuff.

I'm sorry, but software engineering has a lot more than just a bit of
"tech-y stuff" and IT/business fundamentals.  There's an entire side of
software engineering that is not touched by a business degree.  That's
why you see a requirement for a BS in computer/electrical engineering
(or related experience) for most every engineering position advertised. 
Business students (and even most CompSci students) don't have what it
takes to truly engineer software systems.

> So yes, these programs do exist; seek ye the CIS program in Ye Olde
> Businesse Colleje.

Can they teach me how to design a real-time embedded operating system
that I can certify in a safety-critical environment?  Can they even come
close?  Hardly.

> OBC: My final project in CIS430 was to implement an email system using
> SYSV message queues in K&R style.  No prototypes allowed.  Icky.

A simple Unix email system is hardly a challenge to build, no matter
what style you use.  Was your email system a distribution service for a
particular machine or was it to be a true mail server, complete with
support for multiple domains, mail forwarding and routing, embedded mime
types and so forth?  Did your email system even need to communicate
outside the particular system it was running on by itself or did it use
the built in Unix mail transport system?  I would find it hard to
believe that an undergraduate business class would get into something as
involved as mail server architecture.

-- 
Voicing my own opinion, not speaking as a company representative.

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@no.spam.please.cca.rockwell.com
    (remove the no.spam.please. to get my real address)

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5l3g3f$pi9@news.asu.edu>,  <deafen@imap2.asu.edu> wrote:

>Actually, ghod willing, I'll be graduating this december with a degree in
>CIS (Computer Information Systems) through the College of Business at ASU. 

[ snip ]

>OBC: My final project in CIS430 was to implement an email system using 
>SYSV message queues in K&R style.  No prototypes allowed.  Icky.

That's the stupidest requirement I've ever heard of, all the more so because
it's so recent.

Re: Any research putting c above ada?

[Roy Grimm]

Kaz Kylheku wrote:
> >I was trained in the computer-science paradigm.  When I arrived at
> >Rockwell and started working on engineering projects, I was astounded to
> >see the difference between how I had done things before and how I had to
> >do them here.  At my previous position, we cranked out code.  Here, we
> >design and build software.  The focus here is on the design process and
> >how we can build software to meet the design.  At my former employer, we
> >were simply asked to crank out some code that did the job.  If it wasn't
> >quite right, we'd throw some fixes into it and release it again, and
> >again, and again until we either got it close enough or the buyer wanted
> >something completely different.  That kind of slip shod programming
> >doesn't fly very far here.
> 
> That is slip-shod, but it doesn't seem to relate to my own computer science
> background and experiences.

A common theme emerging from this tangent seems to be that every
institution, and even every person does things differently.  We all have
different experiences.  I had all theory in my classwork, but I did
enough extra-curricular work (mostly in my job at the college computer
center) that I was able to apply that theory to real world situations. 
Even though I had a "less than stellar" academic record, I think I came
out of that place with much more usable knowledge than most of the
people in my class.

> What was the focus of your computer science training? Was it largely
> theoretical, or did it involve a lot of ``hands on'' work?

Mostly theoretical.  I did take a directed study in Ada (it wasn't
offered as a regular class at the time) which was my only collegiate
experience with any kind of software engineering.  We spent all of our
time learning about data structures, algorithm analysis, operating
system theory, etc.  The curriculum didn't address the development of
software as a whole.  When it came to writing programs for class, we
were thrown at the VAX, given the script file which ran the compiler and
linker together, and given enough info about the 'edt' editor to get
started.  That's all the more instruction we got on the development
process.  Everything else we learned about that we found out from the
upper-classmen.

Fortunately, I wasn't satisfied with that.  I went out and bought my own
C compiler and started tinkering.  I wrote several programs on my own
that went way beyond the theory I was presented with.  I was just too
hungry to be placated with the contrived examples the professors gave to
us.

> However, over the years I've had the chance to talk to a few graduates from
> other computer science programs and was surprised at the diversity of
> experiences. One student complained that his whole undergraduate career was
> ``all theory'' geared toward further studies. He never got to do any projects
> involving real implementation.  He claimed to have gained next to no
> experience with things like networking, graphical interfaces or concurrent
> programming. I was shocked when he revealed to me that he allegedly studied
> at MIT!

Why should that come as a suprise?  Many people I know (even a friend
from hight school) went to MIT so they could get into graduate school. 
It shouldn't come as a suprise that their curriculum is geard toward
further study any more than many private boarding schools are geared
toward college prep.

I am suprised that there are so few institutions out there which really
prep students for real world software development.  I graduated with
people who could recite operating system theory all day but couldn't
figure out how to change working directories in their VMS accounts
without a cheat sheet.
 
> It's hard to say anything about the nature of computer science training,
> since it seems to vary a great deal from institution to institution.

If that isn't an incredible understatement...
 
> >> Have you ever seen code written by engineers with no understanding of
> >> computer science? :))
> >
> >I have.  Let me tell you, the code is atrocious.  However, it is only
> 
> I was only joking, and playing on the multiple meanings of ``engineer''.
> It's clear that the discussion is about software engineers, not civil or
> electrical engineers! :) These latter guys tend to write 500 line procedures
> with repeated code that is not factored into subprograms. (This is just an
> observation based on a limited sample, not meant to generalize to all
> engineers. :)

Tell me about it.  I had the dubious distinction of porting a VMS based
C program to a Sun workstation.  I cracked it open to find that the
entire 16 page program was one big "main" function.  I just about cried.

> How is that? Are you saying that the computer scientist had a very rigid
> design, and hacked the code to fit that design rather than going through a more
> iterative approach to find a more suitable or flexible design? Or perhaps the
> fellow didn't spend enough time on the design, and ended up with something
> having a narrow scope.  Rather than indicating no training in software
> engineering, that could simply indicate a training in old-style software
> engineering, whereby a team is supposed to go through through requirements,
> design, implementation and testing stages in one swoop, leaving behind a
> massive paper trail of inconsistent documents and inflexible program text.

I'm saying that the computer scientist and the electrical engineer both
hack together some atrocious programs (i.e. a 16 page main function).  
However, the computer scientist will do slightly better than the
electrical engineer because the computer scientist has studied algorithm
theory enough to figure out which algorithm works better.  It isn't
until these people get into a disciplined development group that they
actually learn how to design real software.  I hadn't even heard of a
peer code review until I got to Rockwell.  The only peer reviewing I did
in college was to help other people in my class find bugs when we were
in the computer lab the night before the assignment was due.  (I could
relate the story of the 3 page assembly program with no spaces or
comments that a guy asked me to fix.  When I asked him what was wrong,
he replied "it doesn't work"...)

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3368A6FE.41C6@cca.rockwell.com>,
Roy Grimm  <ragrimm@cca.rockwell.com> wrote:
>Kaz Kylheku wrote:
>> >I was trained in the computer-science paradigm.  When I arrived at
>> >Rockwell and started working on engineering projects, I was astounded to
>> >see the difference between how I had done things before and how I had to
>> >do them here.  At my previous position, we cranked out code.  Here, we
>> >design and build software.  The focus here is on the design process and
>> >how we can build software to meet the design.  At my former employer, we
>> >were simply asked to crank out some code that did the job.  If it wasn't
>> >quite right, we'd throw some fixes into it and release it again, and
>> >again, and again until we either got it close enough or the buyer wanted
>> >something completely different.  That kind of slip shod programming
>> >doesn't fly very far here.
>> 
>> That is slip-shod, but it doesn't seem to relate to my own computer science
>> background and experiences.
>
>A common theme emerging from this tangent seems to be that every
>institution, and even every person does things differently.  We all have
>different experiences.  I had all theory in my classwork, but I did
>enough extra-curricular work (mostly in my job at the college computer
>center) that I was able to apply that theory to real world situations. 
>Even though I had a "less than stellar" academic record, I think I came
>out of that place with much more usable knowledge than most of the
>people in my class.

My experience was quite hands-on. In the compiler construction course, you had
to implement a compiler. (There was a prerequisite course on formal languages,
but I talked to the prof and skipped it). The assigments followed the various
stages of compiler design: lexical analysis, parsing, type checking,
intermediate code generation, etc. The lectures were very good too; you learned
about pattern matching automata, various parsing algorithms and the
construction of parser generators, etc. I still practice the construction of a
table for a shift reduce parser from an LR(1) grammar once in a while just to
stay sharp!

The OS courses had a heavy assignment load, involving real systems. In the
first course, you had to crank out multi-threaded programs. In the second one,
we used old Sun boxes for embedded programming using a small OS kernel.
Assignments ranged from implementing various OS features, to doing fun stuff
like packet sniffing.  I wrote a 68010 emulator to single-step through object
code off-line instead of waiting for the live thing. :) The final assignment
asked a lot of crap about things like the Berkeley FFS, System V
streams---totally unrelated to the assignment work, a lot of which I had no
clue about because I skipped most of the lectures to write the emulator.

In distributed systems, the first assigmnet was to write a scaled down name
service. The next one was to make it distributed, so that servers would talk to
other servers to find information. Then we had to make it multi-threaded, and
finally add public key cryptography. The exam was totally spaced out though,
about things like two-phase commit protocols, totally ordered atomic
multicasts, etc. You got to have _some_ rigor in the course load.  We used
C/UNIX for everything. 

In machine architectures, one assignment had us implementing software floating
point routines in assembly language. The day before the due date, the prof
imposed a much stricter maximum cycle count than the original spec, so the lab
was packed with people optimizing away like mad.  The advanced course was a
complete waste though; step by step analyses of what goes on inside the
pipelines of some model processor ad nauseum---probably because the prof came
from some ivy league university in the USA (great guy, don't get me wrong).

>> What was the focus of your computer science training? Was it largely
>> theoretical, or did it involve a lot of ``hands on'' work?
>
>Mostly theoretical.  I did take a directed study in Ada (it wasn't
>offered as a regular class at the time) which was my only collegiate
>experience with any kind of software engineering.  We spent all of our

Most topics in basic program design were covered by second year. OO wasn't
taught when I was there, just abstract data typing techniques, but was
introduced shortly afterward.  Even the local colleges offered decent
courses in data structures and program design; I took one in which Modula 2
was used as the language. I thought that in every decent school, the first
thing one would learn is how to decompose a program into abstractions
centered around abstract data types along with operations that work on
these data types.

In the third year, there was a mandatory one-semester course on software
engineering accompanied by a mandatory two-semester team project. This involved
developing a multi-user client-server application essentially from scratch,
with graphical interfaces on X terminals, ORACLE for storage. RPC stubs were
generated by a locally developed awk script. :)

I had a lot of fun in school. To this day I'm convinced that I got my money's
worth.

>I'm saying that the computer scientist and the electrical engineer both
>hack together some atrocious programs (i.e. a 16 page main function).  

That sort of coding indicates a serious failure to understand program design.
Functional or algorithmic decomposition is just the bare-bones basic technique
that dates back to the 50's.  It's not sufficient for large software projects,
but it's necessary for even small ones. I can't believe that someone can
come out of a computer science program and not be able to decompose a program
into subprograms. Even good highschools teach that to teenagers (some even
do abstract data types or, more recently, OO. One woman I know claims
to have learned about things like module cohesion and coupling in highschool.
The school was fortunate to have a good CS instructor).

I came to school from a childhood of hacking in assembly language in BASIC, 
and some Pascal.  Assembly taught me functional decomposition; it was far too
impractical to write long functions. Subroutines were your friend! When I
learned about abstract data types, I was bowled over.

>However, the computer scientist will do slightly better than the
>electrical engineer because the computer scientist has studied algorithm
>theory enough to figure out which algorithm works better.  It isn't
>until these people get into a disciplined development group that they
>actually learn how to design real software.  I hadn't even heard of a
>peer code review until I got to Rockwell.  The only peer reviewing I did

You are kidding! We had to do mandatory peer code inspections as part of the
aforementioned software engineering course and the project course.  Code
reviews allegedly catch something like 60% of defects (to pull some vague round
number out of a hat!) You have to read programs, not just write them.  We also
had to do mandatory lab work, which included hands-on experience with a CASE
tool known as Teamwork.  How can a computer science course not include at least
one course in SW engineering? 

Unfortunately, our course was a little too geared toward old traditions, like
structured analysis and design. I never understood the course properly until
some years later, when I realized that I had problems in the course because I
was thinking in an object-oriented manner centered around abstractions rather
than data flows or control flows. For instance, in some of the diagrams related
to structured analysis, I mistakenly tried to see abstractions or object-type
relationships. It was not until I read Booch that I became keenly aware of the
difference between the old and new schools. I could then see my educational
experience in its proper context.

Re: Any research putting c above ada?

[Roy Grimm]

Kaz Kylheku wrote:
> My experience was quite hands-on. In the compiler construction course, you
> had to implement a compiler. (There was a prerequisite course on formal
> languages, but I talked to the prof and skipped it). The assigments followed
> the various stages of compiler design: lexical analysis, parsing, type
> checking, intermediate code generation, etc. The lectures were very good too;
> you learned about pattern matching automata, various parsing algorithms and
> the construction of parser generators, etc. I still practice the construction
> of a table for a shift reduce parser from an LR(1) grammar once in a while
> just to stay sharp!

We didn't have any courses like that.  I took the class on formal
languages, where we touched on the various language types (iterative,
rule-based/logic, OO, etc.) but we never really got into compiler
building.  I started to take a graduate course in language priciples. 
The professor really was just walking us through how he built a lisp
based compiler.  I dropped it about halfway through since I had read to
the end of the book and absorbed all the material.  (I'm not interested
in pursuing a graduate degree right now, so I wasn't too concerned about
dropping the credits.)  I ended up picking up a book and I've started to
write my own Pascal compiler.  I probably won't ever write compilers for
a living, but it's an interesting subject that I don't know too much
about.

> The OS courses had a heavy assignment load, involving real systems. In the
> first course, you had to crank out multi-threaded programs. In the second
> one, we used old Sun boxes for embedded programming using a small OS kernel.
> Assignments ranged from implementing various OS features, to doing fun stuff
> like packet sniffing.  I wrote a 68010 emulator to single-step through object
> code off-line instead of waiting for the live thing. :) The final assignment
> asked a lot of crap about things like the Berkeley FFS, System V
> streams---totally unrelated to the assignment work, a lot of which I had no
> clue about because I skipped most of the lectures to write the emulator.

Our OS course was all theory (and it was an elective to boot! <pun
intended>).  We had to write only one program in the entire class which
showed how we would structure a round-robin process scheduler.  We
didn't actually write the scheduler.  We only wrote a simulator which
would print out the order for processes based on an input file that
listed process entry time and duration.  I wanted to challenge myself so
I did it in Pascal with a circular linked list.

> In distributed systems, the first assigmnet was to write a scaled down name
> service. The next one was to make it distributed, so that servers would talk
> to other servers to find information. Then we had to make it multi-threaded,
> and finally add public key cryptography. The exam was totally spaced out
> though, about things like two-phase commit protocols, totally ordered atomic
> multicasts, etc. You got to have _some_ rigor in the course load.  We used
> C/UNIX for everything.

We never had distributed systems of any kind, except as a brief side
note in our OS class.

> In machine architectures, one assignment had us implementing software
> floating point routines in assembly language. The day before the due date,
> the prof imposed a much stricter maximum cycle count than the original spec,
> so the lab was packed with people optimizing away like mad.  The advanced
> course was a complete waste though; step by step analyses of what goes on
> inside the pipelines of some model processor ad nauseum---probably because
> the prof came from some ivy league university in the USA (great guy, don't
> get me wrong).

Machine architecture turned into an "intro to assembler" class with a
theoretical overview of basic logic circuts.  Wecovered up to showing a
16 bit adder built with various AND/OR/XOR/NOT gates.  We then jumped
right to "then you make all these pieces and put them together to make a
processor and it runs machine instructions".  The latter half of the
class was listening to lectures on how different machine instructions
work.

> Most topics in basic program design were covered by second year. OO wasn't
> taught when I was there, just abstract data typing techniques, but was
> introduced shortly afterward.  Even the local colleges offered decent
> courses in data structures and program design; I took one in which Modula 2
> was used as the language. I thought that in every decent school, the first
> thing one would learn is how to decompose a program into abstractions
> centered around abstract data types along with operations that work on
> these data types.

The data structures/algorithm classes weren't recommended until the
junior year.  First year, intro to programming (two semesters to learn
Pascal).  Second year, architecture and assembler (many elected to take
the OS class too), Third year, data structures/algorithms and a possible
elective of programming language principles.  Then you were done.  You
could graduate with just that. (along with several math classes like
linear algebra and so forth...)  And many people did!  I took every
possible class I could to expand my experience.  However, there wasn't
much to take.  I had to take independent study classes to learn C, Unix
and Ada.

> In the third year, there was a mandatory one-semester course on software
> engineering accompanied by a mandatory two-semester team project. This
> involved developing a multi-user client-server application essentially from
> scratch, with graphical interfaces on X terminals, ORACLE for storage. RPC
> stubs were generated by a locally developed awk script. :)

Team projects?  The only team project we had was when we were all
sitting around in the lab helping each other find bugs.
 
> I had a lot of fun in school. To this day I'm convinced that I got my money's
> worth.

I wish I could say the same.  Too much money and no real practical
knowledge.  I'm really dissapointed with the Comp Sci program at my alma
mater.
 
> That sort of coding indicates a serious failure to understand program design.
> Functional or algorithmic decomposition is just the bare-bones basic
> technique that dates back to the 50's.  It's not sufficient for large
> software projects, but it's necessary for even small ones. I can't believe
> that someone can come out of a computer science program and not be able to
> decompose a program into subprograms. Even good highschools teach that to
> teenagers (some even do abstract data types or, more recently, OO. One woman
> I know claims to have learned about things like module cohesion and coupling
> in highschool. The school was fortunate to have a good CS instructor).

That sort of coding indicates a serious lack of basic training that
permiates some institutions.  We never once touched on debugging
techniques, team development, or any kind of software development
techniques.  The highschool I went to had one teacher for computers.  He
had his nephew (a graduate student in comp sci) come in to teach us all
Pascal (the teacher included!)
 
> I came to school from a childhood of hacking in assembly language in BASIC,
> and some Pascal.  Assembly taught me functional decomposition; it was far too
> impractical to write long functions. Subroutines were your friend! When I
> learned about abstract data types, I was bowled over.

Fortunately, my father is an engineer who taught me many things about
software development when I was in high school.  I had a full working
knowledge of software development before I got to college.  My professor
docked points on my homework because I was doing things in my
assignments that we hadn't covered yet.  Something as simple as "if
response not in ['y', 'Y', 'n', 'N']..." to test a response from the
user brought down the wrath of my prof.  "We won't do anything with sets
until second semester" was the response I got.

> You are kidding! We had to do mandatory peer code inspections as part of the
> aforementioned software engineering course and the project course.  Code
> reviews allegedly catch something like 60% of defects (to pull some vague
> round number out of a hat!) You have to read programs, not just write them. 
> We also had to do mandatory lab work, which included hands-on experience
> with a CASE tool known as Teamwork.  How can a computer science course not
> include at least one course in SW engineering?

"We're teaching Computer Science here.  If you want engineering, go to
an engineering school."  That's the prevailing attitude with many of the
CompSci programs at small liberal arts colleges.  They teach the
"science" of programming almost as a subfield of Mathematics.  The
professors usually don't have any knowledge or training in real world
software development.  You can get a PhD in Comp Sci with only writing a
handfull of large programs.  Even then, your programs really only need
to be directly related to your thesis.  With a PhD, you can become a
professor at almost any college.  Many of the professors that were
teaching in the colleges and universities I attended or was considering
attending had no real-world experience.  They went right through college
to graduate school and right into teaching.  IMNSHO, they are brilliant
theorists but poor software developers.  Granted, there are exceptions
to this very broad generalization, but not too many of them make
themselves widely known in the midwest.

> Unfortunately, our course was a little too geared toward old traditions, like
> structured analysis and design. I never understood the course properly until
> some years later, when I realized that I had problems in the course because I
> was thinking in an object-oriented manner centered around abstractions rather
> than data flows or control flows. For instance, in some of the diagrams
> related to structured analysis, I mistakenly tried to see abstractions or
> object-type relationships. It was not until I read Booch that I became keenly
> aware of the difference between the old and new schools. I could then see my
> educational experience in its proper context.

Personally, I was a cynic from the begining.  I have an engineer for a
father and an older sister who forged the path before me.  I knew enough
ahead of time to expect that most profs are more concerned with academic
theory than with teaching real-world practical knowledge.  I was
pleasantly suprised to find that there were several profs at my school
who thought differently.  My advisor in particular recognized that I was
more interested in learing how to work with computer systems and develop
software.  He supported me by suggesting I take independed and directed
study classes that let me learn what I really wanted and needed.

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Jon S Anthony]

In article <3369FCAF.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:

> "We're teaching Computer Science here.  If you want engineering, go to
> an engineering school."  That's the prevailing attitude with many of the
> CompSci programs at small liberal arts colleges.  They teach the
> "science" of programming almost as a subfield of Mathematics.  The

This is actually very apropos to the problem.  Most of what passes as
so called "computer science" is just watered down mathematics -
discrete mathematics (asymptotic algorithm analysis is fundamentally
various techniques of counting, i.e., a bit of combinatorics) and some
bits of formal logics (which is where the oft mentioned "halting
problem" and such comes from.)  Take this away and you don't have much
left - unless you have the _application_ of that mathematics, i.e.,
software engineering.

Well, there is the AI camp, but there too, if you look at what much of
this is, it's being/been covered by philosophers and CogScis (and
often with rather more perspicacity).


> theorists but poor software developers.  Granted, there are
> exceptions to this very broad generalization, but not too many of
> them make themselves widely known in the midwest.

From what's been said in this thread, this actually sounds rather more
universal a problem.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Steve Furlong]

Jon S Anthony wrote:
...
> Most of what passes as
> so called "computer science" is just watered down mathematics -
> discrete mathematics...

And poorly done, at that. If I see one more O(n) algorithm for finding
a Fibonacci number...

(For those of you who didn't take Discrete Math, you can find a Fib.
number in O(c) time.)


Steve Furlong

Re: Any research putting c above ada?

[Kevin Cline]

Steve Furlong <sr.furlong@pti-us.com.nospam> wrote:

>Jon S Anthony wrote:
>...
>> Most of what passes as
>> so called "computer science" is just watered down mathematics -
>> discrete mathematics...

It's not watered down.  What you see in an undergraduate CS cirriculum may be
simpler than other undergraduate math courses, but there is plenty of
interesting stuff there.

>
>And poorly done, at that. If I see one more O(n) algorithm for finding
>a Fibonacci number...
>
>(For those of you who didn't take Discrete Math, you can find a Fib.
>number in O(c) time.

You can't.  The nth Fibonacci number requires O(n) bits for representation.
So it can't be computed in less than O(n) time.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <A10B0B6EBB3B68B9.B6D11404F25D543E.B07D85116D7067AE@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> >Jon S Anthony wrote:
> >...
> >> Most of what passes as
> >> so called "computer science" is just watered down mathematics -
> >> discrete mathematics...
> 
> It's not watered down.  What you see in an undergraduate CS cirriculum may be
> simpler than other undergraduate math courses, but there is plenty of
> interesting stuff there.

That's called watered down in my book.  But that is not a big deal if
the whole idea was to simply apply the stuff and not try to play at
being a mathematician.  If that is what you like or think important,
then go be a mathematician - it certainly is a lot more interesting.
IMO.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Robert A Duff]

In article <336E51EB.6275@pti-us.com.nospam>,
Steve Furlong  <sr.furlong@pti-us.com.nospam> wrote:
>(For those of you who didn't take Discrete Math, you can find a Fib.
>number in O(c) time.)

That's a Fib.  ;-)

- Bob

Re: Any research putting c above ada?

[Lawrence Kirby]

In article <336E51EB.6275@pti-us.com.nospam>
           sr.furlong@pti-us.com.nospam "Steve Furlong" writes:

>Jon S Anthony wrote:
>...
>> Most of what passes as
>> so called "computer science" is just watered down mathematics -
>> discrete mathematics...
>
>And poorly done, at that. If I see one more O(n) algorithm for finding
>a Fibonacci number...
>
>(For those of you who didn't take Discrete Math, you can find a Fib.
>number in O(c) time.)

I guess you are referring to the formula based on the golden ratio.
Certainly that has its place but it certainly isn't always the best
approach, and whether it can be calculatyed in O(1) time is questionable,
depending on whether things like exp(X) can be calculated in O(1) time.
Given the rate at which the series increases it is often only the first
few terms that are of interest in which case an O(N) approach or perhaps
a lookup table would be more appropriate. The best solution depends on the
specification of the problem, e.g. if you want to generate a series of
Fibonacci numbers. It is interesting but I doubt that there are very many
practical uses for the Fibonacci formula.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Any research putting c above ada?

[T Wheeley]

On 2 May 1997, Jon S Anthony wrote:

> In article <3369FCAF.41C6@cca.rockwell.com> Roy Grimm <ragrimm@cca.rockwell.com> writes:
> 
> > "We're teaching Computer Science here.  If you want engineering, go to
> > an engineering school."  That's the prevailing attitude with many of the
> > CompSci programs at small liberal arts colleges.  They teach the
> > "science" of programming almost as a subfield of Mathematics.  The
> 
> This is actually very apropos to the problem.  Most of what passes as
> so called "computer science" is just watered down mathematics -
> discrete mathematics (asymptotic algorithm analysis is fundamentally
> various techniques of counting, i.e., a bit of combinatorics) and some
> bits of formal logics (which is where the oft mentioned "halting
> problem" and such comes from.)  Take this away and you don't have much
> left - unless you have the _application_ of that mathematics, i.e.,
> software engineering.
> 
> Well, there is the AI camp, but there too, if you look at what much of
> this is, it's being/been covered by philosophers and CogScis (and
> often with rather more perspicacity).

Well then let's not bother teaching computer science at all!  Why not just
make people do Maths + Philosophy degrees.  Yes it's the same stuff, but
don't Physics and Chemistry both cover atoms and electron shells?  Don't
both Biology and Chemistry cover Biological Chemistry?

The fact is that a CS degree combines all these factors into a single
degree related to the study of computers, and puts them in the correct
context.  Yes the idea of dominance in sequences is part of computer
science, but they way I was taught it in maths is not particularly relvant
to the complexity of algorithms.

Unless you have a very good understanding of the principles behind the
maths in a maths degree, it will take you a lot of experience to become a
good programmer (e.g. Knuth)

Of course there is a strong element of theory in CS degrees -- they want
to get good research students to boost the department's standing against
other universities, but you would have to have a poor department or be a
poor student if you didn't pick up some of the fundamentals of good
software design.

:sb)

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <Pine.SGI.3.95L.970514190923.17085C-100000@tower.york.ac.uk>,
T Wheeley  <tw104@york.ac.uk> wrote:

>The fact is that a CS degree combines all these factors into a single
>degree related to the study of computers, and puts them in the correct
>context.  Yes the idea of dominance in sequences is part of computer
>science, but they way I was taught it in maths is not particularly relvant
>to the complexity of algorithms.

In my study of CS, I learned how to formally verify programs, using concepts
such as weakest strict preconditions, postconditions, loop invariants and so
on.  Formal verification is an important component of software engineering.
Some proponents of FV insist that it should be consistently practiced by the
entire software industry, the same way that designs in other engineering
disciplines are verified.

A superior intellect can perhaps make the jump from formal logic and
autononmously deduce the principles of formally verifying programs, but the
right CS course can guide students toward it.

In this thread I have seen attitudes toward mathematics and ``theory''
which are not shared by practitioners of other engineering disciplines.
Without the principles, you are just a hacker, no matter how much you think
your experience makes you into an engineer. 

Re: Any research putting c above ada?

[Jay Martin]

Roy Grimm <ragrimm@cca.rockwell.com> writes:

>Mostly theoretical.  I did take a directed study in Ada (it wasn't
>offered as a regular class at the time) which was my only collegiate
>experience with any kind of software engineering.  We spent all of our
>time learning about data structures, algorithm analysis, operating
>system theory, etc.  The curriculum didn't address the development of
>software as a whole.  When it came to writing programs for class, we
>were thrown at the VAX, given the script file which ran the compiler and
>linker together, and given enough info about the 'edt' editor to get
>started.  That's all the more instruction we got on the development
>process.  Everything else we learned about that we found out from the
>upper-classmen.

>Fortunately, I wasn't satisfied with that.  I went out and bought my own
>C compiler and started tinkering.  I wrote several programs on my own
>that went way beyond the theory I was presented with.  I was just too
>hungry to be placated with the contrived examples the professors gave to
>us.

A classic example of what the academic Computer Science software
competence vacuume does to this field.  Is there any doubt why C is
king and Ada is a joke?

Re: Any research putting c above ada?

[Fritz W Feuerbacher]

Roy Grimm (ragrimm@cca.rockwell.com) wrote:

: > However, over the years I've had the chance to talk to a few graduates from
: > other computer science programs and was surprised at the diversity of
: > experiences. One student complained that his whole undergraduate career was
: > ``all theory'' geared toward further studies. He never got to do any projects
: > involving real implementation.  He claimed to have gained next to no
: > experience with things like networking, graphical interfaces or concurrent
: > programming. I was shocked when he revealed to me that he allegedly studied
: > at MIT!

This is because there is no need to teach people these things.  If comp
sci departments wanted to teach people these types of subjects then they
wouldn't be a comp sci department.  These types of things change from week
to week and there would be no way of keeping up with them.  Comp. Sci
study involves mostly the theories that don't change over time.  Thier
like concrete mathematic examples.

If you want to pursue other avenues of computers such as networks and
GUI's and such go right ahead but no matter how much those areas change
and evolve the core comp. sci. material will still be there existing like 
concrete pillars.

: I am suprised that there are so few institutions out there which really
: prep students for real world software development.  I graduated with
: people who could recite operating system theory all day but couldn't
: figure out how to change working directories in their VMS accounts
: without a cheat sheet.

Thats because it takes about 5 minutes to memorize an os implmentation
dependent command and about 2 years to gain a good understanding of
computer science (with lots of hard work).  Comp. sci. is not to concerned
with specific implementations although it uses them to illiustrate
examples.

Re: Any research putting c above ada?

[Wilbur Streett]

fwf27775@pegasus.cc.ucf.edu (Fritz W Feuerbacher) wrote:

>This is because there is no need to teach people these things.  If comp
>sci departments wanted to teach people these types of subjects then they
>wouldn't be a comp sci department.  These types of things change from week
>to week and there would be no way of keeping up with them.  Comp. Sci
>study involves mostly the theories that don't change over time.  Thier
>like concrete mathematic examples.

The basic networking software that was orignally laid out in Xerox
Networking Services, then implemented in EtherServies 2.0 and later worked
it's way into 3+Open, later know as LAN Server and LAN Manager, licensed by
Microsoft, and now the basis of all PC based networking, hasn't changed in
20 years..  SMB is still SMB.. TCP is still TCP and most CS grads can't do
anything with any of it..

>If you want to pursue other avenues of computers such as networks and
>GUI's and such go right ahead but no matter how much those areas change
>and evolve the core comp. sci. material will still be there existing like 
>concrete pillars.

Yeah right.  And the CS grads will still have no fundamental understanding
of real world systems..
>Thats because it takes about 5 minutes to memorize an os implmentation
>dependent command and about 2 years to gain a good understanding of
>computer science (with lots of hard work).  

And a lifetime to come to understand the real world issues in computer
systems..

>Comp. sci. is not to concerned
>with specific implementations although it uses them to illiustrate
>examples.

Which is why the typical examples of "Computer Science" created by CS grads
are such pieces of garbage..  Tell you what, take NT 4.0's backup and
restore commands and try to back up and restore a file that is larger than
1.4 MB.  I'll bet that there were CS grads doing that work.

Theory doesn't get the work done.

Wilbur

Re: Any research putting c above ada?

[Kevin Cline]

WStreett@shell.monmouth.com.spamguard (Wilbur Streett) wrote:

>The basic networking software that was orignally laid out in Xerox
>Networking Services, then implemented in EtherServies 2.0 and later worked
>it's way into 3+Open, later know as LAN Server and LAN Manager, licensed by
>Microsoft, and now the basis of all PC based networking, hasn't changed in
>20 years..  SMB is still SMB.. TCP is still TCP and most CS grads can't do
>anything with any of it..
>

I agree that this is a basic failure of CS training. Students should be taught
the theory, and then be shown one or two examples of practical applications of
that theory.  This would take quite a lot of time, but I think CS
upperclassmen should be taking about 60% of their load in their major.
To truly understand task scheduling, take a look at a couple of schedulers.
To understand networking, look at a couple of protocol stacks and compare
them.

>>If you want to pursue other avenues of computers such as networks and
>>GUI's and such go right ahead but no matter how much those areas change
>>and evolve the core comp. sci. material will still be there existing like 
>>concrete pillars.
>
>Yeah right.  And the CS grads will still have no fundamental understanding
>of real world systems..
>>Thats because it takes about 5 minutes to memorize an os implmentation
>>dependent command and about 2 years to gain a good understanding of
>>computer science (with lots of hard work).  
>
>And a lifetime to come to understand the real world issues in computer
>systems..
>
>>Comp. sci. is not to concerned
>>with specific implementations although it uses them to illiustrate
>>examples.
>
>Which is why the typical examples of "Computer Science" created by CS grads
>are such pieces of garbage..  Tell you what, take NT 4.0's backup and
>restore commands and try to back up and restore a file that is larger than
>1.4 MB.  I'll bet that there were CS grads doing that work.

I've always felt that certain companies products look like they were developed
by new graduates with no idea of current or past practice.  diff3 and rcsmerge
have been available for years, yet as recently as 1994 someone tried to sell
me a configuration management system that didn't understand 3-way file merge.
The HP1000 had a FORTRAN compiler and linker that couldn't handle
six-character external names.  Most of the commercial Ada 83 compiler systems
for workstations in the early 1990's were laughable when compared with C and
dbx.  The developers of VAX/VMS ignored all lessons learned from UNIX and
TOPS-20 to insure recapture of existing RSX-11M customers.  Heck, maybe that
decision was correct.  DEC made a pile of money on the VAX, but it was the
beginning of a long slow decline.

Re: Any research putting c above ada?

[T Wheeley]

On Sun, 11 May 1997, Wilbur Streett wrote:

> Which is why the typical examples of "Computer Science" created by CS grads
> are such pieces of garbage..  Tell you what, take NT 4.0's backup and
> restore commands and try to back up and restore a file that is larger than
> 1.4 MB.  I'll bet that there were CS grads doing that work.

That was definitely written by someone who's hardly ever had to use a
computer.  

> 
> Theory doesn't get the work done.
> 

No, theory makes the work possible.  If it wasn't for theory you'd still
be programming on the front panel.

:sb)

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5k60au$gig@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > Have you ever seen code written by engineers with no understanding of
  > computer science? :))

   It looks almost as bad as code written by programmers with no
knowledge of software engineering. ;-)

   It is possible to learn, and do, software engineering without a
computer science background.  But on large projects both computer
science and software engineering are necessary.  It is handy if most
project personnel, including the project leaders, know both.
--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Jay Martin]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <5k60au$gig@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

>  > Have you ever seen code written by engineers with no understanding of
>  > computer science? :))

>   It looks almost as bad as code written by programmers with no
>knowledge of software engineering. ;-)

>   It is possible to learn, and do, software engineering without a
>computer science background.  But on large projects both computer
>science and software engineering are necessary.  It is handy if most
>project personnel, including the project leaders, know both.

Huh?  By definition, if the subject has to do with practical software
construction then that is in software engineering.  If it is worthless
theoretical masturbation, then that of course lies in the domain of
Computer "Science".

Jay

Re: Any research putting c above ada?

[Kevin Cline]

jmartin@cs.ucla.edu (Jay Martin) wrote:

>Huh?  By definition, if the subject has to do with practical software
>construction then that is in software engineering.  If it is worthless
>theoretical masturbation, then that of course lies in the domain of
>Computer "Science".

Some knowledge of computer science is a must when working on most systems
today.  How can one select appropriate data structures without a general
knowledge of algorithmic complexity?  How can one design multi-threaded
applications without some knowledge of techniques for managing shared
resources?

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5k8b0p$25f2@uni.library.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:

  > Huh?  By definition, if the subject has to do with practical
  > software construction then that is in software engineering.  If it
  > is worthless theoretical masturbation, then that of course lies in
  > the domain of Computer "Science".

    If you want to say that software engineering is about practical
software construction, fine.  But if you don't know how to navigate
around the slippery shores of the halting problem, or NP-completeness,
you will spend an awful lot of time trying to solve problems that are
not practically solvable.  

    Notice the wording there--if you know how
and where to draw the line, you can solve your problem without
generalizing it into a "simpler" case that is out of reach.  Or, if
you know what you are doing you can, with little trouble, solve an
NP-complete problem.  For example, Ada compilers are required to solve
bin packing problems.  In general, the bin packing problems the
compiler sees are easy to solve, and if you go to the effort of
embedding a large and difficult problem in your record representation
clause, well compiling it might take a while.

   Another example in an Ada context is the discussion we just had
about elaboration order.  In theory, finding a "good" elaboration
order for any Ada program is equivalent to the halting problem.  In
practice, any compiler can find a legal order, and most compilers will
find a "good" order for most programs.  (A good order here is one
which does not raise Program_Error for any input.)

   And by the way, don't ask for the compiler to reject any program
that doesn't run to completion.  In this end of the programming
business we have tools which reject programs that can be shown to halt
for any reason.  Of course, I can't prove that any arbitrary embedded
program never halts, but I don't want to.  What I want is a set of
rules so that my programs can be shown never to halt.  That is a
possible (and not too difficult) task.

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Jay Martin]

>In article <5k8b0p$25f2@uni.library.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:

>  > Huh?  By definition, if the subject has to do with practical
>  > software construction then that is in software engineering.  If it
>  > is worthless theoretical masturbation, then that of course lies in
>  > the domain of Computer "Science".

>    If you want to say that software engineering is about practical
>software construction, fine.  But if you don't know how to navigate
>around the slippery shores of the halting problem, or NP-completeness,
>you will spend an awful lot of time trying to solve problems that are
>not practically solvable.  

Heh, if go my "definition" then practical algorithm design is software
engineering just like mechanical engineers can use the concept of
momentum from physics or equations from mathematics.  But the
difference is that SE concentrates on actual implementation of
practical algorithms to solve real problems while CS would concentrate
on the mathematical theory.  Though sadly it seems the real Software
Engineering field seems to be concentrating on "software management"
leaving technical issues to CS who mostly punt.

There is nothing magical about the "halting problem" or "NP (We think
its exponential but we don't have a cool proof) completeness" that
can't be understood by programmers with minimal theorizing.  The
"halting problem" is proved with like a 5 line proof.  Computer
Science stole most of he practical aspects of this stuff from
Operation Research anyway.

>    Notice the wording there--if you know how
>and where to draw the line, you can solve your problem without
>generalizing it into a "simpler" case that is out of reach.

I don't think it is so hard:

If generalize to exponential problem => stop.
If have exponential problem => try to simplify/restrict problem to non-exponential probem.
If have exponential problem => pull approximating heuristic program out of ass or try a
                               some search techniques like simulating annealing.

Do you need a PHD in CS theory to do this? Probably not.

>Or, if
>you know what you are doing you can, with little trouble, solve an
>NP-complete problem.  For example, Ada compilers are required to solve
>bin packing problems.  In general, the bin packing problems the
>compiler sees are easy to solve, and if you go to the effort of
>embedding a large and difficult problem in your record representation
>clause, well compiling it might take a while.

Seems more like practical software engineering to me than theory.  You have an
exponential problem so you use some approximating algorithm that solves the
problem for simple cases but punts optimality for complex cases.  

>   Another example in an Ada context is the discussion we just had
>about elaboration order.  In theory, finding a "good" elaboration
>order for any Ada program is equivalent to the halting problem.  In
>practice, any compiler can find a legal order, and most compilers will
>find a "good" order for most programs.  (A good order here is one
>which does not raise Program_Error for any input.)

Sounds like specific problem heuristics again, not theory.

How much does this theory actually come up in real software
development?  When it does how much can be easily pulled out of
standard references?  Is it justified in Computer Science to only
concentrate on and worship theory in some pathetic case of "Physics
Envy" while basic software engineering research is not done and basic
SE skills are not taught contributing to the reason why the whole software
field to be a dispicable sewer?  I think not.

Jay

Re: Any research putting c above ada?

[Kevin Cline]

jmartin@cs.ucla.edu (Jay Martin) wrote:

>If generalize to exponential problem => stop.
>If have exponential problem => try to simplify/restrict problem to non-exponential probem.
>If have exponential problem => pull approximating heuristic program out of ass or try a
>                               some search techniques like simulating annealing.
>
>Do you need a PHD in CS theory to do this? Probably not.

It helps a lot for the "try some search techniques" part.

>>Or, if
>>you know what you are doing you can, with little trouble, solve an
>>NP-complete problem.  For example, Ada compilers are required to solve
>>bin packing problems.  

That's interesting.  Why?

>>In general, the bin packing problems the
>>compiler sees are easy to solve, and if you go to the effort of
>>embedding a large and difficult problem in your record representation
>>clause, well compiling it might take a while.

That's fine for a compiler, but there are lots of real applications where a
reasonable solution is needed in reasonable time.

>How much does this theory actually come up in real software
>development?  When it does how much can be easily pulled out of
>standard references?  Is it justified in Computer Science to only
>concentrate on and worship theory in some pathetic case of "Physics
>Envy" while basic software engineering research is not done and basic
>SE skills are not taught contributing to the reason why the whole software
>field to be a dispicable sewer?  I think not.

Actually, things are great in the software field.  I can buy amazingly
powerful and easy to use applications to run on an amazingly powerful computer
that sits on my desk at home, all for only a couple weeks salary.  Things have
never been better.  So what if lots of new S/W development efforts fail.  80%
of all new restaurants close within a year.  No one complains about a crisis
in American cooking.  There are still plenty of restaurants open.

Re: Any research putting c above ada?

[Robert I. Eachus]

I wrote:

   >>Or, if you know what you are doing you can, with little trouble,
   >>solve an NP-complete problem.  For example, Ada compilers are
   >>required to solve bin packing problems.

In article <978312A1F7E892FA.65E9443A2651231A.2F79B86BA594FA84@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) asks:

  > That's interesting.  Why?

  The algorithm is easy to implement, and in most of the cases that
users are interested in the results will be quick.  The issue comes up
with records structures.  You have some components which need to be
stored at a byte, word, or double word boundary, and others that you
want to cram in gaps (by putting a size restriction on the type).

  Now in the usual case where all the restrictions and most of the
object sizes are powers of two, there is no problem.  But what if you
have one component which takes three bytes?  We decided that the
compiler is required to deal with it.

  This means that you can encode an arbitrary bin packing problem in
these representation specifications, and read the result out of the
listing if you clever.  But so what.  It is much easier to write a
(compiler) implementation which solves the expected cases quickly,
some weird cases slowly, and pathological cases sometime in the next
millenium, than for us to enumerate which cases must be handled
correctly and which ones can be done with heuristics.

  Besides, in the embedded world it may occaisionally be the case that
you are willing to trade three day compiles for optimal packing of
data into a 16K PROM.  (You can always loosen the size clause when
debugging.)

  > That's fine for a compiler, but there are lots of real
  > applications where a reasonable solution is needed in reasonable
  > time.

  Agreed, and what is reasonable (for all instances of reasonable in
the above sentence) is very much the heart of software engineering.

  > Actually, things are great in the software field.  I can buy
  > amazingly powerful and easy to use applications to run on an
  > amazingly powerful computer that sits on my desk at home, all for
  > only a couple weeks salary.  Things have never been better.  So
  > what if lots of new S/W development efforts fail.  80% of all new
  > restaurants close within a year.  No one complains about a crisis
  > in American cooking.  There are still plenty of restaurants open.

   And I can buy (or get as freeware or shareware) amazingly powerful
and easy to use applications to run on an amazingly powerful computer
that sits on my desk at home.  My Amiga can even run MS-DOS (and
Windows 3.1 on top) in emulation mode if I need to run any of the
poorly written expensive junk that floats all over the Wintel world.
However, I draw the line at spending a week's salary for any software.
BTW, I'm thinking of upgrading.  There was a $300 board just announced
which will put a 120 MHz 603e PowerPC chip in my Amiga 1200 as a
co-processor running Windows NT.  My real problem is whether to run NT
or Unix on the PPC side. ;-)


					Robert I. Eachus

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

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <EACHUS.97Apr30143016@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:

>   It is possible to learn, and do, software engineering without a
>computer science background.  But on large projects both computer
>science and software engineering are necessary.  It is handy if most
>project personnel, including the project leaders, know both.

Ah. The thing is, I thought that all good computer science programs included
software engineering as part of the curriculum, and I always saw them
as inseparable. I realize that this is not the case in every institution. 

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5k88f8$387@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > Ah. The thing is, I thought that all good computer science
  > programs included software engineering as part of the curriculum,
  > and I always saw them as inseparable. I realize that this is not
  > the case in every institution.

   Unfortunately true.  Some programs, MIT and UCLA have been
mentioned here, concentrate on computer science theory, some Worcester
Polytechnic Institute, for example, are very software engineering
oriented, and most are in between.

   But in reality it is the responsibility of the students to get the
knowledge that they need.  Even at heavy theory schools you can get
practical experience, and (elective) courses to cover the holes.  It
is possible to get through the CS program at MIT without learning C,
C++, Fortran, COBOL, Ada, Pascal, or even BASIC.  But who would want
to?

   (Flame retardant: I don't think you can get through without a
course in Programming Languages.  But when teaching the course, and I
have--but not at MIT, the tendency is to cover less popular languages
which are interesting for other reasons.  I covered Algol 60, PL/I,
APL, and Common Lisp.)
--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[John Apa]

Robert I. Eachus wrote:
> 
> In article <5k88f8$387@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
> 
>   > Ah. The thing is, I thought that all good computer science
>   > programs included software engineering as part of the curriculum,
>   > and I always saw them as inseparable. I realize that this is not
>   > the case in every institution.
> 
>    Unfortunately true.  Some programs, MIT and UCLA have been
> mentioned here, concentrate on computer science theory, some Worcester
> Polytechnic Institute, for example, are very software engineering
> oriented, and most are in between.
> 
>    But in reality it is the responsibility of the students to get the
> knowledge that they need.  Even at heavy theory schools you can get
> practical experience, and (elective) courses to cover the holes.  It
> is possible to get through the CS program at MIT without learning C,
> C++, Fortran, COBOL, Ada, Pascal, or even BASIC.  But who would want
> to?
> 
>    (Flame retardant: I don't think you can get through without a
> course in Programming Languages.  But when teaching the course, and I
> have--but not at MIT, the tendency is to cover less popular languages
> which are interesting for other reasons.  I covered Algol 60, PL/I,
> APL, and Common Lisp.)
> --

Yes it is the student's responsibility to get the knowledge they need.
However the current trend in education is to over generalize so that the
student is a wonderful citizen by forcing them to take highly irrelevant
classes. The cal state system requires over 60% of classes not be
related to scientific majors. Yes, I probably picked the wrong school,
but this seems to be a general trend in "higher" education. Many schools
have gone away from preparing students for the "real" world. They need
to get back to their original purpose.

I have an EE degree. Many of my friends were CS majors. All very smart
and also unprepared for the job market (for better or worse, many live
in Redmond now, SW hell I think). They were taught the wonderful
languages of lisp, algol, and other "interesting" languages. However,
these are things that do not help you find a job. Which, I think most
people will agree, is the main goal of most people going to college.
College is not about learning, it's about jumping through all the right
hoops and writing down what the profs want to see. Anyone who doesn't
believe that has probably never pointed out a design error to a prof in
class. Granted this is worst case but in my (and many of my associates
and friends) experience this is the way many profs work. I did have a
few, maybe 5, profs who were able to teach and encouraged us. It should
not be that way. I don't mean to be preachy on this but my college
career was full of profs in both the technical and non-technical fields
who "knew" everything and were more than willing to fail you for
questioning that. Funny since they always insisted that questions were
important to learning.

We will always need people in academia to do research, but at the same
time someone has to know how to go out and engineer solutions to real
world problems. After all, someone has to keep the planes in the air.

I have long thought that we need to have a degree in the field of
Software Engineering for those who want to learn how to apply SW
technology to the real world. CS could be free to remain dedicated to
doing the pure research that so many of the profs love. It would also
give students more freedom to chose their career direction.

CS covers many great things, but solving design problems is not one of
them (at least in my experience). Now that I am doing real-time embedded
systems using Ada95, I find that most of the _SW_ engineers are indeed
engineers and not CS grads. We have engineers from all fields:
aeronautics, chem, civil, mechanical, Electrical, and even genetics. The
big difference is that in the engineering departments of schools
students are shown how to solve problems.

My $0.02.

John

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

-- 
***********************************
Standard Disclaimers Apply
John Thomas Apa
Replace "DIE_SPAMMER" with "delphi" to email.
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Any research putting c above ada?

[Kevin Cline]

John Apa <japa@DIE_SPAMMER.dasd.honeywell.com> wrote:

>I have an EE degree. Many of my friends were CS majors. All very smart
>and also unprepared for the job market (for better or worse, many live
>in Redmond now, SW hell I think). 

What makes you think Microsoft is a bad place to work?  They have developed
software that a great many people find extremely useful.  To me, it beats the
heck out of developing a one-off application that may or may not be fielded.
It also pays better.

>They were taught the wonderful
>languages of lisp, algol, and other "interesting" languages. However,
>these are things that do not help you find a job. 

I interview one or two people a week, from new college hires to very
experienced professionals.  It is not true that studying LISP and ALGOL
will not help you get a job.  Actually, although we program in C++, I do not
really care what languages candidates know, provided that
they can demonstrate knowledge commensurate with their training and
experience.  If a new graduate can give me some good reasons why they enjoyed
programming in LISP more than in ALGOL, I will hire them, because they are
likely to have a solid understanding of C++ (or any other language) in short
order.  

>Which, I think most people will agree, is the main goal of most people going to college.
>College is not about learning, it's about jumping through all the right
>hoops and writing down what the profs want to see. 

I don't recommend anyone with this attitude, because we need adults with
problem solving skills, not juvenile grade-grubbers.  A low GPA will make it
harder for you to get an interview, but a high GPA is no guarantee of a job.
We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
couldn't demonstrate any understanding of the coursework.

> Anyone who doesn't
>believe that has probably never pointed out a design error to a prof in
>class. Granted this is worst case but in my (and many of my associates
>and friends) experience this is the way many profs work. 

That is truly unfortunate.  However, with industry salaries for top-notch
experienced professionals in six figures now, it is hard to get good
instruction for $100/credit hour.  If you do, be grateful; it's charity.

> I did have a few, maybe 5, profs who were able to teach and encouraged us. 

Five!  That's not so bad.  I hope you learned everything you could from them,
and took all possible steps to complain about the rest.

>We will always need people in academia to do research, but at the same
>time someone has to know how to go out and engineer solutions to real
>world problems. After all, someone has to keep the planes in the air.

Which is hard to do with no understanding of fundamental data structures and
algorithms.

>I have long thought that we need to have a degree in the field of
>Software Engineering for those who want to learn how to apply SW
>technology to the real world. 

There are many schools that have more practical programs.
But I believe that some knowledge of CS theory is required to work effectively
on new applications.  I do not recommend candidates who are unable to
demonstrate some knowledge of CS theory.

>CS could be free to remain dedicated to
>doing the pure research that so many of the profs love. It would also
>give students more freedom to chose their career direction.

Few undergraduates know enough to choose their career direction.
But a good understanding of CS opens the most doors, and leads to the most
rewarding careers.

>CS covers many great things, but solving design problems is not one of
>them (at least in my experience). 

There is not enough time in an undergraduate cirriculum to teach SW
engineering judgment.  But there are plenty of excellent books on the subject.
I suggest you try to read one technical book a month.  Soon you will be well
ahead of your classmates.

Re: Any research putting c above ada?

[Roy Grimm]

> I interview one or two people a week, from new college hires to very
> experienced professionals.  It is not true that studying LISP and ALGOL
> will not help you get a job.  Actually, although we program in C++, I do not
> really care what languages candidates know, provided that
> they can demonstrate knowledge commensurate with their training and
> experience.  If a new graduate can give me some good reasons why they enjoyed
> programming in LISP more than in ALGOL, I will hire them, because they are
> likely to have a solid understanding of C++ (or any other language) in short
> order.

I'd have to agree that this appears to be one sound method of choosing
the candidates.  Seeing that they have "tried out" languages enough to
determine favories shows a little bit of initiative.

> >Which, I think most people will agree, is the main goal of most people going
> >to college.  College is not about learning, it's about jumping through all
> >the right hoops and writing down what the profs want to see.
> 
> I don't recommend anyone with this attitude, because we need adults with
> problem solving skills, not juvenile grade-grubbers.  A low GPA will make it
> harder for you to get an interview, but a high GPA is no guarantee of a job.
> We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
> couldn't demonstrate any understanding of the coursework.

I'd have to disagree with your judgement of this "grade-grubbing"
attitude.  I am a perfect example of someone who had a "less than
stellar" academic career (graduated with less than a 3.0 GPA) but had
plenty of opportunity to demonstrate I have real problem solving
skills.  (I was on a team for an ACM programming contest and finished
two programs myself while the other two members each finished one.  That
made our team one of less than one hundred, out of more than a thousand
nation wide, that finished at least 4 out of the 6 programs in the time
allotted.  A significan percentage of teams didn't even finish one.)

When I was considered for my first job out of college, my boss (to be)
wasn't interested in my GPA in the slightest.  He asked me direct
questions about what I had done to get and/or demonstrate practical
experience and how I would respond to particular problems.  I was direct
and told him what I did (not what I thought he wanted to hear) and he
hired me.

At a homecoming a few years later, I found out that a few people in my
class who had graduated with a 4.0 in comp sci were having trouble in
their jobs maintaining COBOL code for accounting/insurance type
companies becasue they didn't know how to apply their theory to real
world situations.

> > Anyone who doesn't
> >believe that has probably never pointed out a design error to a prof in
> >class. Granted this is worst case but in my (and many of my associates
> >and friends) experience this is the way many profs work.
> 
> That is truly unfortunate.  However, with industry salaries for top-notch
> experienced professionals in six figures now, it is hard to get good
> instruction for $100/credit hour.  If you do, be grateful; it's charity.

Grateful?  Charity?  Hell, I demand it be good instruction, whatever the
price.

> > I did have a few, maybe 5, profs who were able to teach and encouraged us.
> 
> Five!  That's not so bad.  I hope you learned everything you could from them,
> and took all possible steps to complain about the rest.

When they have tenure, complaining does nothing but get you chastized...

> >We will always need people in academia to do research, but at the same
> >time someone has to know how to go out and engineer solutions to real
> >world problems. After all, someone has to keep the planes in the air.
> 
> Which is hard to do with no understanding of fundamental data structures and
> algorithms.

But you can teach the fundamentals in a few weeks, rather than in the
two semesters they currently waste.  If students spent more time
learning how to solve real problems, they would be able to pick up the
theory much faster.  They would see a problem and ask the intelligent
questions about how to solve it.  At that point, you can show them the
theory and how it applies in that case.  Instead, the instructors show
students the theory, spend a long time making sure people understand the
theory and move on to the next one.  Almost no time is spent applying
the theory to anything more than very focused, contrived example
problems that are easy to grade.

> >I have long thought that we need to have a degree in the field of
> >Software Engineering for those who want to learn how to apply SW
> >technology to the real world.
> 
> There are many schools that have more practical programs.
> But I believe that some knowledge of CS theory is required to work
> effectively on new applications.  I do not recommend candidates who are
> unable to demonstrate some knowledge of CS theory.

I would go a step farther and demand that they be able to demonstrate
the ability to _apply_ that theory.  Unless, of course, they were only
doing theoretical work...

> >CS could be free to remain dedicated to
> >doing the pure research that so many of the profs love. It would also
> >give students more freedom to chose their career direction.
> 
> Few undergraduates know enough to choose their career direction.
> But a good understanding of CS opens the most doors, and leads to the most
> rewarding careers.

Ah, but good understanding of engineering coupled with computer science
would not only open the door but get you all the way inside and down the
hall a ways...

> >CS covers many great things, but solving design problems is not one of
> >them (at least in my experience).
> 
> There is not enough time in an undergraduate cirriculum to teach SW
> engineering judgment.

Horse Hockey!

How would software engineering be any different than any other
discipline?  Do they not teach engineering judgement to the other
engineering disciplines?  We recently hired a new graduate, straight out
of engineering school.  He's got a much better handle on engineering
judgement than any of the software weenies (myself included) did when we
started.  I was able to coach him on the fundamentals of algorithm and
data structure design in just a few weeks.  Teach someone to solve
problems and they will pick up the theory much faster.  They know how to
ask more intelligent questions.

> But there are plenty of excellent books on the subject. I suggest you try to
> read one technical book a month.  Soon you will be well ahead of your
> classmates.

Sure.  If you are one of the 5% of students who are able to comprehend
technical manuals, that's good advice.  What about for the rest of them?

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[John Apa]

I missed the original response to my post, but I'm glad that someone
else is willing to state the truth about the state of "higher education"
in this country. The original idea of my post was simply to state that
there was a need for an Applied CS or SW Engineering field of study in
school. I made some comments about the state of Technical education and
the following ensued, I probably should have snipped more:

I fully agree with what Mr Grimm has written.

Roy Grimm wrote {The shear unadulterated truth}:
> 
> > I interview one or two people a week, from new college hires to very
> > experienced professionals.  It is not true that studying LISP and ALGOL

Are you an engineer or a HR type.

> > will not help you get a job.  Actually, although we program in C++, I do not
> > really care what languages candidates know, provided that
> > they can demonstrate knowledge commensurate with their training and
> > experience.  If a new graduate can give me some good reasons why they enjoyed
> > programming in LISP more than in ALGOL, I will hire them, because they are
> > likely to have a solid understanding of C++ (or any other language) in short
> > order.
> 
> I'd have to agree that this appears to be one sound method of choosing
> the candidates.  Seeing that they have "tried out" languages enough to
> determine favories shows a little bit of initiative.
> 

Yes, it's always good to hire people who have initiative and have a wide
field of knowledge. I have also been in the position of reviewing and
interviewing. I could care less what school projects someone did or what
their GPA was. If someone can convince me that they know what they are
doing and that they can solve problems I will recommend them. But then
I'm in the engineering field, we solve problems. There is always a need
for people to do the academic research and push the technology ahead,
but unless it is applied it's useless. People must know how to apply
what they learn in school, or it does no good to anyone.

> > >Which, I think most people will agree, is the main goal of most people going
> > >to college.  College is not about learning, it's about jumping through all
> > >the right hoops and writing down what the profs want to see.
> >
> > I don't recommend anyone with this attitude, because we need adults with
> > problem solving skills, not juvenile grade-grubbers.  A low GPA will make it
> > harder for you to get an interview, but a high GPA is no guarantee of a job.

I had 25 companies calling me for interviews. I don't even know what my
gpa was. I had no problems, no one cared to ask me for it. I know of
others in the same position. My knowledge and experience make me
valuable. What I did years ago in the artificial academic world is
irrelevant. The first company I worked for out of school didn't care
either. So what's your point, your company discriminates against good
engineers who had to work through school and couldn't spend 100% on
classes? Then I'm sorry for your company.

> > We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
> > couldn't demonstrate any understanding of the coursework.
> 
> I'd have to disagree with your judgement of this "grade-grubbing"
> attitude.  I am a perfect example of someone who had a "less than
> stellar" academic career (graduated with less than a 3.0 GPA) but had
> plenty of opportunity to demonstrate I have real problem solving
> skills.  (I was on a team for an ACM programming contest and finished
> two programs myself while the other two members each finished one.  That
> made our team one of less than one hundred, out of more than a thousand
> nation wide, that finished at least 4 out of the 6 programs in the time
> allotted.  A significan percentage of teams didn't even finish one.)

I've been a SW engineer for 8 years now and during my recent job search
no one asked what my GPA was. I don't even know, who cares. My father
who has 45 years of engineering experience was looking for a new job a
few years ago, one of the HR people wanted to know his GPA. That shows
an unrivaled level of stupidity, yes the HR person did lose his job over
that one. He had to work and fight a war while going to school, he is
one of the engineers who got us to the moon and helped us win the cold
war. I doubt that I will ever gain as much knowledge as he possesses.

GPA is not a measure of anything but your ability to get through school.
I hated school, because it was to slow and lacked any creativity. I
loved my reasearch and design courses because I had to think to figure
things out. I tutored many of the "4.0" students I went to class with,
many would have failed had I not helped them understand how to apply the
theories we were taught. This doesn't make me smarter than them, nor
them smarter than me for having a 4.0.

> 
> When I was considered for my first job out of college, my boss (to be)
> wasn't interested in my GPA in the slightest.  He asked me direct
> questions about what I had done to get and/or demonstrate practical
> experience and how I would respond to particular problems.  I was direct
> and told him what I did (not what I thought he wanted to hear) and he
> hired me.

I'm still getting calls on my resume because of the things I know and
the experience I've gained over the years. If my gpa is more important
than my knowledge and experience then I sure don't want to work at that
company. They probably haven't got a clue as to how to do real
engineering. Knowledge is power. Arbitrary social standards are
meaningless.

> 
> At a homecoming a few years later, I found out that a few people in my
> class who had graduated with a 4.0 in comp sci were having trouble in
> their jobs maintaining COBOL code for accounting/insurance type
> companies becasue they didn't know how to apply their theory to real
> world situations.

One of my friends went on to get a MS, yes I tutored some of those
classes also. This particular friends graduated 1st in the class with a
4.0 MS with honors. The job aquired is as a crew chief on a phone
company repair team. Most of the people graduated with me are in nowhere
jobs because they weren't able to apply their CS skills to anything
real.  A terrible waste of good people. Thank the educational proponents
of the socially balanced student for that.

> 
> > > Anyone who doesn't
> > >believe that has probably never pointed out a design error to a prof in
> > >class. Granted this is worst case but in my (and many of my associates
> > >and friends) experience this is the way many profs work.
> >
> > That is truly unfortunate.  However, with industry salaries for top-notch
> > experienced professionals in six figures now, it is hard to get good
> > instruction for $100/credit hour.  If you do, be grateful; it's charity.

Don't EVER EVER tell me that my outrageous taxes are charity! That's
crap. I had to go to school and pay while others get full scholarships
because of their race or religion. I wasn't so lucky. I had to pay for
my education, and for others who where studying basket weaving and
partying everyweekend. SO DON'T EVER EQUATE MY EDUCATION AS CHARITY!

> 
> Grateful?  Charity?  Hell, I demand it be good instruction, whatever the
> price.

I didn't have the 30k to buy my degree. I had to work my way through it.
I couldn't afford to put my parents into poverty so I could go to CM or
MIT. Sorry. I guess the schools that my taxes and my parents taxes went
into are just crap. I had the gall to go to school funded by our
overbearing tax structure and expect thet the professors would a) be
professional and b) actually have a clue. I was wrong for the most part.
And for the miss guided soul who thinks you can do anything about a
tenured professor, let me tell you that I was deliberated failed in two
classes for complaining and going to to the department chair. I tried to
appeal but of course the president of the school and the oversight
commitee wouldn't even convene to consider it. But that was only because
they were never actually on campus. Tenured professors know that short
of actually killing a student they will not be fired, that must change.
Bad professors are destroying the very institutions that they hide
behind.

> 
> > > I did have a few, maybe 5, profs who were able to teach and encouraged us.
> >
> > Five!  That's not so bad.  I hope you learned everything you could from them,

It's five out of about 100 in all my classes and labs. 5% success rate,
if that's your definition of not so bad then I feel sorry for you.

> > and took all possible steps to complain about the rest.
> 
> When they have tenure, complaining does nothing but get you chastized...
> 
> > >We will always need people in academia to do research, but at the same
> > >time someone has to know how to go out and engineer solutions to real
> > >world problems. After all, someone has to keep the planes in the air.
> >
> > Which is hard to do with no understanding of fundamental data structures and
> > algorithms.
> 
> But you can teach the fundamentals in a few weeks, rather than in the
> two semesters they currently waste.  If students spent more time
> learning how to solve real problems, they would be able to pick up the
> theory much faster.  They would see a problem and ask the intelligent
> questions about how to solve it.  At that point, you can show them the
> theory and how it applies in that case.  Instead, the instructors show
> students the theory, spend a long time making sure people understand the
> theory and move on to the next one.  Almost no time is spent applying
> the theory to anything more than very focused, contrived example
> problems that are easy to grade.

YES YES YES. School should be about learning how to think. That is what
is important. The details of any language or field can be picked up
fairly quickly if you KNOW how to think and reason. I know many people
who have no formal training in CS, yet they are very brilliant. One has
a chemical engineering degree, one of the toughest degrees to get. He
learned the stuff that was important as he went along his career.

> 
> > >I have long thought that we need to have a degree in the field of
> > >Software Engineering for those who want to learn how to apply SW
> > >technology to the real world.
> >
> > There are many schools that have more practical programs.
> > But I believe that some knowledge of CS theory is required to work
> > effectively on new applications.  I do not recommend candidates who are
> > unable to demonstrate some knowledge of CS theory.
> 
> I would go a step farther and demand that they be able to demonstrate
> the ability to _apply_ that theory.  Unless, of course, they were only
> doing theoretical work...

Being able to apply a little knowledge is much better than knowing
everything and not having a clue as to what to do with it. It's the car
analogy. A big engine doesn't do any good if you're up on blocks or have
small tires. If you can't get power to the ground you're not going
anywhere.

> 
> > >CS could be free to remain dedicated to
> > >doing the pure research that so many of the profs love. It would also
> > >give students more freedom to chose their career direction.
> >
> > Few undergraduates know enough to choose their career direction.
> > But a good understanding of CS opens the most doors, and leads to the most
> > rewarding careers.

If you are going to college and don't have a clue as to what you want to
be then it's already to late and you're wasting time in college. How
would that work, "Should I be a CS, EE, or a liberal arts student?" I
have a EE degree. I knew I wanted to be an engineer since grade school.
The people I went to school with all know what they wanted to be before
they got to college. It was only a matter of deciding which disciple to
enter. With my experience right now I was able to pick the area where I
wanted to work and live, the job was there and they were glad to hire me
on. 

> 
> Ah, but good understanding of engineering coupled with computer science
> would not only open the door but get you all the way inside and down the
> hall a ways...

It'll get you your offer letter before you leave from the interview.

> 
> > >CS covers many great things, but solving design problems is not one of
> > >them (at least in my experience).
> >
> > There is not enough time in an undergraduate cirriculum to teach SW
> > engineering judgment.

I call BS on this. If you can't teach someone to reason and think in 4
years then the person is either destined for the trades or more likely
the school is crap! Or are you saying that CS people aren't as smart as
other engineers? Either way it's just pure crap. CS is a real degree
just like engineering, I think it needs to have more focus on the
applied side of things.

> 
> Horse Hockey!
> 
> How would software engineering be any different than any other
> discipline?  Do they not teach engineering judgement to the other
> engineering disciplines?  We recently hired a new graduate, straight out
> of engineering school.  He's got a much better handle on engineering
> judgement than any of the software weenies (myself included) did when we
> started.  I was able to coach him on the fundamentals of algorithm and
> data structure design in just a few weeks.  Teach someone to solve
> problems and they will pick up the theory much faster.  They know how to
> ask more intelligent questions.
> 
> > But there are plenty of excellent books on the subject. I suggest you try to
> > read one technical book a month.  Soon you will be well ahead of your
> > classmates.
> 
> Sure.  If you are one of the 5% of students who are able to comprehend
> technical manuals, that's good advice.  What about for the rest of them?

Best advice I got from my father (over 50 years in engineering) pick up
a book read 3 or 4 chapters and call it read. I do have  fairly high
comprehension rate, unfortunately most of the books that are put out by
"publish or perish" professors aren't worth the paper they're printed
on, much less the 60-70 dollars they seem to feel is justified. At to
this the fact that I have a fammily that I love and spend time with. One
book a month is very hard. My family comes first. No matter what. Anyone
who doesn't have this attitude will end up messing up their life. I've
seen it happen to many times. It's sad. My father put the family first
and it did affect his career, but we're al happy he did. We have a fully
functional family.

> 
> --
> Voicing my own opinion, not speaking as a company representative...
> 
> Roy A. Grimm
> Rockwell Collins Avionics
> Cedar Rapids, Iowa
> ragrimm@cca.rockwell.com

Thank you Roy for backing me up on this stuff.

One of my co-workers here has a 4.0 and honors and such. I showed him
this post and he laughed about the gpa meaning anything. It's what you
know and how you apply it that is important. I apologize to all the
profs and CS people who know what they are doing. Some of my comments
may be to broadly applied, and that is not what I meant. My original
point was that a CS degree alone does not prepare you for the real
world, unless you have the initiative to go out on your own and do it.
The concept that it's to hard to do SW engineering in 4 years, or that
schools can't teach it properly is simply more evidence showing that the
CS schools aren't effective in applied CS. Perhaps Applied CS is a
better term for a degree than SW Engineer. I don't know, but touting
educational institutions as being the final solution is a joke.

I guess the best equalizer is living well. I'll be retired by the time
I'm 45. Living up in the Rockies and enjoying life. Hmm....

John


-- 
***********************************
Standard Disclaimers Apply
John Thomas Apa
Senior Software Engineer
Replace "DIE_SPAMMER" with "delphi" to email.
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Any research putting c above ada?

[Roy Grimm]

John Apa wrote:
> 
> I missed the original response to my post, but I'm glad that someone
> else is willing to state the truth about the state of "higher education"
> in this country. The original idea of my post was simply to state that
> there was a need for an Applied CS or SW Engineering field of study in
> school. I made some comments about the state of Technical education and
> the following ensued, I probably should have snipped more:

I've snipped quite a bit myself...

> I fully agree with what Mr Grimm has written.

Thanks.  It's good to know that I'm not the only one who feels this way.

> Roy Grimm wrote {The shear unadulterated truth}:
>
>Are you an engineer or a HR type.

I would be an engineer.  I started at Rockwell as a software technician
writing structural tests for the standard libraries in a C compiler. 
After a short time, I was able to show that I can really develop
software so they put me on a development project where I ported an Ada
application from one system to an entirely new target architecture and
compiler.  I took off with it so fast they decided to promote me to
engineer.  Considering that I have a B.A. in comp sci and math from an
institution that isn't accredited by the "right" committee, it's quite
suprising that the H.R. department let the promotion through.  Though,
when several levels of management in several chains of command step up
to say "I don't care how, make him an engineer", it does eventually go
through, despite the bitchings of the pencil pushing bureaucrats. 
(Thanks to everyone who went to bat for me.)

> GPA is not a measure of anything but your ability to get through school.
> I hated school, because it was to slow and lacked any creativity. I
> loved my reasearch and design courses because I had to think to figure
> things out. I tutored many of the "4.0" students I went to class with,
> many would have failed had I not helped them understand how to apply the
> theories we were taught. This doesn't make me smarter than them, nor
> them smarter than me for having a 4.0.

It doesn't show that you are any smarter but it does demonstrate that
you are more able to do the real work than they were.  When it comes to
engineering positions, that's what counts.

> I'm still getting calls on my resume because of the things I know and
> the experience I've gained over the years. If my gpa is more important
> than my knowledge and experience then I sure don't want to work at that
> company. They probably haven't got a clue as to how to do real
> engineering. Knowledge is power. Arbitrary social standards are
> meaningless.

The social standards are not entirely meaningless.  Sometimes, you can
find yourself in a position where the people in power adhere to those
standards.  In that case, you just grin and bear it while you circulate
resumes.  Either that or you quit, become a contractor, and sell your
services to the company when they desparately need someone who can bail
them out while their regular employees are arguing about theoretical
issues.

> One of my friends went on to get a MS, yes I tutored some of those
> classes also. This particular friends graduated 1st in the class with a
> 4.0 MS with honors. The job aquired is as a crew chief on a phone
> company repair team. Most of the people graduated with me are in nowhere
> jobs because they weren't able to apply their CS skills to anything
> real.  A terrible waste of good people. Thank the educational proponents
> of the socially balanced student for that.

I recently ran into someone I went to high school with whom I constantly
debated the relative merits of good grades (among other things).  He
graduated from a good college and even got really good grades.  I ran
into him when he delivered pizza to my house one night...

Personally, I think that the average student has the ability to be
taught not only how to be an engineer but also has the time to broaden
their minds in other disciplines (literature, art, etc.).  The only
thing standing in their way is the personal agendas of the
professors/departments/institutions.  That applies not only to the
engineering side of the school, but the liberal arts side as well.  Far
too many professors and departments have (not so) hidden agendas in
their curriculum.

> YES YES YES. School should be about learning how to think. That is what
> is important. The details of any language or field can be picked up
> fairly quickly if you KNOW how to think and reason. I know many people
> who have no formal training in CS, yet they are very brilliant. One has
> a chemical engineering degree, one of the toughest degrees to get. He
> learned the stuff that was important as he went along his career.

There are just too many people in positions of power within the
institutions who won't admit/don't care that they are churning out a
bunch of useless, theory spewing hackers with no real job skills.  Until
you can change the attitude of the departments, you won't see much
change.
 
> Thank you Roy for backing me up on this stuff.

My pleasure.  Thanks for providing the sounding board.

> I guess the best equalizer is living well. I'll be retired by the time
> I'm 45. Living up in the Rockies and enjoying life. Hmm....

Living well is surely a goal, though I doubt I'll retire when I'm 45. 
My family comes from a long line of hard workers.  My 59 year old father
has more than enough "points" to retire.  However, it would look bad if
he retired before _his_ father did... :)

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Kevin Cline]

John Apa <japa@DIE_SPAMMER.dasd.honeywell.com> wrote:

>Roy Grimm wrote {The shear unadulterated truth}:

Careful with those citations!  I wrote the stuff with three >'s; Roy wrote the
stuff with two.

>> > I interview one or two people a week, from new college hires to very
>> > experienced professionals.  It is not true that studying LISP and ALGOL...
>
>Are you an engineer or a HR type.

I write software, now in C++, previously in Ada83, and before that in C.

>I had 25 companies calling me for interviews. I don't even know what my
>gpa was. 

If you mean that they were calling to hire you out of school, then
I would guess that one of the following is true:

1. Your GPA was pretty good.
2. You wrote a great resume.
3. You attended a school of some reputation.
4. You had strong co-op experience.

>I had no problems, no one cared to ask me for it. I know of
>others in the same position. My knowledge and experience make me
>valuable. What I did years ago in the artificial academic world is
>irrelevant. 

Of course.

>The first company I worked for out of school didn't care
>either. So what's your point, your company discriminates against good
>engineers who had to work through school and couldn't spend 100% on
>classes? Then I'm sorry for your company.

In companies of any size, initial screening will be done by non-engineers.
They will cut resumes of those who couldn't or wouldn't perform to some
minimum standard while in school, unless there is something extraordinary,
like co-op experience or a strong recommendation, to mitigate a poor GPA.
Personally I would tend to cut candidates who could not maintain a B average
in their CS classes unless I saw something special on the resume.

>> > We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
>> > couldn't demonstrate any understanding of the coursework.
>> 

>I've been a SW engineer for 8 years now and during my recent job search
>no one asked what my GPA was. 

Of course not.  It's irrelevant.  That was my point.  I didn't turn down the
candidate because she had a poor GPA, I rejected the candidate even though the
GPA was quite good.

>My father who has 45 years of engineering experience was looking for a new job a
>few years ago, one of the HR people wanted to know his GPA. 

That's bizarre.  I hope he didn't go to work there.

>That shows an unrivaled level of stupidity, yes the HR person did lose his job over
>that one. 

Wow!! Cool.

>> > That is truly unfortunate.  However, with industry salaries for top-notch
>> > experienced professionals in six figures now, it is hard to get good
>> > instruction for $100/credit hour.  If you do, be grateful; it's charity.
>
>Don't EVER EVER tell me that my outrageous taxes are charity! 

Let's figure this out.  Contract rates for solid software developers are now
around $60/hour, and much more for Ph.D's whose research has practical
application.  Your class meets for say 42 hours, and there are 25 students.
Each student pays $300 in tuition, for a total of $7500.  The university keeps
half and pays the professor $3750.  He teaches 42 hours and also has to
prepare course material and exams and be available outside class.
You can see that consulting is pays considerably more than teaching.
So if you get a good instructor, rest assured that he is not doing it for the
money.  He is doing it for the love of teaching.  To me, that's charity.

>I didn't have the 30k to buy my degree. I had to work my way through it.
>I couldn't afford to put my parents into poverty so I could go to CM or
>MIT. 

$30k gets you about one year at CMU or MIT these days.  I'm not happy about
that at all.  I graduated CMU in 1979 and payed $2900 in tuition my freshman
year, and $3900 my senior year.  A bargain compared to tuition these days.

>Sorry. I guess the schools that my taxes and my parents taxes went
>into are just crap. 

I never said that.  I'm sorry you had a bad experience.  There are good
schools, and if you can get admitted you can probably borrow enough money to
graduate.  I don't know if it's worth it.

>I had the gall to go to school funded by our
>overbearing tax structure and expect thet the professors would a) be
>professional and b) actually have a clue. I was wrong for the most part.
>And for the miss guided soul who thinks you can do anything about a
>tenured professor, let me tell you that I was deliberated failed in two
>classes for complaining and going to to the department chair. 

>It's five out of about 100 in all my classes and labs. 5% success rate,
>if that's your definition of not so bad then I feel sorry for you.

That's a different number than five professors out of a single department.

>Best advice I got from my father (over 50 years in engineering) pick up
>a book read 3 or 4 chapters and call it read. I do have  fairly high
>comprehension rate, unfortunately most of the books that are put out by
>"publish or perish" professors aren't worth the paper they're printed
>on, much less the 60-70 dollars they seem to feel is justified. At to
>this the fact that I have a fammily that I love and spend time with. One
>book a month is very hard. 

I'm not recommending that you read textbooks.  I'm thinking of books like
"Design Patterns", by Gamma et. al, "Peopleware" by DeMarco and somebody,
or "Debugging the Development Process" by McGuire. 

One book a month is one hour per week.  Probably less time than you spend
reading and posting to newsgroups.

Re: Any research putting c above ada?

[John Apa]

Kevin Cline wrote:
> > 
> I'm not recommending that you read textbooks.  I'm thinking of books like
> "Design Patterns", by Gamma et. al, "Peopleware" by DeMarco and somebody,
> or "Debugging the Development Process" by McGuire.
> 
> One book a month is one hour per week.  Probably less time than you spend
> reading and posting to newsgroups.

You must read much faster than anyone I know. I just worked my way
through Jacobson's book. No way to understand it if you spend only 4
hours a month. I'd never get through it. I was lucky and got to do it at
work, took my time and learned it. Not just key words and concepts from
skimming. I could take a book, skim it, go to a meeting, and sound like
an expert (seen people do this); but I wouldn't have accomplished
anything other than making other think I was smarter than I was. My
books all have notes written in the margins, and I try examples and
exercises to solidify the knowledge in my head. It takes much more than
an hour a week to really study the concepts.

This has been a long week and reviewing some of my responses, I may have
been a little hasty. I tend to get spun up quickly about grades and
schools because it is such an arbitrary standard which means practically
0 in the real world. We all know people who are brilliant, some have
high gpas and some low. My first job out of school had little to do with
my gpa. I knew many people in the industry from working to pay for
school. The best thing to get the doors open for interviews is to attend
the local professional society's meetings and get to know people in
industry. We all help friends get jobs, so the more friends we have the
easier it is to get in the door. Of course that is not enough, knowledge
and experience are the most important when it comes to signing the offer
letter.

-- 
***********************************
Standard Disclaimers Apply
John Thomas Apa
Replace "DIE_SPAMMER" with "delphi" to email.
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Any research putting c above ada?

[Kevin Cline]

John Apa <japa@DIE_SPAMMER.dasd.honeywell.com> wrote:

>Kevin Cline wrote:
>> > 
>> I'm not recommending that you read textbooks.  I'm thinking of books like
>> "Design Patterns", by Gamma et. al, "Peopleware" by DeMarco and somebody,
>> or "Debugging the Development Process" by McGuire.
>> 
>> One book a month is one hour per week.  Probably less time than you spend
>> reading and posting to newsgroups.
>
>You must read much faster than anyone I know. I just worked my way
>through Jacobson's book. No way to understand it if you spend only 4
>hours a month. 

I read pretty fast, but agree that four hours per volume is not enough for
many books.  The important thing is for new professionals to realize that they
must take the responsibility to ensure that stay marketable.  It's really sad
to interview someone looking to work on a C++ project and find out that all
they know is what they learned in a week-long course provided by their
employer two years ago.

Re: Any research putting c above ada?

[Nick Roberts]

I used to be able to read a Knuthesque volume in forty minutes flat. But
then my doctor discovered that he was overprescribing ;-)

Nick.

Re: Any research putting c above ada?

[Kevin Cline]

>> >Which, I think most people will agree, is the main goal of most people going
>> >to college.  College is not about learning, it's about jumping through all
>> >the right hoops and writing down what the profs want to see.
>> 
>> I don't recommend anyone with this attitude, because we need adults with
>> problem solving skills, not juvenile grade-grubbers.  A low GPA will make it
>> harder for you to get an interview, but a high GPA is no guarantee of a job.
>> We just turned down an MSCS graduate with a 3.5+ GPA, because the candidate
>> couldn't demonstrate any understanding of the coursework.
>
Roy Grimm <ragrimm@cca.rockwell.com> wrote:

>I'd have to disagree with your judgement of this "grade-grubbing"
>attitude.  I am a perfect example of someone who had a "less than
>stellar" academic career (graduated with less than a 3.0 GPA) but had
>plenty of opportunity to demonstrate I have real problem solving
>skills.  (I was on a team for an ACM programming contest and finished
>two programs myself while the other two members each finished one.  That
>made our team one of less than one hundred, out of more than a thousand
>nation wide, that finished at least 4 out of the 6 programs in the time
>allotted.  A significan percentage of teams didn't even finish one.)

You didn't read my post carefully enough, and evidently "grade-grubber" isn't
well understood either.  I just said that a low GPA makes it harder to get an
interview.  I then indicated that it played little or no part in my evaluation
of a candidate.  A grade grubber is a student interested in expending the
minimum possible effort to obtain a desired grade, with no interest in
mastering the subject.
>
>At a homecoming a few years later, I found out that a few people in my
>class who had graduated with a 4.0 in comp sci were having trouble in
>their jobs maintaining COBOL code for accounting/insurance type
>companies becasue they didn't know how to apply their theory to real
>world situations.
>

The probably didn't understand the theory either, but were able to memorize
enough bullet points to pass the exams.  This reflects poorly on your
instution.

>> > Anyone who doesn't
>> >believe that has probably never pointed out a design error to a prof in
>> >class. Granted this is worst case but in my (and many of my associates
>> >and friends) experience this is the way many profs work.
>> 
>> That is truly unfortunate.  However, with industry salaries for top-notch
>> experienced professionals in six figures now, it is hard to get good
>> instruction for $100/credit hour.  If you do, be grateful; it's charity.
>
>Grateful?  Charity?  Hell, I demand it be good instruction, whatever the
>price.

You can demand all you want, but if you pay a government-regulated
below-market price, there will be a shortage.

>
>> > I did have a few, maybe 5, profs who were able to teach and encouraged us.
>> 
>> Five!  That's not so bad.  I hope you learned everything you could from them,
>> and took all possible steps to complain about the rest.
>
>When they have tenure, complaining does nothing but get you chastized...
>
>> >We will always need people in academia to do research, but at the same
>> >time someone has to know how to go out and engineer solutions to real
>> >world problems. After all, someone has to keep the planes in the air.
>> 
>> Which is hard to do with no understanding of fundamental data structures and
>> algorithms.
>
>But you can teach the fundamentals in a few weeks, rather than in the
>two semesters they currently waste.  

I disagree strongly.  Obviously we disagree on how much knowledge is relevant.

>If students spent more time learning how to solve real problems, they would be able to pick up the
>theory much faster.  

I don't believe this at all.  I have known many experienced developers who
wrote ridiculously inefficient software because of a complete lack of
knowledge of operating system services, the language they were using, and
fundamental data structures.

>They would see a problem and ask the intelligent
>questions about how to solve it.  At that point, you can show them the
>theory and how it applies in that case.  

"Experience is a dear teacher, but fools will learn at no other."

I think this would be painfully slow.


>Instead, the instructors show
>students the theory, spend a long time making sure people understand the
>theory and move on to the next one.  Almost no time is spent applying
>the theory to anything more than very focused, contrived example
>problems that are easy to grade.
>
>> >I have long thought that we need to have a degree in the field of
>> >Software Engineering for those who want to learn how to apply SW
>> >technology to the real world.
>> 
>> There are many schools that have more practical programs.
>> But I believe that some knowledge of CS theory is required to work
>> effectively on new applications.  I do not recommend candidates who are
>> unable to demonstrate some knowledge of CS theory.
>
>I would go a step farther and demand that they be able to demonstrate
>the ability to _apply_ that theory.  Unless, of course, they were only
>doing theoretical work...
>
>> >CS could be free to remain dedicated to
>> >doing the pure research that so many of the profs love. It would also
>> >give students more freedom to chose their career direction.
>> 
>> Few undergraduates know enough to choose their career direction.
>> But a good understanding of CS opens the most doors, and leads to the most
>> rewarding careers.
>
>Ah, but good understanding of engineering coupled with computer science
>would not only open the door but get you all the way inside and down the
>hall a ways...
>
>> >CS covers many great things, but solving design problems is not one of
>> >them (at least in my experience).
>> 
>> There is not enough time in an undergraduate cirriculum to teach SW
>> engineering judgment.
>
>Horse Hockey!
>
>How would software engineering be any different than any other
>discipline?  Do they not teach engineering judgement to the other
>engineering disciplines?  

Engineering judgement involves combining off-the-shelf and custom-built
components to solve a particular problem in a cost-effective manner. The
number of available software components is enormous, and changing rapidly,
perhaps more rapidly than any other field of endeavor.  Understanding the
usefulness of the various tools applicable to any particular development shop
takes at least a year of full-time work.  Without that experience, it's very
hard to maek correct build/buy decisions.  It's also hard to predict the
likely requirements changes to determine where to spend extra resources for
maximum flexibility.

>> But there are plenty of excellent books on the subject. I suggest you try to
>> read one technical book a month.  Soon you will be well ahead of your
>> classmates.
>
>Sure.  If you are one of the 5% of students who are able to comprehend
>technical manuals, that's good advice.  What about for the rest of them?
>

I feel that the ability to learn from written material is essential to staying
on top of this profession.  Even if it is harder for you than some others, you
must do it anyway.  Otherwise your skills will become more and more
specialized, and you have little value to any company except your current
employer.  There are thousands of 50-year-old engineers  RIF'd out of
high-paying positions who ended up taking jobs for half their former salary.
Don't let it happen to you.  Know where your paycheck comes from.
Make sure you are contributing value equal to your cost. 

Re: Any research putting c above ada?

[Roy Grimm]

Kevin Cline wrote:
> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
> 
> You didn't read my post carefully enough, and evidently "grade-grubber" isn't
> well understood either.  I just said that a low GPA makes it harder to get an
> interview.  I then indicated that it played little or no part in my
> evaluation of a candidate.  A grade grubber is a student interested in
> expending the minimum possible effort to obtain a desired grade, with no
> interest in mastering the subject.

Fair enough.  I'd agree in principle with what you are getting at in
reference to "grade-grubbers".  There are slackers out there just
interested in doing enough to get by.  However, too many people
automatically associate that attitude with bad grades.  I've never
gotten really good grades in any of the classwork I've done and yet I've
probably gotten more out of the classes than the average person. 
Fortunately, I've been in the business long enough to prove I'm no
slacker.

> >At a homecoming a few years later, I found out that a few people in my
> >class who had graduated with a 4.0 in comp sci were having trouble in
> >their jobs maintaining COBOL code for accounting/insurance type
> >companies becasue they didn't know how to apply their theory to real
> >world situations.
> 
> The probably didn't understand the theory either, but were able to memorize
> enough bullet points to pass the exams.  This reflects poorly on your
> instution.

Actually, they were brilliant with theory.  The one individual I'm
thinking of was able to take the CompSci GRE and score in the upper 75%,
but couldn't figure out how to format a report of an amortization table
without help.  The point I'm trying to make is that all theory and no
practice is detrimental to the average student and tends to skew the
grading curve all over the place.  Someone who has trouble with
something as simple as formatting output should not graduate with a 4.0
GPA.

> >But you can teach the fundamentals in a few weeks, rather than in the
> >two semesters they currently waste.
> 
> I disagree strongly.  Obviously we disagree on how much knowledge is
> relevant.

Either that or we have had remarkably different experiences learning our
theory and mine was very much sub-par.  Everyone in my classes
complained about the slow pace.  We spent several days studying why
Quicksort works as fast as it does.  This after spending a few weeks on
binary trees and how to search, sort and balance them.

It seems to me that we could spend about a day on the theory of binary
trees, spend the next day on the sorting and balancing algorithms and
move on to one day looking at the various sorting algorithms.  College
students are not stupid.  They do not need to rehash the basics like
they were learining arithmetic in grade school.

If I were designing a CompSci program at a college, I would make the
intro classes available to those who need the "remedial" help.  Most
students who enter college with the intention of studying computer
science have already had some exposure to it, much like most math
students have already had pre-calc.  There is no reason freshmen
couldn't start studying algorithm design first semester.  (unless, of
course, they hadn't had the exposure, but that's what the "remedial"
courses are for.)  Once the basics of algorithm and data structure were
taught in the fall, the spring would be dedicated to teaching basic
programming methods.  These would include using debuggers, performing
peer reviews, constructing functional tests of the software, etc.  After
that, students would be ready to tackle higher level stuff.  (And pardon
my arrogant opinion, but if they can't handle basic algorithm design and
programming methods, they have no business trying to be programmers.)

> >If students spent more time learning how to solve real problems, they would
> >be able to pick up the theory much faster.
> 
> I don't believe this at all.  I have known many experienced developers who
> wrote ridiculously inefficient software because of a complete lack of
> knowledge of operating system services, the language they were using, and
> fundamental data structures.

How have they lasted in their positions to get any experience if they
don't know fundamental data structures?  And did you at least try to
teach them what they needed to know?

> >They would see a problem and ask the intelligent
> >questions about how to solve it.  At that point, you can show them the
> >theory and how it applies in that case.
> 
> "Experience is a dear teacher, but fools will learn at no other."
> 
> I think this would be painfully slow.

My own personal experience demonstrates the opposite of your opinion.

> >How would software engineering be any different than any other
> >discipline?  Do they not teach engineering judgement to the other
> >engineering disciplines?
> 
> Engineering judgement involves combining off-the-shelf and custom-built
> components to solve a particular problem in a cost-effective manner. The
> number of available software components is enormous, and changing rapidly,
> perhaps more rapidly than any other field of endeavor.  Understanding the
> usefulness of the various tools applicable to any particular development shop
> takes at least a year of full-time work.  Without that experience, it's very
> hard to maek correct build/buy decisions.  It's also hard to predict the
> likely requirements changes to determine where to spend extra resources for
> maximum flexibility.

Engineering judgement is the ability to solve problems.  Teach someone
how to solve problems in general, then show them the specifics of the
field and they can apply their fundamental problem solving ability to
that field.  Electrical engineers can combine thousands if not millions
of different components into electrical systems governed by very complex
differential equations.  Why then is it that professors can teach them
how to do it effectively yet you claim the computer science students
couldn't learn how to combine software packages together?  Is there some
genetic defect with computer science students?

> >Sure.  If you are one of the 5% of students who are able to comprehend
> >technical manuals, that's good advice.  What about for the rest of them?
> 
> I feel that the ability to learn from written material is essential to
> staying on top of this profession.  Even if it is harder for you than some
> others, you must do it anyway.  Otherwise your skills will become more and
> more specialized, and you have little value to any company except your
> current employer.  There are thousands of 50-year-old engineers  RIF'd out
> of high-paying positions who ended up taking jobs for half their former
> salary. Don't let it happen to you.  Know where your paycheck comes from.
> Make sure you are contributing value equal to your cost.

I agree that people must keep learning or become obsolete.  No question
about it.  I agree that technical manuals are a good source of
information for professionals wanting to expand their skills. 
Personally, I devour manuals left and right.  I'm always learning
something new and most of my information comes from the technical
manuals.  However, I disagree that technical manuals serve a usefull
purpose for _most_ college students.  They simply do not have the
experience to make use of manuals.

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3370B657.41C6@cca.rockwell.com>,
Roy Grimm  <ragrimm@cca.rockwell.com> wrote:
>Engineering judgement is the ability to solve problems.  Teach someone
>how to solve problems in general, then show them the specifics of the
>field and they can apply their fundamental problem solving ability to
>that field.  Electrical engineers can combine thousands if not millions
>of different components into electrical systems governed by very complex
>differential equations.  Why then is it that professors can teach them
>how to do it effectively yet you claim the computer science students
>couldn't learn how to combine software packages together?  Is there some
>genetic defect with computer science students?

This is another sweeping generalization. Some engineering departments
crank out graduates who are unable to wire up two transistors together, never
mind thousands of components governed by complex DE's.

Some schools have EE programs that focus on theory and examsmanship, like those
CS programs you guys are bitching and generalizing about.

I've met EE's who couldn't assemble a ham radio project from RadioShack if
their lives depended on it. They had programming jobs, of course, in which they
churned out 500 line functions with global side-effects.

That is not to say that there aren't engineering schools that actually turn
out engineers.

One thing I learned in those discrete mathematics and logic courses was that
one crow being white doesn't imply that all crows are white. Ah, but that's
just theoretical masturbation. In real life, generalizing works all the time.

Re: Any research putting c above ada?

[Kevin Cline]

Roy Grimm <ragrimm@cca.rockwell.com> wrote:

>Kevin Cline wrote:
>> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
>> 
>> You didn't read my post carefully enough, and evidently "grade-grubber" isn't
>> well understood either.  I just said that a low GPA makes it harder to get an
>> interview.  I then indicated that it played little or no part in my
>> evaluation of a candidate.  A grade grubber is a student interested in
>> expending the minimum possible effort to obtain a desired grade, with no
>> interest in mastering the subject.
>
>Fair enough.  I'd agree in principle with what you are getting at in
>reference to "grade-grubbers".  There are slackers out there just
>interested in doing enough to get by.  However, too many people
>automatically associate that attitude with bad grades. 

Let me make myself perfectly clear.  I believe there is little correlation
between GPA and the ability to do software development.  However, even the
most open-minded organization is going to deselect candidates with GPA's below
some minimum standard.

> I've never
>gotten really good grades in any of the classwork I've done and yet I've
>probably gotten more out of the classes than the average person. 

That's exactly what I meant to say.  I don't want to hire people whose sole
goal in attending is to get an A on their transcript.

>Fortunately, I've been in the business long enough to prove I'm no
>slacker.

It's definitely easier to judge those with professional experience.

>Actually, they were brilliant with theory.  The one individual I'm
>thinking of was able to take the CompSci GRE and score in the upper 75%,
>but couldn't figure out how to format a report of an amortization table
>without help.  

I assume you mean the upper quartile.  The GRE is a multiple choice exam,
isn't it?  

>The point I'm trying to make is that all theory and no
>practice is detrimental to the average student and tends to skew the
>grading curve all over the place.  Someone who has trouble with
>something as simple as formatting output should not graduate with a 4.0
>GPA.

I agree completely.  That is why I make all candidates actually write code at
a whiteboard.

>> >But you can teach the fundamentals in a few weeks, rather than in the
>> >two semesters they currently waste.
>> 
>> I disagree strongly.  Obviously we disagree on how much knowledge is
>> relevant.
>
>Either that or we have had remarkably different experiences learning our
>theory and mine was very much sub-par.  Everyone in my classes
>complained about the slow pace.  We spent several days studying why
>Quicksort works as fast as it does.  This after spending a few weeks on
>binary trees and how to search, sort and balance them.

I'm sorry.  You were poorly instructed.  I was fortunate enough to attend a
private university, and the pace was quite challenging.

>It seems to me that we could spend about a day on the theory of binary
>trees, spend the next day on the sorting and balancing algorithms and
>move on to one day looking at the various sorting algorithms.  College
>students are not stupid.  They do not need to rehash the basics like
>they were learining arithmetic in grade school.
>
>If I were designing a CompSci program at a college, I would make the
>intro classes available to those who need the "remedial" help.  Most
>students who enter college with the intention of studying computer
>science have already had some exposure to it, much like most math
>students have already had pre-calc.  There is no reason freshmen
>couldn't start studying algorithm design first semester.  (unless, of
>course, they hadn't had the exposure, but that's what the "remedial"
>courses are for.)  Once the basics of algorithm and data structure were
>taught in the fall, the spring would be dedicated to teaching basic
>programming methods.  These would include using debuggers, performing
>peer reviews, constructing functional tests of the software, etc.  After
>that, students would be ready to tackle higher level stuff.  (And pardon
>my arrogant opinion, but if they can't handle basic algorithm design and
>programming methods, they have no business trying to be programmers.)
>
>> >If students spent more time learning how to solve real problems, they would
>> >be able to pick up the theory much faster.
>> 
>> I don't believe this at all.  I have known many experienced developers who
>> wrote ridiculously inefficient software because of a complete lack of
>> knowledge of operating system services, the language they were using, and
>> fundamental data structures.
>
>How have they lasted in their positions to get any experience if they
>don't know fundamental data structures?  And did you at least try to
>teach them what they needed to know?

It's hard to instruct those more senior and more highly paid.  It's was much
more rewarding to move to an organization with higher standards.

>
>> >They would see a problem and ask the intelligent
>> >questions about how to solve it.  At that point, you can show them the
>> >theory and how it applies in that case.
>> 
>> "Experience is a dear teacher, but fools will learn at no other."
>> 
>> I think this would be painfully slow.
>
>My own personal experience demonstrates the opposite of your opinion.
>
>> >How would software engineering be any different than any other
>> >discipline?  Do they not teach engineering judgement to the other
>> >engineering disciplines?
>> 
>> Engineering judgement involves combining off-the-shelf and custom-built
>> components to solve a particular problem in a cost-effective manner. The
>> number of available software components is enormous, and changing rapidly,
>> perhaps more rapidly than any other field of endeavor.  Understanding the
>> usefulness of the various tools applicable to any particular development shop
>> takes at least a year of full-time work.  Without that experience, it's very
>> hard to maek correct build/buy decisions.  It's also hard to predict the
>> likely requirements changes to determine where to spend extra resources for
>> maximum flexibility.
>
>Engineering judgement is the ability to solve problems.  Teach someone
>how to solve problems in general, then show them the specifics of the
>field and they can apply their fundamental problem solving ability to
>that field.  Electrical engineers can combine thousands if not millions
>of different components into electrical systems governed by very complex
>differential equations.  Why then is it that professors can teach them
>how to do it effectively yet you claim the computer science students
>couldn't learn how to combine software packages together?  Is there some
>genetic defect with computer science students?

Combining components does not require judgment.  Evaluating them does.
Deciding which requirements are likely to change and which are not requires
judgment.  Deciding whether to release your product to the marker or continue
testing requires judgment.

>
>> >Sure.  If you are one of the 5% of students who are able to comprehend
>> >technical manuals, that's good advice.  What about for the rest of them?
>> 


I'm not talking about manuals.  I'm talking about books and periodicals.
Most students can't afford to buy them, but they should be available in the
library.

Re: Any research putting c above ada?

[Roy Grimm]

Kevin Cline wrote:
> 
> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
> >Fair enough.  I'd agree in principle with what you are getting at in
> >reference to "grade-grubbers".  There are slackers out there just
> >interested in doing enough to get by.  However, too many people
> >automatically associate that attitude with bad grades.
> 
> Let me make myself perfectly clear.  I believe there is little correlation
> between GPA and the ability to do software development.  However, even the
> most open-minded organization is going to deselect candidates with GPA's
> below some minimum standard.

I would agree 100% with that.  My resume was summarily rejected at
several companies because of an arbitrary GPA minimum that I didn't
meet.

> > I've never
> >gotten really good grades in any of the classwork I've done and yet I've
> >probably gotten more out of the classes than the average person.
> 
> That's exactly what I meant to say.  I don't want to hire people whose sole
> goal in attending is to get an A on their transcript.

I know far too many people like that.  I wouldn't want to work with
them.

> >Fortunately, I've been in the business long enough to prove I'm no
> >slacker.
> 
> It's definitely easier to judge those with professional experience.

So how do students prove they have real technical ability?  Probably the
way I did.  Get a job in the college computer center and do well in ACM
programming contests.  Having those two things on my resume opened quite
a few doors.

> >Actually, they were brilliant with theory.  The one individual I'm
> >thinking of was able to take the CompSci GRE and score in the upper 75%,
> >but couldn't figure out how to format a report of an amortization table
> >without help.
> 
> I assume you mean the upper quartile.  The GRE is a multiple choice exam,
> isn't it?

That's what I meant, yes.

> I agree completely.  That is why I make all candidates actually write code at
> a whiteboard.

I'd love to see how some of the candidates crack under that kind of
pressure.  "You mean I actually have to write real code?!?"

> I'm sorry.  You were poorly instructed.  I was fortunate enough to attend a
> private university, and the pace was quite challenging.

I went to a private college where the pace was barely noticable...  As a
result, I took advantage of the free time to teach myself most of what I
know.

> >How have they lasted in their positions to get any experience if they
> >don't know fundamental data structures?  And did you at least try to
> >teach them what they needed to know?
> 
> It's hard to instruct those more senior and more highly paid.  It's was much
> more rewarding to move to an organization with higher standards.

Personally, I would have loved the challenge.  Teaching people without
them realizing it is not easy, but it can be done.

> >Engineering judgement is the ability to solve problems.  Teach someone
> >how to solve problems in general, then show them the specifics of the
> >field and they can apply their fundamental problem solving ability to
> >that field.  Electrical engineers can combine thousands if not millions
> >of different components into electrical systems governed by very complex
> >differential equations.  Why then is it that professors can teach them
> >how to do it effectively yet you claim the computer science students
> >couldn't learn how to combine software packages together?  Is there some
> >genetic defect with computer science students?
> 
> Combining components does not require judgment.  Evaluating them does.
> Deciding which requirements are likely to change and which are not requires
> judgment.  Deciding whether to release your product to the marker or continue
> testing requires judgment.

I'm not talking about throwing together a few components to make a
trivial system, I'm talking about the judgement it takes to design
complex systems and understand when you've gotten it right.  We recently
hired an EE grad into our software department.  He came fresh from
school right into our department.  He has a better understanding of the
design process than almost any other person in the department.
(including me!)  

Sure, he was a little shaky on the details of designing algorithms and
data structures at first.  But hey, it takes a few weeks to teach that
to someone.  I ran him through the fundamentals and gave him my
algorithms book.  Three weeks later, he gives it back, fully
understanding the practical principles of algorithm design.  We touched
on theory and spent a day or two with algorithm analysis, and he picked
it all up right away.

You see, he learned how to solve problems.  Algorithm design is just
another problem to solve.  He was a better software developer after two
months than I was after a year.

> >> >Sure.  If you are one of the 5% of students who are able to comprehend
> >> >technical manuals, that's good advice.  What about for the rest of them?
> 
> I'm not talking about manuals.  I'm talking about books and periodicals.
> Most students can't afford to buy them, but they should be available in the
> library.

The type of books is irellevant.  The fact is, most students do not have
the practical knowledge and experience to make use of the information in
most technical books (be it manuals or text books) and periodicals.

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3371EDD8.167E@cca.rockwell.com>,
Roy Grimm  <ragrimm@cca.rockwell.com> wrote:
>Kevin Cline wrote:
>> 
>> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
>> >Fair enough.  I'd agree in principle with what you are getting at in
>> >reference to "grade-grubbers".  There are slackers out there just
>> >interested in doing enough to get by.  However, too many people
>> >automatically associate that attitude with bad grades.
>> 
>> Let me make myself perfectly clear.  I believe there is little correlation
>> between GPA and the ability to do software development.  However, even the
>> most open-minded organization is going to deselect candidates with GPA's
>> below some minimum standard.
>
>I would agree 100% with that.  My resume was summarily rejected at
>several companies because of an arbitrary GPA minimum that I didn't
>meet.

That shows you didn't do your best in meeting the requirements of the school
you attended. Not knowing anything about you beyond a mere number, it's not
surprising that the employer might suspect that you could approach the
workplace with the same attitude.  What the employer does not know is that the
school you went to rewarded mere scholastic aptitude, as is evident from
your descriptions.

Companies that request university transcripts are extremely annoying to say the
least. :)

>> > I've never
>> >gotten really good grades in any of the classwork I've done and yet I've
>> >probably gotten more out of the classes than the average person.
>> 
>> That's exactly what I meant to say.  I don't want to hire people whose sole
>> goal in attending is to get an A on their transcript.
>
>I know far too many people like that.  I wouldn't want to work with
>them.

I know two brillant fellows who consistently got straight A's in school.
I was enrolled in a Complex Variables course with one of them; he got 98%
in it, I got 58.  I'd work with him any day. He is a very competent software
designer and implementor. Naturally, he went on to grad school. 

Another such ``genius'' I know started a successful software company, and is
now working on his Ph. D. in computer science.  He wrote a working Pascal
compiler while still in 11th grade of highschool.

Both very nice fellows, lacking any semblance of conceit. In all social
interaction, I have been treated by them as equal despite my dim wit. In fact,
I correspond regularly with one of them.

I've never envied nor resented people who got the grades. Good for them!

Re: Any research putting c above ada?

[Kevin Cline]

Roy Grimm <ragrimm@cca.rockwell.com> wrote:

>Kevin Cline wrote:
>> 
>> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
>> >Fair enough.  I'd agree in principle with what you are getting at in
>> >reference to "grade-grubbers".  There are slackers out there just
>> >interested in doing enough to get by.  However, too many people
>> >automatically associate that attitude with bad grades.
>> 
>> Let me make myself perfectly clear.  I believe there is little correlation
>> between GPA and the ability to do software development.  However, even the
>> most open-minded organization is going to deselect candidates with GPA's
>> below some minimum standard.
>
>I would agree 100% with that.  My resume was summarily rejected at
>several companies because of an arbitrary GPA minimum that I didn't
>meet.
>
>> > I've never
>> >gotten really good grades in any of the classwork I've done and yet I've
>> >probably gotten more out of the classes than the average person.
>> 
>> That's exactly what I meant to say.  I don't want to hire people whose sole
>> goal in attending is to get an A on their transcript.
>
>I know far too many people like that.  I wouldn't want to work with
>them.
>
>> >Fortunately, I've been in the business long enough to prove I'm no
>> >slacker.
>> 
>> It's definitely easier to judge those with professional experience.
>
>So how do students prove they have real technical ability?  Probably the
>way I did.  Get a job in the college computer center and do well in ACM
>programming contests.  Having those two things on my resume opened quite
>a few doors.

There is no doubt that a graduating student with successful work experience in
the field is much more attractive.

>> I agree completely.  That is why I make all candidates actually write code at
>> a whiteboard.
>
>I'd love to see how some of the candidates crack under that kind of
>pressure.  "You mean I actually have to write real code?!?"

I ask them to code a 15-line function that requires two nested loops.
Most people claim to know C, but almost any language is acceptable.
If they can come reasonably close to a solution,  I ask them to tell me the
run-time complexity of their function.

Once, a few years ago, the candidate reported to his head-hunter that I was
unfairly trying to get him to do free work during the interview!

>
>> I'm sorry.  You were poorly instructed.  I was fortunate enough to attend a
>> private university, and the pace was quite challenging.
>
>I went to a private college where the pace was barely noticable...  As a
>result, I took advantage of the free time to teach myself most of what I
>know.
>
>> >How have they lasted in their positions to get any experience if they
>> >don't know fundamental data structures?  And did you at least try to
>> >teach them what they needed to know?
>> 
>> It's hard to instruct those more senior and more highly paid.  It's was much
>> more rewarding to move to an organization with higher standards.
>
>Personally, I would have loved the challenge.  Teaching people without
>them realizing it is not easy, but it can be done.

Yes, but in the meantime, I get tired of cleaning up after them.

>I'm not talking about throwing together a few components to make a
>trivial system, I'm talking about the judgement it takes to design
>complex systems and understand when you've gotten it right.  

We're disagreeing on terms.  To me, designing complex systems that work
requires a combination of creativity, technique, and judgment.  Problem
solving skills are a combination of creativity and technique.  Judgment
basically comes into play when selecting alternative solutions to the same
problem.

Re: Any research putting c above ada?

[Dan Shea]

Kevin Cline (clines@delete_this.airmail.net) wrote:
: Roy Grimm <ragrimm@cca.rockwell.com> wrote:

: >Kevin Cline wrote:
: >> 
: >> Roy Grimm <ragrimm@cca.rockwell.com> wrote:
: >> >Fair enough.  I'd agree in principle with what you are getting at in
: >> >reference to "grade-grubbers".  There are slackers out there just
: >> >interested in doing enough to get by.  However, too many people
: >> >automatically associate that attitude with bad grades.
: >> 
: >> Let me make myself perfectly clear.  I believe there is little correlation
: >> between GPA and the ability to do software development.  However, even the
: >> most open-minded organization is going to deselect candidates with GPA's
: >> below some minimum standard.
: >
: >I would agree 100% with that.  My resume was summarily rejected at
: >several companies because of an arbitrary GPA minimum that I didn't
: >meet.
: >
: >> > I've never
: >> >gotten really good grades in any of the classwork I've done and yet I've
: >> >probably gotten more out of the classes than the average person.
: >> 
: >> That's exactly what I meant to say. I don't want to hire people whose sole
: >> goal in attending is to get an A on their transcript.
: >

Amen.  I sit in class with a bunch of people who are in CS primarily
because it "looks good".  They are also getting business degrees.  What
scares me is these are the same people I may have to deal with when
they are managers!  What pisses me off the most (pardon the language)
is that people assume they are getting the same degree as me.  The
term CS major is far too lose.  I am receiving an Engineering degree,
while they are getting an applied science or BA.  There is a world of
difference between the two.

: >I know far too many people like that.  I wouldn't want to work with
: >them.
: >
: >> >Fortunately, I've been in the business long enough to prove I'm no
: >> >slacker.
: >> 
: >> It's definitely easier to judge those with professional experience.
: >
: >So how do students prove they have real technical ability?  Probably the
: >way I did.  Get a job in the college computer center and do well in ACM
: >programming contests.  Having those two things on my resume opened quite
: >a few doors.

Get an internship.  Shows you have real world experience and can
perform in the "real world" (tm).

: There is no doubt that a graduating student with successful work experience in
: the field is much more attractive.


Indeed.

: >> I agree completely.  That is why I make all candidates actually write code at
: >> a whiteboard.
: >
: >I'd love to see how some of the candidates crack under that kind of
: >pressure.  "You mean I actually have to write real code?!?"

=)  If they crack, they aren't worth hiring.  I *expect* to be asked
to perform either an analytical problem or write some code to show I
have two brain cells to rub together.

: I ask them to code a 15-line function that requires two nested loops.
: Most people claim to know C, but almost any language is acceptable.
: If they can come reasonably close to a solution,  I ask them to tell me the
: run-time complexity of their function.

Maybe I am not reading this right.  You basically tell them to write
bubblesort? O(n^2)
Or do you give them a problem and say, write a double nested for loop
solution?  Either way, I don't see why.  Something a little trickier
perhaps, but even a first year undergrad should know the above.

Most OPIM majors here (laughable parody of what programming should be
for business majors) can't implement a simple linked list data
structure.  I remeber a friend who had this as his final project.  Not
only did I have to give him some reading material, but he spent alot
of time writing some very "interesting" code.

: Once, a few years ago, the candidate reported to his head-hunter that I was
: unfairly trying to get him to do free work during the interview!

heheheh...did he have an Econ degree as well.  =)

: >
: >> I'm sorry.  You were poorly instructed.  I was fortunate enough to attend a
: >> private university, and the pace was quite challenging.
: >
: >I went to a private college where the pace was barely noticable...  As a
: >result, I took advantage of the free time to teach myself most of what I
: >know.
: >
: >> >How have they lasted in their positions to get any experience if they
: >> >don't know fundamental data structures?  And did you at least try to
: >> >teach them what they needed to know?
: >> 
: >> It's hard to instruct those more senior and more highly paid.  It's was much
: >> more rewarding to move to an organization with higher standards.
: >
: >Personally, I would have loved the challenge.  Teaching people without
: >them realizing it is not easy, but it can be done.

: Yes, but in the meantime, I get tired of cleaning up after them.

: >I'm not talking about throwing together a few components to make a
: >trivial system, I'm talking about the judgement it takes to design
: >complex systems and understand when you've gotten it right.  

: We're disagreeing on terms.  To me, designing complex systems that work
: requires a combination of creativity, technique, and judgment.  Problem
: solving skills are a combination of creativity and technique.  Judgment
: basically comes into play when selecting alternative solutions to the same
: problem.

I am tired of seeing these Econ spouting BAS in CS people claiming
they know how to solve real world problems.  Half of them can't even
program, and the other half are to busy bitching about their grades to
even comprehend what a real world problem is.

I have to agree that if you want an Engineer who is going to be useful
in the real world, then education is laughable.  I know, I am getting
reamed for 40k a year so I can have my "Ivy League" tm degree.

Fortunately I like theory as well as solving "real" problems and I
look forward to continuing my education.  And when I do get my "real"
job I plan on readily admitting not to know everything, but I do plan
on being willing to learn.  Yes that rare quality of humility is very
important to have when Engineering is at stake.  In the "real" world I
know fully well the crap code I can use in academia is not going to
cut it. But that...is another story...
It is great to see some people who share some like ideas.  My GPA is
not stellar, but then again, I never have seen GPA as being indicative
to being a good engineer.
--
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.
The question of the existence of views in the absence of anyone to hold
them is left as an exercise for the reader.  The question of the
existence of the reader is left as an exercise for the second god
coefficient.  (A discussion of non-orthogonal, non-integral polytheism
is beyond the scope of this article.)

Re: Any research putting c above ada?

[Kevin Cline]

shea@blue.seas.upenn.edu (Dan Shea) wrote:

>Kevin Cline (clines@delete_this.airmail.net) wrote:
>: Roy Grimm <ragrimm@cca.rockwell.com> wrote:
>

>: I ask them to code a 15-line function that requires two nested loops.
>: Most people claim to know C, but almost any language is acceptable.
>: If they can come reasonably close to a solution,  I ask them to tell me the
>: run-time complexity of their function.
>
>Maybe I am not reading this right.  You basically tell them to write
>bubblesort? O(n^2)
>Or do you give them a problem and say, write a double nested for loop
>solution?  Either way, I don't see why.  Something a little trickier
>perhaps, but even a first year undergrad should know the above.

Sorry for the confusion.  I give a very specific problem to be solved, but the
exact problem is not important to this discussion.  I don't ask them to write
bubblesort because everyone has seen that one.  Besides, the best answer to
that problem in almost any language is to call the library sort routine.

Re: Any research putting c above ada?

[Alan Brain]

Kevin Cline wrote:

> That is truly unfortunate.  However, with industry salaries for top-notch
> experienced professionals in six figures now, it is hard to get good
> instruction for $100/credit hour.  If you do, be grateful; it's charity.

I might point out that Comp Sci Lab demonstrators at the Australian
Defence Force Academy get paid less than $15 US per hour. This is for
someone who's personally written at least 100 Klines of Ada.
A top-rate engineer in Australia would not get $50 K US.
 
I might also add that some of us teach for fun, and because it's a nice
break from our day job.
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Adam Beneschan]

John Apa <japa@DIE_SPAMMER.dasd.honeywell.com> writes:
 
 >Yes it is the student's responsibility to get the knowledge they need.
 >However the current trend in education is to over generalize so that the
 >student is a wonderful citizen by forcing them to take highly irrelevant
 >classes. The cal state system requires over 60% of classes not be
 >related to scientific majors. Yes, I probably picked the wrong school,
 >but this seems to be a general trend in "higher" education. Many schools
 >have gone away from preparing students for the "real" world. They need
 >to get back to their original purpose.

Seems this sort of discussion has come up before.  I agree with what
some have said that software engineering doesn't get enough attention
at some schools.  But I'm not at all convinced that the purpose of
colleges and universities is to prepare students for a job.  When I
went to college (in the University of California system), there were
very little requirements for taking courses outside one's major, and
no specific subject requirements.  There was a general "breadth"
requirement to take a number of courses of your choice outside your
school, most of which was fulfilled by the math courses required for
my CS degree.  Two years after I started, UC took the other path and
started imposing a lot of specific requirements in things like
history, foreign language, science, literature, I don't recall what
else.  At the time, I was glad the new requirements only applied to
new students.  Now, at age 36, I kind of wish I had been required to
take all those other courses.  I might not have appreciated it at the
time, but I'm now convinced the broad knowledge I would have gained on
a variety of subjects would have added to the enrichment of my life
since then.

Anyway, if my information is correct, the "original purpose" of
college was *not* simply to prepare students for jobs.  That was the
original purpose of trade schools and apprenticeships.  But think back
to when Harvard, Yale, William and Mary, etc., were founded back in
the 17th century or whenever.  Was their purpose to prepare 17th
century youngsters for whatever jobs there were back then?  Hardly.
The purpose of colleges and universities has always been to provide a
"well-rounded" education.  I think a lot of students go into college
with the idea that they're there *only* to get a passport to a job, or
to get job skills; but I believe this is a misconception.  Maybe we
need to have more trade schools and the like whose purpose is just to
provide job skills, as an alternative to colleges and universities.
But I also believe that lack of appreciation for the sort of
well-rounded education colleges have traditionally provided is a
disturbing sign of the decay of our society.

Oh, well . . . none of this has anything to do with
comp.lang.anything, so I'll get off my soapbox now.

                                -- Adam

Re: Any research putting c above ada?

[Richard A. O'Keefe]

eachus@spectre.mitre.org (Robert I. Eachus) writes:
>   But in reality it is the responsibility of the students to get the
>knowledge that they need.

I've just had a student in my office who was extremely annoyed.
He had submitted his assignment electronically in two parts,
and his second submission had caused his first to be deleted,
hence his low mark.  He was *outraged* at the suggestion that
he ought to have read the on-line manual for the electronic
submission program.  I pointed out that he _ought_ to read the
manuals for _all_ the programs he used, and he was vehemently
opposed to that view.  In his view, he was paying us money,
and he shouldn't have to read _anything_ that wasn't in the
printed handouts.  It was a very upsetting meeting.

Some students are rock solid *certain* that it *isn't* their
responsiblity.

-- 
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Any research putting c above ada?

[Larry Weiss]

Richard A. O'Keefe wrote:
> eachus@spectre.mitre.org (Robert I. Eachus) writes:
> >   But in reality it is the responsibility of the students to get the
> >knowledge that they need.
> 
> I've just had a student in my office who was extremely annoyed.
> He had submitted his assignment electronically in two parts,
> and his second submission had caused his first to be deleted,
> hence his low mark.  He was *outraged* at the suggestion that
> he ought to have read the on-line manual for the electronic
> submission program.  I pointed out that he _ought_ to read the
> manuals for _all_ the programs he used, and he was vehemently
> opposed to that view.  In his view, he was paying us money,
> and he shouldn't have to read _anything_ that wasn't in the
> printed handouts.  It was a very upsetting meeting.
> 
> Some students are rock solid *certain* that it *isn't* their
> responsiblity.
> 

Give the student a break!   Your mechanistic treatment of this
scenario is very upsetting.   You have a student that you know
acted in good faith to compose what he/she needed to provide to
qualify for a total submission, yet you seem to take satisfaction
(that's my take on it, I may, of course be wrong) in frustrating
this person.    I'd say that if they could quickly resubmit the
missing portion, then what's the harm in accepting it?   

I hope the situation hasn't gotten out of control where you two
can't come to a good outcome on this.   Good luck!

Re: Any research putting c above ada?

[Kevin Cline]

Larry Weiss <lfw@oc.com> wrote:

>Richard A. O'Keefe wrote:
>> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>> >   But in reality it is the responsibility of the students to get the
>> >knowledge that they need.
>> 
>> I've just had a student in my office who was extremely annoyed.
>> He had submitted his assignment electronically in two parts,
>> and his second submission had caused his first to be deleted,
>> hence his low mark.  He was *outraged* at the suggestion that
>> he ought to have read the on-line manual for the electronic
>> submission program.  I pointed out that he _ought_ to read the
>> manuals for _all_ the programs he used, and he was vehemently
>> opposed to that view.  In his view, he was paying us money,
>> and he shouldn't have to read _anything_ that wasn't in the
>> printed handouts.  It was a very upsetting meeting.
>> 
>> Some students are rock solid *certain* that it *isn't* their
>> responsiblity.
>> 
>
>Give the student a break!   Your mechanistic treatment of this
>scenario is very upsetting.   You have a student that you know
>acted in good faith to compose what he/she needed to provide to
>qualify for a total submission, yet you seem to take satisfaction
>(that's my take on it, I may, of course be wrong) in frustrating
>this person.    I'd say that if they could quickly resubmit the
>missing portion, then what's the harm in accepting it?   
>
>I hope the situation hasn't gotten out of control where you two
>can't come to a good outcome on this.   Good luck!

If I were the student, I would be upset too.  Anyone, particularly a CS
professsor, who provides software to automate assignment submission should
have the sense to provide a warning before deleting old information.
I wonder if the student was even informed that he should read the manual.
In all seriousness, I feel sorry for Mr. Eachus students.  I don't think Mr.
Eachus would be very happy if he were told that a file he accidental deleted
while working at Mitre was unrecoverable because no backups were made.

Re: Any research putting c above ada?

[Jay Martin]

clines@delete_this.airmail.net (Kevin Cline) writes:

>If I were the student, I would be upset too.  Anyone, particularly a CS
>professsor, who provides software to automate assignment submission should
>have the sense to provide a warning before deleting old information.
>I wonder if the student was even informed that he should read the manual.
>In all seriousness, I feel sorry for Mr. Eachus students.  I don't think Mr.
>Eachus would be very happy if he were told that a file he accidental deleted
>while working at Mitre was unrecoverable because no backups were made.

Right.  User unfriendly and dangerous software is sewage. Pretty much
a fundemental rule of good software design.  In the real world, tons
of people don't read manuals and make mistakes. Unfortunately, due to
the massive incompetence in this field, macho and arcane "hacker
priest" software like Unix and C have been glorified while user
friendly and safer software and languages have been denegrated.

Jay

Re: Any research putting c above ada?

[Kevin Cline]

jmartin@cs.ucla.edu (Jay Martin) wrote:

>clines@delete_this.airmail.net (Kevin Cline) writes:
>
>>If I were the student, I would be upset too.  Anyone, particularly a CS
>>professsor, who provides software to automate assignment submission should
>>have the sense to provide a warning before deleting old information.
>>I wonder if the student was even informed that he should read the manual.
>>In all seriousness, I feel sorry for Mr. Eachus students.  I don't think Mr.
>>Eachus would be very happy if he were told that a file he accidental deleted
>>while working at Mitre was unrecoverable because no backups were made.
>
>Right.  User unfriendly and dangerous software is sewage. Pretty much
>a fundemental rule of good software design.  In the real world, tons
>of people don't read manuals and make mistakes. Unfortunately, due to
>the massive incompetence in this field, macho and arcane "hacker
>priest" software like Unix and C have been glorified while user
>friendly and safer software and languages have been denegrated.

No other system I have ever worked on comes close to UNIX in providing a
productive environment for software development, and I have worked on quite a
few.  Other systems are easier for casual users, but none provide the
flexibility of UNIX.

Re: Any research putting c above ada?

[Craig Franck]

clines@delete_this.airmail.net (Kevin Cline) wrote:
>Larry Weiss <lfw@oc.com> wrote:
>
>>Richard A. O'Keefe wrote:
>>> eachus@spectre.mitre.org (Robert I. Eachus) writes:
>>> >   But in reality it is the responsibility of the students to get the
>>> >knowledge that they need.
>>> 
>>> I've just had a student in my office who was extremely annoyed.
>>> He had submitted his assignment electronically in two parts,
>>> and his second submission had caused his first to be deleted,
>>> hence his low mark.  He was *outraged* at the suggestion that
>>> he ought to have read the on-line manual for the electronic
>>> submission program.  I pointed out that he _ought_ to read the
>>> manuals for _all_ the programs he used, and he was vehemently
>>> opposed to that view.  In his view, he was paying us money,
>>> and he shouldn't have to read _anything_ that wasn't in the
>>> printed handouts.  It was a very upsetting meeting.
>>> 
>>> Some students are rock solid *certain* that it *isn't* their
>>> responsiblity.

Hopefully, you have dispossessed him of this notion.

>>Give the student a break!   Your mechanistic treatment of this
>>scenario is very upsetting.   You have a student that you know
>>acted in good faith to compose what he/she needed to provide to
>>qualify for a total submission, yet you seem to take satisfaction
>>(that's my take on it, I may, of course be wrong) in frustrating
>>this person.    I'd say that if they could quickly resubmit the
>>missing portion, then what's the harm in accepting it?   
>>
>>I hope the situation hasn't gotten out of control where you two
>>can't come to a good outcome on this.   Good luck!
>
>If I were the student, I would be upset too.  Anyone, particularly a CS
>professsor, who provides software to automate assignment submission should
>have the sense to provide a warning before deleting old information.
>I wonder if the student was even informed that he should read the manual.

He has to be told to do this?

>In all seriousness, I feel sorry for Mr. Eachus students.  

So do I. First they operate the software, then tragedy strikes, then
they must consult the documentation to find out why. Maybe someone
should break them of this pattern.

>I don't think Mr.
>Eachus would be very happy if he were told that a file he accidental deleted
>while working at Mitre was unrecoverable because no backups were made.

If he were wise he would consult with the network administrator and 
find out what the policy is on backups.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Any research putting c above ada?

[Kevin Cline]

Craig Franck <clfranck@worldnet.att.net> wrote:


>>
>>If I were the student, I would be upset too.  Anyone, particularly a CS
>>professsor, who provides software to automate assignment submission should
>>have the sense to provide a warning before deleting old information.
>>I wonder if the student was even informed that he should read the manual.
>
>He has to be told to do this?
>

Today, users expect to be able to use simple systems WITHOUT reading a manual.
Certainly a system as simple as one for assignment submission.

>>In all seriousness, I feel sorry for Mr. Eachus students.  
>
>So do I. First they operate the software, then tragedy strikes, then
>they must consult the documentation to find out why. Maybe someone
>should break them of this pattern.

As I understand it, the student had no clue that the first part of his
submission was not received until he got his grade for that assignment.

>
>>I don't think Mr.
>>Eachus would be very happy if he were told that a file he accidental deleted
>>while working at Mitre was unrecoverable because no backups were made.
>
>If he were wise he would consult with the network administrator and 
>find out what the policy is on backups.

If the network administrator is doing his job, part of the process of new
account creation will be informing that user of those policies.
I have little use for people who stand on principle instead of actively
working with others to reach the common goal.

Re: Any research putting c above ada?

[Craig Franck]

clines@delete_this.airmail.net (Kevin Cline) wrote:
>Craig Franck <clfranck@worldnet.att.net> wrote:

>>>If I were the student, I would be upset too.  Anyone, particularly a CS
>>>professsor, who provides software to automate assignment submission should
>>>have the sense to provide a warning before deleting old information.
>>>I wonder if the student was even informed that he should read the manual.
>>
>>He has to be told to do this?
>>
>
>Today, users expect to be able to use simple systems WITHOUT reading a manual.
>Certainly a system as simple as one for assignment submission.

Yes, but the CS professor is teaching *CS* students, not simple end
users of software. They were given a tool and they should be able to
learn how to use it; on their own, no hand holding. Learning to read
technical documentation is an important skill for computer science 
students (so is taking personal responsibility for their foul-ups:
people who's initial reaction to a problem is "nobody told me, its so 
and so's fault" don't last very long in the real world. Learning to 
say "I should have checked" or "That won't happen again" is a much 
better response and tends to keep you employed longer.)

>>>In all seriousness, I feel sorry for Mr. Eachus students.  
>>
>>So do I. First they operate the software, then tragedy strikes, then
>>they must consult the documentation to find out why. Maybe someone
>>should break them of this pattern.
>
>As I understand it, the student had no clue that the first part of his
>submission was not received until he got his grade for that assignment.

If it were me, I would let him resubmit the assignment; if the first
part was obliterated, and there is no copy, do it over and resubmit 
it. (Of coarse, JUMPING DOWN THE PROFESSOR'S THROAT will ensure he
deals with this in the fairest possible manner...)

>>>I don't think Mr.
>>>Eachus would be very happy if he were told that a file he accidental deleted
>>>while working at Mitre was unrecoverable because no backups were made.
>>
>>If he were wise he would consult with the network administrator and 
>>find out what the policy is on backups.
>
>If the network administrator is doing his job, part of the process of new
>account creation will be informing that user of those policies.
>I have little use for people who stand on principle instead of actively
>working with others to reach the common goal.

"Be sure and read the newuser file in your home directory, and if you
have any questions, feel free to ask..." How many times do you have to
say "don't leave yourself logged onto a terminal if you are going to 
be away from it for a while" before you create such a file and dump all
of your best wisdom into it? (Only authorized personel are allowed into
the Control Room, blah, blah, blah...)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree

Re: Any research putting c above ada?

[Jonathan Guthrie]

In comp.lang.ada Craig Franck <clfranck@worldnet.att.net> wrote:
> >Today, users expect to be able to use simple systems WITHOUT reading a
> >manual.  Certainly a system as simple as one for assignment submission.

> Yes, but the CS professor is teaching *CS* students, not simple end
> users of software.

How is there a difference?

Programs should follow the "law of least astonishment."  That is, programs
should behave in the manner that astonishes the user the least.  That
doesn't say anything about the user.  If you are going to say "in this
instance, it's okay if a program destroys important data without any
user feedback because the target audience is special" which is what you
appear to be saying, then we are going to have to agree to disagree.

The program in question is defective, and should be fixed.  "Hand holding"
or not, teaching programmers-in-training (which is what CS students are
supposed to be) that it is a good idea for programs to overwrite data 
without any indication that it is doing so borders on negligence, in
my opinion.  A much better approach would be to lead by example and at
least tell the end user that something untoward is happening.

I apologize if I have reached improper conclusions without sufficient
evidence.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Any research putting c above ada?

[Mathew Hendry]

Jonathan Guthrie <jguthrie@brokersys.com> wrote:
: Programs should follow the "law of least astonishment." That is, programs
: should behave in the manner that astonishes the user the least.  That
: doesn't say anything about the user.

Of course it does. What will astonish the user depends necessarily on his
expectations. If that doesn't say anything about the user, what does?

-- Mat.

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <5l8gf8$2jp@mtinsc05.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:

>Yes, but the CS professor is teaching *CS* students, not simple end
>users of software. They were given a tool and they should be able to
>learn how to use it; on their own, no hand holding. Learning to read

Moreover, a good CS student would ask the question ``Is this electronic hand-in
service idempotent? What are its precise semantics?'' before attempting to
invoke it more than once.

Re: Any research putting c above ada?

[Lawrence Kirby]

In article <5l8j55$8hk@bcrkh13.bnr.ca>
           kaz@vision.crest.nt.com "Kaz Kylheku" writes:

>In article <5l8gf8$2jp@mtinsc05.worldnet.att.net>,
>Craig Franck  <clfranck@worldnet.att.net> wrote:
>
>>Yes, but the CS professor is teaching *CS* students, not simple end
>>users of software. They were given a tool and they should be able to
>>learn how to use it; on their own, no hand holding. Learning to read
>
>Moreover, a good CS student would ask the question ``Is this electronic hand-in
>service idempotent? What are its precise semantics?'' before attempting to
>invoke it more than once.

I would forgive a CS strudent just starting the course for not thinking that!

:-)

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Any research putting c above ada?

[T Wheeley]

On 13 May 1997, Kaz Kylheku wrote:

> In article <5l8gf8$2jp@mtinsc05.worldnet.att.net>,
> Craig Franck  <clfranck@worldnet.att.net> wrote:
> 
> >Yes, but the CS professor is teaching *CS* students, not simple end
> >users of software. They were given a tool and they should be able to
> >learn how to use it; on their own, no hand holding. Learning to read
> 
> Moreover, a good CS student would ask the question ``Is this electronic hand-in
> service idempotent? What are its precise semantics?'' before attempting to
> invoke it more than once.

Anyone who knew anything about computers would not trust the hand in
program and want to see the source code. :p

:sb)

Re: Any research putting c above ada?

[Ray Blaak]

If this had happened when I was tutoring, I would have simply let the student
hand in the missing part of the assignment again. The important thing relevant
to the course is the work the student did. That students should read the
instructions is important, but not as important as the actual work.

Cheers,
Ray Blaak
blaak@mda.ca

Re: Any research putting c above ada?

[Alan Brain]

Ray Blaak wrote:
> 
> If this had happened when I was tutoring, I would have simply let the student
> hand in the missing part of the assignment again. The important thing relevant
> to the course is the work the student did. That students should read the
> instructions is important, but not as important as the actual work.

Similar thing happened to a student I was tutoring last month. He made a
mistake, and so submitted the wrong file.
I marked him on the latest version of his answer he had in his workspace
before the deadline, easily retrievable.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <0313A6944836C48E.193DB760B2AB7789.7A79EA9ECF40F6E3@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

  > I wonder if the student was even informed that he should read the
  > manual.  In all seriousness, I feel sorry for Mr. Eachus students.
  > I don't think Mr.  Eachus would be very happy if he were told that
  > a file he accidental deleted while working at Mitre was
  > unrecoverable because no backups were made.

   First of all, it wasn't my student, it was Richard O'Keefe's.

   Second, there are levels of blame.  Back when I was teaching, if I
handed out an assignment that was too hard because of a mistake I
made, the students didn't suffer for it in grading.  But if the
assignment was within the realm of possibility, I would certainly give
credit to those who got it right.  And if in such a situation a
student called me to say "this can't be right," I'd check that the
problem was solvable.  (And spread the word if it wasn't, but I never
had to do that.  I always solved and checked solutions before I handed
out a problem, even if it was in the text and had an answer in the
back.  I was going to hand out solution sets anyway, might as well do
them ahead of time.)

    But it is the student's responsibility to follow the directions.
I had no problem holding people to the problems as stated.  And I did
say, and still feel that:

   >> eachus@spectre.mitre.org (Robert I. Eachus) writes:
   >> >   But in reality it is the responsibility of the students to get the
   >> >knowledge that they need.

   Professors have lots of responsibilities, but they can't use
telepathy to find out what the students don't know.  The (good) profs
will help if asked, but can't help if they don't know there is a
problem.  (How many hands are we up to now?)  I always adjusted hours
to reality.  If I was teaching a programming course with an assignment
due Tuesday, I was in the computer lab Sunday night. Thursday office
hours weren't going to help.   

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Kevin Cline]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>In article <0313A6944836C48E.193DB760B2AB7789.7A79EA9ECF40F6E3@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:
>
>  > I wonder if the student was even informed that he should read the
>  > manual.  In all seriousness, I feel sorry for Mr. Eachus students.
>  > I don't think Mr.  Eachus would be very happy if he were told that
>  > a file he accidental deleted while working at Mitre was
>  > unrecoverable because no backups were made.
>
>   First of all, it wasn't my student, it was Richard O'Keefe's.

Please accept my sincere apology.  I was led astray by another post with
incorrect citations.

Re: Any research putting c above ada?

[Jonathan Guthrie]

In comp.lang.ada Craig Franck <clfranck@worldnet.att.net> wrote:

> >> Yes, but the CS professor is teaching *CS* students, not simple end
> >> users of software.

> >How is there a difference?

> It was mostly the attitude of the student that anything they needed 
> to know should be handed to them on a silver plater with no effort 
> on their part to learn about the software involved. A lot of the 
> software used by developers has an "in house" almost beta release 
> feel to it; it is not always like those ubiquitous AOL disks that 
> fall out of almost every computer magazines.

I can't judge the attitude of the student, but if I had a program that
ate some important data and didn't let me know that it was doing it,
I would be more angry with the idiot that coded that piece of crap
than I would be at myself for not memorizing the manual.  Of course,
I don't know how CS people think.  I'm an engineer by training.

Part of the problem is that manuals are usually organized as reference
material and usually do NOT contain information in a fashion that is
easily absorbed.  (A "Monty Python" sketch involving lark's vomit leaps
to mind and will not be elaborated upon, here.)

> >The program in question is defective, and should be fixed.  "Hand holding"
> >or not, teaching programmers-in-training (which is what CS students are
> >supposed to be) that it is a good idea for programs to overwrite data 
> >without any indication that it is doing so borders on negligence, in
> >my opinion.  

> Maybe it is a bug in the beta release. Did he look for a list of
> known bugs?

I assign you a task:  Write, longhand, "Beta software should not be
used in production situations" 500 times.  In the situation described,
whoever chose to use beta software in that manner a fool, if the software
was a beta.  Learning not to use the software in that case is more
important than following directions.

If I were writing the program, a list of known bugs would not contain ANY
mention of a situation where data was lost.  That is a "category 2" defect
and cannot be allowed to exist in any situation where any end user might
run into it.  Look, I don't think that the experience was as valuable for
the user as it should be for the coder.  Learn NOT to write programs that
destroy data without giving feedback.  Learn NOT to write programs that
don't give feedback.

I think a car analogy is good, here.  Every car I've ever owned has come
with an owner's manual.  I suspect that there isn't a person on the
face of the earth has ever read one of those.  I suspect that there are
thousands of mechanics, car dealers, automotive engineers, and suchlike
who have never read the owner's manual for their automobile.  The thing
is, a car will give you feedback.  If you pay attention to the vehicle,
it will let you know when it needs service and you often do not need to
know the details of how to test the level of power steering fluid.

Computer programs need not obey any physical laws so they cannot, except
through the effort of the programmer, let the user know what has happend.
If the program can't tell the user what's going to happen, at least it
should tell the user what has happened.

> CS students are people to and deserve good quality software, but 
> if even *they* don't read the manuals, why bother printing them or 
> making them available on line?

Yes, indeed.  Why bother printing them?  I think that the world would
be a much better place if programmers didn't use the crutch of "the
manual".  ("The fact that it's going to eat all of your tax records
and get you sent to jail for the rest of your life if you run it before
noon on February 29 is documented on page 879 of the manual.  What?
You didn't commit to memory all 12347 pages of the manual?")

Documentation has a use, but it's not to keep users out of trouble.
When a program is about to eat data, it should let the user know.

> Anyway, it is always better to check
> for yourself rather than relying on there not being something fucked 
> up with the software. WARNING: This software only saves your latest
> submission to any project, so if you submit it twice, resubmit the 
> entire project.

Does it give the warning when you save the file?  Why didn't you say
so?  That's different.  If you ignore a well-placed notice that, then
there's nothing you can do to help him.

It might be helpful for you to consider the placarding requirements
for aircraft.  ALL of the information on the placards is in the POH,
(Pilot's Operating Handbook,) shoot, the placards themselves are
documented in the POH.  However, the placards contain information that
is considered important enough to be placed in front of the pilot when
he might need the information rather than relying on the pilot's memory
of the manual.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Any research putting c above ada?

[Szu-Wen Huang]

Normally I wouldn't bother with a crossposted post that doesn't have
anything to do with the topics of any of the three groups, but somehow
the discussion turned into what is expected of software, and I think
that's marginally relevant.

Jonathan Guthrie (jguthrie@brokersys.com) wrote:
: In comp.lang.ada Craig Franck <clfranck@worldnet.att.net> wrote:

: > >> Yes, but the CS professor is teaching *CS* students, not simple end
: > >> users of software.

: > >How is there a difference?

: > It was mostly the attitude of the student that anything they needed 
: > to know should be handed to them on a silver plater with no effort 
: > on their part to learn about the software involved. A lot of the 
: > software used by developers has an "in house" almost beta release 
: > feel to it; it is not always like those ubiquitous AOL disks that 
: > fall out of almost every computer magazines.

: I can't judge the attitude of the student, but if I had a program that
: ate some important data and didn't let me know that it was doing it,
: I would be more angry with the idiot that coded that piece of crap
: than I would be at myself for not memorizing the manual.  Of course,
: I don't know how CS people think.  I'm an engineer by training.
[...]

Here we see two excellent and not mutually contradictory points.  Craig
is saying that a college student, especially one in CS, should have
enough initiative to know the relevance of documentation.  I don't
think Jonathan is actually disagreeing with that, though he makes it
sound like so by saying the software is to blame.

Jonathan, if you accidentally did a 'rm -rf' (recursive delete) at
work and delayed your project by months, do you blame the software?
Sure, rm didn't warn you, wasn't safe, was this and that - but the
point is that the damage is done and it's *your* responsibility.  I
think that's Craig's point - whatever caused it, the CS student must
take responsibility for not reading the manual, not asking the SA,
not asking the teacher.

Another example:  would you send a crucial (not necessarily secret)
piece of message through e-mail?  You might consider calling, or
explicitly asking for an acknowledgement, correct?  Now, if a student
did not receive an acknowledgement that both parts of his work are
received, what kind of students do we want to produce?  The kind that
sits on his ass and *assumes*, or the kind that finds out?

Do you not generally assume your compiler is correct, but not preclude
the possibility that it can be generating wrong output?

I don't think anybody is advocating that the CS student should be
given full credit because of a crappy program whose instructions he
did not read.  Sure, software can and should be better, but in the
end a person must take responsibility (not necessarily guilt, just
responsibility), and I don't think it's the person who wrote it.
 
: Part of the problem is that manuals are usually organized as reference
: material and usually do NOT contain information in a fashion that is
: easily absorbed.  (A "Monty Python" sketch involving lark's vomit leaps
: to mind and will not be elaborated upon, here.)

If the student has trouble understanding the documentation, I believe
there are people available to ask.  Lousy manuals aren't reasons to
skip all manuals.

: > >The program in question is defective, and should be fixed.  "Hand holding"
: > >or not, teaching programmers-in-training (which is what CS students are
: > >supposed to be) that it is a good idea for programs to overwrite data 
: > >without any indication that it is doing so borders on negligence, in
: > >my opinion.  

: > Maybe it is a bug in the beta release. Did he look for a list of
: > known bugs?

: I assign you a task:  Write, longhand, "Beta software should not be
: used in production situations" 500 times.  In the situation described,
: whoever chose to use beta software in that manner a fool, if the software
: was a beta.  Learning not to use the software in that case is more
: important than following directions.

If I didn't trust the programs the SA probably hacked together, I'd
make sure he got it.  In fact, back in school I read the Tcl source
code of our homework submission program, because ultimately it's *my*
grade.

Let me put it most clearly - it's somebody's fault the software isn't
production quality, and that failure might disqualify the person for
a teaching position (teaching the wrong thing, certainly).  It's another
person's fault the assignment wasn't turned in correctly.  The two
failures do not cancel each other out.

: If I were writing the program, a list of known bugs would not contain ANY
: mention of a situation where data was lost.  That is a "category 2" defect
: and cannot be allowed to exist in any situation where any end user might
: run into it.  Look, I don't think that the experience was as valuable for
: the user as it should be for the coder.  Learn NOT to write programs that
: destroy data without giving feedback.  Learn NOT to write programs that
: don't give feedback.

I completely agree.  However, that doesn't mean Microsoft will pay me if
Word ate my document, does it?  Who gets fired?

: I think a car analogy is good, here.  Every car I've ever owned has come
: with an owner's manual.  I suspect that there isn't a person on the
: face of the earth has ever read one of those.  I suspect that there are
: thousands of mechanics, car dealers, automotive engineers, and suchlike
: who have never read the owner's manual for their automobile.  The thing
: is, a car will give you feedback.  If you pay attention to the vehicle,
: it will let you know when it needs service and you often do not need to
: know the details of how to test the level of power steering fluid.

You're joking, right?  All cars I've driven in have this red line on
the tachometer (if it has a tachometer at all), and *nothing* to prevent
me from accelerating past that line.

Yes, the red line is documented, but what does it mean?  Is it the point
where you should be careful because it's about to break, or is it the
point it actually breaks?  What happens when it breaks?  Does the engine
explode or shut down gracefully?

Now, a grades submission program is not a car.  It's not likely that
people will die from its misuse - not impossible, but not likely.  Its
bugs are something the professor can completely undo (by accepting the
homework).  Surely you don't expect its producer to pour in the kind of
rigor seen in mission-critical systems?

Do we really want to produce CS students who sit on their asses assuming
that software will warn them of every potential problem?

: Computer programs need not obey any physical laws so they cannot, except
: through the effort of the programmer, let the user know what has happend.
: If the program can't tell the user what's going to happen, at least it
: should tell the user what has happened.

All sound principles that I agree with.  However, I'm sure you don't
actually *expect* all software to be this uniformly good.  I'm sure you
don't just sit down in front of a new OS and click and drag randomly and
expect that all damages you make can be undone, right?

: > CS students are people to and deserve good quality software, but 
: > if even *they* don't read the manuals, why bother printing them or 
: > making them available on line?

: Yes, indeed.  Why bother printing them?  I think that the world would
: be a much better place if programmers didn't use the crutch of "the
: manual".  ("The fact that it's going to eat all of your tax records
: and get you sent to jail for the rest of your life if you run it before
: noon on February 29 is documented on page 879 of the manual.  What?
: You didn't commit to memory all 12347 pages of the manual?")

You give some extreme examples.  I believe the more common example is
the idiot who doesn't read at all and breaks something.

Ideally all software would be completely intuitive, requiring no manual.
Is that actually feasible?

[...]

Re: Any research putting c above ada?

[Jonathan Guthrie]

In comp.lang.ada Szu-Wen Huang <huang@mnsinc.com> wrote:

> Here we see two excellent and not mutually contradictory points.  Craig
> is saying that a college student, especially one in CS, should have
> enough initiative to know the relevance of documentation.  I don't
> think Jonathan is actually disagreeing with that, though he makes it
> sound like so by saying the software is to blame.

In my posts in this thread (this makes three, I believe) I have not 
ONCE said anything about the student or his grade on the project.  I
break this trend now.  If I were in the position of the instructor,
I believe that I would probably not give him full credit for the
assignment.  It is, after all the student's responsibility to make
sure that the complete assignment is received by the grader.  In the
real world, you can fail for reasons that aren't anything you have
control over.  This is known as "bad luck," a concept which has
fallen out of favor.

My actual point is twofold.  First, saying "he should have read the
manual" isn't a good thing to do because documenting a bad design does
not make the bad design better.  Second, most technical documentation
is bad which leads to people not being able to use it.  (Either because
they don't read it or because they don't understand it.  Either way,
that is a failure of the documentation.  I've recently come to a fairly
deep respect for good technical documentation.)

> Do we really want to produce CS students who sit on their asses assuming
> that software will warn them of every potential problem?

No, we want to produce CS graduates who write software for people who sit
on their asses...

> : Computer programs need not obey any physical laws so they cannot, except
> : through the effort of the programmer, let the user know what has happend.
> : If the program can't tell the user what's going to happen, at least it
> : should tell the user what has happened.

> All sound principles that I agree with.  However, I'm sure you don't
> actually *expect* all software to be this uniformly good.  I'm sure you
> don't just sit down in front of a new OS and click and drag randomly and
> expect that all damages you make can be undone, right?

Let me tell you about the time I deleted all the /usr/lib/libc* files on
my Linux system...

However, I DO expect all software to be that uniformly good.  I may be
disappointed sometimes, but if I don't expect it, it will never happen.
Programming wants to become a kind of engineering.  For that to happen,
the concept of "acceptable practice" has to be universally understood
and adhered to by its practitioners.

> : Yes, indeed.  Why bother printing them?  I think that the world would
> : be a much better place if programmers didn't use the crutch of "the
> : manual".  ("The fact that it's going to eat all of your tax records
> : and get you sent to jail for the rest of your life if you run it before
> : noon on February 29 is documented on page 879 of the manual.  What?
> : You didn't commit to memory all 12347 pages of the manual?")

> You give some extreme examples.  I believe the more common example is
> the idiot who doesn't read at all and breaks something.

> Ideally all software would be completely intuitive, requiring no manual.
> Is that actually feasible?

I don't think that, in an ideal world, all software would be completely
intuitive.  There is a parable about the instruction book for an ax in
_The Zen of Programming_ that might be enlightening.  In fact, I have
argued that it is impossible for ANY software to be truly "intuitive"
because software need not obey any physical laws.  I am not saying that
manuals should not be printed.  I'm trying to get people to think about
what goes in them.  If I can get people to wonder what a manual is good
for (or, more importantly, what it is NOT good for) then I have made my
point. 

It's not just enough to document serious problems (and anything that
eats data is a serious problem with a computer program) you have to
make the end user aware of the danger and make sure that he understands
it.  This is a tall order, but it's what's required.  (Also note that
I'm not just talking about the documentation of software, but of just
about everything.)

The tendency nowadays is to separate manuals into "reference" and "quick
start" sections.  The point being to reduce the apparent amount of
crud that you have to wade through to make use of the documentation in
the most common cases.  This is a good trend, but it's not nearly finished.
The most common problems seem to be related to circular definitions ("The
widget counter is used to count widgets.") or an assumption that the end
user understands the consequences of the use of a particular feature.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Any research putting c above ada?

[W. Wesley Groleau (Wes)]

Alan Bowler wrote:
> I don't think the car analogy applies.  In that case almost everyone
> is forced to observe how a car is operated for 16 YEARS, then they
> are allowed to take a written test on the theory of car use.  If they
> pass that they can start a period of closely supervised instruction
> with the real thing, followed by another test(s) of actual skill.  
> This all in a technology with has had only minimal changes since 
> Henry Ford.

And yet it still kill more people than airplanes, which are
popularly _perceived_ as dangerous.  Perhaps one difference is
that you have to be "certified" for _each_model_ you want to fly.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

          wwgrol  @  pseult01  .  fw  .  hac  .  com

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Any research putting c above ada?

[M. Prasad]

Richard A. O'Keefe wrote:
> 
> eachus@spectre.mitre.org (Robert I. Eachus) writes:
> >   But in reality it is the responsibility of the students to get the
> >knowledge that they need.
> 
> I've just had a student in my office who was extremely annoyed.
> He had submitted his assignment electronically in two parts,
> and his second submission had caused his first to be deleted,
> hence his low mark.  He was *outraged* at the suggestion that
> he ought to have read the on-line manual for the electronic
> submission program.  I pointed out that he _ought_ to read the
> manuals for _all_ the programs he used, and he was vehemently
> opposed to that view.  In his view, he was paying us money,
> and he shouldn't have to read _anything_ that wasn't in the
> printed handouts.  It was a very upsetting meeting.

He was right.  Very few pieces of software *require* reading
of manuals these days.  Software is now user friendly,
and users have come to rely upon it.

If you insist on using your own home-grown software for
actual serious work upon which people's grades might
depend, you should spend the time and effort on getting
your software up to the current standards of reliability.
Otherwise, take submissions on diskettes or paper.  Students
should be graded on the work they did.

Re: Any research putting c above ada?

[W. Wesley Groleau (Wes)]

> Developing a program with a really crappy user interface and then
> telling the user that they should have read the manual when the
> inevitable problems arise is a less than compelling excuse.
> 
> You're more wrong than was he.  That a submission would delete a
> previous submission without warning is inexcusable.  That such
> dangerous behavior was not pointed out is similarly inexcusable.

Although I believe the tool should have been more robust,, I can't 
help but marvel at the mental laziness of the student in not 
considering whether the submission method might choose a file name 
that identifies the student and the assignment, and that when 
both of those are the same, .....  

> They didn't write the program.  He _did_ submit both parts of the
> assignment.  That fulfilled his obligation.  YOU did not choose to
> receive it.

He did not "choose" to reject the submission.  He provided a tool
to make it _easier_ to turn in the assignment.  Now everyone jumps
on him for not making the tool idiot-proof.

Human Factors Principle Number ???: When you try to make a program
idiot-proof, you only find out how resourceful an idiot can be.

BTW, are comp.lang.* the right place for this topic?

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Any research putting c above ada?

[Steve Jones - JON]

ray@netcom.com (Ray Fischer) writes:

[snip]
> 
> Developing a program with a really crappy user interface and then
> telling the user that they should have read the manual when the
> inevitable problems arise is a less than compelling excuse.

If a CS student doesn't get into the habit of reading manuals he
will be of no use when he gets into the real world.

"Oh know I didn't read the specs I just wrote it how I thought it
 should work" -- And yes I have seen this

Currently I am RTFMing through a stack of documents, if I don't do this
nobody will be able to use the service I am about to write. If I was
writting a quick hack to display some data to the user as a proof of
concept then not reading all of the spec is fine, but in this case the
student was handing in an important piece of work, the risk assesment
here is that it is their job to hand the assignment in correctly.
Just hitting the "Send" button or whatever and expecting everything
to be provided on a plate _without_ checking its side-effects is
dangerous and stupid.

> 
> >  In his view, he was paying us money,
> >and he shouldn't have to read _anything_ that wasn't in the
> >printed handouts.  It was a very upsetting meeting.
> 
> You're more wrong than was he.  That a submission would delete a
> previous submission without warning is inexcusable.  That such
> dangerous behavior was not pointed out is similarly inexcusable.

My first question was actually "Why didn't the student submit it
in _one_ go".  And the answer is "because he didn't RTFM".  Had
he done that there would be no problem.

> 
> >Some students are rock solid *certain* that it *isn't* their
> >responsiblity.
> 
> They didn't write the program.  He _did_ submit both parts of the
> assignment.  That fulfilled his obligation.  YOU did not choose to 
> receive it.

He failed to read the instructions.  If it had been an exam paper and
at the top it said "read the provided document for instructions" and the
student had failed to do that, and thus got no marks because the instructions
said "all answers to be written in Hex" would you still feel it was not
his fault ?  He was directed towards a manual, he failed to read the
instructions, thus painful though it is a lesson has been learnt.

The first commandment: RTFM.

-- 
|Un Loup en France  | Wolverhampton Wanderers, out of darkness cometh Bully|
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song------------|
|----The above opinions rarely reflect my own and never my employers'------|
|Do not add me to mailing lists violations will be billed for time.        |

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <rayEA5A7D.932@netcom.com> ray@netcom.com (Ray Fischer) writes:

  > Developing a program with a really crappy user interface and then
  > telling the user that they should have read the manual when the
  > inevitable problems arise is a less than compelling excuse.

     What makes this a crappy user interface?  The requirements may
have specified that new submission erased old ones.  This would allow
a student to submit the current version and do additional checking
during the subway ride home.  If he finds something to fix, the
earlier submission is ignored, otherwise he doesn't have to return to
the lab the next day.

     I've even given take-home tests in this format, although there is
it unusual for a student to use the option.  However, I once had a
student who handed in the test, then entered the hospital for
gallstone removal.  I suspect that the second paper--the other was
returned unopened--was much better.

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5k60au$gig@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> What is a computer-science view and how is it incompatible with a software
> engineering view? Do I detect a slight bias against computer science folk?

IMO, "computer science" is an oxymoron (and this view can and has been
given good arguments of support).  Obviously others will and do
disagree.  Shrug.


> Have you ever seen code written by engineers with no understanding of
> computer science? :))

Ever seen code written by "CS"ers with no knowledge of engineering?
At least as bad (for different reasons) and from what I've seen rather
worse.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <JSA.97Apr30161031@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>In article <5k60au$gig@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
>
>> What is a computer-science view and how is it incompatible with a software
>> engineering view? Do I detect a slight bias against computer science folk?
>
>IMO, "computer science" is an oxymoron (and this view can and has been
>given good arguments of support).  Obviously others will and do
>disagree.  Shrug.

It's not so much of an oxymoron as it is a simple misnomer. But we are stuck
with it.

Some aspects of CS have a scientific flavor; there is a fair degree of
empiricism.

Whenever you prototype some software, or profile the performance of a program,
you are doing an experiment that is not unlike a scientific experiment. You
form a hypothesis, construct an apparatus to test it, and then reevaluate
and form a new hypothesis...

I couldn't help but smile at Fred Brooks' claim that he is a ``dyed in the wool
empiricist''.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5kb91p$1bc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> Some aspects of CS have a scientific flavor; there is a fair degree
> of empiricism.  Whenever you prototype some software, or profile the
> performance of a program, you are doing an experiment that is not
> unlike a scientific experiment. You

That's only a part of the story.  In CS you are dealing with
intentional artifacts and IMO that alone snuffs the "science" part.
As I say, others will disagree...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>
>In article <5kb91p$1bc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:
>
>> Some aspects of CS have a scientific flavor; there is a fair degree
>> of empiricism.  Whenever you prototype some software, or profile the
>> performance of a program, you are doing an experiment that is not
>> unlike a scientific experiment. You
>
>That's only a part of the story.  In CS you are dealing with
>intentional artifacts and IMO that alone snuffs the "science" part.
>As I say, others will disagree...

Well, it is no longer "Natural Science". If you think of science as 
generalizing through observation and application of specific methods 
then, as Kaz said, it only has a scientic "flavor". I think the best 
analogy is one of construction: you are a computer engineer, a 
technologist who builds things and constructs models. The people who
build those billion dollar chip factories rely on semiconductor 
physicists who would be much more of a scientist than the fellow 
writing packages in VHDL. I think you need to distinguish software
engineering from the science behind the technology. Lumping it all 
into "CS" is more of a convience than anythings else; you have one 
term for everything at the expense of being imprecise. When you lump
in cost management and risk assessment quite often it seems like it
has as much to do with actually writing code as your personnel manager
keeping track of how many vacation days you have left.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
All evolution in thought and conduct must at first appear
as heresy and misconduct. -- George Bernard Shaw

Re: Any research putting c above ada?

[Matthew Givens]

Just to add my two cents in again, and to show you that I'm not standing 
alone and whistling in the wind, I would like to share with you a memo 
that hit my e-mail on Wednesday.

The e-mail was from our project director (remember that I work with a 
government contractor doing software for the Air Force).  It stated that, 
since the Air Force was relaxing their insistence on using Ada, we would 
now be able to get rid of the anchor that's been hanging around our necks.
  In short, we get to ditch Ada for the next version.  The memo then went 
on to discuss other language options and ask for opinions.

So, it is not merely I who understand that Ada is not the best language 
for all tasks, but also the project managers and design folks at my 
company.  C++ was one of the languages discussed to replace Ada, but by 
no means the only one.

So, to all those who told me (more than once) that I was crazy to think C 
could do anything better than Ada, I am not alone in my understanding.  
My company shares my opinion, as does the Air Force (after all, they are 
relaxing the Ada requirement).

"What is the speed of dark?"
- Iceman

Re: Any research putting c above ada?

[Robert S. White]

In article <5ke9ft$15lq@newssvr01-int.news.prodigy.com>, NKSW39B@prodigy.com 
says...

>now be able to get rid of the anchor that's been hanging around our necks.
>  In short, we get to ditch Ada for the next version.  The memo then went 
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Curious.  Are you going to throw away all of your previously tested
code modules and re-code/code inspect/low leve test every single code
module for the new version.  Do you ever have code re-use from version
to version?  Or is Ada 83 preventing you from using some large libraries
written in another language?
   
>on to discuss other language options and ask for opinions.
>
>So, it is not merely I who understand that Ada is not the best language 
>for all tasks, but also the project managers and design folks at my 
>company.  C++ was one of the languages discussed to replace Ada, but by 
>no means the only one.
>
>So, to all those who told me (more than once) that I was crazy to think C 
>could do anything better than Ada, I am not alone in my understanding.  

   You say C here again.  But above you say others at your company 
discussed the possiblity of using C++.  For team programming efforts
C does not equate to C++.  C++, Java and Eiffel do provide a better 
set of tools and capabilities (than C) for modern software engineering.  
You could argue that they offer better Object Oriented programming 
features than Ada 83's object based features.  Ada 95 catches up with 
these OO features.  What might be argued about is Eiffel's implementation 
of Design by Contract assertions versus the strong typing that Ada 
provides.  Contrawise one would argue about built-in tasking support 
that Ada provides.  This could go on and on (what are language wars
made of anyway ;-)

>My company shares my opinion, as does the Air Force (after all, they are 
>relaxing the Ada requirement).
  
  The DoD study said other languages could be looked at for 
"non-Warfighting" software.  Are you doing ground based logistics
solutions?  Looked at Smalltalk?  Some could argue that Smalltalk
provides a more rapid OO development enviroment. 

  Frankly I am perplexed about your strong negative "opinion" about
having to use Ada and thinking that C would be a better choice for
your team programming effort.  Do you design software modules with
high cohesion and loose coupling?  Are you concerned with finding 
bugs as early as possible in the software lifecycle?  Is software
re-use a major concern?

_____________________________________________________________________
Robert S. White                  -- an embedded sys software engineer

Re: Any research putting c above ada?

[Matthew Givens]

afn03257@freenet2.afn.org (Daniel P Hudson) wrote:
>
>The problem with C and C++ is, even with exceptions, when witting 
mission
>critical software, C(++) leaves a *lot* UNDEFINED. This translates 
>to a deferenced NULL pointer could cause a defibrillator to go off
>on a healthy patient and cause a heart attack rather than prevent one.
>You can scream you hold the programmer responsible all you want, but
>that is of no comfort to the man sitting there watching his death 
charge
>up to give him a jolt. I'm not saying it is impossible to write bad
>Ada code which may do the same, but it is a LOT less likely. Deny it
>if you must to defend your own opinion of C as the perfect language,
>I don't care, but facts are facts and denying them won't make them
>go away. However, the library itself is defined well. It is the actions
>of the library that worry me. C's undefined behavior is great for
>portability, but bad for safty. You are not going to have both in a
>langauge, you might not have either in some. Assembly lanaguge, for
>example, is NOT portable or safe. It makes it no less useful than Ada
>or C. It only means you should know WHEN to use your tool
>[whether it is C, Ada, Modula, Basic, Eiffel, or whatever] and
>WHEN not to. Always is not the CORRECT or LOGICAL solution.

I would never, I hope, pretend that one language is perfect for every 
situation.  In fact, I argue the opposite quite a lot.  C is good at what 
it does, very good.  Try writing a compiler or OS in Ada.  You can do it, 
certainly, but it's easier and  more natural in C.  Why?  Because that's 
what C was designed to do!  Ada was intended to develop embedded systems, 
and is good at it.  No question.

But something that is good in one situation is bad in another.  This 
means that both C and Ada have their places.  Neither is objectively 
"better" than the other, because you can't compare them objectively.  You 
have to look at the strengths and weaknesses of a language, not just the 
weaknesses.  You also have to look at what the language is being used to 
do.

How many grahics intensive computer games are being written in Ada?  
That's really out of it's intended realm, so I would hazard to guess not 
many.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Nick Roberts]

In reply to...
> > How many grahics intensive computer games are being written in Ada?  
> > That's really out of it's intended realm, so I would hazard to guess
not 
> > many.

Corey Minyard <minyard@acm.org> wrote in article
<m2ragbrmij.fsf@acm.org>...
> But you could.  You might be able to squeak a little more performance
> out of C by using tricks, but probably not that much.

In fact, there is nothing that could be squeezed out of using C or C++ that
could not be squeezed out of using a good Ada compiler. Quite the opposite.
The general principle is that the more information a compiler is given, the
more optimisation it can perform. An Ada program gives more information
than the equivalent C or C++ program. So, more optimisation is possible. I
speakee as one who nose :-)

Nick.

Re: Any research putting c above ada?

[Gary W Smith]

In article <u912rj925.fsf@kastle.com>,
Richard Krehbiel  <rich@kastle.com> wrote:
->kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:
->
->> Hello,
->> 
->> Is there any research out there, that, comparing c and ada, (or c++ and
->> ada), gives advantage to the c side? 
->
->Here's a bit of research you can do yourself.
->
->Can you go to the computer store and buy Microsoft Visual Ada 5.0?
->Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
->compiler at the local Comp USA store?  No.


Can you go to a typical house and count more people than bugs?


- goob 
(numbers don't necessarily equate to higher life form)

Re: Any research putting c above ada?

[Alan Brain]

Richard Krehbiel wrote:
>
> Here's a bit of research you can do yourself.
> 
> Can you go to the computer store and buy Microsoft Visual Ada 5.0?
> Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
> compiler at the local Comp USA store?  No.

Correct. You download a Free compiler from the web instead.
GNAT (freeware) is already being used in safety critical applications,
ie it's Industrial Strength. See http://www.adahome.com

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5j46m5$1nii@newssvr01-int.news.prodigy.com> NKSW39B@prodigy.com (Matthew Givens) writes:

> As to C/C++ not having multi-tasking capabilities, I guess it depends, 
> now doesn't it?  When I was programming on an OS2 platform, I developed 
> an app that could, under the right circumstances, support 5 different 
> concurrent tasks at once.  Sounds like tasking to me.  Of course, what do 
> I know?  I'm just a dirty C programmer, right?

I think he only means that neither C nor C++ have any concurrency
model _within_ the language.  You must go outside it and interface to
the thread package of the OS, use some class library that has already
done this more or less for you, or roll your own such class library
that provides some concurrency support.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Daniel P Hudson]

Richard Krehbiel <rich@kastle.com> wrote:
>kgoldin@galaxy.csc.calpoly.edu (Konstantin B. Goldin) writes:

>> Hello,
>> 
>> Is there any research out there, that, comparing c and ada, (or c++ and
>> ada), gives advantage to the c side? 

>Here's a bit of research you can do yourself.

>Can you go to the computer store and buy Microsoft Visual Ada 5.0?
>Borland Turbo Ada?  Watcom Ada 4.0?  Can you find *anybody's* Ada
>compiler at the local Comp USA store?  No.

According to the older members of this group you can't find C
compilers there either, just C-like compilers. Oh and BTW, I have
seen an Ada compiler in software retail stores, but they catered to
more than the PC and Mac, like Unices, VMS, etc...

Re: Any research putting c above ada?

[Steve Jones - JON]

kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> 
> In article <2senchydgk.fsf@hpodid2.eurocontrol.fr>,
> Steve Jones - JON  <jon@hpodid2.eurocontrol.fr> wrote:
[snip]
> >
> >In C assigning to an unitialised pointer will cause either a crash or
> >wild behaviour and never tell you, in Ada it will crash and tell you why.
> 
> Decent C compilers will diagnose when you have used an unitialized variable
> rather than crashing at run time.

My point is that the manner in which it does fail (for instance if a function
is passed an unitialised pointer, or a pointer whose memory has been 
deallocated by another reference), it fails with a bang, Ada with a whimper.

> 
> >In Ada you can restrict the user from assigning between incompatible types,
> >you can data hide etc etc.
> 
> This is true of C as well. Assigning between incompatible types is a constraint
> violation which *requires* a diagnostic. It's all in ISO 9899:1990.

A Diagnostic yes, but Ada prevents you from doing it.  And this is only
on weak types anyway.
[snip]
> >cfl = a;
(assigning between two seperate int types)
> 
> What is your point here? The two types here are compatible. You have only
> created an alias name for int. In other words, C has structural equivalence
> for types (other than structs).
> 
> Why don't you see a type violation in the very declarations? 
> 
> It could easily be said that
> 
>     a = 4;
> 
> is a type violation. After all, 4 is an integer, and a is an airspeed. A
> decent, safe language would require a special conversion operator to be done on
> the 4 to construct an airspeed from an integer. Does Ada require that?

The Ada code would be
-- Units in hundreds of feet.
type Cleared_Flight_Level_Type is new integer range -10 .. 1000; 

-- Units in Knots, Higher values calculated as Mach.
type Airspeed_Type is new Integer range 0 .. 700;

Airspeed : Airspeed_Type := 4; -- 4 is a literal constant of type Airspeed_Type

Cleared_Flight_Level : Cleared_Flight_Level_Type := Airspeed;

This will bomb out in the compiler as the two types are difference.  The
literal 4 is inherited from the parent type into the new types (as are the
operators +, - etc).

> 
> In C you can do this:
> 
>     typedef struct airspeed { int i } airspeed;
>     typedef struct cleared_flight_level { int i } cleared_flight_level;
> 
> There you go. The two are no longer assignment compatible with each other or
> with the int type. You can still assign an airspeed to an other airspeed, and
> pass it in and out of functions by value. The .i operation converts
> an airspeed to an int.

But this adds complexity (always having .airspeed.value) and still doesn't
allow you to do correct range checking, and assignment of the value part
of airspeed is still compatible with that of CFL.

[snip]
> Ada may have the advantage that this is required behavior. But a quality C
> compiler (such as the GNU C compiler) will warn you if one or more of the
> members of an enumeration are not mentioned in the switch statement. 

My point is that the warnings can be ignored, in Ada the code WILL fail.

> 
> Where C messes up is in those types of errors that _cannot_ be diagnosed
> or cannot be diagnosed easily.  Other than that, a C implementation can be
> retrofitted with all kinds of diagnostics that are not required by the
> language. True, this lack of a requirement is a disadvantage, but it's
> not a major obstacle.
> 

For a large safety project the first thing that would be required is strong
typing, retrofitting this would take a while I feel, and if not enforced
what is the point.

IME C produces more bugs than Ada, and it is harder to track down bugs
in C than in Ada.  And given a choice of specifiying a language for an
"average" programmer I would prefer Ada every time over C (the things
I have seen people do in C make my flesh creep) if they get the design
wrong then the language won't help, but by preventing many of the common
C errors Ada is a leap ahead.

-- 
|Un Loup en France  | Bully deification Party. One Party, one issue.     |
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song----------|
|----The above opinions rarely reflect my own and never my employers'----|
|Do not add me to mailing lists violations will be billed for time.      |

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <2sybamvslk.fsf@hpodid2.eurocontrol.fr>,
Steve Jones - JON  <jon@hpodid2.eurocontrol.fr> wrote:
>kaz@vision.crest.nt.com (Kaz Kylheku) writes:

>> >In Ada you can restrict the user from assigning between incompatible types,
>> >you can data hide etc etc.
>> 
>> This is true of C as well. Assigning between incompatible types is a constraint
>> violation which *requires* a diagnostic. It's all in ISO 9899:1990.
>
>A Diagnostic yes, but Ada prevents you from doing it.  And this is only
>on weak types anyway.

That's a pointless distinction. If you see diagnostics, fix the program.  It's
trivial to make a modified compiler in which any diagnostic is treated as an
error which results in a terminated translation. For example, the GCC -Werror
flag:  ``Treat warnings as errors; abort compilation after any warning''.
True, not all compilers have such an option. But a good engineer doesn't
need it.

Any decent engineer will fix the program if it produces diagnostics. We are
talking about good engineers aren't we? If we are talking about run of the mill
goofballs, language won't help. As someone said earlier, Ada is a tool for
software engineers. It's use won't turn you into one, however.

To me, it's good enough _that_ a compiler or checker catches the error.
Whether or not it will try to emit a translation in spite of the diagnostic
is immaterial, because I'm not interested in such a translation.

I anticipate a good counterargument here: that you sometimes have to maintain
code written by goofs who ignore diagnostics (and even operate the tools with
minimum diagnostic levels). It's hard to go back and fix a body code which
incorporates undefined behavior into its very design.

Some people just don't deserve the freedom to ignore compiler diagnostics!

>The Ada code would be
>-- Units in hundreds of feet.
>type Cleared_Flight_Level_Type is new integer range -10 .. 1000; 
>
>-- Units in Knots, Higher values calculated as Mach.
>type Airspeed_Type is new Integer range 0 .. 700;
>
>Airspeed : Airspeed_Type := 4; -- 4 is a literal constant of type Airspeed_Type
>
>Cleared_Flight_Level : Cleared_Flight_Level_Type := Airspeed;
>
>This will bomb out in the compiler as the two types are difference.  The
>literal 4 is inherited from the parent type into the new types (as are the
>operators +, - etc).

This could be seen as a safety violation. A truly strongly typed language would
require you to coerce all such literals into an appropriate type, and would
not inherit things behind your back. Ada is clearly not as perfect as the
proponents would have us believe. It can be seen as a weakness that '4' can,
like a chameleon, be an Airspeed hither and a Cleared_Flight_Level type
tither. Like C, Ada sacrifices safety for the sake of programmer convenience,
though arguably to a lesser extent.

Re: Any research putting c above ada?

[Matthew Givens]

Steve Jones - JON <jon@hpodid2.eurocontrol.fr> wrote:
>
>IME C produces more bugs than Ada, and it is harder to track down bugs
>in C than in Ada.  And given a choice of specifiying a language for an
>"average" programmer I would prefer Ada every time over C (the things
>I have seen people do in C make my flesh creep) if they get the design
>wrong then the language won't help, but by preventing many of the 
common
>C errors Ada is a leap ahead.
>

Hmmmmm, this struck me as wrong.  Because you've seen people who program 
poorly in C, you prefer Ada every time?  But I've seen some abysmally 
poor (and horrifying) code in Ada.  Does that mean that C is better?

Of course not.  The thing to remember is that different languages fit 
different tasks, and different programmers are suited to different 
languages.  I am a highly proficient C programmer, but only a moderately 
skilled Ada programmer.  In fact, I often rough out algorythms in C 
before implementing them in the Ada version.  Why?  Because I don't have 
to think so much of the surface furnishings of Ada and can concentrate on 
just the functionality.  It would save a lot of time if I didn't have to 
write the Ada version, wouldn't it?

And, before I get lambasted, I realize that other people don't agree with 
that.  That's okay, variety is a good thing, not a bad one.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Any research putting c above ada?

[Alan Brain]

Matthew Givens wrote:

> Of course not.  The thing to remember is that different languages fit
> different tasks, and different programmers are suited to different
> languages.  I am a highly proficient C programmer, but only a moderately
> skilled Ada programmer.  In fact, I often rough out algorythms in C
> before implementing them in the Ada version.  Why?  Because I don't have
> to think so much of the surface furnishings of Ada and can concentrate on
> just the functionality.  It would save a lot of time if I didn't have to
> write the Ada version, wouldn't it?

That's amazing. Because I do the design in Ada, before coding in C/C++.
I'm a skilled Ada-83 programmer, a tyro at -95, poor average at C (OK,
average average, the average is pretty p*ss poor IMHO) and a neophyte at
C++.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Matthew Givens]

Alan Brain <aebrain@dynamite.com.au> wrote:
>
>Matthew Givens wrote:
>
>> Of course not.  The thing to remember is that different languages fit
>> different tasks, and different programmers are suited to different
>> languages.  I am a highly proficient C programmer, but only a 
moderately
>> skilled Ada programmer.  In fact, I often rough out algorythms in C
>> before implementing them in the Ada version.  Why?  Because I don't 
have
>> to think so much of the surface furnishings of Ada and can concentrate 
on
>> just the functionality.  It would save a lot of time if I didn't have 
to
>> write the Ada version, wouldn't it?
>
>That's amazing. Because I do the design in Ada, before coding in C/C++.
>I'm a skilled Ada-83 programmer, a tyro at -95, poor average at C (OK,
>average average, the average is pretty p*ss poor IMHO) and a neophyte 
at
>C++.

And that's my point.  What works well for one programmer doesn't work 
well for another.  Concerning us, what works for me is the exact opposite 
of what works for you.  So, forcing me to work with your method 
dramatically reduces my efficiency, and vice versa.

To reiterate my point again, each programmer is tempermentally fitted to 
one type of language, and that language is "best" for him.  Trying to 
determine if a language is "better" or "best" is subjective, and must 
take into account the task being attempted and the programmer who's 
working on it.

-
If at first you don't succeed, destroy all evidence that you ever tried. 
<< Iceman >>

Re: Any research putting c above ada?

[Andrew Dunstan]

Matthew Givens (NKSW39B@prodigy.com) wrote:

: Alan Brain <aebrain@dynamite.com.au> wrote:
: >
: >Matthew Givens wrote:
: >
: >> Of course not.  The thing to remember is that different languages fit
: >> different tasks, and different programmers are suited to different
: >> languages.  I am a highly proficient C programmer, but only a 
: moderately
: >> skilled Ada programmer.  

This is a worrying statement. If you are a skilled programmer, you
would pick up languages like a sponge and not be worried about small
things like syntax. If you think you are highly proficient in C but
only moderately skilled in Ada, either you have not done enough Ada or
you are not thinking about things at an appropriate level ... most of
your thought should be at a language independent level.

: >> In fact, I often rough out algorythms in C
: >> before implementing them in the Ada version.  Why?  Because I don't 
: have
: >> to think so much of the surface furnishings of Ada and can concentrate 
: on
: >> just the functionality.  It would save a lot of time if I didn't have 
: to
: >> write the Ada version, wouldn't it?
: >
: >That's amazing. Because I do the design in Ada, before coding in C/C++.
: >I'm a skilled Ada-83 programmer, a tyro at -95, poor average at C (OK,
: >average average, the average is pretty p*ss poor IMHO) and a neophyte 
: at
: >C++.

: And that's my point.  What works well for one programmer doesn't work 
: well for another.  Concerning us, what works for me is the exact opposite 
: of what works for you.  So, forcing me to work with your method 
: dramatically reduces my efficiency, and vice versa.

: To reiterate my point again, each programmer is tempermentally fitted to 
: one type of language, and that language is "best" for him.  Trying to 
: determine if a language is "better" or "best" is subjective, and must 
: take into account the task being attempted and the programmer who's 
: working on it.

If you work on a large software project, this is a recipe for
disaster. You can't just let programmers "do the thing that fits them
temperamentally". There must be standards etc. After all, the major
cost in most large s/w projects is not in initial coding but in
maintenance. This is where Ada shines - it is aimed at being easily
maintainable, easier on the reader at the cost of a little more trouble
to the writer. That's why many proigrammers hate it, of course, but is
the very reason that many more managers should love it.

cheers

andrew


--

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

Re: Any research putting c above ada?

[Matthew Givens]

amd001@its.maynick.com.au (Andrew Dunstan) wrote:
>
>
>This is a worrying statement. If you are a skilled programmer, you
>would pick up languages like a sponge and not be worried about small
>things like syntax. If you think you are highly proficient in C but
>only moderately skilled in Ada, either you have not done enough Ada or
>you are not thinking about things at an appropriate level ... most of
>your thought should be at a language independent level.

You don't really think that, do you?  Of all the programmers I know, none 
of them are equally skilled/comfortable in all the languages they know, 
amount of experience with each taken into consideration.  Again, that's 
because one (or more) is naturally easier for them to handle.  Can I 
program in Ada?  Yes, but not with the same ease that I can in C.

>
>If you work on a large software project, this is a recipe for
>disaster. You can't just let programmers "do the thing that fits them
>temperamentally". There must be standards etc. After all, the major
>cost in most large s/w projects is not in initial coding but in
>maintenance. This is where Ada shines - it is aimed at being easily
>maintainable, easier on the reader at the cost of a little more trouble
>to the writer. That's why many proigrammers hate it, of course, but is
>the very reason that many more managers should love it.

I never said anything about ignoring standards.  In fact, I always 
program to a set of standards, some of them industry and some of them 
mine.  But what does that have to do with the fact that many programmers 
work better in one language than another?


-
If at first you don't succeed, destroy all evidence that you ever tried. 
<< Iceman >>

Re: Any research putting c above ada?

[Andrew Dunstan]

Matthew Givens (NKSW39B@prodigy.com) wrote:

: amd001@its.maynick.com.au (Andrew Dunstan) wrote:
: >
: >
: >This is a worrying statement. If you are a skilled programmer, you
: >would pick up languages like a sponge and not be worried about small
: >things like syntax. If you think you are highly proficient in C but
: >only moderately skilled in Ada, either you have not done enough Ada or
: >you are not thinking about things at an appropriate level ... most of
: >your thought should be at a language independent level.

: You don't really think that, do you?  Of all the programmers I know, none 
: of them are equally skilled/comfortable in all the languages they know, 
: amount of experience with each taken into consideration.  Again, that's 
: because one (or more) is naturally easier for them to handle.  Can I 
: program in Ada?  Yes, but not with the same ease that I can in C.

Umm ... well ... yes, I do think that. All the good programmers I know
are competent in a substantial number of languages, and the language
they happen to be writing in makes little difference to the ease with
which they write code because they think about problems in a largely
language-independent way.

My sister used to teach English as a Second Language: she had a great
bumper sticker on her car that read: Monolinguism Is Curable. We ought
to adopt it as a motto in the computing world :-) I've programmed in
many laguages (gave up counting some years ago, the count was
somewhere in the 20s I think) and loved them all (well, nearly all, I
hated Basix and DCL). 

On the other hand, there is a lot to be said for a language that helps
you to avoid some (a lot?) of the mistakes that pretty well all
programmers make. The commonest errors (by far) that I have seen in
years of debugging other people's code (and some of my own) have been
pointer mismanagement and off-by-one errors in array processing. Ada
really does shine in helping you avoid these (as well as having many
other good points).


: >
: >If you work on a large software project, this is a recipe for
: >disaster. You can't just let programmers "do the thing that fits them
: >temperamentally". There must be standards etc. After all, the major
: >cost in most large s/w projects is not in initial coding but in
: >maintenance. This is where Ada shines - it is aimed at being easily
: >maintainable, easier on the reader at the cost of a little more trouble
: >to the writer. That's why many proigrammers hate it, of course, but is
: >the very reason that many more managers should love it.

: I never said anything about ignoring standards.  In fact, I always 
: program to a set of standards, some of them industry and some of them 
: mine.  But what does that have to do with the fact that many programmers 
: work better in one language than another?

Well, one of the standards on a project of any size is surely going
to be the language(s) used. This should NOT be decided on the basis of
programmer preference, IMHO. And what you state as a "fact" is a
highly debatable matter.

cheers

andrew

--

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

Re: Any research putting c above ada?

[Kevin Cline]

amd001@its.maynick.com.au (Andrew Dunstan) wrote:

>The commonest errors (by far) that I have seen in
>years of debugging other people's code (and some of my own) have been
>pointer mismanagement and off-by-one errors in array processing. Ada
>really does shine in helping you avoid these (as well as having many
>other good points).

How does Ada help you avoid the problem of managing dynamically allocated
memory?

Re: Any research putting c above ada?

[Jon S Anthony]

In article <DD2AAB2177A8804B.CD3498B59571A5AA.712C11BECD11BCCC@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> >The commonest errors (by far) that I have seen in
> >years of debugging other people's code (and some of my own) have been
> >pointer mismanagement and off-by-one errors in array processing. Ada
> >really does shine in helping you avoid these (as well as having many
> >other good points).
> 
> How does Ada help you avoid the problem of managing dynamically allocated
> memory?

Two obvious ways leap to mind.  First, pathological uninitialized
pointer behavior is not possible.  You just get constraint error and
in a debugger this plops you at the exact location of the goof.
Second, many places where in C/C++ you must use heap allocation just
go away altogether: functions can return objects of arbitrary size
(strings, records/structs, arrays of any sort, etc.)  Clearly, if you
don't need to use the heap you don't have management problems.

Now, if you really do need to use the heap (lots of threaded together
structures, CarCdr lists, etc., etc.)  Ada does not give you much
direct support for managing this stuff.  It does provide enough
indirect support (storage pools, generics, limited types, unknown
discriminants in client interface, etc.) for someone to construct
automated management of this stuff.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Jeff Carter]

Kevin Cline wrote:
> 
> amd001@its.maynick.com.au (Andrew Dunstan) wrote:
> 
> >The commonest errors (by far) that I have seen in
> >years of debugging other people's code (and some of my own) have been
> >pointer mismanagement and off-by-one errors in array processing. Ada
> >really does shine in helping you avoid these (as well as having many
> >other good points).
> 
> How does Ada help you avoid the problem of managing dynamically allocated
> memory?
Well, let's suppose you have a text file with N+1 lines, where N is not
known until run time. The 1st line is the string representation of an
integer (>= 0), N. The remaining N lines contain strings of varying
lengths.

In C, for example, I think you would have to read the value of N,
dynamically allocate an array of N pointers to char, then read each
string and dynamically allocate space for it pointed to by the
appropriate pointer in the array. You would also be responsible for
correctly deallocating this space when you are finished with it.

I don't have a great deal of C experience, so please pardon any errors I
have made. The important point is that this must involve explicit
allocation and deallocation.

In Ada (even Ada 83), no explicit allocation and deallocation is
required:

function Get_Line (File : Text_Io.File_Type) return String;

Text_Io.Create (File => File, ...

declare
   Image     : constant String  := Get_Line (File);
   Num_Lines : constant Natural := Natural'Value (Image);

   Line : array (1 .. Num_Lines) of Variable_String;
begin
   Read : for I in Line'range loop
      Line (I) := To_Variable_String (Get_Line (File) ):
   end loop Read;

   Text_Io.Close (File => File);

   -- use Line
end;

In Ada 83, you have to provide your own variable-length strings, which
would have to be bounded to provide automatic deallocation. In Ada, you
can use Ada.Strings.Bounded or Ada.Strings.Unbounded.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <DD2AAB2177A8804B.CD3498B59571A5AA.712C11BECD11BCCC@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

  > How does Ada help you avoid the problem of managing dynamically
  > allocated memory?

   First, many of the calls to malloc and free in C and C++ just go
away, since a lot of the allocations that have to be done on the heap
in C end up on the stack in Ada.  The most obvious example is that a
function can return an unconstrained array without the programmer
putting it in the heap.  The compiler may or may not use the
heap--most prefer to play games with the stack or to have two
stacks--but that is an implementation detail, and there is no
(programmer) risk of memory leaks or invalid pointers.

   Second, another bunch of calls goes away because you can have
objects of arbitrary size on the stack.  Once allocated, the size is
set, but that is what is usually wanted:

     Buffer: String := My_IO.Get(Some_Terminal);

   The size of the buffer is determined by the return value of Get.
You can assign to Buffer if you want, but you can't change the size.

   Third, there is a garbage collected, or somehow managed, dynamic
string type in Ada:

    use Ada.Strings.Unbounded;
    ...
    Buffer: Unbounded_String;
    ...
    while not My_IO.End_Of_File(Foo) loop
      Buffer := To_Unbounded_String(My_IO.Get_Line(Foo));
       ....
    end loop;

    In this example, the length of Buffer changes each time through
the loop, but again the programmer doesn't have to manage any pointers,
allocation, or deallocation.

    If you get this far, and still can't solve your problem, there are
hundreds of abstract data types that do their own storage management
using package Finalization so that users never need worry.

    So the only poor sods who ever have to worry about managing memory
in Ada 95 are probably the students taking a data structures course in
Ada, and people like me who build ADTs to share.  But I have gotten to
the point where the management of memory is about sixteenth on the
list of things to consider when implementing an abstraction--it really
is that easy to do things so that the memory management is invisible
to the user.  Of course some of the results are a bit surprising--I
often find that the type with the (implicitly called) Finalize
procedure is not the type which is allocated on the heap, but that is
and should be an implementation detail.  Of course, for Ada 0y, I may
propose Controlled access types, just to clean up some of the
notation, but that just saves a few characters per reference in the
source code. ;-)



--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Kevin Cline]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>In article <DD2AAB2177A8804B.CD3498B59571A5AA.712C11BECD11BCCC@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:
>
>  > How does Ada help you avoid the problem of managing dynamically
>  > allocated memory?
>
>   First, many of the calls to malloc and free in C and C++ just go
>away, since a lot of the allocations that have to be done on the heap
>in C end up on the stack in Ada.  The most obvious example is that a
>function can return an unconstrained array without the programmer
>putting it in the heap.  The compiler may or may not use the
>heap--most prefer to play games with the stack or to have two
>stacks--but that is an implementation detail, and there is no
>(programmer) risk of memory leaks or invalid pointers.

The last time I tried this, the compiler copied the entire array when the
function returned.  That much overhead was completely unexpected, and in my
case, also unacceptable.  I don't like languages that hide large amounts of
overhead in simple operations.  It's okay if they let me hide it through
operator overloading.  But I don't enjoy finding out when I port my program
that a function return is massively wasteful.  In C++, you would solve this
problem by passing a reference to a container.

>   Second, another bunch of calls goes away because you can have
>objects of arbitrary size on the stack.  Once allocated, the size is
>set, but that is what is usually wanted:
>
>     Buffer: String := My_IO.Get(Some_Terminal);
>
>   The size of the buffer is determined by the return value of Get.
>You can assign to Buffer if you want, but you can't change the size.
>
>   Third, there is a garbage collected, or somehow managed, dynamic
>string type in Ada:
>
>    use Ada.Strings.Unbounded;
>    ...
>    Buffer: Unbounded_String;
>    ...
>    while not My_IO.End_Of_File(Foo) loop
>      Buffer := To_Unbounded_String(My_IO.Get_Line(Foo));
>       ....
>    end loop;
>
>    In this example, the length of Buffer changes each time through
>the loop, but again the programmer doesn't have to manage any pointers,
>allocation, or deallocation.

No, but he will probably pay for the string to be copied twice, once upon
return from My_IO.Get_Line, and once in the conversion.

>    If you get this far, and still can't solve your problem, there are
>hundreds of abstract data types that do their own storage management
>using package Finalization so that users never need worry.
>
>    So the only poor sods who ever have to worry about managing memory
>in Ada 95 are probably the students taking a data structures course in
>Ada, and people like me who build ADTs to share. 

C++ is no different.  Allocation and deallocation can always be encapsulated.
What actually happens is that mediocre C++ programmers don't bother to
encapsulate.  In an Ada shop, mediocre programmers simply avoid dynamic
allocation, use lots of arrays, and hope they are big enough.  For embedded
systems, that's usually a reasonable approach.  For desktop applications, it
isn't.

Re: Any research putting c above ada?

[John G. Volan]

Kevin Cline wrote:
> 
> eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> 
> >   First, many of the calls to malloc and free in C and C++ just go
> >away, since a lot of the allocations that have to be done on the heap
> >in C end up on the stack in Ada.  The most obvious example is that a
> >function can return an unconstrained array without the programmer
> >putting it in the heap.  The compiler may or may not use the
> >heap--most prefer to play games with the stack or to have two
> >stacks--but that is an implementation detail, and there is no
> >(programmer) risk of memory leaks or invalid pointers.
> 
> The last time I tried this, the compiler copied the entire array when the
> function returned.  That much overhead was completely unexpected, and in my
> case, also unacceptable.  I don't like languages that hide large amounts of
> overhead in simple operations.  It's okay if they let me hide it through
> operator overloading.  But I don't enjoy finding out when I port my program
> that a function return is massively wasteful.  In C++, you would solve this
> problem by passing a reference to a container.

And promptly run into bizarre undefined behavior, because the container
whose reference you were returning happened to be one you declared
locally on the stack:

    MyContainer& MyClass::myFunction () const {
        MyContainer myContainer;
        ... // build value in myContainer
        return myContainer; // dangling reference returned after
destructor!!!
    }

or

    MyContainer* MyClass::myFunction () const {
        MyContainer myContainer;
        ... // build value in myContainer
        return &myContainer; // dangling pointer returned after
destructor!!!
    }


AFAIK, C++ compilers don't warn you about this. On the other hand,
Ada95's extensive rules about static accessibility levels guarantee that
this sort of thing won't happen, because it's illegal:

    type My_Container_Pointer_Type is access all My_Container_Type;

    function My_Function (This : in My_Class_Type)
      return My_Container_Pointer_Type
    is
      My_Container : aliased My_Container_Type;
    begin
      ... -- build value in My_Container
      return My_Container'Access; -- compiler error! My_Container too
deep!
    end My_Function;

Of course, if you know what you're doing in C++ (no small feat), you'll
be sure to return by value:

    MyContainer MyClass::myFunction () const {
        MyContainer myContainer;
        .. // build value in myContainer
        return myContainer;  // copy constructor called on return
    }

But this, while safe, yields the same efficiency concerns you raised
about Ada's copying-on-return:

    function My_Function (This : in My_Class_Type)
      return My_Container_Type
    is
      My_Container : My_Container_Type;
    begin
      ... -- build value in My_Container
      return My_Container; -- copy done on return
    end My_Function;       -- (and Adjust called if Controlled)

So now, if you _really_ know what you're doing, you could fall back on
using the heap:

    MyContainer* MyClass::myFunction () const {
        MyContainer *myContainer = new MyContainer;
        ... // build value in *myContainer
        return myContainer;
    }

The same can of course be done in Ada95:

    function My_Function (This : in My_Class_Type)
      return My_Container_Pointer_Type
    is
      My_Container : My_Container_Pointer_Type := new My_Container_Type;
    begin
      ... -- build value in My_Container.all
      return My_Container;
    end My_Function;

But then we're back where we started, doing our own heap management by
hand:

    {
        MyClass m1, m2, m3;
        MyContainer *c1 = m1.myFunction();
        MyContainer *c2 = m2.myFunction();
        MyContainer *c3 = m3.myFunction();

        ... 100 lines later

        delete c1;
        delete c2;
    }
    // oops! forgot c3! memory leak!

Of course, you can fall into the same trap in Ada95:

    declare
        procedure Deallocate is new Ada.Unchecked_Deallocation
          (My_Container_Type, My_Container_Pointer_Type);
        ...
        M1, M2, M3 : My_Class_Type;
        C1 : My_Container_Pointer_Type := My_Function(M1);
        C2 : My_Container_Pointer_Type := My_Function(M2);
        C3 : My_Container_Pointer_Type := My_Function(M3);
    begin
        ... 100 lines later

        Deallocate (C1);
        Deallocate (C2);
    end;
    -- oops! forgot C3! memory leak!

So don't turn your nose up so fast about the return-by-copy mechanism in
Ada95 (or in C++ for that matter). Sure, you lose some efficiency, but
you get a lot of safety from that!

[snip]
> >      Buffer := To_Unbounded_String(My_IO.Get_Line(Foo));
[snip]
> >    In this example, the length of Buffer changes each time through
> >the loop, but again the programmer doesn't have to manage any pointers,
> >allocation, or deallocation.
> 
> No, but he will probably pay for the string to be copied twice, once upon
> return from My_IO.Get_Line, and once in the conversion.

Probably, but I think it depends on the particular compiler and what
fancy optimizations it has. I believe a smart compiler can legally
eliminate one of these copies ... but I should let the compiler gurus
have the last word on this.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Any research putting c above ada?

[Kevin Cline]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>Kevin Cline wrote:

>> In C++, you would solve this
>> problem by passing a reference to a container.
>
>And promptly run into bizarre undefined behavior, because the container
>whose reference you were returning happened to be one you declared
>locally on the stack:
>
>    MyContainer& MyClass::myFunction () const {
>        MyContainer myContainer;
>        ... // build value in myContainer
>        return myContainer; // dangling reference returned after
>destructor!!!
>    }
>

I didn't say you would RETURN a reference to a container.
I said you would pass one.


>...So don't turn your nose up so fast about the return-by-copy mechanism in
>Ada95 (or in C++ for that matter). Sure, you lose some efficiency, but
>you get a lot of safety from that!

In C++, you would write something like:

  void Read_File_Lines(vector<string>& lines, istream& in)

Re: Any research putting c above ada?

[John G. Volan]

Kevin Cline wrote:
> 
> I didn't say you would RETURN a reference to a container.
> I said you would pass one.

I jumped into this thread a little late. But it looked like you said
this in a context where to were talking about extra copying happening on
return from a function...

> "John G. Volan" <johnvolan@sprintmail.com> wrote:
>
> >...So don't turn your nose up so fast about the return-by-copy mechanism in
> >Ada95 (or in C++ for that matter). Sure, you lose some efficiency, but
> >you get a lot of safety from that!
> 
> In C++, you would write something like:
> 
>   void Read_File_Lines(vector<string>& lines, istream& in)

You can most certainly do something analogous in Ada95:

   package Line_Vectors is new Vectors (Unbounded_String);

   procedure Read_File_Lines
     (Input_Stream : in out Input_Stream_Type; -- whatever that is
      Line_Vector  : in out Line_Vectors.Vector_Type);

Now, assuming that Vector_Type is either limited or tagged (or both),
you are guaranteed that it will be passed by reference, not by copy.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Any research putting c above ada?

[John G. Volan]

Kevin Cline wrote:
> 
> I didn't say you would RETURN a reference to a container.
> I said you would pass one.

I jumped into this thread a little late. But it looked like you said
this in a context where to were talking about extra copying happening on
return from a function...

> "John G. Volan" <johnvolan@sprintmail.com> wrote:
>
> >...So don't turn your nose up so fast about the return-by-copy mechanism in
> >Ada95 (or in C++ for that matter). Sure, you lose some efficiency, but
> >you get a lot of safety from that!
> 
> In C++, you would write something like:
> 
>   void Read_File_Lines(vector<string>& lines, istream& in)

You can most certainly do something analogous in Ada95:

   package Line_Vectors is new Vectors (Unbounded_String);

   procedure Read_File_Lines
     (Input_Stream : in out Input_Stream_Type; -- whatever that is
      Line_Vector  : in out Line_Vectors.Vector_Type);

Now, assuming that Vector_Type is either limited or tagged (or both),
you are guaranteed that it will be passed by reference, not by copy.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Any research putting c above ada?

[Alan Brain]

Kevin Cline wrote:

> I didn't say you would RETURN a reference to a container.
> I said you would pass one.

> In C++, you would write something like:
> 
>   void Read_File_Lines(vector<string>& lines, istream& in)

And in Ada-83 even, you just pass the parameter as an _in out_ , which
compilers will pass by reference rather than value.

You lose a bit in safety (forex the array being passed may be
unitialised, so may contain random garbage, which if read inside the
procedure will cause interesting results), but gain in efficiency, it's
a judgement call that will depend on circumstances.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Kevin Cline]

Alan Brain <aebrain@dynamite.com.au> wrote:

>Kevin Cline wrote:
>
>> I didn't say you would RETURN a reference to a container.
>> I said you would pass one.
>
>> In C++, you would write something like:
>> 
>>   void Read_File_Lines(vector<string>& lines, istream& in)
>
>And in Ada-83 even, you just pass the parameter as an _in out_ , which
>compilers will pass by reference rather than value.
>
>You lose a bit in safety (forex the array being passed may be
>unitialised, so may contain random garbage, which if read inside the
>procedure will cause interesting results), but gain in efficiency, it's
>a judgement call that will depend on circumstances.
>

This is useless when the size of the array required is computed inside the
function.  Some kind of dynamic data structure is required to write this code
with reasonable efficiency.

Re: Any research putting c above ada?

[Alan Brain]

Kevin Cline wrote:

> This is useless when the size of the array required is computed inside the
> function.  Some kind of dynamic data structure is required to write this code
> with reasonable efficiency.

Why so? Consider a variant record, ie a primitively polymorphic one such
as:

Type fooRecord (KindOfFoo : FooType := GreenFoo) is
record
  case KindOfFoo is
    when GreenFoo => -- blah blah blah
    when BlueFoo  => -- rhubarb rhubarb
    when other    => null;
  end case;
end record;

A variable of type fooRecord could be passed (via an in out) into a
procedure as a BlueFoo, and come out as a GreenFoo. This can be quite
astoundingly complex if, say, BlueFoo is a record of DEMONgrams (each of
which is an array of arrays whose size is variable), GreenFoo an array
of records containing arrays of records containing arrays of arrays 
whose size is fixed (as in a FRAZ spectrum analysis).

Simple really, and a real example. Nary a pointer or access type
anywhere. 


-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Dale Stanbrough]

Alan Brain writes:

"Ray Blaak wrote:
 > 
 > If this had happened when I was tutoring, I would have simply let the
student
 > hand in the missing part of the assignment again. The important thing
relevant
 > to the course is the work the student did. That students should read the
 > instructions is important, but not as important as the actual work.
 
 Similar thing happened to a student I was tutoring last month. He made a
 mistake, and so submitted the wrong file.
 I marked him on the latest version of his answer he had in his workspace
 before the deadline, easily retrievable."


I beg to differ. For students in 2nd and 3rd years (and _possibly_ 1st), 
following specs is an important skill to develop. Managing software is
an important skill, knowing when to sign off a piece of work....

An excellent 3rd year student who wrote a very good Motif program made
a change at the _very_ last minute _after_ testing his program thoroughly.
Of course it core dumped when i fed it an invalid input file. He got 
lower marks as a result, but at least he learnt that you don't make 
changes at the last minute.

There are all sorts of lessons to be learnt in a course, and not all of them
are about the simple concept of programming. If we do desire to have people
understand the ramifications of their actions, well then you have to expose
them to what can happen. I thought that this was a particuarly valuable SE
lesson for this student (who knew he knew how to program already).

Dale

Re: Any research putting c above ada?

[Kevin Cline]

Alan Brain <aebrain@dynamite.com.au> wrote:

>Simple really, and a real example. Nary a pointer or access type
>anywhere. 

Someone has to manage that storage.  Presumably in this case it is the
run-time library.  So the pointers exist in the generated code, even though
hidden from the user.

Re: Any research putting c above ada?

[John G. Volan]

Kevin Cline wrote:
> 
> Alan Brain <aebrain@dynamite.com.au> wrote:
> 
> >Simple really, and a real example. Nary a pointer or access type
> >anywhere.
> 
> Someone has to manage that storage.  Presumably in this case it is the
> run-time library.  So the pointers exist in the generated code, even though
> hidden from the user.

Nope, you're in the weeds here. A mutable record (discriminated record
with default initialization on the discriminant(s)) can be implemented
by simply providing it with enough space to house the largest possible
variant. It might not use all that space all the time, but it won't have
to allocate/reallocate anything.

Bottom line, if you declare one of these beasts in the ordinary way,
your Ada compiler can certainly allocate it on the stack, and pass it
back and forth on the stack.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Any research putting c above ada?

[Kevin Cline]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>Kevin Cline wrote:
>> 
>> Alan Brain <aebrain@dynamite.com.au> wrote:
>> 
>> >Simple really, and a real example. Nary a pointer or access type
>> >anywhere.
>> 
>> Someone has to manage that storage.  Presumably in this case it is the
>> run-time library.  So the pointers exist in the generated code, even though
>> hidden from the user.
>
>Nope, you're in the weeds here. A mutable record (discriminated record
>with default initialization on the discriminant(s)) can be implemented
>by simply providing it with enough space to house the largest possible
>variant. It might not use all that space all the time, but it won't have
>to allocate/reallocate anything.
>
>Bottom line, if you declare one of these beasts in the ordinary way,
>your Ada compiler can certainly allocate it on the stack, and pass it
>back and forth on the stack.

Of course, that's trivial to do, and extremely impractical if the object is
usually small but can occassionally be very large.   Remember the original
problem that started this thread?  The poster claimed that it was easy to
write a program that read a file into an array of lines since Ada allowed
arrays of size determined at run-time to be returned as function values.
The I pointed out that:

1. Most files do not begin with a line count.  That's certainly a ridiculous
requirement for manually prepared input.

2. Returning such an object is very inefficient because most compilers copy
the entire object.

Now you tell me that variable-length arrays can easily be handled in Ada
without dynamic storage allocation.  But then you indicate that the arrays are
not truly variable in size, but are restricted to a compiled-in maximum size.
That's fine for embedded applications where the amount of data to be handled
is carefully defined ahead of time.  It's useless for desk-top applications,
where the size of the data to be handled, and the physical resources available
to handle it vary widely from user to user.  For those applications, you must
resort to truly dynamic data structures, and Ada's arrays are of little use.

This is one of the biggest blind spots I observed in experienced Ada
programmers in a shop a few years ago.  Ada programmers tend to use arrays
instead of more dynamic data structures, resulting in inefficient and
inflexible applications.  OTOH, I have observed that the availability of the
C++ STL containers is already expanding the toolkit of average C++ developers.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <12871CEBFAB00ABE.93483F73373D0261.D1086334F6EF8ED8@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> problem that started this thread?  The poster claimed that it was easy to
> write a program that read a file into an array of lines since Ada allowed
> arrays of size determined at run-time to be returned as function values.
> The I pointed out that:

Just to stir things up a bit.  IMO, the only good way to handle this
sort of thing is with GC.  If you have that, the entire issue isn't
just solved, it becomes completely irrelevant.

> inflexible applications.  OTOH, I have observed that the
> availability of the C++ STL containers is already expanding the
> toolkit of average C++ developers.

Well, despite the unsupported claims of AS, STL could be implemented
in Ada95 without much problem.  In fact, the RPI people have a
reasonable first effort (though it adheres too much to the underlying
_implementation_ aspects of AS's C++ definition).

OTOH, there is really nothing in the STL that is all that interesting
IMO.  Yes, some think it is pretty cool achievement to have split the
container types and iterators so orthogonally.  That's kinda nice, but
has nothing to do with C++.  As for the rest of it: it's just the same
old stuff that's been done over and over again for the last 25+ years.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Brian Rogoff]

On 18 May 1997, Jon S Anthony wrote:
> In article <12871CEBFAB00ABE.93483F73373D0261.D1086334F6EF8ED8@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:
> > inflexible applications.  OTOH, I have observed that the
> > availability of the C++ STL containers is already expanding the
> > toolkit of average C++ developers.
> 
> Well, despite the unsupported claims of AS, STL could be implemented
> in Ada95 without much problem.  In fact, the RPI people have a
> reasonable first effort (though it adheres too much to the underlying
> _implementation_ aspects of AS's C++ definition).

	I don't think AS claimed that an STL like library couldn't be
implemented in Ada 95, just that Ada 83 was not up to the task. In fact, 
I remember him writing that Ada 95 is much better for this.

	I agree with you about the current RPI implementation. I've been 
rewriting a that library, and one of the few things I found really weird 
was that the Random_Access_Iterators generic signature package uses
Ptrdiff_T directly. Still, it succeeds as a proof of concept, though it is 
missing quite a bit.

> OTOH, there is really nothing in the STL that is all that interesting
> IMO.  Yes, some think it is pretty cool achievement to have split the
> container types and iterators so orthogonally.  That's kinda nice, but
> has nothing to do with C++.  As for the rest of it: it's just the same
> old stuff that's been done over and over again for the last 25+ years.

	The power of something like the STL is mostly that it is widely
used, and hopefully not awful for many tasks. By having an Ada "work
alike" for this library, people who use C++ as well as Ada have a
little less of a learning curve to climb. Note that the JGL, Java Generic 
Library (yeah right!) is purposely crafted to be similar to the STL 
too.

	FWIW, I think the STL (AGL really) works fine in Ada 95, the only 
burden for C++ programmers might be those long instantiations (C++ does 
implicit instantiation) and C++ template partial specialization. 

-- Brian

Re: Any research putting c above ada?

[Kevin Cline]

jsa@alexandria (Jon S Anthony) wrote:

>In article <12871CEBFAB00ABE.93483F73373D0261.D1086334F6EF8ED8@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:
>
>> problem that started this thread?  The poster claimed that it was easy to
>> write a program that read a file into an array of lines since Ada allowed
>> arrays of size determined at run-time to be returned as function values.
>> The I pointed out that:
>
>Just to stir things up a bit.  IMO, the only good way to handle this
>sort of thing is with GC.  If you have that, the entire issue isn't
>just solved, it becomes completely irrelevant.

No question about that, but it says nothing about the usefulness of Ada arrays
for solving this problem.

>
>> inflexible applications.  OTOH, I have observed that the
>> availability of the C++ STL containers is already expanding the
>> toolkit of average C++ developers.
>
>Well, despite the unsupported claims of AS, STL could be implemented
>in Ada95 without much problem.  

Never said it couldn't be done.  But it hasn't been done yet.

>OTOH, there is really nothing in the STL that is all that interesting
>IMO.  

To me, the best thing about STL is that it makes it easier for programmers to
select appropriate data structures without having to search the net for PD
stuff, or evaluate vendors of commercial stuff.  It's all right there in the
language, and eliminates the temptation to just use an array.

Re: Any research putting c above ada?

[Jon S Anthony]

In article <E4449B1A3DAD7582.8EEEBAFA93AAAE0F.44F98E52931FC8AF@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> >Just to stir things up a bit.  IMO, the only good way to handle this
> >sort of thing is with GC.  If you have that, the entire issue isn't
> >just solved, it becomes completely irrelevant.
> 
> No question about that, but it says nothing about the usefulness of
> Ada arrays for solving this problem.

True enough...

> >Well, despite the unsupported claims of AS, STL could be implemented
> >in Ada95 without much problem.  
> 
> Never said it couldn't be done.  But it hasn't been done yet.

Actually, he _has_ made this claim.  In fact, he recently made the
even more wog boggling claim that it could not be implemented in any
language _but_ C++.  Of course, when several people called him on
this, he could not support this rather wild claim.

And the RPI people have basically done the STL, in the sense that all
the bases are covered, but it needs to be brought up to a complete
implementation.  Brian Rogoff says he is redoing it along these lines.


> >OTOH, there is really nothing in the STL that is all that interesting
> >IMO.  
> 
> To me, the best thing about STL is that it makes it easier for
> programmers to select appropriate data structures without having to
> search the net for PD stuff, or evaluate vendors of commercial
> stuff.  It's all right there in the language, and eliminates the
> temptation to just use an array.

I suppose.  But to be honest, this is really one big jumbo *yawn*...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[John G. Volan]

Kevin Cline wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> wrote:

[referring to a "mutable" discriminated record with default constraint
on the discriminant]

> >Bottom line, if you declare one of these beasts in the ordinary way,
> >your Ada compiler can certainly allocate it on the stack, and pass it
> >back and forth on the stack.
> 
> Of course, that's trivial to do, and extremely impractical if the object is
> usually small but can occassionally be very large.   Remember the original
> problem that started this thread?  

Actually, no, sorry, jumped in late...

> The poster claimed that it was easy to
> write a program that read a file into an array of lines since Ada allowed
> arrays of size determined at run-time to be returned as function values.
> The I pointed out that:
> 
> 1. Most files do not begin with a line count.  That's certainly a ridiculous
> requirement for manually prepared input.
> 
> 2. Returning such an object is very inefficient because most compilers copy
> the entire object.
> 
> Now you tell me that variable-length arrays can easily be handled in Ada
> without dynamic storage allocation.  But then you indicate that the arrays are
> not truly variable in size, but are restricted to a compiled-in maximum size.

More precisely, they are, in fact, "variable" in size, but "bounded".  I
see now that you're looking for a solution that is "unbounded".  The
only alternatives are:

(1) Use an "indefinite" type and return and instance on the stack (but
this might involve extra copying):

   (a) The "indefinite" type could be an unconstrained array type, with
the bounds on the actual instance not determined until runtime.

   (b) The "indefinite" type could be a discriminated record type
(_without_ a default constraint), with the discriminant constraint on
the instance not determined until runtime.

(2) Develop an "unbounded" abstract data type (which, as you rightly
assert, must entail using some kind of storage pool, perhaps the global
"heap", perhaps some programmer-defined pool).

> That's fine for embedded applications where the amount of data to be handled
> is carefully defined ahead of time.  It's useless for desk-top applications,
> where the size of the data to be handled, and the physical resources available
> to handle it vary widely from user to user.  For those applications, you must
> resort to truly dynamic data structures, and Ada's arrays are of little use.

Of course, but what were you expecting? The semantic level of Ada95 is
comparable to that of C++, and neither language was designed to include
the kind of unbounded ADTs you're looking for -- at least, not as
built-in features of the language.  Rather, these languages provide the
raw materials from which such ADTs might be constructed.  A standard
library might contain such examples as Ada.Strings.Unbounded in Ada95
and the STL in C++, but these components are _written in_ the given
language, not _built into_ the language (i.e., implemented with compiler
support).

(Even in a language like Smalltalk, which routinely comes with unbounded
ADTs such as sets, bags, ordered collections, and the like, these ADTs
are not "built-in" any more than they are in Ada95 or C++. At least, not
in the sense that a Smalltalk compiler knows anything about them. 
Rather, they're part of the standard class library, and are written _in_
Smalltalk.)

> This is one of the biggest blind spots I observed in experienced Ada
> programmers in a shop a few years ago.  Ada programmers tend to use arrays
> instead of more dynamic data structures, resulting in inefficient and
> inflexible applications.  

This observation is not necessarily universal of all Ada programmers.

> OTOH, I have observed that the availability of the
> C++ STL containers is already expanding the toolkit of average C++ developers.

There's nothing about the STL containers that couldn't be done in Ada95
-- probably much more simply, and thus, IMHO, better. (I myself have
re-engineered the RBTree/Set/Map structures in Ada95 for my own
purposes, it really wasn't very hard to get the basic functionality.) 
The advantange of the STL in C++ is that someone has gone to the trouble
of working it up as a "standard" toolkit, and the general C++ user
community is accepting it as such.  It would be nice of someone could
produce a comparable library of such tools in Ada95 and make them widely
available.  There's no technical obstacle to this, only an
economic/cultural one: i.e., we need to get someone to actually do the
work, and the Ada95 community needs to recognize the result as some kind
of "standard,"  official or otherwise.
 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Any research putting c above ada?

[Kevin Cline]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>> That's fine for embedded applications where the amount of data to be handled
>> is carefully defined ahead of time.  It's useless for desk-top applications,
>> where the size of the data to be handled, and the physical resources available
>> to handle it vary widely from user to user.  For those applications, you must
>> resort to truly dynamic data structures, and Ada's arrays are of little use.
>
>Of course, but what were you expecting? The semantic level of Ada95 is
>comparable to that of C++, and neither language was designed to include
>the kind of unbounded ADTs you're looking for -- at least, not as
>built-in features of the language.  Rather, these languages provide the
>raw materials from which such ADTs might be constructed.  A standard
>library might contain such examples as Ada.Strings.Unbounded in Ada95
>and the STL in C++, but these components are _written in_ the given
>language, not _built into_ the language (i.e., implemented with compiler
>support).

That's exactly what I was expecting.  This thread has gotten away from the
post I originally replied to.  That post essentially said that Ada's arrays
were vastly superior to C arrays because in Ada one could write a function
that would read a line count, then declare an array of strings of that size,
read the lines into the array, and then return that array.  All I wanted to do
was point out that:

1.  It's a silly example.
2.  Generally the entire array has to be deep-copied to be returned, so the
return statement from that function hides a whole lot of overhead that will
surprise many programmers.  I don't know about the Ada'95 ARM, but I think the
Ada'83 ARM should have contained some comment on this.

Still, it IS nice to be able to declare temporary arrays on the stack that
have a size declared at run-time.  I don't know if such code actually runs
faster than code that allocates the array on the heap and then frees it, but
it's easier to write.

>> This is one of the biggest blind spots I observed in experienced Ada
>> programmers in a shop a few years ago.  Ada programmers tend to use arrays
>> instead of more dynamic data structures, resulting in inefficient and
>> inflexible applications.  
>
>This observation is not necessarily universal of all Ada programmers.

Of course it isn't.  That is why I was careful to specify the extent of my
observation.

>> OTOH, I have observed that the availability of the
>> C++ STL containers is already expanding the toolkit of average C++ developers.
>
>There's nothing about the STL containers that couldn't be done in Ada95
>-- probably much more simply, and thus, IMHO, better. 

It's hard to say until it's been done.  I think the lack of automatic
instantiation in Ada will make any such library somewhat more cumbersome to
use than the C++ STL.

>The advantange of the STL in C++ is that someone has gone to the trouble
>of working it up as a "standard" toolkit, and the general C++ user
>community is accepting it as such. 

Precisely.  This relative slowness of the Ada community in agreeing on such
standards was one of the biggest factors that prevented Ada'83 from being more
widely adopted.

>There's no technical obstacle to this, only an economic/cultural one.

"More projects fail due to sociological reasons than technical ones"
Tom DeMarco, Peopleware

Re: Any research putting c above ada?

[Jeff Carter]

Kevin Cline wrote:
...
> That's exactly what I was expecting.  This thread has gotten away from the
> post I originally replied to.  That post essentially said that Ada's arrays
> were vastly superior to C arrays because in Ada one could write a function
> that would read a line count, then declare an array of strings of that size,
> read the lines into the array, and then return that array.  All I wanted to do
> was point out that:
...

That's not quite correct, as I posted the example. I was replying to a
request (possibly from you) for an example in which explicit
allocation/deallocation was required in C (not C++) and not required in
Ada. I provided such an example. It happened to use arrays, but did not
make any claims about C arrays vs. Ada arrays. I did not claim that it
was a realistic example; in fact it was unrealistic, but I chose it as
easy to understand.

In real life, I frequently use nested scopes in Ada to create
dynamically sized objects without explicit allocation/deallocation.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Any research putting c above ada?

[Brian Rogoff]

On Mon, 19 May 1997, John G. Volan wrote:
> Kevin Cline wrote:
> > OTOH, I have observed that the availability of the
> > C++ STL containers is already expanding the toolkit of average C++ developers.
> 
> There's nothing about the STL containers that couldn't be done in Ada95
> -- probably much more simply, and thus, IMHO, better. (I myself have
> re-engineered the RBTree/Set/Map structures in Ada95 for my own
> purposes, it really wasn't very hard to get the basic functionality.) 

Same here. It is even possible to program at the same "low-level" as the 
C++ STL by using Interfaces.C. OTOH, I agree with Kevin Cline that the 
type inferencing done in C++ is convenient, and that a C++ programmer might 
find the long declarations troubling, especially for textbook examples
where the length of the working code is close to the length of the
declaration section. I suspect that this will be less of a problem in 
most real code.

> The advantange of the STL in C++ is that someone has gone to the trouble
> of working it up as a "standard" toolkit, and the general C++ user
> community is accepting it as such.  It would be nice of someone could
> produce a comparable library of such tools in Ada95 and make them widely
> available.  There's no technical obstacle to this, only an
> economic/cultural one: i.e., we need to get someone to actually do the
> work, and the Ada95 community needs to recognize the result as some kind
> of "standard,"  official or otherwise.

I'm "evolving" a version for my own use. I am trying to stay as close to 
the C++ STL as possible, but I've left out custom allocators (still
experimenting) and I'm starting to diverge in that I'd prefer a more 
integrated approach to exceptions in the library, more like Cay Horstmann's 
Safe STL. The two languages and their respective programming cultures are
different enough that the the design priorities in the source library (C++ 
STL) will differ a bit. 

One thing I wish I could do better is have the structure of Iterator
categories reflected in the Ada code. In the STL, Forward_Iterators 
have properties of both Input_Iterators and Output_Iterators, i.e.

generic
    type Value_Type is private;
    type Iterator_Type is private;
    with procedure Next ( i: in out Iterator_Type ) is <>;
    with function  Get_Value ( i: in Iterator_Type ) return Value_Type is
<>;
package AGL.Input_Iterators is
end AGL.Input_Iterators;

generic
    type Value_Type is private;
    type Iterator_Type is private;
    with procedure Next ( i: in out Iterator_Type ) is <>;
    with procedure Set_Value ( I: in Iterator_Type; V: Value_Type) is <>;
package AGL.Output_Iterators is
end AGL.Output_Iterators;

generic
  type Value_Type is private;
  type Iterator_Type is private;
  type Value_Ptr is access all Value_Type;
  with procedure Next ( I: in out Iterator_Type ) is <>;
  with function Get_Value ( I: in Iterator_Type ) return Value_Type is <>;
  with procedure Set_Value ( I: in Iterator_Type; V: Value_Type) is <>;
  with function Get_Pointer ( I: in Iterator_Type ) return Value_Ptr is <>;
  with function "="( I: Iterator_Type; J: Iterator_Type ) return Boolean is
<>;
package AGL.Forward_Iterators is
end AGL.Forward_Iterators;

Now, I could just define Forward_Iterators by having two generic package 
parameters, but then I'd have to instantiate an Input/Output Iterator pair 
every time I wanted a Forward_Iterators package. Right now I just leave 
this commonality in the documents, and express each Iterator independently.

-- Brian

Re: Any research putting c above ada?

[Alan Brain]

John G. Volan wrote:

> Kevin Cline wrote:

> > This is one of the biggest blind spots I observed in experienced Ada
> > programmers in a shop a few years ago.  Ada programmers tend to use arrays
> > instead of more dynamic data structures, resulting in inefficient and
> > inflexible applications.

Agree strongly that Ada programmers tend to use (fixed size) arrays
rather than more dynamic data structures.

If you know that at some time you're going to need X items, and never
will need more than X, then IMHO it's very wise to have a fixed-length
table or other data storage area catering for the worst-case. Unless
you're dealing with text, strings etc this is true 99% or more of the
time (at least in the problem domains I've worked with for 15 years),
and means you never have to worry about memory leaks, running out of
heap space during run-time in an unpredictable way etc etc.

But the "resulting in inefficient and inflexible applications" bit does
not, as they say, neccessarily follow. Space innefficient - maybe. There
is a case for that. But consider how much space you'll be using putting
in all the checks on a dynamic structure, the memory fragmentation, the
additional garbage collection load etc, so "it's not that simple". The
brain-dead fixed-size array is actually very efficient for small and
non-sparse arrays, which is the case most of the time (at least, in the
problem domains I'm familiar with).
As for inflexible - which is better, changing a single constant (and
possibly  seeing the resultant program not be loadable because there
isn't enough space left)  or making no change, no re-compile but having
coredumps in whole new places due to memory leaks at run-time, even if
there IS enough space? Which is easier to debug? The former. Which is
easier to ship? The latter.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <3372D44E.5F44@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

  > So don't turn your nose up so fast about the return-by-copy mechanism in
  > Ada95 (or in C++ for that matter). Sure, you lose some efficiency, but
  > you get a lot of safety from that!

  I strongly agree.  First get it working correctly--and that means no
memory leaks--then, if necessary force low-level optimizations for
efficiency.  If you have a good compiler, you may be pleasantly
surprised by the areas where you don't have to do any additional work.

  > Probably, but I think it depends on the particular compiler and
  > what fancy optimizations it has. I believe a smart compiler can
  > legally eliminate one of these copies ... but I should let the
  > compiler gurus have the last word on this.

  The last word from a compiler guru is that if you have a good
compiler and it misses an (obvious to you transformation) there is
probably some reason you are unaware of why that optimization is not
correct.  And even if a compiler guru sees an obvious missing
transformation, he will often discover that it was either left out as
not useful or as less important than some other case.  (I once had one
of these where we really had a problem.  The correct optimization for
well written code prevented an optimization that was much more
important if the code was junk.  In paticular hoisting invariants out
of loops was a big win on "junk" code, but it was preventing some
useful strength reductions.  We put a switch in the compiler,
documented it, and left it at that.)

   But back to the "obvious" to non-gurus transformations of unbounded
function return values.  Many of these transformations work well in
the absence of threads or tasking, but not so well in the real world
that code runs in.  It is perfectly fair to tell a user that the code
doesn't work because he failed to mark something as volatile or
neglected the possibility of a race condition.  However it gets you a
very bad reputation if the compiler introduces race conditions
involving varibles unknown to the user.

   Whew!  Having said all that, suppose the compiler sees a function
returning a string.  Allocating that string on the heap will require
sychronization unless the implementation supports per task heaps, or
the user has told the compiler to ignore tasking and threads.  Copying
the string will be slow for large strings but will be faster than
using heap returns for strings up to about 138 characters.  (YMMV and
probably will, but if you can avoid tasking overhead and the string is
in cache, the number gets pretty large.) 

  Attaching the stack frame above the string to its parent's frame is
fastest--but you can only do that if the nested function call can be
shown to occur a limited number of times in the parent.  The average
number of characters returned per call over a large sample of code is
say 38.  So you decide to do the stack frame munging where it can be
shown to be safe and otherwise copy the value.  Note that you can't do
the stack frame munging if you always return strings on the heap.

   Now a bug report comes in from the field containing a fragment
like:

   function Tail(S: String; I: Integer) return String is
   begin return S(I..S'Last); end Tail;

   function Is_Blank(S: String) return Boolean is 
   begin return S := String'(others => ' '); end Is_Blank;
   ...

   Big: String(1..10000);
   
   for I in Big'Range loop
     Do_Something;
     exit when Is_Blank(Tail(S,I));
   end loop;

   Believe me, your most likely response is not to add this fragment
to your statistical database. ;-)   (There is no resemblence between
this code and any actual incident.  You would throw up if you saw the
original code which was in Pascal...)

   Similarly, we once had a "performance problem" on the same Pascal
compiler.  Seemed the highest optimization level thrashed on an 8000
line subroutine doing common subexpression elimination.  Yes it did.
And after eight hours on a fast CPU, it produced a > 8 Kbyte object
file.  The next lowest optimization level produced a 250 Kbyte
executable which the customer complained was too big.  We eventually
convinced him to upgrade his memory to solve the thrashing problem.
Sigh!  
--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Daniel P Hudson]

amd001@its.maynick.com.au (Andrew Dunstan) wrote:
>Matthew Givens (NKSW39B@prodigy.com) wrote:

>This is a worrying statement. If you are a skilled programmer, you
>would pick up languages like a sponge and not be worried about small

That's like saying if you are a skilled speaker you should be able
to pick up languages [German, Russian, Greek] like a sponge.

>things like syntax. If you think you are highly proficient in C but
>only moderately skilled in Ada, either you have not done enough Ada or
>you are not thinking about things at an appropriate level ... most of
>your thought should be at a language independent level.

Well, can you pick up things is say Korean or Vietnamese right now?
So then are you not thinking about things at an appropriate level?

>If you work on a large software project, this is a recipe for
>disaster. You can't just let programmers "do the thing that fits them
>temperamentally". There must be standards etc. After all, the major
>cost in most large s/w projects is not in initial coding but in
>maintenance. This is where Ada shines - it is aimed at being easily
>maintainable, easier on the reader at the cost of a little more trouble
>to the writer. That's why many programmers hate it, of course, but is
>the very reason that many more managers should love it.

Yes and no. A lot of software is designed to be ported, and this is 
where C/C++ shines. A lot of software is designed to be effecient
or interface new hardware to the system, this is where asm shines.
Every langauge shines somewhere, even if it is where the sun don't.

Re: Any research putting c above ada?

[Adam Beneschan]

afn03257@freenet2.afn.org (Daniel P Hudson) writes:
 >amd001@its.maynick.com.au (Andrew Dunstan) wrote:
 >>Matthew Givens (NKSW39B@prodigy.com) wrote:
 >
 >>This is a worrying statement. If you are a skilled programmer, you
 >>would pick up languages like a sponge and not be worried about small
 >
 >That's like saying if you are a skilled speaker you should be able
 >to pick up languages [German, Russian, Greek] like a sponge.
 >
 >>things like syntax. If you think you are highly proficient in C but
 >>only moderately skilled in Ada, either you have not done enough Ada or
 >>you are not thinking about things at an appropriate level ... most of
 >>your thought should be at a language independent level.
 >
 >Well, can you pick up things is say Korean or Vietnamese right now?
 >So then are you not thinking about things at an appropriate level?

Sorry, but this analogy doesn't fly.  You just can't compare human
languages to computer languages, for a number of reasons:

(1) Human language is not learned by studying it in a classroom and
    poring over the concepts behind it.  Human language is learned
    from hearing it from the time one is born (possibly before) and
    learning to imitate it. 

(2) Experts have been finding out that there is "preprogrammed
    software" in our brains that enables us to learn to understand and
    speak human languages.  (Newsweek's current special issue on child
    care has a fascinating article about this.)  You can't say the
    same about computer languages.

(3) There seem to be neurological barriers to picking up new languages
    easily after a certain age.  I've heard it said a number of times
    that if you want your child to be multilingual, you should start
    using the second language before such-and-such an age (six?),
    because after that new languages get harder to learn.  Also, I've
    been told that if one doesn't learn certain vowels or consonants
    by a certain age, one will *never* be able to pronounce those
    sounds quite correctly.  Thus, you and I will probably never be
    able to speak Xhosa (which has clicking sounds as some of its
    consonants) and have everything sound right, although we could
    learn it well enough to make ourselves understood.

                                -- Adam

Re: Any research putting c above ada?

[Daniel P Hudson]

adam@irvine.com (Adam Beneschan) wrote:
>afn03257@freenet2.afn.org (Daniel P Hudson) writes:
> >amd001@its.maynick.com.au (Andrew Dunstan) wrote:
> >Well, can you pick up things in say Korean or Vietnamese right now?
> >So then are you not thinking about things at an appropriate level?

>Sorry, but this analogy doesn't fly.  You just can't compare human
>languages to computer languages, for a number of reasons:

>(1) Human language is not learned by studying it in a classroom and
>    poring over the concepts behind it.  Human language is learned
>    from hearing it from the time one is born (possibly before) and
>    learning to imitate it. 

I learned Spanish in a classroom, don't remember any of it because 
I don't use it, but then again I don't remember any of my Pascal
teachings either. BTE, if you didn't really learn English in a 
classroom you would not know it either, you MIGHT be able to speak
it well enough to communicate, but you would not be using the
English language as it is defined. Programming and spoken/written 
languages are learned as rules[grammar] and words [vocabulary]
and then applying those rules in usage of the words.

"I do be here but be gone later" is 100% English, and also the way 
many poeple talk, but it is not properly used English which would be
"I am here now, but I will be gone later".

>(2) Experts have been finding out that there is "preprogrammed
>    software" in our brains that enables us to learn to understand and
>    speak human languages.  (Newsweek's current special issue on child
>    care has a fascinating article about this.)  You can't say the
>    same about computer languages.

No, experts have determined there is a center of out brain which 
learns speech paterns [syllables], after infancy you have the ability 
to produce all sounds, but soon [age 3-5] you limit yourself to what your 
parents use [what you hear]. However, that location is NOT responcible 
for the mental imaging of of words we develop, nor it is responcible for 
spelling, grammar, or using the words to form a sentence. If you don't 
talk to your child [or someone else] it will never speak, just as deaf 
children who actually never limit the syllable usage don't learn to 
speak, I'm referring to people *born* deaf, BTW.

>(3) There seem to be neurological barriers to picking up new languages
>    easily after a certain age.  I've heard it said a number of times
>    that if you want your child to be multilingual, you should start
>    using the second language before such-and-such an age (six?),

Age one, but that's only true for languages which use sylables we do 
not use, it is not true for ALL langauges.

The analogy holds true because you will not gain a "GOOD" understanding
of another spoker/written language unless you "USE" it a lot.

Spanish is not hard for Americans to learn, and when I used to visit
Miami, I used it quite well. Now I don't know anyone who speaks it,
nor do I visit Miami, so I have forgotten most of it. The same holds 
true for Programming languages. I used to know Pascal, but have not 
used it in Ooh, 5 years I suppose, thus I couldn't debug a Pascal src 
file to save my life right now. Before I continue, I did not learn 
Spanish until my Jr. high school year which was age, 16 I believe.

Learning a language does not even necessaruly involve proper 
pronounciation, just listen to a Brittish and an American talk
for a while, you'll hear 15 variations of the same word eventually.

The mere fact that you think you could pick up any language because
you understand theory is just wrong. You could use any langauge,
with a reference manual handy, but you, nor I, could go pick up, 
let's say, Occam [something few people are familair with] and just 
start coding like we could in the languages we use from day to day 
unless it was a very small language, maybe a scripting language 
like MSDOS BATCH or something.

Re: Any research putting c above ada?

[Peter Amey]

On 15 Apr 1997, Tom White wrote:

> I remember a Turing Award Lecture by C.A.R. Hoare from the early
> eighties (dig through some Journals of the ACM).  Hoare was not
> an Ada booster; he was concerned about the complexity of Ada from
> both the application programmer's and compiler implementor's
> perspectives.
> 
> As to your second point, Hoare was accepting the award :)
> 
> -- 
> -- Tom White <tom@net.msstate.edu>
> 

A quote from this 1980 lecture includes the following: 

"It is not too late!  I believe that by careful pruning of the Ada
language, it is still possible to select a very powerful subset that would
be reliable and efficient in implementation and safe and economic in use". 

This was part of the inspiration for SPARK, our formally-defined, 
tool-supported, secure SPARK subset.  

There is another important point here as well: the difference between Ada
and most other languages is not just the detail of whether incompatible
types can be coerced or whether run-time checks are turned on or off by
default.  Rather it is that Ada makes a serious attempt to define the
semantics of the language under all conditions including those where
errors have occurred.  This gives the desirable (essential?) property that
the meaning of a program can be determined by looking at the source code
(especially if it is SPARK) rather than by reviewing the test results :-)

This property of Ada is what makes secure subsets feasible (and the nice
things that follow from this - like being able to construct a proof, prior
to execution, that a SPARK program is exception free).  It would not be
possible to define a subset of C that had all SPARK's properties because
after cutting away the ambiguity and insecurity what would be left would
be too small to be useful. 

Peter

Re: Any research putting c above ada?

[Suzette Norby]

Daniel P Hudson wrote:
> 
> Peter Amey <pna@erlang.praxis-cs.co.uk> wrote:
> >On 15 Apr 1997, Tom White wrote:
> 
> >> I remember a Turing Award Lecture by C.A.R. Hoare from the early
> >> eighties (dig through some Journals of the ACM).  Hoare was not
> >> an Ada booster; he was concerned about the complexity of Ada from
> >> both the application programmer's and compiler implementor's
> >> perspectives.
> 
> [SNIP]
> 
> >A quote from this 1980 lecture includes the following:
> 
> [SNIP]
> 
> Jeez, he had to go back 17 years to find something wrong with Ada.
> You know what 17 years does to a language? That's 2 years before
> the ANSI X3J11 sub-commitee for C was even formed. We could kill the
> C that was used back then. But who cares what the problems with Ada
> or C were back then, they are long gone by now.
> 
> Perhaps you would like to suffer through a list of problems with
> C from 1980 bit I wouldn't. Why don't you try keeping the
> factual criticisms within at least this decade if not the past
> couple of years.

It was also 3 years before the _first_ Ada standard.

Since we're strolling down memory lane, let's go back a few more 
years.  The following, explaining why C was not even considered as 
a candidate to be the common language, is quoted from "Ada - The 
Project, The DoD High Order Language Working Group", copyright 1993, 
which was originally published in ACM SIGPLAN Notices (Vol. 28, No. 
3, March 1993).**

     ** Permission to copy without fee all or part of this material 
        is granted provided that the copies are not made or 
        distributed for direct commercial advantage, this ACM 
        copyright notice and the title of the publication and its 
        date appear, and notice is given that copying is by 
        permission of the Association for Computing Machinery. To 
        copy otherwise, or to republish, requires a fee.

(Complete text available at "http://sw-eng.falls-church.va.us/AdaIC/pol-hist/history/holwg-93/2.htm".
The following is found on the second "page".) 

"Evaluations 

The next step, beginning in June 1976, was the evaluation of 
existing languages against the integrated set of requirements. 
     
...
Other languages were considered for formal evaluation, but were not 
included because preliminary examination led one to believe that 
they would not meet the requirements so were not viable candidates 
for the purposes of the DoD. One such language was C. ... When Bell 
Labs were invited to evaluate C against the DoD requirements, they 
said that there was no chance of C meeting the requirements of 
readability, safety, etc., for which we were striving, and that it 
should not even be on the list of evaluated languages. We 
recognized the truth in their observation and honored their 
request."
     
C then? Not even close.  In whose opinion?  Bell Labs' opinion!

To get back to the present, there is a comparison (by David A. 
Wheeler) of today's versions of "Ada, C, C++, and Java vs. The 
Steelman" requirements at 
"http://www.adahome.com/History/Steelman/steeltab.htm".  It includes 
the following table (see article for caveats and link to Steelman):

 Language  "No"	"Partial"  "Mostly"  "Yes"  Percentage of 
 					    Answers with 
 					    "Mostly" or
                                            "Yes" 
                                             			
   Ada	    3	   5	    11	      94	93%
    C	   32	  21	     1	      44	53%
   C++	   19	  17	    23	      54	68%
   Java	   20	  12	    22	      59	72%
   
     
C now? Still not close.  C++?  68% might pass, but it won't get you 
on the Dean's List.

-- 
Suzette N.

\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Any research putting c above ada?

[Craig Franck]

Suzette Norby <psnorby@cacd.rockwell.com> wrote:

>Since we're strolling down memory lane, let's go back a few more 
>years.  The following, explaining why C was not even considered as 
>a candidate to be the common language, is quoted from "Ada - The 
>Project, The DoD High Order Language Working Group", copyright 1993, 
>which was originally published in ACM SIGPLAN Notices (Vol. 28, No. 
>3, March 1993).**
>
>     ** Permission to copy without fee all or part of this material 
>        is granted provided that the copies are not made or 
>        distributed for direct commercial advantage, this ACM 
>        copyright notice and the title of the publication and its 
>        date appear, and notice is given that copying is by 
>        permission of the Association for Computing Machinery. To 
>        copy otherwise, or to republish, requires a fee.
>
>(Complete text available at "http://sw-eng.falls-church.va.us/AdaIC/pol-hist/history/holwg-93/2.htm".
>The following is found on the second "page".) 
>
>"Evaluations 
>
>The next step, beginning in June 1976, was the evaluation of 
>existing languages against the integrated set of requirements. 
>     
>...
>Other languages were considered for formal evaluation, but were not 
>included because preliminary examination led one to believe that 
>they would not meet the requirements so were not viable candidates 
>for the purposes of the DoD. One such language was C. ... When Bell 
>Labs were invited to evaluate C against the DoD requirements, they 
>said that there was no chance of C meeting the requirements of 
>readability, safety, etc., for which we were striving, and that it 
>should not even be on the list of evaluated languages. We 
>recognized the truth in their observation and honored their 
>request."
>     
>C then? Not even close.  In whose opinion?  Bell Labs' opinion!

Yes, but they were the DOD's own requirements for a language 
*not* Bell Labs requirements on what constitutes an acceptable 
programming language to use on certain projects.

>To get back to the present, there is a comparison (by David A. 
>Wheeler) of today's versions of "Ada, C, C++, and Java vs. The 
>Steelman" requirements at 
>"http://www.adahome.com/History/Steelman/steeltab.htm".  It includes 
>the following table (see article for caveats and link to Steelman):
>
> Language  "No"	"Partial"  "Mostly"  "Yes"  Percentage of 
> 					    Answers with 
> 					    "Mostly" or
>                                            "Yes" 
>                                             			
>   Ada	    3	   5	    11	      94	93%
>    C	   32	  21	     1	      44	53%
>   C++	   19	  17	    23	      54	68%
>   Java	   20	  12	    22	      59	72%
>   
>     
>C now? Still not close.  C++?  68% might pass, but it won't get you 
>on the Dean's List.

So, you design a language with some specific requirements and 
then compare it to those requirements, and low and behold, it 
beats several other languages *at its own requirements*. Don't
you think there may be other reasons AT&T uses C++ as an in house
langauge, and not Ada? It is obvious that the "Dean" in this case
has his own daughter for a student.

Also note that it is possible to create requirements that *no*
language meets... Hey! That's exactly how Ada came about in the 
first place: no existing langauge would fit the bill. (I was 
going to use Scott Nudds' SPASM as an example, but this is a much 
better one.) For example, is Ada in anyway backward compatible with
C? No!

           C++      Ada 
           92%      0%

Boy, Ada has got some catching up to do... (I am not just being
a smart ass, that was one of the specifications for C++, to the 
extent that they existed.)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
All evolution in thought and conduct must at first appear
as heresy and misconduct. -- George Bernard Shaw

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5jqvbj$bd9@mtinsc05.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> Suzette Norby <psnorby@cacd.rockwell.com> wrote:
> 
> >Project, The DoD High Order Language Working Group", copyright 1993, 
> >which was originally published in ACM SIGPLAN Notices (Vol. 28, No. 
> >3, March 1993).**
> >
> >     ** Permission to copy without fee all or part of this material 
> >        is granted provided that the copies are not made or 
> >        distributed for direct commercial advantage, this ACM 
> >        copyright notice and the title of the publication and its 
> >        date appear, and notice is given that copying is by 
> >        permission of the Association for Computing Machinery. To 
> >        copy otherwise, or to republish, requires a fee.
...
> >"Evaluations 
> >
> >The next step, beginning in June 1976, was the evaluation of 
> >existing languages against the integrated set of requirements. 
> >     
> >...
> >Other languages were considered for formal evaluation, but were not 
> >included because preliminary examination led one to believe that 
> >they would not meet the requirements so were not viable candidates 
> >for the purposes of the DoD. One such language was C. ... When Bell 
> >Labs were invited to evaluate C against the DoD requirements, they 
> >said that there was no chance of C meeting the requirements of 
> >readability, safety, etc., for which we were striving, and that it 
> >should not even be on the list of evaluated languages. We 
> >recognized the truth in their observation and honored their 
> >request."
> >     
> >C then? Not even close.  In whose opinion?  Bell Labs' opinion!
> 
> Yes, but they were the DOD's own requirements for a language 
> *not* Bell Labs requirements on what constitutes an acceptable 
> programming language to use on certain projects.

Well, you rather miss the mark on this particular comment as at least
two of the requirements in question ("readability, safety,") are not
exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
really care about either issue?  Actually, for all I know, maybe they
don't and your comment is in fact spot on.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Andrew Koenig]

In article <JSA.97Apr28190941@alexandria> jsa@alexandria (Jon S Anthony) writes:

> Well, you rather miss the mark on this particular comment as at least
> two of the requirements in question ("readability, safety,") are not
> exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
> really care about either issue?  Actually, for all I know, maybe they
> don't and your comment is in fact spot on.

OK ... suppose you're in the DoD and you're in charge of setting
down preliminary requirements for a DoD standard programming language.
If a language already exists that will meet those requirements, the
DoD will use it.  If no such language already exists, the DoD will
launch a huge project to create one and put you in charge of it.

Under such circumstances, wouldn't you do whatever it took to be sure
that no existing language could meet the requirements?  If not, you
would probably not have reached a level in the hierarchy that would
have allowed you to influence the decision in the first place.

The nature of the decision process GUARANTEED that no existing
language would qualify.  Therefore, no inference can legitimately
be drawn from the nonqualification of any existing language.
-- 
				--Andrew Koenig
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: Any research putting c above ada?

[Tom Moran]

> If no such language already exists, the DoD will
> launch a huge project to create one and put you in charge of it.
> 
> Under such circumstances, wouldn't you do whatever it took to be sure
> that no existing language could meet the requirements?  If not, you
> would probably not have reached a level in the hierarchy that would
> have allowed you to influence the decision in the first place.
  That's a rather large set of assumptions about DOD decision maker's. 
Do you have any evidence, or merely the assumption they uniformly act as
you would?

Re: Any research putting c above ada?

[Jon S Anthony]

In article <E9F3CF.2KK@research.att.com> ark@research.att.com (Andrew Koenig) writes:

> In article <JSA.97Apr28190941@alexandria> jsa@alexandria (Jon S Anthony) writes:
> 
> > Well, you rather miss the mark on this particular comment as at least
> > two of the requirements in question ("readability, safety,") are not
> > exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
> > really care about either issue?  Actually, for all I know, maybe they
> > don't and your comment is in fact spot on.
> 
> OK ... suppose you're in the DoD and you're in charge of setting

<and then goes on to state a bunch of completely irrelevant stuff>

What in the world has this got to do with whether or not the two
stated requirements ("readability" and "safety") are (or were)
important to ATT/Bell Labs?  The point was that __Bell Labs__ stated
that C could not meet these (and the other) requirements.

> be drawn from the nonqualification of any existing language.

Shrug.  Maybe, maybe not.  The original poster merely pointed out that
Bell Labs were the ones who actively requested that C not even be
considered as they (or at least whoever was tasked with the job of
saying) felt that it could not possibly meet the requirements.

Actually, I don't know why this should bother anyone.  First, since
it's what they did, it is simply the facts of the situation.  Second,
why should anyone care?  So what if they decided C couldn't meet the
requirements?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <JSA.97Apr29212439@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>In article <E9F3CF.2KK@research.att.com> ark@research.att.com (Andrew Koenig) writes:
>
>> In article <JSA.97Apr28190941@alexandria> jsa@alexandria (Jon S Anthony) writes:
>> 
>> > Well, you rather miss the mark on this particular comment as at least
>> > two of the requirements in question ("readability, safety,") are not
>> > exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
>> > really care about either issue?  Actually, for all I know, maybe they
>> > don't and your comment is in fact spot on.
>> 
>> OK ... suppose you're in the DoD and you're in charge of setting
>
><and then goes on to state a bunch of completely irrelevant stuff>
>
>What in the world has this got to do with whether or not the two
>stated requirements ("readability" and "safety") are (or were)
>important to ATT/Bell Labs?  The point was that __Bell Labs__ stated
>that C could not meet these (and the other) requirements.
>
>> be drawn from the nonqualification of any existing language.
>
>Shrug.  Maybe, maybe not.  The original poster merely pointed out that
>Bell Labs were the ones who actively requested that C not even be
>considered as they (or at least whoever was tasked with the job of
>saying) felt that it could not possibly meet the requirements.

And they were right. If you consider the rather sad state of C in 1977.  At
that time it was only three years old. There was no standard to speak of which
would define the language and libraries.  Just think: the language didn't even
have a way to typecheck calls against definitions; prototypes were introduced
in C++ and migrated back into C. Error prone explicit casts had to be used in
function calls, for example:

foo(x)
long x;
{
    /* whatever */
}

bar()
{
    int x;
    foo((long) x);
}

Without the cast, the function call is incorrect. 

Some early C compilers also didn't put structure member names into separate
name spaces. Thus if you did:

    struct foo {
	int bar;
    } A;

    struct baz {
	int xyzzy;
    } B;

you could actually do ``A.xyzzy'' without a hitch.

Modern C is standardized, and offers better type checking. The addition
of function prototypes alone makes it a whole lot safer.

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <E9F3CF.2KK@research.att.com> ark@research.att.com (Andrew Koenig) writes:

  > OK ... suppose you're in the DoD and you're in charge of setting
  > down preliminary requirements for a DoD standard programming language.
  > If a language already exists that will meet those requirements, the
  > DoD will use it.  If no such language already exists, the DoD will
  > launch a huge project to create one and put you in charge of it.

  > Under such circumstances, wouldn't you do whatever it took to be sure
  > that no existing language could meet the requirements?  If not, you
  > would probably not have reached a level in the hierarchy that would
  > have allowed you to influence the decision in the first place.

  > The nature of the decision process GUARANTEED that no existing
  > language would qualify.  Therefore, no inference can legitimately
  > be drawn from the nonqualification of any existing language.

    Nonsense!  This totally misstates the situation.  Let us assume
for the moment that Eiffel existed in 1977 and did meet all or most of
the DoD's needs.  The HOLWG would have said, hey great, now we can
start on the real work of providing tools and a development
environment for Eiffel to do all the things we really want to do.

    In fact, members of the HOLWG have stated publicly that one 
mistake of the HOLWG was doing the language requirements and
development environment requirements in the wrong order.

    The HOLWG had no vested interest in language developments.  If
they had, they probably would have decided that several languages was
a better solution than just one.


--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Alan Brain]

Robert I. Eachus wrote:
 
> In article <E9F3CF.2KK@research.att.com> ark@research.att.com (Andrew Koenig) writes:

>   > The nature of the decision process GUARANTEED that no existing
>   > language would qualify.  Therefore, no inference can legitimately
>   > be drawn from the nonqualification of any existing language.
> 
>     Nonsense!  This totally misstates the situation.  Let us assume
> for the moment that Eiffel existed in 1977 and did meet all or most of
> the DoD's needs.  The HOLWG would have said, hey great, now we can
> start on the real work of providing tools and a development
> environment for Eiffel to do all the things we really want to do.

Concur. Had either Ada-83, Ada-95, Eiffel or possibly even Modula-3
existed in 1977, any could have been selected as the new language
without change.

Meanwhile.... IS there any non-anecdotal, scientific (you know, facts,
numbers, that sort of thing rather than religious conviction, personal
preference, shrill unsubstantiated allegations or market hype) that puts
C above Ada?

And I do mean ANY? Even One? I';m sure there MUST be... heck, there's at
least some evidence for Creationism and the Flat Earth...

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <E9F3CF.2KK@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>In article <JSA.97Apr28190941@alexandria> jsa@alexandria (Jon S Anthony) writes:
>
>> Well, you rather miss the mark on this particular comment as at least
>> two of the requirements in question ("readability, safety,") are not
>> exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
>> really care about either issue?  Actually, for all I know, maybe they
>> don't and your comment is in fact spot on.
>
>OK ... suppose you're in the DoD and you're in charge of setting
>down preliminary requirements for a DoD standard programming language.
>If a language already exists that will meet those requirements, the
>DoD will use it.  If no such language already exists, the DoD will
>launch a huge project to create one and put you in charge of it.
>
>Under such circumstances, wouldn't you do whatever it took to be sure
>that no existing language could meet the requirements?  If not, you
>would probably not have reached a level in the hierarchy that would
>have allowed you to influence the decision in the first place.
>
>The nature of the decision process GUARANTEED that no existing
>language would qualify.  Therefore, no inference can legitimately
>be drawn from the nonqualification of any existing language.

That has too much of the flavor of a conspiracy theory. Even if it's true, what
does it matter? The tough requirements resulted in a strong language; who cares
where they came from?  The requirements are particularly unreasonable or
arbitrary; most of them are justifiable. Furthermore, a language was
successfully constructed which met most of them, indicating that the
requirements are not impossible to meet.  That language now has a proven track
record in demanding applications.

I think that a heck of a lot inference can be drawn from the nonqualification
of an existing languages to these requirements. It means that the languages
which failed to qualify were designed to weak, compromised requirements, if
any.

If I were in that position to draw those requirements, I would have darn well
made sure that they were tougher than those that underlie any existing
language; that way I would not be reproached for having made a compromise
in favor of something less than excellent.

Re: Any research putting c above ada?

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <5jqvbj$bd9@mtinsc05.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:
>
>> Suzette Norby <psnorby@cacd.rockwell.com> wrote:
>> 
>> >Project, The DoD High Order Language Working Group", copyright 1993, 
>> >which was originally published in ACM SIGPLAN Notices (Vol. 28, No. 
>> >3, March 1993).**
>> >
>> >     ** Permission to copy without fee all or part of this material 
>> >        is granted provided that the copies are not made or 
>> >        distributed for direct commercial advantage, this ACM 
>> >        copyright notice and the title of the publication and its 
>> >        date appear, and notice is given that copying is by 
>> >        permission of the Association for Computing Machinery. To 
>> >        copy otherwise, or to republish, requires a fee.
>...
>> >"Evaluations 
>> >
>> >The next step, beginning in June 1976, was the evaluation of 
>> >existing languages against the integrated set of requirements. 
>> >     
>> >...
>> >Other languages were considered for formal evaluation, but were not 
>> >included because preliminary examination led one to believe that 
>> >they would not meet the requirements so were not viable candidates 
>> >for the purposes of the DoD. One such language was C. ... When Bell 
>> >Labs were invited to evaluate C against the DoD requirements, they 
>> >said that there was no chance of C meeting the requirements of 
>> >readability, safety, etc., for which we were striving, and that it 
>> >should not even be on the list of evaluated languages. We 
>> >recognized the truth in their observation and honored their 
>> >request."
>> >     
>> >C then? Not even close.  In whose opinion?  Bell Labs' opinion!
>> 
>> Yes, but they were the DOD's own requirements for a language 
>> *not* Bell Labs requirements on what constitutes an acceptable 
>> programming language to use on certain projects.
>
>Well, you rather miss the mark on this particular comment as at least
>two of the requirements in question ("readability, safety,") are not
>exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
>really care about either issue?  Actually, for all I know, maybe they
>don't and your comment is in fact spot on.

Oh, sure; why should they care if phone service is disrupted? I 
think you can argue which snippet is more readable. I think Ada
may be a tad too verbose, and C a smidgeon too terse.

PROCEDURE swap (a : IN OUT Integer; b : IN OUT Integer) IS
    temp : Integer;
BEGIN
    temp := a;
    a := b;
    b := temp;
END swap;

void swap(int *a, int *b)
	{
	int temp;
	temp = *a;
/**/    *a = *b;
/**/    *b = temp;
	}

(The /**/ are to stop Usenet from eating the "*" because it is the 
first nonwhitespace character on the line. I have *no* idea *why* it
does this; it does the same thing with ".".  I am sure if AT&T used 
Ada to implement their newsserver it wouldn't happen.) ;-)

Anyway, is AND more readable than &&? Who knows.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
All evolution in thought and conduct must at first appear
as heresy and misconduct. -- George Bernard Shaw

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5k67fl$eit@mtinsc03.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

  > Oh, sure; why should they care if phone service is disrupted? I 
  > think you can argue which snippet is more readable. I think Ada
  > may be a tad too verbose, and C a smidgeon too terse.

   And did Ma Bell ever catch it for those major outages a few years
ago!  (In fact several people on their way to an Ada 9X requirements
meeting in Portsmouth, England have fond memories of spending seven
hours or so on the ground because of one failure.)  But I digress...

   A better Ada statement of swap would be:

   procedure Swap (A,B : in out Integer) is
     Temp : Integer := A;
   begin A := B; B := Temp; end Swap;

   I'm not going to count characters, but that feels less verbose than
the C not more.

  > Anyway, is AND more readable than &&? Who knows.

   I do, lots of us do, and yes, it is. (But "and" in lower case is
more readable.)  There are some areas where Ada went with conventional
syntax, such as the arithmetic operations, and others where it can be
oververbose.  But in general, the most easily readable option was the
one chosen.  You have no concept how much Sturm and Drang went on
about the notation for types derived from tagged types which do not
add state.  The final answer was a compromise:

   type Bar is new Foo with null record;

   Three keywords to indicate that the type could have been extended,
but wasn't.  There needs to be something, and a lot of us wanted "with
null;" instead of "with null record;" but that's what compromise is
about.  (And two keywords is the minimum.  The first tells you it is
an extensible type, the second that it wasn't extended here.  If you
fold that together, it is tougher to parse as you read.)


					Robert I. Eachus

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

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Pat Rogers]

[snip]


>    A better Ada statement of swap would be:
> 
>    procedure Swap (A,B : in out Integer) is
>      Temp : Integer := A;
>    begin A := B; B := Temp; end Swap;
> 
>    I'm not going to count characters, but that feels less verbose than
> the C not more.

How about the even shorter:

	procedure Swap is new Exchange( Integer );

 :) :) :)

Re: Any research putting c above ada?

[Jon S Anthony]

In article <EACHUS.97Apr30145510@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> add state.  The final answer was a compromise:
> 
>    type Bar is new Foo with null record;
> 
>    Three keywords to indicate that the type could have been extended,
> but wasn't.  There needs to be something, and a lot of us wanted "with
> null;" instead of "with null record;" but that's what compromise is

Actually, I've always had a simple question about this area.  Why was
the "record" bit included in tagged types at all??  Why not simply:

    type T is tagged
        x: ...
        y: ...
        ...
    end T;

and

    type S is new T with
        ...
    end S;

and as you say above

    type R is new T with null;

Why was the "record" bit even there?  It's not a big deal, but IMO the
"record" part even is rather misleading - tagged things are very
different in all sorts of ways from regular old record types and
people can (and have - as evidenced by various threads in c.l.a) get
tripped up by this.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5k67fl$eit@mtinsc03.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> >Well, you rather miss the mark on this particular comment as at least
> >two of the requirements in question ("readability, safety,") are not
> >exactly specific to DoD.  Or do you think Bell Labs (or ATT) doesn't
> >really care about either issue?  Actually, for all I know, maybe they
> >don't and your comment is in fact spot on.
> 
> Oh, sure; why should they care if phone service is disrupted? I 

I guess this means they do care about this stuff.


> think you can argue which snippet is more readable. I think Ada
> may be a tad too verbose, and C a smidgeon too terse.

This is irrelevant.  You may well think Ada doesn't satisfy the
requirements either.  I may think otherwise, but that's irrelevant
too.  The point is simply that Bell Labs stated that C could not
possibly meet them.  Shrug.


> Anyway, is AND more readable than &&? Who knows.

As you say, who knows.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <335F9D0E.41C67EA6@cacd.rockwell.com>,
Suzette Norby  <psnorby@cacd.rockwell.com> wrote:

>To get back to the present, there is a comparison (by David A. 
>Wheeler) of today's versions of "Ada, C, C++, and Java vs. The 
>Steelman" requirements at 
>"http://www.adahome.com/History/Steelman/steeltab.htm".  It includes 
>the following table (see article for caveats and link to Steelman):
>
> Language  "No"	"Partial"  "Mostly"  "Yes"  Percentage of 
> 					    Answers with 
> 					    "Mostly" or
>                                            "Yes" 
>                                             			
>   Ada	    3	   5	    11	      94	93%
>    C	   32	  21	     1	      44	53%
>   C++	   19	  17	    23	      54	68%
>   Java	   20	  12	    22	      59	72%
>   
>     
>C now? Still not close.  C++?  68% might pass, but it won't get you 
>on the Dean's List.

A lot of the Steelman requirements are subjective. Some of them are irrelevant
to some tasks. And in others the answer depends on how the language is used.

For example, one requirement is that the user of the language not be able
to modify the syntax or or introduce new predence rules.   First of all, it's
not clear why this would necessarily be a bad thing; it depends on how it's
done. Secondly, changing the syntax is done using preprocessor abuses in C. Not
every program exhibits such preprocessor abuses.

The requirements call for overloadable functions. It's religious issue
whether these are a good thing. IMHO, they are bad. I avoid overloading
function names even in languages that offer the feature. Overloaded function
names are extremely poor programming practice. To figure out which function
is called, you have to look at all the argument types and apply all kinds
of rules. In Ada, the rules are particularly arcane. Not only do the
actual argument types matter, but also the expected type that is inherited down
the expression tree. You have to be a compiler expert just to understand
what's going on. 

It's interesting that one of the requirements is a Nudds: that is, that the
language support comments that are delimited by a special character (or
character pair) and terminated at the end of the line.  This is utterly a
religious issue.

Another example is that the language have fixed point types, bit strings, and
operations on subarrays. Shrug. I could also form my own arbitrary
and religious requirement here:  A decent language should have regular
expression matching and string substitution. Ada: no, C: no, C++: no, Java: no,
Perl: a resounding yes! 

The requirements call for some sort of tasking or threading. In fact at least
*six* separate requirements are related to tasking, and a language that doesn't
have the concept will fail on all three counts.  You can't have scheduling
facilities if you don't have concurrent processes, nor can you have passing of
data between processes, signalling or waiting! By comparison, the lack
of an exception handling facility only sets your language back three
points, if you are going to tally.

By adding up the scores naively, is Wheeler saying that a tasking model is
twice as important as an exception handling facility?  Furthermore, I would
also have to question some of Wheeler's assignment of yes and no answers,
though I agree with many, if not most of them. The individual assesments
are useful, but the numeric totals are misleading.

Re: Any research putting c above ada?

[Larry Wissig]

> 
> The requirements call for overloadable functions. It's religious issue
> whether these are a good thing. IMHO, they are bad. I avoid overloading
> function names even in languages that offer the feature. Overloaded function
> names are extremely poor programming practice. To figure out which function
> is called, you have to look at all the argument types and apply all kinds
> of rules. In Ada, the rules are particularly arcane. Not only do the
> actual argument types matter, but also the expected type that is inherited down
> the expression tree. You have to be a compiler expert just to understand
> what's going on.
> 
> 

Definitely religious. Overloading functions of the same name with diff
types little different in effect (albiet less effort) than generating
unique names for them yourself. Figuring out which function should be
called is the complilers business. 

Agreed Ada's rules are arcane.

Point for C++.


-- 
/////////////////////
//Larry Wissig
//lwissig@mindspring.com
/////////////////////

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <336148DD.4BC0@mindspring.com>,
Larry Wissig  <lwissig@mindspring.com> wrote:
>> 
>> The requirements call for overloadable functions. It's religious issue
>> whether these are a good thing. IMHO, they are bad. I avoid overloading
>> function names even in languages that offer the feature. Overloaded function
>> names are extremely poor programming practice. To figure out which function
>> is called, you have to look at all the argument types and apply all kinds
>> of rules. In Ada, the rules are particularly arcane. Not only do the
>> actual argument types matter, but also the expected type that is inherited down
>> the expression tree. You have to be a compiler expert just to understand
>> what's going on.
>> 
>> 
>
>Definitely religious. Overloading functions of the same name with diff
>types little different in effect (albiet less effort) than generating
>unique names for them yourself. Figuring out which function should be
>called is the complilers business. 

It is the compiler's business, but the human who is reading the program
has to understand the compiler's business in order to figure out which
function is called. I think it's a plus that C doesn't have function
overloading, and should count as a point against the other languages.

To add support to my position, consider this snippet from the Eiffel FAQ:

L08)

Why doesn't Eiffel allow function overloading?

In Eiffel, no two features of a class may have the same identifier, regardless
of their respective signatures. The prevents the use of function overloading
("multiple polymorphism"), a common programming technique in languages like
C++.

Eiffel is designed to be minimal: it includes exactly the features that its
designer considered necessary, and nothing else.

Because Eiffel already supports (single) polymorphism through its inheritance
system, the only positive thing that function overloading buys you is reducing
the number of feature names you have to learn. This is at the expense of
reducing the ability of the compiler to trap mistakes (often type errors).

Readability is also enhanced when overloading is not possible. With overloading
you would need to consider the type of the arguments as well as the type of the
target before you can work out which feature is called. With multiple
inheritance and dynamic binding this is awkward for a compiler and error-prone
for a human. There is no intuitive rule which could be used to disambiguate
routine calls where there is no "nearest" routine.

>Agreed Ada's rules are arcane.

Nobody's perfect.

>Point for C++.

No, point against C++. C++ also has function overloading. It also has arcane
rules governing which version of the function gets called.

Point for C, Eiffel, Pascal, and others.

Re: Any research putting c above ada?

[Nick Roberts]

Larry Wissig <lwissig@mindspring.com> wrote in article
<336148DD.4BC0@mindspring.com>...
> 
[critique of overloading by previous poster]
> 
> Definitely religious. Overloading functions of the same name with diff
> types little different in effect (albiet less effort) than generating
> unique names for them yourself. Figuring out which function should be
> called is the complilers business. 
> 

Besides which, operators such as + and - are (effectively) overloaded in
almost all languages, and have been since the days of BASIC. It would
surely be madness to insist that all the (effective) versions of + have
different names. Done with care, overloading in Ada is useful. Consider Get
in Text_IO: many would feel it a pain to have to write Get_My_Real,
Get_My_Integer, etc., all the time. It is true that there is a danger of
overloading being used with ill care, and causing confusion as a result.

Nick.

Re: Any research putting c above ada?

[Lawrence Kirby]

In article <01bc526e$4d178b00$28f982c1@xhv46.dial.pipex.com>
           Nick.Roberts@dial.pipex.com "Nick Roberts" writes:

...

>Besides which, operators such as + and - are (effectively) overloaded in
>almost all languages, and have been since the days of BASIC.

One notable exception is C's ancestor, BCPL. Something like awk probably
qualifies too.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Any research putting c above ada?

[b-see]

In article <862092794snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote:
>In article <01bc526e$4d178b00$28f982c1@xhv46.dial.pipex.com>
>           Nick.Roberts@dial.pipex.com "Nick Roberts" writes:
>
>....
>
>>Besides which, operators such as + and - are (effectively) overloaded in
>>almost all languages, and have been since the days of BASIC.
>
>One notable exception is C's ancestor, BCPL. Something like awk probably
>qualifies too.

The same is true of BLISS.

John

------------------------------------------------
Big Brother is watching and keeping track of what
you post. I have removed my personal information 
from the header and moved it here.

EMail Address:
|miano @    |
|worldnet . |
| att . net |

Full Name:
------------
-John?Miano-
------------

Re: Any research putting c above ada?

[Jon S Anthony]

In article <336148DD.4BC0@mindspring.com> Larry Wissig <lwissig@mindspring.com> writes:

> Definitely religious. Overloading functions of the same name with diff

agreed.

> Agreed Ada's rules are arcane.
> 
> Point for C++.

Huh?  C++'s rules are at least as arcane here and rather less safe.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Mike Haertel]

In article <5jr4ak$dsm@bcrkh13.bnr.ca>, Kaz Kylheku wrote:
>It's interesting that one of the requirements is a Nudds: that is, that the
>language support comments that are delimited by a special character (or
>character pair) and terminated at the end of the line.  This is utterly a
>religious issue.

That's not a religious issue, there's an actual reliability issue.
If a language has Pascal/PL1/C style comments, it's easy to accidently
comment out large blocks of code by forgetting a comment close
delimiter.  I've done it in C.  Often the result will still compile,
but the resulting program will crash in mysterious ways.  With
comment-to-end-of-line that risk doesn't exist.

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <slrn5m2p7t.qog.mike@ducky.net>,
Mike Haertel <mike@ducky.net> wrote:
>In article <5jr4ak$dsm@bcrkh13.bnr.ca>, Kaz Kylheku wrote:
>>It's interesting that one of the requirements is a Nudds: that is, that the
>>language support comments that are delimited by a special character (or
>>character pair) and terminated at the end of the line.  This is utterly a
>>religious issue.
>
>That's not a religious issue, there's an actual reliability issue.
>If a language has Pascal/PL1/C style comments, it's easy to accidently
>comment out large blocks of code by forgetting a comment close
>delimiter.  I've done it in C.  Often the result will still compile,
>but the resulting program will crash in mysterious ways.  With
>comment-to-end-of-line that risk doesn't exist.

Agreed. I would never design a language with Pascal or C style comment
delimiting that can span multiple lines (but I would always provide some
methods for conditional compilation of blocks). A language that I'm working
on uses the Bourne-shell style comments # ... <newline>. It's simple and
effective.

I still think it's a religious issue, though. I merely don't side with C on 
this one. :)

Re: Any research putting c above ada?

[Nick Roberts]

Mike Haertel <mike@ducky.net> wrote in article
<slrn5m2p7t.qog.mike@ducky.net>...
> In article <5jr4ak$dsm@bcrkh13.bnr.ca>, Kaz Kylheku wrote:
> >It's interesting that one of the requirements is a Nudds: that is, that
the
> >language support comments that are delimited by a special character (or
> >character pair) and terminated at the end of the line.  This is utterly
a
> >religious issue.
> 
> That's not a religious issue, there's an actual reliability issue.
> If a language has Pascal/PL1/C style comments, it's easy to accidently
> comment out large blocks of code by forgetting a comment close
> delimiter.  I've done it in C.  Often the result will still compile,
> but the resulting program will crash in mysterious ways.  With
> comment-to-end-of-line that risk doesn't exist.
> 

Although, of course, that problem tends to be historic now, with the (more
or less) ubiquity of chromacoding editors. It was a serious issue at the
time, though.

Nick.

Re: Any research putting c above ada?

[Istvan.Simon]

Mike Haertel wrote:
> In article <5jr4ak$dsm@bcrkh13.bnr.ca>, Kaz Kylheku wrote:
> >language support comments that are delimited by a special character (or
> >character pair) and terminated at the end of the line.  This is utterly a
> >religious issue.
> That's not a religious issue, there's an actual reliability issue.
> If a language has Pascal/PL1/C style comments, it's easy to accidently
> comment out large blocks of code by forgetting a comment close
> delimiter.  I've done it in C.  Often the result will still compile,

Never comment out large block of code using /* */ in C.
	Use 
#if 0

#endif
	instead.

BTW this is a common practice and a Good Thing.

-- MfG/Bye/Udv - Simon Istvan - mailto:istvan.simon@usa.net -

Re: Any research putting c above ada?

[Jerry van Dijk]

In article <5jr4ak$dsm@bcrkh13.bnr.ca> kaz@vision.crest.nt.com writes:

>It's interesting that one of the requirements is a Nudds:

It might be just me, but what is a "Nudds" ???

--

-- Jerry van Dijk       | Leiden, Holland
-- Business Consultant  | Team Ada
-- Ordina Finance       | jdijk@acm.org

Re: Any research putting c above ada?

[Daniel P Hudson]

Peter Amey <pna@erlang.praxis-cs.co.uk> wrote:
>On 15 Apr 1997, Tom White wrote:

>> I remember a Turing Award Lecture by C.A.R. Hoare from the early
>> eighties (dig through some Journals of the ACM).  Hoare was not
>> an Ada booster; he was concerned about the complexity of Ada from
>> both the application programmer's and compiler implementor's
>> perspectives.

[SNIP]

>A quote from this 1980 lecture includes the following: 

[SNIP]

Jeez, he had to go back 17 years to find something wrong with Ada.
You know what 17 years does to a language? That's 2 years before
the ANSI X3J11 sub-commitee for C was even formed. We could kill the
C that was used back then. But who cares what the problems with Ada,
assuming this was actually a problem, or C were back then, they are 
long gone by now.

Perhaps you would like to suffer through a list of problems with
C from 1980 but I wouldn't. Why don't you try keeping the 
factual criticisms within at least this decade if not the past
couple of years.

Re: Any research putting c above ada?

[Mark & Zurima McKinney]

Craig Franck wrote:
> 
> >count length of time needed for a novice to master the language?
> >C++ requires more than Ada.
> 
> It may be take longer, but what if it offers more? There are
> twice as many English words as Russian words. Is this a *bad*
> thing?
> 
In my experience C++ offers significantly less as a language. True there
are more add-ons that can be found but I have a been able to find
equivelent tools and libraries with only slightly more effort. 

Mark McKinney

Re: Any research putting c above ada?

[Craig Franck]

Mark & Zurima McKinney <mckmark@us.net> wrote:
>Craig Franck wrote:
>> 
>> >count length of time needed for a novice to master the language?
>> >C++ requires more than Ada.
>> 
>> It may be take longer, but what if it offers more? There are
>> twice as many English words as Russian words. Is this a *bad*
>> thing?
>> 
>In my experience C++ offers significantly less as a language. True there
>are more add-ons that can be found but I have a been able to find
>equivelent tools and libraries with only slightly more effort. 

Are they portable add-ons? I understand that an Ada implementation
must provide (Cohen 1986) four packages: IO_Exceptions, Text_IO,
Sequential_IO, and Direct_IO. That is it. When "The Long and Winding
Road" to standardization is at its end, C++ will offer a virtual zoo
of functionality; C already offers a good bit and C++ piles even 
more *portable* functionality onto that. In C and C++ the entire 
standard library is part of the language. (It has been pointed out
in an e-mail that there are well defined interfaces to C, Fortran,
and Cobol. This does provide a work around for Ada programmers.)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
Man is the only animal for whom his own existence is
a problem which he has to solve. -- Erich Fromm

Re: Any research putting c above ada?

[Robert I. Eachus]

In article <5j9287$omc@mtinsc02.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

  > Are they portable add-ons? I understand that an Ada implementation
  > must provide (Cohen 1986) four packages: IO_Exceptions, Text_IO,
  > Sequential_IO, and Direct_IO. That is it.

  Never not, even for Ada 83.  Those are the required Ada 83 IO
library units.  Others included Calendar, Unchecked_Conversion, etc.

  > When "The Long and Winding Road" to standardization is at its end,
  > C++ will offer a virtual zoo of functionality; C already offers a
  > good bit and C++ piles even more *portable* functionality onto
  > that. In C and C++ the entire standard library is part of the
  > language.

   In Ada 95, there is an extensive required library.  To quote Annex
A paragraph 1:

   "This Annex contains the specifications of library units that shall
be provided by every implementation.  There are three root library
units: Ada, Interfaces, and System; other library units are children
of these."  It then lists 67 library units, 19 of which are required
only of implementations that support some or all of the specialized
needs annexes.  To give you a flavor, Elementary_Functions and
Command_Line are required, but Complex_Elementary_Functions and RPC
are in specialized annexes.  (For those of you out there who are nit
pickers, there are some packages, such as Machine_Code, where the
applicable annex requires access to the functionality but allows that
to be through package machine code or compiler intrinsics.)

--

					Robert I. Eachus

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

Re: Any research putting c above ada?

[Kaz Kylheku]

In article <3355739E.7B24@pratique.fr>,
Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>Kaz Kylheku <kaz@vision.crest.nt.com> writes:
>
>> In article <335458A4.4C1D@worldnet.att.net>,
>> James S. Rogers <JimMaureenRogers@worldnet.att.net> wrote:
>> >Tom White wrote:
>> >> 
>> >> I remember a Turing Award Lecture by C.A.R. Hoare from the early
>> >> eighties (dig through some Journals of the ACM).  Hoare was not
>> >> an Ada booster; he was concerned about the complexity of Ada from
>> >> both the application programmer's and compiler implementor's
>> >> perspectives.
>
>I'd say that both are complex (comparing C++ to Ada 95) because they 
>are general purpose and support both structured and OO programming 
>with many neat things like genericity and exceptions.
>
>I'd think complexity is a problem (as long as the languge is 
>resonably orthogonal).
>
>> C++ is lame. 
>
>Let me disagree.

Okay. :)

>> This goes without saying. What's funny is that C++ is actually
>> _worse_ than C in many ways.
>
>C++ is more type safe (convertion void* -> T* is disallowed, and 
>each enumeration define a distinct type).

I suppose that the C++ designers want an award for this trivial change?

Pointers to void play an important role in C programming. It buys you nothing
to prevent an implicit conversion from void * to another pointer type.  All it
does is force you to put in a cast. Funny, the treatment void * seems to be the
example that C++ zealots always come up with when asked how C++ is more type
safe than C.

The enumerations are nice, though.

>> In some places it opens up holes.
>
>You mean something which is well-behaved in C and not in C++ ?
>
>Except the NULL pointer constant do you know any ?
>[int i = NULL is valid C++, not C.]
>
>> For example, consider that in C++, it is _undefined behavior_ to fail
>> to return a value from a function that returns some non-void type.
>> This could easily have been turned into a _constraint violation_.
>
>It's nearly the same from std point of view:
>
>- in Ada, the std say raise in case of such error; compilers give 
>  way to disable the test and you get undefined behaviour

??? Is that so?

>- in C/C++, thestd say the behaviour is undefined in case of such 

There is no such language as C/C++. And what the C++ draft says and
what the C standard says about this matter are two different things.

>  error; the compiler is free to optimise the code by guessing this 
>  won't appen or generate a runtime check and show a nice error 
>  message in case of exception

I'm sorry, I don't see how the omission of a return expression in a non-void
function can lead to better optimization. If you don't intend to return
a value, you should declare the function as not returning anything.

>So it's a quality of implementation problem more than a std problem.

No, it's a standard problem. I reiterate: in C, you can fail to return a value,
or you can ``fall of the end'' of a function that returns a value (two
semantically equivalent variants). The behavior is well defined so long as the
_caller_ ignores the return value of the function. I'm not saying that this is
a good thing.  Note that this could be treated as a simple constraint violation
easily diagnosable at _compile time_.  You parse the return statement, note
the lack of an expression, note the return type of the function you are in by
consulting a symbol table and complain!  It should be a constraint
violation---the only reason it is not in C is for historic reasons. Once upon a
time, C programmers simulated procedures by doing things like this:

    foo()		/* this is really an int returning function */
    {
			/* do something		*/
			/* now fall of the end	*/
    }

Bad stuff, but understandable. However, C++ takes the opportunity to make it
worse. Instead of properly constraining the semantics of return statements,
they opened up a bigger hole.  It is now _undefined behavior_ in C++ to do:

    int foo()
    {
	return;
    }

As I said, this is trivial to diagnose. But no, C++ has to make demons fly out
of your nose instead. :) That's language design for you.  The committe has been
at it for years now, and have produced a 780 page document that stacks three
inches high when printed double-sided.  Yet they can't get simple details right
like function calls and returns. What a failure.

>You don't understand the spirit of C++. The same goes for every runtime 
>error (for example dereferencing null pointer); it's undefined
>behaviour: 
>the implementation is free to check it or not.

From the looks of it, the ``spirit'' of C++ seems to be inspired by the
ingestion of spirits.

Here is another goodie: In C++, an assignment expression is itself an lvalue.
The main purpose of this seems to be to allow new ways of invoking undefined
behavior:

    int c;
    (c = 3) = 4;	/* oops, c modified twice between the prior and next
    			   sequence point */

In C, this sort of rubbish is not allowed. An assignment expression does
not inherit the lvalue-ness of its left constituent, hence the above
would be caught by a conforming C compiler. The committee should have
added sequencing properties to the assignment operator to protect against
undefined behavior.

The idea is that the above can be exploited in situations involving functions
that return references (situations in which the function call conveniently
provides a sequence point, making everything legal). You can bet that
it is used incorrectly more often than not.

Re: Any research putting c above ada?

[David Emery]

Measured by the "pages in the standard" metric, I think that Java is also
"worse than" Ada95, certainly if you include the standard library definitions.
What's more important is the level of specification.  Some of the draft 
language standards I've seen for other languages are much shorter than the
Ada95 RM (or ISO C++ or the Java books), but don't come anywhere near the
level of specification that these standards achieve.  Certainly the original
K&R book on C was -not- an adequate language standard (but it was not
intended to be, either...)

				dave
-- 
Note: if email to me bounces, use 'emery@grebyn.com'

Re: Any research putting c above ada?

[Jon S Anthony]

In article <5j1cso$i8p$1@goanna.cs.rmit.edu.au> Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:

> Matthew Givens writes:
> 
> "  In fact, I argue the opposite quite a lot.  C is good at what 
>  it does, very good.  Try writing a compiler or OS in Ada.  You can do it, 
>  certainly, but it's easier and  more natural in C.  Why?  Because that's 
>  what C was designed to do!"
> 
> The Gnat Ada compiler _is_ written in Ada. What makes it so hard to do 
> in Ada? What makes it easier and more natural in C? You've really got
> my curiosity piqued!

A misunderstanding of compiler implementation requirements and practice.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Jon S Anthony]

In article <3355739E.7B24@pratique.fr> Valentin Bonnard <bonnardv@pratique.fr> writes:

> > For example, consider that in C++, it is _undefined behavior_ to fail
> > to return a value from a function that returns some non-void type.
> > This could easily have been turned into a _constraint violation_.
> 
> It's nearly the same from std point of view:
> 
> - in Ada, the std say raise in case of such error; compilers give 
>   way to disable the test and you get undefined behaviour
> 
> - in C/C++, thestd say the behaviour is undefined in case of such 
>   error; the compiler is free to optimise the code by guessing this 
>   won't appen or generate a runtime check and show a nice error 
>   message in case of exception
> 
> So it's a quality of implementation problem more than a std problem.

I don't see how this follows.  In the Ada case the _programmer_ has to
intentionally and explicitly turn off the check.  Actually, I'm not
sure you can turn this check off (11.5 doesn't actually call this case
out).  In the C/C++ case you're stuck even if you would like such
things to be caught and brought to your attention.

To put it another way: in the Ada case the implementation _must_
support the checks and is free to support some form of check
suppression if the implementors wish.  In the C/C++ case, the
implementation is not required to do anything about such cases.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Any research putting c above ada?

[Chris Morgan]

In article <5ius80$1nr8@newssvr01-int.news.prodigy.com>
NKSW39B@prodigy.com (Matthew Givens) writes:

[SNIP]
In fact, I often rough out algorythms in C 
> before implementing them in the Ada version.  Why?  Because I don't have 
> to think so much of the surface furnishings of Ada and can concentrate on 
> just the functionality.  It would save a lot of time if I didn't have to 
> write the Ada version, wouldn't it?

And I have prototyped things in Ada before rewriting them in C. This
proves nothing except people are most productive in their language of
fluency.

> 
> And, before I get lambasted, I realize that other people don't agree with 
> that.  That's okay, variety is a good thing, not a bad one.

Of course I agree, but my point is it's reversible so hardly a
valuable addition to the discussion.

Regards,

Chris
-- 
Chris Morgan (cm@mihalis.demon.co.uk) 
http://www.mihalis.demon.co.uk/

Re: Any research putting c above ada?

[David Emery]

 clines@airmail.net (Kevin Cline) wrote
>1. No reasonably usable bindings to key external components: operating
>systems, windowing systems, databases.

Geez, I never had any problem "rolling my own" Ada bindings when needed.
And I've been doing Unix system-level programming since 1984...

>2. Expensive compilers of rather poor quality.

True...  This is where the DoD "captive market" hurt.  Many of us argued
in 1985 that the best thing the DoD could have done at that point was to
produce/release a free Ada compiler, with full source, a la GNAT.  (The
Intermetrics AIE was one candidate.)  The availability of GNAT has really
helped Ada.  It's also helped GCC/other GNU translator developers, by 
adding features and increasing the quality of the GCC interface and back-end. 

>3. The language moved much too slowly while the software market completely
>changed from mainframes and minicomputers with dumb terminals to client/server
>systems.  Ada83 lacked key features needed to develop client/server systems.

See #1.  I did my first "client-server" system in Ada83 in 1987, using
Sun ONC RPC.  What key features does Ada83 lack that any other -language-
provides for Client-Server?  Fast/efficient client-server support needs
  a.  good client-server infrastructure ("middleware")
  b.  bindings to same
  c.  tool support

My observation on Ada bindings has been that 
  a.  Ada83 went way farther than any previous languages in supporting
      mixed-language programming.   (Try connecting software written by
      2 different C compilers...)
  b.  There were some tricks to writing interfaces to C.  Most of these
      tricks worked on most compilers, although they were not guaranteed
      by the language.
  c.  The time spent producing a good binding to C was recovered by 
      substantially reduced debugging time in the application.  Thus, if
      the binding were to be called many times, we spent more time getting
      it "better" (i.e. "thicker").  If there was only one or two points of
      call, then we'd just cobble up "pragma interface (C);"
Ada95 codifies many of these tricks, and fixes a couple of places where
compiler support was necessary.  I don't know of any other language that
approaches Ada83's support for mixed-language programming, including control
over data layouts, etc.  Ada95 is clearly ahead of the pack, but of course
this has been out of necessity, because most commercial products come with
a C interface.  

The big problem in my experience has been a language-independent problem,
and that's the quality of the interface.  Some vendors provide high 
quality, well-engineered interfaces, and others provide terribly 
hacked-together interfaces.  The former make it easy to use the product
from -any langauge-, while bad interfaces are bad interfaces, regardless
of the language of implementation.  

It remains to be seen if CORBA IDL produces a "paradigm shift" in interface
definitions.  I've seen well designed IDL, and I've seen IDL that looks
like bad C.  

				dave

-- 
Note: if email to me bounces, use 'emery@grebyn.com'

Re: Any research putting c above ada?

[Jim Hyslop]

In article <c4enc8lzi5.fsf@hc17031.hcsd.ca>, demer@hc17031.hcsd.ca 
says...
> My observation on Ada bindings has been that 
>   a.  Ada83 went way farther than any previous languages in supporting
>       mixed-language programming.   (Try connecting software written by
>       2 different C compilers...)
Piece of cake, compared to connecting software compiled by two different 
C++ compilers...

-- 
Jim Hyslop
jim.hyslop@leitch.com
Welcome to the world of Windows 95, where you click on "Start" to shut 
down.