In particular, it seems that I often want a program to do 6 different things, and the best way to do 1 and 2 seems to be Lisp, 3 and 4 is in C, 5 is in Prolog, and 6 seems to be assembly language. I've given up on the QuestForThePerfect Language [1]—why can't I just PickTheRightToolFor TheJob [2] for each part, then glom together all the pieces?
—DavidCary [3]
“Rewrite Code From Scratch [4]”
I touched briefly on this topic [5] a few months ago but went off into a different direction. It wasn't until a few days ago when reading The New UCI Lisp Manual [6] (I enjoy reading old software manuals) which had a section on calling PDP-10 (Programmable Data Processor) [7] assembly langauge from Lisp (and vice-versa) that I recalled the above snippet and found myself once again with the thought of Where did we go wrong? Why can't we do this?
As I wrote then:
The module header contains a value specifying the language type, with values defined for data only, 6809 machine code, BASIC09-I-code, Pascal I- code and COBOL I-code. In theory then, you can construct, say, a pay roll system using a Fortran compiler to generate the math routines into 6809 code, COBOL to generate the business rules, and allow extentions to be written in BASIC. The language type is probably there for two reasons; 1) to know how to run the module, and 2) to figure out what parameter passing conventions to use (if there are any differences between the languages).
“An even longer entry to scare away the new readers [8]”
It really just comes down to calling conventions and making small enough pieces to link together.
Okay, so maybe it's not that simple. I'm having a hard time seeing how one would mix, say, Perl (with wealth of modules), Ruby (for easy integration with the World Wide Web [9]) and Lisp (hey, if it's good enough for Yahoo Stores [10], then why not—it certainly beats using COBOL for business logic) into a single coherent program.
But even just thinking about that I can see why it might not be such a good idea after all [11]—the three languages I mentioned are interpreted (even if it's “compiled” into an internal representation, it's just “compiled” into a form that's easier to interpret) with their own internal structure, and each are garbage collected (which means, memory is reclaimed automatically) but it's a safe bet that memory allocated by a Ruby routine can't be freed by a Perl routine (or Bad Things™ may happen [12]), which is why it's not that simple.
[1] http://c2.com/cgi/wiki?QuestForThePerfectLanguage
[2] http://c2.com/cgi/wiki?PickTheRightToolForTheJob
[3] http://c2.com/cgi/wiki?DavidCary
[4] http://c2.com/cgi/wiki?RewriteCodeFromScratch
[6] http://www.amazon.com/exec/obidos/ASIN/0898590124/conmanlaborat-20
[7] http://en.wikipedia.org/wiki/PDP-10
[9] http://www.rubyonrails.org/
[10] http://www.paulgraham.com/avg.html
[11] http://c2.com/cgi/wiki?BigBallOfMud
[12] http://forums.worsethanfailure.com/forums/thread/119538.aspx