Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Niclas Nilsson on Sep 25, 2008
Have you ever wondered why people talk about having “the right language for the right job”? Or why people talk about using more languages within the same system?
In this article, Sadek Drobi explains why you should consider mixing languages within you system. Sadek explains how different languages support different kinds of problems better (or worse) due to the nature of the language and the nature of the problem.
To dig deeper and to gain understanding of what polyglot programming can do for you, you find the article here: Paradigm based Polyglot Programming.
Technical Debt and Design Death
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Innovation in Your Data Centre
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
There's more info on the topic on Neal Ford's blog. The first entry I recall seeing dates back to 2006.
memeagora.blogspot.com/2006/12/polyglot-program...
Good stuff though...
...and a very good abstract on the topic. Developers definitely need to take more time choosing the right tool*S* for the job*S*. I am however a bit skeptical on the low weight given to the Team Members’ skills factor! I agree that very often, people are just too lazy to even consider learning a new language/skill. But at the same time, when does it make economical sense for a project to grind to a halt so that a new language can be introduced?
Also, what about the community of users/usages built with time around programming languages? I am for example curious to hear whether the case of javascript was excluded on purpose or was just an oversight.
?
@Jared:
Sure, Neal already wrote a lot of interesting stuff about Polyglot Programming as did Ola Bini and Martin Fowler too. However the focus of this article is more about considering paradigm of the language as the most important property of the programming language when doing domain analyses. The article describes an approach inspired by the referenced James Coplien's work on Multi Paradigm Design and Eric Evans' Domain Driven Design.
Thank you for the reference Jared.
@Olivier: Javascript and other languages that wasn't mentioned here haven't been ignored. I just mentioned in the article few examples and the list is far from being exhaustive. Yet javascript properties are interesting to study and consider.
Great Article!.
I want to point out two issues that may be missing from the discussion.
My thesis was actually the construction of PLOG, a logic programming language ala Prolog, but Object Oriented (OOPL). Here you have a combination.
To create an interpreter for that, we used C language plus Prolog to build a meta-interpreter (if you want to add to the mix).
Of course, there were two problems there: Find a way to blend PL and OO into the same language (Done by my professor) and a way to integrate both implementation languages into one product.
Some time ago I've heard about the idea in Java to include XML as a native type, that is the language will understand XML not as a product process but as a natural part of the language. Of course the result was not natural at all.
Having both paradigms in the same language is not an easy task, but if not included, you will need to work with round objects using a language for square ones!
That last issue is present all the time you want to work in a polyglot environment, impedance mismatch may appear too. So first thing to solve is how easily is to integrate two paradigms.
Now, DSLs can be used to solve problems in the actual domain of the problem. But you have always two spaces: the problem and the solution space. The problem one is where the client lives, and you may want to have a language in that domain to solve the problem from that perspective. But the solution of the problem requires you to work with technology, which is another domain. Thus you may need to use languages to work with those technologies, and the problem domain language is not appropriate. That is the second problem.
All that adds another dimension to the discussion: you need to know where are you working (space) and how to integrate all languages you use seamlessly.
What do you think?
William Martinez Pomares.
Architect's Thoughts
@William : The integration of several languages/paradigm on the same project is in my opinion more domain bound than technical. What I mean is, and as you mentioned, the problem exists even if you use a multi paradigm language. The technical integration of several paradigms in a multi paradigm language does not take into account your specific domain or problem.
What I want to say is that seams do exist. There existence is at the domain level between sub-domains. We can not, and more importantly should not, ignore them. Considering the right seams can have its good effect on the integrity, extensibility and flexibility of the software.
Thanks for the supporting example about multi paradigm languages from your own experience.
Hello Sadek.
I agree totally with you. That is actually what I'm trying to state above: You are working with several domains, some from the problem space and the others from the solution space. The seam does exist, and it is not difficult to ignore. A bad seam may cause malfunction or impedance mismatch.
Good Article!
William Martinez Pomares
Sure, polygot programming is quite opposed to multi-paradigm languages.
I can give my own examples about multi-paradigm languages. Let's cite OCaml (from ML family) for example:
- functional
- imperative
- modular
- OO
- with some stream processing features too
Quite a few paradigms.
More people know its cousin: F# as F# is very strongly based on OCaml as Microsoft said itself.
One could see also :
- JoCaml and Acute for concurrency programming (partially sponsored by Microsoft Research) on top of OCaml.
- OCamlDuce is a merger between OCaml and CDuce, in order to introduire CDuce XML features into OCaml.
Similar languages in Microsoft world do exist : while F# puts functional features into C#, C-omega gives C# some XML features.
One key point here is type inference. It alleviates the burden for mixing paradigms into a single language.
It looks like Microsoft has quite well understood about the importance of type inference, as its main base language, C#, has inherited some type inference features too.
Another example of multi-paradigm stuff could be achieved through translators, just like Java-to-JS translator into GWT.
So, the battle is strong on both sides (polygot programming versus multi-paradigm), and I don't know which one is going to win. IMHO, while I strongly prefer multi-paradigm languages, I try to avoid "Highlander Fallacy" ("there can be ‘only one’") bad effects - here is an example.
I can't say also if having a common VM is a plus, or not for polygot programming. SUN and Microsoft, from my Java point of view, are promoting different sides:
- SUN looks like to promote polygot programming through JRuby, JPython and so on.
- Microsoft looks like to promote multi-paradigm languages through more research and development around C# with F#, C-omega and other languages.
Time will tell. Anyway, it's an interesting stuff, thanks for the post
Dominique -
blog
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
8 comments
Watch Thread Reply