>Java - I have always considered Java apps to be rather clunky and not really ready for LoB applications. Also consider it a bit low level for a Business Application development language.

All and all serious points - but in java you have support for pure desktop, installed internet (web start)
and (on Intel) browser based apps. Android being a recompiled java is also not too far away if you code your biz parts with care.

>PHP - I thought this was only a scripting language suitable for basic simple applications, am I wrong?

Has also large web fwks, but has troubled syntax IMHO. Only Web.
>
>Ruby/Python - these see to be bubbling to the top of the choices, further investigation required to compare the two. Why is Ruby considered Enterprise ready but Python is not?

Don't form your opinion just because Craig said so ;-)
Ruby (with Rails) offers seen from afar a more monolithic view most of their adepts share.

Python has more adepts, but (too) many different fwks and specific recipes -
looks bad for any enterprize searching for the IBM HW analogue of the early eighties.

If you look at the companies utilizing python, I think the claim is too encompassing.
Especially as Python makes a great glue language, you can wrap parts of other tools.
The question might be whether biz components should also be written in oython,
as refactoring support is less than with statically typed languages.
But as you need less code in python compared to C#/Java, this is not as importan in Python.

>
>To those questioning why the ability to build an executable is important a recent example I encountered explains this clearly. We were evaluating a remote 'cloud' based lets call it document management system. Although it worked and provided the remote access required, it was awfully slow and clunky. We then considered that actually 90% of the time this was being used within the main Office environment on a network connected to the main Company Server. If we had the ability to change this to an application which detected when it was being run internally and retrieved retrieved documents directly from the internal Server rather via the Internet connection it would have worked fine. As it happened being a cloud based offering where the ability to do that was not possible the application was thrown out.

But that argument is more against the specific cloud based DMS.
Having a config file spelling out "local/LAN" access paths (/and or data load componentes) will speed up
both browser based and installable apps.

I will either go for a Jython based buz classes pluggable into the web and desktiop fwks in java or a pure python based solution.

my 0.00001€

thomas