Python from Wise Guy's Viewpoint

[Dirk Thierbach]

Re: Python from Wise Guy's Viewpoint

Andreas Rossberg <rossberg@ps.un i-sb.de> wrote:[color=blue]
> Pascal Costanza wrote:[/color]
[color=blue]
> Anyway, you are right of course that any type system will take away some
> expressive power (particularly the power to express bogus programs :-)
> but also some sane ones, which is a debatable trade-off).[/color]

Yep. It turns out that you take away lots of bogus programs, and the
sane programs that are taken away are in most cases at least questionable
(they will be mostly of the sort: There is a type error in some execution
branch, but this branch will never be reached), and can usually be
expressed as equivalent programs that will pass.

"Taking away possible programs" is not the same as "decreasing expressive
power".
[color=blue]
> So there is no inclusion, the "expressiveness " relation is unordered wrt
> static vs dynamic typing.[/color]

That's the important point.

- Dirk

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Dirk Thierbach wrote:[color=blue]
> Andreas Rossberg <rossberg@ps.un i-sb.de> wrote:
>[color=green]
>>Pascal Costanza wrote:[/color]
>
>[color=green]
>>Anyway, you are right of course that any type system will take away some
>>expressive power (particularly the power to express bogus programs :-)
>>but also some sane ones, which is a debatable trade-off).[/color]
>
>
> Yep. It turns out that you take away lots of bogus programs, and the
> sane programs that are taken away are in most cases at least questionable
> (they will be mostly of the sort: There is a type error in some execution
> branch, but this branch will never be reached)[/color]

No. Maybe you believe me when I quote Ralf Hinze, one of the designers
of Haskell:

"However, type systems are always conservative: they must necessarily
reject programs that behave well at run time."

found at

http://web.comlab.ox.ac.uk/oucl/research/areas/ap/ssgp/slides/hinze.pdf

Could you _please_ just accept that statement? That's all I am asking for!


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Joe Marshall]

Re: Static typing

"Marshall Spight" <mspight@dnai.c om> writes:
[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote in message news:bnbds3$uui $1@f1node01.rhr z.uni-bonn.de...[color=green]
>>
>> Expressive power is not Turing equivalence.[/color]
>
> Agreed.
>
> So, does anyone have a formal definition of "expressive power?"
> Metrics? Examples? Theoretical foundations?[/color]

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

It's a start.

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Bourguignon" <spam@thalassa. informatimago.c om> wrote in message news:87k76v9531 .fsf@thalassa.i nformatimago.co m...[color=blue]
>
> The only untyped languages I know are assemblers. (ISTR that even
> intercal can't be labelled "untyped" per se).
>
> Are we speaking about assembler here?[/color]

BCPL!


Marshall

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bn8550$cpm $1@newsreader2. netcologne.de.. .[color=blue]
> Marshall Spight wrote:
>[color=green]
> > "Pascal Costanza" <costanza@web.d e> wrote in message news:bn7a3p$1h6 $1@newsreader2. netcologne.de.. .
> >[color=darkred]
> >>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.[/color]
>
> What can happen in Java is the following:
>
> - You might accidentally use the wrong class in a class cast.
> - For the method you try to call, there happens to be a method with the
> same name and signature in that class.
>
> In this situation, the static type system would be happy, but the code
> is buggy.[/color]

How is this any different a bug than if the programmer types the
wrong name of the method he wants to call? This doesn't demonstrate
anything that I can figure.

Here's a logically identical argument:

In a typed language, a programmer might type "a-b" when he meant
to type "a+b". The type system would be happy, but the code will
be buggy.

Well, yes, that's true.

My claim is: explicit downcasting is a technique, manually specified
by the programmer, that weakens the guarantees the compiler makes
to be exactly as weak as those guarantees made by a dynamically
typed language.

So I can see a valid complaint about the extra typing needed, but
I see no validity to the claim that this makes a statically typed
language any more bug-prone than a dynamically typed language.
Indeed, it gives the statically-typed languages *exactly the same*
degree of bug-proneness as a dynamically typed language for the
scope of a single function call, after which the languages returns
to being strikingly less prone to that specific class of bug. (In fact,
completely immune.)

[color=blue]
> In a decent dynamically typed language, you have proper name space
> management, so that a method cannot ever be defined for a class only by
> accident.[/color]

How can a method be defined "by accident?" I can't figure out what
you're trying to say.


Marshall

[ketil+news@ii.uib.no]

Re: Test cases and static typing

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Dirk Thierbach wrote:[/color]
[color=blue][color=green][color=darkred]
>>> testxyz obj = (concretemethod obj == 42)[/color][/color][/color]
[color=blue][color=green]
>> Does the code compile as long as concretemethod doesn't exist?
>> No. Does your test pass as long as conretemthod doesn't exist? It
>> doesn't, for the same reason.[/color][/color]
[color=blue]
> As long as I am writing only tests, I don't care. When I am in the
> mood of writing tests, I want to write as many tests as possible,
> without having to think about whether my code is acceptable for the
> static type checker or not.[/color]

Uh...the type system will let you *write* what you want, it will just
stop you from *running* those tests. Which are obviously going to
fail anyway. Okay, so perhaps you for some reason needs to write the
tests for nonexistent code, and then run something else that you keep
in the same file. You then need to add

concretemethod = undefined

which just goes to show you how useless static typing is.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Joachim Durchholz" <joachim.durchh olz@web.de> wrote in message news:bn8etq$e8o $1@news.oberber g.net...[color=blue]
>
> A test suite can never catch all permutations of data that may occur (on
> a modern processor, you can't even check the increment-by-one operation
> with that, the universe will end before the CPU has counted even half of
> the full range).[/color]

Just to be pedantic, there are some circumstances where this is
possible. For example, it is quite possible to construct a test suite
that will exhaustively test the boolean "or" operator. There are
exactly four test cases, so that's not too bad.

It's worth mentioning this because it points out what you
have to do for a unit test suite to provide the degree of
coverage that any theorem-proving based system does:
you have to check the entire set of inputs for the function.
Sometimes I run into unit test boosters who feel that
they're provably correct when they have a test case
for every code path. But you'd have every code path
tested with just one test case for the "or" example,
whereas you need fully 4 test cases before you're
provably correct.

Hmmm. Should my test suite for "or" include
passing it strings and ints and checking to be
sure it gives an exception?


Marshall

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bn8nhq$l04 $1@f1node01.rhr z.uni-bonn.de...[color=blue]
>
> In a statically typed language, when I write a test case that calls a
> specific method, I need to write at least one class that implements at
> least that method, otherwise the code won't compile.
>
> In a dynamically typed language I can concentrate on writing the test
> cases first and don't need to write dummy code to make some arbitrary
> static checker happy.[/color]

This is a non-issue. In both cases, you need the implementing code
if you want to be able to run the testcase, and you don't need the
implementing code if you don't.


Marshall

[ketil+news@ii.uib.no]

Re: Python from Wise Guy's Viewpoint

Adrian Hey <ahey@NoSpicedH am.iee.org> writes:
[color=blue]
> Kenny Tilton wrote:[color=green]
>> Ralph Becket wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>> STATICALLY TYPED: the compiler carries out a proof that no value of the
>>> wrong type will ever be passed to a function expecting a different type,
>>> anywhere in the program.[/color][/color][/color]
[color=blue][color=green]
>> Big deal.[/color][/color]
[color=blue]
> Yes it is a very big deal.[/color]

While Mr. Martin probably should get out more, I must admit that I
have a nagging feeling about typing and object orientation. Somebody
else correlated typing with imperativity, and I suspect dynamic typing
is a better match for OO than static typing. But I'm probably making
the common error of comparing with the rather pedestrian type systems
of C++ and Java, perhaps O'Haskell and OCaml have systems that work
better?

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue][color=green]
>>In a decent dynamically typed language, you have proper name space
>>management, so that a method cannot ever be defined for a class only by
>>accident.[/color]
>
>
> How can a method be defined "by accident?" I can't figure out what
> you're trying to say.[/color]

class C {
void m();
}

class D {
void m();
}

....

void doSomething (Object o) {
if (o instanceof C) {
((D)o).m();
}
}

"Oops, by accident method m is also defined in D, although I wanted to
call method m in C."

Doesn't happen in languages with proper name space management. (The
problem is that Java gives you only the illusion of well-behaved
namespaces.)

Pascal

P.S, before anyone repeats the same issue again: Yes, Java has a badly
designed static type system. The example was not a very good one in the
first place. Doesn't matter wrt to my essential message though.

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Pascal Costanza]

Re: Test cases and static typing

ketil+news@ii.u ib.no wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>Dirk Thierbach wrote:[/color]
>
>[color=green][color=darkred]
>>>>testxyz obj = (concretemethod obj == 42)[/color][/color]
>
>[color=green][color=darkred]
>>>Does the code compile as long as concretemethod doesn't exist?
>>>No. Does your test pass as long as conretemthod doesn't exist? It
>>>doesn't, for the same reason.[/color][/color]
>
>[color=green]
>>As long as I am writing only tests, I don't care. When I am in the
>>mood of writing tests, I want to write as many tests as possible,
>>without having to think about whether my code is acceptable for the
>>static type checker or not.[/color]
>
>
> Uh...the type system will let you *write* what you want, it will just
> stop you from *running* those tests. Which are obviously going to
> fail anyway. Okay, so perhaps you for some reason needs to write the
> tests for nonexistent code, and then run something else that you keep
> in the same file.[/color]

+ not "for some reason". Writing tests for nonexistent code is in fact
one of the key ideas of extreme programming.

+ No, I don't want to run code that happens to be in the same file. My
development environment can already do some very useful things with the
test code even if it isn't statically type-checkable yet.


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Mike Silva]

Re: Python from Wise Guy's Viewpoint

"Marshall Spight" <mspight@dnai.c om> wrote in message news:<Olxlb.329 829$mp.272035@r wcrnsc51.ops.as p.att.net>...[color=blue]
> "Scott McIntire" <mcintire_charl estown@comcast. net> wrote in message news:MoEkb.8215 34$YN5.832338@s ccrnsc01...[color=green]
> > It seems to me that the Agency would have fared better if they just used
> > Lisp - which has bignums - and relied more on regression suites and less on
> > the belief that static type checking systems would save the day.[/color]
>
> I find that an odd conclusion. Given that the cost of bugs is so high
> (especially in the cited case) I don't see a good reason for discarding
> *anything* that leads to better correctness. Yes, bignums is a good
> idea: overflow bugs in this day and age are as bad as C-style buffer
> overruns. Why work with a language that allows them when there
> are languages that don't?[/color]

As I understand it, the Operand Error that caused the grief was a
hardware trap in the 68k FPU. Seems that this trap would have been
programmed to do the same thing regardless of the language used.

Also, I wouldn't call this an overflow "bug." The code was written to
assume (based on proofs) that any overflow indicated a hardware
failure, and to take the designed action for hardware failure. It
would have been trivial for the programmers to prevent the overflow or
handle it in another way. Instead, they made a deliberate decision
that the default exception handling was exactly the right response for
overflow on this variable.

Mike

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote in message news:bn8nhq$l04 $1@f1node01.rhr z.uni-bonn.de...
>[color=green]
>>In a statically typed language, when I write a test case that calls a
>>specific method, I need to write at least one class that implements at
>>least that method, otherwise the code won't compile.
>>
>>In a dynamically typed language I can concentrate on writing the test
>>cases first and don't need to write dummy code to make some arbitrary
>>static checker happy.[/color]
>
>
> This is a non-issue. In both cases, you need the implementing code
> if you want to be able to run the testcase, and you don't need the
> implementing code if you don't.[/color]

No, in a dynamically typed language, I don't need the implementation to
be able to run the testcase.

Among other things:

- the test cases can serve as a kind of todo-list. I run the testsuite,
and it gives me an exception. This shows what portion of code I can work
on next.

- when a test case gives me an exception, I can inspect the runtime
environment and analyze how far the test case got, what it already
successfully did, what is missing, and maybe even why it is missing.
With a statically typed language, I wouldn't be able to get that far.

Furthermore, when I am still in the exceptional situation, I can change
variable settings, define a function on the fly, return some value from
a yet undefined method by hand to see if it can make the rest of the
code work, and so on.


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Mike Silva]

Re: Python from Wise Guy's Viewpoint

"Marshall Spight" <mspight@dnai.c om> wrote in message news:<Olxlb.329 829$mp.272035@r wcrnsc51.ops.as p.att.net>...[color=blue]
> "Scott McIntire" <mcintire_charl estown@comcast. net> wrote in message news:MoEkb.8215 34$YN5.832338@s ccrnsc01...[color=green]
> > It seems to me that the Agency would have fared better if they just used
> > Lisp - which has bignums - and relied more on regression suites and less on
> > the belief that static type checking systems would save the day.[/color]
>
> I find that an odd conclusion. Given that the cost of bugs is so high
> (especially in the cited case) I don't see a good reason for discarding
> *anything* that leads to better correctness. Yes, bignums is a good
> idea: overflow bugs in this day and age are as bad as C-style buffer
> overruns. Why work with a language that allows them when there
> are languages that don't?[/color]

As I understand it, the Operand Error that caused the grief was a
hardware trap in the 68k FPU. Seems that this trap would have been
programmed to do the same thing regardless of the language used.

Also, I wouldn't call this an overflow "bug." The code was written to
assume (based on proofs) that any overflow indicated a hardware
failure, and to take the designed action for hardware failure. It
would have been trivial for the programmers to prevent the overflow or
handle it in another way. Instead, they made a deliberate decision
that the default exception handling was exactly the right response for
overflow on this variable.

Mike

(Google is gagging right now, so appologies for any multiple posts)

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnarks$v7k $1@f1node01.rhr z.uni-bonn.de...[color=blue]
>[color=green][color=darkred]
> >>>For one thing, type declarations *cannot* become out-of-date (as
> >>>comments can and often do) because a discrepancy between type
> >>>declaratio n and definition will be immidiately flagged by the compiler.
> >>
> >>They same holds for assertions as soon as they are run by the test suite.[/color]
> >
> > That is not true unless your test suite is bit-wise exhaustive.[/color]
>
> Assertions cannot become out-of-date. If an assertion doesn't hold
> anymore, it will be flagged by the test suite.[/color]

This is only correct if all assertions receive coverage from the
test suite, which requires significant discipline, manual testcase
writing, and recurring manual verification, and even then,
it is only true at runtime. And assertions only verify what
you manually specify.

The benefits of a type system require significantly less manual
work, and find errors at compile time. Also, they verify that
type errors provable do not occur anywhere in the program,
vs. just where you manually specify.


Marshall