it is interesting how language wars start and go on. in reading this and
other threads it is clear that the way a person's mind functions has a
great deal to do with the languages they choose to use (unless they are
required to by outside forces).

python types always talk about rigid structure, fixed indenting,
consistant forms. this is a very academic view going back to the purest
(in the minimalist way) language, lisp. academic like only one way to do
something and no complex syntax and semantics. also pythoners (and tcl
and rexx) dislike perl's use of 'noise' chars for language conciseness
and power. this is not a rigid syntax or semantic kind of thing. you
have to choose what you do from an array of possibilities. i don't know
python but having seen enough code snipets here and there i think
understand its design philosophy and style. like java in some ways it
tries to enforce a object and coding style on you. some people like that
structure. in art, it is said that form liberates, so that works for
some brains. not being allowed variations at each step allows them to
focus on what they think is important in the program.

perl hackers tend to like flexibility, TMTOWTDI, a melange of semantic
options, a chunky chowder of code constructs, etc. that works for our
mind set. restricting our coding methods us is like handcuffing our
brains. perl's origins are unix shells, sed, awk, C, lisp and
english. there is no way to be academically rigorous with that
ancestry. you can do some types of operations (e.g. padding a string) in
dozens of equally functional ways. this is an anethema to academic and
rigid minds, but nirvana for perl hackers. sometimes conciseness can
lead you down the path to obsfucation but that is true in any
language. most good perl hackers don't get {*filter*}about conciseness
(randall excepted :-) and write readable and if it is a module, reusable
code.

the language does not force bad code out of us. if you can't read
it easily it is because of how you think about code and not the
language. i can hack lisp (for emacs) but i hate it. i have written many
procs for my emacs startup but i spend too much time on what would be a
trivial thing in perl for me. lispers can whip out functional (if not
readable to me) code in minutes that would take me hours. i could do the
same in perl for them. to each their own.

this is not a wrong approach. having taken some seminars which taught me
how to analyze how different people process information, i can
understand how different languages attract different people. that is the
first choice you can make in a software project. it could be for cost,
fun, sucking up to the boss, speed of execution, speed of development,
availability, being a u$hit zombie, or any other combination of reasons
to chose a language. i, like many of you have a long and deep exposure to
languages from assembler, PL/I, C, unix tools, etc. perl works for me
for most projects. i am working on a testing program in perl but the
things it is testing are c modules (fast cgi) which should never be in
perl (or any language that doesn't compile to machine code). a new
server i am writing will be in C but again the test programs will be in
perl. i conciously make those design decisions.

languages that reach a certain critical mass never seem to die out
completely. there is still production Pascal (an oxymoron) being
created, fresh cobol being written, etc. with all theses new languages,
we still write shell amd awk scripts when it is appropriate. would you
write an install system in perl (or python) not knowing if it was
preinstalled? no way, you do that in shell since it is on all unix
systems by default. a lousy language but it has the advantage of
ubiquitous availablilty. a language isn't better than another but better
for the programmer or project than another. languages are human
artifices and if they are turing compatible than it comes down to our
needs and the project's. given a free choice we will choose a language
that works best in our minds. i choose perl for all projects where i can
use it effectively. these day i only choose C for projects which need
raw speed. i have no need to learn python or rexx, etc since i know i
can do my jobs in perl and my mind likes to think in perl. i have
actively searched for perl work over the last 8 years just because i
like the language. i have been to the first 2 perl conferences,
participate in the c.l.p.* groups, proseletyze perl because  *I* like
it, not because it is the best language.

if perl users migrate to python, more power to them. perl will not die
because of that and python will not take over the computing world
either. i dislike having a fixed indent and rigid coding style force on
me but that is my choice. others agree and disagree and that is their
choice. so stop this language war {*filter*}or we will all become POB and
work in VB++ (DOJ and god help us all!)

uri

--
Uri Guttman                  Fast Engines --  The Leader in Fast CGI Technology

brent

i got this email reply which make some legitimate comments on my previous post
so here is the reply and my rebuttal.

also thanx to all who emailed me positive responses about the essay. you
could post those too!

uri

  PFD> Do you realize that you just said: a. I don't know Python b. I
  PFD> have an opinion about it (e.g., it forces a rigid coding style on
  PFD> the user)

i meant i don't know python like i know perl. i could learn it in a day
if desired. i can learn almost any modern language in a day or so to
minimally function and get a feel for it. i have seen enough python to
get a feel for its style and flavor. also i have seen enough flame wars
about it vs. perl to know i am on the perl side.

  PFD> Apparently (b) is derived from "looking at a few snippets". That
  PFD> isn't proper discourse.

  PFD> FYI: I know both Perl and Python and see no difference between
  PFD> them with respect to this issue. You wouldn't call the need to
  PFD> put { } around some things in a language a "rigid coding
  PFD> style". It is just the syntax.  Likewise, indentation in Python
  PFD> is simply its syntax.

i agree. but the syntax doesn't agree with the way i think in code. i
don't like the C syntax which allows dangling statements after if/while
without {}, so i always use {}. i like {}. it sticks out visually for
me. i don't like indenting as a syntax thing since i have my own indent
style, which may not fit.

  PFD> Please note this reply is not posted to the group. I try to not
  PFD> post criticisms of other people.

this could have been posted as your comments were reasonable and i had a
reasonable response.

again, i don't say python is a bad language. it just isn't to my taste
and way of thinking. i came from the unix/shell/awk/c/lisp world and
perl just subsumes all of them with similar syntax and semantics. python
doesn't map to my mind the same. i don't have to be an expert in cobol
to know i would hate it too. and i have seen as much cobol as i have
seen python. i am a computer professional and picking up languages is
second nature to me. my quick glance at python is enough for me.

uri

--
Uri Guttman                  Fast Engines --  The Leader in Fast CGI Technology

talk about a strange stealth CC. this author is on the

posting his letter and my reply so both groups can see them. i also CC'd
the author.

  GM> [Uri Guttman comments on language choice] While I generally agree
  GM> with most of what Uri said, I have a quibble or two:

  >> python types always talk about rigid structure, fixed indenting,
  >> consistant forms.

  GM> In a literal sense, this is nonsense, they don't talk about any
  GM> such thing.

as a thing that distinguishes python from perl, it is mentioned as a
plus by pythoners. as such it is fair game in comparing the
languages. see below for why it is an important issue in the comparison.

  GM> In the sense in which I believe it was intended, it creates a
  GM> false impression. While Python will have few (relative to Perl)
  GM> alternatives for a given syntactic element, the freedom of
  GM> expression at the level of the module / program / script is nearly
  GM> infinite.  Search dejanews for almost any thread in which someone
  GM> poses a non-trivial problem and gets more than one answer. Not
  GM> only will the answers be different, usually some of them will be
  GM> wildly different.  This is the "freedom" that most Pythoners are
  GM> interested in.

that is turing compatibility and all major languages have it. sure you
can solve a problem with many algorithms and in many styles in any
language. IMO perl offer more choices at the statement level of ways to
do medium level operations. when you get to a higher level operation,
then all languages show flexibility by the nature of programming languages.

  GM> And not everybody likes the (relative) lack of syntatic
  GM> alternatives - there are plenty of requests for more of them. But
  GM> most Pythoners are willing to live with it in return for the
  GM> algorithmic freedom.

you are confusing algorithmic freedom which as i claim (as does turing)
all modern languages have. it is the statemnet level where i feel perl
is more open and you agreed by stating that python has fewer syntactic
alternatives. that is the heart of the difference between languages,
syntactic and semantic operations, not algorithmic ability.

  >> ... i don't know python but having seen enough code snipets here
  >> and there i think understand its design philosophy and style. like
  >> java in some ways it tries to enforce a object and coding style on
  >> you.

  GM> I regard Java as far more "repressive" than Python - it imposes
  GM> restrictions in areas where Python is completely open.

true. i don't like OO in general. i am developing a medium (few 1000's of
lines) test program without any OO itself. i am using some perl
modules and their OO, but i don't need any for this program. just some
nice arrays of hashes and many subs in one file. it even uses (gasp!)
globals since i have to share many values across sub calls. i would hate
to do this in a language that forced OO like java and python. perl lets
me do OO or procedural and even mix the two (i call OO modules). that is
flexibility to me.

  GM> But as I said, I agree with the gist of Uri's comments.

thanx.

uri

--
Uri Guttman                  Fast Engines --  The Leader in Fast CGI Technology

  GM> Uri Guttman writes:
  >> talk about a strange stealth CC. this author is on the

  GM> Yes it is a gateway. Not strange at all.

but by replying to me and the gateway, the perl group wouldn't see your
message. that is a problem if you want to be in this thread. and i don't
wish to keep copying your letters to the perl group. please use a
newsreader to follow this thread or find a perl gateway and use it
too. i won't reply via email anymore as i want this thread to be open.

  >> that is turing compatibility and all major languages have it. sure
  >> you can solve a problem with many algorithms and in many styles in
  >> any language. IMO perl offer more choices at the statement level of
  >> ways to do medium level operations. when you get to a higher level
  >> operation, then all languages show flexibility by the nature of
  >> programming languages.

  GM> Perhaps in a theoretical sense, but not in any practical sense.
  GM> COBOL, for example, does not allow recursion, and all variables
  GM> are globals. This severely limits the solutions that can find
  GM> expression in COBOL. IMO, this is where Python shines.

turing compatibility solves all. you can fake recursion (intro
programming classes covers that) and you can deal with globals. it make
it hard but possible. we are not talking about possible. both perl and
python can have locals and recursion. big deal.

  GM> I don't know Perl, and I have absolutely no opinion on how Perl
  GM> fares at this level of expressiveness. I am simply pointing out
  GM> that (a) Python's relative lack of syntactical "freedom" has
  GM> nothing to do with it's expressiveness at this level and (b) a
  GM> language's theoretical turing completeness doesn't have much to do
  GM> with it either.

we are not agreed on what level we are talking about. i am talking about
the single statement/control level, not algorthmic higher levels. you
have stated python is weaker than perl at the syntax/semantic level
which is what i am refering to. that is the level which most affects the
style of the language. and that is where most people decide if they like
a language or not.

uri

--
Uri Guttman                  Fast Engines --  The Leader in Fast CGI Technology

--
Garry Hodgson                   and when they offer

Software Innovation Services    are you sure you'll refuse?
AT&T Labs                   heaven help the fool.

--
Garry Hodgson                   and when they offer

Software Innovation Services    are you sure you'll refuse?
AT&T Labs                   heaven help the fool.

--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury,          | protected, so as not to waste
Christchurch, New Zealand          | the time of Guido van Rossum.

I think it's cool that in Perl I can do things like this:

          {

            $x << 8 + $y        # some sample function of (x,y)
          }
            [ 4, 5, 6 ],        # the x values
            [ 1, 2, 3 ];        # the y values

This is example illustrates the use of a 2-dimensional mapping
function, analogous to the (1-dimensional) built-in function 'map'.
(Note, I'm not saying this is an example of a totally new syntactic
construct.  It's just a way of simulating the syntax of some of the
existing language features.)

--
John Porter

(For the perlers out there the >>> is the interactive command prompt,
map does pretty much the same as in perl, and lambda defines a
nameless function.).

Unlike in perl, map works with any number of parameters:

running it interactively shows that it doesn't do what the original
poster (presumably) intended, since + binds tighter than << in both
perl and python, which is why I had to switch to arbitrary precision
integers in the last example.  What I think he really meant was the
equivalent of:

This may seem like nit-picking, but it illustrates how easy it is to
test code interractively in python. This is part of the reason that
python is so easy to learn and program - I rarely have to look up how
some language feature works, since it is so quick and easy to try it
and see what happens.

        Dave K
--------------------------------------------------
All great ideas start as heresy and end as dogma.

bigfoot.   My opinions are my own,
com        but I'm willing to share.

*text-only; no windows. ;-)

John Porter

Python does *not* force OO, any more than Perl does.  Python likes
procedural code.  It likes global variables, too.[*]

The default in Python is for variables to be local, but you can change
the value of a global variable simply by declaring it:

  z = 0  #global z
  def showz():  print "z is:", z   #see the global z
  def f(x):  global z;  z=z+x      #change the global z

--
Jason

[*] Interestingly, neither Perl nor Python has "true" global
variables (anymore) in the same sense as C has 'em.