Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

FSF Awards Guido van Rossum For Python 135

Posted by timothy from the congratulations dept.
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 :)
This discussion has been archived. No new comments can be posted.

FSF Awards Guido van Rossum For Python More

FSF Awards Guido van Rossum For Python

Comments Filter:

  • Python (Score:4, Funny)

    by MarkusQ ( 450076 ) on Saturday February 16, 2002 @05:44PM (#3019500) Journal

    *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 (Score:3, Interesting)

    by __past__ ( 542467 ) on Saturday February 16, 2002 @05:50PM (#3019539)
    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 [sourceforge.net] (Python Enhancement Proposals), a very open and community-oriented way to deal with language evolution.

    • Re:Great (Score:2, Insightful)

      by djmitche ( 536135 )

      Guido's management of this enormous, popular project stands in some contrast to Linus' management of Linux, as discussed here on slashdot [slashdot.org] 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.

    • It is good that GNU/RMS have been acting rather reasonably lately. RMS said recently that the GNU project was missing a kernel for a long time, but now it has one: Linux. A bit different from what some people might expect, and I would say that's a good thing.
      • When did RMS say that? I thought he was still trying to say Hurd is the GNU kernel :-) Maybe in another 10 years it will be mature....
    • Recently, due to changes in the Python license, RMS Himself Certified that the Python license is now fully GPL Compatible, thus putting an end to this digression. Python has ALWAYS been open source and free software, now no one can ever again use this canard against this beautiful piece of work that is an ongoing arttistic and technological evolutionary miracle ;-))) Learn Python at Python City [awaretek.com]

  • Previous awards (Score:5, Informative)

    by arnoroefs2000 ( 122990 ) on Saturday February 16, 2002 @05:52PM (#3019548) Homepage
    In 1998, Larry Wall for his work on Perl [perl.org] 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 [gnome.org]

    "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 [mesa3d.org]

    "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 (Score:3, Funny)

    by Anonymous Coward on Saturday February 16, 2002 @05:54PM (#3019564)
    Unfortunately, Guido cannot trim this award to fit into the picture frame.

    Because white space matters on this award.

  • And that in turn... (Score:2, Interesting)

    by 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.
    • > They should ditch tk as default windowing/widget
      > environment though and switch to wx but other
      > than that I love it.

      Unfortunately wx uses a *lot* of ram just to load.. other than that it is very nice though.
    • 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

      ;)

  • simpsons reference (Score:1, Funny)

    by RN ( 21554 )
    Guido van Rossum Awarded the Free Software Foundation Award for the Advancement of Free Software

    when i first read this, it sounded too much like in the simpsons episode where homer won some bullshit award from Mr. Burns,

    You've won the uh..first annual ..uh..Montgomery Burns award..uh.. for the outstanding achievement in the field of ..uhh .uhh. EXCELLENCE!

  • This award goes to all the Python community. (Score:5, Funny)

    by sinserve ( 455889 ) on Saturday February 16, 2002 @06:23PM (#3019660)
    You know, Guido is the root object, and we all have
    the Award attirbute, inherited from out based class.

  • ... and related technologies. Just out of curiosity, is anyone working on a Display PDF emulator? That's one of the technologies that I've found interesting that Apple embraced in OS X.

    I haven't decided if Display PDF is a good idea or not, but it would be interested to play around with it without having to spring for a Mac*.

    *I've sworn a sacred oath never to give Apple any of my money until they change their ways (closed systems, stupid lawsuits over "look and feel", high prices, etc).

    • Re:Speaking of Ghostscript (Score:2, Informative)

      by Anonymous Coward
      DGS [gnustep.org]

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

        • Postscript and Display postscript were developed first, but describing them as "an older technology" has an implication of it being a less advanced system, where really it is still the more advanced one.

          According to The PDF Reference [adobe.com], (labeled page 21 in the document, but the 41 page to the PDF renderer) "To simplifiy the processing of content streams, PDF does not include common programming language features such as procedures, variables, and control constructs." The imaging model of Postscript, Display Postscript, and PDF are the same, but PDF's limited set of operators don't return values. Instead of procedures, PDF has parameterized streams (similar to macros)

          On the plus side, the rigidly defined file format allows PDF renderers to jump to any section of the document without rendering previous ones, and allows documents to be statically checked for validity. (Postscript documents need to be executed before you can actually know whether they are valid or not.)

          Ghostscript does have PDF encoding and decoding capabilities, making use of the strong similarities between the two systems.

    • Why don't lottery players ever pick "1, 2, 3, 4, 5, 6"?

      Actually, they do. I read a newspaper article saying that it was by far the most popular sequence in my local lottery, with something like 10,000 tickets every lottery.

      What's ironic is that all these people picking "1,2,3,4,5,6" think they're so witty, since they know that it has the same probability of coming up as any other sequence. But in fact, it's the worst possible choice: if it did come up, the jackpot would be split among 10,000 people!

    • Yes, there would be:



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


    • I haven't decided if Display PDF is a good idea or not

      Just like Display PostScript, I think it would be a really great idea so long as the interpreter ran on its own CPU, possibly with it's own RAM. Every generation of CPU seems to basically double its speed, and require tripling the component count to accomplish that, and the ratio is gradually getting worse as the easy fixes have already been done. This makes coprocessers a really good way to get performance more cheaply, just so long as they're used steadily. Graphics code, I think, is just begging for it.

  • Yes, but... (Score:2, Insightful)

    by code65536 ( 302481 )
    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... (Score:4, Insightful)

      by Zagadka ( 6641 ) <zagadka AT xenomachina DOT com> on Saturday February 16, 2002 @07:14PM (#3019816) Homepage
      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... (Score:3, Insightful)

        by Shiny Metal S. ( 544229 )
        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 [parrotcode.org], i.e. the virtual machine for Perl 6 [perl.org] and, I hope, also for Python [python.org], Ruby [ruby-lang.org], Tcl [tcl-tk.net] 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 [parrotcode.org] of Parrot use and read Parrot: Some Assembly Required [perl.com] to see what it is. Also the perl6-internals at perl.org [develooper.com] 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... (Score:3, Insightful)

          by Trepidity ( 597 )
          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... (Score:5, Informative)

            by Shiny Metal S. ( 544229 ) on Saturday February 16, 2002 @11:36PM (#3020571) Homepage
            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 [slashdot.org] 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 [slashdot.org] 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 [worldforge.org] 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. :)

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

              • 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 [slashdot.org]: "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.

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

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

              • 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 [oreilly.com] 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.

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

                  • 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 [slashdot.org], through the whole thread [slashdot.org]. Please read the disclaimer at the end of this post [slashdot.org].
                    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.

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

                    • 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 [slashdot.org] and everything I was talking about. The whole long thread [slashdot.org] 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 [cpan.org] and search [cpan.org] for such distributions as CGI.pm [cpan.org], DBI [cpan.org], DBD* [cpan.org], and the core Perl modules [cpan.org], and read them, to see lots of extremely well written Perl code. It's really worth reading.

            • I believe that programming languages are much like human languages in that some are better able to explain ideas more than others are. Like Inuit (Eskimo) languages have 10-15 words for snow, some computer languages are better able to express some ideas than others.

              The flip side to this is that people's brains work better with different languages. Having learned/studied French, German, Spanish, Chinese, Japanese, Finnish and English - my brain works better with some languages than others. Similarly I believe there are those people whose brains work better with Perl than Python.

              But I find python syntax "fits in my brain" better than perl. For others who find dynamically typed languages difficult to fit their heads around perhaps neither (Java?) is better. I find a good naming convention more important than using strict typing. Standardized ways for calling classes, etc nicer. Fewer built in mystery variables ($@#...), Less clutter important as well as not forcing OOP (Java).

              Python is fairly flexible in coding styles (functional, OOP, Xtreme Programming etc), has a nice class library, is fairly easy to extend, and is not controlled by a corporate entity(Sun/Microsoft). Most importantly, discovering it got me excited about programming again.
        • My impression is that Parrot is going to be a VM for Perl only, thanks to somewhat less than wild enthusiasm from the Python contributors, plus the decline of TCL, the fragmented LISP world etc. But I would like to be wrong! any pointers to recent progress in this area?

          <digression>

          Although, having said that, I rather wish that Parrot was more than just another bytecode machine. It would have been nice to have embodied some programs as data capabilities, that general advance is surely long overdue. (Turing put modifiable code in the ACE design in, er, 1945, and LISP did it quite neatly back in 1960).

          Algol seems to cast a long shadow, don't you think?

          </digression>
        • 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.
          • 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 [cpan.org]?), 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.
    • 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()
      }

    • 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... (Score:3, Informative)

        by costas ( 38724 )
        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... (Score:3, Interesting)

      by Kirruth ( 544020 )

      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.

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

  • for some perspective on lightweight languages (Score:4, Interesting)

    by markj02 ( 544487 ) on Saturday February 16, 2002 @06:49PM (#3019731)
    I recommend reading this article on DDJ [ddj.com] 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.

  • Bravo for a powerful, easy to learn, easy to use L (Score:2, Informative)

    by 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
    • 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.
      • "Fallacies"?!?

        pray, do explain!
        • Python, while a good language, does not encompass everything. Python on an embedded device is not a great choice. Python also cannot be compiled into a native binary, nor does it have decent alternate language bindings and requires wrappers.

          Any programmer who thinks one language can do anything, and is the best, is quite frankly an idiot and shouldn't code.

  • congrats, Guido (Score:1, Interesting)

    by Anonymous Coward
    Although I've never programmed in Python, I've read the O'Reilly book and really respect what you've done to advance computer languages.

    You got a lot of balls forcing people to indent their code in a standard way!
  • 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.

  • Python is nice. Python is useful. But it's still just a scripting language. It saddens me that Dylan, which is better in several important ways, has not gained acceptance. Dylan has a real macro facility, is compilable to efficient code (see http://cristal.inria.fr/ICFP2001/prog-contest/), has real garbage collection, multiple inheritance, etc.

    "Dylan--which I think has a very academic flavor--is everything Python is plus so much more" -Guido van Rossum, 1999
    • Tomato vs. Tomato. Whilst I can understand the preference of all of these languages I would argue that since 2.x Python has really shone. However there are such an abundance of good scripting languages out there (Ruby, Perl, Python, Scheme etc.) that praise the difference. They all serve to further the widespread acceptance of free languages. Yesterday Perl, Today PHP, Tommorow Python, next Dylan? Your mentioning it has certainly made me want to look at it. Especially if it has serious Academic review.

      Unfortunately the link doesn't work at the moment, so I'll try tommorow.

    • Dylan is nice, but Python is a general purpose lan (Score:1, Informative)

      by Anonymous Coward
      Python is perfect for large programs, because it is object oriented, modular, easy to read, especially easy to maintain, and powerful. Zope is written entirely in Python. The Google search engine is written in Python. Python is used by Dreamworks, NASA, Disney, Industrial Light and Magic, Lawrence Livermore Labs, IBM, and Yahoo.
      Python is used extensively in the most complex scientific computing applications, including nuclear accelerators and leading biological research labs. Dylan is a fine language; but the statement you made that Python is only a scripting language is 100% wrong. Python is so easy to learn and use that it is popular; but that doesn't mean it isn't powerful and suited to the biggest of programming jobs!

      Your post illustrates a common mis-perception that needs to be corrected. You seem to equate "difficult and complex" with powerful; this is not always true. Sometimes, the apparently simple and easy tool is also the most powerful; and that is precisely Guido's genius and the crowning glory of his creation; Python is the easiest programming tool ever created, so much so that one can learn to program in Python in one day, but is also one of the most powerful programming tools on earth, enabling the creation of the world's greatest search engine, Google, and one of its most complex object oriented web servers, Zope.
      In creating Python, Guido has advanced the state of the art in programming languages.

      Ron Stephens
      Python City Python City [awaretek.com]

      • Python complaints (Score:1, Interesting)

        by Tablizer ( 95088 )
        (* Python is perfect for large programs, because it is object oriented *)

        How *exactly* does OO help large programs? I keep hearing this cliche, but it is never demonstrated, besides comparing it to bad procedural design. The 1st Orielly Python book gave a lame, rigged menu example to justify OO.

        Although I much prefer Python over Java, there are some annoying things about it IMO. First of all, it has too many collection "types". These should be rolled into one protocol so that one can scale clear up to RDBMS's without changing access syntax. (Perhaps the engine will be switched, but the access syntax should not have to be.) OOer's don't "get" scaling collection protocols IMO, stuck in the artificial make-a-taxonomy-of-collections-because-
        Smalltalk-did-that mindset.

        Further, it is too easy to mix up tabs and spaces in scripts. Scripting should *not* assume a controlled editor environment. When you can mix up tabs and spaces, then WYSIWYG indentation goes out the door. The compiler cannot know how tabs *appear* to you. Think about it.

        • Re:Python complaints (Score:1, Interesting)

          by Anonymous Coward
          I wrote "Python is perfect for large programs, because it is object oriented, modular, easy to read, especially easy to maintain, and powerful."

          From which you quoted only the first part
          (* Python is perfect for large programs, because it is object oriented *) and attacked it.

          Well, it is the combination of qualties and characteristics that make a programming langauge good at large programs, not just any one part. I actually agree with you 100% that merely being object oriented does not guarantee that a language will be good at large projects. In fact, extreme purity that puts all emphasis on object orientation or any other one kind of programming leads to very poor languages, in my opinion.

          Indeed, one can program in Python in a purely procedural way, or even a functional way, without ever even using classes or object orientation at all! Newcomers to programming often start out this way in Python and do just fine, creating wonderfully useful programs without classes or any notion of object orientation entering their brains, until they are ready for it. This helps to make Python a perfect first language for new programmers, and yet Python eventually leads them to a clear understanding of even the most advanced programming concepts, in a painless, enjoyable, and useful process.

          Python is very practical, pragmatic, and takes a middle course. This middle way, the Python way, just happens to be a great way to program. And Guido's leadership of the development process is a shining example of open source development that really works well. Python is continuing to evolve into a better and better language all the time.

          The evolution of the Python langauge is a great Work of Art in and of itself.

          learn Python [awaretek.com]
    • You have to be kidding. Python is certainly not 'just a scripting language', I personally have written some rather major software using it, and find it a fantastic tool.

      It finally answered the question that had been sitting in the back of my mind WRT C++, ie: 'this is good, but not quite what I want, it's overkill, but what is wrong?'. Python makes complex tasks my simpler, and does not try and make simple tasks appear complex.

      The lack of a true compiler (and also good linking system) is an issue, but not, IMHO, a major one, there are options available (pyco, py2exe, JPython, etc) that partially address this, but more often it is not a real issue.

      Python has probably doubled my efficiency as a developer, which is no small feat. C++ was probably the last tool to come close to that, and the startup time on c++ was around 6 months, python was closer to 2 weeks!
    • Just a quick link to all those interested in Dylan (to save you the Sourceforge link):
      Here [gwydiondylan.org]

      Interesting to note the paragraph under the heading 'The Downside of Dylan'.

  • Python Topic! (Score:1, Interesting)

    by Anonymous Coward

    I realize slashdot is perl-centric, but this is getting ridiculous!

    It's time for a python topic!

    I realize a topic for every language out there is impractical, but there have been a TON of python related postings!
  • - A clean, SIMPLE, powerfull core language
    - Data types that make life easy (lists/dictionaries)
    - A FANTASTIC set of cross-platform libraries
    - A GREAT standard and simple GUI library (Tk)
    - A GREAT powerful GUI library (WX)

    Things I would love about python :)
    - A compiler (very hard, but I can dream)
    - Smaller/more tunable installs
    - wxWindows built in

    Python is the 'simple c++' I was always looking for and have now found ;), 90% of the functionality with 1% of the complexity, and great cross-platform support to boot!

    As a developer, I just love it. Python reduces my development time significantly, and also allows me to express algorithms in a logic way, without fighting the language. This is a VERY important feature. It lowers development stress, so I can spend more time working and less time reading language manuals.
    • Things I would love about python :)

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

      Keep an eye on the weave project here [scipy.org]. 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.

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

  • The Numerical extensions to Python make it a fabulous language for engineers and researchers trying to get stuff done in a hurry. The language itself is easy to learn and use for real work.

    Similarly, their is tremendous power and ease of use in the other modules that come with the language.
  • I tip my hat to Guido, and take a toast and a SWIG of red, Ruby Wine.

  • Was always the ministry of silly walks.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close