4 ms·

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 underta

by 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.

by Kalium 8y ago

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.