I love Kotlin, but don't want to use IntelliJ, and they obviously have strong financial incentives against supporting other IDEs. Has anything changed in this regard?
I appreciate their work on native/wasm, and I think it's great if they could be financially rewarded/sponsored for that work. It's just unfortunate that it has to be in the shape of an IDE dependency.
I've heard many stories about Chinese food safety.
But is government oversight getting better?
Is this a story of local corruption, or of a larger corrupt system?
And if it has "millions of views" on Weibo, is this an indicator that the government takes it seriously, or just a means of entertaining the public with the latest scandal and establishing legitimacy of government intervention?
The article is extremely short and by an unknown author, so there isn't much to discuss.
But I've met many people who hated onion architecture with a passion.
I have a few theories:
- Maybe a lot of programmers have ADHD, are autistic, or suffer from dyslexia, and find planning, naming, designing abstractions as excruciating activities.
- Onion architecture etc. is a long-term strategy that mainly benefits the company/project owner, but not the individual contributor. So it basically has to be forced upon programmers, who will resist it in every way possible, because they have no real incentive to use it.
- It's supposed to make writing software easier. But it really requires an IDE that's designed for abstractions, such as IntelliJ, and also requires a different way of working with the code. It's also verbose. So it's really a different paradigm, and it won't work if you use a plain text editor. You'll drown in code and a vast number of files.
- Onion architecture is not OOP, but often mixed in with enterprise OOP, and therefore bad associations that come with enterprise OOP.
Any other thoughts on why people resist it so much?
And what changes in how we work with code, would make onion architecture more practical?
>- Maybe a lot of programmers have ADHD, are autistic, or suffer from dyslexia, and find planning, naming, designing abstractions as excruciating activities.
I don't know about the medical conditions, per se, but I think this does bring up a point that is often overlooked when discussing best practices: our brains are different and organize things in different ways.
What works and makes sense to one group of people might not work or make sense to another group of people. I find that more literal-minded people are frustrated by what they see as unnecessary abstraction and are fine with duplicated code whereas people who think in abstractions have no problem seeing the bigger picture and are proponents of abstractions when the abstractions make sense to them.
I have coworkers who will look at a codebase with a layered/onion architecture and immediately understand and reuse all of the abstractions without issue and others who will immediately want to simplify it and change it all into concrete implementations. I find myself to be fairly evenly split so I see it from both sides.
I think it's often more about the nature of the latest person who looks at the codebase than the codebase itself. Eye of the beholder and all that.
>>does bring up a point that is often overlooked when discussing best practices: our brains are different and organize things in different ways.
I really notice this when I first look at a code base...Its not that the code is 'bad' but more of a 'what were they thinking' when the code was laid out. Eventually you get used to it, but its a bit of a shock when you first encounter it as the organization, data structures, etc are so 'alien' to how you would organize it yourself...
> What works and makes sense to one group of people might not work or make sense to another group of people. I find that more literal-minded people are frustrated by what they see as unnecessary abstraction and are fine with duplicated code whereas people who think in abstractions have no problem seeing the bigger picture and are proponents of abstractions when the abstractions make sense to them.
I don't agree. I don't think this is an issue of having different points of view. It is an issue of being oblivious to constraints that result in this specific configuration.
If they do not understand the problem, they don't understand the solution either.
No one adds abstractions and interfaces because they like complexity. In layered architectures, interfaces and abstraction layers are used extensively to manage dependency relationships.
Take for example dependency inversion. Dependency inversion is used extensively to ensure that inner layers, the modules which should change less frequently, do not depend on implementation details implemented by outer layers. Your inner layers need to get data from other services, save data in a data store, etc. But you should not need to change your inner layers just because you need to call a service. Consequently, you eliminate these dependencies on external services by having your inner layers provide the necessary and sufficient interfaces they require to handle external data, and then have the external services implement these interfaces provided by internal services. This can be interpreted as an unnecessary layer of abstraction if you do not have a clue about what's happening. I mean, your inner layers could simply call a database, but instead they have an interface that's implemented God knows where, and then you need to hunt down how it's used. Except this abstraction layer is of critical importance.
Have you found anything that makes everyone happy and productive?
I sometimes wonder if we'll replace traditional design patterns, especially OOP, with new patterns, that are neither OOP or FP, but perhaps a different paradigm (e.g. how Prolog is wildly different from C++).
>Have you found anything that makes everyone happy and productive?
Not really. It's kind of a constant push-pull and a lot of compromises. In the end it's just about getting things done and dealing with the friction in stride when it comes.
I've often wondered what it would be like working at a workplace where everyone programs with the same mental models, but have never worked at such a place myself and I'm not even sure it's possible.
> Onion architecture etc. is a long-term strategy that mainly benefits the company/project owner, but not the individual contributor. So it basically has to be forced upon programmers, who will resist it in every way possible, because they have no real incentive to use it.
Although I was aware of it for a while now, I had never seen this misalignment (between what I called ease-of-writing and ease-of-maintenance) stated so clearly in so few words. Thank you !
Unfortunately, I don't understand what this article is trying to say, but I respect the author and made a diligent attempt.
Yes, open source is now common place.
But I sometimes wonder if it, too, is a market failure, in that many projects are governed by, or mostly funded by, single entities, e.g. Facebook (React), Google (Flutter, Go, Android), Docker (Docker), and so on...
Is C++ a better example of open source, with broad industry contributions?
What about WebAssembly? Major browsers (Chromium) can pretty much refuse to support some functionality, and that'll be the end of that. The power centralization has severe consequences for openness.
I'm not convinced that community/industry-driven public-good type of FOSS will continue to flourish.
If anything, I worry that we'll end up with a bunch of "open source" projects that in reality have built-in limitations (or as the author said "a carefully engineered bottleneck"), that prevent truly open adoption (like HashiCorp preventing contributions that compete with their commercial edition feature offering).
I don't think it really matters who governs or funds open source projects as long as they're under a permissive license. Those companies can't control the software if others are able to fork it and part ways with the company.
The important part though is that people have the freedom to use, modify, and learn from them. Imho it would only be market failure if that freedom disappears.
In practice, however, the source code can be overwhelmingly large or complex, e.g. Chromium.
And yes, even if you're blocked from contributing to the project, you could 'just' fork it. But it would be incredibly hard to maintain a fork, and to get users to use/support it.
It is therefore important to distinguish between community-owned projects (e.g. Linux Foundation) that aim to be inclusive, and those that are privately-owned, and can easily have political behaviors (e.g. intentionally ignoring contributions, e.g. VSCode, because it goes against your interests, e.g. .NET, Copilot, etc.).
> Imho it would only be market failure if that freedom disappears
There is nothing inherently wrong with Facebook making React open-source. React undoubtedly benefits everyone.
However, the issue lies in the fact that this practice doesn't create a true "market". Facebook has made a relatively small and insignificant portion of their source code available for free, which doesn't impact their business significantly. Meanwhile, they have encouraged thousands of programmers around the world to develop React extensions and publish them for free under similar terms. For an individual programmer, unlike Facebook, this means giving away 100% of their work effort without charge. While this benefits society in terms of knowledge sharing, it almost always financially benefits businesses and big tech companies.
Overall, this model creates a situation where most programmers end up doing part of the job for businesses for free, and they have to earn their living by working for these companies as well.
This model exploits programmers' labor in two interconnected ways. Simultaneously, there is widespread public promotion that publishing under OSS licenses is moral and the only way to go.
I don't think DNSSEC would help in the common case of non-validating stub resolvers querying a public resolver. My understanding is that the DNS query response from a DNSSEC-validating public recursive resolver doesn't contain the information required for the stub client to validate it, only a single AD bit.
Probably not, I can't remember the last time I looked at 'resolvectl' output and saw anything other than "DNSSEC: no" on any system so I assume it mostly just doesn't exist in practice
It's impossible to take technology out of the equation.
I.e. that one person may have superior insights in their physiology/glucose levels, or a superior diet before the race. And so on.
Similarly in football, by studying your opponents in previous matches, so that you can identify weaknesses during the match, even if playing in isolation.
This is silly.
Soldered CPU, RAM, SSD.
Pretty much the only thing repairable is the battery.
I'd argue that this was a cheap business decision to make.
Keep the price gouging on parts, while satisfying regulators on "right to repair", and even get some free marketing from iFixit.
It only takes one part to break for you to have to buy an entire new device.
Is there a single laptop on the market that's different in that sense? Even Framework only supports swapping entire mainboard. Even then -- we have yet to see for how long they'll be releasing updates for the current form factor.
Not in the hot-swappable way but yeah, they kinda do: e.g. latest AMD CPUs use sockets called FP7 / FP7r2 / FP8. However, I don't think footprints of these sockets are public.
I'm pretty sure that only Apple is desperate enough to solder storage. I've never heard of any other laptop or desktop with soldered storage (although please correct me if I'm wrong; I'd love to know what brands to avoid).
I wonder what caused all this madness. Doesn't it degrade productivity? And thereby hurt profitability? And thereby the attractiveness of such strategies?
It sometimes seem to me like profit motive has been replaced by a power motive, like money isn't real anymore, but the legitimacy of private ownership is.
Basically aristocracy 2.0.
I'd be happy to hear your thoughts on this, and why there aren't competitive alternatives in an otherwise free market.
Trust fund kids do not need to work, they just choose to do so and they like to watch lower management jump up trying to catch the carrot dangled in front of them. Aristocracy never disappeared only it took them a while to learn how to use modern inventions. Look at who's working as a "trustee" for a lot of projects and watch how everyone is trying to lick their arse in the most imaginative ways.
I appreciate their work on native/wasm, and I think it's great if they could be financially rewarded/sponsored for that work. It's just unfortunate that it has to be in the shape of an IDE dependency.