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.
Is it just me, or does the thought of debugging an app controlled with C code the executes code in PERL, shell, java, and whatever else sound really, really horrible?
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 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".
Actually, I can agree with the "right tool for the right job" which is what you are saying however, I can see points for the other side of the coin (especially in a large corporate environment).
- Standardisation upon one language and/or platform drops training costs for the org (and keeping people up to speed to maintain parts of the system).
- This allows one guy on one project to be shifted to another with minimal re-training (just some familiarisation time).
I will make the point though, that as developers we should be able to language-hop easily as we know the concepts common to all languages.
However, from a business point of veiw - it does make sense to put all the eggs in the one basket (though at times you feel like all your problems look like nails because you've been given a 'hammer' to work with).
-- Dan =)
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 think your approach (and ones similar to it) make the most sense.
Programming languages are like sets of tools; the challenge is picking the right set for the job(s) at hand. I'm sure that given enough resolve, one could code a 3-D FPS game in perl (knowing our community, this has probably already been done). You can also get away with using a butter knife instead of a powerdrill in some instances. It doesn't mean it's the best use of tools or technology.
I've always been puzzled by people who are fanatic about a single language (or any single technology for that matter). You'd never hear a carpenter say, "I always use a chisel and hammer, no matter what the task."
Well performance might not be so much a problem as scaling. Spawning threads and processes has some amount of overhead, and in some OS'es can lead to stability problems. If you were to take this proposal too far you could write applications that essentially became fork bombs, or processor pigs.
I do think it is a good idea to give up the quest for teh single best programming language, currently there are just too many tradeoffs that programming languages and applications need to make for a single programming language to be sufficient, on the other hand I would suggest picking a single programming technique and applying that to your entire application at least. For example, you might use only imperative languages that support real objects, or you might use strictly procedural techniques. But with good enough reason you could vary from that (of course the maintenance costs might skyrocket in that case -- but a prolog based rules system could be cool in a Java business app -- and incredibly slow).
Offtopic: regexp and regcmp are very good parsing utils for C. In general I don't have any problems with Perl, but I am of the opinion that some of its touted advantages don't exist for good C programmers -- of course that is a skillset many do not wish to attain, and I can hardly blame them
"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-
I'm confused about what you're saying. Are you saying you break your problem into small chunks, solve those chunks in the language most suitable, and put them together? If so, how do you call the other chunks? Using exec() or other synonymous calls or using CORBA or SOAP? That's the main problem I have with this.
If I'm solving a large problem, your solution makes sense. I can use CORBA or SOAP to do the parameter passing and the solution will be elegant. The only problem will be the learning curve. I'd have to learn the protocol used. However, it'll pay off in the long run because each is solving the problem the most elegantly. You'd save performance and maintence costs. (Provided you're actually know the multiple languages well and even then, in a large team it'll be iffy.) In a large program, using exec() is probably not acceptable. (Unless, you really know what you're doing.)
But what if I'm solving a small problem that nonetheless can be broken down into smaller chunks that can be best solved using different languages. Would I? Probably not, because the solution you're proposing would complicate the entire development cycle. I'd have to build the small chunks and then try and assimilate them together some how. The problems that I can encounter are a lot and it's not worthit. Also, the increase in performance will be negligible because it is a small problem.
Having said that, for fun, I'm thinking of doing what you're proposing. I know it'll be complicated and I'll have headaches, but it's fun programming something like that.
Me
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.
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.
I see your point, but if all teams used this reasoning, how would better languages (technologies) ever get developed? How does a system evolve when it has reached the limits of its underlying language/technologies?
There is always a learning curve when learning a new language/technology, but the more experienced (or talented) you are, the less steep this curve is, and the less a cause of concern it becomes when considering future maintenance requirements.
I don't think I'm alone when I say I actually look forward to working with a new language/technology, because it increases my skill set. At this point in my career I've worked with enough tools/technologies that I don't balk when a new one falls into my hands because I know it will probably work pretty similarly to others with which I'm already familiar: very few (good) technologies these days are so revolutionary as to confound even veterans.
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
However, the cost of context switch, though very high for an OS, is not high for some installations. Depends on application. Your disks might as well be the bottlenecks. Profiling is necessary in any case.
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.
Tisk tisk... if it's changing so often why it is integrated right into the logic of the code? Simple, it shouldn't be. Find a way of breaking the presentation layer out of the actual code; and write a config file for other options, one that's expandable. Don't suffer from C programmer's diesease thinking that changing #define statements and recompile is a "user friendly" way of doing things.
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 can't really think of any basis for this to tell you the truth. Well designed c/c++ projects shouldn't be any harder to modify than any other language. If they are then the initial design is too inflexible which usually means the original coder didn't know the language at hand well enough to properly put together a project.
I'm not saying that you've picked the wrong languages for whatever you're working on... just disagreeing with the overall "blanket" type nature of the post.
Use whichever language you feel comfortable with.
There's been a lot of comments in this thread suggesting you should use x for y job. Whilst this is true to an extent, if you can get something that works using C++, or spend an extra few hours (days?) doing the same thing in {other language}, use C++. It may be less elegant, but most PHBs don't give a crap about that.
Whether you use multiple languages or not, modular programming is essential if your project isn't a single one-off deal.
Incidentally, even if it is a one-off deal, it's often handy to modularise programs, as there's always the time someone from sales will wander in and say 'can I get a report kinda like that one I had yesterday, but in [blue|mauve|cyan]?',
Often, in scientific research computing (my field is chemical engineering, but I am sure physics, chemistry, geography et. al. use similar techniques) we use multiple languages.
For example, you may have a simulation that requires several hours of CPU time to run. We will write the math end of the code in Fortran. (If you really require high speed execution, you will write the most frequently run code in assembler.) We then write the GUI or the interface or file handling parts in C, C++ or Java, depending on what you want.
-----
The significant problems we face cannot be solved by the same level of thinking that created them. -Einstein
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
People always seem to say that. Sorry I don't want to stay in the same job for the rest of my life. And I'd rather not have people curse my name after I leave.
Of course if you if you leave a complicated, but otherwise well functioning system perhaps they'll say "wow, that guy was really sharp, too bad we didn't realize what we had, now we are going to have to hire 4 people to replace him." That is how I'd like to be thought of.
Oh well...
Your arguement goes both ways
let's suppose for a second, that you're a programmer, working on you own class. Now you know it inside and out, unlike anyone else. You need to add a function to it, you know how to do it so that everything works correctly. And then you're hit by the bus.
Sure other people will have the skills to read what you've done, but understanding why you did things will escape them; unless, you document your code. Which leads to the solution to this.
Good documentation is key; make sure to include your consulting fee for fixing the program or script and your email.
=================
Unix is very user friendly, it's just picky about who its friends are.
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.
We used to have our application written this same way. VB GUI front end, C++ business logic back end. The problem we had was that some people on the team were stronger in VB than in C++, and we ended up with business logic creeping into the VB. A few years ago, we decided we had to walk away from that app for future development, and here we are reinventing the wheel today. After five years, we had ended up with more business logic in the VB than in the C++. It's an awful mix. It's tough to maintain, and tough to debug.
On the other hand, I don't think it was necessarily the language that caused the problem. What we had was people developing without understanding the underlying architecture of the application. The VB portion was originally created by a vendor in 1995, and she walked away from it as soon as it compiled. It was thrown over the fence to other coders at that vendor's site, as well as us at that time. Those of us who got in on her initial training were able to carry the design forward, but almost immediately the new hires (and the vendor developers who were not under our direct supervision) started "blending" business logic into the VB.
I think we were doomed to this fate from the get-go because we didn't have strong project control. Any ongoing programming task is going to have issues like this creep in eventually. Multiple languages aren't necessarily the problem, and in some cases can help, but discipline is required to pull it off successfully over the long run.
John
John