5 ms·

> I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply an

by klmr 8y ago

> I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice everywhere (in languages that don’t support it in the language, it’s done in documentation). > To understand if this project could have a future outside Stripe, how popular is Python 3.6's optional static type declaration? Or rather: How popular are TypeScript or Flow? Very.

fouc 8y ago
Ruby has the advantage of 'duck typing', due to its strong OOP foundations. Not quite sure what Python has that reduces the demand for static type declaration. I think part of the popularity of TypeScript could be down to a large proportion of javascript coders that have a background/preference for static typing. It could also be that certain classes of bugs are more prone to happen in JavaScript or it's harder to debug when bugs do happen?
- oelmekki 8y ago
  Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prevent me to do it and it will generate an exception when quacking. Did I miss something obvious?
  - vidarh 8y ago
    The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirements of dosomething(), the class of "source" is irrelevant. The relevant type information is whether or not "source" responds to "shift". A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.
    - oelmekki 8y ago
      I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.
      - vidarh 8y ago
        It's a language feature in as much as the absence of static typing and the ability to check for methods is what makes it possible. But yes, it it a guideline, and Ruby code that violates it will generally be seen as not being idiomatic Ruby.
        oelmekki 8y ago
        Oh, I see, given the interpreter is written in strongly typed language, allowing to go without static typing is a feature by itself, and allowing to test for methods presence allows to do duck typing, thus it allows to say that ruby implements duck typing. It makes more sense than talking of duck typing explicit usage by end users, given it's quite rare we assert proper received parameters extensively. EDIT : which makes me realize we have a machine language without typing (binary), on top of which we use a language implementing strong typing (C), used to build a language without strong typing (ruby), on top of which Stripe is building strong typing. Making a definitive decision is hard :)
        mdpye 8y ago
        Nitpick: C is weakly typed, Ruby is strong. C is statically typed, Ruby is dynamic. Strong typing is about objects having a definite type. In Ruby, you cannot cast a String to a Fixnum, an exception will be raised. But in C you may cast anything to anything really, and your program will believe you, whether it could possibly make sense or not...
        oelmekki 8y ago
- emodendroket 8y ago
  JavaScript and Python also have "duck typing."
nailer 8y ago
I'm not a typing person, similar to pmontra. Any programming language where print("Hello world") is longer than print("Hello world") bothers me. And most of my JavaScript is untyped, because (and apparently this is common, someone did some stats on it a while ago) typing errors aren't a great source of errors. However I love optional typing. Being able to build a thing quickly, and then add those guarantees if/when you feel they're needed is great. My current codebase is about 80 modules. Nearly all are untyped JS. The database code is TypeScript because that's where I feel type handling would add the greatest benefit - not that I have had typing errors, just that I like the additional peace of mind.
- klmr 8y ago
  > typing errors aren't a great source of errors. That’s not true. On the contrary, typing accounts for a substantial fraction of all errors (and refactoring could transform even more logic errors into catchable type errors). The best research (best methodology, sample size, by far) on the subject [1] puts the lower bound for the fraction of type errors in JavaScript at 15%. [1] https://paperpile.com/app/p/3070170e-933e-0956-82ec-879fb924e452 https://paperpile.com/app/p/3070170e-933e-0956-82ec-879fb924...
  - nailer 8y ago
    Not doing a URL hunt as I'm at work, but as mentioned in the comment you're replying to (literally after you chopped it off), there was a large study showing the opposite on HN a while back.
    - klmr 8y ago
      > there was a large study showing the opposite on HN a while back. Yes, sorry: I didn’t mean to ignore that part of your answer but the research I’ve linked to essentially supersedes everything else in that area. Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors. I’m assuming you’re referring to [1] and while that was an impressive study in its own right, their classification of bug sources is indirect and, ultimately, simply didn’t allow any assertions regarding the prevalence of type errors. [1] https://paperpile.com/app/p/54ee3fdd-a6ef-0767-add5-55b604199453 https://paperpile.com/app/p/54ee3fdd-a6ef-0767-add5-55b60419...

by klmr 8y ago

fouc 8y ago

Ruby has the advantage of 'duck typing', due to its strong OOP foundations. Not quite sure what Python has that reduces the demand for static type declaration. I think part of the popularity of TypeScript could be down to a large proportion of javascript coders that have a background/preference for static typing. It could also be that certain classes of bugs are more prone to happen in JavaScript or it's harder to debug when bugs do happen?

oelmekki 8y ago
Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prevent me to do it and it will generate an exception when quacking. Did I miss something obvious?
- vidarh 8y ago
  The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirements of dosomething(), the class of "source" is irrelevant. The relevant type information is whether or not "source" responds to "shift". A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.
  - oelmekki 8y ago
    I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.
    - vidarh 8y ago
      It's a language feature in as much as the absence of static typing and the ability to check for methods is what makes it possible. But yes, it it a guideline, and Ruby code that violates it will generally be seen as not being idiomatic Ruby.
      - oelmekki 8y ago
        Oh, I see, given the interpreter is written in strongly typed language, allowing to go without static typing is a feature by itself, and allowing to test for methods presence allows to do duck typing, thus it allows to say that ruby implements duck typing. It makes more sense than talking of duck typing explicit usage by end users, given it's quite rare we assert proper received parameters extensively. EDIT : which makes me realize we have a machine language without typing (binary), on top of which we use a language implementing strong typing (C), used to build a language without strong typing (ruby), on top of which Stripe is building strong typing. Making a definitive decision is hard :)
        mdpye 8y ago
        Nitpick: C is weakly typed, Ruby is strong. C is statically typed, Ruby is dynamic. Strong typing is about objects having a definite type. In Ruby, you cannot cast a String to a Fixnum, an exception will be raised. But in C you may cast anything to anything really, and your program will believe you, whether it could possibly make sense or not...
        oelmekki 8y ago
emodendroket 8y ago
JavaScript and Python also have "duck typing."

nailer 8y ago

I'm not a typing person, similar to pmontra. Any programming language where print("Hello world") is longer than print("Hello world") bothers me. And most of my JavaScript is untyped, because (and apparently this is common, someone did some stats on it a while ago) typing errors aren't a great source of errors. However I love optional typing. Being able to build a thing quickly, and then add those guarantees if/when you feel they're needed is great. My current codebase is about 80 modules. Nearly all are untyped JS. The database code is TypeScript because that's where I feel type handling would add the greatest benefit - not that I have had typing errors, just that I like the additional peace of mind.

klmr 8y ago
> typing errors aren't a great source of errors. That’s not true. On the contrary, typing accounts for a substantial fraction of all errors (and refactoring could transform even more logic errors into catchable type errors). The best research (best methodology, sample size, by far) on the subject [1] puts the lower bound for the fraction of type errors in JavaScript at 15%. [1] https://paperpile.com/app/p/3070170e-933e-0956-82ec-879fb924e452 https://paperpile.com/app/p/3070170e-933e-0956-82ec-879fb924...
- nailer 8y ago
  Not doing a URL hunt as I'm at work, but as mentioned in the comment you're replying to (literally after you chopped it off), there was a large study showing the opposite on HN a while back.
  - klmr 8y ago
    > there was a large study showing the opposite on HN a while back. Yes, sorry: I didn’t mean to ignore that part of your answer but the research I’ve linked to essentially supersedes everything else in that area. Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors. I’m assuming you’re referring to [1] and while that was an impressive study in its own right, their classification of bug sources is indirect and, ultimately, simply didn’t allow any assertions regarding the prevalence of type errors. [1] https://paperpile.com/app/p/54ee3fdd-a6ef-0767-add5-55b604199453 https://paperpile.com/app/p/54ee3fdd-a6ef-0767-add5-55b60419...