Passing by value SUCKS!

Thank you for making a small change huge, java.

Proof?
Asking because you're wrong

@iiii proof of what?

@iiii in java object variables hold the reference, therefore even when passing object variables, it’s not passing the reference. It’s passing the value of the variable which just happens to be the value of the reference.
Java never passes by reference though.

@just8littleBit proof that passing by value sucks.

yeah, great)

@iiii I don’t understand how less control can be a good thing..
the more control the engineer has the more flexibility he has so in my opinion less control is a bad thing.

@just8littleBit then we should re-implement GOTO statements?

Having less control (while counter intuitively) can be good. It forces you to stay closer to a functional approach, which is proved to prevent many fuckups!

I've seen way too many unintentional bugs caused due to passing by reference... I can't agree having it is a good thing.

(If you *really* want that behaviour, then you can still get it; just wrap it in an array with a single element, and pass the array around. *Extremely* limited cases aside, it wouldn't pass code review anywhere I know of however.)

@just8littleBit how passing by value results in less control? So far you're just telling some unrelated things.

@AlmondSauce if one works with a language which uses references by default, they should know that they are working with references, otherwise this should raise questions about their competency, unless they are green juniors.

@iiii Sure - it's more the unintentional side effects that can appear way more easily if you're making heavy use of passing by reference. They can be quite subtle and difficult to track down in some cases, even for experienced guys - if that reference is passed around all over the place, the number of places a potential unwanted side effect can occur is huge.

But yes, the "whoops I didn't mean to pass by reference" bugs aren't ones I'd expect a senior to make.

@AlmondSauce what is that language where you can unintentionally pass by reference? 🤔

@iiii Unintentional side effects, not unintentionally passing. It's always clear that I'm passing by reference, but much less clear what the function I'm passing it to actually *does* with that reference, including passing it anywhere else.

Sorry but although many of you will hate me for this, if you’re a competent engineer you know what to use and what not to use.
Be it GOTOs or whatever, I don’t give a shit. If you’re a competent engineer you don’t use stuff you don’t understand. Period. That doesn’t mean that everything that’s not used by the majority is bad.

References are not bad just because most people are not used to dealing with them.

Pointers are the most genius invention in languages but people say don’t use them and only 10% of devs understands them nowadays.

I’m my opinion yes, even GOTO should still be there. It would be so easy to know who to fire.
Goto was replaced, not sacked.

So many (or even most) mainstream Langs are based in C, why take the power out it if.. that’s my point.

Java? Fine. Take away pointers and shit? Well, hide it. But in MY opinion don’t stop supporting it.

Passing by reference is something to be avoided most of the time.
It breaks the boundary between two otherwise well-separated scopes and lures coders into writing impure code whithout need.
Always go for immutability by default to get easily testable code with as few side effects as actually needed.

@Oktokolo generally I agree, but I think that the support should still be there.
There is cases where it’s handy. May be once in a year or once in a decade, but the edge cases still exist.

@just8littleBit
Yes, supporting it is nice-to-have for the very rare edge case.
Almost every time that edge cases are performance-related and i would them rather like to make the compiler better at optimizing copies away though...

@just8littleBit that's where C# shines. It still has all those tricks if you want them

@Oktokolo reference can be constant. If someone writes shitty code, does not mean that the tool is bad

@just8littleBit Understanding it isn't the issue. I could take the time to read through everywhere that reference is passed to, look at all that code, make a note of the side effects, then understand what it did. The point is you've just made it way less readable, and way less clear, by passing references rather than values around. If you're hacking a solo project together that doesn't really matter so much, if you're coding in an enterprise setting where the code should be as readable as possible then it's a big issue.

This isn't just some Java oddity. Other, more modern languages have taken the same decision for the same reason - neither Go nor Kotlin has it, and those are just the two that come to mind right now.

Just because you understand a language feature doesn't mean you should use it.

@just8littleBit so a competent engineer never fuckups? Sorry but that's delusion speaking there. What about when it's late in the day? What about when you are crunching?

But most importantly, a competent engineer understands they have to work with all the spectrum of skills... Juniors and interns are a thing and they'll want to use the "special" tools to get knowledge with them and get senior ASAP.

References are not bad because "most people are not used to them", references are bad cause people who "know how to use them" will overuse it!
And on top of that being forced to not use them open up for memoization, which is kinda of a big deal...

@AlmondSauce references can be constant.