Polyglot Programming - is it all Greek to you?
A little while ago, my ThoughtWorks colleague Neal Ford was discussing Polyglot Programming.
He highlights a renewed interest in a diversity of programming languages, particularly those that display constructs that are dynamic, functional, or declarative. Those of us that have been around a while don’t actually think this is a new thing. I’ve learned over 15 languages to proficiency in my 21 years of programming and was looking at the DDJ and Byte CDs for alternative languages well over a decade ago.
Today in Sydney (and later this week in Melbourne), Scott Shaw from our Melbourne office is presenting a ThoughtWorks Quarterly Technology Briefing with the following magnificent title: “Are Dynamic Languages the Next Big Thing? Fight Bloatware to Achieve Faster Time to Market. What IT Decision Makers Need to Know About the New Dynamic Languages”.
At a point in his presentation, Scott asks if corporate IT developers can be polyglot programmers. I asked if it’s all just Greek to them. (Hilarious? It’s gold, Jerry, gold!).
I’m figuring that “it depends”. It depends largely on the level of software craft they employ or enjoy. It depends on the environment they work in and whether a Renaissance view and humanist learning is encouraged. It depends on whether they are seen as, or see themselves as, monkeys pounding keyboards until something good enough is churned out.
Some less esoteric thoughts:
- The difference between C-derivative languages has been minimal until recently.
- Perl is dynamic and has some neat features but appears to have lost the plot on simplicity and expressiveness (Perl 6 is even further off beam).
- Java and C# are mostly object-oriented (although applications written in them generally aren’t)
- Java has incorporated Doug Lea’s fine concurrency package into the API, providing some effective, if somewhat inorganic (due to the nature of Java) concurrency features, and continues that through at least Java 7 with his ongoing work.
- Java and C# are now incorporating dynamic features into the programming model (BSF, DuckTyping).
- More importantly, C# 3.0 incorporates some of the fine language research from Microsoft Labs and includes declarative and functional features (Linq, lamdas).
Some languages you should know about today:
- Ruby. If you’ve used Lisp, Smalltalk, Python or Perl, you’ll probably want to give this one a whirl. If you’re using Excel or Access to glue enterprise data together, learn it - you’re going to have to know it soon. If you’re building a web application that does what most of the other web applications do, learn it and Rails - you’re going to have to know it soon.
- Erlang. If you can hear the avalanche of demands for highly-available, concurrent, non-monolithic processing in business applications coming, start learning. You’ll also understand the purpose of ForkJoinTasks in JSR166y / Java 7.
- Haskell. If you want to understand how high order functions contribute to effective DSLs, or how concurrent life becomes easier when you do away with global mutable state, give it a go. You’ll truly grok the concurrency features in JSR166y / Java 7. Also making some headway in the game software space. Scary syntax, but not as scary as Lisp. It’s a “Maybe Language” (mildly hilarious Haskell in joke).
All of them have growing IDE support (at least Eclipse and IntelliJ, some Visual Studio) and varying levels of development tools (Rake, RSpec, and Migrations will impress).
You could wait until C# and Java catch up with building these features in as core constructs in the language, making them more idiomatic, less cumbersome and error-prone than the bolt-on after-thoughts they largely are now (C# has done a better job). Or you could understand and utilise them from first principles now. Even if you don’t actually program in such languages on a day-to-day basis as part of your accountant-like job (although we believe the change is inevitable), you’ll at least approach the same problems with fresh insight while using your more pervasive language.
As those that speak Greek might say: Τι περιμένεις (What are you waiting for?)





As I messed up my WP-Gatekeeper config (it seems to struggle with its autoconfigure promise), comments weren’t working properly for a while. Sorry.
Here’s some valuable Haskell insights from Rebecca Parsons, my CTO…
Thanks Rebecca!
Here’s a brief intro to Haskell’s call-by-need delayed evaluation http://www.cs.arizona.edu/~collberg/Teaching/372/2005/Html/Html-14/index.html
Comment by Josh — August 24, 2007 @ 10:41 am
Why Ruby for interacting with Excel and Access? Ruby actually has pretty poor support for stuff like that, and that’s one of my main problems with Ruby - a major lack of libraries. Python on the other hand is a very similar language but is much more mature on the library front.
Comment by AF — September 21, 2007 @ 5:07 pm
AF - no, not for interacting with them, for replacing them!
Many spreadsheets and Access databases started out as a small but pleasing efficiency boost for the information worker. Perhaps a few others in the team were able to use it too. Soon enough, though, they become vital. So many enterprises have important or near-critical business processes hinging on these things. Usually they’re just sitting on one person’s PC (or on a shared drive if you’re lucky). The dude or dudette goes on holiday or leaves the company and no-one knows how the thing really works. Business value has eroded and been replaced with business risk.
The point of my comment is that Ruby gives us something that can provide a low barrier to entry (super-efficient software delivery and a powerfuly simple web/persistence framework like Rails), can be hosted on enterprise infrastructure, and tended by high-performance software delivery teams. At the same time we can still provide the “glue” between the big systems and have lots of little efficiency boosters for those working through the business processes on a day-to-day basis.
Comment by Josh — September 22, 2007 @ 9:36 am