Compiled/interpreted is hardly a meaningful distinction nowadays; IDE's such as Eclipse completely hide away the compile step, interpreted languages are sometimes compiled transparently to improve performance. The really interesting metric is "how much time I need to start my program while developing", really. With today's processors, even compiled heavyweight Java + Tomcat starts in my box in less than two seconds, which hardly bothers me.
Again, most languages are Turing complete, meaning they are all "equivalent" wrt. to the capabilities of the programs you can make with them. What matters normally is:
- Bindings/ability to use the libraries/framework you need. If you are developing a GUI app, you will need to be able to use a GUI library from the language you want. There are loads of GUI libraries (GTK, QT, the couple of Windows frameworks, Cocoa for OS X, etc.)- some are a platform's native GUI library, some are multiplatform- and they all support different sets of languages (and within that, there are often first-class citizens; Objective C is Cocoa's first-class citizen, for instance)
- General language quality and suitability to the task at hand
The latter is more complicated, and fairly subjective.
I would say that PHP is ill-suited to GUI app development- the main GUI binding I know is PHP-GTK and it seems to be pretty much inactive. Also, PHP's programming model is fairly tied to the request-response/HTML generating nature of web applications, which doesn't really fit nicely with GUI development.
Python is generally OK to develop GUI apps. Bindings exist for a variety of toolkits, and while Python isn't a particularly fast language, that hardly matters for most desktop apps- unless your application does something particularly CPU-intensive, you're not gonna notice any performance difference between any languages.
In general, GUI applications are more chosen by your target platform. If you target a single platform, often the least-effort/best-results approach is choosing the first-class citizen in that platform. If you are coding an OS X app, Objective-C + Cocoa is probably the way to go. If you develop a Gnome/Linux app, GTK + (Python|Vala|C) are probably the best options, likewise C++/QT for KDE, and C# + one of the official Windows toolkits (I've lost track now). Funnily enough, the "official way" is muddled- what you want here is something with plenty of documentation and maintained by the same people who develop the platform- languages/bindings by third-parties often lag behind or miss features.
But if you can choose the native "first-class" toolkit/language combination, you'll normally be able to deliver an application which looks and behaves like the rest of applications in the platform and which provides the most natural experience.
If you want to develop cross-platform apps, it gets slightly more complicated. There exist cross-platform toolkits- GTK, QT, Java's Swing and SWT, etc.- but you must realize that often they do not provide as good an experience as native toolkits- maybe the widgets do not look like the native widgets, or stuff like that, but even the best cross-platform toolkit cannot fix that different platforms have different conventions (standard shortcuts, menu arrangement and naming, dialogs, etc.)- think of iTunes on Windows- it looks and behaves definitely foreign and different to regular Windows applications, although it looks perfectly at home at OS X: same application, different platforms; means no native experience.
You might be OK with this- or even you want one of those custom-looking applications which look like no regular apps.
If you aren't, prepare for a road of pain. Probably the best solution is to develop separate applications for each platform you target, and if you are lucky, you might be able to reuse a good chunk of code from platform to platform (particularly, if you can use a common language- for instance you might develop your core app in Python and develop several GUIs for different platforms using different toolkit bindings- if you are lucky and they exist). Another way would be to use a multiplatform toolkit and work hard to adapt your program to the different platforms you target, but that might be a lot of effort or maybe even outright impossible to achieve completely.
