Exercism.io helps developers to increases their craftsmanship in a language through feedback and discussion. It’s a community and tool where developers can write code and discuss it to strengthen their problem-solving skills.
InfoQ did an interview with the creator of exercism Katrina Owen and with Richard Thomson who contributed the C++ language track for exercism.
InfoQ: Can you give a short description of exercism.io for our readers?
Richard: Exercism is a place to practice and improve your software skills. Software has two forces influencing its creation: utility and craft. The utilitarian aspect of software is obvious; it either performs the purported task or it doesn't. Getting the utilitarian aspect of software accomplished is the focus of most efforts to teach programming. Does it work? It it robust? How do we fix this error?
The craft aspect of software is more nebulous. The craft of software is learned through experience and exposure to the work of others. The first time you work on a code base where no one respected the craft aspect of software, you feel the need for it deeply. The code is littered with long methods, poorly chosen names, mixed responsibilities, clutter and duplication.
Over time, the industry has developed a terminology to refer to the positive aspects of the craft through design principles such as SOLID, DRY, Law of Demeter and so-on. When code lacks craftsmanship specific indicators have been codified as various code smells: duplicated code, long methods, large classes and so-on.
Exercism assumes that you know how to achieve the utilitarian part of programming already but you are looking to improve your craft. Improving your craft means interacting with other programmers and having a discussion about some code where you already understand the problem and can use that as a basis for evaluating a given solution to that problem.
Katrina: Exercism lets people do simple programming exercises as a starting point for having conversations about simplicity, style, and idioms in the target language. While people often come for the exercises, they generally stay for the conversations.
InfoQ: Which programming languages does exercism support, and which kinds of exercises doe it provide?
Katrina: At the moment exercism has 19 active languages. In alphabetical order: Clojure, CoffeeScript, Common Lisp, C++, C#, Elixir, Erlang, F#, Go, Haskell, JavaScript, Lua, Objective-C, OCaml, Perl (5), Python, Ruby, Scala, and Swift.
We're also sorting out the final details to launch the PHP and Java tracks.
The exercises themselves are essentially toy problems. The format is a README and a test suite that you fetch and work on locally in your usual environment with your usual tools. The test suite gives people a good stopping point, and the interesting part of the problem is to iterate on the solution, trying different approaches and responding to critique from other programmers.
Richard: We have a synopsis page showing the languages currently available on exercism and the problems available in each language track.
InfoQ: Exercism aims to help developers to produce better code. But what is better, can we really know that?
Katrina: Most of the time I think "better" is just a gut feeling.
Gut feelings tend to be based on experience. Your "better" is going to be quite different from my "better", simply because we've worked on very different types of code bases and solved very different types of problems. Things that are familiar to you will feel alien to me.
We can do static analysis on code to have a factual basis for discussion, but to be honest these things don't come up very much on exercism. The conversations tend to be more about code smells and readability.
Even though the "better" we're talking about is entirely subjective, it's a very useful discussion to have.
Richard: Like Katrina, I think that some aspects of code are subjective. Usually this revolves around the names that are chosen and of course the never ending strong opinions about whitespace and formatting.
However, I think that over time the industry has gravitated towards some objective standards about what makes for better code. Code metrics like cyclomatic complexity can provide an answer to simple questions like "when is a function/method too complex?". Rules of thumb like "no function should have more than 5 parameters" can tell us whether one version of code is better than another.
Software is infinitely malleable and exercism guides people in the direction of discussing alternative forms of the code that have the same utility but are easier to understand by other people. The deeper aspect of the discussion is the principles behind the rules of thumb and the use of objective data like complexity metrics. These are more firmly rooted in experience, but recent developments in cognitive science provide a scientific underpinning that supports those gut instincts learned by experience. A recent book "Principle-Based Refactoring" by Steve Halladay identifies the underlying principles behind the distilled gut feelings of the author when advising students on how to produce better code.
InfoQ: Earlier InfoQ wrote about developing programming skills to become software craftsmen. How can exercism contribute to this?
Richard: With exercism, you get the tests and you write the implementation to make the tests pass. That can give you a gentler introduction to test-driven development than having to think of the tests and the implementation at the same time. Getting the tests is just the starting point for a discussion of your solution to the problem. That discussion is where the real "Ah ha!" occurs.
I learned new ways to improve my Python and JavaScript just from solving the first exercise in each of those languages. My solution worked, but it wasn't pretty and I wasn't particularly proud of the shotgun blast of regexs I had thrown at the first problem in JavaScript. I knew I could do better. After submitting my solution in these languages, I could browse other people's solutions and I learned how to do that same thing in a simpler way. Even without specific feedback from others, just browsing competing solutions taught me how to improve my code and make it more "natural" for those languages.
Katrina: I think the most powerful way in which exercism can help you improve your skills is that it gives you a focused way to look at other people's code and articulate ways in which it could be improved. This forces you to read and understand code that you didn't write, and think about it systematically and critically. You begin to recognize patterns and code smells, and you develop a very practical sense of what is readable and not.
More importantly, you need to articulate this critique in a way that is sensible. It's not enough to say "Do this." Having to come up with reasoning for a gut feeling makes you examine your biases very closely, and sometimes you'll surprise yourself with your own insights.
InfoQ: hack.pledge() is a worldwide movement for programmers to assemble and mentor each other. What do think of this initiative?
Katrina: I think that initiatives such as hack.pledge(), #pairwithme, and CodeNewbies are fantastic. They have a vital human component that sometimes gets lost in many blog posts about getting better at programming.
Richard: I think exercism is a great way to fulfill the hack.pledge()!
InfoQ: Let's assume that it's December 2015. How does exercism look one year from now, and what did you reach during the year?
Katrina: First, I'd love to see the quality of the discussions be consistently good in all the language tracks. At the moment some tracks are much more active than others, and in some languages you'll consistently get phenomenal feedback (Haskell comes to mind), whereas in others there are many people who submit solutions, and very few who provide feedback, or the feedback that is provided is of varying quality.
Second, I hope to improve the usability of the site, in particular when it comes to being able to search and filter existing problems and solutions, and following interesting people and problems to be notified.
Richard: In one year from now I expect to see more language tracks available and I expect to see more problems available in the various languages. I expect to see more problems specific to individual languages as well. I expect to see more participation in exercism by users and more contributors to the project itself making it better for everyone.