On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Discussing is (usually) fun :) [..]
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1]. In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested. And it looks like C++17 already support such a feature (although we are not using it IIRC). As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception. The idea is that the user of the library could decide how important is not finding a device, as it might be (or not) a critical error. But that's a different discussion. [..]
Both errors are the same error, a programmer error. Both errors happen during runtime, just the raised exception is different. In Ruby, the error is revealed in a slightly different way that it would be revealed in a static language. But that's the whole difference. Static type checking would not save you in 98% of the cases.
Proper static type checking might help in those situations.
What can save us in both cases? Comprehensive unit tests. Because they have a completely different goal from the checks performed by the compiler and they should spot a different kind of errors. Of course, that implies that whoever is writing the tests thinks in all possible situations (like the device not being there) and covers those situations with tests. That's why unit tests are a must in both dynamically and statically typed languages.
I absolutely agree. [..] On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value. Most of our bugs have nothing to do with type checking. If main argument against Ruby is that it lacks of type checking, I can live with that :) Regards, Imo [1] https://en.wikipedia.org/wiki/Option_type [2] https://rustbyexample.com/std/option.html -- Imobach González Sosa YaST team at SUSE LINUX GmbH Blog: https://imobachgs.github.io/ Twitter: @imobachgs