Python vs. Io

[Jp Calderone]

What are you talking about? There's tons of new "magical syntax" in
Python. Examples for "magical syntax" features that don't work on
1.5.2 include:
*List comprehensions

Yep.

*String methods

Nope. The syntax is identical. Strings just happen to have more useful
attributes new.

*Generators

Yep.

*Emulating numeric types

Nope. Never seen __coerce__?

*Nested scopes

Hmm. Not really a syntactic difference... The syntax is the same, after
all, but the behavior is definitely different.

* * and ** in function declarations

Yep.

*for line in this_file

Nope. Same as with strings, the iterator protocol, a set of methods with
a defined meaning, was added, and file objects were made to implement it.
No syntactic changes.

*Subclassing types

This is another iffy one. The syntax is no different, the behavior has
just been changed. "str", "int", etc, used to be builtin functions, not
type objects. You also couldn't subclass types in Python, but if you could
have, the syntax would have been identical to what it is today.

There's tons of stuff still being added to Python.

Definitely. But "stuff" isn't always the same as "magical syntax".

Jp

 

[Sean Ross]

[snip]

What are you talking about?

[snip]

Syntax that can be used on one Python x.y.z installation, can
be used on another installation of the _same_ version (x.y.z)
of Python.

 

[Paul Prescod]

I've always presumed that if I wanted an ultra-pure OO language I would
use Smalltalk. Obviously IO's big difference is prototype rather than
class-based inheritance. But that's a difference, not (necessarily) a
benefit. Could you please describe what would attract one to IO over
Smalltalk?

Paul Prescod

 

[Andrew Bennetts]

What are you talking about? There's tons of new "magical syntax" in
Python. Examples for "magical syntax" features that don't work on
1.5.2 include:

[...]

* * and ** in function declarations

Yep.

* and ** in function _calls_ is new in 2.0, but in declarations was already
there in 1.5.2:

bash-2.05b$ python1.5
Python 1.5.2 (#0, Jul 5 2003, 11:45:08) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam.... print args, kwargs
....
-Andrew.

 

[Daniel Ehrenberg]

Do you know why the creator of IO decided not to use the now-ubiquitous

"." operator? I don't know whether I can define a "." operator that has
the appropriate behaviour but that wouldn't help anyhow.

Paul Prescod

In the opinion of the creators of Io, a space looked cleaner. Using a
period looks kinda like you're finishing a sentence and starting a new
one. Consider the following syntaxes:

Dog barks //Io
Dog.barks() #Python

Regardless of which one is more common, which looks more like
language?
You say that "." is more ubiquitous, but "{}" is more ubiquitous than
":" by far, yet Python uses the latter and we don't complain. (note
that in Io, unlike other languages with similar syntax such as Ruby,
functions are first class objects.)

Daniel Ehrenberg

 

[Daniel Ehrenberg]

[snip]

Definitely. But "stuff" isn't always the same as "magical syntax".

Jp

By that logic, anything that can be implimented in the language isn't
"magical syntax". In Io, there is no difference between flow control
and functions, so it's not "magical syntax" and it's just "stuff".

Daniel Ehrenberg

 

[Daniel Ehrenberg]

Okay. So, if I set 'self id', like so

self id := allocated

and want to update it later in the same block I can use

id = "updated self 'id' slot value"

But, if I later use

id := "set new local 'id' slot value"

Yes, but code like that is confusing and shouldn't be used unless you
need to.

in the same block I get a new local variable. Is that how it works?
Or does the first use of a slot determine its assignment scope
for the duration of the block?

self a := "unchanged"
a := "changed"
write("self a is ", self a) # changed or unchanged?

unchanged.

If you want to learn more about Io, you should probably join the Io
mailing list instead of bothering the whole usenet thread. Its website
is http://groups.yahoo.com/group/iolanguage/ .

Daniel Ehrenberg

 

[Christopher Koppler]

In the opinion of the creators of Io, a space looked cleaner. Using a
period looks kinda like you're finishing a sentence and starting a new
one. Consider the following syntaxes:

Dog barks //Io
Dog.barks() #Python

Regardless of which one is more common, which looks more like
language?

Looking like natural language is *not* necessarily a good thing in
programming languages.

 

[Daniel Ehrenberg]

Regardless of which one is more common, which looks more like

Looking like natural language is *not* necessarily a good thing in
programming languages.

Ok, which one looks more intuitive, then? Both languages are
turing-complete and Io's easy syntax doesn't hamper it in the way that
BASIC's intuitive but limited syntax does.

Daniel Ehrenberg

 

[Josiah Carlson]

As mentioned by Sean Ross, I was talking about Python x.y compatibility
with other copies of version x.y. With the way you describe IO, it
encourages people to customize flow control and syntax. Such
customization does not necessarily increase readability, usability, or
write-once-run-anywhere with IO version u.v. It may also fragment the
language in the long run into different camps; those that like the slim
version, and those that like a version with every modification they can
find.

- Josiah

 

[Daniel Ehrenberg]

I've always presumed that if I wanted an ultra-pure OO language I would

use Smalltalk. Obviously IO's big difference is prototype rather than
class-based inheritance. But that's a difference, not (necessarily) a
benefit. Could you please describe what would attract one to IO over
Smalltalk?

Paul Prescod

In short, Io isn't as "ultra-pure" as Smalltalk. Here are some things
that Io supports and Smalltalk doesn't:
*Standard operator precedence
*Normal function syntax
*Standalone functions
*Everything is public (like Python)
*Interpreted and no monolithic system image like Smalltalk
*Better block syntax (no cryptic square brackets or variable symbols)
*Prototypes (which *is* a benefit, not just a difference)
*Not obsessively object oriented (for stuff like flow control)
*Growing, not shrinking community
*Inplace mathematical operations
*Much smaller implimentation and good for embedding
*More flexible for syntax extension
*Everything is anonymous (yet there is still some introspection for
names)
*Functions are first class objects, not merely messages
*The ability to change what it inherets from
*More flexible scoping
*Writing self can be left out when sending messages to the current
object
*Speed on par with Python
*Optionally non-strict functions (but usually strict anyway)

Note that Python lacks some of these things too.

Daniel Ehrenberg

 

[Paul Prescod]

...

In the opinion of the creators of Io, a space looked cleaner. Using a
period looks kinda like you're finishing a sentence and starting a new
one. Consider the following syntaxes:

Dog barks //Io
Dog.barks() #Python

Regardless of which one is more common, which looks more like
language?

The space "operator" is used in way too many different ways in language.
Consider these two grammatical sentences:

The Dog barks. (how IO uses the space)
The Dog Spot. (how Java/C/C++ use the space)

But anyhow I'm not going to argue that IOs choice is wrong, just
confusing at first.

You say that "." is more ubiquitous, but "{}" is more ubiquitous than
":" by far, yet Python uses the latter and we don't complain. (note
that in Io, unlike other languages with similar syntax such as Ruby,
functions are first class objects.)

First, if I had invented Python I would not have bothered to buck the
trend of using curly braces. Hardly anyone chooses Python because of
that feature and some are turned off by it. Python makes tons of
conservative, "traditional" choices and I think that they do have
something to do with its current level of popularity. Sometimes Python
even hides pretty radical semantics under "traditional" syntax (e.g. []
as sugar for getitem). Ruby takes this even farther. If I were in charge
of IO I might do that too. e.g. make {} sugar for a last argument that
is a statement list or something.

Second, I think that the meaning of Python's colon is unuusal but
self-evident. I personally decided to learn Python because I stumbled
upon some code that looked exactly pseudo-code and wondered what
language I was reading. Coming from (e.g.) Java or C++, most of Python's
surfact syntax is self-evident to the English speaker, even when
different (e.g. "or" instead of "||").

Language design is like music composition. You must be better than your
competitors but no so much better (i.e. different) that you just seem
"weird". Judging the right balance is not easy.

Paul Prescod

 

[Daniel Ehrenberg]

As other posts have indicated, this is not the io-user-list. While

you probably have good, purely academic intentions with your post,
this is not the correct forum. Create an io-vs-python list somewhere
and I'm sure you'll get a few subscribers.

Io vs. Python is a very narrow topic and not fit for a mailing list.
There have been many repetitive Python vs. Ruby threads and nobody
made this complaint. When somebody asks a question about using the
Zope CMF, people don't say "go make a zope-cmf mailing list", they
give a constructive response.

Daniel Ehrenberg

 

[Andrew Henshaw]

Paul Prescod wrote:

....snip...

First, if I had invented Python I would not have bothered to buck the
trend of using curly braces. Hardly anyone chooses Python because of
that feature and some are turned off by it.

....snip...


Not that this invalidates your point, as I still fall into the category of
'hardly anyone'; but, the indentation-identified block is precisely the
reason I first tried Python. Having used Occam for many years, I was very
pleased to find a language that recognized the superiority of that style.


--Andy

 

[A. Lloyd Flanagan]

Can anyone show me how to so much as alias "for" to "each" in Python
or allow block syntax at all without hacking the C source code?

I think the point is, why on earth would you want to do something like
that? If you want a language you can use to make programs that make
no sense to anyone but the author, Perl should be more than sufficient
for your needs.

 

[Dang Griffith]

On 29 Jan 2004 13:01:06 -0800, (e-mail address removed) (Daniel
Ehrenberg) wrote:

....

Can anyone show me how to so much as alias "for" to "each" in Python
or allow block syntax at all without hacking the C source code? ....
Many users of Io (myself included) have switched over from Python for
these reasons.

If you've switch from Python to Io, what will you do with the answers
to these questions? Use them for good or evil? Will you switch back
from Io to Python?
--dang

 

[Terry Carroll]

First, if I had invented Python I would not have bothered to buck the
trend of using curly braces. Hardly anyone chooses Python because of
that feature and some are turned off by it.

I have to admit that the indentation feature turned me off at first, but
having used Python for a while now, I find that method superior to the
curly braces approach. Much more DWIM.

 

[John Roth]

First, if I had invented Python I would not have bothered to buck the
trend of using curly braces.

I suppose I am hardly anyone else, since that it exactly what
attracted me to Python. In fact, I will take partial responsibility
for the indentaion syntax in IBM's ISPF mini-language - it's a
preferance of long standing with me.

Now that I actually have a significant language using them, I
can see that there are a couple of things they make more
difficult, statement syntax embedded within expressions being
one. The other is a rather esoteric issue with clauses like
elif, else and except.

John Roth

 

[Hannu Kankaanp??]

I think the point is, why on earth would you want to do something like
that? If you want a language you can use to make programs that make
no sense to anyone but the author, Perl should be more than sufficient
for your needs.

The point is that implementing your own "for" is something you can't
do in Python very nicely, so it's a proof that Io can achieve
genuinely higher abstraction levels on this part. Implementing
"for" again with a new name probably wouldn't make anyone
happy, but such power opens a set of tricks and idioms to
be used in real code to solve real problems, that wouldn't
be possible in Python without kludgy syntax.

Here's a normal loop:

bar = 0
for x in range(10):
bar += x

Here's the same using a custom loop:

bar = [0]
def temp(x):
bar[0] += x
for_each(range(10), temp)

That is just so damn ugly. I want to be able to define (e.g.)

bar = 0
for_each(x, range(10)):
bar += x

Now tell me which of these two lowermost forms looks
better and makes more sense? For examples that don't
just make aliases of existing syntax, see the
Lisp vs Python thread that was here a few months ago
(sorry, can't remember it's topic name).

BTW, Python can be used to make programs that make
no sense as well. (due to Ulf Bartelt

print (lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,fk<=0)or (x*x+y*y

=4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(

64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24)

The real question is if the language *allows* a sensible
programmer to write clear, understandable code even in hard
problem domains.

But this is nothing but my humble opinion without actually
knowing anything about Io.. Maybe it isn't that good. I wasn't
really arguing for Io but for better abstractions.

 

[Paul Prescod]

I suppose I am hardly anyone else, since that it exactly what
attracted me to Python. In fact, I will take partial responsibility
for the indentaion syntax in IBM's ISPF mini-language - it's a
preferance of long standing with me.

There are certainly costs and benefits to the Python way. And we've been
over them many times.

I'm just saying that from a language popularity point of view,
"different" is usually perceived as "worse" unless it is really vastly
better.

Paul Prescod