From Issue #73May 2000
Sabes mucho ingles?
si sabes mucho ingles primero tienes que ir a http://www.catb.org/%7Eesr/faqs/ para ser un hacker, no un cracker
Yeah Eric, it certainly is interesting. Now that Jim has released IronPython for both .NET and MONO/Linux we finally have access to a huge class library and integration between languages. For me this means that Python might finally be useful.
Back in 2000, Python was the clear choice for scripting.
But in 2004, Ruby is the way to go and rapidly gaining momentum.
Back in 2000, the documentation for Ruby in English was virtually non-existent. But several English Ruby books came out in 2002 and the language is rapidly winning converts from both Perl, Python. In Japan, Ruby is already more popular than Python.
In a nutshell, Ruby's author took the best of Perl, Smalltalk and other languages when coming up with Ruby--it literally stands on the shoulders of giants and it clearly shows.
While designed from the ground up to be purely object-oriented, it also recognized the practical needs of programmers and allows provides shortcuts so that one-liner scripts are both possible and easy-to-understand. There are also numerous examples of design patterns (made famous by the "gang-of-four") implemented using Ruby.
If you like Python, check out Ruby. Once you try it, chances are good that you'll not only be productive, but have fun programming.
You'll also find the #ruby-lang IRC channel rather friendly to a "ruby nuby". Compare this to the rather notoriously unfriendly IRC channel of another scripting language (hint: it is not Python's channel).
Ruby 1.8.1 is the current release and Ruby 1.8.2 is scheduled for release around July 7, 2004. Check it out and see what the future of scripting is all about.
For a neat comparison of short snippets written in C++/Java/Python/Ruby, see the Rosetta Stone at:
Yes, Ruby is great, but when it comes to unix scripting, python still rocks. Thanks for the ruby links.
Unless its been added in the last few months, Ruby does not support Unicode. Python does. For me, that by itself rules out Ruby for many applications.
Ruby doesn't really offer any significant advances in expressiveness over Python, but it borrows a ton of misfeatures from Perl. Net result for me: Ugh.
This guy writes very well! Does that proves that writing clean code can be a subset of writing clean? (and relevant, and expressive, and so?)
Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital
asset of a competent programmer.
-- Edsger W. Dijkstra
$I .* see .* \what you|u mean|t \[in a way\]
Seldom do I use the pithy acronym that is LOL, but this comment most certainly caused me to post:
I have not (yet) truly begun exploring the mysteries of Python. I have been struggling for some time now with Perl, and I've run up against a particular roadblock that I'm curious whether Python will let me pass.
I have an existing program (written by someone else, in FORTRAN) with a command-line-driven user interface and a graphics extension (written by me, in C) that accepts arrays and displays them in 2D format. This program works fine under UNIX, but now I have to rewrite the graphics to work under MS-Windows, preferably in a fashion that is not platform-specific.
The problem I've been butting my head against with Perl is that it seems very difficult and esoteric to call a module (such as Tk) from a Perl function that is called from C. I'm also having problems with passing arrays by reference between Perl and C. The numerical address comes through, but I can't dereference it.
Is there a (relatively) trivial way around these issues in Python? If so, I'll stop wasting my time on Perl......
If all else fails, you could take your existing C code and wrap it using the Python API to create a new module (called extending). Python could then act as the intermediary between your low-level C algorithm and whichever GUI you want to use (Python does interact pretty well with Tk via Tkinter).
keep in mind that this is directly from ESRs homepage ...
OMFG.... this is one of hardest to read posts i have ever seen (and as a long time CS admin i know what i'm talking about).
Have you ever considered using at least some structure in your sentences? An occassional point or a line break can do wonders :)
(BUT: no offense meant)
To the topic itself. I started with python several years ago. Before that i wrote a couple of applications (mainly web applications) in several other languages (NOT php! I will never touch that). I was amazed how quickly i was able to generate complete applications. I was also amazed, as a notoricly lazy typer, that i was able to quickly read and understand code after several months not touching the code despite the lack of proper comments or documentation.
That doesn't mean i dont comment or document. I'm just not doing it very much.
I think i once read somewhere that the ratio of comments in a code that is necessary for a reader to understand what it does to the code itself is a hint on how readable and well designed a language is.
Well, my c / c++ experience was i had to write nearly as much comments as code. In python i needed a small comment only in parts where something really important happened (i am using docstrings a lot though). In other languages like VB / VBScript ... I commented and documented a lot with the result that i still was unable to read the code afterwards...
Yay, Python... i see no reason to use another language for my day-to-day tasks
I am convinced, and though I was always intrigued with the prospect of a language that enforces indentation, I was put of by the fact that programmers I know, never mentioned the language.
I read your article last week, and I began studying Python.
I write small utilities now, something which have taken me considerably longer in any other language I have been programming in.
Thanks Guido, and most of all. Thanks Eric, in my world, my first choice of demigod, is probably you.
I've used another language that enforces indentation: COBOL.
Python is a breeze after that (in fact, most languages are).
I used another language where indentation matters: OCCAM. This was developed to support parallellism in a programming language, and it did run on so called Transputers.
Transputers are (were?) processors with integrated communication links dedicated to build systems with a large number of CPUs. Each CPU has its own memory. The communication links are directly supported from the instruction set. Interestingly a task scheduler is integrated into the instruction set.
For my MsC thesis I created a piece of assembly able to monitor the scheduling. The output of all CPUs (we had a box with 32 of them) was then fed into a tool (on a Sun, in C) which created a report about the achieved parallellism of the application. Target was to automatically redistribute the application over the CPUs to gain more performance; measure again, and iterate until the optimal performance is found. Ah, the good old days!
I think using the indentation is not so bad: a lot of times I have seen code with correct indentation but wrong meaning (the funny semicolon-after-an-if-statement trick in C...).
So I think I will try Python, it sounds great.
goddamn. this is a hard one!
couldn't tell what the message was.
tried pyhton standard library for simple encoders/decoders but with no success.
my guss is that the whitespaces should remain intact.
what the hell is "g555 5t 55 5 5 5 5" - i guess that can be a breaking point.
also note the word "james" at the end of the first sequence. is it on purpose?
let us solve this godamn puzzle....
You might try searching CPAN for the "Lingua::31337" module to decode this using Perl.
You ask Why ?
It is simple. You are really not at the right place to talk about cracking because every one here are or want to be hacker (and it is not the same thing trust me > go see the jargon file).
Now you can't make you any friend here because everybody hate you (although you are anonymous).
In other words, in the Internet, there is neutral places, places to encourage the good creation and places to encourage destruction. And you are talking about destruction in a place where we encourage good creation.
Think about it
(I am finishing writing and I see the the "Why ?" was posted in 2002 > anyway)
This makes no sence .This is a sting all computers on this web site will be shut down a police car is speeding to your house now!
If you are new to programming, and wish to use Python as you're first language, which I recommend, havind tutored many undergraduates, you can't go wrong with "How To Think Like A Computer Scientist: Learning With Python". It can be downloaded at http://www.ibiblio.org/obp/. If you are sincere, and work through this text, you will be well on your way to reaching your goal as a programmer.
Regards to all.
My apologies, as I typed an incomplete link to the download. It is more accurately
One more correction:
Great book. Essential reading.
Thanks Eric. You have put into words much of my own experience and understanding of the Perl vs Python debate. Over the last 20 years, I have coded in a variety of languages (not as many as yourself) and even written a few simple ones, and I have been very impressed with Python. My most productive language in 95-97 was Perl but, like you, I was dismayed at how hard it was to maintain my own code. In 97 I discovered Python and found it a very good match for how I build solutions in my head. It is clear, maintainable, concise, and well supported. Thanks again. -- Mike.
Perl is very readable and maintainable when properly coded and commented. Any programmer can write tortured code in any language (not that this is the case with ESR).
Why should you use Perl and not Python? How about the breadth of available modules for Perl. Python is pale in comparison. It will be a long time before I switch Perl for python; there aren't enough libraries.
Note, I do not disagree with anything ESR said. Python is indeed very clean and readable. I am just more concerned with coding speed at this stage in my life. I have to solve the problem, quickly.
Missing? What's missing in Python? In the two years I've worked with Python, I haven't needed any library that wasn't couldn't be found for Python. Most everything I've needed is in the standard library and what little that isn't I found through Starship.
If there is anything missing, please post what that is so I can write it.
The one thing I want python to have (so I hope you write it :) ). Is the equivalent of perl's Spreadsheet::WriteExcel which is a library to write the binary excel file format. I think this would be a great contribution to python, or maybe its me being selfish. Good luck!
Why not try using the XML and ZIP tools to make OpenOffice.org Calc files? There's probably a way to do a format-convert call to OpenOffice.org from Python.
why not ride a bike to iceland instead of flying a plain?
Perl is very readable and maintainable when properly coded and commented. Any programmer can write tortured code in any language
Not buying it. Here's an example from a small script I wrote today.
$sysmsg =~ s/&/
sysmsg = sysmsg.replace('&', '
The Perl version is not readable unless you know Perl well. There's nothing intuitive about it, from the '$' to the '=~' to the bizarre regex substitution thing. The Python version is readable and clear to anyone with just rudimentary programming skills.
I find '$' quite useful in perl. when I define new variables, I don't have to worry about conflicting with key words. you can actually define a variable with the name 'if' by '$if'.
I find python confusing on the other hand.
e.g. sysmsg = sysmsg.replace('&', ' ')
what if you wrote "sysmgs = sysmsg.replace('&',' ')"
there is a small typo! In perl "use strict;" would find that for you, but python has no equivalent yet. Also, I find it quite exhausting to have to remember the different "runtime object" types. if sysmsg was declared an interger or set an interger by accident somewhere, it won't show or warn you like in Java during compilation!
Python class types is quite confusing at times. e.g.
a = 3
b = "2"
c = a + b
would cause an error, while in perl
$a = 3; $b = "2"; $c = $a + $b; is functional.
what matters here is if you had taken b from command line.
b = raw_input()
would return a "string" and you have to explicitly convert it into an integer. But there is no where to specify what "b" is. you can use it as an integer and then a string.
It really confuses me!!!
perl types are confusing at first('$', '%', '&', '@'), but if you take the time to understand them and then learn ooperl, it might become quite convenient to use. (with -w and use strict guarding the design.)
the main reason that made me thought about converting to python is that perl object codes needs more typing than python. in perl "$object->command();" while in python "object.command()" has less typing. Well, just a thought after studying perl for 6 months.
I've worked on QBasic (I was 8 and it was all my father knew), fiddled with VB (Hey, I was only 12), tested the water with C++ (It was a high school course), learned a bit of Java, Wrote a some things in Perl (I'm no expert), and I'm currently working with Python. I haven't used ooperl but I can see what you're talking about.
I did notice some of those annoyances but, in order to prove to myself that they couldn't have done any better, I traced out the changes one generation after another. ("Ok, if I fix this then this needs to be changed but if I do that, then it introduces this problem.") I couldn't find any better way.
In the past couple of months, I have been learning both Perl (as required by my work) and Python (just for fun). So far, I have found that having to remember the "&", "@", etc. for variables rather annoying when just working with variables...but Perl can become very difficult to use when you attempt to create a data structure of a data structure, precisely because of this syntax. As I happen to like making lists of dictionaries of lists sometimes, this makes Perl much more difficult for me to use.
So far, the only shortcoming I've seen in Python on this point is the inability to create anonymous functions (ignoring the simple and limited lambda functions). This is easy enough to get around, though, so it isn't a major problem, just an inconvenience.
If you actually want to name variables "$if" or after other keywords, then yes, you will fit right in with Perl.
One of the problems with using variable names that happen to coincide with reserved words is confusing the variable with the reserved word (i.e., forgetting the $).
As far as Python is concerned (and programming in general), you should not write your programs where the functions/variables/reserved words/etc. could be confused - especially when you have to come back to the program later to update it.
As far as Perl's use of (&,$,@,whatever), you can get the same functionality by using a prefix for your variables; i.e.:
p_if = (something)
The other item is if you use a predefined prefix for variables throughout your code, it becomes easier to trace the variable in other modules as well.
Proper programming should allow the flow to be easily distinguishable anyway. As ESR pointed out, even people comfortable with Perl may have problems getting reaquainted with the language after even a short hiatus.
Many thanks for the example, that clears up so much inner contention I had as to the real value of Python and of Perl.
Shouldn't there be a smiley after this comment?
what is: Perl: $sysmsg =~ s/&/ /g; Python: sysmsg = sysmsg.replace('&', ' ') supposed to mean?
it replaces ever instance of "&" with a " " in the string sysmsg.
Define a vairable called $sysmsg, which when called does a global substitution of & with a wjite space ( I think)
Perl: $sysmsg =~ s/&/ /g;
Python: sysmsg = sysmsg.replace('&', ' ')
Both lines do the same thing. Python is clearer.
I've been away from programming for over 10 years now, (excluding some Microchip PIC assemblier) and I decided to choose between Perl and Python as the first language I'd try to pick up after a long hiatus. I ended up with Python. Like ESR, I was orginally turn off by Python's significant indentation, but Perl's "many ways" approach turned me off even more. (The comment I once read about different 'dialects' of Perl based on how a programmer learned to do things was the final bit of information I needed before making my decision.)
As ESR stated in his article, human time is far more valuable than computer time. (Hence he didn't consider running back to C.) So the quantity of modules available in a language is an important consideration, or is it?
How many modules do you use on a day to day basis? 10? 50? 100?? Look at what you actually use and then check to see modules exist. Unless you're doing some pretty esoteric things, I'd be surprized of Python doesn't already have them.
There's no doubt that Perl's greatest strength is cpan. There are an enormous number of third party libraries available. But the quality of cpan modules is uneven- some contain significant bugs, so it's a bit of work to assess whether or not cpan modules are safe to use.
As for the standard libraries, I think that Python's standard library is actually somewhat more complete than Perl's. There are also a _lot_ of third party Python libraries around, and for some things Python has better libraries than Perl. Gui programming is definitely one of them. Python has bindings to an awful lot of Gui libraries, some of which are IMHO much more useful than Tk. And the asyncore/asynchat library for asynchronous socket programming is the best library for developing network servers that I've ever used.
I think that Perl is pretty much the best language around for what it is best at: writing short scripts for processing text, and performing system calls. Python is good for that sort of thing as well, but I find Perl's regex syntax more comfortable than Python's, and I really like how succinct Perl code can be when I'm writing simple scripts. But for medium and large applications, particularly end user apps requiring a complicated GUI, or apps requiring a complicated OO design, I prefer Python to anything else except Smalltalk.
perl's greatest strength is cpanel not cpan
"Lean" some writing skills, O alien(ated) one...