O’Reilly’s conference on Open Source, OSCON, takes place this week in San Jose, California. One of the events taking place at OSCON is the Open Source Language Roundtable, the abstract for which appears below:

We all have our favorite languages in our tool-belt, but is there a ‘best’ overall language? If anyone can hash that out, it will be the members of this roundtable discussion, some of the stars of the open source language space. This wide-ranging session, hosted and moderated by the O’Reilly Media editorial staff, and broadcast live on the web, will try to identify the best and worst features of each language, and which are best for various types of application development.

The roundtable will me moderated by O’Reilly Media’s James Turner and will cover the following languages, listed below with the corresponding panelist:

• Java: Rod Johnson (SpringSource)
• Perl: Jim Brandt (Perl Foundation)
• PHP: Laura Thomason (Mozilla)
• Python: Alex Martelli (Google)
• Ruby: Brian Ford (Engine Yard)

You can catch this roundtable even if you’re not going to be at OSCON because O’Reilly is webcasting the event. It takes place this Wednesday, July 22nd at 10pm EDT (7 pm Pacific) and is expected to run 90 minutes. It costs nothing to catch the webcast and you’ll even be able to ask the panelists questions via chat, but you’ll need to register.

This article also appears in Canadian Developer Connection.

When I got into web development, I considered myself a latecomer to the game, and that was in 1999. In the five years I’d been working professionally as a developer, my apps were strictly desktop – multimedia CD-ROM stuff done in Director (then a product of Macromedia) and business productivity apps written in pre-.NET VB and Java-a-la-JBuilder.

The company with whom I’d landed a contract had a contrarian tech lead. It seemed that the web app world was building their stuff on Linux, Perl and MySQL, and this guy was all about BSD, Python and PostgreSQL. In 1999 terms, he was a freak even amongst the freaks.

I had a pretty full schedule that summer, followed by a one-week vacation at Burning Man, followed by the start of my contract at this new company. The tech lead wanted me to be ready to do some coding on my first day in, so I brought a copy of O’Reilly’s Learning Python along with my laptop to Black Rock Desert, hoping to squeeze in some hacking time at the big desert bacchanal. Luckily, Burning Man is pretty mellow during the day, and in an additional stroke of luck, the neighbouring camp was sharing AC power from their “eggbeater” windmill. I learned Python by writing sample apps in an extremely distracting environment, and because of that, I fell quite in love with the language. Any language that you can learn while naked people playing the tuba on unicycles are circling you has to be a good one.

That’s why I’m glad to see that implementations like IronPython exist, and that they tie into things like the .NET framework and Silverlight. IronPython’s performance is quite close to standard Python, and I use it along with IronRuby as my scripting language for automating tasks and doing little “housekeeping” things on my systems. I’m not using IronPython to the degree that Michael Foord is – he’s using it for full-on .NET applications instead of C# or VB! Scott Hanselman talks with him about working with IronPython as his primary development language in the latest edition of his Hanselminutes podcast.

As an added bonus, the blog entry for the podcast has a special limited-time coupon code that will save you 40% off the price of Manning Publications’ IronPython in Action (which Foord co-wrote), and the discount applies to both the dead-tree and PDF versions of the book. At 40% off, the PDF version is a mere USD$16.50 (CAD$20.14 at the time of this writing).

In an earlier article, Default and Named Parameters in C# 4.0 / Sith Lord in Training, I wrote about how C# 4.0 – that’s the version coming out with the next release of Visual Studio, known as Visual Studio 2010 – is going to provide support for named parameters.

In that article, I also incorrectly stated that Ruby supported named parameters. Luckily, Jörg W Mittag spotted my mistake an corrected me in a comment. I’ve since corrected the article and thought I’d show you how I got it wrong in the first place.

Ruby and My Named Parameter Goof

I had a vague recollection of Ruby accepting named parameters. I figured I’d be empirical and fired up irb – the Ruby REPL shell – and put together a quick little method to see if the recollection was correct:

# Ruby 1.8.6
def test_named_params(first, second)
    puts "#{first}\n#{second}"
end

Once put together, I made some test calls to the method:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params("alpha", "beta")
alpha
beta

=> nil

irb(main):> test_named_params(first = "alpha", second = "beta")
alpha
beta

=> nil

Seeing that the interpreter didn’t choke on that named parameter call, I thought to myself “Vague recollection confirmed, Ruby supports named parameters!” and wrote the blog article.

Had my brain actually been firing on all cylinders, I would’ve given the method a proper test by providing the named parameters out of the order in which they appear in the method signature. Here’s what I would’ve seen:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(second = "alpha", first = "beta")
alpha
beta


=> nil

Uh-oh. If named parameters worked, the first output line would be “beta” and the second would be “alpha”. Clearly something’s wrong with my recollection.

Let’s try some non-existent named parameters – say, ones involving current entertainemtn news headlines — just to see what happens:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(lindsay_lohan_dui = "alpha",
jim_cramer_smackdown = "beta")


alpha

beta

=> nil

Even with nonsensical named parameters, the method is still accepting the values in order. Why is that?

Just about everything in Ruby has a return value (which can be anything, including nil). You can see for yourself in irb – here’s a quick do-nothing method definition:

irb(main)> def doNothing
irb(main)> end
=> nil

As you can see. defining a method returns a value of nil.

As Jorg pointed out, Ruby assignment statements return a value: the value used in the assigment. Once again, for proof, I’ll use an example from an irb session. In the example below, assigning the string "alpha" to the variable first also returns the string "alpha":

# irb session (Ruby 1.8.6)
irb(main):> first = "alpha"=> "alpha"

In the call to test_named_params, the Ruby interpreter was interpreting my “named parameters” as assignment statements. first = "alpha" evaluates to plain old "alpha", but so does second = "alpha" (and for that matter, so does lindsay_lohan_dui = "alpha"). Each assignment statement in my parameter list was evaluated, and then those values were passed to method in positional order.

Python Supports Named Parameters

After getting the comment from Jorg and correcting my article, I wondered why I thought Ruby supported named parameters. Then it hit me – it’s Python.

So I fired up the Python REPL and put together this quick little method:

# Python 3.0
def test_named_params(first, second):
    print("%s\n%s" % (first, second))

And this time, I decided to be a little more thorough in my testing:

# Python 3.0 REPL
>>> test_named_params("alpha", "beta")
alpha
beta

>>> test_named_params(first = "alpha", second = "beta")
alpha
beta

>>> test_named_params(second = "alpha", first = "beta")
beta
alpha

And some additional searching on the web confirmed that yes, Python method calling does in fact support named parameters.

So in conclusion, when it comes to named parameters, it’s Python si, Ruby no…and C# pronto.

While this is actually not about computer security nor about the Python programming language (which I’ll cover in some articles soon), I thought my Pythonista readers might find it amusing…

…for the real story behind this photo, see this article in the Daily Mail.

The Code_Swarm video is an interesting visualization of the evolution of the work done on the Python programming language and the people involved, tracing its evolution from late 1990 to mid-2005.

code_swarm – Python from Michael Ogawa on Vimeo.

The intro for the video says:

In 1991, Guido van Rossum released his Python scripting language to the public.

This video will take you through the history of the project, compressed into a fraction of the time.

You will see the names of developers fade in and out of prominence, while the files they work on swirl around them.

Red files are core code. Blue files are documents. Yellow files are modules. The histogram on the bottom tracks the size and time of commits. When a person makes a commit, their name stands out. The files they commit also stand out. Files grow in size every time they are committed. Files and people gradually fade when there is no activity.

[Thanks to The War on Folly.]

50 Modules for all Needs is an entry at CatsWhoCode.com that lists 50 Python modules, at least some of which should prove useful to you.

I can’t help but wonder if, what with Zed Shaw’s talk of switching to Python and Django, if Guido and Adrian view him the way Barack Obama is portrayed as viewing Jesse Jackson and Al Sharpton in The Obama Files…

This side-by-side comparison of Java and Python shows why I prefer working in languages like Python and Ruby: the “yak shaving” that Java requires drives me crazy.

Tim “Ongoing” Bray’s Take

Tim Bray posted a blog entry on what drives adoption of a language in which he included some tables such as the only below:

	Flawed Founders	Polished Successors
Procedural	FORTRAN, COBOL, PL/1	C
Object-Oriented	C++	Java
Higher-Level	Perl, TCL	Python, Ruby

This table of his should inspire a monkey knife fight on a number of blogs:

	Flawed Founders	Polished Successors
Web-Centric	WebObjects, ColdFusion, ASP.Net, Struts, etc., etc., etc., PHP	Rails

Here’s an interesting one. What will JavaScript’s successor be? My guess for the short-term (by that, I mean “the next half-dozen or so years”) is “the next version of JavaScript”.

	Flawed Founders	Polished Successors
Mobile-Code	JavaScript	?

The one about concurrent programming is a little more up in the air. Although there are other languages designed with concurrent programming in mind (either from the ground up or with concurrency retrofitted onto an existing language) and there have been for a while (I used Concurrent C in a course back at Crazy Go Nuts University in the early ’90s), Erlang is getting a lot of the attention these days since it has both a success story at Ericsson under its belt as well the clout of a Pragmatic Programmers book behind it. There is a feeling among some programmers (Bray included) that it isn’t going to be the language to turn concurrent programming from arcane art into mainstream practice:

	Flawed Founders	Polished Successors
Concurrent	Erlang	?

Shelley “BurningBird” Powers’ Take

Shelley Powers disagreed with Tim’s assessments in her posts Flaws are in the Eye of the Beholder:

I find it fascinating when a person marks as ‘flawed’ the languages that have, literally, defined not only the web but application development of all forms. Perhaps the metric shouldn’t be on syntax, form, or function, but on usability.

Here’s her own table on languages:

	'Perfect', but barely used	'Flawed', but simple, approachable, powerful, popular
Higher-Level	*Ruby (every time I see 'Ruby' I mentally add, Mama's precious little…) *I’m giving Python a slide because Python has fairly widespread use today.	Perl
Client side code	(The to-be-created scripting language that will take a nice, clean, easy to use language and morph it until it satisfies the purists, while breaking faith with the millions of users just trying to do a job)	JavaScript
Object Oriented	Java (bloated beyond recognition with senseless additions and overly complex infrastructures)	C++ (which can kick Java's ass performance and resource wise)
Web-Centric	Rails (you know that thing they used for the one application?)	Cold Fusion, ASP and ASP.NET, PHP

Those of you who recall Bjarne “C++” Stroustrup’s line “There are just two kinds of languages: the ones everybody complains about and the ones nobody uses” or the essay Worse is Better (or the essay that led to it or Jamie Zawinski’s commentary on it) should be feeling deja vu now.

As for Shelley’s table, I’d probably have put “PHP” where “Perl” is right now.

My Own Take

I think that right now, the “scripting languages” are stuck in something akin to “Three Stooges Syndrome”. That’s the disease where Mr. Burns from The Simpsons, being so old and frail, has so many diseases trying to get at him at the same time that they’re all “stuck in the door”. The doctors illustrated the syndrome with a model, shown below:

And since Tim and Shelley have their tables, I thought I’d make one too:

It’s been a long-time topic of discussion in the Python camp: Python 3.0, also known colloquially in the Python community as “Python 3000″ or “Py3k”, and today it got a little more real. The first alpha release of Python 3000 is now available for download, just in time for those of you who want to test-pilot it over the Labor day weekend.

(If you’re waiting to get a final version before downloading, you’ve got a fair bit of time. The current best estimate for the release date of that version is August 2008.)

Unlike Perl 6, which is a radical reworking of the language, where every feature is subject to change, the idea behind Python 3000 was correct a specific set of design mistakes. These corrections are large enough that they will break programs written in existing versions of Python, but which provide gains that are enough to make the trade-offs worthwhile.

If you’re curious about Python 3000, here are some links you might want to check out:

• The announcement in Guido van Rossum’s blog
• What’s New in Python 3000. This is a work in progress, so many sections of this document aren’t filled in yet.
• Guido’s Python 3000 presentation rehearsal [video, 1 hour, 7 minutes]. This is a Google video of Guido giving his Python 3000 presentation for OSCON a test run in front of his co-workers at Google.
• Python 3000’s Wikipedia entry.
• Source tarball for Mac OS X and Linux users. I just finished the “configure/make/make install” dance and Python 3000 is now working on my G4 PowerBook running Tiger without a hitch.
• MSI installer for Windows users.