Typed Python?

[Ville Vainio]

Chain> You put yourself into big troubles if you miss the
Chain> opportunity of Bigloo.

I agree. Should I also forward this message to 10 other people to
dodge the impending doom?

Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one

So true.

(set! x 10)

Is so much more readable than

x=10

Chain> annoying school people in introductory courses would be
Chain> Python for its huge learning curve and its messy behavior.

With all due respect, someone that thinks python has a huge learning
curve must be a little bit on the slow side, cognition-wise.

[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

[Neil Hodgson]

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

[Paul Prescod]

Post by Neil Hodgson

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

You made me smile but you also made me think. If you need to use Scheme
in the "real world" you will use a Scheme with Python-like libraries,
maybe infix syntax, some form of object orientation etc. So who is
morphing into who?

With respect to Common Lisp I argue no contest: if you build the world's
biggest language from the start of course every other language will look
like a subset of it. ;)

Paul Prescod

[Michele Simionato]

Post by Neil Hodgson

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

This is also true for Scheme:

http://srfi.schemers.org/srfi-49/srfi-49.html

SRFI-49: Indentation-sensitive syntax

Indentation will rule the world! :)

(even if I must confess that secretely I am not yet convinced of the
virtues of indentation and I will estimate advantages/disadvantages to
be 1:1)


Michele Simionato

[Paul Prescod]

Post by Neil Hodgson

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

I hereby dub thee "Hodgson's Law".

Paul Prescod

[Paul Prescod]

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

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

[Hamilcar Barca]

[Full-quoted and top-posted]

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

In article <40ebc811$0$9978$afc38c87 at news.easynet.co.uk> (Wed, 07 Jul 2004

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.

[Peter Hickman]

Post by 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?

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.

Post by Dominic
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.

Post by Dominic
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.

[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

[Harald Massa]

Haskell is strongly typed but fully supports polymorphism
Haskell is functional rather than imperative
Haskell uses significant whitespace, like Python

and it is at least 3 days behind Python. At least in Sweden, @ Chalmers ...
EuroHaskell was just behind EuroPyhton

[Michele Simionato]

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

Hamilcar> How about currying and deferred list evaluation?
Deferred list evaluation: generators
Lazy evaluation in general: lambda : f(1,2)

this does not work so well; missing a constructs such as Scheme "set!" and "let"
anseverely limitates certain programming paradigms which are natural in Scheme.
This is ok, anyway, since Python is not Scheme. But you cannot claim that
Python support for certain things is as good as in other languages (say
Scheme, Haskell, etc.)

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

This is not currying. It is specializing arguments. Here is a reference about
specializing arguments in Scheme:
http://srfi.schemers.org/srfi-26/srfi-26.html

Haskell does real currying.


Michele Simionato

[Arthur]

On 07 Jul 2004 16:45:37 +0200, Jacek Generowicz

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.

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

[Paul Prescod]

Post by Arthur
...
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

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

[John Roth]

"Thomas Reichelt" <XXNOSPAMXX at gibts.net> wrote in message

Moin,
short question: is there any language combining the syntax, flexibility

and

great programming experience of Python with static typing? Is there a
project to add static typing to Python?

I believe that it's on Guido's wish list, at least as an option.
At one time there was a types sig that was looking into it,
but I don't know of its current status. It got bogged down
and didn't deliver anything.

There are a couple of projects that have done some kind
of type inference in Python. You might check out Bicycle
Repair Man, which has a type inference engine that it uses
to help in refactoring. I've also heard of another academic
project that was supposed to release code sometime this
summer, but the name escapes me.

There are a number of places that would have to be cleaned
up to make type inference work well. The <string>.find() method
is practically a poster child for a method that would give any
type inference mechanism fits. It returns an integer, right?
Wrong. It's supposed to return either an index into the string
(a separate type) or an indication it didn't find one. However,
the result sometimes evaluates to False when it found one,
always evaluates to True when it didn't, and is a valid index
even when it didn't find a match.

A <string>.findall() method that returned a list of all
matches is much cleaner: it evalutes to false when the
list is empty (no matches), it never returns something
that looks like an index for a non-match, and it's
compatible with the for statement.

John Roth

Thank you,
--
greetz tom

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

[beliavsky]

Moin,
short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?
Thank you,

If you are using Python mainly for numerical work and use Numeric or
Numarray for array operations, Fortran 90 or 95 may be the closest
replacement with static typing. The syntax is fairly similar (assuming
that the free source form of F90/F95 is used, as it should for new
code). Fortran 2003 supports object-oriented programming with
inheritance (as does Python), but full F2003 compilers are not
available yet.

[Peter Hansen]

And whilst this might seem a trivial point, it's worth remembering that
print "hello"
print "Goodbye"
Looks pretty unamiguous to a programmer's eyes. The most interesting
"If x is something, print 'hello' and if that fails print 'goodbye'"

Was your sample non-programmer a native English speaker? I don't
know anyone who interprets "if/then/else" as implying some kind
of exception mechanism, programmer or not.

print "hello"
print "Goodbye"

That's ludicrous. Is it possible _you_ were misinterpreting
what your non-programmer meant by "if that fails"?

-Peter

[Jacek Generowicz]

Oh. Thanks for correcting me and my apologies to Jacek.

No probs.

I should have read the thread from the beginning but it was way too
long. :)

... I know the feeling :-)

[Brett C.]

To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.

This is not necessarily true. While this is how Standard ML and
friends use it, this is not how Python would use it. Type inferencing
can be used to infer types purely for performance reasons. In this
situation you just want to know either what possible types a variable
can be holding at any time in a block or what it's exact type is at
any point in time (time-insensitive compared to time-sensitive).

In either situation you just use the type inferencing information to
see if you can make a more direct call for the object. Take the
LIST_APPEND opcode in 2.4, for instance. With type inferencing, if
you knew you had exactly a list when you called 'append', you could
skip CALL_FUNCTION and all of its code (of which there is a lot) and
just call LIST_APPEND which is just PyList_Append(). Remember that
IronPython made such noise initially because its function calls were
extremely fast ... thanks to cutting out dynamicism when possible and
type inferring.

And as just a general comment, type inferencing in Python without
changing semantics is **very** limited. My masters thesis is on
adding as much type inferencing as possible without changing any
semantics short of better argument checking at compile-time (read: you
can only type inference atomic types, which are those types with
syntactic support such as lists and dicts, in local variables since
you can inject into the global and built-in namespace and thus make it
all unknown at compile-time). Otherwise restrictions will need to be
put into place. Not being able to inject into the namespace of a
module would help a good amount. That would make keeping track of
return types worth it. Also adding support for C code that have
specific return types would help. Lastly, type-checking of arguments
would help, but *only* if it is strict; it is no help to know
something subclasses list unless you have other restrictions to help
guarantee you know that whatever method you care about is not
overridden.

And all of this is why Starkiller and IronPython compile down to
something. They restrict stuff by locking down what code you are
running against. If you don't practically everything is unknown until
run-time. So decisions would have to be made if extensive type
inferencing is added in terms of what kind of restrictions code will
have on it in order to get type inferred.

The other option after this is type feedback, which tries to
approximate what type a variable might hold. With that you make a
guess and check it before you execute. If your guess is right, you
take the fast code path, otherwise you fall back on the normal way.
Trouble is that requires type information from running the program at
least once to gather run-time type information.

[Ville Vainio]

Paul> reasons. Think about how much the semantics would have to
Paul> change to be able to help with type correctness reliably.

Would it? Wouldn't optional type declarations combined with type
inference "elsewhere" take care of the correctness aspect as well?

def g(x):
...

def f(x,y) -> str:
...


s=g(3)

s.woohey() # might work, no complaint

s = f(1,2)
if randomevent():
s.woohey() # impossible, type inference croaks
else:
s.hjhj() # ditto

[Ville Vainio]

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

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

[Jakub Fast]

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

Jakub> lambda x: lambda y: f(x,y,1,2)?
Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)
Jakub> won't work.
Of course it won't. It's the difference b/w taking 1 and 2 parameters.

Which is pretty much the point of currying.

(lambda x: lambda y: f(x,y,1,2))(3)(4)
will work.
I guess you will see that e.g in haskell
f 1 2
((f 1) 2 )
Jakub> so much for currying?
Well, no.

Well, yes.
In Haskell, both
f 1
and
f 1 2
will work, while in Python you have to install the plumbing yourself
every time.

which is exactly what I meant.... :) With lambda x,y you can't just
curry the function. You can with lambda x: lambda y:, but then you can't
do regular application with it.

however, do take a look at
http://www.sourcekeg.co.uk/www.python.org/peps/pep-0309.html
which is getting in for 2.4 (?)

k

[Paramjit Oberoi]

Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.

This is the same experience some of us had with Python...

The language: Python is wonderful, and I took to it more naturally than to
Smalltalk. But, the Smalltalk environment (Squeak is the only one I have
tried) is *really* quite amazing. I recommend playing with it a bit just
to get an idea of What Could Be even if you never intend to use it for
anything substantial.

[Hamilcar Barca]

In article <pcSdnRdks6tD5XPdRVn-sA at powergate.ca> (Fri, 09 Jul 2004

Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.

This is the same experience some of us had with Python...

So I've read and I've found no reason to disbelieve it. As I noted when I
said this represented "subjective" opinion, It just wasn't my experience.

[Jacek Generowicz]

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

Jakub> lambda x: lambda y: f(x,y,1,2)?
Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)
Jakub> won't work.
Of course it won't. It's the difference b/w taking 1 and 2 parameters.

Which is pretty much the point of currying.

(lambda x: lambda y: f(x,y,1,2))(3)(4)
will work.
I guess you will see that e.g in haskell
f 1 2
((f 1) 2 )
Jakub> so much for currying?
Well, no.

Well, yes.

In Haskell, both

f 1

and

f 1 2

will work, while in Python you have to install the plumbing yourself
every time.

You can write object-oriented programs in C ... but you have to
intstall the plumbing yourself every time. C supports object
orientation to about the same extent that Python supports currying.

You seem to be consistently implying (I just followed up another of
your posts, which implies similar sentiments) that built-in features
of other languages offer them no advantages over Python, because you
can simulate them all in Python. Why don't you take that line of
thought to its logical conclusion and program in a Turing Machine ?

Python offers no advantages over a Turing Machine, because you can
simulate all of Python's features in a Turing Machine.

[Paul Prescod]

...
In Haskell, both
f 1
and
f 1 2
will work, while in Python you have to install the plumbing yourself
every time.

But what does this have to do with Scheme, which was the subject of
conversation? We were trying to decide what deep computer science
concepts you could learn from Scheme that you couldn't from Python.

One thing I find interesting about these deep computer science concepts
seem to be mostly just language features. I mean Java is in some sense a
really good computer science language because of all of the threading
stuff it has: you'll learn about concurrent programming better with Java
than with R4RS scheme!

It might be interesting if someone rewrote SICP for Python...would
Python exhibit big conceptual gaps?

Paul Prescod

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

[Jacek Generowicz]

Post by Jacek Generowicz
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.

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.

[Reinhold Birkenfeld]

Or does it make even sense to evaluate a
programming language based on how far you can get with it in the
first 15 minutes?
Donn Cave, donn at drizzle.com

I evaluated Python based on that ;)

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

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

Sorry, maybe I'm being thick ... what sort of lazy evaluation ?

[Jacek Generowicz]

Only the academics seem to think Scheme is easier to learn
than, say Python or even C. Students often disagree.

Jacek> Sounds great; I bet it makes a lot of Python fans feel warm
Jacek> and fuzzy inside. Unfortunately the claim is completely
Jacek> unfounded.
Jacek> You should take a look at what the TeachScheme people have
Jacek> been doing, and what they seem to be achieving.
I took a look at the TeachScheme website. One example program in
particular caught my eye in http://www.teach-scheme.org/Talks/.

[...]

I'd like to see an example program, targeted at, say, 12 year olds,
where Scheme beats Python in simplicity (one that is not a compiler,
mind you ;-).

That example does indeed look crap (the way you report it; haven't
looked at it directly) in many ways (the most important probably being
that anyone new to programming should be kept as far from C++ as
possible; actually showing the stuff should be considered a criminal
offence).

I was referring to the success reported by the people who are using
the material provided by the TeachScheme project, in teaching
introductory programming courses in school.

[Jacek Generowicz]

Only the academics seem to think Scheme is easier to learn than, say
Python or even C. Students often disagree.

Sounds great; I bet it makes a lot of Python fans feel warm and fuzzy
inside. Unfortunately the claim is completely unfounded.

You should take a look at what the TeachScheme people have been doing,
and what they seem to be achieving.

[Christophe Cavalaria]

Post by Peter Maas
------
#include <stdio.h>
typedef struct listCell * list;
struct listCell {
int first;
list rest;
};
bool guest (int x, list l) {
if (l == NULL)
return false;
else if (x == (l -> first))
return true;
else
return guest (x, l -> rest);
}
int main (int argc, char ** argv) {
list l1, l2, l3 = NULL; int x;
l1 = (list) malloc (sizeof (struct listCell));
l2 = (list) malloc (sizeof (struct listCell));
l2 -> first = 3; l2 -> rest = l3;
l1 -> first = 2; l1 -> rest = l2;
scanf ("%d", &x);
printf ("%d\n", member (x, l1));
}
----------

Some people need to be shot ! This is not C or C++ code, it is C code and
considered very bad C++ code. No wonder that C++ get so much bad press with
such slander.

The *real* C++ version :

#include <list>
#include <string>
#include <algorithm>

using namespace std;

bool guest(string m, list<string> l)
{
return find(l.begin(),l.end(),m) != l.end();
}

// And now the testing code

#include <iostream>

void try_find(string m, list<string> l)
{
if(guest(m,l))
cout << "Found " << m << '\n';
else
cout << "Missing " << m << '\n';
}

int main()
{
list<string> l;
l.push_back("Hi");
l.push_back("There");
l.push_back("You");

try_find("Hi",l);
try_find("Yes",l);
try_find("You",l);
}

[Peter Maas]

Or does it make even sense to evaluate a
programming language based on how far you can get with it in the
first 15 minutes?
Donn Cave, donn at drizzle.com

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

[Marek Baczyński]

What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.

Sounds just like Starkiller+Psyco combo :) (Even though Starkiller is not
released yet AFAIK.)

[Thomas Reichelt]

Post by Marek Baczyński

What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to
native code, resulting in faster execution.

Sounds just like Starkiller+Psyco combo :) (Even though Starkiller is not
released yet AFAIK.)

Starkiller sounds very interesting... I am sure it is worth trying when it's
released!

[Fernando Perez]

To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.

I am one who would really like _optional_ static typing information to be
available in python, but for different reasons than the usually requested here:
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we
rewrite those parts of our codes in C/C++/Fortran, but it would be great to be
able to simply tell python the types of the variables and have it not do any of
its dynamic runtime checks.

I do not believe in static typing as a compile-time 'feature': I've grown to
feel that all the supposed benefits of static typing can indeed be achieved
with proper testing, and the _huge_ gains in flexibility and productivity one
gets from python's type model are something I don't want to do without.

But for tightly constrained code that needs to run as fast as possible, without
repeating any unnecessary work (such as type detection), having an option to
declare type information would be a huge boon.

Cheers,

f

[Fernando Perez]

Psyco sounds appealing, but it's an x86-only solution. That won't be of much
help on a Cray or an Itanum cluster...

Itanium

stupid typo.

f

[Jacek Generowicz]

Post by Fernando Perez
I am one who would really like _optional_ static typing information
to be available in python, but for different reasons than the
usually requested here: performance. My field is scientific
computing, and when you are inside a simple for loop, manipulating
arrays of homogeneous data, the overhead of python's dynamicism is a
killer. Obviously what ends up happening is that we rewrite those
parts of our codes in C/C++/Fortran, but it would be great to be
able to simply tell python the types of the variables and have it
not do any of its dynamic runtime checks.
I do not believe in static typing as a compile-time 'feature': I've
grown to feel that all the supposed benefits of static typing can
indeed be achieved with proper testing, and the _huge_ gains in
flexibility and productivity one gets from python's type model are
something I don't want to do without.
But for tightly constrained code that needs to run as fast as
possible, without repeating any unnecessary work (such as type
detection), having an option to declare type information would be a
huge boon.

I guess that you know that this sort of thing is successfully done in
Common Lisp (and Dylan and probably some, if not all, Schemes).

I've even heard rumours of Guido saying that something like it will
appear in a future, Python.

I would certainly warmly welcome it, if it should arrive in Python.

[Pierre-Frédéric Caillaud]

Try numeric / numarray (optimized arrays/matrices of real/complex for
scientific computing).

Post by Fernando Perez

To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.

I am one who would really like _optional_ static typing information to be
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we
rewrite those parts of our codes in C/C++/Fortran, but it would be great to be
able to simply tell python the types of the variables and have it not do any of
its dynamic runtime checks.
I do not believe in static typing as a compile-time 'feature': I've grown to
feel that all the supposed benefits of static typing can indeed be achieved
with proper testing, and the _huge_ gains in flexibility and
productivity one
gets from python's type model are something I don't want to do without.
But for tightly constrained code that needs to run as fast as possible, without
repeating any unnecessary work (such as type detection), having an option to
declare type information would be a huge boon.
Cheers,
f

[Fernando Perez]

Post by Fernando Perez
I am one who would really like _optional_ static typing information to be
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we

For performance, maybe Psyco is what you need, without the need fo
static typing, but rather different compilation of code for different
types, like with C++ templates.

Psyco sounds appealing, but it's an x86-only solution. That won't be of much
help on a Cray or an Itanum cluster...

Cheers,

f

[Nicolas Fleury]

Post by Fernando Perez
I am one who would really like _optional_ static typing information to be
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we

For performance, maybe Psyco is what you need, without the need fo
static typing, but rather different compilation of code for different
types, like with C++ templates.

Regards,
Nicolas

[Peter Maas]

I am not sure what you personally understand under pattern matching.
However, since they are discussing about pattern matching the following

Oh. Thanks for correcting me and my apologies to Jacek. I should
have read the thread from the beginning but it was way too long. :)

Mit freundlichen Gruessen,

Peter Maas

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

[Ville Vainio]

Smalltalk (50 projects)
Forth (55 projects)
Scheme (181 projects)

...

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.

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

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.

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

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

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

[Arthur]

On Wed, 07 Jul 2004 23:13:49 -0700, Paul Prescod <paul at prescod.net>

Why not have fun while learning computer science?

Yes please, fun.

I am somewhere between a CP4E-er and a "computer science" -er.

There is much to be done with programming, IMO, in the educuational
process that is something short of hard core computer science.
Practical programming as a tool for other learning and teaching
possiblities. But in areas that themselves tend to be tehnical and
demanding (mathematics and science, the most obvious), so the
association of these efforts with "technical" and "demanding" need not
be soft pedaled. It need not be "easy".

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

For the things I hoped to accomplish by learning to program - based on
available compatible libraries and tools - Java would have been a more
practical choice.

Not being in a position to talk to the issue of the "deepest concepts
of computer science", I would have no reason to reject Java for Python
(or Scheme).

But since my self directed efforts were not a required course, and not
designed as a career move, I did demand to be having some fun at it.

Which I think is more or less how I ended up at Python.

Hard to define why this is so. But the word "fun" is slung around the
Python community with abandon, and it is one word used within the
community that I have never found a basis to quibble with.

Art

[Paul Prescod]

...
You don't seem to have taken it this way, but I don't intend to bash
Python.

I didn't take it that way. I'm just trying to understand to what extent
your position is yours and to what extent it is just common wisdom.
Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching? In retrospect it really
wasn't that great. But at the time it was common wisdom.

...

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

How about currying and deferred list evaluation?

Between generators, nested functions and generator expressions I think
we're doing okay. But why are these more important concepts than (let's
say) threads or network programming? Because the latter are tainted by
real-world usefulness?

Computer science is a really massive field and I think that for every
pattern that is made easy to learn because it falls out of the language
syntax ("deferred list evaluation: now I understand lazy processing in
general") there are ten that do not (cache coherency, context-free
grammars, relational algebra, tree transformations, algorithmic
complexity, state machines, quick sort, floating point numbers, graph
theory, text searching).

Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education. Students will probably learn more
from the library than from the language. I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.

Paul Prescod

[Hamilcar Barca]

In article <du7d63858ae.fsf at mozart.cc.tut.fi> (Wed, 07 Jul 2004 15:08:41

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.

[beliavsky]

Post by Hamilcar Barca
The majority of university students fail to recognize they're in school
for an education; if they wanted job training, they should attend a
"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 should not judge a programming language based on outdated
information.

Fortran (not spelled with all caps since the 1990 standard) continues
to evolve. The 1990 standard added array functionality, modules (in
Fortran, 'use foo, only: boo' is equivalent to 'from foo import boo'
in Python) similar to that of Numeric or Numarray, the 1995 standard
added features for parallel programming such as pure and elemental
functions (similar to Python ufunc's), and the 2003 standard added OOP
with inheritance and interoperability with C.
There is a free Fortran 95 compiler for x86 Linux and Free BSD and Mac
OS X at http://www.g95.org .

[Hamilcar Barca]

In article <mailman.151.1089350640.5135.python-list at python.org> (Thu, 08

I'm just trying to understand to what extent your position is yours and
to what extent it is just common wisdom.

I think common wisdom would say VisualBasic and Java, for example, should
be the primary languages; when I first started school, FORTRAN, COBOL,
APL, and (enhanced) Dartmouth BASIC seemed big.

Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching?

Pascal was big because it had a reasonably simple syntax, strong typing,
plain block structure, among other things. Did this make it the best
choice at the time? I don't think so. Was it good enough? Yes.

If I were making the decision between say FORTRAN, COBOL, APL, Pascal,
Modula, C++, Java, C#, VBA, or Python, I'd choose Python quickly. Adding
Smalltalk and Scheme would make me think harder. Perhaps it was you who
said it (or maybe I imagined it), but the availability of a work the
quality of Abelson and Sussman for Python and Smalltalk would make the
decision quite hard.

But why are these more important concepts than (let's say) threads or
network programming?

I don't see why network programming is particularly important for teaching
basic concepts. I do think parallel programming worthy of study but it's
not quite what I mean. I neglected to say so, but my comments were
directed toward introductory education.

Because the latter are tainted by real-world usefulness?

I don't worry about a taint; the choice of language for education should
not be based on salability or popularity, but rather on its ability to
express the concepts to be demonstrated by writing programs.

Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education.

Fun isn't fundamental be neither should pain be inflicted gratuitously.

Students will probably learn more from the library than from the
language.

Perhaps or perhaps not, but...

I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.

I'd go so far as to say that I agree completely with your point.

I'm a bit tired of the attitude of undergraduates, especially, who want to
be taught a language because they think it will get them a job.
Undergratuates as a rule don't know diddly-squat, if you'll excuse the
technical terminology. I'm seriously tired of the rah-rah,
jump-on-the-bandwagon, my-krew's-using-it rationale for language choice.

I'm glad this isn't your attitude and anyway it's a different rant.

[Thomas Reichelt]

Moin,

short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?

Thank you,

[Erik Max Francis]

Just for the record, there's a dialect of C called Cyclone,
which supports type-inference (although with some limitations).
Since it's derived from C, it's not a functional language, but
it has grown quite some features typically found in functional
languages.
http://www.eecs.harvard.edu/~greg/cyclone/index.html

Its extra pointer qualification features are interesting. Thanks for
bringing this to my attention, I don't think I'd heard of it before.

[Arthur]

On Sun, 04 Jul 2004 10:18:18 +0200, Thomas Reichelt

The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.

This is coming close to trolling, IMHO.

Perhaps it is.

But as an advocate of the potential of Python in education, it is to
me not unitneresting to hear, and I do not totally discount the point
of view.

Learning curve, messiness aside - there is little question to be that
the Scheme community has approached the issue of the role of
programming education, as an element of an *education* in general, in
more mature, sophisticated, and honest ways then I have generally
noticed in the Python community.

I recently reread the introduction to How to Design Programs, which is
a book that is part of the TeachScheme project.

http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-4.html#node_chap_1

It expresses in a few paragtraphs some of the inescapable
fundamentals:

"Becoming and being a programmer is fun, but it is not easy."

"Programming a computer requires patience and concentration. Only
attention to minute details will avoid frustrating grammatical
mistakes."

The obvious.

Much of what you hear in the Python world regarding education sounds
different.

"Python is easy, and learning to program with Python is easy."

Often implying that it is only that others are making the effort in
languages other than Python that makes it seem otherwise.

Which is wonderful to hear, and would be worth saying, if saying it
would make it true.

Of course, it doesn't.

Of course, its nonsense.


Art

[Ville Vainio]

Arthur> "Python is easy, and learning to program with Python is
Arthur> easy."

Arthur> Often implying that it is only that others are making the
Arthur> effort in languages other than Python that makes it seem
Arthur> otherwise.

Arthur> Which is wonderful to hear, and would be worth saying, if
Arthur> saying it would make it true.

Arthur> Of course, it doesn't.

Arthur> Of course, its nonsense.

Well, many of us just think it's true. Only the academics seem to
think Scheme is easier to learn than, say Python or even C. Students
often disagree.

[Ville Vainio]

Arthur> I don't think the academics you are referring to think
Arthur> Scheme is easier to learn than Python, I'm thinking that
Arthur> they might be thinking that neither is *easy*, and easy
Arthur> isn't the point in any case.

Actually, the "real" attitude of the lecturers is often "now everyone
knows C (or C++, ot Java, or...) already, let's look at something
completely different". And apparently, the number of schools using
Scheme is constantly dropping - it has either been dropped already, or
the schools are considering dropping it. Usually replacing it for
Java, but they would do better to replace it with Python, of course.

Arthur> It is precisely this promotion as "easy" as somehow
Arthur> representing an ultimnate good, in the context of
Arthur> education, that I find frustrating to hear repeated so
Arthur> often here.

Perhaps. Perhaps you read it as "easy as in VB", while it actually
means "easy to learn, easy to do everything".

Arthur> It seems to me that in many respects Python is a
Arthur> programmer's programming language. Isn't it safe to say
Arthur> that most people who use Python, learned their
Arthur> fundamentals elsewhere, and find Python as a productive
Arthur> way of applying what they already know.

Quite probably, but that's more because of the current status of the
language as a "grassroots" language, where savvy programmers check it
out and start using it as opposed to many languages that are being
pushed by authorities (schools, conservative companies etc.).

Arthur> It happens that *I* have learned Python and not learned
Arthur> Scheme, or C.

Arthur> Maybe precisely *because* it is messier than either. ;)

Frankly, there is no real reason to learn Scheme. Common Lisp, OTOH,
has at least a theoretical possibility of being useful in the real
world (apparently Debian even provides some *gasp* libraries for
Common Lisp).

C itself is probably not too messy (awkward and clumsy, yes). Programs
written in C are.

[Arthur]

On 04 Jul 2004 21:40:11 +0300, Ville Vainio <ville at spammers.com>

Post by Ville Vainio
Arthur> "Python is easy, and learning to program with Python is
Arthur> easy."
Arthur> Often implying that it is only that others are making the
Arthur> effort in languages other than Python that makes it seem
Arthur> otherwise.
Arthur> Which is wonderful to hear, and would be worth saying, if
Arthur> saying it would make it true.
Arthur> Of course, it doesn't.
Arthur> Of course, its nonsense.
Well, many of us just think it's true. Only the academics seem to
think Scheme is easier to learn than, say Python or even C. Students
often disagree.

I don't think the academics you are referring to think Scheme is
easier to learn than Python, I'm thinking that they might be thinking
that neither is *easy*, and easy isn't the point in any case.

It is precisely this promotion as "easy" as somehow representing an
ultimnate good, in the context of education, that I find frustrating
to hear repeated so often here.

Is that the most important thing that Python has to offer?

It seems to me that in many respects Python is a programmer's
programming language. Isn't it safe to say that most people who use
Python, learned their fundamentals elsewhere, and find Python as a
productive way of applying what they already know.

This would be consistent with something I believe I read Guido as
having said in a recent interview. That Python was originally
developed as a tool for C programmers. ABC roots notwithstanding

I think I can be articulate as to why Python can be a good tool to
apply to educational challenges. But "easy" is never a word that
comes quickly to mind.

"Glue" comes to mind.

"Fun" comes to mind - and I see nothing wrong with *that* word in an
educational context.

It happens that *I* have learned Python and not learned Scheme, or C.

Maybe precisely *because* it is messier than either. ;)

Art

[Jarek Zgoda]

short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?

Static typing would destroy all fun in Python. Eventually we would end
with ObjectPascal-like language, just running in VM and not compiled.

Maybe Borland's Delphi for .NET is what you look for?

[bruno modulix]

Thomas Reichelt a ?crit :
(snip)

Yes, type inference, for example, would be a great addition to Python! I
took a look at OCaml a while ago, but as I am not very addicted to pure
functional programming, it wasn't my thing.

<ot>
Err... OCaml is certainly not a 'pure'[1] fpl. It has support for
imperative and OO programming too (the 'O' is for 'Objective').

[1] at least according to the 'official' definition of 'pure functional
programming languages', which is (in short) that you can *never* change
the value of a variable.
</ot>

My 2 cents,
Bruno

[Thomas Reichelt]

Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.
Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.

Yes, type inference, for example, would be a great addition to Python! I
took a look at OCaml a while ago, but as I am not very addicted to pure
functional programming, it wasn't my thing. Also, compared to Python, the
number of libraries is small, and the support for UI is cumbersome... but
type inference is great.

What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.

[Ville Vainio]

Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.

Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.

[Ville Vainio]

Sam> You might want to take a quick look at Haskell, although I
Sam> think it is still largely an academic's language. A quick
Sam> roundup of

I think the Haskell programming experience is totally different from
the Python experience, because of the functional approach. This also
implies that there is about a zero possibility of introducing the
language in commercial projects because of peer opposition and the
"academic" flavor of the language (no libraries, absent/elitist
community that doesn't even need libraries).

The Lisp programming experience might be more pythonic, but the syntax
(or the absence of it) kinda ruins it too. But then again, Lisp is
dynamically typed but with type declarations.

[chain_lube]

Moin,
short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing?

Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".

I was not in dire need for looking back to Python any longer once I
encountered Bigloo:

- types
- object system
- pattern matching
- exception handling
- keywords
- Bee (development environment)
- excellent foreign function interface to C: Bigloo speaks C indeed!
- Java backends (automatically generated from Scheme code)
- .Net integration
- excellent and very stable high perfromance compiler for speed;
performance is on par with OCaml
- nearly on every platform

- and do not forget: though, there are types but you /always/ will get
the option of using Bigloo as it were an ordinary Scheme with all the
freedom so to speak! Types will never be your stumbling block as in
Clean or Haskell for example.


Fensterbrett
PS: Note: with srfi-1 you get a lot of typical functional programming
support! Hey man you can even download the srfi-functions for "lazy
streams".

[Thomas Reichelt]

Thomas Reichelt <XXNOSPAMXX at gibts.net> wrote in message

Moin,
short question: is there any language combining the syntax, flexibility
and great programming experience of Python with static typing?

Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".
I was not in dire need for looking back to Python any longer once I

[...]

Thanks, but... Scheme... I hate parens ;)

[François Pinard]

[Ville Vainio]

[Chain Lube]

The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability.

With all due respect, someone that thinks [...]

Flamatory comments are not really my bag. :-)

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.

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.

[Neil Benn]

"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

That's not really the best distinction IME. Non-academic work can be
exploratory in nature as well. For me the real difference is with academia
something not working/panning out is just as interesting/valid in many
respects as something suceeding - indeed in some cases more interesting.
In non-academia, something not suceeding normally means overhead to the
business, and increasing the costs to the company. In severe cases if this
continues companies involved and go bust.
<snip>

Hello,

Good description of academic vs. Industrial, except for the
point on 'programmers who have C-Like syntax finding python easy to pick
up', IMO python poses a challenge to people who are coding in languages
such as Java and C#. The main issue is getting your head around the
paradigm of 'trusting your client'. Coming from Java I'm desperately
trying to not write code that forces Python to behave like Java - there
are several cases where I don't want my client to change something in my
class but I want to change in my own, separate, class - package level
scope. In addition, the point of scope being a 'hint' to the client
that they should obey the rules and not change something which is
'private' is a very alien concept to me. I understand the arguments for
this but it goes against my natural way of thinking. The same goes for
dynamic typing, again I understand the arguments for this but not having
the ability to 'fail-fast' when my client does something stupid is
alien. I know that I can encode these rules myself but I have to
consciously try to not attempt to cram Python into my way of thinking
gained in other languages.

The syntactical things are learnt to go away (no ';' at the end of a
line, conditionals in break not having brackets, using tabs instead of
braces) after a bit but that's the same with 'most' language learning.

However, I do think that new programmers would like Python's cleaner
syntax - the only problem is that they will have to learn 'C-Like'
syntax at some point or they will be stuck in one language forever
more! As you can probably guess - I'm from the industrial world.

Cheers,

Neil
--
Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : benn at cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Jacek Generowicz]

Post by Ville Vainio
Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

[François Pinard]

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

Even back when I learned Scheme (in 1995), it was regarded as a
language nobody really uses (and dropping it out of school curriculum
was being considered already).

Hey! This is a world-wide conspiration, driven by those who understand
the competitive advantages they get by knowing and using Scheme! :-)

Nowadays, Python is my main weapon, but I surely not make it a secret!

[Arthur]

On 05 Jul 2004 13:24:08 +0200, Jacek Generowicz

Post by Jacek Generowicz

Post by Ville Vainio
Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

Well it does seem to me that the subtleties of assignment in Python is
an excellant example of where its "easiness" is more apparent than
real.

The notice of which takes nothing away from Python.

But does work toward dispute of certain discriptions of it.

Art

[Ville Vainio]

Francois> [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, that is,
Francois> non-academic works, and I'm aware that others
Francois> (individuals or companies) also did or do. Moreover, in
Francois> my own experience at least, the phenomenon of Python in
Francois> commercial circles is more recent and limited that the
Francois> same for Scheme.

Really, when was this? Even back when I learned Scheme (in 1995), it
was regarded as a language nobody really uses (and dropping it out of
school curriculum was being considered already).

[Jacek Generowicz]

Post by Ville Vainio
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.

[Peter Maas]

Post by Jacek Generowicz

Post by Ville Vainio
(set! x 10)
Is so much more readable than
x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression

"(set! x 10)" is_better_structured_as "x=10"

is true? How is is_better_structured_as defined? :)

Mit freundlichen Gruessen,

Peter Maas

[François Pinard]

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

I surely used Scheme for real contracts, that is, non-academic works,
and I'm aware that others (individuals or companies) also did or do.
Moreover, in my own experience at least, the phenomenon of Python in
commercial circles is more recent and limited that the same for Scheme.

[Christopher T King]

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

And Python was used to write Google. :)

[Jorge Godoy]

If you recall, we've got == for comparison in Python and most of the
programming world. There is no ambiguity. x=10 syntax is just
impossible in Scheme without read macro hackery, because of the
s-expression syntax (which does have some virtues).

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

Anyway, this is one thing where the s-exp seems less ambiguous. That was my
only point in the message.

Yes, the Legend of Sir Graham. Lisp does need another success story,
public gets suspicious when the same one is repeated over and over
again.

I agree with you.

The same happens for Python and other languages equally powerful.

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

I guess it all depends on what is "real" for you. For me, academia is as
real as the business and commercial world. It is more tolerant, sometimes,
but both worlds have its peculiarities. And in academia you are evaluated
by people with much more skills and experience than you, for colleagues,
for other people. In the commercial world, people usually deliver closed
source, i.e., nobody can evaluate if you did it the best way or if you
cheated to get the answer you thought were right.


Be seeing you,

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

Jorge> I guess it all depends on what is "real" for you. For me,
Jorge> academia is as real as the business and commercial
Jorge> world. It is more tolerant, sometimes,

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

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

Post by Jorge Godoy

If you recall, we've got == for comparison in Python and most of the
programming world. There is no ambiguity. x=10 syntax is just
impossible in Scheme without read macro hackery, because of the
s-expression syntax (which does have some virtues).

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

Post by Jorge Godoy
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]

Post by Peter Maas

Post by Jacek Generowicz

Post by Ville Vainio
(set! x 10)
Is so much more readable than x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)

Peter Hansen gave you the correct hint: "Better structured THAN".

[Ville Vainio]

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

If you recall, we've got == for comparison in Python and most of the
programming world. There is no ambiguity. x=10 syntax is just
impossible in Scheme without read macro hackery, because of the
s-expression syntax (which does have some virtues).

most programmers probably don't. For academics (possibly with
no code to write in the first place), this is a minor issue.

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

Yes, the Legend of Sir Graham. Lisp does need another success story,
public gets suspicious when the same one is repeated over and over
again.

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

[Ville Vainio]

Jacek> logic ... but given that your logic appears to lead you to
Jacek> conclude that structure "quality" is somehow directly
Jacek> related to string length[*],

..

Jacek> [*] As opposed to, for example, simplicity of
Jacek> transformation to parse tree.

I suppose a teacher of high school kids should be more concerned with
the intuitiveness of the construct than the simplicity of
transformation to parse tree.

Seeing "(set! x 10)", many would probably think "yeah, it's a special
form that binds 'x to 10, I get the idea, now got off my face, I have
work to do". You only need to learn once what "x=10" does, after that
it just happens; you don't need to spell it out to the machine.

Of course the scheme syntax also conveys that "mutating a variable is
a bad idea, please reconsider". While someone might appreciate the
constant nagging by the language targeted at your programming style,
most programmers probably don't. For academics (possibly with no code
to write in the first place), this is a minor issue.

[Peter Maas]

Post by Peter Maas
You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)

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

[Reinhold Birkenfeld]

Post by Peter Maas

Post by Jacek Generowicz

Post by Ville Vainio
(set! x 10)
Is so much more readable than
x=10

Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.

You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)

Hey, it is

(is_better_structured_as "(set! x 10)" "x=10")

Be consistent!

Reinhold

[Jacek Generowicz]

Post by Peter Maas
You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)

def is_better_structured_than(a, b): # take Peter's suggestion
"Returns true if a is better structured than b."
raise ThatsNotFairError
return len(a) > len(b)
(It is the only logical interpretation of the statement since in any sane
parse tree of the two on some fair ground they are indistinguistable. If
you don't like this logic, Jacek,

I love your assertion (re parse tree); you have failed to show me your
logic ... but given that your logic appears to lead you to conclude
that structure "quality" is somehow directly related to string length[*],
I must admit that it seems to me that your logic probably sucks.

:-)


[*] As opposed to, for example, simplicity of transformation to parse
tree.

[Jacek Generowicz]

In the early days of pocket calculators, Texas Instruments had all
these RPN (reverse Polish notation) models.

Wasn't it HP ?

Now, many people argued that computationally RPN made more
sense. But the market has spoken otherwise.

The market has spoken. Microsoft Windows is the best operating system.

No matter how much sense it may make in theory, in practice the
majority of people will NOT buy nor use a RPN calculator.

While power users will.

Sure, there are always going to be those that stick with RPN
calculators and praise their structuredness to no end.
In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.

User friendliness to whom ? RPN calculators are extremely
user-friendly to power-users of calculators.

Trust me.

I'll pass on this one. I prefer to think for myself, rather than
trusting people ... particularly people who give an impression of not
being particularly well informed in the very same post in which they
tell me to trust them :-)

Codeblocks, not Lisp/Scheme's PN expressions,

Never heard of PN expressions. Please enlighten me.

are the way of the future. It's very simple logic: people want
machines to act more like people,

That's not logic; that's an unfounded claim.

they don't want to be told to act more like machines.

Who are these "people"? You seem to be suggesting that the qualities
that Joe Windoze User seeks in a computer are the same that a skilled
programmer seeks in a computer.

Methinks you need to think again.

[Michele Simionato]

"Donn Cave" <donn at drizzle.com> wrote in message news:<1089088884.774076 at yasure>...
<snip>

Or does it make even sense to evaluate a
programming language based on how far you can get with it in the
first 15 minutes?
Donn Cave, donn at drizzle.com

I evaluated Python based on that ;)


Michele Simionato

[Hung Jung Lu]

In the early days of pocket calculators, Texas Instruments had all
these RPN (reverse Polish notation) models.

I don't think TI ever made any RPN calculators.

Sorry, I mixed it up with HP. Though TI did make RPN calculators as
well (see Google.) I never bought any RPN calculator as a scientist.
Sure, I use them and feel quite all right with them, as long as I am
not the owner. :)

regards,

Hung Jung

[Peter Hansen]

Mine was an HP. It was great, would still use it today if
someone hadn't stolen it.
I never bought any RPN calculator as a scientist.
Sure, I use them and feel quite all right with them, as long as I am
not the owner. :)

Hmm... seems like there's an obvious conclusion to be made here. <wink>

-Peter

[Pierre-Frédéric Caillaud]

In the early days of pocket calculators, Texas Instruments had all

Yes, I still have a HP48 from my science school days. It was a great
machine. I found the reverse polish notation much more powerful than the
classical notation when doing manual calculations. However, when
progrmaming, it was hell because you had to keep track of the stack in
your head, which is very difficult. As soon as there's if/then and loops,
I think stack languages become impossible to use.

[Jacek Generowicz]

Post by Pierre-Frédéric Caillaud

In the early days of pocket calculators, Texas Instruments had all

Yes, I still have a HP48 from my science school days. It was a
great machine. I found the reverse polish notation much more
powerful than the classical notation when doing manual
calculations. However, when progrmaming, it was hell because
you had to keep track of the stack in your head, which is
very difficult. As soon as there's if/then and loops, I think
stack languages become impossible to use.

Perhaps you should ask the good folks over on comp.lang.forth to
comment on the matter ... unless you just want to make an unfounded
statement that makes you feel good inside, of course :-)

[Michael Sparks]

short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?

This is almost a word for word description of how I've heard Pyrex
described.

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

It's a language that combines the best elements (IMO) of C and Python.
It's designed for writing extension modules for python, however people
have successfully used it for writing standalone programs - albeit with a
C bootstrap/harness.

It's very pleasant to work work, and you can use distutils to
build/distribute your code.

Example code fragments:
------------------
cdef class vorbissimple:
cdef ogg_vorbis_context* oggVorbisContext
cdef source_buffer* sourceBuffer
cdef decode_buffer* decodeBuffer

def __init__(self):
self.sourceBuffer = newSourceBuffer(NULL,BUFSIZE)
self.oggVorbisContext = newOggVorbisContext()
self.decodeBuffer = NULL
------------------
def primes(int kmax):
cdef int n, k, i
cdef int p[1000]
result = []
if kmax > 1000:
kmax = 1000
k = 0
n = 2
while k < kmax:
i = 0
while i < k and n % p[i] <> 0:
i = i + 1
if i == k:
p[k] = n
k = k + 1
result.append(n)
n = n + 1
return result
----------------------
There's also an excellent tutorial/guide here:
* http://ldots.org/pyrex-guide/

HTH,


Michael.

[François Pinard]

[Ville Vainio]

[Fran?ois Pinard]

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.

Would such a problem be solvable if you could pickle a "running"
generator?

Not really. Generators could be used in chains (of generators), each
element of the chain usually being some local variable in another
element, and pickling one is meaningless if you cannot pickle them
all. Moreover, the serialisation implied by pickling would usually be
extraneous and unwanted overhead to the whole process of saving and
restoring generator state.

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

I'm not a deep philosopher, so I cannot say! :-)

[LittleDanEhren]

Post by Ville Vainio
Chain> You put yourself into big troubles if you miss the
Chain> opportunity of Bigloo.
I agree. Should I also forward this message to 10 other people to
dodge the impending doom?
Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10

Is that intended to be sarcasm? To me, they're equally readable. You
obviously aren't a very experienced scheme programmer, because if you
were, then you'd use define, not set!. Set! is used extremely rarely in
most Scheme code. And the thing about those two syntaxes is that, while
the Python syntax is more concise, you can do so much more with the
scheme syntax since you have macros.

Post by Ville Vainio
Chain> annoying school people in introductory courses would be
Chain> Python for its huge learning curve and its messy behavior.
With all due respect, someone that thinks python has a huge learning
curve must be a little bit on the slow side, cognition-wise.

Some people pick up Python really quickly, others pick up Scheme really
quickly, others don't learn either very fast. If someone is used to
functional programming, then Python could be very confusing.
Daniel Ehrenberg

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

[Christopher T King]

[Christopher T King]

Post by Christopher T King
It may be possible to do what you want to do using only generators.
continuation=dostuff()
value=continuation.next()
<store continuation away for future use>
<function completed, carry on>

If the generator gets exhausted, what would be the purpose of saving it?

Oops, I got that backwards. It should read:

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

I would presume chained generators might ease control of the flow, at
least to a certain extent, but would not help so much for complex state
resumption, especially when state is shared between parts of the program.

And hence the need for continuations ;) Perhaps if there was a way to
resume code that was interrupted by an exception?

[Michael Sparks]

"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

That's not really the best distinction IME. Non-academic work can be
exploratory in nature as well. For me the real difference is with academia
something not working/panning out is just as interesting/valid in many
respects as something suceeding - indeed in some cases more interesting.
In non-academia, something not suceeding normally means overhead to the
business, and increasing the costs to the company. In severe cases if this
continues companies involved and go bust.

ie the bottom line difference is that in the non-academic world whether
the solution is correct, pretty, ideal is less important than whether the
code actually does what's required or not.

There can be an intersection between ideals - and IME python is one of the
best intersections. It has a cleanliness to it that is more common in
"academic" languages - like SML, but a practicality about it that is more
like the Perl/C's of the world. Test first has become the practical answer
to formal specification. Clean imperative languages being able to glue
easily with systems, have become a practical alternative to conventional
functional languages like SML. (OCaml being an interesting convergence
from the other direction)

The reality of the situation in the non-academic world is that the
majority of programmers out there either code in C-like syntax languages
or have been weaned on languages like visual basic. For such programmers
picking up python is incredibly easy. I think this is heavily due to the
fact that if you ask many programmers to describe an algorithm in
pseudocode, they generally drop all the crappy syntactic decorators (such
as "{", "}" etc) and rely on indentation to convey meaning. ie they drop
all the syntactic cruft.

The resulting pseudocode is almost executable python. The upshot is that
many programmers speak python natively when asked to describe what they
want to do. A lisp/scheme-esque equivalent might be more like:

plus:
times:
1 2
minus:
10 2

However you don't see that. It's not the sort of thing that you see most
programmers writing - unless they're trying to figure out a parse tree.

Furthermore, depsite Scheme/lisp appearing less ambiguous, "everything has
the same construct", to many new programmers (I've taught introductory
programming to new users) the more punctuation you have, the more confused
they get. This is particularly true if you try teaching programming to
non-science (graduate level) students.

And whilst this might seem a trivial point, it's worth remembering that
new users generally don't interpret things you expect. For example:

if x is not None:
print "hello"
else:
print "Goodbye"

Looks pretty unamiguous to a programmer's eyes. The most interesting
description I've heard from a non-programmer looking at that is:
"If x is something, print 'hello' and if that fails print 'goodbye'"
ie something semantically more like:

if x is not None:
try:
print "hello"
except:
print "Goodbye"

Adding brackets to this gains a new programmer *nothing* and for the
majority of cases the extra syntax gets in the way.

To my mind, bringing these two halves back together, python is the
language of choice simply because it's inately programmer friendly and
*encourages* clean code(*), with these attributes working together to make
it easier to deliver code that works, and is maintainable.
(*) Like functional languages

Finally the real killer point with python is the ability to use things
like Pyrex to be able to augment python code with types so that
compilation to C is trivial, and effective. This means you can explore
a half dozen potential implementations, pick the most effective or
maintainable and optimise using Pyrex should it become necessary.

And what benefit does that bring? It brings the academic and non-academic
worlds closer together - bringing cold hard shocks and benefits to both
sides.

Regards,


Michael.

[Michele Simionato]

Post by François Pinard
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).

Post by François Pinard
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