Typed Python?

[Ville Vainio]

....

Jacek> Let's do this exercise again when Java reaches the age of
Jacek> Lisp. My prediction is that Lisp will still be there, while
Jacek> Java, C++ and C# will not. I rate Smalltalk's chances of
Jacek> still being there at that time

Java is the Cobol of modern times, so I believe Java will be around
(in the same despised legacy role as Cobol now).

Jacek> What they will need in the future, depends on what they
Jacek> choose to do in the future. If they want to be Java
Jacek> monkeys, then they should not bother with Scheme. If they
Jacek> want to be highly skilled programmers, then Scheme is a
Jacek> vastly superior choice to Java (and even Python).

So you think this one course will determine the future of the
students' careers? You sure exhibit a strong confidence in
education. I tend to believe that "highly skilled programmers" are
born with a certain mindset, and there is only so much school can do.

If the school churns out a succesful Java monkey with good grasp of
software architecture, project management issues etc. the school
should be considered to have succeeded in its mission. Java monkeys
pay the taxes, which support the universities.

Jacek> That may be. But the chances are that you were a better
Jacek> _programmer_ than you would otherwise have been. (But this

I don't think so. In fact I only grasped what is so great about Lisp
much much later. The course was a worthless distraction, which would
not have been so worthless if it was in Python.

Jacek> I doubt it. But that's just my opinion. And it all depends
Jacek> on the sort of person/programmer you are.

The only thing I learned was doing functional programming, handy ways
to use recursion etc (using set! was forbidden in the excercises). I
could have learned the same things with Python. And I don't think I
"missed" anything, got perfect score and generally considered the
course trivial.

Jacek> types of people emerging: those who will become Java
Jacek> monkeys, and those who will become skilled programmers. If
Jacek> you fall into the latter category, then teaching you in
Jacek> Python rather than Scheme would have been a great service
Jacek> to you; if you fall into the former category then it would
Jacek> probably have been a great disservice to you.

Here I disagree. Most students *will* become Java monkeys, project
managers or whatever. Doing a service for them is a sensible thing to
do, statistically. Not teaching something to would-be skilled
programmers is not a major disservice, because they probably know more
/ as much as their lecturers anyway.

Sometimes it seems as if academics are trying to make programming
appear more theoretical or difficult than it actually is. Programming
is a thing that a child can learn, which might be slightly
embarrassing to some professors...

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Michele Simionato]

Yes, indeed having iterators and generators built-in in the language
(as well as an exception system) exhaust most of the use case for
continuation so you don't really feel the need for them in Python in
normal circumstances.

I recently worked on my little `pynits' tool (hoping to release it a
third time, as soon as I'm satisfied enough with the changes), and have
a need for continuations there. The circumstances for that need may be
slightly unusual, but I would surely not qualify them as abnormal .

Suddenly backtracking out of a complex involvement for restarting in a
new direction, for the above project at least, requires a lot of state
resumption, and doing this cleanly in Python implies a rather strict and
burdening discipline about where and how the state information is kept.
While tractable, this is not as comfortable as I would have liked it...

Maybe I'll find better ways if I let the problem mature enough?

 

[Michele Simionato]

[Ville Vainio]

(No, I'm not implying that Lisp is not being used for real [as
in non-academic] work. It is, Scheme isn't).

Francois> I surely used Scheme for real contracts, [...]

Really, when was this?

In my case, this was a few years ago, I never precisely remember dates.
I know other people who do Scheme works for a living in these days. I
would feel a bit uncomfortable in their context, because this is all
too much commercial for my own desires, and am not so money-oriented to
fully dedicate myself in these projects that have no free aspects.

There is a kind of strange constant in what people tell me however.
Scheme seems to be often used "under the cover", in that people deliver
stand-alone solutions in which the real engine is not revealed, a bit
like if Scheme was not far from being an industrial secret.

It remembers me a friend of mine telling me a few months ago something
like
this: "Python or even Smalltalk are more used in the real world than
you expect, especially in the smartest firms, but they don't tell you
since they regard
it as a technological advantage".


Michele Simionato

 

[Ville Vainio]

Francois> Suddenly backtracking out of a complex involvement for
Francois> restarting in a new direction, for the above project at
Francois> least, requires a lot of state resumption, and doing
Francois> this cleanly in Python implies a rather strict and
Francois> burdening discipline about where and how the state
Francois> information is kept.

Would such a problem be solvable if you could pickle a "running"
generator? In fact, why is it not possible to pickle a generator that
is hygienic enough to not mutate nonlocal objects?

def mkgen():
x = 1
while 1:
x += 1
yield x

g = mkgen()
g.next()
g.next()

# x is 3 in generator

pickle.dump(g, open("a.tmp","w'))

g.next()
g.next()

g2 = pickle.load(open("a.tmp"))

g2.next() # yields 4


Is this what you were trying to achieve with continuations? I don't
really have an intuitive grasp of the continuation idea, it seems
messy compared to generators, so I'm trying to learn here...

Mutating nonlocals (in the gtor, or between pickling and unpickling)
would obviously hose this construct, but many generators should avoid
it in the first place. Referenced global objects would still be
referenced normally (because it happens on source code level), the
behaviour would just not be that of "saved state"...

So, is there some deep philosophical (as opposed to implementation
detail) flaw in the picklable generator idea?

 

[Christopher T King]

I recently worked on my little `pynits' tool (hoping to release it a
third time, as soon as I'm satisfied enough with the changes), and have
a need for continuations there. The circumstances for that need may be
slightly unusual, but I would surely not qualify them as abnormal .

Suddenly backtracking out of a complex involvement for restarting in a
new direction, for the above project at least, requires a lot of state
resumption, and doing this cleanly in Python implies a rather strict and
burdening discipline about where and how the state information is kept.
While tractable, this is not as comfortable as I would have liked it...

It may be possible to do what you want to do using only generators.
Assuming that you have some N-deep nested structure, you could do
something like this:

def dootherstuff():
<do some stuff>
if <exceptional condition>:
yield <some helpful value>
<do more stuff>

def dostuff():
<do some stuff>
for value in dootherstuff(): # call dootherstuff(), propogating yields
yield value
<do more stuff>
if <exceptional condition>:
yield <some helpful value>
<finish doing stuff>

for value in dostuff():
<handle exceptional condition described by value>

Alternatively, you could replace the for loops with something like:

continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>

Dunno if this helps or not....

 

[Arthur]

What they will need in the future, depends on what they choose to do
in the future. If they want to be Java monkeys, then they should not
bother with Scheme. If they want to be highly skilled programmers,
then Scheme is a vastly superior choice to Java (and even Python).


Some might say that the time would be better spent teaching
accountancy. It all depends on what you want out of life.

Perhaps it would.

From the point of view of an outsider to the world of professional
programming:

We judge a programming language with respect to its use in the "real
world", with Python and Lisp and Scheme lovers feeling obliged to
point to their languages use in the real world. Real world seeming to
mean - more or less - the business world. By employing the highly
skilled programmer, equipped with the just right tool (be it Python or
Scheme or Lisp or whatever) someone is finding competitive advantage,
and thereby making more than ordinary profits, perhaps building an
empire or two.

But it is quite unlikely that someone is the programmer. Who brings
born aptitudes, years of study and experience, etc, to the table, and
is probably in and out on a contract basis, having earning subsistance
for a bit of time, perhaps, in fact, by accomplishing something of
brilliance.

In the realms where I have my experience, nobody would be boasting of
being that programmer.

Art

 

[Hamilcar Barca]

[Full-quoted and top-posted]

Mr. Hickman has provided an excellent summary of the author's results.

 

[Hamilcar Barca]

Mostly by students, media and "the guys at the internet" ;-). Students
often have some idea of what local companies use at least,
though. ISTR the lecturer didn't disagree either.

The majority of university students fail to recognize they're in school
for an education; if they wanted job training, they should attend a
technical training institute. Here is a quote from a student in 1980:
"FORTRAN is a dead language."

Is FORTRAN dead? No.
Do I want to write more FORTRAN code? No.
Is Python the bestest language ever? No.
Do I want to write more Python code? Sure.

One indicator of the health of the language is the status in the Open
Source community.

A language's "status in the Open Source community [sic]" is indicative
almost solely of the language's popularity among a self-selected group of
programmers. The "health" of language is better measured by its utility
for a specific task.

It's more democratic than the status in the academia
(where one zealous professor can have huge influence).

This putative "democracy" is immaterial.

After Programming I course (in Scheme), I still felt that I was a
better C/C++ programmer than Scheme programmer.

Perhaps you were. C and C++ are quite important commercially but quite
unimportant in the theory the might introduce.

I'll say that let them teach Python in the introductory course, and
let the students that have the craving learn Scheme in their own
time. More people would learn more things, and have more fun.

The concepts in Scheme matter a great deal in computer science. Those that
are "craving ... fun" may do it on their own time. What you're describing
is the de-evolution of education into job training.

 

[Paul Prescod]

...


The concepts in Scheme matter a great deal in computer science. Those that
are "craving ... fun" may do it on their own time.

Why not have fun while learning computer science? Scheme is just a
programming language. It is not in and of itself a revelation of the
deepest concepts of computer science. Python supports recursion, second
order functions, numerical programming and hundreds of other important
concepts. In my mind, Scheme actually lacks important stuff like the
idea that types can be created (not simulated, but CREATED) by
programmers and not just language designers. It also lacks various other
OOP concepts (in its standard form).

Paul Prescod

 

[Paul Prescod]

...
We judge a programming language with respect to its use in the "real
world", with Python and Lisp and Scheme lovers feeling obliged to
point to their languages use in the real world. Real world seeming to
mean - more or less - the business world. By employing the highly
skilled programmer, equipped with the just right tool (be it Python or
Scheme or Lisp or whatever) someone is finding competitive advantage,
and thereby making more than ordinary profits, perhaps building an
empire or two.

But it is quite unlikely that someone is the programmer.Who brings

born aptitudes, years of study and experience, etc, to the table, and
is probably in and out on a contract basis, having earning subsistance
for a bit of time, perhaps, in fact, by accomplishing something of
brilliance.

At the Vancouver Python Workshop there will be a talk from a guy who was
the co-foudner and first programmer at a company. The company was built
around his Python code (and presumably the business acumen of the other
guy) and now (around 5 years later) has 80 employees and is expanding so
quickly that they can't handle all of the requests pounding on the door.
He says: "he doesn't see how he could have done it without Python." Greg
Stein says the same of eShop. Paul Graham of YahooStore. They could all
be wrong but I think that there is an interesting phenomenon there...

I rather expect that as cofounder of a company that did so well so
quickly, he's earning more than substinence these days...it can happen.

Paul Prescod

 

[Paul Prescod]

...
They never seemed to indicate that their architecture was anything
special or that their competitors' was especially bad. Just that they
could develop good code faster than their competitors.

Elsewhere they do claim architectural advantage:

http://www.paulgraham.com/lwba.html

"One way we used macros was to generate Html. There is a very
natural fit between macros and Html, because Html is a prefix
notation like Lisp, and Html is recursive like Lisp. So we had
macro calls within macro calls, generating the most complicated
Html, and it was all still very manageable."

"Users could write their own Rtml templates to describe what they
wanted their pages to look like. We had a structure editor for
manipulating these templates, a lot like the structure editor they
had in Interlisp. Instead of typing free-form text, you cut and
pasted bits of code together. This meant that it was impossible
to get syntax errors. It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."

"We could write the code to say, if the user clicks
on this link, go to the color selection page, and then come back
here. This was just one of the places were we took advantage of
this possibility. It made our software visibly more sophisticated
than that of our competitors."

Paul Prescod

 

[Jacek Generowicz]

The only thing I learned was doing functional programming, handy ways
to use recursion etc (using set! was forbidden in the excercises). I
could have learned the same things with Python. And I don't think I
"missed" anything, got perfect score and generally considered the
course trivial.

Well, there's always the possibility that the course was crap. This is
not unusual, as I've suggested before.

 

[Neil Hodgson]

Paul Prescod:

... It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."

Every sufficiently advanced LISP application will eventually reimplement
Python.

Neil

 

[chain_lube]

Frankly, there is no real reason to learn Scheme.

I have to beg to differ. I am using Bigloo (Scheme) for 3 years now
for pursuing my research PhD in physics (atmospheric physics and
chemistry).

Believe it or not: I had to translate all my former Python programs to
Bigloo because I was at the point where I was not any longer happy
with Python. Numarray was such a big mess (yes I have some experience
with similar things: IDL, Matlab and especially Yorick) and Python is
simply to depressing.

Bigloo gives me all that what I need and what makes me happy. So
saying Scheme is as worthless experience calls for troubles.

What makes me happy:

- I can give types and that /tremendously/ improves readability and
catches type erros but at the same time I am /always/ using all the
freedom of Scheme programming.

- Bigloo has pattern matching

- Object orientied programming (one can even create new types)

- Foreign function interface is very sound and very easy to use (no
need of SWIG)

- Bee development environment

- I do not use the following but they are there: Java backends
(automatically produced from Scheme code) and .NET integration

- And yes: the compiler: ./a.out

- I use it on: Mac OSX, Sun OS (I am steering, post- and preprocessing
there Fortran code with the help of Bigloo), and Linux.

- And much, much more

- disadvantages: every Scheme implemenation is a unique
implementation. However, Python is also a unique implementation ...

Bigloo is very sound and I wouldn't mind to use it in any production
code in any of my "imaginative" companies.

Scheme works so well out for me, though, my knowledge of Scheme is
very shallow but it makes me happy to program in (as opposed to
Python).


Fensterbrett

 

[Hamilcar Barca]

Why not have fun while learning computer science?

That would be good.

Scheme is just a programming language. It is not in and of itself a
revelation of the deepest concepts of computer science.

I agree here, too.

If I had to learn a new language now, and I got to choose, I'd learn
Scheme. Unfortunately, I do have to learn a new language now, and I get
to choose any two of the languages in the set of Java and Scala. I would
have liked Java before I learned Python.

You don't seem to have taken it this way, but I don't intend to bash
Python. It's still my opinion that Scheme is a better language,
theoretically and for instruction on principles (now known as "paradigms",
than Python. If I had to choose, between LISP (which I know) and Python,
for a "real" project, I'd choose Python.

Python supports recursion, second order functions, numerical programming
and hundreds of other important concepts.

How about currying and deferred list evaluation?

In my mind, Scheme actually lacks important stuff like the idea that
types can be created (not simulated, but CREATED) by programmers and not
just language designers.

I think your mind is correct. This lack is deliberate and even CLOS seems
to support concrete data types better than ADTs.

It also lacks various other OOP concepts (in its standard form).

In my limited experience, it's complete lacking in OO. There are many who
argue that functional programming is "better" than OOP, where

(setq better 'opinion)

Is this a good place to insert my "Smalltalk is the only language good
enough for teaching people to program" rant?

 

[Ville Vainio]

Hamilcar> How about currying and deferred list evaluation?

Deferred list evaluation: generators
Lazy evaluation in general: lambda : f(1,2)
Currying: lambda x,y : f(x,y,1,2)

Hamilcar> Is this a good place to insert my "Smalltalk is the only
Hamilcar> language good enough for teaching people to program"
Hamilcar> rant?

What's better about Smalltalk compared to Python, educationally? Just
a brief list will do.

 

[Jakub Fast]

Currying: lambda x,y : f(x,y,1,2)

lambda x: lambda y: f(x,y,1,2)?

but then
(lambda x: lambda y: f(x,y,1,2))(3, 4)

won't work.

so much for currying?


k

 

[Ville Vainio]

chain> Believe it or not: I had to translate all my former Python
chain> programs to Bigloo because I was at the point where I was
chain> not any longer happy with Python. Numarray was such a big
chain> mess (yes I have some experience with similar things: IDL,

Considered complaining to Numarray people instead of interpreting it
as a flaw in Python? Sometimes even filing a bug report might help.

chain> Matlab and especially Yorick) and Python is simply to
chain> depressing.

Could you show us a code example about what depresses you? Consider
this a good chance at advocacy, concrete examples always work. I was
sold to Python when I saw how easy doing CORBA is.

chain> - I can give types and that /tremendously/ improves
chain> readability and catches type erros but at the same time I
chain> am /always/ using all the freedom of Scheme programming.

Is Bigloo statically typed? If it isn't, you can equally well assert
the argument types in python functions.

chain> - Bigloo has pattern matching

Very much doable in Python. Pattern matching is rarely needed, though
- a couple of if-elif's will typically do fine (because that's what
pattern matching essentially is).

if tuple_types_are(argtuple, (int,[str], (int,int)):
pass

chain> - Object orientied programming (one can even create new
chain> types)

Folks here say Python kinda supports OOP too.

chain> Scheme works so well out for me, though, my knowledge of
chain> Scheme is very shallow but it makes me happy to program in
chain> (as opposed to Python).

Again, why? List some reasons, and we'll see if there is something
that would help you in e.g. ASPN Python cookbook.

Of course if Python "depresses" you, there might be some deeper
personality incompatibilities issues between you and the
language. Python tends to make me happy, esp. when I'm doing list
comprehensions .

 

[Jacek Generowicz]

chain> Believe it or not: I had to translate all my former Python
chain> programs to Bigloo because I was at the point where I was
chain> not any longer happy with Python. Numarray was such a big
chain> mess (yes I have some experience with similar things: IDL,

Considered complaining to Numarray people instead of interpreting it
as a flaw in Python? Sometimes even filing a bug report might help.

Though using a language in which the stuff you need already works the
way you want it, might help more.

chain> - I can give types and that /tremendously/ improves
chain> readability and catches type erros but at the same time I
chain> am /always/ using all the freedom of Scheme programming.

Is Bigloo statically typed? If it isn't, you can equally well assert
the argument types in python functions.

You are completely missing the point.

Specifying the type in Bigloo will make the code run more quickly,
while asserting the type in Python will make the code run more slowly.

chain> - Bigloo has pattern matching

Very much doable in Python. Pattern matching is rarely needed,

Chicken and egg. The Blub Paradox. etc. etc. ...

Python provides no built-in support for pattern matching, therefore
your average happy Pythoneer will not be familiar with pattern
matching, the point of pattern matching, the benefits of pattern
matching, or the situations in which pattern matching is a big win. If
they ever do try to do pattern matching, it will probably be via some
clunky home-grown implementation, which will not exhibit pattern
matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...

though - a couple of if-elif's will typically do fine (because
that's what pattern matching essentially is).

.... yup, you prove my point exactly.

My point is, of course, not specific to Python or to pattern matching;
you can replace them with any language, and any feature missing from
that language.

 

[Ville Vainio]

Jacek> Though using a language in which the stuff you need already
Jacek> works the way you want it, might help more.

It's throwing baby out with the bathwater. If something is amiss in a
library, you typically don't switch the whole language (at least in
industrial/corporate setting). You would need to switch languages
every other day. Well, I've seen worse - some people actually
*implement* new languages because e.g. Python has no library that does

Jacek> You are completely missing the point.

Jacek> Specifying the type in Bigloo will make the code run more
Jacek> quickly, while asserting the type in Python will make the
Jacek> code run more slowly.

So performance was the problem? The OP should have said so, perhaps
posted some benchmarks.

Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If

Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.

Jacek> ... yup, you prove my point exactly.

Last time I checked, pattern matching essentially *is* about

1. Finding the pattern that matches the valuable of a variable

2. Unpacking the found value to a tuple.

So please try to avoid speaking in the abstract and give something
concrete.