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
Subscribe to:
Post Comments (Atom)
22 comments:
Hi Aaron
Your blog is always a good read :-)
There is already something over at kde-apps that is sort of like what you're asking for. But it requires kde which is bad if it's supposed to be a global-linux-thing.
I see you have quite dug into the vm powering the languages as well. I think we should leave that out of the picture. If a language gets such a use, it will improve too. I doubt the C-backtraces is called a feature among the mono-devs.
So I think one should just evaluete the language itself. And I don't think C#, while a nice language, is suitable for what you're asking for here.
I've used python a lot last year and I really got to like a lot about it, but I'm not sure whether it fits this use-case. But who knows ^^
I have been impressed by a language called Groovy ( http://groovy.codehaus.org ) in the past; I would think it fits the bill excellently. Its really really short and can be written by people who have zero knowledge of OO up to people used to functional programming.
All we have to do is wait for QtJava and link them up...
Oh, and its got the coolest name, don't you think so? :-)
Hi. Do you know Gambas? (Gambas Almost Basic): http://gambas.sf.net.
It's pretty madure and has native support for both QT and GTK, without code modification. It also has a nice graphical IDE, written in gambas/qt itself.
Regarding your question about how to "announce" that Python is the VB of the open source world: that will take care of itself once it becomes possible to write Python macros for Koffice. Sebastian Sauer has been making great progress in this area with Kross.
Most of the people I know who code in VB (scientists, doctors, accountants, personal secretaries, etc) do so because they have to automate spreadsheets and to generate graphs from those spreadsheets. Some also have to do custom formatting of Word documents, but that's rarer.
So I think making it possible to write Python macros in Koffice will immediately make it appealing to the masses.
While I prefer Ruby and Richard's excellent Kordundum bindings, it seems that the Python developer community is more focused on desktop oriented tasks, while the Ruby developer community seems to want to make Java's life harder on the server side.
*sigh* seems I will have to do a Python KDE-bindings example as well.
I am a VB user, but I don't like it. There's one basic reason: cross-platform/cross-compiling. The only real solution that I've found is REALBasic, and that is crap. I applaud that they made the Personal version for Linux free, but it can't compile for other platforms. In addition, the frequent crashes are borderline unbearable.
I've researched other languages, and Python does look attractive. But I don't see very many easy-to-use tools for it. I'm looking for an IDE similar to the VB IDE, where you can place controls and then merely double-click them to write code. I haven't yet found anything adequate, although it doesn't seem like a great stretch for someone to create.
I've checked out Gambas, but it looks like it doesn't create executables/binaries. I'm not sure if the latest version also has this fault, but this is a biggie.
Anyway, I wait and hope. Hopefully, some people smarter than I will get their act together, and I will be all set.
You should check out Pugs (Perl6) and Parrot.
Parrot promises to bring Python, Perl, Ruby, Java, etc all under one VM, at which point they can share components and objects. It's got a lot of promise, and it makes the job of compiler authors far easier.
What if someone literally implemented Basic on Parrot?
A few notes on what seems like a controversial suggestion, at least for a number of KDE developers...
On Python's string handling: I don't think anyone will deny that Unicode support arrived after the fact and that people struggle with it from time to time; perhaps the suggestion that the string type be renamed as "bytes" and that the unicode type also be known as "string" makes sense. That said, people are going to want both kinds of string - something representing bytes (cf. Java's byte) and something representing characters (cf. Java's char/String) - and it should be noted that those who are aware that characters and bytes are not generally the same thing have fewer problems than people who think that "Unicode is just UTF-8, right? So why is Python complaining?" I suppose sorting and locale interaction could do with some work, if you listen to what the OSAF people have to say.
On Python's GC: If I remember correctly, the only major issue remaining from the laundry list of things people didn't like was the collector's poor behaviour in cases where memory usage peaks severely. Or were there other things you were thinking of?
On Python's stewardship: I wouldn't want to comment publicly on this, but you can count me as a conservative with regard to which recent features I see as superfluous and which things I'd rather see improved. Python's libraries need work, though, which brings me to...
PyQt, PyKDE (and the "other" desktop environment): I'd agree that these libraries don't get very much "celebrity exposure" either within KDE or GNOME, or within the Python scene, yet a lot of work gets done using these technologies. Perhaps KDE adherents should cross over into the Python scene occasionally to educate people about what Qt and KDE can offer... and vice versa, of course.
Oh, how I wish it could be Ruby. It's just so elegant! And Python can't be that much easier to learn, can it? (Not that I have had any closer encounters with Python.)
You seem to have left out good integrated tools, which I don't think python has to the same degree as VB. Every VB programmer I have ever talked to considers the IDE to be its advantage and not really anything else.
As a friendly reminder, mono is about more then C#, including python.
So easy to learn (even for non-programmers, like biologists or linguists, Isaw that...), so powerful, with VM and a full tools library: Smalltalk.
Maybe, interaction with other applications (bindings) is missing, but I'm not sure about that.
See Squeak Smalltalk or GNU Smalltalk.
IDEs and other tools: that's why i mentioned korundum when talking about what we provide in the form of support tools.
smalltalk/perl/ruby/$MY_FAVE_LANG/etc: they all lack the current uniform adoption and support that python has. this isn't about picking a good language, it's about picking a language everyone can get behind. kde (and whomever else) can (and should!) continue to support other languages, but boy what help it would be if there was an agreed upon "base level" language
as for biologists and linguists ... i'm thinking about people with slightly less applied brain matter =)
c# vs mono: that's why i mentioned the clr as well =)
parrot: we're talking apples, parrot is an orange =)
koffice and python: yes, i'm quite eagerly looking at kross. however this is about more than kde. it's about the entire open source desktop *cringe* ecosystem *uncringe*. =)
> But it requires kde which is bad
> if it's supposed to be a
> global-linux-thing.
it's a good start though. =)
> And I don't think C#, while a
> nice language, is suitable for
> what you're asking for here.
agreed. but before being able to consider it as a candidate on technical merit, we'd need a good implementation. i'm not sure the mono project offers that really quite yet.
Hmmmmm. Having used Python for many years in the Zope world, while it's good for many things, it's not a VB replacement. Its syntax is not clean enough for one thing, along with others, and does not lend itself to being a VB equivalent at all. Ruby, although not perfect, is probably a better fit. The key for a VB replacement is having simple English-like syntax, which strikes languages like C# and Java out.
The mindshare issue with Ruby is a non-issue really. You pick the best langauge for the job and build mindshare for it as a result.
However, the language issue is actually a small one. You're talking about taking a suitable language and it's runtime environment and integrating it with the desktop, applications and existing development technology so that everything is programmable, scriptable and accessable through it - in a sensible way. That's a big, big, big ask and an unimaginable amount of work. Somebody like Trolltech would need to be involved. You could actually just take VB and mould it so that it becomes more sensible from a free desktop point of view.
Your example of C#, and more importantly the CLR concept (C# is just a language in this world ;-)) highlights why I think it's a flawed concept, certainly in the open source world. Yep, people highlight the advantages of managed code, but all that managed code does in just about every case is wrap lower level code written with C or C++. The .Net framework on Windows is just a large OO wrapper around Win32. When this code produces strange results (which it will do) the framework still needs to handle that gracefully. You can't just P/Invoke into anything you like because you just run into all the same problems, and probably worse depending on what the CLR craps back at you (it may give you bugger all or totally mislead you), which completely wipes out any programming advantages you might get. It's just about manageable on Windows because Microsoft put huge amounts of resources into making sure that the .Net framework, and the CLR, that wraps native Win32 code functions in a way that isn't disastrous for programmers (and they haven't done it too well so far). Are the Mono people going to do the same for every bit of code that you might invoke into on a Linux desktop environment? If not then the CLR and Mono is a fairly useless concept, unless everything gets written in managed code that will work - and of course, in the open source world things will not be written exclusively for managed code at all. James Gosling was right about P/Invoking in many ways. Wrapping code can only make things a finite amount better better to work with.
There is another problem with the CLR (Common Language Runtime) concept. The reason why we have different languages is that they are different in relevant ways so they can do a different job. The problem with the CLR is that all languages written for it need to follow the same rules. The net effect, ultimately, is that all languages written for the CLR differ only in their syntax. You can see this now as languages like Boo and Nemerle have evolved, but iterative versions of C# are easily acquiring the features that these languages seem to have. Are Boo and Nemerle really different languages, or are their features really only syntactic sugar that any CLR language like C# can adopt? If so, they're not different langauges.
The result of this is that there are only two main languages in the .Net world now, despite early optimism about many languages like Perl and Python plugging into it. Those two languages are C#, of course, and VB.Net. Even then, there have been endless debates in Windows developer circles for some time about just what the point of VB.Net actually is. It's not a RAD language like VB was, it takes on all the complexity of the OO .Net framework, it differs from C# only in syntax and differs in some ways just for the sake of being different. In short, the base language the CLR is designed for is C#.
In the Windows world .Net and the CLR are of borderline benefit at best, and in the open source world Mono and the CLR are, quite frankly, close to useless. There are of course other non-technical reasons, but it would be wise to learn from those mistakes.
A few Python points:
-The unicode issue will disappear with Python 3000, which is slated to be pure unicode. See Guido's slides on his blog:
http://www.artima.com/weblogs/viewpost.jsp?thread=157004
This change hasn't been made yet because it's a backwards compatibility breaker.
-I don't really see any evidence that Guido is holding back the language. He is still pretty aggressive about adding features and adding new standard libs. Python 2.5 is going to add partial function evaluation, the ternary operator, and "context handlers" which if you haven't read about are actually pretty neat. And frankly, design by benevolent dictator beats design by committee everytime.
-I don't really see at all what people think is so seductive about Ruby compared to Python. It is a very equivalent language. There is no feature to draw you away from Python. The only possible reason is if Python's whitespace requirements really annoy you that much. And Python's requireements are a lot looser than most people make them out to be (indent blocks. Yeah, that's it. You can break strings and assignments and function calls across multiple lines and it doesn't care).
-Python is way more mature than anything else out there for this. First, it has 3 promissing implementations -- the main interpereter, CPython, the java based interpreter, Jython, and the .NET based interpreter, IronPython. This means you can conveniently blend Python code with either C, Java, or .NET. The new ctypes module in 2.5 will let you call C code directly without writing a single line of C.
-Python has a next generation interpreter/compiler/JIT called PyPy. It is a common sign of a language's maturity when you can implement a compiler for the language in itself. No other potential VB replacement even comes close to having something as complete (there is work on a Ruby interpreter written in Ruby but it is far behind). PyPy can already bootstrap and compile itself, and it's catching up speedwise with CPython without any of the optimization work done.
-In response to segedunum: I bow to your greater experience in that you've been using Zope w/ Python probably longer than I. But I don't understand why you seem to imply that Python doesn't have a nice english-like syntax. I think Python has made some awesome syntax choices compared to other languages -- making 'is' be for identity and '==' be for comparison, all the uses of the keyword 'in', reusing 'if' for the ternary operator instead of blindly copying C, making function names determine whether they're public/protected/private... the list goes on.
I concur about Mono. I would like to like it except that every Mono app I have used is unstable. Beagle and Banshee have never been stable for me. It's wrong to fault C# itself, but when the only implementation you can use is buggy, the language might as well be.
Also, Python is coming along in the IDE department. The eclipse plugin: http://pydev.sourceforge.net is growing in maturity. Although you are right that there is still the need for a good GUI design tool (listening Trolltech?).
A feature that is dear to non-ninjas and starting Python programmers is the interpreter -- being able to type code in and see what it does without a compile step. I am always reluctant to test how something works in C++ because it takes so damn long to setup a proper test and compile it. Any VB'ish replacement would benefit from having this.
</$.02>
There is an excellent GUI designer for Python: Qt Designer. Works perfectly :-). And the Eric3 IDE is an excellent development enviroment. Nowadays I wouldn't spend time on Blackadder, though. Wing IDE is quite good, too.
Where is this community claiming that Guido is "blocking" Python development??? What I see is intelligent *guiding* of the development so it doesn't become the horror that is Perl (or Ruby).
Richard,
I guess some people get really frustrated when their favourite feature-du-jour is rejected for the purpose of keeping the language (fairly) consistent.
Some of us think that there are too many new features added to the language in each new version of CPython, so upsetting aspiring language architects like these is the very least he can do to restore some kind of balance.
Hopefully, Python 3000 will become the battleground for all those "cool" new features that some people can't seem to live without.
Two objections:
1) Today's Linux distros, and BSD's have automatic installation of dependencies so installing a new language is not a problem. Besides if the language we are talking about will be the VB of free OS's it would be installed with the base system anyway.
2) Python is not the ideal beginner's language. Maybe it was back in the 90's when it was simpler and constrasted with Perl but I don't think it's in the same league with VB today. I find Ruby very easy to learn but I wouldn't suggest Ruby as well...
IMO an easy to learn and program language is still a Basic or a (Object) Pascal. It's no surprise that two beginner friendly major programming environments for Windows world is Delphi and VB. Python and Ruby and others are in a different league both with their programing environments and cultures. If you really want to have a VB equivalent, I'd suggest improving the KDE and Qt integration with something like Lazarus...
It's a real shame that it seems we even have to make a choice like this, but it's actualy a decisions I've had to make already. I want to be able to write simple cross-platform scripts in a simple language with rich library support. Frankly Python was the only choice because, even though I already knew Perl pretty well, it's an ugly and awkward language for anything other than short text procesing scripts.
Since learning Python I've written text processing scripts, simple wxWindows GUI tools, even a Windows operating system service and a program that called Excel using COM. How many other languages offer that much flexibility and convenience?
As for Python being harder to learn than basic - Phooey. I recently wrote some backup scripts in VBScript and some utilities in MapBasic (Mapinfo scripting language). Python is a paragon of clarity and elegance in comparrison. I'm currently rewriting a VB program into Python and it's orders of magnitude easier to read and understand in it's Python incarnation. Apart from anything else it's at least properly indented because, well, it has to be.
Hi all,
First, I'd like to state why I find Ruby such a great language. I think it's because of the great ideas that Matz poured into it. The privatization of fields, the forced scoping of instance and static members, the return everywhere thingy, the synatic suger which is a block, and the various variations which is the control structures. I can't comment on the future of Ruby but the past is pretty amazing. (then again, when I asked my dad to check it out, he smiled and said it looked alot like smalltalk with too many different control structures :))
That being said, it would be great to have a common binding interface to all of the major linux components (kernel, filesystem, gtk, daemon services, X, gtk, qt/kde, etc, etc, etc) which then could be leveraged by either Ruby or python (or Java or perl...) Just look at the success of smoke. If that could be replicated for the rest of the linux source base, it would be a major, major win.
Cheers,
Ben
That is great!
Also there is a way to execute python code in parallel on SMP: Parallel Python
Post a Comment