 More on static vs. dynamic typing
started 2/10/2003; 10:54:41 AM - last post 2/12/2003; 4:13:06 AM
|
|
Michael Vanier - More on static vs. dynamic typing 
2/10/2003; 10:54:41 AM (reads: 1394, responses: 7)
|
|
|
Here's a link to an ongoing thread on the python newsgroup discussing static vs. dynamic typing. They take an interesting tack, which is "what kinds of programs would be significantly harder to write in statically-typed languages as compared to dynamically-typed languages?" This avoids much of the meaningless discussion that was found on the comp.lang.scheme thread posted here a while ago. The link is:
http://groups.google.com/groups?selm=623cd325.0302060257.1542e098@posting.google.com
|
|
Ehud Lamm - Re: More on static vs. dynamic typing
2/10/2003; 12:03:54 PM (reads: 1412, responses: 0)
|
|
|
This indeed the right way to approach this question. But tomake it meaningful you must specify the type system you are thinking about, since not all static type systems are created equal.
|
|
Dan Shappir - Re: More on static vs. dynamic typing
2/10/2003; 2:31:39 PM (reads: 1415, responses: 0)
|
|
|
I think some major points are missed in this discussion (both on in that thread and the various threads at this site). First, I don't see this as an either/or choice. That is, I believe a good solution is one that combines both statically typed languages and dynamically typed ones. Indeed, it is quit common these days for applications developed using a statically typed language to support scripting, which is generally done using a dynamically typed language.
I've been involved in several projects where the underpinning were developed in C++, and the presentation or customization layer was developed using JavaScript, XSL and DHTML. While the motivation for the design was that people with Web skills could customize the applications, I found it a powerful combination for myself as well.
Another point is one I've made before in a reply to Ehud about dynamic types. In some cases "type information" for objects may only be available at runtime. For example, a DB recordSet (rowSet or whatever) object. In this case statically typed languages provide accessor functions that return some variant type given the field name as a string. Dynamically typed languages make it much more natural to manipulate such data as objects.
OTOH if you do know the recordSet structure at compile time, and your development tool can generate an class definition from it, then a statically typed language becomes the better choice.
This brings to mind the WSDL debate ...
|
|
Dominic Fox - Re: More on static vs. dynamic typing
2/11/2003; 4:02:37 AM (reads: 1824, responses: 1)
|
|
|
I've not noticed anybody mention Zope Interfaces so far in the context of the Python / ST/DT discussions. They provide a way to do interface checking on objects at runtime, which means that you can enforce (again, at runtime) what is sometimes called "Duck Typing":
If it looks like a duck, waddles like a duck, and quacks like a duck, then it's probably a duck.
They don't by any means solve the problems that ST advocates see with Python-style DT, but they may increase the level of comfort of Python programmers who would nevertheless like to build a type system as a way of being explicit about contracts.
|
|
Ehud Lamm - Re: More on static vs. dynamic typing
2/11/2003; 7:31:32 AM (reads: 1854, responses: 0)
|
|
|
More on static vs. dynamic typing from GvR.
|
|
Isaac Gouy - Re: More on static vs. dynamic typing
2/11/2003; 1:53:23 PM (reads: 1234, responses: 0)
|
|
More on static vs. dynamic typing from GvR
Déjà vu all-over-again!
That seems like a 10 year-old article- just replace Java with C++, and Python with Smalltalk.
Postings in this thread point the way to a more nuanced discussion.
to make it meaningful you must specify
what are the criteria for comparing st and dt?
which kinds of typing are being discussed?
(All that Java typing and there are still null pointer exceptions - well that's not Nice!)
when a good solution uses a combination of st and dt, what criteria are being used to say dt is good for this but st isn't?
|
|
Dominic Fox - Re: More on static vs. dynamic typing
2/12/2003; 1:52:47 AM (reads: 1179, responses: 1)
|
|
|
It strikes me the GvR's concern that automated (compile-time) type-checking might make programmers complacent about the correctness of their code has to do with some more general misgivings about the value of automation. (I think it's a little odd for a designer of computer programming languages to have these sorts of misgivings, but never mind).
If you automate a task, you may be seen as removing the need for human attention to be paid to that task; and because human attention is more soft-focus than machine attention, you miss some of the incidental benefits of having one or more pairs of human eyes scanning the code.
The anxiety I think some people have here is that the compiler will not simply be seen as an (unusually focussed) extra pair of eyes, but as an infallible once-and-for-all guarantee of correctness. Within its own sharp focus of attention, the compiler is (or ought to be) infallible; but: there is no substitute, as everybody rushes to declare, for disciplined care and thoughtfulness on the part of a real programmer.
I don't feel that anxiety (call it substitution anxiety) nearly so much as I feel the anxiety that I think disciplined, careful and thoughtful real programmers ought to have (and have therefore adopted in the hope that it will help turn me into one), namely that they can never be disciplined, careful or thoughtful enough. That's why programmers try to adhere to coding conventions, ranging from indentation and variable naming styles to more elaborate strictures which shade into the domain of "best practice".
Keeping within the artifical constraints of a type system has a nuts-and-bolts-level practical value for the same reason: it's a way of defining and documenting a kind of correctness, and ensuring that you notice when you fail to achieve it. That's why some Python programmers have decided that they need some sort of type checking after all, and have implemented a suitably Pythonic way of doing it (see post above re Zope interfaces). The mathematically provable virtues of strong typing are undoubtedly the underlying reason why it has the practical value it has; but you can, as I do, appreciate its practical value without knowing about, or understanding, its theoretical basis.
|
|
Alex Sauer-Budge - Re: More on static vs. dynamic typing
2/12/2003; 4:13:06 AM (reads: 1220, responses: 0)
|
|
|
Dominic wrote that GvR's concern about type checking might have "to do with some more general misgivings about the value of automation," a paradox which I wonder might be more prevalent in computer programming than one (that is, I) would imagine. I know people who insist on doing everything in C and not using standard libraries-- doing everything "by hand" --out of similar fears leveraging othr people's work and automation would be giving oneself over to the dark side.
Dominic also wrote that "keeping within the artifical constraints of a type system has a nuts-and-bolts-level practical value...", to which, being of the typed personality, I would reply with why are type constraints artifcial? Are they not necessary conditions for a (particular) correct program, whether compiler enforced, runtime, or programmer enforced? Nevertheless, (current?) type systems don't seem to be always rich enough to capture all possible, the easiest most direct, or even somtimes good solutions, as Simon Peyton Jones admits to some degree in Wearing the hair shirt
Open problem: the IO monad has become Haskell's sin-bin. (When we don't understand something, we toss it in the IO monad.)
Festering sore: unsafePerformIO :: IO a -> a
Dangerous, indeed type-unsafe, but occasionally indispensable,
|
|
|
|