I agree that devices should work independently. But I believe the fundamental baseline should be open interoperability. Yes, the dishwasher should allow a delayed start from the machine itself. But it should also have secure yet open interoperability so other authorised systems that care about the dishwasher can interact with it. I think there's ultimately a user experience benefit. I'm familiar with my phone, its UI paradigms etc. If I (or my gran) can use the dishwasher through an interface or voice assistant we're already familiar with then that's a win. Especially if the form factor of the device itself makes it challenging to deliver a great and intuitive interface in-situ.
In this regard CarPlay is evidence of success - a sufficiently interoperable car that allows users to bring their own context and ecosystems.
CarPlay is only evidence of failure if your expectation is that the car should provide a comparable ecosystem to Android or iOS - one that must also somehow follow you in your pocket when you leave the car.
I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
Yes that's true, but there's effort to consider on both sides of design decisions like those TypeScript has made. Much of the compile time behaviour comes from the decision for TypeScript to be incremental on top of JavaScript. That allows you to start getting the benefit of TS without the effort of having to rewrite your entire codebase, for example. Having used TS for many years now I feel that the balance it strikes is incredibly productive. Maybe for other folks/projects the tradeoff is different - but for me I would hate going back to plain JS, and there's no alternative available with such tight integration with the rest of the web ecosystem.
Because adding types adds constraints across the codebase that detect a broader set of mistakes. It's like saying what's the point of putting seatbelts into a car if they only work when you're wearing them - yes you can use them wrong (perhaps even unknowingly), but the overall benefit is much greater. On balance I find that TypeScript gives me huge benefit.
No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.
I wonder if there's a correlation here with new versions of iOS being released around the same time as new phones? Is it possible that OS optimization takes a back seat to bug fixes during the run up to release then subsequent point releases improve performance?
In this regard CarPlay is evidence of success - a sufficiently interoperable car that allows users to bring their own context and ecosystems.
CarPlay is only evidence of failure if your expectation is that the car should provide a comparable ecosystem to Android or iOS - one that must also somehow follow you in your pocket when you leave the car.