* * * * *
                                        
                                    Polyglut
                                        
> 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
[5] gopher://gopher.conman.org/0Phlog:2007/01/23.1
[6] http://www.amazon.com/exec/obidos/ASIN/0898590124/conmanlaborat-20
[7] http://en.wikipedia.org/wiki/PDP-10
[8] gopher://gopher.conman.org/0Phlog:2007/01/23.1
[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

Email Sean Conner at sean@conman.org

.