▶ No.802037
>>802035 (OP)
WEEEEEEEEEEEEEEEEEEEEEEEW
▶ No.802047>>802386
>>802035 (OP)
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.
▶ No.802055>>802137
>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.
>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.
it is like /tech/ has never done any optimizations................
▶ No.802132
Jesus christ it's like looking at the fibonacci sequence.
▶ No.802137
>>802055
If your langage needs that to optimize, there's a problem, retard.
▶ No.802148>>802155
>having to manually expand argument lists
It's like C++ templates in the bad old days. What the fuck is Java's excuse for that?
▶ No.802155>>802158
>>802148
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.
▶ No.802157
/tech/ cant read comments the thread
>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.
▶ No.802158>>802163
>>802155
I'm no expert, but why couldn't you just read the documentation?????????????????????????????????
▶ No.802163>>802166 >>802464
>>802158
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.
▶ No.802166>>802172
>>802163
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.
* <p>
* The purpose is the reduction of the size of the bytecode. Consider creating a three element Object[] with null values:
* <pre>
* ANEWARRAY java/lang/Object
* DUP
* ICONST_0
* ACONST_NULL
* AASTORE
* DUP
* ICONST_1
* ACONST_NULL
* AASTORE
* DUP
* ICONST_2
* ACONST_NULL
* AASTORE
* </pre>
* with ArrayUtils you can have it like this:
* <pre>
* ACONST_NULL
* ACONST_NULL
* ACONST_NULL
* INVOKESTATIC ArrayUtils.createArray(Object,Object,Object)
* </pre>
* 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.
* <p>
* 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.
*/
▶ No.802172
>>802166
And this is why you shouldn't use java.
▶ No.802180
READING IT AGAIN ISN'T HELPING.
▶ No.802186>>802226 >>802237
>>802181
I wonder if Java programs would actually be faster than C had this level of faggotry never become the language's culture.
▶ No.802226>>802252 >>802466
>>802186
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.
▶ No.802235>>802239 >>802242
>committing auto generated code
Even if the code itself makes sense, having it committed doesn`t.
▶ No.802237>>802456
>>802186
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.
▶ No.802239
>>802235
This.
Autogenerated code is fine but don't commit it.
▶ No.802242>>802275 >>802456
>>802235
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.
▶ No.802250
>a three element Object[] with null values
your brain on OOP
>ACONST_NULL
lol all this for an array of nulls
▶ No.802252
>>802226
which is exactly why oracle continues to celebrate widespread java adoption and honestly believes java is still the future
▶ No.802275>>802456
>>802242
>It's acceptable, as long as the generation is completely deterministic.
No, it's a disgusting webdev practice that should never be done. Version control is not a cache.
>Inlcuding the generated code also means that people can compile it without executing arbitrary code, which is polite.
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.
▶ No.802342>>802349 >>802410
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.
▶ No.802349>>802379
>>802342
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.
▶ No.802379>>802441
>>802349
<xd i posted the pajeet mem do i fit in now guys
>>>/r/programming
▶ No.802386
▶ No.802410
>>802342
Check out Eiffel. It's a statically typed "pure OO" language meaning everything is an object. The Eiffel solution to this problem is tuples.
http://www.eecs.yorku.ca/course_archive/2006-07/F/3311/tuplesAdvanced.pdf
▶ No.802430
>>802035 (OP)
It's readable, but i can't believe it can't be simpler.
▶ No.802439
>>802398
People will defend this.
▶ No.802441>>802452
>>802379
>>>/designatedshittingstreet/
▶ No.802452>>802772
>>802441
>i posted it again xD
LOL!
▶ No.802456>>802755
>>802237
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)
>>802242
yeah that's a good point
>>802275
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.
▶ No.802464>>804103
>>802163
>I don't understand why reducing the bytecode to 4 instructions instead of the previous 15 necessarily optimizes it
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 /tech/ was incompetent, but this is fucking pathetic.
▶ No.802466>>802470
>>802226
>Because they are still using C to translate to assembly code and compiling java via C
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.
▶ No.802470>>802475 >>805669
>>802466
Brainlet stfu. C is a abstraction of assembly. Java is a abstraction of C.
>That's like saying that assembly can't be faster than C if your assembler is written in 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.
▶ No.802474
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.
▶ No.802475>>802767
>>802470
>Hence it can never be faster then the assembly instructions that C generates for it.
What is JIT optimization
▶ No.802755>>802759
>>802456
>Generated source is still the source
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.
▶ No.802759>>804145
>>802755
>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.
▶ No.802767
>>802475
>implying you need java for jit
▶ No.802772
▶ No.804103>>805440
>>802464
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.
▶ No.804145>>804399 >>804410
>>802759
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.
>>802759
>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
That's good, but then why is the generated code in the repository? That's like doubly retarded.
▶ No.804149
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.
▶ No.804395>>804396
>>802035 (OP)
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.
▶ No.804396
>>804395
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.
▶ No.804399>>804422 >>805433 >>805444
>>804145
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.
▶ No.804400
>>804100
The girl on the left has a huge boner
▶ No.804410>>804422
>>804145
You ever try to automate a CLI tool on windows?
▶ No.804422>>804426
>>804410
>You ever try to automate a CLI tool on windows?
>windows
Well, that's your problem right there.
>>804399
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.
▶ No.804426>>804433
>>804422
eh it's still a command line interface
▶ No.804433
>>804426
Not all command lines are created equal. Not even close.
▶ No.805433
>>804399
lel I could touch-type when I was 5 years old back in.... 1998.
▶ No.805435
>me the touch typist since 1998 when I was 5 years old
>tfw don't even have to look at monitor or can have eyes closed and still know when I pressed a wrong key
>tfw also can trance-type, like when a medium writes with a pen, but in my case I'm channeling some shit that types through me
▶ No.805440
>>804103
This. Never underestimate hardware optimizatino magic of modern processors.
▶ No.805444
>>804399
Yeah they had touch typing in computer class in first grade. I hunted and pecked off like a dumbass. Blow me
▶ No.805606
>>802181
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.
▶ No.805669>>805673 >>805674
>>802470
>c is an abstraction of assembly
but assembly doesnt have ub.
really makes my thought noggins jogging...
▶ No.805673>>805794
>>805669
In x86 assembly there is a massive amount of undefined behavior.
▶ No.805674>>805794
>>805669
What are undocumented instructions...?
▶ No.805693
Pretty much anything related to cache races is undefined on all ISAs I know. Defining any of that would prevent improving the hardware.
▶ No.805794
>>805673
no
>>805674
that's not ub though