On Mon, 17 Nov 2003 11:38:50 -0800, ···@jpl.nasa.gov (Erann Gat)
wrote:
>
>We've been having so much fun having theological arguments about the
>relative merits of static versus dynamic typing I thought I'd spoil it all
>by introducing an actual data point.
>
This is an interesting post, Erann, and a very interesting thread--I
haven't yet read all the hundreds of followups but will respond to
this initial one.
I agree with your point that static typing can be a negative. In fact,
anything is a negative to the extent that it prevents you from
spending sufficient time on the most important tasks. I can't deny
that it's nice for the compiler to find errors and tell me about them.
However, we need to look at how programmers go about their work.
In my experience, as an engineer in quite a few companies and
sometimes a manager, engineers are difficult to manage (no surprise
here right ;-) They only follow instructions if it makes sense to
them, and are often critical of authority, to over-generalize. These
are important traits of engineers.
However, engineers are slaves to their development tools. For some
reason, they will do whatever the compiler tells them to. I guess this
is from years of practical experience--it just doesn't get you
anywhere to argue with it.
When you work in a static language, say C++, you write some code. Then
you try to run it. At this point the compiler starts telling you what
to do: you need to change this here, and that there, and on and on
until it will let you compile. Even though you don't know what the
type will be in many instances, and the code doesn't care (say all it
does is collect something and pass it on), you are forced to make
rigorous statements throughout your code about all kinds of things you
haven't yet determined. This is time consuming, but we learn to live
with it. Later when anything changes, we will spend as much time going
all through the code and changing them.
Then we get into linker hell. The linker complains about this function
and that function, and we learn of libraries we didn't know existed
and never would have needed. This is to me the worst kind of hell.
However, we eventually get past that, and the program runs. Not
correctly, but we go home satisfied. We can correct the errors in
logic the next day. But wait--would it not have been better to check
the logic errors as soon as we made them rather than later? The least
important errors, the incorrect types, which can easily be found and
fixed later, are taking all our initial development time. We are
forced to make premature statements about things before we can test
the actual logic that we are coding. The compiler and linker force us
to use our mental energy early on relatively unimportant errors, when
big errors are ignored by it. At some level, we, like the compiler,
are likely to give the logic errors less overal quality attention.
Programming with Lisp is a fundamental reversal of this. It lets us
put type checking where we want it--either at run time for
flexibility, or later in the development cycle for efficiency and
rigorousness. But it does not get in the way of testing our code early
and often. It also does not make us link in libraries we don't need
prior to being able to do anything.
Roger
Roger Corman wrote:
> When you work in a static language, say C++,
C++ is about as representative of static(ally typed) languages
as the Trabby is of the German car industry, if you get what
I mean :-)
Regards
--
Adrian Hey
In article <····················@news.demon.co.uk>, Adrian Hey
<····@NoSpicedHam.iee.org> wrote:
> Roger Corman wrote:
>
> > When you work in a static language, say C++,
>
> C++ is about as representative of static(ally typed) languages
> as the Trabby is of the German car industry, if you get what
> I mean :-)
There are a lot more people programming in C++ today than driving
trabbys. In fact, there are probably more people programming in C++ today
than ever drove trabbys. Like it or not, C++ is representative of
statically typed languages outside the ivory tower.
E.
In comp.lang.functional Erann Gat <·········@jpl.nasa.gov> wrote:
> There are a lot more people programming in C++ today than driving
> trabbys. In fact, there are probably more people programming in C++ today
> than ever drove trabbys. Like it or not, C++ is representative of
> statically typed languages outside the ivory tower.
And dynamic typing is championed by Perl. Conclusion: to reflect the
state of the industry, future comparisons of the merits of static and dynamic
typing should be done based on C++ and Perl.
..
pekka
In article <············@oravannahka.helsinki.fi>, Pekka A Uronen
<········@melkinpaasi.cs.Helsinki.FI> wrote:
> In comp.lang.functional Erann Gat <·········@jpl.nasa.gov> wrote:
> > There are a lot more people programming in C++ today than driving
> > trabbys. In fact, there are probably more people programming in C++ today
> > than ever drove trabbys. Like it or not, C++ is representative of
> > statically typed languages outside the ivory tower.
>
> And dynamic typing is championed by Perl. Conclusion: to reflect the
> state of the industry, future comparisons of the merits of static and dynamic
> typing should be done based on C++ and Perl.
For the topic at hand I think that's not unreasonable.
How many instances do you know of run-time *type* errors in Perl
production code (i.e. errors that would have been caught at compile time
if Perl had static type checking) causing serious problems?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> How many instances do you know of run-time *type* errors in Perl
> production code (i.e. errors that would have been caught at compile
> time if Perl had static type checking) causing serious problems?
I know of some instances of run-time errors in Perl production code
that would have been caught at compile time had only Perl
distinguished properly between numbers, strings & booleans. but it
does not (they are all of type "scalar"), so static type checking
wouldn't help any.
like, the scalar "0" is false in Perl, but the scalar "1" is true.
Perl is a bad example for _anything_ except horrible mess, sorry.
perhaps Python could be a better example.
--
A computer, to print out a fact,
Will divide, multiply, and subtract.
But this output can be
No more than debris,
If the input was short of exact.
-- Gigo
From: Karl A. Krueger
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <bpm2kq$884$1@baldur.whoi.edu>
In comp.lang.lisp Michael Livshin <······@cmm.kakpryg.net> wrote:
> I know of some instances of run-time errors in Perl production code
> that would have been caught at compile time had only Perl
> distinguished properly between numbers, strings & booleans. but it
> does not (they are all of type "scalar"), so static type checking
> wouldn't help any.
>
> like, the scalar "0" is false in Perl, but the scalar "1" is true.
Weirder, consider the promulgation of "0 but true" ...
In Perl, the number 0 is of scalar type.
In boolean context, it is false.
The string "0" is also of scalar type.
In numeric context, it is equal to the number 0.
In boolean context, it is false.
The string "0a" is also of scalar type.
In numeric context, it is equal to the number 0. (Not the number 10!)
In boolean context, it is true.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
On Fri, 21 Nov 2003 22:12:44 +0000 (UTC), "Karl A. Krueger"
<········@example.edu> wrote:
>Weirder, consider the promulgation of "0 but true" ...
>
>In Perl, the number 0 is of scalar type.
>In boolean context, it is false.
>
>The string "0" is also of scalar type.
>In numeric context, it is equal to the number 0.
>In boolean context, it is false.
>
>The string "0a" is also of scalar type.
>In numeric context, it is equal to the number 0. (Not the number 10!)
>In boolean context, it is true.
There are some similar anomalies in XPath expressions. The string()
function, which converts an arbitrary object into its string equivalent,
converts boolean objects into the strings "true" and "false" as
appropriate. But like all non-empty strings in XPath, the string "false"
evaluates to true when involved in a boolean expression.
Similarly, an IEEE 754 numeric value of infinity is converted to the
string "Infinity," but converting "Infinity" back to a number yields a
NaN.
-Steve
Michael Livshin <······@cmm.kakpryg.net> wrote:
>
> Perl is a bad example for _anything_ except horrible mess, sorry.
Like C++. Which was pretty much Pekka's point, I guess.
"Andreas Rossberg" <········@ps.uni-sb.de> writes:
> Michael Livshin <······@cmm.kakpryg.net> wrote:
>>
>> Perl is a bad example for _anything_ except horrible mess, sorry.
>
> Like C++. Which was pretty much Pekka's point, I guess.
in the so called grand scheme of things, this is quite right.
WRT types, no. Perl has too few scalar types (one), and it is fair to
compare it to C++ when considering the damage it inflicts on
programmer's way of thinking (slashes permanently glued to both sides
of the brain, etc), but it's otherwise a safe language. in my (rather
old by now, I have to admit) experience, Perl's dynamic typing nature
never caused me any problems (i.e. my running software never failed
doe to passing a scalar where list was expected, or a list where a
hash was expected, or anything like that). perhaps it would cause me
problems if there were more types in the first place, I don't know. I
don't have any such problems in CL (which is what I use these days
when I can get away with not using What Everyone Else Is Using), so I
guess it wouldn't.
--
Debugging? Klingons do not debug. Our software does not coddle the
weak.
-- Klingon Programmer
·········@jpl.nasa.gov (Erann Gat) writes:
>How many instances do you know of run-time *type* errors in Perl
>production code (i.e. errors that would have been caught at compile time
>if Perl had static type checking) causing serious problems?
The Mercury distribution includes one Perl program, mtags, which is now
500 lines long. I can't give you any examples of _serious_ problems,
since that program is only used for inessential purposes (if it was
used for more important purposes, we wouldn't have used Perl!).
Indeed, this whole program is a bit of hack, using Perl regular
expressions when it really ought to be properly parsing the input.
But nevertheless, I can give you an analysis of the bugs that occurred
in that program.
This program has had 31 CVS revisions. Most of those changes are
improvements in functionality, but six of them are bug fixes
(they mention the word "bug" and/or "fix" in their CVS log message).
Of those six bugs, only four appear to have made it into an official
release; the other two were fixed before then.
Of those four released bugs, two could have been caught at compile
time if Perl's "-w" option had been used. One of them was an incorrect
variable name (using "cmdfile" instead of "srcfile", where "cmdfile" did
not occur anywhere else in the program). The other was a syntax error
("break;" instead of "last;").
I don't know why `-w' wasn't used. It may have been that the program
had originally been converted from an awk script, and the output of the
awk-to-perl program a2p produces warnings from `perl -w'. Or maybe the
original programmer just wasn't aware of `-w' or forgot about it. Or
maybe there were concerns about whether the changes required to make the
code work with `-w' would cause compatibility problems with older versions
of Perl. But in any case, it wasn't. This illustrates the problem of
having safety checks turned off by default.
Of the two remaining bugs, one of them was an infinite loop which was
caused by ignoring the possibility of end-of-file in a read line operation
("$_ = <srcfile>;" instead of "$_ = <srcfile> || last;"). If the program
had been written in Mercury, I very strongly doubt that bug would have
occurred, because Mercury's operation to read a line as a string will
return a discriminated union type with three alternatives, ok(Line),
eof, or error(ErrorMsg), so the programmer is reminded that they need
to consider all three possibilities.
Of course, a similar library design would be possible in a dynamically
typed language, but this is very uncommon; the dynamically typed style
is to return values which are discriminated only by their implicit
type tags. Also, using such a design wouldn't be as effective in a
dynamically typed language, because statically typed languages will
usually issue warnings or errors for inexhaustive pattern matches,
whereas dynamically typed languages don't. In Mercury, if you wanted
to ignore the other two cases, it would not be enough to write
read_line(Result, !IO),
Result = ok(Line),
... process Line ...
because that would result in a determinism error, due to the pattern
match on Result being non-exhaustive. Instead, you'd have to write
something like
read_line(Result, !IO),
(if Result = ok(Line) then
... process Line ...
else
throw "got end-of-file or error"
).
At that point, the programmer has almost certainly at least considered
the end-of-file case, and so they are much less likely to write code which
does the wrong thing in that case.
The last remaining bug was a regular expression which was well-formed,
but did not match the programmer's intention. I do not think static
typing would have caught that error.
Still, we're left with the following conclusion: of the four bugs that
made it into the released code, enabling static checking by default would
have avoided two of them, and a third would probably have been avoided
by using a library design of the kind common in statically typed programming
languages but not in dynamically typed languages, and this would be
even more likely if the language checked for inexhaustive pattern
matches, as is generally only possible in statically typed languages.
Only one of the four would have been likely to occur if the code had been
written in Mercury.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From: Joe Marshall
Subject: Re: Why I don't believe in static typing
Date:
Message-ID: <r801lm5f.fsf@ccs.neu.edu>
Pekka A Uronen <········@melkinpaasi.cs.Helsinki.FI> writes:
> In comp.lang.functional Erann Gat <·········@jpl.nasa.gov> wrote:
>> There are a lot more people programming in C++ today than driving
>> trabbys. In fact, there are probably more people programming in C++ today
>> than ever drove trabbys. Like it or not, C++ is representative of
>> statically typed languages outside the ivory tower.
>
> And dynamic typing is championed by Perl. Conclusion: to reflect the
> state of the industry, future comparisons of the merits of static and dynamic
> typing should be done based on C++ and Perl.
Ok with me. Followups to comp.lang.perl
Erann Gat wrote:
>
> There are a lot more people programming in C++ today than driving
> trabbys.��In�fact,�there�are�probably�more�people�programming�in�C++
> today than ever drove trabbys.��Like�it�or�not,�C++�is�representative
> of statically typed languages outside the ivory tower.
Yes but I expect here on comp.lang.functional that saying "statically
typed" should mean haskell,ocaml or sort of. They have static typing
but also polymorphism, for example, and type inference. All this makes
programming with static types much more comfortable than C++, please
understand that people who advocates static types here is talking about
functional statically typed languages.
V.
On Fri, 21 Nov 2003 17:26:05 GMT, Vincenzo aka Nick Name
<··················@yahoo.it> wrote:
>Erann Gat wrote:
>
>>
>> There are a lot more people programming in C++ today than driving
>> trabbys.��In�fact,�there�are�probably�more�people�programming�in�C++
>> today than ever drove trabbys.��Like�it�or�not,�C++�is�representative
>> of statically typed languages outside the ivory tower.
>
>Yes but I expect here on comp.lang.functional that saying "statically
>typed" should mean haskell,ocaml or sort of. They have static typing
>but also polymorphism, for example, and type inference. All this makes
>programming with static types much more comfortable than C++, please
>understand that people who advocates static types here is talking about
>functional statically typed languages.
You are making a good point Vincenzo. This is cross-posted on
comp.lang.lisp, and I got on it from there. From a common lisp user
perspective I tend to think of more widely noticed languages
(c/c++/java) and implicitly refer to them to contrast lisp's dynamic
nature. I know that more innovative statically typed languages have
much to offer.
OTOH, I like C++, a lot, as well as java, and feel they have their
places. Although I admit that C++ can seem like a big ugly mess (like
my office, or Common Lisp :-) it is a great toolkit of features and
can be elegant in its own way.
Erann Gat wrote:
> There are a lot more people programming in C++ today than driving
> trabbys. In fact, there are probably more people programming in C++ today
> than ever drove trabbys.
Do you have any empirical evidence to justify this claim?
Please cite your sources. This stuff matters if you expect
anyone to take dynamic typing seriously.
Regards
--
Adrian Hey
In article <·····················@news.demon.co.uk>, Adrian Hey
<····@NoSpicedHam.iee.org> wrote:
> Erann Gat wrote:
>
> > There are a lot more people programming in C++ today than driving
> > trabbys. In fact, there are probably more people programming in C++ today
> > than ever drove trabbys.
>
> Do you have any empirical evidence to justify this claim?
> Please cite your sources. This stuff matters if you expect
> anyone to take dynamic typing seriously.
Since the Trabant went out of production in 1991 and was notoriously
unreliable I assumed few survived today, but according to
http://home.clara.net/peterfrost/trabant.html "Today there is a strong
following for the Trabant, many 100s of thousands are still in use..."
Unfortunately, there's no date on the Web page so it's not clear whether
the "today" being referred to by the Web page is the same as today's
"today", but it doesn't matter -- it's still enough to call my reasoning
into question.
So I'll amend my claim and say that the percentage of programmers who use
C++ is vastly larger than the percentage of drivers who ever drove
trabbys. Only 3 million Trabants were produced throughout the car's
entire production run
(http://www.rferl.org/nca/special/10years/germany3.html). By way of
contrast, in 1998, Honda produced 7 million cars in North America alone
(http://world.honda.com/news/1998/c980414.html). As for figuring out what
percentage of programmers use C++ that is left as an exercise.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> Since the Trabant went out of production in 1991 and was notoriously
> unreliable I assumed few survived today,
Having been a proud owner once myself, I can tell you that it was not
"notoriously unreliable" -- or certainly not more so than many an
american car. On the other hand, it really was not much of a car
("cardboard" enclosure, 26 horsepower, 60Mph top speed, tiny, loud,
stinky ...), so based on these datapoints I am suprised myself that so
many are still out in the wild. But people get emotionally attached
to all kinds of wierd stuff, so maybe one should not be suprised after
all.
Matthias
Erann Gat wrote:
> Since the Trabant went out of production in 1991 and was notoriously
> unreliable I assumed few survived today, but according to
> http://home.clara.net/peterfrost/trabant.html "Today there is a strong
> following for the Trabant, many 100s of thousands are still in use..."
> Unfortunately, there's no date on the Web page so it's not clear whether
> the "today" being referred to by the Web page is the same as today's
> "today", but it doesn't matter -- it's still enough to call my reasoning
> into question.
Mozilla reports it as "Modified: Thursday, Feb 8 2001 00:46:45".
Regards,
Jo
In article <············@news.oberberg.net>, Joachim Durchholz
<·················@web.de> wrote:
> Erann Gat wrote:
> > Since the Trabant went out of production in 1991 and was notoriously
> > unreliable I assumed few survived today, but according to
> > http://home.clara.net/peterfrost/trabant.html "Today there is a strong
> > following for the Trabant, many 100s of thousands are still in use..."
> > Unfortunately, there's no date on the Web page so it's not clear whether
> > the "today" being referred to by the Web page is the same as today's
> > "today", but it doesn't matter -- it's still enough to call my reasoning
> > into question.
>
> Mozilla reports it as "Modified: Thursday, Feb 8 2001 00:46:45".
That could just be the last time someone fixed a typo.
E.