Python from Wise Guy's Viewpoint

[Pascal Costanza]

Re: Test cases and static typing

Fergus Henderson wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>What I want is:
>>
>>testxyz obj = (concretemethod obj == 42)
>>
>>Does the code compile as long as concretemethod doesn't exist?[/color]
>
> No, because the likelihood of that being a typo (e.g. for `concrete_metho d')
> is too high.[/color]

This proves that a static type system requires you to write more code
than strictly necessary. (Please think twice before you react. This is
not meant as a pejorative remark, even if it strongly sounds like one.
It's just an objective truth. Even if you think that this is how it
should be, it doesn't make my statement wrong.)
[color=blue]
> I recently added support to the Mercury compiler for an option
> "--allow-stubs". For the equivalent code in Mercury, if this option
> is enabled, then it will compile if there is a _declaration_ for
> concretemethod, even if there is no _definition_. The compiler will
> issue a warning and automatically generate a stub definition which just
> throws an exception if it is ever called.
>
> It would be fairly straight-forward to also add support for allowing
> code like that to compile even if there was no declaration, but that
> does not seems like a good idea to me -- it would make it easier for
> typos to go unnoticed, with insufficient compensating benefit.[/color]

A good development environment gives you immediate feedback on such
kinds of typos. A good compiler for a dynamically type language issues a
warning. So these typos don't go unnoticed. The only difference is that
a dynamically typed language trusts the programmer by default, whereas a
statically typed languages doesn't trust the programmer. (To rephrase
it: A statically typed language gives you stricter support, while the
dynamically typed language gives you weaker support. But that's a
actually more or less the same statement.)
[color=blue]
> I'm sure it would also be easy for developers of other statically typed
> languages to implement what you want, if they thought it was a good idea.[/color]

Of course.

It might be interesting to note that dynamically typed language are
probably a really bad idea when you don't have a good IDE. The features
that fans of statically typed languages care about are usually regarded
as part of the development environment's jobs. This is only to indicate
that programming in a dynamically typed language is not as horrible as
you might think when seen in the right context.

And here is one of the probable replies: Statically typed languages
don't require a sophisticated IDE in order to do useful work. This might
be an advantage in some scenarios.

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

Matthias Blume wrote:
[color=blue]
> You first have to define what the meaning of a phrase is going to be
> if you let it slip past the type checker even though it is not
> well-typed. As Andreas Rossberg pointed out, it is quite often the
> case that the type is essential for understanding the semantics.
> Simply ignoring types does not necessarily make sense under such
> circumstances. So it all depends on how you re-interpret the language
> after getting rid of static types.[/color]

Can you show me an example of a program that does't make sense anymore
when you strip off the static type information?


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)

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
>Fergus Henderson wrote:
>[color=green]
>> 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.[/color]
>
>+ Design process: There are clear indications that processes like
>extreme programming work better than processes that require some kind of
>specificatio n stage.[/color]

This is certainly not clear to me, especially if you consider writing
type declarations to be "some kind of specification stage".
[color=blue]
>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]

That one seems to have been pretty thoroughly debunked by other responses
in this thread. A static type system won't stop you writing unit tests.
And if you want to actually run the unit tests, then you are going to
need appropriate target code, regardless of whether the system is
statically or dynamically typed.
[color=blue]
>+ Error checking: I can only guess what you mean by this.[/color]

I mean compile-time detection of type errors.
I'm just talking about ordinary everyday detection of typos, functions
called with the wrong number of arguments, arguments in the wrong order,
arguments of the wrong type -- that kind of thing.
[color=blue]
>If you mean something like Java's checked exceptions,
>there are clear signs that this is a very bad feature.[/color]

No, I do not mean that. I tend to agree that statically checked
exception specifications are not worth the complication and can be
positively harmful in some situations.
[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]

It's not enough to just identify the bottlenecks. You have to make those
bottlenecks go fast! That's a lot harder with a dynamically typed language,
because you pay a lot of overhead: greater memory usage, and hence worse
cache performance, due to less efficient representations of types in memory;
plus added overhead from all of those dynamic type checks. Of course good
compilers for dynamic languages analyze the source to try to infer the types,
but since the language is not statically typed, such analysis will often fail.

--
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.

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Fergus Henderson wrote:
[color=blue][color=green]
>>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]
>
>
> That one seems to have been pretty thoroughly debunked by other responses
> in this thread. A static type system won't stop you writing unit tests.
> And if you want to actually run the unit tests, then you are going to
> need appropriate target code, regardless of whether the system is
> statically or dynamically typed.[/color]

Not if I only want to check whether the first ten tests work, and don't
care about the remaining ones.
[color=blue][color=green]
>>+ 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]
>
>
> It's not enough to just identify the bottlenecks. You have to make those
> bottlenecks go fast! That's a lot harder with a dynamically typed language,
> because you pay a lot of overhead: greater memory usage, and hence worse
> cache performance, due to less efficient representations of types in memory;
> plus added overhead from all of those dynamic type checks. Of course good
> compilers for dynamic languages analyze the source to try to infer the types,
> but since the language is not statically typed, such analysis will often fail.[/color]

Good dynamically typed languages provide very good options in this
regard. However, other Lispers than me can probably provide much better
comments on that.


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)

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

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

No -- you don't need to implement the method. You only need to declare it.

Even the need to declare it is really just a property of implementations ,
not languages.
[color=blue]
>Well, the research that ultimately lead to the HotSpot Virtual Machine
>originated in virtual machines for Smalltalk and for Self. Especially
>Self is an "extremely" dynamic language, but they still managed to make
>it execute reasonably fast.[/color]

Please correct me if I'm wrong, but as I understand it, iterating over a
collection of values is still going to require keeping some representation
of the type of each element around at runtime, and testing the type for
each element accessed, in case it is not the expected type. AFAIK neither
HotSpot nor the Self compiler do the kind of optimizations which would
be needed to avoid that.

--
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.

[Dirk Thierbach]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> wrote:[color=blue]
> Dirk Thierbach wrote:[/color]
[color=blue][color=green][color=darkred]
>>>According to your criteria, (real * 200) is
>>>- a certain class of values
>>>- given in a limited language describing that class[/color][/color][/color]
[color=blue][color=green]
>> Yes, but you will have a hard time developing a static type checker
>> that will work with such a language.[/color][/color]
[color=blue]
> I am not asking for a definition of the term "static type", but for a
> definition of the term "type".[/color]

I am happy with a definition of "type" that allows arbitrary sets of
values, but how does this apply to static typing? Or dynamic type
checking? I was talking all the time about a definition of a "static
type", because that it what is relevant here.

Philosophically , there are a lot more sensible definitions for type,
but how does one such definition relate to our discussion?
[color=blue]
> Haskell: "An expression evaluates to a value and has a static type."
> (http://www.haskell.org/onlinereport/intro.html#sect1.3 )
>
> Where is the definiton for "type"? (without "static"?)[/color]

There is none, because that is not relevant.
[color=blue]
> Let's first get our terminology right.[/color]

Maybe we should also agree on what we want to use the terminology for.
[color=blue]
> I don't mind if you want to change that terminology. Let's just
> rephrase it: Static type systems need to reject programs that
> wouldn't necessarily fail in serious ways at runtime.[/color]

I think I already agreed with that several times, didn't I?

But then you have also to add "even if they won't necessarily fail,
nearly all of them won't be well-behaved".
[color=blue][color=green][color=darkred]
>>>But I am interested in the question why you (or others) think that
>>>almost all software should be developed like that.[/color][/color][/color]
[color=blue][color=green]
>> I didn't say that. Please do not put up a strawman. In fact, I
>> explicitely said "you use whatever tool you like best".[/color][/color]
[color=blue]
> But that was the original question that initiated this thread. If we
> have an agreement here, that's perfect![/color]

Finally. *Sigh*. Why do I have to repeat that multiple times?
[color=blue]
> What about the example in
> http://groups.google.com/groups?selm....netcologne.de
> ?[/color]
[color=blue]
> I don't think this can be done without a serious rewrite.[/color]

The problem here is that the object system of CLOS and OCaml is
quite different, and Haskell has no objects at all. So you cannot
directly transfer that example to those languages. Not because they
are statically typed, but because they are different. It probably
wouldn't be possible to do exactly the same in another arbitrary
dynamically typed language, either.

But you can trivially simulate the *effects* of your program once
you accept that such a simulation need not use classes.

Please don't mix the differences because of statically/dynamically
typing and because of other language features.
[color=blue]
> Right, it comes from a more principled consideration: You can't have
> metacircularity in a statically type language. You might be able to have
> metacircularity if you strictly separate the stages, but as soon as you
> want to be able to at least occasionally call base code from meta code
> and vice versa, then you lose.[/color]

But you don't need metacircularity , because then you simply solve
your problem in a different way.
[color=blue]
> Metacircularity gives me the guaranntee that I can always code around
> any unforeseeable limitations that might come up, without having to
> start from scratch.[/color]

You can also create very subtle bugs that are difficult to find.
[color=blue]
> I haven't said that I can do more things in a dynamically typed
> language. I have said that statically typed languages need to reject
> well-behaved programs. That's a different claim. We are not talking
> about Turing equivalence.[/color]

Neither am I talking about Turing equivalence.

But if you can agree that it is not harder to express something in a
(properly) statically typed languages then to express it in a
dynamically typed language, then we can stop the discussion here.

What I want you is to give up the point of view that dynamically
languages have an *advantage* because they are dynamically typed.

- Dirk

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
>Do you have a reference for extensible record types. Google comes up,
>among other things, with Modula-3, and I am pretty sure that's not what
>you mean.[/color]

The following are at least a bit closer to what is meant:

[1] Mark P Jones and Simon Peyton Jones. Lightweight Extensible
Records for Haskell. In Haskell Workshop, Paris, September 1999.
<http://citeseer.nj.nec .com/jones99lightwei ght.html>

[2] B. R. Gaster and M. P. Jones. A polymorphic type
system for extensible records and variants. Technical
report NOTTCS-TR-96-3, Department of Computer Science,
University of Nottingham, UK, 1996. Available from URL
<http://www.cs.nott.ac. uk/Department/Staff/~mpj/polyrec.html>.
<http://citeseer.nj.nec .com/gaster96polymor phic.html>.

--
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.

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

"Paul F. Dietz" <dietz@dls.ne t> writes:
[color=blue]
>Ralph Becket wrote:
>[color=green]
>> Here's the way I see it:[/color][/color]
....[color=blue][color=green]
>> (3) type errors flagged by a compiler for an ESCTS can pinpoint the source
>> of the problem whereas ad hoc assertions in code will only identify a
>> symptom of a type error;[/color][/color]
....[color=blue]
>BTW, is (3) really justified? My (admittedly old) experience with ML
>was that type errors can be rather hard to track back to their sources.[/color]

It depends on whether you declare the types of functions or not.
If you leave it up to the compiler to infer the types of all the
functions, then compilers have a difficult job of pinpointing errors,
because sometimes your incorrectly-implemented functions will be
type-correct, just with a different type than you expected, and this
will then leave to type errors further up the call tree.

But declaring the intended types of functions improves things dramatically.
If you get a type error, and you can't immediately figure out what is wrong,
declaring the intended types of the functions involved and recompiling
will allow you to quickly pinpoint the problem.

Of course, the type checker's error messages won't tell you _exactly_
where the error is; they can only point out inconsistencies , e.g. between
the code for a function and its type declaration, or between the code
for a function and one or more of the type declarations for the functions
that it calls. But such inconsistencies should be easy to resolve;
the programmer should be able to tell which of the contradictory parts
are wrong. (The exception is when the inconsistency actually reveals
a design error; in the worst case, a major redesign may be required.)

--
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.

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

Joe Marshall wrote:
[color=blue]
> Joachim Durchholz <joachim.durchh olz@web.de> writes:
>[color=green]
>>prunesquallor @comcast.net wrote:
>>[color=darkred]
>>>My point is that type systems can reject valid programs.[/color]
>>
>>And the point of the guys with FPL experience is that, given a good
>>type system[*], there are few if any practial programs that would be
>>wrongly rejected.[/color]
>
> We're stating a pretty straightforward , objective, testable hypothesis:
>
> ``There exists valid programs that cannot be statically checked by
> such-and-such a system.''
>
> and we get back
>
> `yes, but...'
> `in our experience'
> `*I've* never seen it'
> `if the type system is any good'
> `few programs'
> `no practical programs'
> `no useful programs'
> `isolated case'
> `99% of the time'
> `most commercial programs'
> `most real-world programs'
> `only contrived examples'
> `nothings perfect'
> `in almost every case'
>
> Excuse us if we are skeptical.[/color]

Then be sceptical if you like.
Actually your hypothesis is ill-worded anyway: it says "valid" without
specifying what kind of validity means (which already has lead us into
many irrelevant meanderings about what correctness and validity mean,
and that they cannot be expressed if you don't have specifications) . It
ignores that some programs need restructuring to have any useful static
types associated with its items (you can always put a Lisp-style type
system on top of a statically-typed language, with little effort). It
ignores the practical experience of people who indeed say "static typing
with type inference is not a straightjacket but a ladder: supports where
it's helpful, and extending my reach in directions that were unthinkable
before they were invented".
However, all I hear is questions "how to you type this". Whining for the
known and trusted idioms, instead of even thinking about the idioms that
static typing might provide.

Just take the testimony and accept it. Just as I take the testimony that
one can write large programs in Lisp. Stay sceptical if you like - I
certainly do.

I'm just tired of the Costanza-style constant nitpicking, topic evasion,
and not answering to critical questions (such as his experience with
modern type systems - he claims it but shows little evidence for that,
something that makes me suspicious about his credibility in general).

Technical newsgroups are a place for exchanging new ideas, and for
helping people along. This thread has already served that purpose to the
utmost extent imaginable, what's left is squabbling.

Good night and Over and Out for me (except for direct answers to my
posts, where appropriate).

Regards,
Jo

[Andreas Rossberg]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:[color=blue]
>
> Can you show me an example of a program that does't make sense anymore
> when you strip off the static type information?[/color]

Here is a very trivial example, in SML:

20 * 30

Multiplication, as well as literals, are overloaded. Depending on
whether you type this expression as Int8.int (8-bit integers) or
IntInf.int (infinite precision integer) the result is either 600 or an
overflow exception.

So the program does not make sense without type information, because it
does not have an unambiguous (i.e. no) semantics.

I'm ready to admit that it may be a dubious example of a typing feature.
But it is simple, and clearly sufficient to disprove your repeated claim
that static types don't add expressiveness to a language. If you did not
have them for the example above, you needed some other feature to
express the disambiguation.

- Andreas

--
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.

[John Atwood]

Re: Static typing

Pascal Costanza <costanza@web.d e> wrote:[color=blue]
>John Atwood wrote:[color=green]
>> Pascal Costanza <costanza@web.d e> wrote:[color=darkred]
>>>No, you definitely can do a lot of things with macros in Lisp that are
>>>impossible to do in other languages. There are papers that show this
>>>convincingly . Try
>>>ftp://publications.ai.mit.edu/ai-pub...df/AIM-453.pdf for a
>>>start. Then continue, for example, with some articles on Paul Graham's
>>>website, or download and read his book "On Lisp".[/color]
>>
>> That's a great paper; however, see Steele's later work:
>> http://citeseer.nj.nec.com/steele94building.html[/color]
>
>Yes, I have read that paper. If you want to work with monads, you
>probably want a static type system.
>
>(And I think he still likes Scheme and Lisp. ;)[/color]


Perhaps, but the paper shows convincingly that statically typed languages
can do a lot of things that Lispers use macros for. Work in
meta-programming, aka mult-stage programming, shows how to more finely
control the power of macros, reflection, etc. See, e.g.:

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

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

John

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

prunesquallor@c omcast.net writes:
[color=blue]
>"Andreas Rossberg" <rossberg@ps.un i-sb.de> writes:
>[color=green]
>> Sorry, but that reply of yours somewhat indicates that you haven't really
>> used modern type systems seriously.
>>
>> All decent type systems allow you to define your own types. You can express
>> any domain-specific abstraction you want in types. Hence the type language
>> gives you additional expressive power wrt the problem domain.[/color]
>
>Cool! So I can declare `Euclidean rings' as a type an ensure that I
>never pass a non-Euclidean ring to a function?[/color]

You can easily declare "EuclideanRings " as a type class
(in Haskell/Clean/Mercury, or similar constructs in other languages),
and ensure that you only pass this function values whose type has been
declared to be an instance of that type class.

Generally the type system won't be able to enforce that the
"EuclideanRings " type class really represents Euclidean rings
that conform to all the appropriate axioms. However, declaring
an abstract type like this is nevertheless very useful as documentation:
it makes it clear where the proof obligation lies. _If_ you prove that
every declared instance of the type class is really a Euclidean ring,
then that, together with the type system, will be enough to guarantee
that the function's argument is always a Euclidean ring.

--
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.

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

gt5163b@prism.g atech.edu (Brian McNamara!) writes:
[color=blue]
>prunesquallor@ comcast.net once said:[color=green]
>>(defun black-hole (x)
>> #'black-hole)
>>
>>(for non lispers, the funny #' is a namespace operator.
>> The black-hole function gobbles an argument and returns
>> the black-hole function.)[/color]
>
>Finally, an example that I don't think you can type in Haskell.
>You score a point for that. :)[/color]

I don't think it deserves any points, because as another poster said,
in Haskell that is equivalent to

black_hole _ = undefined

--
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.

[Joe Marshall]

Re: Python from Wise Guy's Viewpoint

Fergus Henderson <fjh@cs.mu.oz.a u> writes:
[color=blue]
> prunesquallor@c omcast.net writes:[color=green]
>>
>>Cool! So I can declare `Euclidean rings' as a type an ensure that I
>>never pass a non-Euclidean ring to a function?[/color]
>
> _If_ you prove that
> every declared instance of the type class is really a Euclidean ring,
> then that, together with the type system, will be enough to guarantee
> that the function's argument is always a Euclidean ring.[/color]

Yeah, but *that's* the easy part.

[Matthew Danish]

Re: Python from Wise Guy's Viewpoint

On Mon, Oct 27, 2003 at 05:57:00PM +0100, Joachim Durchholz wrote:[color=blue]
> (you can always put a Lisp-style type system on top of a
> statically-typed language, with little effort).[/color]

This is not true, as I've pointed out on several occasions. Such
systems do not behave like a Lisp-style type system when dealing with
redefinition.

--
; 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."