4 ms·

I write Ruby professionally and while I agree that this can lead to some very sloppy code, I don't find that this causes a lot of problems in practice. A place

I write Ruby professionally and while I agree that this can lead to some very sloppy code, I don't find that this causes a lot of problems in practice. A place where we would use nil conversions is especially in logging and error handling — you can cast anything, including nil, to a string, and that is useful in debugging. Probably more often than nil conversions, we use the safe navigation operator &. as a way of working with "might be nil" values without having to add too much verboseness. I do miss the way languages like Swift think about Optional values, where you have to be much more explicit about whether or not you are dealing with `nil`. It's easier to reason about and leads to clearer codepaths. And in general, I miss stronger type systems in Ruby. But in a professional environment with relatively high developer expertise in the language and relatively clear style guides, we're still very productive in Ruby and don't suffer hugely from the typing issues. I guess eventually you learn to work around the warts in whatever language you use.

masklinn 3y ago
> A place where we would use nil conversions is especially in logging and error handling — you can cast anything, including nil, to a string, and that is useful in debugging. Lots of languages can format anything to a string though. Even Java will let you write "foo " + null And logging / error handling / debugging seems like the context where you would least want nil to become an empty string (and thus be confusable with an actual empty string, or not appear in the output).
- epidemian 3y ago
  I agree with the grandparent general point, but i would say that it is string formatting more precisely where these nil conversions are useful. For example, you can write something like: bananas = 4 puts "you have #{bananas} banana#{'s' if bananas != 1}" And this works because: `if` is an expression, `if` evaluates to `nil` if the condition is not met and there's no `else`, and `nil.to_s` is an empty string. > And logging / error handling / debugging seems like the context where you would least want nil to become an empty string Yep, 100% agree. And i think Ruby's designers agree too, since the language has the shortest method possible, `p`, for print-debugging. You can do `p something` and that'll print a useful string for debugging (`""` for an empty string, `nil` for nil, `[]` for an empty array, etc).
  - deleted 3y ago
    [deleted]
- vidarh 3y ago
  `"foo " + nil` is a TypeError in Ruby. You need to be explicit.
  - masklinn 3y ago
    Thank you for completely missing the point, your contribution is appreciated.
    - vidarh 3y ago
      The snark is completely unnecessary, and absolutely not appreciated. What is your point of that example, then? Absolutely nobody imagines any languages has no way of converting any value to a string. To me it came across as implying you were implying this was equivalent to what Ruby will do with the equivalent expression.
ljm 3y ago
In the grand scheme of things, it would be difficult to come up with something worse than having both null and undefined in JS, while also being able to define variables as undefined.
vidarh 3y ago
There are many stronger type systems for Ruby. And while that is partially a joke, there are various Optional type implementations, though of course you do then need the discipline of wrapping values as needed. I don't tend to use it myself because between safe navigation and things like Array() etc. it's rarely needed.
lamontcg 3y ago
I used to write Ruby professionally, and found the lack of any type system and duck typing to cause pretty severe problems. Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. But this kind of API where you have 'safe' operators that don't throw is a pretty good convenience, since forgetting that a variable might be nil is pretty common (or passing nil into a method that previously never accepted a nil and where the API was never tested for nil). There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly, which is much better than using 'unsafe' operators that just blow up and throw/panic if you don't think about the edge condition (So I wouldn't consider the Python alternative to be any better, you're just trading one possibly bad behavior of an edge condition for another possibly bad behavior of an edge condition and forcing programmers and code reviewers to constantly have them in their mind, and blaming them for when it goes wrong--with one group or the other feeling superior about their choice of when to blame the programmer for forgetting to handle the behavior). I think this is also roughly equivalent to languages like C# 8.0+ that have nillable/non-nillable types and static checking to make sure you're using them right.
- vidarh 3y ago
  > and found the lack of any type system I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. > Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. Nothing stops you from declaring that you expect a given type in Ruby; it's just code, and not mandatory, though you can certainly write code to impose mandatory types with Ruby - there was a while when writing those seemed a rite of passage for Ruby developers, but the reality was that they buy far less than people think until they've tried writing one and/or spent some time using them. > There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly Nothing stops you from doing that in Ruby, and in fact there are several monad implementations for Ruby that provides building blocks for those kinds of patterns if/when you want to use them.

masklinn 3y ago

> A place where we would use nil conversions is especially in logging and error handling — you can cast anything, including nil, to a string, and that is useful in debugging. Lots of languages can format anything to a string though. Even Java will let you write "foo " + null And logging / error handling / debugging seems like the context where you would least want nil to become an empty string (and thus be confusable with an actual empty string, or not appear in the output).

epidemian 3y ago
I agree with the grandparent general point, but i would say that it is string formatting more precisely where these nil conversions are useful. For example, you can write something like: bananas = 4 puts "you have #{bananas} banana#{'s' if bananas != 1}" And this works because: `if` is an expression, `if` evaluates to `nil` if the condition is not met and there's no `else`, and `nil.to_s` is an empty string. > And logging / error handling / debugging seems like the context where you would least want nil to become an empty string Yep, 100% agree. And i think Ruby's designers agree too, since the language has the shortest method possible, `p`, for print-debugging. You can do `p something` and that'll print a useful string for debugging (`""` for an empty string, `nil` for nil, `[]` for an empty array, etc).
- deleted 3y ago
  [deleted]
vidarh 3y ago
`"foo " + nil` is a TypeError in Ruby. You need to be explicit.
- masklinn 3y ago
  Thank you for completely missing the point, your contribution is appreciated.
  - vidarh 3y ago
    The snark is completely unnecessary, and absolutely not appreciated. What is your point of that example, then? Absolutely nobody imagines any languages has no way of converting any value to a string. To me it came across as implying you were implying this was equivalent to what Ruby will do with the equivalent expression.

ljm 3y ago

In the grand scheme of things, it would be difficult to come up with something worse than having both null and undefined in JS, while also being able to define variables as undefined.

vidarh 3y ago

There are many stronger type systems for Ruby. And while that is partially a joke, there are various Optional type implementations, though of course you do then need the discipline of wrapping values as needed. I don't tend to use it myself because between safe navigation and things like Array() etc. it's rarely needed.

lamontcg 3y ago

I used to write Ruby professionally, and found the lack of any type system and duck typing to cause pretty severe problems. Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. But this kind of API where you have 'safe' operators that don't throw is a pretty good convenience, since forgetting that a variable might be nil is pretty common (or passing nil into a method that previously never accepted a nil and where the API was never tested for nil). There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly, which is much better than using 'unsafe' operators that just blow up and throw/panic if you don't think about the edge condition (So I wouldn't consider the Python alternative to be any better, you're just trading one possibly bad behavior of an edge condition for another possibly bad behavior of an edge condition and forcing programmers and code reviewers to constantly have them in their mind, and blaming them for when it goes wrong--with one group or the other feeling superior about their choice of when to blame the programmer for forgetting to handle the behavior). I think this is also roughly equivalent to languages like C# 8.0+ that have nillable/non-nillable types and static checking to make sure you're using them right.

vidarh 3y ago
> and found the lack of any type system I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. > Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. Nothing stops you from declaring that you expect a given type in Ruby; it's just code, and not mandatory, though you can certainly write code to impose mandatory types with Ruby - there was a while when writing those seemed a rite of passage for Ruby developers, but the reality was that they buy far less than people think until they've tried writing one and/or spent some time using them. > There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly Nothing stops you from doing that in Ruby, and in fact there are several monad implementations for Ruby that provides building blocks for those kinds of patterns if/when you want to use them.