Slashdot Mirror
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 :)
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.
Programming can be fun again. Film at 11.
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.
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.
- 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.
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.
"Well, put a stake in my heart and drag me into sunlight."
(* 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.
Table-ized A.I.