I say that as a Java developer, btw.
And there's nothing wrong with that, but if you want to build systems that have to be maintained over multiple years, you somehow have to compensate for that. Java is one compensation.
That doesn't say much. So yes, most developers are average, but what is average? Is it necessarily developers who need training wheels, helmets and elbow pads in order to protect themselves and others?
That may be the reality, for all I know. But that isn't necessarily a timeless truth. Take a room of expert programmers; now most of them are mediocre (average), relative to each other (imagine a really big room with a lot of experts, if you must). But that doesn't necessarily mean that they need languages that cramp their style in order to mitigate whatever damage they might do.
"Mediocre" is the same as "average", but with more negative connotations. Hence, when someone says that some people are 'mediocre', the immediate thought might be "bad". Then it becomes obvious that tools need to hinder these bad developers from screwing up too much. But mediocre is just a relative term, and can mean that they are really bad developers who create 100 bugs for every feature they implement, or that they are really competent, reliable developers.
I won't comment on the skill of the average (mediocre) developer. But I think that saying "most are mediocre" can easily hint at "most are bad" (because of connotations, not necessarily because that was the intent).
There certainly are huge variations in baseline skill depending on location and line of business.
I was thinking of the more or less generic enterprise software environment in firms whose main business is not software development, and which reside outside silicon valley or other tech hubs.
Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past.
Performance -- poor, regarding memory consumption.
Indeed, the sweet spot.
> If you need lots of cheap developers [...]
Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's the same hard finding decent Java programmers as it is with Haskell, except that Java scares good devs away and Haskell attracts them.
Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot.
Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past.
Bollocks. I challenge you to provide an example of a Java developer being sued for using the language.
Performance -- poor, regarding memory consumption.
Bollocks. Uses more memory than C, but no manual management. Sweet spot.
Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent.
Bollocks. 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 to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.
As an example, I once worked on a Mac GUI app for a company - bog-standard, nothing fancy. I took over from a developer who had been trying to build this using Racket; this involved building a Qt-Racket interface, which involved magical automated parsing of C++ header files, which meant… basically, not delivering a product. Meanwhile, the Objective C build was done.
The point is, there's far too much focus and snobbery about what tools developers use. There are loads of languages out there; pick one that has a reasonable amount of support and fits the problem domain, and build simple, maintainable code. You can do that in any language.
> 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".
Of memory. Any other resource, you've basically got C with UNWIND-PROTECT and a cheap Schrödingerian knock-off of destructors.
Do you have actual examples of companies using Java for their run-of-the mill software that have been hit with lawsuits from Sun/Oracle? The only two I can remember are Sun vs Microsoft (because of proprietary extentions) and Oracle vs Google (complex licensing issues). Sounds like FUD to me.