[fleitz]

I'm not talking about how many features the language has, I'm talking about the endless amount of line noise that you need to accomplish simple tasks.

Most of what the code does is hidden behind ceremony.

Imagine Newtown writing out instructions on how to calculate gravity instead of just writing: F = G((m1 m2)/(r^2))

I really don't understand how a language that can't succinctly express calculus from 300 years ago would be regarded as suitable for complex code.

[bdamm]

Languages like Matlab are best suited for expressing calculus. Why are you choosing a poor tool for the job?

Most Java programmers don't care about expressing calculus. They care about expressing interactions between web services, sql, and applying rules as the data flows through their modules. Or between user interface elements and service requests. It's all about moving data around, working on that data when you've got it, and triggering actions.

[fleitz]

The problems of pushing bits from one server to another aren't that complicated and the pomp and circumstance of java gets in the way of actually accomplishing those things.

As you point out when you have a reasonably complicated problem like applying functions java fails miserably and other languages are a much better choice.

[cgh]

No offence, but it's clear you have no idea about the domains in which server-side Java is typically used. Very large enterprises have all kinds of weirdness and the Java ecosystem has a bunch of libraries found in no other language ecosystem that make things manageable. Java-the-language is sadly verbose and tedious but that's not why people choose it.

So server-side Java lives in a niche and I would never suggest it for, say, anything client-side or basic web apps.

[tracker1]

I'd say that NodeJS or Ruby would be decent alternatives depending on your need. npm and gem are really nice in this space and cover just about any need you might have without weighing your system down in pomp and circumstance.

The runtimes aren't that much slower, and for I/O bound tasks, odds are Node is going to run just as fast with less application complexity.

[bdamm]

Actually, part of the problem is the academic experience of believing that applying functions is hard and pushing bits is simple. It deceives delusional academics like yourself into believing it's just a matter of doing the work and not really a real computation problem at all.

No, in the real world, it's exactly the opposite. Nobody cares about writing a function because generally that's the simple part. Do it however you want. Deploying the system to take inputs and feed outputs, now that's the hard part. Where do those inputs come from? In what form? Are there security requirements to gather or push data? Do you store-and-forward or don't you? What protocol? Stateful or not stateful? Transactional or not transactional? The problems involved in "move these bits in this format on this machine to those bits in that form on that machine over there" are in fact so complex that you can't even prove it to be an NP-complete problem because the problem itself transcends algorithmic analysis. It is much more a social problem than a technical problem, but the social problem is so massive that any simple-minded technical approach will fail to address the scope of the issue and in every case I've ever seen, simply makes the problem worse.

[bradhe]

The "ceremony" you're talking about has nothing to do with the language itself and everything to do with the community. You can write Java and not use the factory pattern, you know.

Hell, Scala is one INSANELY complicated language. It's got about every feature under the sun. Java is simple and to the point...unless you really want to use spring or something of the sort.

Anyway, you've got a really contorted view of Java, and you are conflating some fundamental things.

[kamaal]

Community is a big part of the language. Else we would be writing in our self invented languages. You can write Java like anything you want, but that will make you an alien in a big world. Code reviewers won't accept your code for being the odd-one-out.

And its not about complexity or features in a tool, its about how those features interplay with the base design of the tool.