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

[Arne Vajhøj]

The problem with a program provability that in real life, you only can
formulate complete requirements for small pieces of it. Like for a sort
algorithm, for some calculation, etc, etc. When you start to formulate usage
scenarios for an OS or interactive application, it's not quite possible to
write them down in a form that would be useful for formal proof. Modern
software operates in an environment so indeterministic and chaotic (its
input ispretty much white noise), that one would have very hard time trying
to mathematically prove that a program will do as specified.

There is definitely a difference between what is possible
in theory and what is practical/cost efficient.

Software engineering is not the only field where that
applies.

Arne

 

[Keith H Duggar]

The _American Heritage Dictionary_ gives:

The application of scientific and mathematical principles to
practical ends such as the design, manufacture, and
operation of efficient and economical structures, machines,
processes, and systems.

That certainly covers software engineering. The term
"scientific and mathematical principles" is broad, and covers a
lot more than just physical laws like Archimedes' principle. Or
even mathematical proofs of programs. The entire sentence above
makes it clear that it also applies to the process, for example.
Every good shop I've seen makes extensive use of statistics, for
example, in evaluating their process. And controlled testing,
which is the basis of all scientific methodology. And code
review, which is a form of peer-review such as is used in all
scientific journals. Software engineering is all about the
"design [...] of efficient and economical [...] systems", using
"scientific and mathematical principles" in a practical way.
You can't get more "engineering" than that.

I'm sorry, but could you please be explicit about which scientific
principle is being applied?

Software Engineering is replete with scientific principles.
Here are but a few off the top of my head:

Principle of Induction
Pigeonhole Principle
Information Principle
Chebyshev's Inequality
Akra-Bazzi Theorem
Divide-and-Conquer
Dynamic Programming
Sieve Principle
Occam's Razor
Murphy's Law

A decent computer science or software engineering curriculum
should expose you to these and many other principles. Perhaps
decent curriculums (or students that pay attention) are more
rare than I realized.

KHD

 

[Lew]

Software Engineering is replete with scientific principles.
Here are but a few off the top of my head:

Principle of Induction
Pigeonhole Principle
Information Principle
Chebyshev's Inequality
Akra-Bazzi Theorem
Divide-and-Conquer
Dynamic Programming
Sieve Principle
Occam's Razor
Murphy's Law

A decent computer science or software engineering curriculum
should expose you to these and many other principles. Perhaps
decent curriculums (or students that pay attention) are more
rare than I realized.

Can anyone say Claude Shannon? Entropy! An essential element of Information
Theory, the science of information.

 

[Lew]

It is the only place software reliability can come from.

I suggest a refinement of that response. Meticulous up-front engineering is
required but not sufficient. Engineering cannot stop once construction begins.

Especially as software pretty much requires an iterative development process
even for initial construction of a system, much less its operational evolution.

 

[Lew]

A long time ago in Bath I was amongst 80 contractors fixing a wee problem
the MoD had found themselves saddled with. There was one guy there who
other contractors had seen on and around various projects for 6 or 7
years and had never been known to successfully finish a program. He
always managed to leave in time and his programs were generally scrapped
and rewritten.

I've seen this sort of thing many times over the years. In most cases the
more competent and committed team members made strenuous attempts to alert
management to the problem, only to be rebuffed. I did succeed in getting
management's attention in one such case, when I rewrote almost a million
dollars' worth of useless software from the bad contractor in two days and
about 150 lines of C code, to run on cheaper hardware with virtually no
configuration requirements for the code, and which withstood the worst bad
data streams the tester could hurdle at it without losing the good data,
unlike the bad contractor's code which would crash its server after 30% bad
data, all without even looking at BC's work. Management had a cow - they had
to explain to the investors how almost a million dollars had been converted
from an asset to garbage in two days for a few hundred dollars' worth of an
in-house employee's time. Admittedly the result worked perfectly, but the
investors still pulled out all their funding two weeks later.

The direct employees had been outing BC to the bosses for over six months at
that time, to no avail.

 

[Arne Vajhøj]

I suggest a refinement of that response. Meticulous up-front
engineering is required but not sufficient. Engineering cannot stop
once construction begins.

True.

But the upfront work is often the most important - after it
end up in a bad design, then most of the following work is
often very restricted by compatibility reasons.

Arne

 

[Arne Vajhøj]

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

We have seen no evidence of that in this thread.

And using the scientific principles we obviously
bade our opinions on observable facts.



Arne

 

[Arne Vajhøj]

F = ma is a scientific principle.

No.

It is not a principle.

It is a law in physics.

Arne

 

[Arne Vajhøj]

Arne Vajhøj wrote:
LR wrote:
I've seen some bridges come with documentation that says things like "No
vehicles over 5 [sic] tons." But I can't say I can recall ever seeing
documentation for a program that says "Do not enter numbers over
1,000,000.00 or your computer will break." Sometimes the program itself
will tell you after you enter a bad number. I suppose that would be
more like driving a six ton truck on the aforementioned bridge, without
the sign present, with perhaps obvious consequences. Although I suspect
the bridge sign was probably written with some safety factor in mind,
whereas the program probably won't work if 1,000,000.01 is entered.
I can not think of any serious enterprise app where the docs
does not specify a lot of limits (both functional and for
given hardware performance related).
Please define what you mean by the word "serious" in the above. TIA

Try:

http://www.google.com/search?hl=en&q=define:serious&btnG=Google+Search&aq=f&oq=

Ok, thanks, I think I take your meaning now. So it's circular? If it
doesn't fit your criteria, then it's not serious and if it does, it is?
Did I get that right?

No.

Try click the link and read.

Arne

 

[Arne Vajhøj]

(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?

Most likely yes.

Computer science has proven that it is not possible to do that
for all programs, but it can be done for some programs. If one
is willing to spend the money, then it can be done for most
programs.

(the examples used to prove the haling problem is not
generally solvable are not very realistic programs)

Arne

 

[Arne Vajhøj]

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

Software engineer is a widely used title in the US.

Try search on dice.com or monster.com !

Arne

 

[Arne Vajhøj]

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

That is a very unscientific and non-engineering way of
thinking.

It can be done is most cases. It will not be done in most cases
for cost reasons.

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

Sure is.

It is a formal science and a basis for all the empirical
sciences.

Arne

 

[Arne Vajhøj]

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

Tens of thousands maybe even hundreds of thousands have that job
title.

Arne

 

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

Most likely yes.

Computer science has proven that it is not possible to do that
for all programs, but it can be done for some programs. If one
is willing to spend the money, then it can be done for most
programs.

(the examples used to prove the haling problem is not
generally solvable are not very realistic programs)

I must add that, since we were talking about softwares that were
developped using formal methods, then you can prove it 100% of the
time.

A standard program may not contain enough informations per se to allow
a proof of its termination. A program using formal methods does
contain enough informations. Much like when a compiler may be
confronted to an undecidable problem unless the programmer gave in its
program enough informations, or "hints".

Alexandre Courpron.

 

[James Kanze]

Not true.

I disagree. It is impossible to make a perfect and totally
reliable anything, as long as it is being made by human beings;
software is no different.

 

[Kai-Uwe Bux]

I disagree. It is impossible to make a perfect and totally
reliable anything, as long as it is being made by human beings;
software is no different.

You are getting philosophical

This is not how "perfect" is used in ordinary language. BTW: people
sometimes get hickups about "true" and "to know", as well, and forget that
they are using these terms on a daily basis in many non-controversal
statements. The same applies to "perfect" and "totally reliable". There is
no reasonable doubt that some things qualify as perfect and that some of
them are man-made; otherwise, we probably wouldn't have a need for those
terms. (Of course, there are many different opinions which things
qualify


Best

Kai-Uwe Bux

 

[yakkan]

The terms come from when computers were huge, room filling things with
radio tubes. They would stop working properly when roaches/insects
entered the structure, hence the term "bugs".

Computer viruses are called that because of their self-replicating and
-spreading characteristics.



And that's not what a sane person tests. It is established that an
Integer, for example, can only hold whole numbers. No *need* to test for
that. On a software project, you don't have to re-develop all the tools,
just like a bridge engineer won't build his own hammers in his garage.

With software, you test that it *behaves* as intended, not that an
integer is an integer.

The example yougive with booleans would be unit-tested, or otherwise at
a "low" level of development. If you have a GUI with 64 check buttons,
you really need to rethink that design. If it is settings, then
they/their effects need to be tested. No way around it.


It usually suffices to make up test cases that cover areas - allowed
inputs, impossible inputs, and wrong inputs (whatever that means within
the project).



That doesn't make it less engineering. Even inventors use engineering
techniques.

I think engineering is about using resources efficiently, to produce
best product with minimum usage of resource. Optimization may be
another keyword which is common in all branches of engineering. For a
particular task if a software gives result in 1 hour and other one in
2 hours we can say one of them is better engineered. OR one program
needs 1GB ram to run smoothly while other one needs 100 mb yet both of
them gives same result. Optimization is a keyword which is common in
all branches of engineering. You can speak for a programe as optimized
or poorly optimized. For example in first person shooter type video
games you need to optimize game engine as if it is poorly optimize it
won't sell because customer always compare it with other games or
other products. If one game runs smoothly with same level of graphics
or resolution while the other one freezes every second than you have a
commercially death product. So IMHO "computer engineering" is a title
that fits good to people working on programming.

 

[Alexander Grigoriev]

Although, as you apply force and acceleration happens, the mass changes,
too...

 

[LR]

On Nov 27, 3:58 am, LR <[email protected]> wrote:

[...]
I'm sorry, but could you please be explicit about which
scientific principle is being applied?

All of them. The results must be reproduceable. The results
must be validated by peer-review.

You seem to be confusing scientific principles with scientific
laws. Scientific principles are what we use to determine
whether something is a scientific law or not. Or whether a
program works or not. Whether a given program works according
to its requirements specifications is, in some ways, a
scientific law, or at least, a proposed scientific law. If we
accept that it works according to scientific principles, we've
applied those principles.

(But of course, there's a lot more to engineering than just
using scientific principles.)

Or not.

Ok, then I'll try to use the phrase scientific laws.

I'm sorry, but could you please be explicit about which
scientific law is being applied?

LR

 

[LR]

LR wrote:

[...]
If I accept the definition given above. But to my mind that
would make "software engineering" a unique thing. Different
from say chemical, mechanical or civil.

Well, the same thing could be said about chemical engineering.
Or electronics engineering. Each engineering discipline is
unique. What makes them "engineering" is that they use a
scientific approach to solving pragmatic problems.

It's a little more than the approach, I think. There's an application
of scientific law (your word).

They all do, including software engineering. That's part of
what makes them engineering.

I reiterate, which scientific law is being applied in the creation of
software? In the way, for example that a civil engineer would apply f=ma
while building a bridge or a mech engineer would apply it while
designing a pressure vessel?

Certainly, but as I've pointed out elsewhere, software
engineering is as rigorous in this regard---perhaps
moreso---than e.g. bridge design, or some of the other
activities you've named.

When an engineer designs a bridge, they may for example try to figure
out how the bridge will react to a given load. They may try this for
various loads. The load limit is determined by physics.

What is the analogous thing for software?

It's sufficient that it takes a double as input, and it is, for
all intents and purposes, impossible to test exhaustively.
People who claim the software is correct because it passes some
test suite aren't engineers. (Nor are people who forego testing
entirely, on the grounds that it can't catch everything.)

No argument there.



[snip]

My understanding was that you were forwarding the opposite
argument; that you'd only accept software engineering as an
engineering discipline if it had such formulas. And of course,
we don't have formulas based on physical strengths (although
things like the big-O notation are related in some ways).

Could you expand on that please.

On
the other hand, the formulas aren't the scientific principle;
the reason which causes the civil engineer to accept them and to
use them is. And there are other "formulas" in software
engineering, to which the same principles can be applied.

But you've corrected me to use the term scientific law. Does the same
reasoning apply?

An aspect of engineering that hasn't been mentionned yet is that
it is continuously evolving. It took real engineering talent to
design the pont du Gard, but a modern civil engineer would
probably not recognize (or even accept as usable) any of the
"engineering" techniques used.

I think that's certainly true of medicine as well, and maybe even law.
Software development has evolved as well, I think, in some ways.

Perhaps one day our understanding of science and the nature of the
universe will evolve to the point where software may be related to
scientific law (again, your word) but at the moment, I beleive it is a
mathematical discipline and I don't think that this will qualify it as a
engineering discipline.

LR