RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


ThoughtWorking: Why the Next Five Years Will Be About Languages

Writing software is hard, particularly when the tools you use force you to think at too low a level. At that point, it’s time to start thinking about changing the way you write code…by making it easier to write code.


ack in the days of our fathers, programming meant focusing on learning one language, one platform, and one environment, and mastering it over a span of years. Those years are long behind us, along with half-decade project development times and bell-bottomed pants. It's time to take a hard look at the "state of the union," per se, and see how you can think about how to work better, rather than just putting in more time.

Thanks, Ken Getz!

As frequent readers of this magazine will already know, Ken Getz used to prognosticate and discuss all manner of things technical in this space, offering his insights and experience. But Ken has decided to "hang up his spikes," as they say, and Rod and the crew at CoDe Magazine asked me to help fill in for his absence.

Let's be honest, nobody could ever replace Ken's unique perspective, but it's flattering to be asked to try. In fact, it's a touch intimidating, because Ken had a perspective that stretched across decades. Fortunately, I have a solid crew of people with me at ThoughtWorks, the consulting company I work for (hence the name of this column), who are willing to step in and help me try to walk in Ken's footsteps.

Research to Real-World: The Relevance Gap

In the UNIX world, developers have known for years that sometimes the easiest way to attack a problem is to create "a program that writes a program." Sometimes they use Perl, often combined with code-generation. Sometimes they use regular expressions, either fed to a library that returns hits from a string, or compiled into an actual code library that can be included with your code, (another example of code generation, but in binary form). A third trick was to create an entirely new tool, sometimes known as creating a "little language." Today, in a grinning endorsement of the truism that "everything old is new again," this notion of creating the "little language" rises again under the new moniker "domain-specific language" (or DSL), and currently enjoys tremendous media discussion.

The subject of programming languages—or, more specifically, building programming languages—is one that most "line-of-business" developers find hard to relate to. This isn't surprising given that most programming language research has been restricted to the academic and research communities. These restrictions occurred not because those communities don't want their research widely read or consumed, but because line-of-business developers didn't see it as relevant or useful.

Unfortunately, the "relevance gap" meant that a developer out hunting around on the Internet looking for cool new tools or libraries to help build a highly-scalable (meaning highly-concurrent and thread-safe) web application might run across some papers or discussions that reference this concept of "functional languages." Further research might lead to some papers on why functional languages are great for concurrency, sparking more interest. A bit more reading turns up a reference to a concrete implementation of a functional language called OCaml.

OCaml, for those who've not spent a stint in the research or academic community, meshes the functional and object-oriented programming approaches in some interesting ways. For that reason, among others, it enjoys a pretty good following in academic circles, including some interesting forays into the concurrency space. So our intrepid developer begins working with the language, learning the new syntax and playing with the new libraries, and decides that it's interesting enough to use for building something real. She decides to prototype it for use on her current project.

Like any good horror film, at this point the audience can see it coming, but our developer can't, for whatever reason.

She runs into problems. Not tiny little problems like finding a version that runs on Windows, but larger problems. Obstacles that cannot be overcome in any reasonable timeframe. Building a UI with OCaml is awkward and difficult at best, because it tries to be platform-agnostic and thus relies on other adaptation layers to reach the underlying widget set. Accessing Windows-only features (such as printing) will be a pain, requiring her to build a "trampoline" layer to access native C-based Windows APIs to do anything. Trying to connect with any modern relational database implementation will require…patience.

The problem isn't really our developer's fault, nor is it OCaml's, to be honest. It's not that OCaml isn't interesting—it is—but out of the box (so to speak), OCaml isn't a language that a line-of-business developer can use in any sort of pragmatic sense. Which means, unfortunately, that not only did our developer waste her time researching the subject and discovering its applicability, but she also learned that academics and researchers are not nearly as interested in creating real-world, production-ready solutions as they are in exploring ideas, at least to the point where they can prove or disprove an idea. How likely is our frustrated developer to trust something coming out of the academic or research community in the future?

Therein lies the heart of the problem: academics and researchers focus on trying to solve problems that line-of-business developers may not face until five or ten years down the road, and that forward-looking focus often comes at the expense of helping to build today's solutions.

Stay with me, friends, there is light at the end of this rather bleak tunnel.

Editor's Note: This article was first published in the March/April, 2009 issue of CoDe Magazine, and is reprinted here by permission.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date