Who gets higher salary a Java Programmer or a C++ Programmer?
Sanny
programs in both languages.
I get a lot confused as many times I use Java code in C++ and C++ code
in Java.
So I have descided to only work in one Language.
Both C++ and Java has their importance.
What language should I master. I just want to know who gets higher
salary a Java Programmer or a C++ Programmer?
Because Learning both creates confusions So I have to Choose the best
among them.
Whose future is better a Java Programmer or a C++ Programmer? What
else should I learn for a good Career. Should I learn C# which is very
easy?
How much max salary per Annum I can get If I become a C++ Expert.
and How much max salary per Annum I can get If I become a Java Expert.
Experts in fields, Please Advice.
Bye
Sanny.
Peter Duniho
> I have little experience in both Java and C++. I have designed a few
> programs in both languages.
>
> I get a lot confused as many times I use Java code in C++ and C++ code
> in Java.
>
> So I have descided to only work in one Language.
Probably a good idea, for now.
> Both C++ and Java has their importance.
Yes.
> What language should I master. I just want to know who gets higher
> salary a Java Programmer or a C++ Programmer?
Difficult or impossible to say. Too many variables are left out of your
question.
> Because Learning both creates confusions So I have to Choose the best
> among them.
Yes, don't learn both at the same time. But, also don't plan to learn
just one.
There are a lot of things about programming in either that are specific to
neither. OOP is OOP, for the most part. Different languages have
different "flavors", but for the most part, basic OOP fundamentals will be
the same in either.
C++ is a somewhat lower-level language, while at the same time offers in
some ways much more complex behaviors than Java. Because of that, I'd
recommend learning Java first, just because it's likely to be somewhat
easier. Not that becoming a Java expert is easy, but there are certain
things about Java that restrict you in ways that are helpful for the
beginner.
> Whose future is better a Java Programmer or a C++ Programmer? What
> else should I learn for a good Career. Should I learn C# which is very
> easy?
Frankly, as of the last couple of months or so, if you have a job that
pays for your food, clothing, and shelter, consider yourself fortunate.
This is only going to be even more true in the coming months and years.
As for your other questions...
The programmer who is paid the highest is the one with the most
experience, who takes their profession seriously, and who continues to
learn new things in their field.
I doubt a programmer who thinks C# is any easier than Java is going to be
one of those highest-paid programmers. :) C# has simplified some things
as compared to Java, but it's added new features beyond Java as well, and
continues to do so. C# 1.0 might have literally been easier than Java,
but the fact is that both languages are reasonably complex and I don't
think there's any useful way to say that one is "easier than" the other.
> How much max salary per Annum I can get If I become a C++ Expert.
>
> and How much max salary per Annum I can get If I become a Java Expert.
In programming, there is practically no upper bound. But you won't get
paid the big bucks unless you are very skilled.
I doubt that there's any significant difference in pay between C++ and
Java programmers, but if there is, I'd guess Java pays less just because
it is currently the more popular language, making it easier to find
skilled programmers who use that language. More supply for a given
demand, lower price. But, since that guess doesn't address the demand
side of the equation, it's not worth much. :)
The fact is, salaries in the field of programming are in constant flux,
according to what technologies are most in use and what the work-force
looks like in terms of numbers. Focusing on one language or the other
based on expected salary is not likely to be productive. Learn
_programming_, learn lots of different languages, and then look for the
job that suits you the best (which may be the highest-paying one, for
someone with mercenary tendencies such as yourself :) ).
Pete
Michael Sgier
Robert Klemme
> What language should I master. I just want to know who gets higher
> salary a Java Programmer or a C++ Programmer?
IMHO this is the wrong question. You can achieve mastery in any of
those languages and for any of those there are well paid jobs. If
you're in the market for money only though, I doubt you have the proper
motivation to achieve mastery.
> Because Learning both creates confusions So I have to Choose the best
> among them.
There is no "best" language. Every tool has its strengths and
weaknesses. The question would be "best for what?"
> Whose future is better a Java Programmer or a C++ Programmer?
You must imagine that the community as a form of crystal ball. I am
afraid I have to inform you that this is not the case.
> What else should I learn for a good Career.
Define "good career".
> Should I learn C# which is very easy?
Without knowing C# too much I'd say this is a misconception. C# has a
similar level of complexity at least as Java because it is object
oriented and has a standard library of significant size AFAIK.
Note also that knowing the syntax, constructs and library of a language
not necessarily makes you an expert software developer. You also have
to be aware of all sorts of design level practices that are quite
independent of programming languages.
> How much max salary per Annum I can get If I become a C++ Expert.
>
> and How much max salary per Annum I can get If I become a Java Expert.
You would at least have to provide the bit of information in which
region(s) you are willing to work.
Cheers
robert
James Kanze
> What language should I master. I just want to know who gets
> higher salary a Java Programmer or a C++ Programmer?
Neither. The commercial person who sells the final product
makes the most money.
> Because Learning both creates confusions So I have to Choose
> the best among them.
There is no "best", and if learning both creates confusions, you
should probably look for a different profession; I regularly use
four or five different languages (C++, Java, AWK, Unix
shell...).
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Joshua Cranmer
> I get a lot confused as many times I use Java code in C++ and C++ code
> in Java.
>
> So I have descided to only work in one Language.
Poor choice. Most employers would rather employ the programmer who can
utilize multiple programming languages over one who will choose to use
but a single language.
> What language should I master. I just want to know who gets higher
> salary a Java Programmer or a C++ Programmer?
Any difference in salary between the two would be dwarfed by other
factors, such as seniority, etc. In other words, statistically speaking,
neither.
If you want to try for the big bucks, I hear COBOL is coming back in vogue.
> Because Learning both creates confusions So I have to Choose the best
> among them.
There is no "best" language. For the most part, languages are
fundamentally incomparable. Every single programming language has its
strengths and weaknesses; the goal is to match up a programming language
to the task.
> Whose future is better a Java Programmer or a C++ Programmer? What
> else should I learn for a good Career. Should I learn C# which is very
> easy?
Ideally, you should be well-rounded as a programmer. This means you
should be able to code in C/C++ and Java. You'll probably want some
functional languages under your belt; Python and Perl are two good
dynamic programming languages to tackle, although Ruby seems to be the
next "hip" language. The list goes on.
> Experts in fields, Please Advice.
Another piece of advice would be to brush up on rules of punctuation,
capitalization, and grammar in general.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Nico
> I just want to know who gets higher
> salary a Java Programmer or a C++ Programmer?
None of them.
Programmer is the lowest level in the hierarchy of an IS
In Europe, a baker has a better salary...
Lew
>> I get a lot confused as many times I use Java code in C++ and C++ code
>> in Java.
>>
>> So I have descided to only work in one Language.
Joshua Cranmer wrote:
> Poor choice. Most employers would rather employ the programmer who can
> utilize multiple programming languages over one who will choose to use
> but a single language.
Real programmers can do FORTRAN programming in any language.
Sanny wrote:
>> What language should I master. I just want to know who gets higher
>> salary a Java Programmer or a C++ Programmer?
Joshua Cranmer wrote:
> Any difference in salary between the two would be dwarfed by other
> factors, such as seniority, etc.
Literacy, ...
> In other words, statistically speaking, neither.
Do you have evidence for those statistics?
> If you want to try for the big bucks, I hear COBOL is coming back in vogue.
Never went out of vogue.
Sanny wrote:
>> Because Learning both creates confusions So I have to Choose the best
>> among them.
If you are applying for jobs where English is a relevant skill, you will
improve your earning power by increasing your mastery of that language.
Non-programming skills often count for more than one's technical abilities
when climbing the corporate rungs.
Some might look at your random capitalization of different words in English
and wonder if you are sensitive to case sensitivity in Java. It is a shame,
perhaps, that your command of English might block someone's ability to
perceive your command of programming, but that is a reality in the work world.
Joshua Cranmer wrote:
> There is no "best" language. For the most part, languages are
> fundamentally incomparable. Every single programming language has its
> strengths and weaknesses; the goal is to match up a programming language
> to the task.
Which is exactly what makes Java the best programming language.
;-) for those who insist on explicit irony markers.
Sanny wrote:
>> Whose future is better a Java Programmer or a C++ Programmer? What
>> else should I learn for a good Career. Should I learn C# which is very
>> easy?
You should, but it isn't easy.
Joshua Cranmer wrote:
> Ideally, you should be well-rounded as a programmer. This means you
> should be able to code in C/C++ and Java. You'll probably want some
> functional languages under your belt; Python and Perl are two good
> dynamic programming languages to tackle, although Ruby seems to be the
> next "hip" language. The list goes on.
Sanny wrote:
>> Experts in fields, Please Advice.
Joshua Cranmer wrote:
> Another piece of advice would be to brush up on rules of punctuation,
> capitalization, and grammar in general.
This is not parochialism, but a necessity when one is forced to communicate in
any language. It is vitally necessary in written communications; face to
face, people will forgive accents and unusual constructions, but in written
communication there is little tolerance for fundamental errors, and less
reason for there to be any.
--
Lew
Arved Sandstrom
news:gg983k$k93$1...@news-int2.gatech.edu...
> Sanny wrote:
>> I get a lot confused as many times I use Java code in C++ and C++ code
>> in Java.
>>
>> So I have descided to only work in one Language.
>
> Poor choice. Most employers would rather employ the programmer who can
> utilize multiple programming languages over one who will choose to use but
> a single language.
>
>> What language should I master. I just want to know who gets higher
>> salary a Java Programmer or a C++ Programmer?
>
> Any difference in salary between the two would be dwarfed by other
> factors, such as seniority, etc. In other words, statistically speaking,
> neither.
I'd have to agree. Once you factor out the general state of the economy
(i.e. are IT employers hurting for developers or is there a surfeit of
developers?) and the effects of geography (i.e. your salary is influenced
very heavily by where you live), I can't think of a market I've been in
where I sensed that developers in one of the following groups - Java/J2EE,
C#/.NET, or C/C++ - were paid significantly more or less than their peers in
the other two.
As an individual, _who_ you work for is the other major factor besides
seniority in determining compensation. Are you a consultant/contract
programmer? Do you work as an employee of a private software house? Or do
you work for the government?
Seniority and ability are intertwined, and feature in varying proportions as
factors in determining salary depending on who you work for.
AHS
Roedy Green
<soft...@hotmail.com> wrote, quoted or indirectly quoted someone who
said :
>What language should I master. I just want to know who gets higher
>salary a Java Programmer or a C++ Programmer?
To me that would be well down on my list of considerations. I ask
questions like this:
1. which language do I enjoy coding more? What counts is how much I
enjoy my life. I spend a LOT of it coding.
2. which language will let me tackle more interesting projects. For
than reason COBOL is out. I have no interested in maintaining payroll
programs. If I wanted to make money, I would learn the arcane art of
Unix system administration.
3. Which language will leave my options open where I work. I don't
want to get stuck in some place I hate. I want to be able to go
anywhere. Which language is become more accepted. Which are becoming
obsolete?
4. Which languages offer work from home?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Your old road is
Rapidly agin'.
Please get out of the new one
If you can't lend your hand
For the times they are a-changin'.
Arne Vajhøj
Salary depends on where work, your experience and your general
programming skills (not language and technology specific).
The languages and technologies you know should have much less
impact on salary level.
You should be aware that tools, languages and technologies comes
and goes, so over a life long career you will have to work
with multiples of those no matter what.
Arne
Arne Vajhøj
> C++ is a somewhat lower-level language, while at the same time offers in
> some ways much more complex behaviors than Java. Because of that, I'd
> recommend learning Java first, just because it's likely to be somewhat
> easier.
It is much easier to learn Java than C++ as first language.
But it is also much easier to go C++ -> Java than Java -> C++.
So I am not convinced that learning Java first and C++ later
is in total easier than learning C++ first and Java later.
Arne
Arne Vajhøj
> Sanny wrote:
>> I get a lot confused as many times I use Java code in C++ and C++ code
>> in Java.
>>
>> So I have descided to only work in one Language.
>
> Poor choice. Most employers would rather employ the programmer who can
> utilize multiple programming languages over one who will choose to use
> but a single language.
I think the bad thing of focusing on only one language is the
lack of perspective. Learning multiple languages gives a much
better perspective on things.
Job wise I think the majority either hires for a specific skill set
or hire someone they think is bright enough to learn what is needed.
Too few managers care about whether the new hire will be easy to
move to another department/project that uses another language and
what will happen in 5 or 10 years when the company changes
technology.
Arne
Arne Vajhøj
> On Sat, 22 Nov 2008 00:29:12 -0800 (PST), Sanny
> <soft...@hotmail.com> wrote, quoted or indirectly quoted someone who
> said :
>> What language should I master. I just want to know who gets higher
>> salary a Java Programmer or a C++ Programmer?
>
> To me that would be well down on my list of considerations. I ask
> questions like this:
>
> 1. which language do I enjoy coding more? What counts is how much I
> enjoy my life. I spend a LOT of it coding.
>
> 2. which language will let me tackle more interesting projects. For
> than reason COBOL is out. I have no interested in maintaining payroll
> programs.
I am convinced that there are interesting projects in any language.
> If I wanted to make money, I would learn the arcane art of
> Unix system administration.
I am not sure Unix sys admin is arcane.
> 3. Which language will leave my options open where I work. I don't
> want to get stuck in some place I hate. I want to be able to go
> anywhere. Which language is become more accepted. Which are becoming
> obsolete?
History shows that salaries are usually not bad for languages and
technologies becoming obsolete. Sure demand goes down, but so does
supply.
> 4. Which languages offer work from home?
Unlikely to be correlated with programming language.
Arne
Arne Vajhøj
> Sanny wrote:
>> How much max salary per Annum I can get If I become a C++ Expert.
>>
>> and How much max salary per Annum I can get If I become a Java Expert.
>
> Salary depends on where work, your experience and your general
> programming skills (not language and technology specific).
>
> The languages and technologies you know should have much less
> impact on salary level.
The only specific skill set that seems to have an
above average salary level is SAP knowledge !
Arne
Peter Duniho
> Peter Duniho wrote:
>> C++ is a somewhat lower-level language, while at the same time offers
>> in some ways much more complex behaviors than Java. Because of that,
>> I'd recommend learning Java first, just because it's likely to be
>> somewhat easier.
>
> It is much easier to learn Java than C++ as first language.
"much" vs "somewhat"...same difference. I agree with either statement.
> But it is also much easier to go C++ -> Java than Java -> C++.
I'm not sure of that. I've seen a lot of people get frustrated and
tripped up by differences between the languages when they try to move from
C++ to Java.
A big part of the problem is that they _think_ they've learned C++, but in
reality they don't have a firm grasp of what's really going on. Then they
get to Java, and their misconceptions only slow them down further.
But, let's assume for the moment that it's unequivocably true that
learning Java after C++ is easier than the other way around. The fact is,
that's not a complete analysis of the situation, because it ignores the
up-front cost of learning each language without knowing the other.
The statement "it is also much easier to go C++ -> Java than Java -> C++"
basically assumes two values L1 and L2, where L1 is the cost of learning
Java after having learned C++ and L2 is the cost of learning C++ after
having learned Java, and asserts that L1 < L2. But there are two other
values, L3 and L4, which are the costs of learning Java first, and of
learning C++ first. The real question isn't whether L1 < L2, but whether
L1 + L4 < L2 + L3. Even if L1 < L2, if L4 is greater than L3 by at least
the difference between L1 and L2, the total cost is still lower learning
Java first.
And, given that Java is not only much easier than C++ to learn, it still
teaches one the same basic OOP principles you'd have to learn in C++ as
well, it could very well be that learning Java first is more efficient.
After all, in flight training, even though it is easier to fly a
single-engine airplane if you already know how to fly a twin-engine
airplane, hardly anyone ever tries to learn in a twin-engine airplane
first. It's still more efficient to start in the easier-to-fly airplane,
and then move up to the twin once you've got the fundamentals down.
> So I am not convinced that learning Java first and C++ later
> is in total easier than learning C++ first and Java later.
I'm not convinced that there's a clear advantage one way or the other. I
think there will always been room for equivocation, given the vast
variability of programming students.
But, inasmuch as there may be a measurable difference, I do know which
will get a person programming productively sooner (Java). In additon,
there will still be advantages to learning and using C++ later, but the
fundamental OOP principles will be easier to learn in the context of the
simpler, stricter language than in the more complex, more difficult one.
Pete
Joshua Cranmer
> On Sat, 22 Nov 2008 17:43:35 -0800, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> But it is also much easier to go C++ -> Java than Java -> C++.
>
> I'm not sure of that. I've seen a lot of people get frustrated and
> tripped up by differences between the languages when they try to move
> from C++ to Java.
From observation of other students in classes (my school's curriculum,
like most, started with Java), the single biggest trouble people had in
trying to learn C/C++ was pointers. Classes never got around to
templates (then again, the introductory courses barely covered generics
and presumably ignored all the new features in Java 5 [1]), so I can't
say how much that would cause people to struggle. I have also
observed--with a different group of people, so the results aren't really
comparable--that some people also tend to struggle with Java's
pass-by-value and how it affects Object references.
To me, it seems like someone going from C++ to Java would be able to
quickly understand that an Object in Java is roughly equivalent to
Object* in C++, more quickly than the people going the other way to
learn pointers. The inequivalence of char[] and String may also snag
some people, but I'm not sure how hard people would find it.
>> So I am not convinced that learning Java first and C++ later
>> is in total easier than learning C++ first and Java later.
>
> I'm not convinced that there's a clear advantage one way or the other.
> I think there will always been room for equivocation, given the vast
> variability of programming students.
In other words: The average difference in skill level between learning
Java then C++ and learning C++ then Java is less than the standard
variability in learning the two languages?
> But, inasmuch as there may be a measurable difference, I do know which
> will get a person programming productively sooner (Java). In additon,
> there will still be advantages to learning and using C++ later, but the
> fundamental OOP principles will be easier to learn in the context of the
> simpler, stricter language than in the more complex, more difficult one.
One theory that has been espoused is to start people off of neither--my
university does the first course in Python and my high school considered
it. I can't speak if it has any benefits, though.
[1] This is speculation since I skipped all introductory CS courses. I
cannot say for certain the content of anything below a Data Structures &
Algorithms course. On the other hand, my observations of classmates are
all going to be for people intent on continuing programming (my school
required the introductory course).
Patricia Shanahan
> I have little experience in both Java and C++. I have designed a few
> programs in both languages.
>
> I get a lot confused as many times I use Java code in C++ and C++ code
> in Java.
>
> So I have descided to only work in one Language.
That is a good plan in the short term, but don't think in terms of
picking one language to use for your whole career. There is no way to
know which languages will be popular in 40 years time.
...
> How much max salary per Annum I can get If I become a C++ Expert.
>
> and How much max salary per Annum I can get If I become a Java Expert.
High end programmer salaries depend on a lot of things, such as general
computer science knowledge, programming skill, luck, leadership skill,
and domain knowledge. I don't think choice of first language to learn is
particularly significant.
Knowing only one language would be a handicap, because it would exclude
you from some of the big decisions, such as which language or languages
to use for a project. You would be limited to projects that are strongly
committed to your chosen language.
For the immediate decision of which language to learn first, you could
look at job ads in the area where you live, or would like to live, and
see what skills are being sought.
Patricia
Sherm Pendley
> I've seen a lot of people get frustrated and
> tripped up by differences between the languages when they try to move
> from C++ to Java.
I think that can be more generalized though - people tend to get
frustrated and tripped up when they move from their first language to
their second. They don't have the breadth of experience they need to
understand the difference between concepts and syntax.
Additional languages beyond that tend to be much easier.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Matthias Buelow
> What language should I master. I just want to know who gets higher
> salary a Java Programmer or a C++ Programmer?
COBOL makes the most, I hear.
Martin Gregorie
> Job wise I think the majority either hires for a specific skill set or
> hire someone they think is bright enough to learn what is needed. Too
> few managers care about whether the new hire will be easy to move to
> another department/project that uses another language and what will
> happen in 5 or 10 years when the company changes technology.
>
IME that's nothing to do with the manager who needs the new hire: the
initial hiring task gets given to HR who know nothing about programming
or programming skills but do know how to match acronyms and names on the
manager's skills list with those on a CV. The same applies to recruitment
agencies. The result is that the candidates who get interviewed are
simply those whose CVs get the most hits from what's little more than a
clerical matching exercise.
IOW the manager may know what he wants in the way of transferrable skills
but this gets dropped on the floor by the agency and HR people because
they don't understand IT. The current habit of condensing CVs to one or
two pages and concentrating only on recent experience just exacerbates
the problem.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Ken T.
> 4. Which languages offer work from home?
I've got to ask.. I've tried this alternative using places like Guru.com
to get jobs and I've found I just can't make any money and the clients
are not the kind of clients you want. They want a lot of work for very
little money.. even work for free in some cases. I want to make my
clients happy, but I need to get paid for my time and this just doesn't
seem to work out well.
How do you get jobs where you get to work from home without having to
charge the same rates a person in Deli will charge.
--
Ken T.
I find it rather easy to portray a businessman. Being bland, rather
cruel and incompetent comes naturally to me.
-- John Cleese
Arne Vajhøj
> On Sat, 22 Nov 2008 15:42:04 -0800, Roedy Green wrote:
>> 4. Which languages offer work from home?
>
> I've got to ask.. I've tried this alternative using places like Guru.com
> to get jobs and I've found I just can't make any money and the clients
> are not the kind of clients you want. They want a lot of work for very
> little money.. even work for free in some cases. I want to make my
> clients happy, but I need to get paid for my time and this just doesn't
> seem to work out well.
>
> How do you get jobs where you get to work from home without having to
> charge the same rates a person in Deli will charge.
Well as you have noticed then rentacoder/elance/guru/whatever
is not the place to go.
Find a big company that have found out that office space is
expensive !
Arne
Sanny
> to get jobs and I've found I just can't make any money and the clients
> are not the kind of clients you want. They want a lot of work for very
> little money.. even work for free in some cases. I want to make my
> clients happy, but I need to get paid for my time and this just doesn't
> seem to work out well.
At these places only small companies or business owners come. And big
company with years work contact developing companies directly.
At http://www.GetClub.com/Experts.php you can tell your expertise and
get work from home work. You only get small orders in such places. As
large work people choose already established companies instead of
giving work to strangers who may spoil the work.
Bye
Sanny
Lew
Or that get incentives from their government(s) to reduce pollution.
I've seen many people get to work from home in large companies. There are
often conditions - one can work on a contract basis rather than directly for
the company, one can coordinate with international teams from disparate time
zones, one can work just part of one's schedule from "home" and part at "the
office". Quite frequently working from "home" means reliably working far more
than forty hours per week, or not reliably working at least forty.
What is the fascination with working from home anyway? I live fifty miles
from my job and still prefer to go to the office to work. Then again, it's a
team environment and interaction with colleagues is an important component of
my work.
A hypothetical job interview:
INTERVIEWER: What sort of work conditions do you favor?
INTERVIEWEE: I prefer to work from home and get paid via direct deposit.
ER: Is that all?
EE: I require a six-figure salary, four weeks leave per year, fully-paid
medical with dental, and tuition reimbursement for my on-line college studies.
ER: How about two weeks annually at the corporate condo in the Mediterranean,
a company-paid Mercedes and an annual bonus of 50% of salary?
EE: You're kidding!
ER: Well, yes, but you started it!
--
Lew
Dress code: Superman® jammies and a beer helmet.
Lew
Computer languages, indeed, computer programming is a minority part of the
value equation on which one's compensation is based. You need to know about
far more than coding to make the big bucks.
One $300/hour consultant I knew, and she was worth every penny, was an expert
on data warehousing, its data architecture, and a particular DMBS product for
data warehousing (Red Brick - very powerful). She had years of experience in
data architecture and administration behind her before she became such a
consultant.
Knowing how, say, an enterprise system comprising multiple nodes hangs
together - mainframes, smaller machines, gateways, yada, yada - hangs
together, and how to get the darn thing to deploy all its queues and beans and
monitoring packages and storage arrays and ... that's where one provides
value. Mere programmers are a dime a dozen.
--
Lew
jason.c...@gmail.com
> I have little experience in both Java and C++. I have designed a few
> programs in both languages.
>
> I get a lot confused as many times I use Java code in C++ and C++ code
> in Java.
>
> So I have descided to only work in one Language.
>
>
> salary a Java Programmer or a C++ Programmer?
>
> among them.
>
> Whose future is better a Java Programmer or a C++ Programmer? What
> else should I learn for a good Career. Should I learn C# which is very
> easy?
The language is irrelevant. A good programmer will get a higher salary
than a crappy one, or at least a programmer that knows how to put
himself in a good position in the company. Any decent programmer would
be able to use either language without much issue.
JC
> How much max salary per Annum I can get If I become a C++ Expert.
>
> and How much max salary per Annum I can get If I become a Java Expert.
>
> Experts in fields, Please Advice.
>
> Bye
> Sanny.
Bill
I would award the higher salary to the person who was well-versed in
**software engineering** (and expect them to be "open-minded", as was
suggested in many of the thoughtful posts above).
Matthias Buelow
> EE: You're kidding!
Yeah, only four weeks holiday.. even the 6-figure salary won't make up
for it.
Arne Vajhøj
I think the joke is US centric.
Arne
Matthias Buelow
> I would award the higher salary to the person who was well-versed in
> **software engineering**
"Software engineering" has its place for some projects in the design
phase but on the whole, (imho) is a terrible buzzword and implies the
wrong things. In the end, (good) software isn't "engineered", like a
bridge, but written, like a book.
Matthias Buelow
> I think the joke is US centric.
Must be, I don't think it's particularly funny.
Arne Vajhøj
4 weeks of vacation is a lot in the US.
Arne
Arne Vajhøj
The process of actually writing the code is a very small part
of developing software for large projects.
So if it is 95% engineering and 5% writing the term sounds
fine to me.
Arne
Lew
On top of that, many companies make it difficult to take the vacation you
nominally should get. Various management theories of "earned value" and
"utilization" penalize a worker for taking personal leave, holidays or sick
time. (One friend of mine was told at his job that sick leave was not to be
taken for scheduled doctor visits.) If you do take all the leave to which you
are "entitled", it hurts your performance review and opportunities for
"advancement". Further on top of that acme, many workers are expected to work
50-65 hours per week when not on vacation, and to conference-call in to status
meetings when they are on vacation, particularly if they're salaried.
Exploitative?
--
Lew
Lew
>> "Software engineering" has its place for some projects in the design
>> phase but on the whole, (imho) is a terrible buzzword and implies the
>> wrong things. In the end, (good) software isn't "engineered", like a
>> bridge, but written, like a book.
Spoken like someone who is not an engineer, and not like someone who engenders
confidence in their programming skills.
Software engineering has its place in every software project, and that place
is everywhere in the software.
In the beginning, middle and end, good software is engineered, like a bridge
and, arguably, like a well-written book. If it is not well engineered, it's
not going to be good software.
There are sound principles behind sound programming decisions. These
principles come down to providing desired functionality with provable
management of risk of defects or system failures, within budgetary
constraints. Some of the more formally-expressed principles in software
engineering turn out to have the most significant pragmatic relevance, just
like in bridge-building.
"Software engineering", properly applied, is no buzzword at all, but a precise
description of proper software design and construction.
--
Lew
Arne Vajhøj
If the manager puts Foo and Bar on the required skills then the HR
person goes after that. If the manager only puts Foo on the list
because that is what is needed next year, then ...
It is well known that most HR people don't have a clue about
what the skills means. But what skills that goes on the "must have"
and "nice to have" lists are not HR's responsibility. That manager
filling out the forms must accept that responsibility.
Arne
Martin Gregorie
> It is well known that most HR people don't have a clue about what the
> skills means. But what skills that goes on the "must have" and "nice to
> have" lists are not HR's responsibility. That manager filling out the
> forms must accept that responsibility.
>
Err, my point was that an HR-droid may be able to inspection-match a list
of language names or experience numbers, but if what the manager really
wants is somebody who matches the current skill set but in addition
learns fast, e.g. because he knows the environment is about to change,
then he's stuffed no matter what he puts on his letter to HR. They may be
able to handle the current skill set but are quite unlikely to deal
correctly with the learning bit.
Martin Gregorie
>
> "Software engineering", properly applied, is no buzzword at all, but a
> precise description of proper software design and construction.
>
Exactly, and this includes the ability to do a reasonably accurate
costing from the initial requirement spec and to estimate contingency
from the spec quality.
Roedy Green
or indirectly quoted someone who said :
>How do you get jobs where you get to work from home without having to
>charge the same rates a person in Deli will charge.
I am not getting anywhere near the work I used to, but previously I
kept myself busy working full time from home.
I offered 40 years experience. A young squirt just out of school
can't solve problems the way I could. He could code to a spec, but he
could not write the specs, write the docs in idiomatic English. He
could not suggest 10 totally different ways to approach a problem. You
need experience to do that.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Humanity is conducting an unintended, uncontrolled, globally pervasive experiment
whose ultimate consequences could be second only to global nuclear war."
~ Environment Canada (The Canadian equivalent of the EPA on global warming)
Roedy Green
or indirectly quoted someone who said :
>
>How do you get jobs where you get to work from home without having to
>charge the same rates a person in Deli will charge.
I used to have a monthly column in a Canada-wide computer paper.
People got to know me through my columns, and when it came time to get
custom coding done, wanted me to handle it, since they "knew" me.
Another way to get work in to work for free for charities. You get
known. People who run charities tend to be widely socially connected.
Chris M. Thomasson
news:op.uk1uy...@petes-computer.local...>> Peter Duniho wrote:
>>> C++ is a somewhat lower-level language, while at the same time offers
>>> in some ways much more complex behaviors than Java. Because of that,
>>> I'd recommend learning Java first, just because it's likely to be
>>> somewhat easier.
>>
>> It is much easier to learn Java than C++ as first language.
>
> "much" vs "somewhat"...same difference. I agree with either statement.
>
>> But it is also much easier to go C++ -> Java than Java -> C++.
>
> C++ to Java.
I remember one time when a Java programmer thought the following code
snippet was perfectly fine and 100% correct C++:
void foo() {
object* o = new object();
o->do_something();
}
I said, "your code has a memory leak within the `foo' procedure.".
He responded with, "what's a memory leak?".
;^/
Lew
> I remember one time when a Java programmer thought the following code
> snippet was perfectly fine and 100% correct C++:
>
> void foo() {
> object* o = new object();
> o->do_something();
> }
>
> I said, "your code has a memory leak within the `foo' procedure.".
>
> He responded with, "what's a memory leak?".
Sounds like an ad for Java over C++.
--
Lew
Joshua Cranmer
> He responded with, "what's a memory leak?".
public class Foo {
public Foo() {
bitBucket.add(this);
}
private static java.util.LinkedList<?> bitBucket =
new java.util.LinkedList<?>();
}
That's a memory leak (so long as bitBucket is not otherwise impacted by
any code path coming from a public API).
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Sabine Dinis Blochberger
> Arne Vajhøj wrote:
> > Matthias Buelow wrote:
Salary slavery :p
James Kanze
> Peter Duniho wrote:
> > C++ is a somewhat lower-level language, while at the same
> > time offers in some ways much more complex behaviors than
> > Java. Because of that, I'd recommend learning Java first,
> > just because it's likely to be somewhat easier.
> It is much easier to learn Java than C++ as first language.
I don't know about that. I think it depends on how they are
taught. Neither is really designed as a pedagogic language, but
both can be used successfully if the instructor is willing to
insist that the students accept some magic incantations at the
beginning. (Example: #include <iostream> or the fact that main
must be a member of a class.)
> But it is also much easier to go C++ -> Java than Java -> C++.
I don't know about that. Knowing one will make learning the
other easier, because they share a number of very low level
structures (control flow, expression syntax, etc.). Beyond
that, they tend to have very different idioms for a lot of
fundamental programming tasks, and are really two separate
languages, where what you know about one doesn't help that much
in the other.
> So I am not convinced that learning Java first and C++ later
> is in total easier than learning C++ first and Java later.
If you're teaching yourself, you should probably start with some
more pedagogic language. If you're taking a course, you should
start with whatever the course starts with (and which language
it uses is really not as important in chosing a course as any
number of other things).
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> Sanny wrote:
> If you want to try for the big bucks, I hear COBOL is coming
> back in vogue.
I don't know about being in vogue, but it's sure that skilled
Cobol programmers can pull down more than C++ or Java
programmers. There's a lot of legacy (and some new) Cobol out
there, and there are very few people who would admit to Cobol
skills, even if they have them. So even if the actual demand
isn't as great as for C++ or Java skills, the difference between
the offer and the demand is enormous. (It helps, too, that the
Cobol applications are typically mainframe---for whatever
reasons, the bigger the machine you work on, the more you get
paid, and that they are often the critical central piece of the
IT infrastructure; something goes wrong with them, and nothing
else works.)
James Kanze
> skill, you will improve your earning power by increasing your
> mastery of that language.
> Non-programming skills often count for more than one's
> technical abilities when climbing the corporate rungs.
> Some might look at your random capitalization of different
> words in English and wonder if you are sensitive to case
> sensitivity in Java. It is a shame, perhaps, that your
> command of English might block someone's ability to perceive
> your command of programming, but that is a reality in the work
> world.
The ability to understand other people's ideas is essential if
you are to be productive. The ability to communicate your own
ideas is essential if you are to be productive in anything but
the lowest level positions. If the working language of the
project is English, the ability of a candidate to communicate in
English is very important.
[...]
> Joshua Cranmer wrote:
> > Another piece of advice would be to brush up on rules of
> > punctuation, capitalization, and grammar in general.
> This is not parochialism, but a necessity when one is forced
> to communicate in any language. It is vitally necessary in
> written communications; face to face, people will forgive
> accents and unusual constructions, but in written
> communication there is little tolerance for fundamental
> errors, and less reason for there to be any.
Expressing yourself clearly and concisely is an essential skill,
whether it be in a human language or in a programming language.
In general, people unable to avoid spelling, punctuation and
grammar mistakes in their native language will find it equally
difficult to do so in C++ or Java.
James Kanze
<mar...@see.sig.for.address.invalid> wrote:
> On Sat, 22 Nov 2008 20:51:14 -0500, Arne Vajhøj wrote:
> > Job wise I think the majority either hires for a specific
> > skill set or hire someone they think is bright enough to
> > learn what is needed. Too few managers care about whether
> > the new hire will be easy to move to another
> > department/project that uses another language and what will
> > happen in 5 or 10 years when the company changes technology.
> IME that's nothing to do with the manager who needs the new
> hire: the initial hiring task gets given to HR who know
> nothing about programming or programming skills but do know
> how to match acronyms and names on the manager's skills list
> with those on a CV. The same applies to recruitment agencies.
> The result is that the candidates who get interviewed are
> simply those whose CVs get the most hits from what's little
> more than a clerical matching exercise.
> IOW the manager may know what he wants in the way of
> transferrable skills but this gets dropped on the floor by the
> agency and HR people because they don't understand IT. The
> current habit of condensing CVs to one or two pages and
> concentrating only on recent experience just exacerbates the
> problem.
In this regard, see http://www.idinews.com/keywordskills.html.
(For that matter, the site http://www.idinews.com/ is one that I
would highly recommend.)
James Kanze
wrote:
> On Sat, 22 Nov 2008 00:29:12 -0800 (PST), Sanny
> <softta...@hotmail.com> wrote, quoted or indirectly quoted
> someone who said :
> >What language should I master. I just want to know who gets
> >higher salary a Java Programmer or a C++ Programmer?
> To me that would be well down on my list of considerations. I
> ask questions like this:
> 1. which language do I enjoy coding more? What counts is how
> much I enjoy my life. I spend a LOT of it coding.
On the other hand, a lot of people would like doing something
other than coding.
In the end, I think most people are like me, and strike a
compromize. There are a lot of things I like more than
programming, regardless of the language, but I can't make a
decent living from them. And there are a lot of things which
pay more than programming, but I can't bring myself to do them.
Programming is a nice compromise (for me): it pays reasonably
well, and is somewhat agreeable.
> 2. which language will let me tackle more interesting
> projects. For than reason COBOL is out. I have no interested
> in maintaining payroll programs.
One of the reasons Cobol pays so well is that no one wants to do
it. (For a long time, my sig was "Conseils en informatique
industrielle/Beratung in industrieller Datenverarbeitung". When
asked what I meant by "informatique industrielle"/"industrielle
Datenverarbeitung", I responded that it meant that I didn't do
Cobol. On the other hand, I once had a collegue who worked on
the Cobol part of the project; he continued working on it mainly
because the company accepted paying him a full time salary for
20 hours a week, so he had more spare time for playing bass
guitare.)
> If I wanted to make money, I would learn the arcane art of
> Unix system administration.
Try IBM mainframe administration. It's even more arcane, and
even better paying.
> 3. Which language will leave my options open where I work. I
> don't want to get stuck in some place I hate. I want to be
> able to go anywhere. Which language is become more accepted.
> Which are becoming obsolete?
I see what you're getting at, but IMHO, it's a dangerous
attitude, carried to extremes. Of course, once "in" languages
never die, but they do fall out of grace, leaving a glut of
programmers in them, and making it hard to change jobs.
(Remember, at one time, Cobol was the most accepted language for
business applications.)
> 4. Which languages offer work from home?
Been there, done that. It doesn't work. In practice, some
physical presence in the office is necessary, in order to
maintain effective communications.
James Kanze
> On Sat, 22 Nov 2008 15:42:04 -0800, Roedy Green wrote:
> > 4. Which languages offer work from home?
> I've got to ask.. I've tried this alternative using places
> like Guru.com to get jobs and I've found I just can't make any
> money and the clients are not the kind of clients you want.
> They want a lot of work for very little money.. even work for
> free in some cases. I want to make my clients happy, but I
> need to get paid for my time and this just doesn't seem to
> work out well.
> How do you get jobs where you get to work from home without
> having to charge the same rates a person in Deli will charge.
That part's easy. Do a contract for them on site, first, so
they know what you can do. Then make working from home a
condition for the next contract. If you've done your job right,
then they'll likely prefer using you, working from home, to
someone else, working in their office.
Be prepared to be disappointed, however. Unless you are more or
less regularly present in the office, the quality of your work
will go down considerably. Quality programming is a team
activity, and good teamwork requires physical presence. (This
doesn't mean that 100% of your time must be spent in the office.
But judging from my experience, at least 2 days a week.)
James Kanze
> Matthias Buelow wrote:
> >> "Software engineering" has its place for some projects in
> >> the design phase but on the whole, (imho) is a terrible
> >> buzzword and implies the wrong things. In the end, (good)
> >> software isn't "engineered", like a bridge, but written,
> >> like a book.
> Spoken like someone who is not an engineer, and not like
> someone who engenders confidence in their programming skills.
Also like someone who has never authored a book. They may not
call it engineering, but most of the best books are carefully
organized very much like a engineering project.
Martin Gregorie
>
> In this regard, see http://www.idinews.com/keywordskills.html. (For that
> matter, the site http://www.idinews.com/ is one that I would highly
> recommend.)
>
Excellent.
This should be required reading for any recruiters, HR people and
managers involved in hiring any type of professional, not just IT people.
Lew
> Chris M. Thomasson wrote:
> > He responded with, "what's a memory leak?".
>
> public class Foo {
> public Foo() {
> bitBucket.add(this);
> }
> private static java.util.LinkedList<?> bitBucket =
> new java.util.LinkedList<?>();
>
> }
>
> That's a memory leak (so long as bitBucket is not otherwise impacted by
> any code path coming from a public API).
Strictly speaking it's not a leak but a plug - memory is held by the
program, not leaked from it. It is called a "memory leak" in Java,
but similarly to the term "reference", its meaning in Java is not the
same as in another language like C++.
--
Lew
James Kanze
In no sense of the word is it a leak. A leak isn't a couple of
drops spilling over the edge; it is a continuous loss. A
typical example of a leak in Java (or in C++) would be if in
reaction to some external event, you created a new, unique
identifier, stored some data (perhaps a functional object) under
that identifier in a map, and didn't remove it from the map once
the identifier was no longer in use. Without the identifier,
you no longer access the memory, and you "leak" memory each time
a specific event occurs.
Tom Anderson
> On 23 Nov 2008 13:33:25 GMT, "Ken T." <now...@home.com> wrote, quoted
> or indirectly quoted someone who said :
>
>> How do you get jobs where you get to work from home without having to
>> charge the same rates a person in Deli will charge.
>
> I offered 40 years experience. A young squirt just out of school can't
> solve problems the way I could. He could code to a spec, but he could
> not write the specs, write the docs in idiomatic English. He could not
> suggest 10 totally different ways to approach a problem. You need
> experience to do that.
One of my bosses expounds the same basic idea. The strategy is that we
compete with the outsourcers on a cost-per-project basis. We can't compete
on cost-per-head, because we live in London (or even worse, live in the UK
and commute to London), not Bangalore, and we like to work 40-hour weeks
and earn enough to live comfortable lives [1]. However, if we're good
enough - skilled, experienced, and well-organised enough - we can deliver
a project with a fraction of the man-hours of an outsourcing shop, and
thus be competitive on total cost.
This strategy seems to be working. It works for us for several reasons:
- We're a small company - two software gurus, a business/product/customer
guru, a training and tech writing guy, one permanent programmer (and
jobbing sysop), the intern, and zero to a handful of contractors. That
means we have very low communication overhead, and can coordinate
effectively. We don't waste time with meetings, emails queued in inboxes,
duplication of effort, misunderstood instructions, etc. We don't spend any
time doing anything that isn't concrete, productive work. Apart from
ten-minute stand-up meetings twice a day. And the crossword at lunch.
- We do agile development. I know not everyone's a convert, but honestly,
when you do it right (or near enough to right), it works like a charm. You
spend more of your working time on producing deliverables, and more of
that time is spent effectively.
- We do a lot of work with an e-commerce framework that's powerful but
arcane. We know it well enough to work with it smoothly, which few people
do. That means we can build big, complex e-commerce apps using it more
quickly than non-adepts could, with or without it (probably). It also
means that we're very well placed to pick up maintenance and extension
work on apps that have already been built with it - fortunately, there are
a lot of other shops using it, but using it badly, supplying a crop of
opportunities for us to harvest! That said, we are interested in doing
stuff not using this framework, as it's a rather harsh mistress; it'd be
interesting to see how much competitive edge we lose by stepping away from
it.
- We're not a straight development shop. Indeed, the gurus claim that we
aren't a development shop - apparently we're primarily a consultancy, but
one which can also do implementation should the need arise. A good slice
of the company's work (handled almost entirely by the gurus) is stuff like
proposing an architecture or outline of a solution to company A, or
reviewing such a proposal that company B have got from company C, or going
over company D's existing systems and telling them how to do what they
wan, etc. I don't fully grok how this works - i understand how they can do
that, but i don't see how it synergises with the programmers in the back
office. It's not like you can waltz in and say "oh, clearly the right
solution is to hire us to build this for you", can you. Can you? Maybe
it's about building trust and connections, and establishing ourselves as
people who can be called in to sort things out and get things done. Sort
of a cross between Red Adair and the SAS.
- I would say this, but we're bloody good programmers! The gurus are wise
and crafty (both the technical guys are ex-Smalltalkers, FWIW), and they
make a policy of only hiring people who are good. Our mercenaries^W
contractors are drawn from a smallish pool of people we know and trust,
who have worked with us on and off for ages. We don't have people sitting
around not being on top of their game or not pulling their weight. Apart
from me, obviously - i'm still quite shocked that i haven't been fired.
Anyway, as i said, it seems to be working.
One of the difficulties we run into is that clients' purchasing
departments don't always see things our way. Perversely, they don't look
at the price of the thing they're buying, they actually look at the price
of the programmers. We've had clients offering contracts which did things
like specify caps for salaries, and even annual increases in salaries. I
guess some clients are used to thinking in terms of parts-and-labour
costing, rather than fixed-price. This is shortsighted when the actual
value of labour can vary wildly (or so we claim).
It'll be interesting to see how this strategy pans out in the long run. At
the moment, it works because the competition, domestic and outsourced, are
not so hot. As the Indian software industry matures, we'll see companies
every bit as good as us emerge - and in huge numbers, of course. Will be
all be out of a job then? Or will salaries in India have inflated to the
point where they've lost their cost edge by then? Oh well, chances are the
whole of Europe'll be bankrupt by then anyway.
tom
[1] At least, the others do. I'm part-time, and technically an intern, so
my salary is correspondingly spartan!
--
Tomorrow has made a phone call to today.
Tom Anderson
> On Nov 23, 12:42 am, Roedy Green <see_webs...@mindprod.com.invalid>
> wrote:
>> On Sat, 22 Nov 2008 00:29:12 -0800 (PST), Sanny
>> <softta...@hotmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>
>>> What language should I master. I just want to know who gets
>>> higher salary a Java Programmer or a C++ Programmer?
>>
>> If I wanted to make money, I would learn the arcane art of
>> Unix system administration.
>
> Try IBM mainframe administration. It's even more arcane, and
> even better paying.
At one point, i heard Lotus Notes app development was paying like mad - a
thousand pounds a day for contracting work. And that was back when the
pound was worth something!
tom
Ben Voigt [C++ MVP]
That's a pretty apt description of the example given. The memory is still
reachable, but only from inside an internal data structure, so not *useful*.
And C++ has basically the same thing, orphaned memory is still reachable,
but only via the heap internal data structures (there is actually a public
API to do that though all type information is lost), it's effectively
unusable at that point.
Lew
> We've had clients offering contracts which did things
> like specify caps for salaries, and even annual increases in salaries.
How singularly arrogant of them!
I've heard of this thing before, actually, I've been on the short end
of this before, and it never ceases to shock me. How big must the
client think their balls are that they can dictate employment policies
to another company?
Worse yet is when the consulting firm accepts these types of
restrictions. Oh, please, spare me the defense of the practice; I'm
aware of the considerations. It's still the height of chutzpah to
dictate to another company their business practices so that you can be
their customer.
It's the social equivalent of using reflection to access private
members of another class. There are occasional, very restricted
scenarios where this kind of thing can be justified, but in the common
case it's just awful.
--
Lew
Peter Duniho
wrote:
>> Strictly speaking it's not a leak but a plug - memory is held
>> by the program, not leaked from it. It is called a "memory
>> leak" in Java, but similarly to the term "reference", its
>> meaning in Java is not the same as in another language like
>> C++.
>
> In no sense of the word is it a leak.
Just goes to show, you can have this argument in any programming
newsgroup, with or without a garbage collector. :)
> A leak isn't a couple of
> drops spilling over the edge; it is a continuous loss.
I have never considered "continuous loss" (that is, continually increasing
over time) to be part of the criteria for defining a "leak". Even a
single block of data for which no reference remains and so making the
block of data unreachable is a "leak" in my book.
You may feel free to disagree, but I find it pointless for you to write
something like "in no sense of the word". There are many "senses of the
word" when it comes to the word "leak", and lots of people uses sense of
the word that support Lew's and my interpretation, not yours. It's one
thing for you to choose a sense of the word that differs, but to claim
that there are no other sense of the word that disagree with that chosen
sense? That's silly.
> A
> typical example of a leak in Java (or in C++) would be if in
> reaction to some external event, you created a new, unique
> identifier, stored some data (perhaps a functional object) under
> that identifier in a map, and didn't remove it from the map once
> the identifier was no longer in use. Without the identifier,
> you no longer access the memory, and you "leak" memory each time
> a specific event occurs.
I disgree, though the important thing is not that we agree, but that when
we are working together on the same code, we use the same definition.
As far as this unimportant disagreement goes, here's my stance:
garbage-collected systems cannot have true "leaks", except for a bug in
the GC itself. On the other hand, imperative memory management systems,
such as C++'s "malloc/free/new/delete" can. And the way those "leaks"
happen is that you _do_ remove the "identifier" (i.e. the
pointer/reference to the memory) without calling the appropriate function
to actually release the memory block back to the memory manager.
The behavior you describe would, in Java, C#, C++, or whatever, be
described (in my opinion) as "pack-ratting". That is, you haven't lost
the memory...you have simply neglected to stop using it when you're done
with it. In a GC-based system, it's as close to a "leak" as you can get
(but IMHO isn't a leak, though I certainly have run into people who
disagree).
I don't mind if you want to call that a "leak", but please don't make the
claim that your point of view is the only appropriate one. Doing so only
undermines any justification you might have for your own point of view.
The fact is, there is no industry-standard definition for the word "leak",
so any time you hear or use the word you need to be prepared for the
possibility that the other person is using a different definition from
your own.
Pete
Chris M. Thomasson
Tim Roberts
>
>At http://www.GetClub.com/Experts.php you can tell your expertise and
>get work from home work. You only get small orders in such places. As
>large work people choose already established companies instead of
>giving work to strangers who may spoil the work.
I have a hard time using the word "expert" anywhere around a web site that
thinks the word "doctor" is actually spelled "docter".
I won't be going back to GetClub.com.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts
>Matthias Buelow wrote:
>>> "Software engineering" has its place for some projects in the design
>>> phase but on the whole, (imho) is a terrible buzzword and implies the
>>> wrong things. In the end, (good) software isn't "engineered", like a
>>> bridge, but written, like a book.
>
>Spoken like someone who is not an engineer, and not like someone who engenders
>confidence in their programming skills.
>
>Software engineering has its place in every software project, and that place
>is everywhere in the software.
I have a speech about that.
We are in the middle of a revolution in software development. 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.
If we are ever to build reliable large software systems, software
development needs to transition to a true engineering discipline. The
tools are on their way to being able to enable that transition, but they
aren't there yet.
The tools that my partner uses to create chips are much better suited to
"engineering" than the tools I use to create software. Compare a Pentium
IV processor to Windows, for example. I've had many debates, usually under
the influence of intoxicants, over which one of those is more
"complicated". I would argue that Windows is much less reliable than the
Pentium IV, because the tools aren't as good.
When programming does transition to an engineering discipline, it will be a
much better thing for the world at large, but it won't be nearly as much
fun.
Roedy Green
someone who said :
>3. Which language will leave my options open where I work. I don't
>want to get stuck in some place I hate. I want to be able to go
>anywhere. Which language is become more accepted. Which are becoming
>obsolete?
There was a news item today that having a boss you can't stand leads
to heart disease.
LR
> Matthias Buelow wrote:
>>> "Software engineering" has its place for some projects in the design
>>> phase but on the whole, (imho) is a terrible buzzword and implies the
>>> wrong things. In the end, (good) software isn't "engineered", like a
>>> bridge, but written, like a book.
>
> Spoken like someone who is not an engineer, and not like someone who engenders
> confidence in their programming skills.
Shouldn't that rather be t'other way round? Isn't it that people who
understand that software isn't, and cannot be an engineering discipline,
inspire the confidence that comes from having an appreciation of one's
tools?
> In the beginning, middle and end, good software is engineered, like a bridge
> and, arguably, like a well-written book. If it is not well engineered, it's
> not going to be good software.
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.
>
> There are sound principles behind sound programming decisions. These
> principles come down to providing desired functionality with provable
> management of risk of defects or system failures, within budgetary
> constraints.
Can I use those to prove that my program will halt at some point?
> Some of the more formally-expressed principles in software
> engineering turn out to have the most significant pragmatic relevance, just
> like in bridge-building.
>
> "Software engineering", properly applied, is no buzzword at all, but a precise
> description of proper software design and construction.
When I was young, or at least younger than I am now, I was taught that
engineering is the application of scientific principles. This makes me
curious to know, what scientific principles are being applied in the
development of software?
LR
James Kanze
wrote:
> >> Strictly speaking it's not a leak but a plug - memory is
> >> held by the program, not leaked from it. It is called a
> >> "memory leak" in Java, but similarly to the term
> >> "reference", its meaning in Java is not the same as in
> >> another language like C++.
> > In no sense of the word is it a leak.
> Just goes to show, you can have this argument in any
> programming newsgroup, with or without a garbage collector.
> :)
> > A leak isn't a couple of drops spilling over the edge; it is
> > a continuous loss.
> I have never considered "continuous loss" (that is,
> continually increasing over time) to be part of the criteria
> for defining a "leak". Even a single block of data for which
> no reference remains and so making the block of data
> unreachable is a "leak" in my book.
Well, you can define it anyway you want, but any definition not
implying continuously increasing memory use has no practical
implications. And of course, in non technical English, a leak
is also more or less permanent: you don't say a bucket leaks
because a few drops spill over the top; you would only speak of
a leak if there was a continuous loss.
But by your definition, his code didn't leak either, so I'm not
sure what you're arguing about. I'm aware of this definition,
and considered it in my "no sense of the word".
> You may feel free to disagree, but I find it pointless for you
> to write something like "in no sense of the word".
OK. "In no reasonable sense of the word", then. Or "in no
practically usable sense of the word." Or "in no sense of the
word I've ever seen."
> There are many "senses of the word" when it comes to the word
> "leak", and lots of people uses sense of the word that
> support Lew's and my interpretation, not yours.
The actual example code didn't leak, in any sense of the word.
It corresponded to an established and widely used pattern.
Actually, on looking at the code closer, I think it is a leak.
I'd missed the fact that each constructor added the object to
the list. He has, effectively, created a situation where
objects of type Foo can never be recovered by garbage
collection; this is not fundamentally different from my
classical example of a class registering itself somewhere. So
either:
1) The program needs a record of all instances of Foo; once
created, an instance lives forever; and the program never
creates more than a bound finite set of Foo. In this case,
the code is perfectly correct; if the cardinality of the
bound finite set is 1, we even have the established idiom of
a singleton. (In this case, the constructor really should be
private.)
2) The program needs a record of all instances of Foo; once
created, an instance lives forever; and the number of
instances which may be created in not bound. In this case,
he has a real problem, since his application requires a
machine with infinite memory in order to run. He probably
needs to review the requirements.
Note that in some cases, this may be more or less
inevitable, and the requirements will end up having to be
formulated in terms of "within its resource limits, the
program will...", with a definition of the behavior when the
resource limits are exceeded. Consider the symbol table in
a compiler, for example. If the program is supposed to run
24 hours a day, 7 days a week, however, this could be a
killer problem.
3) The program only needs a record of the active instances of
Foo, and the programmer has forgotten to provide a means of
"deactivating" an instance (or user code has forgotten to
call it). In this case, the code does leak. At least by my
"useful" definition.
[...]
> As far as this unimportant disagreement goes, here's my
> stance: garbage-collected systems cannot have true "leaks",
> except for a bug in the GC itself. On the other hand,
> imperative memory management systems, such as C++'s
> "malloc/free/new/delete" can. And the way those "leaks"
> happen is that you _do_ remove the "identifier" (i.e. the
> pointer/reference to the memory) without calling the
> appropriate function to actually release the memory block
> back to the memory manager.
That's a nice definition for commercial purposes. It sounds
nice to be able to say that your language cannot have a leak (or
that your product detects all leaks). But it's really is a sort
of commercial new-speak to redefine "leak" in order to be able
to say that. It's sort of like Java (and C++ for the unsigned
integral types) redefining arithmetic "overflow", in order to
say that integral arithmetic can't overflow. With the
difference that there are a few exotic cases (at least with
unsigned values) where the new definition is definitely useful
(and even in the case of Java, it allows "defined" behavior at
no cost on most machines---and even incorrect defined behavior
is better than undefined behavior).
James Kanze
> On Sun, 23 Nov 2008, Roedy Green wrote:
> > wrote, quoted or indirectly quoted someone who said :
> >> How do you get jobs where you get to work from home without
> >> having to charge the same rates a person in Deli will
> >> charge.
> > I offered 40 years experience. A young squirt just out of
> > school can't solve problems the way I could. He could code
> > to a spec, but he could not write the specs, write the docs
> > in idiomatic English. He could not suggest 10 totally
> > different ways to approach a problem. You need experience to
> > do that.
> One of my bosses expounds the same basic idea. The strategy is
> that we compete with the outsourcers on a cost-per-project
> basis. We can't compete on cost-per-head, because we live in
> London (or even worse, live in the UK and commute to London),
> not Bangalore, and we like to work 40-hour weeks and earn
> enough to live comfortable lives [1]. However, if we're good
> enough - skilled, experienced, and well-organised enough - we
> can deliver a project with a fraction of the man-hours of an
> outsourcing shop, and thus be competitive on total cost.
Normally, cost isn't the only issue. I've worked on projects
where part of the work was outsourced to Bangalore. What is
clear is that 1) it's cheaper, and 2) the competence of the
people involved was at least as good (and often better) than the
people we had on site (in Germany). On the other hand,
communication was an enormous problem.
If your customer can specify exactly what he wants, with no
ambiguity, and he knows how to vet his supplier, there's no way
you can compete with Bangalore. You raise a number of points,
but all of the technical once (your team are gurus, etc.) are
easily matched in Bangalore. Don't underestimate them; they're
good. On the other hand, it's rarely the case that the customer
knows exactly what he wants, and being on hand to discuss
various possible changes in the requirements or specifications
can far outweigh any price advantage.
James Kanze
> Lew <no...@lewscanon.com> wrote:
> >Matthias Buelow wrote:
> >>> "Software engineering" has its place for some projects in
> >>> the design phase but on the whole, (imho) is a terrible
> >>> buzzword and implies the wrong things. In the end, (good)
> >>> software isn't "engineered", like a bridge, but written,
> >>> like a book.
> >Spoken like someone who is not an engineer, and not like
> >someone who engenders confidence in their programming skills.
> >Software engineering has its place in every software project,
> >and that place is everywhere in the software.
> I have a speech about that.
> We are in the middle of a revolution in software development.
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.
> 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.
> If we are ever to build reliable large software systems,
> software development needs to transition to a true engineering
> discipline. The tools are on their way to being able to
> enable that transition, but they aren't there yet.
We build reliable large software systems today. At least, I've
worked in companies that do. If the software I've worked on
wasn't reliable, your phones wouldn't work, you wouldn't have
reliable electricity, the brakes on your car wouldn't work
(actually, I worked on train brakes, not car brakes, but the
principle is the same), etc., etc.
> The tools that my partner uses to create chips are much better
> suited to "engineering" than the tools I use to create
> software.
The tools your partner uses to create chips are run by software.
> Compare a Pentium IV processor to Windows, for example. I've
> had many debates, usually under the influence of intoxicants,
> over which one of those is more "complicated". I would argue
> that Windows is much less reliable than the Pentium IV,
> because the tools aren't as good.
Or they haven't been used correctly (or at all). Perhaps the
management at Microsoft thinks like you do with respect to
software engineering, rather than informing themselves of the
what can really be done. (Or perhaps they're just stuck with a
lot of legacy code, and fear that a total rewrite using modern
software engineering techniques would be too expensive.)
Note that just because some firms don't practice software
engineering (and Microsoft is far from alone in this) doesn't
mean that it doesn't exist.
> When programming does transition to an engineering discipline,
> it will be a much better thing for the world at large, but it
> won't be nearly as much fun.
It depends on what you consider "fun". There is a certain
personal satisfact to be had in knowing that you've just
delivered a program which actually works.
LR
> 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?
> 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 the same extent that an engineer could
"prove" that the bridge they designed will work? What kinds of metrics
are used? Does software have a stress point beyond which it will
deform, like the metal in the bridge will?
LR
Lew
>> At http://www.GetSchlub.scam/Experts.php you can tell your expertise and
>> get work from home work. You only get small orders in such places. As
>> large work people choose already established companies instead of
>> giving work to strangers who may spoil the work.
Tim Roberts wrote:
> I have a hard time using the word "expert" anywhere around a web site that
> thinks the word "doctor" is actually spelled "docter".
>
> I won't be going back to GetClub.com.
I am so disappointed in Sanny for spamming this group, and right in the middle
of an interesting discussion, too. He's starting to seem quite plonk-worthy.
I am not surprised that the quality of the spammed-for site should suck so
badly. That is to be expected.
Tsk, tsk, Sanny.
--
Lew
Lew
> Lew wrote:
>> Matthias Buelow wrote:
>>>> "Software engineering" has its place for some projects in the design
>>>> phase but on the whole, (imho) is a terrible buzzword and implies the
>>>> wrong things. In the end, (good) software isn't "engineered", like a
>>>> bridge, but written, like a book.
>> Spoken like someone who is not an engineer, and not like someone who engenders
>> confidence in their programming skills.
>
> Shouldn't that rather be t'other way round? Isn't it that people who
> understand that software isn't, and cannot be an engineering discipline,
> inspire the confidence that comes from having an appreciation of one's
> tools?
You are begging the question.
And wrong. Software development can be, and is, an engineering discipline.
--
Lew
Puppet_Sock
[snip]
> How much max salary per Annum I can get If I become a C++ Expert.
> and How much max salary per Annum I can get If I become a Java Expert.
If all you care about is maxing your salary, you
should learn COBOL. There are millions of lines of
old business apps, payroll, accounting, etc., that
were written in COBOL. Because many people don't
want to admit to being proficient at COBOL, the
billable rate for COBOL developers is huge.
Socks
Puppet_Sock
> salary a Java Programmer or a C++ Programmer?
Seriously, this is backwards.
Learn the one that is going to get you a job today.
Or this week or this month or whatever.
Master the concepts of good software design and
development. That is, look at what is good design,
what is a good idiom, how do you approach a software
task so as to get to a good product at the end.
Such things are, to some degree, influenced by the
language. Good design in Java is not identical to
good design in C++. But also, to some degree, the
idea of good design is transferable to other languages.
For example, one generic idea is to manage complexity.
There are ways to localize and hide complexity, so as
to make the largest chunk of information a coder has
to understand at any given time as small as possible.
There are ways to make the scope of various items in
the code as short as possible, so as to minimize the
impact of changes to the code. There are ways to code
such that changes are easy to make when the spec is
updated, changes are easy to see to be correct, easy
to test, easy to document, etc. And so on.
A good book on this topic is
_Code Complete: A Practical Handbook of Software
Construction_ by Steve McConnell (2nd Edition).
But don't let that be the only book you read on
the topic. Depending on the specific area of work
you select (or get a job in) then there are lots of
other books to make that task easier. For example, if
you get into scientific or numerical work, you want
one set of books. If you do communications, another.
If you do user interface, another. Security, another.
And so on.
If you learn good software development methods, then
you will have a better chance of earning the big bucks
regardless of language.
Socks
LR
> LR wrote:
>> Lew wrote:
>>> Matthias Buelow wrote:
>>>>> "Software engineering" has its place for some projects in the design
>>>>> phase but on the whole, (imho) is a terrible buzzword and implies the
>>>>> wrong things. In the end, (good) software isn't "engineered", like a
>>>>> bridge, but written, like a book.
>>> Spoken like someone who is not an engineer, and not like someone who engenders
>>> confidence in their programming skills.
>> Shouldn't that rather be t'other way round? Isn't it that people who
>> understand that software isn't, and cannot be an engineering discipline,
>> inspire the confidence that comes from having an appreciation of one's
>> tools?
>
> You are begging the question.
No, I contradicting you.
>
> And wrong. Software development can be, and is, an engineering discipline.
>
No, I'm right. But please feel free to explain how software development
can be an engineering discipline. TIA.
LR
AL
> Lew wrote:
>> LR wrote:
>>> Lew wrote:
>>>> Matthias Buelow wrote:
> No, I contradicting you.
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. 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? :)
AL
cour...@gmail.com
> {...]
> 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.
Alexandre Courpron.
Tom Anderson
> Lew wrote:
>> Matthias Buelow wrote:
>>
>>>> "Software engineering" has its place for some projects in the design
>>>> phase but on the whole, (imho) is a terrible buzzword and implies the
>>>> wrong things. In the end, (good) software isn't "engineered", like a
>>>> bridge, but written, like a book.
>>
>> Spoken like someone who is not an engineer, and not like someone who
>> engenders confidence in their programming skills.
>>
>> "Software engineering", properly applied, is no buzzword at all, but a precise
>> description of proper software design and construction.
>
> When I was young, or at least younger than I am now, I was taught that
> engineering is the application of scientific principles. This makes me
> curious to know, what scientific principles are being applied in the
> development of software?
Exactly. The making of software is not, and will never be, engineering.
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.
There's no analogue of this in software. There's no useful description of
a system any simpler than the system itself. I can draw UML diagrams or
write prototype code, or do a high-level sketch in some kind of formal
language, and i *might* be able to verify that those do the right thing,
but there's no way to get from there to the real thing. There's no
analogue to the idea of the model being a close approximation - one
character out of place somewhere in the implementation can completely
change the behaviour of the whole system.
Nor can you apply analysis of this kind to the actual program, which is
actually a closer analogue to the bridge engineer's analysis [1].
There are brave and optimistic people who have tried, and are trying, to
do something about this - to find ways of proving things about programs,
or of writing programs about which things can be proven, so that we can
look at a system and give cast-iron guarantees - mathematical proofs, even
stronger than the bridge engineer's calculations - that the thing will
work as specified. Sadly, the resounding finding is that it's just not
practical to give useful guarantees for useful programs. Maybe that will
change, but there are no signs of that so far.
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.
tom
[1] Since the finished source code is a design, not a product - see:
http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign
--
The literature is filled with bizarre occurrances for which we have
no explanation
Tom Anderson
> On Nov 25, 12:06 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
> wrote:
>> On Mon, 24 Nov 2008 14:14:01 -0800, James Kanze
>> <james.ka...@gmail.com> wrote:
>
>>>> Strictly speaking it's not a leak but a plug - memory is
>>>> held by the program, not leaked from it. It is called a
>>>> "memory leak" in Java, but similarly to the term
>>>> "reference", its meaning in Java is not the same as in
>>>> another language like C++.
>>>
>>> In no sense of the word is it a leak.
>>
>> There are many "senses of the word" when it comes to the word "leak",
>> and lots of people uses sense of the word that support Lew's and my
>> interpretation, not yours.
>
> The actual example code didn't leak, in any sense of the word. It
> corresponded to an established and widely used pattern.
>
> Actually, on looking at the code closer, I think it is a leak.
*facepalm*
Thanks for taking the time to actually read and understand the example. If
i may be so bold as to make a suggestion, maybe do that a little earlier
in the thread next time?
tom
Tom Anderson
Oh, absolutely!
But i'm still skeptical about them being matched. There are plenty of
people in the US and European software industries with 20-30 years, or
more, of experience in their fields. Bangalore's software industry only
took off in the last 10-15 years, so it just hasn't built up a depth of
maturity and experience yet. Equally, of course, it isn't laden with a
deadweight of old guys with obsolete knowledge!
Either way, another 10-15 years from now, things may look very different.
> On the other hand, it's rarely the case that the customer knows exactly
> what he wants, and being on hand to discuss various possible changes in
> the requirements or specifications can far outweigh any price advantage.
Most of our contact with the client consists of emails and phone calls.
Once every few weeks, a couple of people fly out to their offices (which
are in a nearby country). A Bangalore-based team would have a longer plane
trip, but what's to stop them having just as much contact with the client
as us? Is it just a language thing?
We've got a contract coming over the horizon where the client is in the
Middle East. That puts the Bangaloreans closer than us, and nobbles the
lanuguage edge. How about then?
Tom Anderson
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.
Lars Enderin
case. How come you're working in Lithuania, by the way?
Lew
> 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.
--
Lew
Lars Enderin
Sorry. Actually, I meant to write a private comment by mail, but I was
careless. Maybe that would have been equally bad, though?
(I wonder when Google Groups is going to handle signature delimiters "--
" correctly?)
cour...@gmail.com
> On Tue, 25 Nov 2008, courp...@gmail.com wrote:
> > On 25 nov, 15:38, LR <lr...@superlink.net> 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.
>
> Name three.
You already named more later in your message. The use of design by
contract is not reserved to those few sectors. It is mandatory in
those sectors, but is sometimes attractive to other domains because it
removes the need to spend days, weeks, months in the testing phase of
the software development cycle.
>
> 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
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.
> , 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.
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.
Alexandre Courpron.
Martin Gregorie
> 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.
>
Substitute 'industrial/nuclear process control' for telecoms and I'd
agree: this substitution assumes that your 'real-time' means vehicle and
machine control.
I remain to be convinced that telecoms code is particularly robust.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
James Kanze
> On Tue, 25 Nov 2008, James Kanze wrote:
[...]
> > If your customer can specify exactly what he wants, with no
> > ambiguity, and he knows how to vet his supplier, there's no
> > way you can compete with Bangalore. You raise a number of
> > points, but all of the technical once (your team are gurus,
> > etc.) are easily matched in Bangalore. Don't underestimate
> > them; they're good.
> Oh, absolutely!
> But i'm still skeptical about them being matched. There are
> plenty of people in the US and European software industries
> with 20-30 years, or more, of experience in their fields.
> Bangalore's software industry only took off in the last 10-15
> years, so it just hasn't built up a depth of maturity and
> experience yet. Equally, of course, it isn't laden with a
> deadweight of old guys with obsolete knowledge!
All I can say for sure is that the people we were working with
were very competent. More so than the people we could find in
Germany at the time---it's nice to know that there are plenty of
people with 20-30 years experience, but if they aren't on the
job market, it doesn't help.
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.
> > On the other hand, it's rarely the case that the customer
> > knows exactly what he wants, and being on hand to discuss
> > various possible changes in the requirements or
> > specifications can far outweigh any price advantage.
> Most of our contact with the client consists of emails and
> phone calls. Once every few weeks, a couple of people fly out
> to their offices (which are in a nearby country). A
> Bangalore-based team would have a longer plane trip, but
> what's to stop them having just as much contact with the
> client as us? Is it just a language thing?
If contact only once every few weeks is sufficient, then they
likely can do just as good a job for less. But don't forget the
issue of time zones, either. Or the fact that the longer plane
trip is relevant; it certainly makes it more difficult to set up
meetings on short notice, if something unexpected comes up. As
for the language: that can play a role, too, but I expect
cultural differences could play an even bigger role in making
communications difficult. (I've worked on some joint
French/German projects, and even there, cultural differences
created a lot of difficulties.)
> We've got a contract coming over the horizon where the client
> is in the Middle East. That puts the Bangaloreans closer than
> us, and nobbles the lanuguage edge. How about then?
A priori, there's no reason a firm in Bangalore couldn't make an
offer just as legitimate as yours. But in the end, there are a
lot of issues that the client will consider.
James Kanze
> 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.
> > 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.
> 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.
> What kinds of metrics are used? Does software have a stress
> point beyond which it will deform, like the metal in the
> bridge will?
See http://www.sei.cmu.edu/. I obviously can't stuff a four
year course in software engineering into a web article.
James Kanze
> Name three.
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.
Paavo Helde
> (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).
Paavo
James Kanze
> On Tue, 25 Nov 2008, LR wrote:
> > Lew wrote:
> >> Matthias Buelow wrote:
> >>>> "Software engineering" has its place for some projects in
> >>>> the design phase but on the whole, (imho) is a terrible
> >>>> buzzword and implies the wrong things. In the end, (good)
> >>>> software isn't "engineered", like a bridge, but written,
> >>>> like a book.
> >> Spoken like someone who is not an engineer, and not like
> >> someone who engenders confidence in their programming
> >> skills.
> >> "Software engineering", properly applied, is no buzzword at
> >> all, but a precise description of proper software design
> >> and construction.
> > When I was young, or at least younger than I am now, I was
> > taught that engineering is the application of scientific
> > principles. This makes me curious to know, what scientific
> > principles are being applied in the development of software?
> 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.)
Tom Anderson
> Lew skrev:
>> On Nov 25, 2:41 pm, Lars Enderin <lars.ende...@telia.com> 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. '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.
--
Heinlein has done more to harm SF than has any other writer, I think. --
PKD
LR
> 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
LR
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
Tom Anderson
> On 25 nov, 20:12, Tom Anderson <t...@urchin.earth.li> wrote:
>> On Tue, 25 Nov 2008, courp...@gmail.com wrote:
>>> On 25 nov, 15:38, LR <lr...@superlink.net> 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.
>>
>> 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
>
> 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.
>> , 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.
>
> 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
LR
> On Nov 25, 3:38 pm, LR <lr...@superlink.net> 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.
>
>> 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.geo/GeneralsBridge.JPG
I think software doesn't have this particular problem.
>> What kinds of metrics are used? Does software have a stress
>> point beyond which it will deform, like the metal in the
>> bridge will?
>
> 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
LR
> On Nov 25, 7:40 pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> On Tue, 25 Nov 2008, LR wrote:
>>> Lew wrote:
>>>> Matthias Buelow wrote:
>
>>>>>> "Software engineering" has its place for some projects in
>>>>>> the design phase but on the whole, (imho) is a terrible
>>>>>> buzzword and implies the wrong things. In the end, (good)
>>>>>> software isn't "engineered", like a bridge, but written,
>>>>>> like a book.
>
>>>> Spoken like someone who is not an engineer, and not like
>>>> someone who engenders confidence in their programming
>>>> skills.
>
>>>> "Software engineering", properly applied, is no buzzword at
>>>> all, but a precise description of proper software design
>>>> and construction.
>
>>> When I was young, or at least younger than I am now, I was
>>> taught that engineering is the application of scientific
>>> principles. This makes me curious to know, what scientific
>>> principles are being applied in the development of software?
>
>> Exactly. The making of software is not, and will never be,
>> engineering.
>
> 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
LR
> 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
Lew
> 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.
--
Lew
Lew
> 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.
--
Lew
Arne Vajhøj
> 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