Python from Wise Guy's Viewpoint

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Matthias Blume wrote:
[color=blue][color=green]
>>we both don't have the necessary empirical data to back our claims)[/color]
>
>
> Speak for yourself.[/color]

You too.


This:
[color=blue]
> I have worked on projects where people worried about *every cycle*.[/color]
^^^^^^^^
[color=blue]
> (Most of the time I agree with you, though. Still, using infinite
> precision by default is, IMO, a mistake. Having it around and at your[/color]
^^^^^^
[color=blue]
> fingertips, though, is nice. That's why I added the long-missing
> compiler support for IntInf to SML/NJ recently.)[/color]

is by any scientifical standard not enough evidence to back this:
[color=blue]
> The problem
> is that for many algorithms people want to be sure that the compiler
> represents their values in machine words. Infinite precision is
> needed sometimes, but in the majority of cases it is overkill. If you
> need infinite precision, specify the type (IntInf.int in SML's case).
> A clever compiler might optimize that like a Lisp compiler does. In
> most other cases, why take any chances?[/color]


Pascal

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Matthias Blume wrote:
>[color=green]
> > Pascal Costanza <costanza@web.d e> writes:[/color]
>[color=green][color=darkred]
> >>I think that Neelakantan has better examples for programs that are
> >>possible to write with a statically typed language, but not with
> >>dynamically typed ones. (Not 100% sure yet, though.)[/color]
> > There are no such programs, obviously. You can always translate a[/color]
>[color=green]
> > statically typed program into a dynamically typed one (and vice
> > versa).[/color]
>
> No, for christ's sake! There are dynamically typed programs that you
> cannot translate into statically typed ones![/color]

Yes you can. (In the worst case scenario you lose all the benefits of
static typing. But a translation is *always* possible. After all,
dynamically typed programs are already statically typed in the trival
"one type fits all" sense.)
[color=blue]
> Yes, these things are all obvious. But these are not examples for an
> increase of expressive power! These are only examples of _restricting_
> the set of potentially useful programs! How hard is this to
> understand?
>
> You _want_ this restriction. Why don't you _admit_ that it is a restriction?[/color]

Who said that I don't admit that I want restrictions. That's the
whole point. Static typing increases my expressive power because I
can now *express restrictions* which I couldn't express before.
That's the whole point. Being able to express more programs is not
the issue, being able to express more restrictions and being told
early about their violations is!

[This whole discussion is entirely due to a mismatch of our notions of
what constitutes expressive power.]

Matthias

[Daniel C. Wang]

Re: Python from Wise Guy's Viewpoint


Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Matthias Blume wrote:
>[color=green]
> > The problem
> > is that for many algorithms people want to be sure that the compiler
> > represents their values in machine words. Infinite precision is
> > needed sometimes, but in the majority of cases it is overkill. If you
> > need infinite precision, specify the type (IntInf.int in SML's case).
> > A clever compiler might optimize that like a Lisp compiler does. In
> > most other cases, why take any chances?[/color]
>
> I disagree strongly here. I am convinced that in most algorithms,
> machine words don't matter at all. Have you ever seen in books on
> algorithms that they actually _need_ to restrict them to values that
> are representable in machine word sizes?
>[/color]

Hmmm.. lets see... AES and MD5 most if not all DSP/ signal processing
algorithms. There are quite a few.

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Matthias Blume wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>Matthias Blume wrote:
>>
>>[color=darkred]
>>>Pascal Costanza <costanza@web.d e> writes:[/color]
>>[color=darkred]
>>>>I think that Neelakantan has better examples for programs that are
>>>>possible to write with a statically typed language, but not with
>>>>dynamical ly typed ones. (Not 100% sure yet, though.)
>>>
>>>There are no such programs, obviously. You can always translate a[/color]
>>[color=darkred]
>>>statically typed program into a dynamically typed one (and vice
>>>versa).[/color]
>>
>>No, for christ's sake! There are dynamically typed programs that you
>>cannot translate into statically typed ones![/color]
>
>
> Yes you can. (In the worst case scenario you lose all the benefits of
> static typing. But a translation is *always* possible. After all,
> dynamically typed programs are already statically typed in the trival
> "one type fits all" sense.)[/color]

No, that's not all you need to do. Essentially you would need to write a
complete interpreter/compiler for the dynamically typed language on top
of the statically typed one, _if_ you want runtime metaprogramming .
That's not what I would call a straightforward translation.

But this is really getting tiring.
[color=blue]
> [This whole discussion is entirely due to a mismatch of our notions of
> what constitutes expressive power.][/color]

No, it's not. There's a class of programs that exhibit a certain
behavior at runtime that you cannot write in a statically typed language
_directly in the language itself_. There's no program that exhibits a
certain behavior at runtime that you can only write in a statically
typed language. [1]

That's a fact that you simply don't want to admit. But you're
objectively wrong here.

However, the horse is beaten to death by now.


Good bye.

Pascal

[11 Except perhaps for a class of programs that would change their
runtime and/or space complexity, provided they would need lots of
dynamic type checks. But I haven't sorted out yet whether this class
really exists.

[Jens Axel Søgaard]

Re: Python from Wise Guy's Viewpoint

Daniel C. Wang wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> writes:[/color]
[color=blue][color=green]
>>I disagree strongly here. I am convinced that in most algorithms,
>>machine words don't matter at all. Have you ever seen in books on
>>algorithms that they actually _need_ to restrict them to values that
>>are representable in machine word sizes?[/color][/color]
[color=blue]
> Hmmm.. lets see... AES and MD5 most if not all DSP/ signal processing
> algorithms. There are quite a few.[/color]

It's true that they are specified such that particularly efficient
implementations exists on machines with the proper word size. This
holds for many crypthographic algorithms.

This doesn't rule out other implementations though.

<Shame less self plug

<http://www.scheme.dk/md5/md5.html>

/>
--
Jens Axel Søgaard

[Stephen J. Bevan]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:[color=blue][color=green]
> > Perhaps I'm just a low tech kind of guy but if I just want to run the
> > first ten then I comment out the rest. Even without a fancy IDE that
> > only take a few key presses.[/color]
>
> ...and it requires you to go to all the places where they are defined.
>
> Yes, I know the answer: "But they should be all in one place." No,
> they shouldn't need to be all in one place.[/color]

As I wrote, I'm a low tech guy, I put all the tests for a particular
feature in the same file. If I only want to run some of the tests in
the file then I comment out those tests. If I only want to run the
tests in some file rather than others then I comment out the names of
the files containing the tests I don't want to run. I can see how
things can get more complicated if you use other approaches, which is
one of the reasons I don't use those approaches. YMMV.

[color=blue]
> Ah, another example: What if my test code is actually produced by some
> macro, or some other code generation facility?[/color]

Er, comment out either definition of the macro and the calls to it or
the code generation facility.

[Stephen J. Bevan]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:[color=blue][color=green]
> > is that for many algorithms people want to be sure that the compiler
> > represents their values in machine words. Infinite precision is
> > needed sometimes, but in the majority of cases it is overkill. If you
> > need infinite precision, specify the type (IntInf.int in SML's case).
> > A clever compiler might optimize that like a Lisp compiler does. In
> > most other cases, why take any chances?[/color]
>
> I disagree strongly here. I am convinced that in most algorithms,
> machine words don't matter at all. Have you ever seen in books on
> algorithms that they actually _need_ to restrict them to values that
> are representable in machine word sizes?
> [snip]
> Computers are fast enough and have enough memory nowadays. You are
> talking about micro efficiency. That's not interesting anymore.[/color]

Implement something like MD5, SHA-1, AES, ... etc. in your favourite
language and use the fastest compiler available to you to calculate
how many MB/s it can process. If it can get say with a factor of 2 of
C code then IMHO you'll have proved your point. If not, then either
your point stands but your favourite language doesn't have
sufficiently good compilers available yet, or exact sizes are required
in order to get good performance in this case.

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:
[color=blue]
> Matthias Blume wrote:
>[color=green][color=darkred]
> >>we both don't have the necessary empirical data to back our claims)[/color]
> > Speak for yourself.[/color]
>
> You too.[/color]

I am.
[color=blue]
>
>
> This:
>[color=green]
> > I have worked on projects where people worried about *every cycle*.[/color]
> ^^^^^^^^
>[color=green]
> > (Most of the time I agree with you, though. Still, using infinite
> > precision by default is, IMO, a mistake. Having it around and at your[/color]
> ^^^^^^
>[color=green]
> > fingertips, though, is nice. That's why I added the long-missing
> > compiler support for IntInf to SML/NJ recently.)[/color]
>
> is by any scientifical standard not enough evidence to back this:[/color]

It is more than enough evidence that there are programs which require
cycle-level efficiency and therefore cannot afford to use infinite
precision arithmetic.

It is, in my opinion, ridiculous to claim that most programs should
use infinite precision integers in almost all places (i.e., by
default). Infinite precision is rarely necessary and almost always
wasteful overkill.

And in any case, it is also completely besides the point in the
discussion of static checking vs. everything dynamic. (It just came
up as a side discussion after Andreas gave an example of ML code which
exhibits different semantics in different typing contexts -- a
discussion which seems to circle around the extremely questionable
idea that the only correct result of 20 * 30 has to be 600.)

Matthias

[Raffael Cavallaro]

Re: Python from Wise Guy's Viewpoint

Matthias Blume <find@my.addres s.elsewhere> wrote in message news:<m11xsx2ai u.fsf@tti5.uchi cago.edu>...

[color=blue][color=green][color=darkred]
> > > Pascal Costanza <costanza@web.d e> writes:[/color]
> > No, for christ's sake! There are dynamically typed programs that you
> > cannot translate into statically typed ones![/color]
>
> Yes you can. (In the worst case scenario you lose all the benefits of
> static typing. But a translation is *always* possible. After all,
> dynamically typed programs are already statically typed in the trival
> "one type fits all" sense.)[/color]

This is sophistry at its worst. If you "translate" a dynamically typed
program into a statically typed language by eliminating all the static
type checking, then WTF is the point of the static type checking?

It's also possible to "translate" any program into a turing machine
tape, so we should all start coding that way!

Introducing TuringTape(TM), the ultimate bondage and discipline
language!

[Raffael Cavallaro]

Re: Python from Wise Guy's Viewpoint

Matthias Blume <find@my.addres s.elsewhere> wrote in message news:<m11xsx2ai u.fsf@tti5.uchi cago.edu>...[color=blue]
> [This whole discussion is entirely due to a mismatch of our notions of
> what constitutes expressive power.][/color]

No, it is due to your desire to be type constrained inappropriately
early in the development process. Lispers know that early on, you
don't care about type constraints because you haven't settled on your
final data representations yet. So why waste time placating a
type-checking compiler before you have to?

With lisp, you only add as much type checking as you need, *when* you
need it.

With a statically typed language, you have to do the compiler type
check dance from the very first minute, even though you don't need to
solve the type constraint problems yet.

[Matthias Blume]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> writes:

[ on my claim that every dynamically typed program has a statically typed
translation: ][color=blue]
> No, that's not all you need to do. Essentially you would need to write
> a complete interpreter/compiler for the dynamically typed language on
> top of the statically typed one, _if_ you want runtime
> metaprogramming . That's not what I would call a straightforward
> translation.[/color]

Actually, I didn't say what I need, so how can you contradict me on
this point? Anyway, having to have a compiler/interpreter around is
only true if the original program contained a complete
compiler/interpreter, in which case I'd say this is just par for the
course.
[color=blue][color=green]
> > [This whole discussion is entirely due to a mismatch of our notions of
> > what constitutes expressive power.][/color]
>
> No, it's not. There's a class of programs that exhibit a certain
> behavior at runtime that you cannot write in a statically typed
> language _directly in the language itself_.[/color]

This is simply not true. See above.
[color=blue]
> There's no program that
> exhibits a certain behavior at runtime that you can only write in a
> statically typed language. [1][/color]

I do not dispute this fact.
[color=blue]
> [11 Except perhaps for a class of programs that would change their
> runtime and/or space complexity, provided they would need lots of
> dynamic type checks.[/color]

This comment makes me /very/ uneasy. Namely, the funny thing here
is that you seem to question a statement that you make /yourself/ even
though it is undoubtedly true. *Of course* you can write everything
that can be written in a statically typed language in a dynamically
typed language in such a way that runtime behavior is the same
(including complexity). Translating a well-typed ML program into,
say, Lisp is completely straightforward . (Early ML implementations
were done that way.)

The proof of type-safety for the original ML program also shows that
no additional runtime checks are needed for the result of the
translation. You don't even need the runtime checks that Lisp does on
its own because it doesn't know any better. (This is unless you turn
these checks off explicitly -- which in general would make the code
unsafe but in this specific case does not.)

So rest assured that the answer to your question:
[color=blue]
> But I haven't sorted out yet whether this class
> really exists.[/color]

is "no". But that was not my point anyway.

Matthias

PS: You don't need to try and convince me of the virtues of dynamic
typing. I *come* from this world -- having implemented at least three
(if not four -- depending on how you count) interpreters/compilers for
dynamically typed languages. Because of this I also already know all
the arguments that you are undoubtedly thinking of bringing forward,
having either used them myself or once marveled at them when I heard
them from other, then like-minded folks. But the long-term effect of
working with and on such systems was that I now prefer to avoid them.
"Run-time metaprogrammmin g" you say? The emperor has no clothes.

[Adrian Hey]

Re: Python from Wise Guy's Viewpoint

Raffael Cavallaro wrote:
[color=blue]
> Matthias Blume <find@my.addres s.elsewhere> wrote in message
> news:<m11xsx2ai u.fsf@tti5.uchi cago.edu>...
>
>[color=green][color=darkred]
>> > > Pascal Costanza <costanza@web.d e> writes:
>> > No, for christ's sake! There are dynamically typed programs that you
>> > cannot translate into statically typed ones![/color]
>>
>> Yes you can. (In the worst case scenario you lose all the benefits of
>> static typing. But a translation is *always* possible. After all,
>> dynamically typed programs are already statically typed in the trival
>> "one type fits all" sense.)[/color]
>
> This is sophistry at its worst. If you "translate" a dynamically typed
> program into a statically typed language by eliminating all the static
> type checking, then WTF is the point of the static type checking?[/color]

Read what he wrote..in particular the words *WORST CASE SCENARIO*

Regards
--
Adrian Hey

[Fergus Henderson]

Re: Test cases and static typing

Pascal Costanza <costanza@web.d e> writes:[color=blue]
>Fergus Henderson wrote:[color=green]
>> Pascal Costanza <costanza@web.d e> writes:[color=darkred]
>>>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.[/color]

True in the sense that "there exists a static type system that requires ...".
That is true for several static type systems that I know --
but the amount of extra code required is very very small.
E.g. in Haskell it is usually sufficient to just write

concretemethod = error "stub"

However, your statement would be false if you tried to generalize it to
all languages and language implementations that have static type systems.
As I said, it would be easy to modify a statically typed system to
optionally allow references to undefined functions, and indeed there
are some systems which do that. (For example I think ObjectCenter,
and interpretive environment for C/C++ programs, did that.)

If a couple of potential users of Mercury were to ask for it, I would
go ahead and add support for this to the Mercury implementation. But
so far, to the best of my knowledge, no Mercury user has ever asked for it.
[color=blue][color=green]
>> 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.[/color]

My experience is that compiler warnings are too easily ignored.

As for error highlighting in IDEs, well... Firstly, as you yourself
mentioned, not everyone wants to use a complicated IDE.

Secondly, even in such an IDE, I think errors could still slip through
unnoticed. For example, consider the following scenario. You might
write a call to a new function, which will get highlighted. But you
expect that, since the function is not yet defined so you ignore the
highlighting. Then you write another call to the function, which also
gets highlighted, and again you ignore it, since you expected that.
Finally you write the definition of the function, and run the program.
The compiler reports a few dozen warnings, which you ignore, since they
all seem to be referring to some undefined stubs in part of the program
that one of your colleagues is responsible for. Then you run a few tests,
which all work, so you check your change in to the shared repository and
go home for the weekend.

Your colleague, who is working all weekend to get things ready for an
important demo, does a cvs update and incorporates your change. But when
he runs _his_ test case, it now crashes with an error about
"undefined function 'tingamajig_han dler'"! He greps the source
for "tingamajig ", but the only occurrence is the one single place
where it is called, which happens to have absolutely no comments about
what it is supposed to do. In desparation, he tries calling you,
but your mobile phone's battery has run flat. He tries to implement
"tingamajig_han dler" himself, but has no idea of what invariants it
is supposed to enforce, and eventually gives up. The demo on Monday
morning is a complete failure.

On Monday afternoon, he finally catches up with you, and tells you of his
woes. You see immediately that the problem was just a simple typo --
the function was named "thingamajig_ha ndler", not "tingamajig_han dler".


A far-fetched hypothetical? Possibly. But if you tell us that
"typos don't go unnoticed", please forgive me if I am a little skeptical ;-)

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

[ketil+news@ii.uib.no]

Re: Python from Wise Guy's Viewpoint

Matthias Blume <find@my.addres s.elsewhere> writes:
[color=blue][color=green]
>> - 1 * 1.0;
>> val it = 1.0 : float (* ideally *)[/color][/color]
[color=blue]
> That's not "ideal" at all, to me. I find the automatic conversions in
> C a paint in the b*tt[/color]

You're making the mistake of comparing to C :-) And it's much worse
in C++, when conversions in conjunction with overloading can impact
which function gets called in non-obvious ways.

Anyway, I think Haskell makes this work better. Still no automatic
conversions, but more flexibility in the use of numeric literals.
Occasionally, you need to sprinkle "fromIntegr al"s around in
expressions, which I agree aren't terribly pretty.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

[Matthew Danish]

Re: Python from Wise Guy's Viewpoint

On Wed, Oct 29, 2003 at 04:20:01AM +0000, Matthias Blume wrote:[color=blue]
> It is more than enough evidence that there are programs which require
> cycle-level efficiency and therefore cannot afford to use infinite
> precision arithmetic.[/color]

Said programs will then use specialized data types.
[color=blue]
> It is, in my opinion, ridiculous to claim that most programs should
> use infinite precision integers in almost all places (i.e., by
> default). Infinite precision is rarely necessary and almost always
> wasteful overkill.[/color]

How is it wasteful? Numbers can still be represented by the most
efficient representation available, while retaining infinite precision
when operated upon. Do you realize that Common Lisp implementations
represent integers in the range of a fixnum as machine words? And
automatically convert them to bignum objects when they overflow?
Declarations can take this further, such that a compiler as smart as
CMUCL can manipulate raw (unsigned-byte 32) values, for example.

Are the vast majority of your programs the type which behave properly
within machine-word integers? Do they take into account the possibility
of overflow? Should someone have to worry about issues like overflow
when they just want to write a simple arithmetic program, in a high
level language?
[color=blue]
> idea that the only correct result of 20 * 30 has to be 600.)[/color]

(20 * 30) mod 256 is, of course, a completely different expression.

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