Absolutely amazing, kudos. Seems so evident in retrospect, but it takes someone with granular sensibility to think about it. Additionally to the idea being very good, I love the API.
Cool talk/idea. I would point out one issue with the zod slide. In 99% of cases, you only need to define the schema and then infer the type. There is no need to have both a schema and type in most cases (at least, from my exp) const coolStringSchema = z.string(); type CoolString = z.infer; // It's also possible to use specifically the "input" or "output" version of // the schema in the case of transforms type CoolStringIn = z.input; type CoolStringOut = z.output; // default of z.infer
just watched again, the elegance of simplicity strikes hard. kudos! "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. Tony Hoare" hopefully, you get support to continue this work...
Or you can do what common lisp (in particular SBCL) does, add type inference within the runtime itself, when you type a function in the REPL you get the type analysis, and is Hindle Millner analysis. Steel-Bank Common Lisp uses the type analysis to increase performance of the code, due to its standard definition you can add type hints respecting the syntax predefined in the 1980s using primitives like `declare` Or you can use what Verse a functional-logic programming language for video-games by Epic does, uses functions as contracts in Scheme to use as types, oops we go back to Lisp baby. Maybe JavaScript should've never acquired the filthy Java -ness.
A more production ready version of this idea is: Flow + Flowtate comments. No new syntax. Just comments for annotations. The type checker runs as a server, just like a “linter”. No runtime cost. var x/*: int */ = 5; function add(a/*: number */, b/*: number */)/*: number */ { return a + b; }
So much work on type-safe JS, but I doubt type-safety issues have cost me a day's work in the last 5 years total without any type checking. Who are these developers with type-safety issues and what the hell are they writing? :)
In large codebases, types are documentation. Even sans the type safety, they are invaluable for developer productivity. This effect would be less pronounced in small codebases.
Well said! Well written, well tested code does not require types. Big or small team. Big or small software. I don't understand the desperate need for types - almost feels like an addiction. Tests are much better at keeping you safe, types just slow you down and give you a false sense of security. If you test your code you don't need types.
@@theguatemalian I agree and disagree 😃 I don't find that losing a type system necessitates more tests than are otherwise useful, and I think that the cognitive load then goes on the developer is precisely the reason tests win over types for me, I want my engineers to *think* - I find type systems tend to be a false sense of security, and when you strip that away and it's just you and your tests you tend to give them the attention they deserve. Tests force you to understand what you're doing before you do it, they force you to write modular, pliable code, they automatically document expectations and interfaces, and then on top of that they can automatically verify them... At runtime, not statically! At the end of the day we care what the code does what we want when it's running, not when it's building. That said, I wouldn't throw away types altogether in a real life situation. They are very useful when working in a team, for example. It does irk me when engineers get distracted fiddling with appeasing type systems and linters and forget higher level tests, though. So often I get into a codebase and find compiler and lint settings are maxed out to the point of annoyance and yet there are no tests - no unit tests, no integration or deployment tests, no synthetics, no telemetry, error reporting, logging... It's incredible how common this is! I just wish more people knew the power of TDD. And I think a good way to do that is strip away type systems, take off the training wheels! Happy for you to disagree though of course 😁 disagreement is what drives ideas forward!
Absolutely amazing, kudos. Seems so evident in retrospect, but it takes someone with granular sensibility to think about it. Additionally to the idea being very good, I love the API.
This is such an incredible idea! I’m all for it!
Loved it! For a lot of things I can see how this would be very useful, great talk!
Wonderful, I especially love the generics implemented via functions on types. Like Zig which I discovered recently!
Cool talk/idea. I would point out one issue with the zod slide.
In 99% of cases, you only need to define the schema and then infer the type. There is no need to have both a schema and type in most cases (at least, from my exp)
const coolStringSchema = z.string();
type CoolString = z.infer;
// It's also possible to use specifically the "input" or "output" version of
// the schema in the case of transforms
type CoolStringIn = z.input;
type CoolStringOut = z.output; // default of z.infer
This is genius.
So simple... yet genius...
Love it.
just watched again, the elegance of simplicity strikes hard. kudos!
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
Tony Hoare"
hopefully, you get support to continue this work...
Very cool approach!
Excellent talk!
Or you can do what common lisp (in particular SBCL) does, add type inference within the runtime itself, when you type a function in the REPL you get the type analysis, and is Hindle Millner analysis. Steel-Bank Common Lisp uses the type analysis to increase performance of the code, due to its standard definition you can add type hints respecting the syntax predefined in the 1980s using primitives like `declare`
Or you can use what Verse a functional-logic programming language for video-games by Epic does, uses functions as contracts in Scheme to use as types, oops we go back to Lisp baby. Maybe JavaScript should've never acquired the filthy Java -ness.
A more production ready version of this idea is:
Flow + Flowtate comments.
No new syntax. Just comments for annotations.
The type checker runs as a server, just like a “linter”.
No runtime cost.
var x/*: int */ = 5;
function add(a/*: number */, b/*: number */)/*: number */ {
return a + b;
}
So much work on type-safe JS, but I doubt type-safety issues have cost me a day's work in the last 5 years total without any type checking. Who are these developers with type-safety issues and what the hell are they writing? :)
I run into undefineds just about every debugging session I run into, I'm impressed you don't!
In large codebases, types are documentation. Even sans the type safety, they are invaluable for developer productivity. This effect would be less pronounced in small codebases.
What kind of software are you building? I work on a large react codebase with multiple other teams and not having types there is simply not a option
Well said! Well written, well tested code does not require types. Big or small team. Big or small software. I don't understand the desperate need for types - almost feels like an addiction. Tests are much better at keeping you safe, types just slow you down and give you a false sense of security. If you test your code you don't need types.
@@theguatemalian I agree and disagree 😃 I don't find that losing a type system necessitates more tests than are otherwise useful, and I think that the cognitive load then goes on the developer is precisely the reason tests win over types for me, I want my engineers to *think* - I find type systems tend to be a false sense of security, and when you strip that away and it's just you and your tests you tend to give them the attention they deserve.
Tests force you to understand what you're doing before you do it, they force you to write modular, pliable code, they automatically document expectations and interfaces, and then on top of that they can automatically verify them... At runtime, not statically! At the end of the day we care what the code does what we want when it's running, not when it's building.
That said, I wouldn't throw away types altogether in a real life situation. They are very useful when working in a team, for example. It does irk me when engineers get distracted fiddling with appeasing type systems and linters and forget higher level tests, though. So often I get into a codebase and find compiler and lint settings are maxed out to the point of annoyance and yet there are no tests - no unit tests, no integration or deployment tests, no synthetics, no telemetry, error reporting, logging... It's incredible how common this is!
I just wish more people knew the power of TDD. And I think a good way to do that is strip away type systems, take off the training wheels!
Happy for you to disagree though of course 😁 disagreement is what drives ideas forward!