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
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
(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.
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 example if you are
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
during runtime, just the raised exception is different. In Ruby, the
error is revealed in a slightly different way that it would be
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
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
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
If main argument against Ruby is that it lacks of type checking, I can
live with that :)
Imobach González Sosa
YaST team at SUSE LINUX GmbH