Python and Ruby

[Jonathan Gardner]

If you get rid of the syntax specific to Perl, then having to explicitly
obtain a function reference, or to dereference the result, is not such a big
deal:

 foo          # Call 'foo' with no args.
 bar = foo    # Call 'foo; with no args, assign to 'bar'
 bar = &foo   # Don't call 'foo', but assign a pointer to it to 'bar'
 bar^         # Call whatever 'bar' is pointing at with no args

(Here I use ^ instead of -> to dereference.)  Compared with Python, it saves
3 lots of (), but needs & and ^ added. Still a net saving.

On one shoulder, a demon taunts the programmer: "Ohmygosh, you can
save three keystrokes if you introduce an entirely new syntax with odd
squiggles that make no pronounceable sound in the English language!
Perhaps one day, you can program APL in Python!"

The angel that sits on the other shoulder says, "Alas, poor
programmer, one day, you'll have to read that and understand it. And
heaven help us when we hire a poor college graduate to maintain the
code we wrote five years ago. Or worse, when that poor college
graduate writes code and expects us to read it!"

Thankfully, Guido has banished that demon from the realm of Python a
long time ago.

I'd say that having this "&" symbol in front of "foo" makes it more obvious
than just foo by itself. But I agree not quite as clean.

Another thing is that you have to know whether "bar" is a function, or a
function ref, and use the appropriate syntax. Sometimes this is helpful,
sometimes not.

Thankfully, in Python, everything is a ref, so everything is
consistent.

 

[Jonathan Gardner]

That's not a particularly good metric, IMHO.

A simple "core" language doesn't necessarily make a language simple to
use. You can explain the entirety of pure lambda calculus or combinators
in five minutes, but you wouldn't want to write real code in either (and
you certainly wouldn't want to read such code which was written by someone
else).

For a start, languages with a particularly simple "core" tend to delegate
too much to the library. One thing which puts a lot of people off of
lisp is the lack of infix operators; after all, (* 2 (+ 3 4)) works fine
and doesn't require any additional language syntax. For an alternative,
Tcl provides the "expr" function which essentially provides a sub-language
for arithmetic expressions.

A better metric is whether using N features has O(N) complexity, or O(N^2)
(where you have to understand how each feature relates to each other
feature) or even O(2^N) (where you have to understand every possible
combination of interactions).


Not once you move beyond the 10-minute introduction, and have to start
thinking in terms of x + y is x.__add__(y) or maybe y.__radd__(x) and also
that x.__add__(y) is x.__getattribute__('__add__')(y) (but x + y *isn't*
equivalent to the latter due to __slots__), and maybe .__coerce__() gets
involved somewhere, and don't even get me started on __metaclass__ or
__init__ versus __new__ or ...

Yes, the original concept was very nice and clean, but everything since
then has been wedged in there by sheer force with a bloody great hammer.

I strongly suggest you read the documentation on these bits of Python.
If you're scared of __new__ versus __init__, then you haven't been
programming very long in any language. There is a case when you need
one over the other. The same goes for the other concepts.

Programming languages that don't provide these features (like
Javascript) are nice for toy programs, but lack the power to
accommodate the needs of large apps.

 

[Steve Holden]

Compare with Python's syntax.

# The only way to assign
a = b

# The only way to call a function
b(...)

# The only way to access a hash or array or string or tuple
b[...]

For all of your examples, there are other ways supported. I do wish this
focus on “only way†would depart, it's a fallacy and not helpful.

And besides which most people get the quote wrong. The "authoritative"
version from the Zen is, as you clearly already know

There should be one-- and preferably only one --obvious way to do it.

What is important (and supports the main point of your message) is that
for each of the above, whether or not they are the only way, they are
the one *obvious* way to do the operation.

Quite.

People might be interested to know the history of the Zen, which I got
directly from Tim Peters over lunch one day. It was composed,
apparently, during the commercial breaks one evening while he was
watching professional wrestling on the television!

So it's wise not to take the Zen too seriously. It wasn't written to
guide, but to amuse. The fact that it can do both is a testament to
Tim's sagacity.

regards
Steve

 

[sjdevnull]

FYI: the language is called Perl, the program that executes a Perl
program is called perl.

It should be $bar = \&foo
Your example actually calls foo...

I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.

The syntax follows that of referencing and dereferencing:

$bar = \@array;       # bar contains now a reference to array
$bar->[ 0 ];          # first element of array referenced by bar
$bar = \%hash;        # bar contains now a reference to a hash
$bar->{ key };        # value associated with key of hash ref. by bar
$bar = \&foo;         # bar contains now a reference to a sub
$bar->( 45 );         # call sub ref. by bar with 45 as an argument

Consistent: yes. New syntax? No.

Except for the following symbols and combinations, which are entirely
new and different from the $@% that you have to know just to use
arrays and hashes.

\@, ->[ ]
\%, ->{ }
\&, ->( )

By the way:
* How do you do a hashslice on a hashref?
* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?

Compare with Python's syntax.

# The only way to assign
a = b b

# The only way to call a function
b(...) 6

# The only way to access a hash or array or string or tuple
b[...]

b={}
b[1] = 'a'
print b.__getitem__(1)

a

 

[bartc]

On one shoulder, a demon taunts the programmer: "Ohmygosh, you can
save three keystrokes if you introduce an entirely new syntax with odd
squiggles that make no pronounceable sound in the English language!
Perhaps one day, you can program APL in Python!" ....
Thankfully, Guido has banished that demon from the realm of Python a
long time ago.

You mean & (bitwise AND in Python) and ^ (bitwise XOR in Python)?

 

[John Bokma]

I can explain, in an hour, every single feature of the Python language
to an experienced programmer, all the way up to metaclasses,

Either you're a hell of a talker, or I am far, far away from being an
experienced programmer. It's advocacy like this, IMO, that keeps people
away from a language, because you can't feel nothing but a failure after
a statement like this.

 

[John Bokma]

[..]

It should be $bar = \&foo
Your example actually calls foo...

I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.

Uhm, in another post you wrote that you could explain Python in an hour
to an experienced programmer and you *still* make mistakes like that in
Perl!?

By the way, the language is called Perl. If you write "I've been
programming perl" in a Perl related group some people might read it as
that you've been working on the internals of the perl executable (in C)

One is simple, consistent, and easy to explain. The other one requires
the introduction of advanced syntax and an entirely new syntax to make
function calls with references.

The syntax follows that of referencing and dereferencing:

$bar = \@array;       # bar contains now a reference to array
$bar->[ 0 ];          # first element of array referenced by bar
$bar = \%hash;        # bar contains now a reference to a hash
$bar->{ key };        # value associated with key of hash ref. by bar
$bar = \&foo;         # bar contains now a reference to a sub
$bar->( 45 );         # call sub ref. by bar with 45 as an argument

Consistent: yes. New syntax? No.

Except for the following symbols and combinations, which are entirely
new and different from the $@% that you have to know just to use
arrays and hashes.

\@, ->[ ]

@array, one item: $array[ 1 ];
$arrayref, one item: $arrayref->[ 1 ];

\%, ->{ }

%hash, one item: $hash{ key };
hence: $hashref, one item: $hash->{ key }

\&, ->( )

should now be clear ;-)

You *should* have no problem with that if you have been
programming professionally Perl since 2000 IMNSHO. Otherwise print my
post or copy it on a post-it note ;-).

Remember that all this was added to Perl in version 5. So it had to be
added in a way that wouldn't break Perl 4. Perl is, in my experience
quite good in backwards compatibility. Quite some Perl modules on CPAN
work from 5.00x-5.10 and most likely will work without trouble in 5.12.

By the way:
* How do you do a hashslice on a hashref?

I will reply like it's a genuine question, and not like "Oh, look, how
silly Perl works". I don't care about that much. I do like Perl and am
starting to like Python.

@$hashref{ 'key1', 'key2', 'key3' };

* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?

I guess you mean:

$hashref->{ key }[ index ]( arguments );

The long version is:

$hashref->{ key }->[ index ]->( arguments );

[ Python advocacy snipped]

I'd rather think of the task at hand than what each of the funky
symbols on my keyboard mean.

Then just quit programming Perl ;-) Perl has always come naturally to
me, no idea why. Recently I said to a close friend:

Python is like my desk, which I prefer to keep clean and neat.
Perl is like my livingroom, which I prefer to keep clean and neat to
some extend, but some mess is allowed. For example, the cat can be
there. Toys of my daughter are allowed to be all over the place. A
pleasant mess, but not too much.

I won't repeat what I said about PHP ;-).

 

[Dennis Lee Bieber]

So it's wise not to take the Zen too seriously. It wasn't written to
guide, but to amuse. The fact that it can do both is a testament to
Tim's sagacity.

It also does to keep Python separate from the SF/F books... The
guiding principle of the kingdom of Valdemar (Mercedes Lackey's
"Heralds" books) is "There is no one true way" <G>

 

[Steven D'Aprano]

Either you're a hell of a talker, or I am far, far away from being an
experienced programmer. It's advocacy like this, IMO, that keeps people
away from a language, because you can't feel nothing but a failure after
a statement like this.

Surely you're exaggerating?

Without making any aspersions towards Jonathan either way, the Internet
is full of both blowhards and geniuses. Anyone who lets the off-the-cup
claims of either ruin their self-confidence is unlikely to be thinking
about learning Python, they're probably sitting alone in a dark room
staring as the walls close in.

Either that or on MySpace.

 

[John Bokma]

Surely you're exaggerating?

No, because if I was I would've put a smiley there somewhere. I am
learning Python, for a time to be honest. I can manage in the language
quite well.

I consider myself quite an experienced Perl programmer, I have no
problems with the constructs Jonathan elsewhere in this thread claims to
have problems with after 10 years of professional Perl programming. They
come natural to me. But I don't see myself being able to understand
every Python feature in a talk of an hour *with* the current
understanding of Python I have (read halfway through Programming In
Python 3, read selected chapters on decorators, etc.).

Without making any aspersions towards Jonathan either way, the Internet
is full of both blowhards and geniuses. Anyone who lets the off-the-cup
claims of either ruin their self-confidence is unlikely to be thinking
about learning Python, they're probably sitting alone in a dark room
staring as the walls close in.

I am quite serious about learning Python, I do write professionally in
it [1], but I am convinced that I need at least several months more of
studying to feel comfortable with most (not even all) of Python.

To me a much more relastic view on learning a programming language is:
http://norvig.com/21-days.html

[1] very small programs, and my customer is fully aware of that I am
learning a new language but trust me, which is great.

 

[John Bokma]

No, because if I was I would've put a smiley there somewhere. I am
learning Python, for a time to be honest. I can manage in the language
quite well.

Clarification: for a beginner that is.

[1] very small programs, and my customer is fully aware of that I am
learning a new language but trust me, which is great.

Should've been "but trusts me,".

 

[Timothy N. Tsvetkov]

Are you sure about that?

There's a lot of line noise in Ruby. How are you supposed to pronounce
"@@"? What about "{|..| ... }"?

There's a lot of "magic" in Ruby as well. For instance, function calls
are made without parentheses. Blocks can only appear as the first
argument. There's a lot more, if you put your mind to it.

Indentation is also optional in Ruby. You can quickly fool a newbie by
not indenting your code properly, which is impossible in Python.

Python is much, much cleaner. I don't know how anyone can honestly say
Ruby is cleaner than Python.

I will. I developed on both (Python was first) and I think that ruby I
very clean and maybe cleaner than Python. Also I don't know any
situation where you need to pronounce your code symbol by symbol. You
might need to pronounce some semantics.

And you're wrong with blocks.

About indent your right. It helps newbies indent code becouse they
must to. But most of professional developers started with Pascal and
then C and they all indent well it is about culture and it is what
about teacher should say.

 

[Jonathan Gardner]

Either you're a hell of a talker, or I am far, far away from being an
experienced programmer. It's advocacy like this, IMO, that keeps people
away from a language, because you can't feel nothing but a failure after
a statement like this.

I can explain all of Python in an hour; I doubt anyone will understand
all of Python in an hour.

Coming from perl to python, the big "aha!" moment was when I realized
there wasn't anything more than what I saw before me. I kept expecting
something big around the corner, kind of like when I first discovered
refs in perl, or when I realized how hard it truly was to write OO
code in perl that actually does what you think it should do.

Perl has trained me to be fearful of the language, constantly on the
lookout for jabberwockies. If you fall into one of those traps in
perl, it's because you weren't smart enough and aren't worthy of the
language, or so they say. It's never perl's fault. I mean, doesn't
everyone know what the Schwartzian Transform is?

Python is the complete opposite. Go through http://docs.python.org/reference/
.. Once you've familiarized yourself with all the operators,
statements, and the special methods, you're done with syntax and the
core language. There is no more.

The next step is to learn the basic objects and functions in builtins.
That's in the first seven chapters of http://docs.python.org/library/index.html.
You can always fall back to the "help" function to remind yourself if
you forget. I do it all the time.

After that, it's merely figuring out which standard libraries do what
and how. The documentation there is complete and awesome, and there
are more than enough people willing to point you in the right
direction here.

There are no dragons in this forest. Heck, this isn't even a forest---
it's a single-room apartment with everything you need right there
where you can see it. The thermostat is set to room temperature, and
no matter what happens outside, you're safe and protected from it all.

 

[Robert Kern]

I can explain all of Python in an hour; I doubt anyone will understand
all of Python in an hour.

With all respect, talking about a subject without a reasonable chance of your
audience understanding the subject afterwards is not explaining. It's just
exposition.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Lou Pecora]

I can explain all of Python in an hour; I doubt anyone will understand
all of Python in an hour.

Coming from perl to python, the big "aha!" moment was when I realized
there wasn't anything more than what I saw before me. I kept expecting
something big around the corner, kind of like when I first discovered
refs in perl, or when I realized how hard it truly was to write OO
code in perl that actually does what you think it should do.

Perl has trained me to be fearful of the language, constantly on the
lookout for jabberwockies. If you fall into one of those traps in
perl, it's because you weren't smart enough and aren't worthy of the
language, or so they say. It's never perl's fault. I mean, doesn't
everyone know what the Schwartzian Transform is?

Python is the complete opposite. Go through http://docs.python.org/reference/
. Once you've familiarized yourself with all the operators,
statements, and the special methods, you're done with syntax and the
core language. There is no more.

The next step is to learn the basic objects and functions in builtins.
That's in the first seven chapters of
http://docs.python.org/library/index.html.
You can always fall back to the "help" function to remind yourself if
you forget. I do it all the time.

After that, it's merely figuring out which standard libraries do what
and how. The documentation there is complete and awesome, and there
are more than enough people willing to point you in the right
direction here.

There are no dragons in this forest. Heck, this isn't even a forest---
it's a single-room apartment with everything you need right there
where you can see it. The thermostat is set to room temperature, and
no matter what happens outside, you're safe and protected from it all.

That's a pretty accurate description of how I transitioned to Python
from C and Fortran. I kept trying to think of how to output data and
parameter variables of different types to files for later reading in.
How to format them all consistently and then get them back in with the
exact same accuracy. I was stuck in printf and scanf land. Then after
much noodling around and reading it hit me that I could just put all
that output of different types of variables into a list, hit it with a
repr() function to get a string version, and write the string to a file
-- no formatting necessary-- three lines of code. Later reading in the
string version (no formatting necessary), and hitting it with an eval()
function returned all the values I originally had in those variables.
How simple, but beautiful. I was making it harder when Python was
making it easier. Trained on the wrong language.

 

[John Bokma]

I can explain all of Python in an hour;

OK, in that case I would say give it a go. Put it on YouTube, or write a
blog post about it (or post it here). I am sure you will help a lot of
people that way.

Coming from perl to python, the big "aha!" moment was when I realized
there wasn't anything more than what I saw before me. I kept expecting
something big around the corner, kind of like when I first discovered
refs in perl, or when I realized how hard it truly was to write OO
code in perl that actually does what you think it should do.

There are very nice frameworks to help you (e.g. Moose). OO is not that
hard IMO, but I can imagine it's very hard if you don't understand
references sufficiently.

Perl has trained me to be fearful of the language, constantly on the
lookout for jabberwockies. If you fall into one of those traps in
perl, it's because you weren't smart enough and aren't worthy of the
language, or so they say.

Odd, you gave me the same feeling when you stated you could explain me
all features of Python in an hour.

It's never perl's fault. I mean, doesn't everyone know what the
Schwartzian Transform is?

Doesn't everyone know what the big O notation is? I mean, Schwartzian
transform is not unique to Perl, and it strikes me as odd that you think
it is. It's all about understanding that general sort on average is O(n
log n), and hence does O(n log n) comparisons. Which means that if you
do an expensive calculation in a custom compare function or do a lot of
comparisons it might be cheaper to do precalculate the keys
(O(n)). Randal Schwartz was the person who made this idea popular in the
Perl community, hence the Perl community named it after him, but it was
long known before that and used in other languages.

[How to learn Python]
I am fully aware of how to learn a language, I've done so several times
(or many times even). I only disagree with your statement that you can
explain all features of Python to me in an hour. But I love to be wrong
on this, and to stand corrected.

There are no dragons in this forest. Heck, this isn't even a forest---
it's a single-room apartment with everything you need right there
where you can see it. The thermostat is set to room temperature, and
no matter what happens outside, you're safe and protected from it all.

Why does this sound like some religious speech?

I always say: if there was a really easy to learn programming language,
I would be programming in it. And no, I don't think Python is it. (Nor
Perl for that matter). I do agree that Python /looks/ more simple (and
certainly cleaner, unless you're using regexp a lot) than Perl, and
certainly to some extend Python /is/ simpler. But in my (relatively long
experience) programming boils mostly down to which libraries you know,
and how well you can use them.

Finally, note that simpeler doesn't always make your code more easy to
grasp. There is a reason that human languages are rich and often have
many ways to say something. Programming, after all, is also
communication with other humans (if only with one self).

 

[Paul Rubin]

after much noodling around and reading it hit me that I could just put
all that output of different types of variables into a list, hit it
with a repr() function to get a string version, and write the string
to a file -- no formatting necessary-- three lines of code. Later
reading in the string version (no formatting necessary), and hitting
it with an eval() function returned all the values I originally had in
those variables. How simple, but beautiful.

FYI: I do that too sometimes, but in general using repr/eval that way
is poor style and not very reliable. It's better to use the pickle
module, which is intended for that sort of thing, or the json module
if your datatypes are suitable and you want to follow a semi-standard.

 

[Steve Holden]

With all respect, talking about a subject without a reasonable chance of
your audience understanding the subject afterwards is not explaining.
It's just exposition.

I agree. If the audience doesn't understand then you haven't explained it.

regards
Steve

 

[John Bokma]

That's a pretty accurate description of how I transitioned to Python
from C and Fortran.

Not C, but C++ (but there are also C implementations): YAML, see:
http://code.google.com/p/yaml-cpp/wiki/HowToParseADocument

I use YAML now and then with Perl for both reading/writing data and for
debugging purposes (YAML is quite human readable, for programmers at least)

Of course there is also YAML support for Python:
http://pyyaml.org/.

 

[alex23]

I developed on both (Python was first) and I think that ruby I
very clean and maybe cleaner than Python.

And you're wrong with blocks.

You say 'static', and I say 'dynamic'.
You say 'consistent', and I say 'erratic'.
Static! Dynamic!
Consistent! Erratic!
Let's join the right news group.