11 ms·

I am not convinced of the utility of how good type annotations are in the long term. I think static typing is a very fundamental part of language design that a

I am not convinced of the utility of how good type annotations are in the long term. I think static typing is a very fundamental part of language design that affects the entire language. To make static typing ergonomic without massive boilerplate, you also need concepts like generics, co and contra-variance, type inference, and other things that dynamically typed languages never have to really concern themselves with. When you try to bolt it on afterwards, I think you can end up with a lot of foot guns and corner cases and a false sense of security.

Too 3y ago
Typescript and Python managed to pull it off. With a result that in many ways allows both expressing stricter, yet more fluid typing, compared to languages traditionally considered static. The false sense of security they give is not a problem. As with testing, this is not a black or white answer, having more is better than having nothing. You could also argue they are more strict by allowing more richer types like unions and structural typing, letting you strictify things that you in C# or Java would have solved with non type safe Dictionary<String,Object>, instanceof(), overloads galore or layers upon layers of AbstractFactories.
LesZedCB 3y ago
i personally really like the idea of what clojure has done with spec or malli instead of type annotations. it just feels to me more like what rubyists want: pragmatic validation of "does this quack?" but like you say, i'm not sure ergonomics can be brought up to the level of ease/happiness to be used regularly
itake 3y ago
I've worked in multiple systems written in python, ruby, and JS where an untyped dict|hash|object is passed from function to function. In each function, keys are read; keys are written; keys are deleted. Tracking params were actually called by each function was a nightmare. If this "magic" dictionary was sourced from a schemeless api or database, it was impossible to figure out the schema of this dict without running the code in production.
lloeki 3y ago
> I am not convinced of the utility of how good type annotations are in the long term. Anecdata: adding typing (via Sorbet, then RBS) to multiple projects over the years uncovered many corner case (and not-so-corner case but non obvious) bugs, some subtle but critical, before they ended up crashing production. I can vouch with real life experience that it is useful. RBS+Steep is so useful I inadvertently found myself† beginning to write type-first, describing my code in .rbs files then filling in the implementation. Thinking in types has helped me uncovered issues right at the idea stage when I could have produced a smart^Wfatally flawed implementation that would still work thanks to Ruby's dynamism (mind you, Ruby's dynamism is great, it is merely a tool to be wielded at appropriate times) † Which is kinda useful as a "ok this thing works" rule of thumb in my book
akavi 3y ago
Have you used typescript? Because to my eyes, that's a massively successful "bolted on" type system. Sure there're holes in the system, but the utility is significant, especially relative to the cost.
- dalyons 3y ago
  Typescript is more successful by the numbers than almost all “native” typed languages
  - bilalq 3y ago
    Not just more successful in terms of adoption, but safer even than many "native" typed languages. You can never really tell if a random method in Java can return null without reading through its source and the transitive source of anything it may potentially call. And with dynamic dispatch, this becomes literally impossible. That Java virus of null contaminates other JVM languages like Scala too. It's even worse because you can have Option types that are themselves potentially nullable. Some/None/null is a terrible situation to be stuck in. And then the expressiveness of the type system there is also really pragmatic. You can't natively express union types in Java and many other static languages without writing your own Either monad implementation. Instead, you often wind up with code that has objects with a hodge-podge of field sets that are nullable. It's nothing short of miraculous how well the null-safety situation is in TypeScript. It's built on the back of community-driven types in DefinitelyTyped where the maintainers of libs often aren't the ones writing and keeping types up to date. Nowadays, types are becoming more and more first-party, but it still amazes me how we got to this point.
codr7 3y ago
Yeah, I just duplicated a Go method because it wouldn't accept a typed vararg as untyped (...any), and methods can't be generic either. I would rather not have static types at all than a not-quite-complete type system. I find Common Lisp's gradual approach to types very convenient.
eric-hu 3y ago
The author speaks to this in the blog post too. > The “this can be typed, this can’t” approach would most probably lead to a schism unseen before: splitting of the community into those who prefer type-annotated code and consequently became reluctant to any of the most expressive and dynamic features—and everyone else. I'm an active user of Sorbet at work, and I can see this happening even with my own opinions. On the one hand, I don't want to see the Ruby ecosystem fractured more, but on the other, I've seen clear benefits from helping add static typing to my team's project. I didn't really know much about Steep at the time, so I pushed for Sorbet. My first preference was actually Ruby 3 types, but when I looked into implementing them, I found they provided much weaker guarantees than Sorbet. The tooling also wasn't there.

Too 3y ago

Typescript and Python managed to pull it off. With a result that in many ways allows both expressing stricter, yet more fluid typing, compared to languages traditionally considered static. The false sense of security they give is not a problem. As with testing, this is not a black or white answer, having more is better than having nothing. You could also argue they are more strict by allowing more richer types like unions and structural typing, letting you strictify things that you in C# or Java would have solved with non type safe Dictionary<String,Object>, instanceof(), overloads galore or layers upon layers of AbstractFactories.

LesZedCB 3y ago

i personally really like the idea of what clojure has done with spec or malli instead of type annotations. it just feels to me more like what rubyists want: pragmatic validation of "does this quack?" but like you say, i'm not sure ergonomics can be brought up to the level of ease/happiness to be used regularly

itake 3y ago

I've worked in multiple systems written in python, ruby, and JS where an untyped dict|hash|object is passed from function to function. In each function, keys are read; keys are written; keys are deleted. Tracking params were actually called by each function was a nightmare. If this "magic" dictionary was sourced from a schemeless api or database, it was impossible to figure out the schema of this dict without running the code in production.

lloeki 3y ago

> I am not convinced of the utility of how good type annotations are in the long term. Anecdata: adding typing (via Sorbet, then RBS) to multiple projects over the years uncovered many corner case (and not-so-corner case but non obvious) bugs, some subtle but critical, before they ended up crashing production. I can vouch with real life experience that it is useful. RBS+Steep is so useful I inadvertently found myself† beginning to write type-first, describing my code in .rbs files then filling in the implementation. Thinking in types has helped me uncovered issues right at the idea stage when I could have produced a smart^Wfatally flawed implementation that would still work thanks to Ruby's dynamism (mind you, Ruby's dynamism is great, it is merely a tool to be wielded at appropriate times) † Which is kinda useful as a "ok this thing works" rule of thumb in my book

akavi 3y ago

Have you used typescript? Because to my eyes, that's a massively successful "bolted on" type system. Sure there're holes in the system, but the utility is significant, especially relative to the cost.

dalyons 3y ago
Typescript is more successful by the numbers than almost all “native” typed languages
- bilalq 3y ago
  Not just more successful in terms of adoption, but safer even than many "native" typed languages. You can never really tell if a random method in Java can return null without reading through its source and the transitive source of anything it may potentially call. And with dynamic dispatch, this becomes literally impossible. That Java virus of null contaminates other JVM languages like Scala too. It's even worse because you can have Option types that are themselves potentially nullable. Some/None/null is a terrible situation to be stuck in. And then the expressiveness of the type system there is also really pragmatic. You can't natively express union types in Java and many other static languages without writing your own Either monad implementation. Instead, you often wind up with code that has objects with a hodge-podge of field sets that are nullable. It's nothing short of miraculous how well the null-safety situation is in TypeScript. It's built on the back of community-driven types in DefinitelyTyped where the maintainers of libs often aren't the ones writing and keeping types up to date. Nowadays, types are becoming more and more first-party, but it still amazes me how we got to this point.

codr7 3y ago

Yeah, I just duplicated a Go method because it wouldn't accept a typed vararg as untyped (...any), and methods can't be generic either. I would rather not have static types at all than a not-quite-complete type system. I find Common Lisp's gradual approach to types very convenient.

eric-hu 3y ago

The author speaks to this in the blog post too. > The “this can be typed, this can’t” approach would most probably lead to a schism unseen before: splitting of the community into those who prefer type-annotated code and consequently became reluctant to any of the most expressive and dynamic features—and everyone else. I'm an active user of Sorbet at work, and I can see this happening even with my own opinions. On the one hand, I don't want to see the Ruby ecosystem fractured more, but on the other, I've seen clear benefits from helping add static typing to my team's project. I didn't really know much about Steep at the time, so I pushed for Sorbet. My first preference was actually Ruby 3 types, but when I looked into implementing them, I found they provided much weaker guarantees than Sorbet. The tooling also wasn't there.