Table XI

How testing new programming languages helps our developers solve problems

For non-developers, it may seem like a new computer language is created every day, each with an uninformative name. Even developers sometimes feel that way. At Table XI, we’re always assessing ways to solve our clients’ problems, whether that’s a new schema for critiquing design or a new language well-suited to a necessary function. Still, the pace of new languages can make it difficult for our developers to try them out — and their new ways of solving problems

To broaden our thinking, this week several members of the Table XI team participated in a challenge: to take the coding exercise we ask our interview candidates to complete, and to build it in a language that’s unfamiliar. Each developer then presented the results to the group, so the whole team could each get an understanding of the new languages available, and an understanding of how our teammates approach a new language.

We wound up with nine presentations in eight languages. The first was Swift, Apple's next-generation language for iOS and Mac development. We use this extensively, but not everyone is familiar with it. The challenge gave those people a chance to test it out.

Then we had three languages that we’d all heard something about, but few of us had used. Each of these might be perfect for a future project, or part of a project, so we wanted to familiarize ourselves with them ahead of time.

Elixir, in particular, seemed to get a lot of interest, especially because of its syntax for “pattern matching”, choosing which method to execute in the codebase based on the values of data at runtime. Pattern matching can be used to simplify complex coding logic — by separating the logic of different cases, we can make each individual case smaller and easier to write.

We also tried out three languages that are probably too new for us to use. These languages are still changing and don’t yet have the ecosystem to sustain most of our projects, but they may work in certain cases. We also want to keep an eye out for new technologies that might mature into useful solutions down the road.

We also tried out one language that’s historically important, even though it would be impractical for most of our uses. Smalltalk, is the first pure Object-Oriented language, and it comes with its very own integrated development environment. Trying it out allowed us to experience a language many of us had only learned about during college.

Nine presentations in 45 minutes gave us a quick overview of how each language might differ when tackling the same problem. Some of the languages encourage recursive solutions, others have objects, records, or different kinds of data structures. Some have their own development or display environment. Each is the right key to unlock a particular problem. Knowing what’s out there equips us to identify the right language for a particular project. But even if we never use a language, seeing how it approaches a problem keeps us sharp and gives us another approach to try when we’re struggling with our own solutions.

We highly recommend doing a new language challenge with your team. Not only is it a great method for testing new programming languages, it gives everybody some exposure to new and different tools and gives everyone on your team a chance to teach their approach. Here’s how to get started:

Given how helpful the new language challenge was, we’re going to keep going with the same basic idea. Next up, we’ll probably try a new framework challenge, where we look at different web frameworks.