uh-oh. i'm going to blog about languages again. ring the bells of warning. i fully expect to get all sorts of fun email and blog comments from the language gallery, but please keep in mind while reading this entry: i personally don't like python all that much, which is to say it isn't the language itself that causes me to write this.
ok, enough "hoping to deflect the flames" preamble ... i was sitting in an airport with zack, chris blizzard, david from pgsql and keith packard chatting about stuff. the topic of languages came up, in particular python. i suggested that we really need a visual basic for our platform. but not visual basic. even microsoft seems to understand that it's a dead end language, and we really can do better than vb.
but it's pretty undeniable that we need a language for the people who aren't code ninjas that is safe to use and fast to develop in. it should be open source, easy to learn and have lots of hooks into useful functionality like xml handling, networking and graphical toolkits. of course, we have several of these in the open source world. but none are hailed as "the vb for the open source desktop" because ... well ... we can't get our ducks in a row.
personally, i'd love to see ruby get the nod because i really like that language. but python is already used far and wide, has a smaller learning curve (at least imho) and has all sorts of vb-like qualities.
if python were to be christened the quick-n-dirty app devel language of choice for the open source desktop, several things would likely have to happen. like the string handling in python would need to get unfuckified. due to having two internal string representations, one unicode safe and one not, all sorts of fun can happen when running python apps in various locales. i was unaware of this problem until i sat in on a discussion and listened while some people described the problem is great detail to a python fan at linuxconf.au in january. python's gc also needs a revisit.
guido would probably also need to show his ability to do the graceful hand-off of his baby to the community. not that he needs to step away from it, but apparently there is a feeling in the community that guido is a blocker to python's future success. this isn't my opinion (i am completely uninvolved in the python community) but it is a common comment i get from people. (please don't shoot the messenger *whimper*) if this isn't an accurate observation, then the python community needs to find a way to fix that perception in the broader open source community. how? i don't know, because i really don't know where the sentiment is coming from (i just know it exists).
then we'd need to circle the wagons and get most people on the same page: kde, gnome, ubuntu, mandriva, red hat, novell, etc ... so we can tell the world that if you want something to fill the gnawing void of vb for the open source desktop, it's right there. only through consistent messaging and proper support across the board will the newcomer crowd grok the talk. the good news is that most of these groups are already python supporters in some way, so it shouldn't be a stretch.
we also need to look at what we offer for support. richard dale's korundum for ruby shows the way, imho. from the kde perspective, while we have pyqt and it seems to work rather well indeed i think we could do better. well, that's probably stating the obvious (i'm good at that ;) because anyone can always do better ;) but if python gets the nod, then that needs to become the mantra for the python tools we offer.
ok, so ... why not java? too complicated, too 1990s. why not ruby? not enough mind share, a bit too complex to throw vb'ers at i think (though what a beautiful language it is! =) why not c#? while in brazil, i got to see one of the landmark c# apps that comes out of novell itself crashing spectacularly. yep: crashing, complete with backtrace into c code. according to miguel "the mono man" himself this was because the c# app was passing a null into a method that ended up calling a c library function which doesn't do nulls and that the crash was intentional. apparently they used to throw exceptions, but this "hid bugs in application code" and so they instead now just let things crash. uuuuuh. why use a new-gen language if you get to deal with the same friggin' problems we've struggled with for decades, like memory management? while the clr concept is a great idea (i'd love to see a really solid clr widely available and used in the open source community), my faith in c# is pretty much zero at this point, and that's without even going into the non-technical issues with the language.
of course, these languages must not be abandoned or relegated to being red headed step children if python gets elected to fill this one role. these languages all fulfill important places in our ecosystem and have thriving communities around them. that's valuable.
so ... is it possible to get a well advertised and supported vb alternative? i don't know. this may be yet another fantastic though on my part that we as a community just aren't ready to implement in a meaningful way. maybe we are. i hope to keep another opportunity to chat with chris, and others, about this as the year unfolds. who knows where the wind will blow ....
and now back to our regularly scheduled m