RE: Is strong typing worth the cost?

RE: Is strong typing worth the cost?

[Beard, Frank [Contractor]]

-----Original Message-----
From: dmjones [mailto:derek@NOSPAMknosof.co.uk]


>> Because then they will have to program in all the necessary
>> checking to prevent erroneous results.  The group that uses

> Not necessarily.  If I know a particular quantity will vary
> between 1..5 I will define such a type.  I know that I then get
> this 1..5 assumption checked for me, which is useful.  But would
> I go to the effort of putting all those 1..5 checks in by hand?
> I doubt it.

But that's my point.  You would by using a strong typing feature,
in this case a subtype range.  If you were not using strong typing,
then you would have to write in checks to ensure the value was
within that range.  Otherwise, you get unexpected, and erred,
results.
 
>> How are you going to determine that the unprotected group
>> programmed all the necessary checking?  Are you going to
>> have some type of code analysis software to check it out?
>> This will have a huge impact on downstream maintenance.

> Can back this statement up with some evidence?

Not with a study that you're looking for, just practical
experience (though I do remember reading articles off an on).

I worked on a Fortran graphics project a number of years back.
Fortran has no protection from going outside any boundaries
you define (at least not back then).  The data that was being
plotted looked fine most of the time, when suddenly the graph
would flat-line either high or low.  It took days, if not weeks,
to figure out where a rounding error was occurring.  Someone had
forgotten to explicitly declare a variable as a float, and it
had defaulted to an integer.  So, there was rounding error that
sometimes lead to an out-of-bounds high or out-of-bounds low
value.  That would never have happened with Ada.  For one, you
would have to explicitly convert between the types, instead of
continuing along in blissful ignorance.  Secondly, you would
have gotten an exception, with a traceback, telling you where
the offending code was located.  We didn't even know that with
the Fortran (hours and hours of painful attempts to recreate
the situation).

I had a similar experience with interfacing to C code on Windows.
A C DLL we interfaced with went wandering out through our code
and eventually crashed the application.  Fortunately, with CodeView
debugging on, the traceback pointed back into the C code, where
the C programmer figured out he was interrogating the data structure
the was passed to him.  The problem was it was an empty structure
that his code was supposed to populate.  For some reason, his code
was trying to examine it and print the contents of one of the string
values.  All the strings were blank filled, so it went who knows
where until it cause some type of segmentation fault and crash the
application.

Anyway, I'm sorry I don't have the time to try and dredge up the
articles from the past, but I've been in both environments (strongly
typed and loosely typed) and I never want to go back to loosely
typed languages.

Frank

Re: Is strong typing worth the cost?

[Gralia, Mars J.]

dmjones <derek@NOSPAMknosof.co.uk> asked:
> I have been trying to locate evidence that the cost of the use
> of strong typing is repaid by a greater benefit.

I believe I saw an article exactly like this in the journal Communications
of the Association for Computing Machinery (ACM) perhaps seven (7) years
ago.

They ran the study by taking something like a dozen college Computer Science
folks, inventing two pseudo-languages (with and without strong typing) and
let them go at it.  Strong typing was better in
time-to-produce-a-correct-program.  It was slower in
time-to-get-a-program-which-cycled.

Sorry, but our library doesn't yet have the ACM on-line, so I can't search
for it. I did search the IEEE archives and found nothing; I looked in
"journals, conference proceedings and standards".  I also looked in INSPEC,
but was overwhelmed with the number of low-value results.

M. Gralia

RE: Is strong typing worth the cost?

[Beard, Frank [Contractor]]

> OK this is very trivial, but think about this in a big complex program
> where the variables are not so obvious. Say a Mars probe that crashes
> due to a simple bug or whatever.

Exactly.  Do you see any cost/benefit of not crashing your
Mars probe into the planet?  Or lets say you're dealing with
a vehicle that transports people.  Do you see any cost benefit
of not crashing it into the ground?  Let's see, big lawsuit 
equals big cost.  As far as the benefit, ask the people traveling
on the vehicle.

RE: Is strong typing worth the cost?

[Beard, Frank [Contractor]]

From: dmjones [mailto:derek@NOSPAMknosof.co.uk]

> Who mentioned safe and correct?  This is avoiding the base
> issue.  Where is the evidence of a worthwhile cost/benefit
> for strong typing?

If you can't grasp the connection between "safe and correct"
and "cost/benefit", then everyone is wasting their time
discussing it with you.  It is a fundamental key point.

I haven't seen any research lately on the benefits of strong
typing.  Why should there be any, since most of the C/C++
camps, and other loosely typed languages, don't care?  That's
why you end up with products like Windows that are expected
to crash frequently.  And they don't care, because they'll
just charge you for an upgrade to fix things that shouldn't
have been there in the first place.  And that's also why you 
don't see Microsoft products user in life-and-death situations.

Does anybody remember the link to the site/agency that forbade
C from being used on mission critical or safety critical systems?
They had a paper on the site the went into the reasons.  Most of
them, even if not explicitly stated, where strong typing issues.
It's been several years since I read it, and I can't remember
where.

Re: Is strong typing worth the cost?

[David Gillon]

"Beard, Frank [Contractor]" wrote:

> Does anybody remember the link to the site/agency that forbade
> C from being used on mission critical or safety critical systems?
> They had a paper on the site the went into the reasons.  Most of
> them, even if not explicitly stated, where strong typing issues.
> It's been several years since I read it, and I can't remember
> where.


It's MISRA, the (UK) Motor Industry Software Research Association. A
search should turn it up. Last time I checked the reports were
downloadable as PDFs once you registered (I did, but they're on my home
system so I can't check them off hand).

-- 

David Gillon

RE: Is strong typing worth the cost?

[Beard, Frank [Contractor]]

This will be very difficult to get an apples to apples
comparison, because the group that is not allowed to use
subranges or subtypes should also suppress range checking.
Because then they will have to program in all the necessary
checking to prevent erroneous results.  The group that uses
subtypes/subranges will mean they had to spend some time
in some up front analysis, where the unprotected group will
not.

The fun will begin when your test data contains out of
range values and the unprotected group starts producing
all type of erroneous results, which will take hours, or
days, if ever, to uncover, where the strongly type group
will find it in minutes.

Unless what you're really talking about is comparing the use
of parent types to subtypes.  In this case, you sort of in
the in-between realm.  You have range checking for when you
go outside the parent range, but then you still have to
manually code in the sub-range protection.

How are you going to determine that the unprotected group
programmed all the necessary checking?  Are you going to
have some type of code analysis software to check it out?
This will have a huge impact on downstream maintenance.

Frank

-----Original Message-----
From: dmjones [mailto:derek@NOSPAMknosof.co.uk]
Sent: Monday, April 29, 2002 2:38 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Is strong typing worth the cost?


Ted,
 
>> I have been trying to locate evidence that the cost of the use
>> of strong typing is repaid by a greater benefit.
> 
> There was a study done on compiler software by Rational. It showed
> something like 2x productivity for Ada over C, with the credit being
> laid at least partially on Ada's strong typing. It should be available
> somewhere on their website, but you'll probably have to search for it.

Thanks for the reference.  But I my interest is purely in
the advantages of strong typing.  Language comparison is too
broad an issue.

The experiment I had in mind was two set of subjects, all
working on the same Ada program.  However, one set of subjects
is not allowed to use subranges or subtypes. All objects
holding integer values have integer type.  The other
set of subjects would be able to create as many different
integer types as they liked.

How long would each group of subjects take to complete their
tasks, and what would down stream maintenance costs be (for
programs created by each set of subjects)
?
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

RE: Is strong typing worth the cost?

[dmjones]

Pat, Darren,

I appreciate there is more to strong typing than
subtypes of integers.  But including structured types
brings in all sorts of bagage.  If I were doing such
an experiment I would keep it simple.

Besides, many languages are a bit stronger in their
typing of array and structured types, than of their
integer types.

Frank,

> Because then they will have to program in all the necessary
> checking to prevent erroneous results.  The group that uses

Not necessarily.  If I know a particular quantity will vary
between 1..5 I will define such a type.  I know that I then get
this 1..5 assumption checked for me, which is useful.  But would
I go to the effort of putting all those 1..5 checks in by hand?
I doubt it.
 
> How are you going to determine that the unprotected group
> programmed all the necessary checking?  Are you going to
> have some type of code analysis software to check it out?
> This will have a huge impact on downstream maintenance.

Can back this statement up with some evidence?

At the moment I will settle for any references to studies
showing that use of strong typing (not structured types) has
a cost/benefit ratio of less than one.

Is strong typing worth the cost?

[dmjones]

All,

I have been trying to locate evidence that the cost of the use
of strong typing is repaid by a greater benefit.

Now we all know, from first hand experience, the benefits of
strong type checking.  But where is the experimental proof?
I know of two studies:

A Controlled experiment to assess the benefits of procedure
argument type checking, by Prechelt & Tichy, IEEE Trans on
Software Engineering Vol 24, no 4. 302-312.

An Experimental evaluation of data type conventions, by Gannon,
CACM Vol 20, no 8. 584-595.

Both studies used student subjects, not the one most likely
to have had lots of experience structuring a program using types.
One study also used C, which is strongly typed if compared
to assembler.

So where are the studies showing that strong typing in Ada (or
Pascal) saves money/time, creates more reliable programs, etc?

References anybody?

Re: Is strong typing worth the cost?

[Ted Dennison]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns91FEB85DCA09Cderekknosofcouk@62.253.162.108>...

> I have been trying to locate evidence that the cost of the use
> of strong typing is repaid by a greater benefit.

There was a study done on compiler software by Rational. It showed
something like 2x productivity for Ada over C, with the credit being
laid at least partially on Ada's strong typing. It should be available
somewhere on their website, but you'll probably have to search for it.

There are other differences in the languages than just the strength of
the typing though (eg: no "=" vs "==" confusion, more English-like
syntax, etc), so it isn't as clean a study as you'd want if you are
just looking at type checking. But it would be tough to find better
from an Ada newsgroup, as there aren't non-type-checking versions of
Ada floating around.

A better idea might be to try to find out if anyone ever did such a
study with C projects with and without Lint.


-- 
T.E.D.
         Home     -  mailto:dennison@telepath.com (Yahoo:
Ted_Dennison)
         Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Is strong typing worth the cost?

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204290722.2189008@posting.google.com...
> dmjones <derek@NOSPAMknosof.co.uk> wrote in message
news:<Xns91FEB85DCA09Cderekknosofcouk@62.253.162.108>...
>
> > I have been trying to locate evidence that the cost of the use
> > of strong typing is repaid by a greater benefit.
>
> There was a study done on compiler software by Rational. It showed
> something like 2x productivity for Ada over C, with the credit being
> laid at least partially on Ada's strong typing. It should be available
> somewhere on their website, but you'll probably have to search for it.

It is available at the AdaIC web site at

http://www.adaic.org/whyada/ada-vs-c.html

Re: Is strong typing worth the cost?

[dmjones]

Ted,
 
>> I have been trying to locate evidence that the cost of the use
>> of strong typing is repaid by a greater benefit.
> 
> There was a study done on compiler software by Rational. It showed
> something like 2x productivity for Ada over C, with the credit being
> laid at least partially on Ada's strong typing. It should be available
> somewhere on their website, but you'll probably have to search for it.

Thanks for the reference.  But I my interest is purely in
the advantages of strong typing.  Language comparison is too
broad an issue.

The experiment I had in mind was two set of subjects, all
working on the same Ada program.  However, one set of subjects
is not allowed to use subranges or subtypes. All objects
holding integer values have integer type.  The other
set of subjects would be able to create as many different
integer types as they liked.

How long would each group of subjects take to complete their
tasks, and what would down stream maintenance costs be (for
programs created by each set of subjects)
?

Re: Is strong typing worth the cost?

[Pat Rogers]

"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns91FFC7B971B88derekknosofcouk@194.168.222.64...
> >> I have been trying to locate evidence that the cost of the use
> >> of strong typing is repaid by a greater benefit.
<snip>
> The experiment I had in mind was two set of subjects, all
> working on the same Ada program.  However, one set of subjects
> is not allowed to use subranges or subtypes. All objects
> holding integer values have integer type.  The other
> set of subjects would be able to create as many different
> integer types as they liked.
>
> How long would each group of subjects take to complete their
> tasks, and what would down stream maintenance costs be (for
> programs created by each set of subjects)

That's an extremely narrow definition of strong typing!  Are you sure you don't
want to include the more typical "abstract data type" concept, as embodied by
Ada's private types?

When I review customer Ada code and see few or no private types I start to
worry.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Is strong typing worth the cost?

[Darren New]

dmjones wrote:
> The experiment I had in mind was two set of subjects, all
> working on the same Ada program.  However, one set of subjects
> is not allowed to use subranges or subtypes. All objects
> holding integer values have integer type.  The other
> set of subjects would be able to create as many different
> integer types as they liked.

Um, both of these are strong typing. You've just limited one group to
use fewer types than the other. Even most dynamically-typed languages
are still strongly typed. I'm not guessing you'd learn too much from
this experiment, but it might be an interesting data point when combined
with other experiments.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marc A. Criley]

dmjones wrote:
> 
> Thanks for the reference.  But I my interest is purely in
> the advantages of strong typing.  Language comparison is too
> broad an issue.
> 
> The experiment I had in mind was two set of subjects, all
> working on the same Ada program.  However, one set of subjects
> is not allowed to use subranges or subtypes. All objects
> holding integer values have integer type.  The other
> set of subjects would be able to create as many different
> integer types as they liked.
> 
> How long would each group of subjects take to complete their
> tasks, and what would down stream maintenance costs be (for
> programs created by each set of subjects)
> ?

So far the only aspect of strong typing that's been mentioned here is
that of type and constraint checking, i.e., defensive use.  Don't forget
that strong typing is also an offensive aid, allowing programmers to
implicitly embed massive amounts of information within their software
that can then be extracted with the aid of attributes.

Think about it, what relevent information can you deduce about the
characteristics of:

   Alt : Integer;

versus:

   type Altitude_Type is range 0 .. 50_000;
   Alt : Altitude_Type;

?

E.g., 'First, 'Last, 'Range, etc.

The inherent ability to embed and extract information via properly
conceived type definition is one of the most overlooked and underused
strengths of strong typing.  Don't fight strong typing, USE it!

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: Is strong typing worth the cost?

[dmjones]

Marc,

>> Thanks for the reference.  But I my interest is purely in
>> the advantages of strong typing.  Language comparison is too
>> broad an issue.
> 
> So far the only aspect of strong typing that's been mentioned here is
> that of type and constraint checking, i.e., defensive use.

The real problem with the discussion so far is that it has
only mentioned the benefits.  What about the costs?


> strengths of strong typing.  Don't fight strong typing, USE it!

Why?  Can you prove to me that the benefits will be greater
than the costs?

Why am I asking for this evidence?  I am working on a detailed
analysis of C that includes material on coding guidelines.
I have set myself the target of basis these guidelines on
empirical evidence.  I am a fan of strong typing.  However,
unless I can find any evidence to the contrary, the most I
can say at the moment is "some people think ...".

You can find a draft copy of the introduction at the most
excellent Research Index:
http://citeseer.nj.nec.com/jones02new.html
This is a somewhat long introduction, to a somewhat unusual
book, but there is lots to talk about.  Check out the table
of contents of the introduction for relevant page numbers.
The book will not be in the stores in time for you to take on
holiday with you this summer :-(

Re: Is strong typing worth the cost?

[Jim Rogers]

dmjones wrote:

> Marc,
> 
> 
> Why?  Can you prove to me that the benefits will be greater
> than the costs?
> 
> Why am I asking for this evidence?  I am working on a detailed
> analysis of C that includes material on coding guidelines.
> I have set myself the target of basis these guidelines on
> empirical evidence.  I am a fan of strong typing.  However,
> unless I can find any evidence to the contrary, the most I
> can say at the moment is "some people think ...".
> 


What costs are you seeing?

Seriously, any software that reports itself as safe and
correct must perform a significant amount of what the old
COBOL programmers call data editing. It must verify that the
data is correct in all phases of the program. Weakly typed
languages such as C do not avoid this problem. C simply
delegates all such responsibility to the application
programmer. Ada, on the other hand, allows the application
programmer to supply important information, such as the minimum
and maximum values for a scalar type, and then lets the
compiler generate the range checking.

Range checking always requires someone to do the coding.
Ada has put that burden on the compiler developer. C puts it
on the application developer. For the application developer this
makes coding in C more expensive than coding in Ada.

C complicates the problem by its extensive use of implicit
numeric convrsions. The C compiler is not allowed to object if
you assign an int to a double. In all cases, such assignments
are dangerous. C insists the danger does not exist because a
double can always represent all values representable in an int.
The problem is that you can be assigning an AppleCount to a
WeightOfScrapIron. Strong typing can flag the danger of such
assignments, forcing you as the programmer to review your
program. Weak typing gives you no help. You are left with the
need to carefully test all possible value combinations for your
code, an impossible task for any non-trivial program.

Jim Rogers

Re: Is strong typing worth the cost?

[dmjones]

Boys and girls,

> Seriously, any software that reports itself as safe and
> correct must perform a significant amount of what the old

Who mentioned safe and correct?  This is avoiding the base
issue.  Where is the evidence of a worthwhile cost/benefit
for strong typing?

If I had posted to comp.lang.basic asking about strong typing
I'm sure I would have had lots of well meaning people tell me
that strong typing was a waste of time and money.  They might
even have thrown in some references to web pages, papers backing
up this view.

Is this what it boils down to?  Is choice of type system based
on faith only?

Is experimental evaluation a dead duck in software engineering?

http://citeseer.nj.nec.com/lukowicz94experimental.html

ps.  Jim you were the last to post and get the semi-rant.
Those before you are just as guilty of being faith based
(if that is what it is).

Re: Is strong typing worth the cost?

[Marin David Condic]

Experiments in software engineering could get very expensive. Maybe not as
expensive as high-energy particle physics, but pretty expensive. In order to
be meaningful, they would also need to be of sufficient size that they would
become very time consuming - making possible results rather dated.

Consider that to test the hypothesis: "Strong Typing In A Language Improves
Productivity And Reduces Errors" you would need the following:

1) A set of requirements for a project that should result in software of
100,000 slocs or better. (Small projects aren't likely to show much benefit,
nor are they realistically representative of real world programming.)

2) Two designs to those requirements that are as close to identical as
possible. One based on a strong typing model and the other relying on raw
machine types. (This may not even be possible since that really reflects two
different design philosophies.)

3) Two language compilers that support identical languages except that in
one, you have strong type checking and in the other, you have just machine
types with automatic conversions, etc. (You can't just say "use the standard
types in Ada" because even those are strongly typed and eliminate a whole
class of errors on their own. You'd need to have something like Ada with C
type checking. I'm not convinced you could get there without destroying
other aspects of the language that would then alter the validity of the
results.)

4) Two teams of reasonably similarly experienced engineers (Does the test
prove the hypothesis for inexperienced students or for experienced
engineers? Did they know the languages in question before they started the
project or did they have to learn them? It isn't simple, is it?) The
engineers would have to be available full-time for the duration of the
project (6 months, to be realistic?) so start thinking of salaries and how
to get engineers to forgo/interrupt promising careers to be part of the
study.

5) Identical development environments - the only variable being the language
support for the type model. (Is that fair? What about compiler bugs? Could
they account for delays, reported errors, etc?)

6) A well defined development process that is adhered to by both groups.
(Errors are injected by sloppy CM, lack of code reviews, etc. How tightly is
strong typing tied to development process anyway? Are weakly typed languages
used in places with no identifiable process and strongly typed languages
used by developers with well organized and followed procedures?)

7) A rigorous test suite that can be applied to both end products to
determine compliance with requirements and existence of errors. (You can't
write a test suite to detect all errors, but its got to be thorough enough
to demonstrate the most eggregious ones or its not going to demonstrate the
hypothesis.)

Even when you get done with all that, we can still cast serious stones at
whatever results are demonstrated:

1) Its only one trial - To reflect reality, it ought to be conducted lots of
times with different teams at different skill levels.

2) Its only one problem domain. Type checking might be real important in one
problem domain and not a big deal in another.

3) Whatever the project looks like, its artificial and doesn't reflect the
kinds of things that need to be done or dealt with in a real project.
(Things like shifting requirements, vague problem definitions, needing to
meet deadlines, etc.)

4) Whatever the results are, they reflect the technology available at the
start of the research project (6 months? A year before the results are
ready?) and that is a long time in Computer Years. Would better debuggers,
faster computers, automatic code generators, analysis tools, etc. that are
available today have changed the outcome?

All in all, its a lot simpler and less costly to deal with questions like
"What happens if I drop different sized cannonballs off a tall building?"
than it is to ask questions about software engineering. Not that I'd be
against asking those questions and trying to come up with experiments to
investigate them, but you've got to admit that doing so in anything like a
scientific manner would cost a LOT of money. Its probably worth doing, but
who would pay? (I'd personally love to have a research grant to conduct a
study like that. It would get me out of hacking C code for a living! :-)

Question: What I outlined here is pretty rigorus. Would you accept as being
useful or valid some kind of experiment that didn't require such controlled
conditions?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns9200B524E1781derekknosofcouk@62.253.162.109...
>
> Is experimental evaluation a dead duck in software engineering?
>
> http://citeseer.nj.nec.com/lukowicz94experimental.html

Re: Is strong typing worth the cost?

[Brian Gaffney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aaml7i$eft$1@nh.pace.co.uk>...
> Experiments in software engineering could get very expensive. Maybe not as
> expensive as high-energy particle physics, but pretty expensive. In order to
> be meaningful, they would also need to be of sufficient size that they would
> become very time consuming - making possible results rather dated.
> 
> Consider that to test the hypothesis: "Strong Typing In A Language Improves
> Productivity And Reduces Errors" you would need the following:
> 
> 1) A set of requirements for a project that should result in software of
 . . .
> 2) Two designs to those requirements that are as close to identical as
 . . .

Perhaps this could be done using two different Win32 (or similiar)
bindings.  One team could be required to use a paper-thin (C) binding,
and be provided with easy-to-access conversion routines (so type
conversions could be done whenever desired).  The other team could be
given a thicker binding (same API routines, but using Ada types,
type-distinct parameters, etc.).  You could use the same requirements,
basically the same design, and possibly even the same test suite.  If
the project were reasonably large with a sufficient percentage of the
code dealing with the binding, the first team would basically be
writing C code.  The result could be a reasonable assessment (of
something:-).  Not saying it'd be a good idea, or a productive use of
time, just an idea of how this could be done.  I know I am a lot more
productive after I've made a thicker binding to a library I'm trying
to use.

Re: Is strong typing worth the cost?

[tmoran]

> Who mentioned safe and correct?
  If you don't care about safe or correct, then ";" constitutes
an elegant, short, program to solve any problem whatsoever.

> Where is the evidence of a worthwhile cost/benefit
> for strong typing?
  Let's rephrase that: Where is the evidence that strong typing
is not worth the cost?  As a matter of fact, what does it cost?
I suggest the cost is zero, in which case even the most minor of
benefits would make the benefit/cost = infinity.

> Is experimental evaluation a dead duck in software engineering?
  To be dead implies it once lived.  Actual hard data on software
engineering is remarkable by its absence.

2 cents: In addition to constraints, strong typing allows the compiler
to tell you when you've used the wrong variable for a subscript, for
instance.

Re: Is strong typing worth the cost?

[Marin David Condic]

There does tend to be a "Put the burden of proof on Ada" kind of attitude
that often comes into play. It may not be entirely unfair in that someone
can say "This is what I do now. You propose that I do something different
and claim it is better. Can you demonstrate how this is better?"

OTOH, there actually *is* some half-way scientific evidence that Ada *does*
do things better when taken overall. (Its difficult to isolate just one
feature of Ada and say "Demonstrate that just this feature is better." We do
have studies that tend to indicate that The Ada Way, taken as a whole,
results in higher productivity and lower defects.) There is no scientific
evidence I am aware of that somehow weak typing, lack of runtime checks,
"concise" syntax or other features that are contrary to the Ada philosophy
(The AntiAda Way?) improve productivity or reduce defects over development
in Ada or other more rigorous languages.

So we might say, "There is no rigorous, *scientific* proof of the
superiority of either strategy. Do we have any unscientific evidence or
logical reasoning or anectdotal evidence or other factors to prefer the
strong typing model of Ada?" I think there is quite a bit of that sort of
thing to demonstrate that for non-trivial applications, you get better
results with Ada's philosophy than with other philosophies. (With the
standard disclaimer: "All Other Things Being Equal" :-) Now the ball can go
over to the other court: Can this be demonstrated with science to be false?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


<tmoran@acm.org> wrote in message
news:9gBz8.4054$%r1.2380315867@newssvr21.news.prodigy.com...
> > Where is the evidence of a worthwhile cost/benefit
> > for strong typing?
>   Let's rephrase that: Where is the evidence that strong typing
> is not worth the cost?  As a matter of fact, what does it cost?
> I suggest the cost is zero, in which case even the most minor of
> benefits would make the benefit/cost = infinity.
>

Re: Is strong typing worth the cost?

[dmjones]

"Marin David Condic",

> There does tend to be a "Put the burden of proof on Ada" kind of
> attitude that often comes into play. It may not be entirely unfair in
> that someone can say "This is what I do now. You propose that I do
> something different and claim it is better. Can you demonstrate how this
> is better?" 

This discussion is occurring in an Ada news group because Ada
is essentially the only game in town, with regard to a) strong
typing, and b) a reasonable sized commercial usage base.

The reason for originally posting here was the thought that
if some research existed, this would be the group that would
know about it.  If a study is performed, Ada would be the obvious
candidate to use.  There is a pool of experienced users working
on problems similar to problems being solved using other languages.

Yes, Ada may contain other fine features and separating out the
type system (for experimentation) from the rest of the language may 
sound like an odd thing to do.  I think the use of strong typing in
other languages would reduce the cost of software ownership.  If
you can think of a better way for me to obtain substantiating
evidence please let me know.

Re: Is strong typing worth the cost?

[Marin David Condic]

I don't think it is an odd thing to do - you're asking a fair question.
There are reasons to suspect that going to the pains of creating lots of
specialized types to distinguish between the data being manipulated is of
benefit to projects in terms of reducing costs, etc. Is there any way of
substantiating it with research?

I think it would be difficult to test - but it might depend on how you
worded the question. If the question is "Suppose I just use the language
provided types with language provided checks, versus a design that
distinguishes the kind of data into their own types and subtypes to avoid
mixing things. Does this improve productivity?" That, you *might* be able to
construct an experiment to test. However, that's a significantly different
thing than comparing a weak-typed language (such as C) to a strongly typed
language, since Ada still provides a lot of checks on its own defined types
that C does not. (Parameter passing or automatic data conversions are good
examples. Checking those things can result in major reductions in errors -
which Ada does and C does not.) So do the results tell you anything
significant?

I sympathize with your desire for scientific study - its just understandable
why there is so little out there to look at.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns9201A63CA1674derekknosofcouk@62.253.162.105...
>
> Yes, Ada may contain other fine features and separating out the
> type system (for experimentation) from the rest of the language may
> sound like an odd thing to do.  I think the use of strong typing in
> other languages would reduce the cost of software ownership.  If
> you can think of a better way for me to obtain substantiating
> evidence please let me know.

Re: Is strong typing worth the cost?

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

>                                  However, that's a significantly different
> thing than comparing a weak-typed language (such as C) to a strongly typed
> language, since Ada still provides a lot of checks on its own defined types
> that C does not. (Parameter passing or automatic data conversions are good
> examples. Checking those things can result in major reductions in errors -
> which Ada does and C does not.)

I suppose OP could try ANSI-C-with-prototypes vs original-K&R-C> I am
perpetually amazed by folk who don't write prototypes ...

Re: Is strong typing worth the cost?

[Martin Dowie]

> > There does tend to be a "Put the burden of proof on Ada" kind of
> > attitude that often comes into play. It may not be entirely unfair in
> > that someone can say "This is what I do now. You propose that I do
> > something different and claim it is better. Can you demonstrate how this
> > is better?"
>
> This discussion is occurring in an Ada news group because Ada
> is essentially the only game in town, with regard to a) strong
> typing, and b) a reasonable sized commercial usage base.

Have you considered asking the question of the C-plus-Lint community?

Re: Is strong typing worth the cost?

[Darren New]

Following up on several posts at once...

> There is no scientific
> evidence I am aware of that somehow weak typing, lack of runtime checks,
> "concise" syntax or other features that are contrary to the Ada philosophy
> (The AntiAda Way?) improve productivity or reduce defects over development
> in Ada or other more rigorous languages.

Well, depending on the project, you might consider things like XP to be
evidence that such a system can be made more productive than a strict
top-down design blah blah.

However, I think the benefit of something like Ada over something like C
is pretty clear. It's just not clear to me that the benefit of something
like Ada over something like Smalltalk or Common Lisp or FORTH or
something else with an entirely different philosophy of programming is
as obvious.

If you're trying to convince C programmers to move to Ada, focussing on
only the strong typing is probably a bad idea, given there's good
"scientific" evidence that Ada outperforms C. If you're trying to
convince people that Ada is best, it's less obvious.

> standard disclaimer: "All Other Things Being Equal" :-) 

And the problem is that in reality, all other things aren't equal. A
language specifically designed to be weakly typed, or dynamically typed,
or something like that isn't going to be equal to Ada in most other
ways. If all you know are the "romance languages" of programming
(procedural imperative statically-typed languages), this may not be as
obvious.

> This discussion is occurring in an Ada news group because Ada
> is essentially the only game in town, with regard to a) strong
> typing, and b) a reasonable sized commercial usage base.

Errr, COBOL? Smalltalk? Java? You seem to have a very odd definition for
"strong typing". 

> Things like that *can* become functional requirements as in "The system
> shall detect all input that is out of range..." or "The system shall never
> generate an output for this device that exceeds its safe operating
> range...." All that requires some kind of constraint checks at points
> throughout the code where a weak typed language is going to be at a
> disadvantage because you'll have to manufacture your own checks.

It's not clear a weakly-typed language is going to be at a disadvantage
from this. Consider a compiler that has a requirement to give a syntax
error for any malformed input. Something like Ada could declare types
representing valid syntax trees and build the syntax trees during
parsing. But the Ada code is still going to have to check the input as
it reads it in order to give an error message rather than throwing an
uncaught exception. Something like an SQL RDBMS written in Ada is going
to have to do pretty much all the same checks in Ada as it would in C.
So once you get to a high enough level of input checking and error
reporting, you can't rely on the constraint checks to tell you what's
wrong with your input. You really don't want a stack traceback printed
out on your payroll checks.

> How about doing what I did: keep track of each bug found in their
> currently-developing code, and then determine whether strong typing
> would have either prevented it or turned a multi-day debug into a
> multi-minute debug.

And XP addresses this by making every debug session a multi-minute debug
session. For some types of developments, it really does work, even
without the strong typing. (Well, it's strongly typed, but dynamically
typed, so I don't think the OP would consider it strongly typed.) And
indeed the keeping track of bugs found and fixed is one of the central
mantras of XP. The way you program is you first insert a bug ("The code
doesn't yet implement this new requirement, so the test that it works
fails, so that's considered a bug") then you fix that bug. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marin David Condic]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CD01D32.19D997B0@san.rr.com...
> Following up on several posts at once...
>
Makes it kind of hard to respond...


>
> Well, depending on the project, you might consider things like XP to be
> evidence that such a system can be made more productive than a strict
> top-down design blah blah.
>
I wasn't thinking of XP or any other development methodologies, etc. I was
talking about language philosophies - Ada has a distinct philosophy that
distinguishes it from other languages like C. (Programs should be more
readable than writable. Programs should have checks done by the language
rather than the programmer... etc...) If what you want to test is the
relative efficiency of this philosophy as compared to the C philosophy, then
you'd have to introduce them both to the same development process. Anything
else and you've got a worthless experiment.


> However, I think the benefit of something like Ada over something like C
> is pretty clear. It's just not clear to me that the benefit of something
> like Ada over something like Smalltalk or Common Lisp or FORTH or
> something else with an entirely different philosophy of programming is
> as obvious.
>
I don't know of any studies that introduced Ada into a process that used to
use Smalltalk, etc. (or the other way around) and demonstrated any change in
productivity or quality. It would be interesting to find out, but given the
more niche-market characteristics of the above languages, its harder to find
case studies - real or potential.


>
> > standard disclaimer: "All Other Things Being Equal" :-)
>
> And the problem is that in reality, all other things aren't equal. A
> language specifically designed to be weakly typed, or dynamically typed,
> or something like that isn't going to be equal to Ada in most other
> ways. If all you know are the "romance languages" of programming
> (procedural imperative statically-typed languages), this may not be as
> obvious.
>
That's one big reason that it is hard to study the impact of language, or
some specific language characteristic, on productivity and quality. It is
unbelievably hard to make all other things equal. This would be true even
within the "romance languages" so its just plain hard to do anything that
doesn't immediately come under fire as not being scientific or at least
seriously flawed.


>
> > Things like that *can* become functional requirements as in "The system
> > shall detect all input that is out of range..." or "The system shall
never
> > generate an output for this device that exceeds its safe operating
> > range...." All that requires some kind of constraint checks at points
> > throughout the code where a weak typed language is going to be at a
> > disadvantage because you'll have to manufacture your own checks.
>
> It's not clear a weakly-typed language is going to be at a disadvantage
> from this. Consider a compiler that has a requirement to give a syntax
> error for any malformed input. Something like Ada could declare types
> representing valid syntax trees and build the syntax trees during
> parsing. But the Ada code is still going to have to check the input as
> it reads it in order to give an error message rather than throwing an
> uncaught exception. Something like an SQL RDBMS written in Ada is going
> to have to do pretty much all the same checks in Ada as it would in C.
> So once you get to a high enough level of input checking and error
> reporting, you can't rely on the constraint checks to tell you what's
> wrong with your input. You really don't want a stack traceback printed
> out on your payroll checks.
>
I think this is a separate issue. Think in terms of two levels of checks.
The first safeguard (which may be a requirement) you might call "Sanity
Checks". If you know your inputs are supposed to be in some range or that
they must be valid ASCII characters or that arrays have to be of some
specific size or you have to insure you can't walk off the end of a buffer
or whatever, and all those things are considered to be system requirements,
then any weak typed language is going to be at a disadvantage because you'll
have to code all those checks yourself. The next level of checks for
validity - the kinds of things you bring up such as a compiler looking for
valid syntax - those are going to be very application specific and you'll
have to manually code those checks no matter what language you use. So is
the requirement to do both validity checks and sanity checks? If so, weak
typing loses.


>
> And XP addresses this by making every debug session a multi-minute debug
> session. For some types of developments, it really does work, even
> without the strong typing. (Well, it's strongly typed, but dynamically
> typed, so I don't think the OP would consider it strongly typed.) And
> indeed the keeping track of bugs found and fixed is one of the central
> mantras of XP. The way you program is you first insert a bug ("The code
> doesn't yet implement this new requirement, so the test that it works
> fails, so that's considered a bug") then you fix that bug.
>
You're bringing up process - not language. Process may be interesting, but I
don't think it has much to do with the original question.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Is strong typing worth the cost?

[Darren New]

Marin David Condic wrote:
> rather than the programmer... etc...) If what you want to test is the
> relative efficiency of this philosophy as compared to the C philosophy, then
> you'd have to introduce them both to the same development process. Anything
> else and you've got a worthless experiment.

Sure. Here's my problem with the whole "scientific experiment" bit.

It's obvious that a trivial way to do the experiment would be to use two
versions of Ada, one where you get to use the whole language, the other
where you get to only use the base types and all the run-time checking
is turned off at compile-time. That would seem to be about as close as
you can come to having the same language both strongly and weakly typed.
Maybe C vs C+Lint would be the other way to go.

But obviously, the second version of Ada is a subset of the first
version of Ada. Running off the end of an array or overflowing a
variable or whatever is going to be an error. It won't be caught without
the run-time checking, but it's still an error. So the run-time checking
doesn't really give you any benefit when the program is correct
(assuming you don't intentionally throw and later catch constraint
errors or something rather than returning inside an "if", say). 

So clearly the first group *could* be just as productive as the second
group by simply ignoring the range checks in Ada, and *will* be more
productive because the errors are caught earlier.

My point being that it sounds like a pretty worthless experiment,
because it's so constrained that the outcome is obvious. The interesting
part is to ask what using a language with weak typing buys you. If the
language with weak typing is Ada, it doesn't buy you anything. If the
language with weak typing is C, it buys you programmer experience, more
populous newgroups, a plethora of syntax-directed editors, code
generators for GUIs, zero-effort interfaces to third-party libraries,
etc etc etc.
 
> I don't know of any studies that introduced Ada into a process that used to
> use Smalltalk, etc. (or the other way around) and demonstrated any change in
> productivity or quality. It would be interesting to find out, but given the
> more niche-market characteristics of the above languages, its harder to find
> case studies - real or potential.

Errr, this is odd. What do you think the "niche market" is for Smalltalk
or Forth? Do you really think Smalltalk's market is more of a "niche"
than Ada's?

Now, if you'd said that Atlas is a niche language, or Postscript is a
niche language, or YACC is a niche language, I'd agree with you. But by
what criterion is Smalltalk or Forth a niche language?

> > > standard disclaimer: "All Other Things Being Equal" :-)
> >
> > And the problem is that in reality, all other things aren't equal. A
> > language specifically designed to be weakly typed, or dynamically typed,
> > or something like that isn't going to be equal to Ada in most other
> > ways. If all you know are the "romance languages" of programming
> > (procedural imperative statically-typed languages), this may not be as
> > obvious.
> >
> That's one big reason that it is hard to study the impact of language, or
> some specific language characteristic, on productivity and quality. 

I'd say it's easy to determine the impact of language choice on
productivity and quality. However, I'd say that things tangential to the
language may have a serious effect. For example, it's possible that
Smalltalk's model of the environment (in terms of debugging, code
editting, "workspace"-style program management, etc) make it far more
productive in some situations than Ada is. However, it's not independent
of the language, because Ada can't do the kinds of things that Smalltalk
does in that regard.

> It is
> unbelievably hard to make all other things equal. This would be true even
> within the "romance languages" so its just plain hard to do anything that
> doesn't immediately come under fire as not being scientific or at least
> seriously flawed.

Again, I'd say it's easy to evaluate the choice of language+environment
on programming productivity, and trying to evaluate a question of
language and discarding all the environmental differences *caused* by
the difference in the language is just silly.
 
> have to manually code those checks no matter what language you use. So is
> the requirement to do both validity checks and sanity checks? If so, weak
> typing loses.

No, I'd think that putting in a requirement to do sanity checks would be
silly. The requirements on a program ought to be based on the input and
output. Otherwise, why not just write in a requirement that you have to
use a language where all sanity checks are done by the compiler?
 
> You're bringing up process - not language. Process may be interesting, but I
> don't think it has much to do with the original question.

Except that I can't imagine the XP process working with Ada, for
example, so it is relevant. Asking about the typing independent of the
process is like asking whether it's better to travel by car or airplane
without asking how far you're going.

Take as an extreme example, if your goal is to save programming dollars
... is it better to spend money on Ada training, or is it better to
spend money to put programmers in offices with doors they can close
instead of cubicles? If your bottom line is dollars, it's not obvious
that checking strong against weak typing is going to tell you anything.
If you're just interested in strong vs weak typing, well, anything you
can do with weak typing you can also do with strong typing, so limiting
yourself to a language that only supports one is going to be at best no
better than one that supports both.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marin David Condic]

By "niche-market" I mean that it is not responsible for, say, 60% of all
software written everywhere. I'm not sure why that doesn't seem obvious.
Does one regularly see, say 1/3 of all programmer positions offered in the
newspaper being for Smalltalk or Forth programmers? By that standard, I am
simultaneously including Ada in the "niche-market" category.

The point is this: If you want to study the impact of Ada vs C++, it is a
lot easier to find something that is being done in C++ (because of the large
number of projects) where you can possibly inject Ada into the mix and see
if it works better. Likewise, one might compare Smalltalk to C++ by finding
a C++ project that could be supplanted or duplicated in some manner. But if
Ada doesn't have the same massive following as C++ and Smalltalk doesn't
have as massive a following as C++ are you going to be able to find an
opportunity to replace Smalltalk with Ada or the other way around?

One can always contrive experiments, but a lot of industry studies are done
based on some practical project(s) where enough information is available to
look at and get an understanding of what happens. You might have a dozen
similar C++ products in a company and somehow convince management "Hey,
let's do the next one in Ada and see if it works better..." and because of
similarity you might be able to draw some conclusions that Ada did a
better/worse job. That's the kind of scenario I was thinking of.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3CD1652C.5A4736@san.rr.com...
>
> Errr, this is odd. What do you think the "niche market" is for Smalltalk
> or Forth? Do you really think Smalltalk's market is more of a "niche"
> than Ada's?
>
> Now, if you'd said that Atlas is a niche language, or Postscript is a
> niche language, or YACC is a niche language, I'd agree with you. But by
> what criterion is Smalltalk or Forth a niche language?
>

Re: Is strong typing worth the cost?

[Darren New]

Marin David Condic wrote:
> By "niche-market" I mean that it is not responsible for, say, 60% of all
> software written everywhere. I'm not sure why that doesn't seem obvious.

Fair enough. I thought you were excluding Ada from the "niche" category.
:-)

That said, yes, the rest of what I just snipped makes perfect sense.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[tmoran]

>So we might say, "There is no rigorous, *scientific* proof of the

>OTOH, there actually *is* some half-way scientific evidence that Ada *does*
  The relevant question is "what is likely to make me money".  There's
rarely "rigorous, *scientific* proof" available (except on late night
TV), so you go with half baked evidence and statistical probabilities.
That's what "statistical decision theory" is about.  You have a set
of probabilities and costs, eg, 1% chance strong typing will double
productivity, 10% chance it will improve productivity by 20%, 69%
chance it will make no difference, and 20% chance it will decrease
productivity by 15%.  Given those numbers,

       Ratio of new   expected
 Prob  Productivity   value
+0.01  200%           2
+0.10  120%           12
+0.69  100%           69
+0.20  85%            17
                      = 100 %

the expected value of strong typing is the same productivity you had
before, ie, no improvement.

But if you spend money on an experiment and improve your estimates to,
say, no chance of a doubling of productivity, but a 15% chance of a 20%
improvement, and a 20% chance of only a 10% loss, then

       Ratio of new   expected
 Prob  Productivity   value
+0.00  200%           0
+0.15  120%           18
+0.65  100%           69
+0.20  90%            18
                      = 105%

Let's assume the experiment is 50-50 likely to give those results, or to
leave the original estimates untouched.  Then the expected value of the
experiment is a 2.5% improvement in your company's software costs - for
the foreseeable future.  You ought to be willing to spend up to the
discounted present value of that improvement for such an experiment.

If your company expects to employ 10 programmers for 10 years and has
a 10% discount rate, your future software costs are
10+.9*10+.9**2*10+...+.9**9*10 = 65 man years,
2.5% of that is 1.625 man years, which is what it's worth to your
company to perform the experiment.  If you have 100 programmers,
it's worth investing 16 man years in the experiment.
So the obvious question is "why haven't large companies with many
programmers and a long time horizon, done the experiment yet?"

Re: Is strong typing worth the cost?

[Marin David Condic]

<tmoran@acm.org> wrote in message
news:FnWz8.4427$4%6.2697137369@newssvr21.news.prodigy.com...
>   The relevant question is "what is likely to make me money".  There's
> rarely "rigorous, *scientific* proof" available (except on late night
> TV), so you go with half baked evidence and statistical probabilities.

This is the reason that I won't demand scientific proof before adopting Ada.
There is some reasonable level of evidence and logic behind the choice and
absolute proof isn't necessary. I've seen it make money. OTOH, there are
"skeptics" who will want more evidence than is available. For those
unwilling to approach it with an open mind, no amount of evidence will
satisfy them. The best you can hope for is that the more reasonable and
rational companies will adopt the better technology and out-compete the
rest.


> company to perform the experiment.  If you have 100 programmers,
> it's worth investing 16 man years in the experiment.
> So the obvious question is "why haven't large companies with many
> programmers and a long time horizon, done the experiment yet?"

Many of them do not perceive themselves to be in the software business.
Those that do percieve of themselves as having a large interest in software
probably have not had the idea presented in a way that makes some business
sense. Besides, its *real* hard to get R&D $$$ out of a company for anything
that starts looking "fundamental" rather than geared at directly
developing/enhancing a product. (Much more the realm of academia or the
government.)

There was the Software Productivity Consortium (is it still out there?)
which was basically an attempt by several companies to get some research
work done that was a little more "fundamental" in nature. I don't remember a
whole lot coming out of that. It might be a clever idea to propose an
experiment on language productivity under a similar aegis and get some big
software developers (including Government?) to foot the bill.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Is strong typing worth the cost?

[Dan Andreatta]

This reminds me of a test that has been done with a flight simulator, to 
check if better instrumentation results in lower problems due to 
misjudgments of the pilot. They took two sets of pilots and let them fly 
with the simulator. The first group had almost perfect instrumentation, 
while the other had a (simulated) less good instrumentation. The result was 
that the number of problems that arose were statistically equal. The first 
group relied too much on the goodness of the instruments, failing to catch 
the eventual errors of the instruments, while the other group double 
checked everything.
The only difference were that the first group was less tired after the 
flight.

Dan

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <Xns92019E29F9E8Dandreattamailchemsce@12.252.202.62>, Dan Andreatta <andreatta@mail.chem.sc.edu.REMOVEME> writes:
> This reminds me of a test that has been done with a flight simulator, to 
> check if better instrumentation results in lower problems due to 
> misjudgments of the pilot. They took two sets of pilots and let them fly 
> with the simulator. The first group had almost perfect instrumentation, 
> while the other had a (simulated) less good instrumentation. The result was 
> that the number of problems that arose were statistically equal. The first 
> group relied too much on the goodness of the instruments, failing to catch 
> the eventual errors of the instruments, while the other group double 
> checked everything.
> The only difference were that the first group was less tired after the 
> flight.

Certainly we can agree that tired people make more errors.

Re: Is strong typing worth the cost?

[Wes Groleau]

> that the number of problems that arose were statistically equal. The first
> group relied too much on the goodness of the instruments, failing to catch
> the eventual errors of the instruments, while the other group double
> checked everything.

That reminds me of one argument against the
late U.S. 55 MPH speed limit.

Proponents pointed out the proven reduction
in fatalities.

Opponents said that was only because people
were more alert trying not to get caught
while driving as fast as ever.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Preben Randhol]

On Tue, 30 Apr 2002 16:48:18 GMT, dmjones wrote:
> 
> Who mentioned safe and correct?  This is avoiding the base
> issue.  Where is the evidence of a worthwhile cost/benefit
> for strong typing?

If you want to write unsafe and non-correct programs that has a lot of
bugs and crash a lot, strong typed languages would not be the right
choice for you. A weak typed language would be much more cost efficient
to use to write such a program. For one the compilor of a weak typed
language would pass a lot more bugs at compiletime.

At least one cost/benefit of strong typing is that you save a lot of
time chasing odd bugs with your debugger. The compiler has a lot more
information to go on in order to track down bugs. Therefore it will be
able to tell you about them when you compile.

But I guess you are not looking for this either. So please sit down
think about it and come with a question that is such that we can
understand what it is that you are asking.

Preben
-- 
"Jeg tror nordmenn har glemt hvordan de tilbreder fisk. De er mest
 opptatt av firkantet fisk."
  --  Kristian Kristiansen, yrkesfisker, aftenposten.no 19/04/02

Re: Is strong typing worth the cost?

[Preben Randhol]

On Tue, 30 Apr 2002 19:01:58 +0000 (UTC), Preben Randhol wrote:
> 
> At least one cost/benefit of strong typing is that you save a lot of
> time chasing odd bugs with your debugger. The compiler has a lot more
> information to go on in order to track down bugs. Therefore it will be
> able to tell you about them when you compile.

Example (though it is trivial example):

---------------------------------------------------------
-- Weak typed version:
---------------------------------------------------------
with Ada.Text_IO;    use Ada.Text_IO;

procedure weak is

   Peter_Weight : Integer := 75;
   Peter_Height : Integer := 180;
   Ann_Weight   : Integer := 55;
   Ann_Height   : Integer := 165;

   Total_Height : Integer;
   Total_Weight : Integer;
begin

   Total_Height := Peter_Height + Ann_Weight;
   Total_Weight := Peter_Weight + Ann_Weight;

   Put_Line ("Total height is: " & Integer'Image(Total_Height));
   Put_Line ("Total weight is: " & Integer'Image(Total_Weight));
   if Peter_Weight > Ann_Height then
      Put_Line ("Peter is heavier than Ann");
   else
      Put_Line ("Ann is heavier than Peter");
   end if;

end weak;

---------------------------------------------------------

running gnatmake on weak.adb goes without any complaints and when
running the program the result is:

   Total height is:  235
   Total weight is:  130
   Ann is heavier than Peter

Hmm something doesn't seem right with that output. Let's debug.

Now let's do this a bit more strongly typed:

---------------------------------------------------------
-- Strong typed version:
---------------------------------------------------------
with Ada.Text_IO;    use Ada.Text_IO;

procedure Strong is

   type Weight_Type is range 0..500;   -- kg
   type Height_Type is range 0..200;   -- cm

   Peter_Weight : Weight_Type := 75;
   Peter_Height : Height_Type := 180;
   Ann_Weight   : Weight_Type := 55;
   Ann_Height   : Height_Type := 165;

   Total_Height : Height_Type;
   Total_Weight : Weight_Type;
begin

   Total_Height := Peter_Height + Ann_Weight;
   Total_Weight := Peter_Weight + Ann_Weight;

   Put_Line ("Total height is: " & Height_Type'Image(Total_Height));
   Put_Line ("Total weight is: " & Weight_Type'Image(Total_Weight));

   if Peter_Weight > Ann_Height then
      Put_Line ("Peter is heavier than Ann");
   else
      Put_Line ("Ann is heavier than Peter");
   end if;

end strong;
---------------------------------------------------------

Running gnatmake on strong.adb gives:

   gnatmake strong.adb
   gnatgcc -c strong.adb
   strong.adb:17:33: invalid operand types for operator "+"
   strong.adb:17:33: left operand has type "Height_Type" defined at line 6
   strong.adb:17:33: right operand has type "Weight_Type" defined at line 5
   strong.adb:23:20: invalid operand types for operator ">"
   strong.adb:23:20: left operand has type "Weight_Type" defined at line 5
   strong.adb:23:20: right operand has type "Height_Type" defined at line 6
   gnatmake: "strong.adb" compilation error

Oops I seem to have some errors in my program *BLUSH* ;-) 

OK this is very trivial, but think about this in a big complex program
where the variables are not so obvious. Say a Mars probe that crashes
due to a simple bug or whatever.

Preben

Re: Is strong typing worth the cost?

[Marin David Condic]

In fairness, I think that the problem is a little different than just
finding examples of where strong typing reduces bugs. I think all of us here
have seen numerous examples where strong type checking had caught things
that are potentially really nasty, hard to find bugs. The question seems to
be "...But is there any scientific evidence that strong type checking buys
back more than it costs?"

To a large extent, the question is ill-phrased. Do we mean just the basic
type checking that Ada does free of charge? (Not allowing you to add
Booleans to Integers, for example.) Do we mean the kind of type checking you
get by designing types for specific purposes versus relying only on
intrinsic types? (Your height & weight example, for instance.) Do we mean
designed type checking versus duplicate semantics in another language? (Some
version of implementing range checks in C on all the things you design to
have some constraints.) I'm sure we could come up with other variations on
this theme, but these are the ones I've seen so far in this thread. (Like,
are we only talking about numerical things or does that include the kinds of
type consistency that comes with enumerals, records, arrays, etc.?)

There may not be a lot of science to back it up, but I think its pretty
clear that the first and last types I described above basically cost nothing
compared to the alternative and bring lots of benefit. The one in the middle
is arguable. To do it right, you have to go through analysis and design that
tries to identify all of the necessary types and create the proper
architecture to exploit it. That costs something up front and reduces time
at the back end. The alternative (grabbing the raw data and "Just Do It"
design) costs less up front, but (based on our experience) costs a lot at
the back end. Do you save enough at the back end to justify doing the work
at the front end? We may consider that intuitively obvious to even the most
casual observer, but it is a rather Faith Based Institution. (Other than
relying on a generally accepted principle of manufacturing that the sooner
you catch a problem, the less it costs to fix. Unless, maybe you don't care
if there are problems? :-)

Is there any science to back it up? I don't know of any that addresses that
specific topic, but it would be nice if we had some. In the mean time, I'll
continue to have my faith backed up by reason and what I can see around me.
Maybe one day the science will catch up with me. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnacts3r.2qr.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> OK this is very trivial, but think about this in a big complex program
> where the variables are not so obvious. Say a Mars probe that crashes
> due to a simple bug or whatever.
>

Re: Is strong typing worth the cost?

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> In fairness, I think that the problem is a little different than just
> finding examples of where strong typing reduces bugs. I think all of us here
> have seen numerous examples where strong type checking had caught things
> that are potentially really nasty, hard to find bugs. The question seems to
> be "...But is there any scientific evidence that strong type checking buys
> back more than it costs?"

This is always hard to prove... But look at Preben example, the second version
of the program is no more complex than the first one. Both are so similar than
they certainly cost the same at the development step. But the second will
catch the error and will avoid a debug session which cost more than writing
the piece of code in the example ! As you say we all have lot of example like
this... This is no proof, we don't have resources to play the game of writing
a software in two different languages and compare the results...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Is strong typing worth the cost?

[Gary Scott]

Pascal Obry wrote:
> 
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> 
> > In fairness, I think that the problem is a little different than just
> > finding examples of where strong typing reduces bugs. I think all of us here
> > have seen numerous examples where strong type checking had caught things
> > that are potentially really nasty, hard to find bugs. The question seems to
> > be "...But is there any scientific evidence that strong type checking buys
> > back more than it costs?"
> 
> This is always hard to prove... But look at Preben example, the second version
> of the program is no more complex than the first one. Both are so similar than
> they certainly cost the same at the development step. But the second will
> catch the error and will avoid a debug session which cost more than writing
> the piece of code in the example ! As you say we all have lot of example like
> this... This is no proof, we don't have resources to play the game of writing
> a software in two different languages and compare the results...

Even with the resources, you likely won't have equal knowledge in
multiple languages in order to do the best possible job in each
language.  In a great many fields, execution performance is highly
important whereas not in others, so you also need to carefully choose
the problem you're solving in those multiple languages, possibly
designed specifically targeting specific, disparate problem domains. 
Some languages claim to be "general purpose", but usually those are weak
in numerical programming.  Those tailored for numerical programming are
often weak in "system" programming.  So no matter what you do, it
probably won't be a fair comparison.

> 
> Pascal.
> 
> --
> 
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|         http://perso.wanadoo.fr/pascal.obry
> --|
> --| "The best way to travel is by means of imagination"


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Is strong typing worth the cost?

[Marin David Condic]

I'm pretty well convinced that you can't really conduct an experiment to
demonstrate the superiority/inferiority of strong typing by using two
different languages. There is so much more to language design than just its
type model, so you can't really isolate just that one feature. The *best*
you could hope to do is demonstrate that Language A that has amongst it
weaponry strong typing, encapsulation, human readable syntax, ... (fear,
surprise, ruthless efficiency...:-) in general results in higher
productivity & quality than Language B that has weak typing, cryptic syntax,
little to no compile or runtime checking, etc. Even that would be extremely
hard to construct an experiment to demonstrate, but at least you can get it
down to one (rather large) variable. That might lead one to guess that
"strong typing" is one of the contributing factors to higher success, but it
really isn't the same as being able to demonstrate that hypothesis with any
scientific certainty.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Gary Scott" <scottg@flash.net> wrote in message
news:3CCFD76A.A60BB9A8@flash.net...
>
> Even with the resources, you likely won't have equal knowledge in
> multiple languages in order to do the best possible job in each
> language.  In a great many fields, execution performance is highly
> important whereas not in others, so you also need to carefully choose
> the problem you're solving in those multiple languages, possibly
> designed specifically targeting specific, disparate problem domains.
> Some languages claim to be "general purpose", but usually those are weak
> in numerical programming.  Those tailored for numerical programming are
> often weak in "system" programming.  So no matter what you do, it
> probably won't be a fair comparison.
>

Re: Is strong typing worth the cost?

[Darren New]

Marin David Condic wrote:
> I'm pretty well convinced that you can't really conduct an experiment to
> demonstrate the superiority/inferiority of strong typing by using two
> different languages.

I don't think you can have a single language that has both strong typing
and not strong typing. Getting rid of the strong typing in a language
allows you to replace that part of the design and coding with other
techniques.

> In general, we convince ourselves that for larger systems, failure to do any
> up front design costs a lot at the back end in terms of missed requirements,
> debugging, rework, total failure, etc.

Except there's also a lot of empirical evidence that suggests this is
not so, in some fields of software development. 

Certainly, if you're building software to run the space station, doing a
lot of up-front development is important and cost-effective.

On the other hand, if you're writing run-once software, it's pretty easy
to see that the cleanliness of the design is virtually irrelevant.
Consider software to animate a crowd of CGI characters in a movie. As
long as the end result looks good, it doesn't matter what the code looks
like. It could be the most god-awful mess of spaghetti code and misnamed
uncommented variables you can imagine, and it just doesn't matter. As
soon as the film is out, you're never going to run the program again.
Certainly if the requirement is "make the fur on the monster look
realistic", the first place to start is not the type system.

> I'm not sure that there is any
> "scientific" evidence we can point to, but certainly a lot of experience
> that tells us this ought to be "Conventional Wisdom". 

Yes. Which is why it surprised the people who abandoned such wisdom when
they were far more successful than those that came before them using
that wisdom.

> Most of us with experience doing this will contend
> that, yes, it costs something up front but it saves a lot at the back end.

I think in some environments, like where the requirements are changing
faster than you can code and test, that saving costs on code that you no
longer need by the time you've finished implementing it is not a
worthwhile expenditure, regardless of how much you save. In that
situation, the trick would be to save 100% of the costs.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Wes Groleau]

> long as the end result looks good, it doesn't matter what the code looks
> like. It could be the most god-awful mess of spaghetti code and misnamed
> uncommented variables you can imagine, and it just doesn't matter. As
> soon as the film is out, you're never going to run the program again.

That may be true if it's really "run-once" software.
But what if you want something you can use again,
something more general purpose.  So that you can
spend a hundred thousand adapting it instead of
a million starting over.

And what if it costs two million to get it working
when if it were readable and/or less buggy, it would have
cost one million?

Back to the original question, eh?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> 
> > long as the end result looks good, it doesn't matter what the code looks
> > like. It could be the most god-awful mess of spaghetti code and misnamed
> > uncommented variables you can imagine, and it just doesn't matter. As
> > soon as the film is out, you're never going to run the program again.
> 
> That may be true if it's really "run-once" software.

Well, considering that the matte paintings in the second half of Star
Wars were painted on the same scraped-clean glass that the matte
painting in the first half were painted on, yah, I'd say it's likely
run-once.

> But what if you want something you can use again,
> something more general purpose.  So that you can
> spend a hundred thousand adapting it instead of
> a million starting over.

Here you're making the assumption that the people selling the movie have
a non-zero interest in selling the software as well. I don't think it
works that way. Half the time they can't even find intact versions of
the movies themselves 10 years later, let alone the software used to
create them.

Now, maybe Pixar comes along and adds the routines to Renderman or
something, but in that case, I think Pixar would generally wind up
rewriting it from scratch anyway. The hard part is getting the
algorithms and parameters right, not implementing them correctly given
you know what they're supposed to do.

> And what if it costs two million to get it working
> when if it were readable and/or less buggy, it would have
> cost one million?

Then you just spent a million more than you thought you would. Or,
rather, you spent 2 million on software to save 20 million worth of
artists' time, rather than spending 1 million to save 20 million. 

I'm not saying strong typing is bad. I'm just saying it's not obvious
that it's always a win, because not all programming has the same
reliability requirements as the kind of "niche" ;-) that Ada works well
in.
 
> Back to the original question, eh?

Well, the original question is "is strong typing good?" I'm just trying
to point out that it's not really a yes/no question, and the right
question to ask is "is strong typing good for me?" And then you get to
define the appropriate meaning for "strong typing". Clearly, if your
programming environment is based on something like Extreme Programming,
then strong typing (as the OP seems to define it) is *not* going to be
beneficial and will probably slow you down at least to half speed if not
more.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Chad R. Meiners]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CD16B60.93078396@san.rr.com...
> Well, the original question is "is strong typing good?" I'm just trying
> to point out that it's not really a yes/no question, and the right
> question to ask is "is strong typing good for me?" And then you get to
> define the appropriate meaning for "strong typing". Clearly, if your
> programming environment is based on something like Extreme Programming,
> then strong typing (as the OP seems to define it) is *not* going to be
> beneficial and will probably slow you down at least to half speed if not
> more.
>

How so?  You assert this, but you never offer reasoning to support this
claim.

-CRM

Re: Is strong typing worth the cost?

[Darren New]

"Chad R. Meiners" wrote:
> 
> "Darren New" <dnew@san.rr.com> wrote in message
> news:3CD16B60.93078396@san.rr.com...
> > Well, the original question is "is strong typing good?" I'm just trying
> > to point out that it's not really a yes/no question, and the right
> > question to ask is "is strong typing good for me?" And then you get to
> > define the appropriate meaning for "strong typing". Clearly, if your
> > programming environment is based on something like Extreme Programming,
> > then strong typing (as the OP seems to define it) is *not* going to be
> > beneficial and will probably slow you down at least to half speed if not
> > more.
> >
> 
> How so?  You assert this, but you never offer reasoning to support this
> claim.

Um....

If you've read about Extreme Programming, it's kind of obvious. If you
haven't read about Extreme Programming, it's too much to explain.

But take, just as a simple example, the "once and only once" rule, which
says that everything should be stated in exactly one place. Ada fails
this miserably, on purpose. Ada always has at least *two* declarations
for every type, and usually a great deal more.

The compile-link-test cycle is bad for XP, in that every time you fix a
bug you have to start the program over from the beginning instead of
picking up where you found the bug. 

The inability to compile a program that makes reference to functions you
haven't written yet is bad for XP. It means you can't run the test for a
new piece of functionality without writing something about that
functionality into the code.

If you find you have one type that really should have been two types
(say, you had a "name" type, and now you decide you want a "maiden name"
type and a "current name" type), then you have to touch every place in
the code that makes any reference to a name, and update the declaration,
even if 90% of the places that a "name" is declared you don't do
anything with it except pass it to another routine that takes a "name"
as an argument. In the extreme case, if "name" was limited, you still
have to touch everyplace in the code that uses a "name" (to change the
declaration) even tho the only module that could possibly have an effect
on it is in the place where "name" is declared.

Now, if you want to know *why* these things would make XP much harder,
you'll have to go read about how XP works. If you've already done that
and have specific questions, I can try to answer them, but I can't
guarantee I'll be able to.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Wes Groleau]

> But take, just as a simple example, the "once and only once" rule, which
> says that everything should be stated in exactly one place. Ada fails
> this miserably, on purpose. Ada always has at least *two* declarations
> for every type, and usually a great deal more.

?!?!? WHAT in the world are you talking about?

> The inability to compile a program that makes reference to functions you

Ada does not require a subprogram to be written to compile
a call to it.  It does require it to be written (or a "stub"
for it) to execute the call.

Apparently you are as familiar with Ada
as I am with XP.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> 
> > But take, just as a simple example, the "once and only once" rule, which
> > says that everything should be stated in exactly one place. Ada fails
> > this miserably, on purpose. Ada always has at least *two* declarations
> > for every type, and usually a great deal more.
> 
> ?!?!? WHAT in the world are you talking about?

type age is integer range 0..50; -- that's one

x : age; -- that's two

procedure y(yy : age) is -- That's three
  z : age -- That's four
begin
  z := blah(yy);
  zilch(z);
end y;

Now, if I change X to be a date instead of an age, how many places to I
need to change it? I need to change it two places in Y's body and one
place in Y's header, and Y doesn't even care whether its argument is an
age or a date, since it doesn't do anything with it except pass it to
other functions. Imagine that blah and zilch each pass it to a couple
other modules before something interesting actually happens with it. How
many places do you have to touch? It's exactly the same sort of
wide-spread changing that OO is supposed to reduce.

Contrast this with a similar function for Y in smalltalk:

y: yy
  | z |
  z <- yy blah { this is like z := blah(yy) }
  z zilch      { this is like zilch(z) }

If YY changes from an integer to a disk-based database, you don't have
to touch this function, because the type information is irrelevant to
the y routine.  (Actually, the syntax isn't quite right for the
smalltalk, and I don't remember the comment character for smalltalk, but
you get the idea.)


> > The inability to compile a program that makes reference to functions you
> 
> Ada does not require a subprogram to be written to compile
> a call to it.  It does require it to be written (or a "stub"
> for it) to execute the call.

It requires the subprogram to be declared to compile a call to it, and
it requires the subprogram to be implemented to link. (The difference
between being able to compile and being able to link is kind of academic
when the goal is to do both at least five times an hour, so I wasn't
really distinguishing all the steps between "finish writing" and "being
able to run".) In addition, it requires that you declare all the types
you use before you write the code that uses them. For example, you can't
compile (let alone link and run) the test that checks that the day
before tomorrow is today without declaring your date type, the
"tomorrow" routine, the "day before" routine, comparison of dates, and
etc. 

Basically, you can't run a program that makes a call on an undeclared
subprogram. Which means you can't write a unit test that fails without
touching the the production code. Before you can run a test, you have to
already have started to implement the functionality that makes the test
pass. This is a no-no.

In Smalltalk, for example, the program will run until it gets to the
unimplemented call, and pop up a debugger. At that point, you can
implement the function called, and then tell the debugger to resume from
where it was interrupted.  I haven't seen any Ada system that will let
you come close to the ease of debugging that Smalltalk allows.

> Apparently you are as familiar with Ada
> as I am with XP.

Err, no. Apparently, you don't understand enough about XP to even have
an idea of why Ada is poorly suited to it. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Aidan Skinner]

On Thu, 02 May 2002 23:52:46 GMT, Darren New <dnew@san.rr.com> wrote
in <3CD1D17B.F60DCB89@san.rr.com>:

>  subprogram. Which means you can't write a unit test that fails without
>  touching the the production code. Before you can run a test, you have to

Yes you can. It's just that your test suite fails to compile. Which is
a pretty big failure. ;)

>  implement the function called, and then tell the debugger to resume from
>  where it was interrupted.  I haven't seen any Ada system that will let
>  you come close to the ease of debugging that Smalltalk allows.

Neither have I. But then I haven't seen many systems that allow the
ease of debugging that Smalltalk allows.

> > Apparently you are as familiar with Ada
> > as I am with XP.
>  
>  Err, no. Apparently, you don't understand enough about XP to even have
>  an idea of why Ada is poorly suited to it. 

I don't think Ada is really that poorly suited to it. OnceAndOnlyOnce
is harder to achieve than in Smalltalk (for reasonably strict
interpretations of OAOO), but then there are few languages as well
suited to XP as Smalltalk. Which is hardly surprising, given XPs
history.

OTOH, Ada's strong typing can be used to mitigate some of the same
problems as OAOO. Specifically the "one of the versions will be out of
date" problem. In your example the compiler will catch the change of
parameter type and tell me about it. It will take slightly longer to
fix than if it was in Smalltalk, but won't lead to buggy code
compiling.

Further, it's strong typing actively *aids* OAOO in the case where
you're doing range checking etc, you can leave it up to the compiler
in most places. :)

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint |Unix Programmer/Admin actively seeking work
01AA 1594 2DB0 09E3 B850       |CV at http://www.velvet.net/~aidan/cv.txt
C2D0 9A2C 4CC9 3EC4 75E1       |Gis a job, go on, I can do that, go on, gis it.

Re: Is strong typing worth the cost?

[Aidan Skinner]

On Fri, 3 May 2002 00:17:15 +0000 (UTC), Aidan Skinner
<aidan@velvet.net> wrote in <slrnad3lob.l1o.aidan@crushed.velvet.net>:

[snip discussion of XP]

There's a node on the c2 wiki on ada:
http://c2.com/cgi/wiki?ExtremeAdaExperiment

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint |Unix Programmer/Admin actively seeking work
01AA 1594 2DB0 09E3 B850       |CV at http://www.velvet.net/~aidan/cv.txt
C2D0 9A2C 4CC9 3EC4 75E1       |Gis a job, go on, I can do that, go on, gis it.

Re: Is strong typing worth the cost?

[Wes Groleau]

> type age is integer range 0..50; -- that's one
> 
> x : age; -- that's two
> 
> procedure y(yy : age) is -- That's three
>   z : age -- That's four
> begin
>   z := blah(yy);
>   zilch(z);
> end y;

OK, I take back the comment about your Ada knowledge.
Still, only one of these declares a type.  Your terminology
induced misunderstanding.

> Now, if I change X to be a date instead of an age, how many places to I
> need to change it? I need to change it two places in Y's body and one

Sure.  But changing something from "Date" to "Age" in the middle
of the project is a sure sign you didn't have a clue what
you were working on when you started!  Changing from an integer
to a disk-based database is even more extreme (pun intended).

When they are used in a place where it truly doesn't
matter, a generic or a tagged type might be appropriate.

In either case, scripting a global change is quite easy.
Of course, you still get stuck with recompilation.


> > > The inability to compile a program that makes reference to functions you
> >
> > Ada does not require a subprogram to be written to compile
> > a call to it.  It does require it to be written (or a "stub"
> > for it) to execute the call.
> 
> It requires the subprogram to be declared to compile a call to it, and
> it requires the subprogram to be implemented to link. (The difference

No, to link you only need a stub, if you are not debugging
that subroutine.  If you are, the obviously it has to be written
either way.

> between being able to compile and being able to link is kind of academic
> when the goal is to do both at least five times an hour, so I wasn't

You make it sound like XP is a euphemism for rapid trial and error.

Why not make a hundred copies of the program each cycle,
make random changes, and keep the few that look promising?
Genetic algorithm--sort of.

Seriously, when I have to debug Ada I can (usually)
EASILY compile and run five or ten times an hour.
But I rarely need five or ten tries to make it work.

And when it's old code, those irritating declarations
help my changes to be based on understanding instead of
guessing or random changes.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> OK, I take back the comment about your Ada knowledge.
> Still, only one of these declares a type.  Your terminology
> induced misunderstanding.

Fair enough. Actually, when I said "every type has to be declared
twice", I was thinking about subprogram declarations, so yes, my bad.

Limited types wind up being declared twice, in general, yes? Once in the
"public" part of the spec and once in either the private part or the
body? Subprogram names show up at least twice (at the start and end of
the subprogram) and usually in the package spec too. Etc.

> > Now, if I change X to be a date instead of an age, how many places to I
> > need to change it? I need to change it two places in Y's body and one
> 
> Sure.  But changing something from "Date" to "Age" in the middle
> of the project is a sure sign you didn't have a clue what
> you were working on when you started!  Changing from an integer
> to a disk-based database is even more extreme (pun intended).

Well, yes and no. One of the points of XP is that you *don't* know
everything you're going to put in the code before you start. Secondly,
again, XP is for where the specs change over the lifetime of the
development. If you're running (say) a payroll system, you can't
possibly predict what Congress is going to want to see on tax reports
three years from now. XP explicitly says don't even *look* at
requirements that are more than a week away from being implemented.

I picked date->age specifically because I used to write life insurance
proposal software, and that kind of change got to be so common that I
made up a special UI widget that would accept either a date or an age,
as an example. 

> When they are used in a place where it truly doesn't
> matter, a generic or a tagged type might be appropriate.

That only works if you know when you declare the type that it's going to
be used in ways where it doesn't matter. I.e., you have to plan ahead to
make it a generic or tagged type. And if you change it from non-generic
to generic, you now have to go find all the places you used the
non-generic type and instantiate the right thing, and etc. Again, a lot
more changes than you would need with a dynamically-typed system.

And then when you refactor and move some of the routines into a
different package, then you have to find every reference to it and
change the "with" clause and the "use" clause or the fully-qualified
calls.
 
> In either case, scripting a global change is quite easy.

Well, unless there's other people working on other stuff in the same
package, yes. :-?  No question that you can *work around* all the extra
work that Ada makes you do when you frob requirements twice a week. But
it's certainly more efficient to code in a language with less
redundancy, and XP advocates claim it's more efficient to get a working
result as well.

> > > Ada does not require a subprogram to be written to compile
> > > a call to it.  It does require it to be written (or a "stub"
> > > for it) to execute the call.
> >
> > It requires the subprogram to be declared to compile a call to it, and
> > it requires the subprogram to be implemented to link. (The difference
> 
> No, to link you only need a stub, if you are not debugging
> that subroutine.  If you are, the obviously it has to be written
> either way.

You've still implemented the stub. To run the test, you still have to
code the declaration of the subprogram and you still have to code the
body of the subprogram. The body doesn't have to be *right*, but it
still has to be coded.

> > between being able to compile and being able to link is kind of academic
> > when the goal is to do both at least five times an hour, so I wasn't
> 
> You make it sound like XP is a euphemism for rapid trial and error.

Yes, amongst other techniques. It's a whole raft of maybe a dozen
different techniques that basically make rapid trial and error work
better (so it's claimed) than thinking things out well in advance and
planning before coding. One of the rules is that every bit of knowledge
in the program is coded exactly once, which Ada doesn't do, as
demonstrated above. Another of the rules is that you never touch the
productive code unless there's a test that fails. I suppose you could
count "won't compile" as a failed test, but since XP uses Smalltalk and
the only reason for something not to compile is a very localized syntax
error, its hard to say whether an XPer would say "fails to compile"
counts as a failing test.
 
> Why not make a hundred copies of the program each cycle,
> make random changes, and keep the few that look promising?
> Genetic algorithm--sort of.

Well, you could, but it wouldn't be XP.
 
> Seriously, when I have to debug Ada I can (usually)
> EASILY compile and run five or ten times an hour.
> But I rarely need five or ten tries to make it work.

No, the point of 5 or 10 changes an hour is that you implement 5 or 10
requirements per hour. 
 
> And when it's old code, those irritating declarations
> help my changes to be based on understanding instead of
> guessing or random changes.

I'm not trying to say XP is superior to the normal mechanisms used by
Ada. I'm just saying that *if* you're doing XP, doing it with something
like Smalltalk is better than doing it with something like Ada, in part
because of the strictness of Ada's type system that requires extra work
to make things compile/link and extra redundancy that assures the
compiler you mean what you said.

In other words, saying that strict typing is always superior is wrong,
unless you want to throw away all the experience of successful XP-based
development as being irrelevant or bogus in some other way. I.e., there
*is* evidence that weak typing buys you something, namely, the ability
to be more agile in the face of rapidly-changing specifications.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Wes Groleau]

> You've still implemented the stub. To run the test, you still have to
> code the declaration of the subprogram and you still have to code the
> body of the subprogram. The body doesn't have to be *right*, but it
> still has to be coded.

I must be missing something.  Why do you want to
run a test when the item being tested doesn't
exist?

> count "won't compile" as a failed test, but since XP uses Smalltalk and

I avoided saying it until you brought it up, but
in the limited reading on XP that I've done. it
continues to look like a methodology designed to
promote Smalltalk and to not work with anything else.
If "extreme programming IS Smalltalk" why fault Ada
for not "fitting in" ?

> > Why not make a hundred copies of the program each cycle,
> > make random changes, and keep the few that look promising?
> > Genetic algorithm--sort of.
> 
> Well, you could, but it wouldn't be XP.

Sounds like it would be a faster version of the same thing.

> I'm not trying to say XP is superior to the normal mechanisms used by
> Ada. I'm just saying that *if* you're doing XP, doing it with something
> like Smalltalk is better than doing it with something like Ada, in part
> because of the strictness of Ada's type system that requires extra work
> to make things compile/link and extra redundancy that assures the
> compiler you mean what you said.

Since XP and Smalltalk seem to be in a chicken and egg
cycle, I think "Is Ada bad for XP?" is not a very useful
question.  A better question would be,

  "For a particular application domain, does using
   Smalltalk with XP or Ada with its 'best practices'
   produce better code sooner?"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> 
> > You've still implemented the stub. To run the test, you still have to
> > code the declaration of the subprogram and you still have to code the
> > body of the subprogram. The body doesn't have to be *right*, but it
> > still has to be coded.
> 
> I must be missing something.  Why do you want to
> run a test when the item being tested doesn't
> exist?

Already addressed with at least two examples. See the other XP papers.

> > count "won't compile" as a failed test, but since XP uses Smalltalk and
> 
> I avoided saying it until you brought it up, but
> in the limited reading on XP that I've done. it
> continues to look like a methodology designed to
> promote Smalltalk and to not work with anything else.

Errr, no. Only someone who thinks it's trying to promote one language at
the price of another would think that. Smalltalk fits very well with XP,
and the folks who invented XP (or at least who first popularized it) use
Smalltalk to its best advantage. 

> If "extreme programming IS Smalltalk" why fault Ada
> for not "fitting in" ?

Where do I "fault" Ada? I'm simply saying that Ada doesn't seem like it
would work very well with XP to me. Nor would I use Smalltalk in a
safety-critical real-time embedded system. Is that a fault of Smalltalk?
 
> > > Why not make a hundred copies of the program each cycle,
> > > make random changes, and keep the few that look promising?
> > > Genetic algorithm--sort of.
> >
> > Well, you could, but it wouldn't be XP.
> 
> Sounds like it would be a faster version of the same thing.

Err, no.
 
> > I'm not trying to say XP is superior to the normal mechanisms used by
> > Ada. I'm just saying that *if* you're doing XP, doing it with something
> > like Smalltalk is better than doing it with something like Ada, in part
> > because of the strictness of Ada's type system that requires extra work
> > to make things compile/link and extra redundancy that assures the
> > compiler you mean what you said.
> 
> Since XP and Smalltalk seem to be in a chicken and egg
> cycle, I think "Is Ada bad for XP?" is not a very useful
> question.  A better question would be,

That wasn't the question I'm trying to answer. See the subject line.

The question I'm trying to answer is "is strong (static) typing always
superior to dynamic typing?" (Note that Smalltalk doesn't have weak
typing, but rather dynamic typing, so I'm fudging the question just a
touch to actually address something slightly different.) If the question
is "is strong typing worth the cost", then I'd argue "Not if you're
using an XP development cycle." 

That is, *given* that you've chosen to use XP, which will work better, a
dynamically-typed language or a statically-typed language. I think the
answer there is that a dynamically-typed language will work better.
 
>   "For a particular application domain, does using
>    Smalltalk with XP or Ada with its 'best practices'
>    produce better code sooner?"

And since the OP didn't state their particular application domain, I'd
say this is an impossible questin to answer. And the OP didn't ask this
question either. My only point is that there are times when strong
typing (as the OP seemed to mean it)is not worth the cost. Not that Ada
is good or bad or that Smalltalk is good or bad or that XP is good or
bad.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[tmoran]

"... it can be seen that there are two main problems with the development
of software:  the need to reuse software components as much as possible
and the need to establish disciplined ways of working."  Programming in
Ada 95, 2nd edition, p.4, by John Barnes.
  Sounds to me as if Ada addresses the first of those and XP addresses
the second, no?

Re: Is strong typing worth the cost?

[Darren New]

tmoran@acm.org wrote:
> 
> "... it can be seen that there are two main problems with the development
> of software:  the need to reuse software components as much as possible
> and the need to establish disciplined ways of working."  Programming in
> Ada 95, 2nd edition, p.4, by John Barnes.
>   Sounds to me as if Ada addresses the first of those and XP addresses
> the second, no?

I think there's a great deal of discipline used by those who do
large-scale Ada development. I also think XP encourages a lot of reuse
of software. (Indeed, the "once and only once" mantra could be
considered a recommendation that software be maximally reused.) 

I think Ada is a programming language with a philosophy of programmers
spending a lot of forethought and planning up front to get a
high-quality robust result.

I think XP is a programming philosophy where you spend a minimum of
forethought and planning up front (for various reasons having to do with
the nature of the requirements) and hence works well in a language where
you don't need to do a lot of planning up front to get an initial
result. The rest of XP is basically how to get a high-quality result in
spite of not planning very far ahead.

Personally, I like both Ada and Smalltalk. I wouldn't use them for the
same thing, tho.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Preben Randhol]

On Tue, 07 May 2002 15:21:28 GMT, Darren New wrote:

[...]
> I also think XP encourages a lot of reuse
> of software. (Indeed, the "once and only once" mantra could be
> considered a recommendation that software be maximally reused.) 
[...]
and 

> I think XP is a programming philosophy where you spend a minimum of
> forethought and planning up front (for various reasons having to do with
> the nature of the requirements) and hence works well in a language where
> you don't need to do a lot of planning up front to get an initial
> result. The rest of XP is basically how to get a high-quality result in
> spite of not planning very far ahead.

Though only a myth, the story of the armed army of kangaroos springs to
mind when you say this :-)

(URL => http://www-users.cs.umn.edu/~heimdahl/csci5802/misc/killer-kangas.htm)

Preben

Re: Is strong typing worth the cost?

[Wes Groleau]

> Basically, you can't run a program that makes a call on an undeclared
> subprogram. Which means you can't write a unit test that fails without
> touching the the production code. Before you can run a test, you have to
> already have started to implement the functionality that makes the test
> pass. This is a no-no.

??
You can write anything any time.

You can compile as soon as the INTERFACE is declared.

You can link and run if ANYTHING that has that
interface is compiled.  It doesn't have to be
something that "makes the test pass."  It can
even be something that you KNOW will fail--in
which case, why waste time running the test?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> You can link and run if ANYTHING that has that
> interface is compiled.  It doesn't have to be
> something that "makes the test pass." 

Correct. But you've still started implementing the code, which is one
step more than you need to go.

> It can
> even be something that you KNOW will fail--in
> which case, why waste time running the test?

Because you *don't* know it will fail. And perhaps adding that
declaration made some *other* test fail. So now you know it was the very
declaration making the other test fail (perhaps by overloading something
that used to work) rather than the body of the code.

> Anyone who feeds you slogans instead of information
> is selling something.  The above slogan is selling XP.

Well, anyone who bases their opinion of an entire programming
methodology on "the first thing that caught my eye" is unlikely to make
any sort of radical shift in their methodologies, I think. Of course
they're selling XP. That's what the paper you printed out is. It's an
introduction to XP, i.e., "why do I want to learn more?"

Chad sez:
> For this you could be break the one type into three
> types thus keeping Name as a generic placeholder for 'don't care' while
> deriving Current_Name and Maiden_Name from Name.

Assuming that "Name" is a tagged type to start with. If Name is an array
of characters, I would think changing
  x(15..20) := "123456";
in the code to something that works with tagged types is going to be
difficult to do without touching the code outside the package that
declares Name. Or is there something I'm misunderstanding in Ada?

> You  failed to show how strong typing must slow you down in XP.  You can
> always elect not to define a type or you could define an object type that
> you derive all of your types from.

And if you elect not to define a type or define one type that every
object in your program is derived from, then you've basically given up
strong typing. I also believe it's impossible in Ada, because integers,
floats, tasks, generic packages, etc are not tagged types.

That Ada makes it possible in many ways to get around the strong typing
is a testiment to Ada's power. Since weak typing is basically a subset
of strong typing, yes, you can do this. But I doubt any 100,000-line
program where every user-defined type is derived from the same object is
going to be considered "good Ada style".

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Wes Groleau]

> > It can
> > even be something that you KNOW will fail--in
> > which case, why waste time running the test?
> 
> Because you *don't* know it will fail. And perhaps adding that
> declaration made some *other* test fail. So now you know it was the very

If it's a stub, you _do_ know it will fail.
And if you aren't sure whether a stub will
break something it doesn't call, you REALLY
chose the wrong language.


> > Anyone who feeds you slogans instead of information
> > is selling something.  The above slogan is selling XP.
> 
> Well, anyone who bases their opinion of an entire programming
> methodology on "the first thing that caught my eye" is unlikely to make

I don't base my opinion on it.  I just couldn't help
but notice the obvious marketing technique in the very
statement that puts down marketing.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Darren New]

Wes Groleau wrote:
> 
> > > It can
> > > even be something that you KNOW will fail--in
> > > which case, why waste time running the test?
> >
> > Because you *don't* know it will fail. And perhaps adding that
> > declaration made some *other* test fail. So now you know it was the very
> 
> If it's a stub, you _do_ know it will fail.

Only if you write the stub. See, in Smalltalk, everything's an object.
So maybe the parent class already takes care of this.

Or, in another case, maybe you're writing code to handle (say)
misformatted records, and there aren't any misformatted records in your
data.

You can check the XP sites for other real live examples of where folks
thought the test would fail and it didn't.

Anyway, this is the XP philosophy. I can't say it's right. I'm just
saying that strong typing makes it harder to do it.

> And if you aren't sure whether a stub will
> break something it doesn't call, you REALLY
> chose the wrong language.

Again, OO. If you implement something broken that overrides something
working, you're going to break something, yes?
 
> I don't base my opinion on it.  I just couldn't help
> but notice the obvious marketing technique in the very
> statement that puts down marketing.

I think what they were trying to say is that they're giving you real
experience rather than simply saying "here's something that ought to
work." That is, if I remember right the paper you're talking about.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Wes Groleau]

> Err, no. Apparently, you don't understand enough about XP to even have
> an idea of why Ada is poorly suited to it.

Well, I've been too busy to look into it.  But I finally
printed out an intro to read in the bathroom.  :-)

First thing that caught my eye as I was clicking 'print':

  Listening, Testing, Coding, Designing.
  That's all there is to software.
  Anyone who tells you different is selling something. 

Anyone who feeds you slogans instead of information
is selling something.  The above slogan is selling XP.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Marin David Condic]

Are they supposed to be done in that order? :-)

I seem to recall the Waterfall model had Requirements (Listening), Design,
Code and Test, which doesn't sound too different. The more things change,
the more they stay the same? :-)

Assuming we all agree that all four of these things need to be done, then
the rest is just a matter of how much and when. Development processes can
always be tuned based on the needs of the organization and the applications
involved.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CD2AEE4.850F28C4@despammed.com...
>
>   Listening, Testing, Coding, Designing.
>   That's all there is to software.
>   Anyone who tells you different is selling something.
>

Re: Is strong typing worth the cost?

[Randy Brukardt]

Darren New wrote in message <3CD1D17B.F60DCB89@san.rr.com>...

>Now, if I change X to be a date instead of an age, how many places to I
>need to change it? I need to change it two places in Y's body and one
>place in Y's header, and Y doesn't even care whether its argument is an
>age or a date, since it doesn't do anything with it except pass it to
>other functions.

This is a tools problem, not a language problem. I can easily imagine a
programming system for Ada that included a command that let you change
the current declaration and all of its uses. That isn't even that hard
to implement (think ASIS tool).

>It's exactly the same sort of
>wide-spread changing that OO is supposed to reduce.


It seems unusual to be changing your objects so fundementally that you
would want to change the name.

>It requires the subprogram to be declared to compile a call to it, and
>it requires the subprogram to be implemented to link. (The difference
>between being able to compile and being able to link is kind of
academic
>when the goal is to do both at least five times an hour, so I wasn't
>really distinguishing all the steps between "finish writing" and "being
>able to run".)

Again, the whole idea of "compile" and "link" is based on the
"conventional" way to look at Ada. You will find very little in the
standard that assumes this model, for the very simple reason that the
designers believed that it would someday be useful to use a different
model. The only real requirement for error handling in Ada is that
"compile-time" errors are detected before the program begins to execute.

So, again, this is a tools problem. With some imagination, it isn't
unreasonable to think of an Ada programming environment which completely
did away with visible notions of compilation. Essentially, the
environment would compile the source as it is needed; no explicit
commands needed. Certainly, if XP catches on big-time, you'll see
environments like that for all programming languages.

>Err, no. Apparently, you don't understand enough about XP to even have
>an idea of why Ada is poorly suited to it.


I'll grant you that existing Ada environments are poorly suited to XP.
It's unclear if the language really is, or if it is simply a deficiency
of the current environments.

               Randy.

Re: Is strong typing worth the cost?

[Ed Falis]

Randy Brukardt wrote:
> Darren New wrote in message <3CD1D17B.F60DCB89@san.rr.com>...

>>Err, no. Apparently, you don't understand enough about XP to even have
>>an idea of why Ada is poorly suited to it.
> 
> 
> 
> I'll grant you that existing Ada environments are poorly suited to XP.
> It's unclear if the language really is, or if it is simply a deficiency
> of the current environments.

I don't buy either argument.  While I haven't done full-up XP, I've 
certainly done test-first development a la XP quite effectively, using 
AUnit and the capability in Glide for generating its boilerplate code. 
I also approximate DbC using pragma Assert.  It works well, and is 
within the spirit of XP.  GNAT is quite fast enough for test-first 
flavored development, as you tend not to have a lot of context in unit 
tests.

Admittedly, refactoring would be easier without manifest typing, but 
that's a tradeoff, and tool support is possible.

- Ed

disclaimer: ACT employee

Re: Is strong typing worth the cost?

[Brian Rogoff]

On Fri, 3 May 2002, Ed Falis wrote:
> Randy Brukardt wrote:
> > I'll grant you that existing Ada environments are poorly suited to XP.
> > It's unclear if the language really is, or if it is simply a deficiency
> > of the current environments.
>
> I don't buy either argument.  While I haven't done full-up XP, I've
> certainly done test-first development a la XP quite effectively, using
> AUnit and the capability in Glide for generating its boilerplate code.
> I also approximate DbC using pragma Assert.  It works well, and is
> within the spirit of XP.  GNAT is quite fast enough for test-first
> flavored development, as you tend not to have a lot of context in unit
> tests.

I agree with all that. I don't think the X in XP is so extreme that the
verbosity of Ada causes your keys to get hot because of all the extra
pounding. And GNAT is a very quick, and has excellent error reporting
facilities.

> Admittedly, refactoring would be easier without manifest typing, but
> that's a tradeoff, and tool support is possible.

Excellent observation, and well phrased too. Note that Ed says *manifest*
typing. It's certainly possible to have languages with strong, static
(static = compile time) typing that do some type inference, and this can
reduce the refactoring burden. One of the few things I like a lot better
in C++ than in Ada is that C++ templates get some implicit instantiation.
I'd love it if there was an Ada variant with some kind of implicit
instantiation.

-- Brian

Re: Is strong typing worth the cost?

[Chad R. Meiners]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CD1B496.DBE8ADC4@san.rr.com...
> Um....
>
> If you've read about Extreme Programming, it's kind of obvious. If you
> haven't read about Extreme Programming, it's too much to explain.
>

Nevertheless, you failed in your attempt to address my concern since you
never showed how strong typing as the OP mentioned slows the extreme
programmer down.  Perhaps you should be more careful with your responses.

Re: Is strong typing worth the cost?

[Darren New]

"Chad R. Meiners" wrote:
> Nevertheless, you failed in your attempt to address my concern since you
> never showed how strong typing as the OP mentioned slows the extreme
> programmer down.  Perhaps you should be more careful with your responses.

I think I did a fairly good job of showing how it slows down the extreme
programmer. You just snipped it out. In what way did I fail to address
your questions?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Chad R. Meiners]

You mentioned dividing one type into two and claimed that you had to X cost
when it should be Y.  For this you could be break the one type into three
types thus keeping Name as a generic placeholder for 'don't care' while
deriving Current_Name and Maiden_Name from Name.  Although this in some
cases may not be a elegant solution; after reading a primer about XP, I have
discovered XP is in some ways against elegant solutions so this just in time
hack should be very appropriate. ;-)   (I wonder what happens when you throw
a non-obviously NP-Complete problem at the XP process infinite loop,
perhaps? ;-)

You  failed to show how strong typing must slow you down in XP.  You can
always elect not to define a type or you could define an object type that
you derive all of your types from.  You showed how you could slow yourself
down intentionally by using strong typing, but you clearly failed to show
how strong typing in and of itself slows you down in XP.

"Darren New" <dnew@san.rr.com> wrote in message
news:3CD1DE85.C00AD2A9@san.rr.com...
> I think I did a fairly good job of showing how it slows down the extreme
> programmer. You just snipped it out. In what way did I fail to address
> your questions?
>

Re: Is strong typing worth the cost?

[Marin David Condic]

Part of the problem here is that it is not at all clear or obvious that XP
is any good for anything at all. Does XP result in faster time to market
than some other development process? Maybe. Maybe not. It is not proven
AFAIK that following an XP process is going to get you to market sooner.
Does it result in more reliable software? Unclear. Does it result in lower
overall costs for software? Similarly unclear. It may be well suited to some
domains and not to others. Its a development strategy that might have some
intellectually satisfying characteristics, but (like strong typing in
isolation) it isn't proven to be "The Answer" for any or all development
problems. It also is not demonstrated that you can't modify or abandon any
individual elements of an XP methodology without destroying any of the
benefits it might yield.

From what I've read of XP it seems to be kind of a "religion" that might be
really appealing to the "Hacker Mentality" since it deliberately avoids lots
of formal stuff that seems to chafe at the free spirits out there. But since
XP is really a development process (kind of a variation on the "spiral
model" theme) - then like any other process, I don't see why it can't be
adapted to suit the demands of an organization. (Unless, of course, one
accepts every pronouncement of XP as an article of faith that cannot be
denied without commiting an act of heresy. :-) So likewise, I don't see why
XP cannot be adapted to programming in Ada, presuming that there is any
food-value to be had by doing so to begin with. For example, if some aspect
of XP is easy to do with pointers to functions but it is considered some
kind of apostasy to use subprogram stubs, then commit the apostasy and use
subprogram stubs. (You can usually generate them automatically - or at least
pretty quickly). I don't think its at all obvious that this would "destroy"
XP or mean that if XP has some benefit that the benefit is lost.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:aaturp$10tn$1@msunews.cl.msu.edu...
> You  failed to show how strong typing must slow you down in XP.  You can
> always elect not to define a type or you could define an object type that
> you derive all of your types from.  You showed how you could slow yourself
> down intentionally by using strong typing, but you clearly failed to show
> how strong typing in and of itself slows you down in XP.
>

Re: Is strong typing worth the cost?

[Darren New]

Marin David Condic wrote:
> Part of the problem here is that it is not at all clear or obvious that XP
> is any good for anything at all.

Well, you can ignore all the information provided by the people actually
doing XP, but I don't imagine doing so would be any more productive than
ignoring the information that evidences that strong typing reduces
bugcount when you're not doing XP.

> From what I've read of XP it seems to be kind of a "religion" that might be
> really appealing to the "Hacker Mentality" since it deliberately avoids lots
> of formal stuff that seems to chafe at the free spirits out there.

Um, I think you've not read enough. Or you've read it thru
preconception-filters that keep you from seeing what's going on there.
Not saying that it's good or bad, but it's certainly nothing that a
cowboy coder could ever manage. The process is quite formal. It's just
not "waterfall".

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marin David Condic]

Maybe. Maybe not. I have not made a thorough study of it, but have read some
descriptions of it. But as for "Waterfall" - I don't think anybody ever
actually did anything of significance in a pure "Waterfall" method - even if
they say they did. Almost any project of size has to deal with changes
midstream that require going back to revisit requirements or design or other
things along the way - thus really creating a kind of spiral model. Most of
the projects I've been on have involved iterative builds of some sort - how
fast and when are always an issue.

Keep in mind that a lot of technologies have come out where adherents start
to think they have found a panacea - including Ada. Usually, you gain
something and give something else up along the way. Not that Ada or XP or
<insert the next hip thing here> isn't going to possibly produce a step
forward, but usually it isn't as "revolutionary" as the marketers would have
you believe and you still need something approximating "science"
demonstrating that it does some good (and in what circumstances) rather than
relying on gut instinct, perceptions or theory. Software really has a hard
time with this.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3CD329FE.C067B6CE@san.rr.com...
>
> Um, I think you've not read enough. Or you've read it thru
> preconception-filters that keep you from seeing what's going on there.
> Not saying that it's good or bad, but it's certainly nothing that a
> cowboy coder could ever manage. The process is quite formal. It's just
> not "waterfall".
>

Re: Is strong typing worth the cost?

[Darren New]

Marin David Condic wrote:
> 
> Maybe. Maybe not. I have not made a thorough study of it, but have read some
> descriptions of it. But as for "Waterfall" - I don't think anybody ever
> actually did anything of significance in a pure "Waterfall" method - even if
> they say they did. Almost any project of size has to deal with changes
> midstream that require going back to revisit requirements or design or other
> things along the way - thus really creating a kind of spiral model. Most of
> the projects I've been on have involved iterative builds of some sort - how
> fast and when are always an issue.

Sure. But by "waterfall" I mean the development model where first you
talk to the customers and get all the requirements, then you plan how
you're going to structure the code, then .....

In XP, if you can't implement it this week, it's not a requirement. You
don't even consider it. It's off the scope.

> Keep in mind that a lot of technologies have come out where adherents start
> to think they have found a panacea - including Ada. Usually, you gain
> something and give something else up along the way.

Yep. I think there are a lot of situations where XP is not effective.
Pair Programming is going to be very difficult if you don't have
everyone in the same office. If you don't have a customer there to tell
you the next set of requirements every day/week and to answer questions,
it's likely not to work well. If the project is big enough that you need
more than about a dozen programmers, I don't think it would work well.
If it's a system where a language like Smalltalk isn't reasonable (say,
embedded or real-time systems) it's not going to work. If it's a system
where you aren't developing on the same class of machines that you're
deploying on, it's not going to work well. I'm told that it works well
for things like libraries and components for general distribution, but I
don't really believe that, due to the customer not being there. Etc.

I don't think it's a panacea at all. Perhaps some of the proponents do.
Again, I only brought it up as an example of a situation in which strong
typing *might* be more of a cost than a benefit.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Chad R. Meiners]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CD7F29C.196F8D20@san.rr.com...
> I don't think it's a panacea at all. Perhaps some of the proponents do.
> Again, I only brought it up as an example of a situation in which strong
> typing *might* be more of a cost than a benefit.

I can see your case for might.  I misunderstood that you were trying to show
a must.

-CRM

Re: Is strong typing worth the cost?

[Marin David Condic]

I have absolutely no argument with the notion that different problem domains
are going to have different cost drivers. I believe I said somewhere else
that if you didn't care about bugs and you didn't care about maintenance,
then design work was just an up-front cost with little to no back end
payoff. (With the caveat that if you do *no* design, your project might just
fail entirely.)

One might reasonably ask: "Couldn't the animation software be well built and
still do its job?" Is it of necessity spaghetti code? Is it somehow or other
faster to get the job done to just start plodding along laying down code
until the animation looks right? I suspect that if the hypothetical
animation developers did *some* analysis and design up front and *did* build
solid, reliable code that it would possibly not take any longer to get to
market and might yield larger chunks of things that could be reused & save
time/money on the next animation. (I wouldn't go to the extremes of analysis
& design done for safety critical software, but surely the animator still
needs to do some amount of "debugging" to get the thing to work at all and
surely that means if there were better forthought and stronger checks, lots
of those problems might be minimized.)

I see the point that throw-away code need not be well built. But it is not
demonstrated that this is somehow faster or better or cheaper than
well-built code to do the same thing.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3CD0A3B8.7B7C8622@san.rr.com...
>
> On the other hand, if you're writing run-once software, it's pretty easy
> to see that the cleanliness of the design is virtually irrelevant.
> Consider software to animate a crowd of CGI characters in a movie. As
> long as the end result looks good, it doesn't matter what the code looks
> like. It could be the most god-awful mess of spaghetti code and misnamed
> uncommented variables you can imagine, and it just doesn't matter. As
> soon as the film is out, you're never going to run the program again.
> Certainly if the requirement is "make the fur on the monster look
> realistic", the first place to start is not the type system.
>

Re: Is strong typing worth the cost?

[Gary Scott]

Marin David Condic wrote:
> 
> I have absolutely no argument with the notion that different problem domains
> are going to have different cost drivers. I believe I said somewhere else
> that if you didn't care about bugs and you didn't care about maintenance,
> then design work was just an up-front cost with little to no back end
> payoff. (With the caveat that if you do *no* design, your project might just
> fail entirely.)

Nearly everything I develop is likely to be categorized as Q&D code by
the those in this NG.  However, I think I produce fairly high quality
Q&D code.  I've done this by being highly "modular" and building up a
huge library of utility code that suits my typical problem domain
(avionics modeling and data analysis).  I can put together a Q&D
application (with GUI) very rapidly and still have 99% cross-platform
portable code, with all platform portability modifications located in
one or a few modules (i.e. packages).  So, I don't necessarily agree
with some that Q&D always means poor quality.  I'm not a programmer and
I've been asked to provide source to some of my tools on a number of
occasions to programming teams and have received occasional complements
on the structure, comment quality, etc.  I do not perform a formal
design process.  In fact for the last major tool, the team making the
request was not versed in software and had little idea what it needed to
do so I had to make it up as I went by dragging it out of them and an
avionic equipment vendor (verbal inputs and emails)...it seems to have
turned out well and cost 1/10 of what the subcontractor originally
estimated.

This wasn't intended to be a bragging session as I don't claim to be a
programmer (electronics engineer), just modifying the definition of
"Q&D" slightly.

> 
> One might reasonably ask: "Couldn't the animation software be well built and
> still do its job?" Is it of necessity spaghetti code? Is it somehow or other
> faster to get the job done to just start plodding along laying down code
> until the animation looks right? I suspect that if the hypothetical
> animation developers did *some* analysis and design up front and *did* build
> solid, reliable code that it would possibly not take any longer to get to
> market and might yield larger chunks of things that could be reused & save
> time/money on the next animation. (I wouldn't go to the extremes of analysis
> & design done for safety critical software, but surely the animator still
> needs to do some amount of "debugging" to get the thing to work at all and
> surely that means if there were better forthought and stronger checks, lots
> of those problems might be minimized.)
> 
> I see the point that throw-away code need not be well built. But it is not
> demonstrated that this is somehow faster or better or cheaper than
> well-built code to do the same thing.
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> "Darren New" <dnew@san.rr.com> wrote in message
> news:3CD0A3B8.7B7C8622@san.rr.com...
> >
> > On the other hand, if you're writing run-once software, it's pretty easy
> > to see that the cleanliness of the design is virtually irrelevant.
> > Consider software to animate a crowd of CGI characters in a movie. As
> > long as the end result looks good, it doesn't matter what the code looks
> > like. It could be the most god-awful mess of spaghetti code and misnamed
> > uncommented variables you can imagine, and it just doesn't matter. As
> > soon as the film is out, you're never going to run the program again.
> > Certainly if the requirement is "make the fur on the monster look
> > realistic", the first place to start is not the type system.
> >


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Is strong typing worth the cost?

[Marin David Condic]

I'd agree that "Q" does not necessarily imply "D". But in a sense, what you
describe is a kind of design (informal though it may be) over time - partly
possibly by trial and error or deep meditation, etc. You come up with large
quantities of code that have broken the problem up into well defined chunks
and then you can quickly glue them together into a working, reliable
application. That sort of thing can work quite well. I think where it breaks
down is when you have a development project that may not be well understood,
well defined/scoped, and starts involving a larger number of people. Then
you've got to be a bit more rigorous or you end up in trouble.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Gary Scott" <scottg@flash.net> wrote in message
news:3CD32114.D45C3978@flash.net...
>
> This wasn't intended to be a bragging session as I don't claim to be a
> programmer (electronics engineer), just modifying the definition of
> "Q&D" slightly.
>

Re: Is strong typing worth the cost?

[Pascal Obry]

Gary Scott <scottg@flash.net> writes:

> Even with the resources, you likely won't have equal knowledge in
> multiple languages in order to do the best possible job in each
> language.  In a great many fields, execution performance is highly
> important whereas not in others, so you also need to carefully choose
> the problem you're solving in those multiple languages, possibly
> designed specifically targeting specific, disparate problem domains. 
> Some languages claim to be "general purpose", but usually those are weak
> in numerical programming.  Those tailored for numerical programming are
> often weak in "system" programming.  So no matter what you do, it
> probably won't be a fair comparison.

I completely agree.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Is strong typing worth the cost?

[Marin David Condic]

First off, I can convince myself of the benefit of strong typing and don't
really need scientific proof that it is a better way to do business, so I'm
not opposed to Preben's example. (Or numerous other possible examples.) I
state that because now I'm going to play devil's advocate. :-)

The example shown was, of necessity, a very simple case that will *not*
illustrate the cost of doing the design needed to properly build a set of
types and subtypes for a system of realistic size. If you're approaching a
system of some magnitude and plan on utilizing strong typing to the fullest
desirable extent, then you've really got to do a lot of analysis and design
to actually exploit it. If you *don't* want to use strong typing, then
you've just eliminated a bunch of design work - which obviously costs less
up front. In fact, you can totally eliminate *any* design and just start
coding and save all the cost of analysis and design. ("O.K. You guys get
started writing the code while I go talk to the customer and find out what
they want..." :-)

In general, we convince ourselves that for larger systems, failure to do any
up front design costs a lot at the back end in terms of missed requirements,
debugging, rework, total failure, etc. I'm not sure that there is any
"scientific" evidence we can point to, but certainly a lot of experience
that tells us this ought to be "Conventional Wisdom". Properly using strong
typing (beyond the inherent checks within the language supplied types) is
something that requires you think about the problem, analyze the constraints
on everything, devise a set of types and operations that reflect the problem
space, etc., etc., etc. Most of us with experience doing this will contend
that, yes, it costs something up front but it saves a lot at the back end.
(Maybe the biggest benefit comes from the fact that you had to *think* about
the problem pretty rigorusly?) But its not totally unfair to ask if there is
anything that might demonstrate this with hard data rather than just
perceptions and anecdotes. How much evidence one might demand before
concluding that it is a wise thing to do is up to the individual.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uwuuouuwi.fsf@wanadoo.fr...
>
> This is always hard to prove... But look at Preben example, the second
version
> of the program is no more complex than the first one. Both are so similar
than
> they certainly cost the same at the development step. But the second will
> catch the error and will avoid a debug session which cost more than
writing
> the piece of code in the example ! As you say we all have lot of example
like
> this... This is no proof, we don't have resources to play the game of
writing
> a software in two different languages and compare the results...
>

Re: Is strong typing worth the cost?

[Wes Groleau]

> this... This is no proof, we don't have resources to play the game of writing
> a software in two different languages and compare the results...

But other people have done so. 

We have the Ada vs. C report from Rational,
the Ada vs. C report from Plattsburgh (McCormick),
I read, but can't remember where, an Ada vs. Fortran
report, and there have been others.

Not enough to consider "proof" perhaps, but
evidence.  And Watts Humphrey's PSP
(http://www.sei.cmu.edu/publications/articles/practice-preach/practice-preach.html)
offers methods that can identify programs/modules
that are "similar" in difficulty, so you can
compare them even if they are not the "same" program.

I'm curious--has anyone _ever_ seen, on the web
or in print, an article on a successful project where a
manager or engineer has said, "We would never have
made it if we had tried to use something other than C."

There have been plenty of such remarks about Ada.
I think there have been some about Eiffel.  There
probably have been some about Java, maybe not.

Has anyone seen a discussion of a project with problems
where the people actually involved blamed Ada?

(Ariane 5 does not count--the only people
that blame Ada there are Ada-phobes from
outside the project.)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Marin David Condic]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CCFFB7F.B8080F7A@despammed.com...
>
> We have the Ada vs. C report from Rational,
> the Ada vs. C report from Plattsburgh (McCormick),
> I read, but can't remember where, an Ada vs. Fortran
> report, and there have been others.
>
Ada vs Some Other Language is at least something that can be tested in a
reasonably scientific manner. Its hard to get truly scientific information
for a whole lot of reasons, but at least we have a few case studies where
all other things were sufficiently equal to give one high confidence in the
conclusions. The OP's interest in specifically "strong typing" I don't think
is something that can be tested readily in a scientific manner because it
can't be separated as the only factor in the experiment.


>
> I'm curious--has anyone _ever_ seen, on the web
> or in print, an article on a successful project where a
> manager or engineer has said, "We would never have
> made it if we had tried to use something other than C."
>
The problem with that observation is that when you're on top of the heap,
you don't typically make statements like this. In many areas, C is just the
accepted way of doing it. Hence, nobody feels the need to say "We couldn't
have done it if we had not used the standard-issue technology that everyone
else successfully builds projects with..." Sort of like no manager ever
getting fired for picking IBM. But if you take a risk by using something off
the beaten path, you later want to credit your success to having made such
Bold, Creative, Insightful Management Decisions.


>
> Has anyone seen a discussion of a project with problems
> where the people actually involved blamed Ada?
>
I vaguely recall some sort of FAA project that didn't do well and used Ada.
People were eager to blame Ada, but IIRC, there was supposed to have been a
bunch of other problems as well. I don't think that proves much since people
blame failures on any convenient target that isn't themselves and so it is
at least a highly subjective measure. Putting too much emphasis on praise or
blame is a symptom of a language with a massive inferiority complex. :-)
Better to think about the solid evidence of Ada's contribution to better
productivity and quality since that is as sound argument for using it.


> (Ariane 5 does not count--the only people
> that blame Ada there are Ada-phobes from
> outside the project.)
>
<Butchered_Old_Movie_Quote>
There it is! There it is! Every time we start talking about software
failures some dude's gotta go pull Ariane 5 outa his rectum!!! :-)
</Butchered_Old_Movie_Quote>

It really is an old saw that ought to go on the list along with "Ada was
designed by committee", "Ada runs slow", "You can't do systems programming
in Ada", etc.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Is strong typing worth the cost?

[Wes Groleau]

> We have the Ada vs. C report from Rational,
> the Ada vs. C report from Plattsburgh (McCormick),
> I read, but can't remember where, an Ada vs. Fortran
> report, and there have been others.

I wish I knew how to find the Ada/Fortran comparison.
It was in the 1980s, and some company decided to give
the same requirements to two teams, one to use Ada
and one to use Fortran.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Gary Scott]

Wes Groleau wrote:
> 
> > We have the Ada vs. C report from Rational,
> > the Ada vs. C report from Plattsburgh (McCormick),
> > I read, but can't remember where, an Ada vs. Fortran
> > report, and there have been others.
> 
> I wish I knew how to find the Ada/Fortran comparison.
> It was in the 1980s, and some company decided to give
> the same requirements to two teams, one to use Ada
> and one to use Fortran.

That would have been FORTRAN 77.  Hardly the same results as a
comparison with Fortran 95, which nearly every current compiler is (not
that if you restricted yourself to the FORTRAN 77 subset of Fortran 95,
you may get the same results, but that would not be a wise thing to do).

> 
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Preben Randhol]

On Thu, 02 May 2002 11:47:26 -0500, Gary Scott wrote:
> 
> That would have been FORTRAN 77.  Hardly the same results as a
> comparison with Fortran 95, which nearly every current compiler is (not
> that if you restricted yourself to the FORTRAN 77 subset of Fortran 95,
> you may get the same results, but that would not be a wise thing to do).

FORTRAN 77 is almost beyond weak typed language so I have used IMPLICIT
LOGICAL (A-Z) in every subroutine/function so that any variable not
defined by me becomes a boolean variable and thus in almost all cases
will give an error at compilation.

Preben

Re: Is strong typing worth the cost?

[Dan Nagle]

Hello,

Better, use the Mil-Std-1753 (sp?) implicit none statement.

De facto standard due to the necessity of the military market.

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Thu, 2 May 2002 18:24:48 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>On Thu, 02 May 2002 11:47:26 -0500, Gary Scott wrote:
>> 
>> That would have been FORTRAN 77.  Hardly the same results as a
>> comparison with Fortran 95, which nearly every current compiler is (not
>> that if you restricted yourself to the FORTRAN 77 subset of Fortran 95,
>> you may get the same results, but that would not be a wise thing to do).
>
>FORTRAN 77 is almost beyond weak typed language so I have used IMPLICIT
>LOGICAL (A-Z) in every subroutine/function so that any variable not
>defined by me becomes a boolean variable and thus in almost all cases
>will give an error at compilation.
>
>Preben

Re: Is strong typing worth the cost?

[Preben Randhol]

On Thu, 02 May 2002 14:48:16 -0400, Dan Nagle wrote:
> Hello,
> 
> Better, use the Mil-Std-1753 (sp?) implicit none statement.
> 
> De facto standard due to the necessity of the military market.

Don't have it. We have a NAG F90 compiler only.

Preben

Re: Is strong typing worth the cost?

[Gary Scott]

Preben Randhol wrote:
> 
> On Thu, 02 May 2002 14:48:16 -0400, Dan Nagle wrote:
> > Hello,
> >
> > Better, use the Mil-Std-1753 (sp?) implicit none statement.
> >
> > De facto standard due to the necessity of the military market.
> 
> Don't have it. We have a NAG F90 compiler only.

It (IMPLICIT NONE) is standard in F90 (including NAG F90).  It was an
extension only in FORTRAN 77.

> 
> Preben


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Is strong typing worth the cost?

[Preben Randhol]

On Fri, 03 May 2002 10:17:45 GMT, Gary Scott wrote:
> It (IMPLICIT NONE) is standard in F90 (including NAG F90).  It was an
> extension only in FORTRAN 77.

Yes, but all the old code is F77 and we want to be able to compile it on
other platforms as F77 too :-)

Re: Is strong typing worth the cost?

[Gary Scott]

Preben Randhol wrote:
> 
> On Fri, 03 May 2002 10:17:45 GMT, Gary Scott wrote:
> > It (IMPLICIT NONE) is standard in F90 (including NAG F90).  It was an
> > extension only in FORTRAN 77.
> 
> Yes, but all the old code is F77 and we want to be able to compile it on
> other platforms as F77 too :-)

But that was the point of Dan Nagle.  There are almost certainly NO
FORTRAN 77 compilers that do not support IMPLICIT NONE, since it was
required by MIL-STD-1753 (or whatever it was).  True, it isn't 100%
standard, but unless the code is purely numerical (and maybe even then),
I'd almost bet, having never seen it, that it isn't 100% standard
already.  And while IMPLICIT NONE SHOULD have been made the default at
Fortran 90 but wasn't, it is an improvement over the use of logical for
implicit declarations (i.e. completely eliminates implicit typing).  It
does nothing with regard to mixed mode conversions, but I find the
Fortran rules quite straightforward there.

Re: Is strong typing worth the cost?

[Preben Randhol]

On Fri, 03 May 2002 08:13:36 -0500, Gary Scott wrote:
> But that was the point of Dan Nagle.  There are almost certainly NO
> FORTRAN 77 compilers that do not support IMPLICIT NONE, since it was

OK, I'll test it next time.

Preben

Re: Is strong typing worth the cost?

[Dan Nagle]

Hello,

implicit none was standardized with f90, as was the rest
of mil-std 1753.

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Fri, 3 May 2002 08:44:41 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>On Thu, 02 May 2002 14:48:16 -0400, Dan Nagle wrote:
>> Hello,
>> 
>> Better, use the Mil-Std-1753 (sp?) implicit none statement.
>> 
>> De facto standard due to the necessity of the military market.
>
>Don't have it. We have a NAG F90 compiler only.
>
>Preben

Re: Is strong typing worth the cost?

[Larry Hazel]

Wes Groleau wrote:
> 
> > We have the Ada vs. C report from Rational,
> > the Ada vs. C report from Plattsburgh (McCormick),
> > I read, but can't remember where, an Ada vs. Fortran
> > report, and there have been others.
> 
> I wish I knew how to find the Ada/Fortran comparison.
> It was in the 1980s, and some company decided to give
> the same requirements to two teams, one to use Ada
> and one to use Fortran.
> 
Wes - It may have been SAIC.  We converted a pilot training simulator from
assembly language to Fortran 77.  The company funded an R&D project to convert
the Fortran to Ada.  It was quite successful, and found some errors in the
Fortran.  I didn't ever see a report on the results but I'm sure there was one.

Larry

Re: Is strong typing worth the cost?

[Wes Groleau]

> > I wish I knew how to find the Ada/Fortran comparison.
> > It was in the 1980s, and some company decided to give
> > the same requirements to two teams, one to use Ada
> > and one to use Fortran.
> >
> Wes - It may have been SAIC.  We converted a pilot training simulator from
> assembly language to Fortran 77.  The company funded an R&D project to convert
> the Fortran to Ada.  It was quite successful, and found some errors in the
> Fortran.  I didn't ever see a report on the results but I'm sure there was one.

Of course my memory could be wrong,
but I'm pretty sure the article said
that they gave each team the same
requirements to create (not convert)
some project, in order to determine
the advantages/disadvantages of Ada
vs. Fortran.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Preben Randhol]

On Thu, 02 May 2002 13:12:01 -0500, Wes Groleau wrote:
> 
> Of course my memory could be wrong,
> but I'm pretty sure the article said
> that they gave each team the same
> requirements to create (not convert)
> some project, in order to determine
> the advantages/disadvantages of Ada
> vs. Fortran.

Any of these:

http://www.adaic.org/atwork/weirton.html
http://sel.gsfc.nasa.gov/website/documents/online-doc/95-001.pdf
http://www-adele.imag.fr/~jmfavre/ENSEIGNEMENT/TRANSPARENTS/SoftwareMaintenance/7/SoftwareMaintenance-7.pdf

Re: Is strong typing worth the cost?

[Wes Groleau]

> > that they gave each team the same
> > requirements to create (not convert)
> > some project, in order to determine
> > the advantages/disadvantages of Ada
> > vs. Fortran.
> 
> Any of these:
> 
> http://www.adaic.org/atwork/weirton.html

Not this one.

> http://sel.gsfc.nasa.gov/website/documents/online-doc/95-001.pdf

Maybe an alternate report of the GROSS/GRODY study
on pages 17-18, but I don't think so.

> http://www-adele.imag.fr/~jmfavre/ENSEIGNEMENT/TRANSPARENTS/SoftwareMaintenance/7/SoftwareMaintenance-7.pdf

I see nothing in this one about comparing Fortran to Ada.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Gary Scott]

Larry Hazel wrote:
> 
> Wes Groleau wrote:
> >
> > > We have the Ada vs. C report from Rational,
> > > the Ada vs. C report from Plattsburgh (McCormick),
> > > I read, but can't remember where, an Ada vs. Fortran
> > > report, and there have been others.
> >
> > I wish I knew how to find the Ada/Fortran comparison.
> > It was in the 1980s, and some company decided to give
> > the same requirements to two teams, one to use Ada
> > and one to use Fortran.
> >
> Wes - It may have been SAIC.  We converted a pilot training simulator from
> assembly language to Fortran 77.  The company funded an R&D project to convert
> the Fortran to Ada.  It was quite successful, and found some errors in the
> Fortran.  I didn't ever see a report on the results but I'm sure there was one.

But on the other hand, I can site an equally disastrous and quite large
conversion from Fortran to Ada in the mid 90's (an engineering system
integration and software development tool set and associated fixture). 
Later ones went from Fortran to C much more successfully.  And yes,
there were errors in the original Fortran.  There were also introduced
numerous errors in the C code that the Fortran code did correctly.

> 
> Larry

Re: Is strong typing worth the cost?

[Wes Groleau]

> But on the other hand, I can site an equally disastrous and quite large
> conversion from Fortran to Ada in the mid 90's (an engineering system
> integration and software development tool set and associated fixture).
> Later ones went from Fortran to C much more successfully.  And yes,
> there were errors in the original Fortran.  There were also introduced
> numerous errors in the C code that the Fortran code did correctly.

About five years ago, I called someone to discuss the
AdaIC "success story" of their use of Ada.  Don't
remember who for sure, but I think it was a petroleum
company.

He said that Ada was a really good thing, but that they
had gone back to Fortran because more numerical code
was available in Fortran.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Robert I. Eachus]

Larry Hazel wrote:


> Wes - It may have been SAIC.  We converted a pilot training simulator from
> assembly language to Fortran 77.  The company funded an R&D project to convert
> the Fortran to Ada.  It was quite successful, and found some errors in the
> Fortran.  I didn't ever see a report on the results but I'm sure there was one.


At Honeywell SSD, we converted a (fielded as part of an OS) module from 
Fortran to Ada 83.  The module was mature, but had a number of closed 
bug reports against it.  The process of converting the module discovered 
several errors in the FORTRAN code.  The Ada code ran slower than the 
original code, but much faster than the corrected/debugged Fortran code.

Does that say that coding in Ada found lots of bugs that were not found 
by the original implementors?  (No, some were clearly introduced by 
other bug fixes.)  Does that say that an Ada implementation was less 
likely to have bugs than a Fortran implementation?  (No, there could 
have been other problems that would not have been noticed in a pure Ada 
implementation that were not a problem in Fortran or were discovered and 
fixed during the Fortran implementation.)  So what did the study really 
tell us?

That strong typing and subtypes were more than free in Ada, they 
resulted in tighter, faster machine code.  I think Intermetrics had a 
similar result they presented in a conference.  (SIGPLAN 84?)  The 
constraint checking optimizations resulted in about 2% smaller code than 
with constraint checking turned off.  There were enough similar results 
about the same time than it has become accepted wisdom in the Ada 
community.  Now apparently the question is being asked differently, can 
you show a development cost savings instead of a code efficiency benefit?

What I guess I, and a lot of other here feel is that there is no 
question there worth asking.  Comparing the cost of developing an 
incorrect version of a program to the cost of developing a correct 
version is meaningless.  And all Ada programmers know from personal 
experience that strong typing finds bugs in our code at compile time 
that would be much more difficult to find using the debugger.  In fact, 
there is a very good clue that has been intertwined with this 
discussion...  C programmers will compile their code with debugging 
options enabled, then run it first via the debugger.  Ada programmers 
tend to compile with debug options turned off, and personally I have 
never used the debugger that comes with GNAT.  (I did use the Verdix 
debugger a few times though.)

In my personal experience, I make very few coding errors that are not 
caught by the compiler, and many of these are output formatting errors. 
  When I do need to debug something, it is actually the algorithm that I 
am debugging/testing, and test cases plus occasional embedded print 
statements are IMHO the best tool for that.

Re: Is strong typing worth the cost?

[Brian Rogoff]

On Sun, 26 May 2002, Robert I. Eachus wrote:
[...snip...]
> What I guess I, and a lot of other here feel is that there is no
> question there worth asking.  Comparing the cost of developing an
> incorrect version of a program to the cost of developing a correct
> version is meaningless.  And all Ada programmers know from personal
> experience that strong typing finds bugs in our code at compile time
> that would be much more difficult to find using the debugger.

Being, with you, on the side of strong *static* typing, I find that a
more interesting question to ask is to what extent should the typing be
explicit (in Ada, it's almost all explicit) and to what extent should the
language allow implicit typing, like most modern functional languages.

Another related question I'd like language designers to think about is the
relationship between verbosity and readability. It's often insinuated in
the Ada community that verbosity and readability are directly proportional,
but I don't believe that's true. If we look at the history of mathematics,
there was a period of time when mathematicians wrote mathematics like
prose, and it was a big advance to get more succint notations. Just making
it like prose does not enhance readability, especially when the underlying
ideas are just inherently difficult, as with mathematics.

>  In fact, there is a very good clue that has been intertwined with this
> discussion...  C programmers will compile their code with debugging
> options enabled, then run it first via the debugger.  Ada programmers
> tend to compile with debug options turned off, and personally I have
> never used the debugger that comes with GNAT.  (I did use the Verdix
> debugger a few times though.)

I have the same experience with OCaml, though I admit I've used the
debugger when I didn't catch some generic exception like "Not_found"
and I get some bad data. That's just my own fault for being lazy.

Mostly, I've learned to write my programs so that as many errors as
possible are type errors. What I really wish for now is a powerful
dependently typed system, though of course at that point checking
becomes undecidable, like C++ templates before that iteration depth limit
was imposed...

-- Brian

Re: Is strong typing worth the cost?

[Robert I. Eachus]

Brian Rogoff wrote:


> Another related question I'd like language designers to think about is the
> relationship between verbosity and readability. It's often insinuated in
> the Ada community that verbosity and readability are directly proportional,
> but I don't believe that's true. If we look at the history of mathematics,
> there was a period of time when mathematicians wrote mathematics like
> prose, and it was a big advance to get more succint notations. Just making
> it like prose does not enhance readability, especially when the underlying
> ideas are just inherently difficult, as with mathematics.


I think you may have gotten a wrong impression here.  I think that 
outside of software with very tough performance requirements, anyone 
here would favor adding one line of code if it replaced the necessity 
for three lines of comments.  In practice that trade-off almost always 
occurs in declarative parts where additional Ada source is unlikely to 
result in code size expansion or performance penalties.

Having said that, if I am given the choice between two ways to implement 
a function or package in Ada, one that is more complex and requires much 
more source code, which am I going to choose?  Right.  So the natural 
evolution of Ada code during the creation process is toward smaller more 
easily understood modules with fewer comments explaining obscure or 
difficult to understand sections.

My personal criteria are that comments that explain what a package, 
module, or section of code does are fine.  Comments on why something is 
done one way instead of another are also a good idea.  For example, in 
an implementation of the Miller-Rabin algorithm I just wrote:

  -- We now need to pick off all the bits of Reduced in reverse order.
  -- It shouldn't matter how we express this, but just in case avoid two
  -- obvious divide routines.
        loop
          Temp := Temp_Reduced/2;
          if Temp + Temp /= Temp_Reduced
            ...
          Temp_Reduced := Temp;

The first comment is definitely what, and the second explains why I 
chose not to use (Temp_Reduced mod 2) /= 0 to test the low-order bit. 
This is inside a generic, with the intent that Temp_Reduced could be a 
non-standard integer type, and the compiler might not be able to do the 
test for oddness efficiently.  Oh, and the parantheses around 
Temp_Reduced mod 2 above are another example of helping the reader.  I 
know the parentheses are unnecessary, but they make reading easier.

Comments that explain how code works are a clue that I shouldn't write 
the code that way, but in a way that is more self-explanatory.  Comments 
that explain what a variable is used for indicate that the variable is 
poorly named, and so on.

So I guess what I am saying is that the "Ada style" is to move comments 
into compilable source code whenever possible.


 

Re: Is strong typing worth the cost?

[Marin David Condic]

My experience is similar and I totally agree. When working with Ada I either
generate errors that are caught at compile time or with a runtime exception
& the error is pretty obvious, or its the kind of profound, metaphysical
error that a debugger would be worthless at catching anyway. ("You wanted
the program to do what????" :-) I'm sure the gdb tool is a wonderful thing,
but I've never turned it on and tried to figure out how to get it to work.
Usually a few well placed Put_Line calls will get the info much faster & I
don't generally need that very often. (Or its the kind of "Debugging" that
you want to leave in place in the production code anyway...)

Now when programming in C/C++? I can't live without the debugger!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3CF1231F.6000609@attbi.com...
> options enabled, then run it first via the debugger.  Ada programmers
> tend to compile with debug options turned off, and personally I have
> never used the debugger that comes with GNAT.  (I did use the Verdix
> debugger a few times though.)
>
> In my personal experience, I make very few coding errors that are not
> caught by the compiler, and many of these are output formatting errors.
>   When I do need to debug something, it is actually the algorithm that I
> am debugging/testing, and test cases plus occasional embedded print
> statements are IMHO the best tool for that.
>
>

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <3CD0A3B8.7B7C8622@san.rr.com>, Darren New <dnew@san.rr.com> writes:

> On the other hand, if you're writing run-once software, it's pretty easy
> to see that the cleanliness of the design is virtually irrelevant.
> Consider software to animate a crowd of CGI characters in a movie. As
> long as the end result looks good, it doesn't matter what the code looks
> like. It could be the most god-awful mess of spaghetti code and misnamed
> uncommented variables you can imagine, and it just doesn't matter. As
> soon as the film is out, you're never going to run the program again.
> Certainly if the requirement is "make the fur on the monster look
> realistic", the first place to start is not the type system.

I wonder whether there is such a thing as non-trivial run-once software.
There may be only one _production_ run, but amongst all the trials one
might have many many runs before the result achieves quality.

If I were given the assignment and was able to complete it, the final
source would at the very least be littered with historical comments
like "tried doubling the X value and the monster's fur looked like
concrete".

Re: Is strong typing worth the cost?

[Darren New]

Larry Kilgallen wrote:
> I wonder whether there is such a thing as non-trivial run-once software.
> There may be only one _production_ run, but amongst all the trials one
> might have many many runs before the result achieves quality.

I think you pretty much answered it yourself. You'd consider any program
that runs right the first time to be trivial, yes? So by definition, no,
there's no non-trivial program that only runs once.

How about an SQL statement that takes an hour to reorganize the database
in an application-specific way, but runs right the first time after
spending half an hour writing the statement?
 
> If I were given the assignment and was able to complete it, the final
> source would at the very least be littered with historical comments
> like "tried doubling the X value and the monster's fur looked like
> concrete".

Assuming, for example, that you're even using a programming language
where you make changes that way. A lot of these types of languages are
entirely visual, programmed primarily with the mouse.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Jim Rogers]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns9200B524E1781derekknosofcouk@62.253.162.109>...
> Boys and girls,
> 
> > Seriously, any software that reports itself as safe and
> > correct must perform a significant amount of what the old
> 
> Who mentioned safe and correct?  This is avoiding the base
> issue.  Where is the evidence of a worthwhile cost/benefit
> for strong typing?
> 

You asked about cost. You did not specify the cost parameters you want to
measure. My experience with software is that software is a total waste
of exense UNLESS it is both safe and correct.

My point in my previous posting is that costs are a result of an overall
development process, as well as the requirements and restrictions of a
project. If you want to meet the requirements and restrictions of your
project you normally, in my experience, must produce the required behavior
from your software. Strong typing allows me to define code such that 
the compiler and default run time checks can detect erroneous data.
This saves me the time and the cost of trying to manually build in all
the same checks, or to define a test program to identify all the places
where such checks are needed.

This does not mean that I do not test my software. It does mean that I
do not have to test my software for how it handles out of range data.

To paraphrase a posting to comp.lang.ada many years ago, in my experience
C programmers are much more adept at using debuggers than are Ada 
programmers. The reduced need for debugging time is a cost savings.

When you are looking at cost, are you only looking at the execution speed
of a compiled program? Clearly a program with no type checking at all will
be much faster than one with type checking. It is also true that a 
program with no type or data checking will not be as safe as one with
type and data checking.

This discussion may need to be reduced to a discussion of how to determine
the cost of software. Many organizations have no answer to the question
of how to determine the cost of software. Some people think software costs
only include coding costs. Some people include coding and design costs.
Some even add in maintenance costs. Other people see the primary cost
of software being the damages caused by the software when it malfunctions.

Jim Rogers

Re: Is strong typing worth the cost?

[Darren New]

Jim Rogers wrote:
> You asked about cost. You did not specify the cost parameters you want to
> measure. My experience with software is that software is a total waste
> of exense UNLESS it is both safe and correct.

Not always true. There is plenty of software that if it works 90% of the
time it was worth the effort of writing it.  Even though people complain
mightily about all the bugs in MS software, it was still quite
profitable to MS to write it.
 
> This discussion may need to be reduced to a discussion of how to determine
> the cost of software. Many organizations have no answer to the question
> of how to determine the cost of software. Some people think software costs
> only include coding costs. Some people include coding and design costs.
> Some even add in maintenance costs. Other people see the primary cost
> of software being the damages caused by the software when it malfunctions.

Some see part of the cost of the software also to be the cost of running
it. Otherwise, nobody would ever *re*write a piece of code from a HLL to
assembler to make it more efficient. There's also the cost of
distribution to consider - how much effort does it take to (say) write
the scripts that install the software when it's done?

Anyway, I strongly suspect that anyone who thinks
  x : Integer range 0..5000;
as "strongly typed" and
  y : Integer;
as "not strongly typed" is not going to come up with much worthwhile in
terms of learning about the costs and benefits of different typing
systems.



-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Colin Paul Gloster]

In article news:3CCEB246.9090009@worldnet.att.net , Jim Rogers wrote:
"dmjones wrote:
  
 > Marc,
 > 
 > 
 > Why?  Can you prove to me that the benefits will be greater
 > than the costs?
 > 
 > Why am I asking for this evidence?  I am working on a detailed
 > analysis of C that includes material on coding guidelines.
 > I have set myself the target of basis these guidelines on
 > empirical evidence.  I am a fan of strong typing.  However,
 > unless I can find any evidence to the contrary, the most I
 > can say at the moment is "some people think ...".
 > 
  
  
  What costs are you seeing?
  
  Seriously, any software that reports itself as safe and
  correct must perform a significant amount of what the old
  COBOL programmers call data editing. It must verify that the
  data is correct in all phases of the program. Weakly typed
  languages such as C do not avoid this problem. C simply
  delegates all such responsibility to the application
  programmer."

And of course, these programmers do not bother to put in more than a
flimsy counterpart to the rigorous sentinel a strongly typed compiler
would produce.

" Ada, on the other hand, allows the application
  programmer to supply important information, such as the minimum
  and maximum values for a scalar type, and then lets the
  compiler generate the range checking.
  
  Range checking always requires someone to do the coding.
  Ada has put that burden on the compiler developer. C puts it
  on the application developer. For the application developer this
  makes coding in C more expensive than coding in Ada.
  
  C complicates the problem by its extensive use of implicit
  numeric convrsions. The C compiler is not allowed to object if
  you assign an int to a double. In all cases, such assignments
  are dangerous. C insists the danger does not exist because a
  double can always represent all values representable in an int.
  The problem is that you can be assigning an AppleCount to a
  WeightOfScrapIron."

Of course, even with fellow integer counts that would not be
sensible. E.g. AppleCount and NumberOfPeoplePushingTheAppleCart. Even a
C++ programmer could produce code (using fully fledged objects) to do
the idiomatic (to Ada users) practise of divorcing integer metrics from
each other if they are in separate domains, but normally a C++ lover would
see this as overkill. Indeed, it has been lamely argued that there would
be an upsurge of identifiers to remember: was that variable of type
AppleCount or ApplesCount?, oooohh, so much hassle to check its
declaration and even which of those types exists. Did somebody say renames
anyway?

 "Strong typing can flag the danger of such
  assignments, forcing you as the programmer to review your
  program. Weak typing gives you no help. You are left with the
  need to carefully test all possible value combinations for your
  code, an impossible task for any non-trivial program."

Re: Is strong typing worth the cost?

[Hyman Rosen]

Colin Paul Gloster wrote:
> Of course, even with fellow integer counts that would not be
> sensible. E.g. AppleCount and NumberOfPeoplePushingTheAppleCart. Even a
> C++ programmer could produce code (using fully fledged objects) to do
> the idiomatic (to Ada users) practise of divorcing integer metrics from
> each other if they are in separate domains, but normally a C++ lover would
> see this as overkill.

Which makes me think - in the recent specifications for containers
that were posted here, do the generics have a parameter for the
type used to count the members of the container? Otherwise when I
ask my LinkedListOfApples and my LinkedListOfCartPushers how many
things each contains I'll have to convert the result, and then I
could make the same mistake that a C++ programmer would.

Re: Is strong typing worth the cost?

[Marin David Condic]

This is a legitimate question to ask. There are lots of theories and
reasoning about theories that tend to give one cause to believe that strong
typing (and other aspects of Ada) lead to lower costs and higher
reliability. However, that's different than some emperical evidence that in
the real world you actually *do* get the benefit claimed by the theories.
There can be lots of factors in the real world that tend to mess up the
theories.

Example: Automotive research indicates that antilock breaking systems ought
to reduce accidents. Yet there have been some recent studies of accident
statistics that would seem to indicate that cars equipped with ABS actually
end up in *more* accidents than other cars. Why is that? The engineers will
have to puzzle over it for a while to see if they can explain the
phenomenon.

The bad news is that there is a real dearth of any empirical evidence to
support most of the claims made by theoreticians and practitioners in
software engineering. There is a lot of anecdotal evidence - but that gets
weak. (Think of the last time some politician parades some pathetic,
suffering family out in front of the news cameras to justify why he wants to
pass some bill & spend some truckload of (our) money "to help these poor,
suffering people..." Does finding one single case where a program might be
of benefit justify the whole program?) There have been some studies here and
there, but not necessarily in the areas of interest and certainly not
consistently enough to really make the conclusions "scientific".

There have even been some economic studies at Harvard that indicate that
computerization does not benefit a company. Dollars in to purchase PC's,
etc., for a company do not necessarily translate into dollars out in
profits.

The good news is that Ada seems to have more empirical evidence of
productivity/error improvements than most other languages. Maybe we Ada fans
are just more "scientific" than most? :-) I had in-house data indicating Ada
improved things over other languages and there are other studies that seem
to support that conclusion out there on the net. (McCormick & Rational being
the two most frequently referenced.) But those are at a gross level of "Ada
vs Something Else" so you can't really claim it proves that strong typing
itself is a good thing.

My study looked at error rates and found a huge decrease there. Review of
the errors indicated that a large percentage of them were due to numerical
scaling errors and such that went away with Ada's support for representation
of numbers & strong typing. (The representation of fixed point numbers and
the use of well defined floating point numbers and the ability of the
compiler to do the conversion work for you were all major factors in
eliminating errors.) A reduction of errors translates into increased
productivity as well since you aren't spending time patching things.

The problem is that this was just in one domain where the numeric problems
are a really big deal & wouldn't necessarily reflect the rest of the world.
(That, and the study was completely internal so I can't give you references
you can cite. :-) It would be interesting to see if any of the academic
types out there with an interest in Ada could come up with some experiments
or studies that could provide some solid evidence for Ada's claims to doing
it "better".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns9200929868B11derekknosofcouk@62.253.162.107...
>
> Why am I asking for this evidence?  I am working on a detailed
> analysis of C that includes material on coding guidelines.
> I have set myself the target of basis these guidelines on
> empirical evidence.  I am a fan of strong typing.  However,
> unless I can find any evidence to the contrary, the most I
> can say at the moment is "some people think ...".
>

Re: Is strong typing worth the cost?

[Wes Groleau]

> There have even been some economic studies at Harvard that indicate that
> computerization does not benefit a company.  Dollars in to purchase PC's,
> etc., for a company do not necessarily translate into dollars out in
> profits.

It's awfully hard to control all the variables.
For example, there's a big difference between a year of

100 cheap Pentiums       $50,000  |  100 better Pentiums       $65,000  
100 copies of Windows    $10,000  |  100 copies of Linux       $    50  
 40 hours/week admin*    $30,000  |    5 hours/week admin**    $ 4,000

*cleaning up crashes and viruses and resolving
 incompatibilities

**these people are _really_ thorough

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Marin David Condic]

I recall reading about the study several years ago as I was persuing an MBA.
IIRC, the study involved looking at a number of companies that didn't have
computerization in any significant way and then they invested large sums of
money to put computers in place. By looking at, say, a case where a company
invests $5m on computerization and looking at its output per employee, you
would expect that this investment ought to result in more output per
employee in some manner or it wasn't worth it. Apparently, the numbers
didn't get better and the theory goes that employees did things like spend
time putting together fancy, typeset memos where they used to just
hand-scrawl something and show it to the xerox machine. So its not a forgone
conclusion that computers make us more productive. And its not obvious that
the reason for lack of productivity gains is because all the companies
studied used Microsoft products. :-)

Of course a counter argument is that there are just a bunch of things we
couldn't do without computers (such as design better products with computer
simulations, etc) and so computers are just the price of admission if you
want to be competitive. But that doesn't mean the original study isn't
important. It goes to show that you really need to look at things carefully
to determine if they are an actual benefit.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CCFFE11.F0CBE6FE@despammed.com...
>
> It's awfully hard to control all the variables.
> For example, there's a big difference between a year of
>

Re: Is strong typing worth the cost?

[Jeffrey Carter]

Marin David Condic wrote:
> 
> I recall reading about the study several years ago as I was persuing an MBA.
> IIRC, the study involved looking at a number of companies that didn't have
> computerization in any significant way and then they invested large sums of
> money to put computers in place. By looking at, say, a case where a company
> invests $5m on computerization and looking at its output per employee, you
> would expect that this investment ought to result in more output per
> employee in some manner or it wasn't worth it. Apparently, the numbers
> didn't get better and the theory goes that employees did things like spend
> time putting together fancy, typeset memos where they used to just
> hand-scrawl something and show it to the xerox machine. So its not a forgone
> conclusion that computers make us more productive. And its not obvious that
> the reason for lack of productivity gains is because all the companies
> studied used Microsoft products. :-)

I recall a paper from the 1980's in which a group of English professors
reviewed a bunch of computer-prepared papers from students and found
that those prepared on PCs (DOS, non-WYSIWYG word processors) had better
content than those prepared on Macs. The presumed causal mechanism was
that people working on Macs invested effort in the appearance of the
papers that students working on PCs invested in the content of the
papers.

Are we far enough off topic yet?

Re: Is strong typing worth the cost?

[Marin David Condic]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3CD19EC1.BA1DCC3@boeing.com...
>
> Are we far enough off topic yet?

Maybe. :-) But I don't think its as bad as other examples - political
diatribes, legal opinions, flame wars, netiquette lessons, etc. At least
this has been going back to the notion that one can't just assume that
because something sounds good, it must automatically *be* good. Just because
we believe strong typing in Ada is a contributor to productivity, it doesn't
follow that it automatically is in all circumstances. Like your DOS vs Mac
example -  perhaps a developer can get too drawn up into creating lots of
highly specialized types (I've seen that!) and end up either a) building the
proverbial brick-outhouse and/or b) wasting too much time and/or c) actually
creating something that is *worse* than had they just stuck to basic
primitive types.

How's that for getting back on-topic? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Is strong typing worth the cost?

[Robert I. Eachus]

Marin David Condic wrote:

> I recall reading about the study several years ago as I was persuing an MBA.
> IIRC, the study involved looking at a number of companies that didn't have
> computerization in any significant way and then they invested large sums of
> money to put computers in place. By looking at, say, a case where a company
> invests $5m on computerization and looking at its output per employee, you
> would expect that this investment ought to result in more output per
> employee in some manner or it wasn't worth it. Apparently, the numbers
> didn't get better and the theory goes that employees did things like spend
> time putting together fancy, typeset memos where they used to just
> hand-scrawl something and show it to the xerox machine. So its not a forgone
> conclusion that computers make us more productive. And its not obvious that
> the reason for lack of productivity gains is because all the companies
> studied used Microsoft products. :-)


I've worked on a couple of these studies, and there is really vicious 
infighting over the definition of productivity.  If you use a bean 
counter definition of productivity, like customer calls handled or memos 
written productivity will usually go down.  If you use a market 
definition of productivity such as corporate ROI, productivity goes way 
up with PCs.

But my favorite "two-faced" study was done by Ford Motor Company many 
years ago.  They looked at the support and capital costs of  Unix 
workstations vs. Multics.  Multics cost about four times as much per 
user.  But when they looked into the details, the costs per task were 
very similiar.  They then turned the data around, and at a low level, 
Multics users accomplished about four times as much design work as 
workstation users. At a high level, a design done using workstations 
cost about as much as a design done using Multics.  Finally, they found 
that this was because similar projects had similar design budgets. ;-) 
Projects done on Multics tended, in a cost benefit tradeoff to use a 
much lower cost in terms of man hours for similar tasks, and therefore 
do much more (computer) analysis as part of an overall design project.

So it turned out that the middle managers had the right information all 
along.  Their screaming about being forced to use Unix workstations, 
which resulted in the study being done, was correct.  But if Ford hadn't 
looked carefully at the data, the budgets imposed on the products would 
have colored the results. (Instead they spent over $10 million on new 
Multics hardware.)

Now I am not arguing that Multics would be better than today's Unix 
workstations.  Workstations have come a long way since then.  Just that 
you have to be very careful when doing such a study not to define the 
study in a way that determines the results in advance.

Re: Is strong typing worth the cost?

[Marin David Condic]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3CF113D6.40601@attbi.com...
>
>
> I've worked on a couple of these studies, and there is really vicious
> infighting over the definition of productivity.  If you use a bean
> counter definition of productivity, like customer calls handled or memos
> written productivity will usually go down.  If you use a market
> definition of productivity such as corporate ROI, productivity goes way
> up with PCs.
>
Its been a while since I read the study, but I believe that it was using
some metric based on ROI. (Don't the bean counters use ROI? :-) It was at a
fairly gross level across a number of companies so one could still argue
that the study was flawed in terms of the metric being impacted by more than
just the introduction of computers. (It was some version of "Here's a
company that invested a bunch of money in computers. Heres a company that
did not. Both are similarly profitable...." I oversimplify, but I think you
get the point.)

You're right though about arguing over the metrics. Its really hard to come
up with a yardstick that can't be criticised heavily and/or manipulated &
abused. Money comes darned close though. Its pretty easy to count and you
can't argue that it doesn't matter in commercial enterprises. :-)


>
> Now I am not arguing that Multics would be better than today's Unix
> workstations.  Workstations have come a long way since then.  Just that
> you have to be very careful when doing such a study not to define the
> study in a way that determines the results in advance.
>
An age-old management technique - first you define the answer you want, then
you go casting about to get the information that supports that answer. I
suppose that's why I'm not vice president of engineering at some big firm -
I'm not politically inclined enough to forgo science and reason in decision
making. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Is strong typing worth the cost?

[Chad R. Meiners]

"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns9200929868B11derekknosofcouk@62.253.162.107...

> Why?  Can you prove to me that the benefits will be greater
> than the costs?

If you want to write the SAME programs (one with and one without strong
typing), you will have to analyze the constraints that you wish to place on
variables in both programs.  The cost of using a strong type system is the
creation of types that satisfy your constraints; the cost of not using a
strong type system is writing the code so that it audits itself with
constraint checks every time it modifies the variables.  Note that if you do
not wish to place constraints on any variables the strong typing system does
not cost more than the weak typing system since you do not have to create
any types.  One can easily construct examples where the strong typing
systems costs less.  Can you construct an example where it costs more?

If you want to write DIFFERENT programs (one with strong typing the others
without), how can you compare the costs of strong typing against the cost of
weak typing?

-CRM

Re: Is strong typing worth the cost?

[Darren New]

"Chad R. Meiners" wrote:
> One can easily construct examples where the strong typing
> systems costs less.  Can you construct an example where it costs more?

Perhaps one where requirements are changing almost as fast as you can
keep up. Here I'm thinking of the XP techniques, which I think the OP
would probably classify as not strongly typed, even tho I expect most
programming language experts would classify Smalltalk as strongly typed.
:-)

> If you want to write DIFFERENT programs (one with strong typing the others
> without), how can you compare the costs of strong typing against the cost of
> weak typing?

You figure the cost of everything it takes to write the program that
meets the requirements under realistic requirements. Sometimes strong
typing will be better (like, when you're launching a space ship).
Sometimes dynamic typing will be better (like, when you're tracking
government regulations about payroll).

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Chad R. Meiners]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CCED46D.43145174@san.rr.com...
> "Chad R. Meiners" wrote:
> > One can easily construct examples where the strong typing
> > systems costs less.  Can you construct an example where it costs more?
>
> Perhaps one where requirements are changing almost as fast as you can
> keep up. Here I'm thinking of the XP techniques, which I think the OP
> would probably classify as not strongly typed, even tho I expect most
> programming language experts would classify Smalltalk as strongly typed.
> :-)

Changing requirements would require changing the auditing code which I would
gather is alot more costly than changing type information.

> > If you want to write DIFFERENT programs (one with strong typing the
others
> > without), how can you compare the costs of strong typing against the
cost of
> > weak typing?
>
> You figure the cost of everything it takes to write the program that
> meets the requirements under realistic requirements.

Invalid! (well mostly ;) How do we know the costs are related to strong or
weak typing?  It could be that program A satisfies an unrequested
requirement that doubles the cost of development.  I realize that your
realistic requirements MIGHT TRY to address this issue, but the better the
requirements the closer your programs get to being the same which is the
only way you can do a truly valid comparison.  This is why it is hard to
acquire valid experimental data in computer science.

-CRM

Re: Is strong typing worth the cost?

[Marin David Condic]

I can imagine requirements that state things like "Thou Shalt Range Check
All Values Before Assignment..." and then any weak typed language loses.
That's not really a functional requirement, but I could imagine something
like that being necessary to insure that you're comparing apples to apples
in your experiment.

Things like that *can* become functional requirements as in "The system
shall detect all input that is out of range..." or "The system shall never
generate an output for this device that exceeds its safe operating
range...." All that requires some kind of constraint checks at points
throughout the code where a weak typed language is going to be at a
disadvantage because you'll have to manufacture your own checks. (Or drive
fast and take chances! :-) (Hey! Maybe that's my new analogy: "Any
*Competent* Driver can get all tanked up at a bar and drive home really fast
and not get in an accident or get busted by the cops..." :-)

So maybe the question starts coming down to "How correct do you want the
software to be?" If its a quick and dirty, one shot program, Ada is likely
to lose. If it Absolutely, Positively Has To Be There Overnight, then weakly
typed languages will lose. Somewhere in the middle, there is an arguable
point where it crosses over.

Which all gets us back to the issue of how hard it is to conduct true
science with software engineering because its like trying to nail Jello to a
tree. Its really hard to reduce an experiment to one (or even a few)
variable(s).

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:aamu42$bc8$1@msunews.cl.msu.edu...
>
> Invalid! (well mostly ;) How do we know the costs are related to strong or
> weak typing?  It could be that program A satisfies an unrequested
> requirement that doubles the cost of development.  I realize that your
> realistic requirements MIGHT TRY to address this issue, but the better the
> requirements the closer your programs get to being the same which is the
> only way you can do a truly valid comparison.  This is why it is hard to
> acquire valid experimental data in computer science.
>

Re: Is strong typing worth the cost?

[Marc A. Criley]

Marin David Condic wrote:
> 
> So maybe the question starts coming down to "How correct do you want the
> software to be?" If its a quick and dirty, one shot program, Ada is likely
> to lose. If it Absolutely, Positively Has To Be There Overnight, then weakly
> typed languages will lose. Somewhere in the middle, there is an arguable
> point where it crosses over.

I often see this assertion, that when it comes to quick-and-dirty, one
shot programs, there are arguably better choices than Ada.

But I write one shot programs all the time, and while I'm less rigourous
in the typing of the variables that are used (predominantly Integer,
Natural, Float, and Unbounded_String), I can hardly envision things
going any faster using C, Perl, etc.

Maybe it's just due to the nature of the q&d programs I typically need
to write.

Marc A. Criley

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <3CD12A77.5C48FD2F@earthlink.net>, "Marc A. Criley" <mcqada95@earthlink.net> writes:

> I often see this assertion, that when it comes to quick-and-dirty, one
> shot programs, there are arguably better choices than Ada.
> 
> But I write one shot programs all the time, and while I'm less rigourous
> in the typing of the variables that are used (predominantly Integer,
> Natural, Float, and Unbounded_String), I can hardly envision things
> going any faster using C, Perl, etc.

Likewise for me.

> Maybe it's just due to the nature of the q&d programs I typically need
> to write.

I think the best language for quick and dirty programs is the one known
best by the programmer.

Re: Is strong typing worth the cost?

[Darren New]

"Marc A. Criley" wrote:
> Maybe it's just due to the nature of the q&d programs I typically need
> to write.

Probably. My one-shot programs tend to be along the lines of 
 take all the jpeg files in this directory or subdirectories,
 and rename them with the string "Fred" followed by the date
 and time extracted from the EXIF information inside the 
 file. Takes about 5 lines of Tcl.

Perhaps something like
 draw a graph of sin(x)*cos(y)+sin(cos(x)) and rotate it to show
 the structure of that function. Probably a one-liner in mathematica.
:-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marin David Condic]

I have similar experience - I too hack quick & dirty things in Ada. Part of
why that works is a high level of familiarity with the language - its always
quicker if you don't have to read the book. Part of it is that I have a
large toolkit of utilities accumulated over time that I am intimately
familiar with and can thus hack together a fairly large program quickly from
parts.

But I can still see that there are jobs more easily pulled together with a
shell script or something like DCL, etc.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Marc A. Criley" <mcqada95@earthlink.net> wrote in message
news:3CD12A77.5C48FD2F@earthlink.net...
>
> I often see this assertion, that when it comes to quick-and-dirty, one
> shot programs, there are arguably better choices than Ada.
>
> But I write one shot programs all the time, and while I'm less rigourous
> in the typing of the variables that are used (predominantly Integer,
> Natural, Float, and Unbounded_String), I can hardly envision things
> going any faster using C, Perl, etc.
>
> Maybe it's just due to the nature of the q&d programs I typically need
> to write.
>
> Marc A. Criley

Re: Is strong typing worth the cost?

[Darren New]

"Chad R. Meiners" wrote:
> Changing requirements would require changing the auditing code which I would
> gather is alot more costly than changing type information.

Well, no, that's kind of the point. It's cheaper to change the auditing
code than it is to change the type information, due to the way the whole
process (including the language) is set up. 

> > You figure the cost of everything it takes to write the program that
> > meets the requirements under realistic requirements.
> 
> Invalid! (well mostly ;) How do we know the costs are related to strong or
> weak typing?  It could be that program A satisfies an unrequested
> requirement that doubles the cost of development.

"Doctor, Doctor! It hurts when I do this!"
    "Well, don't do that!"

Of course you would have to know that your goal is to minimize the
development effort, and therefore satisfying a number of unrequested
requirements that take a great deal of work to satisfy is Bad.

>  I realize that your
> realistic requirements MIGHT TRY to address this issue, but the better the
> requirements the closer your programs get to being the same which is the
> only way you can do a truly valid comparison. 

Well, I don't think it's reasonable to try to develop a program without
strong typing in Ada. It just doesn't make sense, because Ada is
strongly typed. You *can't* develop a weakly-typed program in Ada. So
you would have to compare Ada against a weakly-typed language (or a
dynamically-typed language) as a comparison, at which point your two
programs won't be the same. Your requirements, of course, would have to
deal with input and output, rather than program structure.

And of course, the OP asked for some actual evidence, rather than lots
of handwaving about why strong typing *should* be better. There's
actually empirical evidence that dynamic typing is better in some
situations, and one can point to many convincing theoretical reasons for
strong typing being safer, and there are a number of axes to measure
along, so I don't think there's any one answer.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[tmoran]

> Sometimes dynamic typing will be better (like, when you're tracking
  Whoa!  Just what did the OP mean by "strong typing"?  Static/Dynamic,
or the sort of "type miles is new float; type kilometers is new float;"
sort of thing we call "strong typing" in the Ada world?  If it's the
latter, the cost is minimal, if not actually zero.  But in terms of
execution speed and (sometimes) speed of modifying a program for new
requirements, there are clearly tradeoffs in static vs dynamic typing.
What is the subject under discussion?

Re: Is strong typing worth the cost?

[Darren New]

tmoran@acm.org wrote:
> > Sometimes dynamic typing will be better (like, when you're tracking
>   Whoa!  Just what did the OP mean by "strong typing"? 

I don't know. That's why I said it's important to figure out what Derek
is talking about. 

He said 
> But I my interest is purely in
> the advantages of strong typing.  Language comparison is too
> broad an issue.

That's just silly, tho. You can't take a language as strongly typed as
Ada and just throw away the typing, and expect to get anything
worthwhile out of it. It's like saying "I want to investigate the effect
of different engine sizes on automobile performance, so I'm going to put
this V-8 in a VW Bug and see how it handles." If you don't change the
steering, the transmission, and the wheels to match the new power (let
alone the center of balance), it's not going to work well. 

x : Integer;
is neither more nor less strongly typed than
y : Integer range 0..5000;
in Ada. If you're trying to do this study and then generalize it to
something other than Ada, something about strong vs weak typing, then
you're going to be playing the GIGO game. If you ask
> So where are the studies showing that strong typing in Ada (or
> Pascal) saves money/time, creates more reliable programs, etc?
and then only compare Ada programs, you're getting garbage.

Ask a similar question - "How efficient would an Ada program be with no
type declarations?"  You can't answer that, because "Ada without type
declarations" is a meaningless phrase. So of course there's no
experimental evidence about which is better.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Marin David Condic]

Interesting questions. If I write an Ada program using just the types
defined in Standard, I've still got stronger typing than writing a C program
with the types int and char and double, etc... It doesn't cost any more to
use Integer and Character and Long_Float, etc... in terms of any relavent
development time, yet you automatically get *some* level of type safety. If
it causes a single error to be found at compile time that would have snuck
through an equivalent C program that needed to be found with a debugger, one
could argue that the fix is inherently less costly since it is found earlier
in the process. To argue that this *adds* any cost you'd have to convince
yourself that including appropriate conversions and fixing compiler error
messages takes some significant amount of time in comparison to having the
compiler let everything slide on through. That, while undemonstrated, seems
to be highly unlikely.

Its not an easy thing to demonstrate with experiments, in any case. There
are just too many variables. It might be easier to demonstrate something at
a more encompassing level, like "Language X is more productive than Language
Y" since there you can easily swap out the variable. But you're still stuck
with trying to make all other things be equal.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:aamiqj$30ce$1@msunews.cl.msu.edu...
>
> If you want to write the SAME programs (one with and one without strong
> typing), you will have to analyze the constraints that you wish to place
on
> variables in both programs.  The cost of using a strong type system is the
> creation of types that satisfy your constraints; the cost of not using a
> strong type system is writing the code so that it audits itself with
> constraint checks every time it modifies the variables.  Note that if you
do
> not wish to place constraints on any variables the strong typing system
does
> not cost more than the weak typing system since you do not have to create
> any types.  One can easily construct examples where the strong typing
> systems costs less.  Can you construct an example where it costs more?
>
> If you want to write DIFFERENT programs (one with strong typing the others
> without), how can you compare the costs of strong typing against the cost
of
> weak typing?
>
> -CRM
>
>

Re: Is strong typing worth the cost?

[Jeffrey Carter]

dmjones wrote:
> 
> Why am I asking for this evidence?  I am working on a detailed
> analysis of C that includes material on coding guidelines.
> I have set myself the target of basis these guidelines on
> empirical evidence.  I am a fan of strong typing.  However,
> unless I can find any evidence to the contrary, the most I
> can say at the moment is "some people think ...".

So, there is no evidence that the benefits of strong typing outweighs
the costs. Is there evidence that the benefits of weak typing outweigh
the costs?

It seems that you are saying you will recommend strong typing if there
is evidence for it, and you will recommend weak typing if there is no
evidence against it. This is a double standard biased towards weak
typing. Either you should recommend anything that has evidence for it,
or recommend everything that has no evidence against it, or not even
mention the subject in the absence of evidence one way or the other.

-- 
Jeffrey Carter

Re: Is strong typing worth the cost?

[Marc A. Criley]

dmjones wrote:
> 
> The real problem with the discussion so far is that it has
> only mentioned the benefits.  What about the costs?
> 
> > strengths of strong typing.  Don't fight strong typing, USE it!
> 
> Why?  Can you prove to me that the benefits will be greater
> than the costs?
> 
> Why am I asking for this evidence?  I am working on a detailed
> analysis of C that includes material on coding guidelines.
> I have set myself the target of basis these guidelines on
> empirical evidence.  I am a fan of strong typing.  However,
> unless I can find any evidence to the contrary, the most I
> can say at the moment is "some people think ...".

I understand what you're trying to do here, and applaud your motivation
to find empirical evidence on the cost/benefits of strong typing.

But there's like a problem with the concept of programming with or
without strong typing, particularly in a language that is built upon it,
like Ada.  So I have difficulty characterizing what such a study would
demonstrate, which may suggest why one focused exclusively on that topic
is difficult to find.

I find the idea roughly analogous to talking about the costs/benefits of
using classes in C++.  Classes are a fundamental part of that language,
so avoiding them would mean performing "programming acrobatics" and the
resulting software would certainly not adhere to the "spirit of C++". 
It can be done, but what has it proved?

Likewise, strong typing is a fundamental part of Ada, so if you avoid
strong typing, you're not really programming in Ada.  This is what I was
alluding to in the posting about how programmers can embed and extract
information in software written in a strongly typed programming
language.  Ada semantics are a manifestation of a "type model", and it's
very difficult to answer the question: "What would programming in this
language be like if it wasn't based on a strong typing model?"

What are the costs of strong typing?  Well, the aspects of this question
must be better defined...

Are you (the generic "you") talking about the time required to fix
constraint errors caused by exceeding an index range?  I've known
developers and managers who hated exceptions, because they ended up
costing time and money.  Yet I see the raising of such exceptions as a
benefit of strong typing!

Is there a cost associated with the analysis to properly define a type
range with minimum and maximum values that can then be extracted via
'First, 'Last, and 'Range?  Well, if I don't embed that information in
the type definition, then I'll need to maintain variables or constants
(whose values I also had to determine via analysis).

A study tossed at me decrying strong typing as more cost than benefit
would have to clearly identify what they're calling "strong typing",
what criteria are being used to measure cost and benefit, and be
evaluating strong typing in a sensible environment.  I.e., claiming that
strong typing has more cost than benefit when programming in C or BASIC
probably wouldn't give me much heartburn, because those are not strongly
typed languages, and therefore emulating strong typing would be an added
development cost, and depend on the standards of the project, and the
commitment and skill of the application developers.

When it comes to strong typing, Ada has spoiled me, and any sort of
analysis of strong typing will have to provide support and rigor equal
or exceeding that provided by Ada.

Marc A. Criley
Consultant 
Quadrus Corporation
www.quadruscorp.com

Re: Is strong typing worth the cost?

[Richard Riehle]

dmjones wrote:

> The real problem with the discussion so far is that it has
> only mentioned the benefits.  What about the costs?

When developing software with a significant dependability requirement
you may want to believe you cannot afford type safety.   However, in the
words of an insurance agent, when told by a prospect he cannot afford to
buy a particular kind of insurance, "Mr. Jones, you can't afford not to buy

this policy."     What level of insurance do you want to offset the risk
when
delivering a reliable system on-time and within budget?   Perhaps, when
assessing cost, we might say, "Mr. Jones, you can't afford not to use
type safety."

It is not clear what costs you mean.   It is also not clear
what you mean by "strong typing."    A type is characterized by:

               A type name
               A set of values
               A set of operations
               A set of rules relative to objects of other types

Nearly every language has types.   Therefore, nearly every
language has some level of type safety.  I think what you mean
by strong typing is the rigor of type safety.  Even COBOL has
a certain amount of type safety.  For example, one cannot
add a PICTURE XX to a PICTURE 99.

Is there a cost associated with type safety?  Is there a corresponding
cost associated with lack of type safety?    In Ada, type safety begins
earlier in the development process than in most languages.   For small,
programs, extensive reliance on type safety is probably overkill.   As
an application gets larger,  type safety tends to scale nicely with the
demands and complexity of that larger set of code.   The cost of resorting
to the debugger, examining lots of cross-reference listings, and prowling
through hexadecimal dumps can be expensive on large-scale software.

So the cost of type safety, if there is a cost,  on small, relatively easy
programs may not not offset the ease of invoking debugging tools. But
as that program grows, and as more programmers work on modules that
must interface with each other, the cost of type safety tends to be
cancelled out by the cost of debugging efforts.

Richard Riehle

Re: Is strong typing worth the cost?

[Marin David Condic]

You might try:

http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp

This article by Dr. McCormick doesn't specifically address strong typing,
but he concludes that strong typing was one factor in increased project
success. He's got some fair amount of evidence that Ada improves
productivity over C as a result of various class project studies. You might
look for further research by him and see if it applies.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"dmjones" <derek@NOSPAMknosof.co.uk> wrote in message
news:Xns91FEB85DCA09Cderekknosofcouk@62.253.162.108...

> So where are the studies showing that strong typing in Ada (or
> Pascal) saves money/time, creates more reliable programs, etc?
>
> References anybody?

Re: Is strong typing worth the cost?

[dmjones]

All,

To summarise, no new research investigating the
cost/benefit of using strong typing has come to light.
There was a suggestion that a John McCormick might
be able to provide some pointers.  I have contacted him
and he does not know of any such published research.

On the basis that somebody reading this group might be
interested in carrying out some research, or perhaps funding
it (I have other fish to fry and am not after funds to do
it) lets move on.

I have tried to summarise peoples points.  Please say if
I have misrepresented you.

Jeffrey Carter:  Only recommend strong typing if evidence
in favour of it?  Otherwise recommend use of weak typing?

Me:  I am dealing with developers who use a weakly typed
language.  To change existing practice I need evidence
that it is worthwhile.  The default is weak, I am not recommending
anything unless I have evidence one way or the other.

The language is C.  So called 'safe' subsets are typically created
by removing 'dangerous' constructs.  Please don't ask me to
define a 'safe' subset, or what a 'dangerous' construct is.  I
don't know.  Anyway, my interest is more economics based, reducing
the cost of software ownership.  Rather than subseting, why not
add to the language; stronger typing is the candidate?

Yes, I know that adding stronger typing to C is not a sensible
thing to do for all sorts of reasons.  I am looking for an
incremental change in developer usage (a separate tool [modified
gcc or commercial product, the tool is not the issue] to
enforce the checks, then compile with existing compiler).  Being
evangelical about using another language is not where I am coming
from.

Marc Criley:  Can strong typing be separated from the host
language?

Me:  Probably not 100%.  Is 90% possible?  Who knows.
Experience has taught me (Pascal based commercial applications
in the 80's, accounts packages, simple process control, simple
database applications, etc), that developers can quiet easily
write code using only integer & real + arrays of those types.
It's no good turning our noses up at such code.  Unless developers
are given good training, incentives to use what they have learnt,
and time to perfect their skills, so called 'well written' code
will not get written.

I am not interested in detailed language issues.  I want a study,
with independent duplication, showing use of string typing has
a cost/benefit of X%.  Where X is suitably impressive.

Frank Bearcd, tmoran:  Safe & correct is everything.

Me:  Making a profit is everything.

Neither statement is true.  Readers will have no trouble thinking
of bug ridden products that make their owners a fortune.  I know
of products that have been shown to have a high degree of correctness
that have lost money and caused their developers to go bust.

I see strong typing as a tool for cost reduction in acheiving
a specified level of software reliability.  Nothing more.

Jim Rogers:  What are the parameters of cost?

Me:  Money.  Developers time (original development, subsequent
maintenance), lost business opportunities being late to market
(finding staff with necessary skills, additional lead time in
getting it 'more right').  Plus lots of other things.

Re: Is strong typing worth the cost?

[Preben Randhol]

On Wed, 01 May 2002 00:31:44 GMT, dmjones wrote:
> Frank Bearcd, tmoran:  Safe & correct is everything.
> 
> Me:  Making a profit is everything.

Ah if it this you mean, then what you need is a good marketing team and
you could probably sell air. ;-)

Preben

Re: Is strong typing worth the cost?

[Preben Randhol]

On Wed, 01 May 2002 00:31:44 GMT, dmjones wrote:
> Jim Rogers:  What are the parameters of cost?
> 
> Me:  Money.  Developers time (original development, subsequent
> maintenance), lost business opportunities being late to market
> (finding staff with necessary skills, additional lead time in
> getting it 'more right').  Plus lots of other things.

What about maintainability costs?

Preben

Re: Is strong typing worth the cost?

[Mike Silva]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns9201F90F50C5derekknosofcouk@62.253.162.108>...
> 
> Me:  I am dealing with developers who use a weakly typed
> language.  To change existing practice I need evidence
> that it is worthwhile.  The default is weak, I am not recommending
> anything unless I have evidence one way or the other.

How about doing what I did: keep track of each bug found in their
currently-developing code, and then determine whether strong typing
would have either prevented it or turned a multi-day debug into a
multi-minute debug.  This will prove to be a very sobering exercise,
especially in the case of bugs so nasty that they had programmers
considering new careers in door-to-door sales.

Mike

Re: Is strong typing worth the cost?

[Marin David Condic]

In the metrics I was involved in collecting that demonstrated a factor of
four reduction in errors by using Ada, we did exactly that. We did an
analysis of the change requests filed against the systems and categorized
them to determine what sort of errors went away. One of the categories that
saw the largest reductions was one that dealt with various math errors
relating to scaled integers versus Ada's fixed point types (with related
type checking). It was strong evidence that the strong typing Ada provided
contributed significantly to error reduction.

Of course, this implies that the shop in question has some sort of change
request system or other data source to analyze. I know of lots of software
operations where change control and configuration management are either
non-existent or so primitive that you wouldn't have the information needed
to determine what the bugs were. You can't improve your process if you don't
have a process. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Mike Silva" <mjsilva697@earthlink.net> wrote in message
news:27085883.0205010632.4c8225d8@posting.google.com...
>
> How about doing what I did: keep track of each bug found in their
> currently-developing code, and then determine whether strong typing
> would have either prevented it or turned a multi-day debug into a
> multi-minute debug.  This will prove to be a very sobering exercise,
> especially in the case of bugs so nasty that they had programmers
> considering new careers in door-to-door sales.
>

Re: Is strong typing worth the cost?

[Wes Groleau]

> How about doing what I did: keep track of each bug found in their
> currently-developing code, and then determine whether strong typing
> would have either prevented it or turned a multi-day debug into a
> multi-minute debug.  This will prove to be a very sobering exercise,
> especially in the case of bugs so nasty that they had programmers
> considering new careers in door-to-door sales.

I was once asked to do a report on the histories
of files on a project.  It was interesting to note
how many one- or two-year-old Java files had
very high version numbers compared to the 15-year-old
Ada files.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Is strong typing worth the cost?

[tmoran]

> of files on a project.  It was interesting to note how many one- or
> two-year-old Java files had very high version numbers compared to the
> 15-year-old Ada files.
  That sounds like a good proxy measure.  Can you write a short note for
Ada Letters or something?  Or how about looking at publicly posted G*PL
programs or something and counting changes submitted per SLOC per download.

Re: Is strong typing worth the cost?

[Pat Rogers]

<tmoran@acm.org> wrote in message
news:FWfA8.5083$PD6.3022266536@newssvr21.news.prodigy.com...
> > of files on a project.  It was interesting to note how many one- or
> > two-year-old Java files had very high version numbers compared to the
> > 15-year-old Ada files.
>   That sounds like a good proxy measure.  Can you write a short note for
> Ada Letters or something?  Or how about looking at publicly posted G*PL
> programs or something and counting changes submitted per SLOC per download.

The Ada Letters Technical Editor would be most happy to receive such a paper.
;-)

Pat Rogers
Technical Editor, Ada Letters

Re: Is strong typing worth the cost?

[Jim Rogers]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns9201F90F50C5derekknosofcouk@62.253.162.108>...
> All,
> 
> To summarise, no new research investigating the
> cost/benefit of using strong typing has come to light.
...
> Me:  I am dealing with developers who use a weakly typed
> language.  To change existing practice I need evidence
> that it is worthwhile.  The default is weak, I am not recommending
> anything unless I have evidence one way or the other.
> 
> Jim Rogers:  What are the parameters of cost?
> 
> Me:  Money.  Developers time (original development, subsequent
> maintenance), lost business opportunities being late to market
> (finding staff with necessary skills, additional lead time in
> getting it 'more right').  Plus lots of other things.

Your answers on cost parameters are still a bit vague. "Money" is not
a cost parameter. It is a system of paying for those parameters.

You are correct in seeing that lost business opportunities produce
negative economic results for a company. It appears that you have an
underlying assumption is that weak typing is a tool to avoid lost
business opportunities. Where is the proof for that assumption? If
your business model is one
where quality and correctness have no bearing on time to market, then
why bother with finding staff with necessary skills?

Companies I have worked for in the past have had some additional cost
factors to track:
* Initial design and development
* Maintenance
* Warranty Costs (the costs arising from dealing with unhappy
customers)
* Legal Costs (patents as well as injured party litigation)
* Reuse Costs (The costs of designing for reuse as well as the costs
of
               maintaining and re-releasing reused components)
* Talent (The cost of finding, training, and retaining staff with
necessary
          skills)
* Business Infrastructure (The facilities and tools needed to produce
and
               maintain software)
* Marketing/Sales

I see no way the choice of languages has a significant impact on
Marketing/
Sales. Most sales persons would not know the differences between C,
Ada, and
Visual Basic. Weak typing is assumed by its proponents to lower the
cost
of Initial Design and Development as well as Maintenance. The Rational
study comparing C and Ada contradicts that assumption. It shows that
the
cost of using Ada is consistently one half the cost of using C for
similar
projects. The Rational study tracked development, maintenance, and 
warranty costs for software.

Jim Rogers

Re: Is strong typing worth the cost?

[Marin David Condic]

That is consistent with my own study that found we doubled productivity and
cut errors by a factor of four where Ada was used. But that was also
monitoring projects with very long lifespans and where errors were not
acceptable. If you don't care that it works right and conduct no testing of
your original design and implementation, you can save a bunch of time to
market. If you fix no errors, you have no maintenance cost. So maybe the
proponents of weak typing are seeing lower cost and attributing it to weak
typing when in reality the lower cost is because of what/how they are
building software.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:82347202.0205010735.1d1a66c3@posting.google.com...
> Visual Basic. Weak typing is assumed by its proponents to lower the
> cost
> of Initial Design and Development as well as Maintenance. The Rational
> study comparing C and Ada contradicts that assumption. It shows that
> the
> cost of using Ada is consistently one half the cost of using C for
> similar
> projects. The Rational study tracked development, maintenance, and
> warranty costs for software.

Re: Is strong typing worth the cost?

[dmjones]

Jim,

>> Jim Rogers:  What are the parameters of cost?
>> 
>> Me:  Money.  Developers time (original development, subsequent
>> maintenance), lost business opportunities being late to market
>> (finding staff with necessary skills, additional lead time in
>> getting it 'more right').  Plus lots of other things.
> 
> Your answers on cost parameters are still a bit vague. "Money" is not
> a cost parameter. It is a system of paying for those parameters.

But developers time and lost business opportunities are the next level
down the chain.

> You are correct in seeing that lost business opportunities produce
> negative economic results for a company. It appears that you have an
> underlying assumption is that weak typing is a tool to avoid lost
> business opportunities. Where is the proof for that assumption?

Strong typing requires me to pay more attention to 100% of the
source I write.  By pay attention I mean I have to get it through
the compiler (the compiler will pick me up on type errors that I will
have to invest time in fixing).  Using a weakly typed language does
not require me to invest so much time up front.

Usage of my program, by customers, will not result in all
statements being executed.  Say 70-80% are not executed (I can dig up
some papers on this).

Knowing this my management has instituted an 'only test what the
initial customers are likely to use' policy (of course if they really
knew what they were doing they would have an 'only write what the
customer is likely to use' policy, but we are in a hurry to get things
out the door and once written any code is kept).

So I have saved time by only concentrating on a subset of the code.
Now the question is, what is the cost & benefits of weak/strong
typing on the code I do concentrate on?

A small group of people, starting from scratch, say under 100K SLOC,
working for 6 months.  I think weak typing could win.

More people, having to use existing code, longer time period, then
yes strong typing would win.  No proof on this (what bad habits I
have picked up by posting to this group ;-), just practical experience.

> * Maintenance

I would rather pay higher maintenance costs and be in business
than have lower maintenance costs if I were in business.

I know from experience that many successful companies build
some of their products from the most tangled mess of source code.

> * Warranty Costs (the costs arising from dealing with unhappy
> customers)
> * Legal Costs (patents as well as injured party litigation)

These are the only issues that might generate a change of management
attitude.

Jerrey Carter:
> I recall seeing, but can't now find, an article that put the worldwide
> cost of crackers exploiting security flaws at $10G for a recent year.

Unless the vendor of the software pays, these are not costs in
the sense being discussed here.

Re: Is strong typing worth the cost?

[Dan Andreatta]

dmjones <derek@NOSPAMknosof.co.uk> wrote in 
news:Xns9201C885373ADderekknosofcouk@194.168.222.64:

> Strong typing requires me to pay more attention to 100% of the
> source I write.  By pay attention I mean I have to get it through
> the compiler (the compiler will pick me up on type errors that I will
> have to invest time in fixing).  Using a weakly typed language does
> not require me to invest so much time up front.
> 
To me, it seems the exact opposite. I can be a little sloppier, because I 
know that those errors will be caught by the compiler.

Dan

Re: Is strong typing worth the cost?

[Darren New]

dmjones wrote:
> So I have saved time by only concentrating on a subset of the code.
> Now the question is, what is the cost & benefits of weak/strong
> typing on the code I do concentrate on?
> 
> A small group of people, starting from scratch, say under 100K SLOC,
> working for 6 months.  I think weak typing could win.

This definitely sounds like a situation in which Extreme Programming
could pay off. Check it out via google.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Jeffrey Carter]

Darren New wrote:
> 
> dmjones wrote:
> >
> > A small group of people, starting from scratch, say under 100K SLOC,
> > working for 6 months.  I think weak typing could win.
> 
> This definitely sounds like a situation in which Extreme Programming
> could pay off. Check it out via google.

"Anything over 50,000 lines of code, you should be using Ada." -- Dennis
Ritchie

-- 
Jeffrey Carter

Re: Is strong typing worth the cost?

[Wes Groleau]

> "Anything over 50,000 lines of code, you should be using Ada." -- Dennis
> Ritchie

I was told that was P. J. Plauger.

??

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <Xns9201C885373ADderekknosofcouk@194.168.222.64>, dmjones <derek@NOSPAMknosof.co.uk> writes:

> Strong typing requires me to pay more attention to 100% of the
> source I write.  By pay attention I mean I have to get it through
> the compiler (the compiler will pick me up on type errors that I will
> have to invest time in fixing).  Using a weakly typed language does
> not require me to invest so much time up front.

I think of it as the compiler locating errors I would not even hear
about until unit test, system test, field test or production use.

> Usage of my program, by customers, will not result in all
> statements being executed.  Say 70-80% are not executed (I can dig up
> some papers on this).
> 
> Knowing this my management has instituted an 'only test what the
> initial customers are likely to use' policy (of course if they really

The idea that one can predict usage patterns is a great leap of faith,
and defect removal is ten times more expensive after the fact.

Re: Is strong typing worth the cost?

[Jeffrey Carter]

dmjones wrote:
> 
> Jerrey Carter:

I thought my name was Jeffrey, but maybe it changed recently and I
didn't know about it.

> > I recall seeing, but can't now find, an article that put the worldwide
> > cost of crackers exploiting security flaws at $10G for a recent year.
> 
> Unless the vendor of the software pays, these are not costs in
> the sense being discussed here.

The vendor of the software certainly should pay. Every company that
loses money from these flaws should sue the vendors. Even if they won
every case the cost of litigation would make it worth correcting the
software

-- 
Jeffrey Carter

Re: Is strong typing worth the cost?

[John English]

Jeffrey Carter wrote:
> 
> dmjones wrote:
> >
> > Unless the vendor of the software pays, these are not costs in
> > the sense being discussed here.
> 
> The vendor of the software certainly should pay. Every company that
> loses money from these flaws should sue the vendors. Even if they won
> every case the cost of litigation would make it worth correcting the
> software

A case in point is the "I love you" virus. Instead of pursuing some
hapless idiot in the Philippines and putting him on trial for releasing
a virus, why didn't they sue Microsoft for handing the guy the lethal
weapon (VBScript) which has the power to do anything at all to the
machine
it runs on and which, by default, Microsoft mail clients will run
automatically. I know who I consider the guilty party here... and
the companies who lost out from the virus would stand more chance
of a meaningful settlement from Microsoft than from a lone Filipino.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Is strong typing worth the cost?

[Darren New]

John English wrote:
> I know who I consider the guilty party here... and
> the companies who lost out from the virus would stand more chance
> of a meaningful settlement from Microsoft than from a lone Filipino.

So who would you sue for the Morris worm that took advantage of a
similar hole in sendmail?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <3CD16729.E695572@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> John English wrote:
>> I know who I consider the guilty party here... and
>> the companies who lost out from the virus would stand more chance
>> of a meaningful settlement from Microsoft than from a lone Filipino.
> 
> So who would you sue for the Morris worm that took advantage of a
> similar hole in sendmail?

The person using sendmail, if they did not have a vendor on which
they could pin it.

Re: Is strong typing worth the cost?

[Preben Randhol]

On 2 May 2002 11:41:27 -0500, Larry Kilgallen wrote:
> In article <3CD16729.E695572@san.rr.com>, Darren New <dnew@san.rr.com> writes:
>> John English wrote:
>>> I know who I consider the guilty party here... and
>>> the companies who lost out from the virus would stand more chance
>>> of a meaningful settlement from Microsoft than from a lone Filipino.
>> 
>> So who would you sue for the Morris worm that took advantage of a
>> similar hole in sendmail?
> 
> The person using sendmail, if they did not have a vendor on which
> they could pin it.

How can one sue if the license agreements says: Use at own risk... no
responsibility ... etc, which also Microsoft says. I don't really see
that it is any better to buy software from Microsoft just because it is
a commercial company that one can give the blame? How can one get
anywhere in court with it?

Preben

Re: Is strong typing worth the cost?

[Larry Kilgallen]

In article <slrnad31ag.99k.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> On 2 May 2002 11:41:27 -0500, Larry Kilgallen wrote:
>> In article <3CD16729.E695572@san.rr.com>, Darren New <dnew@san.rr.com> writes:
>>> John English wrote:
>>>> I know who I consider the guilty party here... and
>>>> the companies who lost out from the virus would stand more chance
>>>> of a meaningful settlement from Microsoft than from a lone Filipino.
>>> 
>>> So who would you sue for the Morris worm that took advantage of a
>>> similar hole in sendmail?
>> 
>> The person using sendmail, if they did not have a vendor on which
>> they could pin it.
> 
> How can one sue if the license agreements says: Use at own risk... no

In the United States there is no question about one's right to sue.
The issue is one of whether one would prevail.  A lawyer would look
to issues like implied warranty, strict liability and contracts of
adhesion, along with others.

> responsibility ... etc, which also Microsoft says. I don't really see
> that it is any better to buy software from Microsoft just because it is
> a commercial company that one can give the blame? How can one get
> anywhere in court with it?

One must balance the presence of a known fiscally sound vendor against
the quality of the software, and make a judgement whom to patronize.

Re: Is strong typing worth the cost?

[Andrzej Filip]

Preben Randhol wrote:

>On 2 May 2002 11:41:27 -0500, Larry Kilgallen wrote:
>
>>In article <3CD16729.E695572@san.rr.com>, Darren New <dnew@san.rr.com> writes:
>>
>>>John English wrote:
>>>
>>>>I know who I consider the guilty party here... and
>>>>the companies who lost out from the virus would stand more chance
>>>>of a meaningful settlement from Microsoft than from a lone Filipino.
>>>>
>>>So who would you sue for the Morris worm that took advantage of a
>>>similar hole in sendmail?
>>>
>>The person using sendmail, if they did not have a vendor on which
>>they could pin it.
>>
>
>How can one sue if the license agreements says: Use at own risk... no
>responsibility ... etc, which also Microsoft says. I don't really see
>that it is any better to buy software from Microsoft just because it is
>a commercial company that one can give the blame? How can one get
>anywhere in court with it?
>
I would call selling anything under such licence agreement a fraud.
But I am not a lawyer :-)

BTW Have you noticed that the "disclaimers" get longer and longer ?

-- 
Andrzej (Andrew) A. Filip  anfi@box43.pl  http://www.polbox.com/a/anfi/
366A 5DD7 7707 379C 9251  32AE C948 0BD2 7D99 688A  expires: 2003-01-25
I may disagree with the following *random epigram* :
I never cheated an honest man, only rascals.  They wanted something for
nothing.  I gave them nothing for something.
		-- Joseph "Yellow Kid" Weil

Re: Is strong typing worth the cost?

[Georg Bauhaus]

Darren New <dnew@san.rr.com> wrote:
: 
: So who would you sue for the Morris worm that took advantage of a
: similar hole in sendmail?

Microsoft doesn't make a noticable effort to warn you about the
possibly lethal power of VBScript, used per default in a client
program with other interesting default wrt personal/company data.
To me that is the important point in  John's message.

-georg

Re: Is strong typing worth the cost?

[Robert I. Eachus]

Darren New <dnew@san.rr.com> wrote:
> 
> So who would you sue for the Morris worm that took advantage of a
> similar hole in sendmail?


It depends, and if you were not flipping off a one liner, you would know 
that some people did end up taking the heat.

The "bug" in Unix sendmail had been fixed, and the patch was available 
for older systems.  If your system was at risk--to that threat of the 
Morris worm--then you had an older Unix system which had not had the 
security patch applied.  If it got in by copying the /etc/passwd/ file 
via NFS and cracking it, then your error was in not having a shadow 
password file, or permissions set correctly on it.

Re: Is strong typing worth the cost?

[Florian Weimer]

John English <je@brighton.ac.uk> writes:

> A case in point is the "I love you" virus. Instead of pursuing some
> hapless idiot in the Philippines and putting him on trial for
> releasing a virus, why didn't they sue Microsoft for handing the guy
> the lethal weapon (VBScript) which has the power to do anything at
> all to the machine it runs on and which, by default, Microsoft mail
> clients will run automatically.

ActiveX is widely accepted and much more dangerous (I can read a WSH
script and decide if it is fishy, but i can't do this with an ActiveX
control).

Re: Is strong typing worth the cost?

[Jim Rogers]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns9201C885373ADderekknosofcouk@194.168.222.64>...
> >> Jim Rogers:  What are the parameters of cost?
> >> 
> Strong typing requires me to pay more attention to 100% of the
> source I write.  By pay attention I mean I have to get it through
> the compiler (the compiler will pick me up on type errors that I will
> have to invest time in fixing).  Using a weakly typed language does
> not require me to invest so much time up front.
> 
> Usage of my program, by customers, will not result in all
> statements being executed.  Say 70-80% are not executed (I can dig up
> some papers on this).
> 
> Knowing this my management has instituted an 'only test what the
> initial customers are likely to use' policy (of course if they really
> knew what they were doing they would have an 'only write what the
> customer is likely to use' policy, but we are in a hurry to get things
> out the door and once written any code is kept).

I would be very uncomfortable working in an environment where 70-80% of
my code was unwanted and unused by customers. It appears that your
company suffers from a poor requirements definition process. Clearly,
you will get the greatest benefit from designing and coding only the
features actually used by your customers. 

Nothing is free, however. Determining your actual customer needs costs
time and money. On the other hand, not knowing what your customer wants
and needs is apparently costing you 70-80% of your development budget.

There is nothing that a choice of languages could do to improve your
software development expenses as much as simply determining what your
actual requirements are. This will then allow you to think about 100%
of your code. At that point you can also be concerned with the "trivial"
points of quality and reliability.

Jim Rogers

Re: Is strong typing worth the cost?

[Jeffrey Carter]

What is the cost/benefit ratio of weak typing? In "Managing Software
Security Risks", Gary McGraw (IEEE Computer, 2002 April) says "Buffer
overflows have been causing serious security problems for decades and
now account for nearly half of all major security bugs resulting in CERT
Coordination Center (http://www.cert.org/) advisories.". Buffer
overflows result from the use of weakly typed languages that do not
automatically check array accesses against array bounds by developers
who do not manually perform such checks. About half of all major
security flaws would not exist if the software had been developed in a
strongly typed language.

I recall seeing, but can't now find, an article that put the worldwide
cost of crackers exploiting security flaws at $10G for a recent year.
The best I can find is http://www.statonline.com/technologies/facts.asp,
which says, "In 1998, 163 organizations reported losing $123.7 million
to computer security breaches, or about $759,000 per organization. (1999
CSI/FBI Report)". There need be only about 13,000 organizations
worldwide for the $10G figure to be correct.

That would put the cost of buffer overflows, a subset of weak typing, at
about $61M for 163 organizations in 1998, or about $330k/organization.
If the $10G figure is correct, the worldwide cost is about $5G/year. If
my memory is off by an order of magnitude, it would be $500M/year. All
of these figures represent a significant cost from a subset of weak
typing.

What is the benefit of weak typing? There appears to be none, which puts
the cost/benefit ratio for this instance of weak typing at or
approaching infinity.

One benefit of strong typing would be the elimination of about half of
all major security flaws, a significant benefit. The cost of obtaining
this benefit would have been small if an appropriate language choice had
been made for this software (remember that C and Pascal are
contemporaries, so it's not as if this technology was unknown when
networking software was developed). This is evidence that the
cost/benefit ratio of strong typing is smaller than the ratio for weak
typing.

-- 
Jeffrey Carter

Re: Is strong typing worth the cost?

[Marin David Condic]

Very interesting and another bit of ammo to keep in my back pocket. However,
there is one weakness here - the example you are talking about applies only
to some software domains. It makes a good "In General, Ada is better..."
kind of case, but the question can be "But is it better in *my specific*
problem domain?" and the answer may not always be "Yes." Not all software
runs on networks and needs to be cognizant of security risks, so it won't
incur the costs described here. (There probably will be other costs!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3CD01895.A2CD5F41@boeing.com...
> What is the cost/benefit ratio of weak typing? In "Managing Software
> Security Risks", Gary McGraw (IEEE Computer, 2002 April) says "Buffer
> overflows have been causing serious security problems for decades and

Re: Is strong typing worth the cost?

[Wes Groleau]

> Coordination Center (http://www.cert.org/) advisories.". Buffer
> overflows result from the use of weakly typed languages that do not
> automatically check array accesses against array bounds by developers
> who do not manually perform such checks. About half of all major
> security flaws would not exist if the software had been developed in a
> strongly typed language.

We may be mixing definitions here.  These bugs theoretically
cannot happen in Java, yet compared to Ada, Java is weakly typed.

(Depending AGAIN on how you define strong/weak typing)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Is strong typing worth the cost?

[Brian Gaffney]

dmjones <derek@NOSPAMknosof.co.uk> wrote in message news:<Xns9201F90F50C5derekknosofcouk@62.253.162.108>...
 . . .
> Frank Bearcd, tmoran:  Safe & correct is everything.
> 
> Me:  Making a profit is everything.
> 
 . . .
> 
> I see strong typing as a tool for cost reduction in acheiving
> a specified level of software reliability.  Nothing more.
> 
> Jim Rogers:  What are the parameters of cost?
> 
> Me:  Money.  Developers time (original development, subsequent
> maintenance), lost business opportunities being late to market
> (finding staff with necessary skills, additional lead time in
> getting it 'more right').  Plus lots of other things.

It sounds like the question you originally asked will not get you what
you're looking for, and no one here can (directly) answer what you
need.  What you really need to do is find out what costs _you_ money
and what you can do to reduce costs for _your_ software, developers,
processes, etc.  If you can show what percentage of bugs you see are
caused by (your definition of) this issue, you would know you're on
the right track.  However, in that case, you'd probably also have the
answer you're looking for.  You may also find other things that can be
more useful.

If you're looking for ammunition to push for strong typing, any
evidence you get from (us) 'Ada zealots' may not be too effective
(especially to 'C programmers'):-)  I think you would still need to
get evidence based on your own software, or at least domain.  You may
also want to look on Comp.Software-Eng.

Re: Is strong typing worth the cost?

[dmjones]

All,
 
> I have been trying to locate evidence that the cost of the use
> of strong typing is repaid by a greater benefit.

I have been following up on the references posted here (thanks all).

Figure 4 of "Impact of Ada and object-oriented design in the
flight dynamics division of Goddard Space Flight Center",
SEL-95-001 shows a graph of "total types per statement" vs
time (a five year period).  The increase is claimed to be
due to an increase in use of strong typing.

The cited reference is:
"Experiments in software engineering technology" by
McGarry & Waligora.  From SEL-91-006.

This paper does not appear to be available online.
Does anybody have a copy?

How is "total types per statement" measured?
Is it an average of the number of types appearing in the
same statement?

Re: Is strong typing worth the cost?

[Martin Dowie]

> The cited reference is:
> "Experiments in software engineering technology" by
> McGarry & Waligora.  From SEL-91-006.
>
> This paper does not appear to be available online.
> Does anybody have a copy?

Try

http://sel.gsfc.nasa.gov/website/documents/online-doc/95-001.pdf

Re: Is strong typing worth the cost?

[Preben Randhol]

On Fri, 3 May 2002 08:59:47 +0100, Martin Dowie wrote:
>> The cited reference is:
>> "Experiments in software engineering technology" by
>> McGarry & Waligora.  From SEL-91-006.
>>
>> This paper does not appear to be available online.
>> Does anybody have a copy?
> 
> Try
> 
> http://sel.gsfc.nasa.gov/website/documents/online-doc/95-001.pdf

He is looking for SEL-91-006 :-)

Preben

Re: Is strong typing worth the cost?

[Martin Dowie]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnad4jcn.1ps.randhol+abuse@kiuk0152.chembio.ntnu.no...
> On Fri, 3 May 2002 08:59:47 +0100, Martin Dowie wrote:
> >> The cited reference is:
> >> "Experiments in software engineering technology" by
> >> McGarry & Waligora.  From SEL-91-006.
> >>
> >> This paper does not appear to be available online.
> >> Does anybody have a copy?
> >
> > Try
> >
> > http://sel.gsfc.nasa.gov/website/documents/online-doc/95-001.pdf

Whoops! I need a strongly typed newsgroup browser/brain!

Re: Is strong typing worth the cost?

[Preben Randhol]

On Fri, 03 May 2002 02:45:56 GMT, dmjones wrote:
> All,
>  
>> I have been trying to locate evidence that the cost of the use
>> of strong typing is repaid by a greater benefit.
> 
> I have been following up on the references posted here (thanks all).
> 
> Figure 4 of "Impact of Ada and object-oriented design in the
> flight dynamics division of Goddard Space Flight Center",
> SEL-95-001 shows a graph of "total types per statement" vs
> time (a five year period).  The increase is claimed to be
> due to an increase in use of strong typing.

As I understand the text and Figure it shows how Ada developers were
using more strong typing and generic and less tasking and shorter
package sizes over the years from 1985 to 1993. So they were starting to
utilise the features of the language.

> How is "total types per statement" measured?
> Is it an average of the number of types appearing in the
> same statement?

It says earlier that the statement count is "the number of logical
statements and declarations". It further says that since 1985 the number
of lines per statement for FORTRAN increased from 2.5 to 5 due to
commenting, where for Ada it went from 6 to 3 as more of the Ada coding
style was used. So it may look like strong typing is doing much of the
commenting for you, but this is just a guess as I haven't seen the
report referred to either. But at least I think it is a fair
interpretation.

But I think that the gains of strong typing are

   reduction in debugging time, more errors are found during compilation
   more information can be retrieved, ranges etc...
   leads to a more self-commenting source code.
   makes maintainability easier

though I have no scientific proof. Neither do I see any proof saying
that weak typing is better in any way.

Are there really a lot of projects out there where maintainability isn't
an issue? I can understand that software companies may not care about
this, because if they have to rewrite the entire program in order to
give the customer a new version with additional features/removal of
errors, they would use more time and get more paid. But if the customers
don't take this into account, then I don't understand. Given the history
of Y2K, it shows clearly IMHO that maintaining the system you have is
done to a great extent even if the customer thought he would switch to a
new superduper system in the near future. I hope that the times were
customers review software engineers as sort of witch-doctors of the
village are over. :-) There are two much magic mumbo-jumbo in the air
and I for one thinks that bug is a euphemism for error. ;-) 

OK enough on this, I'll go back to do some more strong typed coding and
code reading. :-)

Preben
-- 
�There are three things you can do to a woman. You can love her, suffer
 for her, or turn her into literature.�  - Justine, by Lawrence Durrell