Maybe you drive into flood waters, but I don't. That's not a difficult skill to pull off.
We're still in the early days of self driving cars, and as much simulation and miles as they have, they're still constantly getting exposed to real world conditions that are new to them. The world is dynamic, so this will always remain true.
It remains to be seen where we'll converge on capability, incident rate, and acceptance.
Maybe you don't drive into flood waters, but your Uber driver might, and that's what Waymo is trying to replace, not your personal driving.
In that context I think comparing it to the average human driver makes a lot of sense, because even if you personally are an even better driver, or even if human drivers are better at some specific things, we have more than enough data to show that Waymo reduces accident rates overall in their current rollout.
> It remains to be seen where we'll converge on capability, incident rate, and acceptance.
I think we're already there with Waymo as the example. We may later choose to diverge from this now-accepted path, but for the moment we have a blueprint, and fixing edge cases with a software update is apparently acceptable, if you just look at all the Waymos operating legally right now.
The world is dynamic, so sure, it will always be true in some technical sense. But I am confident that eventually we’ll have trained them on enough scenarios that novelty will have a smaller and smaller effect on their ability to safely navigate through the world.
My most enjoyable and productive experiences with AI so far have looked more like pair-programming than agent-based vibe coding. That is to say, I care about the details, and I want to read, understand, edit, and curate the codebase. I find that if I'm not limiting AI to relatively small enhancements per request-review cycle (100 or so LOC), then when things inevitably go off the rails, I'm in a deep hole that takes a long time to climb out of.
I haven't tried out Junie yet, but the concept seems pretty compelling to me. I want a good IDE for the language I'm using, and I'd like an AI that's well integrated and trained on delegating to it for algorithmic/deterministic transforms (e.g. IDE-driven refactorings).
They take about the same time as with an ICE. I stop and charge for 20m whenever I need a restroom break or some food (every couple hours or so). My car generally goes longer without stopping than I do.
If you're stopping often or long, something is wrong with your setup.
I just drove 100mi in freezing temps (around 25F) at mostly interstate speeds (70+) mph. I completed my trip around 95% of EPA. Maybe a function of the quality of your EV.
I know congestion can be an issue at some sites, but I have never waited in line to charge in seven years of EV ownership.
In addition, for superchargers, you can see real-time stall availability, so if a particular site was crowded, you could just opt for the next. (Easy enough to do since there are so many).
Is that legally enforceable? If a mod doesn't contain code / assets from the game itself, what legal rights does Microsoft have over the distribution of that mod?
Yes courts have found that game mods, even if they don't directly include any content from the original game in their distributable, count as derivative works under copyright.
> The ruling continues to apply to the legal status of video game modding, with mods viewed as derivative works that require the consent of the copyright holder. While this may legally limit the creation of mods, machinima, broadcasts, or even cheats, many game developers have authorized and encouraged some of these activities.
Teslas illuminate brake lights based on deceleration (until reaching a stop), which is the desired behavior. I use regen braking aggressively to slow down, and different light behavior would give people seizures or make them brake-light-deaf.
If you're annoyed by the braking lights on a Tesla, it's because you're following too (dangerously) closely.
Slava mentions both bidirectional inferencing and overloading as two of the big culprits.
I've been doing some language work recently, and I'm quite sympathetic to bidirectional inferencing. I think, though, that modern PLs need better solutions for adhoc overloading. It's notorious for its complexity, blowing up algorithmically, and confusing users with surprising results (why oh why did the compiler select this function over the one I intended). That said, I haven't discovered a good alternative (for my purposes) yet.
The paper The Simple Essence of Overloading: Making Ad-Hoc Polymorphism More Algebraic with Flow-Based Variational Type-Checking, should help with the overloading part hopefully
No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.
> The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.
I think the ExpressibleBy thing means that a string literal can be interpreted to mean any of those 9 types. Personally I agree with you; I would actually suggest that the compiler error out if there are anywhere near this many interpretations of an expression. Apparently the corrected expression compiles in 0.19s, which is unacceptable to me. I would much rather pay the cost once of adding a few type annotations or intermediate expressions than pay that fifth of a second over and over and over again for every recompile of that file. Since the types a pretty global constraint system, the expression is a landmine as well: you could fiddle with some distant overload which causes it to attempt the permutations in a different order and suddenly start timing out again.
I would rather just have a flag to require type annotations to simply not have to worry about this. I find code much harder to read without them anyway.
We're still in the early days of self driving cars, and as much simulation and miles as they have, they're still constantly getting exposed to real world conditions that are new to them. The world is dynamic, so this will always remain true.
It remains to be seen where we'll converge on capability, incident rate, and acceptance.