Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Who gets higher salary a Java Programmer or a C++ Programmer?

Reply
Thread Tools

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

 
 
Arne Vajhøj
Guest
Posts: n/a
 
      11-26-2008
LR wrote:
> 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...earch&aq=f&oq=

Arne
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-26-2008
LR wrote:
> Tom Anderson wrote:
>
>> 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?


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

--
Lew
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      11-26-2008
On Nov 26, 12:28 am, Paavo Helde <(E-Mail Removed)> wrote:
> James Kanze <(E-Mail Removed)> kirjutas:


> > (I've worked on some joint French/German projects, and even
> > there, cultural differences created a lot of difficulties.)


> Fascinating, would you care to give an example? (just a
> theoretical interest, I'm neither French nor German).


Well, it affected almost all levels, and part of it was due to
differences in corporate culture. One simple example: the
French use a lot more white space in their coding guidelines.
More importantly, perhaps, were expectations with regards to
personal relationships. It's difficult to describe these in
detail, because of course there was a great deal of personal
variance, and there were a lot of people in both groups who you
might situation "in the middle".

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      11-26-2008
On Nov 26, 1:25 am, Tom Anderson <(E-Mail Removed)> wrote:
> On Tue, 25 Nov 2008, Lars Enderin wrote:
> > Lew skrev:
> >> On Nov 25, 2:41 pm, Lars Enderin <(E-Mail Removed)> wrote:
> >>> I am surprised that Lew hasn't castigated you for writing
> >>> I in lower case.


> >> Nice rhetorical trick. You get to make a grammatical
> >> comment but foist the blame for it off on someone else.


> Is it grammar? I think it's typography.


Or spelling. The line between orthography and typography is
fine.

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


In both, I'd say it's orthography, which can be attached to
grammar, but is also related to typography.

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


Hmmm. I'm having problems relating "modern trendiness" with
"medieval handwriting", but one thing is certain: established
practice in English is to capitalize the nominative first person
singular pronoun, and it has been since the 1700's. The
original motive may have had to do with difficulties in
distinguishing the character in handwriting, but that's really
irrelevant now. The standard practice is to capitalize it, and
neither you nor I have much say about it. Not capitalizing it
is felt as an error by most English readers, and thus hinders
communication. Refusing to capitalize it, for whatever reasons,
can only be attributed to a lack of respect for your readers.

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


The difference, in this case, is that there are numerous
established standards. English orthography contains a lot of
irregularities, and it really could stand some cleaning up, but
you can't just decrete something in your corner, and expect it
to take hold.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      11-26-2008
On Nov 26, 2:00 am, LR <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > On 25 nov, 15:38, LR <(E-Mail 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?


Most of them want just the opposite. If the program should
halt, there's usually no problem in proving it in practice;
proving that it won't is more difficult.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      11-26-2008
On Nov 26, 2:28 am, LR <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Nov 25, 3:38 pm, LR <(E-Mail Removed)> wrote:
> >> James Kanze wrote:
> >>> Software engineering


> >> I am still wondering what the definition of this is.


> >>>> Today, with few exceptions, software development is FAR
> >>>> more art than engineering, and most of us are "software
> >>>> artists" instead of "software engineers". Programs are
> >>>> carefully hand-crafted one line at a time, like an
> >>>> amateur building a bridge out of balsa wood, and not
> >>>> engineered, like an engineering firm building a highway
> >>>> bridge.


> >>> And that is simply false. If a company is doing that,
> >>> their software costs far too much.


> >> Could you please expand on this, how does using software
> >> tools change software development to an engineering
> >> discipline?


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


> >>> There is a certain personal satisfact to be had in knowing
> >>> that you've just delivered a program which actually works.


> >> Do the programs provably work?


> > To some degree.


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


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.

> >> To the same extent that an engineer could "prove" that the
> >> bridge they designed will work?


> > 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.ge...ralsBridge.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. 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. But it's still several orders of
magnitude easier than verifying that you've analysed all
possible physical interactions which might affect a bridge.

> >> What kinds of metrics are used? Does software have a
> >> stress point beyond which it will deform, like the metal in
> >> the bridge will?


> > Seehttp://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"?


Mathematics.

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). But the operative word in your case is "principles",
not just one principle, but more the set of all of them.

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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
courpron@gmail.com
Guest
Posts: n/a
 
      11-26-2008
On 26 nov, 01:59, Tom Anderson <(E-Mail Removed)> wrote:
> On Tue, 25 Nov 2008, (E-Mail Removed) wrote:
>
> [...]
>
> > 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.


I'm talking about using pre/postconditions assertions in conjunction
with other defensive programming techniques, i. e. you use pre/post
assertions for your component and use, between those assertions,
defensive programming techniques that are known to handle all possible
situations in the context you are facing. I brought this up for the
discussion because I believe this kind of programming is more used
than pure DbC. However those techniques are rarely used homogeneously
over the whole development of a large software. In such cases, you
have in one hand the software that is not 100% reliable but, on the
other hand, some components inside the software that are reliable.

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


I would say that's a normal reaction if you didn't hear about DbC
before.
However, between a software that has DbC but a superficial testing
phase, and a project without DbC but a lot of testing, I would choose
without hesitation the former if I wanted reliability.


Alexandre Courpron.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      11-26-2008
On Nov 26, 4:01 am, Arne Vajhj <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > 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.


And it was. Mature doesn't mean that it won't evolve.

> I very much doubt that software engineering is mature.


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


Certainly. That will always be the case.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
courpron@gmail.com
Guest
Posts: n/a
 
      11-26-2008
On 26 nov, 02:00, LR <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > On 25 nov, 15:38, LR <(E-Mail 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.

Alexandre Courpron.
 
Reply With Quote
 
Bent C Dalager
Guest
Posts: n/a
 
      11-26-2008
On 2008-11-25, James Kanze <(E-Mail Removed)> wrote:
> On Nov 25, 7:40*pm, Tom Anderson <(E-Mail Removed)> wrote:
>> 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.
>> (...)

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


Moreover, if bridge engineering is dependant upon software simulation
in order to be proper "engineering", and the software in question
cannot be engineered, then the bridge also cannot be engineered except
by replacing the software simulation with some proper engineering
discipline (scale model testing perhaps).

(Which, of course, isn't in itself an argument for software being an
engineering discipline.)

Cheers,
Bent D
--
Bent Dalager - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://www.pvv.org/~bcd
powered by emacs
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Who gets higher salary a Java Programmer or a C++ Programmer? Sanny C++ 396 12-17-2008 06:13 PM
The Java vs C++ higher salary thread Zjargands C++ 6 11-30-2008 09:54 PM
Average salary for a novice Java Programmer java_killer Java 4 05-09-2008 11:38 PM
Average salary for a novice Java Programmer java_killer Java 0 05-09-2008 06:51 AM
Accessing higher security level from higher security level nderose@gmail.com Cisco 0 07-11-2005 10:20 PM



Advertisments