Optional Static Typing

[bearophileHUGS@lycos.com]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Boo (http://boo.codehaus.org/) is a different language, but I like its
"as" instead of ":" and "->", to have:
def min(a as iterable(T)) as T:
Instead of:
def min(a: iterable(T)) -> T:


Sometimes it can be useful to mix parts with static typing and parts
without it in the same module (because dynamic typing is very useful
sometimes), but some other times you want to be sure to have a full
typed and checked module. So maybe a kind of compiler directive (like
the # used to define encoding) can be used to define a module fully
typed and fully checked by a pychecker-like. (A module with static
typing can be very useful for a "true" python compiler too.)
Bear hugs,
bearophile

[Doug Holton]

Re: Optional Static Typing

bearophileHUGS@ lycos.com wrote:[color=blue]
> Adding Optional Static Typing to Python looks like a quite complex
> thing, but useful too:
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551[/color]

Thanks for pointing out that article by Guido van Rossum. Looks like it
just came out today. It is something that may be added to Python 3.0:

http://www.python.org/moin/Python3.0

[color=blue]
> Sometimes it can be useful to mix parts with static typing and parts
> without it in the same module (because dynamic typing is very useful
> sometimes), but some other times you want to be sure to have a full
> typed and checked module.[/color]

The closest option right now in CPython is to use Pyrex.

http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/

[color=blue]
> Boo (http://boo.codehaus.org/) is a different language, but I like its
> "as" instead of ":" and "->", to have:
> def min(a as iterable(T)) as T:
> Instead of:
> def min(a: iterable(T)) -> T:[/color]

Right, you're first example is how Boo does it, and the 2nd is how Guido
proposed to do it in Python 3.0.

Boo flips the problem around. Instead of optional static typing,
everything is statically typed by default (but with type inference so
you do not always need to explicitly declare the type), and it has
optional runtime typing that works like python's ("duck typing").

http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-2.boo?view=auto

http://svn.boo.codehaus.org/trunk/examples/duck-typing/XmlObject.boo?view=auto

http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-5.boo?view=auto

http://boo.codehaus.org/Duck+Typing

And there are some disadvantages to doing it this way. It means Python
is more flexible to use than Boo, as I stated a couple months back:

http://groups-beta.google.com/group/comp.lang.python/messages/c57cf0e48827f3de,a750c109b8ee57c3,cf89205a5e93051e,cfb1c7453e1f3c07,58a2dedd1059783e,8a1ee82cc328d023,7a51cdc9ffecbc72,38304f35cb42bb63,fc5e4ae1cbae0248,2de118caa7010b30?thread_id=5a7018d37b7bf4b8&mode=thread&noheader=1&q=boo+python-like#doc_7a51cdc9ffecbc72

[John Roth]

Re: Optional Static Typing


<bearophileHUGS @lycos.com> wrote in message
news:1103795375 .843649.286620@ c13g2000cwb.goo glegroups.com.. .[color=blue]
> Adding Optional Static Typing to Python looks like a quite complex
> thing, but useful too:
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551[/color]

One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.

I'm not convinced that it's all that effective at either objective.
My viewpoint on this is
that of someone who generally uses test first programming
(as in Test Driven Development or Extreme Programming).
Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more.

Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

This isn't to say TDD is the be-all and end-all of
correctness. Formal methods and formal inspections
both have very good reputations. In fact, the technique
with the best reputation is embodied in a sign that was
on the wall of every office of the old IBM: Think!

So let's look a bit deeper. As far as I remember, static
typing came out of the formal methods work in the '70s
by people like Djikstra, Hoar and Wirth (to name only
a few.) The thing is, if you properly use the formal program
derivation methods they advocated, then you don't need
it: your program will be as correct as it's possible to get
short of your being promoted to godhood.

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place. This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

So if the problem is reducing errors, then maybe
we should be working on the places where errors
show up.

Another point that's sometimes raised is that it's
useful to provide type information via reflection.
I used to think that was a valid concern until I
started work on PyFit. I had to put a rather
simplistic metadata facility into the program to
substitute for not having type information, and
I found that it was incredibly useful for other
things that you can't get from reflection on
type data.

John Roth
[color=blue]
> Bear hugs,
> bearophile
>[/color]

[Rocco Moretti]

Re: Optional Static Typing

John Roth wrote:[color=blue]
>
> One of the comments on Artima asks a rather profound
> question: static typing is an answer. What's the question?
> (That's a paraphrase.)
>
> The answer that everyone seems to give is that it
> prevents errors and clarifies the program.[/color]

<shrug> It might just be me, but I thought it was to simplify code
analysis and compilation. (That is, for the use of static typing in
general, not for Python in particular.)

Looking at C, it's doubtful error prevention and program clarification
was a serious objective in the static typing system. It's more
reasonable to conclude that C is statically typed because it allows the
compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular
variable, and to make sure the proper addition opcodes get put down.

Now whether this would be useful for Python is an open question.
[color=blue]
> Many of the supposed advantages simply aren't there
> when you go to the discipline of writing a test and then
> writing exactly the code needed to make the test pass, and
> not one keystroke more.[/color]
....[color=blue]
> This isn't to say TDD is the be-all and end-all of
> correctness.[/color]

Right. And unit tests don't do anything for people who don't use them.
The question is, should Guido state "TDD is the one true way to program
in Python.", or should concessions be made in the language design for
those who don't "drink the TDD Kool-aide".
[color=blue]
> So the conclusion here is that static typing is an attempt
> to make programming safe for people that shouldn't be
> programming in the first place.[/color]

I rebut it thusly: "elitist bastard." <wink and a half>

One of the draws of Python is that it's welcoming to newcomers and
programmers of all talents. You don't have to be an "uber-programmer" to
use it and use it well. Should we hobble it to suit poor programmers?
No. But that's no reason why it can't be made to be easier and safer to
use for the hobbyist when it doesn't compromise usefulness for the
power-programmer. (My opinion) Python shouldn't have a sign on the door
saying: "You must be this 'leet to enter."

Will static typing be a boon for Python? Is it necessary? Or is it the
trailhead on the road to Hades? <shrug> Only time will tell.

[bearophileHUGS@lycos.com]

Re: Optional Static Typing

Doug Holton:
[color=blue]
>And there are some disadvantages to doing it this way.
>It means Python is more flexible to use than Boo,[/color]
I've just suggested the *syntax* that I like more.

Bye,
Bearophile

[John Roth]

Re: Optional Static Typing


"Rocco Moretti" <roccomoretti@h otpop.com> wrote in message
news:cqf06r$g39 $1@news.doit.wi sc.edu...[color=blue]
> John Roth wrote:[color=green]
>> One of the comments on Artima asks a rather profound
>> question: static typing is an answer. What's the question?
>> (That's a paraphrase.)
>>
>> The answer that everyone seems to give is that it
>> prevents errors and clarifies the program.[/color]
>
> <shrug> It might just be me, but I thought it was to simplify code
> analysis and compilation. (That is, for the use of static typing in
> general, not for Python in particular.)
>
> Looking at C, it's doubtful error prevention and program clarification was
> a serious objective in the static typing system. It's more reasonable to
> conclude that C is statically typed because it allows the compiler to more
> easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make
> sure the proper addition opcodes get put down.[/color]

The C language does not have strong typing in the sense
that most people use the term today.
[color=blue]
>
> Now whether this would be useful for Python is an open question.
>[color=green]
>> Many of the supposed advantages simply aren't there
>> when you go to the discipline of writing a test and then
>> writing exactly the code needed to make the test pass, and
>> not one keystroke more.[/color]
> ...[color=green]
>> This isn't to say TDD is the be-all and end-all of
>> correctness.[/color]
>
> Right. And unit tests don't do anything for people who don't use them.[/color]

Absolutely correct.
[color=blue]
> The question is, should Guido state "TDD is the one true way to program in
> Python.", or should concessions be made in the language design for those
> who don't "drink the TDD Kool-aide".[/color]

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.
[color=blue][color=green]
>> So the conclusion here is that static typing is an attempt
>> to make programming safe for people that shouldn't be
>> programming in the first place.[/color]
>
> I rebut it thusly: "elitist bastard." <wink and a half>[/color]

Bullshit. Where did you get your certificate in mind reading?

Remember that all of the people who started this were
computer science professors, and most of their experiance was
with computer science students. They were also European
computer science professors with a strong mathematical
tendency; we have since learned that mathematicians and
software developers think differently (see some comments
by Don Knuth to that effect - don't have the reference handy.)

They're the ones who were elitist: they strongly believed
that you had to be a mathematician to be able to properly
program, and that they were doing something good for
the people who weren't fortunate enough to have a
rigorous mathematical background by forcing them into
the strait-jacket of static typing.

Competent professional programmers are a different group,
and need different facilities.
[color=blue]
> One of the draws of Python is that it's welcoming to newcomers and
> programmers of all talents. You don't have to be an "uber-programmer" to
> use it and use it well. Should we hobble it to suit poor programmers? No.
> But that's no reason why it can't be made to be easier and safer to use
> for the hobbyist when it doesn't compromise usefulness for the
> power-programmer. (My opinion) Python shouldn't have a sign on the door
> saying: "You must be this 'leet to enter."[/color]

And it won't. Python has always had the "consenting adults"
philosophy.
[color=blue]
> Will static typing be a boon for Python? Is it necessary? Or is it the
> trailhead on the road to Hades? <shrug> Only time will tell.[/color]

Since it won't happen, I'm not particularly worried about it.
If it does, I'll find another language.

John Roth

[Rocco Moretti]

Re: Optional Static Typing

John Roth wrote:
[color=blue]
> "Rocco Moretti" <roccomoretti@h otpop.com> wrote
>[color=green]
>> Looking at C, it's doubtful error prevention and program clarification
>> was a serious objective in the static typing system. It's more
>> reasonable to conclude that C is statically typed because it allows
>> the compiler to more easily allocate 1 vs 2 vs 8 bytes for a
>> particular variable, and to make sure the proper addition opcodes get
>> put down.[/color]
>
> The C language does not have strong typing in the sense
> that most people use the term today.[/color]

Strong != Static

As I understand it, strong typing means an object (variable) is what it
is, and can't be changed to a different type without explicit conversion
- weak typing being that an object can be any type, depending on which
functions you use to look at it.

Static typing is that a variable has a specific type, and can't hold a
variable of a different type. This is opposed to dynamic typing, where
the type of an (object in a) variable is flexible and determined at run
time.

Python - Strong, Dynamic
C - Weak, Static
Perl - Weak, Dynamic

This is how I understand it. Could be wrong - wouldn't be surprised if I
was, as it's a rather confusing issue at times.
[color=blue][color=green]
>> The question is, should Guido state "TDD is the one true way to
>> program in Python.", or should concessions be made in the language
>> design for those who don't "drink the TDD Kool-aide".[/color]
>
> Neither one. I hope you didn't mean that people
> who advocate TDD are suicidal fanatics, because
> that's exactly what "drink the kool-aid" means.[/color]

The irony didn't travel well. All I meant is that in all the advocacy,
it may get ignored that reasonable people might disagree about the value
of TDD, that TDD is not a "be-all, end-all" for all people.

"Concession s" also probably wasn't the right choice of word, as it
implies the TDD people are giving something up. My point was, if Python
is not going to be solely targeted at TDD, facilities that make other
ways of doing things easier are likely (should) be included, as long as
they don't negatively affect how the majority of the people who use
Python do things.
[color=blue][color=green][color=darkred]
>>> So the conclusion here is that static typing is an attempt
>>> to make programming safe for people that shouldn't be
>>> programming in the first place.[/color]
>>
>> I rebut it thusly: "elitist bastard." <wink and a half>[/color]
>
> Bullshit. Where did you get your certificate in mind reading?[/color]

Sorry. I didn't mean to imply that *you* were an elitist bastard. I
merely meant that someone who would dismiss something as for "people
that shouldn't be doing X in the first place" is likely biased by
snobbery. You were merely restating someone else's opinion, and if I
accidentally accused you of also holding it, I'm sorry.

From the rest of your post, it seems we pretty much agree on the key
point - different people have different ways of doing things, none of
which are necessarily "wrong" in and of themselves. Python tries to be
open and inclusive towards all who want to program, without sacrificing
power for it's core users.

Is there a group of people for whom static typing truly helps? I don't
know. What I do know is that saying that you don't need static typing if
you use TDD doesn't say anything about the helpfulness of static typing
for those who don't use TDD. Whether the latter group is worth Python
worrying about is a philosophical question on the future direction of
Python best left to Guido.

[Peter Hansen]

Koolaid (was Re: Optional Static Typing)

John Roth wrote:[color=blue]
> "Rocco Moretti" <roccomoretti@h otpop.com> wrote:[color=green]
>> The question is, should Guido state "TDD is the one true way to
>> program in Python.", or should concessions be made in the language
>> design for those who don't "drink the TDD Kool-aide".[/color]
>
> Neither one. I hope you didn't mean that people
> who advocate TDD are suicidal fanatics, because
> that's exactly what "drink the kool-aid" means.[/color]

I always thought the connotation was more that those who
"drank the Kool-Aid" were unthinking drones, following what
others told them to do.

Reading Wikipedia's account of Jonestown, it seems
that the truth is a mix of both the blind loyalty thing
and the suicidal fanatic thing.

I've heard this applied most often in recent years
to XML, and while I can imagine some people who apply
the phrase to those overusing XML might think they
are effectively committing suicide, I'm pretty sure
most times it is just used to mean "you are blindly
doing what everybody else does without thinking about
whether it's the right thing to do".

-Peter

P.S.: The ironic thing about all this is that it was
actually something called "Flavor Aid", made by a
company called Jel Sert (http://www.jelsert.com),
and not Kool-Aid at all. What would be even funnier
is if the expression doesn't derive from the Jonestown
suicides and I've always just assumed it did...

[Alex Martelli]

Re: Optional Static Typing

<bearophileHUGS @lycos.com> wrote:
[color=blue]
> Adding Optional Static Typing to Python looks like a quite complex
> thing, but useful too:
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551
>
> I have just a couple of notes:[/color]

Guido doesn't read this group; if you want him to read your notes, post
them as comments to Artima.

_My_ personal note is that I'm now even gladder I got myself Van Roy's
and Haridi's excellent "Concepts, Techniques and Models of Computer
Programming" book as a Christmas self-gift, and my motivation for
studying it in depth is renewed and refreshed...


Alex

[Alex Martelli]

Re: Optional Static Typing

John Roth <newsgroups@jhr othjr.com> wrote:
...[color=blue]
> question: static typing is an answer. What's the question?
> (That's a paraphrase.)
>
> The answer that everyone seems to give is that it
> prevents errors and clarifies the program.[/color]
...[color=blue]
> Most of the kinds of error that static typing is supposed
> to catch simply don't persist for more than a minute when
> you do test driven development.[/color]

....which is exactly the point of the famous post by Robert ("Uncle Bob")
Martin on another artima blog,
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .


Alex

[Mike Meyer]

Re: Optional Static Typing

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> <bearophileHUGS @lycos.com> wrote in message
> This may sound a bit
> cynical, but most real uber-programmers have either
> Lisp or Smalltalk in their backgrounds, and
> frequently both one. Neither of those languages
> have static typing, and they simply don't need it.[/color]

LISP has type declarations. Everybody I know doing production work in
LISP uses them. It's the only way to get reasonable performance out of
LISP compiled code.

Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Neal D. Becker]

Re: Optional Static Typing - Haskell?

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

[Rahul]

Re: Optional Static Typing

Hi.
Well i am a newbie to python and maybe not qualified enough to make a
comment on proposals to changes in python. My previous programming
experience has been in Java and C. So maybe you will forgive me if i
make any outlandish comments.

But anyway here goes:

I think instead what should be done is:

1.def gcd(a,b) expects (int,int)

Here the function is not enforcing type checking. The compiler should
only generate warning when someone passes something which is not an int
and should not generate an error.Maybe the person calling the function
knows what he is doing and wants to pass the unexpected type.

2.Another possibility is to let the function decide if the type is not
what it is expecting. Maybe the function recvs some kind of flag which
tells it that the type passed is not what it was expecting. So it can
throw an error if it is really critical.

3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes
this clear.

Rahul Garg

[Alex Martelli]

Re: Optional Static Typing - Haskell?

Neal D. Becker <ndbecker2@veri zon.net> wrote:
[color=blue]
> I've just started learning about Haskell. I suggest looking at this for an
> example.
>
> A good intro: http://www.haskell.org/tutorial[/color]

Haskell's a great language, but beware: its static typing is NOT
optional -- it's rigorous. It can INFER types for you (just like, say,
boo), that's a different issue. It also allows bounded genericity at
compile time (like, say, C++'s templates without the hassles), and
that's yet another (typeclasses are a great mechanism, btw).

Languages with really optional static typing can be found; I think the
premier example is still Dylan -- a kind of commonlisp without infix
notation, unfortunately very out of fashion nowadays but still available
(some good books, too).

I love the explanations of Van Roy and Haridi, p. 104-106 of their book,
though I may or may not agree with their conclusions (which are
basically that the intrinsic difference is tiny -- they point to Oz and
Alice as interoperable languages without and with static typing,
respectively), all the points they make are good. Most importantly, I
believe, the way dynamic typing allows real modularity (harder with
static typing, since type discipline must be enforced across module
boundaries), and "explorator y computing in a computation model that
integrates several programming paradigms".

"Dynamic typing is recommended", they conclude, "when programs must be
as flexible as possible". I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most real-world
application programming -- and therefore why, in said real world rather
than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
dynamic typing is generally preferable, and not such a tiny issue as
they make the difference to be. Still, they at least show more
awareness of the issues, in devoting 3 excellent pages of discussion
about it, pros and cons, than almost any other book I've seen -- most
books have clearly delineated and preformed precedence one way or the
other, so the discussion is rarely as balanced as that;).


Alex

[Nick Coghlan]

Re: Optional Static Typing

Mike Meyer wrote:[color=blue]
> Which raises what, to me, is the central question. If we have optional
> static typing, can I get a performance enhancement out of it? If not,
> why bother?[/color]

I had some thoughts along the same lines, so I dug up PEP 246 and looked at how
it could be enhanced to potentially support compile time code optimisation
through static type declarations.

The write up is here:

http://boredomandlaziness.skystorm.net/2004/12/type-checking-in-python.html

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net