Java

Oh god the memes are real!
github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/ArrayUtil.java

Other urls found in this thread:

docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
en.m.wikipedia.org/wiki/Groovy_(programming_language)
eecs.yorku.ca/course_archive/2006-07/F/3311/tuplesAdvanced.pdf
twitter.com/NSFWRedditGif

WEEEEEEEEEEEEEEEEEEEEEEEW

They seem to know that this is shit code, but it works for some reason to them. Seems to save instructions, but maybe they shouldn't be doing shit on Java if they wished to save instructions in the first place.

it is like Holla Forums has never done any optimizations................

...

Jesus christ it's like looking at the fibonacci sequence.

If your langage needs that to optimize, there's a problem, retard.

It's like C++ templates in the bad old days. What the fuck is Java's excuse for that?

I'm no expert, but why couldn't they write a function, oh I mean a METHOD, to just iterate X times and add argX+1 each time? This seems so fucking counter productive.

Holla Forums cant read comments the thread

I'm no expert, but why couldn't you just read the documentation?????????????????????????????????

If I could understand why it wouldn't be possible from reading the documentation, I wouldn't have had to ask. I don't understand why reducing the bytecode to 4 instructions instead of the previous 15 necessarily optimizes it, nor do I understand how a class that contains over 1000 lines for creating an ever expanding null array 249 times, helps optimize it.

the documentation very clearly explains what is going on:
/**
* This is a generated class used internally during the writing of bytecode within the CallSiteWriter logic.
* This is not a class exposed to users, as is the case with almost all classes in the org.codehaus.groovy packages.
*
* The purpose is the reduction of the size of the bytecode. Consider creating a three element Object[] with null values:
*
* ANEWARRAY java/lang/Object
* DUP
* ICONST_0
* ACONST_NULL
* AASTORE
* DUP
* ICONST_1
* ACONST_NULL
* AASTORE
* DUP
* ICONST_2
* ACONST_NULL
* AASTORE
*
* with ArrayUtils you can have it like this:
*
* ACONST_NULL
* ACONST_NULL
* ACONST_NULL
* INVOKESTATIC ArrayUtils.createArray(Object,Object,Object)
*
* The number of needed instructions is thus reduced from 15 to 4. For every entry we save 3 bytecode instructions.
* This allows better readable bytecode and it allows the JIT to see less bytecode to optimize, helping under the
* inlining threshold here or there.
*
* So even though the class is ugly, there are good reason to have this in Groovy, even if the class makes
* absolutely no sense in normal Java. But it is not used in normal Java, but from the bytecode.
*/

And this is why you shouldn't use java.

READING IT AGAIN ISN'T HELPING.

docs.spring.io/spring/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

I wonder if Java programs would actually be faster than C had this level of faggotry never become the language's culture.

No. Because they are still using C to translate to assembly code and compiling java via C. The whole point of java was a abstraction of C so that it could run on anything java was ported to. Which failed.

Even if the code itself makes sense, having it committed doesn`t.

Java uses portable bytecode and garbage collection. Those are not bad design decisions, but they do mean that it can never be as fast as C. It's a tradeoff.

This.
Autogenerated code is fine but don't commit it.

It's acceptable, as long as the generation is completely deterministic.
Inlcuding the generated code also means that people can compile it without executing arbitrary code, which is polite.

LOL

your brain on OOP

lol all this for an array of nulls

which is exactly why oracle continues to celebrate widespread java adoption and honestly believes java is still the future

No, it's a disgusting webdev practice that should never be done. Version control is not a cache.
What else would be polite, including the binary in the repo to save them compile time? No, it's stupid. You create massive version control churn doing this and there is absolutely zero value to any of those commits to someone having to go through the history.

Any good resources for someone learning java, or object oriented languages in general? I'm taking it in uni atm, and coming from C and Lisp it's a bit of a jump.

find the dirtiest toilet you can, stick your head all the way in, and start flushing until it's clean again. go ahead and lick off any bits that won't come out to show your dedication.

...

It's not for Java, it's for the Groovy language.

en.m.wikipedia.org/wiki/Groovy_(programming_language)

...

Check out Eiffel. It's a statically typed "pure OO" language meaning everything is an object. The Eiffel solution to this problem is tuples.

eecs.yorku.ca/course_archive/2006-07/F/3311/tuplesAdvanced.pdf

It's readable, but i can't believe it can't be simpler.

People will defend this.

...

LOL!

Except when it can
(if you do pure number crunching while avoiding any memory allocation — that means using only primitive types unfortunately — the speed will be almost the same as in C, this has been tested a lot of times)

yeah that's a good point

Generated source is still the source, and if generating it requires extra software then it's unnecessary load on those who only wanted to change the parts which do not affect the code generation. Typical example is Google Protobuf, especially if the protocol definition changes rarely — there is no point in requiring everyone to re-translate them every time.

You don't understand how increasing speed by reducing the amount of instructions need to be executed is an optimization?
Jesus fucking Christ, I knew Holla Forums was incompetent, but this is fucking pathetic.

You are retarded. That's like saying that assembly can't be faster than C if your assembler is written in C. The language of your JIT compiler doesn't affect the speed of your program, because by the time your program is executing, the JIT compiler isn't even being used anymore.

Brainlet stfu. C is a abstraction of assembly. Java is a abstraction of C.
That depends on your compiler and linker. Of which java has none. Hence precompiled bytecode. Hence it can never be faster then the assembly instructions that C generates for it. Fuck off.

Let's pretend you could even write your own compiler, linker, and assembler. The assembly you use for your general C library is going to be the assembly used in all future compiled versions of that compiler on that arcitecture. This is because you never introduced new or better assembly instructions into it. So if you compile your compiler using the same compiler then it always uses the same assembly. But if you compile your first compiler with a new compiler, like say gcc to compile clang, then the assembly output will be different then if you had compiled gcc with gcc.

TLDR;stfu brainlet.

ITT: C weenies who always get their mouth full of "muh optimization" and don't realize this is pretty much the Java equivalent of loop unrolling.

What is JIT optimization

No, it isn't, it's an intermediate state. That would be like saying that assembly code generated by a C compiler is also source code.

The real issue is people using IDEs. IDEs tie your hands and make you stupid. If the project was managed using a CLI tool like Make this would be a non-issue and one could just set up a step in the build process to generate the Java source file. I used to be an IDE users myself, and I would not want to go back there.

Almost everything about this is bullshit.
CLI tools can be inflexible and GUI tools can be flexible, those things are weakly correlated but they don't require each other.
This project uses Gradle, which does in fact have a command line interface.
This project's gradle build scripts are hand-written, and even commented.
If I'm reading it correctly (my Java experience is small because I avoid it as much as I can, and my Gradle experience is non-existent) the generated files are generated while building, unless they don't need to because the generation script hasn't changed.
Gradle can execute arbitrary commands if you ask it to, just like make.

...

...

LOL

It's also possible those 4 instructions take more cycles than the 15. I'm not saying he isn't a dumbass but instructions do not take the same time to execute.

CLI-tools are operated in text, and so you can write any arbitrary text and stick it together. You can write text which generates text for you. Show me an IDE where you can click the GUI to make clicks for you. Of course retarded CLI tools can exist, but GUI tools are awful for automation by default. GUIs are good for grandma to send an email or look up cookie recipes, but when I see a software professional using a GUI for work it's like seeing a construction worker trying to work with Fisher Price toys.


That's good, but then why is the generated code in the repository? That's like doubly retarded.

IDEs aren't the problem. I do gamedev and we add functionality to the IDE so things like generating the sound files for fmod is done as part of the build. This is just sloppy work from a bad programmer. Never commit files that have another "source" to "source" control.

That's a decent library and I've used that particular class to write more succinct Java code.

There are far better languages running on the JVM, my favorite being Kotlin, but if you're stuck using plain ol' Java on a job contract, these convenience classes are incredibly handy.

Oops that's a Groovy library. At first glance I thought it was the Guava or Apache Commons utils for Java Collections. Pretty much the same thing though.

Gui's are also good for people that don't know how to touch type. I'm finally learning to touch type at 31 and already find myself preferring keyboard shortcuts much more than I used to.

The girl on the left has a huge boner

You ever try to automate a CLI tool on windows?

Well, that's your problem right there.


Same here, since I can remember I had to stare at the keyboard while typing, then look up and fix typos before getting back to the keyboard. I eventually learned to touch-type when I had to learn Vim, and how I can touch-type without problems. It has made me so much more efficient, I can now type with my eyes closed and I'll still feel it in my fingers when I make a typo.

eh it's still a command line interface

Not all command lines are created equal. Not even close.

lel I could touch-type when I was 5 years old back in.... 1998.

...

This. Never underestimate hardware optimizatino magic of modern processors.

Yeah they had touch typing in computer class in first grade. I hunted and pecked off like a dumbass. Blow me

Such over engineered garbarge. I suppressed those memories and found solace in Scheme... and now you have brought it all back. Just for that, I'm going to curse you with this evil word struts.

but assembly doesnt have ub.
really makes my thought noggins jogging...

In x86 assembly there is a massive amount of undefined behavior.

What are undocumented instructions...?

Pretty much anything related to cache races is undefined on all ISAs I know. Defining any of that would prevent improving the hardware.

no


that's not ub though