Is polyglot programming dead?

[Moandji Ezana]

In 2006, when Neal Ford coined or popularised the term polyglot programming, it seemed to gain some popularity.

However, in the past few years, the trend seems to have gone towards using as few languages as possible.

In Java you could use GWT or Android on the client and Hibernate on the server and not see either JavaScript or SQL.

With Node.js, JavaScript becomes the common language. Fantom and Clojure (via ClojureScript) can also compile to JavaScript.

Was polyglottism ever a good way to build an application? Is this just a pendulum swing or rather the result of more powerful tools?

Moandji

[Martijn Verburg]

I'm personally seeing the opposite, well with a caveat. In London
we're seeing increased use of multiple languages on the JVM for a
single project, e.g. Java/Scala or Java/Clojure + the usual
smattering of web languages if that's what you're building - M

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Sat, 21 Jan 2012 14:31:26 +0100, Moandji Ezana <mwa...@gmail.com> wrote:

> In 2006, when Neal Ford coined or popularised the term polyglot
> programming, it seemed to gain some popularity.
>
> However, in the past few years, the trend seems to have gone towards
> using
> as few languages as possible.

I don't know whether it was a passing fancy...

>
> In Java you could use GWT or Android on the client and Hibernate on the
> server and not see either JavaScript or SQL.

... but you have JPAQL. I'd say that you can only avoid it in simpler
cases.

> With Node.js, JavaScript becomes the common language. Fantom and Clojure
> (via ClojureScript) can also compile to JavaScript.

Compiling to JavaScript just doesn't mean you're noy polyglot. In this
case JS serves as bytecode.

>
> Was polyglottism ever a good way to build an application? Is this just a
> pendulum swing or rather the result of more powerful tools?

Actually we have created an ecosystem where it often happens that a rock
star extracts a new concept from his bag and we have some "wow" effect,
and it seems that from now on everything must be done in that way.
Fortunately, the effect sooner or later vanishes, but the good idea
remains. For what concerns me, I don't feel compelled to be polyglot. I'm
just fine knowing that I can have multiple weapons to do something and I
can pick the best fitting if I want.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Alex Turner]

I have rarely worked somewhere where enough folks on the team had overlap in more than the core skill set.  Ancillary tools are always handy, but they end up being just that.  They are mostly esoteric and limited in understanding to the one person that created them.  This is a great pity, but it just seems like that's the way it goes.

For every little script and subsystem in another language, it's yet another build or script that has to be understood in order to use it for the rest of a team, and ultimately they either never get used or simply just slow the team down. This seems to go double the more 'brilliant' the polyglot is.  They'll create this amazing script, and it's so amazing that only a high skill  programmer in whatever specific language could figure out how it works.  Somehow this is a badge of honor to some, but it seems like it should be a badge of shame when you create things no-one else can work with.

Also, the fewer the languages, the easier it becomes to be expert at them.

Alex

[Kirk Pepperdine]

polgot programming.. well who knows wft that is.... but I do see more people using more langauges on the JVM.

Kirk

[Vince O'Sullivan]

On Jan 21, 4:21 pm, Alex Turner <alexrmtur...@gmail.com> wrote:
> I have rarely worked somewhere where enough folks on the team had overlap in more than the core skill set.  Ancillary tools are always handy, but they end up being just that.  They are mostly esoteric and limited in understanding to the one person that created them.  This is a great pity, but it just seems like that's the way it goes.
>
> For every little script and subsystem in another language, it's yet another build or script that has to be understood in order to use it for the rest of a team, and ultimately they either never get used or simply just slow the team down. This seems to go double the more 'brilliant' the polyglot is.  They'll create this amazing script, and it's so amazing that only a high skill  programmer in whatever specific language could figure out how it works.  Somehow this is a badge of honor to some, but it seems like it should be a badge of shame when you create things no-one else can work with.

I think that's a pretty spot-on description of team programming.

[Ricky Clarkson]

That's true, the problem is related to teamwork more than number of
languages. The hardest to understand systems I've seen were written
only in Java, and I have worked somewhere that used custom languages
(interpreted variants of C).

I think the solution is not to standardise on one language, although
that may help in certain cases, but to make parts small enough and
their inputs and outputs well-understood enough that not understanding
the code is not a disaster as the item can be rewritten without too
much drama.

[Jon Kiparsky]

"They'll create this amazing script, and it's so amazing that only a high skill  programmer in whatever specific language could figure out how it works.  Somehow this is a badge of honor to some, but it seems like it should be a badge of shame when you create things no-one else can work with."

I do hope that clouds parted, angels sang, and a beam of light shone down upon you when you wrote that. Yes, yes, yes, a thousand times yes: code that is not written to be understood is bad code, regardless of how smart you had to be to write it in the first place. Brilliant writing is writing that communicates brilliantly, not writing that communicates the fact of the writer's (supposed) brilliance.

[Moandji Ezana]

On Sat, Jan 21, 2012 at 3:45 PM, Martijn Verburg <martijn...@gmail.com> wrote:

In London
we're seeing increased use of multiple languages on the JVM for a
single project, e.g.  Java/Scala or Java/Clojure

How do things tend to be split between the two? Programmer preference, performance needs... ?

Moandji

[Martijn Verburg]

Hi Moanji,

Mainly performance needs or a particular language feature that's
compelling for the problem domain (e.g. Statistical analysis with
Clojure/Incanter, immutable data structure modelling in Scala etc).
Often it ties into an existing core of Java (domain logic).

We advise people to go through the sorts of Ola Bini pyramid analysis
that we outlined in Java Magazine:

http://www.oraclejavamagazine-digital.com/javamagazine/20111112#pg51

Cheers,
Martijn

[Casper Bang]

These days, we need/use more abstraction levels than we used to because the stack is simply bigger and more complex. If we equate abstraction level with paradigm, and paradigm with language, it makes good sense that the pendulum now swings in the multi-paradigm corner. Scala is an interesting example where everything but the kitchen sink is thrown in: declarative XML literals, imperative code for your mutable business logic, OO for encapsulation and FP for concurrency as well as declarative internal DSL's.

I tend to think of polyglotism as a necessarily evil of the past, and while Scala goes a tad bit far, I do think the future is in general purposefulness baked in. It won't happen from day one though, it takes time to generalize and iron out inconsistencies. However, there is no sane reason for why we should be limited by a JDBM/ODBC driver when wanting to query/map/project over a collection of data, let alone be forced out into embedded internal DSL's (SQL, JPQL, HQL...) when 90% of what your average program does is to read data, transform it, and store it again. Microsoft codified this with LINQ and although not native to the stack, I do believe Scala allows for this as well. There are countless examples of the default medium of expression being lackluster and thus giving birth to polyglotism, i.e. look at how Google came up RenderScript (though that may say more about Java than RenderScript).

Many a language designer have said that the hard thing is not what to put in, but what leave out. Even Odersky apparently now regrets having put stuff like XML literals in and he constantly has to defend the complexity of Scala. Not an easy job to design a general purpose language.

[Rakesh]

Hi,

I'm not sure if this is common in other industries but at any one time
we have people developing software commercially:

1. Writing COBOL against mainframes setup in the 70/80's.
2. Writing and maintaining EJB 2.x apps.
3. Various versions of the JVM
4. The latest JVM languages

My point is a new way of working becomes possible in 2006. It may not
actually reach the average development workshop (if at all) for many,
many years.

My last project used Java 5, JSPs and MySQL. A bit long in the tooth
you could argue (and I did!).

My new project is the more cutting edge - Java 6(!), MongoDB and the
JVM layer - Java is ok but Groovy is preferred (we use Grails).

I am really impressed by Groovy. It really allows you to take your
time migrating to its syntax, reducing the initial load and
complexity. Ruby and Scala feel like to big a jump.

I think polyglot programming will only get bigger and more popular,
especially as the tooling (IDEs and cross compilers) become better.

Rakesh

On 21 January 2012 13:31, Moandji Ezana <mwa...@gmail.com> wrote:

[Casper Bang]

On Monday, January 23, 2012 11:34:25 AM UTC+1, raks wrote:

My new project is the more cutting edge - Java 6(!), MongoDB and the
JVM layer - Java is ok but Groovy is preferred (we use Grails).

I think polyglot programming will only get bigger and more popular,

especially as the tooling (IDEs and cross compilers) become better.

A dynamic language like Groovy can obviously talk to anything, but you loose toolability/interoperability when dynamic invocation is more than just opt-in for a specific subsystem. I'm not sure I see much polyglot in using Groovy to query MongoDB, when the native language is JavaScript. 

However, it may well demonstrate a more strict nuance of polyglot (semantic polyglot?) that includes type interoperability, which I would consider far superior to having isolated language silos with crude interfaces between them. After all, Neal Fords definition of polyglot represents the way we have been developing programs over the last 30 years or so, and I think we're ready to move on.

[Rakesh]

Hi Casper,

you've taken it to another level!!!

If what you say is true, I should ditch the JVM and use Node.js
because my data is JSon in MongoDb! Thats not how decisions get made
corporately.

The common, default situation would be to use Java to talk to MongoDb.
What I'm saying is that by using Groovy, you can be more productive
and have a shallower learning curve. The issue isn't that the data is
Json.

Its deciding that Java, alone, is not the general purpose language to
use always in an app.

Cheers

Rakesh

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/Ot0nNYxMyLYJ.

[Casper Bang]

you've taken it to another level!!!

I tend to do that.

 

If what you say is true, I should ditch the JVM and use Node.js
because my data is JSon in MongoDb! Thats not how decisions get made
corporately.

Well, corporation favor standards over... everything else. The illusion that they can scale teams on-demand can also explain why Java has gotten so successful (on the server) even if we all know the hard thing is not Java itself, but knowing the associated IDE's, build-tools, frameworks and toolkits. I am writing a lot of GWT, even if my gut feeling is that I might as well pull the curtain aside and deal with pure JavaScript (through JQuery).

 

Its deciding that Java, alone, is not the general purpose language to

use always in an app.

Can't argue with that. But it sounds like Groovy is your general purpose language. Is there anything you do NOT use Groovy for then?

PS: Btw. Fantom also speaks native JSON.

[Eric Jablow]

On Jan 22, 6:16 pm, Jon Kiparsky <jon.kipar...@gmail.com> wrote:
> "They'll create this amazing script, and it's so amazing that only a high
> skill  programmer in whatever specific language could figure out how it
> works.  Somehow this is a badge of honor to some, but it seems like it
> should be a badge of shame when you create things no-one else can work
> with."
>
> I do hope that clouds parted, angels sang, and a beam of light shone down
> upon you when you wrote that. Yes, yes, yes, a thousand times yes: code
> that is not written to be understood is bad code, regardless of how smart
> you had to be to write it in the first place. Brilliant writing is writing
> that communicates brilliantly, not writing that communicates the fact of
> the writer's (supposed) brilliance.

However, there are situations where going outside the world of
your project's preferred language is the only useful and maintainable
way to go. I remember learning flex and bison to generate code
for an Objective-C project I was on. No one wanted to maintain it,
but doing the work by hand would have taken a lot more time. In the
Java world, I would have used ANTLR or JavaCC.

Most of us know enough SQL to get by; even if projects prefer JPA or
Hibernate or another ORM tool, it's important for the programmers to
know the basics. I'm not saying that one should add additional
languages to a project on a whim or to pad one's resume. I'm not
sure Java/Scala, Java/Groovy, or Java/Clojure projects are worth the
effort. Using all the capabilities of the libraries that your code
depends upon seems easier, though I've run into conflicts even there.
But if the additional language is the correct language for the problem
domain, and if it can be used clearly and integrated clearly, I see no
reason to object.

You do need to work in harmony with your coworkers, though.
Fifteen years ago, I was programming in a language named
MODSIM-2, by CACI. There were no supporting tools; people used
point-and-grunt editors, and spent most of their time mousing
around from one file to the next. Out of frustration, I cored out the
Emacs Modula-2 mode and created a MODSIM-2 mode, and I
improved it over the years. People were alternately impressed and
appalled. I could not persuade anyone else to use it, though it would
have made their work a lot easier. Of course that was the fault of
my 'winning' personality.

Respectfully,
Eric Jablow