I believe that almost any programming language can be used to build almost any kind of user interface, but that the closer the user interface is to the assumptions built into the language, the simpler and more efficient this component of the overall application will be. More importantly, I believe that the simpler and more efficient you make the interface for users, the more usage your application will attract and the more valuable it will become for users.
Notice that these are matters of belief, not fact because the needed research, widely underway in the late seventies and early eighties, has largely been abandoned.
Taken together, however, these beliefs mean that the language and toolset selection should be dominated by application considerations, that the lighter weight you can make the front end the more effective the thing will be, and that interfaces have to be tailored to your users more than to the application.
In today's IT context this means that most of the "rich experience" interfaces are strongly counter-productive when applied to normal business applications of the ERP/CRM kind, whatever value they may have for stuff like porn, email and customer accessible catalogs.
Consider, for example, the consequences of writing an AR package using something like the OpenLaszlo tools.
In many ways Laszlo is pretty cool stuff - and it does deliver rather well on that "rich experience" idea, enabling live multi-media integration and other colorful flourishes like user movable windows within a standard browser - with the standard plugins running on a standard device.
In the typical usage scenario, however, the thing is a bit of a pig: given a 300K basic library set downloaded with the first page it still takes 200 lines of XML running on a dual core PC with a gigabyte of RAM and 80MB of browser related executables to print "Hello World" - and another 2,000 to present the information that the overnight batch from Rhode Bloche transport doesn't match up with the warehouse shipping records.
In other words, you should never pick that toolset for writing and delivering this class of application because none of the "rich experience" stuff you'd be spending money and time on would do anything to help your user get the job done - and in fact the user would be much happier with a 1982 dumb terminal and something written in K&R C, because at least that would start up instantly, almost never fail, and not add heat, noise, and frustration to the working environment.
Neither approach is really practical today, but the absurdity here is that most business users for most of the bread and butter business applications would be better off if roughly twenty-five years of PC desktop had simply never happened.
Most people won't believe that, of course; but there's a simple test you can do to prove it to yourself: go talk to actual users -not power users in head offices, but the people who run the machines, drive the trucks, get the work done, and make the money. What you'll find is that they say the same things over and over again: they want the system to be fast; they want the application workflow to be logical, efficient, and minimal; and they want it to work reliably.
They'll demand simplicity too - but if you explore this idea with them you'll find that it's completely unrelated to GUI related ideas about of ease of use. To them "simple" means with a minimum number of steps, done quickly and in the right order, with no data re-entry or long pauses.
Thus their ideal user interface can be arbitrarily complex, but allows of no waste and requires a minimum of navigational interaction - so a radiologist setting up a procedure doesn't want to click through separate patient, resource, scheduling, integrity check, commitment, and result screens - he wants that all in one place and if that takes a tightly packed 24" screen he's perfectly willing to accept the learning burden involved as a trade-off against long term efficiency.
And that's the user bottom line on application design: the clerk posting journal entries, the guy running the machine, the person dispatching freight cars, the girl at the lensecrafters counter entering your new prescription on her PC - none of these people care about stuff like mp3 integration in the interface - that's for hobbyists and home entertainment - what they care about is getting the job done, and the less the tool gets in the way, the happier they are.
But if that's the real bottom line on the interface component in application design, it's also the real bottom line on development tool selection - because tools like Laszlo, no matter how attractive to us IT types, simply don't produce the lightest, thinest, most efficient front ends possible and therefore don't meet very fundamental user needs.