Learn kotlin, it’s awesome and runs on literally everything.

deleted by creator

You’ve obviously never been in the military, because it’s definitely “females”.

In French, the literal translation of female and male, are only used for animals in the common language, but I have been taught that in English it is ok to use those for humans in common language. Is it not the case in your region?

You need to me careful about benchmarking to find performance problems after the fact. You can get stuck in a local maxima where there is no particular cost center buts it’s all just slow.

If performance specifically is a goal there should probably at least be a theory of how it will be achieved and then that can be refined with benchmarks and profiling.

Writing the code in a natural and readable way should be number one.

I mean, even there it depends what you’re doing. A small matrix multiplication library should be fast even if it makes the code uglier. For most coders you’re right, though.

In my experience we all go through a stage at the Designed-Developer level of, having discovered things like Design Patterns, overengineering the design of the software to the point of making it near unmaintainable (for others or for ourselves 6 months down the line).

The next stage is to discover the joys of KISS and, like you described, refraining from premature optimization.

I think a lot of academic oop adds inheritance for the heck of it. Like they’re more interested in creating a tree of life for programming than they are in creating a maintainable understandable program.

deleted by creator

That’s the problem, a lot of CS professors never worked in the industry or did anything outside academia so they never learned those lessons…or the last time they did work was back in the 90s lol.

Doesn’t help that most universities don’t seem to offer “software engineering” degrees and so everyone takes “computer science” even if they don’t want to be a computer scientist.

Atomic instructions are quite slow and if they run a lot… Rust has two types of reference counted pointer for that reason. One that has atomic reference counting for multithreaded code and one non-atomic for single threaded. Reference counting is usually overkill in the first place and can be a sign that your code doesn’t have proper ownership.

This may be an unpopular opinion, but I like some of the ideas behind functional programming.

An excellent example would be where you have a stream of data that you need to process. With streams, filters, maps, and (to a lesser extent) reduction functions, you’re encouraged to write maintainable code. As long as everything isn’t horribly coupled and lambdas are replaced with named functions, you end up with a nicely readable pipeline that describes what happens at each stage. Having a bunch of smaller functions is great for unit testing, too!

But in Java… yeah, no. Java, the JVM and Java bytecode is not optimized for that style of programming.

As far as the language itself goes, the lack of suffix functions hurts readability. If we have code to do some specific, common operation over streams, we’re stuck with nesting. For instance,

var result = sortAndSumEveryNthValue(2, 
                 data.stream()
                     .map(parseData)
                     .filter(ParsedData::isValid)
                     .map(ParsedData::getValue)
                )
                .map(value -> value / 2)
                ...

That would be much easier to read at a glance if we had a pipeline operator or something like Kotlin extension functions.

var result = data.stream()
                .map(parseData)
                .filter(ParsedData::isValid)
                .map(ParsedData::getValue)
                .sortAndSumEveryNthValue(2) // suffix form
                .map(value -> value / 2)
                ...

Even JavaScript added a pipeline operator to solve this kind of nesting problem.

And then we have the issues caused by the implementation of the language. Everything except primitives are an object, and only objects can be passed into generic functions.

Lambda functions? Short-lived instances of anonymous classes that implement some interface.

Generics over a primitive type (e.g. HashMap<Integer, String>)? Short-lived boxed primitives that automatically desugar to the primitive type.

If I wanted my functional code to be as fast as writing everything in an imperative style, I would have to trust that the JIT performs appropriate optimizations. Unfortunately, I don’t. There’s a lot that needs to be optimized:

• Inlining lambdas and small functions.
• Recognizing boxed primitives and replacing them with raw primitives.
• Escape analysis and avoiding heap memory allocations for temporary objects.
• Avoiding unnecessary copying by constructing object fields in-place.
• Converting the stream to a loop.

I’m sure some of those are implemented, but as far as benchmarks have shown, Streams are still slower in Java 17. That’s not to say that Java’s functional programming APIs should be avoided at all costs—that’s premature optimization. But in hot loops or places where performance is critical, they are not the optimal choice.

Outside of Java but still within the JVM ecosystem, Kotlin actually has the capability to inline functions passed to higher-order functions at compile time.

/rant