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.

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.

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.

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.

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...

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: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...

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

;)

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...

[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...

[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.

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.