Because beforehand engineers could be reasonably confident that their work would simply accelerate a the growth of a growing pie; today, most expect that further development will be used, first and foremost, to replace labor. Most sectors do not grow indefinitely, so there's no reason to assume software has to.
To put it gently, yes it feels different: for people who haven't already saved a lifetime of SWE wages, this is the first credible threat to the sector in which they're employed since the dot com bubble. People need to work to eat.
> iPhone and macOS are basically the same product technically
This seems hard to justify. They share a lot of code yes, but many many things are different (meaningfully so, from the perspective of both app developers and users)
Lockdown mode costs ~nothing for devices that don't have it enabled. GP is pointing out that the straightforward way to implement this feature would not have that same property.
You'd be surprised how many Apple engineers are fixing many bugs, of this caliber, on a semi-regular basis.
That "Human Hours Wasted" is not just sitting there because engineers don't care about it, it's because there are many many other opportunities to save similar amounts of time. Crashes waste time, perf bugs waste time -- and security bugs are much worse.
I really doubt everyone or even a tiny fraction of people at Apple are working on opportunities to save more time than fixing the repeated autocorrect issue. It affects everyone and it's been a meme since forever.
At this scale, some bugs become features. I think fixing the bugs would need lots of conceptual work, due to the fact that there are millions of users of these apps.
JavaScript isn't the only programming language around. I'm not the strongest around with JS either but I can figure it out as necessary -- knowing C/C++/Java/whatever means you can still grok "this looks better than that" for most cases.
Yep. I have plenty of experience in languages that use C-style syntax, enough to easily understand code written in other languages that occur nearby in the syntactical family tree. I'm not steeped in JS enough to know the weird gotchas of the type system, or know the standard library well, etc. But I can read the code fine.
If I'd asked an AI coding tool to write something up for me in Haskell, I would have no idea if it had done a good job.
This doesn't sound right to me. If someone who were expert in JS looked at a relatively simple C++ program, I think they could reasonably well tell if the quality of code were good or not. They wouldn't be able to, e.g., detect bugs from default value initialization, memory leaks, etc. But so long as the code didn't do any crazy templating stuff they'd be able to analyze it at a rough "this algorithm seems sensible" level".
Analogously I'm quite proficient at C++, and I can easily look at a small JS program and tell if it's sensible. But if you give me even a simple React app I wouldn't be able to understand it without a lot of effort (I've had this experience...)
I agree with your broad point: C/C++/Java are certainly much more complex than JS and I would expect someone expert in them to have a much easier time picking up JS than the reverse. But given very high overlap in syntax between the four I think anyone who's proficient in one can grok the basics of the others.
Why? How is it "discrimination" if it actually corresponds to a single user, who has been doing bad things to your server (e.g. slamming it with requests)? Do you expect to be able to go and knock on people's doors all day and not have them tell you off?
I think most have moved past SWE-Bench Verified as a benchmark worth tracking -- it only tracks a few repos, contains only a small number of languages, and probably more importantly papers have come out showing a significant degree of memorization in current models, e.g. models knowing the filepath of the file containing the bug when prompted only with the issue description and without having access to the actual filesystem. SWE-Bench Pro seems much more promising though doesn't avoid all of the problems with the above.
swe-REbench is interesting. The "RE" stands for re-testing after the models were launched. They periodically gather new issues from live repos on github, and have a slider where you can see the scores for all issues in a given interval. So if you wait ~2 months you can see how the models perform on new (to them) real-world issues.
It's still not as accurate as benchmarks on your own workflows, but it's better than the original benchmark. Or any other public benchmarks.
If monopolies are "non capitalistic", then why has every capitalist economy in history had such a tendency towards creating large monopolies? The same cab certainly not be said any those economies producing, say, worker control of the means of production.
To put it gently, yes it feels different: for people who haven't already saved a lifetime of SWE wages, this is the first credible threat to the sector in which they're employed since the dot com bubble. People need to work to eat.
reply