6 ms·

Why is everything moving to types?

by cocochanel 7y ago

symlinkk 7y ago
Because TypeScript has proven that a type system can be helpful without being clunky and annoying.
- eru 7y ago
  I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.
  - bfung 7y ago
    ML family has "type inference", which means the compiler figured out the type even if not explicitly written into the code. However, the language spec is still statically typed - an int will not turn into a string and vice versa (ex: "1"). Javascript and ruby, the underlying types can change depending on where the code is in execution - a variable holding a 1 can turn into a "1" and back (implicit type conversion - try 3 * "3"). This leads to a whole class of bugs not possible in a statically typed codebase where explicit conversion needs to happen - I have no hard data, but I remember debugging this type of stuff far too often and far too many times when I could've spend my time better elsewhere. (but I actually like ruby a lot!) Type checking is not the same as being statically vs. dynamically typed!
    - abhorrence 7y ago
      > a variable holding a 1 can turn into a "1" and back This is true of Javascript, but not of Ruby. irb(main):001:)> 3 * "3" TypeError: String can't be coerced into Fixnum People commonly conflate dynamic typing with weak typing, Ruby has the former, but not the latter (with some explicit exceptions, e.g. to_ary and friends). That's not to say you can't still end up with some interesting problems though -- if we just slightly change your example: a = 3 b = 3 # later... a = "oops" product = a * b # product is now "oopsoopsoops" But this isn't due to automatic "weak types" style coercion -- just that Ruby lets you build a repeated string by multiplying a string by a number.
    - eru 7y ago
      The alternative view is that those so-called 'dynamically typed' or 'untyped' languages should really be called 'monotyped languages' since all variables and expressions have the same type: a giant union of all possibilities. See https://news.ycombinator.com/item?id=8206562 https://news.ycombinator.com/item?id=8206562
jaequery 7y ago
I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.
- tomc1985 7y ago
  So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?
  - joelbluminator 7y ago
    It rarely happens to me that I stare at a variable and have to wonder what type it is. And yes, an IDE like Rubymine is becoming crazy good at autocomplete and method lookup. I think the experience of developing on Rubymine isn't that far behind from Intellij nowadays. Not everyone have to use the same IDE, the vim or emacs guys will have to find equivalent tools.
  - Shish2k 7y ago
    C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable. How does nobody(?) support this yet? Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free, but "distanceInKm + distanceInKm" gives you an int instead of a distanceInKm; and "distanceInKm + distanceInMiles" gives you an int instead of an error. Rust also has partial support but from the other end: distanceInMiles and distanceInKm can be two distinct subclasses of int, and adding them together is a compile time error. But also adding distanceInMiles with distanceInMiles is a compiler error, because these are basically "completely new classes" rather than "subclasses of int", and so you have to implement add / subtract / stringify / etc for yourself for every type D: (I'm fairly new to Rust so if there is a shortcut there that I'm missing please do point it out)
westoque 7y ago
I believe it depends on the use case. If you notice, Stripe and Coinbase are the first few companies that use the type system. They are both dealing with financial systems and numbers in general where having types would help a lot in catching errors and bugs earlier. I've worked on financial systems before in a dynamic language, JavaScript, and from my experience there would be cases where a number would be passed from a place where it's a string (in a textfield) that then needs to be passed around as an integer at times. Type systems would help catch bugs here or in similar situations.
codesushi42 7y ago
There is benefit to future proofing code with basic static analysis for type checking. But it is always an incomplete solution because a) old code needs to be retrofitted, see TypeScript's way of defining type maps for vanilla JS or b) more commonly you keep the code around that's using unsafe types, effectively passing void*|Object|"choose your poison" around.
biql 7y ago
Harder to make bugs. Better documentation. Typed code is easier to optimize - just look at Crystal performance. Better IDE/Text editor tools. Simpler deploy / distribution - just copy a binary file. I really wish there will be optional type to prevent nil errors at compile time.
fouc 7y ago
It does seem like there is a fad around moving to types, mostly because of typescript's current popularity. Will be interesting to see how ruby handles types vs duck typing etc 10 years from now, when the new best practices have been figured out.
trixie_ 7y ago
Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the job. It's like a cost/benefit analysis where none of the benefits you're using, and the cost is the total inability to validate, refactor, and navigate your code base.
- saagarjha 7y ago
  > Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? Yes, yes, and no. I do most of my work in languages that prevent the first two, but when I do have access to this kind of runtime trickery I do use it when useful.
- viraptor 7y ago
  > Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? The issue is not "Do you purposefully do those things?", but rather "Do you have a call stack where you can't guarantee it won't happen by accident?" Type checking is not relevant when you know what will happen and want the dynamic/ducktyping behaviour. Another issue is: I'd use a different framework which doesn't use Ruby, but this was the most productive framework at the time the codebase was started, and nobody will port that many lines of code to a non-dynamic language now. So the best course of action is to validate the current code is not overly-dynamic.
- joelbluminator 7y ago
  I think most rubyists do benefit from dynamic types. How easy would it be to build rspec and Rails in java? The whole dependency injection thing in Spring is in part a by product of types making it way harder to test things. That's just one example.
viraptor 7y ago
Because it's easier to deal with your CI telling you that you made a mistake before a deployment, than with Rollbar telling you that you're losing money due to a stupid bug in a case you forgot to test for.
crnkofe 7y ago
It's a sad state of affairs. Every programming language is just copying the 'next cool' feature from another language. Duck typing, deconstruction, functional stream-like constructs you name it. I guess this ends when every language features is copied and we get X omni languages with Y omni SDK's all having same features with different syntax. The thing is that I only really need 1 omni language, not a dozen of them, so I feel that all the feature stealing in the end will be detrimental to all but the best supported omni language. I guess some companies started fast with Ruby/Python and similar and instead of rewriting to static/typed languages they pushed forward features that would allow them to just continue where they left off at the expense of having a more concise problem oriented programming language that's good for solving specific problems.
- pjmlp 7y ago
  Not really, what many seem to keep missing is that programming languages are products like anything else. One buys into eco-systems, not language features bullet point list. And there isn't something like an universal eco-system for any kind of business case, hence multiple languages.

Why is everything moving to types?

symlinkk 7y ago

Because TypeScript has proven that a type system can be helpful without being clunky and annoying.

eru 7y ago
I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.
- bfung 7y ago
  ML family has "type inference", which means the compiler figured out the type even if not explicitly written into the code. However, the language spec is still statically typed - an int will not turn into a string and vice versa (ex: "1"). Javascript and ruby, the underlying types can change depending on where the code is in execution - a variable holding a 1 can turn into a "1" and back (implicit type conversion - try 3 * "3"). This leads to a whole class of bugs not possible in a statically typed codebase where explicit conversion needs to happen - I have no hard data, but I remember debugging this type of stuff far too often and far too many times when I could've spend my time better elsewhere. (but I actually like ruby a lot!) Type checking is not the same as being statically vs. dynamically typed!
  - abhorrence 7y ago
    > a variable holding a 1 can turn into a "1" and back This is true of Javascript, but not of Ruby. irb(main):001:)> 3 * "3" TypeError: String can't be coerced into Fixnum People commonly conflate dynamic typing with weak typing, Ruby has the former, but not the latter (with some explicit exceptions, e.g. to_ary and friends). That's not to say you can't still end up with some interesting problems though -- if we just slightly change your example: a = 3 b = 3 # later... a = "oops" product = a * b # product is now "oopsoopsoops" But this isn't due to automatic "weak types" style coercion -- just that Ruby lets you build a repeated string by multiplying a string by a number.
  - eru 7y ago
    The alternative view is that those so-called 'dynamically typed' or 'untyped' languages should really be called 'monotyped languages' since all variables and expressions have the same type: a giant union of all possibilities. See https://news.ycombinator.com/item?id=8206562 https://news.ycombinator.com/item?id=8206562

jaequery 7y ago

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

tomc1985 7y ago
So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?
- joelbluminator 7y ago
  It rarely happens to me that I stare at a variable and have to wonder what type it is. And yes, an IDE like Rubymine is becoming crazy good at autocomplete and method lookup. I think the experience of developing on Rubymine isn't that far behind from Intellij nowadays. Not everyone have to use the same IDE, the vim or emacs guys will have to find equivalent tools.
- Shish2k 7y ago
  C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable. How does nobody(?) support this yet? Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free, but "distanceInKm + distanceInKm" gives you an int instead of a distanceInKm; and "distanceInKm + distanceInMiles" gives you an int instead of an error. Rust also has partial support but from the other end: distanceInMiles and distanceInKm can be two distinct subclasses of int, and adding them together is a compile time error. But also adding distanceInMiles with distanceInMiles is a compiler error, because these are basically "completely new classes" rather than "subclasses of int", and so you have to implement add / subtract / stringify / etc for yourself for every type D: (I'm fairly new to Rust so if there is a shortcut there that I'm missing please do point it out)

westoque 7y ago

I believe it depends on the use case. If you notice, Stripe and Coinbase are the first few companies that use the type system. They are both dealing with financial systems and numbers in general where having types would help a lot in catching errors and bugs earlier. I've worked on financial systems before in a dynamic language, JavaScript, and from my experience there would be cases where a number would be passed from a place where it's a string (in a textfield) that then needs to be passed around as an integer at times. Type systems would help catch bugs here or in similar situations.

codesushi42 7y ago

There is benefit to future proofing code with basic static analysis for type checking. But it is always an incomplete solution because a) old code needs to be retrofitted, see TypeScript's way of defining type maps for vanilla JS or b) more commonly you keep the code around that's using unsafe types, effectively passing void*|Object|"choose your poison" around.

biql 7y ago

Harder to make bugs. Better documentation. Typed code is easier to optimize - just look at Crystal performance. Better IDE/Text editor tools. Simpler deploy / distribution - just copy a binary file. I really wish there will be optional type to prevent nil errors at compile time.

fouc 7y ago

It does seem like there is a fad around moving to types, mostly because of typescript's current popularity. Will be interesting to see how ruby handles types vs duck typing etc 10 years from now, when the new best practices have been figured out.

trixie_ 7y ago

Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the job. It's like a cost/benefit analysis where none of the benefits you're using, and the cost is the total inability to validate, refactor, and navigate your code base.

saagarjha 7y ago
> Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? Yes, yes, and no. I do most of my work in languages that prevent the first two, but when I do have access to this kind of runtime trickery I do use it when useful.
viraptor 7y ago
> Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? The issue is not "Do you purposefully do those things?", but rather "Do you have a call stack where you can't guarantee it won't happen by accident?" Type checking is not relevant when you know what will happen and want the dynamic/ducktyping behaviour. Another issue is: I'd use a different framework which doesn't use Ruby, but this was the most productive framework at the time the codebase was started, and nobody will port that many lines of code to a non-dynamic language now. So the best course of action is to validate the current code is not overly-dynamic.
joelbluminator 7y ago
I think most rubyists do benefit from dynamic types. How easy would it be to build rspec and Rails in java? The whole dependency injection thing in Spring is in part a by product of types making it way harder to test things. That's just one example.

viraptor 7y ago

Because it's easier to deal with your CI telling you that you made a mistake before a deployment, than with Rollbar telling you that you're losing money due to a stupid bug in a case you forgot to test for.

crnkofe 7y ago

It's a sad state of affairs. Every programming language is just copying the 'next cool' feature from another language. Duck typing, deconstruction, functional stream-like constructs you name it. I guess this ends when every language features is copied and we get X omni languages with Y omni SDK's all having same features with different syntax. The thing is that I only really need 1 omni language, not a dozen of them, so I feel that all the feature stealing in the end will be detrimental to all but the best supported omni language. I guess some companies started fast with Ruby/Python and similar and instead of rewriting to static/typed languages they pushed forward features that would allow them to just continue where they left off at the expense of having a more concise problem oriented programming language that's good for solving specific problems.

pjmlp 7y ago
Not really, what many seem to keep missing is that programming languages are products like anything else. One buys into eco-systems, not language features bullet point list. And there isn't something like an universal eco-system for any kind of business case, hence multiple languages.