3 ms·

>Using the same language everywhere. Naturally, if we want to share type information as much as possible, we need to be using the same language This goes to th

>Using the same language everywhere. Naturally, if we want to share type information as much as possible, we need to be using the same language This goes to the heart of what's not great about this, types impose global semantics on a piece of software, they introduce coupling. (It's why Alan Kay used to stress "late binding of all things") as a feature of managing complexity. In fact one result of this kind of programming were microservices. What do they do? Reintroduce runtime dynamism. It's not often framed that way but there's a reason you see more statically typed microservices than Lisp or Erlang ones. It's because they're an attempt to get away from the coupling imposed by type driven programming and towards more independence of each service. Which is already baked into message based, dynamic languages. And there's also a fundamental misunderstanding about data and types in the article. > Making our types represent the “truth” 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.

esafak 2y ago
> 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.
- leeeeeepw 2y ago
  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
  - msanlop 2y ago
    > 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
- ervine 2y ago
  Not if your types represent something you don't control, like an API response.
  - DangitBobby 2y ago
    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.
    - ervine 2y ago
      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.
Garlef 2y ago
> 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.
pavel_lishin 2y ago
> 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.
tikhonj 2y ago
> 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.
turbojet1321 2y ago
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.

esafak 2y ago

> 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.

leeeeeepw 2y ago
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
- msanlop 2y ago
  > 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
ervine 2y ago
Not if your types represent something you don't control, like an API response.
- DangitBobby 2y ago
  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.
  - ervine 2y ago
    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.

Garlef 2y ago

> 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.

pavel_lishin 2y ago

> 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.

tikhonj 2y ago

> 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.

turbojet1321 2y ago

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.