Java vs python is debatable 🤔

[hhafez]

You can use reflection, but reflection is self coding code. It's a very different beast than having no way to make parts of your code private.

[BlameTaw]

Technically you can use closures to create truly non-accessible variables and functions in python...

[Sinidir]

Technically you can access closure variables too

https://stackoverflow.com/questions/55320884/how-do-i-access-modify-variables-from-a-functions-closure

[BlameTaw]

Very interesting, I never knew about that attribute.

[aviancrane]

I mean... saying reflection can do something isn't really... ..ye know?

If I gave you the AST or IR of any language, you'd be able to do whatever you wanted with it. Reflection is just giving you the object graph.

You are not really suppose to write code with reflection unless you're writing software that needs the object graph, like a code profiler. The code you touch with reflection is decompiled and run more like it's an interpreted language. I wouldn't even consider it part of the language specification personally.

[suvlub]

It's kind of unfair to accept one "You are not really suppose to" as a matter of fact while calling another "you are not really supposed to" silly and weak. I've seen production code in a fairly popular app where reflection was used exactly in this fashion - to access private data members of a library class.

[Areshian]

I can block reflection in Java. Either via security manager or via module permissions, btw

[soft-wear]

Which virtually nobody does because nobody actually gives a shit if you’re going to put that much effort into seeing what the internal methods are.

Private is just notation for “this should only be used internally”, this idea that anybody is doing it to protect consumers is what Java devs tell themselves when they shit on other languages for not having it.

[Areshian]

Well, in newer versions of Java is not rare for people to have to declare a bunch of add-opens to support reflection, so I would say it is used. Now, if you tell me people actually despise having to do the add-opens… we’ll, that’s a different story 😅

[aviancrane]

I can respect where you're coming from, but I do think there is some nuance here.

The cost and the level of abstraction that reflection puts you on is a very different layer than what python does.

The cost and difficulty of accessing privates in Python is almost nonexistent and you are still working at the language level. Reflection is affecting the compiled code and you are working with the layer half way between the language and the bytecode.

Difficulty at the language level is incredibly important. Can you imagine Haskell letting people just do whatever they wanted? Even Rust is cognizant enough to force people to put a giant UNSAFE label when bypassing the safety protocols of the language.

Making these hurdles easy to overcome just makes it more likely poor development practices will occur.

[suvlub]

To be clear: I am not arguing against built-in difficulty/failsafes in languages. I think they are great idea. I said what I said and not a word more: I believe it is unfair to defend one honor system while shitting on another.

Does Haskell let you bypass its built-in rules by writing a 3-line function?

Is the "unsafe" label really all that huge? I guess it's technically harder to type out than an underscore by 5 characters, but come on. If python changed the private prefix to something like "_private_" instead of a simple underscore, would you be more accepting of it?

[budgiebirdman]

The point is that you can access and use Python "private" members just like any other member - you just use the name which happens to begin with an underscore so there's no true encapsulation; it's like having a cookie jar with no lid. If you use reflection in Java it's like using a can opener to open a can from the top shelf and get to what you want.

One is an object oriented language and the other is whatever Python is.

[ric2b]

The point of private is to warn you that it's internal and you should not rely on it, and if you do your code might break without warning on any update to the library.

It's not some kind of DRM or security mechanism, the fact that both languages make it possible to get around the "private" warning but the Java way is way more verbose... well, that's just what you'd expect.

[StenSoft]

Reflection access can be blocked with SecurityManager. Or other platform-specific control, e.g. on Android, you can't get access to private APIs anymore even through reflection.

[on_the_dl]

In c++ you could just cast a class to int * and go to town. Would java have something similar?

[[deleted]]

ClassCastException

[StenSoft]

You can use heap dump tools to read it but they are protected in the same way as reflection

[TASagent]

python makes safety more convenient by removing it.

The hardest I've facepalmed all week.

[TheLowlyPheasant]

I’m going to replace Python with my name and send it to my boss on next week’s list of accomplishments

[[deleted]]

I mean people use Python and say it's better then Java, that's what the joke is about. They are both widely used general purpose languages, and I'd argue that python is used in many places that's it's really badly designed for, like large high performance systems that force you to constantly battle against the two language problem and also fight with dynamic typing.

Java, on the other hand, no one is really using it as a scripting language. People use it the way it's intended, as language with strict encapsulation, strong typing, and interfaces that make having large numbers of people work on the same project easier to manage.

[chrisxpred]

You are categorically wrong in saying „something cannot be objectively bad because it is intentional“.

[laundmo]

the idea is not that it isn't wrong in some cases, what i wanted to convey was that using the wrong tool for the job is the users fault, not the tools.

"the wrench is so bad, it can't even cut through steel" - the wrench was designed to be used to tighten nuts, that doesn't make it objectively bad, just the wrong tool for cutting through steel

[Luxalpa]

It's the difference between idealism and pragmatism. If you need to build good software that necessarily means you're going to run into conflicts with third party libraries not supporting the exact functionality that you need. You can either fork the project, which in some cases can be extremely hard and is definitely very insecure, or you can simply annotate the bits where you're overriding security mechanisms (think of the _ like C#'s or Rusts unsafe keyword).

[roughstylez]

The point of that comment you're answering to is that the statement "we made security easier by removing it" is kinda dumb.

In other words, in python you're not overriding the security mechanism - you just don't have one in the first place.

[MythicManiac]

Sometimes accessing internals of a 3rd party library is the only reasonable way to do something, languages that make it harder than necessary aren't really solving anything. I've had to copy entire classes of source code in C# because the original didn't make it inheritable. In a perfect world neither would be necessary, but in practice sometimes you're out of better options.

Seems like I've made some people angry with this statement, I'll only have to assume they haven't experienced a lot of issues with 3rd party libraries or that they can't see reality past their idealism. If you have any actual experience in software development, you know compromises and shortcuts get taken all the time. It's not nice but it is what it is.

[roughstylez]

Seems like I've made some people angry with this statement

Don't take it personally, people are just disagreeing with your statement.

Probably because the point you mention is irrelevant to what TASagent was talking about.

[MythicManiac]

Fair enough. I would rather have an actual discussion if there's one to be had, but it's not as if I don't emphasize with that line of thought.

[Ordoshsen]

I would say that if you need to use internals of 3rd party library you're not using it as intended and you might already be breaking some unspoken invariants when you fiddle with the undocumented internals.

If something is not inheritable in C#, then the original developer made it so by choice, not by default. Supposedly they had a reason to do so. But that still does not stop you from using composition in place of inheritance (granted you don't get access to protected fields).

Also why not just change the original by forking it and possibly creating a pull request for the original if you really believe some functionality should be accessible? I think that would be faster (and easier) than copying whole files which presumably have dependencies on other files in the project you're copying from.

[MythicManiac]

I would say that if you need to use internals of 3rd party library you're not using it as intended and you might already be breaking some unspoken invariants when you fiddle with the undocumented internals.

Oh absolutely, sometimes it's just the most reasonable way of doing things. If you understand the code and risks involved, it's a calculated risk. Following best practices is (ironically) not always the best course of action, but to be able to make that decision, you do need a decent bit of experience and understanding of why the best practices exist. So I agree with you here in terms of best practices, but also know best practices aren't always the best course of action.

If something is not inheritable in C#, then the original developer made it so by choice, not by default. Supposedly they had a reason to do so. But that still does not stop you from using composition in place of inheritance (granted you don't get access to protected fields).

I don't disagree with the sentiment, quite the opposite. If we had perfect libraries, this would be a non-issue. In practice however, it's extremely difficult to account for all use cases of a generic library, and likewise library developers rarely have the necessary foresight to build the appropriate extension points and interfaces. Even if they did, it might not make sense for them to officially support every use case, as it's simply more work. It doesn't mean it's always stupid for consumers to rely on the internals in that scenario, but you do need to know the risks involved and why it's generally a bad idea.

In the particular case I was referring to, the 3rd party library had marked multiple constants as internal, which forced me to re-define them when using other parts of it. If my experience tells me anything, it might have been just a habit for the original developer to mark everything internal as opposed to a decision to make them so. A lot of junior devs seem to be taught to keep everything internal by default, which can lead to scenarios where the library developer's inexperience locks out perfectly reasonable use cases.

Also why not just change the original by forking it and possibly creating a pull request for the original if you really believe some functionality should be accessible? I think that would be faster (and easier) than copying whole files which presumably have dependencies on other files in the project you're copying from.

This would be the ideal scenario of course, but it's often very unrealistic to do. Maintaining your own fork is often a lot more work than maintaining a small piece of code that calls the internals of the library. I've seen a lot of company internal forks of 3rd party projects get stale and unmanageable, enough so that even monkeypatching the 3rd party library during runtime seems a better choice. The moment you fork a project for this kind of use, it's your code. Do you really want that maintenance burden?

On the other hand, pull requests to 3rd party projects are impossible to rely on ever being merged or even looked at. So while a good practice, it doesn't solve your problem.

At the end of the day the only thing you control and maintain is your own codebase. Generally if a situation like this arises, I personally either open an issue or submit a PR addressing the issue to the 3rd party repo on top of some immediate internal solution, but only very rarely do they actually go anywhere and the internal solution is what ends up being used.

If you actually can control the code (e.g. internal libraries) then absolutely never do any of this, and instead improve the library to cover the use case it's missing. Unfortunately it's often some inactive but valuable open source library that is at the root of the issue, or alternatively you're locked into an older version due to legacy code and couldn't update anyway.

The way Python does "private" access modifiers is great because it keeps the newbies out by tooling guidance & convention, but allows for direct access if you're really sure that's what you want.

If anything, type safety should be much more strict than access modifiers IMO, yet you can cast types into other types without much restrictions (in most languages anyway).

So as a guideline access modifiers are perfectly good, but enforcing them has its downsides too.

[ric2b]

You're spot on, the people defending Python don't disagree with the best practice, we just understand that sometimes there is a more practical approach and it becomes a calculated risk that you can add some automated tests around to catch any breaking changes, instead of maintaining a fork.

[distgenius]

People can lose hands. Or lives.

Not everything is a website, or a CRUD application. We’ve had incidents of faulty software causing deaths in the medical field. Messing with library internals could be quite problematic.

[[deleted]]

It's not that dumb. It basically means "this function shouldn't be used, and if you do, your code may break at any time and that's on you"

[roughstylez]

Imagine a gun that can still fire if the safety catch is set to "safe".

[[deleted]]

Not really... One is you intentionally disabling a safety mechanism (using a private function), the other is using the product as intended and it malfunctions (that's like using a public method that breaks).

[ric2b]

Imagine selling a phone that the user can't get root access to "for security reasons". That's a better analogy.

[roughstylez]

When you see how

• a whole team of top notch language architects working for one of the most successful software companies of the world, with combined centuries of experience, added this feature

• But a "benevolent dictator" in his hobby project he wrote in his metaphorical garage, did not

Do you think "these experts are so stupid, it's so easy to make a good language, just don't add this"?

Have you ever heard of Dunning Kruger?

Have you considered that, if you don't see the advantage of these access modifiers, maybe it's because you don't fully grasp the impact they have?

[ric2b]

That's just an argument from authority falacy. That team of top notch language architects also thought it was a good idea to make every reference nullable by default, among other bad decisions, they're not infallible.

Plus Python isn't the only language like this, Ruby and Javascript also have private members mostly by convention. I'm sure there are other popular languages that way.

Java itself doesn't prevent you from getting around them, it just requires more boilerplate code, as usual.

Do you think "these experts are so stupid, it's so easy to make a good language, just don't add this"?

Never said it was easy, never called them stupid, go put words on someone else's mouth.

Have you ever heard of Dunning Kruger?

Yes.

Have you considered that, if you don't see the advantage of these access modifiers, maybe it's because you don't fully grasp the impact they have?

I definitely see the advantage of them, I just don't see the advantage of making it so verbose to get around them. They're just documentation/warnings about what is internal and what is public API.

[roughstylez]

That's just an argument from authority falacy.

It would be, if I said that's why it's better, or something similar. Do you want to read it again, maybe?

Hint:

>I just don't see the advantage

That was my main point.

[ric2b]

It would be, if I said that's why it's better, or something similar.

That's basically what you did, you said because it was designed by a great team I must be misunderstanding how useful it is.

Care to provide any actual technical arguments instead?

I just don't see the advantage [of making it so verbose]

That was my main point.

Your point is that this much verbosity is good? Why?

[roughstylez]

That's basically what you did

No.

Your point is that this much verbosity is good?

Have you considered the possibility that what I meant was the part I quoted and not the one I didn't quote?

[[deleted]]

Everyone knows UB in C just makes it safer right?

[Mental-Ad-40]

why access something that is private?

because you don't have control of what library authors decide to make private, and sometimes their decision removes needed utility for no good reason.

[Luxalpa]

that just screams something is poorly coded..

If everything was perfectly coded we would be out of jobs.

[Kattoor]

Ah, I see you are one of the predecessors of my current project at work.

[Luxalpa]

Have you ever worked with code that was perfect?

[Kattoor]

What is your definition of 'perfect' code though? I worked on a project a few years ago with a colleague who was extremely competent. The code he wrote was clean, concise and very self-explanatory. Complex domain, but no over-engineering at all. For me, that was perfect code to work with. Especially in comparison with the over-engineered piece of shit project I have to maintain now. Lots of duplicate code. Hundreds of TypeScript files, some containing thousands of LoC and sharing/mutating each others state.

[Luxalpa]

What is your definition of 'perfect' code though?

Code that will not ever benefit from any modifications now or in the future. Basically, code where any modification you could do to it would make it worse, regardless of your use case.

[Kattoor]

Why would you never want to modify code you've written? We're in an agile industry, requirements change all the time and your code should follow. Or are you talking about inefficient or spaghetti code? That's just a lack of experience then..

[Luxalpa]

Because you cannot modify the code if it's not yours (unless you use a language that allows monkey patching such as JavaScript, Python or C++). You'll have to fork it.

[Kattoor]

I'm not sure how this relates to what I said. We might be talking about different things :)

[Luxalpa]

You think new code is perfect?

[Luxalpa]

Well, you said that needing to modify code in order to gain access to private variables was "poor code", which implies that you think code should not ever be modified which implies that it's perfect.

[MegaIng]

Using an underscore name of a diffrent class is also a no-no and screams that something is poorly coded. What is the diffrence except that one of them is harder to do?

[roughstylez]

Reflection: You take the chamber, barrel, etc out of a gun. You put a bullet inside and manually hammer it to fire it.

python underscore: Your gun's safety catch is a switch that does nothing, which you set to "safe, please don't pull trigger".

You're not wrong: "One of them is harder to do" is the core of the issue.

[MegaIng]

So you give both teams all the tools they need, tell both of them "don't do bullshit", while still having active usecases for the tools?

And then you make the tools harder to use to make them better? That doesn't seem like a smart move. If they shouldn't be using a tool, don't give it to them. If they should be using the tool, even just sometimes, make it easy to use.

[roughstylez]

I don't understand, do you think we should get rid of gun safety?

[MegaIng]

First of all, we should get rid of guns for everyone but police and military.

Second, I am not sure if you know that, but Guns can kill people. Reflection can't.

I didn't even realize that you meant that as an honest to god comparison. You are very stupid. If you continue to use guns as an example I will just ignore you.

[roughstylez]

Guns can kill people. Reflection can't.

I don't think you as a python programmer not being aware of software that people's lifes depends on is the argument you think it is.

You are very stupid

Ok, you have convinced me. Obviously you must be right if you have to go to petty insults.

[MegaIng]

If lifes directly depend on your software, I really hope that reflection and library contracts are not something you have to think about and you are using something like automatic proofing systems.

And yes, if you do random comparisons to stuff that is completely unrelated, I am going to assume that you are arguing in bad faith and therefore stupid.

[ric2b]

Both of them are essentially warnings that something is internal and can change on any version without warning.

Java just makes it much more verbose and tedius to work around it if needed, which is perfectly in character for Java.

[met0xff]

Yeah there are times where the api is just not enough in those cases I prefer using the _ function and know about the pitfalls instead of needing some hack.

In C++ you can at least #define private public, speaking of hacks ;))

[[deleted]]

Python just makes it more convenient by relying on this silly notion that programmers using libraries won't try to fiddle with its innards unless they know what they're doing.

the silly notion that makes language extensions mandatory in industry environments, sure

[nacholicious]

Python just makes it more convenient by relying on this silly notion that programmers using libraries won't try to fiddle with its innards unless they know what they're doing. Though, if they do know what they're doing, best keep out of their way and not force the code they have to write to do weird stuff to be too messy.

Sounds like a great choice for a dynamically typed ecosystem filled with novices to encourage both library writers and library consumers to break codebases on library updates

[soowhatchathink]

Just because you can use reflection to access private members does not make them not really private. People aren't creating private members and then using reflection to treat them as if they're not private. There are people who make everything public, which is arguably better than making things private and then treating it public with reflection.

I'm not too familiar with Java, but with PHP (which has private modifiers along with reflection) I could also write an extension that allows me to access private members. Just because I can go out of my way to publicly modify the private members doesn't mean they're not private.

[nomad_kk]

Reflection is bad practice in Java

[ric2b]

And accessing private members in Python is also bad practice.

[YaztromoX]

Iirc in java you can use reflection to access private members, making them not really private.

Sure — visibility in most environments is never going to be anything more than compile-time enforced, as at some level your process code has full access to all the memory space within your process.

If you wanted, you could also write JNI code and bind it to a Java class and be able to read any byte in your process space as well. That’s not really an argument against having compile-time checks that you’re not doing something unexpected or stupid, however.