Slashdot Mirror

Eric Schrock, a developer for Sun, posits his opinions on why the GPL would not be a good fit for Sun.

Well, this is basically rehashing some well-known arguments that are often brought up in a GPL vs. BSD debate or Free Software vs. Open Source software.

In a nutshell, the GPL gives you some freedoms but only if you accept its rather strict conditions. GPL advocates claim that it is a good thing, while GPL opponents claim that it is a bad thing. The basic idea that differentiates the GPL from other licenses is that a piece of code licensed under the GPL should not be used to give an advantage to non-free software. This is why the GPLed code cannot be linked together with code that is not GPL-compatible. This is also why RMS encourages developers to release their library code under the GPL instead of LGPL, although many developers who are more "open" still release code under the LGPL (e.g., GLib and GTK+, etc.)

The analogy with Oracle having to release their whole code under the GPL is also frequently (ab)used. Nobody is forcing Oracle (or anybody else) to incorporate some pieces of GPLed code into their software. They can easily rewrite something similar on their own, if they need it. If the author of the interesting function wants to promote Free Software and does not want to give an advantage to proprietary software, then his/her wishes should be respected. This is what the GPL does.

If you take the point of view of Oracle and you want to add some functions to your proprietary code, then GPLed software is not better than other proprietary software because you cannot just take it and use it without conditions. But if you take the GPL zealot's point of view, then it makes sense that the GPLed gift comes with some strings attached.

It is just a matter of choice. The arguments from Eric Schrock could interesting if the only option for Sun had been to release the code under the GPL or the CDDL but not both. But there is also the option to dual-license and allow those who get the code to continue their development under the GPL, CDDL, or both. Then anybody, including Oracle as in his example, would have been able to pick the best combination for them. But since Sun did not give any dual-licensing permissions for their code, they are effectively preventing a larger number of free software developers from using their code. It makes sense for them, but some of the arguments brought up in the press release and other public statements are rather misleading.

even slower than it's already glacial performance

Drop the apostrophe in "it's", unless you meant "slower than it is already glacial performance". That doesn't make any sense to me, but perhaps it does to you.

there aren't any CS departments that base their courses on Java, who cares about java

As horrible as the idea may be, there are a number of CS departments that made the Java switch during the big Java boom of the late 90s. My alma mater did the switch, though luckily I was always at least a semester ahead of Java changes.

Seriously, we really need a suite of JAVA tools, like word processors, spreadsheets, web browsers, etc... No more of this "well, it works on Windows, if you want it on Linux or Mac though we'll have to sit down and write it all over again, and probably introduce a ton of bugs....." stuff.

Just as soon as Java gets a good, cross-platform widget set, this can start happening. AWT and Swing aren't it. SWT is the right way to go, IMHO, but since it's not built into Java, it'll never have as much acceptance as AWT or Swing, and Java on the client will continue to be judged by those crappier toolkits.

What good is a program that depends on exact versions of 50 libraries (yeah, like I'll be able to reinstall that in 5 years and have even an outside shot at it working) and only works on a couple platforms, if you're lucky.

Java has the same problem. The Java base librraries are good, but there will always be something you want or need to do that the default set of libraries doesn't supply. What do you do? Well, just like a C programmer, you find a library that has already done what you need, and you use that. As for portability across platforms, you still have to worry about differences in the JRE for each environment and if you make any assumptions about a particular platform (paths, for instance). Java gives you the possibility of being portable, but it doesn't guarantee it.

when you make your own custom hacked windowing system to speed the process (Mozilla), it ends up being a slow RAM hog, even more so than it would be if it was written in JAVA, or another portable language to begin with.

The problem is not writing your own custom hacked windowing system (which XUL isn't -- it's a custom hacked widget set; the difference being that a widget set is the stuff inside the window, while a windowing system handles the windows themselves and doesn't much care what's inside), but writing your own custom hacked system stupidly. Mozilla's XUL is written stupidly, because it doesn't use native widgets (hey, sounds like Swing!). If the Mozilla developers would lose the ego, they would find that there are a number of good cross-platform widget sets (Qt, wxWindows (or wxWidgets, I guess they're calling it now), or even GTK+, though that would be my very last choice for a cross-platform widget set). Instead, the Mozilla team created Firefox when people complained about the weight of the Mozilla suite, yet they left XUL in place. At least there's Galeon, K-Meleon, and even Konqueror (since it can use Gecko as a rendering engine) available as native-widget web browsers.

I don't know about manpages, but there are plenty of resources online for learning various X toolkits. Gtk+ is the one I know must about, and I can say that gtk.org is a very helpful resource. They have API specs and even a tutorial. The tutorial also has Hello World.

So, if you want to write a Gtk+ application and you have no idea how, all you have to do is go to gtk.org. I'm sure that there are similar resources at trolltech.com (the company that makes Qt), gnome.org, kde.org, and any other toolkit you can mention.

It may not be a manpage, but it's about as straightforward as going to MSDN, if not moreso.

I don't know about manpages, but there are plenty of resources online for learning various X toolkits. Gtk+ is the one I know must about, and I can say that gtk.org is a very helpful resource. They have API specs and even a tutorial. The tutorial also has Hello World.

So, if you want to write a Gtk+ application and you have no idea how, all you have to do is go to gtk.org. I'm sure that there are similar resources at trolltech.com (the company that makes Qt), gnome.org, kde.org, and any other toolkit you can mention.

It may not be a manpage, but it's about as straightforward as going to MSDN, if not moreso.

I don't know about manpages, but there are plenty of resources online for learning various X toolkits. Gtk+ is the one I know must about, and I can say that gtk.org is a very helpful resource. They have API specs and even a tutorial. The tutorial also has Hello World.

So, if you want to write a Gtk+ application and you have no idea how, all you have to do is go to gtk.org. I'm sure that there are similar resources at trolltech.com (the company that makes Qt), gnome.org, kde.org, and any other toolkit you can mention.

It may not be a manpage, but it's about as straightforward as going to MSDN, if not moreso.

Like this? http://www.gtk.org/gtk-2.6.0-notes.html

(No, it doesn't use fancy html features but it's HTML. The "announcements" liked in the story are announcements for developers. Developers like pure ascii)

Check out the The Mono Handbook for tutorials and general getting started instructions. It's still a work in progress, so many sections are still quite empty. Another resource you should familiarize yourself with is the MSDN developer documentation for most of the core .NET API, it includes a lot of examples.

I also recommend you check out the standard GTK+ tutorial. A lot of it is still directly applicable to GTK# and it's more complete than most GTK# only tutorials. If you're already familiar with GTK+, Glade# for Rapid Development will help you get up to speed with Mono.

1. The Menus should be much more customizable; treated like folders that you can click and drag into (I hate to say this, but "Like Windows").

2. Better Video control properties; take advantage of XFree's extended features and have options like TV switching and such.

3. Better preferences; the control panels are quite lacking.

4. Other aesthetic enhancements that will make gnome pretty enough to compete with other window environments (like win XP's or OSX's). Smooth scrolling, the zoom-on-hover icons in OSX are sweet, and _drop shadows on windows_ would be real nice.

5. Some kind of Linux-version-of-Active-Desktop would be real nice, so I could have an IRC session running as part of my wallpaper,anchor the weather channel radar map to the background, etcetera.

Yes, multimedia is certainly something we'd like the desktop to do well. However, it's not realistic to expect comprehensive multimedia support from a Linux desktop today with open source software. It's a very difficult and costly problem to solve comprehensively. There are some positive signs, such as helix community, but you don't really have a single piece of software that does it all as well as the Windows variants.

Ummm...I'm not sure how to respond to this. How about mplayer? That has to be the best movie player I have ever used. And didn't it receive some sort of award recently? Or how about Xine?

Let's see...what else? The GStreamer framework is coming along nicely and will probably mature before the end of the year. There are several audio players available, some more usable than others, though. There are also more specialized programs like the Bedevilled Audio System. So I would hardly say linux is deficient in multimedia software.

All they ask is that someone give them a first-class GUI toolkit at no cost, and with no strings attached! Is that so much to ask?

Sounds reasonable to me.

Please specify a single popular commercial app that uses GTK...

People fail to understand that you don't pay only for the right for developing commercial programs when you buy a QT licence. You are also paying for SUPPORT.

There exist lot of free software for Linux, thus if you want to SELL your software, you need to invest lot of money in any case to create something much, much better.

Last time I checked, there were lot of undocumented widgets in the GTK. How are you supposed to figure them out? $1000-$2000 QT licence pays itself quickly back with faster development times.

For anyone who doesn't want to "ignore the C++ nature of it," I would also recommend looking at gtkmm , a class library built upon GTK+ . I've used it in a couple of projects so far and have generally had a pleasant experience.

There's this thing called GTK that Gnome is based on, I hear it's pretty decent.

GTK Tutorial
QT Tutorial

I get the impression that you want to record mouse movements and keystrokes and whatnot, but given that I don't know the specific tasks that you are trying to "macro" I think this method of automation is bass-ackwards.

I can't think of very many tasks in linux that cannot be done with console based alternatives to graphical ones. That being the case, you can control and automate all aspects of a console application using bash or the shell of your choice.

But if you must automate an application that only has a graphical interface, this application should do it.

Not to sound like a troll, but this is a very weak area compared to the Gnome/GTK+ bindings to languages as infrequently-used and obscure as ML, OCAML and Haskell.

Here's a list of GTK's bindings:
http://www.gtk.org/bindings.html

KDE needs to improve here, and C++ needs a standardized ABI first. The ease of binding other languages to C is what gives GNOME a huge leap in this regard, and not much else.

Wasn't it supposed to be released on the 2nd?

http://gtk.org/plan/2.4/

New file selector, yum.

When it comes to window programming, object-oriented is the way to go.

Man, I hear this a lot from MFC programmers. GNOME/GTK's lowest level API is not in C++. It is written in C. However, there are well-supported C++ bindings, which I have written code with and been happy with. This is particularly funny, since you're talking about MFC as being an example of what you want -- and the same thing is true of Win32 (C) and MFC (C++ sitting on top).

Not *only* that, but even the C-level code is object-oriented. It's not "half assed" object orientation either, as I see a lot of claims of. I have the ability to use either, and I'e chosen to use the C-based approach. Really, the only people I know of who yell and scream about the fundamental GNOME/GTK API are those who (a) program most of the time in Java and don't like using C and simply complain at the sight of it or (b) program most of the time in C++ (frequently ex-MFCers) and don't like using C and again complain at the sight of it. All this is *doubly* funny since there are a *ton* of language bindings. If you like a language, support is probably there in at least GTK. If you want to use Java to write your GNOME apps, if you really feel that you need a language that requires you to use OO interfaces (which C++ is *not*), then by all means, go ahead and do it.

Come to think of it, I don't believe I've used a procedural style GUI API since coming to UNIX. Actually, no, there's Tk. And I've used Xlib.

Is GTK for Win32 actually viable now?

The stable releases (2.0.x/2.2.x) are pretty much usable under win32.

Oh and yeh, I can't stand writing GUIs in C.

You don't have to "write GUIs in C": just use one of the bindings (C++, Python, Perl, ...).

Tk is a horrible example of a GUI toolkit tied to a language. Even if you wanted to write using Perl::TK or TK in C, you needed a TCL interpreter installed.

QT and GTK+ have a fabulous assortment of high-quality language bindings. You aren't tied to using C or C++, respectively. I'm familiar with the Python, C++ and C# GTK+ bindings, and can say that they are superb.

http://www.gtk.org/bindings.html

• What is GDK?
  
  GDK is basically a wrapper around the standard Xlib function calls. If you are at all familiar with Xlib, a lot of the functions in GDK will require little or no getting used to. All functions are written to provide an way to access Xlib functions in an easier and slightly more intuitive manner. In addition, since GDK uses GLib (see below), it will be more portable and safer to use on multiple platforms.

I used it myself when I needed to store a symbol table for a language, and that app most definately didn't use any GNOME facilities.

More information at the GTK+ web site.

- GTK's poor resize performance compared to Qt.
- GTK's poor expose handling compared to Qt.
- For practical purposes, lack of component technology. Bonobo is there, but almost no apps use it. Meanwhile, tons of KDE apps use KParts.
- For practical purposes, lack of a network-transparent filesystem. gnome-vfs is there, but not many apps use it, and its not supported through the standard file dialog. Meanwhile, every KDE app uses KIO.
- Nothing comparable to DCOP (until D-BUS comes out).
- Lower-level UI framework, compared to KDE's higher-level framework. GNOME's button Ok/Cancel button order is dictated by the HIG, while in KDE, its dictated by the framework, and would take a single line of code in kdelibs to change for all KDE apps.
- Lack of UI integration at the technology level. KDE apps use XML-GUI to define their layout. GUI layout can be change without touching a single line of code. KDE apps support customizable toolbars at the framework level, so all apps get it for free. The HIG is great, and GNOME's UI is very polished compared to KDE, but it would be nice if GNOME did like KDE and enforced a lot of those things in the code framework level.

Let's look at some of the upcoming GTK+ 2.4's features that Qt/KDE already has.

File selector (#29087)
------
KDE has it.

Combo widget (#50554)
------
Qt has it.

New action-based menu API (#55393)
-------
KDE has it.

Toolbar improvements (#55393)
--------
If you click on the feature request number and look at the proposed features, you'll see that Qt/KDE has a lot of these already, like customizable toolbars.

Autocompletion and history for GtkEntry (#69613)
--------
KDE already has this.

XCursor support for GDK. (#69436)
---------
Yep, this too. And they even mention Qt right in the first post of the feature-request thread, how nice!

No, GTK+ is LGPL. You can do closed-source development with GTK on any platform without getting a licence. Check the page.

Not really on topic, but Linux (and other free Unix-like systems) users learning Japanese I recommend
gjiten + kanjipad + im-ja for a good dictionary system (you just have to convert Jim's dictionary files to UTF-8, iconv(1) is your friend).

What other Japanese-related software slashdotters like?

Quick, KILL IT! It had a damn retarded licencing scheme anyway. Now if only KDE will die as well, the world would be a better place.

You'll find that wxWindows, the Fox Toolkit and GTK provide vastly superior -AND FREE- alternatives to QT.

Qt also works on the Mac and Windows - GNOME toolkits don't

There is no GNOME toolkit. I think you mean "The GIMP Toolkit.

GTK does work on Windows, and it works pretty good. Two projects that use GTK are Gaim and Workrave. I have used both on my Win2K box at home for the last year, and use it regularly here on my work box also.

Against Ballmer's glib...

The line-edges of the cube form a "Y" shape. Slick.

The line-edges of the cube form a "Y" shape. Slick.

• There is a "standard" API, but it's using the old, limited feature Xlib API.
• Today, there exists two very popular alternative Desktop environments, which in turn are based on two different Widget-toolkits. These are Gnome (uses GTK+) and KDE (uses Qt).
• Developers wishing to develop on Linux will usually pick one of these two Toolkits, as almost all Distributions offer both environments (and associated development libraries).

So the problem isn't a lack of API details (GTK API's and Qt API documentation), but moreso an issue of choice.

• There is a "standard" API, but it's using the old, limited feature Xlib API.
• Today, there exists two very popular alternative Desktop environments, which in turn are based on two different Widget-toolkits. These are Gnome (uses GTK+) and KDE (uses Qt).
• Developers wishing to develop on Linux will usually pick one of these two Toolkits, as almost all Distributions offer both environments (and associated development libraries).

So the problem isn't a lack of API details (GTK API's and Qt API documentation), but moreso an issue of choice.

On another note, I've been trying to pick up some Linux programming in my spare time and am completely confused. I come from a Win/Apple background where the system APIs are fairly straightforward and well documented. In contrast, Linux APIs are pretty much non-existent.

I assume that the standard C library exists, but once I try to do any windowing, I am faced with half-documented APIs from a multitude of sources. Gnome, KDE, etc., it's all very confusing. The worst part of it all is that the documentation is virtually nonexistent. Sure, there are blurbs here and there, but you'd be lucky to find a documentation system that links together related APIs, clearly enumerates all parameters and their meanings, and displays the data in a readable manner.

It makes me wonder how anyone gets anything done with this proramming environment.

If I run KDE, will I be able to run Abiword?

gtk is another site that is protesting. Good though, if you look at the rubbish pattens which are already registered (illegally) in Europe, ...

It has the same miserable file selector dialog as the X11 version! Won't those monkeys ever realize what a barrier to adoption that thing is? It was behind the times they moment they wrote it.

Indeed. A new file selector is in the works. In the meantime, discover the nice tab-completion feature. While I certainly agree there is room for improvement and definitely wouldn't suggest the file selector to my grandmother, I save/open files faster with the GTK dialog than any other I've used.

GTK+ 2.4 Plan

For example, for the C program that I'm writing right now, I decided to use GLib -- the base utillity library used by GTK.

I initially chose it for portability reasons, but soon discovered it had a wealth of cool stuff in it. In addition to providing the standard data structures (trees, hashes, linked lists), it also has a string type ( GString, ) which handles a lot of the string issues that C programmers get bogged down with.

A lot of the gotchas (buffer overflows, et. al.) mentioned in this article have to do with these string issues, and using GLib's GString data type has enabled me to avoid those.

There is another library similar to GLib, The Apache Portable Runtime, used in the Apache webserver, and also in Subversion.

In addition to all this, I'm using XML as the storage format for my program, mostly because libxml takes care of the file parsing issues so I don't have to.

Bottom line, choose your libraries carefully, they can make a world of difference.

Thomas

For example, for the C program that I'm writing right now, I decided to use GLib -- the base utillity library used by GTK.

I initially chose it for portability reasons, but soon discovered it had a wealth of cool stuff in it. In addition to providing the standard data structures (trees, hashes, linked lists), it also has a string type ( GString, ) which handles a lot of the string issues that C programmers get bogged down with.

A lot of the gotchas (buffer overflows, et. al.) mentioned in this article have to do with these string issues, and using GLib's GString data type has enabled me to avoid those.

There is another library similar to GLib, The Apache Portable Runtime, used in the Apache webserver, and also in Subversion.

In addition to all this, I'm using XML as the storage format for my program, mostly because libxml takes care of the file parsing issues so I don't have to.

Bottom line, choose your libraries carefully, they can make a world of difference.

Thomas

"You've said it! You have to port C code!! Java is cross-platform by design, not portable."

Uh, I think anyone rolling-out a government-wide payroll system will know how to use a compiler.

GNU runs on pretty much every computer yet invented, thanks to automake, autconf, gcc, the GNU libraries (GTK, gnome, glibc...), and the GNU application standards. I didn't see anyone re-writing grep in java, and when people needed massively cross-platform applications (mozilla, gimp, kaffe), they weren't looking at Java for those either.

"porting C code is just a matter of making sure the library you use on OS A is also ported on OS B"

Kind of like making sure the virtual machine you use on OS A is also ported to OS B? Or that the Java AWT libraries you use in OS A are also ported to OS B?

The only true cross-platform GUI code I've seen recently is Konspire2B, and that was pure C, using an http://localhost:6065/ web-interface for the GUI. They chose not to use java because you'd need to install a java machine to use it. With C, you can just run the program as-is.

Look at any of the user-interface modules for perl, for ruby, or for java, and the chances are they'll be written in C.

gtk and gnome are both primarily Linux initiatives.

If you use something other than just the commandline than what you see is NOT GNU.

GNOME is part of the GNU project, and is free software (sometimes referred to as open source software).

GTK+ is free software and part of the GNU project.

IMHO, the problem with Swing is mostly that it is horribly overengineered and, frankly, that the implementation sucks. It's all in src.jar - read it and tell me if you would hire someone who would present that piece of crap as their prior experience.

• xscribble -- a Graffiti-like text input tool.
• gsumi -- a writing/drawing utility.

Anyway, he had an itch and he scratched it. besides, although XP looks to be more workable practically and although some things can be easier to do in XP in terms of number of steps, etc, I know from experience that windows interfaces always irritate me. they just do. waaaaay too limiting.

So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?

At what level? SDL? GGI? GTK? Qt? wxWindows? KPart? Six of one, half a dozen of the other, perhaps you're spoilt for choice?

For those who don't understand this distinction: glib is *not* a GNOME library. It is used by GNOME, but it's actually part of the Gtk+ project.

In glib2, the object model used in Gtk+ and GNOME was broken in half and all of the non-GUI parts were put into glib, but that's really just a small part of glib. It also provides a number of invaluable tools for C programming, acting as a sort of extension to the standard libc, and providing many of the facilities that higher level languages generally give you.

Most high level languages already do most of what glib does, and in those higher-level language bindings to Gtk+ and GNOME (e.g. from Python, Perl or Ruby) the glib interface is just a matter of data-type conversion and synchronization of assumptions (e.g. how exceptions will be handled).

Java programs aren't cross-platform. Otherwise I could download a single package to run on whatever OS I have.

Java is a platform, or at least Sun calls it that. Following that reasoning leads to absurdities like claiming Super Mario Brothers or StarCraft are cross-platform, since they work in emulators. You could say I'm being pedantic, that "running on a platform on platform A" is practically equivalent to "running on platform A", but that's not so.

To the point, suggesting the use of Swing imposes serious limitations on the project- mainly that it has to be written in Java and run on a JVM. The performance penalties are appreciable. (It is possible to use Swing to display a non-Java program, but ugly and impractical).

The other GUI toolkits that got good recommendations generally have multiple language bindings for them

PersonalJava is sold on devices with 64 megabytes of RAM, or even more.

1. http://www.gtk.org/tutorial/ch-introduction.html
2. http://www.gnu.org

So, do you want to port the app to a command-line form running on Linux on the current hardware? (0.02USD: ncurses, slackware) Or do you want to port the app to a GUI form running on Linux on newer hardware? (0.02USD: any number of toolkits, any number of distributions) Obviously as the second route is the greatest change, the variables are more numerous giving you a much wider of range of options to look at. I'm guessing your current programmers are C or Pascal folks? You might consider using GTK+ (GUI Lib written in C, also has bindings for FreePascal). As far as a linux distro for the more open-ended situation goes, I'd have to say debian. The install can be a bit of a pain for the uninitiated, but it more than pays back that annoyance after install becuase with the very intelligent package management system you can do stuff like point the terminals at a central server to pull updates from (e.g. roll your app in to a .deb, have terms auto-update once a week using a cron job, makes deploying patches and security updates easy as pie). Debian will also work in fairly constrained hardware environments like slackware, but it tends to be a beefier install usually.

Well, there's Python, Perl, Java, C#, Ruby, and C++ according to the KDE docs. Not bad, but pretty lame that it can't even do a single functional language, much less Objective C.

Gtk has Ada, C++, Perl, Python, Common Lisp, Eiffel, Erlang, Guile, Haskell, Java, JavaScript, Objective-C, Objective-Caml, Objective-Label, Pascal, PHP, Ruby, TCL, TOM, and XBase bindings.

GTK+ has a native (not a preferred) language specifically chosen because it's least-common-denominator. The Qt people evidently didn't see compatibility with less-used languages as important, so they snubbed everyone else.

Qt uses the STL.

Really? When did they lose the QString and QVector class and other ugly warts?

And it's bigger because it does a heck of a lot more than widgets-only GTK+

Which is a *bad* thing, violating the UNIX design principle of many small parts, each the best for its job. I frequently use glib even in projects that I'm not using gtk+ in -- I find it makes C a joy to use. You can't do that with Qt -- it's all or nothing. I don't want a bloody "platform" on my computer. I got my fill of that with JVMs. Qt is bloated, and far more so than gtk.

GTK+ manages with the LGPL because it is a free beer library.

Okay, I miswrote. My point has not changed -- if you want to put it that way, Qt is not a free beer library. And that's a sorry state of affairs.

The impression I got is that Qt pretty much exists to pander to ex-Windows types, who are used to coding in C++.

Ah good, someone got in before me :) It is definatly a good idea to separate out the GUI part when dealing with cross-platform applications, since a lot of portability problems reside there.

In all honesty, I don't recommand Qt or wxWindows - they are great toolkits, but you lose out heavily on productivity compared to visual development environments with GUI builders. While both of these have associated builder tools, I don't consider them very mature of capable compared to VB or Delphi/C Builder. There is also a write-once-debug-and-tweak-everywhere concern (just getting wxWindows looking good on Windows and Solaris takes some effort).

Java is a great choice as it is supported on many platforms, has powerful GUI classes, a couple of builder products, and has several means for client/server support, including CORBA. But for UI applications it isn't hugely productive (strangely enough).

Some of your other options include ParaGUI and SDL, gTk, GraphApp, V, Mozilla's XPToolkit and XUL, and WideStudio.

I have grappled with exactly this question (legacy C/C++ needing to go cross platform with GUIs), and the best answer I've come up with so far is to keep your main code in C/C++ (since you have the legacy code AND the skills), define a clear UI abstraction layer, and create the UI in a scripting language such as Tcl or Python. Use SWIG to tie the script to native C functions.

I have more experience with Tcl/Tk, and believe it is more widely portable (especially the GUI consistency), but it is slower and arguably more difficult to program than Python. Still, this depends on what skills you can acquire, and what your UI requirements are.

Prechelt has an empirical comparison of some languages, including C/C++, Python, Tcl and Perl, and most importantly he has productivity figures! Keith Waclena has a Language Crisis page of comparisons, and Doug Bagley hosts the Great Computer Language Shootout. There are all invaluable resources for determining a balance between portability, functionality and productivity.