The language trap
By Dean
(2007-10-21 11:00:10)
To me, the scariest thing a programmer can say is, "I don't like X, I'd rather use Y," where X and Y are the names of programming languages. It means that whoever said this has fallen into the language trap.
We, as computer scientists, have many different programming languages at our disposal. From object-oriented languages like Java and C# to functional languages like LISP and Haskell to interpreted languages like BASIC and Perl to entirely bizarre languages like those found on Esolang, the esoteric programming languages wiki. Those of you not familiar with this might tend to think, "Why do you have so many different languages? Isn't programming just telling the computer to do things?"
The reason why we have so many different languages is because each language is created with a particular set of problems in mind. Though each language is inevitably compiled or interpreted into the same machine code, different languages are more suited to specific tasks than others. In general, if a language was designed for a specific task in mind, then if you are writing software that needs to accomplish that specific task, then you should be using that language.
For example, Perl was designed for parsing strings; Java is designed primarily for platform independence (the same code can be run on any machine running any operating system); XSL was created specifically to parse XML documents and transform them into other document types in entirely different (if desired) formats. I can go on. There simply too many programming languages to enumerate here.
It is paramount as a programmer to know as many different languages as possible, if only at a high level. Obviously no one person can have intimate knowledge of all languages; however, one can easily know the major language paradigms and know major languages that implement those paradigms. Indeed, even across language paradigms the majority of programming concepts still hold firm. After all, all languages are there to accomplish the same goal: to facilitate the programmer in creating the desired software. The differences are just niceties that allow us to produce software faster and better.
And thus is the language trap. One is trapped if one thinks one language or paradigm is fundamentally better than all others. Someone who is trapped in a language will not see that it is silly to write string-parsing libraries for XSL, or that JavaScript's object-oriented facade is nothing more than buzzword compliance (more on this some other day). This person will spend days trying to mutate one language (his preferred language) into an already-existing language he doesn't know about because his mind is closed to alternatives.
The language trap can even instill such arrogance in those trapped that they speak such nonsense as denying an entire paradigm as useless simply because it does not conform to their ideals. Take a look at this article, Inheritance is evil, and must be destroyed. Inheritance is a fundamental concept in object-oriented programming. Due to his exposure to JavaScript's terrible object-oriented implementation, the author builds a straw man example of how inheritance should not be used in any situation. He is simply missing the whole picture, most likely because his only exposure to object-oriented design is in his preferred language.
I'm not entirely sure how people first fall into the trap. I know of several people from both real life and online who have fallen. In one case, I suppose he fell for rhetoric from those who were already trapped. In other cases, I'm not so sure. I do know that practically no time at all is spent teaching this lesson to university students (at least at Waterloo, my alma mater), beyond teaching a few different paradigms. No extra effort was expended by saying, "No language is suited for everything, and so while it's OK to have a preferred language, it's not OK to not consider using a different one." How much impact such advice would have, I don't know.
One language does not suit every task. If that were so then we'd only have this one magic language and no one would ever have the need to create new languages. Don't fall into the trap — learn as much as you can!
Language integration is a pain...
By George Caswell
(2007-12-10 16:33:40)
There are, at present at least, certain obstacles to integrating languages from different programming languages that make domain-specific programming languages apparently less-attractive. Even the Unix command shell, which is supposed to be a kind of playground for working with a collection of tools written in other languages, has fallen into decline. People apparently prefer to incorporate all their necessary tools into Perl or Python or something and call them from there. I believe this is because in Perl or Python you get a more complete programming language environment than you do in the shell: assumptions about datatypes and calling formats that you can rely on, and thus a level of inter-module operation that's higher than what you can get from the shell.
I believe the inter-operation problems need a much better solution if the idea of domain-specific programming languages is really to work. I believe .NET is, in part, an attempt at this, though I don't know too much about it.
P.S.: What's with that "Esolang" link? I saw the link to it you wrote into the page and thought, oh, wow! That sounds like fun! But it seems like almost all the ideas on that page are jokes. Or at least, not good examples of what a domain-specific programming language could be, but rather just examples of how a programming language could be intentionally made weird...
Indeed
By Dean
(2007-12-12 09:58:07)
I think the problem of language integration is our tendency to think too high level about certain things. We want this thing called "language interoperability", which is one language using a generic API to call a function inside a library written in some other language. I would argue that this concept itself is flawed.
Think of the way interoperability is accomplished in Unix. Instead of calling one particular function using some magic API directly into a foreign library, Unix has only executables. Interoperation is on a much lower level. You're not calling a foreign function, you're executing another application, supplying it with its input and waiting on the result, trusting that it will do its job.
Instead of trying to expose magic generic APIs to call foreign functions, the Unix approach is to write wrappers for common tasks so that they appear, in your high-level language, as simple functions. In reality they're completely autonomous applications written in their own most appropriate languages.
.NET tries to look at the problem from an interesting level. J#, C#, VB and other .NET languages all "compile" into the same intermediate language, so .NET's "interoperability" is really not thus. It fakes the concept by making it seem that C# and VB are calling each other's functions, when in reality C# and VB are the same thing.
Regarding the Esolang link, it's a site that isn't really dedicated to domain-specific languages, but rather to coming up with novel programming paradigms and metaphors. While the languages on Esolang aren't really meant to be used in the real world, it is a very useful site to reinforce the concept that not all languages are created equal, but still have a lot in common at a fundamental level.