Python from Wise Guy's Viewpoint

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnbafk$uu6 $1@f1node01.rhr z.uni-bonn.de...[color=blue]
> ... there exist programs that work but
> that cannot be statically typechecked. These programs objectively exist.
> By definition, I cannot express them in a statically typed language.[/color]

I agree these programs exist.

It would be really interesting to see a small but useful example
of a program that will not pass a statically typed language.
It seems to me that how easy it is to generate such programs
will be an interesting metric.

Anyone? (Sorry, I'm a static typing guy, so my brain is
warped away from such programs. :-)


Marshall

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote in message news:bnbafk$uu6 $1@f1node01.rhr z.uni-bonn.de...
>[color=green]
>>... there exist programs that work but
>>that cannot be statically typechecked. These programs objectively exist.
>>By definition, I cannot express them in a statically typed language.[/color]
>
>
> I agree these programs exist.
>
> It would be really interesting to see a small but useful example
> of a program that will not pass a statically typed language.
> It seems to me that how easy it is to generate such programs
> will be an interesting metric.
>
> Anyone? (Sorry, I'm a static typing guy, so my brain is
> warped away from such programs. :-)[/color]

Have you ever used a program that has required you to enter a number?

The check whether you have really typed a number is a dynamic check, right?


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)

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Kenny Tilton" <ktilton@nyc.rr .com> wrote in message news:Zn7mb.3548 3$pT1.33385@twi ster.nyc.rr.com ...[color=blue]
>
> Lights out for static typing.[/color]

That kind of statement reminds me a lot of the people
who were saying in 1985 that CISC computing was
dead.

Anyway, I've argued elsewhere with Uncle Bob about
the issues raised in the quoted blog, and one thing
that came out of those arguments was that much of
what he was talking about was true for C++ vs.
Python, but not true for C++ vs. Java. In particular,
it's not clear to me that what he's referring to is
anything besides just rapid turnaround in getting
from a file edit to a running program. Java and
Python are both good about that, with Python
probably having the edge, but C++ can take a
*long* time to compile.

I'll probably get flamed for that statement, eh?


Marshall

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Paul F. Dietz" <dietz@dls.ne t> wrote in message news:KrKdnVmOxJ rQfgWiRVn-vg@dls.net...[color=blue]
>
> (7) Developing reliable software also requires extensive testing to
> detect bugs other than type errors, and
> (8) These tests will usually detect most of the bugs that static
> type checking would have detected.[/color]

Whether and to what degree (8) is true is the big open
question in this debate. Does anyone have any objective
metrics? Anyone know how to get them?

This strikes me as a very hard thing to quantify.


Marshall

[Brian McNamara!]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> once said:[color=blue]
>Marshall Spight wrote:[color=green]
>> I agree these programs exist.
>>
>> It would be really interesting to see a small but useful example
>> of a program that will not pass a statically typed language.
>> It seems to me that how easy it is to generate such programs
>> will be an interesting metric.
>>
>> Anyone? (Sorry, I'm a static typing guy, so my brain is
>> warped away from such programs. :-)[/color]
>
>Have you ever used a program that has required you to enter a number?
>
>The check whether you have really typed a number is a dynamic check, right?[/color]

Yes, but this doesn't imply we can't write a statically-typed program to
handle the situation...

I can imagine Haskell code like

y = do x <- myread "34"
return x * 2
z = do x <- myread "foo"
return x * 2

where

myread :: String -> Maybe a
y, z :: Maybe Int

and "y" ends up with the value "Just 68" whereas "z" is "Nothing".

--
Brian M. McNamara lorgon@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Brian McNamara! wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> once said:
>[color=green]
>>Marshall Spight wrote:
>>[color=darkred]
>>>I agree these programs exist.
>>>
>>>It would be really interesting to see a small but useful example
>>>of a program that will not pass a statically typed language.
>>>It seems to me that how easy it is to generate such programs
>>>will be an interesting metric.
>>>
>>>Anyone? (Sorry, I'm a static typing guy, so my brain is
>>>warped away from such programs. :-)[/color]
>>
>>Have you ever used a program that has required you to enter a number?
>>
>>The check whether you have really typed a number is a dynamic check, right?[/color]
>
>
> Yes, but this doesn't imply we can't write a statically-typed program to
> handle the situation...
>
> I can imagine Haskell code like
>
> y = do x <- myread "34"
> return x * 2
> z = do x <- myread "foo"
> return x * 2
>
> where
>
> myread :: String -> Maybe a
> y, z :: Maybe Int
>
> and "y" ends up with the value "Just 68" whereas "z" is "Nothing".[/color]

The code you have given above doesn't give the user any feedback, right?
Do you really think that this is useful?


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)

[Dirk Thierbach]

Re: Test cases and static typing

Pascal Costanza <costanza@web.d e> wrote:
[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]

Then just do it. Write as many tests as you care; when you're ready,
compile them and run the type checker.

Where's the problem? One thing that is certainly missing for Haskell or
OCaml is a good IDE that supports as many styles of programming
as possible, but even with the primitive command line versions at the
moment you can do what you want in this case.

And anyway, this would be a question of the IDE, not of static typing.
[color=blue][color=green][color=darkred]
>>>The type system might test too many cases.[/color][/color][/color]
[color=blue][color=green]
>> I have never experienced that, because every expression that is valid
>> code will have a proper type.[/color][/color]
[color=blue][color=green]
>> Can you think of an example (not in C++ or Java etc.) where the type
>> system may check too many cases?[/color][/color]
[color=blue]
> Here is one:
>
> (defun f (x)
> (unless (< x 200)
> (cerror "Type another number"
> "You have typed a wrong number")
> (f (read)))
> (* x 2))[/color]
[color=blue]
> Look up
> http://www.lispworks.com/reference/H...ror.htm#cerror
> before complaining.[/color]

Done. But I still miss the point. OTOH, Lisp certainly doesn't check
types, so I don't see how a Lisp program can be an example of the
type system checking too many cases. OTOH, this example is tied to
a specific Lisp debugger feature. I think it would be better to give
an example in a statically typed language.

I could probably rewrite the code with an approximation to cerror
(with the restriction that non-local control structures don't
translate one to one), but even then I don't see why the type system
would test too many cases for this example.

- Dirk

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnc4bg$r6s $1@f1node01.rhr z.uni-bonn.de...[color=blue]
> Marshall Spight wrote:[color=green]
> >[color=darkred]
> >>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.[/color]

You need it to be able to run the testcase and have it succeed.
If you just want to fail with undefined method, that's exactly
the same as the compile error.

[color=blue]
> 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.[/color]

The compile errors also serve as a kind of todo list. I run the compiler,
and it gives me an error. This shows what portion of the code
I have to write next.

[color=blue]
> - 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.[/color]

Okay, so if you want to write testcases for two methods without
writing either, you have to stub in *both* methods and write
one before you can execute the testcases for one successfully.
You'd have to do this eventually anyway; the static compiler
will impose the requirement that you write stubs for the second
one before you execute the first. So I'd admit that the statically
typed language would put a tiny ordering on trivial tasks that
wouldn't otherwise be there.

(Aren't you supposed to write the method right after you
write the testcases, though?)

All those other things you've mentioned are also possible
for statically typed languages as well. (Inspect the runtime
environment, analyze how far, etc.)

[color=blue]
> 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.[/color]

I'll acknowledge dynamic languages have an advantage in interactive
execution, which may be considerable.


Marshall

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnc57b$pv6 $1@f1node01.rhr z.uni-bonn.de...[color=blue]
> Marshall Spight wrote:[color=green]
> > "Pascal Costanza" <costanza@web.d e> wrote in message news:bnbafk$uu6 $1@f1node01.rhr z.uni-bonn.de...
> >[color=darkred]
> >>... there exist programs that work but
> >>that cannot be statically typechecked. These programs objectively exist.
> >>By definition, I cannot express them in a statically typed language.[/color]
> >
> > I agree these programs exist.
> >
> > It would be really interesting to see a small but useful example
> > of a program that will not pass a statically typed language.
> > It seems to me that how easy it is to generate such programs
> > will be an interesting metric.
> >
> > Anyone? (Sorry, I'm a static typing guy, so my brain is
> > warped away from such programs. :-)[/color]
>
> Have you ever used a program that has required you to enter a number?
>
> The check whether you have really typed a number is a dynamic check, right?[/color]

This is not an example of what I requested. I can easily write
a statically typed program that inputs a string, and converts
it to a number, possibly failing if the string does not parse to a number.

I was asking for a small, useful program that *cannot* be written
in a statically compiled language (i.e., that cannot statically
be proven type-correct.) I'd be very interested to see such
a thing.


Marshall

[Pascal Costanza]

Re: Test cases and static typing

Dirk Thierbach wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> wrote:
>
>[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]
>
>
> Then just do it. Write as many tests as you care; when you're ready,
> compile them and run the type checker.
>
> Where's the problem? One thing that is certainly missing for Haskell or
> OCaml is a good IDE that supports as many styles of programming
> as possible, but even with the primitive command line versions at the
> moment you can do what you want in this case.
>
> And anyway, this would be a question of the IDE, not of static typing.[/color]

A flexible and useful IDE must treat static type checking as a separate
tool. It needs to be able to do useful things with code that isn't
correct yet. Modern IDES even give you parameter lists, etc., when the
code isn't actually completely parsable.

And that's all I wanted from the very beginning - static typing as an
additional tool, not as one that I don't have any other choice than use
by default.
[color=blue][color=green][color=darkred]
>>>>The type system might test too many cases.[/color][/color]
>
>[color=green][color=darkred]
>>>I have never experienced that, because every expression that is valid
>>>code will have a proper type.[/color][/color]
>
>[color=green][color=darkred]
>>>Can you think of an example (not in C++ or Java etc.) where the type
>>>system may check too many cases?[/color][/color]
>
>[color=green]
>>Here is one:
>>
>>(defun f (x)
>> (unless (< x 200)
>> (cerror "Type another number"
>> "You have typed a wrong number")
>> (f (read)))
>> (* x 2))[/color]
>
>[color=green]
>>Look up
>>http://www.lispworks.com/reference/H...ror.htm#cerror
>>before complaining.[/color]
>
> Done. But I still miss the point. OTOH, Lisp certainly doesn't check
> types, so I don't see how a Lisp program can be an example of the
> type system checking too many cases. OTOH, this example is tied to
> a specific Lisp debugger feature. I think it would be better to give
> an example in a statically typed language.[/color]

No, it's not better to give an example in a different language. The
whole point of my argument is that the code above cannot be statically
type-checked. And the feature presented is extremely helpful, even in
end user applications.
[color=blue]
> I could probably rewrite the code with an approximation to cerror
> (with the restriction that non-local control structures don't
> translate one to one), but even then I don't see why the type system
> would test too many cases for this example.[/color]

I don't want an "approximat ion of cerror". I want cerror!



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)

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue]
> (Aren't you supposed to write the method right after you
> write the testcases, though?)[/color]

No.
[color=blue][color=green]
>>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.[/color]
>
>
> I'll acknowledge dynamic languages have an advantage in interactive
> execution, which may be considerable.[/color]

Thank you.


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)

[Marshall Spight]

Re: Test cases and static typing

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnc8dj$pvi $1@f1node01.rhr z.uni-bonn.de...[color=blue]
>
> And that's all I wanted from the very beginning - static typing as an
> additional tool, not as one that I don't have any other choice than use
> by default.[/color]

I can get behind that idea! It strikes me as being better
than what one has now with either statically typed
languages or dynamically typed languages.


Marshall

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue][color=green][color=darkred]
>>>It would be really interesting to see a small but useful example
>>>of a program that will not pass a statically typed language.
>>>It seems to me that how easy it is to generate such programs
>>>will be an interesting metric.
>>>
>>>Anyone? (Sorry, I'm a static typing guy, so my brain is
>>>warped away from such programs. :-)[/color]
>>
>>Have you ever used a program that has required you to enter a number?
>>
>>The check whether you have really typed a number is a dynamic check, right?[/color]
>
>
> This is not an example of what I requested. I can easily write
> a statically typed program that inputs a string, and converts
> it to a number, possibly failing if the string does not parse to a number.[/color]

....and what does it do when it fails?
[color=blue]
> I was asking for a small, useful program that *cannot* be written
> in a statically compiled language (i.e., that cannot statically
> be proven type-correct.) I'd be very interested to see such
> a thing.[/color]

I have given this example in another post. Please bear in mind that
expressive power is not the same thing as Turing equivalence.

I have given an example of a program that behaves well and cannot be
statically typechecked. I don't need any more evidence than that for my
point. If you ask for more then you haven't gotten my point.


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)

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

Dirk Thierbach <dthierbach@gmx .de> writes:
[color=blue]
> 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.[/color]

I don't understand why you think that most of them will be `dead code'.

I don't understand why a smart type checker would complain about dead
code.

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bnc3cj$pv0 $1@f1node01.rhr z.uni-bonn.de...[color=blue]
>
> 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.)[/color]

The above code in Java would fail at runtime. What do you think it
ought to do? What would it do in Python? How is this superior to
what Java does? Do you consider this a real-world example?

Does the fact that you didn't respond to the other items
in my post mean you are no longer holding the position that
"explicitly cast[ing] objects" "is one of the sources for potential bugs
that you don't have in a decent dynamically typed language."


Marshall