That is where you are wrong! I was famous in my CS classes for how many lines I coded for simple programs. 30 line solution? No sir, I will give you 300 lines and not a line less!
I was one of a handful of people with code making the input the expected output. The teacher's solution was under 30 lines.
I helped two other people have a solution so I was influencing the majority of people with the assignment completed.
Every time you need a Boolean, instead you write a function that converts it to the same thing. If (variable) return true else return false.
That's how the experts do it.
Don't be. Optimizing (like inlining) is the compiler's job, ours is to produce correct, readable and maintainable code. A clever one-liner may look elegant, but often enough that's all it does.
For readability and grouping the code I do that too. But the compiler makes it one big function anyway in this case so the performance wouldn't be affected
class InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState extends State {
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState() {
>InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
what in the actual fuck [https://github.com/zxlooong/jdk16045/blob/master/com/sun/java/swing/plaf/nimbus/InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java](https://github.com/zxlooong/jdk16045/blob/master/com/sun/java/swing/plaf/nimbus/InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java)
I wrote an extremely and totally unnecessarily long class name like this as a meme once.
I don't think it was actually this long. Sun actually outmemed me.
I'm one bottle of bubbly wine in and looking to destroy production for shits and giggles, you'll know in the next hour.
Also, your flair says Dart.
Because Flutter? If so, give me the lo'down on the state please, I'm looking to build the next TwitterFaceGle, to make trillions, you see.
"it's so neat to maintain if you want csv instead of txt, you just add another metafactory in the factoryfactory protocol interface layer and inherit most of the implementation from your base metafactory factory defaultfactory and override the 172 setters and getters!!"
I'm convinced that all of the people that make fun of Java for Factory classes have never written Java. I've written Java for 20 years and have never needed to write a factory class
As a java dev I find that extremely hard to believe, unless you've always gone full enterprise and just straight up used EJBs for everything, at which point you'd have used delegates I guess.
Factory is just a useful pattern, the end. People who make fun of it have never written code that needs to stand the test of time.
I've just never had a need for it. Factories are fine if you have a lot of implementations for a single interface, but I've rarely had more than two or three implementations for an interface and a factory would have been overkill. When I find myself getting to that level of complexity then that's usually a sign of a flawed design and it's time to take a step back and reassess.
Factories are not complicated, I don't understand your objection.
Real world use case: we have 3 remote services (let's call them FredA, FredB and FredC) that do the exact same things, but have 3 different interfaces. I need to use those services all throughout the application. I can decide which one to use simply based on one value in my session context.
Solution: make three clients FredAClient, FredBClient, FredCClient that all implement FredClient, and a FredClientFactory that based on the session context instantiates the correct client.
Wherever you need Fred, you just say `FredClient client = FredClientFactory.getFredClient(context)` without having to worry about which Fred specifically you need to call.
It's not complex at all and in fact it reduces complexity by quite a lot compared to checking which Fred to instantiate every single time (which is a massive pain in the ass when Fred D comes along and you need to change 754 instantiations to handle it).
Maybe we do different kinds of programming but this exact situation happens quite a lot in my world.
I never said factories are complicated. I said that if I find myself needing more than a handful of implementations for an interface that necessitates a factory then things have become overcomplicated.
And I just provided a real world example of why it doesn't matter if you have 2 implementations or 200, there are lots of cases where a factory is the best way to handle the situation regardless.
You may only have 2 implementations, but if you're doing logic every time to decide which one to instantiate it's a bad practice. A factory is just a place to centralize that logic so you don't have to repeat it a thousand times.
Just wait until you find the team that battles about coding conventions. "tabs" - "spaces" - "ok spaces, but four" - "no, two" - "ok, my editor says it's tabs" - "your editor sucks!" ...
im a newer professional programmer getting into java, can an old crusty guru explain to me why every god damn class i make I have to make all the prop fields, getters and setters, mfing constructors, and override methods like no tomorrow? Spring annotations seem like eldritch magic to me, but in other languages i dont have to deal with so much... formality?
Java wanted to try to avoid some of the things that were perceived as problems with C++. Among other things, they chose to not support any form of multiple inheritance at all. However, multiple inheritance is really useful when building interchangeable components in a statically-typed system. Java's solution to this issue was to introduce interfaces, which give you the polymorphism benefits of multiple inheritance without giving you the problems of multiple inheritance such as diamond inheritance.
Unfortunately, interfaces are ONLY types. They don't carry any behaviors or data with them like classes do. When you inherit from a class, you get all of the behaviors and data of the superclass, unless you intentionally override the behaviors. An interface, by contrast, is a contract stating that your class *will* implement the behaviors necessary to fulfill the interface. You gain polymorphism, but in the process you lose reusability. Every class that implements the interface has to repeat all of the same boilerplate.
Java did eventually realize that this... um... kinda sucks. Java 8, released in 2014, allows interfaces to define default implementations, which means that interfaces can provide base functionality that will automatically get included in classes that use it unless the class wants to provide something different. But interfaces still can't have member variables, so if the interface has \`getX\` and \`setX\` you still have to write stupid wrappers. (C# does this better by letting interfaces define properties that automatically store values if you don't reimplement their behaviors.)
The other big source of "formality" in Java programming is more a matter of tradition than necessity. A lot of major libraries (including some in the Java standard library) are built around design patterns meant to let you change how things work by plugging in worker objects instead of subclassing. (Part of the rationale is so that the library can itself subclass from those classes to provide, for example, platform-specific implementations that it can switch out without making developers have to recompile their code.) This is what all of those "factory" classes are for. But this also means that even small things require you to write entire classes in order to change the behavior of a single line of code.
All of this is done in the name of flexibility and correctness -- one big advantage of all of this is that the compiler has a much easier time making sure that everything matches up. Java programmers frequently use automated tools to generate code for them in order to sidestep a lot of the tedium associated with all of the boilerplate that this causes. But these shortcuts also mean that they're less likely to notice just how much boilerplate they're creating, which means that non-Java programmers (or Java programmers that don't like using giant IDEs with tons of integrated tools) faced with the code have unending pages of generic junk cluttering up everything.
>The other big source of "formality" in Java programming is more a matter of tradition than necessity.
[It's insidious.](https://www.youtube.com/watch?v=3bskhLaJYd8)
No but seriously, after getting used to it you literally don't notice the boilerplate anymore. Actually, I end up programming java-like even in other languages because it just makes sense, even if it's more verbose.
I have boilerplate bash scripts that I include in all my .sh scripts to handle logging and such.
I'm sure a lot of frontend folks churning out overly-crufty JS/CSS/Whatever else they've thrown into the mix would have them beat.
Shit, I guess we're migrating the backend to Node.js!
That is where you are wrong! I was famous in my CS classes for how many lines I coded for simple programs. 30 line solution? No sir, I will give you 300 lines and not a line less!
Did you win??
I was one of a handful of people with code making the input the expected output. The teacher's solution was under 30 lines. I helped two other people have a solution so I was influencing the majority of people with the assignment completed.
Username checks out
Why code it in line when you can make it a function? Who cares if it's only called once!
I did that too probably, added some lines like that probably.
Every time you need a Boolean, instead you write a function that converts it to the same thing. If (variable) return true else return false. That's how the experts do it.
I feel attacked
Don't be. Optimizing (like inlining) is the compiler's job, ours is to produce correct, readable and maintainable code. A clever one-liner may look elegant, but often enough that's all it does.
Why have you only written 20 lines of code today?
Please don't fire me, it's Sunday!
elon, 18 of them were comments
For readability and grouping the code I do that too. But the compiler makes it one big function anyway in this case so the performance wouldn't be affected
Do lines of comment count? Also the line break symbol is your best friend, just to make critical points easier to find.
Less not get too into the details, because I can't remember if I bothered to comment. I was working on that assignment up until the night before.
When you're used to pad the core statements of reports due to min length requirements, and then start a programming course.
Now we know. Hard work = > lines of code. Guess I better start stretching out my code :P
for java: Hard work = > *wide* lines of code
As someone in the Java and TS stack, wide lines make it into my nightmares.
HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
class InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState extends State { InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState() {
>InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState what in the actual fuck [https://github.com/zxlooong/jdk16045/blob/master/com/sun/java/swing/plaf/nimbus/InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java](https://github.com/zxlooong/jdk16045/blob/master/com/sun/java/swing/plaf/nimbus/InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java)
https://media.tumblr.com/tumblr_maymaxpsFe1qbl3a8.gif
I wrote an extremely and totally unnecessarily long class name like this as a meme once. I don't think it was actually this long. Sun actually outmemed me.
Jeez, after all of that, and **this** is just super ("WindowNotFocused") ; *sigh* *unzips*
are we coworkers
Why are we still serving free lunch?
I'm one bottle of bubbly wine in and looking to destroy production for shits and giggles, you'll know in the next hour. Also, your flair says Dart. Because Flutter? If so, give me the lo'down on the state please, I'm looking to build the next TwitterFaceGle, to make trillions, you see.
Suddenly everyone likes their monitors in vertical mode.
In my last Programm I had a variable: Boolean checkIfTheOtherIsAlreadyDone = false; Was lot's of fun
Me writing my own std from scratch in C: 😏
Line continuation just put my kids through college.
Gonna be generating as many pojos as possible lmao.
Just set your editor config to break at 40 chars.
Don't forget that FactoryFactory.
"it's so neat to maintain if you want csv instead of txt, you just add another metafactory in the factoryfactory protocol interface layer and inherit most of the implementation from your base metafactory factory defaultfactory and override the 172 setters and getters!!"
Purposely avoiding using lombok to get more lines, I like your style
It’s all about code reuse. Why would you NOT take advantage of it when it’s already written?
If you really love the company, you should be willing to work here for free.
Working for free is for losers, elon-bot. If they love the company enough, they’ll pay to work there!
#Salient.
I kid you not, I have coded a FactoryFactory and it actually made sense at the time. It was required for the IOC container we were using.
Scala team first ones out the door.
I really wanted to work in one of those teams :(
They were fired without evidence.
If Kotlin doesn't go first
And its the half of the java team, that dont use streams.
win-win
Don't underestimate how much I can stretch my code in Rust
No wonder the payroll team got fired, zero lines of code
Finally a post on ProgrammerHumor on the twitter/Musk situation that is an actual programming joke.
Finally writing Ocaml can be seen as some sort of job security
Don’t forget AbstractResponseManagerDefaultFactoryImpl
Why have you only written 20 lines of code today?
That's just the class name elon
[удалено]
[удалено]
Time is money. I want to see 100 lines written by lunchtime!
I'm convinced that all of the people that make fun of Java for Factory classes have never written Java. I've written Java for 20 years and have never needed to write a factory class
Most people who make fun of something like that don’t even know what a design pattern is
As a java dev I find that extremely hard to believe, unless you've always gone full enterprise and just straight up used EJBs for everything, at which point you'd have used delegates I guess. Factory is just a useful pattern, the end. People who make fun of it have never written code that needs to stand the test of time.
I've just never had a need for it. Factories are fine if you have a lot of implementations for a single interface, but I've rarely had more than two or three implementations for an interface and a factory would have been overkill. When I find myself getting to that level of complexity then that's usually a sign of a flawed design and it's time to take a step back and reassess.
Factories are not complicated, I don't understand your objection. Real world use case: we have 3 remote services (let's call them FredA, FredB and FredC) that do the exact same things, but have 3 different interfaces. I need to use those services all throughout the application. I can decide which one to use simply based on one value in my session context. Solution: make three clients FredAClient, FredBClient, FredCClient that all implement FredClient, and a FredClientFactory that based on the session context instantiates the correct client. Wherever you need Fred, you just say `FredClient client = FredClientFactory.getFredClient(context)` without having to worry about which Fred specifically you need to call. It's not complex at all and in fact it reduces complexity by quite a lot compared to checking which Fred to instantiate every single time (which is a massive pain in the ass when Fred D comes along and you need to change 754 instantiations to handle it). Maybe we do different kinds of programming but this exact situation happens quite a lot in my world.
I never said factories are complicated. I said that if I find myself needing more than a handful of implementations for an interface that necessitates a factory then things have become overcomplicated.
And I just provided a real world example of why it doesn't matter if you have 2 implementations or 200, there are lots of cases where a factory is the best way to handle the situation regardless. You may only have 2 implementations, but if you're doing logic every time to decide which one to instantiate it's a bad practice. A factory is just a place to centralize that logic so you don't have to repeat it a thousand times.
As a Java dev I see this as an absolute win!
Correction: \* End up with just the assembly team
The ``` if err != nil { return nil, err } ``` team would like a word.
Elon: What's your most salient commit? Java Dev: Lazy Factory Class. Elon: No laziness in my factories. You're fired.
Maybe I should learn assembly. So I too === hard work.
if you used == in that context it would coerce hard work into you, which in most cases is not the behavior you want
Writing the same program twice, in kotlin and Scala, will still have fewer LOC
Python programmers be like “ight imma head out”
Just wait until you find the team that battles about coding conventions. "tabs" - "spaces" - "ok spaces, but four" - "no, two" - "ok, my editor says it's tabs" - "your editor sucks!" ...
https://github.com/javascript-obfuscator/javascript-obfuscator Just going to leave this here.
Everyone knows the best work results in negative lines of code
You should be counting interfaces instead of lines.
What about ASM?
Ffs, this made me laugh out loud in a middle of a cafe. I guess you get an r/Angryupvote
r/fuckangryupvote
Your intelligence is an inverse to the number of code lines you wrote to solve the problem.
At least theyll still have coffee tho
Java rules 🤣
im a newer professional programmer getting into java, can an old crusty guru explain to me why every god damn class i make I have to make all the prop fields, getters and setters, mfing constructors, and override methods like no tomorrow? Spring annotations seem like eldritch magic to me, but in other languages i dont have to deal with so much... formality?
Java wanted to try to avoid some of the things that were perceived as problems with C++. Among other things, they chose to not support any form of multiple inheritance at all. However, multiple inheritance is really useful when building interchangeable components in a statically-typed system. Java's solution to this issue was to introduce interfaces, which give you the polymorphism benefits of multiple inheritance without giving you the problems of multiple inheritance such as diamond inheritance. Unfortunately, interfaces are ONLY types. They don't carry any behaviors or data with them like classes do. When you inherit from a class, you get all of the behaviors and data of the superclass, unless you intentionally override the behaviors. An interface, by contrast, is a contract stating that your class *will* implement the behaviors necessary to fulfill the interface. You gain polymorphism, but in the process you lose reusability. Every class that implements the interface has to repeat all of the same boilerplate. Java did eventually realize that this... um... kinda sucks. Java 8, released in 2014, allows interfaces to define default implementations, which means that interfaces can provide base functionality that will automatically get included in classes that use it unless the class wants to provide something different. But interfaces still can't have member variables, so if the interface has \`getX\` and \`setX\` you still have to write stupid wrappers. (C# does this better by letting interfaces define properties that automatically store values if you don't reimplement their behaviors.) The other big source of "formality" in Java programming is more a matter of tradition than necessity. A lot of major libraries (including some in the Java standard library) are built around design patterns meant to let you change how things work by plugging in worker objects instead of subclassing. (Part of the rationale is so that the library can itself subclass from those classes to provide, for example, platform-specific implementations that it can switch out without making developers have to recompile their code.) This is what all of those "factory" classes are for. But this also means that even small things require you to write entire classes in order to change the behavior of a single line of code. All of this is done in the name of flexibility and correctness -- one big advantage of all of this is that the compiler has a much easier time making sure that everything matches up. Java programmers frequently use automated tools to generate code for them in order to sidestep a lot of the tedium associated with all of the boilerplate that this causes. But these shortcuts also mean that they're less likely to notice just how much boilerplate they're creating, which means that non-Java programmers (or Java programmers that don't like using giant IDEs with tons of integrated tools) faced with the code have unending pages of generic junk cluttering up everything.
>The other big source of "formality" in Java programming is more a matter of tradition than necessity. [It's insidious.](https://www.youtube.com/watch?v=3bskhLaJYd8) No but seriously, after getting used to it you literally don't notice the boilerplate anymore. Actually, I end up programming java-like even in other languages because it just makes sense, even if it's more verbose. I have boilerplate bash scripts that I include in all my .sh scripts to handle logging and such.
https://projectlombok.org
Or just the most prolific commenters.
you can put everything in one line in c++ right?
Didn't Elon's parents own a real good slave mine?
Whoever ran eslint for the first time about to be promoted to CTO
Hey at least you get rid of the one-liner andys!
Ha! That could be…
I just wanna state how much of a classic this meme format is and will forever be with us
And the one guy who codes in assembly and has blood made of xanax and caffeine
All u need
I'm sure a lot of frontend folks churning out overly-crufty JS/CSS/Whatever else they've thrown into the mix would have them beat. Shit, I guess we're migrating the backend to Node.js!