FSF Awards Guido van Rossum For Python

bkuhn writes: "The FSF today bestowed its fourth annual Award for the Advancement of Free Software upon Guido van Rossum . The two other finalists were L. Peter Deutsch and Andrew Tridgell." Developing Python seems like a good reason :)

Comments

Python

[MarkusQ]

*smile* I assume they only care if it's free-as-in-speech, and not if it's free-as-in-format.

-- MarkusQ

P.S. I say this as a Python fan; truth be known, that's pretty much how I've indented my code (in anything but forth/postscript) since the mid-seventies.

Great

[__past__]

This is really nice, especially after all this fuss about the Python license not being GPL-compatible.

I really like Python, and the style Guido and the other core hackers manage it. Best example are the PEPs (Python Enhancement Proposals), a very open and community-oriented way to deal with language evolution.

Re:Great

[djmitche]

Guido's management of this enormous, popular project stands in some contrast to Linus' management of Linux, as discussed here on slashdot in January. Guido has held a tight on his project, but has always been careful to justify his positions with solid reasoning based in a few of his own well-known principles of language design.

Guido's PEPs are a good way for him to relinquish some responsibility for the project while ensuring proper formal scrutiny of and public comment on all language improvements.

In its relatively short existence, Python has made some impressive gains in popularity and diversity of uses (from embedded systems to "supercomputers" and from 10-second syadmin hacks to full-scale applications). Congratulations, Guido.

Previous awards

[arnoroefs2000]

In 1998, Larry Wall for his work on Perl and other software.

"Larry Wall won the Free Software Foundation Award for the Advancement of Free Software for his many contributions to the advancement of freely distributed software, most notably Perl, a robust scripting language for sophisticated text manipulation and system management. His other widely-used programs include rn (news reader), patch (development and distribution tool), metaconfig (a program that writes Configure scripts), and the Warp space-war game."

In 1999, Miguel de Icaza for his work on GNOME

"de Icaza headed a team of more than 300 programmers worldwide, most of them volunteers, in the development of GNOME. GNOME is a user-friendly graphical users interface (GUI) and programming platform for GNU/Linux. GNOME 1.0 was first released in March, 1999 and has since had a step-up release."

In 2001, Brian Paul for his ground-breaking work on the Mesa 3D Graphics Library

"The Mesa 3D Graphics Library allows free software users to model and render in full 3D." Jeff Bates, chairman of the Free Software Foundation Awards Committee said. "The library has added tools and capabilities to the GNU/Linux system that are being utilized by people all over the world."

Cannot trim to fit frame

[Anonymous Coward]

Unfortunately, Guido cannot trim this award to fit into the picture frame.

Because white space matters on this award.

And that in turn...

[Anonymous Coward]

makes it possible for me as a probably far less advanced programmer to be able to *read* your code :-)

Python deserves all credit it gets really, mostly because it's really really simple. They should ditch tk as default windowing/widget environment though and switch to wx but other than that I love it.

And it is NOT true that any stuff one can do on 2 lines in perl would take 6 in python. Not at all.

Re:And that in turn...

[Shiny Metal S.]

And it is NOT true that any stuff one can do on 2 lines in perl would take 6 in python. Not at all.

Well... It depands.

"You want it in one line? Does it have to fit in 80 columns?" - Larry Wall

;)

This award goes to all the Python community.

[sinserve]

You know, Guido is the root object, and we all have
the Award attirbute, inherited from out based class.

Re:Speaking of Ghostscript

[Anonymous Coward]

DGS

Yes, but...

[code65536]

I still like Perl, better, though. :) I'm not sure I like Python's strict style rules. It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

Re:Yes, but...

[Zagadka]

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

If you ever have to maintain code written by others, you'll be glad that Python encouraged them to use good style. (I say "encouraged", because no language really forces good or bad style.) It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Re:Yes, but...

[__past__]

I still like Perl, better, though. :)

Come on, Larry Wall got the award in 1998! (And he was in the commite chosing GvR for this years award)

However, note that Python is not strict at all, other than with indentation - and Emacs handles that for you. It's just a nicer syntax - it doesn't matter much, but it definitly doesn't hurt. (And, btw, I believe it might have something to do with Guido being from the Netherlands - I don't think their keyboard layout is much different from the german one, and on that, typing curly braces is a major PITA [Alt-Gr 8/9]).

And if you insist on Perls broken syntax, but without its broken semantics, there's always Ruby... :)

However, Guido and Larry once should get an award together for this great Parrot hoax last april. Remember? It read like

if dollar_underscore == 1:
do_something()
}

Re:Yes, but...

[Shiny Metal S.]

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.

Re:Yes, but...

[Trepidity]

The original poster's point still stands though - most Perl code is utter crap and completely unreadable. This is not to say that Perl is inherently worse than Python, and good Perl code is probably comparable to good Python code (maybe better?). But Perl is much more lenient in allowing really really horrible code, which for some reason a lot of people take advantage of.

Re:Yes, but...

[johnnyb]

I spent two years not learning Python simply because of those rules. However, they are kind of nice. THe thing I absolutely LOVE about python, though, is the ability to pass bound methods as first class objects. In addition to that, I like it's implementation of lambda, as well as the new generator stuff in 2.2. Python is a very-well-constructed language.

However, for those who have done python longer than I, what happens if person A edits in emacs using spaces for spacing, and person B edits in vi using tabs for spacing? How does Python determine the length of a tab, and is there anything to help you out if you are the victim of such a tragedy?

Re:Yes, but...

[Kirruth]

I love both Python and Perl, but they occupy different parts of my brain-space. Python is very much a well-thought out, systematic kind of language whereas Perl is more of a code party.

With Perl it's either, "My God, Larry, you are a genius" or "What exactly were you smoking, buddy" (more usually the former), whereas Python's strength lies in having a very solid core language sitting squarely across the areas people use for general purpose programming. If its text I use Perl, if its objects I use Python.

Using either of them, I am just amazed at how great they are, and definitely cheer on Guido for his award.

Re:Yes, but...

[Shiny Metal S.]

The original poster's point still stands though - most Perl code is utter crap and completely unreadable. This is not to say that Perl is inherently worse than Python, and good Perl code is probably comparable to good Python code (maybe better?). But Perl is much more lenient in allowing really really horrible code, which for some reason a lot of people take advantage of.

Most of everything is uter crap. This includes every aspect of human creation.

Few days ago, someone posted this Perl code:

#!/usr/bin/perl
use MIME::Base64; $x = ""; while(<&gt) { $x .= $_; $x =~ s/[\r\n\t ]//g; } print decode_base64($x); exit 0;

to which I posted this:

$ perl -0MMIME::Base64 -e 'print decode_base64 <&gt'

a one-liner to be typed directly at a shell prompt, which does exactly the same. Much simpler, isn't it? It's just that, like Larry Wall has well said, Give people enough rope to hang themselves, and they'll usually figure out how not to, after several successes.

I'll give you another good example. Some time ago I tuned Perl code of one Senior Design Technologist (I won't tell you the name of his company, for obvious reasons). This was one of my records, so I have the exact stats. His program had 190 lines of code in 6530 characters and he asked me if the same can be done in more elegant way. I wrote my version from scratch, which had only 13 lines of code in 227 characters, i.e. it was 30 times smaller - it's 3% of original size. It was also over 900% faster than the original (doing exactly the same of course), as a side effect of my elegance-tuning. And no, it wasn't obfuscated and I wasn't writing it just to use as small space as possible. Later I wrote a minimal version of that program and it had 2 lines in 112 characters (including a new-line), so the real 13-lines version was quite readable, with descriptive function and variable names, indentation, etc.

So, my point is: Most of everything is uter crap. This includes Perl code. But it says more about programmers than about the language itself. Like the fact that most of text available on the Internet is crap, doesn't mean that the English or any other natural language is crap.

The problem with newbie Perl programmers is that they usually write in C, not in Perl. The Perl motto is There's More Than One Way To Do It. That means that you can also program using a C-style if you want. This is sometimes very useful, but it's often abused by beginners. So it's very common to see a code like this:

for($index = 0; $index <= $maxindex; $index++){
printf("ITEM: %s\n", $items[$index]);
}

where you could just write:

print "ITEM: $_\n" for @items;

You see my point. I'll quote Larry once again: Perl is designed to give you several ways to do anything, so consider picking the most readable one.

That said, I may surprise you, that I am going to learn Python. For few reasons: It's a nice and powerful language, with many unique features (like e.g. the idea of using the indentation to define blocks scope) so it's definitely worth learning, even if it won't be my main language, and the WorldForge AI scripts are written in Python.

OK, I said a lot, much more than I originally wanted to... Now you should tell me something interesting about Python, as a revenge. :)

Re:Yes, but...

[ameoba]

Even if those 'strict style rules' closely mimic accepted 'best practices' in code formatting?

Indenting code is a lot like punctuatiting English. Yeah, ee cummings was able to get some milage out of creative punctuation, but when most people do it they look retarded. The same goes for code; a few ppl can make their code better by using creative punctuation, but most ppl end up using the freedom to write unreadable, unmaintainable code. It's OK to write in a language that doesn't look like C.

Considering all things that Python does allow you to do, it's a fair trade off. 'Sides, your code never gets confused with line noise.

Re:Yes, but...

[WNight]

I was going to make your point about most of everything being crap, but you made it so very well.

I'll just add that I've cleaned up hideous code in C, C++, ASM, Perl, Basic, VB, ObjectPAL, and probably other languages. Usually because somebody didn't know a simpler way to accomplish the task and ended up reinventing the wheel, or used a bubble sort where a quicksort would do, etc. Or, in nasty cases, coded their own quicksort as an optimization, because they didn't realize the libraries contained a quicksort routine...

I think my code has gotten easier to read and less crufty in languages like perl because things that would have been such a pain in C (for instance) are just a line or two of code. This lets you get down to the business of writing the program, not the functions.

(The side effect of this though is programmers who do terribly complex list operations without an understanding of what would be involved in coding them manually, and thus no idea of what is involved in processing them. But that's my example of why formal education (forcing you to do stuff that doesn't immediately make sense, like ASM) is really a good thing.)

Perl can make an unreadable program, but it'd be an unreadable C program, just ten times longer. And I'm sure many of the people I've worked with (myself included I'm sure, at times) could mangle it even with Python, if we were rushed.

Re:Yes, but...

[costas]

One common misconception: Python only forces you to use consistent identation *within the same code block* not the entire file or project. Which makes perfect sensem if you think about it.

Re:Yes, but...

[smallpaul]

Perl is designed to give you several ways to do anything, so consider picking the most readable one.

The problem is that programmers that care will differ radically in which the consider the most readable one and many programmers just don't care at all. So in either case we have trouble reading each other's code because even when we are trying our hardest we can easily make code that is mutually incomprehensible. Python cannot prevent this but it can encourage a consistent and readable style. The language encourages good taste. No more, no less.

Re:Yes, but...

[Shiny Metal S.]

The problem is that programmers that care will differ radically in which the consider the most readable one and many programmers just don't care at all. So in either case we have trouble reading each other's code because even when we are trying our hardest we can easily make code that is mutually incomprehensible.

When you know the syntax and semantics, you won't have problems reading different styles. At least I don't have any problems, and I don't consider myself a Perl guru. Read The Camel Book and you'll learn everything you need to understand any Perl code. I don't know personaly any Perl coder who would not understand the Perl syntax.

It doesn't meter if someone has written
print "ITEM: $_\n" for @items;
or
for(@items){ print "ITEM: $_\n" }
or
foreach $item (@items) { print "ITEM: $item\n" }
or
print map {"ITEM: $_\n"} @items;
when you know the basics of Perl, you understand it.

Also you have to remember a very important thing, true for Perl, Python, Smalltalk, C++, Ruby, Java or any other higher-level language. When you have a good code, you don't have to fully understand or often even read the implementation details to maintain it (not to say about simply using it). All you need is to understand the interfaces. When you have a working class and you need to add a new functionality, you shouldn't edit the implementation. You should subclass it instead. These are the most basic concepts of code design for future reuse. But you have to actually design the code in the first place, not just write some crap.

Python cannot prevent this but it can encourage a consistent and readable style. The language encourages good taste. No more, no less.

Perl is designed somehow similar to natural languages. You don't have anything in English, Latin, Polish, Russian or any other natural language, which would "encourage a consistent and readable style", still there's a lot of great art. Remember that there's not only one good style of English, almost every poet, every novelist, every writer has his or her own, unique style. And that freedom of choice also means that you can hear lots of crap. But we can't restrict English to only a subset of lexical and semantic rules, because any restrictions which would prevent stupid people from saying stupid things, would also prevent really smart people from saying really smart things.

Re:Yes, but...

[smallpaul]

When you know the syntax and semantics, you won't have problems reading different styles. At least I don't have any problems, and I don't consider myself a Perl guru.

Lots of Perl people do tell me that they have trouble reading other people's Perl code. The examples you give are four extremely readable Perl snippets. They are not typical. Even so, they are enough to confuse a new Perl programmer which I would say is reason enough to choose one way and stick with it.

When you have a good code, you don't have to fully understand or often even read the implementation details to maintain it (not to say about simply using it). All you need is to understand the interfaces.

And when you find that there is a bug in that code? Or need to add a feature that cannot be added by subclassing (i.e. MOST features!)

Perl is designed somehow similar to natural languages.

I know that that it the mantra of the Perl community but that doesn't make it either true or relevant.

You don't have anything in English, Latin, Polish, Russian or any other natural language, which would "encourage a consistent and readable style", still there's a lot of great art.

When I'm working together on a project artistry is secondary to engineering. Natural languages are not typically used for engineering. In fact, we tend to use languages that are more formal: like algebraic symbols or pseudo-code languages.

Remember that there's not only one good style of English, almost every poet, every novelist, every writer has his or her own, unique style. And that freedom of choice also means that you can hear lots of crap. But we can't restrict English to only a subset of lexical and semantic rules, because any restrictions which would prevent stupid people from saying stupid things, would also prevent really smart people from saying really smart things.

The descriptive power of a natural language is not proportional to either its vocabulary or its grammatical complexity. As I'm sure you've been told, the problem solving power of a programming language is exactly equivalent to that of any other programming language. Really smart people can say really smart things in ASSEMBLY LANGUAGE. So if you want to compare languages you have to look at other factors such as cost of development, cost of maintenance, amount of fun (Perl probably wins in that category for some people), etc.

If what you really mean to say is that Perl is more fun, for you, and you've actually tried the other languages to compare, then I will support that wholeheartedly. But there is a price to be paid: and whoever has maintain your code is probaby paying it. And there is no payoff in descriptive power or cost of development.

Re:Yes, but...

[Shiny Metal S.]

I'll just add that I've cleaned up hideous code in C, C++, ASM, Perl, Basic, VB, ObjectPAL, and probably other languages. Usually because somebody didn't know a simpler way to accomplish the task and ended up reinventing the wheel, or used a bubble sort where a quicksort would do, etc. Or, in nasty cases, coded their own quicksort as an optimization, because they didn't realize the libraries contained a quicksort routine...

You're right. The most important mistakes which I've seen, was caused by the lack of knowledge about CPAN or STL. The syntax is on the second place. Such programs run much slower, have more bugs, and are harder to maintain, but what's even more important, it took much more time (and money) to write them. That is why it's not smart to hire a poor programmer for $10/hour to produce some crap after a week of full-time work, when someone for $100/hour can do it better in few hours. Hackers with high rates are often much cheaper in the long run, that's something which is often being not fully understood by the management.

(The side effect of this though is programmers who do terribly complex list operations without an understanding of what would be involved in coding them manually, and thus no idea of what is involved in processing them. But that's my example of why formal education (forcing you to do stuff that doesn't immediately make sense, like ASM) is really a good thing.)

That's a very good point. Only when I know Assembler, I can fully understand what is really going on, when I run my C program. The same is true with e.g. Perl, when I know C and perl internals. I didn't write any assembly code in the last five years, but still I use that knowledge even while hacking Perl. You have to know how much and what exactly is being done, very low in the machine, when you write
print "$_ $hash{$_}\n" for sort keys %hash;
to fully understand your own abstract code. That's true that you have to master hacking on every level of abstraction, to truly master any one of them.

But speaking about formal education, I actually haven't got much, to be honest. Unless you count dozens of books read, as a formal education. But don't get me wrong, it's not that I think that I don't need a more formal education, it's actually quite complicated, mostly from the economical standpoint.

Perl can make an unreadable program, but it'd be an unreadable C program, just ten times longer. And I'm sure many of the people I've worked with (myself included I'm sure, at times) could mangle it even with Python, if we were rushed.

Good point. Before I knew Perl, I used to write text-processing programs in C. Sometimes many screens of C code, for what I write in Perl one-liners today. And however obfuscated would it be, it's still just one line.

Besides, I do like to have a choice. I write unreadable, quick and dirty Perl one-liners every day, and it's a Good Thing that I can write them in few seconds directly from the shell command line, which would be impossible witch such verbose languages like Java. It's not that I have to write larger programs that way, it's however important that I can if I want to.

You know, you sometimes just want to know hexadecimal values of ip addresses in Net-HOWTO.txt.gz, and you just want to write:

shell$ zcat Net-HOWTO.txt.gz | perl -ne 'print"$1\n"for/((\d+\.){3}\d+)/g' | sort | uniq | perl -pe 's/(\d+)/sprintf"%.2X",$1/eg;y/.//d'

hit enter, get answers, and forget about this crap. Not to design a nice and elegant program. This code is ugly, it's probably not efficient, elegant, fast or readable, but I have my answers after few second from thinking my questions, which is quite important to me. (BTW, I wonder how the same would look in Python or Java - not that I want to start any flame wars whose language is better - I just wonder how exactly the same filter would be written by Java and Python wizards. Would it be smaller? Larger? Simpler? More complicated? More elegant? I'm curious.) And the ability itself to write ugly code, like that above, didn't prevent Tim Bunce from writing DBI, or Lincoln Stein from writing CGI.pm, which are both great examples of beautiful Perl code.

Disclaimer: (this is for some people, who get this thread very personally, even when I stated at the very beginning: "Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today.") I do not think that Perl is better than [insert your language here]. I'm just telling about things which I like in Perl, with many examples of code, real-life situations, etc. I hope that maybe people find it somehow interesting. I'd also love to hear other interesting stories, about other languages. When people tell me about advantages of Python I'm not mad that it means that Python is better than Perl, or that my IQ is lower than theirs, or anything like that - I listen to what they have to say and I'm glad that I can learn something new. It's about time for many people to understand the same.

Re:Yes, but...

[Shiny Metal S.]

Lots of Perl people do tell me that they have trouble reading other people's Perl code. The examples you give are four extremely readable Perl snippets. They are not typical.

I've already said, that I personally don't know any Perl coder (excluding beginners) who doesn't know the Perl syntax and semantics, and who therefore doesn't understand Perl code of other people, written in different styles.

Even so, they are enough to confuse a new Perl programmer which I would say is reason enough to choose one way and stick with it.

Remember that you're a beginner only at the beginning, and after you learn it, you're an expert for the rest of your life. That is why I don't prefer to save few hours (or even few months) at the start and stick with something simple and easy to the end of my days. I prefer to chose what's better for me in the long run.

And when you find that there is a bug in that code? Or need to add a feature that cannot be added by subclassing (i.e. MOST features!)

Then I fix the bug. Isn't that quite obvious? I've already told you that I don't have problems in understanding Perl syntax.

Perl is designed somehow similar to natural languages.

I know that that it the mantra of the Perl community but that doesn't make it either true or relevant.

What is your point? Do you say that Perl is not "designed somehow similar to natural languages"?

When I'm working together on a project artistry is secondary to engineering. Natural languages are not typically used for engineering. In fact, we tend to use languages that are more formal: like algebraic symbols or pseudo-code languages.

That is exactly why I'm saying that "Perl is designed somehow similar to natural languages". It's a quite unique design goal. If every programming language had this property, then it would be quite pointless talking about it to explain what I like about Perl, wouldn't it?

The descriptive power of a natural language is not proportional to either its vocabulary or its grammatical complexity.

But you have to agree, that "A language that is artificially simple induces artificial complexity in all solutions written in that language."

As I'm sure you've been told, the problem solving power of a programming language is exactly equivalent to that of any other programming language. Really smart people can say really smart things in ASSEMBLY LANGUAGE. So if you want to compare languages you have to look at other factors such as cost of development, cost of maintenance, amount of fun (Perl probably wins in that category for some people), etc.

If I didn't consider anything other than the bare ability to solve problems, I wouldn't see the difference between any two Turing-complete languages, and I'd be probably using Unlambda instead of Perl, because the syntax is much simpler to learn, while it's still Turing-complete.

If what you really mean to say is that Perl is more fun, for you, and you've actually tried the other languages to compare, then I will support that wholeheartedly.

And what did you think I could mean otherwise? I was telling different stories and showing many code examples, to illustrate what I like in Perl, not why Perl is better than your favorite language, while strongly stating that these are my subjective opinions, from the beginning, through the whole thread. Please read the disclaimer at the end of this post.

But there is a price to be paid: and whoever has maintain your code is probaby paying it. And there is no payoff in descriptive power or cost of development.

Here you assumed that: I use Perl, therefore my code is less maintainable. Which is irrational, I hope you realize that.

Re:Yes, but...

[smallpaul]

Remember that you're a beginner only at the beginning, and after you learn it, you're an expert for the rest of your life. That is why I don't prefer to save few hours (or even few months) at the start and stick with something simple and easy to the end of my days. I prefer to chose what's better for me in the long run.

Fortunately, you don't have to choose. You can have easy at the beginning and sophisticated in the long run.

What is your point? Do you say that Perl is not "designed somehow similar to natural languages"?

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

Here you assumed that: I use Perl, therefore my code is less maintainable. Which is irrational, I hope you realize that.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

Re:Yes, but...

[Shiny Metal S.]

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but...

[WNight]

Ditto on the formal education, but I try to read books on theory as well as practice, to make sure I understand why as well as what.

It's *always* served me well. I've never had a CPU or disk bound program that I couldn't speed up by a factor of five (or more) by something I found in an algorithms books. (Excepting perhaps, when I use an existing algorithm like SHA1 that I assume has already been fairly well written.)

for some perspective on lightweight languages

[markj02]

I recommend reading this article on DDJ on the lightweight languages workshop at MIT. It talks about Python and similar languages, and their role in the world. Note that both the LL1 workshop and the FSF are at MIT.

Re:Speaking of Ghostscript

[Reality Master 101]

Display PDF is different from Display Postscript. Display Postscript is an older technology, although I'm not exactly sure of the differences.

Bravo for a powerful, easy to learn, easy to use L

[Anonymous Coward]

Python is the easiest to learn, easiest to use programming language ever. It is also a very powerful, object oriented, recursive, workhorse suited to scripting and general porgramming in the large. Google is written in Python, Red Hat installation is written in Python, NASA uses Python; it takes one tenth the time develop a program in Python that it takes in Java, C++, or similar languages. Python can be learned in one day of tutorials on the web.

Ron Stephens
Python City (for learning Python, including web spider that displays all new Pythonic web articles four times a day, continuously).
http://www.awaretek.com/plf.html

DPS Implementations...

[Christopher B. Brown]

Yes, there would be:

• A DPS extension for XFree86
  
  
• GNUstep Resources (See miscellaneous packages)
  
  

For those that think GNOME and KDE are too big and bloated, this is moving towards being usable for some applications.

Keeping relevance, if L. Peter Deutsch didn't win, the somewhat-inadequacy of DGS work that the FSF contracted for might very well be part of the reason...

Not quite...

[Christopher B. Brown]

If you use Ghostscript (from one of the runners-up!), then you're using Postscript, and haven't forcibly licensed anything from Adobe.

On the other hand, if you read a PDF document using acroread, you do have to have a valid license from Adobe

What happened with DPS was that Adobe was not prepared to continue licensing it to Apple under terms they were prepared to agree on. The natural result was that Apple went away and implemented their own thing, namely a "Display PDF" renderer, called Quartz.

The notion that this has much of anything to do with the formats is just silly...

Re:Not quite...

[Reality Master 101]

The natural result was that Apple went away and implemented their own thing, namely a "Display PDF" renderer, called Quartz.

Is that true? There is no standard from Adobe called "Display PDF" and that's totally an Apple thing? I thought it came from Adobe.

Re:simpsons reference

[Kidder]

Gah!
ObSimpsons:
Lisa: This award is the biggest farse I've ever seen.
Bart: What about the Emmy's?
Lisa: I stand corrected.

Re:yeah, but

[TeknoHog]

... did he write Perl? I don't think so.

Somebody wrote Perl? I thought it grew by itself, out of the stray code that had leaked inside hot mainframes from unterminated cables. Python, on the other hand, was designed...

Thanks Guido

[MAXOMENOS]

Not that it matters much, but I really want to thank Guido for everything he's done for the Python world, including working things out with the FSF regarding GPL compatibility. It's a real pleasure developing in this language, and I know it's cut development for some projects I've worked on by about half.

So, congrats on a job well done and an award well deserved.

Re:Bravo for a powerful, easy to learn, easy to us

[Xerithane]

Google is not written in Python. Google has pieces of it written in Python.

NASA also uses Fortran, COBOL, Pascal, Perl, C, C++, Java. What's your point?

Python is really not an all-in-wonder language, it's good but please don't tote it that it is the wonder language that will solve all the problems of the world, because no language is. Python has it's fallacies as well.

Re:Things I love about Python..

[fperez]

Things I would love about python :)

- A compiler (very hard, but I can dream)

Keep an eye on the weave project here. Currently it allows you to inline C/C++, and work is under way to have automatic acceleration of arbitrary python code via compilation to C/C++. It's *really* cool.

Re:yukk

[TeknoHog]

no braces {} for blocks,
no ";" to end the statement.
Whitespace mandatory.

Yukk,
Puke.

So you don't like whitespace and line breaks. Then why the heck are you indenting your code? You have such fine {;} operators, you can write every program in one line. ;-)

Open Source advocates on the FSF panel?

[ftobin]

I find it interesting that Eric Raymond was on the selection committee. If I rcall correctly, Raymond has specfically stated he is not a follower of the Free Software movement (just as Stallman has specifically stated he is not a follower of the Open Source movement).

Re:Bravo for a powerful, easy to learn, easy to us

[FFFish]

"Fallacies"?!?

pray, do explain!

Implementation != Specification

[Christopher B. Brown]

PDF is a specification on which Apple based their own scheme, Quartz.

There is no such thing, in formal terms, as "Display PDF." Neither Apple nor Adobe use that name. Apple calls their thing (which, as near as can be told, has NO Adobe encumbrances) Quartz. Adobe has a document format that they call PDF, but nothing that they call "Display PDF."

Re:Python complaints

[Tablizer]

(* Inheritence allows you to take an object and modify it, using existing behaviour with little effort. *)

Often the differences are not on method boundaries. IOW, the change granularity often does not match the method granularity in reality. Plus, you end up with the "fragile parent problem" in that changes to the parent may break many children. Thus, nobody wants to clean up the creeping inheritance vine.

Many seasoned OO proponents suggest using inheritance sparingly. They agree that inheritance is way oversold in the "Learn X in 21 Days" kind of books. (However, their alternatives are often even messier IMO.)

I don't quite follow your example. Maybe after some sleep I will have more patience with it. I don't use C, especially in a big project setting, so I guess I cannot relate to managing header files. I tend to use relational tables. If I need a Path column or BaseDir column, I simply add a path column. Code that uses other columns usually does not need any changing. (Note that not all relational systems are as bulky as most SQL API's.) I also find it easy to study the table data in a table browser and table structure without writing RAM dumps. The structure and data usually exist outside of the program, so I can inspect, study, grok, and filter it any way and time I want.

(* species_dict = bsddb3.rnopen( "/tmp/db_file" )
No other code in my program had to be changed. This is a lot faster data store than any RDBMS that I've used *)

Well, but dictionaries only have *one* index. That is an arbitrary limit. It is like, "I declare a new collection taxonomy type called the Zork. It has 3 indexes and 13 columns." Listen, everybody likes different things. For me, having every collection able to potentially have full relational capabilities is a good thing. I hate rewriting code just because my collections grow up. I can also sort, view, and filter the data into tables any way I want without writing RAM dumps.

The judges simply think kinda like Guido. My own pet language would be different. Collection "types" are a pet peeve of mine.

(* From my python experience there are only two collection types in python. They are: list and dictionary. *)

I thought it had 3. Anyhow, even 2 is too many. I don't think there should be *any* sharp syntactical boundary between the smallest and largest collection. I see no excuse for such, other than historical habit. Smalltalkers have repeatedly failed to objectively justify it. I doubt Python fans can pull it off also. It will eventually come down to, "you just get used to arbitrary boundaries and then they won't bother you so much. You take the boundary penalty in stride, like New Jersey weather."

(* Python doesn't beat the "how many spaces is one tab" thing. However, errors are as easy to spot as missing semi colons. *)

I am not a semi-colon fan either. However, block-ender syntax and line separator syntax are two different issues anyhow. You are intermixing two independent syntax issues it appears.

(* However python code is made a lot easier to code once you have an editor set up for it( and there are many ). *)

But that is *counter* to the very idea of a scripting language IMO. I *have* had tab problems in other languages because one editor or one computer was set up different than a prior editor. Requiring a strict editor setup is a feature that I would expect from one of those stuffy languages, not a programmer-friendly one.

BTW, another Python fault is not consolidating dictionaries and classes. A class is simply a dictionary of methods and attributes with an inheritance option thrown in. Other scripting languages have successfully consolidated these two concepts. Python blew the opportunity IMO. (Dictionaries are great as interface mechanisms, such as passing and storing dynamic parameters. However, as a data container, they suck IMO because they don't scale in complexity, as already described.)

Thanks for your feedback.

Re:Python complaints

[webmaven]

BTW, another Python fault is not consolidating dictionaries and classes. A class is simply a dictionary of methods and attributes with an inheritance option thrown in. Other scripting languages have successfully consolidated these two concepts. Python blew the opportunity IMO. (Dictionaries are great as interface mechanisms, such as passing and storing dynamic parameters. However, as a data container, they suck IMO because they don't scale in complexity, as already described.)

Python 2.2 now unifies types and classes, allowing you to subclass the built in data types, including dictionaries.

Parrot, Python and Perl 6

[Shiny Metal S.]

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Given that a Google search for "Parrot" on the Python.org shows 570 matches, I don't think so.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

If you had ever clicked one of the links in my post, you'd have known that. There are these basic data types:

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Parrot Magic Cookie type is the whole magic here. Let me quote Simon Cozens' article Parrot: Some Assembly Required , emphasis is mine:

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

And about ``Perl's broken "scalars are scalars" type system''. I won't argue with you, as you obviously have no idea what are you talking about, but other people may be interested in this subject as well, so I'll point out where to find informations on how these things are going to change in Perl 6:

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

For a good introduction to Perl 6 in current shape read Larry Wall's Apocalypses and Damian Conway's Exegeses:

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

For more detailed info, join the mailing lists and read the archives:

• perl6-language at perl.org
• perl6-internals at perl.org

There's more info about in on dev.perl.org - the Perl 6 homepage.

Re:Let me call up some painful memories here...

[Shiny Metal S.]

If you can't figure out the majority of what the programmer is getting at... There's more than one way to RE-do it.

I don't know what painful memories do you have with redoing something (do you know about CPAN?), but if you can't figure out the majority of what the programmer is getting at... There's a sign, that you need more education. Sad but true. This includes much more than only programming.

Re:Bravo for a powerful, easy to learn, easy to us

[MrBlack]

I'm more of a dabbler in python than anything else, but I like it quite a lot. The information hiding thing kinda bothered me when I first heard about it too.....I guess I always wondered why python doesn't allow it? Is it a technical thing? or a philosophical one?