yes - monorepo. Git (and associated service providers) have a lot of work to do to scale out to large organizations working in a single code base.
"Better Merge Conflicts" is not on this list.
Although I'm sympathetic to the problem, and I've personally worked on "Merge Conflicts at Scale". Some of what's being suggested here is interesting. I question if it makes a material difference in the "age of ai", where an AI can probably go figure out enough context to "figure things out".
Merge conflict avoidance is not a monorepo issue. In fact, the whole purpose of a monorepo is to avoid these sorts of issues, so it's not surprising.
Merge conflict hell shows up when, for example, you maintain a long-lived feature branch periodically rebased against an indifferent upstream that has its own development priorities.
I've maintained a project for years that was in this sort of situation. About ~100 commits on top of upstream, but invasive ones that touched nearly every file. Every six months upstream did a new tagged release. It would take me literally weeks of effort to rebase our patches on top, as nearly every commit triggered its own merge conflict hell.
You don't encounter these sorts of issues in a monorepo.
The most frustrating thing with the "Atomic architecture" bit with tiny packages is how obviously stupid it is. Any borderline sane person should look at isOdd/isEven and see that it's an awful idea
Instead they've elevated it to a cultural pillar and think they've come up with a great innovation. It's like talking to antivaxers
It's because it has a smart-sounding name. Some people are shallow and performative; some nice-looking blog post says they can have "atomic architecture", then the trend starts and everybody wants to show how enlightened they are.
Atomic packages brings more money to the creators.
If you have two useful packages it's hard to ask for money, even if they're used by Babel or some popular React dependency.
If you have 900 packages that are transitive dependencies the same couple deps above, it's way easier to get sponsorship. This is a way to advertise themselves: "I maintain 1000 packages".
The first guy that did this in a not-nice way was a marketing/salesperson and has mentioned that they did on purpose to launch their dev career.
TLDR: This is just some weird ass pyramid thing to get Github sponsors or clout.
A third argument is that it was because of aliens from the planet Blotrox Prime. But I suppose without evidence we'll just have to accept that all three theories are equally probable.
Interesting how you decided to switch to hyperbole instead of providing evidence for your claim. Backing up your viewpoint would have easily shut me down, putting the ball in my court to do the same. Instead you gave a knee-jerk childish response.
Nope. Just a reductio as absurdum that you decided to counter by asking that I maintain higher standards of debate than you.
The notion that atomic architecture came about because people are stupid and performative is not really useful. Its fairly misanthropic and begs the question why it became so prevalent in JS specifically.
The philosophy was kinda refreshing in the early days. There was a really low barrier to publishing and people were encouraged to build and share tools rather than hoard things. It was probably somewhat responsible for the success of npm and the node ecosystem, especially given the paltry standard lib.
Of course, like most things, when taken to an extreme it becomes absurd and you end up with isOdd.
I think the issue is that the JavaScript ecosystem is so large that even the strangest extremes manage to survive. Even if they resonate with just 0.1% of developers, that’s still a lot of developers.
The added problem with the atomic approach is that it makes it very easy for these fringes to spread throughout the ecosystem. Mostly through carelessness, and transitive dependencies.
I've seen some juniors writing risoni code like that. They've heard that you shouldn't write big functions, so obviously they forcefully split things until they can't be split anymore.
Bose QuietComfort Ultra 2 at least just allows varying levels of passthrough. You can have noise cancelling or noise cancelling + sound from the outside mike. You cannot have noise-cancelling off for better battery life or to cope with windy conditions
They're awful in several other ways too, which is sad for what should be their flagship model
This is why I use wired for longer calls or video conferences. I've tried so many wireless in-ear things and all of them are more sensitive to surrounding noise and I have to repeat myself more due to dropouts or spotty quality.
It's just much harder to get good sound quality when the mikes are by your ear rather than on a wire near your mouth
Not to mention that it completely removes the risk of running low on headphone battery mid-call
> A bit like how java people insisted on making naive getFoo() and setFoo() to pretend that was different from making foo public
But it's absolutely different and sometimes it really matters.
I primarily work with C# which has the "property" member type which is essentially a first-class language feature for having a get and set method for a field on a type. What's nice about C# properties is that you don't have to manually create the backing field and implement the logic to get/set it, but you still have the option to do it at a later time if you want.
When you compile C# code (I expect Java is the essentially same) which accesses the member of another class, the generated IL/Bytecode is different depending on whether you're accessing a field, property or method.
This means that if you later find it would be useful to intercept gets or updates to a field and add some additional logic for some reason (e.g. you want to now do lazy initialization), if you naively change the field to a method/property (even with the same name), existing code compiled against your original class will now fail at runtime with something like a "member not found" exception. Consumers of your library will be forced to recompile their code against your latest version for things to work again.
By having getters and setters, you have the option of changing things without breaking existing consumers of your code. For certain libraries or platforms, this is the practical difference between being stuck with certain (now undesirable) behaviour forever or trivially being able to change it.
Adding lots of code for the common case to support consumers of the code not recompiling for some uncommon potential future corner-cases seems like a bad deal.
In a product world where customers are building on your platform, requiring that they schedule time with their own developers to recompile everything in order to move to the latest version of your product is an opportunity to lose one or more of those paying customers.
These customers would also be quite rightfully annoyed when their devs report back to them that the extra work could have been entirely avoided if your own devs had done the industry norm of using setters/getters.
Maybe you're not a product but there are various other teams at your organization which use your library, now in order to go live you need to coordinate with various different teams that they also update their code so that things don't break. These teams will report to their PMs how this could have all been avoided if only you had used getters and setters, like the entire industry recommends.
Unless you're in a company with a single development team building a small system whose code would never be touched by anyone else, it's a good idea to do the setters/getters. And even then, what's true today might not be true years from now.
I'm not convinced that Unicode fixed anything. I was kind of hoping, way back when, that everyone would adopt ASCII, as a step to a more united world. But things seem to have got more differentiated, and made things much more difficult.
The options were never ASCII or unicode though. Before unicode we had ASCII + lots of different incompatible encodings that relied on metadata to be properly rendered. That's what unicode fixed
Besides I like being able to put things like →, €, ∞ or ∆ into text. With ascii a lot of things that are nowadays trivial would need markup languages
You're still relying on sites fulfilling what they promise in a world where facebook has been blatantly violating gdpr from day one and enforcement just isn't happening
Set your browser to block 3rd party cookies, add privacy badger and ublock origin. It will have more effect than clicking "reject"
I click "don't send me mail" every time I buy something. Every place I buy from still sends me spam at some point. There are no negative repercussions for them beyond whatever infinitessimal thing me clicking the "report as spam" button does
Is it because of a monorepo?
reply