That's the issue with WASM. Very, very few people want a limited VM that's only good for CPU-intensive pure functions. The WASM group has redirected a huge amount of resources to create something almost nobody wants.
My credit card company has a "dispute charge" button in the transaction history. It's one click. Sounds like you should look into a different provider.
It really depends on how much you reduce costs. If you reduce costs enough, you can have increasing supply even in the face of falling prices. This argument sounds like one made by a hedge fund protecting its real estate investments.
The reality is that the housing market in the US (and most countries) is heavily distorted by government NIMBY regulations. Because of this, it's reasonable to expect that there is actually a lot of room to reduce the $/sqft if the market can build housing in general. Current costs are inflated by being forced into specifically prescribed solutions designed to grow the wealth of developers and landowners.
Machine translation is a great example. It's also where I expect AI coding assistants to land. A useful tool, but not some magical thing that is going to completely replace actual professionals. We're at least one more drastic change away from that, and there's no guarantee anyone will find it any time soon. So there's not much sense in worrying about it.
A very similar story has been happening in radiology for the past decade or so. Tech folks think that small scale examples of super accurate AIs mean that radiologists will no longer be needed, but in practice the demand for imaging has grown while people have been scared to join the field. The efficiencies from AI haven't been enough to bridge the gap, resulting in a radiologist _shortage_.
Having worked in medical software for a long time now, it's not surprising.
Medical software is purchased by upper management based on features. Usability is rarely considered, and hard to evaluate anyway since it depends on integration.
Hospitals themselves create this incentive because they will rarely if ever change their processes to fit more smoothly into a different workflow. The core purpose of an EMR is to integrate different parts of the hospital, though, so the only possible solution is a huge do-everything piece of software like Epic.
I spent years on a project to try to standardize exams between a major research hospital and its satellites. The ended up quitting about half-way through because they realized there just wasn't going to be enough political power at the main campus to convince the doctors at the satellites to follow their lead.
You'll even see this at smaller regional hospitals. We'll bring software and workflows developed in tandem with the top hospitals in the world, and they'll tell us that they don't care and they want to keep doing things the way they've always done them.
Everyone may hate EMR, but hospitals seem to be getting exactly the EMR they're asking for.
Obviously being LLM generated is a good data point because it shows that the OP isn't arguing against the statements of the review itself.
It's also good for the editor to know about. LLMs represent a new acute threat to review quality that they may currently be underestimating. I've literally heard of people bragging about using ChatGPT instead of doing reviews themselves. People who aren't LLM experts don't necessarily understand their limitations or that using them in this way should be unacceptable. The editors should know so they can improve the communication of review expectations.
The demand for human radiologists never actually went down, though[1]. There is improved efficiency due to technology, but it hasn't kept up with increased demand for scanning and increased patient volumes. There's also induced demand caused by efficiency increasing. Diagnostic AI tends to make different kinds of errors than a human, so even if it were better, both together is even stronger.
The "Radiologists are being replaced by technology" story has been repeated so many times by uninformed software developers that it has become popular wisdom, but the reality so far is that we need more radiologists than ever.
Ironically, radiology might be a decent proxy for what could happen with software engineering, but in the opposite way you intend.
Amusingly a poster above indicated they had issues with multiple Subarus, and another had issues with Hondas (which is what has worked well for me).
People on this forum want it to be a technology issue, and I'm sure it is to some extent, but I think the differences between driving styles is also a large component. If you're a careful driver that usually leaves a lot of separation, many AEB implementations will rarely trigger and you'll usually understand why when it does. Whereas if you're an aggressive driver that cuts between vehicles, leaves <1 s separation, etc., you will notice a lot of "unexpected" braking from these systems. Like the poster above that was upset the system slowed them down when they were nearly clipping a car exiting the road.
A lot of good comments here, here's one point I haven't seen: If you can, just respond tomorrow. Use the evening to exercise, visit friends, play trivia, etc. I find it can help you force your brain to see the comments as just one part of your whole life.
The creators of these images assigned the rights to adobe, including allowing Adobe to develop future products using the images. So yes, this is perfectly fair.
It's completely different than many (most?) other companies, which are training on data they don't have the right to re-distribute.
If you're an experienced individual contributor, the shift to remote work was great. You got less oversight at work and more free time in your personal life. This category is a lot of the hacker news audience, so remote work is popular here.
It was less good if you were a new contributor. You might find yourself with less development and struggling to break into existing cliques within the organization. You may not have built good practices in personal time management. None of this is malicious, it is just failures that are easier to have happen when working remote and not being careful.
Managers have an even harder time. Good managers work by building strong relationships with their team members, not with carrots or sticks. That's harder in a remote environment, due to the default-private nature of most remote communication. The lack of relationships hurts individual contributors too, who become even more like cogs in a machine.
Overall, I think the ability to retain experienced employees and hire from a wide range of locations outweighs these costs of remote work, but they are real and significant. For Big Tech, where acquiring talent is relatively easier due to salaries and name recognition, you can see why they might prioritize in-office work.
> I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were.
I think you're forgetting about Mercurial, which was also created by a Linux kernel developer around the same time. It brought all the same benefits of git, but had a simpler command line API and better cross platform support. Mercurial saw wide use, especially in large corporations like Facebook.
Indeed, a lot of people will say that it was the success of github itself that pushed git over the top. In a world where bitbucket won instead of github, we could all be using mercurial.
Although I've never used it, I'm not sure how much of an improvement either of these was over BitKeeper. The primary impetus to create git and mercurial was licensing changes in BitKeeper, not technical deficiencies.
> doing the monitoring, and was ready to take over
This isn't even uncommon. Almost every Honda sold for a while has been a L2 system that will take over in certain ways if the car believes a crash is imminent, such as a car suddenly breaking.
> but would be less sexy
It's so less sexy people don't know that millions of vehicles are sold this way...
There are "sandwich style" SFF cases which mount the GPU parallel to the back of the motherboard, if that's what you mean. It's more for space than for airflow, but you can get good airflow too with the right design (e.g. standoffs/separation, exhaust fans).
> test coverage gets in the way of the iterative design process. In theory TDD should work as part of that iterative design, but in practice it means a growing collection of broken tests and tests for parts of the program that end up being completely irrelevant.
So much of this is because TDD has become synonymous with unit testing, and specifically solitary unit testing of minimally sized units, even though that was often not the original intent of the ideators of unit testing. These tests are tightly coupled to your unit decomposition. Not the unit implementation (unless they're just bad UTs), but the decomposition of the software into which units/interfaces. Then the decomposition becomes very hard to change because the tests are exactly coupled to them.
If you take a higher view of unit testing, such as what is suggested by Martin Fowler, a lot of these problems go away. Tests can be medium level and that's fine. You don't waste a bunch of time building mocks for abstractions you ultimately don't need. Decompositions are easier to change. Tests may be more flaky, but you can always improve that later once you've understood your requirements better. Tests are quicker to write, and they're more easily aligned with actual user requirements rather than made up unit boundaries. When those requirements change, it's obvious which tests are now useless. Since tests are decoupled from the lowest level implementation details, it's cheap to evolve those details to optimize implementation details when your performance needs change.
Every time this comes up, lots of people start with the assumption that coding problems have a large amount of false negatives.
Because of this perceived "truth", I had the same worry when we started to implement a coding problem. Rather than guess, we decided to measure it: for the first six months, we used a wide filter (50% pass rate, actually like 65-80% of people who didn't cheat).
What we found was that there were zero candidates in the bottom 66% who passed the rest of the interviews. The plagiarism detector also had no false positives (based on manual review). So at least on this sample, we found that we could screen out about 80% of applicants without having _any_ false negatives.
I'm sure there are some bad employers misusing coding tests, just like with any tool, but I have to imagine many others have done similar experiments and found their tests to be effective.
