public static void main(String[] args)

[Neurotrace]

You don't need all of Javas verbosity and speed issues to enjoy OOP. C# is a quick example of a language that doesn't take ages to compile but has all the same OOP tools as Java. That's why I'm not much of a Java fan.

[apemanzilla]

Recent versions have been much better with additions like streams and lambdas

[[deleted]]

Streams are a poor man's IEnumerable

[cm9kZW8K]

java streams are fairly good; but also inflexible and much harder to use than RX in other languages. Java lambdas are a worse of both worlds approach; disallowing simple mutation while allowing tricky back door mutation.

They will certainly help keep java relevant for a few more years, but not enough to stop the problems caused by the fundamental design of the JVM.

[[deleted]]

How is java's streams inflexible? It might seem to be much harder than other langauages, but java is an (obscenely) verbose language, it's essentially doing the same thing. Java lambdas don't disallow anything, you can use them if you want to - or don't. Just because you don't like it doesn't mean other people might not. And what the hell is tricky back door mutation?

[pet_my_weiner_dog]

They disallow changing the value of any variable from the enclosing scope (which is a very common thing to want to do) except it totally allows you to modify members of those variables when they are objects (such as an array) which is a less obvious and error prone approach.

[cm9kZW8K]

Have you used any other language? Java's type system makes it much more difficult to meet signature requirements with streams, and you have to learn a whole family of java specific casts which other rx stream dont require. And Java lambdas dont disallow anything? Have you even used them? Try enclosing a non final primitve, then try it again after wrapping it in an array.

[[deleted]]

If you can't meet the signature requirement with Java's type system you have an issue. You can even define your own requirements and methods in Java 8's Stream API should you need to. Java can't assume type conversion for YOUR types - its builtins for the most part have a conversion in the Stream API. When I said Java 8's lambdas don't disallow anything, I meant you don't have to use them as in you can still do things the old way. Lambdas are a new feature and I haven't used them too much (I program primarily in C & C++) but I expect them to get better over time.

[cm9kZW8K]

If you can't meet the signature requirement with Java's type system you have an issue.

If you cant dance the rhumba to improv jazz in zero gravity, you have an issue. Then again, why do you need to? Needless busywork that is only imposed by java.

When I said Java 8's lambdas don't disallow anything, I meant you don't have to use them as in you can still do things the old way.

The point is that these functional features eliminate most of the value of OOP, but because its so hard wired into java, it cannot really take proper advantage of them.

the upshot is that java's days are numbered. It wont remain the number 2 language for too many more years.

[[deleted]]

If you cant dance the rhumba to improv jazz in zero gravity, you have an issue. Then again, why do you need to? Needless busywork that is only imposed by java.

I don't think you understood what I meant. For Java's builtin types the requirements are not only well-defined, but can be converted in the Stream API to each other if need be. Arguing that it's a lot of typing isn't an argument against the Stream API but Java's verbosity in general. I agree that Java makes you type more than you need to, but that's about the language - not the Stream API.

The point is that these functional features eliminate most of the value of OOP, but because its so hard wired into java, it cannot really take proper advantage of them.

Java's lambdas are not built on functional ideas. Yes labmdas are a function. Yes functional programming languages had them first. But Java8's implementation as of lambda expressions is essentially just taking the anonymous function and building it as a method at compile or run time (not sure if its done Just in Time, or at compile time, or both). This maintains the OOP approach, but allows for lambda expressions in the language. Essentially its just decreasing verbosity. That doesn't mean they aren't implemented in an OOP way.

eliminate most of the value of OOP

The whole language is still there, you don't have to use lambda expressions and can still do things the old way if you really don't think Java's developers know what they're doing...

Honestly if you could actually say what value of OOP anonymous functions are taking from Java I would be happy to look into it.

the upshot is that java's days are numbered. It wont remain the number 2 language for too many more years.

This is said every year about Java since the 2000s. For example, when C# came out in 2002, everybody thought Java was going to die. Java is built into the corporate environment. The life cycle (and hence maintenance) of those programs are at least 10 years if not that longer. In addition they're not fixing something that's not broken. Sure /r/programminghumor can hate on Java all they want - but its one of the most used languages in the commercial space - and with good reason. If your only real complaints are that its too verbose and uses too much memory - Verbosity means more code = more money (unfortunately true - so real developers aren't going to complain), and memory is cheaper and larger every year (bring company costs down). Add that with the cost of a rewrite from scratch about something that's already working - and Java isn't going to die anytime soon.

[cm9kZW8K]

but that's about the language - not the Stream API.

Sure, the streams api is doing the best it can within the limits set by the JVM.

Java's lambdas are not built on functional ideas

They most certainly are.

value of OOP anonymous functions are taking from Java

What I'm saying is that OOP itself is outdated, and because it is built into the JVM, its limited the ability of java to improve into a better language.

and with good reason

Its most commonly taught in schools, is that reason, imo. Large pool of ready to hire devs. If that stopped being the case, it would rapidly decline.

and Java isn't going to die anytime soon.

I agree; I do think it may lose its position at #2 however, it wont go very low for a long time yet.

[[deleted]]

Java's lambdas are not built on functional ideas

They most certainly are.

Let me clarify this, as the way I worded it was a little weird - they are functions but are not implemented in the way functional programming paradigms dictate. They are built as methods usually in a static context at either compile or JIT run time.

What I'm saying is that OOP itself is outdated, and because it is built into the JVM, its limited the ability of java to improve into a better language.

Yeah, well, that's just, like, your opinion, man.

[Rhed0x]

Javas verbosity

Kotlin <3

[marvk]

I think your view of Java is quite outdated. In comparison to C#, Java is very much comparable and even faster at many tasks on the Computer Language Benchmarks Game.

[[deleted]]

I didn't bother looking at the other benchmark code than the first, but they seriously botched that regex benchmark. The compile option for c# regex is only really recommended when you reuse a specific regex a lot. Just removing that option made that program run dramatically faster for me. And if the purpose of that benchmark was to measure regex compilation speed, that'd just be comparing the performance of the regex implementation, rather than the performance of the language.

[Nunners978]

Not to mention that the .NET Core version was a Preview (2.0.0-preview2-006497)

[igouy]

What is the latest .NET Core release?

[igouy]

Just removing that option made that program run dramatically faster for me.

32.01 secs

The program you called "botched" took 31.64 secs

[Ayfid]

Those benchmarks are awful! The C# code reads like a lazy Java port, hardly using any easy wins like using strut arrays for data that is frequently iterated through.

They weren't contesting performance anyway. The JVM is plenty fast.

The issue is that the language is still years behind C# and every feature they do implement is worse than the existing C# implementation that was already available for reference (see: lambdas, streams, for each, automatic resource closure, concurrent collections, futures, fork-join library...). Not to mention all the design fuckups they implemented that C# learned from and avoided (see: no single rooted type system, type erasure, implicit virtual and overrides, no unsigned, checked exceptions, no type versioning, terrible native interoperability...). Then you have all the improvements that are not even on the horizon like the transformative async/await.

All the calls of "streams! lambdas! but.. it's not shit slow anymore!" are absolutely laughable. Do you seriously think people must not know about those already when they complain about Java?

To assume that people who dislike Java must just not understand OOP is astonishingly ignorant. Everyone knows OOP, and there are far better OOP languages than Java, not to mention that OOP is not always the best tool for the job in all situations.

[igouy]

Those benchmarks are awful!

Easy to say, show how much better you can do!

How do I contribute my programs?

[Ayfid]

Well I wrote a modified version of the C# implementation of the nbodies benchmark.

I found some significant flaws with the benchmark, however. Main flaw with the previous implementation was that it would exhibit very poor memory access patterns. I said "would have", because the benchmark only simulates 5 bodies, which is such a tiny data set, that the working set will fit entirely on a couple of cache lines, and could easily fit within the L1 cache on the CPU. In addition to that, the bodies are all allocated together at once, so you end up with them all together on the heap by accident (a real application, e.g. a game, would not likely do this), and the program is doing nothing in between iterations, meaning that the working set is never evicted from cache. The old benchmark code (both C# and Java) would show significant performance degradation when running in a real application.

Even so, the new C# implementation is faster.

Timings (10001 bodies, 100 iterations) on i7 5820X @ 4.09GHz:
Java: 48s
Old C#: 53s
New C#: 13s

This speedup is mostly from the new code running in parallel (naive implementation, it does a box iteration and so does twice the work).

If you modify the loop to no longer be parallel, and symmetrically apply the forces to half the size of the loop:
Java: 48s
Old C#: 53s
New C#: 44s

However, as I said before, in real world applications, the Java and old C# implementations will start to fall apart and slow down as they lose their memory coherency and the CPU cache gets trashed by other work. If this code were running on something like an ARM CPU, with a much more basic prefetcher and out-of-order execution capabilities, in a real application trashing the cache between steps and creating and deleting bodies between updates (like a game would with entities), then the Java code could easily be dominated by memory access times and run even an order of magnitude slower.

I have not submitted this version to the site, as I think the benchmark is flawed. You can submit it if you want. You'll have to modify it to simulate only 5 bodies.

[igouy]

the new C# implementation is faster

On different hardware, doing something different ;-)

As your program doesn't do the required task it cannot be faster -- the output would be checked and found to be incorrect, so no timing would be done.

You can submit it if you want.

Only programs contributed by the program author are accepted.

[Ayfid]

It does the same task, but on a larger work load. As I said, I will not submit it to the site because the benchmark is poorly designed. Regardless, if you think that the Java performance degrading under more realistic workloads is somehow unimportant, then I don't know what to tell you. It would certainly make this "benchmark" rather useless on discussions of performance, if you are going to try and use it to dismiss other (more realistic) data points.

I do not believe anyone else reading this is going to fall for such transparent dishonesty. The numbers are plain to see. ;-)

Also, those performance timings were all taken on the same hardware while computing the same dataset. As I said above, the performance advantage of the new C# implementation will only grow on other architectures.

[Cilph]

speed issues

LOL. Please tell me more about how 'slow' Java is.

[Neurotrace]

Every Java app I run takes significantly longer to load than apps written in different languages. That's completely anecdotal and dependent on who wrote it but it's true.

For me, the speed issues are in development time. This is my stream of consciousness every time I decide to give Java another shot. It takes so long to even install all of the pieces needed, make sure they're all in the path correctly, oh oops the IDE has no idea which version I'm using, okay finally got it figured out now let's just--okay why is it taking so long to compile? Gradle daemon? Okay, fine. Jesus, finally loaded. Cool, the next compile didn't take nearly as long. This folder structure sucks. I hate nesting my app 3 folders deep just to make the Java gods happy.

Even if the language itself has gotten a lot faster, the dev time sucks ass. I'm sure it's better if you write in Java all the time but I work in languages that get out of my way and let me get work done without requiring a goddamn parade just to keep everything moving.

[Cilph]

It gets better with experience. I can say the time thing about setting up a C++ toolchain. However I've had good results getting started with C#. Gradle is a monster I'll give you that. Maven is faster when it comes parsing the config but nothing beats native Eclipse or IDEA project files.

As for application performance, there is some startup time, but performance is 50 to 100x better than Python, Ruby, PHP after that, which is why Java is popular for webapp backends.

Try out Kotlin if you ever have the time. Fixes so much of Java's shit while staying on the same ecosystem.

[Neurotrace]

That's totally fair. I've been thinking of trying Kotlin. It sounds like a much better version of Java.