5 ms·

This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, t

This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, the language has to be designed with this property from the beginning. Yes, you should always enforce complete checking in CI. But you should also be able to try half-baked ideas.

zogrodea 2y ago
There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing. The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest. [0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program." https://blog.darklang.com/real-problems-with-functional-languages/ https://blog.darklang.com/real-problems-with-functional-lang... [1] "If you like, you can run a program that has compile-time errors like this. (If the program reaches the error at runtime, it will crash.)" https://www.roc-lang.org/friendly https://www.roc-lang.org/friendly
- valcron1000 2y ago
  Let me introduce you to `-fdefer-type-errors` in GHC Haskell: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defer_type_errors.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe...
  - zogrodea 2y ago
    That's pretty cool! Wouldn't have guessed that Haskell would has had this feature since 2015.
duped 2y ago
> Type checkers shouldn't get in the way of your code compiling. I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed. I understand (and have used in production) optionally/gradually typed languages, and without fail codebases will opt for using types up front and not ignoring type check failure because they are always incorrect. A type error is the compiler/run time telling you "I don't understand what you told me" so why do you want to ignore that? And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with. It should be easy to pull in what you need and play with it without affecting everything else if you haven't done a bad job of architecting the codebase.
- ativzzz 2y ago
  Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good. Sometimes, it's useful to bypass these things for a prototype and you don't care if it crashes on any edge case. This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code
  - dbrueck 2y ago
    Exactly this. Typing in the final version is great. Typing up front is almost always getting in the way. Most interesting programs involve a lot of figuring things out as you go, and so any "tax" on that process is one you hope to avoid. The last thing you want is for the language itself to be the source of that tax any more than it has to be.
  - whytevuhuni 2y ago
    I agree with this, but I don't think dynamic types is the only solution. Something like Roc[0] strikes a better balance: it gives you a flag for development, and when enabled, all compilation errors become warnings. The compiler substitutes every function it couldn't compile with one that panics at runtime. [0] https://www.roc-lang.org/ https://www.roc-lang.org/
hot_gril 2y ago
It's also pointless to care about types in fine-scoped code. Like if your language forces me to assert that i is an integer like this, something is wrong... for (int i = 0; i < n; i++) And when I'm writing backends, usually there will be no types anywhere except at the API layer, i.e. OpenAPI spec or protocol buffers. Not once have I encountered a bug related to accidental wrong types that wasn't caught at this outermost layer.

zogrodea 2y ago

There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing. The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest. [0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program." https://blog.darklang.com/real-problems-with-functional-languages/ https://blog.darklang.com/real-problems-with-functional-lang... [1] "If you like, you can run a program that has compile-time errors like this. (If the program reaches the error at runtime, it will crash.)" https://www.roc-lang.org/friendly https://www.roc-lang.org/friendly

valcron1000 2y ago
Let me introduce you to `-fdefer-type-errors` in GHC Haskell: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defer_type_errors.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe...
- zogrodea 2y ago
  That's pretty cool! Wouldn't have guessed that Haskell would has had this feature since 2015.

duped 2y ago

> Type checkers shouldn't get in the way of your code compiling. I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed. I understand (and have used in production) optionally/gradually typed languages, and without fail codebases will opt for using types up front and not ignoring type check failure because they are always incorrect. A type error is the compiler/run time telling you "I don't understand what you told me" so why do you want to ignore that? And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with. It should be easy to pull in what you need and play with it without affecting everything else if you haven't done a bad job of architecting the codebase.

ativzzz 2y ago
Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good. Sometimes, it's useful to bypass these things for a prototype and you don't care if it crashes on any edge case. This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code
- dbrueck 2y ago
  Exactly this. Typing in the final version is great. Typing up front is almost always getting in the way. Most interesting programs involve a lot of figuring things out as you go, and so any "tax" on that process is one you hope to avoid. The last thing you want is for the language itself to be the source of that tax any more than it has to be.
- whytevuhuni 2y ago
  I agree with this, but I don't think dynamic types is the only solution. Something like Roc[0] strikes a better balance: it gives you a flag for development, and when enabled, all compilation errors become warnings. The compiler substitutes every function it couldn't compile with one that panics at runtime. [0] https://www.roc-lang.org/ https://www.roc-lang.org/

hot_gril 2y ago

It's also pointless to care about types in fine-scoped code. Like if your language forces me to assert that i is an integer like this, something is wrong... for (int i = 0; i < n; i++) And when I'm writing backends, usually there will be no types anywhere except at the API layer, i.e. OpenAPI spec or protocol buffers. Not once have I encountered a bug related to accidental wrong types that wasn't caught at this outermost layer.