Why Python?

Cardinal Biggles had Eric in the comfy chair for over four hours before wringing this confession from him...

My first look at Python was an accident,
and I didn't much like what I saw at the time. It was early 1997,
and Mark Lutz's book Programming Python from
O'Reilly & Associates had recently come out. O'Reilly books
occasionally land on my doorstep, selected from among the new
releases by some mysterious benefactor inside the organization
using a random process I've given up trying to understand.

One of them was Programming Python. I
found this somewhat interesting, as I collect computer languages. I
know over two dozen general-purpose languages, write compilers and
interpreters for fun, and have designed any number of
special-purpose languages and markup formalisms myself. My most
recently completed project, as I write this, is a special-purpose
language called SNG for manipulating PNG (Portable Network
Graphics) images. Interested readers can surf to the SNG home page
at
http://www.catb.org/~esr/sng/.
I have also written implementations of several odd general-purpose
languages on my Retrocomputing Museum page,
http://www.catb.org/retro/.

I had already heard just enough about Python to know that it
is what is nowadays called a “scripting language”, an
interpretive language with its own built-in memory management and
good facilities for calling and cooperating with other programs. So
I dived into Programming Python with one
question uppermost in my mind: what has this got that Perl does
not?

Perl, of course, is the 800-pound gorilla of modern scripting
languages. It has largely replaced shell as the scripting language
of choice for system administrators, thanks partly to its
comprehensive set of UNIX library and system calls, and partly to
the huge collection of Perl modules built by a very active Perl
community. The language is commonly estimated to be the CGI
language behind about 85% of the “live” content on the Net. Larry
Wall, its creator, is rightly considered one of the most important
leaders in the Open Source community, and often ranks third behind
Linus Torvalds and Richard Stallman in the current pantheon of
hacker demigods.

At that time, I had used Perl for a number of small projects.
I'd found it quite powerful, even if the syntax and some other
aspects of the language seemed rather ad hoc and prone to bite one
if not used with care. It seemed to me that Python would have quite
a hill to climb as yet another scripting language, so as I read, I
looked first for what seemed to set it apart from Perl.

I immediately tripped over the first odd feature of Python
that everyone notices: the fact that whitespace (indentation) is
actually significant in the language syntax. The language has no
analog of the C and Perl brace syntax; instead, changes in
indentation delimit statement groups. And, like most hackers on
first realizing this fact, I recoiled in reflexive disgust.

I am just barely old enough to have programmed in batch
FORTRAN for a few months back in the 1970s. Most hackers aren't
these days, but somehow our culture seems to have retained a pretty
accurate folk memory of how nasty those old-style fixed-field
languages were. Indeed, the term “free format”, used back then to
describe the newer style of token-oriented syntax in Pascal and C,
has almost been forgotten; all languages have
been designed that way for decades now. Or almost all, anyway. It's
hard to blame anyone, on seeing this Python feature, for initially
reacting as though they had unexpectedly stepped in a steaming pile
of dinosaur dung.

That's certainly how I felt. I skimmed through the rest of
the language description without much interest. I didn't see much
else to recommend Python, except maybe that the syntax seemed
rather cleaner than Perl's and the facilities for doing basic GUI
elements like buttons and menus looked fairly good.

I put the book back on the shelf, making a mental note that I
should code some kind of small GUI-centered project in Python
sometime, just to make sure I really understood the language. But I
didn't believe what I'd seen would ever compete effectively with
Perl.

A lot of other things conspired to keep that note way down on
my priority list for many months. The rest of 1997 was eventful for
me; it was, among other things, the year I wrote and published the
original version of “The Cathedral and the Bazaar”. But I did
find time to write several Perl programs, including two of
significant size and complexity. One of them,
keeper, is the assistant still
used to file incoming submissions at the Metalab software archive.
It generates the web pages you see at
metalab.unc.edu/pub/Linux/!INDEX.html.
The other, anthologize, was used
to automatically generate the PostScript for the sixth edition of
Linux from the Linux Documentation Project's archive of HOWTOs.
Both programs are available at Metalab.

Writing these programs left me progressively less satisfied
with Perl. Larger project size seemed to magnify some of Perl's
annoyances into serious, continuing problems. The syntax that had
seemed merely eccentric at a hundred lines began to seem like a
nigh-impenetrable hedge of thorns at a thousand. “More than one
way to do it” lent flavor and expressiveness at a small scale, but
made it significantly harder to maintain consistent style across a
wider code base. And many of the features that were later patched
into Perl to address the complexity-control needs of bigger
programs (objects, lexical scoping, “use strict”, etc.) had a
fragile, jerry-rigged feel about them.

These problems combined to make large volumes of Perl code
seem unreasonably difficult to read and grasp as a whole after only
a few days' absence. Also, I found I was spending more and more
time wrestling with artifacts of the language rather than my
application problems. And, most damning of all, the resulting code
was ugly—this matters. Ugly programs are like ugly suspension
bridges: they're much more liable to collapse than pretty ones,
because the way humans (especially engineer-humans) perceive beauty
is intimately related to our ability to process and understand
complexity. A language that makes it hard to write elegant code
makes it hard to write good code.

With a baseline of two dozen languages under my belt, I could
detect all the telltale signs of a language design that had been
pushed to the edge of its functional envelope. By mid-1997, I was
thinking “there has to be a better way” and began casting about
for a more elegant scripting language.

One course I did not consider was going back to C as a
default language. The days when it made sense to do your own memory
management in a new program are long over, outside of a few
specialty areas like kernel hacking, scientific computing and 3-D
graphics—places where you absolutely must get maximum speed and
tight control of memory usage, because you need to push the
hardware as hard as possible.

For most other situations, accepting the debugging overhead
of buffer overruns, pointer-aliasing problems,
malloc/free memory leaks and all
the other associated ills is just crazy on today's machines. Far
better to trade a few cycles and a few kilobytes of memory for the
overhead of a scripting language's memory manager and economize on
far more valuable human time. Indeed, the advantages of this
strategy are precisely what has driven the explosive growth of Perl
since the mid-1990s.

I flirted with Tcl, only to discover quickly that it scales
up even more poorly than Perl. Old LISPer that I am, I also looked
at various current dialects of Lisp and Scheme—but, as is
historically usual for Lisp, lots of clever design was rendered
almost useless by scanty or nonexistent documentation, incomplete
access to POSIX/UNIX facilities, and a small but nevertheless
deeply fragmented user community. Perl's popularity is not an
accident; most of its competitors are either worse than Perl for
large projects or somehow nowhere near as useful as their
theoretically superior designs ought to make them.

My second look at Python was almost as accidental as my
first. In October 1997, a series of questions on the
fetchmail-friends mailing list made it clear that end users were
having increasing trouble generating configuration files for my
fetchmail utility. The file uses a
simple, classically UNIX free-format syntax, but can become
forbiddingly complicated when a user has POP3 and IMAP accounts at
multiple sites. As an example, see Listing 1 for a somewhat
simplified version of mine.

I decided to attack the problem by writing an
end-user-friendly configuration editor,
fetchmailconf. The design
objective of fetchmailconf was clear: to completely hide the
control file syntax behind a fashionable, ergonomically correct GUI
interface replete with selection buttons, slider bars and fill-out
forms.

The thought of implementing this in Perl did not thrill me. I
had seen GUI code in Perl, and it was a spiky mixture of Perl and
Tcl that looked even uglier than my own pure-Perl code. It was at
this point I remembered the bit I had set more than six months
earlier. This could be an opportunity to get some hands-on
experience with Python.

Of course, this brought me face to face once again with
Python's pons asinorum, the significance of
whitespace. This time, however, I charged ahead and roughed out
some code for a handful of sample GUI elements. Oddly enough,
Python's use of whitespace stopped feeling unnatural after about
twenty minutes. I just indented code, pretty much as I would have
done in a C program anyway, and it worked.

That was my first surprise. My second came a couple of hours
into the project, when I noticed (allowing for pauses needed to
look up new features in Programming Python) I
was generating working code nearly as fast as
I could type. When I realized this, I was quite startled. An
important measure of effort in coding is the frequency with which
you write something that doesn't actually match your mental
representation of the problem, and have to backtrack on realizing
that what you just typed won't actually tell the language to do
what you're thinking. An important measure of good language design
is how rapidly the percentage of missteps of this kind falls as you
gain experience with the language.

When you're writing working code nearly as fast as you can
type and your misstep rate is near zero, it generally means you've
achieved mastery of the language. But that didn't make sense,
because it was still day one and I was regularly pausing to look up
new language and library features!

This was my first clue that, in Python, I was actually
dealing with an exceptionally good design. Most languages have so
much friction and awkwardness built into their design that you
learn most of their feature set long before your misstep rate drops
anywhere near zero. Python was the first general-purpose language
I'd ever used that reversed this process.

Not that it took me very long to learn the feature set. I
wrote a working, usable fetchmailconf, with GUI, in six working
days, of which perhaps the equivalent of two days were spent
learning Python itself. This reflects another useful property of
the language: it is compact--you can hold its
entire feature set (and at least a concept index of its libraries)
in your head. C is a famously compact language. Perl is notoriously
not; one of the things the notion “There's more than one way to do
it!” costs Perl is the possibility of compactness.

But my most dramatic moment of discovery lay ahead. My design
had a problem: I could easily generate configuration files from the
user's GUI actions, but editing them was a much harder problem. Or,
rather, reading them into an editable form was a problem.

The parser for fetchmail's configuration file syntax is
rather elaborate. It's actually written in YACC and Lex, two
classic UNIX tools for generating language-parsing code in C. In
order for fetchmailconf to be able to edit existing configuration
files, I thought it would have to replicate that elaborate parser
in Python. I was very reluctant to do this, partly because of the
amount of work involved and partly because I wasn't sure how to
ascertain that two parsers in two different languages accept the
same. The last thing I needed was the extra labor of keeping the
two parsers in synchronization as the configuration language
evolved!

This problem stumped me for a while. Then I had an
inspiration: I'd let fetchmailconf use fetchmail's own parser! I
added a --configdump option to fetchmail that
would parse .fetchmailrc and dump the result to standard output in
the format of a Python initializer. For the file above, the result
would look roughly like Listing 2 (to save space, some data not
relevant to the example is omitted).

Python could then evaluate the fetchmail
--configdump output and have the configuration
available as the value of the variable “fetchmail”.

This wasn't quite the last step in the dance. What I really
wanted wasn't just for fetchmailconf to have the existing
configuration, but to turn it into a linked tree of live objects.
There would be three kinds of objects in this tree:
Configuration (the top-level
object representing the entire configuration),
Site (representing one of the
sites to be polled) and User
(representing user data attached to a site). The example file
describes five site objects, each with one user object attached to
it.

I had already designed and written the three object classes
(that's what took four days, most of it spent getting the layout of
the widgets just right). Each had a method that caused it to pop up
a GUI edit panel to modify its instance data. My last remaining
problem was somehow to transform the dead data in this Python
initializer into live objects.

I considered writing code that would explicitly know about
the structure of all three classes and use that knowledge to grovel
through the initializer creating matching objects, but rejected
that idea because new class members were likely to be added over
time as the configuration language grew new features. If I wrote
the object-creation code in the obvious way, it would be fragile
and tend to fall out of sync when either the class definitions or
the initializer structure changed.

What I really wanted was code that would analyze the shape
and members of the initializer, query the class definitions
themselves about their members, and then adjust itself to
impedance-match the two sets.

This kind of thing is called metaclass
hacking and is generally considered fearsomely
esoteric—deep black magic. Most object-oriented languages don't
support it at all; in those that do (Perl being one), it tends to
be a complicated and fragile undertaking. I had been impressed by
Python's low coefficient of friction so far, but here was a
real test. How hard would I have to wrestle
with the language to get it to do this? I knew from previous
experience that the bout was likely to be painful, even assuming I
won, but I dived into the book and read up on Python's metaclass
facilities. The resulting function is shown in Listing 3, and the
code that calls it is in Listing 4.

That doesn't look too bad for deep black magic, does it?
Thirty-two lines, counting comments. Just from knowing what I've
said about the class structure, the calling code is even readable.
But the size of this code isn't the real shocker. Brace yourself:
this code only took me about ninety minutes to write—and it worked
correctly the first time I ran it.

To say I was astonished would have been positively wallowing
in understatement. It's remarkable enough when implementations of
simple techniques work exactly as expected the
first time; but my first metaclass hack in a new language, six days
from a cold standing start? Even if we stipulate that I am a fairly
talented hacker, this is an amazing testament to Python's clarity
and elegance of design.

There was simply no way I could have pulled off a coup like
this in Perl, even with my vastly greater experience level in that
language. It was at this point I realized I was probably leaving
Perl behind.

This was my most dramatic Python moment. But, when all is
said and done, it was just a clever hack. The long-term usefulness
of a language comes not in its ability to support clever hacks, but
from how well and how unobtrusively it supports the day-to-day work
of programming. The day-to-day work of programming consists not of
writing new programs, but mostly reading and modifying existing
ones.

So the real punchline of the story is
this: weeks and months after writing fetchmailconf, I could still
read the fetchmailconf code and grok what it was doing without
serious mental effort. And the true reason I no longer write Perl
for anything but tiny projects is that was never true when I was
writing large masses of Perl code. I fear the prospect of ever
having to modify keeper or anthologize again—but fetchmailconf
gives me no qualms at all.

Perl still has its uses. For tiny projects (100 lines or
fewer) that involve a lot of text pattern matching, I am still more
likely to tinker up a Perl-regexp-based solution than to reach for
Python. For good recent examples of such things, see the
timeseries and
growthplot scripts in the
fetchmail distribution. Actually, these are much like the things
Perl did in its original role as a sort of combination
awk/sed/grep/sh, before it had functions and direct access to the
operating system API. For anything larger or more complex, I have
come to prefer the subtle virtues of Python—and I think you will,
too.

Comment viewing options

you hit the nail there. it is easy to say that a code is superior until you use it yourself. every programming has its own difficulty and every coder has his or her own unique style. logic is not something that is uniform among people. so i have to say it really depends on the experience of the coder on judging which programming language is superior. contact me @Joe Holt if you need additional input.

Despite his famous name, I think that the author hasn't got even the slightest idea about modern Perl (Perl 5) and how to manage big projects with it, something that so many large companies happily do (Amazon among these).
All the comments the author made about Perl seem to refer to Perl 4, and he seems to not have even the slightest clue about CPAN and the modern tools (Perl::Critic et al.) it offers to automate the enforcement of coding standards and best practices across a large developers team.

No, the author has programmed much more Perl then this random troll. The fact is Perl does indeed suck, which is why no one uses it anymore. Amazon just did a big rewrite to ensure they didn't depend too much on a dead language (Perl).

The most complex and integrate computer hardware is useless without instructions telling it what to do. These instructions are called programs and are written in computer programming languages. These computer programming languages allow people to communicate with the computer.

Compared to today's computers, the first computers were very simple. They were programmed by flipping switches or by inserting punched cards. They were only capable of doing simple math problems, such as addition and subtraction. The language used for these simple computers was not capable to perform the tasks of today's modern computers - graphics, word manipulation, etc. To make programming modern computers possible, more sophisticated languages had to be developed.

Machine Language
In a computer, all information or data is represented by numbers that represents electrical circuits in the computer. Electrical circuits in a computer exist in only two conditions: ON and OFF. Computers represent these states with the binary number system. The binary number system uses only digits 0 and 1 where a 0 indicating the switch is off; a 1 indicates that it is on. Each character (letter, number, or symbol) in the computer's character set is represented by a series of these off and on switches - in other words, by a series of 0s and 1s. Each switch called a bit, with is short for binary digit. Most computers use eight bits, or switches to represent each number, letter, or symbol. The collection of eight bits used to represent a character is called a byte.

Because computers understand only these on and off switches, the first programmers had to write the program using nothing but 0s and 1s. Instructions written in 0s and 1s are called machine languageor machine code.
Writing a program in machine language is very difficult because even a simple program requires hundreds or even thousands of microprocessor instructions. Another problem is that the numbers used to represent microprocessor instructions are difficult for people to understand and these programs were often prone to errors.

Assemble Language
In trying to make programming easier and not having to write in binary, assembly language was born. Assembly Language is slightly more advanced than machine code. The assembly languages simplify the programmer's job by allowing the programmer to use mnemonics in place of 0s and 1s in the program. Mnemonics are letters and numbers to represent machine language instructions. However, assembly language is still difficult for novices to read, and is specific to the machine's architecture.
Assembly language programming is accomplished using an assembler. An assembler is a program that reads the codes the programmer has written and assembles a machine language program based on these codes.

High Level Procedural-Oriented Languages
Machine language and assembly language are called low-level languages. Most programming done today is done in high-level languages. In a high-level language, instructions do not necessarily correspond one-to-one with the instructions set of the microprocessor. High-level languages reduce the number of lines of code necessary to write a program and reduce the number of errors because the programmer does not have to write as many instructions, and the instructions are easier to read. High-level languages are also easier to move among computers with different microprocessors.
In high-level procedure-oriented languages, the emphasis of a program is on how to accomplish as task, or objects, the order of the instructions is extremely important. When writing programs in a procedure-oriented language, the programmer must determine not only the proper instructions to give the computer, but the correct sequence of those instructions as well. A programmer will typically use a design methodology called top-down design to create a procedure-oriented program. Top-down design begins with a general statement describing the purpose of the program this purpose is then broken into smaller, more manageable tasks; and eventually into the actually high-level procedure-oriented language instructions.
High-level procedure-oriented languages require a compiler to convert the English-like instructions into the 0s and 1s the computer can understand. Like assemblers, compilers are separate programs. A compiler translates the entire program into machine code before running the program. Some of the high-level procedure-oriented languages include BASIC, COBOL, Pascal, and C.

A computer does not understand high level language. Several translations must be accomplished before it will understand what the programmer intended. The instructions in a high-level language must be translated into the one language a computer understands -machine language. There are two types of programs that perform the task of translating high-level languages into machine language-interpreters and compilers. Once the "source code" is translated a second file is produced called an object code.In high-level procedure-oriented languages, the emphasis of a program is on how to accomplish a task or the algorithm. The programmer must instruct the computer every step of the way. The programmer determines and controls the order in which the computer should process the instructions. In all procedure-oriented programs, the order of the instructions is extremely important. When writing programs in a procedure-oriented language, the programmer must determine not only proper instructions to give the computer, but the correct sequence of those structures as well.

Object-Oriented Languages
The most recent advance in high-level languages has been the introduction of object-oriented languages. C++ and Visual Basic are two popular object-oriented languages. Programs that are WYSIWYG (what you see is what you get) are based on these same principles. Object-oriented languages view a problem solution as a set of interacting objects. A programmer typically uses a design methodology called object-oriented design (OOD). The programmer begins with a statement that describes the purpose of the program and divides the program into one or more objects. The objects in an object-oriented program can take on many different forms such as menus, options buttons, and command buttons. Objects may also take on real-life meanings (examples include an employee, date, and time card object).
There are two main advantages of object-oriented languages over procedure-oriented languages. First it allows a programmer to use familiar objects to solve a problem. Second, because each object is viewed as an independent unit, an object can be used in more than one application. Many object-oriented languages are direct descendants from procedure-oriented languages and can be used to create both object and procedure-oriented programs.
Like procedure-oriented languages, object-oriented languages need a compiler to translate the high-level instructions into machine code.

OOP Terminology

Object - anything that can be seen or touched (example being a car); every object has attributes and behaviors
Attribute (data) - characteristics that describe the object (example: your car (the object) has tires (the attribute))
Behaviors - operations or actions that the object can either perform or have performed on it (example: your car (object) can accelerate (behavior))
Class - a pattern or blueprint for creating an object; it contains all of the attributes and behaviors that describes the object
Instance - the object that you create from a class; note that a class is not an object; however an instance of a class is an object
Encapsulation - combining of an object's attributes and behaviors into one package (a class)
Abstraction - hiding the internal details of an object from the user; protects against the user inadvertently making changes to the object
Exposed - attributes that are not hidden from the user
Inheritance refers to creating a new class (derived class) from an existing class (base class); note that the derived class inherits the attributes and behaviors from the base class
Linking - The object code for your C++ program must be combined with the object code for routines (such as input and output routines) that your program uses. This process of combining object code is called linking and is done by a program called a linker

Most of the comments I see on Python have a religious feel to them. They do not
contain technical details. They are of the form: "Python programs are short and easy to program". What would be preferable would be comparions to Java, for example construct by construct, and not Java 1.4 or earlier but Java 1.5 that has autoboxing and for(type id : collection) loops, enumerated types, etc. One of the specific advantages I see in Python is the set, list and map collector syntax. However this is not highlighted in most of the comments I see. I wonder why. Another debate that I would encourage is the static versus dynamic typing issue. Can Python be used for softare that has to be reliable when it is dynamically typed? What is the experience writing thousands of lines of untyped code? Does it crash occasionally because a specific path throgh the program was never tested, causing a type error to occur (for example adding a number to a list of numbers.

the basics are more or less the way YOU can understand the language that of a computer system. numbers and letter with add ons.it is important to remember that just because you know the basics of hacking anything you need to know how to get in and get out with little or no trace that you were there.breaking into a major web site is in it's own way easy but very complicated understanding all the codes and passwords scripts and how to pass them with out getting booted because they will send illegal access codes to your IP address and shut you down while the feds are on to you.typing fast is also a key to good hacking.typing without mistakes is hard to complete but after you learn more of the world we live in you will make little mistakes.reasons you cant find alot of info on the net about how to learn to hack is because we dont want to let the secrets out.anyone can become a hacker it is just how you look at the way it works.you need to learn much about encoding and scripts.like if someone makes a page to a password that is loaded into the script box and then in the main page it will let you access it with the password but if someone forgets to upload the password file BAM you get in by simply pressing the button that login pages require.as if you try and steel from the net with no way knowing how to read the computer the way you have to.kiss you ass good bye.as i sat in my cell for hacking in the federalsystem and changing my record and then making ATM's read any card and give as much as i want i wanted to do it more and more...now i am known as suicide.understanding how to hack pro is a very long process as it takes some knowledge of how to read the sorce codes and all that happy stuff.and myspace is nothing to hack into...try hacking in something usefull.oh and hackers dont beg for ways to hack we just learn on our own.

what is the best way to learn python? not easiest, best. should i buy a book, or can i learn on my pc. i have been abused by ppl that call themselves hackers several times, especially when im beating them at chess they can stop timers and so forth. these are not hackers, they are cheaters! i only desire to become a hacker to protect myself from cheaters and grow intelectually. i have a 4 year, so i know i can learn. i know noone can teach me i have to learn myself, but where do i start? useful information will be rewarded monetarily. i will be buying linux soon, so dont wait forever with the info. teaching me could be a part time job for some lucky hacker!peace out.

What you are describing, is not hacking, but rather cracking. A cracker is, as per the Great Jargon File
"One who breaks security on a system. Coined ca. 1985 by hackers in defense against journalistic misuse of hacker (q.v., sense 8)...a separate and lower form of life..."
This is a generalization of a cracker. Do you want to be that separate and lower form of life, or do you desire to transcend to Hackerdom? To learn more, read "The Loginataka", "How to Be a Hacker" and browse the "Jargon File".

The article was good and demonstrates well the fact that there is no need for perl anymore really. No more then there is for sed, awk or any of those old unix tools.

Unfortunatly perl seems to attract a very odd sort of person, someone who constantly feels the need to bash everything else that they feel threatens the language (notice the author didn't try to say don't use perl, just not for everything. not the response you will get from a perl advocate).

These strange people always say odd things like "Perl can actually be very readable if written that way". Great, so can assembler, but I would rather use a language that *encourages* this instead of one so hostile to it (the reason people write unreadable perl is because that code will run much faster then the readable counter-part).

Or another gem is "Perl can do anything I need it to do". Well if these were programmers instead of system admins that *think* they are computer scientists, they would realize any Turing compliant language can do "anything I need it to do". The question is only about how much code and how maintanable.

And the last thing they bring up is always "well I just couldn't live with a language that didn't have as many modules as perl does". Well, the vast majority of those modules you will never us. And many modules are basically the same problem space redone 10 different ways. Perl's CPAN giving it some great power is a myth. If you are doing something really obscure there is a chance CPAN might save you a little time, but for 99% of the people Python, Ocaml, Ruby, etc. have everything you will ever use.

The article mentions the fact that you lose familiarity with your program very quickly. This is a side effect of the chosen design. Larry Wall mistakenly believes that natural language is what a programing language should be modelled after. This view seems very ignorant of computer science in general. To manage complexity (and programming, after all, is mostly about managing complexity) steps must be made to ensure the program can easily be reasoned about. This is the exact opposite goal of a natural language. Just think of how many times you have misunderstood what someone said in their life. There is a reason for this.

Natural language has the distinguishing trait that it is *not* like riding a bycicle. When you ride a bycicle for just a little while and then leave it for 60 years, you will still know how later on should you try again. However, if you stop speaking a language for half that time you will have forgotten nearly everything about it. Natural language is so complicated we can only keep it in our head if we use it constantly. And someone wants to model a programming language after that?!

The article was good and demonstrates well the fact that there is no need for perl anymore really. No more then there is for sed, awk or any of those old unix tools.

That's strange, most of the CGI scripts on the web is written in Perl -- did you say useless? Hum, and those *old* unix tools are still useful. Correct me if I'm wrong but I think they're the best way to introduice the use of ``regular expressions'' -- even if it's only for a general culture.

Unfortunatly perl seems to attract a very odd sort of person,(...)

Do you mean that most of the hacker community are psycho? :). Yeah, you're dead right.

These strange people always say odd things like "Perl can actually be very readable if written that way". Great, so can assembler, but I would rather use a language that *encourages* this instead of one so hostile to it (the reason people write unreadable perl is because that code will run much faster then the readable counter-part).

I don't get the picture here. No *strange* people actually encourages the use of unreadable code. But the language is expressive enough that everybody could do *whatever* he wants -- even dumping some piece of _write-only_ code I have to admit.

Or another gem is "Perl can do anything I need it to do". Well if these were programmers instead of system admins that *think* they are computer scientists, they would realize any Turing compliant language can do "anything I need it to do". The question is only about how much code and how maintanable.

I suggest __Brainfuck__ :)
No more seriously, you'd hardly find another scipting language that produce more consice code than Perl. And the maintenance depends on the *way* you wrote it.

(...). Perl's CPAN giving it some great power is a myth. If you are doing something really obscure there is a chance CPAN might save you a little time, but for 99% of the people Python, Ocaml, Ruby, etc. have everything you will ever use.

So does Perl. I don't know if you've noticed the author mentionned that for a work of less than 100 lines, Perl is *okay*. And that's what 99% of the people have to deal with.

The article mentions the fact that you lose familiarity with your program very quickly. This is a side effect of the chosen design. Larry Wall mistakenly believes that natural language is what a programing language should be modelled after. This view seems very ignorant of computer science in general. To manage complexity (and programming, after all, is mostly about managing complexity) steps must be made to ensure the program can easily be reasoned about. This is the exact opposite goal of a natural language. Just think of how many times you have misunderstood what someone said in their life. There is a reason for this.(...)

Yeah, Larry Wall wasn't a visionary after all -- he's just a jack adams with rubbish ideas :) -- we've been deceived. A true language should include a bunch ``goto'' and whatever else a machine could easily read except for a human side, right?
The main advantage of natural language is that you don't need to know all the *vocabulary* to understand it. That's not the case of machine-language: you need to know exactly what you're doing if you don't want to be in trouble. So yes, you could start to learn a ``natural language'' very quickly but you need time and and practice before you could mastered its arcanes -- that's the downside.

"That's strange, most of the CGI scripts on the web is written in Perl -- did you say useless?"

That's strange, most of the users of the web are running Windows...

"Hum, and those *old* unix tools are still useful."

Yes, *those* old unix tools are still useful. Those. As in plural. As in, "do one thing, do it well." Each of those tools has its own syntax specialized for its own specific purpose. Perl takes all those tools and tries to squeeze not only the functionality but also the syntax of every single one into the same language. Python has the same functionality, it just doesn't try to put all of it into the core language. It's called the standard library. For example:

That's strange, most of the CGI scripts on the web is written in Perl -- did you say useless? Hum, and those *old* unix tools are still useful. Correct me if I'm wrong but I think they're the best way to introduice the use of ``regular expressions'' -- even if it's only for a general culture.

Yes most of the "cgi" scripts are perl. But most of the web isn't written in CGI anymore. Welcome to early 2000. And by "old unix tools" I meant things like sed and awk. They are still useful on the command line but not really needed in scripts like they were before. And every language has regular expressions now. No need to go into Perl for it.

Do you mean that most of the hacker community are psycho? :). Yeah, you're dead right.

Most of the hacker community... Why must obscure groups always try to make themselves sound like the majority? No, I mean people who use Perl and like it have issues.

I don't get the picture here. No *strange* people actually encourages the use of unreadable code. But the language is expressive enough that everybody could do *whatever* he wants -- even dumping some piece of _write-only_ code I have to admit.

Of course you don't get the picture. Perl is all about misunderstandings and it's advocates take this trait to heart. And have you not read you lord's writings? Look at what he says you do to read lines of a file, then look what he says an "experienced" perl programmer would do. Just because someone *says* they are writing good code doesn't mean it's true.

I suggest __Brainfuck__ :)
No more seriously, you'd hardly find another scipting language that produce more consice code than Perl. And the maintenance depends on the *way* you wrote it.

Interesting that you chose a language with similar readability. :) And yes, of course you can find languages that produce more concise code. The difference is; some concise lisp, for example, is still readable and probably accomplishes something useful. And to find something perl does in less lines of code you have to select specific sorts of tasks. Stay away from making classes, for example. More sensible languages like Python, Ruby, well almost anything other then C or Java do this much simpler and obvious what is going on.

So does Perl. I don't know if you've noticed the author mentionned that for a work of less than 100 lines, Perl is *okay*. And that's what 99% of the people have to deal with.

Uh, did you completely miss the point of the paragraph? And no, 99% of the people *start* with less then 100 lines, but when you get something working you always wind up adding features to it. So for this reason it is just best to avoid perl all together in all cases.

Yeah, Larry Wall wasn't a visionary after all -- he's just a jack adams with rubbish ideas :) -- we've been deceived.

Pretty much. Calling Larry a visionary surely must be a joke. He is closer to a lottery winner (i.e. he did nothing more then "buy a ticket" by putting his program on the net and managed to win some support. Being in the right place at the right time). But yes, anyone who thinks perl is anything but a horribly designed, horribly implemented exercise in what not to do that had already been learned a couple of decades before, is deceived.

A true language should include a bunch ``goto'' and whatever else a machine could easily read except for a human side, right?

Um, the reason I am against perl is exactly *because* it takes us backwards in computer science. It's basically C with strings, automatic memory allocation and without core dumps happening quite as often. It's hilarious that you assumed I wanted a *less* human readable language. We need *higher* level languages to get our work done fast, instead of playing around with bit twiddling. And we have had higher level languages for quite some time now.

The main advantage of natural language is that you don't need to know all the *vocabulary* to understand it. That's not the case of machine-language: you need to know exactly what you're doing if you don't want to be in trouble. So yes, you could start to learn a ``natural language'' very quickly but you need time and and practice before you could mastered its arcanes -- that's the downside.

Uh, no. You analogy is 100% wrong. You need to know a *lot* of vocabulary before you even *think* about talking. Babies supposedly know around 2-4k words before they say their first one. And notice you jumped from "to understand it" for natural language but "know what you are doing" for machine-language (obviously you would want a well designed high level language, not machine language). There is a very large gap between being able to *understand* (your natural language statement) a language, natural or computer, and being able to *speak/use* (your machine-language statement) a language, natural or computer. So basically, your point is completely invalid and you don't seem to have any idea about any of these subjects you are talking about. But don't feel bad, the rest of your camp are no better.

PS: I'm not a Perl zeloat, just an average user.

What a ridiculous attempt to add validity to your clearly zealotus statements. And of course it failed miserably. It is very clear to everyone that you are a perl zealot.

Yes most of the "cgi" scripts are perl. But most of the web isn't written in CGI anymore. Welcome to early 2000.

Um... It seems that there are still a bunch of neanderthals out of here. How about these guys -- did you forget to profess them the wise words?

And by "old unix tools" I meant things like sed and awk. They are still useful on the command line but not really needed in scripts like they were before. And every language has regular expressions now. No need to go into Perl for it.

There's a little difference between ``still useful on the command line'' and ``No more then there is for sed, awk or any of those old unix tools''. Of course every language have regular expressions. The main issue is the implementation in the given language. For example, it's tiresome to use it with Java.

Most of the hacker community... Why must obscure groups always try to make themselves sound like the majority? No, I mean people who use Perl and like it have issues.

It's funny seeing someone overreacting at every piece of joke. Everytime these magic words are pronounced, there's always someone who take them at first degree. Did you really think I was serious? Come on!

Of course you don't get the picture. Perl is all about misunderstandings and it's advocates take this trait to heart. And have you not read you lord's writings? Look at what he says you do to read lines of a file, then look what he says an "experienced" perl programmer would do. Just because someone *says* they are writing good code doesn't mean it's true.

My ``Lord''? Do you think that I worship Larry Wall? For me, Perl is just a language like another one. It's not that I don't hate it that I must be an addicted. And yes, I don't take for granted what everyone says: I don't agree with Eric Raymond and you, see.

Interesting that you chose a language with similar readability. :)

Why bother? It's simple, ergonomic and have practical utilities :)

And yes, of course you can find languages that produce more concise code. The difference is; some concise lisp, for example, is still readable and probably accomplishes something useful. And to find something perl does in less lines of code you have to select specific sorts of tasks. Stay away from making classes, for example. More sensible languages like Python, Ruby, well almost anything other then C or Java do this much simpler and obvious what is going on.

Let's put it clear once for all. Perl is *ugly* because the designers and the Perl community *wanted* it that way. The readability has been sacrificed for the utility. So actually, everyone knows with what he have to deal with when he uses it. Of course Python and Ruby choose another philosophy -- fine. It's up to everyone to find out what fits his mind.

Uh, did you completely miss the point of the paragraph? And no, 99% of the people *start* with less then 100 lines, but when you get something working you always wind up adding features to it. So for this reason it is just best to avoid perl all together in all cases.

In everything? Even if you have to use a lot of pattern matching? And for a sysadmin for example, a typical script is about 30 lines. I don't use Perl for everything but I actually think that in some situations it's the best candidate.

Pretty much. Calling Larry a visionary surely must be a joke. He is closer to a lottery winner (i.e. he did nothing more then "buy a ticket" by putting his program on the net and managed to win some support. Being in the right place at the right time).

So does Richard Stallman and Linus Torvalds and the list goes on. So what? Being in ``the right place at the right time'' doesn't require any quality?
You need to have a certain insight of the situation to be able to understand that there's a vacuum and somebody got to fill it.
Maybe if another language which would have the same features appeared at the same time, the story could be different. But that's not the case, Perl was already on the wild and had a huge community before Python and later Ruby appeared. And the language is flexible enough that it adapted succefully | awkwardly (depending from which board you come from) when the internet rose up.

But yes, anyone who thinks perl is anything but a horribly designed, horribly implemented exercise in what not to do that had already been learned a couple of decades before, is deceived.

cf what I mentionned above.

Um, the reason I am against perl is exactly *because* it takes us backwards in computer science. It's basically C with strings, automatic memory allocation and without core dumps happening quite as often.

Yes and everybody actually reckons that, you know.

It's hilarious that you assumed I wanted a *less* human readable language. We need *higher* level languages to get our work done fast, instead of playing around with bit twiddling. And we have had higher level languages for quite some time now.

Need to be enlightened?
Of course we need a high level language to accomplish a job rapidly. It's not time consuming anymore except in some critical areas. So when I'm refering to the ``goto'' trick, I'm not talking about the level of the language.
You mentioned earlier we should ensure that a program should easily be reasonned about for a *good* language, fine. In theory that's great. But in practice?
A program to be easily reasonned about should have no ambiguities in the syntax so you don't have to misinterpret it. The best way to accomplish this is to produice a ``turing-machine'' like code. That's why I ask you if a *true* language should include a bunch of ``goto''.

Uh, no. You analogy is 100% wrong.

That for sure is the best way to keep the discussion on.

You need to know a *lot* of vocabulary before you even *think* about talking. Babies supposedly know around 2-4k words before they say their first one.

Sounds interesting. Source?
So let's suppose it's true. But remember that for example there's over 500,000 words in english. Thus, the baby needs to know less than 0.8 % of the total vocabulary before he could pronounce a word. I don't think it's that much.

And notice you jumped from "to understand it" for natural language but "know what you are doing" for machine-language (obviously you would want a well designed high level language, not machine language).

Yeah, I'm a lazy bastard so I said it all at once. I was talking about the syntax not the vocabulary. Of course a machine-language have only few vocabularies.

There is a very large gap between being able to *understand* (your natural language statement) a language, natural or computer, and being able to *speak/use* (your machine-language statement) a language, natural or computer.

Of course *understanding* a language doesn't mean that you could speak|use it fluently. But for a natural language -- since it's more flexible and permissive -- you could learn it by practice.E.T. phone home: even if it's not a correct english, everyone understands what it means. But a machine -- say an A.I. -- wouldn't understand the phrase if it's not spelt correctly.

So basically, your point is completely invalid and you don't seem to have any idea about any of these subjects you are talking about. But don't feel bad, the rest of your camp are no better.

Rest of my camp? :) I represent nobody else than myself.
And I don't feel bad. Do you really think that I would take into my heart what you're groaning about? I'm cold to all of this, cold to what you feel.

What a ridiculous attempt to add validity to your clearly zealotus statements. And of course it failed miserably. It is very clear to everyone that you are a perl zealot.

Did you make a local survey to know their opinion? It's not that I don't agree with you that I'm inevitably a Perl fanatic.
An ad hominem attack never works on me. Like I said before, we're not obliged to be friends.

Um... It seems that there are still a bunch of neanderthals out of here. How about these guys -- did you forget to profess them the wise words?

Do you even look at the links you post? The first hit on the first link is a company from the late 70's called CGI (since it's before the web I'm guessing it doesn't mean common gateway interface). Most of the rest on the first page are just explaining what CGI is. On your second link, I don't know. It was a 404 error, maybe they moved into early 2000 as well.

There's a little difference between ``still useful on the command line'' and ``No more then there is for sed, awk or any of those old unix tools''. Of course every language have regular expressions. The main issue is the implementation in the given language. For example, it's tiresome to use it with Java.

No actually there isn't. The phrase "no more useful" means the same as "just as useful as but no more". Get it?

And yes, in Java regular expressions, making hello world, printing to the screen, etc., etc. are complicated. In python and ruby, for example, re's are just as simple (some might say easier).

It's funny seeing someone overreacting at every piece of joke. Everytime these magic words are pronounced, there's always someone who take them at first degree. Did you really think I was serious? Come on!

The way I usually detect jokes is when someone says something that is funny on purpose. Sorry I missed this one some how. ;)

My ``Lord''? Do you think that I worship Larry Wall? For me, Perl is just a language like another one. It's not that I don't hate it that I must be an addicted. And yes, I don't take for granted what everyone says: I don't agree with Eric Raymond and you, see.

I still don't buy your "I'm not a Perl zealot, just an average Joe" routine. So yea, I kind of do suspect you of having life size Larry Wall posters, etc.

Let's put it clear once for all. Perl is *ugly* because the designers and the Perl community *wanted* it that way. The readability has been sacrificed for the utility. So actually, everyone knows with what he have to deal with when he uses it. Of course Python and Ruby choose another philosophy -- fine. It's up to everyone to find out what fits his mind.

No, it is ugly because it was made by and for Unix Sys admins. So it looks like the other tools they used. And you speak as if you have to get such an ugly language to get tersity. This is simply not the case. In fact, for the things I tend to do; lisp, smalltalk, python, ruby and some others all do the same thing in less statements then equivalent Perl code.

In everything? Even if you have to use a lot of pattern matching? And for a sysadmin for example, a typical script is about 30 lines. I don't use Perl for everything but I actually think that in some situations it's the best candidate.

Well, as I said before, Python and Ruby do pattern matching just as easy, and if the script winds up needing more features you can maintain it and still read it when you come back in a few years. I worked in Perl for 5+ years and I honestly can't think of a single thing it does better then some other solution.

So does Richard Stallman and Linus Torvalds and the list goes on. So what? Being in ``the right place at the right time'' doesn't require any quality?
You need to have a certain insight of the situation to be able to understand that there's a vacuum and somebody got to fill it.

But none of these people did that. Linus is not a visionary because of his initial release of Linux. He is a visionary because of everything that happened after that. Likewise Larry isn't excluded based on his original release of Perl. He, like Linus, probably didn't do the first release with the plan of making something big.

Larry is excluded because of everything that occurred after that. In the beginning Perl was what we would today call a DSL for text processing. It was when he decided to try and make it a general programming language and bolted on one misunderstanding based feature after another.

And the language is flexible enough that it adapted succefully | awkwardly (depending from which board you come from) when the internet rose up.

Any language was "flexible" enough to do the kind of adapting they did.

Yes and everybody actually reckons that, you know.

I have met enough "Perl mongers" in person and online to know this to be false. They genuinely believe that Perl is well implemented, and further, the language we should all be programming in!

You mentioned earlier we should ensure that a program should easily be reasonned about for a *good* language, fine. In theory that's great. But in practice?
A program to be easily reasonned about should have no ambiguities in the syntax so you don't have to misinterpret it. The best way to accomplish this is to produice a ``turing-machine'' like code. That's why I ask you if a *true* language should include a bunch of ``goto''.

Again, it's only your Perl-based CS understanding that makes you think this is so hard to do. Perl is actually one of the few languages that has syntax ambiguities. I would suggest going out and learning some better designed programming languages so you can see that you don't have to go so low level to make a language clear and powerful.

It was in one of the CD's or something for this system. It has been some time since I heard it, but it was part of their explanation of why the language teaching packet came with no text at all.

So let's suppose it's true. But remember that for example there's over 500,000 words in english. Thus, the baby needs to know less than 0.8 % of the total vocabulary before he could pronounce a word. I don't think it's that much.

Well it takes around 2 years to form the simplest sentences. It is simply unnecessary to make your programming language this difficult. You could also paint your house with a toothbrush, but why?

Of course *understanding* a language doesn't mean that you could speak|use it fluently. But for a natural language -- since it's more flexible and permissive -- you could learn it by practice.
E.T. phone home: even if it's not a correct english, everyone understands what it means. But a machine -- say an A.I. -- wouldn't understand the phrase if it's not spelt correctly.

This still isn't the point. The point is, yes people can and do learn natural language, but it is extremely complicated. If you are trying to manage complexity (which is basically what programming is) you want exactly the opposite of such a system.

Did you make a local survey to know their opinion? It's not that I don't agree with you that I'm inevitably a Perl fanatic.

It is not that you disagree with me. It is the position you take on these issues that labels your camp.

When I was looking for a language for test system and tool making to replace C and C++, I had a look at Perl. But only a look. It is a truly ugly language and looked quite possibly more unmaintainable than Forth. Seeing a few random source listings convinced me the learning curve would be brutal.

A look at Python code suggested good things could be done quickly and efficiently. The indentation was not a big deal once I stopped mixing spaces and tabs - Python's only gotcha. I ended up writing some of the smartest code I had ever written simply because it was so easy to do.

I agree with what you said that as the Perl code gets larger, it becomes unreadable. However, PHP is based on Perl (as far as I understand), and PHP is pretty readable and browsable even in large chunks of code. What I tried lately is to use PHP as in shell scripts, and it worked fairly well. Of course it was slow, and I expected that from the start however it was orders of magnitude simpler than Perl. I didn't do much Python coding but I also know that it is pretty powerful and I know many people who are currently using it in automated testing esp. in web applications where it fetches the pages and submits forms ...etc.

Err, no, PHP is not based on Perl and doesn't read anything like Perl. PHP reads a lot more like C. Knowing C and similar languages, I was able to learn PHP very rapidly. Perl is a whole different world.

Tried Python, did not like it, returned back home. Tried Ruby, did not like it, returned back home. Maybe sometime I find something that'll feel even more natural and will allow me to be even more productive, until then Perl is my tool.

I didn't do much Python coding but I also know that it is pretty powerful and I know many people who are currently using it in automated testing esp. in web applications where it fetches the pages and submits forms

Really? I just happened to come across this article, and know virtually nothing about Python. I thought it might be a good intro as to the main benefit of using this language over another (and I think it has been).

Anyway, for the past few weeks I've been trying to find automated GUI testing tools for web applications; preferrably in PHP. Could you point me in the direction of the Python projects for testing, or people using them?

My preference is for REBOL. It has the easiest cross platform GUI tools I've seen, an elegant built-in parse dialect, built-in network protocols, CGI interface, many useful built-in data types (times, dates, money values, urls, binary representations of images, etc. are all recognized natively). Scripts run unchanged on 40+ platforms. REBOL's designed to allow for natural language dialecting, and it's got the most natural learning curve that I've seen, at least for average computer users who are new to coding. It comes in an absolutely tiny download (~ 1/7 to 1/2 meg, depending on platform and distribution). It's a shame so few people even know it exists.

I wrote a tutorial that teaches absolute beginners how to do many useful things with REBOL in about 160 pages:

Having read a large amount of the replies to this article, (not all of them or I would be suffering a migrane) I would like to make some comments that may be of more use than slagging off the author (nameing no names).

What comes to mind first is the amount of replies asking how to become a hacker. Now correct me if I'm wrong, but I came to this article under the impression that it was an evaluation of Python, not a tutorial on hacking.

My advice to anybody who reads this in the hope that they will become hackers is to go and do some independant research. Although I do not claim to be a hacker, I do know that hacking is not something that can be taught straight off. It is something that requires a logical but open mind, background knowledge and understanding of computers, programming languages, network protocols and workings... the list goes on.

This is why you can't just "become a hacker" it takes a lot of work and independent research. A good place to start might be Eric Raymonds homepage "http://www.catb.org/~esr/". There is a very good article on hacking in the HOWTO's section, however it is all a matter of preference.

Secondly I would like to agree with certain people that breaking in to private computers and organisations is not hacking. It may require some skills that many hackers have, however this particular practice is commonly known as cracking... and yes it is illegal. If you want to become a hacker so that you can crack, I would imagine that you don't have the right mindset or patience to learn how to hack.

Moving on... all these posts claiming that people who keep moving from one programming language to another are "whimps". I completely disagree. In my opinion, a greater knowledge of programming as a whole, leads to more compact, efficient and pleasing programs that one can produce. I firmly agree with Eric's comment that learning different programming languages helps you to think about one same problem in different ways. This is a key method to problem solving and hence why I disagree that better programs can be written by learning only one language very well.

Finally, I am under the impression that the hacker morale embraces freedom of speech. Just some comments on this. I would advise that if you do have a strong opinion on a matter and would like to voice it, then you should be prepared to back your opinion up with some reasoning behind it. I have seen so many posts ranting about how they are right and other people are wrong with absolutely no reasoning as to why they are.

I would like to say more, but I think this post is long enough anyway. Comments are appreciated.

Thank you Eric Raymond for an extensive look in to Python. Your articles are always valued.

I completely agree with you.
as eric raymond states in his indespensable how to guide:

"There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer. Unfortunately, many journalists and writers have been fooled into using the word ‘hacker’ to describe crackers; this irritates real hackers no end."

I'm laughably young be some people's standards to be getting into REAL hacking, but am very interested and have downloaded python only as the almighty guide referred to it as a good beginners language.

I came across this article through searching for 'Python for idiots'.
unfortuantely i came only across an atricle about python, and some idiots.

This page is for people serious about hacking, not cracking, nor any other illegal wannabe activity. Its nice to see somebody who knows what they think, rather than some who merely think what they know.

Theres a big difference between putting a computer together and knowing how to use one. Assuming you do want to be a hacker and not a cracker, then Python is a good place to start. As was previously mentioned, it is a good begginer's language, with easy syntax and an intuitive vocabulary. Nevertheless, is is still powerful, and could last you as long as you're interested.
The first place to start? Python.org

PASCAL is the BEST language of the world. Easy to learn and programming. You can do all with pascal.
Java, Basic, Python, Perl, PHP ... are toys! Slow! PHP is good for dynamic websites.
You can do with Delphi/Lazarus all easier and quickly as C, C++ or other toys. Too many Windows programs are coded by Delphi/Object Pascal.

Lua looks promising, but it seems so similar to Python and offers so little more that I doubt a Python programmer would bother with it. I might be wrong though since this is the first time I've heard of Lua.

I disagree with Eric. Basically, he's exposing his own subjectivity about his chosen language. He uses the characteristic slap-shot
words that language zealots and converts everywhere fling at
"competition": "eccentric", "fragile" , "jerry-rigged", and, of course, "ugly".

To me, the mark of a really great language advocate or designer is
someone who wouldn't feel the need to bash the competition with
the patronizing remark that Perl is just a niche utiility "For tiny projects (100 lines or fewer)"; who wouldn't need to embroider the discussion with his fame or personal accomplishments; who doesn't backfill argument holes with hyperbole about his Python programs working the "first time".

And a real language designer understands the complexity, history,
and roles of computer languages; sees the trade-offs and embraces
diversity; learns from and adopts good features of other languages;
supports and strives for the interoperation of other languages with his own. Moreover, He'd distance himself from any shallow advocacy.

ESR is a well known, talented programmer but, despite his reputation
and "12 languages", does, what everyone at one time or another has
done: becaome enamored with his own prejudices.

There's nothing wrong with being excentric. And ugly ... I don't find Perl ugly, but I understand it may look that way to some. Camels are not the nicest and smelliest animals, but if I need to cross a desert you know what I'd choose. Rather than a great-looking stallion.

hey i like what you say and the way you say it not that i undersatnd a word of it.
i would like to learn to become a hacker im 23 and very eager to learn any help will do can you send me some programs or post them i'll give you all u need if u reply thanx

That's funny. Your style of critique is so stupid and blah it makes me want to re-use it on you, but it's not designed for re-use and a "real language designers critic" would know how to make their critique re-usable for maximum effect and virality... bleh.. you're way off buddy. Learn to think before you talk.

Excellent article and great unbiased perspective. As Eric, I also have almost a dozen languages under my belt. Python is one of the better. I'll use anything that I need to get the job done, but these days I try to avoid Perl, C++, and C, and I use Java, Python, and C# when I can.

Hello mate,
Are you aware about the fact that __python__ isn't comestible -- even if it's a non-venomous snake? Moreover, there is a threat of extinction against this species. So it'd be nice if you don't pourchase them.

I've heard a lot about python ,perl etc but i am sort of a newbie when it comes to programming. I really want to get serious about coding but i dont know where to start. I also want to know how long it will take me to get a grasp of it. I would really appreciate it if you could help me out.

What is it wrong with you all of you pathetic programmer whimps. Always wasting time looking for and learning "new better" programming languages that will save you time - and wasting truckloads of time doing so!!! Then after learning five new programming languages you choose one, do a project with it and start learning the next five - 'because it will save you more time'. LOL!!!! Get a grip. Are you guys are just lazy and/or dumb and/or bad programmers? Just perhaps you should just learnd ONE programming language and learn that one really well, eh? What do you say? I callenge anybody who claims they can be more productive with Python or any of their crappy languages than I can be with just simple and plain C! That's right. C. Anytime! Anywhere! What's more I can still run and even compile (gosh!) my programs from 10 years ago. You probably don't even remember what programming trash you used back then, eh? I thought so. Plus my program will be fifteen times smaller and sixty times faster. But please just go back wasting more of your time learing yet another language you will hardly use and never be good at pretending you are a trendsetter. Chuckle chuckle.

"Just perhaps you should just learnd ONE programming language and learn that one really well, eh?"

and uh duh, how do you choose that one without looking at more than one Language. Or, just take the first one you see I guess.

"I callenge anybody who claims they can be more productive with Python or any of their crappy languages than I can be with just simple and plain C! That's right. C. Anytime! Anywhere! What's more I can still run and even compile (gosh!) my programs from 10 years ago."

Uh, let's see. For example, I write a gui hello world in C and compile it for say MS Windows, then rewrite and compile it for Mac, then rewrite it and compile for Amiga,... Palm, ...Nokia ... others. Now then, write a gui hello world in python and portability rules.

"Anyway, if your background is primarily C and similar languages, I'd recommend taking it to "broaden your horizons" a bit. If nothing else, learning something different will make you think about the same problems in different ways.

OTOH, if you're not really into programming in general then I'd drop it." -gamedev

" You probably don't even remember what programming trash you used back then, eh?"

Sure I do. I used C. ;-)
I still do from time to time, but when I discover a programming language that makes me more productive and more importantly, makes programming more fun, I'm not going to let fear of change stop me from using it.

Oh, and speaking of "waste of time". Well... you can probably guess where I'm going with this...

Have you looked at Ruby? My impression so far is that it is very similar to Python. I couldn't find a good reason to prefer Ruby over Python. Ruby on Rails seems to be a way of generating code using simple conventions, so could be done in a similar way with other languages.

I always like to see discussions of different scripting languages. It's unfortunate that people view this as a "language war" of one scripting language against another. What's really at stake is scripting itself. There are so many things that can be done with scripting, but so few scripting languages are general-purpose. VBScript only works well with COM. Javascript is intended for web browsers. Tcl is made for short bits of "glue code". PHP is for web pages. PERL matured to be general-purpose, but its roots are in text manipulation.

I have not worked with Python yet, but it's nice to see attempts at making general-purpose scripting languages, and it's nice to hear reports from people who have used them. We need more of these languages, and more research in them.

Um, we don't need more languages. We need one that has a general enough application space, so that we prefer to apply it to the next problem rather than deciding that the new problem needs yet another language. How many languages do you want to have to learn? As far as I'm concerned, Python is that one language, or pretty darn close.

Open question: what's a 'scripting' language? why is Python called a 'scripting' language, so people put it in the same head space as bash, tcl, perl, awk? It has mostly replaced C/C++ for me, in addition to having entirely replaced those scripting languages.

From a 'python marketing' standpoint, I'd define a scripting language as one which requires you to put $ or whatever in front of variable names, and makes quoting strings an optional construct, and does string variable substitution inside string constants unless you force it not to with odd escape characters. A non-scripting language is one which has simple, clear-cut lexical conventions and parsing syntax.

There: now python's not a scripting language, it's a real language that has dynamic runtime typing and name binding, and dynamic compilation (unlike most 'scripting' languages). This distinction may seem contrived, but I think this goes a long way to explain why most scripting languages become unmaintainable very quickly for longer scripts, and Python doesn't. The $ are an advantage when you are writing a simple bash script, but a serious burden in code which is more complex, or is not actually working with strings.

In advance I appologize for my minimal knowledge of the english language. Iam also not a guy who's studying abilities are above average. So now having said this and being busy with studying Java 2 for about 3 months now I read your article about python.

I am an AIX system administrator for a couple of years now, but having no college degree or even an AIX certification of some kind is holding me back from getting a regular ongoing job.

So reading your article and having a hard time remember the massive amount of java 2 details, it convinced me to at least hold my J2 study and give python a try. I will also have a look at Ruby, you never know how it hits me. :)

I am looking for a complementary language to Php5, for more demanding projects. It should be faster, have an standartised class framework and scale fairly well. The speed of development should remain rather high. Python or Java or ???

After using python cross-platform in a real world project I can tell you that perl is much better.

If you have a large class and at some line you accidentally add a blank line or you end up chopping a line, then your program will act busted - when it was just a silly extra line.

Multiple versions(old/new) of python running together on the same linux box causes problems that you shouldn't have to deal with but since python doesn't have a plan for dealing with multiple version of the same library file then I guess you're screwed.

try blender which uses a old version of python, get a python plugin for blender and then put it on a system with a new version of python - ouch the pains.