Being Multilingual

One of the things that naturally happens as people become more exposed to things is that they develop a vocabulary to describe those things. Classically (though somewhat controversially) this is exemplified by the idea that the Eskimos of North America have dozens of words for snow - as the frequency with which something is observed increases, so does the precision with which we’re able to describe it.

Just as we develop new words to describe those things we see in our world a lot, thus extending our human natural languages, so too do we add new computer languages to help describe and control the digital world as new concepts take hold.

This is what’s happened over the last decade or more, as data has become an increasingly important and truly central part of business life. While SQL has existed for a long time and has been the lingua franca of data professionals for decades, with the exponential increase in focus on data, other languages have taken root as strong alternatives - Python, Scala, or R, for example.

As the field continues to advance, more languages will certainly be added to the mix, new toolsets will arrive centered around those languages, and more specialization will be needed to attend to the work driven by those tools and those languages. So the question will start to become: which language should I learn?

The answer is not a clear, cut-and-dried one; instead, it feels like a bit of a hedge. Maybe it is: you should have a number of data languages in your pocket. I personally love SQL, it’s like a second language to me, and Python is increasingly meaningful to me. But neither of these is necessarily the “right” language - that’s going to be determined situationally, by what’s happening on a project and what the desired outcomes are.

But more important than choosing which languages to learn, or when to learn them, is developing the skill of being able to learn a language in the first place. Of being able to understand the semantics behind what you write in one language, and understand how those same semantics might be conveyed in another language - even in a rough sense. I’m probably never going to stop thinking about data problems first in SQL before any other language. But if I can think about the data manipulation I’d encode in SQL, and take it piecemeal into another language, it’s much more valuable than having learned the syntax of a language that has minimal semantic meaning to me.

Dataploma doesn’t bind itself to any particular language or technology because concepts transcend the technologies and we believe that the concepts - and the ability to apply them abstractly and independently of language or technology - are more important. Languages help to describe and implement the concepts, and we all should strive to be multilingual in that regard.