What I like about Common Lisp is that it has support for both of them;
both weakish and strongish typing. I also like the fact that it has got
it in the right order; weak first, as default - and strong later, if
you need it.
The other way around seems hopelessly old fashioned, unnecessary and
just plain annoying while coding.
I'm never going back. :)
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
Hmm, don't know what to think about this article.
The author says:
"They artifically limit your expressiveness."
And his justification is an example:
"In Java, for instance, the type system doesn't let you do operator
overloading, multiple inheritance, mix-ins, reference parameters, or
first-class functions. Any time the most natural design involves these
things, you're stuck trying to mutate it into a design that fits Java's
type system."
But what does static typing have to do with Javas non-existing support
for the points he mentioned (operator overloading, mult. inh., etc.)?
The Java designers did intentionally *not* putting them into the
language. From Suns point of view that might be a good thing cause Java
is now pretty much the most popular programming language.
The author got that point plain wrong.
Later he says: "Dynamic languages give you more expressive power and
more design options;" but does not explain this point. It sounds like
an opinion and therefor is not much more worth than the opinion "Static
languages give you more expressive power and more design options;".
And I personally would like to know what a static language or a dynamic
language is. Probably he wanted to say "statically typed language".
Making this kind of mistake tells me that he is probably not an expert
on this issue, and so I should not take his conclusions too serious.
André
--
The reason I found the article interesting was not so much the analysis
of the theoretical pros and cons of static/dynamic typing but the hard
fact that that *in the field* the dynamic typing guys were much more
productive with no observable difference in robustness of the
corresponding solution. I cannot think off hand of other language "case
studies" that spanned multiple years and held the problem domain and
talent pool constant.
Granted we are talking Java here. Perhaps ML or Haskell would have done
better. But then again, they did use Perl instead of Lisp.
-pp
From: Ulrich Hobelmann
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <447mquFqp4tU1@individual.net>
Andr� Thieme wrote:
> But what does static typing have to do with Javas non-existing support
> for the points he mentioned (operator overloading, mult. inh., etc.)?
> The Java designers did intentionally *not* putting them into the
> language. From Suns point of view that might be a good thing cause Java
> is now pretty much the most popular programming language.
> The author got that point plain wrong.
True. ML already existed in 1984, so there's no real excuse for
designing a statically typed language in '90+ without generics. They
simply didn't *want* it. Operator overloading is only syntax, so it's
arguable if it's needed (but with Java's crappy syntax I'd say yes).
The throwing-in-one-bowl of interfaces and inheritance (with classes) is
unfortunate and could have been avoided with OCaml-style "inherit" clauses.
> Later he says: "Dynamic languages give you more expressive power and
> more design options;" but does not explain this point. It sounds like
> an opinion and therefor is not much more worth than the opinion "Static
> languages give you more expressive power and more design options;".
> And I personally would like to know what a static language or a dynamic
> language is. Probably he wanted to say "statically typed language".
> Making this kind of mistake tells me that he is probably not an expert
> on this issue, and so I should not take his conclusions too serious.
Yes, I wouldn't say that Lisp advantage is in having no static typing.
It's in making it convenient to do symbolic programming, which makes
macros easy and possible.
--
Suffering from Gates-induced brain leakage...
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <448mmvFtt21U1@individual.net>
Andr� Thieme wrote:
> Hmm, don't know what to think about this article.
> The author says:
> "They artifically limit your expressiveness."
>
> And his justification is an example:
>
> "In Java, for instance, the type system doesn't let you do operator
> overloading, multiple inheritance, mix-ins, reference parameters, or
> first-class functions. Any time the most natural design involves these
> things, you're stuck trying to mutate it into a design that fits Java's
> type system."
>
> But what does static typing have to do with Javas non-existing support
> for the points he mentioned (operator overloading, mult. inh., etc.)?
> The Java designers did intentionally *not* putting them into the
> language. From Suns point of view that might be a good thing cause Java
> is now pretty much the most popular programming language.
> The author got that point plain wrong.
It's actually true that whenever you try to design new language features
for Java, you always have to match them against Java's type system if
you want a remote chance that it will ever get accepted. And this can
lead to horrible situations. Consider the interactions between AspectJ 5
and generic types in JDK 5.
In Common Lisp, for example, it is actually relatively straightforward
to create an incompatible new "world" in which your type system behaves
very differently from the CL's original type system. Consider ACL2 and
Qi as examples. Something like that wouldn't be acceptable in Java.
(That's a social restriction, not a strict technical one.)
The relationship to expressivity is unclear here, but it is actually an
acknowledged fact that static type systems have to limit the
expressivity of the base language in the sense that they have to reject
programs that wouldn't produce type errors at runtime. This is because
there is always a grey area for which a static type checker cannot
decide whether a program will produce a type error or not, and a static
type system is only accepted (again socially by the people who are into
static type systems) when such programs are effectively rejected.
As a comparison, CMUCL's and SBCL's compiler use a type inferencing,
which means that they effectively have a static type system. But instead
of rejecting programs for which they cannot prove type safety, they will
just issue warnings. This is typically not considered "strong" enough.
> Later he says: "Dynamic languages give you more expressive power and
> more design options;" but does not explain this point. It sounds like
> an opinion and therefor is not much more worth than the opinion "Static
> languages give you more expressive power and more design options;".
> And I personally would like to know what a static language or a dynamic
> language is. Probably he wanted to say "statically typed language".
> Making this kind of mistake tells me that he is probably not an expert
> on this issue, and so I should not take his conclusions too serious.
It's relatively straightforward to produce example that show how a
dynamically typed language can be more expressive than a statically
typed one. For example, in Common Lisp you can change class definitions
at runtime. Especially when you remove slots from a class, this results
in a program that a static type checker wouldn't have accepted in the
general case. Yet, Common Lisp provides enough rope to ensure that such
a program still works (ultimately by error handlers that can take
advantage of useful restarts).
There are also cases where static type systems are more expressive than
dynamically typed languages, but in that case the gained expressivity is
not at the base language level, but rather at the type system level. I
have only seen one example so far, though, in which code can be
dispatched on the type of the expected return value - which is
interesting because the dispatch can depend on some future event,
something that is, as far as I can tell, impossible to do in a
dynamically typed language.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal, you mentioned that you have only seen one example so far, where
static typing provides something that looks impossible to do in a
dynamically typed language.
Could you elaborate on that since I didn't get the point in your brief
description.
Thanks a lot,
Dominikus
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <44d1mdF1ju2vU1@individual.net>
dominikus wrote:
> Pascal, you mentioned that you have only seen one example so far, where
> static typing provides something that looks impossible to do in a
> dynamically typed language.
>
> Could you elaborate on that since I didn't get the point in your brief
> description.
The example I was referring to was posted to the ll-discuss mailing list
a while ago. See
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04650.html
To quote from that posting:
"Static typing can make programs more concise: I can write
getLine >>= print . (/2) . read
or
getLine >>= print . not . read
rather than
getLine >>= print . (/2) . readDouble
or
getLine >>= print . not . readBool
What happens here is that the correct read function is selected by the
static type system based on the return value of the expression that is
executed beforehand. In a statically typed language, the return type can
be guaranteed to be of a single deterministic type. In a dynamically
typed language, you can never know what the return value of a function
will be (unless you use a type inferencer for optizimation purposes, but
that _is_ static typing).
It's interesting to read the discussion that follows the posting above.
This was the first time I have seen a real example of increased
expressive power of static type systems, which is far more interesting
than the usual hogwash about early detection of so-called "errors",
better documentation and better efficiency.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Thank you very much for your explanations and the very interesting
pointer to the ll-mailing list. The example given is really cool and
makes a point I wasn't aware of before.
Thanks again,
Dominikus
On Thu, 02 Feb 2006 01:22:36 +0100, Pascal Costanza <··@p-cos.net> wrote:
>
> The example I was referring to was posted to the ll-discuss mailing list
> a while ago. See
> http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04650.html
Sorry to interject, but I've been wondering whether this mailing list
reformed somewhere else, perhaps with a different name? The archives show
the list getting swamped with spam in early 2004.
--
Jack Unrue
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <44go3tF22kr2U2@individual.net>
Jack Unrue wrote:
> On Thu, 02 Feb 2006 01:22:36 +0100, Pascal Costanza <··@p-cos.net> wrote:
>
>>The example I was referring to was posted to the ll-discuss mailing list
>>a while ago. See
>>http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04650.html
>
> Sorry to interject, but I've been wondering whether this mailing list
> reformed somewhere else, perhaps with a different name? The archives show
> the list getting swamped with spam in early 2004.
See https://lists.csail.mit.edu/mailman/listinfo/ll-discuss
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On 30 Jan 2006 14:44:30 -0800, <······························@justmail.de> wrote:
> Making this kind of mistake tells me that he is probably not an expert
> on this issue, and so I should not take his conclusions too serious.
Anyone can write a blog and then anonymously pimp it in c.l.l.
Sometimes they skip the blog step....
--
Fairy tales do not tell children the dragons exist.
Children already know that dragons exist.
Fairy tales tell children the dragons can be killed. -- G.K.Chesterton
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <87u0bkoqzz.fsf@qrnik.zagroda>
"pp" <·············@gmail.com> writes:
> http://opal.cabochon.com/~stevey/blog-rants/strong-weak-typing.html
This article is being discussed at
http://lambda-the-ultimate.org/node/1268
and the general conclusion is that it's clueless.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "pp" <·············@gmail.com> writes:
>
> > http://opal.cabochon.com/~stevey/blog-rants/strong-weak-typing.html
>
> This article is being discussed at
> http://lambda-the-ultimate.org/node/1268
> and the general conclusion is that it's clueless.
My general conclusion is that the article is clueless, and most of that
discussion also.
When we eliminate obvious obsolescence like C++ and Java with type
declarations everywhere, what is left is that the difference between
static and dynamic typing is one between what sets of programs are
accepted.
Firstly, ignoring for a second the idea that catching type exceptions
can be incorporated into the logic of a software system, type checking
is not strictly required. A program that is free of type mismatch
errors will run properly whether or not type checking is performed. It
chugs along and always correct operations to correctly typed data.
Type checking, whether static or dynamic, is a safety net that we apply
because we don't trust programs to be free of type errors.
Static type checking means that there is a safety net consisting of a
function that analyzes the program without actually running it. That
function can either conclude that the program A) has a type mismatch
error, B) that it certainly has no type mismatch error, or C) that
although no error was found, no conclusion can be drawn that there
isn't an error.
A statically typed language applies the type checking function, and
then rejects programs that land into case A, but also ones that fall
into case C.
Under a dynamic language, type checking means that the program for
which C was reported can be run anyway, and the type checking safety
next extends into the run time.
Therefore, static languages are quite simply crippleware: they duck out
of case C) whereas dynamic languages keep going. They don't have the
run-time support to deal with case C.
The static diagnostics themselves are valuable, of course; it's the
rejection of some perfectly good programs that is the problem. At the
very least, there should be a switch. The developer should decide
whether the program is to be run anyway, an the run-time support should
rise to the occasion. In category C) are all kinds of useful programs
which make our programming lives easier and more productive. Then you
can decide which paradigm is appropriate for any given problem without
switching languages.
One posting in the above blog, compares dynamic typing to manual memory
management in a completely clueless way.
If we compare type systems to memory management, then static type
checking is analogous to statically computing object lifetimes and
inserting the object liberation calls into the compiled code, so that
dynamic garbage collection is unnecessary.
The static object lifetime computation can either conclude that the
lifetimes of all objects can be determined, or that the lifetimes of
some objects could not be determined.
In the latter case, if the program is to be run anyway, then dynamic
object lifetime computation, i.e. garbage collection, is necessary.
If garbage collection is not implemented and such programs are
rejected, it means that all kinds of useful software cannot be written.
So, because garbage collection is dynamic, it is not commensurable with
static type checking. Garbage collection does not reject programs, it
cleans up after them.
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <448lk6Fhrk1U1@individual.net>
Kaz Kylheku wrote:
> Firstly, ignoring for a second the idea that catching type exceptions
> can be incorporated into the logic of a software system, type checking
> is not strictly required. A program that is free of type mismatch
> errors will run properly whether or not type checking is performed. It
> chugs along and always correct operations to correctly typed data.
That's not quite correct. When you have an object system in which
messages are dispatched dynamically, you are effectively relying on type
checks to determine the meaning of your program.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Marcin 'Qrczak' Kowalczyk wrote:
> "pp" <·············@gmail.com> writes:
>> http://opal.cabochon.com/~stevey/blog-rants/strong-weak-typing.html
>
> This article is being discussed at
> http://lambda-the-ultimate.org/node/1268 and the general conclusion is
> that it's clueless.
That sounds about right. Many of the conclusions seem illogical to me, as
other people have pointed out.
However, one interesting point is the question of how long it takes to learn
a language. I certainly agree that you need to know something about the
static type systems and checkers of more advanced languages in order to
make good use of the language. That's extra learning but is it offset by
not having to do so much unit testing and not having to be so adept with a
run-time debugger?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop wrote:
> That's extra learning but is it offset by
> not having to do so much unit testing and not having to be so adept with a
> run-time debugger?
Yes it is but the folks in c.l.l are clearly not deserving of such a
boon.
ML and OCaml are far too good for us.
Perhaps some worthies can be found elsewhere. I hear c.l.c has some
virgins.
-andy
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <4497kcF10hi3U1@individual.net>
Jon Harrop wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
>>"pp" <·············@gmail.com> writes:
>>
>>>http://opal.cabochon.com/~stevey/blog-rants/strong-weak-typing.html
>>
>>This article is being discussed at
>>http://lambda-the-ultimate.org/node/1268 and the general conclusion is
>>that it's clueless.
>
> That sounds about right. Many of the conclusions seem illogical to me, as
> other people have pointed out.
>
> However, one interesting point is the question of how long it takes to learn
> a language. I certainly agree that you need to know something about the
> static type systems and checkers of more advanced languages in order to
> make good use of the language. That's extra learning but is it offset by
> not having to do so much unit testing and not having to be so adept with a
> run-time debugger?
You have to write tests and debug your programs anyway, no matter
whether you use a statically typed language or not.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> You have to write tests and debug your programs anyway, no matter
> whether you use a statically typed language or not.
Would you not say that programs written in dynamically typed languages
require more run-time debugging and testing?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
> Would you not say that programs written in dynamically typed languages
> require more run-time debugging and testing?
We'd say pretty much anything to get you to peddle that stuff somewhere
else. If we were interested in ML, we know where to find it. We're
not,
and nothing you write is going to change that.
Surely folks who have some affection for static typing would be a
better
audience.
Why do you persist in writing about it here?
Jon Harrop wrote:
> Pascal Costanza wrote:
>
>>You have to write tests and debug your programs anyway, no matter
>>whether you use a statically typed language or not.
>
>
> Would you not say that programs written in dynamically typed languages
> require more run-time debugging and testing?
This is a moot question, since the object isn't to minimize
debugging+testing, but to minimize development+debugging+testing. The
OP's referenced rant claims that dynamic typing seems to do that, and
also claims that he was initially biased in favour of static typing.
Thinking back to my salad days programming in statically typed languages
like BASIC and FORTRAN, I remember that many variables were such things
as "the number of records, or -1 if inapplicable." Then on to C, and "a
pointer to the record, or NULL." Knowing what I now know, I suppose that
should have been two variables: The count, and a count-is-valid flag.
Then instead of IF COUNT<>-1 THEN stuff, I should've written IF
COUNTVALID THEN stuff, but who the heck does that? Do state of the art
static typecheckers allow users to express that x is only valid if y is
1, and then compute that the storage locations can overlap, and then
merge them, or do coders use the same old efficiency hacks, essentially
rolling their own dynamic typing?
Cameron MacKinnon wrote:
> Thinking back to my salad days programming in statically typed languages
> like BASIC and FORTRAN, I remember that many variables were such things
> as "the number of records, or -1 if inapplicable." Then on to C, and "a
> pointer to the record, or NULL." Knowing what I now know, I suppose that
> should have been two variables: The count, and a count-is-valid flag.
> Then instead of IF COUNT<>-1 THEN stuff, I should've written IF
> COUNTVALID THEN stuff, but who the heck does that? Do state of the art
> static typecheckers allow users to express that x is only valid if y is
> 1, and then compute that the storage locations can overlap, and then
> merge them, or do coders use the same old efficiency hacks, essentially
> rolling their own dynamic typing?
In ML you'd write "None" or "Some x" and the compiler would most likely
store either a NULL pointer or a pointer to "x".
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
From: Pascal Costanza
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <44adafF17gosU1@individual.net>
Jon Harrop wrote:
> Pascal Costanza wrote:
>
>>You have to write tests and debug your programs anyway, no matter
>>whether you use a statically typed language or not.
>
> Would you not say that programs written in dynamically typed languages
> require more run-time debugging and testing?
Not in my experience. It seems that in most languages, you need
considerably large test suites anyway, and when test coverage is good,
it also seems that due to the fact that good test suites test
independent / orthogonal features, they will reveal all the type errors
anyway that a static type system would have revealed. Taking into
account that static type system typically seem to slow down development
in favor of checks that are ultimately redundant, there doesn't seem to
be any benefit at all.
Note that these are conjectures based on anecdotes at best. However, my
impression is that many users of dynamically typed languages share this
experience. This is no better and no worse than the claims made by fans
of static type systems which are also based purely on anecdotes.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Jon Harrop wrote:
>> Pascal Costanza wrote:
>>
>>>You have to write tests and debug your programs anyway, no matter
>>>whether you use a statically typed language or not.
>> Would you not say that programs written in dynamically typed
>> languages
>> require more run-time debugging and testing?
>
> Not in my experience. It seems that in most languages, you need
> considerably large test suites anyway, and when test coverage is good,
> it also seems that due to the fact that good test suites test
> independent / orthogonal features, they will reveal all the type
> errors anyway that a static type system would have revealed. Taking
> into account that static type system typically seem to slow down
> development in favor of checks that are ultimately redundant, there
> doesn't seem to be any benefit at all.
>
> Note that these are conjectures based on anecdotes at best. However,
> my impression is that many users of dynamically typed languages share
> this experience. This is no better and no worse than the claims made
> by fans of static type systems which are also based purely on
> anecdotes.
True, but with the bemol that dynamic typing ==> easier to develop
bottom-up ==> easier to test smaller units ==> more tests are done
while writing the program ==> less bugs to debug at "run-time".
Just remember to activate the dribble while you write your program, or
to keep in a file all these tests... ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
WARNING: This product attracts every other piece of matter in the
universe, including the products of other manufacturers, with a
force proportional to the product of the masses and inversely
proportional to the distance between them.
On Wed, 01 Feb 2006 01:32:50 +0100, Pascal Bourguignon
<······@informatimago.com> wrote:
>True, but with the bemol that dynamic typing ==> easier to develop
Is "bemol" a metaphor?
····@unreal.uncom writes:
> On Wed, 01 Feb 2006 01:32:50 +0100, Pascal Bourguignon
> <······@informatimago.com> wrote:
>
>>True, but with the bemol that dynamic typing ==> easier to develop
>
> Is "bemol" a metaphor?
Sorry. It's "flat" in English.
Like with notes: you've got plain G (Sol) and G flat (Sol b�mol).
It's a "reducing modifier" :-) The expression is usual in French.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
Pascal Bourguignon wrote:
> ····@unreal.uncom writes:
>
>>>True, but with the bemol that dynamic typing ==> easier to develop
>>
>>Is "bemol" a metaphor?
> Like with notes: you've got plain G (Sol) and G flat (Sol b�mol).
> It's a "reducing modifier" :-) The expression is usual in French.
Ah! In english, 'caveat' could be used.
Cameron MacKinnon <··········@clearspot.net> writes:
> Pascal Bourguignon wrote:
>> ····@unreal.uncom writes:
>>
>>>>True, but with the bemol that dynamic typing ==> easier to develop
>>>
>>>Is "bemol" a metaphor?
>
>> Like with notes: you've got plain G (Sol) and G flat (Sol b�mol).
>> It's a "reducing modifier" :-) The expression is usual in French.
>
> Ah! In english, 'caveat' could be used.
Good suggestion. I take note. Thank you.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Indentation! -- I will show you how to indent when I indent your skull!"
On Wed, 01 Feb 2006 12:26:57 -0500, Cameron MacKinnon
<··········@clearspot.net> wrote:
>Ah! In english, 'caveat' could be used.
A caveat is a warning. A flat note doesn't seem to connote a warning.
Maybe more of a semi-incidental thing, as if you put the phrase in
parentheses? (That could make it lispier.)
····@unreal.uncom wrote:
> On Wed, 01 Feb 2006 12:26:57 -0500, Cameron MacKinnon
> <··········@clearspot.net> wrote:
>
> >Ah! In english, 'caveat' could be used.
>
> A caveat is a warning. A flat note doesn't seem to connote a warning.
But the symbol which introduces that B flat is a kind of warning. From
that point on (key signature), or in that measure (incidental), you
have to remember to jam with a flattened B. Or else you clash with the
music. It's like missing an important traffic sign. The accompaniment
is playing a dominant harmony rooted at C that will be resolving to the
F, and there you are off in space somewhere, farting around with a
leading tone into C.
Jon Harrop wrote:
> Pascal Costanza wrote:
> > You have to write tests and debug your programs anyway, no matter
> > whether you use a statically typed language or not.
>
> Would you not say that programs written in dynamically typed languages
> require more run-time debugging and testing?
I would say this:
In an environment where type errors are undetected at run time, or
are hard to
pinpoint where they are detected, those programs which /can/ be
statically checked
will certainly take less time to debug if static checking is
available.
But the dynamic languages that we use, like Common Lisp, have very good
debugging support. Type mismatch errors are detected and turned into a
proper condition. As such, these errors get trivially flushed out in
the course of normal testing.
You don't write unit tests just to flush out type mismatches. You test
in the ordinary way, trying combinations of correct inputs, trying to
hit as many corner cases as possible. If a dynamically typed module
handles all correct inputs and produces correct outputs for them, then,
by the way, you also know that its use of types is sane. None of the
lower-level operators and functions that it relies on are complaining
about any bad type or value. The only source of a type mismatch could
be a bad input. That's a bug in a different module.
Internally to a program, you don't have to worry as much about bad
inputs between modules. Of course, software has to be robust against
all combinations of external inputs.
Even so, if in a production run, a user stumbles across some bad input
that triggers a type mismatch or whatever, it isn't necessarily
catastrophic.
Those static languages that are actually robust against this kind of
thing also do have to have run-time checks too. Those checks don't have
to be for type, but there are plenty of other things to check for. If
null object references are allowed, those have to be checked. Array
overruns, ditto.
By the way, is a null reference exception a dynamic type error or a
value error?
In Lisp, I'd represent a null reference using NIL, and so the use of a
null reference would manifest itself as a dynamic type mismatch. That
is not any worse, nor any harder to debug for, just a different
perspective. It's the same bug, caught in the same point in the logic.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <87y80uvk1s.fsf@qrnik.zagroda>
"Kaz Kylheku" <········@gmail.com> writes:
>> Would you not say that programs written in dynamically typed languages
>> require more run-time debugging and testing?
>
> I would say this:
>
> In an environment where type errors are undetected at run time, or
> are hard to pinpoint where they are detected, those programs which
> /can/ be statically checked will certainly take less time to debug
> if static checking is available.
In most statically typed environments they are either detected
(Java, C#) or the type system doesn't include features which might
result in type errors at runtime (ML, Haskell).
You are right about C++.
Static typing is most useful for evolving code with changing data
representation, because it makes easier to ensure that all places
operating on a certain kind of data are synchronized when the data
model changes. Not only many errors are detected earlier, but it's
easier to locate the place which must be fixed; with dynamic typing
it's often not obvious how did a wrongly typed value got into the
given place, if it's not a function parameter but a deep part of the
result of an earlier computation, which has since long time finished
and the trace is no longer on the stack.
Dynamic typing has other merits: it makes easier to express generic
libraries where types used depend on the concrete client (e.g. an
interface to a database, a parser generator, transmitting objects
over a network), it leads to simpler language rules, it makes easier
to define the semantics of changing or loading code at runtime.
But it's silly to negate any benefit of static typing, as if Lisp was
in all respects better than anything else. There are three major
advantages of static typing:
- more errors are detected early, and they are easier to fix;
- a part of the documentation is specified formally and checked
by the compiler that it agrees with the code;
- it's easier for the compiler to generate efficient code, and thus
easier for a human to write source code from which efficient
compiled code will be generated.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Static/Dynamic typing, lessons from the field
Date:
Message-ID: <87y80w78sy.fsf@qrnik.zagroda>
Jon Harrop <······@jdh30.plus.com> writes:
> I certainly agree that you need to know something about the static
> type systems and checkers of more advanced languages in order to
> make good use of the language. That's extra learning but is it
> offset by not having to do so much unit testing and not having to be
> so adept with a run-time debugger?
You learn it once, and make use of it every time, so considering these
aspects alone it's definitely worth the effort in the long run.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/