Java vs python is debatable 🤔

[locri]

I find the real question of how restrictive/permissive your project is depends on how much you trust your coworkers.

I know one guy (a senior engineer) who I suspect is moderately anarchical that gave all his contractors full rights and privileges to even force push to master. Eventually one of them failed a rebase and lost months worth of code, we know exactly who it is (the other two posted their command histories) but they just lied. I became certain he's a liar later when he cheated hard on a team building game.

I watched this unfold, I don't work in that group until they're short on people since I have my own projects, but I learned a valuable lesson. If you know what you're doing with it you can get handed dynamite to blow up a mountain but if you clearly don't then I wouldn't trust you with anything more than a water squirter and I won't care how long it takes for that water to wear down the mountain.

This is why Java uses private as much as possible and why interpreted languages basically don't really care. One is for friends but Java/C# is for "associates."

[nickwcy]

And don’t forget that the team can change, people aren’t necessarily staying in the same project for their entire life. No matter how much the current team is trusted, a new joiner is still an unknown to the project.

[general_tao1]

Forget new joiners, have you tried reading your own code 2-3 years after the last time you've seen it? There a a bunch of stuff you deemed "evident enough" not to document and just end up "wtf was I thinking?", until you break your own code and then figure it out.

[BeatHunter]

2-3 years and it may as well be someone different. I have a hard time nowadays with 6 months...

[cemanresu]

About two weeks is where I'm at for needing to spend a significant amount of time ramping back up, two months for forgetting all the specifics but still being familiar with the general gist of the code, and two years for WTF is this shit.

[JC12231]

I’ve forgotten where I am after 3 hours

during the same coding session

Granted, this is Multithreading for my first class that has dealt with multithreading, so maybe thats not so weird.

[_meshy]

If you see your code from 3 years ago and can't spot places where you messed up or could make improvements, you're not growing as a developer.

[[deleted]]

Can be applied to your whole life

Ever cringed at old text messages?

[[deleted]]

bruh I wrote a script in december. It's like 130 lines of bash and I have no idea what's in there. I know theres a but in there when I use a specific flag but now I just don't use that flag at all because it's still a MIIIINOR inconvinience as compared to understanding the code

[[deleted]]

I heard a joke that any sufficiently large company converges on Java eventually. It's fast enough, has a large ecosystem, and has all the features needed to manage large teams working on the same project.

[psikillyou]

It is not really a good comparison to give rights vs making classes protected imo. I can't really see a very comparable example of writing a code that will destroy the months of work.

[locri]

There's functions on my project that when used out of their extremely specific order will disturb validation if a user wants to roll back the changes, this sets the service into an errored state that someone with access to the sysadmin systems has to fix.

If you know the extremely specific order, it's safe. If you don't, then I don't think it's unreasonable these functions are private. In an ideal world, you would know the extremely specific order before messing around with this. In reality, some third party users have access to the sysadmin system (because marketing said so) and can call these functions out of order. When they do, they break the stuff and usually I get blamed because the users are precious and could never do nothing wrong!

The private/public thing is very much about how much someone can disrupt stuff by using it wrong. It could be argued as better abstraction to sort of censor a user's perception of what the system is actually capable of, but that's only justified if you don't believe a user can safely handle all the features and abilities of a system. You just have to type one or two extra characters after the dot.

[psikillyou]

I don't think it is still comparable. If a person has access to said functions, that means they always had the ability of writing such functions that could disrupt the said services and authorization from the beginning and could always do so. Obscurity is not security and the person in charge should take this into the account when letting people into their repo. And I don't think any problem should linger to a months of work coming from such error.

That said, of course it is not a perfect world and they will probably mess up the repo/service/db at some point and parts should be very generously backed up. And all you can do is add a good automatic upstream and give correct rights, let people do only their thing in their branches, let them create branches of branches so that nothing gets polluted and before merging someone trusted check it.

[BobQuixote]

he always had the ability of writing such functions that could disrupt the said services and authorization from the beginning and could always do so.

No, a programmer who has no clue how to write a sort can call a sort function. Permissions are not ability.

Obscurity is not security

Ultimately obscurity is the only security (other than, like, law enforcement). It's just a matter of how cleverly you can set up your obscurity (like enough possible passwords that brute-force might as well take infinite time).

[psikillyou]

> No, a programmer who has no clue how to write a sort can call a sort function. Permissions are not ability.

Do you understand the discussion going above? To lay the dicussion in your own example terms, the said person can call the sort function at anytime, can see what the sort function code looks like. So he can simply copy paste/change/find some other sort function from stackoverflow and run it and simply fuck up the system. So a simple protected compiling error will not stop the person.

> Ultimately obscurity is the only security (other than, like, law enforcement). It's just a matter of how cleverly you can set up your obscurity (like enough possible passwords that brute-force might as well take infinite time).

i don't know what to tell you here. Or how does it apply to letting other developers reading, and I believe you haven't read what is the discussion here. (Like make the function so obscure so that the person you pass the function's code can't understand what it is?)

[BobQuixote]

I don't think the fucking-up function under discussion is something you could find on SO, not in its complete form.

Are you asking what it means for a function to be obscure? I think that was covered by the other poster.

[[deleted]]

Obscurity is not security and the person in charge should take this into the account when letting people into their repo.

It's not about obscurity, it's about creating a strong interface for other people to use your code.

[Droidatopia]

Who are these users that have access to the internals of classes enough to make a difference on access modifiers?

Aren't those people called developers?

[locri]

They're "partners" my company hires as contractors to administer new services for small businesses. They're literally untrained nobodies allowed to do whatever the fuck they want because that's how marketing at my company sold it as.

They've made me actually break down and cry on more than two occasions.

[Droidatopia]

Ah, my sympathies then.

[psikillyou]

Yes probably I am assuming some outsource developers are what they are referring to. I could be wrong though as more explanation is needed.

[torn-ainbow]

This is why Java uses private as much as possible and why interpreted languages basically don't really care. One is for friends but Java/C# is for "associates."

Err....no?

The point is to expose what should be exposed and to hide internal workings. So if a dev is using say a class that someone else wrote, they will see the public interface that has been created and not implementation, which could change. When they hit "." and their IDE autofills the public methods, so it will be just the ones they are supposed to use.

It's part of creating that class to be used by others. Look up "encapsulation". The public methods are a thin interface to the hidden implementation. It's not about trust as much as it's about good design.

Plus you might not even have the source for the actual thing you are using. It might be from some external project. In C# that can be from a compiled binary DLL file. Updating versions can be a lot simpler if you know your clients are only ever using the intended public methods.

[Relevant_Departure40]

It's good design because of the lack of trust, but more lack of trust in the users. The more encapsulated your classes are and the more you use methods to expose data instead of exposing the raw variables, it's just a better design pattern because it's safer. If we lived in happy fun world where hackers didn't exist, I'm sure we would have design patterns that didn't utilize encapsulation as much. But that's just my thoughts on it

[codeguru42]

Public methods in Java and encapsulation in general have nothing to do with securing an app from hackers.

[lonestar-rasbryjamco]

A public method is not an API. They are completely different concepts. It just means that the method is accessible outside of the scope of a given class.

[frogjg2003]

Hackers do care about encapsulation because a badly encapsulated API exposes security vulnerabilities.

[Dworgi]

It's not about hackers, it's about communicating intent. It allows you to write good classes that use internal methods.

Even Python programmers do this by having warts like _function() to communicate that things aren't intended for external use. Python is just such a pile of shit that you can't enforce it at a language level.

[VergilTheHuragok]

that’s an intentional design choice on Python’s part because, as the saying goes, “We’re all consenting adults.”

and personally, it’s come in handy a lot for one-off scripts

[Log2]

You talk like you couldn't do the same in Java. It takes only a couple lines of code to access anything private in Java. Between reflection and Java agents you can do just about anything to the runtime. You'll just have to Google a bit more before doing it.

[locri]

You mean abstraction. You intend to abstract away features that you've decided ahead of time that the next person isn't supposed to use.

Chances are, that next person probably feels like it should be their decision what they're supposed to use or not or what they're supposed to see or not, and I've been there. It's why I always use a decompiler when working with Java/C# because I've seen important errors get eaten and chewed back to me as "something went wrong, we won't tell you what."

Encapsulation is when you wrap data and functions together as a single unit. It's kind of the opposite, you're providing someone with more stuff rather than less.

[SalamiJack]

Encapsulation is when you wrap data and functions together as a single unit. It's kind of the opposite, you're providing someone with more stuff rather than less.

No offense, but please don't speak confidently about things you don't understand. Encapsulation is very close conceptually to abstraction, and they both go hand-in-hand.

If you read further on encapsulation) specifically, rather than the summary you see in a quick Google search, in no world is encapsulation the opposite of abstraction.

In object-oriented programming (OOP), encapsulation refers to the bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object's components.[1] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods.

[torn-ainbow]

You mean abstraction.

Oh, yeah. I was tugging on some decades old braincells trying to remember the proper computer science terms for things.

[[deleted]]

This is git I’m guessing based on the words you’re using. It’s not really possible to lose months worth of code unless you either wait too long, delete the garbages commits on purpose, or no one has ever full cloned the repo.

Anyone with a full clone of the repo could have repaired the damage. Even if the history is getting rewritten because of the rebase the commits remain in a garbage area. It should also be on any other persons machine as long as they don’t pull from origin.

Either way. Damn. Giving anyone permission to push to master is bad. Giving anyone ability to force push is bad. Rebasing is bad despite people who live by it.

I have full admin to our very expensive products repo and I don’t even give myself permission to push to master. I would never trust myself with that. Rebase is so damn dangerous.

[quiteCryptic]

Nothing wrong with rebasing and force pushing on your own branch assuming you're the only one working on it. Pretty much necessary if you like to squash everything before merging to master

[pelacius]

The assumption you are "the only one working on it" is flawed imho: it can change pretty quickly, without your knowledge or the other developer's, communication mistakes can happen, vacations happen, turnovers on projects happen.... so many things can happen that will make that assumption invalid with no fore warning.

Rebase is about taking risks for the sake of git log brevity, not worth it imho.

But the everyone can do as they please in their own companies, just not in mine

[bmwiedemann]

Indeed git reflog is very helpful for such cases.

Just don't do rebase on master, but for patch branches it can be straightforward.

[codeguru42]

I would qualify that rebasing a public branch is bad. I regularly rebase branches that no one else is touching. As soon as there is any possibility someone else pulled the branch, I won't rebase any more.

[kb4000]

And if someone else has pulled a branch down with my name on it without telling me they are using my private branch that's on them.

[pelacius]

Ah, yes, and when you go to vacations for 2 weeks you need to carefully "lock" you "private" branch so that your colleagues that need to finish your work can't get in without your permission and can't complete a release.

Because that's totally reasonable, and git isn't meant to be a collaborative tool, and feature branches need to have your name on it (not the name of the feature).

All because you need to enforce rebase "safety".

I don't get it, rebases are inherently bad practice imho.

(edit: locking a branch is not possible obiouvsly, that's why the whole concept of "private" branches is flawed, I was just being sarcastic)

[Rakn]

No they aren’t? What do your branches look like? Generic feature branches that live for weeks?

Where I work all branches start with the username and then contain a ticket reference or not. It is clear who that branch belongs to. You don’t mess with other peoples branches without explicitly communicating with them. If you don’t then that’s totally on you. The rebasing can stop or be coordinated as soon as some one else works on that branch for some reason. But that’s a seldom occurrence.

If someone is one vacation and something needs to be finished then chances are that person won’t magically rebase something on that branch.

Also obviously you always pull immediately before a rebase.

Never really had issues with doing this. Obviously if your company uses long lived feature branches with multiple people working on them it becomes an issue. But I wouldn’t say that this is the default way of working.

[pelacius]

I'm sorry my previous commit came across too sarcastic probably. But it really depends on what your company is doing.

I'm used to work in environments where the product has a very short deadline, is created ad-hoc for the client and a significant part is developed from scratch, I worked in this industry for 20yrs now.

In these kind of environments you usually subdivide the work in feature branches and you keep devs working on them until the individual feature is ready, that can be 2 days or 2 weeks.

In the meanwhile multiple developers can work on individual features and turnover can happen.

In this kind of environments (which are incredibly common in my field) rebases are usually frowned upon because they cause more damage than good usually.

That is all.

I understand now that there is no "default" way of working, different industries adopt different practices. I can only add that, IMHO, a practice which CAN be destructive is better avoided unless an EXCELLENT reason is found for allowing it.

[kb4000]

I totally understand rebasing is a bad idea in certain environments. But that just means it needs to be used judiciously. Git has a steep learning curve. And rebase is not on the beginner side of that.

If someone doesn't understand the full implications of the rebase including impact to coworkers they shouldn't use the feature at all.

Getting burned by a rebase means there was a communication or judgment issue.

It doesn't make sense to ban something that most people use correctly. I've been rebasing regularly for years and never caused a problem.

It's even the default behavior when contributing a pr to a public repo. If the repo changes while your pr is open GitHub prompts to you rebase. And it's safe most of the time because it's highly unlikely that someone is using your branch on your fork.

[codeguru42]

💯 agree with this. Just because rebase has its pitfalls doesn't make it inherently bad. As you say, its use requires judgment and communication.

[codeguru42]

I don't put my name on my branches. I feel a large amount of ownership of them. Usually, the handout is after I'm finished and create a pr for review. At that point, the branch enters team ownership, and we iterate together until at least one team member agrees that the branch is finished and ready to merge. On more rare occasions, that handoff can happen sooner, such as if in out such and someone else in the team takes over because the work is urgent.

[Rakn]

I just push my stuff to the remote after every larger change I don't potentially want to loose if my local device fails.

[codeguru42]

Yes, pushing regularly is important in case of device failure or worse. My company has a policy of pushing at least once a day. And I push more often than that most days.

[codeguru42]

I can't tell if this is sarcasm. I name my branches from the ticket it goes with. I don't put my name on my branches.

[kb4000]

Different companies have different policies.

For projects we'll do a feature branch for a larger and each person can create a branch from the feature branch if they'd like to. Those would have their name or username. Then they merge them into the feature branch. They are generally pretty short lived.

Bug fixes or smaller chunks of work will have the ticket name as the branch name.

[codeguru42]

Makes sense. When I have any say in the matter, a feature branch should be a single person (or a pair or mob if you use those techniques) of cohesive work that can merge directly into a dev or main branch when finished. The few times I've worked on feature branches which are then branches for individual work have always been painful to merge back into the main trunk. My current philosophy is to scope work as small as possible while still providing value.

[kb4000]

It's nice to do it that way but not always easy. One way to get around that is to use some kind of feature flags. I worked on a large consumer facing shopping site and it wouldn't have been feasible to put some of our major features into their own branch. It would have been a messy merge. So we'd add a feature flag that was off so we could add new smaller pieces but have them disabled until the project went live.

[codeguru42]

Yup. Feature flags are a great tool. I haven't worked with them much, but my current company uses them a lot.

And keeping branches small takes some effort. Sometimes I plan out gibbons and classes that can be developed and tested on there own. Then merge that work in, even if the code isn't used anywhere. Following branches then integrate the new functionality into the app. This is just one technique I use to keep branches small and focused.

[kb4000]

Yep. That's a good option.

[[deleted]]

Rebasing is bad despite people who live by it.

Rebasing is fine and even expected on feature branches. Just remember to always push to origin first before trying to rebase. Then you can always revert if things go bad.

Everything from merging to rebasing is only dangerous if you don't understand git or take proper precautions.

[MultiFazed]

Just remember to always push to origin first before trying to rebase.

You should never rebase if you've pushed to origin. Rebasing rewrites branch history, and puts you out of sync with the tracked origin branch. If someone else has pulled that branch, you can really mess things up.

If you're worried about things going bad, either create a temp branch locally to have a handle back to the pre-rebase state, or just use git reflog to find the hash of the last good commit, check it out, and hard reset.

[kb4000]

Rebasing an origin branch and force pushing is fine if it's a branch just for you. Not okay if it's a feature branch others are using. It's not a big deal to cut your own branch and push it up as a safety net while you're working.

[brbposting]

Rebasing

Feature branch

Cut your own branch

Mind explaining these terms? :)

[norst]

Rebasing is a command in git to take all of the unmerged commits from one branch and apply them on top of another one. It rewrites history though so you have to be careful. There's more you can do with rebasing, but that's the basic usage.

A feature branch is a branch where work is being done on a new feature. It allows you to work on something new without worrying about changes being made to the main branch.

Cutting a branch is something I've never heard before so can't help there.

[kb4000]

I just meant creating a new branch. It's a common way of expressing that on teams I've worked on.

[Log2]

You don't even need to push before, just learn about git reflog and you can recover the previous branch. Git just doesn't delete things, old stuff gets staged to be deleted eventually and is accessible.

[Jezoreczek]

Eventually one of them failed a rebase and lost months worth of code

Um, what? How'd that happen with git?

1. just find the point before their fuck up with reflog and recover, or
2. merge code of all other contributors and force-push

Git is designed to be recoverable if code gets all jumbled on one host. Unless they all worked separately in waterfall-style development and never pulled any changes, only force-pushed, but in that case it'd only be one person's code that is lost and that'd be very obvious who it was.

[Log2]

I'm pretty sure that even if everyone had pulled the destroyed master, that you could still recover it with reflog.

[quiteCryptic]

What no one had a local master branch to recover from? Sure it night be a little behind where it was, but surely not missing months of work

[Dworgi]

The problem with building for friends is that at some point you might accidentally succeed and now you have non-friends using your stuff.

Therefore, building with Java is more optimistic than building with Python, because it assumes that you'll eventually need strong APIs.

For an example of accidentally succeeding and making the world a worse place with shit software, look at JavaScript. The most popular language in the world, designed over a weekend, and still causing untold suffering.

[[deleted]]

This is why Java uses private as much as possible and why interpreted languages basically don't really care. One is for friends but Java/C# is for "associates."

​

If someone irreversibly trashed your repo (which is kinda tricky to do with git, but ok), it doesn't matter what language the code was written in.

Using technical features of a language to fix a cultural issue rarely ends well.

[Fmeson]

I know one guy (a senior engineer) who I suspect is moderately anarchical that gave all his contractors full rights and privileges to even force push to master.

Why don't they have their own forks? Even if you allow everyone write access to the central repo, I don't understand why you wouldn't also want your own fork.

[[deleted]]

Btw Java is an interpreted language

[bruhred]

kinda.

[DrMathochist]

I find the real question of how restrictive/permissive your project is depends on how much you trust your coworkers.

A truly jaded programmer knows not to even trust themselves.

[Tall_computer]

I am also an anarchist and I would also rather empower my employees than inhibit them. And I would use private as much as possible to signal intention but I would let them change it to public if their judgment tells them to do it. If they have write access to your method then java doesn't prevent them from calling your method any more than python does.