My first professional work as a software developer was writing Clipper code. Clipper was a compiler for dBASE code with object-oriented extensions. This was in the days of DOS, and the entire application was written in a single language. We didn’t even use SQL. Instead, the data storage was shared DBF files on a new concept, the LAN (I remember reading a PC-Magazine of that era declaring that the current year was the “Year of the LAN”).
So why bother? Why not use a language that handles multiple threads more gracefully? Like a functional language? Functional languages eliminate side effects on variables, making it easier to write thread-safe code. Haskell is such a language, and implementations exist for both Java (Jaskell) and .NET (Haskell.net). Need a nice web-based user interface? Why not use Ruby on Rails via JRuby (which now support RoR). Applications of the future will take advantage of the polyglot nature of the language world. We have 2 primary platforms for “enterprise” development: .NET and Java. There are now lots of languages that target those platforms. We should embrace this idea.
While polyglot programming will make some chores more difficult (like debugging), it makes others lot easier. It’s all about choosing the right tool for the job and leveraging it correctly. Pervasive testing helps the debugging problem (adamant test-driven development folks spend much less time in the debugger). SQL, Ajax, and XML are just the beginning. Increasingly, as I’ve written before, we’re going to start adding domain specific languages. The times of writing an application in a single general purpose language is over. Polyglot programming is a subject I’m going to speak about a lot next year. Stay tuned