Python from Wise Guy's Viewpoint

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:[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?
>
> But why should more regression testing mean less static type checking?
> Both are useful. Both catch bugs. Why ditch one for the other?[/color]

....because static type systems work by reducing the expressive power of
a language. It can't be any different for a strict static type system.
You can't solve the halting problem in a general-purpose language.

This means that eventually you might need to work around language
restrictions, and this introduces new potential sources for bugs.

(Now you could argue that current sophisticated type systems cover 90%
of all cases and that this is good enough, but then I would ask you for
empirical studies that back this claim. ;)

I think soft typing is a good compromise, because it is a mere add-on to
an otherwise dynamically typed language, and it allows programmers to
override the decisions of the static type system when they know better.


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)

[Garry Hodgson]

Re: Re: Python from Wise Guy's Viewpoint

Pascal Bourguignon <spam@thalassa. informatimago.c om> wrote:
[color=blue]
> You're right, I did not answer. I think that what is missing in
> classic software, and that ought to be present in AI software, is some
> introspective control: having a process checking that the other
> processes are live and progressing, and able to act to correct any
> infinite loop, break down or dead-lock.[/color]

so assume this AI software was running on Ariane 5, and the same
condition occurs. based on the previously referenced design
assumptions, it is told that there's been a hardware failure, and that
numerical calculations can no longer be trusted. how does it cope
with this?
[color=blue]
> Some hardware may help in
> controling this controling software, like on the latest Macintosh:
> they automatically restart when the system is hung.[/color]

in this case, a restart would cause the same calculations to occur,
and the same failure to be reported.
[color=blue]
> And purely at the
> hardware level, for a real life system, you can't rely on only one
> processor.[/color]

absolutely right. though, in this case, this wouldn't have helped either.

the fatal error was a process error, and it occurred long before launch.

----
Garry Hodgson, Technology Consultant, AT&T Labs

Be happy for this moment.
This moment is your life.

[William Lovas]

Re: Python from Wise Guy's Viewpoint

In article <bn687n$l6u$1@f 1node01.rhrz.un i-bonn.de>, Pascal Costanza wrote:[color=blue]
> Marshall Spight wrote:[color=green]
>> But why should more regression testing mean less static type checking?
>> Both are useful. Both catch bugs. Why ditch one for the other?[/color]
>
> ...because static type systems work by reducing the expressive power of
> a language. It can't be any different for a strict static type system.
> You can't solve the halting problem in a general-purpose language.[/color]

What do you mean by "reducing the expressive power of the language"? There
are many general purpose statically typed programming languages that are
Turing complete, so it's not a theoretical consideration, as you allude.
[color=blue]
> This means that eventually you might need to work around language
> restrictions, and this introduces new potential sources for bugs.
>
> (Now you could argue that current sophisticated type systems cover 90%
> of all cases and that this is good enough, but then I would ask you for
> empirical studies that back this claim. ;)[/color]

Empirically, i write a lot of O'Caml code, and i never have to write
something in a non-intuitive manner to work around the type system. On the
contrary, every type error the compiler catches in my code indicates code
that *doesn't make sense*. I'd hate to imagine code that doesn't make
sense passing into regression testing. What if i forget to test a
non-sensical condition?

On the flip-side of the coin, i've also written large chunks of Scheme
code, and I *did* find myself making lots of nonsense errors that weren't
caught until run time, which significantly increased development time
and difficulty.

Furthermore, thinking about types during the development process keeps me
honest: i'm much more likely to write code that works if i've spent some
time understanding the problem and the types involved. This sort of
pre-development thinking helps to *eliminate* potential sources for bugs,
not introduce them. Even Scheme advocates encourage this (as in Essentials
of Programming Languages by Friedman, Wand, and Haynes).
[color=blue]
> I think soft typing is a good compromise, because it is a mere add-on to
> an otherwise dynamically typed language, and it allows programmers to
> override the decisions of the static type system when they know better.[/color]

When do programmers know better? An int is an int and a string is a
string, and nary the twain shall be treated the same. I would rather
``1 + "bar"'' signal an error at compile time than at run time.

Personally, i don't understand all this bally-hoo about "dynamic languages"
being the next great leap. Static typing is a luxury!

William

[Andrew Dalke]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza:[color=blue]
> ...because static type systems work by reducing the expressive power of
> a language. It can't be any different for a strict static type system.
> You can't solve the halting problem in a general-purpose language.
>
> This means that eventually you might need to work around language
> restrictions, and this introduces new potential sources for bugs.[/color]

Given what I know of embedded systems, I can effectively
guarantee you that all the code on the rocket was proven
to halt in not only a finite amount of time but a fixed amount of
time.

So while what you say may be true for a general purpose
language, that appeal to the halting problem doesn't apply given
a hard real time constraint.

Andrew
dalke@dalkescie ntific.com

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> ...because static type systems work by reducing the expressive power
> of a language.[/color]

It depends a whole lot on what you consider "expressive ". In my book,
static type systems (at least some of them) work by increasing the
expressive power of the language because they let me express certain
intended invariants in a way that a compiler can check (and enforce!)
statically, thereby expediting the discovery of problems by shortening
the edit-compile-run-debug cycle.
[color=blue]
> (Now you could argue that current sophisticated type systems cover 90%
> of all cases and that this is good enough, but then I would ask you
> for empirical studies that back this claim. ;)[/color]

In my own experience they seem to cover at least 99%.

(And where are _your_ empirical studies which show that "working around
language restrictions increases the potential for bugs"?)

Matthias

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

William Lovas <wlovas@force.s twing.upenn.edu > writes:
[color=blue]
> [...] Static typing is a luxury![/color]

Very well put!

[Pascal Bourguignon]

Re: Python from Wise Guy's Viewpoint

Garry Hodgson <garry@sage.att .com> writes:
[color=blue]
> Pascal Bourguignon <spam@thalassa. informatimago.c om> wrote:
>[color=green]
> > You're right, I did not answer. I think that what is missing in
> > classic software, and that ought to be present in AI software, is some
> > introspective control: having a process checking that the other
> > processes are live and progressing, and able to act to correct any
> > infinite loop, break down or dead-lock.[/color]
>
> so assume this AI software was running on Ariane 5, and the same
> condition occurs. based on the previously referenced design
> assumptions, it is told that there's been a hardware failure, and that
> numerical calculations can no longer be trusted. how does it cope
> with this?[/color]

I just read yesterday an old paper by Sussman about how they designed
a Lisp on a chip, including the garbage collector and the eval
function. Strangely enough that did not included any ALU (only a test
for zero and an incrementer, for address scanning).

You can implement an eval without arithmetic and you can implement
theorem prover above it still without arithmetic. You can still do a
great deal of thinking without any arithmetic...

[color=blue][color=green]
> > Some hardware may help in
> > controling this controling software, like on the latest Macintosh:
> > they automatically restart when the system is hung.[/color]
>
> in this case, a restart would cause the same calculations to occur,
> and the same failure to be reported.[/color]

In this case, since the problem was not in the supposed AI controlling
agent, there would have been no restart.

[color=blue][color=green]
> > And purely at the
> > hardware level, for a real life system, you can't rely on only one
> > processor.[/color]
>
> absolutely right. though, in this case, this wouldn't have helped either.
> the fatal error was a process error, and it occurred long before launch.[/color]

I think it would have been helped. For example, an architecture like
the Shuttle's where there are five computer differently programmed
would have helped, because at least one of the computers would not
have had the Ariane-4 module.

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

William Lovas wrote:
[color=blue]
> In article <bn687n$l6u$1@f 1node01.rhrz.un i-bonn.de>, Pascal Costanza wrote:
>[color=green]
>>Marshall Spight wrote:
>>[color=darkred]
>>>But why should more regression testing mean less static type checking?
>>>Both are useful. Both catch bugs. Why ditch one for the other?[/color]
>>
>>...because static type systems work by reducing the expressive power of
>>a language. It can't be any different for a strict static type system.
>>You can't solve the halting problem in a general-purpose language.[/color]
>
> What do you mean by "reducing the expressive power of the language"? There
> are many general purpose statically typed programming languages that are
> Turing complete, so it's not a theoretical consideration, as you allude.[/color]

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.
[color=blue][color=green]
>>This means that eventually you might need to work around language
>>restriction s, and this introduces new potential sources for bugs.
>>
>>(Now you could argue that current sophisticated type systems cover 90%
>>of all cases and that this is good enough, but then I would ask you for
>>empirical studies that back this claim. ;)[/color]
>
> Empirically, i write a lot of O'Caml code, and i never have to write
> something in a non-intuitive manner to work around the type system. On the
> contrary, every type error the compiler catches in my code indicates code
> that *doesn't make sense*. I'd hate to imagine code that doesn't make
> sense passing into regression testing. What if i forget to test a
> non-sensical condition?[/color]

You need some testing discipline, which is supported well by unit
testing frameworks.
[color=blue]
> On the flip-side of the coin, i've also written large chunks of Scheme
> code, and I *did* find myself making lots of nonsense errors that weren't
> caught until run time, which significantly increased development time
> and difficulty.
>
> Furthermore, thinking about types during the development process keeps me
> honest: i'm much more likely to write code that works if i've spent some
> time understanding the problem and the types involved. This sort of
> pre-development thinking helps to *eliminate* potential sources for bugs,
> not introduce them. Even Scheme advocates encourage this (as in Essentials
> of Programming Languages by Friedman, Wand, and Haynes).[/color]

Yes, thinking about a problem to understand it better occasionally helps
to write better code. This has nothing to do with static typing. This
could also be achieved by placing some other arbitrary restrictions on
your coding style.
[color=blue][color=green]
>>I think soft typing is a good compromise, because it is a mere add-on to
>>an otherwise dynamically typed language, and it allows programmers to
>>override the decisions of the static type system when they know better.[/color]
>
> When do programmers know better? An int is an int and a string is a
> string, and nary the twain shall be treated the same. I would rather
> ``1 + "bar"'' signal an error at compile time than at run time.[/color]

Such code would easily be caught very soon in your unit tests.


Pascal

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

Pascal Bourguignon wrote:[color=blue]
> [...] For example, an architecture like
> the Shuttle's where there are five computer differently programmed
> would have helped, because at least one of the computers would not
> have had the Ariane-4 module.[/color]

Even the Ariane team is working under budget constraints. Obviously, in
this case, the budget didn't allow a re-check of the SRI design wrt.
Ariane-5 specifications, much less programming the same software five(!)
times over.

Besides, programming the same software multiple times would have helped
regardless of whether you're doing it with an AI or traditionally. I
still don't see how AI could have helped prevent the Ariane-5 crash. As
far as I have seen, any advances in making chips or programs smarter
have consistently been offset by higher testing efforts: you still have
to formally specify what the system is supposed to do, and then test
against that specification.
Actually, AI wouldn't have helped in the least bit here: the
specification was wrong, so even an AI module, at whatever
sophistication level, wouldn't have worked.

The only difference is that AI might allow people to write higher-level
specifications. I.e. something like "the rocket must be stable" instead
of "the rocket must not deviate more than 12.4 degrees from the
vertical"... but even "the rocket must be stable" would have to be
broken down into much more technical terms, with leeway for much the
same design and specification errors as those that caused the Ariane-5
software to lose control.

Regards,
Jo

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Andrew Dalke wrote:
[color=blue]
> Pascal Costanza:
>[color=green]
>>...because static type systems work by reducing the expressive power of
>>a language. It can't be any different for a strict static type system.
>>You can't solve the halting problem in a general-purpose language.
>>
>>This means that eventually you might need to work around language
>>restriction s, and this introduces new potential sources for bugs.[/color]
>
>
> Given what I know of embedded systems, I can effectively
> guarantee you that all the code on the rocket was proven
> to halt in not only a finite amount of time but a fixed amount of
> time.[/color]

Yes, this is a useful restriction for a certian scenario. I don't have
anything against restrictions put on code, provided these restrictions
are justified.

Static type systems are claimed to generally improve your code. I don't
see that.


Pascal

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
>Marshall Spight wrote:[color=green]
>> But why should more regression testing mean less static type checking?
>> Both are useful. Both catch bugs. Why ditch one for the other?[/color]
>
>...because static type systems work by reducing the expressive power of
>a language. It can't be any different for a strict static type system.
>You can't solve the halting problem in a general-purpose language.[/color]

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. Sometimes you need a bit more flexibility than the
static type system allows, and then in those few cases, you can make use
of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
"System.Obj ect" in C#, etc.). The need to do this is not uncommon
in languages like C# and Java that don't support parametric polymorphism,
but pretty rare in languages that do.
[color=blue]
>I think soft typing is a good compromise, because it is a mere add-on to
>an otherwise dynamically typed language, and it allows programmers to
>override the decisions of the static type system when they know better.[/color]

Soft typing systems give you dynamic typing unless you explicitly ask
for static typing. That is the wrong default, IMHO. It works much
better to add dynamic typing to a statically typed language than the
other way around.

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

Matthias Blume wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>...because static type systems work by reducing the expressive power
>>of a language.[/color]
>
>
> It depends a whole lot on what you consider "expressive ". In my book,
> static type systems (at least some of them) work by increasing the
> expressive power of the language because they let me express certain
> intended invariants in a way that a compiler can check (and enforce!)
> statically, thereby expediting the discovery of problems by shortening
> the edit-compile-run-debug cycle.[/color]

The set of programs that are useful but cannot be checked by a static
type system is by definition bigger than the set of useful programs that
can be statically checked. So dynamically typed languages allow me to
express more useful programs than statically typed languages.
[color=blue][color=green]
>>(Now you could argue that current sophisticated type systems cover 90%
>>of all cases and that this is good enough, but then I would ask you
>>for empirical studies that back this claim. ;)[/color]
>
> In my own experience they seem to cover at least 99%.[/color]

I don't question that. If this works well for you, keep it up. ;)
[color=blue]
> (And where are _your_ empirical studies which show that "working around
> language restrictions increases the potential for bugs"?)[/color]

I don't need a study for that statement because it's a simple argument:
if the language doesn't allow me to express something in a direct way,
but requires me to write considerably more code then I have considerably
more opportunities for making mistakes.


Pascal

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza wrote:[color=blue]
> ....because static type systems work by reducing the expressive power of
> a language. It can't be any different for a strict static type system.
> You can't solve the halting problem in a general-purpose language.[/color]

The final statement is correct, but you don't need to solve the halting
problem: it's enough to allow the specification of some easy-to-prove
properties, without hindering the programmer too much.

Most functional languages with a static type system don't require that
the programmer writes down the types, they are inferred from usage. And
the type checker will complain as soon as the usage of some data item is
inconsistent.
IOW if you write
a = b + "asdf"
the type checker will infer that both a and b are strings; however, if
you continue with
c = a + b + 3
it will report a type error because 3 and "adsf" don't have a common
supertype with a "+" operation.

It's the best of both worlds: no fuss with type declarations (which is
one of the less interesting things one spends time with) while getting
good static checking.
(Nothing is as good in practice as it sounds in theory, and type
inference is no exception. Interpreting type error messages requires
some getting used to - just like interpreting syntax error messages is a
bit of an art, leaving one confounded for a while until one "gets it".)
[color=blue]
> (Now you could argue that current sophisticated type systems cover 90%
> of all cases and that this is good enough, but then I would ask you for
> empirical studies that back this claim. ;)[/color]

My 100% subjective private study reveals not a single complaint about
over-restrictive type systems in comp.lang.funct ional in the last 12 months.

Regards,
Jo

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Fergus Henderson wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>Marshall Spight wrote:
>>[color=darkred]
>>>But why should more regression testing mean less static type checking?
>>>Both are useful. Both catch bugs. Why ditch one for the other?[/color]
>>
>>...because static type systems work by reducing the expressive power of
>>a language. It can't be any different for a strict static type system.
>>You can't solve the halting problem in a general-purpose language.[/color]
>
>
> 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
specification stage. 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.

+ Documentation: Comments are usually better for handling documentation.
;) If you want your "comments" checked, you can add assertions.

+ Error checking: I can only guess what you mean by this. If you mean
something like Java's checked exceptions, there are clear signs that
this is a very bad feature.

+ 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=blue]
> Sometimes you need a bit more flexibility than the
> static type system allows, and then in those few cases, you can make use
> of dynamic typing ("univ" in Mercury, "Dynamic" in ghc,
> "System.Obj ect" in C#, etc.). The need to do this is not uncommon
> in languages like C# and Java that don't support parametric polymorphism,
> but pretty rare in languages that do.[/color]

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=blue][color=green]
>>I think soft typing is a good compromise, because it is a mere add-on to
>>an otherwise dynamically typed language, and it allows programmers to
>>override the decisions of the static type system when they know better.[/color]
>
> Soft typing systems give you dynamic typing unless you explicitly ask
> for static typing. That is the wrong default, IMHO. It works much
> better to add dynamic typing to a statically typed language than the
> other way around.[/color]

I don't think so.


Pascal

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz wrote:
[color=blue]
> Most functional languages with a static type system don't require that
> the programmer writes down the types, they are inferred from usage. And
> the type checker will complain as soon as the usage of some data item is
> inconsistent.[/color]

I know about type inference. The set of programs that can be checked
with type inference is still a subset of all useful programs.
[color=blue]
> My 100% subjective private study reveals not a single complaint about
> over-restrictive type systems in comp.lang.funct ional in the last 12
> months.[/color]

I am not surprised. :)


Pascal