f



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

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.

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.
0
softtanks (50)
11/22/2008 8:29:12 AM
comp.lang.c++ 49423 articles. 6 followers. Post Follow

444 Replies
2516 Views

Similar Articles

[PageSpeed] 1

On Sat, 22 Nov 2008 00:29:12 -0800, Sanny <softtanks@hotmail.com> wrote:

> 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
0
NpOeStPeAdM (1108)
11/22/2008 8:48:46 AM
Paid programmers work with any language on / for any OS.
0
sgier (47)
11/22/2008 9:48:49 AM
On 22.11.2008 09:29, Sanny wrote:

> 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
0
shortcutter (5830)
11/22/2008 11:10:45 AM
On Nov 22, 9:29=A0am, Sanny <softta...@hotmail.com> wrote:
> 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.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/22/2008 11:32:21 AM
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.

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
0
Pidgeot18 (1520)
11/22/2008 3:22:28 PM
Sanny wrote:
> 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...
0
nico3400 (1)
11/22/2008 4:25:30 PM
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.

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
0
noone7 (4050)
11/22/2008 5:08:54 PM
"Joshua Cranmer" <Pidgeot18@verizon.invalid> wrote in message 
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.
[ SNIP ]

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 


0
asandstrom (223)
11/22/2008 6:35:21 PM
On Sat, 22 Nov 2008 00:29:12 -0800 (PST), Sanny
<softtanks@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'.
0
see_website (5876)
11/22/2008 11:42:04 PM
Sanny wrote:
> 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.
> 
> 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.

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
0
arne6 (9808)
11/23/2008 1:38:19 AM
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.

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
0
arne6 (9808)
11/23/2008 1:43:35 AM
Joshua Cranmer wrote:
> 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
0
arne6 (9808)
11/23/2008 1:51:14 AM
Roedy Green wrote:
> On Sat, 22 Nov 2008 00:29:12 -0800 (PST), Sanny
> <softtanks@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
0
arne6 (9808)
11/23/2008 1:54:32 AM
Arne Vajh�j wrote:
> 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
0
arne6 (9808)
11/23/2008 1:57:06 AM
On Sat, 22 Nov 2008 17:43:35 -0800, Arne Vajhøj <arne@vajhoej.dk> wrote:

> 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
0
NpOeStPeAdM (1108)
11/23/2008 2:10:08 AM
Peter Duniho wrote:
> On Sat, 22 Nov 2008 17:43:35 -0800, Arne Vajhøj <arne@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).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
11/23/2008 3:22:04 AM
Sanny wrote:
> 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
0
pats (3556)
11/23/2008 10:02:46 AM
"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> writes:

> 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
0
spamtrap25 (371)
11/23/2008 12:11:39 PM
Sanny wrote:

> 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.
0
mkb (1001)
11/23/2008 1:03:59 PM
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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/23/2008 1:21:38 PM
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. 



-- 
Ken T.

  I find it rather easy to portray a businessman.  Being bland, rather
  cruel and incompetent comes naturally to me.   
        -- John Cleese
0
nowhere7 (109)
11/23/2008 1:33:25 PM
Ken T. wrote:
> 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
0
arne6 (9808)
11/23/2008 3:39:24 PM
> 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. =A0They want a lot of work for very
> little money.. even work for free in some cases. =A0I 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

0
softtanks (50)
11/23/2008 3:43:31 PM
Arne Vajhøj wrote:
> Ken T. wrote:
>> 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 !

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.
0
noone7 (4050)
11/23/2008 4:04:07 PM
Matthias Buelow wrote:
> Sanny wrote:
> 
>> 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.

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
0
noone7 (4050)
11/23/2008 4:12:54 PM
Peter Duniho wrote:
> 
> 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.


Interesting.  I think one advantage of learning Java first may that Java 
enforces better habits.  Bjarne Stroustrup has said (I believe he said 
this, not 100% sure) that he tried to encourage abstract classes and 
pure virtual classes as base classes and types in his language 
descriptions. This didn't really work out, as many folks just went 
straight to multiple inheritance.

Java doesn't allow multiple inheritance, so one is forced to use 
interfaces instead. This might translate to better habits when going 
from Java to C++.



0
markspace (1144)
11/23/2008 6:50:22 PM
On Nov 22, 3:29=A0am, Sanny <softta...@hotmail.com> wrote:
> 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.
>
> 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?

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.

0
11/23/2008 8:14:19 PM
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). 


0
11/23/2008 8:49:20 PM
Lew wrote:

> EE: You're kidding!

Yeah, only four weeks holiday.. even the 6-figure salary won't make up
for it.
0
mkb (1001)
11/23/2008 9:21:29 PM
Matthias Buelow wrote:
> Lew wrote:
> 
>> EE: You're kidding!
> 
> Yeah, only four weeks holiday.. even the 6-figure salary won't make up
> for it.

I think the joke is US centric.

Arne
0
arne6 (9808)
11/23/2008 9:23:59 PM
Bill wrote:

> 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.
0
mkb (1001)
11/23/2008 9:33:24 PM
Arne Vajhøj wrote:

> I think the joke is US centric.

Must be, I don't think it's particularly funny.
0
mkb (1001)
11/23/2008 9:33:55 PM
Matthias Buelow wrote:
> Arne Vajhøj wrote:
>> I think the joke is US centric.
> 
> Must be, I don't think it's particularly funny.

4 weeks of vacation is a lot in the US.

Arne
0
arne6 (9808)
11/23/2008 9:39:30 PM
Matthias Buelow wrote:
> Bill wrote:
>> 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.

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
0
arne6 (9808)
11/23/2008 9:41:23 PM
Arne Vajhøj wrote:
> Matthias Buelow wrote:
>> Arne Vajhøj wrote:
>>> I think the joke is US centric.
>>
>> Must be, I don't think it's particularly funny.
> 
> 4 weeks of vacation is a lot in the US.

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
0
noone7 (4050)
11/23/2008 10:33:53 PM
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.

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
0
noone7 (4050)
11/23/2008 10:43:15 PM
Martin Gregorie 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.

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
0
arne6 (9808)
11/23/2008 11:49:10 PM
On Sun, 23 Nov 2008 18:49:10 -0500, Arne Vajhøj wrote:

> 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@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/24/2008 2:04:33 AM
On Sun, 23 Nov 2008 17:43:15 -0500, Lew wrote:

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


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/24/2008 2:14:33 AM
On 23 Nov 2008 13:33:25 GMT, "Ken T." <nowhere@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 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)
0
see_website (5876)
11/24/2008 3:13:37 AM
On 23 Nov 2008 13:33:25 GMT, "Ken T." <nowhere@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 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.

-- 
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)
0
see_website (5876)
11/24/2008 3:15:46 AM
"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message 
news:op.uk1uy6oo8jd0ej@petes-computer.local...
> On Sat, 22 Nov 2008 17:43:35 -0800, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>> 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.
[...]

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


;^/ 

0
no6 (2828)
11/24/2008 4:25:07 AM
Chris M. Thomasson wrote:
> 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
0
noone7 (4050)
11/24/2008 5:11:28 AM
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).
-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
11/24/2008 5:20:56 AM
Lew wrote:

> Arne Vajhøj wrote:
> > Matthias Buelow wrote:
> >> Arne Vajhøj wrote:
> >>> I think the joke is US centric.
> >>
> >> Must be, I don't think it's particularly funny.
> > 
> > 4 weeks of vacation is a lot in the US.
> 
> 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?
> 
Salary slavery :p

0
no.spam6050 (391)
11/24/2008 10:04:50 AM
On Nov 23, 2:43 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> 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.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 12:23:48 PM
On Nov 22, 4:22 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 12:32:03 PM
On Nov 22, 6:08 pm, Lew <no...@lewscanon.com> wrote:
> Sanny wrote:
> 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.

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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 12:37:50 PM
On Nov 23, 2:21 pm, Martin Gregorie
<mar...@see.sig.for.address.invalid> wrote:
> On Sat, 22 Nov 2008 20:51:14 -0500, Arne Vajh=F8j 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 12:41:36 PM
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?

> 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 1:03:05 PM
On Nov 23, 2:33 pm, "Ken T." <nowh...@home.com> wrote:
> 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 1:07:15 PM
On Nov 23, 11:43 pm, 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.

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.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 1:15:27 PM
On Mon, 24 Nov 2008 04:41:36 -0800, James Kanze wrote:

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


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/24/2008 1:45:00 PM
On Nov 24, 12:20=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> Chris M. Thomasson wrote:
> > He responded with, "what's a memory leak?".
>
> public class Foo {
> =A0 =A0public Foo() {
> =A0 =A0 =A0bitBucket.add(this);
> =A0 =A0}
> =A0 =A0private static java.util.LinkedList<?> bitBucket =3D
> =A0 =A0 =A0new 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
0
lew (2468)
11/24/2008 7:16:09 PM
On Nov 24, 8:16=A0pm, Lew <l...@lewscanon.com> wrote:
> On Nov 24, 12:20=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:

> > Chris M. Thomasson wrote:
> > > He responded with, "what's a memory leak?".

> > public class Foo {
> > =A0 =A0public Foo() {
> > =A0 =A0 =A0bitBucket.add(this);
> > =A0 =A0}
> > =A0 =A0private static java.util.LinkedList<?> bitBucket =3D
> > =A0 =A0 =A0new 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. =A0It 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.  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.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/24/2008 10:14:01 PM
On Sun, 23 Nov 2008, Roedy Green wrote:

> On 23 Nov 2008 13:33:25 GMT, "Ken T." <nowhere@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.
0
twic (2088)
11/24/2008 10:45:59 PM
On Mon, 24 Nov 2008, James Kanze wrote:

> 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

-- 
Tomorrow has made a phone call to today.
0
twic (2088)
11/24/2008 10:47:43 PM
James Kanze wrote:
> On Nov 24, 8:16 pm, Lew <l...@lewscanon.com> wrote:
>> On Nov 24, 12:20 am, Joshua Cranmer <Pidgeo...@verizon.invalid>
>> wrote:
>
>>> 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++.
>
> 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.

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. 


0
rbv (28)
11/24/2008 10:56:44 PM
Tom Anderson wrote:
> 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
0
lew (2468)
11/24/2008 11:04:06 PM
On Mon, 24 Nov 2008 14:14:01 -0800, James Kanze <james.kanze@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.

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
0
NpOeStPeAdM (1108)
11/24/2008 11:06:10 PM
"Lew" <noone@lewscanon.com> wrote in message news:ggdd20$eds$2@aioe.org...
> Chris M. Thomasson wrote:
>> 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++.

=^D
0
no6 (2828)
11/25/2008 12:09:42 AM
Sanny <softtanks@hotmail.com> wrote:
>
>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, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
11/25/2008 4:14:02 AM
Lew <noone@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.  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.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
11/25/2008 4:24:56 AM
On Sat, 22 Nov 2008 15:42:04 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
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.
-- 
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)
0
see_website (5876)
11/25/2008 5:20:24 AM
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?


> 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

0
lruss (582)
11/25/2008 6:34:55 AM
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.

> 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 9:32:23 AM
On Nov 24, 11:45 pm, Tom Anderson <t...@urchin.earth.li> wrote:
> On Sun, 23 Nov 2008, Roedy Green wrote:
> > On 23 Nov 2008 13:33:25 GMT, "Ken T." <nowh...@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.

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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 9:47:09 AM
On Nov 25, 5:24 am, Tim Roberts <t...@probo.com> wrote:
> 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.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 9:57:03 AM
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?


>  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

0
lruss (582)
11/25/2008 2:38:42 PM
Sanny <softtanks@hotmail.com> wrote:
>> 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
0
noone7 (4050)
11/25/2008 2:51:22 PM
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.

And wrong.  Software development can be, and is, an engineering discipline.

-- 
Lew
0
noone7 (4050)
11/25/2008 2:54:31 PM
On Nov 22, 3:29=A0am, Sanny <softta...@hotmail.com> wrote:
[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
0
puppet_sock (479)
11/25/2008 3:55:05 PM
On Nov 22, 3:29=A0am, Sanny <softta...@hotmail.com> wrote:
[snip]
> What language should I master. I just want to know who gets higher
> 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
0
puppet_sock (479)
11/25/2008 4:10:17 PM
Lew wrote:
> 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
0
lruss (582)
11/25/2008 5:43:17 PM
LR wrote:
> Lew wrote:

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




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
0
lithar (20)
11/25/2008 6:02:07 PM
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? =A0

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.

0
courpron (89)
11/25/2008 6:14:41 PM
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.

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
0
twic (2088)
11/25/2008 6:40:21 PM
On Tue, 25 Nov 2008, James Kanze wrote:

> 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

-- 
The literature is filled with bizarre occurrances for which we have
no explanation
0
twic (2088)
11/25/2008 6:45:34 PM
On Tue, 25 Nov 2008, James Kanze wrote:

> On Nov 24, 11:45 pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> On Sun, 23 Nov 2008, Roedy Green wrote:
>>> On 23 Nov 2008 13:33:25 GMT, "Ken T." <nowh...@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.
>
> 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.

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

-- 
The literature is filled with bizarre occurrances for which we have
no explanation
0
twic (2088)
11/25/2008 6:55:53 PM
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-778830787-1227640376=:3153
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 25 Nov 2008, courpron@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.

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.

tom

-- 
The literature is filled with bizarre occurrances for which we have
no explanation
---910079544-778830787-1227640376=:3153--
0
twic (2088)
11/25/2008 7:12:56 PM
I am surprised that Lew hasn't castigated you for writing I in lower 
case. How come you're working in Lithuania, by the way?
0
11/25/2008 7:41:10 PM
On Nov 25, 2:41=A0pm, 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.

--
Lew
0
lew (2468)
11/25/2008 7:50:57 PM
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.

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?)
0
11/25/2008 9:30:29 PM
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? =A0
>
> > 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, we=
b
> 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.


0
courpron (89)
11/25/2008 9:45:12 PM
On Tue, 25 Nov 2008 19:12:56 +0000, Tom Anderson wrote:

> 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       |
0
martin5229 (287)
11/25/2008 10:08:11 PM
On Nov 25, 7:55=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:
> 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. =A0You 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 11:13:52 PM
On Nov 25, 3:38=A0pm, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > =A0Software 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. =A0If 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? =A0Does 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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 11:17:48 PM
On Nov 25, 8:12=A0pm, 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? =A0

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

> If a shop does this - uses those methods to prove that their
> software works - then i'm happy to call them software
> engineers. Ecstatic, in fact - it's a great and wonderful
> achievement.

> But i believe that the number of such shops is vanishingly
> small, and concentrated in a few sectors where the cost is
> worth it - real-time control, telecoms, aerospace, defence,
> medical devices. It's not a technique that is used for the
> common bulk of software - desktop apps, web apps, even
> operating systems. Furthermore, i don't believe it can be,
> because such systems tend to be complex enough that the cost
> of proving correctness would be so astronomical that it
> wouldn't be economical.

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 11:21:34 PM
James Kanze <james.kanze@gmail.com> kirjutas:

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

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

Paavo
0
paavo9668 (26)
11/25/2008 11:28:07 PM
On Nov 25, 7:40=A0pm, 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. =A0This 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.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/25/2008 11:33:10 PM
On Tue, 25 Nov 2008, Lars Enderin wrote:

> 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
0
twic (2088)
11/26/2008 12:25:51 AM
AL wrote:

> 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




0
lruss (582)
11/26/2008 12:59:31 AM
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1566155815-1227661189=:29314
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 25 Nov 2008, courpron@gmail.com wrote:

> 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

-- 
Heinlein has done more to harm SF than has any other writer, I think. --
PKD
---910079544-1566155815-1227661189=:29314--
0
twic (2088)
11/26/2008 12:59:49 AM
courpron@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.

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
0
lruss (582)
11/26/2008 1:00:58 AM
James Kanze wrote:
> 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
0
lruss (582)
11/26/2008 1:28:52 AM
James Kanze wrote:
> 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
principle is being applied in "software engineering"?

LR
0
lruss (582)
11/26/2008 1:30:59 AM
Tom Anderson wrote:

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

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

LR
0
lruss (582)
11/26/2008 1:33:30 AM
James Kanze wrote:
> 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
0
noone7 (4050)
11/26/2008 1:53:49 AM
Tom Anderson wrote:
> 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
0
noone7 (4050)
11/26/2008 1:59:35 AM
LR wrote:
> 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
0
arne6 (9808)
11/26/2008 2:01:05 AM
LR wrote:
> I've seen some bridges come with documentation that says things like "No
> vehicles over 5 [sic] tons." But I can't say I can recall ever seeing
> documentation for a program that says "Do not enter numbers over
> 1,000,000.00 or your computer will break." Sometimes the program itself
> will tell you after you enter a bad number.  I suppose that would be
> more like driving a six ton truck on the aforementioned bridge, without
> the sign present, with perhaps obvious consequences.  Although I suspect
> the bridge sign was probably written with some safety factor in mind,
> whereas the program probably won't work if 1,000,000.01 is entered.

I can not think of any serious enterprise app where the docs
does not specify a lot of limits (both functional and for
given hardware performance related).

Arne
0
arne6 (9808)
11/26/2008 2:16:36 AM
LR wrote:
     [...]
> and I've been told by several engineers that
> engineering is the application of scientific principle, so if you don't
> mind, even though you can't do the full four years here, I was wondering
> if you could take a shot at answering what I think is a simple question
> with what might be a quick answer:

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

> What scientific principle is being applied in "software
> engineering"?

The fourth law of thermodynamics :-)

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

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

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

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

-- 
   Gennaro Prota         |           name.surname yahoo.com
     Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
     Do you need expertise in C++?   I'm available.
0
prota (69)
11/26/2008 2:25:07 AM
James Kanze wrote:
> The revolution in software development took place long ago (by
> the usual measures in this field).  Software engineering is a
> mature discipline today, even if there are still a lot of
> retrograde shops which don't understand this.

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

I very much doubt that software engineering is mature.

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

Arne
0
arne6 (9808)
11/26/2008 3:01:28 AM
Gennaro Prota wrote:
> LR wrote:
>      [...]
>> and I've been told by several engineers that
>> engineering is the application of scientific principle, so if you don't
>> mind, even though you can't do the full four years here, I was wondering
>> if you could take a shot at answering what I think is a simple question
>> with what might be a quick answer:
> 
> It's one of those questions made more to give semblance of
> asking something intelligent than to really understand things.


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


> 
>> What scientific principle is being applied in "software
>> engineering"?
> 
> The fourth law of thermodynamics :-)

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

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


> 
> Since you were after a quick answer, is quoting the IEEE
> 610.12-1990 definition of "software engineering" enough?
> 
> (1) The application of a systematic, disciplined, quantifiable
>      approach to the development, operation, and maintenance of
>      software; that is, the application of engineering to
>      software.
> (2) The study of approaches as in (1).
> 
> Cf. the definition of "engineering" in the same standard.
> 
> It's not something free of disputes, but you'd have to
> acknowledge that the Institute of Electrical and Electronics
> Engineers has something to say about "engineering", wouldn't
> you?
> 

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

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

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

Why is that?

LR


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


Please define what you mean by the word "serious" in the above. TIA

LR
0
lruss (582)
11/26/2008 3:22:21 AM
AL wrote:
>> 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?  :)

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

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

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

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

-- 
Lew
0
noone7 (4050)
11/26/2008 3:26:41 AM
Gennaro Prota wrote:
>> Since you were after a quick answer, is quoting the IEEE
>> 610.12-1990 definition of "software engineering" enough?
>>
>> (1) The application of a systematic, disciplined, quantifiable
>>      approach to the development, operation, and maintenance of
>>      software; that is, the application of engineering to
>>      software.
>> (2) The study of approaches as in (1).
>>
>> Cf. the definition of "engineering" in the same standard.
>>
>> It's not something free of disputes, but you'd have to
>> acknowledge that the Institute of Electrical and Electronics
>> Engineers has something to say about "engineering", wouldn't
>> you?

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

That would not be fair.  He quoted a noted and authoritative source for 
definitions of engineering disciplines that categorizes an endeavor as 
"software engineering".  That is evidence.

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

Providing an authoritative definition from a professional organization with an 
acknowledged expertise in the area is not a "semblance of something 
intelligent" but the real thing which does promote an ability "to really 
understand things".

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

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

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

Try:

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

Arne
0
arne6 (9808)
11/26/2008 3:34:22 AM
LR wrote:
> Tom Anderson wrote:
> 
>> Still, i call myself a 'software engineer' because it sounds more 
>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>> and academics and the like.
> 
> IANAL, but since you're calling yourself a "software engineer" might I
> ask what jurisdiction you do that in?

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

-- 
Lew
0
noone7 (4050)
11/26/2008 4:07:54 AM
On Nov 26, 12:28 am, Paavo Helde <pa...@nospam.please.org> wrote:
> James Kanze <james.ka...@gmail.com> kirjutas:

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

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/26/2008 8:46:35 AM
On Nov 26, 1:25 am, Tom Anderson <t...@urchin.earth.li> wrote:
> On Tue, 25 Nov 2008, Lars Enderin wrote:
> > 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.

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

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

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

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

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

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/26/2008 9:19:03 AM
On Nov 26, 2:00 am, LR <lr...@superlink.net> wrote:
> 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.

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/26/2008 9:21:40 AM
On Nov 26, 2:28 am, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > 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.

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

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

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

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

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

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

> I think software doesn't have this particular problem.

I'm not exactly sure what problem you're referring to.  If I've
understood you correctly, then no, software doesn't have this
problem.  Which makes verification several orders of magnitude
easier; you know the full environment.  For some types of
software, at laest.  For real time software, it's less obvious,
since it's fairly hard to be sure that you've analysed all
possible timing issues.  But it's still several orders of
magnitude easier than verifying that you've analysed all
possible physical interactions which might affect a bridge.

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

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

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

Mathematics.

Seriously, engineering is a lot more than just the application
of scientific principles---engineering is also concerned with
esthetics, cost, development methodology, etc.  (Take a look at
some of the bridges designed by Gustave Eiffel---the viaduc de
Garabit, for example---and tell me that esthetics aren't
involved).  But the operative word in your case is "principles",
not just one principle, but more the set of all of them.

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/26/2008 9:35:08 AM
On 26 nov, 01:59, Tom Anderson <t...@urchin.earth.li> wrote:
> On Tue, 25 Nov 2008, courp...@gmail.com wrote:
>
> [...]
>
> > I don't have the numbers and you don't have them either. In particular,
> > I wouldn't use the adverb "vanishingly". Furthermore, any software
> > developper that adopts a defensive programming approach and uses
> > assertions as pre/postconditions starts to be on the path of DbC. Such
> > programmers can develop reliable components because of sufficient
> > defensive programming techniques.
>
> No, sorry, DbC not accompanied by proof - as i understand (perhaps
> wrongly, and please correct me if so) is normal for mainstream DbC, for
> instance in Eiffel - is not any kind of analogue of proven correctness.
> It's no more than a very regular and powerful testing mechanism. I'm all
> for testing, and i think DbC-style pre/postcondions are a great idea, but
> they do not constitute proof.

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

> [...]
>
> > If you want to "prove" by DbC a large, existing software, then yes, it
> > can be costy. If you start a project and use DbC from the beginning of
> > the development cycle, you can actually make savings because of the
> > testing phase removal/reduction I mentioned earlier.
>
> If anyone tried to sell me a project with a superficial testing phase on
> the grounds that they'd designed it by contract, i would not be impressed.

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


Alexandre Courpron.

0
courpron (89)
11/26/2008 9:46:42 AM
On Nov 26, 4:01 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> James Kanze wrote:
> > The revolution in software development took place long ago
> > (by the usual measures in this field).  Software engineering
> > is a mature discipline today, even if there are still a lot
> > of retrograde shops which don't understand this.

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

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

> I very much doubt that software engineering is mature.

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

Certainly.  That will always be the case.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/26/2008 9:51:30 AM
On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
> courp...@gmail.com wrote:
> > On 25 nov, 15:38, LR <lr...@superlink.net> wrote:
>
> >> =A0{...]
> >> Do the programs provably work? To the same extent that an engineer cou=
ld
> >> "prove" that the bridge they designed will work? =A0
>
> > There is a whole branch of computer science that is dedicated to
> > "program provability". In the practical world, the theory gave rise to
> > what is called "design by contract", by which you define formally the
> > specifications of your program with pre/postconditions, invariants,
> > etc. You can mathematically prove that your program will work by those
> > means. This is used in any sensible environment that needs absolutely
> > reliable softwares.
>
> Absolutely reliable? Suppose you have a =A0customer who wants a formal
> proof that the program you've written will halt. =A0Can you provide that?

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

Alexandre Courpron.
0
courpron (89)
11/26/2008 10:08:09 AM
On 2008-11-25, James Kanze <james.kanze@gmail.com> wrote:
> On Nov 25, 7:40�pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> With a bridge, i can build a system of linear equations that
>> describes it, not perfectly, but to a high degree of accuracy,
>> and i can put those into a computer and solve them, and show
>> that the bridge won't fall down when trains run across it. 
>> (...)
>
> I fear you don't really understand what engineering is about.
> In a very real sense, most software is more provable than any
> bridge, because all possible inputs are known, and nothing else
> is relevant.

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

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

Cheers,
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
11/26/2008 12:09:34 PM
On 2008-11-26, Tom Anderson <twic@urchin.earth.li> wrote:
>
> 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.

Capitalising the first person singular is expected by the vast
majority of readers, and it is expected to such an extent that not
capitalising it effectively makes the text harder to read. When you
consistently fail to do it on purpose it reveals a fundamental
disrespect for your readers that, in turn, causes me to lose respect
for you as a writer. Similarly there are those who feel that
capitalising the first word of a sentence is an archaic habit that
might as well be ignored, or that the established conventions for
punctuation are purely optional.

Now, for all of these it may very well be that they are correct, that
they are part of a linguistic movement that will lead to the gradual
shift of the language in the direction that they are advocating. This
is all well and good but in the mean time their text /is/ harder to
read and this /does/ have an intrinsic cost both to themselves and to
others.

It's either the price of progress or else the price of being wrong
about progress.

Cheers,
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
11/26/2008 12:46:43 PM
James Kanze <james.kanze@gmail.com> writes:
> On Nov 26, 12:28 am, Paavo Helde <pa...@nospam.please.org> wrote:
>> James Kanze <james.ka...@gmail.com> kirjutas:
>> > (I've worked on some joint French/German projects, and even there,
>> > cultural differences created a lot of difficulties.)
>
>> Fascinating, would you care to give an example? (just a
>> theoretical interest, I'm neither French nor German).
>
> Well, it affected almost all levels, and part of it was due to
> differences in corporate culture.  One simple example: the French use
> a lot more white space in their coding guidelines.  More importantly,
> perhaps, were expectations with regards to personal relationships.
> It's difficult to describe these in detail, because of course there
> was a great deal of personal variance, and there were a lot of people
> in both groups who you might situation "in the middle".

     When I was working with a group of primarily French and Belgian
nationals, the company was bought by a German company.  Amidst the
general wailing and gnashing of teeth, I was able to figure out that
they were saying "The Germans are coming.  With their *binders*."

     Sure enough, the new policies and procedures were specified ad
nauseam in shelves of three-inch binders.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
http://www.spe.com/pjm | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
11/26/2008 2:37:40 PM
LR wrote:
> AL wrote:
> 
>> 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?
> 


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


FWIW, not all engineers design bridges.

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

How I came to design software is a whole other story but suffice it to 
say that I found the discipline of engineering to be directly 
transferable to the development of software.  I took over a position 
vacated by someone who probably should have been out writing a book 
(programming analogy provided by someone else in this thread) rather 
than designing software. I also worked with someone who entered the 
programming field from a job in social services. What I found sadly 
lacking in the work of these genuinely nice folks was the vaguest notion 
of logic and structured design. And that was back in the days when the 
programming language itself imposed some limits on how careless you 
could get. IMO, the freedom JAVA provides to go totally berserk 
*demands* an engineered approach to software design.

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

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




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

AL
0
lithar (20)
11/26/2008 3:33:02 PM
AL wrote:
> BTW, did anyone ever answer the question posed in the subject line?

Yes, many times in this thread.

--
Lew
0
lew (2468)
11/26/2008 4:33:45 PM
On Tue, 25 Nov 2008, LR wrote:

> courpron@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.
>
> Absolutely reliable? Suppose you have a customer who wants a formal 
> proof that the program you've written will halt.  Can you provide that?

He might well be able to. Don't make the mistake of thinking that the 
undecidability of the halting problem means you can't ever prove a program 
will or will not terminate. It doesn't. It just means that you won't be 
able to prove it for *some* programs (or rather, combinations of programs 
and inputs). Much like how Goedel's incompleteness theorem doesn't mean 
you can't prove anything, it means you can't prove everything.

tom

-- 
Brace yourself for an engulfing, cowardly autotroph! I want your
photosynthetic apparatii!
0
twic (2088)
11/26/2008 5:12:13 PM
On Tue, 25 Nov 2008, LR wrote:

> Tom Anderson wrote:
>
>> Still, i call myself a 'software engineer' because it sounds more
>> high-status than 'programmer', and i go to a lot of parties with lawyers
>> and academics and the like.
>
> IANAL, but since you're calling yourself a "software engineer" might I 
> ask what jurisdiction you do that in?

In the UK.

tom

-- 
Brace yourself for an engulfing, cowardly autotroph! I want your
photosynthetic apparatii!
0
twic (2088)
11/26/2008 5:13:38 PM
On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:

> On Tue, 25 Nov 2008, LR wrote:
> 
>> Tom Anderson wrote:
>>
>>> Still, i call myself a 'software engineer' because it sounds more
>>> high-status than 'programmer', and i go to a lot of parties with
>>> lawyers and academics and the like.
>>
>> IANAL, but since you're calling yourself a "software engineer" might I
>> ask what jurisdiction you do that in?
> 
> In the UK.
> 
Same here: its well recognised in the UK. I hold a CE in software 
engineering as well as an MSc (Chemistry).


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/26/2008 6:47:15 PM
James Kanze wrote:
> On Nov 26, 12:28 am, Paavo Helde <pa...@nospam.please.org> wrote:
>> James Kanze <james.ka...@gmail.com> kirjutas:
> 
>>> (I've worked on some joint French/German projects, and even
>>> there, cultural differences created a lot of difficulties.)
> 
>> Fascinating, would you care to give an example? (just a
>> theoretical interest, I'm neither French nor German).
> 
> Well, it affected almost all levels, and part of it was due to
> differences in corporate culture.  One simple example: the
> French use a lot more white space in their coding guidelines.
> More importantly, perhaps, were expectations with regards to
> personal relationships.  

It can work well, I worked on a couple of projects within Alcatel, all
of these were multi-national.  The company had a policy of multinational
teams at that time (late 80s) with all written communication (including
meeting minutes) in English.  That caused a few grumbles when there were
no native English speakers at meetings!  Female software was an
interesting concept for the English members to grasp...

-- 
Ian Collins
0
ian-news (10155)
11/26/2008 7:24:12 PM
On Nov 25, 1:55=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:
[snip]
> Either way, another 10-15 years from now, things may look very different.

This is likely to be true regardless of whether it's
India or North America, or what language, or what
kind of computer, etc.

What did software look like in 1993? What did the
"interweb" look like in 1993? Where were entities
like Google and Amazon.com? C++ was still pretty
young, though it was a precocious little squirt.

> 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 plan=
e
> 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?

The amount of contact you need with the user/client
is highly variable from project to project.

The less clearly the spec is known, the more contact
I'd expect you to need. I've been on projects where
the client and I would sit down at a terminal three
or four times a week and bash at the interface.
"This sucks, this is good, that's confusing, what's
this for?" We'd do that for two or three hours,
then I'd take my notes and his notes back to my
desk and develop them for a day or so, and then we'd
be back at the terminal over the app again.

This was because the requirements for the app were
not very clearly defined. The guy was doing trades
with the app while I was hacking it. (In the test
market system, not the real system.) He'd find that
it was clumsy doing things the way they thought they
would do it, and changed his mind. Then he'd have
an idea that some feature needed to be more prominent.
And another needed polish. And another had to be faster.

It was a wild and crazy project. But the end result
satisfied the traders. I got "gold star" reviews
from everybody on the trade floor. My boss was happy.
His boss was happy. The traders and two levels of
their bosses were happy. Productivity abounded.

Though it was sometimes hard to be open and accurate
about the current progress of the project.

The software I replaced was supposed to be developed
on an at-a-distance basis. The client tested and
sent emails of bug reports. A month later they
would send the new version with the "bug fixes."
And the old bugs would still be there, and new
bugs would be added. After 20 consecutive months
when the bug count rose every month, upper levels
of management pulled the plug. And the lawyers
and other suits took the project.
Socks
0
puppet_sock (479)
11/26/2008 7:27:40 PM
Ian Collins wrote:


> Female software was an interesting concept for the English members to grasp...


hmmm...  :)

AL ( aka dirty old man)
0
lithar (20)
11/26/2008 7:44:24 PM
Lew wrote:
> AL wrote:
>>> 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?  :)
> 
> LR wrote:
>> No, not at all, in fact, not the least little bit.  I'll be happy to
>> repeat my fundamental question.  I've been told, by engineers if that's
>> relevant, that engineering is the application of scientific principle.
>> What scientific principle is being applied in the development of software?
> 
> Logic, a branch of mathematics, for one.  Not that I agree that you have 
> defined engineering completely, or even correctly.  Also, algorithms and data 
> structures.  Before you say those aren't scientific principles, you'll have to 
> let me know what you mean by "science", which I understand to be the formal 
> and rigorous study of phenomena to elicit the underlying structures and 
> relationships pertaining to the area of study.  The formal study of the 
> underlying structures and relationships of software is called "computer 
> science".  So the scientific principles of software engineering are the 
> principles of computer science.

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

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

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


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

Sorry, I think that qualifies as mathematics.

LR


0
lruss (582)
11/26/2008 9:02:31 PM
Lew wrote:
> Gennaro Prota wrote:
>>> Since you were after a quick answer, is quoting the IEEE
>>> 610.12-1990 definition of "software engineering" enough?
>>>
>>> (1) The application of a systematic, disciplined, quantifiable
>>>      approach to the development, operation, and maintenance of
>>>      software; that is, the application of engineering to
>>>      software.
>>> (2) The study of approaches as in (1).
>>>
>>> Cf. the definition of "engineering" in the same standard.
>>>
>>> It's not something free of disputes, but you'd have to
>>> acknowledge that the Institute of Electrical and Electronics
>>> Engineers has something to say about "engineering", wouldn't
>>> you?
> 
> LR wrote:
>> In that case, please allow me to paraphrase what you wrote above.
> 
> That would not be fair.  He quoted a noted and authoritative source for 
> definitions of engineering disciplines that categorizes an endeavor as 
> "software engineering".  That is evidence.

Argument by appeal to authority? Well, I've done that too. And there was
nothing whatsoever unfair about it.

> 
>> It's one of those answers made more to give semblance of saying
>> something intelligent than to really understand things.
> 
> Providing an authoritative definition from a professional organization with an 
> acknowledged expertise in the area is not a "semblance of something 
> intelligent" but the real thing which does promote an ability "to really 
> understand things".

So far it hasn't helped me except as more evidence that there isn't any
scientific principle being applied in this so called engineering disciple.


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

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

LR



0
lruss (582)
11/26/2008 9:05:40 PM
Arne Vajhøj wrote:
> LR wrote:
>> Arne Vajhøj wrote:
>>> LR wrote:
>>>> I've seen some bridges come with documentation that says things like "No
>>>> vehicles over 5 [sic] tons." But I can't say I can recall ever seeing
>>>> documentation for a program that says "Do not enter numbers over
>>>> 1,000,000.00 or your computer will break." Sometimes the program itself
>>>> will tell you after you enter a bad number.  I suppose that would be
>>>> more like driving a six ton truck on the aforementioned bridge, without
>>>> the sign present, with perhaps obvious consequences.  Although I suspect
>>>> the bridge sign was probably written with some safety factor in mind,
>>>> whereas the program probably won't work if 1,000,000.01 is entered.
>>> I can not think of any serious enterprise app where the docs
>>> does not specify a lot of limits (both functional and for
>>> given hardware performance related).
>> Please define what you mean by the word "serious" in the above. TIA
> 
> Try:
> 
> http://www.google.com/search?hl=en&q=define%3Aserious&btnG=Google+Search&aq=f&oq=
> 


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

LR
0
lruss (582)
11/26/2008 9:07:01 PM
Lew wrote:
> LR wrote:
>> Tom Anderson wrote:
>>
>>> Still, i call myself a 'software engineer' because it sounds more 
>>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>>> and academics and the like.
>> IANAL, but since you're calling yourself a "software engineer" might I
>> ask what jurisdiction you do that in?
> 
> I call myself a "software engineer" in Maryland, the U.S. of A.
> 

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

LR
0
lruss (582)
11/26/2008 9:08:34 PM
On Nov 26, 4:02=A0pm, LR <lr...@superlink.net> wrote:
> Lew wrote:
> > AL wrote:
> >>> 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 creat=
ive
> >>> spark for such innovative work? =A0:)
>
> > LR wrote:
> >> No, not at all, in fact, not the least little bit. =A0I'll be happy to
> >> repeat my fundamental question. =A0I've been told, by engineers if tha=
t's
> >> relevant, that engineering is the application of scientific principle.
> >> What scientific principle is being applied in the development of softw=
are?
>
> > Logic, a branch of mathematics, for one. =A0Not that I agree that you h=
ave
> > defined engineering completely, or even correctly. =A0Also, algorithms =
and data
> > structures. =A0Before you say those aren't scientific principles, you'l=
l have to
> > let me know what you mean by "science", which I understand to be the fo=
rmal
> > and rigorous study of phenomena to elicit the underlying structures and
> > relationships pertaining to the area of study. =A0The formal study of t=
he
> > underlying structures and relationships of software is called "computer
> > science". =A0So the scientific principles of software engineering are t=
he
> > principles of computer science.
>
> That sounds like mathematics to me. =A0I've always been told that Compute=
r
> Science is a branch of mathematics. =A0Just because something is called
> science doesn't mean it is, the same as if you call something
> engineering it doesn't mean it is.
>
>
>
> > Just because an engineering discipline is relatively young and not nece=
ssarily
> > well developed doesn't mean that it's not engineering.
>
> I agree. =A0But something that isn't engineering won't become engineering
> as it gets more mature.
>
>
>
> > Engineering is also about the way in which one applies "scientific" pri=
nciples
> > to solve real-world problems. =A0While the structural physics of buildi=
ngs or
> > bridges differs from the structural rules of software, there is a cohes=
ive and
> > formalizable set of principles to software. =A0The deliberate and knowl=
edgeable
> > attempt to apply those principles, i.e., the principles of computer sci=
ence,
> > qualifies as engineering.
>
> Sorry, I think that qualifies as mathematics.

What a specious argument.

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

There is no reasoning with you.

--
Lew
0
lew (2468)
11/26/2008 9:20:22 PM
James Kanze wrote:
> On Nov 26, 2:28 am, LR <lr...@superlink.net> wrote:
>> James Kanze wrote:
>>> 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.
> 
> Not entirely.  It's generally easier to verify that software
> will work than it is for a bridge, because software works in a
> very controlled medium.

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

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

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

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

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

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


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

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



> 
>>>> What kinds of metrics are used?  Does software have a
>>>> stress point beyond which it will deform, like the metal in
>>>> the bridge will?
> 
>>> Seehttp://www.sei.cmu.edu/.  I obviously can't stuff a four
>>> year course in software engineering into a web article.
> 
>> No, I agree that would be difficult. I think I've visited that
>> site in the past.  However, I've always thought that Computer
>> Science was a branch of Mathematics, and I've been told by
>> several engineers that engineering is the application of
>> scientific principle, so if you don't mind, even though you
>> can't do the full four years here, I was wondering if you
>> could take a shot at answering what I think is a simple
>> question with what might be a quick answer:  What scientific
>> principle is being applied in "software engineering"?
> 
> Mathematics.

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


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

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

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

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

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


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

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

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

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

LR

0
lruss (582)
11/26/2008 9:32:19 PM
courpron@gmail.com wrote:
> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>> 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.
>> Absolutely reliable? Suppose you have a  customer who wants a formal
>> proof that the program you've written will halt.  Can you provide that?
> 
> Yes, absolutely reliable. The program is proven to be correct in any
> way. The proof can be given in the form of mathematical notations.

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

LR
0
lruss (582)
11/26/2008 9:34:44 PM
LR wrote:

> Sorry, I think that qualifies as mathematics.

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

Tom
0
tdemjen (5)
11/26/2008 9:35:39 PM
LR wrote:
>>> I'd say this is a definition that is at variance with all the other
>>> answers I've gotten from engineers over the past apprx 35 years.
>> Let's see, a definition from the professional organization of engineers whose 
>> business includes software engineering is at variance with the answers you 
>> claim to have gotten from engineers (not cited by name, I notice) over "apprx" 
>> 35 years.  I think I'll align with the definition offered by the professional 
>> society whose business it is over the unattributed anecdotal non-evidence of 
>> your hearsay.
> 
> If that choice works for you, then that's what's best for you.  I'm
> still waiting for a single example of a scientific principle applied in
> the development of software.

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

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

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

-- 
   Gennaro Prota         |           name.surname yahoo.com
     Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
     Do you need expertise in C++?   I'm available.
0
prota (69)
11/26/2008 9:37:09 PM
On 26 nov, 22:34, LR <lr...@superlink.net> wrote:
> courp...@gmail.com wrote:
> > On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
> >> courp...@gmail.com wrote:
> >>> On 25 nov, 15:38, LR <lr...@superlink.net> wrote:
> >>>> =A0{...]
> >>>> Do the programs provably work? To the same extent that an engineer c=
ould
> >>>> "prove" that the bridge they designed will work? =A0
> >>> There is a whole branch of computer science that is dedicated to
> >>> "program provability". In the practical world, the theory gave rise t=
o
> >>> 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 thos=
e
> >>> means. This is used in any sensible environment that needs absolutely
> >>> reliable softwares.
> >> Absolutely reliable? Suppose you have a =A0customer who wants a formal
> >> proof that the program you've written will halt. =A0Can you provide th=
at?
>
> > Yes, absolutely reliable. The program is proven to be correct in any
> > way. The proof can be given in the form of mathematical notations.
>
> I'm not sure you responded to my question, so please allow me to restate
> it. =A0Suppose you have a customer who wants a formal proof that the
> program you've written will halt, can you provide that?

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

Alexandre Courpron.

0
courpron (89)
11/26/2008 10:23:27 PM
AL wrote:
> LR wrote:
>> AL wrote:
>>
>>> 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?
>>
> 
> 
> Help me understand your definition of "scientific principle" 

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


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

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

> 
> 
> FWIW, not all engineers design bridges.

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

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

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

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

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


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

Sounds a little like my background.

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


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




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

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

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

In some circumstances.

> Acknowledging I might be a bit biased. :)

;)


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

Not to be completely contrarian, but is that answerable? ;)

LR


0
lruss (582)
11/26/2008 10:24:06 PM
Martin Gregorie wrote:
> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
> 
>> On Tue, 25 Nov 2008, LR wrote:
>>
>>> Tom Anderson wrote:
>>>
>>>> Still, i call myself a 'software engineer' because it sounds more
>>>> high-status than 'programmer', and i go to a lot of parties with
>>>> lawyers and academics and the like.
>>> IANAL, but since you're calling yourself a "software engineer" might I
>>> ask what jurisdiction you do that in?
>> In the UK.
>>
> Same here: its well recognised in the UK. I hold a CE in software 
> engineering as well as an MSc (Chemistry).
> 

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

LR
0
lruss (582)
11/26/2008 10:26:15 PM
LR wrote:
> courpron@gmail.com wrote:
>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>> 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.
>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>> proof that the program you've written will halt.  Can you provide
>>> that?
>>
>> Yes, absolutely reliable. The program is proven to be correct in any
>> way. The proof can be given in the form of mathematical notations.
>
> I'm not sure you responded to my question, so please allow me to
> restate it.  Suppose you have a customer who wants a formal proof
> that the program you've written will halt, can you provide that?

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

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

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

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

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

The proof runs something like this:

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

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

QED This function returns in finite time for all inputs.

>
> LR 


0
rbv (28)
11/26/2008 10:42:58 PM
> So far it hasn't helped me except as more evidence that there isn't
> any scientific principle being applied in this so called engineering
> disciple.

And you'd be wrong.

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

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


0
rbv (28)
11/26/2008 10:46:58 PM
LR wrote:
> Martin Gregorie wrote:
>> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>>
>>> On Tue, 25 Nov 2008, LR wrote:
>>>
>>>> Tom Anderson wrote:
>>>>
>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>> high-status than 'programmer', and i go to a lot of parties with
>>>>> lawyers and academics and the like.
>>>> IANAL, but since you're calling yourself a "software engineer"
>>>> might I ask what jurisdiction you do that in?
>>> In the UK.
>>>
>> Same here: its well recognised in the UK. I hold a CE in software
>> engineering as well as an MSc (Chemistry).
>>
>
> Some of the states too, I think.  However, I read a little of the law
> for one state and it doesn't really describe an engineering
> discipline. It actually used the phrase "computer programming".  At
> least AFAIR.

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

>
> LR 


0
rbv (28)
11/26/2008 10:51:15 PM
>> Help me understand your definition of "scientific principle"
>
> By way of example, "F = ma" is a scientific principle.  I^2*R=W is a
> scientific principle. Hz = 1/(2*PI*sqrt(L*C)) is a scientific
> principle.
> I admit I had to pull out my copy of Marks for that last one. It's a
> been a long time since I needed it.

Actually I think that last should be

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

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

You've confused variables with their units. 


0
rbv (28)
11/26/2008 10:58:33 PM
LR <lruss@superlink.net> kirjutas:

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

Obviously you have not done MFC programming ;-) If you tried that, it 
would become clear that programming (at least in this environment) is an 
experimental discipline. You set up experiments to determine how the 
library (MFC) behaves under some simulated conditions; you keep the 
records and try to infer some general rules from that; then you attempt 
to construct your own software according to the rules you have found, in 
the hope that it will function to some extent also in other space and 
time points. 

Sounds like physics+engineering to me ;-) Seriously, in every case you 
don't have a full control over the environment, it's engineering (my 2 
cents definition ;-)  If you have full control, then it's mathematics. 
Regarding to programming, full control would mean computers with infinite 
memory and infinite speed. If that was the case, programming would be 
indeed reduced to a branch of mathematics or logic. Any mathematically 
correct algorithm, however slow or memory-consuming, would qualify as a 
valid and usable program. As we are not there yet, programming needs 
engineering approach.

Paavo
0
paavo1 (190)
11/26/2008 11:18:14 PM
LR wrote:
>> I'm not sure you responded to my question, so please allow me to
>> restate it.  Suppose you have a customer who wants a formal proof
>> that the program you've written will halt, can you provide that?

.... proof elided ...
Ben Voigt [C++ MVP] wrote:
> QED This function returns in finite time for all inputs.

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

-- 
Lew
0
noone7 (4050)
11/27/2008 12:59:30 AM
On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:

> 
> But I think I made it plain that engineers don't consider the entire
> physics of the bridge. They might not consider fluid interactions or
> wind loading or some such.  The parameters are likely to be driven by
> budget, customer requirements or perhaps good practice.
>
That's quite wrong. The engineers who designed the Tay and the Tacoma 
Narrows bridges ignored wind and look where that got them.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/27/2008 1:13:22 AM
On Nov 26, 4:05=A0pm, LR <lr...@superlink.net> wrote:
> Lew wrote:
> > Let's see, a definition from the professional organization of engineers=
 whose
> > business includes software engineering is at variance with the answers =
you
> > claim to have gotten from engineers (not cited by name, I notice) over =
"apprx"
> > 35 years. =A0I think I'll align with the definition offered by the prof=
essional
> > society whose business it is over the unattributed anecdotal non-eviden=
ce of
> > your hearsay.
>
> If that choice works for you, then that's what's best for you. =A0I'm
> still waiting for a single example of a scientific principle applied in
> the development of software.

A blind man may wait for many years after asking someone to show him
the path, though he had received a prompt response.
0
koloth17 (34)
11/27/2008 2:21:45 AM
Lew wrote:
> On Nov 26, 4:02 pm, LR <lr...@superlink.net> wrote:
>> Lew wrote:
>>> AL wrote:
>>>>> 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?  :)
>>> LR wrote:
>>>> No, not at all, in fact, not the least little bit.  I'll be happy to
>>>> repeat my fundamental question.  I've been told, by engineers if that's
>>>> relevant, that engineering is the application of scientific principle.
>>>> What scientific principle is being applied in the development of software?
>>> Logic, a branch of mathematics, for one.  Not that I agree that you have
>>> defined engineering completely, or even correctly.  Also, algorithms and data
>>> structures.  Before you say those aren't scientific principles, you'll have to
>>> let me know what you mean by "science", which I understand to be the formal
>>> and rigorous study of phenomena to elicit the underlying structures and
>>> relationships pertaining to the area of study.  The formal study of the
>>> underlying structures and relationships of software is called "computer
>>> science".  So the scientific principles of software engineering are the
>>> principles of computer science.
>> That sounds like mathematics to me.  I've always been told that Computer
>> Science is a branch of mathematics.  Just because something is called
>> science doesn't mean it is, the same as if you call something
>> engineering it doesn't mean it is.
>>
>>
>>
>>> Just because an engineering discipline is relatively young and not necessarily
>>> well developed doesn't mean that it's not engineering.
>> I agree.  But something that isn't engineering won't become engineering
>> as it gets more mature.
>>
>>
>>
>>> Engineering is also about the way in which one applies "scientific" principles
>>> to solve real-world problems.  While the structural physics of buildings or
>>> bridges differs from the structural rules of software, there is a cohesive and
>>> formalizable set of principles to software.  The deliberate and knowledgeable
>>> attempt to apply those principles, i.e., the principles of computer science,
>>> qualifies as engineering.
>> Sorry, I think that qualifies as mathematics.
> 
> What a specious argument.

I conclude that you don't have an argument.

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

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


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

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


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

I only wish that were true.


> There is no reasoning with you.

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

LR
0
lruss (582)
11/27/2008 2:54:56 AM
Gennaro Prota wrote:
> LR wrote:
>>>> I'd say this is a definition that is at variance with all the other
>>>> answers I've gotten from engineers over the past apprx 35 years.
>>> Let's see, a definition from the professional organization of engineers whose 
>>> business includes software engineering is at variance with the answers you 
>>> claim to have gotten from engineers (not cited by name, I notice) over "apprx" 
>>> 35 years.  I think I'll align with the definition offered by the professional 
>>> society whose business it is over the unattributed anecdotal non-evidence of 
>>> your hearsay.
>> If that choice works for you, then that's what's best for you.  I'm
>> still waiting for a single example of a scientific principle applied in
>> the development of software.
> 
> We might be having a problem around the term "principle". If you
> refer to scientific principles (laws) such as Archimedes'
> principle or the law of conservation of energy then, of course,
> they aren't "applied to the development of software".
> 
> "Therefore it is not 'engineering'", you are saying? Fine, it's
> a terminology problem: you might call it software-ology, for
> instance. However "software engineering" is used by an engineer
> association with an agreed upon meaning. 

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

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

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



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

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

LR


0
lruss (582)
11/27/2008 2:58:36 AM
Tamas Demjen wrote:
> LR wrote:
> 
>> Sorry, I think that qualifies as mathematics.
> 
> It's applied mathematics, 

Is applied mathematics science?


> like with other fields of engineering. 

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



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

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



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

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

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

LR


0
lruss (582)
11/27/2008 3:04:00 AM
courpron@gmail.com wrote:
> On 26 nov, 22:34, LR <lr...@superlink.net> wrote:
>> courp...@gmail.com wrote:
>>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>>> 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.
>>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>>> proof that the program you've written will halt.  Can you provide that?
>>> Yes, absolutely reliable. The program is proven to be correct in any
>>> way. The proof can be given in the form of mathematical notations.
>> I'm not sure you responded to my question, so please allow me to restate
>> it.  Suppose you have a customer who wants a formal proof that the
>> program you've written will halt, can you provide that?
> 
> If "halting of the program" was in the user requirement specifications
> of the software, then yes. Since the software was developped using
> design by contract, it can be proved to meet the specifications. If
> the specifications was impossible to meet for one reason or another,
> the software couldn't have been developped using formal methods.

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

LR
0
lruss (582)
11/27/2008 3:05:52 AM
Ben Voigt [C++ MVP] wrote:
> LR wrote:
>> courpron@gmail.com wrote:
>>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>>> 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.
>>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>>> proof that the program you've written will halt.  Can you provide
>>>> that?
>>> Yes, absolutely reliable. The program is proven to be correct in any
>>> way. The proof can be given in the form of mathematical notations.
>> I'm not sure you responded to my question, so please allow me to
>> restate it.  Suppose you have a customer who wants a formal proof
>> that the program you've written will halt, can you provide that?
> 
> You could provide a formula for the number of instructions that will be 
> executed as a function of the inputs (or the size of the inputs).  

Isn't that math?


> It's 
> considerably harder to put bounds on the number of cycles because of all the 
> crazy things modern CPUs do to try to execute a program faster and the 
> possibilities for introducing bugs at the hardware level.  But yes, it's 
> absolutely possible to write a program that will provably, given a bug-free 
> processor, halt within a certain number of instructions.  If the program 
> uses recursion this can be done as a proof by induction.  If the program 
> uses iteration it needs to be broken into basic blocks and then proof by 
> induction can be applied.
> 
> Note that the "halting problem" asserts that there is no algorithm that 
> determines whether an arbitrary program halts in finite time.  For specific 
> programs this can be very easy to determine.

I'm sorry, I'm not sure what you're saying in context.  Are you
suggesting that there's some way to distinguish between programs that
can be proven to halt and those that it can't be proven for?


[example of a program that can be proved to halt snipped]

LR
0
lruss (582)
11/27/2008 3:09:04 AM
Ben Voigt [C++ MVP] wrote:
>> So far it hasn't helped me except as more evidence that there isn't
>> any scientific principle being applied in this so called engineering
>> disciple.
> 
> And you'd be wrong.

Really?  Why? I'm waiting for a reason.

> 
>> If that choice works for you, then that's what's best for you.  I'm
>> still waiting for a single example of a scientific principle applied
>> in the development of software.
> 
> There are plenty of mathematical principles applied.  In fact, let's play 
> YOU name a principle and we'll give you an example (I already used proof by 
> induction in another response in this thread). 

I've given several examples of scientific principles in this thread.

I'll repeat them here for your convenience.

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



LR



0
lruss (582)
11/27/2008 3:13:13 AM
Ben Voigt [C++ MVP] wrote:
> LR wrote:
>> Martin Gregorie wrote:
>>> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>>>
>>>> On Tue, 25 Nov 2008, LR wrote:
>>>>
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>>> high-status than 'programmer', and i go to a lot of parties with
>>>>>> lawyers and academics and the like.
>>>>> IANAL, but since you're calling yourself a "software engineer"
>>>>> might I ask what jurisdiction you do that in?
>>>> In the UK.
>>>>
>>> Same here: its well recognised in the UK. I hold a CE in software
>>> engineering as well as an MSc (Chemistry).
>>>
>> Some of the states too, I think.  However, I read a little of the law
>> for one state and it doesn't really describe an engineering
>> discipline. It actually used the phrase "computer programming".  At
>> least AFAIR.
> 
> There is a lot of computer programming going on that doesn't involve 
> engineering.  But that doesn't mean that no software is engineered.

Perhaps I haven't been clear. I see no evidence that there is  "software
engineering" any more than computer science is a science.

I conclude that no software is engineered.  People may be following some
formal procedure.  If a cobbler wanted to s/he could follow a formal
procedure to make shoes too and it wouldn't be engineering, unless there
is some application of scientific principle to design of the shoe. Cooks
do this all the time. It's called a recipe, but they don't call it food
engineering.  That is, unless someone is actually designing the food
relative to some physical process. Software is a mathematical construct
and I do not believe it is amenable to these sorts of applications.

However, I've asked, and if someone can point out an application of
scientific principle to software development, then I'll have to change
my opinion.

LR

0
lruss (582)
11/27/2008 3:21:15 AM
Paavo Helde wrote:
> LR <lruss@superlink.net> kirjutas:
> 
>> No, I disagree.  I don't say that engineering doesn't encompass those
>> other things, I suggest that fundamentally engineering is the
>> application of scientific principle and lacking that, it isn't
>> engineering but something else.  Perhaps accounting. Or aesthetic
>> design. Or management.  Not that engineers can't do these things too.
> 
> Obviously you have not done MFC programming ;-) If you tried that, it 
> would become clear that programming (at least in this environment) is an 
> experimental discipline. You set up experiments to determine how the 
> library (MFC) behaves under some simulated conditions; you keep the 
> records and try to infer some general rules from that; then you attempt 
> to construct your own software according to the rules you have found, in 
> the hope that it will function to some extent also in other space and 
> time points. 

Lot's of programming is done this way.


> 
> Sounds like physics+engineering to me ;-)

What is the physics part?  If that were actually there, then this would
be software engineering, because you'd be applying a scientific principle.

A cook might experiment with the mixture of spices in a dish.  Is that
engineering?


>  Seriously, in every case you 
> don't have a full control over the environment, it's engineering (my 2 
> cents definition ;-)  If you have full control, then it's mathematics. 
> Regarding to programming, full control would mean computers with infinite 
> memory and infinite speed. 

I'm sorry, but I don't agree in the slightest with this conclusion. Or
else we have very different views of what control is.  But since you can
write programs with the same functionality in assembler or C++ I think
the programmer has control. I've worked on machines with 256 bytes in
machine code and I had control.

Gosh, some computers didn't even any "memory" aside from disk storage,
so I'm told.


> If that was the case, programming would be 
> indeed reduced to a branch of mathematics or logic. 

What part of it isn't?


> Any mathematically 
> correct algorithm, however slow or memory-consuming, would qualify as a 
> valid and usable program. As we are not there yet, programming needs 
> engineering approach.

I don't think that an engineering approach to something doesn't mean
that it's engineering.  I've already said in this thread that
programmers can learn quite a bit from engineers.  I don't think that's
in dispute. What is in dispute is if this _can_ result in an engineering
discipline.

LR


0
lruss (582)
11/27/2008 3:32:41 AM
Martin Gregorie wrote:
> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
> 
>> But I think I made it plain that engineers don't consider the entire
>> physics of the bridge. They might not consider fluid interactions or
>> wind loading or some such.  The parameters are likely to be driven by
>> budget, customer requirements or perhaps good practice.
>>
> That's quite wrong. The engineers who designed the Tay and the Tacoma 
> Narrows bridges ignored wind and look where that got them.


I'm sorry, but what is quite wrong?  I completely fail to understand how
your response contradicts anything I wrote above.  Please explain,
because I utterly bewildered by your response.

LR
0
lruss (582)
11/27/2008 3:36:41 AM
Captain Koloth wrote:
> On Nov 26, 4:05 pm, LR <lr...@superlink.net> wrote:
>> Lew wrote:
>>> Let's see, a definition from the professional organization of engineers whose
>>> business includes software engineering is at variance with the answers you
>>> claim to have gotten from engineers (not cited by name, I notice) over "apprx"
>>> 35 years.  I think I'll align with the definition offered by the professional
>>> society whose business it is over the unattributed anecdotal non-evidence of
>>> your hearsay.
>> If that choice works for you, then that's what's best for you.  I'm
>> still waiting for a single example of a scientific principle applied in
>> the development of software.
> 
> A blind man may wait for many years after asking someone to show him
> the path, though he had received a prompt response.


Well then, help me see. I might be slow and require repetition. Please
show me the scientific application that is used in the development of
software.


LR
0
lruss (582)
11/27/2008 3:38:48 AM
LR wrote:
> Simply because I disagree with you doesn't mean I'm a troll.  But then
> I'm quite used to having people bend words in ways that fit their
> misconceptions.  Isn't that what this discussion is about, at least in part?

And a master of it yourself.

-- 
Lew
0
noone7 (4050)
11/27/2008 5:42:25 AM
LR wrote:
> I've given several examples of scientific principles in this thread.

So have those who disagreed with you.

-- 
Lew
0
noone7 (4050)
11/27/2008 5:43:21 AM
LR wrote:
> Well then, help me see. I might be slow and require repetition. Please
> show me the scientific application that is used in the development of
> software.

Why?  This was done already and you twisted definitions and begged questions 
so that you could reject what people said.  What would make it different this 
time?

-- 
Lew
0
noone7 (4050)
11/27/2008 5:44:15 AM
LR wrote:
> It seems to me that you haven't read my posts.

Lots of things seem to you different from what they are.

-- 
Lew
0
noone7 (4050)
11/27/2008 5:45:49 AM
LR wrote:
> Software isn't engineered, so I believe your statement is based on a
> false predicate. Or at least it hasn't been demonstrated to my
> satisfaction that there is such a discipline.

Circular reasoning.  You believe that software isn't engineered, therefore 
statements that evidence otherwise violate your belief and must be "based on a 
false predicate" in your world view.

-- 
Lew
0
noone7 (4050)
11/27/2008 5:47:07 AM
LR wrote:
> Perhaps I haven't been clear. I see no evidence that there is  "software
> engineering" any more than computer science is a science.

And yet the evidence has been placed before you repeatedly in this thread.

> I conclude that no software is engineered.  People may be following some

You conclude based on that it was your premise and that's the end of it.

> However, I've asked, and if someone can point out an application of
> scientific principle to software development, then I'll have to change
> my opinion.

Which they did, and yet somehow you haven't changed your opinion.

-- 
Lew
0
noone7 (4050)
11/27/2008 5:48:58 AM
>
> 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

I teach my students that software engineering is the study of tools and 
techniques (methods) that are used in the development of large software 
systems.    Anyone developer not familiar with software engineering 
principles should not be a leader (IMO).

Bill 


0
11/27/2008 6:45:58 AM
LR <lruss@superlink.net> kirjutas:

> Paavo Helde wrote:
>> LR <lruss@superlink.net> kirjutas:
>> 
>>> No, I disagree.  I don't say that engineering doesn't encompass
>>> those other things, I suggest that fundamentally engineering is the
>>> application of scientific principle and lacking that, it isn't
>>> engineering but something else.  Perhaps accounting. Or aesthetic
>>> design. Or management.  Not that engineers can't do these things
>>> too. 
>> 
>> Obviously you have not done MFC programming ;-) If you tried that, it
>> would become clear that programming (at least in this environment) is
>> an experimental discipline. You set up experiments to determine how
>> the library (MFC) behaves under some simulated conditions; you keep
>> the records and try to infer some general rules from that; then you
>> attempt to construct your own software according to the rules you
>> have found, in the hope that it will function to some extent also in
>> other space and time points. 
> 
> Lot's of programming is done this way.
> 
> 
>> 
>> Sounds like physics+engineering to me ;-)
> 
> What is the physics part?  If that were actually there, then this
> would be software engineering, because you'd be applying a scientific
> principle. 

One can apply sccientific principle regardless of the area of the study. 
And besides, I see no fundamental distinction of a process running on 1D 
arrays of bits in the computer memory, and a process running on 11D M-
branes.  

> 
> A cook might experiment with the mixture of spices in a dish.  Is that
> engineering?

If preparing a dinner would take man-years of team effort, then by all 
means, the cooks should use engineering principles to ensure that the 
result is edible. And yes, I call something engineering if it applies 
engineering principles.

If I want to cross a ditch and throw a log over it, then I'm not 
engineering. Maybe only a bit, the "scientific knowledge" learned from 
experience and experimentation consists of facts that larger logs bear 
more weight, however on the other hand they are heavier to lift. When 
choosing the suitable log I have to compromise, and this is what 
engineering is all about (IMO).

If I want to make a permanent bridge over the ditch, I have to apply more 
thought and effort. If I want to make a bridge a car or train can pass, I 
should already make some calculations. And so on, engineering is gradual.

>> If that was the case, programming would be 
>> indeed reduced to a branch of mathematics or logic. 
> 
> What part of it isn't?

If programming were mathematics, then it would be possible to derive new 
programs from existing ones. We would have no buggy software, because the 
smallest "axiom" programs would be correct, and everything else would be 
rigorously derived from them. The fact that the people are forced to use 
software with bugs inside shows that this is not mathematics, just like 
people are forced to use bridges which sometimes collapse.

> 
> I don't think that an engineering approach to something doesn't mean
> that it's engineering.  I've already said in this thread that
> programmers can learn quite a bit from engineers.  I don't think
> that's in dispute. What is in dispute is if this _can_ result in an
> engineering discipline.

It appears you have a definition of "engineering discipline" which 
excludes computer programming. In that case it make no sense to argue 
further. 

Paavo

0
paavo1 (190)
11/27/2008 8:27:20 AM
On Nov 26, 8:24 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Nov 26, 12:28 am, Paavo Helde <pa...@nospam.please.org> wrote:
> >> James Kanze <james.ka...@gmail.com> kirjutas:

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

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

> > Well, it affected almost all levels, and part of it was due
> > to differences in corporate culture.  One simple example:
> > the French use a lot more white space in their coding
> > guidelines.  More importantly, perhaps, were expectations
> > with regards to personal relationships.

> It can work well, I worked on a couple of projects within
> Alcatel, all of these were multi-national.  The company had a
> policy of multinational teams at that time (late 80s) with all
> written communication (including meeting minutes) in English.
> That caused a few grumbles when there were no native English
> speakers at meetings!  Female software was an interesting
> concept for the English members to grasp...

My experience was late '80s and Alcatel, too, but I don't think
I would have characterized it as "working well".  This was not
long after Alcatel had taken over ITT (SEL in Germany); in
addition to national cultural differences, the ex-Alcatel and
the ex-ITT units had a completely different corporate culture.
Not to mention the resentment on the part of many of the Germans
about their company having been "taken over".

Language was also a problem; this was the first time using
English for the French team, and although English was the
official language of ITT even before the merger, the Germans
didn't seem that used to it either.  I can remember more than
one meeting (supposedly in English) at the beginning where I
didn't understand a word.  The French and German collegues
claimed to have understood each others English, however, which
was the important part.  Except that when I discussed what had
been decided with them later (in their own language), they'd
understood something completely different.

(I might add that I've worked with Alcatel on international
projects later, and the situation was greatly improved.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 9:20:50 AM
On Nov 27, 4:09 am, LR <lr...@superlink.net> wrote:
> Ben Voigt [C++ MVP] wrote:

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

> I'm sorry, I'm not sure what you're saying in context.  Are
> you suggesting that there's some way to distinguish between
> programs that can be proven to halt and those that it can't be
> proven for?

He's saying that for a given set of requirements, you can write
a program which provably meets those requirements.  Whether
"halting" is part of those requirements or not---if halting is
part of the requirements, then you write the program in a way
that it can be proved to halt.

Of course, unless provable halting (or anything else) is part of
the unnegociable requirements, it might be poor engineering to
do so.  Engineering is a lot about finding cost-efficient
solutions (as opposed to pure science, where cost is not a
factor).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 9:37:39 AM
On Nov 26, 10:05 pm, LR <lr...@superlink.net> wrote:
> Lew wrote:
> > Gennaro Prota wrote:
> >>> Since you were after a quick answer, is quoting the IEEE
> >>> 610.12-1990 definition of "software engineering" enough?

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

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

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

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

> > That would not be fair.  He quoted a noted and authoritative source for
> > definitions of engineering disciplines that categorizes an endeavor as
> > "software engineering".  That is evidence.

> Argument by appeal to authority?

Not really.  He's arguing about the definition of a word.
Definitions are determined by use.  He's siting a use.  And all
uses aren't equal---the use he cited was by a professional group
of engineers, generally recognized as such.  Which has a bit
more weight that citing just one random individual.

    [...]
> So far it hasn't helped me except as more evidence that there
> isn't any scientific principle being applied in this so called
> engineering disciple.

As we say in French: "Il n'est pire sourd que celui qui ne veut
pas entendre."  (There's none so deaf as those who don't want to
hear?)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 9:45:14 AM
LR wrote:

> James Kanze wrote:
> 
> >  Software engineering 
> 
> I am still wondering what the definition of this is.
> 
This looks pretty good to me
<http://en.wikipedia.org/wiki/Software_engineering>
> 
> >> 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?
> 
Because it makes it a structured, systematic and quantifiable approach
(see link above). Instead of just guessing use cases, results and
timelines.
> 
> >  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?
> 
The criteria are different, so you can't apply physical strength to any
project. There is stress testing in software development. The
engineering part makes sure the software has been tested for all
possible (and impossible) events/usages.

And AFAIK civil engineers have formulas to calculate physical strengths
and such, that are based on observation and experimentation.

0
no.spam6050 (391)
11/27/2008 9:53:36 AM
On Nov 27, 3:58 am, LR <lr...@superlink.net> wrote:
> Gennaro Prota wrote:
> > LR wrote:
> > We might be having a problem around the term "principle". If you
> > refer to scientific principles (laws) such as Archimedes'
> > principle or the law of conservation of energy then, of course,
> > they aren't "applied to the development of software".
>
> > "Therefore it is not 'engineering'", you are saying? Fine, it's
> > a terminology problem: you might call it software-ology, for
> > instance. However "software engineering" is used by an engineer
> > association with an agreed upon meaning.

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

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

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

It's not changed.  The concept engineering includes many
aspects; he's just accenting a different one.

The _American Heritage Dictionary_ gives:

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
11/27/2008 9:58:20 AM
On Nov 27, 4:13 am, LR <lr...@superlink.net> wrote:
> Ben Voigt [C++ MVP] wrote:

   [...]
> I've given several examples of scientific principles in this thread.
>
> I'll repeat them here for your convenience.

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

Those are NOT scientific principles.  They're just formula.  How
and when you use them would be controled by various scientific
principles.  How you know that the formula applies would be
controled by scientific principles.  But the formula itself
isn't a principle.

And the principle which says that you use F=3Dma to determine the
force, given mass and acceleration, in a limited set of
circumstances (low speed, non-quantic mass, etc.), and which
causes you to understand that the results aren't exact, but are
probably close enough, is the same sort of principle as those
which govern software engineering.  (I.e. analysis of the
surrounding conditions, to determine whether the techniques I'm
using to determine quality are "close enough".)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 10:04:23 AM
LR wrote:

> 
> 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?
> 
Well, have you ewver considered that that wasn't a complete definition,
that it may have changed over the years?

Engineering makes use of scientific methods, yes. But that's not all. To
wit:
<http://en.wikipedia.org/wiki/Engineering>

0
no.spam6050 (391)
11/27/2008 10:06:32 AM
On Nov 26, 10:32 pm, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > On Nov 26, 2:28 am, LR <lr...@superlink.net> wrote:
    [...]
> >>>>> There is a certain personal satisfact to be had in
> >>>>> knowing that you've just delivered a program which
> >>>>> actually works.

> >>>> Do the programs provably work?

> >>> To some degree.

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

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

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

In a certain sense, by definition.  The boundary with the
physical world is the boundary of what is usually considered
software.  But of course, software isn't developed in a vacuum,
and someone will have to decide how to map the physical world to
the software's inputs and outputs.  (As a simple, very low level
example: on most systems I've worked on, the hardware debounces
key contacts---on one, the hardware engineers weren't aware that
keys bounce, so we debounced them in software.)

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

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

Well, you certainly hadn't made it plain, but that is, IMHO, a
critical element of engineering.  Parameters driven by a number
of pragmatic constraints.  In a similar way, well engineered
software will be in budget and on time.  That's how you measure
the quality of engineering (along with meeting requirements, of
course).  Good engineering delivers a product (in the largest
sense of the word) which meets the requirements, in budget and
on time, using rigorous (i.e. scientific) techniques which
ensure that this will be the case.

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

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

It depends on the software, but in general, yes.  Testing can
only show that the software doesn't work, never that it works.
(But that's really true of just about every complicated system.
How do you test a bridge?)

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

It's possible for a small subset of software.  An isupper
function for ASCII characters, for example.

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

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

No.  In the end, designing bridges is just like creating
software.  You can't test all possible cases.  In the case of
bridge design, you can't even analyse all possible cases; you
can generally get a lot closer to it with software, but there's
still a costs-benefits trade-off involved.  If the evaluation of
these trade-offs is done using a serious, scientific
methodology, we speak of good engineering.  If it is done by
guessing, or not done at all, we speak of bad engineering (or no
engineering).  Both for software or for bridges.

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

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

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

> > Mathematics.

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

Of course it is.  It's the queen of sciences.

And computer science is a science.  Or are you going to claim
that computer science doesn't exist, too.

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

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

My point is just that scientific principles are only a small
part of engineering.

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

That I don't know.  Given the coefficient of penetration of a
typical steam engine, it would seem that almost anything would
help.  But the real motivation was commercial, I think.

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

Personally, that DOESN'T sound like good engineering to me.  But
the reverse might be true: if it is well designed, it will look
good.

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

Which wasn't by Eiffel (although Eiffel's company did the
engineering for the internal structure to hold it up).

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

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

I'd prefer the expression "scientific method" to "scientific
principles".  The word "principles" can be understood at too
many different levels.

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

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

I find software development to be very, very much like
architecture or bridge engineering (and probably a lot less like
chemical engineering---or even electrical engineering).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 10:39:26 AM
On 27 nov, 04:05, LR <lr...@superlink.net> wrote:
> courp...@gmail.com wrote:
> [...]
> > If "halting of the program" was in the user requirement specifications
> > of the software, then yes. Since the software was developped using
> > design by contract, it can be proved to meet the specifications. If
> > the specifications was impossible to meet for one reason or another,
> > the software couldn't have been developped using formal methods.
>
> So then, not all software can be produced using formal methods?

It depends if you mean hypothetical softwares, or softwares that can
be practically produced to fulfill the specifications.
In the first case, obviously not all softwares (using formal methods
or not) can be made in practice, for the same reason that not all
problems are computable.
If, in practice, a software X can be produced to fulfill the
specifications, then another software Y using formal methods can be
produced according to the same specifications.

Alexandre Courpron.


0
courpron (89)
11/27/2008 10:45:19 AM
Bill wrote:
>> 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
> 
> I teach my students that software engineering is the study of tools and 
> techniques (methods) that are used in the development of large software 
> systems.    Anyone developer not familiar with software engineering 
> principles should not be a leader (IMO).


What do you mean by large?

LR
0
lruss (582)
11/27/2008 12:36:24 PM
Paavo Helde wrote:
> LR <lruss@superlink.net> kirjutas:
> 
>> Paavo Helde wrote:
>>> LR <lruss@superlink.net> kirjutas:
>>>
>>>> No, I disagree.  I don't say that engineering doesn't encompass
>>>> those other things, I suggest that fundamentally engineering is the
>>>> application of scientific principle and lacking that, it isn't
>>>> engineering but something else.  Perhaps accounting. Or aesthetic
>>>> design. Or management.  Not that engineers can't do these things
>>>> too. 
>>> Obviously you have not done MFC programming ;-) If you tried that, it
>>> would become clear that programming (at least in this environment) is
>>> an experimental discipline. You set up experiments to determine how
>>> the library (MFC) behaves under some simulated conditions; you keep
>>> the records and try to infer some general rules from that; then you
>>> attempt to construct your own software according to the rules you
>>> have found, in the hope that it will function to some extent also in
>>> other space and time points. 
>> Lot's of programming is done this way.
>>
>>
>>> Sounds like physics+engineering to me ;-)
>> What is the physics part?  If that were actually there, then this
>> would be software engineering, because you'd be applying a scientific
>> principle. 
> 
> One can apply sccientific principle regardless of the area of the study. 
> And besides, I see no fundamental distinction of a process running on 1D 
> arrays of bits in the computer memory, and a process running on 11D M-
> branes.  

Sounds like you might be discussing computer engineering?


> 
>> A cook might experiment with the mixture of spices in a dish.  Is that
>> engineering?
> 
> If preparing a dinner would take man-years of team effort, then by all 
> means, the cooks should use engineering principles to ensure that the 
> result is edible. And yes, I call something engineering if it applies 
> engineering principles.

Like say the application of materials science to extruded food?

> 
> If I want to cross a ditch and throw a log over it, then I'm not 
> engineering. Maybe only a bit, the "scientific knowledge" learned from 
> experience and experimentation consists of facts that larger logs bear 
> more weight, however on the other hand they are heavier to lift. 

That only a bit would imply that everything is engineering.  There'd be
some interesting consequences of that. So I suspect that no one really
wants to go there.

> When
> choosing the suitable log I have to compromise, and this is what 
> engineering is all about (IMO).
> 
> If I want to make a permanent bridge over the ditch, I have to apply more 
> thought and effort. If I want to make a bridge a car or train can pass, I 
> should already make some calculations. And so on, engineering is gradual.

But surely not every calculation involves engineering?  Suppose I want
to decide how much pepper to add to the pot and I have some formula
based on the volume of the pot, or rather the volume of the contents, is
that engineering?


> 
>>> If that was the case, programming would be 
>>> indeed reduced to a branch of mathematics or logic. 
>> What part of it isn't?
> 
> If programming were mathematics, then it would be possible to derive new 
> programs from existing ones. We would have no buggy software, because the 
> smallest "axiom" programs would be correct, and everything else would be 
> rigorously derived from them. The fact that the people are forced to use 
> software with bugs inside shows that this is not mathematics, just like 
> people are forced to use bridges which sometimes collapse.

I think that Alan Turing's mathematics was quite rigorously done and his
math suggests that what you've written here is wrong. Although I'm not a
mathematician either, so maybe someone here will correct me.  Not
everything can be proven using math.  I think this is sort of a meta issue.


> 
>> I don't think that an engineering approach to something doesn't mean
>> that it's engineering.  I've already said in this thread that
>> programmers can learn quite a bit from engineers.  I don't think
>> that's in dispute. What is in dispute is if this _can_ result in an
>> engineering discipline.
> 
> It appears you have a definition of "engineering discipline" which 
> excludes computer programming. In that case it make no sense to argue 
> further. 

I have a definition that I've taken from various engineers I know who
all told me that engineering is the application of scientific principle.
 Either the definition has changed, in which case I'd like to know why,
or I'd like to know what scientific principle is being applied in
"software engineering".

LR

0
lruss (582)
11/27/2008 12:44:12 PM
James Kanze wrote:

> Engineering is a lot about finding cost-efficient
> solutions (as opposed to pure science, where cost is not a
> factor).

Yes.  I'll agree with that.

Except for funding the research. ;)

LR
0
lruss (582)
11/27/2008 12:45:34 PM
James Kanze wrote:

> 
> Not really.  He's arguing about the definition of a word.
> Definitions are determined by use.  He's siting a use.  And all
> uses aren't equal---the use he cited was by a professional group
> of engineers, generally recognized as such.  Which has a bit
> more weight that citing just one random individual.

In which case AFAICT the definition would seem to have changed.  Why is
that, do you think?

> 
>     [...]
>> So far it hasn't helped me except as more evidence that there
>> isn't any scientific principle being applied in this so called
>> engineering disciple.
> 
> As we say in French: "Il n'est pire sourd que celui qui ne veut
> pas entendre."  (There's none so deaf as those who don't want to
> hear?)

I've already admitted that I may be slow.  I don't believe that I've
seen a single example of the application of scientific principle to
software development.  Please be explicit. Thanks.

LR
0
lruss (582)
11/27/2008 12:55:54 PM
Sabine Dinis Blochberger wrote:
> LR wrote:
> 
>> James Kanze wrote:
>>
>>>  Software engineering 
>> I am still wondering what the definition of this is.
>>
> This looks pretty good to me
> <http://en.wikipedia.org/wiki/Software_engineering>

Interesting stuff.  I've heard about that first usage in a NATO paper.
I read somewhere, sorry, no cite, that the intent of the usage was to shock.


>>>> 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?
>>
> Because it makes it a structured, systematic and quantifiable approach
> (see link above). Instead of just guessing use cases, results and
> timelines.

If I accept the definition given above.  But to my mind that would make
"software engineering" a unique thing.  Different from say chemical,
mechanical or civil. But perhaps there is another branch of engineering
that doesn't require the application of scientific principle?

>>>  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?
>>
> The criteria are different, so you can't apply physical strength to any
> project. There is stress testing in software development. 

There are viruses and bugs too. Is software development biology?  I
don't mean to be flippant, but the mere use of a word doesn't confer
meaning on the object it refers to, does it?

> The
> engineering part makes sure the software has been tested for all
> possible (and impossible) events/usages.

I suspect that this is not even likely.  I gave a counter example else
thread involving input for a number of boolean variables, let's say 64.
 Tough to test all of those.

And to repeat, I once spoke to a EE who told me his company was going to
test software for all possible inputs. Once I did the arithmetic for him
he withdrew his statement.


> And AFAIK civil engineers have formulas to calculate physical strengths
> and such, that are based on observation and experimentation.


They do.  I'm sorry, did I say anything to indicate otherwise? If so,
please allow me to withdraw that. Although, I suspect they may not know
all there is to know about this yet.  I also note that,  AFAIK, at least
some of these are of comparatively recent origin. For example, I think
the use of timber in bridges wasn't even reasonably understood until
Herman Haupt did the experiments to figure out what the strength of the
beams were.

LR

LR

0
lruss (582)
11/27/2008 1:05:48 PM
James Kanze wrote:
> On Nov 27, 3:58 am, LR <lr...@superlink.net> wrote:
>> Gennaro Prota wrote:
>>> LR wrote:
>>> We might be having a problem around the term "principle". If you
>>> refer to scientific principles (laws) such as Archimedes'
>>> principle or the law of conservation of energy then, of course,
>>> they aren't "applied to the development of software".
>>> "Therefore it is not 'engineering'", you are saying? Fine, it's
>>> a terminology problem: you might call it software-ology, for
>>> instance. However "software engineering" is used by an engineer
>>> association with an agreed upon meaning.
> 
>> So if it's defined that way, then that's what it is?
> 
>>> It's of course more about methodology ("systematic,
>>> disciplined, quantifiable") than scientific principles.
> 
>> I wonder why the definition of what engineering is seems to
>> have changed.
> 
> It's not changed.  The concept engineering includes many
> aspects; he's just accenting a different one.
> 
> The _American Heritage Dictionary_ gives:
> 
>     The application of scientific and mathematical principles to
>     practical ends such as the design, manufacture, and
>     operation of efficient and economical structures, machines,
>     processes, and systems.
> 
> That certainly covers software engineering.  The term
> "scientific and mathematical principles" is broad, and covers a
> lot more than just physical laws like Archimedes' principle.  Or
> even mathematical proofs of programs.  The entire sentence above
> makes it clear that it also applies to the process, for example.
> Every good shop I've seen makes extensive use of statistics, for
> example, in evaluating their process.  And controlled testing,
> which is the basis of all scientific methodology.  And code
> review, which is a form of peer-review such as is used in all
> scientific journals.  Software engineering is all about the
> "design [...] of efficient and economical [...] systems", using
> "scientific and mathematical principles" in a practical way.
> You can't get more "engineering" than that.

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

Thanks,

LR


0
lruss (582)
11/27/2008 1:07:14 PM
Sabine Dinis Blochberger wrote:
> LR wrote:
> 
>> 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?
>>
> Well, have you ewver considered that that wasn't a complete definition,
> that it may have changed over the years?
> 
> Engineering makes use of scientific methods, yes. But that's not all. To
> wit:
> <http://en.wikipedia.org/wiki/Engineering>

Of course that's not all.  I've already said so.  What I've said is that
without this, it's not engineering but something else.

I'll try to make this clearer.  Application of scientific principle is
necessary but not sufficient to make something engineering.

Please tell me if that isn't clear and I'll try to do better.

Sorry if I wasn't clear before.

LR


> 
0
lruss (582)
11/27/2008 1:09:28 PM
On Nov 27, 2:07 pm, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > On Nov 27, 3:58 am, LR <lr...@superlink.net> wrote:

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

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

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 1:26:03 PM
On Nov 27, 1:55 pm, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
>
> > Not really.  He's arguing about the definition of a word.
> > Definitions are determined by use.  He's siting a use.  And
> > all uses aren't equal---the use he cited was by a
> > professional group of engineers, generally recognized as
> > such.  Which has a bit more weight that citing just one
> > random individual.

> In which case AFAICT the definition would seem to have
> changed.  Why is that, do you think?

I don't see where it has changed.  Engineering is a complex
endevour, and its definition includes many aspects.  His
definition accents one particular aspect, perhaps, but no more.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
11/27/2008 1:27:41 PM
On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
> Sabine Dinis Blochberger wrote:
> > LR wrote:

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

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

> But perhaps there is another branch of engineering that
> doesn't require the application of scientific principle?

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

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

> > The criteria are different, so you can't apply physical
> > strength to any project. There is stress testing in software
> > development.

> There are viruses and bugs too. Is software development
> biology?  I don't mean to be flippant, but the mere use of a
> word doesn't confer meaning on the object it refers to, does
> it?

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

> > The engineering part makes sure the software has been tested
> > for all possible (and impossible) events/usages.

> I suspect that this is not even likely.  I gave a counter
> example else thread involving input for a number of boolean
> variables, let's say 64.  Tough to test all of those.

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

> And to repeat, I once spoke to a EE who told me his company
> was going to test software for all possible inputs. Once I did
> the arithmetic for him he withdrew his statement.

Just because there are incompetents making unreasonable claims
doesn't mean that the field doesn't exist.

> > And AFAIK civil engineers have formulas to calculate
> > physical strengths and such, that are based on observation
> > and experimentation.

> They do.  I'm sorry, did I say anything to indicate otherwise?

My understanding was that you were forwarding the opposite
argument; that you'd only accept software engineering as an
engineering discipline if it had such formulas.  And of course,
we don't have formulas based on physical strengths (although
things like the big-O notation are related in some ways).  On
the other hand, the formulas aren't the scientific principle;
the reason which causes the civil engineer to accept them and to
use them is.  And there are other "formulas" in software
engineering, to which the same principles can be applied.

> If so, please allow me to withdraw that. Although, I suspect
> they may not know all there is to know about this yet.  I also
> note that,  AFAIK, at least some of these are of comparatively
> recent origin. For example, I think the use of timber in
> bridges wasn't even reasonably understood until Herman Haupt
> did the experiments to figure out what the strength of the
> beams were.

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 1:41:18 PM
On Nov 27, 3:54 am, LR <lr...@superlink.net> wrote:
> Lew wrote:
> >> Sorry, I think that qualifies as mathematics.
> > What a specious argument.
> I conclude that you don't have an argument.

I conclude that you are using a rhetoric technic that isn't
being recognized or understood here.  (Happens to me all the
time:-).)

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

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

In the same way quantum physics is a science.  Mathematics is
also a science.  It differs from other sciences in that it has a
somewhat particular relationship with reality, but if you've
read any Feynman, you'll realize that quantum physics is pretty
much in the same situation.  (And if you understand quantum
physics---supposing that understanding quantum physics is
possible, or that the word "understanding" is even applicable to
quantum physics---you'll realize that it implies that all other
sciences have the same somewhat tenuous relationship to
reality.)

In a very real sense, one might say that science is
understanding, and engineering using that understanding.
Mathematics leads to real understanding, so it is a science.
Applied mathematics uses that understanding, so it is
engineering.  In a similar way, computer science determines the
big-O for some algorithm (understanding), so it is science;
software engineering chooses between algorithms on the basis of
that understanding, weighing big-O, cost, etc., so it is
engineering.  Of course, there's a lot more to software
engineering than just choosing the right algorithm.  Much of it
is involved in choosing the right "technique"---sort of like
deciding whether a bridge should be welded or use rivets.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 1:53:45 PM
On Nov 27, 4:04 am, LR <lr...@superlink.net> wrote:
> Tamas Demjen wrote:
> > LR wrote:
> >> Sorry, I think that qualifies as mathematics.
> > It's applied mathematics,

> Is applied mathematics science?

> > like with other fields of engineering.

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

That's because you've left us guessing what you mean by
"scientific principle".  The examples you've given have been
more akin to formula than to principles.  Software has such
(e.g. big-O forula), and they do play a role in software
engineering, but a moderate role.  What makes something science,
however, isn't the formula (chemistry uses a completely
different sort of formula), but rather, the principles which are
used to determine which formula are valid.  Why do you accept
F=3Dma (which actually isn't valid according to modern science),
rather than, say F=3D2ma, or F=3Dmv?  (This isn't trivial.  For the
longest time, scientists believed that it was acceleration which
was dependent on the gravitational masses, rather than force.
And today relativistic and quantum physics teach us something
different as well.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 2:01:08 PM
On Nov 27, 4:32 am, LR <lr...@superlink.net> wrote:
> Paavo Helde wrote:
> > LR <lr...@superlink.net> kirjutas:

> A cook might experiment with the mixture of spices in a dish.
> Is that engineering?

If he does so in a scientific way.  If he's just guessing, no,
but if he's basing his choice of which spice to try on the known
characteristics of the spice, and if he meets the other
qualifications (considers price, etc.), then it is engineering.

    [...]
> > Any mathematically correct algorithm, however slow or
> > memory-consuming, would qualify as a valid and usable
> > program. As we are not there yet, programming needs
> > engineering approach.

> I don't think that an engineering approach to something
> doesn't mean that it's engineering.

So what is engineering.  It sounds to me like using a
engineering approach would be a definition.  (Not a good one,
since it is circular.)

Science tells us whether the algorithm is correct or not, and
evaluates its speed (in big-O).  Engineering tells us whether it
is appropriate in the context of the given requirements, taking
into account what science tells us about it (e.g. big-O), but
also other pragmatic issues (like development time).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 2:10:50 PM
On Nov 27, 1:44 pm, LR <lr...@superlink.net> wrote:
> Paavo Helde wrote:
> > If I want to cross a ditch and throw a log over it, then I'm
> > not engineering. Maybe only a bit, the "scientific
> > knowledge" learned from experience and experimentation
> > consists of facts that larger logs bear more weight, however
> > on the other hand they are heavier to lift.

> That only a bit would imply that everything is engineering.

Not really.  If there are three logs, of different sizes, and I
choose the smallest, because it is easiest to lift, even though
I hae no reason to believe that it will support my weight, it's
not engineering.  If I choose one of the logs because of some
religious reasons (always choose the one on the right, because
things on the right are holy), it's not engineering.  It's only
engineering if I choose based on scientific fact (or what is
believed to be so by me)---log A won't support me, but log C
will require a lot more effort to put into place than log B,
etc.

> > If I want to make a permanent bridge over the ditch, I have
> > to apply more thought and effort. If I want to make a bridge
> > a car or train can pass, I should already make some
> > calculations. And so on, engineering is gradual.

> But surely not every calculation involves engineering?
> Suppose I want to decide how much pepper to add to the pot and
> I have some formula based on the volume of the pot, or rather
> the volume of the contents, is that engineering?

Maybe.  If the formula was given to me by a priest, because the
gods said to do it like that, no.  If the formula is based on
how much pepper it takes to achieve a certain degree of
spiciness (determined by scientific research), yes.

> >>> If that was the case, programming would be indeed reduced
> >>> to a branch of mathematics or logic.
> >> What part of it isn't?

The fact that it costs money:-).  Seriously: mathematics or
logic, in the classical sense, are sciences.  They're concerned
with some sort of abstract truth, determined according to
certain criteria.  Programming is concerned with solutions, not
the abstract truth.  Which makes it engineering, instead of
science.  (If you accept that programming is a branch of applied
mathematics, then you've accepted the "scientific principles"
aspect; the only question remains is whether it is engineering
or pure science.  And I don't think that there's much doubt
about that one.)

> > It appears you have a definition of "engineering discipline"
> > which excludes computer programming. In that case it make no
> > sense to argue further.

> I have a definition that I've taken from various engineers I
> know who all told me that engineering is the application of
> scientific principle.

Which is only part of it.  Quantum physics applies scientific
principles, but I wouldn't consider it engineering.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 2:20:14 PM
On Thu, 27 Nov 2008, Paavo Helde wrote:

> LR <lruss@superlink.net> kirjutas:
>
>> Paavo Helde wrote:
>>> LR <lruss@superlink.net> kirjutas:
>>>
>>>> No, I disagree.  I don't say that engineering doesn't encompass those 
>>>> other things, I suggest that fundamentally engineering is the 
>>>> application of scientific principle and lacking that, it isn't 
>>>> engineering but something else.
>>>
>>> Obviously you have not done MFC programming ;-) If you tried that, it 
>>> would become clear that programming (at least in this environment) is 
>>> an experimental discipline. You set up experiments to determine how 
>>> the library (MFC) behaves under some simulated conditions; you keep 
>>> the records and try to infer some general rules from that; then you 
>>> attempt to construct your own software according to the rules you have 
>>> found, in the hope that it will function to some extent also in other 
>>> space and time points.
>>
>> What is the physics part?  If that were actually there, then this
>> would be software engineering, because you'd be applying a scientific
>> principle.
>
> One can apply sccientific principle regardless of the area of the study.
> And besides, I see no fundamental distinction of a process running on 1D
> arrays of bits in the computer memory, and a process running on 11D M-
> branes.

Fundamentally, no. But in practice, there's a huge difference, because 
there are simplifying approximations that describe the M-branes (or 
whatever it really is) very accurately, which we can use to analyse 
problems and designs to predict with corresponding accuracy whether 
they'll work. There are no such approximations with the bits.

Or rather, there are such approximations for *some* things the M-branes 
do. I note that there are no fields of engineering which are based around 
detailed sculpting of the patterns in turbulent flow. I also note that 
fast-moving compound pendulums are rarely used in mechanical engineering. 
Both of these are systems which are chaotic, and thus for which there are 
no simplifying approximations. Hence, they aren't tractable for 
engineering.

My position is that software is like the latter - sufficiently nonlinear 
that you can't engineer it in the way that you can machines, structures, 
or chemical reactions.

tom

-- 
I now have a problem with tomorrow. -- Graham
0
twic (2088)
11/27/2008 2:42:19 PM
On Thu, 27 Nov 2008, James Kanze wrote:

> On Nov 27, 2:07 pm, LR <lr...@superlink.net> wrote:
>> James Kanze wrote:
>>> On Nov 27, 3:58 am, LR <lr...@superlink.net> wrote:
>
>> I'm sorry, but could you please be explicit about which scientific 
>> principle is being applied?
>
> All of them.  The results must be reproduceable.  The results must be 
> validated by peer-review.
>
> You seem to be confusing scientific principles with scientific laws. 
> Scientific principles are what we use to determine whether something is 
> a scientific law or not.

This is not a definition of 'scientific principle' which i have heard 
before. In normal (and British) English, 'principle' is interchangeable 
with 'law'. Mach's principle, Le Chatelier's principle, Archimedes' 
principle, etc. Perhaps this is different in French.

tom

-- 
I now have a problem with tomorrow. -- Graham
0
twic (2088)
11/27/2008 2:47:27 PM
On Wed, 26 Nov 2008, Martin Gregorie wrote:

> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>
>> On Tue, 25 Nov 2008, LR wrote:
>>
>>> Tom Anderson wrote:
>>>
>>>> Still, i call myself a 'software engineer' because it sounds more
>>>> high-status than 'programmer', and i go to a lot of parties with
>>>> lawyers and academics and the like.
>>>
>>> IANAL, but since you're calling yourself a "software engineer" might I
>>> ask what jurisdiction you do that in?
>>
>> In the UK.
>
> Same here: its well recognised in the UK. I hold a CE in software 
> engineering as well as an MSc (Chemistry).

But i'm right in thinking that one doesn't need either of those to call 
oneself a software engineer, i hope?

tom

-- 
I now have a problem with tomorrow. -- Graham
0
twic (2088)
11/27/2008 3:01:34 PM
James Kanze wrote:
> On Nov 27, 4:13 am, LR <lr...@superlink.net> wrote:
>> Ben Voigt [C++ MVP] wrote:
> 
>    [...]
>> I've given several examples of scientific principles in this thread.
>>
>> I'll repeat them here for your convenience.
> 
>> F = ma is a scientific principle.  I^2*R=W is a scientific
>> principle. Hz = 1/(2*PI*sqrt(L*C)) is a scientific principle.
>> And I repeat, I admit I had to pull out my copy of Marks for
>> that last one. It's a been a long time since I needed it.
> 
> Those are NOT scientific principles.  They're just formula.  How
> and when you use them would be controled by various scientific
> principles.  How you know that the formula applies would be
> controled by scientific principles.  But the formula itself
> isn't a principle.
> 
> And the principle which says that you use F=ma to determine the
> force, given mass and acceleration, in a limited set of
> circumstances (low speed, non-quantic mass, etc.), and which
> causes you to understand that the results aren't exact, but are
> probably close enough, is the same sort of principle as those
> which govern software engineering.  (I.e. analysis of the
> surrounding conditions, to determine whether the techniques I'm
> using to determine quality are "close enough".)

Don't feed the troll.

-- 
Lew
0
noone7 (4050)
11/27/2008 3:29:45 PM
LR wrote:
> I've already admitted that I may be slow.  I don't believe that I've
> seen a single example of the application of scientific principle to
> software development.  Please be explicit. Thanks.

You may not believe you've seen a single example of such, but in this thread 
you've actually seen several examples.

-- 
Lew
0
noone7 (4050)
11/27/2008 3:31:08 PM
LR wrote:
>> Yeah, that's it then.  Except math is not a science.

James Kanze wrote:
> Of course it is.  It's the queen of sciences.
> 
> And computer science is a science.  Or are you going to claim
> that computer science doesn't exist, too.

He is going to, and has already done so.  He's a troll.

> I'd prefer the expression "scientific method" to "scientific
> principles".  The word "principles" can be understood at too
> many different levels.

Well, LR will just reject any definitions, evidence, authority or experience 
that violates his "reasoning".

-- 
Lew
0
noone7 (4050)
11/27/2008 3:34:26 PM
Sabine Dinis Blochberger wrote:

> Because it makes it a structured, systematic and quantifiable approach
> (see link above). Instead of just guessing use cases, results and
> timelines.

You can only do this if you are writing software that basically is made
up of subparts that have been done before. This doesn't work for all
software. If you've never built something like a bridge before, you
can't apply proven patterns and procedures.
0
mkb (1001)
11/27/2008 3:35:48 PM
Sabine Dinis Blochberger wrote:
>> This looks pretty good to me
>> <http://en.wikipedia.org/wiki/Software_engineering>

LR wrote:
> Interesting stuff.  I've heard about that first usage in a NATO paper.
> I read somewhere, sorry, no cite [sic], that the intent of the usage was to shock.

More unsubstantiable hearsay from someone who rejects all actual evidence on 
the basis of anecdotal, non-verifiable junk like this.

> For example, I think
> the use of timber in bridges wasn't even reasonably understood until
> Herman Haupt did the experiments to figure out what the strength of the
> beams were.

The ancient Romans had a very reasonable understanding of the structural 
strength of timber and other materials that they used in bridges.

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

"James Kanze" <james.kanze@gmail.com> wrote in message 
news:440188fd-b351-45f4-ba1f-7e5a8b23848d@j38g2000yqa.googlegroups.com...

> I'm sorry, I'm not sure what you're saying in context.  Are
> you suggesting that there's some way to distinguish between
> programs that can be proven to halt and those that it can't be
> proven for?

He's saying that for a given set of requirements, you can write
a program which provably meets those requirements.  Whether
"halting" is part of those requirements or not---if halting is
part of the requirements, then you write the program in a way
that it can be proved to halt.

Of course, unless provable halting (or anything else) is part of
the unnegociable requirements, it might be poor engineering to
do so.  Engineering is a lot about finding cost-efficient
solutions (as opposed to pure science, where cost is not a
factor).



0
alegr (49)
11/27/2008 3:44:29 PM
"Paavo Helde" <paavo@nospam.please.ee> wrote in message 
news:Xns9B636A5CC3B3Bnobodyebiee@216.196.97.131...
>
>>> If that was the case, programming would be
>>> indeed reduced to a branch of mathematics or logic.
>>
>> What part of it isn't?
>
> If programming were mathematics, then it would be possible to derive new
> programs from existing ones. We would have no buggy software, because the
> smallest "axiom" programs would be correct, and everything else would be
> rigorously derived from them.

That's caled code reuse. It helps to reduce bugs, too.


0
alegr (49)
11/27/2008 3:45:38 PM
LR wrote:
>> I have a definition that I've taken from various engineers I
>> know who all told me that engineering is the application of
>> scientific principle.

You have a definition that you invented, claim by hearsay only that you have 
"taken [it] from various engineers [you] know", none named and whose expertise 
cannot be verified, and who may, for all you tell us, have told you additional 
aspects that you choose to omit from this discussion, and which you refuse to 
modify in the face of widely-accepted definitions proffered by official bodies 
of certified, professional engineers who are cited by verifiable reference.

You are intellectually dishonest.

James Kanze wrote:
> Which is only part of it.  Quantum physics applies scientific
> principles, but I wouldn't consider it engineering.

This discussion has given overwhelming evidence that software engineering as a 
discipline does exist, that it has a definition or set of definitions that is 
widely accepted by engineers and high-end academic institutions, that it has a 
different definition than that proffered by the troll, and that it is widely 
practiced.  The troll will never accept this evidence, choosing instead to 
circularly define "software engineering" in an idiolectic, self-serving and 
circular fashion, retreating to mere repetition of his discredited arguments 
whenever confronted with the facts.

-- 
Lew
0
noone7 (4050)
11/27/2008 3:47:16 PM
Martin Gregorie wrote:
>> Same here: its well recognised in the UK. I hold a CE in software 
>> engineering as well as an MSc (Chemistry).

Tom Anderson wrote:
> But i'm right in thinking that one doesn't need either of those to call 
> oneself a software engineer, i hope?

Absolutely.

-- 
Lew
0
noone7 (4050)
11/27/2008 3:49:32 PM
On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:

> Martin Gregorie wrote:
>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>> 
>>> But I think I made it plain that engineers don't consider the entire
>>> physics of the bridge. They might not consider fluid interactions or
>>> wind loading or some such.  The parameters are likely to be driven by
>>> budget, customer requirements or perhaps good practice.
>>>
>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>> Narrows bridges ignored wind and look where that got them.
> 
> 
> I'm sorry, but what is quite wrong?  I completely fail to understand how
> your response contradicts anything I wrote above.  Please explain,
> because I utterly bewildered by your response.
>
This: 
  "But I think I made it plain that engineers don't consider the entire
   physics of the bridge. They might not consider fluid interactions or
   wind loading or some such."

I suggest you do some reading about those bridges.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/27/2008 3:57:53 PM
Lew wrote:

> And wrong.  Software development can be, and is, an engineering discipline.

You can reduce it to that, however, you'll lose out in the long run.

Writing software isn't like building a bridge. Once a bridge is in
place, it will stay that way for a long time. Apart from maintenance, it
most likely won't be touched. It certainly won't be turned into an
apartment block.
However, this is what happens to software. A large program is a moving
target. It needs to be able to grow, expand and mutate far beyond what
has been imagined by its original designers. Also, it is impossible to
make perfect and totally reliable software. You can make a bridge that
won't fall down if you correctly calculate all the statics, make sure
the building work isn't executed sloppily with subgrade materials and
include a generous safety margin in all areas. Software is far too
complex for that. Software must be able to fail gracefully, and recover
from that. It must be possible to, if needed, debug and modify (running)
software, and large software systems also have to include heuristical
and autonomous mechanisms for self-repair. The notion that software
reliability comes from meticulous up-front "engineering" is naive thinking.
0
mkb (1001)
11/27/2008 5:36:50 PM
Lew wrote:
>> And wrong.  Software development can be, and is, an engineering discipline.


Matthias Buelow wrote:

> You can reduce it to that, however, you'll lose out in the long run.

How is that in any way a reduction?

> Writing software isn't like building a bridge. Once a bridge is in
> place, it will stay that way for a long time. Apart from maintenance, it
> most likely won't be touched. It certainly won't be turned into an
> apartment block.

What does that have to do with software being an engineering discipline?

> However, this is what happens to software. A large program is a moving
> target. It needs to be able to grow, expand and mutate far beyond what
> has been imagined by its original designers. Also, it is impossible to
> make perfect and totally reliable software. You can make a bridge that
> won't fall down if you correctly calculate all the statics, make sure
> the building work isn't executed sloppily with subgrade materials and
> include a generous safety margin in all areas. Software is far too
> complex for that. Software must be able to fail gracefully, and recover
> from that. It must be possible to, if needed, debug and modify (running)
> software, and large software systems also have to include heuristical
> and autonomous mechanisms for self-repair. The notion that software
> reliability comes from meticulous up-front "engineering" is naive thinking.

Nothing you said contradicts the notion that software can or should be 
engineered.  /Au contraire/ you have presented compelling arguments for why 
software must be engineered.  Given the dynamic nature of software, solid and 
competent engineering must be employed to make it viable and robust.

In this, software engineering is more similar to civil engineering than bridge 
building.  Cities also must live, grow, change, evolve and repair themselves 
in the face of chaotically induced change.  No one can plan a city "up front" 
either.

Is it possible to make a "perfect and totally reliable" city plan?  No?  Does 
that invalidate civil engineering as a discipline?  Certainly not.

Also, introducing the thought that engineering must be done "up front" is a 
straw man argument.  Nothing about engineering says it must be done strictly 
/a priori/ in any engineering discipline.  Even bridges need maintenance and 
repair over their lifetimes, and good bridge engineering accounts for that. 
Thinking that engineering is strictly up front is the naive thinking.

The distinction is that engineering is appropriate to the domain of activity. 
  Bridges are not just like software, so the respective engineering 
disciplines will differ as well.  This does not invalidate either profession 
as an engineering one.

-- 
Lew
0
noone7 (4050)
11/27/2008 6:22:44 PM
On 2008-11-27, Lew <noone@lewscanon.com> wrote:
>
> Also, introducing the thought that engineering must be done "up front" is a 
> straw man argument.

Anyone who thinks that the engineering of buildings is a strictly
up-front process should try to track down an iron worker (the sort of
people that end up /actually/ putting these things together) and ask
him how well he thinks that would work out in practice :-)

For any non-trivial engineering project, much of the engineering takes
place throughout the construction phase as real-world limitations make
their presence known. Only recently have solutions become available
that would give the up-front planners any reasonable idea about how
pipes and ducts can actually be laid out in a building, for instance.

See any of the "Construction" type docutainment series on Discovery et
al to get an idea of the prevalence of this and keep in mind that what
the docutainment dramatizes as the end of the world and probable death
knell of the project (that is, some unplanned-for change during
construction) is actually pretty common and undramatic and usually
gets promptly handled by the engineers.

Cheers,
	Bent "oh, and I changed the subject" D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
11/27/2008 6:46:30 PM
Tom Anderson <twic@urchin.earth.li> kirjutas:

> On Thu, 27 Nov 2008, Paavo Helde wrote:
>> One can apply sccientific principle regardless of the area of the
>> study. And besides, I see no fundamental distinction of a process
>> running on 1D arrays of bits in the computer memory, and a process
>> running on 11D M- branes.
> 
> Fundamentally, no. But in practice, there's a huge difference, because
> there are simplifying approximations that describe the M-branes (or 
> whatever it really is) very accurately, which we can use to analyse 
> problems and designs to predict with corresponding accuracy whether 
> they'll work. There are no such approximations with the bits.

I think there are, otherwise we would still program in machine code. I 
think for example functions, computer languages, libraries, processes, 
operating systems are all some kind of generalisations aka approximations 
which allow us to reason about this bit-twiddling machine in more 
convenient terms.

If the approximations are working very well, then all the better. I don't 
really care into what machine code my for loop is translated, as far as 
it works and is not too slow. However, it is only an approximation and I 
don't usualy know which exact assembler instructions are generated, and 
more often I don't know the exact timing of their execution, as they are 
interspersed with other instructions from other programs and threads 
running on the machine at the same time. Whenever I move my mouse, a 
hardware interrupt routine kicks in and services that event. However, in 
my database application I don't have to care about this. So it appears 
that my source code file represents an enormous simplification and 
approximation of the actual computing process taking place on the machine 
at the time my program is run. In other words, I can predict with some 
certainty that my program will work correctly, regardless of how many 
mouse move events the computer happens to process at the same time.

Paavo

0
paavo1 (190)
11/27/2008 6:55:40 PM
James Kanze wrote:
> On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
>> Sabine Dinis Blochberger wrote:
> 
>>> The engineering part makes sure the software has been tested
>>> for all possible (and impossible) events/usages.
> 
>> I suspect that this is not even likely.  I gave a counter
>> example else thread involving input for a number of boolean
>> variables, let's say 64.  Tough to test all of those.
> 
> It's sufficient that it takes a double as input, and it is, for
> all intents and purposes, impossible to test exhaustively.
> People who claim the software is correct because it passes some
> test suite aren't engineers.  (Nor are people who forego testing
> entirely, on the grounds that it can't catch everything.)
> 
Testing is one area where the analogies between software and other
engineering disciplines do stand up well.  The software developer who
develops in the debugger poking in numbers and checking the code "works"
is little different form the electronics engineer who tinkers on his
bench with a signal generator and an oscilloscope until his circuit
"works".  Both are ill-disciplined, both are producing something fragile.

The equipment and time costs make it much more difficult for the
hardware engineer to build an test harness for his circuit than for the
software developer to write unit tests for his code.  The cost/time of
testing problem increases exponentially for larger physical systems
which is why most engineering disciplines now rely on simulation models.

Maybe software development is closer to what engineering once was: the
basic application of scientific principals.  We start with an hypothesis
(a requirement), we design and experiment (writ a test), conduct the
experiment (run the test) and observe the result.

I expect over time we will come to rely on more abstract tools for
software development (the simulation model approach used by physical
engineering disciplines), but that time is still a way off.

>> And to repeat, I once spoke to a EE who told me his company
>> was going to test software for all possible inputs. Once I did
>> the arithmetic for him he withdrew his statement.

Just like they test their circuits with all possible inputs!

-- 
Ian Collins
0
ian-news (10155)
11/27/2008 7:19:59 PM
On Thu, 27 Nov 2008 15:01:34 +0000, Tom Anderson wrote:

> On Wed, 26 Nov 2008, Martin Gregorie wrote:
> 
>> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>>
>>> On Tue, 25 Nov 2008, LR wrote:
>>>
>>>> Tom Anderson wrote:
>>>>
>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>> high-status than 'programmer', and i go to a lot of parties with
>>>>> lawyers and academics and the like.
>>>>
>>>> IANAL, but since you're calling yourself a "software engineer" might
>>>> I ask what jurisdiction you do that in?
>>>
>>> In the UK.
>>
>> Same here: its well recognised in the UK. I hold a CE in software
>> engineering as well as an MSc (Chemistry).
> 
> But i'm right in thinking that one doesn't need either of those to call
> oneself a software engineer, i hope?
>
In theory, no. However, in practise it can be helpful when you consider 
some of the cowboys I've met on big contracts and the dodgy agencies they 
worked through. 

A long time ago in Bath I was amongst 80 contractors fixing a wee problem 
the MoD had found themselves saddled with. There was one guy there who 
other contractors had seen on and around various projects for 6 or 7 
years and had never been known to successfully finish a program. He 
always managed to leave in time and his programs were generally scrapped 
and rewritten. Example: he didn't know that by default a COBOL program 
drops through to the next paragraph, so his source looked like this:

	 .....
       PARA-1.
         DO THIS.
         DO THAT
         PERFORM SOMETHING-OR-OTHER.
         GO TO PARA-2.
      PARA-2.
         .....

The agency he worked through was as bent as he was incompetent, once 
supplying another coder as having 3.5 years of ICL 1900 COBOL when in 
fact he had been a 1900 operator for 3 years followed by a 6 month COBOL 
course.

Checking on recognised qualifications could certainly have saved a lot of 
programming shops a lot of grief and expense over the years with people 
like this around.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/27/2008 8:59:58 PM
On Thu, 27 Nov 2008, Martin Gregorie wrote:

> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>
>> Martin Gregorie wrote:
>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>
>>>> But I think I made it plain that engineers don't consider the entire
>>>> physics of the bridge. They might not consider fluid interactions or
>>>> wind loading or some such.  The parameters are likely to be driven by
>>>> budget, customer requirements or perhaps good practice.
>>>>
>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>> Narrows bridges ignored wind and look where that got them.
>>
>> I'm sorry, but what is quite wrong?  I completely fail to understand how
>> your response contradicts anything I wrote above.  Please explain,
>> because I utterly bewildered by your response.
>>
> This:
>  "But I think I made it plain that engineers don't consider the entire
>   physics of the bridge. They might not consider fluid interactions or
>   wind loading or some such."
>
> I suggest you do some reading about those bridges.

Hold up - those examples show that, in the cases of those bridges (or 
Tacoma Narrows, at least), the engineers indeed did not consider wind 
loading!

tom

-- 
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler
0
twic (2088)
11/27/2008 9:13:44 PM
On Thu, 27 Nov 2008, Martin Gregorie wrote:

> On Thu, 27 Nov 2008 15:01:34 +0000, Tom Anderson wrote:
>
>> On Wed, 26 Nov 2008, Martin Gregorie wrote:
>>
>>> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>>>
>>>> On Tue, 25 Nov 2008, LR wrote:
>>>>
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>>> high-status than 'programmer', and i go to a lot of parties with
>>>>>> lawyers and academics and the like.
>>>>>
>>>>> IANAL, but since you're calling yourself a "software engineer" might
>>>>> I ask what jurisdiction you do that in?
>>>>
>>>> In the UK.
>>>
>>> Same here: its well recognised in the UK. I hold a CE in software
>>> engineering as well as an MSc (Chemistry).
>>
>> But i'm right in thinking that one doesn't need either of those to call
>> oneself a software engineer, i hope?
>>
> In theory, no. However, in practise it can be helpful when you consider
> some of the cowboys I've met on big contracts and the dodgy agencies they
> worked through.
>
> A long time ago in Bath I was amongst 80 contractors fixing a wee problem
> the MoD had found themselves saddled with. There was one guy there who
> other contractors had seen on and around various projects for 6 or 7
> years and had never been known to successfully finish a program. He
> always managed to leave in time and his programs were generally scrapped
> and rewritten. Example: he didn't know that by default a COBOL program
> drops through to the next paragraph, so his source looked like this:
>
> 	 .....
>       PARA-1.
>         DO THIS.
>         DO THAT
>         PERFORM SOMETHING-OR-OTHER.
>         GO TO PARA-2.
>      PARA-2.
>         .....
>
> The agency he worked through was as bent as he was incompetent, once
> supplying another coder as having 3.5 years of ICL 1900 COBOL when in
> fact he had been a 1900 operator for 3 years followed by a 6 month COBOL
> course.
>
> Checking on recognised qualifications could certainly have saved a lot 
> of programming shops a lot of grief and expense over the years with 
> people like this around.

Oh, absolutely. I'm not knocking the value of qualifications! At least, 
not all of them. I was just wondering if my lack of them made me a 
criminal.

tom

-- 
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler
0
twic (2088)
11/27/2008 9:21:01 PM
On Nov 27, 8:19=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
> >> Sabine Dinis Blochberger wrote:

> >>> The engineering part makes sure the software has been
> >>> tested for all possible (and impossible) events/usages.

> >> I suspect that this is not even likely. =A0I gave a counter
> >> example else thread involving input for a number of boolean
> >> variables, let's say 64. =A0Tough to test all of those.

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

> Testing is one area where the analogies between software and
> other engineering disciplines do stand up well. =A0The software
> developer who develops in the debugger poking in numbers and
> checking the code "works" is little different form the
> electronics engineer who tinkers on his bench with a signal
> generator and an oscilloscope until his circuit "works". =A0Both
> are ill-disciplined, both are producing something fragile.

> The equipment and time costs make it much more difficult for
> the hardware engineer to build an test harness for his circuit
> than for the software developer to write unit tests for his
> code. =A0The cost/time of testing problem increases
> exponentially for larger physical systems which is why most
> engineering disciplines now rely on simulation models.

There are similarities, but testing is not an option for all
disciplines.  How do you "test" a skyscraper?

> Maybe software development is closer to what engineering once
> was: the basic application of scientific principals. =A0We start
> with an hypothesis (a requirement), we design and experiment
> (write a test), conduct the experiment (run the test) and
> observe the result.

We also use known (tested) components.

There is one other important difference (and the point was
raised earlier).  Software isn't linear.  Depending on what the
code does, this can affect the significance of testing.

> I expect over time we will come to rely on more abstract tools
> for software development (the simulation model approach used
> by physical engineering disciplines), but that time is still a
> way off.

Regretfully.  Especially with regards to things like thread
safety; a good simulation model could determine the results of a
thread switch at all possible moments, something which is
impossible to trigger for a test.

> >> And to repeat, I once spoke to a EE who told me his company
> >> was going to test software for all possible inputs. Once I did
> >> the arithmetic for him he withdrew his statement.

> Just like they test their circuits with all possible inputs!

It's actually more or less possible for analog circuits.  Just
feed a ramp into the input.  But it doesn't mean much, because
such circuits may respond differently depending on input
frequencies, etc.  Hardware isn't necessarily linear either.
(Back when I was working in hardware, we actually had a problem
where the resonant frequency of the backplane was about the same
as our main clock frequency.  Most of the time, everything
worked fine, but as the components aged, their impedence changed
slightly, which changed the resonant frequency of the backplane.
When it corresponded exactly to the clock frequency, all hell
broke loose.  And back then, the clock frequency was determined
by a simple RC oscillator, so a slight change in temperature,
and the thing started working again.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/27/2008 10:16:09 PM
On Thu, 27 Nov 2008, Paavo Helde wrote:

> Tom Anderson <twic@urchin.earth.li> kirjutas:
>
>> On Thu, 27 Nov 2008, Paavo Helde wrote:
>>> One can apply sccientific principle regardless of the area of the
>>> study. And besides, I see no fundamental distinction of a process
>>> running on 1D arrays of bits in the computer memory, and a process
>>> running on 11D M- branes.
>>
>> Fundamentally, no. But in practice, there's a huge difference, because
>> there are simplifying approximations that describe the M-branes (or
>> whatever it really is) very accurately, which we can use to analyse
>> problems and designs to predict with corresponding accuracy whether
>> they'll work. There are no such approximations with the bits.
>
> I think there are, otherwise we would still program in machine code. I
> think for example functions, computer languages, libraries, processes,
> operating systems are all some kind of generalisations aka approximations
> which allow us to reason about this bit-twiddling machine in more
> convenient terms.

That's an interesting idea. The trouble is that those abstractions are 
mostly either too complicated to work or too simple to be any use. Your 
example of an operating system is quite a good one - we can have a very 
simple formal model of how something like memory management works, which 
lets us think about programs running in a simple linear address space, 
despite the truth being rather different. But i don't think you can break 
a typical application down into bits like that. The interfaces between 
parts, and the behaviours of those parts, are too complicated to be 
described simply.

This is why designing really successful component architectures has been 
so hard (so far, impossible). Components - for reuse or for proof - need 
to have simple interfaces. The interfaces to interesting bits of code just 
aren't simple.

tom

-- 
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler
0
twic (2088)
11/27/2008 10:37:38 PM
On Thu, 27 Nov 2008 21:21:01 +0000, Tom Anderson wrote:

> 
> Oh, absolutely. I'm not knocking the value of qualifications! At least,
> not all of them. I was just wondering if my lack of them made me a
> criminal.
>
Why on earth would it do that?

We're not yet /required/ to belong to a professional association like 
medical doctors.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/27/2008 11:44:27 PM
On Thu, 27 Nov 2008 21:13:44 +0000, Tom Anderson wrote:

> On Thu, 27 Nov 2008, Martin Gregorie wrote:
> 
>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>
>>> Martin Gregorie wrote:
>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>
>>>>> But I think I made it plain that engineers don't consider the entire
>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>> wind loading or some such.  The parameters are likely to be driven
>>>>> by budget, customer requirements or perhaps good practice.
>>>>>
>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>> Narrows bridges ignored wind and look where that got them.
>>>
>>> I'm sorry, but what is quite wrong?  I completely fail to understand
>>> how your response contradicts anything I wrote above.  Please explain,
>>> because I utterly bewildered by your response.
>>>
>> This:
>>  "But I think I made it plain that engineers don't consider the entire
>>   physics of the bridge. They might not consider fluid interactions or
>>   wind loading or some such."
>>
>> I suggest you do some reading about those bridges.
>
> Hold up - those examples show that, in the cases of those bridges (or
> Tacoma Narrows, at least), the engineers indeed did not consider wind
> loading!
>
Exactly so. Look back up this post and you'll see that "LR" said it 
didn't matter whether bridge designers looked at wind loading or not 
because the cost of doing the design was a bigger consideration than 
spending time and money to calculate wind loading. I pointed to two well-
known failures that were due to the designers ignoring wing factors. He 
evidently *didn't know* that both blew down because he clearly didn't 
understand that reply.

You jumped in when I was trying, rather politely I thought, to give "LR" 
the chance to dig himself out of his self-constructed hole rather than 
calling him a pig-headed know-nothing. So I won't, but I did want to see 
what his reply would be.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
martin5229 (287)
11/28/2008 12:00:58 AM
Matthias Buelow wrote:
> Lew wrote:
>> And wrong.  Software development can be, and is, an engineering discipline.
> 
> You can reduce it to that, however, you'll lose out in the long run.
> 
> Writing software isn't like building a bridge. Once a bridge is in
> place, it will stay that way for a long time. Apart from maintenance, it
> most likely won't be touched. It certainly won't be turned into an
> apartment block.
> However, this is what happens to software. A large program is a moving
> target. It needs to be able to grow, expand and mutate far beyond what
> has been imagined by its original designers.

I think everyone agrees that software engineering is much more complex
than bridge building.

But that does not make it less engineering - probably more.

>                                             Also, it is impossible to
> make perfect and totally reliable software.

Not true.

It just happens that the cost for doing that is too high.

>                                                 The notion that software
> reliability comes from meticulous up-front "engineering" is naive thinking.

It is the only place software reliability can come from.

Arne

0
arne6 (9808)
11/28/2008 12:28:03 AM
Matthias Buelow wrote:
> Sabine Dinis Blochberger wrote:
>> Because it makes it a structured, systematic and quantifiable approach
>> (see link above). Instead of just guessing use cases, results and
>> timelines.
> 
> You can only do this if you are writing software that basically is made
> up of subparts that have been done before. This doesn't work for all
> software. If you've never built something like a bridge before, you
> can't apply proven patterns and procedures.

But that is the same for software and bridges.

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

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

Software engineering is not the only field where that
applies.

Arne
0
arne6 (9808)
11/28/2008 1:00:04 AM
On Nov 27, 8:07 am, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > The _American Heritage Dictionary_ gives:
>
> >     The application of scientific and mathematical principles to
> >     practical ends such as the design, manufacture, and
> >     operation of efficient and economical structures, machines,
> >     processes, and systems.
>
> > That certainly covers software engineering.  The term
> > "scientific and mathematical principles" is broad, and covers a
> > lot more than just physical laws like Archimedes' principle.  Or
> > even mathematical proofs of programs.  The entire sentence above
> > makes it clear that it also applies to the process, for example.
> > Every good shop I've seen makes extensive use of statistics, for
> > example, in evaluating their process.  And controlled testing,
> > which is the basis of all scientific methodology.  And code
> > review, which is a form of peer-review such as is used in all
> > scientific journals.  Software engineering is all about the
> > "design [...] of efficient and economical [...] systems", using
> > "scientific and mathematical principles" in a practical way.
> > You can't get more "engineering" than that.
>
> I'm sorry, but could you please be explicit about which scientific
> principle is being applied?

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

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

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

KHD

0
duggar (292)
11/28/2008 1:28:03 AM
Keith H Duggar wrote:
> Software Engineering is replete with scientific principles.
> Here are but a few off the top of my head:
> 
> Principle of Induction
> Pigeonhole Principle
> Information Principle
> Chebyshev's Inequality
> Akra-Bazzi Theorem
> Divide-and-Conquer
> Dynamic Programming
> Sieve Principle
> Occam's Razor
> Murphy's Law
> 
> A decent computer science or software engineering curriculum
> should expose you to these and many other principles. Perhaps
> decent curriculums (or students that pay attention) are more
> rare than I realized.

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

-- 
Lew
These go to eleven.
0
noone7 (4050)
11/28/2008 1:32:52 AM
Matthias Buelow wrote:
>> The notion that software
>> reliability comes from meticulous up-front "engineering" is naive 
>> thinking.

Arne Vajhøj wrote:
> It is the only place software reliability can come from.

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

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

-- 
Lew
0
noone7 (4050)
11/28/2008 1:41:23 AM
Martin Gregorie wrote:
> A long time ago in Bath I was amongst 80 contractors fixing a wee problem 
> the MoD had found themselves saddled with. There was one guy there who 
> other contractors had seen on and around various projects for 6 or 7 
> years and had never been known to successfully finish a program. He 
> always managed to leave in time and his programs were generally scrapped 
> and rewritten. 

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

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

-- 
Lew
0
noone7 (4050)
11/28/2008 1:48:56 AM
Lew wrote:
> Matthias Buelow wrote:
>>> The notion that software
>>> reliability comes from meticulous up-front "engineering" is naive 
>>> thinking.
> 
> Arne Vajhøj wrote:
>> It is the only place software reliability can come from.
> 
> I suggest a refinement of that response.  Meticulous up-front 
> engineering is required but not sufficient.  Engineering cannot stop 
> once construction begins.

True.

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

Arne
0
arne6 (9808)
11/28/2008 1:51:19 AM
LR wrote:
> Lew wrote:
>> There is no reasoning with you.
> 
> Actually to the contrary, there is only reasoning with me.

We have seen no evidence of that in this thread.

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

:-)

Arne
0
arne6 (9808)
11/28/2008 2:21:52 AM
LR wrote:
> F = ma is a scientific principle.

No.

It is not a principle.

It is a law in physics.

Arne
0
arne6 (9808)
11/28/2008 2:25:08 AM
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Arne Vajhøj wrote:
>>>> LR wrote:
>>>>> I've seen some bridges come with documentation that says things like "No
>>>>> vehicles over 5 [sic] tons." But I can't say I can recall ever seeing
>>>>> documentation for a program that says "Do not enter numbers over
>>>>> 1,000,000.00 or your computer will break." Sometimes the program itself
>>>>> will tell you after you enter a bad number.  I suppose that would be
>>>>> more like driving a six ton truck on the aforementioned bridge, without
>>>>> the sign present, with perhaps obvious consequences.  Although I suspect
>>>>> the bridge sign was probably written with some safety factor in mind,
>>>>> whereas the program probably won't work if 1,000,000.01 is entered.
>>>> I can not think of any serious enterprise app where the docs
>>>> does not specify a lot of limits (both functional and for
>>>> given hardware performance related).
>>> Please define what you mean by the word "serious" in the above. TIA
>> Try:
>>
>> http://www.google.com/search?hl=en&q=define%3Aserious&btnG=Google+Search&aq=f&oq=
> 
> Ok, thanks, I think I take your meaning now.  So it's circular?  If it
> doesn't fit your criteria, then it's not serious and if it does, it is?
>  Did I get that right?

No.

Try click the link and read.

Arne
0
arne6 (9808)
11/28/2008 3:31:09 AM
LR wrote:
> courpron@gmail.com wrote:
>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>> 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.
>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>> proof that the program you've written will halt.  Can you provide that?
>> Yes, absolutely reliable. The program is proven to be correct in any
>> way. The proof can be given in the form of mathematical notations.
> 
> I'm not sure you responded to my question, so please allow me to restate
> it.  Suppose you have a customer who wants a formal proof that the
> program you've written will halt, can you provide that?

Most likely yes.

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

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

Arne
0
arne6 (9808)
11/28/2008 3:36:31 AM
LR wrote:
> Lew wrote:
>> LR wrote:
>>> Tom Anderson wrote:
>>>
>>>> Still, i call myself a 'software engineer' because it sounds more 
>>>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>>>> and academics and the like.
>>> IANAL, but since you're calling yourself a "software engineer" might I
>>> ask what jurisdiction you do that in?
>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>
> 
> On business cards? Letterhead? I'm sorry, I don't recall, did you say
> you were a PE?

Software engineer is a widely used title in the US.

Try search on dice.com or monster.com !

Arne
0
arne6 (9808)
11/28/2008 3:38:57 AM
LR wrote:
> James Kanze wrote:
>> For some types of
>> software, at laest.  For real time software, it's less obvious,
>> since it's fairly hard to be sure that you've analysed all
>> possible timing issues.  
> 
> I don't think testing all the possible interactions is possible for most
> software. Consider a fairly simple program that reads inputs for say 64
> boolean variables and has at least one conditional branch for each
> variable.

 >> But it's still several orders of
 >> magnitude easier than verifying that you've analysed all
 >> possible physical interactions which might affect a bridge.
 >
 > But that isn't done.  AFAIK ever. I don't think there's enough time in
 > the universe to do that.  Not even for all the likely cases.

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

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

>>>                                   I was wondering if you
>>> could take a shot at answering what I think is a simple
>>> question with what might be a quick answer:  What scientific
>>> principle is being applied in "software engineering"?
>> Mathematics.
> 
> Yeah, that's it then.  Except math is not a science.

Sure is.

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

Arne
0
arne6 (9808)
11/28/2008 3:44:18 AM
LR wrote:
[...]  But to my mind that would make
> "software engineering" a unique thing.  Different from say chemical,
> mechanical or civil. But perhaps there is another branch of engineering
> that doesn't require the application of scientific principle?

Perhaps there is.

AL
0
lithar (20)
11/28/2008 3:46:54 AM
Lew wrote:
> LR wrote:
>> Tom Anderson wrote:
>>> Still, i call myself a 'software engineer' because it sounds more 
>>> high-status than 'programmer', and i go to a lot of parties with 
>>> lawyers and academics and the like.
>>
>> IANAL, but since you're calling yourself a "software engineer" might I
>> ask what jurisdiction you do that in?
> 
> I call myself a "software engineer" in Maryland, the U.S. of A.

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

Arne
0
arne6 (9808)
11/28/2008 3:50:00 AM
On Mon, 24 Nov 2008 00:20:56 -0500, Joshua Cranmer wrote:

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

It doesn't even compile.

-- 
// This is my opinion.
0
jebblue
11/28/2008 4:46:24 AM
Tom Anderson wrote:

>> Same here: its well recognised in the UK. I hold a CE in software 
>> engineering as well as an MSc (Chemistry).
> 
> But i'm right in thinking that one doesn't need either of those to call 
> oneself a software engineer, i hope?

A programmer who calls himself a Software Engineer is not going to
fool those who know the difference - job wise, need wise, hiring wise,
pay wise.

-- 

0
plas (2)
11/28/2008 5:32:06 AM
On 28 nov, 04:36, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> LR wrote:
> > courp...@gmail.com wrote:
> >> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
> >>> courp...@gmail.com wrote:
> >>>> On 25 nov, 15:38, LR <lr...@superlink.net> wrote:
> >>>>> =A0{...]
> >>>>> Do the programs provably work? To the same extent that an engineer =
could
> >>>>> "prove" that the bridge they designed will work? =A0
> >>>> 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 th=
e
> >>>> specifications of your program with pre/postconditions, invariants,
> >>>> etc. You can mathematically prove that your program will work by tho=
se
> >>>> means. This is used in any sensible environment that needs absolutel=
y
> >>>> reliable softwares.
> >>> Absolutely reliable? Suppose you have a =A0customer who wants a forma=
l
> >>> proof that the program you've written will halt. =A0Can you provide t=
hat?
> >> Yes, absolutely reliable. The program is proven to be correct in any
> >> way. The proof can be given in the form of mathematical notations.
>
> > I'm not sure you responded to my question, so please allow me to restat=
e
> > it. =A0Suppose you have a customer who wants a formal proof that the
> > program you've written will halt, can you provide that?
>
> Most likely yes.
>
> Computer science has proven that it is not possible to do that
> for all programs, but it can be done for some programs. If one
> is willing to spend the money, then it can be done for most
> programs.
>
> (the examples used to prove the haling problem is not
> generally solvable are not very realistic programs)

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

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

Alexandre Courpron.
0
courpron (89)
11/28/2008 8:44:23 AM
On Nov 28, 1:28 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Matthias Buelow wrote:
> > Lew wrote:
> >                                             Also, it is impossible to
> > make perfect and totally reliable software.

> Not true.

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/28/2008 9:21:55 AM
James Kanze wrote:

> On Nov 28, 1:28 am, Arne Vajh�j <a...@vajhoej.dk> wrote:
>> Matthias Buelow wrote:
>> > Lew wrote:
>> >                                             Also, it is impossible to
>> > make perfect and totally reliable software.
> 
>> Not true.
> 
> I disagree.  It is impossible to make a perfect and totally
> reliable anything, as long as it is being made by human beings;
> software is no different.

You are getting philosophical :-)

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


Best

Kai-Uwe Bux
0
jkherciueh (3186)
11/28/2008 9:35:40 AM
LR wrote:

> Sabine Dinis Blochberger wrote:
> > LR wrote:
> > 
> >> James Kanze wrote:
> >>>  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?
> >>
> > The criteria are different, so you can't apply physical strength to any
> > project. There is stress testing in software development. 
> 
> There are viruses and bugs too. Is software development biology?  I
> don't mean to be flippant, but the mere use of a word doesn't confer
> meaning on the object it refers to, does it?
> 
The terms come from when computers were huge, room filling things with
radio tubes. They would stop working properly when roaches/insects
entered the structure, hence the term "bugs".

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

> > The
> > engineering part makes sure the software has been tested for all
> > possible (and impossible) events/usages.
> 
> I suspect that this is not even likely.  I gave a counter example else
> thread involving input for a number of boolean variables, let's say 64.
>  Tough to test all of those.
> 
And that's not what a sane person tests. It is established that an
Integer, for example, can only hold whole numbers. No *need* to test for
that. On a software project, you don't have to re-develop all the tools,
just like a bridge engineer won't build his own hammers in his garage.

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

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

> And to repeat, I once spoke to a EE who told me his company was going to
> test software for all possible inputs. Once I did the arithmetic for him
> he withdrew his statement.
> 
It usually suffices to make up test cases that cover areas - allowed
inputs, impossible inputs, and wrong inputs (whatever that means within
the project).

> > And AFAIK civil engineers have formulas to calculate physical strengths
> > and such, that are based on observation and experimentation.
> 
> They do.  I'm sorry, did I say anything to indicate otherwise? If so,
> please allow me to withdraw that. Although, I suspect they may not know
> all there is to know about this yet.  I also note that,  AFAIK, at least
> some of these are of comparatively recent origin. For example, I think
> the use of timber in bridges wasn't even reasonably understood until
> Herman Haupt did the experiments to figure out what the strength of the
> beams were.

That doesn't make it less engineering. Even inventors use engineering
techniques.
0
no.spam6050 (391)
11/28/2008 10:43:57 AM
On Nov 28, 12:43=A0pm, Sabine Dinis Blochberger <no.s...@here.invalid>
wrote:
> LR wrote:
> > Sabine Dinis Blochberger wrote:
> > > LR wrote:
>
> > >> James Kanze wrote:
> > >>> =A0There 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 c=
ould
> > >> "prove" that the bridge they designed will work? =A0What kinds of me=
trics
> > >> are used? =A0Does software have a stress point beyond which it will
> > >> deform, like the metal in the bridge will?
>
> > > The criteria are different, so you can't apply physical strength to a=
ny
> > > project. There is stress testing in software development.
>
> > There are viruses and bugs too. Is software development biology? =A0I
> > don't mean to be flippant, but the mere use of a word doesn't confer
> > meaning on the object it refers to, does it?
>
> The terms come from when computers were huge, room filling things with
> radio tubes. They would stop working properly when roaches/insects
> entered the structure, hence the term "bugs".
>
> Computer viruses are called that because of their self-replicating and
> -spreading characteristics.
>
> > > The
> > > engineering part makes sure the software has been tested for all
> > > possible (and impossible) events/usages.
>
> > I suspect that this is not even likely. =A0I gave a counter example els=
e
> > thread involving input for a number of boolean variables, let's say 64.
> > =A0Tough to test all of those.
>
> And that's not what a sane person tests. It is established that an
> Integer, for example, can only hold whole numbers. No *need* to test for
> that. On a software project, you don't have to re-develop all the tools,
> just like a bridge engineer won't build his own hammers in his garage.
>
> With software, you test that it *behaves* as intended, not that an
> integer is an integer.
>
> The example yougive with booleans would be unit-tested, or otherwise at
> a "low" level of development. If you have a GUI with 64 check buttons,
> you really need to rethink that design. If it is settings, then
> they/their effects need to be tested. No way around it.
>
> > And to repeat, I once spoke to a EE who told me his company was going t=
o
> > test software for all possible inputs. Once I did the arithmetic for hi=
m
> > he withdrew his statement.
>
> It usually suffices to make up test cases that cover areas - allowed
> inputs, impossible inputs, and wrong inputs (whatever that means within
> the project).
>
> > > And AFAIK civil engineers have formulas to calculate physical strengt=
hs
> > > and such, that are based on observation and experimentation.
>
> > They do. =A0I'm sorry, did I say anything to indicate otherwise? If so,
> > please allow me to withdraw that. Although, I suspect they may not know
> > all there is to know about this yet. =A0I also note that, =A0AFAIK, at =
least
> > some of these are of comparatively recent origin. For example, I think
> > the use of timber in bridges wasn't even reasonably understood until
> > Herman Haupt did the experiments to figure out what the strength of the
> > beams were.
>
> That doesn't make it less engineering. Even inventors use engineering
> techniques.

I think engineering is about using resources efficiently, to produce
best product with minimum usage of resource. Optimization may be
another keyword which is common in all branches of engineering. For a
particular task if a software gives result in 1 hour and other one in
2 hours we can say one of them is better engineered. OR one program
needs 1GB ram to run smoothly while other one needs 100 mb yet both of
them gives same result. Optimization is a keyword which is common in
all branches of engineering. You can speak for a programe as optimized
or poorly optimized. For example in first person shooter type video
games you need to optimize game engine as if it is poorly optimize it
won't sell because customer always compare it with other games or
other products. If one game runs smoothly with same level of graphics
or resolution while the other one freezes every second than you have a
commercially death product. So IMHO "computer engineering" is a title
that fits good to people working on programming.
0
11/28/2008 11:34:51 AM
On Nov 28, 10:35 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> James Kanze wrote:
> > On Nov 28, 1:28 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> >> Matthias Buelow wrote:
> >> > Lew wrote:
> >> >                                             Also, it is impossible t=
o
> >> > make perfect and totally reliable software.

> >> Not true.

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

> You are getting philosophical :-)

Not really.  Much of what makes engineering engineering is
deciding just how close to perfect and totally reliable we have
to be.  Claiming perfection, however, is not responsible
engineering (software or otherwise).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
11/28/2008 2:43:17 PM
Although, as you apply force and acceleration happens, the mass changes, 
too...

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:492f5679$0$90270$14726298@news.sunsite.dk...
> LR wrote:
>> F = ma is a scientific principle.
>
> No.
>
> It is not a principle.
>
> It is a law in physics.
>
> Arne 


0
alegr (49)
11/28/2008 3:29:51 PM
Arne Vajh�j <arne@vajhoej.dk> wrote:
> Matthias Buelow wrote:

> > The notion that software reliability comes from meticulous
> > up-front "engineering" is naive thinking.
> 
> It is the only place software reliability can come from.

Although I agree with Arne, I think his conception of what constitutes 
"engineering" in the software sense is probably too exclusive. In 
construction, the engineers design the structure then pass it off to the 
builders who then build it to spec. For software, the "builders" are the 
compiler, linker, and runtime environment. The writing of the code is 
part of the design processes.
0
daniel_t (1960)
11/28/2008 5:05:27 PM
Tommy <plas@dacxsee.com> wrote:
> Tom Anderson wrote:
> 
> >> Same here: its well recognised in the UK. I hold a CE in software 
> >> engineering as well as an MSc (Chemistry).
> > 
> > But i'm right in thinking that one doesn't need either of those to call 
> > oneself a software engineer, i hope?
> 
> A programmer who calls himself a Software Engineer is not going to
> fool those who know the difference - job wise, need wise, hiring wise,
> pay wise.

I think many people here have anecdotes to the contrary.

Tom the problem is that many who have CE degrees in "software 
engineering" aren't effective software engineers, and many who are 
effective don't hold a degree. I'm not going to hazard to guess what the 
proportions are, but the question is enough up in the air, that 
requiring a degree for any software construction job would be a huge 
mistake IMHO.

The above may not always be the case, schools may one day become 
effective in weeding out the unqualified and not graduating them, but 
they aren't there yet. I think part of the problem is that no one is 
really sure what software engineering really entails yet.
0
daniel_t (1960)
11/28/2008 5:21:55 PM
> Programs are carefully hand-crafted one line at a time...

Aren't bridge blueprints carefully drawn one line at a time as well?
0
daniel_t (1960)
11/28/2008 5:26:56 PM
James Kanze wrote:
> On Nov 27, 2:07 pm, LR <lr...@superlink.net> wrote:
>> James Kanze wrote:
>>> On Nov 27, 3:58 am, LR <lr...@superlink.net> wrote:
> 
>     [...]
>> I'm sorry, but could you please be explicit about which
>> scientific principle is being applied?
> 
> All of them.  The results must be reproduceable.  The results
> must be validated by peer-review.
> 
> You seem to be confusing scientific principles with scientific
> laws.  Scientific principles are what we use to determine
> whether something is a scientific law or not.  Or whether a
> program works or not.  Whether a given program works according
> to its requirements specifications is, in some ways, a
> scientific law, or at least, a proposed scientific law.  If we
> accept that it works according to scientific principles, we've
> applied those principles.
> 
> (But of course, there's a lot more to engineering than just
> using scientific principles.)

Or not.

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

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

LR
0
lruss (582)
11/28/2008 5:45:02 PM
James Kanze wrote:
> On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
>> Sabine Dinis Blochberger wrote:
>>> LR wrote:
> 
>     [...]
>> If I accept the definition given above.  But to my mind that
>> would make "software engineering" a unique thing.  Different
>> from say chemical, mechanical or civil.
> 
> Well, the same thing could be said about chemical engineering.
> Or electronics engineering.  Each engineering discipline is
> unique.  What makes them "engineering" is that they use a
> scientific approach to solving pragmatic problems.

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


> 
>> But perhaps there is another branch of engineering that
>> doesn't require the application of scientific principle?
> 
> They all do, including software engineering.  That's part of
> what makes them engineering.

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


> 
>>>>> 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?
> 
>>> The criteria are different, so you can't apply physical
>>> strength to any project. There is stress testing in software
>>> development.
> 
>> There are viruses and bugs too. Is software development
>> biology?  I don't mean to be flippant, but the mere use of a
>> word doesn't confer meaning on the object it refers to, does
>> it?
> 
> Certainly, but as I've pointed out elsewhere, software
> engineering is as rigorous in this regard---perhaps
> moreso---than e.g. bridge design, or some of the other
> activities you've named.

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

What is the analogous thing for software?


> 
>>> The engineering part makes sure the software has been tested
>>> for all possible (and impossible) events/usages.
> 
>> I suspect that this is not even likely.  I gave a counter
>> example else thread involving input for a number of boolean
>> variables, let's say 64.  Tough to test all of those.
> 
> It's sufficient that it takes a double as input, and it is, for
> all intents and purposes, impossible to test exhaustively.
> People who claim the software is correct because it passes some
> test suite aren't engineers.  (Nor are people who forego testing
> entirely, on the grounds that it can't catch everything.)

No argument there.



[snip]
>>> And AFAIK civil engineers have formulas to calculate
>>> physical strengths and such, that are based on observation
>>> and experimentation.
> 
>> They do.  I'm sorry, did I say anything to indicate otherwise?
> 
> My understanding was that you were forwarding the opposite
> argument; that you'd only accept software engineering as an
> engineering discipline if it had such formulas.  And of course,
> we don't have formulas based on physical strengths (although
> things like the big-O notation are related in some ways). 

Could you expand on that please.


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

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



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

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

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

LR





0
lruss (582)
11/28/2008 5:55:42 PM
Daniel T. wrote:
> Arne Vajh�j <arne@vajhoej.dk> wrote:
>> Matthias Buelow wrote:
>>> The notion that software reliability comes from meticulous
>>> up-front "engineering" is naive thinking.
>> It is the only place software reliability can come from.
> 
> Although I agree with Arne, I think his conception of what constitutes 
> "engineering" in the software sense is probably too exclusive. In 
> construction, the engineers design the structure then pass it off to the 
> builders who then build it to spec. For software, the "builders" are the 
> compiler, linker, and runtime environment. The writing of the code is 
> part of the design processes.

It is sometimes difficult to find a 100% matching analogy.

If a project do extremely detailed design, then I will consider
writing the actual code part of building.

And it fits with:
- it is very unlikely that a compiler turns good source code
   into bad binary code
- it happen that a builder mess up a good blueprint
- it happen that the programmer writing the code
   mess up a good design

But very few projects do detailed design to make writing
the code pure building. It is often a mix of lowel level
design and building.

Arne
0
arne6 (9808)
11/28/2008 6:02:02 PM
James Kanze wrote:
> On Nov 27, 3:54 am, LR <lr...@superlink.net> wrote:
>> Lew wrote:
>>>> Sorry, I think that qualifies as mathematics.
>>> What a specious argument.
>> I conclude that you don't have an argument.
> 
> I conclude that you are using a rhetoric technic that isn't
> being recognized or understood here.  (Happens to me all the
> time:-).)

I suspect that I'm being misunderstood, yes, but that might be because
I'm not explaining myself well?

But no, I think that he simply didn't have an argument and chose to
complain about mine instead of responding to it. Happens to me all the
time. ;)

Well, OTOH, I must admit the possibility that it's possible that he had
a brilliant argument, and simply choose not to waste it on me.


> 
>>> Then you reject the scientific principles proffered because
>>> they "sound like" mathematics *to you*, and therefore must
>>> not be science, again, by your definition only.
> 
>> In what way is computer science a science and not mathematics.
> 
> In the same way quantum physics is a science.  Mathematics is
> also a science.  It differs from other sciences in that it has a
> somewhat particular relationship with reality, but if you've
> read any Feynman, you'll realize that quantum physics is pretty
> much in the same situation.  

I haven't read enough Feynman to understand that. How is quantum
mechanics in the same situation?

> (And if you understand quantum
> physics---supposing that understanding quantum physics is
> possible, or that the word "understanding" is even applicable to
> quantum physics---you'll realize that it implies that all other
> sciences have the same somewhat tenuous relationship to
> reality.)

I seem to recall some physicist who said that anyone who claimed they
understood quantum mechanics was self-deluded.  I'm not yet at the stage
where I can claim to not understand quantum mechanics because I don't
yet understand classical physics.  But maybe that's not possible either? ;)



> In a very real sense, one might say that science is
> understanding, and engineering using that understanding.

I'm not sure that I agree with that completely.  In part perhaps.




> Mathematics leads to real understanding, so it is a science.

I don't agree with that. And I don't think I've ever heard anyone
describe math as a science. They differ.

OTOH, I once attended a class in "Social Sciences."  I don't know what
that means either. I can say that I don't think it led to "real
understanding."

Also, not to get too involved in a semantic argument, "real
understanding" is at odds with my understanding that math is useful as a
tool because often only limited understanding is open to us.


> Applied mathematics uses that understanding, so it is
> engineering.  In a similar way, computer science determines the
> big-O for some algorithm (understanding), so it is science;
> software engineering chooses between algorithms on the basis of
> that understanding, weighing big-O, cost, etc., so it is
> engineering.  

I recently came across a link where George Soros uses the term
"financial engineering" with perhaps some of the sense of
"understanding" and "using that understanding" that you meant, although
I think he may have meant the phrase somewhat derogatorily.
http://www.georgesoros.com/crisis-and-what-to-do110608  Is there a
recognized discipline of "financial engineering"?


> Of course, there's a lot more to software
> engineering than just choosing the right algorithm.  Much of it
> is involved in choosing the right "technique"---sort of like
> deciding whether a bridge should be welded or use rivets.

Like a cobbler selecting what material to use for an upper as opposed to
a sole?

LR
0
lruss (582)
11/28/2008 6:20:11 PM
James Kanze wrote:
> On Nov 27, 4:04 am, LR <lr...@superlink.net> wrote:
>> Tamas Demjen wrote:
>>> LR wrote:
>>>> Sorry, I think that qualifies as mathematics.
>>> It's applied mathematics,
> 
>> Is applied mathematics science?
> 
>>> like with other fields of engineering.
> 
>> I think every branch of engineering applies mathematics. But
>> they do it to apply scientific principle. I repeat, as I don't
>> believe I have received an answer, what scientific principle
>> is applied in "software engineering"?
> 
> That's because you've left us guessing what you mean by
> "scientific principle".  

I accept this may not have been the best choice of words and your
suggestion of scientific law may have been better.

> The examples you've given have been
> more akin to formula than to principles.  

It may have been better to say resonance rather than give a formula for
an LC circuit.

>
> Software has such
> (e.g. big-O forula), and they do play a role in software
> engineering, but a moderate role.  What makes something science,
> however, isn't the formula (chemistry uses a completely
> different sort of formula), but rather, the principles which are
> used to determine which formula are valid.  Why do you accept
> F=ma (which actually isn't valid according to modern science),
> rather than, say F=2ma, or F=mv?  (This isn't trivial.  For the
> longest time, scientists believed that it was acceleration which
> was dependent on the gravitational masses, rather than force.
> And today relativistic and quantum physics teach us something
> different as well.)

I'll happily accept that correction as well, but then in some sense I'd
might have to revert to scientific principle, or maybe there's a better
word, but not probably not law.  I know an engineer who says that
anytime you have to consider quantum effects you're in trouble.  My
understanding is that engineering is a very pragmatic endeavor and
what's good enough is good enough. Depending on what good enough means
in the context of the work you're doing.

LR
0
lruss (582)
11/28/2008 6:30:51 PM
James Kanze wrote:
> On Nov 27, 4:32 am, LR <lr...@superlink.net> wrote:
>> Paavo Helde wrote:
>>> LR <lr...@superlink.net> kirjutas:
> 
>> A cook might experiment with the mixture of spices in a dish.
>> Is that engineering?
> 
> If he does so in a scientific way.  If he's just guessing, no,
> but if he's basing his choice of which spice to try on the known
> characteristics of the spice, and if he meets the other
> qualifications (considers price, etc.), then it is engineering.

I think I agreed with something similar to this elsethread.

> 
>     [...]
>>> Any mathematically correct algorithm, however slow or
>>> memory-consuming, would qualify as a valid and usable
>>> program. As we are not there yet, programming needs
>>> engineering approach.
> 
>> I don't think that an engineering approach to something
>> doesn't mean that it's engineering.
> 
> So what is engineering.  It sounds to me like using a
> engineering approach would be a definition.  (Not a good one,
> since it is circular.)

I think that I disagreed with this elsethread.

> 
> Science tells us whether the algorithm is correct or not,

I think it's math that tells us if the algorithm is correct or not.



> and
> evaluates its speed (in big-O).  


> Engineering tells us whether it
> is appropriate in the context of the given requirements, taking
> into account what science tells us about it (e.g. big-O), but
> also other pragmatic issues (like development time).

Sounds a little more like accounting or management to me.

LR
0
lruss (582)
11/28/2008 6:34:00 PM
James Kanze wrote:
> On Nov 27, 1:44 pm, LR <lr...@superlink.net> wrote:
>> Paavo Helde wrote:
>>> If I want to cross a ditch and throw a log over it, then I'm
>>> not engineering. Maybe only a bit, the "scientific
>>> knowledge" learned from experience and experimentation
>>> consists of facts that larger logs bear more weight, however
>>> on the other hand they are heavier to lift.
> 
>> That only a bit would imply that everything is engineering.
> 
> Not really.  If there are three logs, of different sizes, and I
> choose the smallest, because it is easiest to lift, even though
> I hae no reason to believe that it will support my weight, it's
> not engineering.  

No?  Didn't you suggest elsewhere that part of engineering was
considering development time?  How does this differ? Did I misunderstand
you?

> If I choose one of the logs because of some
> religious reasons (always choose the one on the right, because
> things on the right are holy), it's not engineering.  

And yet, I've been told that some religions have god that are technology
related.  I don't know enough about them to know if it's true or not.

> It's only
> engineering if I choose based on scientific fact (or what is
> believed to be so by me)---log A won't support me, but log C
> will require a lot more effort to put into place than log B,
> etc.

Easiest to lift doesn't fall into this problem space?

[snip]
>>>>> If that was the case, programming would be indeed reduced
>>>>> to a branch of mathematics or logic.
>>>> What part of it isn't?
> 
> The fact that it costs money:-).  

Bwahaha.


> Seriously: mathematics or
> logic, in the classical sense, are sciences.  

We disagree on this.  Might I ask how you define math and science?

> They're concerned
> with some sort of abstract truth, determined according to
> certain criteria.  

Every definition I recall ever reading about science and math differs
from this.

> Programming is concerned with solutions, not
> the abstract truth.  Which makes it engineering, instead of
> science.  

I don't think this is particularly how math and science and engineering
differ.


> (If you accept that programming is a branch of applied
> mathematics, then you've accepted the "scientific principles"
> aspect; 

No, I don't think that's true either.  If I need to know the formula a
volume, and I look it up, and calculate it, I might be doing that as
part of an engineering process, but I'm still doing, or using, mathematics.



[snip]

LR
0
lruss (582)
11/28/2008 6:41:42 PM
"Daniel T." <daniel_t@earthlink.net> wrote:
>
>> Programs are carefully hand-crafted one line at a time...
>
>Aren't bridge blueprints carefully drawn one line at a time as well?

I would argue "no".  For the most part, bridges are built up from
pre-defined and well-understood modules with limited options and provable
behavior.

You might get an artist's rendering drawn one line at a time.

Even if we do grant your point, the analogy is not valid.  I don't drive
over a bridge blueprint.  The blueprint is the design document.  The bridge
is engineered.  With software, that "hand-crafted" artistry is exactly what
I am driving on.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
11/28/2008 6:44:19 PM
Arne Vajh�j <arne@vajhoej.dk> wrote:
>LR wrote:
>> 
>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>> you were a PE?
>
>Software engineer is a widely used title in the US.
>
>Try search on dice.com or monster.com !

The fact that it is widely used does not mean that it is CORRECTLY used.
There are many states in which it is illegal to call yourself an "engineer"
of any kind unless you have received an engineering license from the state,
and those license examinations often involve topics in which a software
engineer has no training.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
11/28/2008 6:46:38 PM
Tom Anderson wrote:
> On Wed, 26 Nov 2008, Martin Gregorie wrote:
> 
>> On Wed, 26 Nov 2008 17:13:38 +0000, Tom Anderson wrote:
>>
>>> On Tue, 25 Nov 2008, LR wrote:
>>>
>>>> Tom Anderson wrote:
>>>>
>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>> high-status than 'programmer', and i go to a lot of parties with
>>>>> lawyers and academics and the like.
>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>> ask what jurisdiction you do that in?
>>> In the UK.
>> Same here: its well recognised in the UK. I hold a CE in software 
>> engineering as well as an MSc (Chemistry).
> 
> But i'm right in thinking that one doesn't need either of those to call 
> oneself a software engineer, i hope?

IANAL, so this is just my understanding and shouldn't in any way be
construed as being advice, mere observation.

Most of the places I know about, you'd need a license to use the word
engineer.  There's a test. And perhaps something like an apprenticeship.
And I think the license has to be endorsed by other engineers who will
agree that you have the requisite skills.

AFAIK, calling yourself an engineer without the license is illegal in
many jurisdictions, although, I don't know what the penalty is and I
really do with to emphasize this, IANAL.

OTOH, I've never heard of someone actually being prosecuted for calling
themselves an engineer. I repeat IANAL, but I suspect, but do not know,
that if you did something that might be considered to be malpractice
whilst calling yourself an engineer things might get interesting.

OTOOH, I've read at least one or two arguments in an engineering ng
about what is called a locomotive engineer in the US.  From what I've
seen engineers don't like that usage much. Some get upset about it.


Did I mention IANAL? Good, didn't want to forget that. ;)

LR
0
lruss (582)
11/28/2008 6:57:27 PM
Matthias Buelow wrote:
> Sabine Dinis Blochberger wrote:
> 
>> Because it makes it a structured, systematic and quantifiable approach
>> (see link above). Instead of just guessing use cases, results and
>> timelines.
> 
> You can only do this if you are writing software that basically is made
> up of subparts that have been done before. This doesn't work for all
> software. If you've never built something like a bridge before, you
> can't apply proven patterns and procedures.

But there is now, a reasonable, if imperfect, understanding of how
materials work and the physics of things like fluids for wind loading,
and these may be applied to almost any structure with care. So for
bridges this isn't, IMO, the same kind of problem.

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

I think I agree with that.

But there's something else about this that's been nagging at me, and I
think it might be the issue of system size.  I think I've read, either
in this thread, or maybe in a link someone provided that software
engineering was about big systems.  You seem to be saying that some of
what people are claiming "SE" can do can't really apply to large systems.

And AFAICT size doesn't seem to be an issue with other kinds of
engineers.  Some engineers design bridges, some design the bolts that
hold them together.  Both are engineering.  But maybe we'd need a better
definition of large since I suspect screws have complications that I
don't imagine.


[snip]
> He's saying that for a given set of requirements, you can write
> a program which provably meets those requirements.  Whether
> "halting" is part of those requirements or not---if halting is
> part of the requirements, then you write the program in a way
> that it can be proved to halt.

I don't mean to be obvious, but can the program be proved to halt?

It seems to me that "SE" is going to have to limit itself to a very
small set of problems about which things can be proven.



> Of course, unless provable halting (or anything else) is part of
> the unnegociable requirements, it might be poor engineering to
> do so.  Engineering is a lot about finding cost-efficient
> solutions (as opposed to pure science, where cost is not a
> factor).

I'm not sure I understand, doesn't this conflict with what you wrote above?

LR


0
lruss (582)
11/28/2008 7:09:40 PM
Lew wrote:
> Martin Gregorie wrote:
>>> Same here: its well recognised in the UK. I hold a CE in software 
>>> engineering as well as an MSc (Chemistry).
> 
> Tom Anderson wrote:
>> But i'm right in thinking that one doesn't need either of those to call 
>> oneself a software engineer, i hope?
> 
> Absolutely.

What is your understanding of the requirements to call yourself a
software engineer?

TIA

LR

0
lruss (582)
11/28/2008 7:11:32 PM
Daniel T. wrote:
> Tommy <plas@dacxsee.com> wrote:
>> Tom Anderson wrote:
>>
>>>> Same here: its well recognised in the UK. I hold a CE in software 
>>>> engineering as well as an MSc (Chemistry).
>>> But i'm right in thinking that one doesn't need either of those to call 
>>> oneself a software engineer, i hope?
>> A programmer who calls himself a Software Engineer is not going to
>> fool those who know the difference - job wise, need wise, hiring wise,
>> pay wise.
> 
> I think many people here have anecdotes to the contrary.
> 
> Tom the problem is that many who have CE degrees in "software 
> engineering" aren't effective software engineers, and many who are 
> effective don't hold a degree. I'm not going to hazard to guess what the 
> proportions are, but the question is enough up in the air, that 
> requiring a degree for any software construction job would be a huge 
> mistake IMHO.
> 
> The above may not always be the case, schools may one day become 
> effective in weeding out the unqualified and not graduating them, but 
> they aren't there yet. I think part of the problem is that no one is 
> really sure what software engineering really entails yet.

Possibly, but at the end of the day, considering the topic (who gets a 
higher salary among Java, C++), one who attempts to cover the gambit 
or believes the better pay will come by self-proclaiming to be a 
"Software Engineer" in his resume, better have the credentials and 
experience to back it up.  A CE degree is nice, but it must also be 
coupled with practical experience.  When I talking to potential hire, 
a good clue that the person has promise is when he tells me he can't 
live without his white board. :-)

He would be just as well calling himself a "Software Developer", or 
Project Developer or Product Developer.

The former tells me he has R&D experience, design experience. The 
latter tells me he has production, QA, customer relations, even 
possible technical sales and support experiences.

Grant it, with today smarter tools, IDEs, etc, the many traditional 
disciplines have merged. That was the intent - not only to increase 
productivity, but to lower the cost of expertise requirements, 
increase output without increasing staff.  If a developer wants to say 
he is Software Engineer because he uses these tools, even created 
tools, has experience with all the current languages, he might get 
hired, but not a SE pay scale. If he can put start a project from 
start to finish, create functional specs, communicate with others to 
fine tine it without writing a single line of code, then he/she may 
deserve the pay, but then again he probably won't be looking at a 
programming position. :-)

Anyway my take.  To me, SE still means something and an "IDE" does not 
make one an SE.

--
0
plas (2)
11/28/2008 7:16:03 PM
Martin Gregorie wrote:
> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
> 
>> Martin Gregorie wrote:
>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>
>>>> But I think I made it plain that engineers don't consider the entire
>>>> physics of the bridge. They might not consider fluid interactions or
>>>> wind loading or some such.  The parameters are likely to be driven by
>>>> budget, customer requirements or perhaps good practice.
>>>>
>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>> Narrows bridges ignored wind and look where that got them.
>>
>> I'm sorry, but what is quite wrong?  I completely fail to understand how
>> your response contradicts anything I wrote above.  Please explain,
>> because I utterly bewildered by your response.
>>
> This: 
>   "But I think I made it plain that engineers don't consider the entire
>    physics of the bridge. They might not consider fluid interactions or
>    wind loading or some such."
> 
> I suggest you do some reading about those bridges.

I have read a bit about them. Sorry, but I really am quite confused now.
 You said that they ignored wind loading and I agreed that they might
not consider fluid interactions or wind loading. Perhaps you object to
the redundancy?

Could you please explain to me where we disagree?

LR

0
lruss (582)
11/28/2008 7:16:19 PM
LR wrote:
> Lew wrote:
>> Martin Gregorie wrote:
>>>> Same here: its well recognised in the UK. I hold a CE in software 
>>>> engineering as well as an MSc (Chemistry).
>> Tom Anderson wrote:
>>> But i'm right in thinking that one doesn't need either of those to call 
>>> oneself a software engineer, i hope?
>> Absolutely.
> 
> What is your understanding of the requirements to call yourself a
> software engineer?

In most places it is a job title not an academic title or other
type of certification.

So in most places the requirements is that a company will give
you a job with that title.

Arne
0
arne6 (9808)
11/28/2008 7:20:14 PM
Paavo Helde wrote:

[snip]

> So it appears 
> that my source code file represents an enormous simplification and 
> approximation of the actual computing process taking place on the machine 
> at the time my program is run. In other words, I can predict with some 
> certainty that my program will work correctly,

Makes the process easier, but doesn't change it fundamentally, because
of it's mathematical nature.  It isn't a physical process.

LR


0
lruss (582)
11/28/2008 7:20:52 PM
Tim Roberts wrote:
> Arne Vajh�j <arne@vajhoej.dk> wrote:
>> LR wrote:
>>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>>> you were a PE?
>> Software engineer is a widely used title in the US.
>>
>> Try search on dice.com or monster.com !
> 
> The fact that it is widely used does not mean that it is CORRECTLY used.

I am very skeptical about so called "correct" definitions of words
that are different from the way they are used in practice.

Arne


0
arne6 (9808)
11/28/2008 7:26:10 PM
Ian Collins wrote:

>>> And to repeat, I once spoke to a EE who told me his company
>>> was going to test software for all possible inputs. Once I did
>>> the arithmetic for him he withdrew his statement.
> 
> Just like they test their circuits with all possible inputs!

Heh heh.  But that's part of the point isn't it?

Engineers don't do that, because they rely on the physics to make
predictions about how things will work over a range of physical conditions.

I think that's more difficult for programmers who work with what is a
mathematical construct where provability is more of an issue.

LR



0
lruss (582)
11/28/2008 7:28:05 PM
LR wrote:
> OTOH, I've never heard of someone actually being prosecuted for calling
> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
> that if you did something that might be considered to be malpractice
> whilst calling yourself an engineer things might get interesting.

If someone design a bridge, it collapses and it turns out he is a
software engineer with degree in computer science, then I am sure
all hell will break out.

But if a software engineer designs a piece of software that crashes
then I can not imagine him being prosecuted for not having an
engineering degree in bridge building.

Arne
0
arne6 (9808)
11/28/2008 7:29:19 PM
Tom Anderson wrote:
> On Thu, 27 Nov 2008, Martin Gregorie wrote:
> 
>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>
>>> Martin Gregorie wrote:
>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>
>>>>> But I think I made it plain that engineers don't consider the entire
>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>> wind loading or some such.  The parameters are likely to be driven by
>>>>> budget, customer requirements or perhaps good practice.
>>>>>
>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>> Narrows bridges ignored wind and look where that got them.
>>> I'm sorry, but what is quite wrong?  I completely fail to understand how
>>> your response contradicts anything I wrote above.  Please explain,
>>> because I utterly bewildered by your response.
>>>
>> This:
>>  "But I think I made it plain that engineers don't consider the entire
>>   physics of the bridge. They might not consider fluid interactions or
>>   wind loading or some such."
>>
>> I suggest you do some reading about those bridges.
> 
> Hold up - those examples show that, in the cases of those bridges (or 
> Tacoma Narrows, at least), the engineers indeed did not consider wind 
> loading!

Maybe you can clear this up then.  I think that's what I wrote or at
least implied I think that's what MG wrote above.  I honestly don't see
where we have a disagreement.

Confusedly,

LR
0
lruss (582)
11/28/2008 7:31:11 PM
James Kanze wrote:

> There are similarities, but testing is not an option for all
> disciplines.  How do you "test" a skyscraper?

They build mathematical models, with the knowledge that since our
knowledge of the physical world is imperfect the models won't work
perfectly. But these are used to come as close as you can with the
scientific knowledge (law?) available. Then you make some physical
models, maybe full size ones, for testing various kinds of things.

I only know this from reading about it in some book long ago, since
besides not being an engineer, I'm not an architect either. ;)

The model I read about was to test for windows leaking in rainstorms.

I'm not sure if they'd still do that today.  Maybe use some CFD code to
check, although more recently, I think Boeing had a bit of a surprise
when an engine they were testing let loose like a flame thrower on
takeoff. The computer models did not predict this. Well, like I said,
our understanding of the physics is imperfect.

There are some other interesting things about building failures
including that they tend to be publicly investigated. Both formally and
informally. People make documentaries about those failures.

Also, I suppose it depends exactly what you are testing the skyscraper
for.  I saw a documentary about how the people who study how groups of
people act during catastrophic events, like fires, or earthquakes build
full scale tiltable models of staircases to see how people will move on
them in various stressful situations.

LR
0
lruss (582)
11/28/2008 7:45:06 PM
Martin Gregorie wrote:
> On Thu, 27 Nov 2008 21:21:01 +0000, Tom Anderson wrote:
> 
>> Oh, absolutely. I'm not knocking the value of qualifications! At least,
>> not all of them. I was just wondering if my lack of them made me a
>> criminal.
>>
> Why on earth would it do that?
> 
> We're not yet /required/ to belong to a professional association like 
> medical doctors.
> 
> 

Are doctors required to belong to a professional association?  May I ask
what jurisdiction you're speaking of.

However, in almost every jurisdiction that I know of where it would
matter, software engineers, actually anyone who calls themselves an
engineer, like doctors, lawyers and hairdressers are required to have a
license.

Am I wrong?

LR
0
lruss (582)
11/28/2008 7:47:12 PM
LR wrote:
> 
> When an engineer designs a bridge, they may for example try to figure
> out how the bridge will react to a given load.  They may try this for
> various loads. The load limit is determined by physics.
> 
> What is the analogous thing for software?
> 
The Roman or medieval bridge builder who pre-dated the discovery of physics?

The Roman or medieval bridge builder was no less of an engineer than
today's bridge builder.  If anything he was more of an engineer because
he didn't have machines to do his donkey work for him.

The physics of software has not been discovered yet, so we still have to
rely in basic engineering and scientific principals to build our
applications.  Maybe every software application has its own set of
physical laws?

-- 
Ian Collins
0
ian-news (10155)
11/28/2008 8:03:08 PM
LR wrote:
> 
> However, in almost every jurisdiction that I know of where it would
> matter, software engineers, actually anyone who calls themselves an
> engineer, like doctors, lawyers and hairdressers are required to have a
> license.
> 
> Am I wrong?
> 
Yes.

-- 
Ian Collins
0
ian-news (10155)
11/28/2008 8:08:32 PM
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-220589287-1227903076=:11338
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 27 Nov 2008, Arne Vajh�j wrote:

> LR wrote:
>> James Kanze wrote:
>>
>>>> I was wondering if you could take a shot at answering what I think is 
>>>> a simple question with what might be a quick answer:  What scientific 
>>>> principle is being applied in "software engineering"?
>>>
>>> Mathematics.
>> 
>> Yeah, that's it then.  Except math is not a science.
>
> Sure is.
>
> It is a formal science and a basis for all the empirical sciences.

I don't consider mathematics a science. The foundation of science is 
experiment: you do experiments, and from the results, you draw conclusions 
about the world. Mathematics does not have experiments. In mathematics, 
you start with some assumptions, and then you use pure logic to work out 
as many conclusions as you can. The kind of knowledge you get from the two 
systems is really very different - they're called a posteriori and a 
priori, respectively.

However, it doesn't follow that mathematics cannot be the basis of 
software engineering. Rather, given that software is a purely mathematical 
thing, which doesn't have physical existence [1], it's pretty obvious that 
mathematics is the *only* thing which could be the basis of software 
engineering.

tom

[1] Really, it doesn't! There are physical realisations of software which 
have material existence, but they aren't software themselves. It's like 
the distinction between a story and a book. You wouldn't argue that the 
making of stories is based on the science of papermaking, would you?

-- 
Would you like to remember more?
---910079544-220589287-1227903076=:11338--
0
twic (2088)
11/28/2008 8:11:16 PM
Martin Gregorie wrote:
> On Thu, 27 Nov 2008 21:13:44 +0000, Tom Anderson wrote:
> 
>> On Thu, 27 Nov 2008, Martin Gregorie wrote:
>>
>>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>>
>>>> Martin Gregorie wrote:
>>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>>
>>>>>> But I think I made it plain that engineers don't consider the entire
>>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>>> wind loading or some such.  The parameters are likely to be driven
>>>>>> by budget, customer requirements or perhaps good practice.
>>>>>>
>>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>>> Narrows bridges ignored wind and look where that got them.
>>>> I'm sorry, but what is quite wrong?  I completely fail to understand
>>>> how your response contradicts anything I wrote above.  Please explain,
>>>> because I utterly bewildered by your response.
>>>>
>>> This:
>>>  "But I think I made it plain that engineers don't consider the entire
>>>   physics of the bridge. They might not consider fluid interactions or
>>>   wind loading or some such."
>>>
>>> I suggest you do some reading about those bridges.
>> Hold up - those examples show that, in the cases of those bridges (or
>> Tacoma Narrows, at least), the engineers indeed did not consider wind
>> loading!
>>
> Exactly so. Look back up this post and you'll see that "LR" said it 
> didn't matter whether bridge designers looked at wind loading or not 
> because the cost of doing the design was a bigger consideration than 
> spending time and money to calculate wind loading. 

I don't think that I said that exactly.

Or perhaps you're jumping to the conclusion that I think this is a good
thing.

The fact remains, engineers do not always, or maybe ever, consider the
full physics of whatever they are designing.  No one has either an
unlimited amount of money, or a perfect understanding of the physical
world, although this can be mitigated by good practice.


> I pointed to two well-
> known failures that were due to the designers ignoring wing factors. He 
> evidently *didn't know* that both blew down because he clearly didn't 
> understand that reply.

I think that you're mistaken about this.  In any case, it would be
peculiar if someone didn't know that Tacoma was a result of a fluids
problem.  I went back and reread what I wrote about the Tay, and I did
say that I thought it might have collapsed under it's own weight and I
agree with you that I was mistaken in that fact.

> You jumped in when I was trying, rather politely I thought, to give "LR" 
> the chance to dig himself out of his self-constructed hole rather than 
> calling him a pig-headed know-nothing. So I won't, but I did want to see 
> what his reply would be.

I have already responded.  I was utterly bewildered by your previous
response and now, if it were possible, I would be even more so.

I think that I'll stand by what I wrote, with the exception of the cause
of the Tay's failure. Since I am still not sure what you understood from
what I posted, please feel free to ask me to amplify or clarify and I
will be happy to make the attempt. Otherwise, I shall be glad to wallow
quite contentedly in my hole.

LR
0
lruss (582)
11/28/2008 8:13:19 PM
Arne Vajh�j wrote:
> LR wrote:
>> courpron@gmail.com wrote:
>>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>>> 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.
>>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>>> proof that the program you've written will halt.  Can you provide that?
>>> Yes, absolutely reliable. The program is proven to be correct in any
>>> way. The proof can be given in the form of mathematical notations.
>> I'm not sure you responded to my question, so please allow me to restate
>> it.  Suppose you have a customer who wants a formal proof that the
>> program you've written will halt, can you provide that?
> 
> Most likely yes.
> 
> Computer science has proven that it is not possible to do that
> for all programs, but it can be done for some programs. If one
> is willing to spend the money, then it can be done for most
> programs.
> 
> (the examples used to prove the haling problem is not
> generally solvable are not very realistic programs)

What is the relevance of their being realistic programs or not?

LR
0
lruss (582)
11/28/2008 8:17:34 PM
Arne Vajhøj wrote:
> LR wrote:
>> Lew wrote:
>>> LR wrote:
>>>> Tom Anderson wrote:
>>>>
>>>>> Still, i call myself a 'software engineer' because it sounds more 
>>>>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>>>>> and academics and the like.
>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>> ask what jurisdiction you do that in?
>>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>>
>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>> you were a PE?
> 
> Software engineer is a widely used title in the US.
> 
> Try search on dice.com or monster.com !

At one time, or so I was told in school, many people believed the world
was flat.  It did not make it so.

LR

0
lruss (582)
11/28/2008 8:18:35 PM
Arne Vajh�j wrote:
> LR wrote:
>> James Kanze wrote:
>>> For some types of
>>> software, at laest.  For real time software, it's less obvious,
>>> since it's fairly hard to be sure that you've analysed all
>>> possible timing issues.  
>> I don't think testing all the possible interactions is possible for most
>> software. Consider a fairly simple program that reads inputs for say 64
>> boolean variables and has at least one conditional branch for each
>> variable.
> 
>  >> But it's still several orders of
>  >> magnitude easier than verifying that you've analysed all
>  >> possible physical interactions which might affect a bridge.
>  >
>  > But that isn't done.  AFAIK ever. I don't think there's enough time in
>  > the universe to do that.  Not even for all the likely cases.
> 
> That is a very unscientific and non-engineering way of
> thinking.

What about this way of thinking is unscientific or non-engineering.  Do

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

Time isn't a factor?


> 
>>>>                                   I was wondering if you
>>>> could take a shot at answering what I think is a simple
>>>> question with what might be a quick answer:  What scientific
>>>> principle is being applied in "software engineering"?
>>> Mathematics.
>> Yeah, that's it then.  Except math is not a science.
> 
> Sure is.
> 
> It is a formal science and a basis for all the empirical
> sciences.

Certainly not what I was taught in school.

LR


0
lruss (582)
11/28/2008 8:20:50 PM
AL wrote:
> LR wrote:
> [...]  But to my mind that would make
>> "software engineering" a unique thing.  Different from say chemical,
>> mechanical or civil. But perhaps there is another branch of engineering
>> that doesn't require the application of scientific principle?
> 
> Perhaps there is.

Perhaps.  Perhaps not.

I was wondering if perhaps someone could point out an instance instead
of referring to the class.

LR
0
lruss (582)
11/28/2008 8:22:03 PM
On Fri, 28 Nov 2008, LR wrote:

> Lew wrote:
>> Martin Gregorie wrote:
>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>> engineering as well as an MSc (Chemistry).
>>
>> Tom Anderson wrote:
>>> But i'm right in thinking that one doesn't need either of those to call
>>> oneself a software engineer, i hope?
>>
>> Absolutely.
>
> What is your understanding of the requirements to call yourself a
> software engineer?

In the UK, there are no requirements. We don't regulate the term 
'engineer' directly, but instead have the specific title of Chartered 
Engineer (we also have Chartered Accountants, Chartered Surveyors, etc), 
which is regulated by a professional society, and which probably has exams 
and rules and all sorts of things.

tom

-- 
Would you like to remember more?
0
twic (2088)
11/28/2008 8:24:02 PM
Kai-Uwe Bux wrote:
> James Kanze wrote:
> 
>> On Nov 28, 1:28 am, Arne Vajh�j <a...@vajhoej.dk> wrote:
>>> Matthias Buelow wrote:
>>>> Lew wrote:
>>>>                                             Also, it is impossible to
>>>> make perfect and totally reliable software.
>>> Not true.
>> I disagree.  It is impossible to make a perfect and totally
>> reliable anything, as long as it is being made by human beings;
>> software is no different.
> 
> You are getting philosophical :-)

In a discussion where people speak of programs being provably able to
halt, excuse me the set of programs that were written to the design of
being provably able to halt, philosophy is perfectly ok.  Well, if the
philosophy is man made, perhaps not perfectly ok. ;)


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

Can a program be perfect? Provably so?  Proof in the sense of
mathematical proof?

However, I note that I've read some stuff recently that suggests that
mathematicians have some doubts about the concept of proof.

LR
0
lruss (582)
11/28/2008 8:29:48 PM
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> LR wrote:
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more 
>>>>>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>>>>>> and academics and the like.
>>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>>> ask what jurisdiction you do that in?
>>>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>>>
>>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>>> you were a PE?
>> Software engineer is a widely used title in the US.
>>
>> Try search on dice.com or monster.com !
> 
> At one time, or so I was told in school, many people believed the world
> was flat.  It did not make it so.

Indeed. One must look at the actual shape of the world to find out
whether the world is flat or not just as one must look at the actual
behavior of speakers of a language to find out what a term means in that
language.

Patricia
0
pats (3556)
11/28/2008 8:30:22 PM
Sabine Dinis Blochberger wrote:
> LR wrote:
[snips]

> 
>
>>> The criteria are different, so you can't apply physical strength to any
>>> project. There is stress testing in software development. 
>> There are viruses and bugs too. Is software development biology?  I
>> don't mean to be flippant, but the mere use of a word doesn't confer
>> meaning on the object it refers to, does it?
>>
> The terms come from when computers were huge, room filling things with
> radio tubes. They would stop working properly when roaches/insects
> entered the structure, hence the term "bugs".
> 
> Computer viruses are called that because of their self-replicating and
> -spreading characteristics.

May I take that as a no?


> 
>>> The
>>> engineering part makes sure the software has been tested for all
>>> possible (and impossible) events/usages.
>> I suspect that this is not even likely.  I gave a counter example else
>> thread involving input for a number of boolean variables, let's say 64.
>>  Tough to test all of those.
>>
> And that's not what a sane person tests. 

No one sane starts a task that can't be completed.




> The example yougive with booleans would be unit-tested, or otherwise at
> a "low" level of development. If you have a GUI with 64 check buttons,
> you really need to rethink that design. 

Wasn't there a recent discussion in this ng about some compiler and the
interactions of it's many flags?

Perhaps that software wasn't "engineered". But I suspect that even if it
was, many of those options would still exist, many of them would
conflict, some of the ways that they'd conflict would cause the software
to fail, some of the failures would be immediately noticable.  Some
would have more interesting consequences.

> If it is settings, then
> they/their effects need to be tested. No way around it.

How many tests do you think could be done every second and how long
would the testing take to complete?


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

Assuming someone has the time to figure that out.  How much time would
it take to do that for 64 inputs?

> 
>>> And AFAIK civil engineers have formulas to calculate physical strengths
>>> and such, that are based on observation and experimentation.
>> They do.  I'm sorry, did I say anything to indicate otherwise? If so,
>> please allow me to withdraw that. Although, I suspect they may not know
>> all there is to know about this yet.  I also note that,  AFAIK, at least
>> some of these are of comparatively recent origin. For example, I think
>> the use of timber in bridges wasn't even reasonably understood until
>> Herman Haupt did the experiments to figure out what the strength of the
>> beams were.
> 
> That doesn't make it less engineering. Even inventors use engineering
> techniques.

I agree that using engineering techniques is not in anyway sufficient to
call an activity engineering.

LR

0
lruss (582)
11/28/2008 8:38:16 PM
James Kanze wrote:
> On Nov 28, 10:35 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
>> James Kanze wrote:
>>> On Nov 28, 1:28 am, Arne Vajh�j <a...@vajhoej.dk> wrote:
>>>> Matthias Buelow wrote:
>>>>> Lew wrote:
>>>>>                                             Also, it is impossible to
>>>>> make perfect and totally reliable software.
> 
>>>> Not true.
> 
>>> I disagree.  It is impossible to make a perfect and totally
>>> reliable anything, as long as it is being made by human beings;
>>> software is no different.
> 
>> You are getting philosophical :-)
> 
> Not really.  Much of what makes engineering engineering is
> deciding just how close to perfect and totally reliable we have
> to be.  Claiming perfection, however, is not responsible
> engineering (software or otherwise).

Is it in math?

LR
0
lruss (582)
11/28/2008 8:39:02 PM
LR wrote:

[snip]
> 
> Can a program be perfect? Provably so?  Proof in the sense of
> mathematical proof?

There are correctness proofs for algorithms, and those proofs are
mathematical proofs. Whether that qualifies as a correctness proof for a
program depends in part on your understanding of the term "program". After
all, programs are to some degree algorithms worded in a programming
language and translated by a compiler on a specific piece of hardware; so
there are many things about which the correctness proof does not talk.


> However, I note that I've read some stuff recently that suggests that
> mathematicians have some doubts about the concept of proof.

Where did you read that? Neither my colleagues nor myself seem to have any
doubt about "the concept of proof". In fact, we devote a huge chunk of our
time to train students to produce exactly that old-fashioned thing called
proof. And I do not see any signs of change.


Best

Kai-Uwe Bux
0
jkherciueh (3186)
11/28/2008 8:43:53 PM
Arne Vajhøj wrote:
> LR wrote:
>> Lew wrote:
>>> Martin Gregorie wrote:
>>>>> Same here: its well recognised in the UK. I hold a CE in software 
>>>>> engineering as well as an MSc (Chemistry).
>>> Tom Anderson wrote:
>>>> But i'm right in thinking that one doesn't need either of those to call 
>>>> oneself a software engineer, i hope?
>>> Absolutely.
>> What is your understanding of the requirements to call yourself a
>> software engineer?
> 
> In most places it is a job title not an academic title or other
> type of certification.
> 
> So in most places the requirements is that a company will give
> you a job with that title.

Are you certain about this?  As I've written else thread, my
understanding is there are legal issues surrounding calling yourself an
engineer of any type.

LR

0
lruss (582)
11/28/2008 8:49:10 PM
Arne Vajh�j wrote:
> LR wrote:
>> OTOH, I've never heard of someone actually being prosecuted for calling
>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>> that if you did something that might be considered to be malpractice
>> whilst calling yourself an engineer things might get interesting.
> 
> If someone design a bridge, it collapses and it turns out he is a
> software engineer with degree in computer science, then I am sure
> all hell will break out.
> 
> But if a software engineer designs a piece of software that crashes
> then I can not imagine him being prosecuted for not having an
> engineering degree in bridge building.


I think it might depend on consequences of the failure and to who and
why it failed.

I think that engineers do sometimes get prosecuted for their failures in
much the same way that physicians do.

I didn't find a specific case, and this isn't proof, but evidence.  A
google(tm) search for engineering malpractice insurance turns up quite a
few hits.


LR
0
lruss (582)
11/28/2008 8:52:29 PM
On Fri, 28 Nov 2008, Martin Gregorie wrote:

> On Thu, 27 Nov 2008 21:13:44 +0000, Tom Anderson wrote:
>
>> On Thu, 27 Nov 2008, Martin Gregorie wrote:
>>
>>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>>
>>>> Martin Gregorie wrote:
>>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>>
>>>>>> But I think I made it plain that engineers don't consider the entire
>>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>>> wind loading or some such.  The parameters are likely to be driven
>>>>>> by budget, customer requirements or perhaps good practice.
>>>>>>
>>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>>> Narrows bridges ignored wind and look where that got them.
>>>>
>>>> I'm sorry, but what is quite wrong?  I completely fail to understand
>>>> how your response contradicts anything I wrote above.  Please explain,
>>>> because I utterly bewildered by your response.
>>>
>>> This:
>>>  "But I think I made it plain that engineers don't consider the entire
>>>   physics of the bridge. They might not consider fluid interactions or
>>>   wind loading or some such."
>>>
>>> I suggest you do some reading about those bridges.
>>
>> Hold up - those examples show that, in the cases of those bridges (or
>> Tacoma Narrows, at least), the engineers indeed did not consider wind
>> loading!
>
> Exactly so. Look back up this post and you'll see that "LR" said it
> didn't matter whether bridge designers looked at wind loading or not

No, he said they might not - and those examples clearly show that in some 
cases they didn't. And why not? Perhaps budget was a factor, as he 
suggests - the client didn't want to pay to have the job done properly.

But as you imply, nobody could reasonably disagree that bridge engineers 
*should* consider wind and water, and i would imagine they almost always 
do.

I think you may have been attaching different meanings to the precise 
words used, that's all.

And now for something completely different - Edsger Dijkstra, writing in 
1993, on why software engineering is "just humbug; from an academic i.e. 
scientific and educational point of view it is a sham, a fraud":

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html

The wikipedia article from which i cribbed that is worth a read:

http://en.wikipedia.org/wiki/Debates_within_software_engineering

tom

-- 
Would you like to remember more?
0
twic (2088)
11/28/2008 8:52:51 PM
LR wrote:
>
> At one time, or so I was told in school, many people believed the
> world was flat.  It did not make it so.

And what you were told might not be true.  Certainly the ancient 
Greeks know the world was round, both from the way that a ship sailing 
towards you from over the horizon becomes visible from the top down, 
and from the fact that the earth's shadow seen during a lunar eclipse 
is curved.  Medieval Europeans knew this too: Columbus's voyage seemed 
risky not because he might fall off the edge, but because the voyage 
was of unknown length.  (And in fact, had the New World not been in 
the way, he almost certainly would have perished in the 
15,000-mile-wide ocean.)

I suppose the larger point stands,though: the fact that many people 
think that the ancients believed the world was flat does not make it 
so.


0
11/28/2008 8:53:26 PM
LR wrote:
> Arne Vajh�j wrote:
>> LR wrote:
>>> courpron@gmail.com wrote:
>>>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>>>> 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.
>>>>> Absolutely reliable? Suppose you have a  customer who wants a formal
>>>>> proof that the program you've written will halt.  Can you provide that?
>>>> Yes, absolutely reliable. The program is proven to be correct in any
>>>> way. The proof can be given in the form of mathematical notations.
>>> I'm not sure you responded to my question, so please allow me to restate
>>> it.  Suppose you have a customer who wants a formal proof that the
>>> program you've written will halt, can you provide that?
>> Most likely yes.
>>
>> Computer science has proven that it is not possible to do that
>> for all programs, but it can be done for some programs. If one
>> is willing to spend the money, then it can be done for most
>> programs.
>>
>> (the examples used to prove the haling problem is not
>> generally solvable are not very realistic programs)
> 
> What is the relevance of their being realistic programs or not?

You asked whether some real world programs could be verified to halt.

The fact that those programs and the programs that can be shown
not to halt are not similar is very relevant.

Arne
0
arne6 (9808)
11/28/2008 8:53:29 PM
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> LR wrote:
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more 
>>>>>> high-status than 'programmer', and i go to a lot of parties with lawyers 
>>>>>> and academics and the like.
>>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>>> ask what jurisdiction you do that in?
>>>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>>>
>>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>>> you were a PE?
>> Software engineer is a widely used title in the US.
>>
>> Try search on dice.com or monster.com !
> 
> At one time, or so I was told in school, many people believed the world
> was flat.  It did not make it so.

No.

People sailed around the globe and proved it was round.

You can prove to yourself that my statement is correct by doing the
search I suggested.

Arne
0
arne6 (9808)
11/28/2008 8:55:06 PM
Tom Anderson wrote:
> On Fri, 28 Nov 2008, LR wrote:
> 
>> Lew wrote:
>>> Martin Gregorie wrote:
>>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>>> engineering as well as an MSc (Chemistry).
>>> Tom Anderson wrote:
>>>> But i'm right in thinking that one doesn't need either of those to call
>>>> oneself a software engineer, i hope?
>>> Absolutely.
>> What is your understanding of the requirements to call yourself a
>> software engineer?
> 
> In the UK, there are no requirements. We don't regulate the term 
> 'engineer' directly, but instead have the specific title of Chartered 
> Engineer (we also have Chartered Accountants, Chartered Surveyors, etc), 
> which is regulated by a professional society, and which probably has exams 
> and rules and all sorts of things.

Ok, that's good to know. Thanks.

LR
0
lruss (582)
11/28/2008 8:58:25 PM
LR wrote:
> Arne Vajh�j wrote:
>> LR wrote:
>>> James Kanze wrote:
>>>> For some types of
>>>> software, at laest.  For real time software, it's less obvious,
>>>> since it's fairly hard to be sure that you've analysed all
>>>> possible timing issues.  
>>> I don't think testing all the possible interactions is possible for most
>>> software. Consider a fairly simple program that reads inputs for say 64
>>> boolean variables and has at least one conditional branch for each
>>> variable.
>>  >> But it's still several orders of
>>  >> magnitude easier than verifying that you've analysed all
>>  >> possible physical interactions which might affect a bridge.
>>  >
>>  > But that isn't done.  AFAIK ever. I don't think there's enough time in
>>  > the universe to do that.  Not even for all the likely cases.
>>
>> That is a very unscientific and non-engineering way of
>> thinking.
> 
> What about this way of thinking is unscientific or non-engineering.

Not distinguishing between what is possible and what is
practical possible.

>> It can be done is most cases. It will not be done in most cases
>> for cost reasons.
> 
> Time isn't a factor?

It can be. In most cases time is just a surrogate for cost.

>>>>>                                   I was wondering if you
>>>>> could take a shot at answering what I think is a simple
>>>>> question with what might be a quick answer:  What scientific
>>>>> principle is being applied in "software engineering"?
>>>> Mathematics.
>>> Yeah, that's it then.  Except math is not a science.
>> Sure is.
>>
>> It is a formal science and a basis for all the empirical
>> sciences.
> 
> Certainly not what I was taught in school.

Possible.

But did you ever notice what a master degree in math is called ?

Arne
0
arne6 (9808)
11/28/2008 8:59:17 PM
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> Martin Gregorie wrote:
>>>>>> Same here: its well recognised in the UK. I hold a CE in software 
>>>>>> engineering as well as an MSc (Chemistry).
>>>> Tom Anderson wrote:
>>>>> But i'm right in thinking that one doesn't need either of those to call 
>>>>> oneself a software engineer, i hope?
>>>> Absolutely.
>>> What is your understanding of the requirements to call yourself a
>>> software engineer?
>> In most places it is a job title not an academic title or other
>> type of certification.
>>
>> So in most places the requirements is that a company will give
>> you a job with that title.
> 
> Are you certain about this?  As I've written else thread, my
> understanding is there are legal issues surrounding calling yourself an
> engineer of any type.

I have already told you how you can verify it (look at job ads sites).

Arne
0
arne6 (9808)
11/28/2008 9:03:14 PM
On Fri, 28 Nov 2008, LR wrote:

> Martin Gregorie wrote:
>> On Thu, 27 Nov 2008 21:21:01 +0000, Tom Anderson wrote:
>>
>>> Oh, absolutely. I'm not knocking the value of qualifications! At least,
>>> not all of them. I was just wondering if my lack of them made me a
>>> criminal.
>>
>> Why on earth would it do that?
>>
>> We're not yet /required/ to belong to a professional association like
>> medical doctors.
>
> Are doctors required to belong to a professional association?

Yes.

http://www.gmc-uk.org/

Although it's a matter of registration with them, rather than membership 
per se.

> May I ask what jurisdiction you're speaking of.

Martin and i are both sited in the UK. As, in his case, his sig makes 
clear.

> However, in almost every jurisdiction that I know of where it would 
> matter, software engineers, actually anyone who calls themselves an 
> engineer, like doctors, lawyers and hairdressers are required to have a 
> license.
>
> Am I wrong?

Yes.

Also, whilst the term is formally regulated in the USA, i don't believe 
the regulation has any teeth in practice.

tom

-- 
Would you like to remember more?
0
twic (2088)
11/28/2008 9:05:16 PM
LR wrote:
> Arne Vajh�j wrote:
>> LR wrote:
>>> OTOH, I've never heard of someone actually being prosecuted for calling
>>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>>> that if you did something that might be considered to be malpractice
>>> whilst calling yourself an engineer things might get interesting.
>> If someone design a bridge, it collapses and it turns out he is a
>> software engineer with degree in computer science, then I am sure
>> all hell will break out.
>>
>> But if a software engineer designs a piece of software that crashes
>> then I can not imagine him being prosecuted for not having an
>> engineering degree in bridge building.
> 
> I think it might depend on consequences of the failure and to who and
> why it failed.

If someone prosecuted a software engineer for not having an
engineering degree in bridge building should have their head
examined by a shrink.

> I think that engineers do sometimes get prosecuted for their failures in
> much the same way that physicians do.
> 
> I didn't find a specific case, and this isn't proof, but evidence.  A
> google(tm) search for engineering malpractice insurance turns up quite a
> few hits.

When I make that search there do not show any hits up about software
engineers being prosecuted for not having an engineering degree in
construction.

So please provide a link to one of your hits.

Arne
0
arne6 (9808)
11/28/2008 9:06:49 PM
On Sat, 29 Nov 2008, Ian Collins wrote:

> LR wrote:
>
>> When an engineer designs a bridge, they may for example try to figure
>> out how the bridge will react to a given load.  They may try this for
>> various loads. The load limit is determined by physics.
>>
>> What is the analogous thing for software?
>
> The Roman or medieval bridge builder who pre-dated the discovery of physics?

Despite what the Civ2 tech tree may say, the building of bridges by Romans 
and medievals was not done without the aid of physics. Indeed, the 
mechanics needed to build bridges, siege engines, and other such staples 
of the ancient world was well advanced in classical Greece. They didn't 
have calculus, or quite such an integrated picture of physics, but they 
had plenty of quantitative rules.

> The Roman or medieval bridge builder was no less of an engineer than
> today's bridge builder.  If anything he was more of an engineer because
> he didn't have machines to do his donkey work for him.

The Greeks built tools to calculate cube roots, which were essential to 
the design of those big spear-throwing siege engines - oxybeles, i seem to 
remember they're called.

Although the mathematics they used was empirical, rather than being based 
on theory.

> The physics of software has not been discovered yet, so we still have to 
> rely in basic engineering and scientific principals to build our 
> applications.

Perhaps. There may well be a theoretical breakthrough somewhere up ahead.

> Maybe every software application has its own set of physical laws?

If so, i don't think they'd qualify as laws, would they?

tom

-- 
Would you like to remember more?
0
twic (2088)
11/28/2008 9:42:52 PM
LR wrote:

> AL wrote:

>> LR wrote:

>> [...]  But to my mind that would make
>>> "software engineering" a unique thing.  Different from say chemical,
>>> mechanical or civil. But perhaps there is another branch of engineering
>>> that doesn't require the application of scientific principle?

>> Perhaps there is.

> Perhaps.  Perhaps not.
> I was wondering if perhaps someone could point out an instance instead
> of referring to the class.
> 
> LR


deflecting - you've cornered yourself and now you are deflecting...



You posed, "perhaps there is another branch of engineering that doesn't
require the application of scientific principle" which equates to a 
meaning of engineering that is not consistent with your narrow
inflexible definition.

Look up definitions in the dictionary and you will find multiple
definitions for most any given word. Use a dictionary 100yrs old and you
will not unnecessarily find the same definitions found in a modern
dictionary and you will even find new words. It may be that not everyone 
appreciates the new definitions, I remember my grade school teacher's 
response when "ain't" was legitimized by Webster, but there they are.

0
lithar (20)
11/28/2008 10:07:52 PM
Tom Anderson wrote:
> On Sat, 29 Nov 2008, Ian Collins wrote:
> 
>> LR wrote:
>>
>>> When an engineer designs a bridge, they may for example try to figure
>>> out how the bridge will react to a given load.  They may try this for
>>> various loads. The load limit is determined by physics.
>>>
>>> What is the analogous thing for software?
>>
>> The Roman or medieval bridge builder who pre-dated the discovery of
>> physics?
> 
> Despite what the Civ2 tech tree may say, the building of bridges by
> Romans and medievals was not done without the aid of physics. Indeed,
> the mechanics needed to build bridges, siege engines, and other such
> staples of the ancient world was well advanced in classical Greece. They
> didn't have calculus, or quite such an integrated picture of physics,
> but they had plenty of quantitative rules.
> 
Which is probably where software engineering is now.

>> The Roman or medieval bridge builder was no less of an engineer than
>> today's bridge builder.  If anything he was more of an engineer because
>> he didn't have machines to do his donkey work for him.
> 
> The Greeks built tools to calculate cube roots, which were essential to
> the design of those big spear-throwing siege engines - oxybeles, i seem
> to remember they're called.
> 
> Although the mathematics they used was empirical, rather than being
> based on theory.
> 
Which is probably where software engineering is now.

>> Maybe every software application has its own set of physical laws?
> 
> If so, i don't think they'd qualify as laws, would they?
> 
Why not? For all we know, there might be an infinite number of parallel
universes each with their own set of physical laws.

-- 
Ian Collins
0
ian-news (10155)
11/28/2008 10:15:54 PM
Kai-Uwe Bux wrote:
> LR wrote:

>> However, I note that I've read some stuff recently that suggests that
>> mathematicians have some doubts about the concept of proof.
> 
> Where did you read that? Neither my colleagues nor myself seem to have any
> doubt about "the concept of proof". In fact, we devote a huge chunk of our
> time to train students to produce exactly that old-fashioned thing called
> proof. And I do not see any signs of change.


I have to apologize. I should have said that I can't remember where I
read it, but I do remember reading it. It might have been in a popular
science type of magazine or maybe at the link below. If it helps at all,
I think the concern was in part about complexity and in part about the
fundamental ability to prove something, but I wouldn't come close to
saying that I understood it. I do apologize again for not having
mentioned before that I can't remember where I read it.

It might have been here, but the full article seems unavailable, so I'm
not sure.
http://www.economist.com/science/displaystory.cfm?story_id=E1_PRDJGGT

LR
0
lruss (582)
11/28/2008 10:43:41 PM
Tom Anderson wrote:
> On Fri, 28 Nov 2008, Martin Gregorie wrote:
> 
>> On Thu, 27 Nov 2008 21:13:44 +0000, Tom Anderson wrote:
>>
>>> On Thu, 27 Nov 2008, Martin Gregorie wrote:
>>>
>>>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>>>
>>>>> Martin Gregorie wrote:
>>>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>>>
>>>>>>> But I think I made it plain that engineers don't consider the entire
>>>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>>>> wind loading or some such.  The parameters are likely to be driven
>>>>>>> by budget, customer requirements or perhaps good practice.
>>>>>>>
>>>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>>>> Narrows bridges ignored wind and look where that got them.
>>>>> I'm sorry, but what is quite wrong?  I completely fail to understand
>>>>> how your response contradicts anything I wrote above.  Please explain,
>>>>> because I utterly bewildered by your response.
>>>> This:
>>>>  "But I think I made it plain that engineers don't consider the entire
>>>>   physics of the bridge. They might not consider fluid interactions or
>>>>   wind loading or some such."
>>>>
>>>> I suggest you do some reading about those bridges.
>>> Hold up - those examples show that, in the cases of those bridges (or
>>> Tacoma Narrows, at least), the engineers indeed did not consider wind
>>> loading!
>> Exactly so. Look back up this post and you'll see that "LR" said it
>> didn't matter whether bridge designers looked at wind loading or not
> 
> No, he said they might not - and those examples clearly show that in some 
> cases they didn't. And why not? Perhaps budget was a factor, as he 
> suggests - the client didn't want to pay to have the job done properly.
> 
> But as you imply, nobody could reasonably disagree that bridge engineers 
> *should* consider wind and water, and i would imagine they almost always 
> do.
> 
> I think you may have been attaching different meanings to the precise 
> words used, that's all.

As I said elsethread and acknowledge again, I was wrong in part.

> 
> And now for something completely different - Edsger Dijkstra, writing in 
> 1993, on why software engineering is "just humbug; from an academic i.e. 
> scientific and educational point of view it is a sham, a fraud":
> 
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html

I liked part of that, but what's a "mathematical engineer"?


> 
> The wikipedia article from which i cribbed that is worth a read:
> 
> http://en.wikipedia.org/wiki/Debates_within_software_engineering

"Texas even goes so far as to ban anyone from writing any real-time code
without an engineering license." I smell a First Amendment case.  (For
those of you who aren't in the US, sorry, that's a free speech issue.)

Thanks for those links, fascinating.

LR
0
lruss (582)
11/28/2008 10:56:49 PM
On 2008-11-28, LR <lruss@superlink.net> wrote:
>
> No one sane starts a task that can't be completed.

Science itself is a task that can't be completed. How, then, would you
reconcile the above with the idea that engineering should be based on
science?

Cheers,
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
11/28/2008 10:57:59 PM
Arne Vajh�j <arne@vajhoej.dk> wrote:
> Daniel T. wrote:
> > Arne Vajh�j <arne@vajhoej.dk> wrote:
> > > Matthias Buelow wrote:

> > ... I think [Arne's] conception of what constitutes "engineering"
> > in the software sense is probably too exclusive. In construction,
> > the engineers design the structure then pass it off to the
> > builders who then build it to spec. For software, the "builders"
> > are the compiler, linker, and runtime environment. The writing of
> > the code is part of the design processes.
> 
> It is sometimes difficult to find a 100% matching analogy.
> 
> If a project do extremely detailed design, then I will consider
> writing the actual code part of building.
> 
> And it fits with:
> - it is very unlikely that a compiler turns good source code
>    into bad binary code
> - it happen that a builder mess up a good blueprint
> - it happen that the programmer writing the code
>    mess up a good design

A draftsman can mess up a good blueprint too. I don't think that is 
relvelent.

> But very few projects do detailed design to make writing
> the code pure building. It is often a mix of lowel level
> design and building.

Writing the code is never "pure building", if it were then tools would 
be doing it. Writing the code is, as you put it "low level design", 
i.e., it is part of the design phase.
0
daniel_t (1960)
11/28/2008 11:04:08 PM
Arne Vajh�j wrote:
> LR wrote:
>> Arne Vajh�j wrote:
>>> LR wrote:
>>>> OTOH, I've never heard of someone actually being prosecuted for calling
>>>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>>>> that if you did something that might be considered to be malpractice
>>>> whilst calling yourself an engineer things might get interesting.
>>> If someone design a bridge, it collapses and it turns out he is a
>>> software engineer with degree in computer science, then I am sure
>>> all hell will break out.
>>>
>>> But if a software engineer designs a piece of software that crashes
>>> then I can not imagine him being prosecuted for not having an
>>> engineering degree in bridge building.
>> I think it might depend on consequences of the failure and to who and
>> why it failed.
> 
> If someone prosecuted a software engineer for not having an
> engineering degree in bridge building should have their head
> examined by a shrink.
> 
>> I think that engineers do sometimes get prosecuted for their failures in
>> much the same way that physicians do.
>>
>> I didn't find a specific case, and this isn't proof, but evidence.  A
>> google(tm) search for engineering malpractice insurance turns up quite a
>> few hits.
> 
> When I make that search there do not show any hits up about software
> engineers being prosecuted for not having an engineering degree in
> construction.

I didn't say that it would turn up hits for "software engineers".  The
context didn't demand that it would. This part of the discussion was
about liability for engineers. My preface to the search was about
engineers in general.

> So please provide a link to one of your hits.

They can be found. It's not very hard. Add software or maybe "software
engineer" to the above list.  And no, I don't accept this as evidence
that software development is an engineering discipline.  Perhaps the
insurance industry uses the expression as a term of art.

LR

0
lruss (582)
11/28/2008 11:06:35 PM
LR wrote:
> Arne Vajh�j wrote:
>> LR wrote:
>>> Arne Vajh�j wrote:
>>>> LR wrote:
>>>>> OTOH, I've never heard of someone actually being prosecuted for calling
>>>>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>>>>> that if you did something that might be considered to be malpractice
>>>>> whilst calling yourself an engineer things might get interesting.
>>>> If someone design a bridge, it collapses and it turns out he is a
>>>> software engineer with degree in computer science, then I am sure
>>>> all hell will break out.
>>>>
>>>> But if a software engineer designs a piece of software that crashes
>>>> then I can not imagine him being prosecuted for not having an
>>>> engineering degree in bridge building.
>>> I think it might depend on consequences of the failure and to who and
>>> why it failed.
>> If someone prosecuted a software engineer for not having an
>> engineering degree in bridge building should have their head
>> examined by a shrink.
>>
>>> I think that engineers do sometimes get prosecuted for their failures in
>>> much the same way that physicians do.
>>>
>>> I didn't find a specific case, and this isn't proof, but evidence.  A
>>> google(tm) search for engineering malpractice insurance turns up quite a
>>> few hits.
>> When I make that search there do not show any hits up about software
>> engineers being prosecuted for not having an engineering degree in
>> construction.
> 
> I didn't say that it would turn up hits for "software engineers".  The
> context didn't demand that it would. This part of the discussion was
> about liability for engineers. My preface to the search was about
> engineers in general.

No - you replied to:

#But if a software engineer designs a piece of software that crashes
#then I can not imagine him being prosecuted for not having an
#engineering degree in bridge building.

It would make your arguments a little easier to follow if
you replies actually are intended for what you technically
reply to.

Whether engineers responsible for a bridge collapse can
be prosecuted is not relevant in this subthread and as far
as I can tell not particular relevant for the thread at all.

Arne
0
arne6 (9808)
11/28/2008 11:13:18 PM
Daniel T. wrote:
> Arne Vajh�j <arne@vajhoej.dk> wrote:
>> Daniel T. wrote:
>>> Arne Vajh�j <arne@vajhoej.dk> wrote:
>>>> Matthias Buelow wrote:
> 
>>> ... I think [Arne's] conception of what constitutes "engineering"
>>> in the software sense is probably too exclusive. In construction,
>>> the engineers design the structure then pass it off to the
>>> builders who then build it to spec. For software, the "builders"
>>> are the compiler, linker, and runtime environment. The writing of
>>> the code is part of the design processes.
>> It is sometimes difficult to find a 100% matching analogy.
>>
>> If a project do extremely detailed design, then I will consider
>> writing the actual code part of building.
>>
>> And it fits with:
>> - it is very unlikely that a compiler turns good source code
>>    into bad binary code
>> - it happen that a builder mess up a good blueprint
>> - it happen that the programmer writing the code
>>    mess up a good design
> 
> A draftsman can mess up a good blueprint too. I don't think that is 
> relvelent.

I think that was what I wrote. And i think it is very relevant.

>> But very few projects do detailed design to make writing
>> the code pure building. It is often a mix of lowel level
>> design and building.
> 
> Writing the code is never "pure building", if it were then tools would 
> be doing it. Writing the code is, as you put it "low level design", 
> i.e., it is part of the design phase.

No.

You argue that not fully automated means design.

That is obviously not true.

Else the brick layer would be designing the building.

Building engineering has not invented a widely used machine
for laying bricks.

Software engineering has not invented a widely used program
for generating executables from models (MDA tools exist but
are not widely used).

Arne
0
arne6 (9808)
11/28/2008 11:16:03 PM
AL wrote:
> LR wrote:
> 
>> AL wrote:
> 
>>> LR wrote:
> 
>>> [...]  But to my mind that would make
>>>> "software engineering" a unique thing.  Different from say chemical,
>>>> mechanical or civil. But perhaps there is another branch of engineering
>>>> that doesn't require the application of scientific principle?
> 
>>> Perhaps there is.
> 
>> Perhaps.  Perhaps not.
>> I was wondering if perhaps someone could point out an instance instead
>> of referring to the class.
>>
>> LR
> 
> 
> deflecting - you've cornered yourself and now you are deflecting...

Can you name an instance?


> You posed, "perhaps there is another branch of engineering that doesn't
> require the application of scientific principle" which equates to a 
> meaning of engineering that is not consistent with your narrow
> inflexible definition.


I did pose that, since I wondered if there is an example counter to my
belief about what engineering is. Was I unclear? I'm not sure that I
understand your point.


Can you name an instance?


> Look up definitions in the dictionary and you will find multiple
> definitions for most any given word. 

I'll start with the word cleave. ;)

> Use a dictionary 100yrs old and you
> will not unnecessarily find the same definitions found in a modern
> dictionary and you will even find new words. 

"new words"?  Meaning? Words I am unfamiliar with?  Old words that don't
see much current usage?  New to me? I'm not sure that I take your
meaning of the word new in this context.

> It may be that not everyone
> appreciates the new definitions, I remember my grade school teacher's 
> response when "ain't" was legitimized by Webster, but there they are.

Then why would anyone bother to disagree with me?

LR


0
lruss (582)
11/28/2008 11:18:50 PM
On Nov 28, 12:55 pm, LR <lr...@superlink.net> wrote:
> James Kanze wrote:
> > On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
> >> But perhaps there is another branch of engineering that
> >> doesn't require the application of scientific principle?
>
> > They all do, including software engineering.  That's part of
> > what makes them engineering.
>
> I reiterate, which scientific law is being applied in the creation of
> software? In the way, for example that a civil engineer would apply f=ma
> while building a bridge or a mech engineer would apply it while
> designing a pressure vessel?

I already provided you with several examples off-the-cuff.
Perhaps you missed them the first time; here they are again:

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

Since scientific principles are applied regularly in software
engineering I'm mystified as to why others in this thread are
having such a hard time providing simple specific examples as
the above. Perhaps well trained software engineers are more
rare than I realized.

Below is a dictum of mine, that is germane here and provides
clearer understanding of the duality between and the purpose
of science and engineering:

   "Science applies control to pursue knowledge.
    Engineering applies knowledge to pursue control."

KHD

0
duggar (292)
11/28/2008 11:29:25 PM
Keith H Duggar wrote:

Sorry I'm so late responding to this.

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

I'm not familiar with most of these and I had to look  most of them up.
 I'm still in the process of looking some of them up. I am unfortunately
pressed for time so I regret that I can't give each of these the
attention they deserve. So briefly, very briefly:
> 
> Principle of Induction
Looks like logic.


> Pigeonhole Principle
Looks like math.


> Information Principle
I'm not sure what this means.


> Chebyshev's Inequality
Math. Probablity theory.


> Akra-Bazzi Theorem
Math.


> Divide-and-Conquer
I think this is math.  The articles I find online define it as being an
algorithm design paradigm in computer science.


> Dynamic Programming
From the wikipedia article: "In mathematics and computer science,
dynamic programming..." Math.


> Sieve Principle
Math.

> Occam's Razor
Logic.  Used by scientists, but not science itself.


> Murphy's Law
Ok, perhaps you got me.  But it's not, I don't think, a scientific law
or principle. Maybe it should be. Or you haven't offered proof of the
law, or shown how it's applied to the production of software.

I'm certain that I've overlooked some obvious point or made some
mistake.  Please feel free to point those out.


I seem to have metaphorically misplaced the post, but think I saw
someone else mention Shannon and Information Theory and in the hope that
no one minds, I'll respond here.

I think that IT might come pretty close. It does seem to use math to
describe a physical phenomenon. Border line perhaps.  But I don't know
anyone who uses IT to produce code.  They might write apps that
implement some part of an algorithm that involves IT, but not apply it
to the actual production of code, in the way that an engineer will
consider f=ma (or f=mv per James Kanze) when deciding how strong to make
a bridge.  I wouldn't say that I understand it very well.  To me it
looks like it might be of more value to electrical engineers in terms of
application.

But it's something to consider.  How might it be applied to the
production of code?

LR






0
lruss (582)
11/28/2008 11:59:50 PM
Tommy <plas@dacxsee.com> wrote:
> Daniel T. wrote:
> > Tommy <plas@dacxsee.com> wrote:
> >> Tom Anderson wrote:

> ... at the end of the day, considering the topic (who gets a 
> higher salary among Java, C++), one who attempts to cover the gambit 
> or believes the better pay will come by self-proclaiming to be a 
> "Software Engineer" in his resume, better have the credentials and 
> experience to back it up.  A CE degree is nice, but it must also be 
> coupled with practical experience. 

Agreed. A CE degree is nice but ultimately not relevant IMHO. A kid 
fresh out of college simply is not going to make a good Software 
Engineer, he's got too much to unlearn first. Experience is the best 
teacher.

> When I talking to potential hire, 
> a good clue that the person has promise is when he tells me he can't 
> live without his white board. :-)

I never use the damn things. Hate them. I do keep a pad of graph paper 
on my desk at all times though. :-) When a coder tells me he likes to 
keep the lights off, that tells me he believes the only thing that is 
important is that which is on the screen. Big mistake IMHO.

> He would be just as well calling himself a "Software Developer", or 
> Project Developer or Product Developer.
> 
> The former tells me he has R&D experience, design experience. The 
> latter tells me he has production, QA, customer relations, even 
> possible technical sales and support experiences.
> 
> Grant it, with today smarter tools, IDEs, etc, the many traditional 
> disciplines have merged. That was the intent - not only to increase 
> productivity, but to lower the cost of expertise requirements, 
> increase output without increasing staff.  If a developer wants to say 
> he is Software Engineer because he uses these tools, even created 
> tools, has experience with all the current languages, he might get 
> hired, but not a SE pay scale. If he can put start a project from 
> start to finish, create functional specs, communicate with others to 
> fine tine it without writing a single line of code, then he/she may 
> deserve the pay, but then again he probably won't be looking at a 
> programming position. :-)

IMHO, if he thinks he can take a project from start to finish, create 
functional specs, communicate with others and define completion dates 
without writing a single line of code, he's a danger to the project.
0
daniel_t (1960)
11/29/2008 12:04:22 AM
LR wrote:

> Keith H Duggar wrote:
> 
> Sorry I'm so late responding to this.
> 
>> Software Engineering is replete with scientific principles.
>> Here are but a few off the top of my head:
> 
> I'm not familiar with most of these and I had to look  most of them up.
>  I'm still in the process of looking some of them up. I am unfortunately
> pressed for time so I regret that I can't give each of these the
> attention they deserve. So briefly, very briefly:
>> 
>> Principle of Induction
> Looks like logic.
> 
> 
>> Pigeonhole Principle
> Looks like math.
> 
> 
>> Information Principle
> I'm not sure what this means.
> 
> 
>> Chebyshev's Inequality
> Math. Probablity theory.
> 
> 
>> Akra-Bazzi Theorem
> Math.
> 
> 
>> Divide-and-Conquer
> I think this is math.  The articles I find online define it as being an
> algorithm design paradigm in computer science.
> 
> 
>> Dynamic Programming
> From the wikipedia article: "In mathematics and computer science,
> dynamic programming..." Math.
> 
> 
>> Sieve Principle
> Math.
> 
>> Occam's Razor
> Logic.  Used by scientists, but not science itself.
[snip]

a) There is some tension about where to put math. Some place it with the
sciences, others don't. All agree that it is somewhat different. On the
other hand, each science in itself seems to be different from the others.

b) Looking for physical, chemical, or biological knowledge in programs, you
will find that there is quite a few programs that incorporate exactly that.
E.g., the software that NASA uses to guide space probes to other planets
clearly incorporates a lot of Newtonean mechanics. There are programs to
compute orbitals for molecules. Those programs embed quantum mechanics to a
large degree (although most of the program is probably devoted to top-notch
techniques of number crunching and PDE solving).

Similarly, much of the software of today is embedded in devices. If you
drive a modern car, chances are that the anti blocking system for your
brakes has a computer chip somewhere. The software therein probably
benefits a lot from physical knowledge about breaking.

Any sort of knowledge will find its way into software (e.g., software for
transactions between banks incorporates much knowledge about the particular
kinds of transactions involved). Scientific principles are no exception.


Best

Kai-Uwe Bux
0
jkherciueh (3186)
11/29/2008 12:11:46 AM
LR wrote:
> AFAIK, calling yourself an engineer without the license is illegal in
> many jurisdictions, although, I don't know what the penalty is and I
> really do with to emphasize this, IANAL.

One can call oneself a "software engineer" if one wants in the U.S., thanks to
the First Amendment.  One might be restricted in engaging in certain
activities that require a licensed engineer in the states that have
such requirements, but that has nothing to do with calling oneself one.

One can call oneself "God" if one wants for the same reason.

-- 
Lew
0
lew (2468)
11/29/2008 12:33:35 AM
Tim Roberts wrote:
> The fact that it is widely used does not mean that it is CORRECTLY used.
> There are many states in which it is illegal to call yourself an "engineer"
> of any kind unless you have received an engineering license from the state,

Which ones?

> and those license examinations often involve topics in which a software
> engineer has no training.

If you are speaking of the United States, one has the First Amendment right to
call oneself whatever one likes.  I can call myself President of the United
States or God, should I so choose.  (Since no one agrees on what or if God is,
that last one has no conceivable actionable consequences at law.)

What one calls one's profession or business may, of course, be a different matter.

-- 
Lew
0
lew (2468)
11/29/2008 12:34:08 AM
Joshua Cranmer wrote:
>> 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).

jebblue wrote:
> It doesn't even compile.

s/?/Foo/g

-- 
Lew
0
lew (2468)
11/29/2008 12:34:54 AM
Lew wrote:
> LR wrote:
>> AFAIK, calling yourself an engineer without the license is illegal 
>> in
>> many jurisdictions, although, I don't know what the penalty is and 
>> I
>> really do with to emphasize this, IANAL.
>
> One can call oneself a "software engineer" if one wants in the U.S.,
> thanks to the First Amendment.

It's not quite that simple.  One can't falsely call oneself a "medical 
doctor" or "police officer" and, when challenged by legal authority, 
simply point to the Bill of Rights. 


0
11/29/2008 12:45:11 AM
Mike Schilling wrote:
> Lew wrote:
>> LR wrote:
>>> AFAIK, calling yourself an engineer without the license is illegal 
>>> in
>>> many jurisdictions, although, I don't know what the penalty is and 
>>> I
>>> really do with to emphasize this, IANAL.
>> One can call oneself a "software engineer" if one wants in the U.S.,
>> thanks to the First Amendment.
> 
> It's not quite that simple.  One can't falsely call oneself a "medical 
> doctor" or "police officer" and, when challenged by legal authority, 
> simply point to the Bill of Rights. 

Sure, one can.  One just cannot engage in acts that require that one 
legitimately be a medical doctor or police officer.

I could walk into a bar and tell a girl with a fetish for policemen that I am 
a police officer, and I have broken no law.

-- 
Lew
0
lew (2468)
11/29/2008 12:53:59 AM
Mike Schilling wrote:
> Lew wrote:
>> LR wrote:
>>> AFAIK, calling yourself an engineer without the license is illegal 
>>> in
>>> many jurisdictions, although, I don't know what the penalty is and 
>>> I
>>> really do with to emphasize this, IANAL.
>> One can call oneself a "software engineer" if one wants in the U.S.,
>> thanks to the First Amendment.
> 
> It's not quite that simple.  One can't falsely call oneself a "medical 
> doctor" or "police officer" and, when challenged by legal authority, 
> simply point to the Bill of Rights. 

I think that is correct.

But that does not apply to Engineer or Software Engineer.

Claiming to be a Professional Engineer without a license in
the state would not be allowed.

Arne
0
arne6 (9808)
11/29/2008 1:03:10 AM
Lew wrote:
> Mike Schilling wrote:
>> Lew wrote:
>>> LR wrote:
>>>> AFAIK, calling yourself an engineer without the license is illegal in
>>>> many jurisdictions, although, I don't know what the penalty is and I
>>>> really do with to emphasize this, IANAL.
>>> One can call oneself a "software engineer" if one wants in the U.S.,
>>> thanks to the First Amendment.
>>
>> It's not quite that simple.  One can't falsely call oneself a "medical 
>> doctor" or "police officer" and, when challenged by legal authority, 
>> simply point to the Bill of Rights. 
> 
> Sure, one can.  One just cannot engage in acts that require that one 
> legitimately be a medical doctor or police officer.
> 
> I could walk into a bar and tell a girl with a fetish for policemen that 
> I am a police officer, and I have broken no law.

First, I think that is walking a very thin line if it ends up in court.

Second, it is not particular relevant for the discussion, since
that is about using the title software engineer not to impress girls
(I doubt they will be impressed by that title but ...) but for work.

Arne
0
arne6 (9808)
11/29/2008 1:06:01 AM
Lew wrote:
>> I could walk into a bar and tell a girl with a fetish for policemen 
>> that I am a police officer, and I have broken no law.

Arne Vajhøj wrote:
> First, I think that is walking a very thin line if it ends up in court.

It would only end up in court if one engaged in the activities reserved for 
legitimate policemen.  To date, impressing girls in bars by lying about your 
profession is not illegal, at least not where the U.S. Constitution prevails.

> Second, it is not particular relevant for the discussion, since
> that is about using the title software engineer not to impress girls
> (I doubt they will be impressed by that title but ...) but for work.

That, too, would only end up in court if one engaged in activities that 
required that one be a licensed software engineer.  It is entirely relevant.

-- 
Lew
0
lew (2468)
11/29/2008 1:14:28 AM
Lew wrote:
> Lew wrote:
>>> I could walk into a bar and tell a girl with a fetish for policemen 
>>> that I am a police officer, and I have broken no law.
> 
> Arne Vajhøj wrote:
>> First, I think that is walking a very thin line if it ends up in court.
> 
> It would only end up in court if one engaged in the activities reserved 
> for legitimate policemen.  To date, impressing girls in bars by lying 
> about your profession is not illegal, at least not where the U.S. 
> Constitution prevails.
> 
>> Second, it is not particular relevant for the discussion, since
>> that is about using the title software engineer not to impress girls
>> (I doubt they will be impressed by that title but ...) but for work.
> 
> That, too, would only end up in court if one engaged in activities that 
> required that one be a licensed software engineer.  It is entirely 
> relevant.

Not really.

It is not the first amendment that is important here, but the
fact that the state has not made software engineer something
that requires a certificate by state board and has not made
software engineering something that requires a certfied
software engineer.

Arne
0
arne6 (9808)
11/29/2008 1:18:49 AM
Tim Roberts <timr@probo.com> wrote:
> 
> I don't drive over a bridge blueprint.  The blueprint is the design
> document.  The bridge is engineered.  With software, that
> "hand-crafted" artistry is exactly what I am driving on.

No, the code isn't what you are "driving on," that's my point. You don't 
use C++/Java code when you are writing a document in MSWord/OpenOffice. 
The code is a design that the compiler/interpreter uses to create the 
program that the user ultimately runs. Our construction process is 
automated, but that doesn't mean it's non-existent, and it doesn't mean 
that something we are doing just before construction starts is part of 
the construction itself.
0
daniel_t (1960)
11/29/2008 1:32:13 AM
"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:Pine.LNX.4.64.0811261713040.14016@urchin.earth.li...
> On Tue, 25 Nov 2008, LR wrote:
>
>> Tom Anderson wrote:
>>
>>> Still, i call myself a 'software engineer' because it sounds more
>>> high-status than 'programmer', and i go to a lot of parties with lawyers
>>> and academics and the like.
>>
>> IANAL, but since you're calling yourself a "software engineer" might I 
>> ask what jurisdiction you do that in?
>
> In the UK.
>
> tom

In Canada I have never encountered any programmer who calls themselves a 
software engineer. We're not allowed to.

Over and above my actual degree, I've taken a Certificate in Software 
Engineering from DalTech (it used to be Technical University of Nova 
Scotia), and this consisted of 6 courses: project management, human 
resources mgmt, quality control/assurance/testing, requirements analysis, 
design, and maintenance. None of this is covered in a CS degree, and I'm not 
saying it should be. However, if people felt strongly enough about having 
software engineers in Canada, I'd support a requirement for formal education 
in topics like the above. I'd also add software/systems security as a 
course.

Way back when I did most of a B.Eng. after finishing my B.Sc, before 
realizing I really, really didn't want to be an electrical engineer. Having 
said that, it became clear to me that there was nothing in the typical 
engineering curriculum that sets a person up to be more of an "engineer" 
than someone studying CS or physics or chemistry...what really does it is 
the mentored work experience and professional examinations. In fact (at 
least in NS) you don't need an engineering degree to become an engineer - 
you just need enough years experience doing an engineer's job, and pass the 
exams.

My personal feeling about "software engineers" is that if it's a title we 
want to have, we should have equivalent standards to other engineers. 
Require courses like the ones I mentioned. Make sure - perhaps through the 
professional exams - that the aspirant really knows core CS. Have an 
engineer-in-training period (in NS it's 4 years) where you are mentored and 
observed, and your work experience is assessed.

Is there value to this? I think there is. One of the reasons for having 
professional accreditation (the other big one being public safety) is the 
assurance of reasonable competency. Right now in software development you 
really don't know what you're getting.

Do all software developers need to be engineers (Assuming such schemes were 
adopted)? Probably not. In fact I think few would be. A number of IT jobs 
could likely be done by technicians, although the technicians themselves 
would be accredited (perhaps two year programmes of study) and also have 
work experience before being certified. But probably most software 
development would continue to be done by individuals who have no 
accreditation. The main difference would be that safety-critical software 
would require professional software engineers and technicians, and also that 
any client could demand that as they saw fit.

I personally don't much care. I just don't like seeing the title used unless 
you really are one. And it's not a title that you award to yourself, I'm 
afraid.

AHS 


0
asandstrom (223)
11/29/2008 1:52:12 AM
Arne Vajh�j <arne@vajhoej.dk> wrote:

> You argue that not fully automated means design.
> 
> That is obviously not true.

No, I argue that C++/Java programmers do help design the application.

> Else the brick layer would be designing the building.

The brick layer only has a job because automated tools are more 
expensive than him. If it were cheeper to have a human being take 
C++/Java code and create machine language/bytecode, we wouldn't be using 
automated tools. But I would still say that the builder (i.e., the one 
who takes the code that we write and turns it into the program that the 
user runs) is not designing, while the person who decides exactly what 
the program will do in a given situation is.

What I'm saying is that the decision makers are the designers, it isn't 
possible for a non-programmer to make all the decisions a programmer 
needs to make, and those decisions are vital for correct code.

We are not mere assembly line workers, no matter how hard corporations 
try to put us in that role. The programmers' experience, attitudes and 
biases will dramatically affect the design, and eventual effectiveness 
of the application.

I'll take another tack... A finished product, whether it's a bridge, 
building, or application is complete and not amiable to modification 
(except in ways that were specifically designed into it.)

A design for a product is amiable to modification. Parts of the design 
can be lifted out and used independently of the product in question. 
Beauty can be found in a design, independent of the product that the 
design produces. All these aptly describe C++/Java code.
0
daniel_t (1960)
11/29/2008 1:57:23 AM
Kai-Uwe Bux wrote:
> LR wrote:

> a) There is some tension about where to put math. 

I didn't think so, but this thread has clarified that for me.

> Some place it with the sciences, others don't.

I don't.  I tend to think of science as dealing with physical phenomena
and math dealing with, for lack of a better word, abstraction.

I suppose there's some meta-argument about math being a physical
phenomena itself, which might be very interesting and even useful in
some contexts, but maybe not this one.

> All agree that it is somewhat different. On the
> other hand, each science in itself seems to be different from the others.

I'm not sure that I agree with that.  All of the sciences are subject to
the same physical laws, aren't they? Even if we don't understand those
laws?  Even if the ideas in some of them are somewhat unrealistic and
abstract models themselves?  Like say the concept of an electron as a
particle, useful in some contexts, pointless in others?  The ideas in
science still have their purpose as a referent to the physical world.
And if they appear to differ, maybe that difference is in the models
that the scientists in each field use, their mental shorthand?  But I
certainly believe if a difference between two fields of science
manifested itself as an inconsistency, science as a whole could not
tolerate that situation, it would have to be corrected.

I don't think that math is the same as this.


> b) Looking for physical, chemical, or biological knowledge in programs, you
> will find that there is quite a few programs that incorporate exactly that.

I find that I have a tremendous amount of trouble communicating the
particular idea I am trying to explain here.

I do not debate that people create applications that calculate things
about the physical world.

But I haven't run into an example of them using some law (principle, or
whatever word we'd choose for this concept) of science to create the
software itself, the way an engineer applies physics to build a bridge.

> E.g., the software that NASA uses to guide space probes to other planets
> clearly incorporates a lot of Newtonean mechanics.There are programs to
> compute orbitals for molecules. Those programs embed quantum mechanics to a
> large degree (although most of the program is probably devoted to top-notch
> techniques of number crunching and PDE solving).

Of course there are programs that calculate these things but Newtonian
and quantum mechanics aren't used by software developers to create the
software itself. Or at least I don't know of an instance of that.



> Similarly, much of the software of today is embedded in devices. If you
> drive a modern car, chances are that the anti blocking system for your
> brakes has a computer chip somewhere. The software therein probably
> benefits a lot from physical knowledge about breaking.

Certainly, it will perform calculations about this.


> Any sort of knowledge will find its way into software (e.g., software for
> transactions between banks incorporates much knowledge about the particular
> kinds of transactions involved). Scientific principles are no exception.

I agree that there is software that performs calculations that have to
do with physics and software that performs calculations having to do
with banking.  No one claims that the science of banking (not AFAIK a
real term) is used to create the banking software simply because it does
calculations related to banking.

I know that I have a lot of trouble explaining what I mean here exactly,
so if something isn't clear to you, it's almost certainly my fault.  If
it isn't clear please let me know and I'll try to clarify.

LR
0
lruss (582)
11/29/2008 3:04:56 AM
On Nov 28, 6:59 pm, LR <lr...@superlink.net> wrote:
> Keith H Duggar wrote:
> > Software Engineering is replete with scientific principles.
> > Here are but a few off the top of my head:
>
> I'm not familiar with most of these and I had to look most of them up.
> I'm still in the process of looking some of them up. I am unfortunately
> pressed for time so I regret that I can't give each of these the
> attention they deserve. So briefly, very briefly:

It seems we'll need to wait until you have more time because:

[snip categorizations of the several scientific principles]

> I'm certain that I've overlooked some obvious point or made some
> mistake.  Please feel free to point those out.

fails to make any point as far as I can see. Did you have a
point you were trying to make?

> > Murphy's Law
>
> Ok, perhaps you got me. But it's not, I don't think, a scientific law
> or principle. Maybe it should be. Or you haven't offered proof of the
> law, or shown how it's applied to the production of software.

Murphy's Law is applied regularly in engineering disciplines
including software engineering. I do not see much of a need to
"show" this any more than I see a need to show that algebra is
used often in graph theory or combinatorics. That is to say it
is such an obvious fact to anyone with a engineering education
that "showing" it seems trite.

On the other hand, if you are largely (or nearly completely)
ignorant of what engineering involves, how engineering is done,
how engineering is taught, how it relates to science, etc, then
I might be more patience to offer you a bit of free education.
But only if you 1) admit that you are ignorant 2) demonstrate
an open mind and willingness to learn 3) provide an honest
estimate of your current degree of knowledge.

(1) is crucial to establishing the right mindset and attitude.
(2) is obviously necessary in a newsgroup context. (3) is will
help us find an appropriate starting point.

Finally, it would be a kindness and one very helpful to me if
you state honestly what your goal is. Do you seek to learn? Do
you seek to persuade? Do you seek to troll? Do you seek to pass
time? Do you see to reinforce your existing prejudices? Do you
seek to "prove" that you are smart? Do you seek to show that
others are stupid or naive? etc.

KHD

0
duggar (292)
11/29/2008 4:14:21 AM