Here are some key differences in language choice in regard to cross-platform development.

Languages like C/C++ compile to native code for a specific platform/OS. To build an executable for a given OS, you need to run the compiler and/or development tools on the same OS. So if you want to make a Mac OS X version of your program, but you don't have a Mac, you're out of luck. Toolkits like Qt and wxWidgets only allow you to port your source code across platforms, but you can't compile executables for other platforms from one OS. Think "write once, compile everywhere." You will also need to include the runtime library for the cross-platform GUI toolkit with the executable you give to your users or have them download and install it. The runtime libraries for cross-platform toolkits are not typically included in the OS.

Languages like Java and Python are interpreted languages, that is they require an interpreter or virtual machine on the end-user's machine to run the programs. There is no need to compile a separate executable for every platform you wish to support. You can build the program in your favorite OS and distribute the ready-to-run source code (in the case of Python) or executable .jar (in the case of Java) to users of any OS that supports it. Think "write/compile once, run everywhere."

If you want to support an OS that you don't have yourself, choose one of the interpreted languages. The downside is that you will need your end users to download and install the interpreter or virtual machine for that language for their platform. However, since almost every OS nowadays includes a Java virtual machine, most users won't need to install anything extra. The same cannot be said of other interpreted languages like Python.

In terms of speed, programs written in interpreted languages will start up somewhat slower than native programs because the interpreter has to start before running your program. Unless you are writing something like a large, complex office suite, the speed of a modern interpreted language should not be appreciably slower if at all. For cross-platform development, the fact that almost every OS comes with a Java virtual machine allows a Java program using the standard Java GUI library (i.e. AWT/Swing) to be ironically less bloated in terms of file size than the equivalent C++ program requiring additional runtime libraries like Qt or wxWidgets, some of which add up to 10 Mb to the program.

I found writing a GUI program with Glade and Python to be very easy. I would definitely recommend it to get started. You can convert Python programs to executables with py2exe.
http://logix4u.net/Python/Tutorials/...on_script.html

Sorry, but thats all complete BS.

I take it you have never heard of a cross-compiler? I can write software using c++ and wxwidgets on linux, and cross-compile to Windows with two mouse clicks. Eg: http://wiki.wxwidgets.org/Cross-Compiling_Under_Linux

Regarding the runtimes - Qt: yes, many dlls needed on windows/libraries on linux. wxWidgets compiles the extra into the binary. Most fairly simple GUI apps compile to approximately 1MB, and need no extra files at all, just the single executable.

No it is not. What kaiser_suse was giving was a overview of the most common approach to the problem and arguably the most appropriate approach for someone asking the question that starts "Beginner programming language...".
Please think before flaming someone else's response.

OK, so the original poster said he was fairly proficient at bash scripting and wanted to move up a notch, and you see that 'notch' as being learning C++?!?
Recently I've come across a few recommendations to n00bs that they start off with C++ and I have to say I've never heard such rubbish. In the length of time it takes to be a proficient C++ programmer with good knowledge of the various STLs and a solid grasp of the multitude of gotchas, which C++ is rife with, someone could go from total beginner to expert in any number of 'scripting languages'. Sure, it might not be as 1337, but at least they wouldn't be plagued with and put off by the various stack trashes and buffer overruns that even experienced C++ coders have to deal with.

Please mind your tone. Okay, so you have a different opinion on what language is best for a beginner. Fine. But discarding other views as "rubbish" or "1337" isn't helpful, nor is it adding any credibility to your point of view.

You have some valid points about difficulties with C++, but there are bugs and gotchas in pretty much any language; and good reasons for chosing a compiled language (including ease of distribution, runtime efficiency and compile-time type checking).

Personally, I'm not experiencing the gotchas of C++ as a huge issue (particularly since Qt offers ways to work around some of them); and I can recommend it with a good conscience also to beginners. Still, what I would recommend most of all is to have a look at both a compiled (C++) and a scripting language (my personal favorite would be Ruby, since it feels "cleaner" to me than Python and has built-in text processing features comparable to Perl) and decide for yourself what suits your needs and your taste best.

If you would like a RAD tool that compiles to a single executable file and that can give you some good foundations, I would recommend Lazarus. Lazarus is almost like Delphi, but it runs on Win 32/64/CE, Linux 32/64, Mac OSX, and a few others. Lazarus is a extension of FreePascal. It is very easy to create a GUI using drag & drop. You can find out more at www(dot)lazarus(dot)freepascal(dot)org.

anything but java.lang.outofmemoryError.

nothing is easier than tcl/tk.
perl/tk
python/tk

a full tcl/tk program:

pack [button .b -text OK -command exit]

I always liked Turbo Pascal back in the day. I'm surprised there aren't more people coding using FreePascal. I'd have thought that with the Object Pascal extensions it'd be quite usable. What's wrong with it? Is it just that it's 'old' and therefore un-cool?

Another thing I've often wondered about is why there's so few Objective-C programmers out there. As a pure superset of 'C' I'd have thought it'd be a much more natural transition to OO for existing C programmers then C++.

Not just that, but it is really cross platform. If it runs on Linux, it runs on Windows, no matter how you write your program. Just have the tclsh/wish executable installed.

And it is not bloated, nor slow. How a GUI is built is the script, but the actual building is compiled code.

In one evening you have your first application running, that easy it is.

jlinkels

Regarding what language to learn first, you could write a book, with the various pro's and con's of each language. I personally started with GW-BASIC when I was about 10 or so. Then to assembler (on a System 80), then C, and C++. I've only recently learnt Python (and loving it). The main reason I suggested Python is that you can sit down with a book, or a tutorial, with the interpreter running, and just goof around with out much trouble, and learn heaps. Like I did with BASIC a couple of decades ago ;-)

I just had an idea, does anyone remember those books you could get (generally from your local library) with BASIC code listings for games? There usually was a section for converting to TRS-80 or Commodore 64 and so on. Books like that might work well for Python. If you could drag the kids off the Xbox. :-/

Speaking for myself, I have to say that using a mainstream language has some benefits in and of itself. There's usually more and better tools and libraries available. Particularly, if you decide to use a C++ GUI toolkit, then going with C++ is a natural choice. Particularly if that toolkit works around limitations of the language, interfaces to other languages tend to feel not quite natural (thinking of Qt meta object system and signals/slots here). Similarly, as a language I like Ruby better than Python; but for scientific computing I'd have to recommend Python simply because it has the better libraries available for the task.

Also, if you're doing performance-critical stuff (involving large, tight loops; e.g. numerical computing) then (non-virtual) C++ method calls are preferable to ObjC message passing (not to mention interpreted languages). Of course, this doesn't apply equally to all types of applications.

On the other hand, I have to admit that I never actually tried FreePascal and only had a cursory look at ObjC/GnuStep; so I may be missing the key benefit there.

Speaking of Tk, I just have to add that Ruby ships with Tk bindings, too. :-)

tcl/tk is a great way to quickly build basic applications, such as what the poster wants, and would seem to fit in nicely with the experience level. In any case, avoid C++, with your expecience it would probably take to long to learn, and cause far more headaces to be worth it. Python is also good, ruby, maybe java.

As for Objective-C: Its not used because its a crappy language to program in. From my experience with it, it seems to require a runtime to deal with low-level things that the compiler handles in C++. Also, the only real libraries for it outside of MacOS is GnuStep, but the filesystem layout of GnuStep applications is very much not native (and thats ignoring the actual GUI), which is annoying to deal with. If only it was possible to use Objective-C without GnuStep, I would consider it, as its a fairly nice language in source code form.

I've done Python, TCL/TK, QT, C++ and what have you. Java is a lot easier. For one, your end users probably aleady have it installed as so many Web sites and applications require it. Another reason is that you can get your hands on tons of documentation and IDE's ( Eclipse, NetBeans ) to help you out with it.

A third reason is that you can use it in your workplace, and get a J-O-B with it.


Java is the winner!


Enjoy!

Yes, I have heard of a cross-compiler and have explored the possibility of using cross compilation to port my programs to other platforms in the past. But cross-compiling in most cases more specifically means compiling for another cpu architecture (e.g. i386, ARM, PowerPC) rather than for another OS, which is why I specifically said "OS" my post. Even though Windows, Linux, Mac OS X all run on the same Intel processors, it does not mean code compiled for the same CPU will run on every OS that runs on that CPU. In modern software development, programs talk to the OS through OS specific APIs (e.g. MFC, Cocoa) or an OS specific port of a cross-platform API (e.g. wxWidgets, Qt) rather than directly to the hardware as was done in the past. Simply having one of the cross-platform libraries available for a given OS does not automatically mean that any compiler on another platform can cross compile executables for it. To do cross compiling, you need a compiler that has that feature and that supports cross compiling to the specific OS(s) you want to target. In the case of gcc/MinGW/wxWidgets there is one-way cross compiling to Windows from Linux, but what about vice versa? It will most likely be a very different procedure. Last time I checked, there is no way to build a Mac OS X executable using gcc or wxWidgets from Windows or Linux, otherwise I would written my programs for distribution in C++ rather than Java. There are vastly more JVMs available for different platforms than there are C++ cross-compilers for them.