A
L
Lew
LR said:
I call myself a "software engineer" in Maryland, the U.S. of A.
J
James Kanze
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".
J
James Kanze
Or spelling. The line between orthography and typography is
fine.
In both, I'd say it's orthography, which can be attached to
grammar, but is also related to typography.
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.
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.
J
James Kanze
Most of them want just the opposite
. If the program shouldhalt, there's usually no problem in proving it in practice;
proving that it won't is more difficult.
J
James Kanze
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.
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.
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.
C
courpron
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.
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.
J
James Kanze
And it was. Mature doesn't mean that it won't evolve.
Certainly. That will always be the case.
C
courpron
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.
B
Bent C Dalager
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
B
Bent C Dalager
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
L
Lew
AL said:
Yes, many times in this thread.
T
Tom Anderson
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
T
Tom Anderson
In the UK.
tom
M
Martin Gregorie
Same here: its well recognised in the UK. I hold a CE in software
engineering as well as an MSc (Chemistry).
I
Ian Collins
James said:
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...
P
Puppet_Sock
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.
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
L
LR
Lew said:
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.
I agree. But something that isn't engineering won't become engineering
as it gets more mature.
Sorry, I think that qualifies as mathematics.
LR
L
LR
Lew said:
Argument by appeal to authority? Well, I've done that too. And there was
nothing whatsoever unfair about it.
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.
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
L
LR
Arne said:
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