Slashdot Mirror
The Power of Multi-Language Applications
wbav queries: "I've been programming for a number of years, and someone always asks, 'What language do you use, Java or C++?'. Now personally, I find that question a little biased, mainly because, of how I program. Rather than making one massive program, adding in all the support I need to make up for weaknesses in languages, I prefer to make several different apps that call each other, each using the strengths of that particular language. I tend to use C++ as my controlling program, and then execute Perl, PHP, or Java depending on what will give me the best performance for and cause me the least amount of pain to accomplish the task at hand. Do you guys use this kind of method, or do you try to do everything in one program? What advantages or disadvantages do you see in creating one program compared to many programs?"
When I develop web applications, I tend to mix languages. That's really the only time, though.
I spent some time dorking with tcl a ways back and it's always been touted as a "glue" language for bringing lots of pieces together.
./foo.sh than it is to dork with the up arrow.
Ultimately I decided I didn't like it because unerringly, at some point, you'll want your "pieces" to talk to each other more intimatley than your "glue" will provide (without substantial effort anyways). Keeping my pieces to modules or at the very least individual C libraries means I can have my stuff talk amongst itself in whatever form the language provides.
My suspicion is that having lots of executables laying around increases run time / memory usage as well because the system has to deal with that many more processes getting created.
And that's not even getting into the readability issues of having a piece of software use a random number of different languages..
The only "language" I've ever found the glue idea even remotely useful was in shell scripting, because the massive bulk of my scripts are just done to automate repetitive shell commands and it's a lot easier to type
Actually, I've been working on a pretty large programming project recently, and I find that breaking up the task into several different small programs, written in different languages for convenience, actually makes debugging easier. This allows me to test each program chunk individually under controlled conditions. Compare this to a single monolithic executable, and seeding loops with printf commands to figure out just where it segfaults. This also enables me to identify problem code much earlier in the development process.
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."
Depends on your interfaces, of course. If you want to bind the modules together by having them freely call each others functions, this can and probably will become a debugging nightmare.
However, for those cases where you'd already go for a multiprocess design, using a clean protocol that's spoken between the modules, it can be quite a good idea to exploit the simple fact that some languages are better at some things than others.
Eg. my current project, OpenRADIUS has a C core that does low level packet handling, job scheduling, etc., and a module that happens to be written in Perl to easily deal with simple and more complex formatted ASCII tables.
If I would have had to write that module in C as well, it would *definitely* have taken me a lot more time.
All generalizations are false, including this one. (Mark Twain)
And because SlashDot.Sucks.The.Big.One won't let me post just that, here's an explanation:
Writing a program in ALL C++ or ALL Java reduces the dependencies you need to write that program. Nothing is worse than finding a peice of software you would LOVE to use and discovering it required 60 different libraries, all of which are out of date on your system. With RPM distributions this quickly becomes a nightmare, and is currently the primary reason why I have never used Galeon, for example.
> ...just the cost of the context switch can be
> enought to deter one from this.
not really - breaking up your app by process adds a few efficiencies with a nice, simple, easy to understand model.
1. multi-processor scaling, generally a no brainer with seperate processes, if they are broken up intelligently
2. reduced memory foot print - well broken up processes mean you don't have to worry about loading up a ton of libraries all at once, you can let the os deal with memory as processes are kicked off and finished
3. security - different processes can be run as untrusting groups, a great boon especially if one processes needs to run as root!
a great example of this is qmail, the original mta that took a monolithic app like sendmail and used the unix process model to break it apart into well defined pieces. the result is a faster, more secure, easier to understand and generally much simpler application.
h
Being a Visual Basic developer, I feel who better to know its short comings as a language. For the last few months, I've been doing cross language applications for windows.
;-)
Basically, I develop the Application Interface and Simple Functions using Visual Basic Modles and ActiveX Classes.
-but- For Intense Number Crunching, I weave Visual C++ DLL's that have all the function calls that would normally chew and grind Visual Basic to a halt (Floating Point Number Calculations, Loops on Data, and Byte Cyphers).
There's a wonderful book on the topic by A! Press (I know.. I'm a Wrox man myself) called "C++ for VB Programmers" (Link) which explains the process of using Win32 DLL's and ATL COM DLL's in your VB Application.
This process leaves VB doing what it does best, looking pretty. It also lets C++ do what it does best..... all the work
I'm willing to bet that most of the posters on here saying that using more than one language isn't a good idea (for whatever reason) haven't done much web programming. For a fairly normal browser plugin project that I worked on, we used the following:
1) C++ for the actual plugin.
2) JavaScript for webpages embedding the plugin.
3) Perl for CGI backends.
4) SQL (duh).
5) Wise Installer script for the installer
6) Delphi (Pascal) for a game builder app that made games to be played in the plugin. This app loaded the plugin as a normal dll.
If you're doing integration between technologies, you'll almost invariably wind up using different languages. Often times, you have no choice. Also, this isn't meant to be offensive, but people that think C/C++ is one language are naive. Generally, you have to ship clients executables, so you're limited to languages that compile natively (with the possible exception of Java). You generally can run whatever you want on your own servers. Then you have web browsers that are their own funky platform. If you can get away with using only one language, congratulations!, but don't expect that all the time.