Chapter 2. The problem and the solution

It's obvious, then, that these four types of languages and their four contenders in this study (C, Python, Eiffel, and Haskell) have different strengths and weaknesses; C can handle systems effort and is the "lowest common denominator" for function calling. Python has an enormous standard library and a flexible, mutable execution; Eiffel has strong typing, design by contract, and a "large-scale construction" feel; Haskell is powerful and easy to reason about in a narrow domain.

If only they talked to each other...

Component programming offers one possible solution. If each of the previous languages could communicate via defined components and interfaces (such as CORBA or COM), the problem could be soluble that way. But while this is an outstanding solution in many ways (and certainly leaves the door open for other languages) there may be situations in which a request broker or other middleware is undesirable; it may be a better tradeoff to call each language directly.

The solution I'll pursue here, while a bit clumsy, addresses the problem in a different way. Because C is the most widely-used systems programming language, the other three all have some sort of C interface. By using C as the glue between the three, we should be able to create a set of libraries and tools to automate and simplify the process of using the four together: structure a large application in Eiffel, script it and extend it at run-time using Python, refer to Haskell for thorny numerical sections, and drop down to C for any system-specific bit-twiddling stuff.