>> Simplicity -- none, if talking about the resulting code.
> Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot.
But Java is close. Compare its standard library with virtually anything else
on the market. Nobody has dozen ways of reading a file, and in Java they can't
be reduced to a one or two (buffered vs. unbuffered), because they're used in
many places in the library.
> Bollocks. Uses more memory than C, but no manual management. Sweet spot.
Every other runtime has smaller memory requirements. No other runtime requires
several hundreds megabytes of RAM to do anything non-trivial. Totally not the
sweet spot.
>> Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent.
> In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution [...]
...which is generally a good thing, you just need to remind them they need to
ship the product. They need different approach than mediocre programmers. With
the latter ones you need to focus on preserving acceptable quality, with the
former you need to focus on getting things done.
> [...] solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.
Standard library in Java is hardly extensive. It only contains several typical
containers, some networking (raw, HTTP, SOAP and Java's dedicated RPC),
a little cryptography, XML parser, regexes and GUI toolkit. Oh, and routines
for Zip files. It doesn't even have SMTP library built in. It doesn't have
HTTP crawler library, like WWW::Mechanize. No XML-RPC or REST library. No
built-in support for parsers. No indexed storage, like BerkeleyDB or
TokioCabinet.
> Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot.
But Java is close. Compare its standard library with virtually anything else on the market. Nobody has dozen ways of reading a file, and in Java they can't be reduced to a one or two (buffered vs. unbuffered), because they're used in many places in the library.
>> Performance -- poor, regarding memory consumption.
> Bollocks. Uses more memory than C, but no manual management. Sweet spot.
Every other runtime has smaller memory requirements. No other runtime requires several hundreds megabytes of RAM to do anything non-trivial. Totally not the sweet spot.
>> Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent.
> In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution [...]
...which is generally a good thing, you just need to remind them they need to ship the product. They need different approach than mediocre programmers. With the latter ones you need to focus on preserving acceptable quality, with the former you need to focus on getting things done.
> [...] solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.
Standard library in Java is hardly extensive. It only contains several typical containers, some networking (raw, HTTP, SOAP and Java's dedicated RPC), a little cryptography, XML parser, regexes and GUI toolkit. Oh, and routines for Zip files. It doesn't even have SMTP library built in. It doesn't have HTTP crawler library, like WWW::Mechanize. No XML-RPC or REST library. No built-in support for parsers. No indexed storage, like BerkeleyDB or TokioCabinet.
It's hardly "extensive".