Who gets higher salary a Java Programmer or a C++ Programmer?

[LR]

I call myself a "software engineer" in Maryland, the U.S. of A.

On business cards? Letterhead? I'm sorry, I don't recall, did you say
you were a PE?

LR

 

[Lew]

That sounds like mathematics to me.  I've always been told that Computer
Science is a branch of mathematics.  Just because something is called
science doesn't mean it is, the same as if you call something
engineering it doesn't mean it is.




I agree.  But something that isn't engineering won't become engineering
as it gets more mature.




Sorry, I think that qualifies as mathematics.

What a specious argument.

You set up a straw-man definition of engineering as solely
"application of scientific principles", rejecting every definition
offered by engineering groups as cited here. Then you reject the
scientific principles proffered because they "sound like" mathematics
*to you*, and therefore must not be science, again, by your definition
only. Then by redefining everything you have "proven" that software
development cannot be engineering. So you control all the
definitions, rejecting everything the rest of the world uses if it
doesn't fit your little, narrow world view. Thus, you will always
win.

There is no reasoning with you.

 

[LR]

Not entirely. It's generally easier to verify that software
will work than it is for a bridge, because software works in a
very controlled medium.

Yes, that's right. Programmers don't worry about things like power
outages. Although they may have to worry about incomplete transactions.
But the physical world is more or less besides the point. Usually.

Yes, but do software systems fail in the same way that bridges
do?

I tend to think that a significant number of bridge failures
occur because engineers don't take the entire physical world
into account when they do their work. EG, in the case of the
Tacoma Narrows they may not have accounted for certain kinds
of fluids problems. I don't recall exactly but I think the Tay
may have collapsed under it's own weight.

OTOH good engineering can work wonders which layman can only
comment on as Lincoln famously did: "That man [Herman] Haupt
has built a bridge four hundred feet long and one hundred feet
high, across Potomac Creek, on which loaded trains are passing
every hour, and upon my word, gentlemen, there is nothing in
it but cornstalks and beanpoles." I'm not sure if this is the
bridge in question, but it might fit the
bill:http://www.geocities.com/rayhaupt.geo/GeneralsBridge.JPG

I think software doesn't have this particular problem.

I'm not exactly sure what problem you're referring to. If I've
understood you correctly, then no, software doesn't have this
problem. Which makes verification several orders of magnitude
easier; you know the full environment.

But I think I made it plain that engineers don't consider the entire
physics of the bridge. They might not consider fluid interactions or
wind loading or some such. The parameters are likely to be driven by
budget, customer requirements or perhaps good practice.

For some types of
software, at laest. For real time software, it's less obvious,
since it's fairly hard to be sure that you've analysed all
possible timing issues.

I don't think testing all the possible interactions is possible for most
software. Consider a fairly simple program that reads inputs for say 64
boolean variables and has at least one conditional branch for each
variable.

And yes, I once did speak to a EE who told me that the software his
company wrote was fully tested for all possible inputs.

But it's still several orders of
magnitude easier than verifying that you've analysed all
possible physical interactions which might affect a bridge.

But that isn't done. AFAIK ever. I don't think there's enough time in
the universe to do that. Not even for all the likely cases.

Mathematics.

Yeah, that's it then. Except math is not a science.

Seriously, engineering is a lot more than just the application
of scientific principles---engineering is also concerned with
esthetics, cost, development methodology, etc. (Take a look at
some of the bridges designed by Gustave Eiffel---the viaduc de
Garabit, for example---and tell me that esthetics aren't
involved).

I won't. But engineers aren't precluded from doing design, in the sense
of aesthetics rather then physics, are they?

Not always successfully though, the attempt to streamline steam
locomotives in the early to middle 20th century was a bit misguided,
wasn't it? At least from an engineering standpoint.

(Some of this raises several interesting questions that go beyond the
scope of this discussion. EG, I've read statements by a few engineers
who write something similar to: If it looks right it will fly. Or
steam, or sail, or whatever it is they're designing for. I've heard
programmers say something similar. But then I'd expect cobblers and
coopers to have something similar to say. Why something looks right is
left as an exercise. )

And speaking of Eiffel and aesthetics let's not forget that statue
standing in NYC's harbor.

But the operative word in your case is "principles",
not just one principle, but more the set of all of them.

Oh I agree that there's more to engineering than the application of
scientific principle. But that is the heart of the matter. Without
that I don't think that it's engineering.

In many ways, the way you develop software is exactly the same
as the way an engineer develops a bridge, or an architect
develops a building. It involves a complex mixture of creative
work, applying known and established principles, having the work
verified by others, etc., etc. There is also the great range of
applications: most bridges/programs are really just a rehash of
standard solutions, and can be turned out quite quickly, with
very little real creativity or analysis. And a very, very few
push the envelope; these require even more analysis than usual.

I agree that there are similarities. Even though you haven't said it
explicitly, I think there is quite a bit that software developers can
learn from engineers. But I don't quite see how software development is
engineering. I suspect they are fundamentally different. I've sometimes
wondered if perhaps software development isn't little more like making
movies.

LR

 

[LR]

{...]
Do the programs provably work? To the same extent that an engineer could
"prove" that the bridge they designed will work?
There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave rise to
what is called "design by contract", by which you define formally the
specifications of your program with pre/postconditions, invariants,
etc. You can mathematically prove that your program will work by those
means. This is used in any sensible environment that needs absolutely
reliable softwares.

Absolutely reliable? Suppose you have a customer who wants a formal
proof that the program you've written will halt. Can you provide that?

Yes, absolutely reliable. The program is proven to be correct in any
way. The proof can be given in the form of mathematical notations.

I'm not sure you responded to my question, so please allow me to restate
it. Suppose you have a customer who wants a formal proof that the
program you've written will halt, can you provide that?

LR

 

[Tamas Demjen]

Sorry, I think that qualifies as mathematics.

It's applied mathematics, like with other fields of engineering. These
days a lot of the hardware is engineered similarly to software: You
write code in a hardware description language, simulate it in software,
and compile it in silicon or a programmable hardware. Just like with
software, it is extremely hard to formally prove hardware correctness as
well (remember the old Pentium floating point bug?).

Tom

 

[Gennaro Prota]

If that choice works for you, then that's what's best for you. I'm
still waiting for a single example of a scientific principle applied in
the development of software.

We might be having a problem around the term "principle". If you
refer to scientific principles (laws) such as Archimedes'
principle or the law of conservation of energy then, of course,
they aren't "applied to the development of software".

"Therefore it is not 'engineering'", you are saying? Fine, it's
a terminology problem: you might call it software-ology, for
instance. However "software engineering" is used by an engineer
association with an agreed upon meaning. It's of course more
about methodology ("systematic, disciplined, quantifiable") than
scientific principles.

Note that I've assumed good faith so far. I won't feed the
troll.

 

[courpron]

(e-mail address removed) wrote:
 {...]
Do the programs provably work? To the same extent that an engineer could
"prove" that the bridge they designed will work?  
There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave rise to
what is called "design by contract", by which you define formally the
specifications of your program with pre/postconditions, invariants,
etc. You can mathematically prove that your program will work by those
means. This is used in any sensible environment that needs absolutely
reliable softwares.
Absolutely reliable? Suppose you have a  customer who wants a formal
proof that the program you've written will halt.  Can you provide that?

Yes, absolutely reliable. The program is proven to be correct in any
way. The proof can be given in the form of mathematical notations.

I'm not sure you responded to my question, so please allow me to restate
it.  Suppose you have a customer who wants a formal proof that the
program you've written will halt, can you provide that?

If "halting of the program" was in the user requirement specifications
of the software, then yes. Since the software was developped using
design by contract, it can be proved to meet the specifications. If
the specifications was impossible to meet for one reason or another,
the software couldn't have been developped using formal methods.

Alexandre Courpron.

 

[LR]

Help me understand your definition of "scientific principle"

By way of example, "F = ma" is a scientific principle. I^2*R=W is a
scientific principle. Hz = 1/(2*PI*sqrt(L*C)) is a scientific principle.
I admit I had to pull out my copy of Marks for that last one. It's a
been a long time since I needed it.

and the
background of the engineers you cite as your source. If they are the
white lab coat Phud types of research I can understand the narrowness of
the definition. If, on the other hand the engineers are brushing off the
dirt & crud from the field I can't imagine any of them giving you that
singular an answer.

I've met both kinds and up until now, all of the ones I've met in person
have told me this.

FWIW, not all engineers design bridges.

I know. Civil engineers design targets. Mechanical engineers design weapons.

I hold a degree in electrical engineering where systems are designed
based on electrical theory. Did you catch that "theory" thing?

I did. I'd think of that as being scientific principle. Would that do
for you too?

I also
hold a degree in industrial engineering where systems design entails
such issues as process flow & control, statistical measurements of
production, cost accounting, environmental issues and human behavior,
just to name a few - oh, and a thorough study of materials science, just
so you know there *is* a scientific principle or two involved.

Materials science is multi-disciplinary and is a science. Yes.

How I came to design software is a whole other story but suffice it to
say that I found the discipline of engineering to be directly
transferable to the development of software. I took over a position
vacated by someone who probably should have been out writing a book
(programming analogy provided by someone else in this thread) rather
than designing software. I also worked with someone who entered the
programming field from a job in social services. What I found sadly
lacking in the work of these genuinely nice folks was the vaguest notion
of logic and structured design.

Sounds a little like my background.

And that was back in the days when the
programming language itself imposed some limits on how careless you
could get. IMO, the freedom JAVA provides to go totally berserk
*demands* an engineered approach to software design.

I'm not a Java programmer so I can't respond to this directly. I use
C++ as my primary programming language at the moment. I find that using
it, reasonably well, imposes more discipline than a language like C,
Pascal, COBOL, PL/I or Fortran77 would. This might just be my personal
experience, but I am a little surprised by what you say. Perhaps I
don't understand what you mean. Or perhaps I'm not being objective since
I can't easily compare what I used to be like to what I'm like now.

The field of engineering is a richly diverse discipline that encompasses
logic, structure, nathematics, ethics, economics, reliability, safety,
creativity, imagination, aesthetics, the human element and *even*
scientific principles. Your insistence on such a narrow definition is
like insisting that flight requires the flapping of wings.

No, I disagree. I don't say that engineering doesn't encompass those
other things, I suggest that fundamentally engineering is the
application of scientific principle and lacking that, it isn't
engineering but something else. Perhaps accounting. Or aesthetic
design. Or management. Not that engineers can't do these things too.

I guess to sum up my thoughts on software engineering, the exponential
growth of complexity in the systems that we depend on every day demands
a disciplined, structured approach to safe reliable designs - that is
the function of engineering.

In some circumstances.

Acknowledging I might be a bit biased.



BTW, did anyone ever answer the question posed in the subject line?

Not to be completely contrarian, but is that answerable?

LR

 

[LR]

Same here: its well recognised in the UK. I hold a CE in software
engineering as well as an MSc (Chemistry).

Some of the states too, I think. However, I read a little of the law
for one state and it doesn't really describe an engineering discipline.
It actually used the phrase "computer programming". At least AFAIR.

LR

 

[Ben Voigt [C++ MVP]]

(e-mail address removed) wrote:
{...]
Do the programs provably work? To the same extent that an
engineer could "prove" that the bridge they designed will work?
There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave
rise to what is called "design by contract", by which you define
formally the specifications of your program with
pre/postconditions, invariants, etc. You can mathematically prove
that your program will work by those means. This is used in any
sensible environment that needs absolutely reliable softwares.
Absolutely reliable? Suppose you have a customer who wants a formal
proof that the program you've written will halt. Can you provide
that?

Yes, absolutely reliable. The program is proven to be correct in any
way. The proof can be given in the form of mathematical notations.

I'm not sure you responded to my question, so please allow me to
restate it. Suppose you have a customer who wants a formal proof
that the program you've written will halt, can you provide that?

You could provide a formula for the number of instructions that will be
executed as a function of the inputs (or the size of the inputs). It's
considerably harder to put bounds on the number of cycles because of all the
crazy things modern CPUs do to try to execute a program faster and the
possibilities for introducing bugs at the hardware level. But yes, it's
absolutely possible to write a program that will provably, given a bug-free
processor, halt within a certain number of instructions. If the program
uses recursion this can be done as a proof by induction. If the program
uses iteration it needs to be broken into basic blocks and then proof by
induction can be applied.

Note that the "halting problem" asserts that there is no algorithm that
determines whether an arbitrary program halts in finite time. For specific
programs this can be very easy to determine.

Of course you need to guarantee that all backward branches are part of
elementary control structures, but remember you said we could write the
program, so we can ensure this is the case.

For example, it's relatively easy to prove that this function always halts
if given sufficient stack space (and it is also easy to prove a bound on the
stack space required, especially so since it uses a tail call):

unsigned hamming(unsigned n, unsigned counted = 0)
{
if (n == 0) return counted;
return hamming(n >> 1, counted + (n & 1));
}

The proof runs something like this:

Let k be the position (1-based, started at the LSB) of the most significant
non-zero bit of n, or 0 if there are no non-zero bits. k is naturally
bounded by the size of the 'unsigned' data type.
For k zero, then the function returns without taking a backward branch, thus
finite runtime cost (use the assembly code to count the instructions).
For k non-zero, the function reaches the recursive tail call without taking
any backwards branch (use the assembly code to count the instructions), so
the total cost is that finite runtime cost plus the cost of executing
recursively.

But k is decreased in recursion by the bit-shift operator. So induction
applies.

QED This function returns in finite time for all inputs.

 

[Ben Voigt [C++ MVP]]

So far it hasn't helped me except as more evidence that there isn't

any scientific principle being applied in this so called engineering
disciple.

And you'd be wrong.

If that choice works for you, then that's what's best for you. I'm
still waiting for a single example of a scientific principle applied
in the development of software.

There are plenty of mathematical principles applied. In fact, let's play
YOU name a principle and we'll give you an example (I already used proof by
induction in another response in this thread).

 

[Ben Voigt [C++ MVP]]

Some of the states too, I think. However, I read a little of the law
for one state and it doesn't really describe an engineering
discipline. It actually used the phrase "computer programming". At
least AFAIR.

There is a lot of computer programming going on that doesn't involve
engineering. But that doesn't mean that no software is engineered.

 

[Ben Voigt [C++ MVP]]

By way of example, "F = ma" is a scientific principle. I^2*R=W is a
scientific principle. Hz = 1/(2*PI*sqrt(L*C)) is a scientific
principle.
I admit I had to pull out my copy of Marks for that last one. It's a
been a long time since I needed it.

Actually I think that last should be

f_resonance = 1/(2*PI*sqrt(L*C))

with f_resonance in Hz = 1/s, L in Henrys, and C in Farads = Coulombs/Volt.

You've confused variables with their units.

 

[Lew]

.... proof elided ...

QED This function returns in finite time for all inputs.

A very scientific analysis firmly rooted in the principles of computer
science. Clearly, Ben, you are an engineer!

 

[Martin Gregorie]

But I think I made it plain that engineers don't consider the entire
physics of the bridge. They might not consider fluid interactions or
wind loading or some such. The parameters are likely to be driven by
budget, customer requirements or perhaps good practice.

That's quite wrong. The engineers who designed the Tay and the Tacoma
Narrows bridges ignored wind and look where that got them.

 

[Captain Koloth]

If that choice works for you, then that's what's best for you.  I'm
still waiting for a single example of a scientific principle applied in
the development of software.

A blind man may wait for many years after asking someone to show him
the path, though he had received a prompt response.

 

[LR]

What a specious argument.

I conclude that you don't have an argument.

You set up a straw-man definition of engineering as solely
"application of scientific principles", rejecting every definition
offered by engineering groups as cited here.

It seems to me that you haven't read my posts.

Then you reject the
scientific principles proffered because they "sound like" mathematics
*to you*, and therefore must not be science, again, by your definition
only.

In what way is computer science a science and not mathematics.

Then by redefining everything you have "proven" that software
development cannot be engineering. So you control all the
definitions, rejecting everything the rest of the world uses if it
doesn't fit your little, narrow world view. Thus, you will always
win.

I only wish that were true.

There is no reasoning with you.

Actually to the contrary, there is only reasoning with me.

LR

 

[LR]

We might be having a problem around the term "principle". If you
refer to scientific principles (laws) such as Archimedes'
principle or the law of conservation of energy then, of course,
they aren't "applied to the development of software".

"Therefore it is not 'engineering'", you are saying? Fine, it's
a terminology problem: you might call it software-ology, for
instance. However "software engineering" is used by an engineer
association with an agreed upon meaning.

So if it's defined that way, then that's what it is?

It's of course more
about methodology ("systematic, disciplined, quantifiable") than
scientific principles.

I wonder why the definition of what engineering is seems to have changed.

Note that I've assumed good faith so far. I won't feed the
troll.

Simply because I disagree with you doesn't mean I'm a troll. But then
I'm quite used to having people bend words in ways that fit their
misconceptions. Isn't that what this discussion is about, at least in part?

LR

 

[LR]

It's applied mathematics,

Is applied mathematics science?

like with other fields of engineering.

I think every branch of engineering applies mathematics. But they do it
to apply scientific principle. I repeat, as I don't believe I have
received an answer, what scientific principle is applied in "software
engineering"?

These
days a lot of the hardware is engineered similarly to software:

Software isn't engineered, so I believe your statement is based on a
false predicate. Or at least it hasn't been demonstrated to my
satisfaction that there is such a discipline.

You
write code in a hardware description language, simulate it in software,
and compile it in silicon or a programmable hardware. Just like with
software, it is extremely hard to formally prove hardware correctness as
well (remember the old Pentium floating point bug?).

But all of that is an attempt to apply some science related to
electricity and physics. Right?

Using a software tool to calculate something doesn't mean that you're
not doing engineering. But the creation of the software itself wasn't
AFAICT engineering.

LR

 

[LR]

(e-mail address removed) wrote:
{...]
Do the programs provably work? To the same extent that an engineer could
"prove" that the bridge they designed will work?
There is a whole branch of computer science that is dedicated to
"program provability". In the practical world, the theory gave rise to
what is called "design by contract", by which you define formally the
specifications of your program with pre/postconditions, invariants,
etc. You can mathematically prove that your program will work by those
means. This is used in any sensible environment that needs absolutely
reliable softwares.
Absolutely reliable? Suppose you have a customer who wants a formal
proof that the program you've written will halt. Can you provide that?
Yes, absolutely reliable. The program is proven to be correct in any
way. The proof can be given in the form of mathematical notations.

I'm not sure you responded to my question, so please allow me to restate
it. Suppose you have a customer who wants a formal proof that the
program you've written will halt, can you provide that?

If "halting of the program" was in the user requirement specifications
of the software, then yes. Since the software was developped using
design by contract, it can be proved to meet the specifications. If
the specifications was impossible to meet for one reason or another,
the software couldn't have been developped using formal methods.

So then, not all software can be produced using formal methods?

LR