Python from Wise Guy's Viewpoint

**Fergus Henderson** · Jul 18 '05, 04:09 AM

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz <joachim.durchh olz@web.de> writes:
[color=blue]
>My 100% subjective private study reveals not a single complaint about
>over-restrictive type systems in comp.lang.funct ional in the last 12 months.[/color]

While I tend to agree that such complaints are rare, such complaints also
tend to be language-specific, and thus get posted to language-specific
forums, e.g. the Haskell mailing list, the Clean mailing list, the OCaml
mailing list, etc., rather than to more general forums like
comp.lang.funct ional.

--
Fergus Henderson <fjh@cs.mu.oz.a u> | "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.

**Matthew Danish** · Jul 18 '05, 04:09 AM

Re: Python from Wise Guy's Viewpoint

On Thu, Oct 23, 2003 at 12:38:50AM +0000, Fergus Henderson wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> writes:[color=green]
> >Marshall Spight wrote:[color=darkred]
> >> But why should more regression testing mean less static type checking?
> >> Both are useful. Both catch bugs. Why ditch one for the other?[/color]
> >
> >...because static type systems work by reducing the expressive power of
> >a language. It can't be any different for a strict static type system.
> >You can't solve the halting problem in a general-purpose language.[/color]
>
> Most modern "statically typed" languages (e.g. Mercury, Glasgow Haskell,
> OCaml, C++, Java, C#, etc.) aren't *strictly* statically typed anyway.
> They generally have some support for *optional* dynamic typing.
>
> This is IMHO a good trade-off. Most of the time, you want static typing;
> it helps in the design process, with documentation, error checking, and
> efficiency. Sometimes you need a bit more flexibility than the
> static type system allows, and then in those few cases, you can make use
> of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
> "System.Obj ect" in C#, etc.). The need to do this is not uncommon
> in languages like C# and Java that don't support parametric polymorphism,
> but pretty rare in languages that do.[/color]

The trouble with these `dynamic' extensions is that they are `dynamic
type systems' from a statically typed viewpoint. A person who uses
truly dynamically typed languages would not consider them to be the
same thing.

In SML, for example, such an extension might be implemented using a sum
type, even using an `exn' type so that it can be extended in separate
places. The moment this system fails (and when a true dynamic system
carries on) is when such a type is redefined. The reason is because the
new type is not considered to be the same as the old type, due to
generativity of type names, and old code requires recompilation.

I'm told Haskell has extensions that will work around even this, but the
last time I tried to play with those, it failed miserably because
Haskell doesn't really support an interactive REPL so there was no way
to test it. (Maybe this was ghc's fault?)

As for Java/C#, downcasting is more of an example of static type systems
getting in the way of OOP rather than of a dynamic type system. (It's
because those languages are the result of an unholy union between the
totally dynamic Smalltalk and the awkwardly static C++).
[color=blue][color=green]
> >I think soft typing is a good compromise, because it is a mere add-on to
> >an otherwise dynamically typed language, and it allows programmers to
> >override the decisions of the static type system when they know better.[/color]
>
> Soft typing systems give you dynamic typing unless you explicitly ask
> for static typing. That is the wrong default, IMHO. It works much
> better to add dynamic typing to a statically typed language than the
> other way around.[/color]

I view static typing as an added analysis stage. In that light, it
makes no sense to `add' dynamic typing to it. Also, I think that static
typing should be part of a more comprehensive static analysis phase
which itself is part of a greater suite of tests.

--
; Matthew Danish <mdanish@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

**Matthias Blume** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> The set of programs that are useful but cannot be checked by a static
> type system is by definition bigger than the set of useful programs
> that can be statically checked.[/color]

By whose definition? What *is* your definition of "useful"? It is
clear to me that static typing improves maintainability , scalability,
and helps with the overall design of software. (At least that's my
personal experience, and as others can attest, I do have reasonably
extensive experience either way.)

A 100,000 line program in an untyped language is useless to me if I am
trying to make modifications -- unless it is written in a highly
stylized way which is extensively documented (and which usually means
that you could have captured this style in static types). So under
this definition of "useful" it may very well be that there are fewer
programs which are useful under dynamic typing than there are under
(modern) static typing.
[color=blue]
> So dynamically typed languages allow
> me to express more useful programs than statically typed languages.[/color]

There are also programs which I cannot express at all in a purely
dynamically typed language. (By "program" I mean not only the executable
code itself but also the things that I know about this code.)
Those are the programs which are protected against certain bad things
from happening without having to do dynamic tests to that effect
themselves. (Some of these "bad things" are, in fact, not dynamically
testable at all.)
[color=blue]
> I don't question that. If this works well for you, keep it up. ;)[/color]

Don't fear. I will.
[color=blue][color=green]
> > (And where are _your_ empirical studies which show that "working around
> > language restrictions increases the potential for bugs"?)[/color]
>
> I don't need a study for that statement because it's a simple
> argument: if the language doesn't allow me to express something in a
> direct way, but requires me to write considerably more code then I
> have considerably more opportunities for making mistakes.[/color]

This assumes that there is a monotone function which maps token count
to error-proneness and that the latter depends on nothing else. This
is a highly dubious assumption. In many cases the few extra tokens
you write are exactly the ones that let the compiler verify that your
thinking process was accurate (to the degree that this fact is
captured by types). If you get them wrong *or* if you got the
original code wrong, then the compiler can tell you. Without the
extra tokens, the compiler is helpless in this regard.

To make a (not so far-fetched, btw :) analogy: Consider logical
statements and formal proofs. Making a logical statement is easy and
can be very short. It is also easy to make mistakes without noticing;
after all saying something that is false while still believing it to
be true is extremely easy. Just by looking at the statement it is
also often hard to tell whether the statement is right. In fact,
computers have a hard time with this task, too. Theorem-proving is
hard.
On the other hand, writing down the statement with a formal proof is
impossible to get wrong without anyone noticing because checking the
proof for validity is trivial compared to coming up with it in the
first place. So even though writing the statement with a proof seems
harder, once you have done it and it passes the proof checker you can
rest assured that you got it right. The longer "program" will have fewer
"bugs" on average.

Matthias

**Andrew Dalke** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Pascal Bourguignon:[color=blue]
> You can implement an eval without arithmetic and you can implement
> theorem prover above it still without arithmetic. You can still do a
> great deal of thinking without any arithmetic...[/color]

But theorem proving and arithmetic are isomorphic. TP-> arithmetic
is obvious. Arithmetic -> TP is through Godel.
[color=blue]
> I think it would have been helped. For example, an architecture like
> the Shuttle's where there are five computer differently programmed
> would have helped, because at least one of the computers would not
> have had the Ariane-4 module.[/color]

Manned space projects get a lot more money for safety checks.
If a few rockets blow up for testing then it's still cheaper than
quintupling the development costs.

Andrew
dalke@dalkescie ntific.com

**Andrew Dalke** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Pascal Costanza:[color=blue]
> The set of programs that are useful but cannot be checked by a static
> type system is by definition bigger than the set of useful programs that
> can be statically checked. So dynamically typed languages allow me to
> express more useful programs than statically typed languages.[/color]

Ummm, both are infinite and both are countably infinite, so those sets
are the same size. You're falling for Hilbert's Paradox.

Also, while I don't know a proof, I'm pretty sure that type inferencing
can do addition (and theorem proving) so is equal in power to
programming.
[color=blue]
> I don't need a study for that statement because it's a simple argument:
> if the language doesn't allow me to express something in a direct way,
> but requires me to write considerably more code then I have considerably
> more opportunities for making mistakes.[/color]

The size comparisons I've seen (like the great programming language
shootout) suggest that Ocaml and Scheme require about the same amount
of code to solve small problems. Yet last I saw, Ocaml is strongly typed
at compile time. How do you assume then that strongly&static ally typed
languages require "considerab le more code"?

Andrew
dalke@dalkescie ntific.com

**Marshall Spight** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bn774d$qj3 $1@newsreader2. netcologne.de.. .[color=blue][color=green]
> >
> > When do programmers know better? An int is an int and a string is a
> > string, and nary the twain shall be treated the same. I would rather
> > ``1 + "bar"'' signal an error at compile time than at run time.[/color]
>
> Such code would easily be caught very soon in your unit tests.[/color]

Provided you think to write such a test, and expend the effort
to do so. Contrast to what happens in a statically typed language,
where this is done for you automatically.

Unit tests are great; I heartily endorse them. But they *cannot*
do everything that static type checking can do. Likewise,
static type checking *cannot* do everything unit testing
can do.

So again I ask, why is it either/or? Why not both? I've had
*great* success building systems with comprehensive unit
test suites in statically typed languages. The unit tests catch
some bugs, and the static type checking catches other bugs.

Marshall

**Lulu of the Lotus-Eaters** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz <joachim.durchh olz@web.de> writes:[color=blue]
>My 100% subjective private study reveals not a single complaint about
>over-restrictive type systems in comp.lang.funct ional in the last 12
>months.[/color]

I also read c.l.functional (albeit only lightly). In the last 12
months, I have encountered dozens of complaints about over-restrictive
type sytems in Haskell, OCaml, SML, etc.

The trick is that these complaints are not phrased in precisely that
way. Rather, someone is trying to do some specific task, and has
difficulty arriving at a usable type needed in the task. Often posters
provide good answers--Durchholz included. But the underlying complaint
-really was- about the restrictiveness of the type system.

That's not even to say that the overall advantages of a strong type
system are not worthwhile--even perhaps better than more dynamic
languages. But it's quite disingenuous to claim that no one ever
complains about it. Obviously, no one who finds a strong static type
system unacceptable is going to be committed to using, e.g.
Haskell--the complaint doesn't take the form of "I'm taking my marbles
and going home".

Yours, Lulu...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

**Dennis Lee Bieber** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Pascal Bourguignon fed this fish to the penguins on Wednesday 22
October 2003 13:44 pm:

[color=blue]
>
> I think it would have been helped. For example, an architecture like
> the Shuttle's where there are five computer differently programmed
> would have helped, because at least one of the computers would not
> have had the Ariane-4 module.
>[/color]

Are you sure? What if all the variants reused code from variants of
the A-4... They could all have had different versions of the same
problem...

Merely comparing the A-4 requirements to the A-5 requirements and then
testing the code associated with different performance limits would
also have found the problem...

There isn't much you can do, as a programmer, if the bean counters up
above decree: Use this module -- unchanged -- since it works on the
previous generation... No, you don't need to test it -- we said it
works...

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

**Donn Cave** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Quoth Lulu of the Lotus-Eaters <mertz@gnosis.c x>:
| Joachim Durchholz <joachim.durchh olz@web.de> writes:
|> My 100% subjective private study reveals not a single complaint about
|> over-restrictive type systems in comp.lang.funct ional in the last 12
|> months.
|
| I also read c.l.functional (albeit only lightly). In the last 12
| months, I have encountered dozens of complaints about over-restrictive
| type sytems in Haskell, OCaml, SML, etc.
|
| The trick is that these complaints are not phrased in precisely that
| way. Rather, someone is trying to do some specific task, and has
| difficulty arriving at a usable type needed in the task. Often posters
| provide good answers--Durchholz included. But the underlying complaint
| -really was- about the restrictiveness of the type system.
|
| That's not even to say that the overall advantages of a strong type
| system are not worthwhile--even perhaps better than more dynamic
| languages. But it's quite disingenuous to claim that no one ever
| complains about it. Obviously, no one who finds a strong static type
| system unacceptable is going to be committed to using, e.g.
| Haskell--the complaint doesn't take the form of "I'm taking my marbles
| and going home".

No one said that strict typing is free, requires no effort or learning
from the programmer. That would be ridiculous - of course a type system
is naturally restrictive, that's its nature. A restrictive system that
imposes a constraint on the programmer, who needs to learn about that
in order to use the language effectively. `Over-restrictive' is
different. If there are questions about static typing, it does not
follow that it's over-restrictive, nor that the questions constitute
a complaint to that effect.

Donn Cave, donn@drizzle.co m

**Marshall Spight** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bn7a3p$1h6 $1@newsreader2. netcologne.de.. .[color=blue]
>
> I wouldn't count the use of java.lang.Objec t as a case of dynamic
> typing. You need to explicitly cast objects of this type to some class
> in order to make useful method calls. You only do this to satisfy the
> static type system. (BTW, this is one of the sources for potential bugs
> that you don't have in a decent dynamically typed language.)[/color]

Huh? The explicit-downcast construct present in Java is the
programmer saying to the compiler: "trust me; you can accept
this type of parameter." In a dynamically-typed language, *every*
call is like this! So if this is a source of errors (which I believe it
is) then dynamically-typed languages have this potential source
of errors with every function call, vs. statically-typed languages
which have them only in those few cases where the programmer
explicitly puts them in.

Marshall

**Matthew Danish** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Here's a link to a relavant system that may be worthwhile to check out:

http://www.simulys.com/guideto.htm

--
; Matthew Danish <mdanish@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

**Pascal Costanza** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote in message news:bn774d$qj3 $1@newsreader2. netcologne.de.. .
>[color=green][color=darkred]
>>>When do programmers know better? An int is an int and a string is a
>>>string, and nary the twain shall be treated the same. I would rather
>>>``1 + "bar"'' signal an error at compile time than at run time.[/color]
>>
>>Such code would easily be caught very soon in your unit tests.[/color]
>
>
> Provided you think to write such a test, and expend the effort
> to do so. Contrast to what happens in a statically typed language,
> where this is done for you automatically.[/color]

There are other things that are done automatically for me in dynamically
typed languages that I care more about than such static checks. I don't
recall ever writing 1 + "bar". (Yes, this is a rhetorical statement. ;)
[color=blue]
> Unit tests are great; I heartily endorse them. But they *cannot*
> do everything that static type checking can do. Likewise,
> static type checking *cannot* do everything unit testing
> can do.[/color]

Right.
[color=blue]
> So again I ask, why is it either/or? Why not both? I've had
> *great* success building systems with comprehensive unit
> test suites in statically typed languages. The unit tests catch
> some bugs, and the static type checking catches other bugs.[/color]

That's great for you, and if it works for you, just keep it up.

But I have given reasons why one would not want to have static type
checking by default. All I am trying to say is that this depends on the
context. Static type systems are definitely not _generally_ better than
dynamic type systems.

Pascal

**Ralph Becket** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> wrote in message news:<bn7a3p$1h 6$1@newsreader2 .netcologne.de> ...[color=blue]
>
> + Design process: There are clear indications that processes like
> extreme programming work better than processes that require some kind of
> specification stage. Dynamic typing works better with XP than static
> typing because with dynamic typing you can write unit tests without
> having the need to immediately write appropriate target code.[/color]

This is utterly bogus. If you write unit tests beforehand, you are
already pre-specifying the interface that the code to be tested will
present.

I fail to see how dynamic typing can confer any kind of advantage here.
[color=blue]
> + Documentation: Comments are usually better for handling documentation.
> ;) If you want your "comments" checked, you can add assertions.[/color]

Are you seriously claiming that concise, *automatically checked*
documentation (which is one function served by explicit type
declarations) is inferior to unchecked, ad hoc commenting?

For one thing, type declarations *cannot* become out-of-date (as
comments can and often do) because a discrepancy between type
declaration and definition will be immidiately flagged by the compiler.
[color=blue]
> + Error checking: I can only guess what you mean by this. If you mean
> something like Java's checked exceptions, there are clear signs that
> this is a very bad feature.[/color]

I think Fergus was referring to static error checking, but (and forgive
me if I'm wrong here) that's a feature you seem to insist has little or
no practical value - indeed, you seem to claim it is even an impediment
to productive programming. I'll leave this point as one of violent
disagreement...
[color=blue]
> + Efficiency: As Paul Graham puts it, efficiency comes from profiling.
> In order to achieve efficiency, you need to identify the bottle-necks of
> your program. No amount of static checks can identify bottle-necks, you
> have to actually run the program to determine them.[/color]

I don't think you understand much about language implementation.
A strong, expressive, static type system provides for optimisations
that cannot be done any other way. These optimizations alone can be
expected to make a program several times faster. For example:
- no run-time type checks need be performed;
- data representation is automatically optimised by the compiler
(e.g. by pointer tagging);
- polymorphic code can be inlined and/or specialised according to each
application;
- if the language does not support dynamic typing then values need not
carry their own type identifiers around with them, thereby saving
space;
- if the language does support explicit dynamic typing, then only
those places using that facility need plumb in the type identifiers
(something done automatically by the compiler.)

On top of all that, you can still run your code through the profiler,
although the need for hand-tuned optimization (and consequent code
obfuscation) may be completely obviated by the speed advantage
conferred by the compiler exploiting a statically checked type system.
[color=blue]
> I wouldn't count the use of java.lang.Objec t as a case of dynamic
> typing. You need to explicitly cast objects of this type to some class
> in order to make useful method calls. You only do this to satisfy the
> static type system. (BTW, this is one of the sources for potential bugs
> that you don't have in a decent dynamically typed language.)[/color]

No! A thousand times, no!

Let me put it like this. Say I have a statically, expressively, strongly
typed language L. And I have another language L' that is identical to
L except it lacks the type system. Now, any program in L that has the
type declarations removed is also a program in L'. The difference is
that a program P rejected by the compiler for L can be converted to a
program P' in L' which *may even appear to run fine for most cases*.
However, and this is the really important point, P' is *still* a
*broken* program. Simply ignoring the type problems does not make
them go away: P' still contains all the bugs that program P did.
[color=blue][color=green]
> > Soft typing systems give you dynamic typing unless you explicitly ask
> > for static typing. That is the wrong default, IMHO. It works much
> > better to add dynamic typing to a statically typed language than the
> > other way around.[/color]
>
> I don't think so.[/color]

Yes, but your arguments are unconvincing. I should point out that
most of the people on comp.lang.funct ional (a) probably used weakly/
dynamically typed languages for many years, and at an expert level,
before discovering statically typed (declarative) programming and
(b) probably still do use such languages on a regular basis.
Expressive, static typing is not a message shouted from ivory towers
by people lacking real-world experience.

Why not make the argument more concrete? Present a problem
specification for an every-day programming task that you think
seriously benefits from dynamic typing. Then we can discuss the
pros and cons of different approaches.

-- Ralph

**Pascal Costanza** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Matthias Blume wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>The set of programs that are useful but cannot be checked by a static
>>type system is by definition bigger than the set of useful programs
>>that can be statically checked.[/color]
>
>
> By whose definition? What *is* your definition of "useful"? It is
> clear to me that static typing improves maintainability , scalability,
> and helps with the overall design of software. (At least that's my
> personal experience, and as others can attest, I do have reasonably
> extensive experience either way.)
>
> A 100,000 line program in an untyped language is useless to me if I am
> trying to make modifications -- unless it is written in a highly
> stylized way which is extensively documented (and which usually means
> that you could have captured this style in static types). So under
> this definition of "useful" it may very well be that there are fewer
> programs which are useful under dynamic typing than there are under
> (modern) static typing.[/color]

A statically typed program is useless if one tries to make modifications
_at runtime_. There are software systems out there that make use of
dynamic modifications, and they have a strong advantage in specific
areas because of this.

If you can come up with a static type system for an unrestricted runtime
metaobject protocol, then I am fine with static typing.
[color=blue][color=green]
>>So dynamically typed languages allow
>>me to express more useful programs than statically typed languages.[/color]
>
>
> There are also programs which I cannot express at all in a purely
> dynamically typed language. (By "program" I mean not only the executable
> code itself but also the things that I know about this code.)
> Those are the programs which are protected against certain bad things
> from happening without having to do dynamic tests to that effect
> themselves.[/color]

This is a circular argument. You are already suggesting the solution in
your problem description.
[color=blue]
> (Some of these "bad things" are, in fact, not dynamically
> testable at all.)[/color]

For example?
[color=blue][color=green]
>>I don't question that. If this works well for you, keep it up. ;)[/color]
>
>
> Don't fear. I will.
>
>[/color]

....and BTW, please let me keep up using dynamically typed languages,
because this works well for me!

(That's the whole of my answer to the original question, why one would
want to give up static typing.)
[color=blue][color=green][color=darkred]
>>>(And where are _your_ empirical studies which show that "working around
>>>language restrictions increases the potential for bugs"?)[/color]
>>
>>I don't need a study for that statement because it's a simple
>>argument: if the language doesn't allow me to express something in a
>>direct way, but requires me to write considerably more code then I
>>have considerably more opportunities for making mistakes.[/color]
>
>
> This assumes that there is a monotone function which maps token count
> to error-proneness and that the latter depends on nothing else. This
> is a highly dubious assumption. In many cases the few extra tokens
> you write are exactly the ones that let the compiler verify that your
> thinking process was accurate (to the degree that this fact is
> captured by types). If you get them wrong *or* if you got the
> original code wrong, then the compiler can tell you. Without the
> extra tokens, the compiler is helpless in this regard.[/color]

See the example of downcasts in Java.
[color=blue]
> To make a (not so far-fetched, btw :) analogy: Consider logical
> statements and formal proofs. Making a logical statement is easy and
> can be very short. It is also easy to make mistakes without noticing;
> after all saying something that is false while still believing it to
> be true is extremely easy. Just by looking at the statement it is
> also often hard to tell whether the statement is right. In fact,
> computers have a hard time with this task, too. Theorem-proving is
> hard.
> On the other hand, writing down the statement with a formal proof is
> impossible to get wrong without anyone noticing because checking the
> proof for validity is trivial compared to coming up with it in the
> first place. So even though writing the statement with a proof seems
> harder, once you have done it and it passes the proof checker you can
> rest assured that you got it right. The longer "program" will have fewer
> "bugs" on average.[/color]

Yes, but then you have a proof that is tailored to the statement you
have made. The claim of people who favor static type systems is that
static type systems are _generally_ helpful.

Pascal

**Pascal Costanza** · Jul 18 '05, 04:10 AM

Re: Python from Wise Guy's Viewpoint

Andrew Dalke wrote:
[color=blue]
> Pascal Costanza:
>[color=green]
>>The set of programs that are useful but cannot be checked by a static
>>type system is by definition bigger than the set of useful programs that
>>can be statically checked. So dynamically typed languages allow me to
>>express more useful programs than statically typed languages.[/color]
>
>
> Ummm, both are infinite and both are countably infinite, so those sets
> are the same size. You're falling for Hilbert's Paradox.
>
> Also, while I don't know a proof, I'm pretty sure that type inferencing
> can do addition (and theorem proving) so is equal in power to
> programming.[/color]

Just give me a static type system CLOS + MOP.
[color=blue][color=green]
>>I don't need a study for that statement because it's a simple argument:
>>if the language doesn't allow me to express something in a direct way,
>>but requires me to write considerably more code then I have considerably
>>more opportunities for making mistakes.[/color]
>
>
> The size comparisons I've seen (like the great programming language
> shootout) suggest that Ocaml and Scheme require about the same amount
> of code to solve small problems. Yet last I saw, Ocaml is strongly typed
> at compile time. How do you assume then that strongly&static ally typed
> languages require "considerab le more code"?[/color]

_small_ problems?

Pascal