Python from Wise Guy's Viewpoint

[Erann Gat]

Re: Python from Wise Guy's Viewpoint

In article <3638acfd.03102 30039.306b14f@p osting.google.c om>,
rafe@cs.mu.oz.a u (Ralph Becket) wrote:
[color=blue]
> 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]

No. The fallacy in this reasoning is that you assume that "type error"
and "bug" are the same thing. They are not. Some bugs are not type
errors, and some type errors are not bugs. In the latter circumstance
simply ignoring them can be exactly the right thing to do.

(On the other hand, many, perhaps most, type errors are bugs, and so
having a type system provide warnings can be a very useful thing IMO.)

E.

[Ken Rose]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:[color=blue]
> Ken Rose wrote:
>[color=green]
>> Pascal Costanza wrote:
>>[color=darkred]
>>> Joachim Durchholz wrote:
>>>
>>>> Pascal Costanza wrote:
>>>>
>>>>> For example, static type systems are incompatible with dynamic
>>>>> metaprogramming . This is objectively a reduction of expressive
>>>>> power, because programs that don't allow for dynamic
>>>>> metaprogramming can't be extended in certain ways at runtime, by
>>>>> definition.
>>>>
>>>>
>>>> What is dynamic metaprogramming ?
>>>
>>>
>>> Writing programs that inspect and change themselves at runtime.[/color]
>>
>>
>> Ah. I used to do that in assembler. I always felt like I was aiming
>> a shotgun between my toes.
>>
>> When did self-modifying code get rehabilitated?[/color]
>
>
> I think this was in the late 70's.[/color]

Have you got a good reference for the uninitiated?

Thanks

- ken

[Andreas Rossberg]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:[color=blue]
> Matthias Blume wrote:
>[color=green]
>> Pascal Costanza <costanza@web.d e> writes:
>>
>>[color=darkred]
>>> Matthias Blume wrote:
>>>
>>>
>>>> PS: When I say "untyped" I mean it as in "the _untyped_ lambda
>>>> calculus".
>>>
>>>
>>> What terms would you use to describe the difference between
>>> dynamically and weakly typed languages, then?
>>>
>>>
>>> For example, Smalltalk is clearly "more" typed than C is. Describing
>>> both as "untyped" seems a little bit unfair to me.[/color]
>>
>>
>>
>> Safe and unsafe.
>>
>> BTW, C is typed, Smalltalk is untyped. C's type system just happens
>> to be unsound (in the sense that, as you observed, well-typed programs
>> can still be unsafe).[/color]
>
>
> Can you give me a reference to a paper, or some other literature, that
> defines the terminology that you use?
>
> I have tried to find a consistent set of terms for this topic, and have
> only found the paper "Type Systems" by Luca Cardelli
> (http://www.luca.demon.co.uk/Bibliography.htm#Type systems )
>
> He uses the terms of static vs. dynamic typing and strong vs. weak
> typing, and these are described as orthogonal classifications . I find
> this terminology very clear, consistent and useful. But I am open to a
> different terminology.[/color]

My copy,

http://research.microsoft.com/Users/luca/Papers/TypeSystems.A4.pdf

on page 3 defines safety as orthogonal to typing in the way Matthias
suggested.

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

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Ken Rose wrote:[color=blue]
> Pascal Costanza wrote:
>[color=green]
>> Ken Rose wrote:
>>[color=darkred]
>>> Pascal Costanza wrote:
>>>
>>>> Joachim Durchholz wrote:
>>>>
>>>>> Pascal Costanza wrote:
>>>>>
>>>>>> For example, static type systems are incompatible with dynamic
>>>>>> metaprogramming . This is objectively a reduction of expressive
>>>>>> power, because programs that don't allow for dynamic
>>>>>> metaprogramming can't be extended in certain ways at runtime, by
>>>>>> definition.
>>>>>
>>>>>
>>>>>
>>>>> What is dynamic metaprogramming ?
>>>>
>>>>
>>>>
>>>> Writing programs that inspect and change themselves at runtime.
>>>
>>>
>>>
>>> Ah. I used to do that in assembler. I always felt like I was aiming
>>> a shotgun between my toes.
>>>
>>> When did self-modifying code get rehabilitated?[/color]
>>
>>
>>
>> I think this was in the late 70's.[/color]
>
>
> Have you got a good reference for the uninitiated?[/color]

http://www.laputan.org/ref89/ref89.html and
http://www.laputan.org/brant/brant.html are probably good starting
points. http://www-db.stanford.edu/~paepcke/...ts/mopintro.ps
is an excellent paper, but not for the faint of heart. ;)


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

Andreas Rossberg wrote:
[color=blue][color=green]
>> Can you give me a reference to a paper, or some other literature, that
>> defines the terminology that you use?
>>
>> I have tried to find a consistent set of terms for this topic, and
>> have only found the paper "Type Systems" by Luca Cardelli
>> (http://www.luca.demon.co.uk/Bibliography.htm#Type systems )
>>
>> He uses the terms of static vs. dynamic typing and strong vs. weak
>> typing, and these are described as orthogonal classifications . I find
>> this terminology very clear, consistent and useful. But I am open to a
>> different terminology.[/color]
>
>
> My copy,
>
> http://research.microsoft.com/Users/...Systems.A4.pdf
>
> on page 3 defines safety as orthogonal to typing in the way Matthias
> suggested.[/color]

Yes, but it says dynamically typed vs statically typed where Matthias
says untyped vs typed.


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)

[Andreas Rossberg]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:[color=blue][color=green]
>>
>> My copy,
>>
>> http://research.microsoft.com/Users/...Systems.A4.pdf
>>
>> on page 3 defines safety as orthogonal to typing in the way Matthias
>> suggested.[/color]
>
> Yes, but it says dynamically typed vs statically typed where Matthias
> says untyped vs typed.[/color]

Huh? On page 2 Cardelli defines typed vs. untyped. Table 1 on page 5
clearly identifies Lisp as an untyped (but safe) language. He also
speaks of statical vs. dynamical _checking_ wrt safety, but where do you
find a definition of dynamic typing?

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

[Pascal Bourguignon]

Re: Python from Wise Guy's Viewpoint

Matthias Blume <find@my.addres s.elsewhere> writes:[color=blue]
> 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).[/color]

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?

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

Pascal Bourguignon <spam@thalassa. informatimago.c om> writes:
[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]

No, we are speaking different definitions of "typed" and "untyped"
here. Even assembler is typed if you look at it the right way.

As I said before, I mean "untyped" as in "The Untyped Lambda
Calculus" which is a well-established term.

Matthias

[Dirk Thierbach]

Re: Static typing

Pascal Costanza <costanza@web.d e> wrote:[color=blue]
> Unless the static type system takes away the expressive power that I need.[/color]

Even within a static type system, you can always revert to "dynamic
typing" by introducing a sufficiently universal datatype (say,
s-expressions).

Usually the need for real runtime flexiblity is quite localized (but
of course this depends of the application). Unless you really need runtime
flexibility nearly everywhere (and I cannot think of an example where
this is the case), the universal datatype approach works quite well
(though you loose the advantages of static typing in these places, of
course, and you have to compensate with more unit tests).
[color=blue]
> I have given reasons when not to use a static type system in this
> thread.[/color]

Nobody forces you to use a static type system. Languages, with their
associated type systems, are *tools*, and not religions. You use
what is best for the job.

But it's a bit stupid to frown upon everything else but one's favorite
way of doing things. There are other ways. They may work a bit
differently, and it might be not obvious how to do it if you're used
to doing it differently, but that doesn't mean other ways are
completely stupid. And you might actually learn something once
you know how to do it both ways :-)
[color=blue]
> Please take a look at the Smalltalk MOP or the CLOS MOP and tell
> me what a static type system should look like for these languages![/color]

You cannot take an arbitrary language and attach a good static type
system to it. Type inference will be much to difficult, for example.
There's a fine balance between language design and a good type system
that works well with it.

If you want to use Smalltalk or CLOS with dynamic typing and unit
tests, use them. If you want to use Haskell or OCaml with static typing
and type inference, use them. None is really "better" than the other.
Both have their advantages and disadvantages. But don't dismiss
one of them just because you don't know better.

- Dirk

[Andrew Dalke]

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz[color=blue]
> Not quite - that was a loss of 500 million dollars. I don't know what
> the software development costs were, so I'm just guessing here, but I
> think it's relatively safe to assume a doubly redundant system would
> already have paid off if it had caught the problem.[/color]

Since the Mars rover mission a few years ago cost only about $250million,
I'm going to assume that you included payload cost. Here's some
relevant references I found [after sig], which suggests a price per rocket
of well under $100 million and the cost of the "four uninsured scientific
satellites" made it be about $500 million.

It used to be that rockets needed a lot of real-world tests before
people would stick expensive payloads on them. For a while, dead
weight was used, but people like amateur hams got permission to
put "cheap" satellites in its place, and as the reliability increased,
more and more people were willing to take chances with unproven
rockets.

So there's an interesting tradeoff here between time spent on live
testing and the chance it will blow up. Suppose Ariane decided
to launch with just bricks as a payload. Then they would have
been out ~$75 million. But suppose they could convince someone
to take a 10% chance of failure to launch a $100 million satellite
for half price, at $40 million. Statistically speaking, that's a good
deal. As long as it really is a 10% chance.

(The satellites were uninsured, which suggests that this was
indeed the case.)

However, it seems that 4 of the first 14 missions failed, making
about a 30% failure rate. It also doesn't appear that all of those
were caused by software failures; the 4th was in a "cooling
circuit."
[color=blue]
> The point is that no amount of software technology would have caught the
> problem if the specifications are wrong.[/color]

I agree.

Andrew
dalke@dalkescie ntific.com

http://www.namibian.com.na/2002/june/techtalk/02651A180A.html

] The Ariane 44L rocket equipped with four liquid strap-on boosters --
] the most powerful in the Ariane-4 series --
...
] Specialists estimated the cost of the satellite, launch and insurance at
] more than $250 million.

http://www.cnn.com/2000/TECH/space/12/20/rocket.ariane.reut/

] Western Europe's new generation Ariane-5 rocket has placed three
] satellites into space
...
] Experts have estimated the cost of the [ASTRA 2D] satellite,
] launch and insurance at over $85 million
...
] The estimated cost of the GE-8 satellite, launch and insurance is
] over $125 million.

] But Ariane-5's career began with a spectacular failure during its
] maiden test launch in June 1996, exploding 37 seconds after
] lift-off and sending four uninsured scientific satellites worth $500
] million plunging into mangrove swamps on French Guiana's coast.

http://www.centennialofflight.gov/essay/SPACEFLIGHT/ariane/SP42.htm

] After Arianespace engineers rewrote the rocket's control software,
] the second Ariane-5 launch successfully took place on October 30,
] 1997. More launches followed and the rocket soon entered full commercial
] service, although it suffered another failure on its tenth launch in July
2001.
] Ariane-5 joined the Russian Proton, American Titan IV and Japanese
] H-IIA as the most powerful rockets in service. Ariane-5 initially had a
very
] high vehicle cost, but Arianespace mounted an aggressive campaign to
] significantly reduce this cost and make the rocket more cost-effective.
The
] company also planned further upgrades to the Ariane-5 to enable it to
remain
] competitive against a growing number of competitors.

http://www.chron.com/cgi-bin/auth/story.mpl/content/interactive/space/news/9

9/990824.html
] Each launch of Japan's flagship H-2 rocket to place a satellite into
] geostationary orbit costs close to 19 billion yen, about double the cost
] of competitors such as the European Space Agency's Ariane rocket.
(19 billion yen ~ $190 million => ~$100million for geostationary orbit on
Ariane)

] Part of the six-billion European-Currency-Unit ($6.28 billion U.S.) cost
of
] the Ariane 5 project went toward construction of new facilities at ESA's
Kourou,
] French Guiana launch complex

http://www.rte.ie/news/2002/1212/satellite.html

] It is the fourth failure of an Ariane-5 in its 14-mission history, and is
] being seen as a major setback for the European space programme.
See also

http://www.dw-world.de/english/0,3367,1446_A_713425,00.html

] the problem occurred in the cooling circuit of one of the rocket's main
] engines. A change in engine speed around 180 seconds after take-off
] caused the launcher to "demonstrat e erratic behaviour".

[Adrian Hey]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:
[color=blue]
> Adrian Hey wrote:[color=green]
>> I've been using statically typed FPL's for a
>> good few years now, and I can only think of one occasion where I had
>> "good" code rejected by the type checker (and even then the work around
>> was trivial). All other occasions it was telling me my programs were
>> broken (and where they were broken), without me having to test it.
>>
>> This is good thing.[/color]
>
> Maybe you haven't written the kind of programs yet that a static type
> system can't handle.[/color]

Your right, I haven't. I would say the overwhelming majority of programs
"out there" fall into this category. I am aware that some situations are
difficult to handle in a statically typed language. An obvious example
in Haskell would be trying to type a function which interpreted strings
representing arbitrary haskell expressions and returned their value..

eval :: String -> ??

If this situation is to be dealt with at all, some kind of dynamic
type system seems necessary. I don't think anybody is denying that
(certainly not me).
[color=blue][color=green]
>> As for dynamics, I don't think anybody would deny the usefulness of a
>> dynamic type system as a *supplement to* the static type system.[/color]
>
> I don't deny that static type systems can be a useful supplement to a
> dynamic type system in certain contexts.[/color]

I don't think anybody who read your posts would get that impression :-)
[color=blue]
> There is an important class of programs - those that can reason about
> themselves and can change themselves at runtime - that cannot be
> statically checked.[/color]

Yes indeed. Even your common or garden OS falls into this category I
think, but that doesn't mean you can't statically type check individual
fragments of code (programs) that run under that OS. It just means
you can't statically type check the entire system (OS + application
programs).
[color=blue]
> Your claim implies that such code should not be written,[/color]

What claim? I guess you mean the one about dynamic typing being a
useful supplement to, but not a substitute for, static typing.

If so, I don't think it implies that at all.
[color=blue]
> at least not "most of the time" (whatever that means).[/color]

Dunno who you're quoting there, but it isn't me.
[color=blue]
> Why? Maybe I am missing an important insight about such programs
> that you have.[/color]

Possibly, but it seems more likely that you are simply misrepresenting
what I (and others) have written in order to create a straw man to demolish.

Regards
--
Adrian Hey

[Pascal Costanza]

Re: Static typing

Dirk Thierbach wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> wrote:
>[/color]
[color=blue][color=green]
>>I have given reasons when not to use a static type system in this
>>thread.[/color]
>
>
> Nobody forces you to use a static type system. Languages, with their
> associated type systems, are *tools*, and not religions. You use
> what is best for the job.[/color]

_exactly!_

That's all I have been trying to say in this whole thread.

Marshall Spight asked

http://groups.google.com/groups?selm=MoEkb.821534%24YN5.832338%40sccrnsc01

why one would not want to use a static type system, and I have tried to
give some reasons.

I am not trying to force anyone to use a dynamically checked language. I
am not even trying to convince anyone. I am just trying to say that
someone might have very good reasons if they didn't want to use a static
type system.
[color=blue][color=green]
>>Please take a look at the Smalltalk MOP or the CLOS MOP and tell
>>me what a static type system should look like for these languages![/color]
>
>
> You cannot take an arbitrary language and attach a good static type
> system to it. Type inference will be much to difficult, for example.
> There's a fine balance between language design and a good type system
> that works well with it.[/color]

Right. As I said before, you need to reduce the expressive power of the
language.
[color=blue]
> If you want to use Smalltalk or CLOS with dynamic typing and unit
> tests, use them. If you want to use Haskell or OCaml with static typing
> and type inference, use them. None is really "better" than the other.
> Both have their advantages and disadvantages. But don't dismiss
> one of them just because you don't know better.[/color]

dito

Thank you for rephrasing this in a probably better understandable way.

Pascal

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

Matthias Blume <find@my.addres s.elsewhere> writes:
[color=blue]
> In fact, you should never need to "solve the halting problem" in order
> to statically check you program. After all, the programmer *already
> has a proof* in her mind when she writes the code! All that's needed
> (:-) is for her to provide enough hints as to what that proof is so
> that the compiler can verify it. (The smiley is there because, as we
> are all poinfully aware of, this is much easier said than done.)[/color]


I'm having trouble proving that MYSTERY returns T for lists of finite
length. I an idea that it would but now I'm not sure. Can the
compiler verify it?

(defun kernel (s i)
(list (not (car s))
(if (car s)
(cadr s)
(cons i (cadr s)))
(cons 'y (cons i (cons 'z (caddr s))))))

(defconstant k0 '(t () (x)))

(defun mystery (list)
(let ((result (reduce #'kernel list :initial-value k0)))
(cond ((null (cadr result)))
((car result) (mystery (cadr result)))
(t (mystery (caddr result))))))

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Andreas Rossberg wrote:
[color=blue]
> Pascal Costanza wrote:
>[color=green][color=darkred]
>>>
>>> My copy,
>>>
>>> http://research.microsoft.com/Users/...Systems.A4.pdf
>>>
>>> on page 3 defines safety as orthogonal to typing in the way Matthias
>>> suggested.[/color]
>>
>>
>> Yes, but it says dynamically typed vs statically typed where Matthias
>> says untyped vs typed.[/color]
>
>
> Huh? On page 2 Cardelli defines typed vs. untyped. Table 1 on page 5
> clearly identifies Lisp as an untyped (but safe) language. He also
> speaks of statical vs. dynamical _checking_ wrt safety, but where do you
> find a definition of dynamic typing?[/color]

Hmm, maybe I was wrong. I will need to check that again - it was some
time ago that I have read the paper. Oh dear, I am getting old. ;)

Thanks for pointing this out.


Pascal

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Adrian Hey wrote:
[color=blue]
> Your right, I haven't. I would say the overwhelming majority of programs
> "out there" fall into this category.[/color]

Do you have empirical evidence for this statement? Maybe your sample set
is not representative?
[color=blue][color=green][color=darkred]
>>>As for dynamics, I don't think anybody would deny the usefulness of a
>>>dynamic type system as a *supplement to* the static type system.[/color]
>>
>>I don't deny that static type systems can be a useful supplement to a
>>dynamic type system in certain contexts.[/color]
>
>
> I don't think anybody who read your posts would get that impression :-)[/color]

Well, then they don't read close enough. In my very posting wrt to this
topic, I have suggested soft typing as a good compromise. See

http://groups.google.com/groups?selm=bn687n%24l6u%241%40f1node01.rhrz.uni-bonn.de

Yes, you can certainly tell that I am a fan of dynamic type systems. So
what? Someone has asked why one would want to get rid of a static type
system, and I am responding.

(Thanks for the smiley. ;)
[color=blue][color=green]
>>Your claim implies that such code should not be written,[/color]
>
>
> What claim?[/color]

"Most code [...] should be [...] checked for type errors at compile time."

[color=blue][color=green]
>>at least not "most of the time" (whatever that means).[/color]
>
>
> Dunno who you're quoting there, but it isn't me.[/color]


Pascal