4 ms·

Can you comment on why a good type system became so important to you? I can understand the value in interfaces but not really in any other context.

empath75 8y ago
Fewer run time errors. Easier testing, among other things.
tyre 8y ago
Not having `nil` is soooo nice. I can't count the number of `Runtime Error`s because some method isn't defined on `NilClass` that have blown things up in weird edge cases. Knowing exactly what types a method takes and the compiler catching incorrect uses before the code ever runs saves a lot of frustration. Another thing I've enjoyed in Rust include `match` clauses forcing me to define branches for any possibility, especially for `Result` structs. In ruby this isn't possible because anything can be anything.
- ken 8y ago
  There's got to be more to it than "has / doesn't have nil". Lisp has nil, and I rarely if ever see an analogous error there, or even a type error. I have a hunch that single/static dispatch is what tends to cause more problems than merely the presence of nil. It's not nil, but how you use it.
  - akjha 8y ago
    "It's not nil, but how you use it." Can you elaborate on how multi-dispatch reduces the issue of nil/null? I also use static type (typescript) to prevent issues with nil and would like to know how I can achieve the same in a dynamic language.
    - jashmatthews 8y ago
      You can prevent nil errors using contracts like in Eiffel and Clojure.
tanin 8y ago
For a non-strong-typed language, it's difficult to dive into the code after you haven't work on that codebase for a while. We were on a really old Mongoid (or carrierwave, or some other gem, can't remember), It was difficult to find the right methods to use and etc. I understand it was our own fault not to write comprehensive tests or keep all gems up-to-date. But a dynamic typing language is a lot more "punitive" when we aren't writing perfect code, using perfect design, and/or exercising perfect engineering practices.
Redoubts 8y ago
Languages without ADTs and Optionals just feel impoverished.
- yxhuvud 8y ago
  Languages without full blown union types feel so impoverished. With good language typing support (including flow typing), optionals feel quite redundant.
  - int_19h 8y ago
    But optionals are just a union type (T | None).
- pjmlp 8y ago
  Languages without dependent types feel that something is still missing.
karmakaze 8y ago
The === for Range and Datetime serves as a one example, with a good type system they wouldn't be directly comparable.
QuinnWilton 8y ago
I can't type up a full answer right now, but for me, a strong type system is about being able to model my domain and bake all of my assumptions about that domain into the types I define. It's a lot easier for me to reason about and avoid edge cases when I can (more or less) verify at compile time that invalid states are impossible. This is about more than just catching null values, and also encompasses things like mutually exclusive fields, and access control. If you're interested, I gave a talk once that dives into these ideas more effectively than I can express in this comment: https://github.com/ShaneWilton/programming-with-types-talk/blob/master/readme.md https://github.com/ShaneWilton/programming-with-types-talk/b...

empath75 8y ago

Fewer run time errors. Easier testing, among other things.

tyre 8y ago

Not having `nil` is soooo nice. I can't count the number of `Runtime Error`s because some method isn't defined on `NilClass` that have blown things up in weird edge cases. Knowing exactly what types a method takes and the compiler catching incorrect uses before the code ever runs saves a lot of frustration. Another thing I've enjoyed in Rust include `match` clauses forcing me to define branches for any possibility, especially for `Result` structs. In ruby this isn't possible because anything can be anything.

ken 8y ago
There's got to be more to it than "has / doesn't have nil". Lisp has nil, and I rarely if ever see an analogous error there, or even a type error. I have a hunch that single/static dispatch is what tends to cause more problems than merely the presence of nil. It's not nil, but how you use it.
- akjha 8y ago
  "It's not nil, but how you use it." Can you elaborate on how multi-dispatch reduces the issue of nil/null? I also use static type (typescript) to prevent issues with nil and would like to know how I can achieve the same in a dynamic language.
  - jashmatthews 8y ago
    You can prevent nil errors using contracts like in Eiffel and Clojure.

tanin 8y ago

For a non-strong-typed language, it's difficult to dive into the code after you haven't work on that codebase for a while. We were on a really old Mongoid (or carrierwave, or some other gem, can't remember), It was difficult to find the right methods to use and etc. I understand it was our own fault not to write comprehensive tests or keep all gems up-to-date. But a dynamic typing language is a lot more "punitive" when we aren't writing perfect code, using perfect design, and/or exercising perfect engineering practices.

Redoubts 8y ago

Languages without ADTs and Optionals just feel impoverished.

yxhuvud 8y ago
Languages without full blown union types feel so impoverished. With good language typing support (including flow typing), optionals feel quite redundant.
- int_19h 8y ago
  But optionals are just a union type (T | None).
pjmlp 8y ago
Languages without dependent types feel that something is still missing.

karmakaze 8y ago

The === for Range and Datetime serves as a one example, with a good type system they wouldn't be directly comparable.

QuinnWilton 8y ago

I can't type up a full answer right now, but for me, a strong type system is about being able to model my domain and bake all of my assumptions about that domain into the types I define. It's a lot easier for me to reason about and avoid edge cases when I can (more or less) verify at compile time that invalid states are impossible. This is about more than just catching null values, and also encompasses things like mutually exclusive fields, and access control. If you're interested, I gave a talk once that dives into these ideas more effectively than I can express in this comment: https://github.com/ShaneWilton/programming-with-types-talk/blob/master/readme.md https://github.com/ShaneWilton/programming-with-types-talk/b...