Typed Python?

[Arthur]

"Real" work is admittedly a bit careless choice of words. Non-academic
work is often more concerned with delivering stuff, while academic
work is more exploratory in nature (and often without the obligation
to deliver anything but research papers). Scheme/Lisp like languages
are undoubtedly better for exploratory work, because of the "plastic"
nature of the languages themselves (macros help here).

What I don't hear, curiously, in the discriptions of programming
languages significance in academia is its current role and potential
role in teaching (and learning).

The current catch phrase, I think, is "activity based learning" or
some such. There have been recurring headlines here in the US over
the last few weeks about the crisis in science education. Integrating
programming activities into science education, I think, has the
potential to improve the situation there considerably.

Numpy came up somewhere in this thread. It happen to have been an
effective tutor in a range of mathematical concepts, for me.

In fact, for someone like myself, the core interest has never be in
programming. It was a correct assessment that some understanding of
programming would open up learning opportunities otherwise closed, in
the areas where my core interests happen to lie.

And perhaps that is what distinguishes much of "academic" computing
from "professional" computing. The professional programmer tends to
be a hired gunslinger, with no necessary compelling interest in the
underlying problem being explored or solved. In academic computing, it
is more likely the underlying problem that is the heart of the matter
to whoever it is that happens to be slinging the code.

Which is the higher level acitivity?

Well I certainly wouldn't look down my nose at Scheme even if it were
admitted it best uses were academic.

But more interesting to me is Python as an academic language. Which it
most certainly is, and I think will continue to be, Proudly, I would
think, for those who have developed and supported it.

Art

 

[Greg Ewing]

Try programming an HP41 or earlier, before you had access to an
onboard editor (insert/delete by instruction was about it).

This is the crux of the matter, I think. If you can see a
whole expression at once, algebraic notation is easier to
follow. If you can only see one opcode at a time, it's
no advantage, and possibly a disadvantage.

 

[Peter Maas]

I think you mean "is_better_structured_than", not "_as".

Sorry, typical mistake (in German it's "besser als").

What you wrote, if true, would mean that Jacek meant
"x=10" was the better structured one...

Really? I think it would produce a parsing error.

Mit freundlichen Gruessen,

Peter Maas

 

[Peter Maas]

I evaluated Python based on that

You were lucky! Others end up programming Visual Basic for the rest
of their life.

Mit freundlichen Gruessen,

Peter Maas

 

[Reinhold Birkenfeld]

You were lucky! Others end up programming Visual Basic for the rest
of their life.

Well, they use Windows, they don't deserve better.

SCNR, Reinhold

 

[Dominic]

What reminds me that LISP was used to write Yahoo! Store first...

I read this a couple of times now.
What was so great about Yahoo-Store?

Did they have a better design, a better
architecture?

Or could they just mess around faster
because they were doing it in a
more dynamic language than e.g. C.

What did Yahoo!-Store prove?

If they had done it in BASIC or COBOL,
would that justify a claim that BASIC/COBOL
are great implementation languages?

Obviously a implementation benefits if
the implementation language fits and
supports the programmer by being e.g.
readable etc..
But isn't the architecure and overall
design, a well documented analysis
more important? As soon as the
system is operating, requirements
change and the system must adopt.
In the future Model Driven Architecture
may put even more emphasis on
the activities happening before coding
even starts.

This SCHEME vs. Python discussion leads
nowhere. Sure LISP/SCHEME are quite
unique and the language is very elegant
and powerful. But many do not feel
comfortable with the programming style
and readability (i like LISP but to me
it still looks like symbolic machine code),
so they chose Python or something else.

Ciao,
Dominic

 

[Jacek Generowicz]

From what I've read I got that they were trying to show that there's no
ambiguity in using "(set! x 10)" but there is in "x=10": is it an
attribution or a comparison?

There's no ambiguity about that in Python: 'x=10' is binding, 'x==10'
is comparison.

The ambiguity in Python is abouth whether 'x=10' creates a new
binding, or rebinds an existing name. Before lexical scopes this was
disambiguated with the 'global' keyword. Now, that's not enough any
more.

 

[Peter Hickman]

I read this a couple of times now.
What was so great about Yahoo-Store?

The use of Lisp allowed the original developers of the Yahoo stores to extend
the functionality of the sites faster than their competitors and, when a
competitor can up with a novel idea, do some easy feature matching.

The developers attributed their success to speed of development and said that it
was Lisp that allowed them develop things so quickly. They also said that they
only ever got nervous when they heard that a competitor was looking to develop
in Python.

Did they have a better design, a better architecture?

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.

What did Yahoo!-Store prove?

That large, robust production systems could be developed in a dynamic language
without being dragged down by poor performance. This went against the current
ethos that said that dynamic languages were only any good for prototypes but you
would have to convert to a real language (C, C++ or Java) because dynamic
languages would not scale.

 

[Jacek Generowicz]

I agree, but usig "==" is unnatural and computer specific. (I'm not saying
that the scheme approach is better.)

Ultimately it's just a choice of names. Whatever names you chose, the
programmer and reader have to understand the meanings of the names. In
Scheme (or other Lisps) you could have made the same choices of names
as in Python:

(== a b) ; Compare a and b
(= a b) ; bind a to the value of b

But choices of names are a very boring issue, compared to the issue of
code structure, the issue of series-of-token (just about everything)
syntaxes vs hierachical structure syntaxes (s-expressions, XML, sort
of Forth ...)

Anyway, this is one thing where the s-exp seems less ambiguous.

I think you were commenting on the choice of names ('set!' vs '='),
which has nothing to do with s-expressions.

 

[Jacek Generowicz]

"Real" work is admittedly a bit careless choice of words. Non-academic
work is often more concerned with delivering stuff, while academic
work is more exploratory in nature (and often without the obligation
to deliver anything but research papers). Scheme/Lisp like languages
are undoubtedly better for exploratory work, because of the "plastic"
nature of the languages themselves (macros help here).

The implication being that business applications are delivered without
having explored the solution space. That could explain one or two
things

 

[Jacek Generowicz]

Really, when was this? Even back when I learned Scheme (in 1995), it
was regarded as a language nobody really uses

Regarded as such by whom ?

Probably by students who saw lots more job adverts for Java, C++, VB,
COBOL etc. programmers.

You probably regard Forth, Smalltalk (and so on, and so on) as
languages nobody uses, and yet there are people making a living
delivering applications in these languages, and I would bet that they
are doing it far more efficiently than all those who do so in Java,
C++ or COBOL ... and are having much more fun in the process, and are
probably getting paid much more.

 

[Jacek Generowicz]

Take the "Reverse" off of RPN... Reverse Polish Notation has the
operator following the operands.
a b +
vs original Polish Notation
+ a b

Yes, it struck me, a couple of hours after posting, that by "PN" he
must have meant "Polish Notation". The canonical name, in the
Lisp/Scheme context, is, of course, s-expression.

 

[Jacek Generowicz]

[Jacek Generowicz]

Also, there once was a notable distance between Scheme and Python
about lazy evaluation [...] but more recent versions of Python offer
fairly tractable, almost easy approaches for such things.

[...] what sort of lazy evaluation ?

[...]

In Scheme, lazy evaluation is part the language with the `(delay ...)'
and `(force ...)' constructs. In Python, one could already "simulate"
lazy evaluation by various means, but it turned out to be fairly easy
after iterator generators were introduced, and these are now used all
over the place in Python, often yielding interesting speedup.

I find non-data descriptors quite useful for lazy evaluation, at times.

I guess it comes down to a difference in what we consider a "notable
distance" to be. Scheme and Python provide different means of built-in
lazy evaluation ... this strikes me as considerably less notable than
the difference between Haskell and Python/Scheme (wtr lazy evaluation).

 

[Ville Vainio]

Jacek> Regarded as such by whom ?

Jacek> Probably by students who saw lots more job adverts for
Jacek> Java, C++, VB, COBOL etc. programmers.

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.

Jacek> You probably regard Forth, Smalltalk (and so on, and so on)
Jacek> as languages nobody uses, and yet there are people making a

Pretty much, yes. For languages like Smalltalk, "nobody using it" can
be extremely damaging, whereas with languages like Python it wouldn't
matter as much, since the language can be used for scripting. A
scripting language can be sneaked into companies that don't use it
"officially". Apparently the same works for embeddable languages like
Scheme, where the Scheme-lovers are hacking Scheme while the PHB lives
in the oblivious belief that their application is in C++ ;-).

Jacek> delivering applications in these languages, and I would bet
Jacek> that they are doing it far more efficiently than all those
Jacek> who do so in Java, C++ or COBOL ... and are having much
Jacek> more fun in the process, and are probably getting paid much
Jacek> more.

The languages you enumerate are irrelevant for this
discussion. Contrast them with Python.

One indicator of the health of the language is the status in the Open
Source community. It's more democratic than the status in the academia
(where one zealous professor can have huge influence). Some snippets from sourceforge.net
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160


Smalltalk (50 projects)
Forth (55 projects)
Scheme (181 projects)
Lisp (307 projects)
C# (1602 projects)

Python (3392 projects)
Java (12617 projects)
C (13799 projects)
C++ (13943 projects)

This alone isn't very interesting - what is interesting that some of
these languages are very old, have had all the time in the world to
gain a strong foothold, have been pushed by industry giants such as
IBM, and now have... 50 projects.

Of course people have jobs using any odd language in the
world. Another thing is whether it pays off for future students to
learn a language that they won't need after that one course, unless
they choose to stay in school & join academia. Some might say that the
time would be better spent by teaching Python instead.

After Programming I course (in Scheme), I still felt that I was a
better C/C++ programmer than Scheme programmer. If the same time was
spent learning Python, my Python skills would quite probably have
exceeded my C/C++ skills and I would still have achieved all the
"pedagogical" aims of the course (there was no macro programming).

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.

 

[Jacek Generowicz]

Jacek> Regarded as such by whom ?

Jacek> Probably by students who saw lots more job adverts for
Jacek> Java, C++, VB, COBOL etc. programmers.

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 problem with many Lisp/Scheme lecturers is that they completely
miss the point about Lisp and Scheme.

I actually attended a Lisp course at university (we used Common Lisp),
but it wasn't until about 10 years later that I first noticed that
Common Lisp wasn't a quaint language for manipulating lists
recursively, but that it is the most advanced development environment
for solving complex problems in existence, that it has the most
sophisticated Object system around [... waxing lyrical for 12
screenfulls suppressed ...]

Forgive me if I don't give too much weight to the opinions of your
average Lisp/Scheme lecturers.

Jacek> delivering applications in these languages, and I would bet
Jacek> that they are doing it far more efficiently than all those
Jacek> who do so in Java, C++ or COBOL ... and are having much
Jacek> more fun in the process, and are probably getting paid much
Jacek> more.

The languages you enumerate are irrelevant for this
discussion. Contrast them with Python.

Fine ... all this week, in which I've been programming almost
exclusively in Python, I've been cursing it, and wishing I were
programming in Common Lisp, because in Common Lisp I would be much
more productive, and be having much more fun. In particular, this
week, I miss CL's condition system (stack does not get unwound when a
condition is signalled, so I don't lose any data I can inspect all the
frames in the stack right up to the one where the signal came from,
debug, redefine some buggy functions and continue execution from the
very point where it broke off ... which brings me to the second thing
I'm cursing abouth this week ...) and it's ability to update single
functions in a running program robustly (works fine in Python right up
to the point where you start using modules ... which is not very far).

Which is kinda ironic, given that last week I was giving my Python
course, and one of the first things I tell the students there is that
Python is sooo bloody wonderful for incermental development.

OK, so CL was not in my original List, but I think it ranks among
those that "everybody knows that nobody uses for any real work".

(Unfortunately, I wouldn't be getting paid more if I were programming
in CL; I'd proably get fired

Smalltalk (50 projects)
Forth (55 projects)
Scheme (181 projects)
Lisp (307 projects)
C# (1602 projects)

Python (3392 projects)
Java (12617 projects)
C (13799 projects)
C++ (13943 projects)

This alone isn't very interesting - what is interesting that some of
these languages are very old, have had all the time in the world to
gain a strong foothold, have been pushed by industry giants such as
IBM, and now have... 50 projects.

Let's do this exercise again when Java reaches the age of Lisp. My
prediction is that Lisp will still be there, while Java, C++ and C#
will not. I rate Smalltalk's chances of still being there at that time
as greater than Java's. (C# is guaranteed to be gone; it will have
been replaced (4 times over) by MS's next langage du jour.)

Of course people have jobs using any odd language in the world.

It was you who originally expressed surprise at Francois having had a
Scheme job.

Another thing is whether it pays off for future students to learn a
language that they won't need after that one course,

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

unless they choose to stay in school & join academia. Some might
say that the time would be better spent by teaching Python instead.

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

After Programming I course (in Scheme), I still felt that I was a
better C/C++ programmer than Scheme programmer. If the same time was
spent learning Python, my Python skills would quite probably have
exceeded my C/C++ skills

That may be. But the chances are that you were a better _programmer_
than you would otherwise have been. (But this depends on the amount of
enthusiasm with which you followed the course. I certainly missed a
number of opportunities in my life to learn very valuable things,
merely by being too naive to appreciate the importance of what was
being taught at the time it was being taught.)

Becoming a good _programmer_ is not about becoming proficient in some
language.[*]

and I would still have achieved all the "pedagogical" aims of the
course

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

It's interesting to look at the Amazon reader reviews for SICP. The
only ratings it gets are either 5 stars or 1 star. There is nothing in
between (well, there may be one). If you read the actual reviews, and
see how the opinions correlate with the star rating, you see two clear
types of people emerging: those who will become Java monkeys, and
those who will become skilled programmers. If you fall into the latter
category, then teaching you in Python rather than Scheme would have
been a great service to you; if you fall into the former category then
it would probably have been a great disservice to you.


[*] You call the course "Programming I". That should be a hint to you
that the purpose of the course was not to make you more proficient
in Scheme that in C++

 

[David Bolen]

The ambiguity in Python is abouth whether 'x=10' creates a new
binding, or rebinds an existing name. Before lexical scopes this was
disambiguated with the 'global' keyword. Now, that's not enough any
more.

Isn't it? Binding is still always local unless you use the global
keyword, it's just lookups that walk the scope hierarchy after lexical
scoping was added to Python. In fact, there's currently no way (that
I can think of - well, maybe with mucking with frames manually) to
rebind a name in an intermediate scope. That could in fact be
considered a wart in the nested scope support (PEP 227 indicates Guido
was opposed to it), but it does maintain the unambiguous nature of
name binding.

-- David

 

[Jacek Generowicz]

Isn't it? Binding is still always local unless you use the global
keyword, it's just lookups that walk the scope hierarchy after lexical
scoping was added to Python. In fact, there's currently no way (that
I can think of - well, maybe with mucking with frames manually) to
rebind a name in an intermediate scope. That could in fact be
considered a wart in the nested scope support (PEP 227 indicates Guido
was opposed to it), but it does maintain the unambiguous nature of
name binding.

Heh. It's unambiguous in Python, because Python, when faced with an
ambiguous situation (x=10), always makes the same choice (create a
local x unless x was declared global). The consequence is that there
is no way for the programmer to express the fact that he prefers the
other choice (rebind the lexically innermost x).

So, if it's not an ambiguity then it's a lack of expressivity.

 

[Paul Prescod]

I read this a couple of times now.
What was so great about Yahoo-Store?

Did they have a better design, a better
architecture?

Or could they just mess around faster
because they were doing it in a
more dynamic language than e.g. C.

The funny thing is that Greg Stein et. al. implemented Microsoft's
equivalent of Yahoo Store (Commerce server) in Python circa 1996.

http://www.lyra.org/greg/CaseStudy/

I don't know anything about commerce serving so I don't know how
comparable they are but the stories sound eerily familiar:

Graham:

"In the summer of 1995, my friend Robert Morris and I started a startup
called Viaweb. Our plan was to write software that would let end users
build online stores. What was novel about this software, at the time,
was that it ran on our server, using ordinary Web pages as the interface."

Stein:

"In the Fall of 1995, eShop was somewhat at a crossroads. Its
proprietary client and server were due out soon, yet the Web was taking
off. On one hand, eShop wanted to continue to provide the best possible
shopping experience possible, which required the custom client software;
on the other hand, it was becoming obvious that a custom client was
going to limit the acceptance of the eShop system. Customers were
beginning to demand entirely Web-based software. Greg was charged with
trying to find a way to create this "Lite" version of a shopping
experience via a Web browser."

Paul Prescod

 

[Michele Simionato]

But as someone who much liked both Scheme and Python, let me stress a
few aspects where Python attracted me more than Scheme.

The most important one is the bulk of library code which comes standard
with Python, but which has to be collected or rewritten in Scheme, not
being part of the standard.

Another is that, despite Scheme attempts to be minimalist (something
that I much like), Python is -- or at least once was! -- more on the
side of having only one way of doing things. Two examples come to mind.

Scheme has three ways to write a conditional statement: `(cond ...)',
`(if ...)' and `(case ...)'. All have virtues and drawbacks, and I often
switch between the three, depending on my code, and the edits I do on my
code, so it stays best at all time. This is annoying.

Scheme has many ways for looping while changing local variables, some
of which are less nice and which I did not use much, I'm not even
discussing them. The `(let loop ...)' construct is useful for writing
tail-recursive loops without creating a flurry of little separate
functions, but it is often clearer writing destructive `(set! ...)'
instead of always being tail-recursive, even if tail-recursivity
often yields more efficient compilation. When you mix assignment and
tail-recursion, the amount of solutions for a piece a code is near
exponential in the number of variables. I found this annoying, too.

Bindings, conditionals and loops are very basic and ubiquitous in any
programming language, and Python got these relatively simpler than
Scheme. Scheme may be minimalist overall, but because of the frequency
of the above constructs in a program, the minimalism is not so apparent.

Interesting that you make these remarks. One of my major complaints
about
Scheme (about aestetical aspects) was just that fact which is
advertised
as a minimalistic language but is not: the cruft you notice, an
useless/redundant "do" construct, too many let, let*, letrec, define,
inner
defines, etc. It is minimalistic only when it comes to the lack of
useful
standard libraries :-(

OTOH, things that Scheme has better than Python are the scope rules,
the
recursive structures and some functional stuff (but this is kind of
obvious).

P.S. - On the other side, in those rare circumstances one needs
continuations, Scheme offers them very easily, while there are rather
painful to simulate in standard Python. Also, there once was a notable
distance between Scheme and Python about lazy evaluation and closure
construction, but more recent versions of Python offer fairly tractable,
almost easy approaches for such things.

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


Michele Simionato

 

[Dominic]

First of all, thank you very much for
your detailed summary about Yahoo Store
and it's connection to Lisp.

>That large, robust production systems could be developed in a dynamic
>language without being dragged down by poor performance. This went
>against the current ethos that said that dynamic languages were only
>any good for prototypes but you would have to convert to a real
>language (C, C++ or Java) because dynamic languages would not scale.

Isn't this mostly an architecture dependent issue?
Python is certainly slower than plain C/C++, so that
you have to be more careful. Even if parts are done in
C/C++ partitioning is not a trivial undertaking by itself.
I see Python's or Lisp's advantage in the possibility to
prototype different architectures more quickly. After
evaluation a final system could then be implemented
in Python/Lisp + some C/C++ code for example.

Ciao,
Dominic