Any reason why existing typecheckers for Ruby didn't make the cut? There are projects like RDL [1] which provide similar functionality. I know for certain that people from Stripe were taking a look at it last year from the issues they had raised. Disclosure: I am a grad student, recently started working on RDL. [1]: https://github.com/plum-umd/rdl
What's the next step for RDL? It seems like Hummingbird is much more powerful than Sorbet, but it's hard to tell without them publishing a paper yet.
Stripe is building a Ruby typechecker
171–180 of 187 posts
Re: Stripe is building a Ruby typechecker
#172People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…
I'm not sure how well you understand functional programming either if you think it needs dynamic typing. The king of functional programming languages (Haskell) is statically typed.
Re: Stripe is building a Ruby typechecker
#173People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…
> Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. I don't see how seeking to add types precludes also understanding "closures, concurrency passing or functional programming", especially since these are in no way foreign concepts in statically typed languages. > If you wan…
Re: Stripe is building a Ruby typechecker
#174I was at RubyKaigi. This presentation was one of the best delivered, so kudos to the Stripe team for all the work put into it. A question I didn't get to ask while there is -- will there be some sort of type sharing system introduced? I've been a user of both Typescript and Flow (both great tools), but saw Typescript's popularity soar because of community written types.
> A question I didn't get to ask while there is -- will there be some sort of type sharing system introduced? Yes. This was one of goals of our talks. We wanted implementors of type systems for ruby to start collaborating, in particular on a repository of typed shims. The details of how this would work out might be different. Typescript and Flow change syntax and thus they cannot be included inline in arbitrary JavaS…
I see. Do you see this being a mono-repo of types that's under a Sorbet org or something Sorbet looks for in a gem if provided? Opening issues for a project's types with Typescript has been somewhat painful since many live in one repo [1].
Re: Stripe is building a Ruby typechecker
#175Earlier quoted context omitted.
> 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, t…
You'll have to justify this: "Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors." Your recent study is pay walled, so I can only go by the abstract, but it doesn't sound any more rigorous to me. I also find its comparing very different things. It says bugs in release, but it sounds like they consider commits to be releases, which would be very unfortunate.…
That topic has filled whole blog posts. But in a nutshell, no previous study was able to compare directly the effect of typing disciplines due to confounders that they couldn’t control for in their experimental setup. For instance, virtually all previous studies compared different programming languages, which obviously differ by more than just their typing discipline. Many studies had very small sample sizes due to using human test subjects to write sample programs. These test subjects were almost exclusively students without real-world experience — or, in some case, any prior experience in the respective programming languages. Thus, many studies — from the outset — tested beginner-friendliness of languages rather than everyday use. Fair enough, but not the same as type checking benefits. Furthermore, most of these studies, for the same reason, were restricted to testing on artificial, academic, small toy programs rather than real-world applications.
The few studies that looked at big real-world data sets (the biggest and most rigorous being linked above) didn’t even look at typing discipline as an individual factor — again because they couldn’t regress it out as a single factor.
> Your recent study is pay walled
The link I posted has the full text PDF (that’s the whole reason for me to share Paperpile links rather than the original or DOI). See also an academic discussion [1] of the manuscript.
> Its also specifically targeting JavaScript
Which is explained in the paper: no other constellation allows to compare the effect of added static type checks as directly as JavaScript/TypeScript/Flow. That’s because (a) these languages only differ in their type checker, and are gradually typed, i.e. types can be added to just a subset of the program, which enabled the study methodology. And (b) there’s an extensive database of real-world code to analyse.
> For example, it would be interesting to know how many bugs were due to weak typing.
Fair enough. I’d expect the effect to be (much) less pronounced in a language with stronger type guarantees. Then again, the 15% number is absolutely an underestimate to begin with (see the paper and the blog post [1]).
> adding the typed annotations should be a blind activity to be rigorous
That’s not at all obvious, and from experience I disagree. Thinking about types is automatic neither in static nor in dynamic languages. Once you’ve figured out the correct type, yes, it’s a blind activity … but that’s a pretty empty statement.
> having to add types can introduce other forms of bugs
Again, this claim is far from obvious, beyond the trivial “if I make this type an `int` even though it should be a `string` then that’s a bug”. Fair enough, but adding the type annotation and performing a type check merely reveals this bug. The bug itself was present in the programmer’s flawed assumptions about the invariants in the code. Your assertion is equivalent to saying “compiling or interpreting the code [rather than writing it on a piece of paper and never touching it] can introduce bugs”. — The bugs are already in the code, we just didn’t detect them.
> Would have been interesting too to analyse how long it took for the bug fix commit
They only considered bugs they could fix within a highly constrained time frame, and only looking at local code around the bug. Hence, again, why the 15% is an extreme underestimate. Furthermore,
> So you would know the real cost of them.
The study calculated the token cost of adding types (and provide a justification for this metric). In a nutshell, the cost is negligible, especially in languages with strong type inference capabilities (Flow outperforms TypeScript here).
> Clojure and Ruby were both outliers that outdid almost all static languages.
Right, and I’d expect the same to still hold. But it shows one of the crucial shortcomings of previous studies: they primarily did not examine the effect of static vs dynamic typing. Rather, they examined the effect of different programming languages, to which typing is just one contributor amongst many. It should come as no surprise to experienced programmers that some languages (regardless of static vs dynamic discipline) vastly outperform others. For me, this is all the more reason to be excited about the headline topic: If done well, statically type checked Ruby could be an amazing language, with the added benefit of static typing at (as shown) virtually no cost.
[1] https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
Re: Stripe is building a Ruby typechecker
#176Earlier quoted context omitted.
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 m…
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...
Re: Stripe is building a Ruby typechecker
#177Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?
If larger companies (eg. Stripe) would put more effort into improving Crystal instead of improving Ruby, Crystal would absolutely blow Ruby out of the water. Instead we get improvements to Ruby because larger companies have larger codebases and don't want to refactor everything all at once. They'd rather slowly add type annotations to their Ruby codebase until eventually it's all done. I get it, it's better from a bu…
Re: Stripe is building a Ruby typechecker
#178Earlier quoted context omitted.
> Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. I don't see how seeking to add types precludes also understanding "closures, concurrency passing or functional programming", especially since these are in no way foreign concepts in statically typed languages. > If you wan…
My argument is that you can always implement your own breed of type checking either via convention (with appropriate enforcement via static analysis or linting tools if so desired without having to run the code), or you can do type checking at run time -- most dynamic languages have a facility to interrogate a variable to determine its contents and you can implement any number of tests on it as you see fit to validat…
Re: Stripe is building a Ruby typechecker
#179People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…
> People created dynamic languages for the exact reason of not having to define types. Not having to define types is not the biggest merit of dynamic languages. The biggest benefit is to be able to do things that you couldn’t do if you had a type system. You can do some crazy stuff with Ruby’s meta programming.
Re: Stripe is building a Ruby typechecker
#180Earlier quoted context omitted.
> I don't have to lose time writing types In C#, I write type names when I declare a type, when I create instance of a type, when I declare method argument or return type (which you would probably do even in a dynamic language as a comment - you don't want people to have to go through your code to figure it out themselves, right?) and when I declare a collection of that type. Out of all of these, only the last one se…
am i mistaken, or do generics specifically eliminate that last case...?