yoden

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.

Price Drops Don’t Lead to Supply. They Kill It.

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.

[1] https://marvel-b1-cdn.bc0a.com/f00000000046012/info.vrad.com...

It's right there on the about us page: https://www.hotels.com/lp/b/about_us?pos=HCOM_US&locale=en_U...

If you're a member they've been sending emails about how they're merging the rewards with Expedia's reward system.

Perhaps you're right that most guests don't pay enough attention to realize, but it's not a secret.

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.

I think this is a very insightful comment.

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.

Bad news for big tech conglomerates that want to take the work of individuals and sell it back to them.

It's good news for the artists and programmers whose work was being copied, though.

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).

GPU prices are already down. "Sell the rumor, buy the news" and all that.

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.

The Eclipse incremental compiler is faster than IntelliJ on any decently sized project. Something like 20-60 times faster for us (<1s vs. 20-60s).

I think the UI of IntelliJ is snappier, so for small projects that leads to people saying it's "fast".

History repeats itself.

Before people thought Java would save everyone from ever having to think about native dependencies. Turned out not so much, although it works "OK" for desktop these days.

Now everyone thinks Docker is going to save everyone from having to think about native dependencies. In a few years everyone will realize that Docker only works like that when deploying from linux to linux on the same CPU architecture.

Many (basically all?) Java libraries that use native code have pre-compiled code for all platforms. They'll just work on all platforms.

We've been upgrading our dependencies for arm64 support; for the most part it is as simple as updating our pined version to a newer version of the jar. Sometimes the native code is in a separate jar so you just add it (opencv works this way).

Yeah, it's hilarious to see Docker so misused. Most Java/.Net environments will just work on any system without Docker. Adding Docker gives you a bunch of native platform and emulation pains you wouldn't have otherwise.

Why would the best candidates be put off by a low minimum? Their salary isn't going to have anything to do with the minimum.

If anything, the best candidates should prefer a wide range. That would mean there is more opportunity for them to distinguish themselves beyond just "years served".

The problem with your thesis is that many radiologists are paid per read. They're essentially contractors. These independent radiologists would gladly pay 100k/year for an AI that could do their jobs. Even if the tool didn't do diagnosis, just made them 50% faster, they would gladly pay a huge amount of money.

Contrast this with the field of Radiation Oncology. There are already AI auto-contouring solutions that you can buy today. It's a better fit given the limitations of AI:

1) Contouring can take hours per patient, so more value is gained by automating it

2) Normal structures are, well, normal; that is that they are not the diseased part of the patient. If the AI can't quite figure out where the kidney is and fills it out with an average looking kidney, hey that's probably an alright guess!

3) The AI doesn't have to be perfect; dosimetrists and docs can quickly check and update the result if the algorithm fails. Everyone is already familiar with this workflow due to the atlas segmentation algorithms that were state-of-the-art before.

4) Similarly, the output is easy to understand. If the AI did something crazy because of a failure to generalize, it will be obvious. Not so for a diagnostic AI.

5) Clinicians have the final say on which contours are used for treatment. The liability for contour assistance is lower for the software vendor.

So does eclipse. The author seems unaware of similar solutions that have existed forever...

That's not what he's saying. He's saying the test should measure an externally visible detail. In this case that would be "is the list sorted". This way the test will still pass without maintenance if the sorting algorithm is switched again in the future. You can still consider the implementation to create antagonistic test cases.

in the year 2020, why are we expecting people to write compilable code on a whiteboard

I think this is the bad assumption that's causing your confusion. Maybe this happens, but I think it's very uncommon.

The point of using whiteboards is to focus more on algorithms, data structures, and problem solving, not just spitting out code. If you make the applicant write actual code it limits the scope of the questions that can be asked.

So, it's actually beneficial that whiteboards aren't good for writing compilable code, because that's not what you want the applicant to do.

No it's not. They're still allowing an exception that allows any number of online classes. They're just requiring at least one in-person credit, and for the university to say it is at least partially open.

Weird article. After reading it I agree more with the points it's trying to refute.

You can't use the existence of a 1995 law to prove the GDPR doesn't have problems. The whole reason the GDPR got written was because the 1995 law was ineffective.

The GDPR adds new requirements on top of the 1995 law. Privacy advocates don't think these requirements help privacy much. Businesses claim that it makes it harder to do business (but they say that about any legislation). You can argue about who is right but neither side particularly likes the regulation.

The biggest group of people who do like the regulation seem to be EU citizens who want a reason to feel superior to Americans. It's unfortunate nationalism. We're all on the same side against the large corporations.