Typed Python?

[Christophe Cavalaria]

C/C++:

------

#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);
}

 

[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

 

[Hung Jung Lu]

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

In the early days of pocket calculators, Texas Instruments had all
these RPN (reverse Polish notation) models. Now, many people argued
that computationally RPN made more sense. But the market has spoken
otherwise. No matter how much sense it may make in theory, in practice
the majority of people will NOT buy nor use a RPN calculator. 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.

Trust me. Codeblocks, not Lisp/Scheme's PN expressions, are the way of
the future. It's very simple logic: people want machines to act more
like people, they don't want to be told to act more like machines.
Again, RPN calculators are a good example.

regards,

Hung Jung

 

[Arthur]

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

The TeachScheme project is pretty explicit in targetting high school
and up, so targetting 12 year olds is not in its scope. Having a scope
seems to indicate that some thought has been given, or experimentation
done, about age appropriateness To me, a sign of maturity of
approach.

Wild claims are made about the age appropriate range of Python
learning, with next to nothing to back those claims.

That being said, I can certainly understand being turned off by some
of the Talk you cite.

A good deal of embedded hype, of its own.

Knowing that that kind of thing goes on around the TeachScheme project
is one reason I find it hard to fully embrace.

My own ideal would be an approach that probably did in the end center
around Python, but that was itself less hype ridden. Less glib use
of the word "Easy", for example. Age appropriatenss ideas based on ,
well, something.

Art

 

[Paul Rubin]

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.

In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.

Scientific users still often prefer RPN. Business users might prefer
algebraic to RPN, but for that matter they're likely to prefer Cobol
(or Java or whatever they call it now) over Python.

 

[Arthur]

In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.

Academia and business have very different reasons for being, or
should.

Part of the problem here is in fact taking valid lessons learned in
HCI for - say - business users, and then making invalid assumptions as
to what those lessons mean in a learning process in an academic
setting.

We can't expect those who control the realm of the business interface
to help us make the distinction. We could more likely expect them to
help misdirect the process, with and without subtlety.

All of which relates back to why the word "easy" disturbs me so much.
I'm not sure a process which involves the goal of learning is ever the
easist way from here to there.

It is *easiest* not to learn programming at all. And one gets by with
that fine.

Art

 

[Ville Vainio]

Arthur> On 05 Jul 2004 21:08:35 +0300, Ville Vainio <[email protected]>
Arthur> wrote:

Arthur> Wild claims are made about the age appropriate range of
Arthur> Python learning, with next to nothing to back those
Arthur> claims.

I would expect Python to be easier than the line numbered Basic
horrors that kids (including your truly) polluted their brains with
back in the eighties. The only problem is the lack of native language
(as in non-english) documentation. This should be easy to fix - some
pedagogic specialist write a simple tutorial that is short enough to
translate quickly, and people translate it.

After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding .

Arthur> My own ideal would be an approach that probably did in the
Arthur> end center around Python, but that was itself less hype
Arthur> ridden. Less glib use of the word "Easy", for example.

Into dull professionalism, are we ;-)? I bet the phenomenon you
observe is because many of us are not interested in education as such,
it's just awe-inspiring to imagine all the fun those kids could have
with Python, compared to POS languages we've had to use.

 

[Paul Rubin]

I would expect Python to be easier than the line numbered Basic
horrors that kids (including your truly) polluted their brains with
back in the eighties.

I'm not really convinced of that, at least for the simplest types of
programming.

 

[Jorge Godoy]

After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding .

Hey! How are they going to code OpenGL stuff nicely if they don't have a
good video adapter to try it? ;-)


With regards to small tutorials there are some of them even in other
languages other than in English. Take a look at the python.org website and
you'll see non-English docs linked there --- and also in some of the
English documents...

 

[Arthur]

After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding .

What they do on their own time ...

Certainly no Windows desktops allowed in school.

Though if the criteria is what's easiest, I probably lose my case.


Art

 

[Steve Lamb]

Certainly no Windows desktops allowed in school.

Though if the criteria is what's easiest, I probably lose my case.

Not rally. There have been studies that show that Linux in general is no
harder than Windows for kids who have had no prior experience with computers
to pick up. Some, in fact, have shown that it is easier because of the
consistent behaviors which are sorely lacking in Windows.

 

[Arthur]

Not rally. There have been studies that show that Linux in general is no
harder than Windows for kids who have had no prior experience with computers
to pick up. Some, in fact, have shown that it is easier because of the
consistent behaviors which are sorely lacking in Windows.

I'm not comitted to this yet, but I don't think my school desktop has
a mouse. Well maybe for special occassions.

In which case I guess Windows does end up losing on the easiness
scale.

Art

 

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

 

[Donn Cave]

Quoth Paul Rubin <http://[email protected]>:
| (e-mail address removed) (Hung Jung Lu) writes:
| > 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.

Mine was an HP. It was great, would still use it today if
someone hadn't stolen it. (So then I bought an inexpensive
slide rule, which has served me pretty well and has evidently
never tempted any thief.)

|> In academia all this is fine and dandy. In business, igonoring
|> user-friendliness means... well, no business. RPN calculators are a
|> good example.
|
| Scientific users still often prefer RPN. Business users might prefer
| algebraic to RPN, but for that matter they're likely to prefer Cobol
| (or Java or whatever they call it now) over Python.

Or C++. User-friendliness rules.

Seriously, I heard some years back that Smalltalk was at the time
rather popular for certain kinds of business applications. Is
Smalltalk "user friendly", or is it the programming equivalent of
reverse polish notation? 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, (e-mail address removed)

 

[Hung Jung Lu]

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

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_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.

 

[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

 

[Jacek Generowicz]

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]

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

 

[Jacek Generowicz]

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

What's with the pesky underscores ?

It's:

(is-better-structured-as "(set! x 10)" "x=10")

And anyway, that's pretty meaningless. It really should be:

(is-better-structured-than? "(set! x 10)" "x=10") => T

I hope that's perfectly clear to everyone now


PS: The self evident truth of the resurt is demonstrated by the
fact that it could (meningfully) be written:

(is-better-structured-than? '(set! x 10) "x=10") => T

The difference in the quotes used is subtle, but _extremely_
important.