H.264 and WiFi standards are recent examples of a lot of companies working together.

It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java.

Eventually the JCP turned into "take popular open source ideas like hibernate and spring, and bless them with a JCP number". Which worked a lot better, and each of those individual projects was usually launched by an individual or small group initially.

I would really love to hear how you could possibly believe otherwise.

Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations.

I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be convenient and make rails possible.

http://en.wikipedia.org/wiki/List_of_Java_keywords http://docs.python.org/3/reference/lexical_analysis.html#ide... https://github.com/ruby/ruby/blob/trunk/parse.y (grep for reswords)

I'm undecided whether Python/Ruby or Java are simpler.

At least to me dynamic typing seems much simpler than static typing: from a very very pragmatic view that just means no compile-time checks (?), and I'm not that good with Ruby, but I'd consider Pythons type system much simpler than Javas (Python has none of: primitive types, null, arrays, interfaces, visibility (well, there is name mangling for __...), enums, final/abstract, the checked/unchecked mess (look up what the correct way to catch exactly: all checked exceptions is!), casting, generics and everything that comes with it: have a look at the index at the left side of http://docs.oracle.com/javase/tutorial/java/generics/index.h... -- but to be fair Pythons type system has a couple of nontrivial features (metaclasses, multiple inheritance, ...) too)

Python/Ruby have a lot of very useful language features which make the languages much less of a pain to use than Java (the language), but for any meaningful comparison of language complexity you'd surely also have to consider the intricacies of the underlying VMs. The Java VM is quite complex and also quite powerful. For simple programs that don't require high performance or efficient memory management or whatnot that might not matter much though.

[Now, after having written this, I don't think its possible that any of the three languages is strictly simpler than any of the other ones.]

Me too, great comment, thanks.

I understand your point. Ruby and Python both have dynamic behaviour which makes it difficult to predict ahead of time what will happen when a program is run. In practice, however, the full range of possibilities is never exercised. It's not enough to look only at the language specification when you make these generalizations.

EDIT: TL;DR, essentially what matters is not the complexity of the language, but the complexity of programs written in the language.

The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know.

But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons standards is still pretty clear.

The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to say that, that arrangement could turn all kinds of great ideas into disasters.

I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interoperable stacks.

But at least there was a real reason, and serious value for a lot of developers. To compare, JSON doesn't even have a standard date format defined.

Imagine doing SOAP entirely by hand, with a semi-complicated WSDL. It's a nightmare. Doing a RESTful service based on JSON data is not just not a nightmare, it's a breeze, with no need for any of the tooling you describe and with, in my opinion, absolutely no difference in API richness, interoperability, security, quality etc.