• Weird Ruby: Zeroing in on a Couple of Numeric Predicates

    Today we’re going to discuss a couple of really simple numeric predicates - namely Numeric#zero? and Numeric#nonzero?. I assume most Ruby developers are familiar with them, as they represent a popular alternative to doing traditional checks for zero:

    if foo == 0 ...
    if ...
    if foo != 0 ...
    if foo.nonzero? ...

    So far, so good. Nothing really weird, right? Let’s now take a closer at the two predicate methods:
    # => true
    #=> nil
    #=> false
    #=> 1

    Now this looks kind of weird… As you can see zero? returns true or false and nonzero? returns its receiver or nil. So much for API symmetry. There’s a long weird story behind this inconsistency, and an interesting ticket on Ruby’s bug tracker discussing options how to address it. Most of the time you probably won’t experience any issues related to that inconsistency, but there are certainly cases where it is going to bite you.1

    As far as I’m concerned nonzero? doesn’t exist and I simply use !zero? all the time. Negative predicates are pretty weird in the first place and I’ve never seen much value in them.2

    I’ll end this post with a small challenge for you - what are your favourite examples of API inconsistency in Ruby?

    Articles in the Series

  • Clojure Heroes

    Oh we can beat them, for ever and ever
    Then we could be heroes, just for one day

    – David Bowie, Heroes

    This tweet made my day:

    It’s a great reminder of how awesome the Clojure community is. I was truly touched by the tweet (as I didn’t really expect it, plus I was having a pretty bad day) and I already feel like I’ve won the “Clojure Hero” award! Thanks for the kind words, Daniel! I’m honoured and humbled to be on your list!1

    This all reminded me that we often don’t value enough the people who make Clojure so awesome. Let me address this today by “nominating” three more Clojurians for the “Clojure Hero” award:

    I’m reasonably certain they need no introduction and that most of you are well aware of their huge impact on the Clojure community. I’ll just say “Thank you! You’re awesome! Clojure wouldn’t not be the same without you!”.

    Last, but not least - a very big “Thanks!” to Rich, Stu Halloway, Alex Miller, David Nolen and everyone else on Clojure(Script)’s team. There wouldn’t be a Clojure community without you!2

    So, who are your nominees for the “Clojure Hero” award? Why don’t you reach out to them and let them know how much you value their contributions to the Clojure community? I’m sure that small gesture is going to mean a lot to them!

    1. And you’re certainly on mine. 

    2. I’m pretty sure they are on everyone’s list. :-) 

  • Weird Ruby: Block Comments

    Welcome to another installment of “Weird Ruby”! Today we’re going to be discussing the typically boring subject of code comments. I guess pretty much every Ruby developer knows that comments in Ruby start with # and typically look something like this:

    # I'm a comment.

    That’s not the whole story, though. Ruby actually has a second syntax for comments, which is focused on block (multi-line) comments. Here’s how it looks:

    # I'm a plain old multi-line comment.
    # You've probably seen a million like me.
    I'm a block comment.
    I look kind of weird and you've probably never
    seen one like me before.

    So, what’s so weird about this syntax that it made it to “Weird Ruby”? After all other programming languages have the block comments as well.1 It’s pretty simple - the block comment syntax has the weird requirement that the comments have to begin at the very start of each line. Consider this:

    class SomeClass
    This is a block comment.
    It looks pretty out of place.
      def some_method
    # Don't do this at home!
    class SomeClass
      This looks like a block comment, right?
      Unfortunately it's a syntax error.
      def some_method

    Bummer! As you can imagine this really limits the usefulness of the block comment syntax and probably this is the reason why it never gained any traction. I’ve got no idea why the syntax was designed in a such a limiting manner, or if Ruby’s Core Team plans to address or remove it down the road. If someone knows something on the subject - please, share your insight via a comment. The good thing is that in the era of today’s super powerful editors and IDEs you don’t really lose much, as they make it really easy to (un)comment blocks of code. Perhaps we no longer need a special block comment syntax at all?

    That’s all I have for you today! Hopefully it was weird enough, fun and somewhat useful! Keep hacking!

    Update (2019-06-10)

    A couple of people commented that this was not a really a block comment syntax, but more of an attempt to emulate Perl’s POD documentation system. In hindsight that makes a lot of sense given the massive Perl heritage that exists in Ruby today. Funny enough I used be a Perl programmer at the beginning of my career, but I had forgotten the POD syntax completely by now.

    Turns out there’s an rdtool for Ruby that’s pretty similar to POD. Basically rdtool scans a file for =begin and =end{=begin...=end@{=begin pairs, and extracts the text between them all. This text is assumed to be documentation in RD format. You can read more about it here.

    There’s very little documentation on rdtool online and I couldn’t find any real-world usage of it. I assume it predated the rise of RDoc and YARD and was effectively obsoleted by them.2 Anyways, it’s safe to say that this installment of “Weird Ruby” was pretty educational for me!

    Articles in the Series

    1. /* */ from C and family immediately come to mind. 

    2. According to this Wikipedia article the RD format used to be popular until the early 2000s when it was superseded by RDoc. 

  • Reloaded

    I hope that by now most CIDER users have heard of https://docs.cider.mx1 and I have spent some quality time there. Today I’m excited to share with you a few updates about CIDER’s documentation site!2

    1. Also aliased to for historical reasons. 

    2. I know documentation is not an exciting topic for most people, but I’m weird. 

    Read More
  • Eradicate Typos in Source Code

    I don’t know about you, but I keep making typos like crazy1, so I’m really glad that today we’ve got so many tools to help us with their discovery and mitigation. While most text editors have some spell checking for the comments in source files2, that generally is not enough to free our source files from typos - often we’d make typos in identifiers, some team mates won’t be using spell checkers at all, some people would use British spellings instead of US spellings and so on.

    Read More

Subscribe via RSS | View Older Posts