syntax philosophy

[Alan Kennedy]

[Tuang wrote]
> I'm checking out Python as a candidate for replacing Perl as my "Swiss
> Army knife" tool. The longer I can remember the syntax for performing
> a task, the more likely I am to use it on the spot if the need arises.
> If I have to go off and look it up, as I increasingly have to do with
> Perl's ever hairier syntax, I'm more likely to just skip it, making me
> even less likely to remember the syntax the next time.

and

[Tuang wrote]
> Imagine that you have a list of records -- lines in a text file will
> do fine. Let's say each record is a person and you're interested in
> favorite colors.
> 
> You iterate thru the lines, regexing the "favorite color" field out of
> each and put it in the variable $color. Then you just use the line:
> 
> $dict{$color}++
> 
> to count up what you find. The first time that line is called, it
> creates the dictionary, then creates a key for $color, initializes its
> value to zero, then increments it to 1.
> 
> As you continue iterating, each new color it encounters creates a new
> key, initializing it to zero and incrementing. When it finds a color
> that already has a key, it just increments the count.

It seems to me that it is not syntax that is the issue here, but
semantics.

You've listed a number of data structures that are creatly implicitly
by Perl, given the above syntax, i.e. dictionaries, keys, etc, are
created implicitly as your code is run.

That, IMHO, is what hinders you from remembering the "syntax" to carry
out the job. You don't just have to remember the syntax, but also all
of the implicit object creation semantics that go with it. That is
more likely to send you reaching for the reference manual, and also
more likely to prevent you using such use a construct (according to
your statement "If I have to go off and look it up .. I'm more likely
to just skip it").

The problem with such implicit semantics is that they increase the
complexity of what it is that you're learning, and thus steepen your
learning curve. It gets worse if/when there are lots of special cases
because the implicit object creation semantics don't fit every
situation, and the semantics implied by a syntax vary depending on
context.

I think the fundamental difference between Perl and Python is one of
philosophy.

Perl people seem to like implied semantics, because it gives them
terser code, meaning that

1. More steps can be achieved with less syntax, e.g. golf
competitions[1].
2. Increasing knowledge of the "secret operation of the machine"
brings on feelings of guru-hood.
3. Which is shown off by writing code which depends upon the detailed
implicit semantics of the machine, that no-one else can understand
without a similar detailed understanding of the machine.

Python takes the opposite philosophical view: Explicit is better than
Implicit. Meaning object and data creation semantics are always
explicit. This tends to make python code easier to read, because there
is a limited (but well-designed and powerful) set of semantics to
learn, which must be explicitly stated by all code that uses them.

Have you done this yet?

shell>python
Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Welcome to the python community.

-- 
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan

[1] http://perlmonks.thepen.com/130140.html