I agree that the primary feature of CSS is what people don't want from it anymore. If you're building your app with components (web components, react, etc), those become the unit of reuse. You don't need CSS to offer an additional unit of reuse, it only complicates things at that point.
This is a great point. Style reuse was the dream of CSS, but we have all mostly settled that that's too fine grained for anything beyond a simple website. It's much easier to build, share, reuse a bunch of components.
This is technically true, but misses the point. Tailwind classes are fine grained utility classes, the fact that they are CSS classes at all is pretty much an implementation detail.
Compare tailwind classes to bootstrap classes and you'll see what I mean.
>Last month, Tesla confirmed the fleet had traveled roughly 250,000 miles. With 7 reported crashes at the time, Tesla’s Robotaxi was crashing roughly once every 40,000 miles (extrapolating from the previously disclosed Robotaxi mileage).
>For comparison, the average human driver in the US crashes about once every 500,000 miles.
The capitalization the parent poster used on Robotaxi may have been intentional to assist with interpretation. While it can be a generic term, I believe only Tesla uses it as a brand name: https://www.tesla.com/robotaxi
Robotaxi: Tesla's autonomously driven ride hailing service. Currently using Model Y's or whatever, maybe using Cybercabs once those actually exist, maybe eventually also leveraging Tesla vehicles owned by others (lmao no one who has though that through for more than a minute or two actually wants to risk their vehicle like that)
Cybercab: A Tesla vehicle explicitly built for the Robotaxi service, containing no driver controls whatsoever because they're expected to operate without any (local) human oversight
Some studies are better than others, and headlines / secondary sources don’t do enough to comment on this, but looking the source and having an opinion about their methodology, sample size, etc. can help a lot.
Soon the only way to assure your readers that your writing is human is by calling them a motherfucker in the opening sentence.
But then, you'd only be sure that the first sentence was legitimate and not the rest of the article. That is why I constantly reassure my readers that they're some goddamn motherfuckers throughout my writing. And you, too, are one, my friend.
It’s not as technically impressive, but my toddler was very impressed by the R2D2 that was making its rounds in the park. Not part of a show; you could go right up to it. Probably the only character where the theme park robot is really indistinguishable from the real thing.
To help prevent confusion: Clair Obcur was not stripped of its record-breaking 9 awards at the Game Awards.
The Indie Game Awards, despite sounding similar to The Game Awards, is an unrelated organization that holds their awards the same week. They are small and this is their second year.
I've been thinking about this all day. I think the best approach is probably twofold:
1) Thrown errors should track the original error to retain its context. In JavaScript errors have a `cause` option which is perfect for this. You can use the `cause` to hold a deep stack trace even if the error has been handled and wrapped in a different error type that may have a different semantics in the application.
2) For logging that does not stop program execution, I think this is a great case for dependency injection. If a library allows its consumer to provide a logger, the application has complete control over how and when the library logs, and can even change it at runtime. If you have a disagreement with a library, for example it logs errors that you want to treat as warnings, your injected logger can handle that.
I have a feeling that the real work of writing a complex application is in fully understanding the domain logic in all its gory details and creating a complete description of your domain logic in code. This process that OP is going through seems to be "what if I materialize the domain logic in tests instead of in code." Well, at first blush, it seems like maybe this is better because writing tests is "easier" than writing code. However, I imagine the biggest problem is that sometimes it takes the unyielding concreteness of code to expose the faults in your description of the domain problem. You'd end up interacting with an intermediary, using the tests as a sort of interpreter as you indirectly collaborate with the agent on defining your application. The cost of this indirection may be the price to pay for specifying your application in a simpler, abstracted form. All this being said, I would expect the answers to "is it easier? is it faster?" would be: well, it depends. If it can be better, it's certainly not always better.
Its not mutually exclusive. We write test precisely because expressing a complex application is hard without them. But to your point, we should not wave away applications that cannot be understood with extra tests. I agree.
reply