Is Polyglot programming important?

Question

Trying to learn more about Polyglot programming.
What is it exactly and is it important?

I found this article by Ted Neward (Thoughtworks) interesting.

Article suggests that polyglot programming was first mentioned by Neil Ford.

Answer 1

It can be useful as all languages and paradigms are good for certain things. Making use of the appropriate language/feature/paradigm for a given part of a problem can lead to a better solution.

Answer 2

According to the website,

Polyglot Programming is a website dedicated to exploring the benefits (and drawbacks) of combining multiple programming languages and multiple "modularity paradigms" in application development. The "paradigms" include Object-Oriented Programming, Aspect-Oriented Programming, Functional Programming, etc.

Is it important? The author wants you to believe that it is...

Answer 3

Different languages have different strengths and weaknesses. You would not write a one-off script in C or a low level device driver in perl.

Polyglot programming is about using a mix of languages that complement each other. For example low level languages like C or C++ run fast but are slow to develop in, while high level dynamic languages like Python and Ruby enable rapid development but run much more slowly. A common paradigm is to develop primarily in a high level language and code the bottlenecks in a low level language when necessary.

Another example is to use a functional language for handling concurrency or a declarative rule language for handling business logic in combination with an OO language like Java or C# for the user interface.

Answer 4

The first question has been answered pretty well: polyglot programming is about using multiple programming languages together.

It is terribly important and not at all. Serious.

Every earnest piece of software includes at least 3 languages: Some more or less all purpose language like php, c#, java you name it. Add HTML + SQL + Java Script + a language for building this sutff and you are well in Polyglot programming land. So there really isn't anything new about this stuff.

What is new is that people want you to:

• use different languages for different pieces of your software, without being forced to. E.g. using Java for complex logic, while using Groovy for glue code.

• write your own DSLs to work with.

Both ideas aren't inherently bad. Trying to do this kind of stuff will broaden your knowledge. But in most projects 80% of the people understand only little pieces of the complete project. And it doesn't help when the other pieces are in a language they don't even program fluently.

So if you aren't part of an extremely skilled team, you won't (and don't want to) see much of this.

What might happen though is that you will use a library in java land, which was written in scala, but this shouldn't affect you much.

Answer 5

Trying to learn more about Polyglot programming. What is it exactly and is it important? Look like it is cross platform coding and interoperability across platforms...

Nowadays almost not a single project is realized from A to Z with one language. You may like it or not, but we are all getting polyglot programmers.

Consider for instance JEE: it is not only about Java as a language, but about XML configuration files, XML templates for page rendering (JSP, JSF), etc. All these are actually different languages. And it doesn't stop here. There are build file such as Maven which once again represent some form of language.

The same apply to all other technologies. We have languages within languages, with fluent interface embedded in a host language. For instancece jQuery and javascript. We interoperable between systems with web service and SOAP, yet another language. We use AOP, annotation, depenency injection and other patterns. And the list goes on.

This is an important challenge and research topic. Lots of tools and technique have been designed for one language and they need to be expanded to a multi-language paradigm.

This raises numerous issues. Examples:

• refactoring. In a polyglot world, a refactoring should consider all elements in the languages of the project, for instance configuration files, etc.

• debugging. The debugger stops at what the host language provide. Ever got a crazy exception because of several framework being stacked together with their one concepts. This is again a challenge of polyglot programming.

• modelling, say with UML. How do you cope with the many languages, DSL and frameworks that are used together?

• searching. How can you efficiently search within heterogeneous sources, without being at the syntactic level but at the semantic level?

• and many more...

We see a better support for this reality more and more within IDE, but there is still a lot of work ahead of us.

Answer 6

As mentioned already, it is hard to do any modern development in a single language. At one of my current contract positions, I do Java EE work so throughout the day, I am constantly working in not only Java, but with various XML related technologies as well, XSD and WSDL to name just a few.

I would say that almost any non-systems specific stuff involves more than one language. Especially web based programming. It is hard to do anything substantial on the web without knowing XHTML/DHTML/CSS/JavaScript and than whatever your back end is written in, C#, Ruby or PHP for instance.

I think any programmer should strive to learn other languages. If you work with Java a lot, learn C# or vice versa. Even if you don't like the language, or decide not to use it, much like learning a foreign language will help you understand your own language better, it will make you a better programmer.

Answer 7

It's pretty funny to see him use Emacs as an example of "polyglot programming":

PPP is not a new idea. One of the most successful applications of all time is Emacs, which is still widely used even though it is over twenty years old. Emacs succeeded because it combines a fast kernel written in C, which gives Emacs speed and access to operating system services, combined with a scripting engine that uses a Lisp dialect called Emacs Lisp (or ELisp, for short). Most of the functionality of Emacs is implemented in ELisp. It is this scripting capability that has made Emacs so easy to adapt, even by end users, to meet changing needs over the past 20 years.

Yet the fact that the kernel is C isn't important (it also doesn't make Emacs fast!), and in fact there have been fully Lisp implementations of Emacs from time to time. C happened to work well because in 1976 it was the only reasonable systems programming language. But Emacs is long lived because it offered a language with tremendously rich abstraction: Lisp.

To anybody who thinks it's merely the "polyglot" architecture: why have other editors with "polyglot" architectures not been at all successful? I can name a dozen text editors which were extensible with REXX, yet almost every programmer I know uses Emacs, and no programmer I've ever met used one of them.

Yegge dropped 3500 words on why Lisp is perhaps the least bad solution to this problem. Roughly: a homoiconic tree-structured language tends to win big at processing tree structures, which is what pretty much all of your text files are in disguise anyway.

What would you rather do? Learn 16 different languages and frameworks in order to do "simple" log-file and configuration-file processing? Or just buckle down, learn Lisp, and have all of these problems go away forever?

It's a rhetorical question. The answer is patently obvious at this point: Lisp is evil, and you'd damned well better write all your code in C++ and XML and JavaScript and PL*SQL and CSS and XSLT and regular expressions and all those other God-fearing red-blooded manly patriotic all-American languages from now on. No more of this crazy Lisp talk, ya hear?

I guess the moral of this story is that when you invent a new ____-Oriented Programming buzzword, you have to attach it to an existing successful program, and retroactively claim that its success was by implementing your paradigm, even if that program was written 30 years before your paradigm, and even though it wasn't successful because of the reason you state.