I've fielded another slew of relevant comments and emails on last week's post on multilingual development, both for and against my stated points. Delving into these waters always makes for brisk responses, and there is vehemence on both sides.
I'm not entirely sure why this is, but it's probably the same basic human impulse that is behind the Chevy truck with a picture of a kid peeing on a Ford logo, or the Ford with the child defiling a Chevy logo. It's also the same reason we no longer have "Calvin and Hobbes," but that's a rant for another day.
We tend to get very much tied to our "favorite" language, and moving outside those boundaries can be difficult for anyone. We get comfortable in our chosen shells much the same way. Moving from a general Bash shell to Zsh can open up a world of different options and potential reflexes, but it's foreign enough that unless and until we invest the time to learn the intricacies, we get a bit angry at the whole thing and go back to Bash to get stuff done. Not all of us have the time to invest in reworking a few decades of reflexes, no matter how promising the end result.
But moving through different languages is very much a crucial exercise from time to time. As comfortable as we get in any language, shell, or app, we tend to wear out the commands and practices that we use the most, and once we've established a working baseline, we tend not to tread too far from those comfortable spaces.
An example of this would be that to this day in Vi, I habitually hit "w" three times to move forward three words, or "0" to move forward to the end of a line, rather than use the more concise motion operators such as "3w" or ")". The same is true to move to the top of a file -- I will always reflexively hit "1G", not "gg". These reflexes might as well be carved into stone.
So it is with development. We have our known-solid functions, our tried-and-true methods, and our go-to modules in our favorite language. While we may know another language, we'll be heading into less familiar waters when we get to these elements.
The funny part is that in many cases, the need to revisit these known-good methods can many times produce even better and more robust methods in both languages. Once we've written something a few dozen times, we stop seeing the logic behind it. We just know that we drop this function in place, feed it, and get what we want back from it. A few years down the road, if we look at the same function through the eyes of a different language, we might see optimizations that we hadn't before. New eyes on old code can be both wonderful and terrible at the same time.
When you get right down to it, Web app developers have to be fluent in several languages just to get started, regardless of the core language. Sure, it looks very simple to write 10 lines in Rails and have a Web app that performs some minor function like inserting a text field into a database and displaying it back. But if you aren't well versed in the underlying languages that make it happen, you'll be extremely limited when trying to do much else and severely challenged when trying to figure out why something's broken.
As I said last week, being a multilingual developer not only increases your options, but also offers a deeper insight into what a given project really needs versus what a given language can provide. The best part is that you're already a multilingual developer if you've ever written a Web app.
With that in mind, carving out a few days to take something you've written in one language and rewrite it in another is the fastest way I know to really dig into a new language. It's reinventing the wheel, to be sure, but the template was yours to begin with, so at least the wheel you're reinventing was your invention in the first place.
This story, "Don't want to mix programming languages? You already do!" was originally published by InfoWorld.