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

J

James Kanze

Name three.
If a shop does this - uses those methods to prove that their
software works - then i'm happy to call them software
engineers. Ecstatic, in fact - it's a great and wonderful
achievement.
But i believe that the number of such shops is vanishingly
small, and concentrated in a few sectors where the cost is
worth it - real-time control, telecoms, aerospace, defence,
medical devices. It's not a technique that is used for the
common bulk of software - desktop apps, web apps, even
operating systems. Furthermore, i don't believe it can be,
because such systems tend to be complex enough that the cost
of proving correctness would be so astronomical that it
wouldn't be economical.

First, a major part of engineering is being cost effective, and
not over-designing. Complete formal proofs are rarely used, at
least in the fields I've been active in (and that includes
telecoms and locomotive brake systems). Informal proofs,
evaluated during code review, are a normal part of any good
software development process, however. And for what it's worth;
one of the companies I worked for introduced the SEI methods
because of reliability constraints, only to find out that it's
actually cheaper to develop code that way.
 
J

James Kanze

Exactly. The making of software is not, and will never be,
engineering.

Except that it is engineering, in every sense of the word.
The simple reason for this is that software is not
analytically tractable. There's nothing that is to software
as Newton's laws, or all the other physical discoveries of the
nineteenth century, are to mechanical engineering. And because
software is manifestly vastly nonlinear, it's quite clear
that, barring a titanic theoretical breakthrough, there never
will be.
With a bridge, i can build a system of linear equations that
describes it, not perfectly, but to a high degree of accuracy,
and i can put those into a computer and solve them, and show
that the bridge won't fall down when trains run across it. My
calculations are only approximations, although pretty accurate
ones, but i can add a safety factor to cover that. I can say
with a great deal of confidence that the bridge as designed
will work.

I fear you don't really understand what engineering is about.
In a very real sense, most software is more provable than any
bridge, because all possible inputs are known, and nothing else
is relevant. Despite your impressions, bridge designers still
have to guess concerning a number of issues, and bridges do
fail. The number of unknows in the equations necessary to
calculate them exactly puts the calculations beyond the
possibility of the most powerful computers today. (And of
course, the reliability of those calculations is not more than
the reliability of the programs which do them.)
 
T

Tom Anderson

Lew skrev:

Is it grammar? I think it's typography. 'I' and 'i' are the same word,
surely, just as awesome and AWESOME are. But the question of where
capitalisation stands in relation to grammar is interesting - failing to
capitalise an acronym or a proper name, or the start of a sentence, is
wrong, isn't it? But is it grammar? In German, it definitely is. In
English? I'm not so sure.

Anyway, this business of capitalising 'i' is modern trendiness with which
i have no truck. People started doing it because lowercase 'i' was a bit
indistinct in medieval handwriting, and it made it clearer. But like the
double spacing after a full stop that people used with typewriters, it's a
convention that's outlived its usefulness, and can now be laid to rest.

Nonetheless, Lew makes clear, in a subtle way, that he considers this
incorrect. But this is merely one of many points on which we consider each
other incorrect!
Sorry. Actually, I meant to write a private comment by mail, but I was
careless. Maybe that would have been equally bad, though?

That would have been bitchy, and i would have disapproved.

..li isn't Lithuania, it's Liechtenstein. Lithuania is .lt. And that's not
the FORTRAN [1] < operator, that's .lt followed by a full stop. And Latvia
is .lv - people sometimes guess that too.

Anyway, i don't have any actual connection to Liechtenstein, although i'm
sure it's a fine country. I'm a user of a machine which sails the internet
under a TLD of convenience. I don't know why the sysops picked li. Sysops
move in mysterious ways, their wonders to perform.

tom

[1] Or, according to certain obstinate historians, Fortran.
 
Joined
Nov 25, 2008
Messages
17
Reaction score
0
no metter which one you choose,you'll having a dish in the feature!Good luck with you.Even I use Java,but I also learn other language,just like:C,C++,Python and so on.if your envirement changed ,you have to chang,becase "shi zhe sheng cun!",It's a chinese "ge yan"!
 
L

LR

AL said:
I can't lay my hands on the issue of PE magazine where this is discussed
in some detail, but I can say the argument has risen to the level of
proposing standards for licensing.

My understanding is that in some parts of the US and I think perhaps
Canada it has gone beyond the a discussion. Probably other places.
Speaking as a PE and someone involved
in software development for close to 30 years (now retired) I don't
understand your resistance to the notion that software can be
engineered, unless you are of the opinion we engineers lack the creative
spark for such innovative work? :)

No, not at all, in fact, not the least little bit. I'll be happy to
repeat my fundamental question. I've been told, by engineers if that's
relevant, that engineering is the application of scientific principle.
What scientific principle is being applied in the development of software?

LR
 
T

Tom Anderson

I don't have the numbers and you don't have them either. In particular,
I wouldn't use the adverb "vanishingly". Furthermore, any software
developper that adopts a defensive programming approach and uses
assertions as pre/postconditions starts to be on the path of DbC. Such
programmers can develop reliable components because of sufficient
defensive programming techniques.

No, sorry, DbC not accompanied by proof - as i understand (perhaps
wrongly, and please correct me if so) is normal for mainstream DbC, for
instance in Eiffel - is not any kind of analogue of proven correctness.
It's no more than a very regular and powerful testing mechanism. I'm all
for testing, and i think DbC-style pre/postcondions are a great idea, but
they do not constitute proof.
If you want to "prove" by DbC a large, existing software, then yes, it
can be costy. If you start a project and use DbC from the beginning of
the development cycle, you can actually make savings because of the
testing phase removal/reduction I mentioned earlier.

If anyone tried to sell me a project with a superficial testing phase on
the grounds that they'd designed it by contract, i would not be impressed.

tom
 
L

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?

LR
 
L

LR

James said:
What tools are you talking about? I thought the issue was
software engineering; software developed using a established
methodology which is known to work. Engineering, and not pure
research.

I thought that you had mentioned the use of tools in connection with
this, if not, sorry.

To some degree.

In that case I think the answer is "no". Software is not like a bridge.

The that extent, yes. But I suspect you're over-estimating
just how certain it is that a bridge will work. There've been
serious bridge failures as well.

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.


See http://www.sei.cmu.edu/. I obviously can't stuff a four
year course in software engineering into a web article.

No, I agree that would be difficult. I think I've visited that site in
the past. However, I've always thought that Computer Science was a
branch of Mathematics, and I've been told by several engineers that
engineering is the application of scientific principle, so if you don't
mind, even though you can't do the full four years here, I was wondering
if you could take a shot at answering what I think is a simple question
with what might be a quick answer: What scientific principle is being
applied in "software engineering"?

LR
 
L

LR

James said:
Except that it is engineering, in every sense of the word.

I'd like to repeat my question here. I've been told by engineers that
engineering is the application of scientific principle. What scientific
principle is being applied in "software engineering"?

LR
 
L

LR

Tom said:
Still, i call myself a 'software engineer' because it sounds more
high-status than 'programmer', and i go to a lot of parties with lawyers
and academics and the like.

IANAL, but since you're calling yourself a "software engineer" might I
ask what jurisdiction you do that in?

LR
 
L

Lew

James said:
And of course, some people will not be competent no matter how
much experience, and most will be competent after a lot less
than 20-30 years. The first five years make a big difference,
but if I judge from my own case, most of what I learned more
than five years ago it irrelevant today.

I learned a number of useful skills to be a software developer from being a
restaurant busboy a few decades ago. That was a lot about customer service,
teamwork, work ethic and how to treat managers.

Much of my considerable competence as a programmer no doubt stems from playing
WFF'n'Proof at age eight, a dice game of symbolic logic. I also had a game
called "Dr. Nim", a three-bit (that is, three flip-flops) marble-powered
computer that could kick your ass at nim. It introduced me to logic states,
algorithms and binary arithmetic. (I had to stop playing when I lost my marbles.)

In college I sought mentors for my programming classes who were true geeks;
they taught an attitude and way of thinking that continues to serve me well.

There are meta-skills that never fade or lose power.
 
L

Lew

Tom said:
Anyway, this business of capitalising 'i' is modern trendiness with

If by "modern" you mean for several hundred years.
which i have no truck. People started doing it because lowercase 'i' was
a bit indistinct in medieval handwriting, and it made it clearer. But
like the double spacing after a full stop that people used with
typewriters, it's a convention that's outlived its usefulness, and can
now be laid to rest.

Nonetheless, Lew makes clear, in a subtle way, that he considers this
incorrect. But this is merely one of many points on which we consider
each other incorrect!

I suppose that depends on whether you choose to adhere to the typographical
convention in English that has been set for so many centuries. The notion of
"proper" grammar has detractors, but nevertheless serves well to indicate a
level of erudition. Not spelling "I" in the mandated upper case is jarring to
someone used to the rules, which really are the rules BTW, just as much as
those for proper nouns, and should be corrected in any formal publication.

I did not correct Tom, except occasionally as a review of the archives might
reveal, because he is clearly an intelligent, erudite writer who has made a
conscious decision to flout the rule. I have to respect that.
 
A

Arne Vajhøj

LR said:
No, not at all, in fact, not the least little bit. I'll be happy to
repeat my fundamental question. I've been told, by engineers if that's
relevant, that engineering is the application of scientific principle.
What scientific principle is being applied in the development of software?

All the principles from the science called computer science.

:)

Arne
 
A

Arne Vajhøj

LR said:
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).

Arne
 
G

Gennaro Prota

LR wrote:
[...]
and I've been told by several engineers that
engineering is the application of scientific principle, so if you don't
mind, even though you can't do the full four years here, I was wondering
if you could take a shot at answering what I think is a simple question
with what might be a quick answer:

It's one of those questions made more to give semblance of
asking something intelligent than to really understand things.
What scientific principle is being applied in "software
engineering"?

The fourth law of thermodynamics :)

Since you were after a quick answer, is quoting the IEEE
610.12-1990 definition of "software engineering" enough?

(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to
software.
(2) The study of approaches as in (1).

Cf. the definition of "engineering" in the same standard.

It's not something free of disputes, but you'd have to
acknowledge that the Institute of Electrical and Electronics
Engineers has something to say about "engineering", wouldn't
you?
 
A

Arne Vajhøj

James said:
The revolution in software development took place long ago (by
the usual measures in this field). Software engineering is a
mature discipline today, even if there are still a lot of
retrograde shops which don't understand this.

I am sure the roman engineers also considered bridge building
a mature discipline.

I very much doubt that software engineering is mature.

It has come a long way, but there are still lots of open road ahead.

Arne
 
L

LR

Gennaro said:
LR wrote:
[...]
and I've been told by several engineers that
engineering is the application of scientific principle, so if you don't
mind, even though you can't do the full four years here, I was wondering
if you could take a shot at answering what I think is a simple question
with what might be a quick answer:

It's one of those questions made more to give semblance of
asking something intelligent than to really understand things.


The fact that an assertion is made does not mean that the assertion is
true, so please allow me to judge my own intentions: No. I asked because
I want an answer to this question. One has not been forthcoming. Your
response is helping me to draw a conclusion as to why.

The fourth law of thermodynamics :)

Does the smiley imply that the fourth law is a scientific principle that
does in fact _not_ apply to "software engineering"?

I wonder if there is a scientific principle that is applied in the
creation of software.

Since you were after a quick answer, is quoting the IEEE
610.12-1990 definition of "software engineering" enough?

(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to
software.
(2) The study of approaches as in (1).

Cf. the definition of "engineering" in the same standard.

It's not something free of disputes, but you'd have to
acknowledge that the Institute of Electrical and Electronics
Engineers has something to say about "engineering", wouldn't
you?

In that case, please allow me to paraphrase what you wrote above.

It's one of those answers made more to give semblance of saying
something intelligent than to really understand things.

I'd say this is a definition that is at variance with all the other
answers I've gotten from engineers over the past apprx 35 years.

Why is that?

LR
 
L

LR

Arne said:
LR said:
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

LR
 
L

Lew

No, not at all, in fact, not the least little bit. I'll be happy to
repeat my fundamental question. I've been told, by engineers if that's
relevant, that engineering is the application of scientific principle.
What scientific principle is being applied in the development of software?

Logic, a branch of mathematics, for one. Not that I agree that you have
defined engineering completely, or even correctly. Also, algorithms and data
structures. Before you say those aren't scientific principles, you'll have to
let me know what you mean by "science", which I understand to be the formal
and rigorous study of phenomena to elicit the underlying structures and
relationships pertaining to the area of study. The formal study of the
underlying structures and relationships of software is called "computer
science". So the scientific principles of software engineering are the
principles of computer science.

Just because an engineering discipline is relatively young and not necessarily
well developed doesn't mean that it's not engineering.

Engineering is also about the way in which one applies "scientific" principles
to solve real-world problems. While the structural physics of buildings or
bridges differs from the structural rules of software, there is a cohesive and
formalizable set of principles to software. The deliberate and knowledgeable
attempt to apply those principles, i.e., the principles of computer science,
qualifies as engineering.
 
L

Lew

In that case, please allow me to paraphrase what you wrote above.

That would not be fair. He quoted a noted and authoritative source for
definitions of engineering disciplines that categorizes an endeavor as
"software engineering". That is evidence.
It's one of those answers made more to give semblance of saying
something intelligent than to really understand things.

Providing an authoritative definition from a professional organization with an
acknowledged expertise in the area is not a "semblance of something
intelligent" but the real thing which does promote an ability "to really
understand things".
I'd say this is a definition that is at variance with all the other
answers I've gotten from engineers over the past apprx 35 years.

Let's see, a definition from the professional organization of engineers whose
business includes software engineering is at variance with the answers you
claim to have gotten from engineers (not cited by name, I notice) over "apprx"
35 years. I think I'll align with the definition offered by the professional
society whose business it is over the unattributed anecdotal non-evidence of
your hearsay.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top