3 ms·
Former Ruby developer here. I believe we will look back at this period where we eschewed static typing as a historical mistake. Back in the 2000s I was using m
by atombender 8y ago
Former Ruby developer here. I believe we will look back at this period where we eschewed static typing as a historical mistake.
Back in the 2000s I was using mostly statically typed languages (Java, C/C++, ObjectPascal), and compared to those, Ruby and Rails seemed like incredible productivity boosters. But we quickly found that the lack of typing led to all sorts of issues. For one, you need really comprehensive tests to determine whether a change breaks anything. Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Duck typing is elegant, but it only works so far as you know the range of types to expect. I very quickly got tired of checking the validity of arguments in code and doing coercion such as Array(maybe_array_or_maybe_not). And the nils, ugh. I never created so many bugs as when I was writing Ruby code (though JavaScript is a close second).
A language with a rich type system (Haskell, Swift and Rust come to mind) can eliminate entire classes of bugs. Not just by letting you validate the types of arguments and return values, but by letting you describe your program logic in terms of types. It's often said that Haskell programs rarely have bugs once they compile, and while there are no guarantees, it's often true.
Give a statically typed language a try for a while, and you will probably change your mind. I don't know about Crystal, but Go is a decent entry-level language. (Many former Ruby devs seem to enjoy Go quite a bit.)
- vinceguidry 8y agoI'm looking forward to Ruby's upcoming type system. But for now I have no problems leaning on discipline for handling the problems dynamic typing introduces.
- tigershark 8y agoYou remind me of all the people that 10 years ago were saying that they don’t need tests because they have the discipline to write correct code...
- kjeetgill 8y ago> Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Beautifully put. The ability refactor confidently is so underrated. It's one of the places where a little bit of verbosity (i.e. Java) pays huge dividends. > Duck typing is elegant, but it only works so far as you know the range of types to expect. Go shines particularly well here. In Java code bases, interfaces occasionally accumulate too many methods or interfaces of interfaces start to get unwieldy. I like Go's approach of letting the function declare the relevant subinterface it really needs.
- rdc12 8y agoI think part of the beauty of static type systems, for refactoring guiding, is that most (if not all) issues arise at the time of change, when the change is fresh in your mind, locality of reference if you will.
- kazinator 8y agoI recently refactored my fork of the linenoise library (written in C) from char to wchar_t. C being statically typed made it easy to find all the places that need to be updated if some declaration is changed from the one type to the other. The editor gathers the compiler errors and takes you to all of them. The result was broken though. For instance, in some places I replaced strcspn (complemented span) with wcsspn instead of wcscspn. It has exactly the same signature. This was caught by testing all the edit operations, and a very careful diff review. Type checking only works when you make a mistake which breaks a type signature. You can call entirely the wrong function with the right type signature. You can call sin instead of cos, or forget to take a log of something. You an swap the arguments to a subtraction: both are floats. Think of all the numeric code in which lots of variables, arguments, array elements and so on are all of the same type. Or string code in which there are numerous strings. Or OOP code where you have two or more objects in the same scope of exactly the same class, which can get mixed up. The idea that you do not need a comprehensive test suite because you have static types is horribly wrong.
- atombender 8y agoC is not a great example here, because it's somewhat weakly typed. But it's true that typing doesn't fix the identical-arguments problem.