Python from Wise Guy's Viewpoint

[prunesquallor]

Because otherwise the code will be executed, and this will result
in a crash -- there must be a reason why the type checker complains.

Allow me to rephrase: I don't understand why you think *most* of them
will be dead code. Aren't there other cases where the type checker
would complain?

 

[prunesquallor]

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.

Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?

 

[prunesquallor]

Ooops...

Yeah, my innocent sounding question often hide some nasty pitfalls.

 

[Marshall Spight]

I have a my own pet theories to explain the current exitement about
dynamically typed languages. Here they are..

Nice analysis. I particularly liked:

But some language developers don't want to get to bogged down with
all that difficult and boring theory stuff for however many months
or years it takes.

Your ideas are probably biased, but your biases match mine, so
there you are.


Marshall

 

[Jay O'Connor]

Cool! So I can declare `Euclidean rings' as a type an ensure that I
never pass a non-Euclidean ring to a function?

In Ada, you can

 

[Jay O'Connor]

In Ada, you can

Ooops...

 

[Pascal Costanza]

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?

You should be able to choose unique names in the first place. The
problem Java has here is that there is no safe way to avoid that in
general. There is a risk of name clashes here.

There is some information about one way to properly deal with namespaces
at
http://www.cs.northwestern.edu/academics/courses/325/readings/packages.html

There are also other approaches. For example, there exist several module
systems for Scheme. (I don't know a lot about them, though.)

I don't know how Python handles potential name conflicts.

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

No.

Pascal

 

[Pascal Costanza]

I don't agree with the "must", but type checking is a seperate phase
in the compiler. It should be possible to make an IDE that treats
it that way. But I doubt that particular point is high on the priority
list of any potential programmer of an IDE.

No, it's only high on the priority list of actual programmers of IDEs.
For example, you could check what Eclipse has to offer for Java in that
regard.

And that's fine, but it is not an issue of static typing.



You can look now at two examples of code like this that can be
statically type-checked.

I am not convinced, but let's play that game for a while: OK, we have
three programs that have the same behavior, and they especially all
behave well. Only two of them can be statically type checked.

This completes my proof that static type systems reduce expressive power.

And I had the impression that you wanted to explain why a "type system
might test too many cases". I still don't understand this argument. I
don't see any "case" that the type system will test in the above
program, let alone "too many".



Then use Lisp and cerror. Nobody forces you to use anything else. The
problem is again that you want to do it only in exactly the same way
as you are used to doing it. You don't see how to do it in another
language, and then you say "it cannot be done". And that's just wrong.

I don't say it cannot be done. Don't put words into my mouth.

In this case, you actually need to write additional code to simulate
dynamic checks in a statically typed language that a dynamically typed
language gives you for free. I am sorry, but I don't see any advantage
in such an approach.

So can we settle on "you like to do it your way, but it is possible
to do everything you want in a statically typed language if
you're a little bit more flexible"? (That means of course that if
you refuse to be a bit more flexible, it cannot be done in exactly
the same way -- after all, they are different languages.)

Well, in my book the computer should adapt to what I want, and not the
other way around.

As long as you say "this cannot be done" you'll get answers showing
you that it can indeed be done, only in a way that is a little bit
different. Then you say "yes, but that's not how I want it. You're
trying to force to use me something I don't want!".

No, I haven't said it cannot be done. I have talked about expressive
power, and that's something different.

It gets a bit silly after some iterations.

Indeed.


Pascal

 

[Pascal Costanza]

That's a contradiction, because the type system is part of the "target"
language. You cannot separate them, because the type system is more then
just a static analysis phase - you can program it.

For christ's sake, the only interesting question here is: do statically
typed languages increase or decrease the set of programs that behave
well at runtime?


Pascal

 

[Donn Cave]

Quoth Adrian Hey <[email protected]>:
| (e-mail address removed) wrote:
|> 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?
|
| I have a my own pet theories to explain the current exitement about
| dynamically typed languages. Here they are..
|
| 1- Most of this buzz comes from OO folk, many of whom will only have
| (bad) experience of static typing from C/C++/Java.

That is true for sure with at least some of them.

While your other two theories were interesting, I think most of
it is essentially psychological. I am quite sure that some people
react to static typing with a deep personal resentment. Static
typing is discipline. It would be interesting to see how it flies
in different cultural contexts, say US vs. Japan.

But the value in not blaming it all on C++ et al. is that it gives
us some reasons to think about whether Haskell et al. are really
doing all they can to make static typing work for everyone. Like,

ERROR "hello.hs":8 - Unresolved top-level overloading
*** Binding : main
*** Outstanding context : Show b

Not to get into the details here, but is someone who takes our
hint here and checks out Haskell really headed for a terrific
demonstration of how modern static typing is an easy and fun way
to increase programming productivity? It really is at least a
little harder than we would like to understand type errors like
this, let's admit. A significant factor in the success of languages
like Python is that their shallow learning curve allows the typical
beginner (someone who has used another language) to write a useful
program after literally a few minutes of study of the language.
People like that, they don't like frustration. Psychological thing,
as I said, but possibly something that FPLs could work on.

As for O'Haskell and Objective CAML ... I find O'Haskell really
interesting, but in my view it isn't particularly about OOP
programming in any conventional sense. Objective CAML is, but
someone else will have to tell us how well it works as an OOPL.

Donn Cave, (e-mail address removed)

 

[Marshall Spight]

You should be able to choose unique names in the first place. The
problem Java has here is that there is no safe way to avoid that in
general. There is a risk of name clashes here.

Grrr. You didn't answer any of my questions. (Except the one
about Python, for which you said you didn't know.) Or maybe
your response is meant to be an answer to one or more of
them, only I can't tell which or how.

I'm having a hard time following you. Also, you seem to be
shifting what you're talking about quite frequently, which
makes me suspicious.

At this stage I've entirely lost track of the thread. Ah, well.

No.

I didn't think so.


Marshall

 

[Marshall Spight]

Would this count?

(defun noisy-apply (f arglist)
(format t "I am now about to apply ~s to ~s" f arglist)
(apply f arglist))

Interesting, interesting. Thanks for taking me seriously!

I'm trying to map this program into Java, and it's possible
but there are enough different ways to go about it that
I'm having a hard time reasoning about the result.

For one thing, what would f be? Probably an instance of
a class that implements a specific interface. But then,
implementing a specific interface is like saying we
know what type f is. Is it a function that takes a
single argument of type Object? If we concede
all those points, then this is fairly easy to map
into Java. If we say that f can take any single argument
then we can do it with reflection if we are willing
to add 15 lines of code, which is certainly not pretty.
If it can take any number of arguments then it's
looking triply awful now.

It's starting to feel like this is merely a demonstration
of Java's weakness in generic programming, and
not something hooked into Goedel.

Anyone have any comments?


Marshall

 

[Thomas Lindgren]

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

Because Intel ultimately triumphed over the pundits advocating another
solution?

Because differences in instruction set architecture due to
implementation advances ultimately became irrelevant for
high-performance computers? (Meaning all non-embedded ones, that is.)

Because a big, somewhat worse standard (x86) beat a squabbling horde of
somewhat better contenders (RISCs)?

Because the marketplace moved on from "workstations", stranding the
high-cost, high-performance systems in favour of low-cost,
nearly-same-performance systems? Which then overtook the former
champions.

Something else?

Best,
Thomas

 

[Marshall Spight]

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

Because [...] ?

Because at no time did CISC machines ever fall below 95%
market share.

Because a big, somewhat worse standard (x86) beat a squabbling horde of
somewhat better contenders (RISCs)?

Hey, x86 is a *lot* worse!


Marshall

 

[Matthew Danish]

It is not, because Lisp hasn't been designed with types in mind. It is
pretty much folklore that retrofitting a type system onto an arbitrary
language will not work properly. For example, Lisp makes no distinction
between tuples and lists, which is crucial for type inference.

Tell that to the hackers who worked on the "Python" compiler found in
CMUCL, SBCL, and some others. It does extensive type inference for both
efficiency and correctness. But it doesn't get in the way (except in
certain rare cases), it just (noisely) informs you what it thinks.

Tell that to the people who wrote Chapter 4 of the Common Lisp standard.
http://www.lispworks.com/reference/HyperSpec/Body/04_.htm

If you want to have extensible overloading then static types are the only
way I know for resolving it. Witness Haskell for example. It has a very
powerful overloading mechanism (for which the term 'overloading' actually is
an understatement). It could not possibly work without static typing, which
is obvious from the fact that Haskell does not even have an untyped
semantics.

Correction: it could not work without typing--dynamic typing does not
imply a lack of typing. I could be wrong, but it seems you would rule
out generic functions in the CLOS (and dynamic dispatch in general) with
the above statement.

Erasing type information from a program that uses type abstraction to
guarantee certain post conditions will invalidate those post conditions. So
you get a program with a different meaning. It expresses something
different, so the types it contained obviously had some expressive power.

This doesn't sound right: erasing type information should not invalidate
the post conditions; it should simply make it more difficult
(impossible?) to check the validity of the post conditions.

This program should still work, even if you fail to type-check it, if
said type-checking would have passed successfully.

Erasing type information from a program that uses overloading simply makes
it ambiguous, i.e. takes away any meaning at all. So the types definitely
expressed something relevant.

This statement is irrelevant because dynamic typing does not eliminate
type information.

 

[Matthew Danish]

That's because you're in an interpreted environemt, not because you're
using a dynamically typed language. Interpreters for statically typed
languages allow the same.

Wrong on all counts.

* Most Common Lisp environments compile to native code, even when
working interactively.
SBCL, for example, has no interpreter whatsoever. The interpreter is
simulated by calling the compiler and evaluating the resulting
function immediately.
* There exists statically typed language implementations which do the
same (SML/NJ)
* The behavior of redefinition in a statically typed environment
is far different from the behavior in a dynamically typed environment.
For one thing, generativity of names kicks in, which makes it
basically impossible to redefine types and functions without
recompiling all uses (and thus restarting your program), in a static
environment.

 

[ketil+news]

ERROR "hello.hs":8 - Unresolved top-level overloading
*** Binding : main
*** Outstanding context : Show b

Not to get into the details here, but is someone who takes our
hint here and checks out Haskell really headed for a terrific
demonstration of how modern static typing is an easy and fun way
to increase programming productivity?

(This is Hugs, no?) One of the things I find much better now compared
to when I started with Haskell a couple of years ago are the error
messages of GHC -- and it will generally tell you exactly what to do
(add Show b to the context) in this case.

Then there's Helium, which has a simplified type system and primarily
tries to be helpful to beginners.

True, typing can give you difficult to comprehend error messages, but
this is obviously something developers take very seriously.

-kzm

 

[Nikodemus Siivola]

I'm having a hard time following you.

I have a guess about this. You seem -- by your references to Python --
to be implicitly assuming that Pascal, Joe &co are setting up Python
as the lightbearer of dynamism.

I find this rather unlikely, as most -- if not all -- of the
pro-dynamic side of this argument hail from Lisp, not Python.

Just a datapoint, since there seemed to be an unstated
misunderstanding there.

Cheers,

-- Nikodemus

 

[Joachim Durchholz]

Downcasts in Java are not a source of problems.

Huh?
Alone the need to downcast whenever I take something out of a container
would suffice to term it as a "serious problem".
Unless you meant: it's not the downcasts that are the problem, it's the
many language mechanisms that require downcasts that are.

Regards,
Jo

 

[prunesquallor]

I am not sure if I read this correctly, but it seems equivalent to what
I say.

\exists branch. mismatch-in (branch)

should be the same as

\not \forall branch. \not mismatch-in (branch)

Anyway, I don't understand your point.

Only if you assume binary logic. If there are three values that
can arise --- provable-mismatch, provable-non-mismatch, and undecided
--- then you cannot assume that ~provable-mismatch = provable-non-mismatch.

My point is that type systems can reject valid programs.