Human Errors, by Olivier Lacan
Abstract
Runtime errors can sometimes turn into dark and unpleasant journeys which lead you to question the nature of reality. Thankfully, Ruby often provides friendly feedback for understanding the cause and remedy for exceptions. Yet, there are situations in which programmers don't receive clear enough context for what really caused an exception and how to address it. We'll look at Ruby's error feedback mechanisms and search for constructive ways in which they can be made more helpful to humans.
Details
Whether you're a beginner or a seasoned Ruby developer it's a given that you encounter exceptions of some kind every single day. Many of them are caused by simple mistakes that can be easily fixed assuming you have the proper context and understand the cause of the exception.
As a programming language that focuses on happiness, Ruby has done a good job of supporting developers in their constant struggle against exceptions. However in recent years, languages like Elm, Rust, Kotlin, Go, and Elixir have set a higher standard for the quality of feedback given to programmers in exceptional situations.
In this talk we will look at existing ways in which Ruby offers useful feedback on exceptions to programmers but also ways in which Ruby's feedback mechanisms can be improved by taking inspiration from other languages in order to make Ruby developers happier and more productive.
At first I will describe the problem by showcasing hopefully familiar situations in which Ruby is less than useful with exception feedback. A good first example is ArgumentError which can give confusing feedback when a method requiring keyword arguments is given regular arguments by complaining that it somehow expected 0 arguments.
I will show how confusing or inappropriate feedback often creeps in the fringes of a language like Ruby or manifest itself when new features are added and have unexpected interactions with existing feedback mechanisms.
I will take the opportunity for a quick dive into how Ruby provides feedback to programmers in the first place to demonstrate the fact that despite lacking C knowledge, it's quite possible for someone to contribute improvements to such mechanisms.
To show how far Ruby has progressed in recent years I will use examples like the did_you_mean gem which is now part of Ruby itself since 2.3 and has significantly improved the NameError exception by providing a list of variables or methods similar to the one invoked when it can't be found.
Finally, after having presented the problem space, offered ways to contribute fixes, and example of recent successful improvements, I will delve into other modern programming language with interesting or different error feedback mechanisms which could serve as inspiration to attendees so they can be a part of the future of Ruby.
Pitch
Performance improvements have been the official priority for Ruby for some years now. Despite very beneficial improvements and a tighter release schedule, Ruby has seen other languages take the lead on what was once one of its most attractive traits: programmer friendliness. I hope that my talk will motivate fellow Rubyists to refocus at least some work on making Ruby the most programmer-friendly language it can be today.
In the past, I've presented talks about how to contribute to to Ruby for the first time. I've also contributed feature proposals and patches to Ruby myself. The motivation for this talk came from a recent patch I submitted to improve error feedback on argument errors involving keyword arguments. My patch was accepted and merged into Ruby 2.5. It will serve as one of the examples in the talk.
I believe this will allow me not only to diagnose error feedback issues in Ruby, but provide clear instructions to invite improvements in the future.
Bio
Olivier likes to use computers to help people and not the other way around. He's worked on Code School for the past five years, created Shields badges and Keep a Changelog to try and make open source project more accessible to humans. More importantly, he's the kind person who stops in the middle of a book to figure out the etymology of a cool new word.