Yeah, and the article is wrong, though only slightly. They seem to be confusing watts (power, energy over time) with Joules (energy, power times a duration of time). They give a passable definition in the beginning ("energy transfer"), but they seem to misunderstand what the "transfer" part means exactly.

If you find-replace all instances of "watt" with "watt-hour" after that starting definition, it would be more accurate. That's why I say it's only slightly wrong.

I do this, too, and I've been wishing there were a setting I could set where kbin would just auto-hide content submitted by accounts that have been blocked by at least X other accounts.

If you're on a desktop (or other large screen), click on the user name to go to their user page and there's a block button in the sidebar on the right. If you're on a mobile device (or other small screen), go to their user page and the block button should be prominent on the right of the "follow" button.

I think a critical detail getting overlooked in the broader discussion of the changes brought by LLM AI is not quality but quantity. What I mean is, sure, AI isn't going to replace any one complete worker. There are vanishingly few jobs AI can 100% take over. But it can do 80% of a few jobs, 50% of more jobs, and 20% of a lot of jobs.

So at the company level, where you had to hire 100 workers to do something, now you only need 80, or 50, or 20. That's still individual people who are out of their entire job because AI did some or most of it, and their bosses consolidated the rest of the responsibilities onto the remaining workers.

"Calls" and "puts" are types of contracts about buying/selling stocks (they aren't the stock themselves but are centered around a given stock and its trading price, so they are called "derivatives" as they are "derived" from the stock).

A put is a contract that allows the buyer of the contract to sell stock at an agreed upon price to the seller of the contract, regardless of the current trading price. They are used for a variety of reasons. In one usage, someone who is buying some of the stock at the current trading price may also buy a "put" on the stock at a slightly lower price. This way, they spend a little more money at the time of buying the stock, but if the trading price plummets, they can still sell it at that slightly lower "put" price and not lose too much money.

In this case, the idea would be to buy a "put" (without buying the stock at the same time) when the buyer thinks the stock's trading price is overvalued. Then when the price falls below the "puts" agreed upon value, buy the stock at the lower price and immediately invoke the contract to sell at the "put"s higher price.

Here I thought they meant women in domestic abuse situations who are still trying to get out. Like discussed here.

I think you are right that optimising engineering cost is the goal of these practices, but I believe it is a bad thing.
In the end the only people that benefit from this are the owners of the product [...]

Yes, that's exactly how the for-profit software industry (and really any for-profit industry) is run. The owners maximize their benefit. If you want to change that, that's a much different problem on a much larger scale, but you will not see a for-profit company do anything but that.

I thought the point of "clean code" was to make a software source code base comprehensible and maintainable by the people who are in charge of working with and deploying the code. When you optimize for people reading the code rather than some kind of performance metrics, I would expect performance improvements when you switch to performance optimization. The trade-off here is now code that's more performant, but that's more difficult to read, with interdependence and convolution between use cases. It's harder to update, which means it's slower and more costly (in engineering resources) to upgrade.

In a lot of modern software, you don't need extreme performance. In the fields that do, you'll find guidelines and other resources that explain what paradigms to avoid and what are outright forbidden. For example, I have heard of C++ exceptions and object-oriented features being forbidden in aircraft control software, for many of the reasons outlined in this article. But not everyone writes aircraft control code, so rather than saying clean code is "good" or clean code is "bad," like a lot of things this should be "it depends on your needs."

That sounds more like a modern reinterpretation of "protecting religion from the state." The context of the origin of the separation of church and state from the late 18th century was more about religious adherence being closely tied to political power, so you could deal your political opponents harm by branding them a participant of a socially outcast religion, or you could use political power to (legally) persecute the followers of a non-state religion. Yes, it was about protecting religion from the state, but it was in more concrete terms of protecting the followers of non-state-backed religions, rather than preventing some kind of philosophical corruption of the moral foundations of the religion.

The way posts are shared between instances is by user subscription. For example, if there's a community on Lemmy and a Kbin user subscribes to it, Kbin will then receive new posts from that Lemmy instance for that community.

So if no one on an instance is subscribed to that community, new posts won't flow to that instance. And then if you do subscribe to it, the instance will only automatically receive new posts. Federation will not back-fill older content.

I have seen this happen on Android when using the PWA with Firefox. If I open it, then switch to other apps, and then come back to it hours later, it immediately crashes. When I open it again, it will work fine, unless I switch away from it without closing it again for a few hours, where it will crash again.

Might be related to your issue, or it might be an issue with how Firefox does PWAs on mobile. I have seen a few other bugs with Firefox PWAs, so I assumed it was a Firefox problem.

You can click the hamburger menu icon (the 3 horizontal lines) on the very upper left of the page and it will open the sidebar overtop of the current view. Then you can scroll down just a little and find the send message button.

But I don't support their burden on shared resources (hospitals) on their way out. So many people who don't subscribe to those conspiracy theorist views died as collateral damage during the pandemic because the hospitals didn't have the resources to support all of their usual burdens plus the wave of COVID-ill vaccine deniers.

I think inheritance served as a good stepping stone to features like traits in Rust. I spent most of my early career in C and C++, and given just those 2, I would pick C++ for classes alone, even though that's nominally "picking inheritance." Because with C++ classes you can define interfaces and compose those objects better than you can with just functions and structures in C (no callback functions and void pointers, thank you).

So it's about the ergonomics of the language, and I think we as developers are collectively growing and exploring, figuring out what works and what doesn't, and with Rust and Go we're trying out those traits and interfaces we figured out in object oriented languages without dragging along classical inheritance. Given another 5, 10, 20 years, I'm sure we will have figured out what doesn't work in Rust and Go and see new languages dropping those concepts in favor of newer, even more ergonomic ones.