James Thigpen

Everyone is blogging about Domain Specific Languages these days. Even beyond DSLs there are a lot of languages these days to care about. C++, C#, VB, ASP.NET, Java, Ruby, Python, PHP. The list goes on and on! Programmers need to know more languages than even the most freakish polyglot savant.

Sometimes we like this. This is where DSLs come in. Sometimes it’s so much easier to express a concept in one language than another, especially if your language was designed for one specific task. But it’s becoming next to impossible to use all these different languages simultaneously without a huge amount of glue code being written.

Have you ever been to a multilingual house? People change languages in mid-sentence, using words which more closely reflect the concept they’re trying to communicate regardless of its language. They use words which come more easily to them.

Imaging being able to choose your language in mid-program, in mid-method even. Yes, projects like Ruby on the JVM and on the .NET CLR and similar languages on virtual machines are nice, but trying to bridge the JVM to the .NET CLR or, heaven forbid, native code is painful at best. We have all these languages, but sometimes we have extant code which needs to be utilized. This is still very difficult to do.

Maybe all the old code will have to die. It lacks metadata. It’s much closer to the hardware than anything running in a virtual machine. Can a virtual machine expose enough functionality that we no longer need to drop down below it to do nitty gritty things?

My perspective is warped I suppose, I have to interface with hardware components. Actual real-world hardware components, and it is terribly annoying. What’s more annoying is I know how difficult the problem is.

I hate when I only have problems and no solutions.