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?"
This sounds like a nightmare for PHBs. What if you were to shuffle off this mortal coil, it would be difficult for them to find someone with a similar skillset to maintain those applications, would it not? On the other hand, from a technical POV, this seems eminently reasonable.
I can see some merit in that, but if you pass on maintenance to someone else, you could have just increased the number of people required to support the project, or require the new developers to learn more new languages before they can be useful. It's easier to find someone skilled in foo than to find someone that knows foo, bar, baz, etc.
...just the cost of the context switch can be enought to deter one from this.
Cross platform development just got that much more complex.
Add in the cost (not always $) of additional development tools, maintaining such a beast, and obtaining the required knowledge/skills can make your approach daunting - esp on large scale multideveloper projects.
I am very small, utmostly microscopic.
When you start using several different languages, you now need a person with several skills to maintain it. Trying to find a mid-level programmer who is strong in 5 unrelated languages is much more expensive than a mid-level programmer with 2 primary languages in his toolbox.
Personally, I write something end-to-end with one language because its nice to be consistent.
- A
I'd go insane if I tried to use a compiled language for frequently-changing applications (eg. web interfaces to purchasing systems, database large object manipulation & indexing, etc.) but likewise I'd grow old waiting for things to happen if the cores weren't in C.
Personally I dislike C++ because I find it harder to port than ANSI C. But I wrote plenty of it when I was learning how to program (before I learned Scheme and Perl and Java and got some latitude in my paradigms). Either C or C++ is great for speed and hooking into the OS or an Apache module or whatever. It's also less tempting for admins or rookies to mess with C code because bad code may not compile.
On the other hand, object-oriented (or at least modular) PHP and Perl code, and decently-written Java code, is much easier to adapt to changing demands. I stick with PHP and Perl, myself, and I use Perl as kind of a glue-core layer between C applications and PHP interfaces. If I had more time I'd probably write the hooks as PHP extensions, but Perl is just so damn powerful when you use it right.
I'm not sure what people are thinking when they specify that everything on a project "needs" to be done in Java or whatever. It's not particularly hard to use my code, since it's all just calls to libraries that automagically do the hard stuff. More importantly, I tend to use POD or Javadoc-style comments in everything, and don't put it anywhere else. That way I am forced to keep it all up to date, because that's where *I* remind myself what arguments to feed what methods!
Remember that what's inside of you doesn't matter because nobody can see it.
I will do this sometimes for code that is intended for short-term, internal-only use, as I can often save quite a bit of valuable time.
If the code has to be maintained, forget it; what if I leave the company? Not only does my employer need to find someone who can code in C, C++, Java, Perl, Python, shell script, and assembler, but they have to find someone who knows how all the languages work together. Debugging is also a bit more difficult, as you have to jump between languages, and it can nastily confusing.
For code which is supposed to be release-quality, this is out of the question; you can't expect all of your clients to install Python because GUIs in Java are grotty, or install Perl because you don't want to screw with hashes and regexps in C. Release code also needs to be maintained, and there is going to be some developer turnover; it'll be easier to replace coders who leave when you don't need to list five languages as "required" on the employment-availablity posting.
--
I Hit the Karma Cap, and All I Got Was This Lousy
I think that by designing one larger program, you leave the maintainer (even if it is yourself) with an easier job. It is much much less painful to use one compiler to change one set of source files, in one language. Maybe it's just me, but I always seem to have problems shifting gears between more than two languages at once. And C compilers don't like perl a whole lot.....
This goes double if your code is open source. There is enough hard to read, poorly organized code out there that anything that is unified (in style, language, etc.) is helpful. Call me old fasioned, but simpler is usually better.
Mixing multiple languages creates huge maintainence issues - will the API for integrating the languages give you enough breathing room in the future?
How about performance? Integrating multiple languages means invoking multiple runtimes and address spaces.
What about debugging? The small amount of experience I have had integrating Perl and C clearly indicates that debugging large apps written in multiple languges is extremely difficult - forget about your IDE or traditional single debugger.
Use a screwdriver to drive in screws. Use a hammer to drive in a nail. And sometimes, if I need something really quick and dirty, you can just staple it in.
Having language religion is bad!!!!
Also, there's much to be said about the life of applications. Save for COBOL, how many old-style two-tier client-server apps are still around with no plans of being retired.
Also, I second the motion that using scripting languages is not a bad idea. For those parts of a system that get executed repeatedly, it makes sense to go with a compiled language.
For those program paths that are called occasionally, its not a bad idea to use "glue code".
There are a lot of factors you haven't mentioned: will you need to reimplement the same features in multiple languages? Will you have messaging between programs that don't support identical datatypes and structures? Will you have unicode support in all the languages when you need it? How about futureproofing? Will all those languages continute to have the necessary degree of orthogonality two years from now when you need o overhaul the system to meet some new requirement or paradigm?
These are all risks that you take, and this is just off the top of my head.
I mix languages on occasion, mainly for client-server apps where I need the server to be fully optimized and not necessarily portable, but the client must be portable and can stand to be less optimized. But you introduce a lot of risk and redundancy if you don't have very good reasons for doing everything you're doing.
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 think you could argue that it would make debugging easier. The program is proken down into parts, each doing a certain task. If one part has a bug, you only need to debug that specific part, rather than wading through masses of code that aren't related.
"But really, I think life is just a game of Mao Nomic." -Purplebob
"Do you guys use this kind of method, or do you try to do everything in one program?"
.Net CRL that they touted was that each developer could write in whatever language they were comfortable with. mkay, that's nice. The problem is when A) programmer quits B) programmer goes on vacation C) programmers is assigned elsewhere. Just my opinion, but in a workplace environment, a standard language should be adopted. Otherwise you have another programmer who doesn't know Cobol trying to debug the app.
Depends on the situation. In a workplace environment, which is where I do most of my coding, we code in the same language. I just attended DevDays from MS. One of the strengths of the
What you do on your own time, that's a different story. Whatever suits your fancy.
-Frijoles-
Looks like you have it backwards. If you're going to mix languages, why not do your control code in some high level language and then call your c++ or c from that? I guess it really depends on what you're doing, though.
Lately I've been using python a good deal. I write the major features in python because it's wicked fast and yet scales well. Once you have a program written in python it's pretty damn easy to convert modules to C or C++ (especially with SWIG) for optimization.
My reasoning is simple. Hack out the major features quickly, look at where your bottlenecks are, then optimize those 1) in python if possible (maybe just a bad algorithm)...otherwise 2)in c/c++. It just seems counter productive to me to have some c/c++ code calling modules written in some higher level language. The glue languages of choice are perl, python, and shell.
Then again, if what you're doing works well for you, by all means use it.
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."
this is computer programing. I know people who tought themselves Basic in a morning. I belive that I can learn any computer language you wish me to program in, in under a week. I can read well written programs in most lanuages without any learning time. I'm not special, any compitent programer can do it.
However after attempting to teach myself Spanish for 6 months I still couldn't hold even a basic conversation (and I had a year of spanish a few years back). Once I learn spanish I won't have much a head start should I need to learn Russian or Chinese. Learning those two wouldn't give me much advantage if I need Hebrew.
People think of programing languages as if it is something special to know a lot. Really you know zero (most people), one (a lot of people, normally basic), or all of them, including ones that have not been invented yet, though you will need a refresher before you would use one.
Mastering a programing language takes expirence, and that only comes with time, but a good programer in his first week with a new language can already prove that good programers are 10 times as productive as bad programers, even if the bad programer has been using that language for 10 years.
I know people who know 20 programing languages, I'm not impressed. I know people who are fluent in 17 human languages, and I'm impressed. In school I was once given the task of learning 12 languages in 10 weeks, and I had 2 other classes besides. It was no big deal, in fact learning 3 languages was trivial compared to using one language (C) to write a program in anouther class, even though I knew that language very well.
Use the language that is right for the job. TCL is designed to make your programs scriptable. Perl is great for string manipulation. There is no reason you can't combine both, someone who needs to maintain you code will not find it difficult to learn the ones needed.
PLEASE PLEASE PLEASE make sure that you write nice, well commented code. As an example of the above, monday I was digging into someone else's C++ code. Even though I haven't done C++ is years, it was no problem reading C++. However the lack of comments was a problem. I can make changes, but I can't be sure I make the right ones without knowing what the programer was thinking. this is far more important than what language it is written in.
Unless you tend to make the mistakes in the calling code.
I did, and spent a couple of hours trying to find out what is wrong, because I knew what I *meant* to put in the calling code, and never tried to look up what I actually wrote.
--
Two witches watched two watches.
Which witch watched which watch?
Common understanding by Developers- while I know a variety of languages, the next person probably does not. Nor can I expect to know all those that someone else might. Limiting choices provides a means to decide if an individual has the skills necessary to participate and to introduce training.
Resource Consumption- Each transition of languages, one to the next and back is resource consumptive. This tends to make applications with multiple languages more expensive (CPU, Memory, and response time) over single languages.
Developer Time- Very similar to machine resource, multiple languages tend to be more difficult to debug and more difficult to maintain. As developers now tend to be the most expensive part of a project, this can have a real impact on the budget
All that being said, there can be very good reasons to use multiple languages. Some languages have inherited limitations that would make a secondary option worthwhile. However, that needs to be weighed against the prior notes to ensure we are getting something for the extra effort.
Finally, all language transitions should be completely encapsulated. While a good idea regardless, try to make it as easy as possible replace a unit and especially to replace it without requiring changes to everyone calling it.
This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:
In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.
Lately I've found that using SWIG makes this pattern very easy to apply in real life.
--
CPAN rules. - Guido van Rossum
Building software is a function of economics. If you've dumped considerable resources into training, code licenses, an existing software base, or other real-world issues, you will be very inclined to insist that your "chosen" language be used in future projects unless there is an overwhelming issue that prohibits it.
lest you facilitate a dialogue with my supervisor.
my sourcebook for business-speak -- Action Item Man comics
yeah, you got me... I'll go back to my TPS reports now.
Remember that what's inside of you doesn't matter because nobody can see it.
I tend to use C++ as my controlling program, and then execute Perl, PHP, or Java ...
... unusual. You're using C++ as your "glue" language, and a higher level language for the code where your inner loop resides?
That's very
Stupid job ads, weird spam, occasional insight at
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
There are definite advantages to this design; PHP is probably the easiest language in which to write a web GUI, and Perl greatly simplified the process of building the incredibly complex parser.
The disadvantages: eGrail has (or at least had) a ridiculously long list of dependencies; one needed both a working web server with PHP4 and many extensions, not to mention Perl 5 with a host of 3rd party modules. TWO seperate database interface libraries are required.
I think it was a good thing for eGrail, but it's a carefully balanced tradeoff.
Justin
"Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
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.
I consider myself a good programmer. It's been my experience that depending on the complexity of the language, it takes between six months to a year of experience in a language before you are fluent. Fluency is not mastery, it's the point at which you can sit in front of the code and write in such a way that you are using the language, not wrestling with it. And you can't write good code when you're fighting the language.
As for reading a language. Sure, you can read any program immediately, provided the syntax is familiar, and the code is well named and well commented. On the other hand, there are always unfamiliar syntaxes - take someone who's only coded in C and Perl, and put them in front of Lisp or Smalltalk, and they'll need a couple of days work just to be able to parse it.
You can learn enough to slap a program together in a week, provided the syntax of the language isn't particularly alien, but it's not going to be one you're proud of the week after, when you've learned a little bit more. You'll know the syntax and control structures. You'll have some idea of the shape of the main libraries, and you'll know where in the documentation to look if you need to know more.
I've done this before - I remember having three days to learn enough of a particular language to fool a customer into thinking I knew what I was doing. And I did, we got the tender, I continued to learn more over the ensuing weeks, and the customer was happy with me. Looking back, my total unfamiliarity with the language probably cost this customer many thousands of dollars in lost productivity, for all the time I took looking up library functions in the language documentation, and all the time I spent inefficiently re-implementing functions that were already available, but that I wasn't aware of enough to know to look for them.
A week of study will qualify you to painstakingly inch through other peoples code with piles of documentation at hand, and get a pretty good gist of what the code is doing. It'll qualify you to write something artificial for your CS class. It'll qualify you to make simple logical changes real code. It will NOT qualify you to write, or make significant changes real code.
The syntax of a language is only the smallest, and easiest part of it to learn. The libraries, the idioms are far more important. Knowing all the weird letters you can stick at the end of a regexp in Perl. Knowing that double-checked locking in Java doesn't work. Knowing which collection in the STL is most suited to the data you're storing. Would you trust the maintenance programmer you've just hired and taught C in a week not to introduce an exploitable buffer overflow?
Charles Miller
The more I learn about the Internet, the more amazed I am that it works at all.
This method has a loss of productivity from the added complexity of the task, but this can easily be made up for in increased productivity at the meta-level. I.e. if your application has many buttons with only slightly different functionality, a single Lisp function call creates each button. Changing behaviors and adding or deleting parts of the program becomes simple. Best of all, the end result is a valid Java program that anyone who knows Java can understand. If the person who comes after you does not understand Lisp or the idea of program generation, it doesn't matter. They have a Java program to hack on. If they do happen to understand Lisp, even better, they can pick up where you left off with a big productivity gain. Lisp is particularly suited to this type of thing, but any good high-level language would work.