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 TXI, 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 TXI 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.
- Clojure, a Lisp-based language on top of the Java VM
- Elixir, a pattern-matching functional language built on top of Erlang
- Lua, a small scripting language often used for dynamic game logic
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.
- Elm, a typed functional language that compiles to JavaScript and runs in a browser. We found the type system to be a little opaque, but it does give great error messages and has an interesting built-in Model View Controller (MVC) framework.
- Emily, a relatively new functional language, where everything is a function.
- Julia, a dynamically typed language designed for scientific computing.
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:
- Identify a common problem — We were lucky that our interview coding challenge was suitable, but any of a number of code kata-sized problems will do. It’s probably best if the solution is not super long.
- Pick the languages. We made our list based on what people were interested in, and what we felt like we should be keeping an eye on. We let each developer pick the language he or she wanted to try out, so everyone’s working on something that engages them.
- Bug people to get it done. Giving a deadline is important. Setting a date for the presentation ensured everyone would finish up their work by a certain point — or risk presenting incomplete thoughts to the team.
- Let people teach. Have everyone who solved the problem take a few minutes to talk about the language, explain what makes it unique, show their solution and identify problems they had. By teaching back to the team, everyone gets to learn a little bit about the language, and the problem solver gets a chance to distill his or her thoughts. We gave people five minutes to present, and we’ll probably try 10 minutes next time we take this challenge.
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.
Published
by
Patrick Turley
in
coding
