Visual Basic —

Typical MLP Scenarios

The following scenarios in which MLP can be advantageous might help kindle your imagination and help whet your appetite for using it.

  1. You might be required to write a fast user interface in Visual Basic and then call into a remote, platform-independent, ActiveX server that was written in Visual J++. In turn, that server might want to connect to a couple of DLLs (via COM), one containing collection-oriented Standard Template Library (STL) code written in Visual C++ and the other containing code, written in assembly language, for accessing a device such as a hard disk controller. This particular situation is one that every MLP developer dreams about.
    NOTE
    How portable is Java code really? While I think it's pretty cool in theory, I find that I must agree with Bill Dunlap, Microsoft's Visual J++ Technical Product Manager, when he says that (I'm paraphrasing here) due to the sensitivity of the Java run time to differences in underlying hardware architectures, operating systems, and the virtual machines themselves, the "write once, run anywhere" mantra has all too often been found to translate directly to "write once, debug everywhere."
  2. You have the vision to imagine a world in which your mainframe-hosted COBOL code wasn't pejoratively and routinely labeled "legacy code" (for "legacy code" reads "doomed to expire on the mainframe" or perhaps can be relabeled as "heritage code"<g>). The good news is that with MLP, this tried and tested, smoothly-running, expensive, mission critical business logic doesn't need to be ported to be fully exploited by "modern" languages.
  3. You have a need to do something that is, by definition, more suited to one language than to another. Name your poison-that's what MLP is all about.
  4. For raw speed or flexibility, you've determined that you have only to write a routine or two in Assembler and then link to these routines by calling into a DLL. Easy MLP!
  5. You might need pointers in a program you're creating in, say, Visual Basic. Another language might be considered more useful simply because that language handles pointers (in the C/C++ sense). We all know that the best programs implement, at each turn, the correct algorithm (putting these before data structures) in the most efficient way possible. More often than not a good algorithm implies some sort of underlying, possibly complex, data structure. Such complex data structures frequently dictate that some pointer manipulation will be required. Ergo, pointers are good for implementing this type of algorithm. An appropriate language for this implementation might be Visual C++ or an assembly language (using the _asm capabilities in Visual C++ or perhaps using Microsoft Macro Assembler [MASM]). Because they don't support pointers, we probably wouldn't choose either Visual J++ or Visual Basic. No problem-MLP lets us mix 'n match as we please, more or less.
    NOTE
    Visual Basic cannot (yet) directly use pointers to data or pointers to what's commonly called a "function" (meaning any routine in this context). In this case, the choice between C++, C, or Assembler would most likely come down to some requirement in terms of a clock-cycle count (raw speed) and, perhaps, developer resource.
  6. You need to do something that is most suited to a language other than Visual Basic, but the problem doesn't naturally fit into any known language. Normally in such cases you'd resolve this problem by writing your solution in, say, C. (You can pretty much do anything in C correctly!) Alternatively, the proper solution might be to design and write your own language to build certain DLLs. Sound difficult? Don't you believe it-see the section on creating your own "little language," later in this chapter.