> Types can't represent truth. Real world data doesn't have types. It changes incrementally however it wants, and all the time.

That's like saying "Maps can't represent truth". They're a model that works well enough, just like types do, if you do it right.

> Types can't represent truth. Real world data doesn't have types. It changes incrementally however it wants, and all the time. You can use types to not let something you don't want into your program, but you can never represent arbitrary real world data by matching types onto them.

That's true for static types... but it's just as true for the constructs in your dynamically typed code! Nothing about dynamic typing makes your logic or data representation any more adaptable, it just makes the rigid models inherent to your code implicit rather than explicit.

> you can never represent arbitrary real world data by matching types onto them.

I think that's why the article references the 'parse, don't validate' article: Real world data is messy and so you ingest it into your business logic at the system boundaries via parsing.

> Types can't represent truth. Real world data doesn't have types. It changes incrementally however it wants, and all the time.

What do you mean? If a variable is a date/time or an integer etc. in the real world it should stay that way and be represented as such in software.

AI chatbot example, you're chatting and then there could be some Mark down, latex, images maybe base64 encoded webp, audio files, we can type all this stuff do all the validations and such, understand it better and there's some gains to be had doing that, then likely someone like Facebook comes along with this Giant byte Transformer expert system with all of the data specific optimisations, that's kind of the bitter lesson but I guess the main point is that the problem itself of how to best communicate with AI is not necessarily solved so you can get bogged down typing the best possible ways to do it but it's a moving target.

Same with a lot of systems like say a search system that tracks data using the best embedding, well we don't know what that best embedding is in terms of price performance and encoded knowledge perf it's just a moving target.

Send me the system that tracks important metrics effecting the stock market, or a weather system etc... the sensors are all updating and then an entirely new thing comes along like Starlink that helps us track the weather in totally new ways

> get bogged down typing the best possible ways to do it but it's a moving target

As someone who is still learning this is a huge reason why I've come to love dynamic languages. Any project I do involves a lot of rewriting as the code evolves, I found that trying to predict ahead of time what the structures and types will be is mostly a waste of time. The best middle ground for me so far has been using python with type hints. It allows for quick iteration, I can experiment and only then update the types to match what I have, so that I can still get LSP help and all that.

But I could see this being less relevant with more experience

Not if your types represent something you don't control, like an API response.

Having runtime type validation utilities such as Typebox help here. Even in the absence of type guarantees at I/O boundaries (where you have to just "lie" about the type you really have, which would be `unknown` if we were honest), I'd certainly rather my code at least specify what types it expects from the server than attempt to access arbitrary attributes in various places.

Oh yeah definitely, I write the types that I expect from the API - the point the original comment is making is that the state of reality is not your types, it's what the actual API returns.

But yeah if you use something like Zod you can at least say "this is what I'm pretty sure the API should return" but also define what should happen if things change / don't meet your types.

The quote from the article is incorrect, though. We have a C# backend and a TS front end, with the shared types generated for TS using nswag. I'm sure there are many other variations on this, too.