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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

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

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

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

[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... (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?)

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

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

[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

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?

[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

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