7 ms·

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases

• sanderjd 8y ago
  This seems like boiling oceans as well. It's hard to guess which oceans are bigger or harder to boil. Clearly Stripe thinks this is the easier way to go. That wouldn't have been my instinct. Maybe they made a really good estimate for how it will be though. I'd be very curious to see their full analysis!
  • Kalium 8y ago
    You're absolutely right! Building probably was a lot like boiling an ocean. Grafting static typing onto a very dynamic language is a massive and complex undertaking. That said, it's one item that can be built greenfield. In some senses, that makes it easier to apply to other codebases once the tool is in a working state. It also means one thing to work on, rather than N, which is much easier to plan for. You're completely right that this is an ocean to boil, and it's rarely easy to guess the size of any given one. Yet it's possible that the naive intuition - when boiling oceans, prefer fewer - might be reliable in this case.
    • vidarh 8y ago
      Grafting a complete and safe static typing system onto a very dynamic language is a massive and complex one. But writing an advisory type checker (that just warns) with a specific code base as a starting point is a very different thing. Biggest question to me is if they support duck-typing. Secondly, if I was to do type checking for Ruby I'd start with parsing yard-style annotations, as a lot of libraries etc. come with that as part of generating their documentation (and if not, writing them means you're now writing comments a lot of tools can generate documentation from.
      • Kalium 8y ago
        You're right. An advisory system isn't incredible difficult or intimidatingly large and complex, and doing it for a small set of codebases is much easier than solving it as a general problem. But uh, I didn't want to tell the commenter that they weren't thinking it through and were being utterly betrayed by their instincts. It's hard to get people to listen to that kind of thing. So I opted for telling them that they're right, implying that they have the opportunity to become more right, and reminding them of how right they are.
    • rurban 8y ago
      It's only massive if you are doing it wrong. All examples I found so far were doing it wrong. For cperl (perl5 with classes and types) I did it right instead. It took about half a year, with most parts improving the rest of the system and signatures. Ruby already has signatures, so thats out if the way. Python eg did it completely wrong, PHP is doing it right. The goal is catch type violations with optionally declared types and constant literals, and help the compiler and optimizer to specialize ops on types, and do array and loop bounds checks, essentially moving runtime checks to compile-time checks. A good type checker should make overall code faster and safer, what you see out there are rudimentary and not scalable efforts to make it safer, but not faster. It certainly looks like ocean boiling if you look at all the horribly bad efforts out there, comparable to pypy, unladen swallow, perl6, ... But if you look at proper type checkers and optimizers it's trivial, really.
  • emilsedgh 8y ago
    This might be as hard, but it's not as risky as rewriting the whole thing. This approach, at worst, will just fail. Rewriting the whole thing can have real big consequences if not done carefully and takes a real long time to bear fruit.
• pmontra 8y ago
  I'm one of those people. I'm not sure I'd keep loving Ruby as much as I do now if the majority of Ruby developers end up using the type checker and I'll also have to. I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That was very welcome coming from C and Java in 2006. I prefer to lose time when I pass a type that I shouldn't have passed. It doesn't happen often (not every year) vs at every single method definition. To understand if this project could have a future outside Stripe, how popular is Python 3.6's optional static type declaration?
  • 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?
• _pmf_ 8y ago
  > "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." Sometimes, if a baby is really, really ugly, it's OK to throw it out with the bathwater.
  • Kalium 8y ago
    You're absolutely right! But just because it's OK doesn't make it pragmatic engineering or good project planning.
• amelius 8y ago
  > boiling any number of oceans How many lines of code are we talking about here?
  • Kalium 8y ago
    How many services do you think a big company like Stripe has? Let's be exceptionally conservative and assume fifty, with a minimum of a million LoC between them. All of them need to keep working for the business to keep working.
    • amelius 8y ago
      Ok, but they also have a lot of developers.
      • Kalium 8y ago
        They do! And most of them are considered valuable employees because they can produce features the business wants in acceptable timeframes. It's perhaps possible that the business and management side of the house at Stripe might not want to give that up for a while so all of those developers can re-implement every service. Given that historically something like half of all rewrite projects fail, there's some non-trivial level of risk there. Though I understand if some think Stripe can afford it.
• edwinyzh 8y ago
  So it might (or not) be the best option for them at this point, but on the other hand, is it another case that shows a static-typed language is a better option for developing complex systems? IMHO, it is.
  • Kalium 8y ago
    I think this shows that static typing becomes more desirable and a better investment as size and complexity of a codebase - and company - grow. This might not be the same as evidence that starting with static typing is preferable.
    • gmaster1440 8y ago
      To your earlier point, larger systems are harder to migrate. This suggests that starting off with an investment in static type systems is more tenable as a long-term strategy.
      • Kalium 8y ago
        All other things being equal, that's probably true!
        • toasterlovin 8y ago
          If only all other things were equal...
          • Kalium 8y ago
            That's the catch, yes. All other things are very rarely equal. There are almost always other factors worth paying attention to when forming a long-term strategy. A handful that spring to mind are availability of talent, software runtime performance, schedule impact of static vs dynamic typing, and expected runway of the business. Producing a statically typed system that runs slowly and correctly after the business has folded is not always more valuable than producing a buggy one in time to start producing revenue.
• random3 8y ago
  I think making Ruby typed is a cool endeavor. It's just that it's a bit hard to justify from a business perspective.. It's not like changing to typed Ruby wouldn't affect the code bases. They'll end up having something that will resemble Ruby, but likely won't be quite Ruby. It's unlikely they could automate it. They'll have to rewrite a lot of code and typically, when you do that you also want to refactor obvious problems, so you end up rewriting big parts. And that's in addition to the cost of trying to make Ruby typed. Or you could leave the code base as it is and extract functionality out and rewrite it in something more manageable.
  • Kalium 8y ago
    I think it becomes a reasonable business pitch if you look at it as a tool that significantly reduces the defect rate and improves on-time delivery.
  • zem 8y ago
    i work on pytype [https://github.com/google/pytype https://github.com/google/pytype], a similar project for python, and it has definitely made business sense. it lets developers code in the language they find most productive (largely due to its dynamic nature), and adds back some of the benefits of static type checking. in particular, it has caught a lot of bugs that would otherwise only have shown up in production, and perhaps not until some rare code path was hit.