Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming IT Technology

The Power of Multi-Language Applications 413

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 discussion has been archived. No new comments can be posted.

The Power of Multi-Language Applications

Comments Filter:
  • by easter1916 ( 452058 ) on Tuesday November 20, 2001 @05:03PM (#2592516) Homepage
    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.

    • Actually, being the only one locally with even simple linux skills, that's the exact same fear I have promoting samba over win2k fileservers.


      Just an interesting viewpoint.

    • hm, so you guyz are saying that most developers only know 1 language? Now I'm really scared...
      Basically most languages have at least 1 thing they are good at fe: Java has good networking, and PROLOG is great for AI but please don't open a socket with it..Using languages where they excell is key for rapid prototyping. Personally, I think you shoud really be afraid of the '<language XYZ > isn't performant, I'll code it in C' excuse that some hackers have for there ignorance. development cost comes first and since maintenance is a function of KLOC, you should prefer compact solutions (even if that means gluing code written in several languages together).

      have fun.
    • 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.
    • Not to sound insensitive towards my employer's position, but if I got hit by a bus, my company is the last thing on my mind.

      --Dan
    • This is why it is so hard to find a decent cool job. The PHBs are always looking for the lowest common denominator. And this is despite the fact that there are plenty of good people around to be had. The key to this is their inability to find. Why would a decent programmer or a decent system administrator come to work for a PHB who is so concerned with being able to replace them with any jerk scrounged up off the street in a moment's notice?

  • You scare me. (Score:2, Insightful)

    by supabeast! ( 84658 )
    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?
    • Re:You scare me. (Score:3, Interesting)

      by MWright ( 88261 )
      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.
      • 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.
    • Quite the Contrary (Score:3, Informative)

      by spoonboy42 ( 146048 )
      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.
      • by plover ( 150551 ) on Tuesday November 20, 2001 @05:21PM (#2592676) Homepage Journal
        I, too, am working on a large programming project. It's primarily written in C++, but I use other languages to write quick-n-dirty tests for the objects.

        A curious side benefit I've found is that when I cross language boundaries, I tend to expose more flaws than if I just had a small main() testing the objects. Crossing language boundaries forces me to code the interface to each object very properly and distinctly.

        John

      • I think that if you need to use different language to break the task to small parts, then you might want to review your design methods.
        You are supposed to do it anyway, after all.
      • The process you described is irrelevant of differences in languages. It's always better to break down your code into components and debug the components as much as possible seperately. Coding those chunks in different languages is just adding possibly unnecessary complexity in doing integration testing between the components.

        From personal experience using JNI, I found it to be a giant pain to try to debug the code. Sure you can test the underlying C++ code on it's own and test the Java on it's own, but when you glue them together you get new bugs and debuggind between the two layers is much more difficult than if it was all Java in the first place. In that case we had no choice but to use two languages so we put up with it.

        As for using printf's, what does that have to do with how you wrote the code? If you choose to debug using printf's that has nothing to do with if you have one big mound of spaghetti code or a well designed modular architecture.
  • well (Score:5, Interesting)

    by djweis ( 4792 ) on Tuesday November 20, 2001 @05:03PM (#2592519) Homepage
    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.
    • Re:well (Score:2, Insightful)

      by ez76 ( 322080 )

      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.

      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.
    • Re:well (Score:5, Funny)

      by dhamsaic ( 410174 ) on Tuesday November 20, 2001 @05:27PM (#2592727)
      And that, my friend, is called job security. :)
      • Re:well (Score:2, Insightful)

        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...
    • Re:well (Score:2, Troll)

      by jabbo ( 860 )
      Dude, this is like saying that you shouldn't use VB or shell scripts because then you'll have to hire a [language Foo] guru.

      Anyone who can understand C++ or real C code can pick up Perl or Python or PHP in a few hours.
    • Re:well (Score:2, Interesting)

      by Nelson ( 1275 )
      I agree. I hope he described his system poorly and really meant something else.


      The fact is, lot's of large projects are multi-language based right now. Not always in ways you might expect but for example, a large project I worked on for a very large and successful computer company had a large C++ code base. It has a set of no less than 35 support "scripts" written in Korn shell, it has an elaborate build process written in "make" which has portions that break out into Korn or Bourne shell to read environment variables and do various things. If you want to be pedantic you could easily point to pure C in the code base as well... And that doesn't include the java based client that was written later. Honestly I don't know of an easier or better way to run it, not for something like that. It was a very large "system" and not really an "app" or a "program" there were dozens of programs in the system that were sold as a package.


      With web based apps I don't think it's terribly uncommon to have C or C++ doing some kind or service oriented task and then have something like perl or php interface to it and format some HTML. I could easily see a C++ server with some support scripts in Bourne shell (perhaps entries in /etc to start it up) feeding XML type data to a PHP or Perl script running on apache or something like that. As long as things are kept sane I could see it being a very easy way to develop an app and probably a sane one. I don't see someone writing C or C++ code to do what PHP does any better than PHP does it or producing the product very quickly. As a consultant, most of my clients would gladly pay for a few lines of php if it means I get done in 2 months instead of 4 months.

  • by gatkinso ( 15975 ) on Tuesday November 20, 2001 @05:04PM (#2592526)
    ...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.
    • 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.
    • it really depends on how you do cross language development. For instance COM allows in process and in thread calls, even if one side is C++ and the other is VB.

      A good example of how COM and 'COM like' systems can work is with DirectX in VB. There is obviously more then one language at play: VB, C++, C and a good deal of x86. however I've seen some very impressive demos done with this exact setup the is because the overhead for calling a C++ method from VB is virtually nothing, at least if it's in process.
    • by horster ( 516139 ) on Tuesday November 20, 2001 @06:38PM (#2593251)
      > ...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
      • I hear these arguments alot, but they are just not right.

        1. multi-processor scaling, generally a no brainer with seperate processes, if they are broken up intelligently

        This is what threads are for. Now, there has to be communications amoung the processes and the overhead to accomplish this is greatly reduced if done in a single application. Now, you can bitch about programming threads but if you can break the program into entirely seperate processes, you shouldn't have to worry about race conditions since you code is already so seperate.

        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

        Well, one would hope that if multiple processes need to be using a common library that it be made into a shared library. There is only ever one instance of a shared library in memory. The little bit about avoiding memory leakage by having processes restart frequently requires a great deal of latency when actions occur. If your application can handle this latency, and you want to be that lazy about programming, then just have your application restart every n minutes.

        3. security - different processes can be run as untrusting groups, a great boon especially if one processes needs to run as root!

        There are very few circumstances when a process should ever have to run as root. Why do a bunch of apps have to run in a group whereas a single app can't? If an application absolutely requires some bit of access to resources only given to root, then having that application just exist presents a huge problem since you are effectively making a resource that many smart people think shouldn't be given to arbitrary applications and giving it to them.

        qmail is written in C, and this is definitely the C way to do things, but in C++, objects present a much cleaner interface to all of this. That is the beauty of OOD. qmail really should be written in C++ if there is such to encapsulate things. (although OOD is accomplishable in C, albeit very, very ugly).
  • Maintainability (Score:4, Insightful)

    by cfadam ( 220860 ) on Tuesday November 20, 2001 @05:05PM (#2592533)
    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
    • Most programmers I know who actually have a CS degree or equivelent (That didn't come from Bob's Orange Smoothie and School of Computer Science) can pick up a new programming language fast enough to be useful.

      But then, my definition of a mid-level programmer must be different than yours is.
    • Re:Maintainability (Score:2, Insightful)

      by hearingaid ( 216439 )

      5 unrelated languages?

      Are there 5 unrelated languages?

      Okay, let's see. There are assembly languages. There's ALGOL-family languages, which include every language I've seen mentioned here except maybe Perl (and it's usually written in an ALGOL kind of style). There's LISP, Forth, Prolog.

      Okay, there are five unrelated languages. But C, Java, C++, Pascal, ADA, FORTRAN, COBOL, BASIC, Modula-2, and lots of others are all related, and frankly are pretty easy to learn once you know one of them well.

  • use 'em all (Score:2, Interesting)

    by gerardrj ( 207690 )
    I personally like the 'use whatever gets the job done' technique.
    Writing differnt parts of apps in difernt languages is the easiest way for me to accomplish a task, and to support the software later. For instance, writing some things in AWK or PERL will dramatically reduce the complexity of a C++ program. I Write some things in C or Assembly (I gave up machine language with my 6809) for speed or source code control.
    There is something to be said for developing a library of code all in one language, but for my purposes the multi-language approach works best.
  • oh god yes (Score:5, Interesting)

    by jabbo ( 860 ) <jabboNO@SPAMyahoo.com> on Tuesday November 20, 2001 @05:06PM (#2592541)
    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!
    • Think about it (Score:3, Interesting)

      I'm not sure what people are thinking when they specify that everything on a project "needs" to be done in Java or whatever.

      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.

      • You are right, but this is sometimes taken too far. Some companies / managers have a wildly over-inflated idea of the effort of switching to new tools or new languages.
      • In my opinion, the single biggest hurdle is acceptance by the client. If it's too late, or too buggy, or too rigid, no one will care whether it's in Java or PHP or Perl or Visual Fortran...

        I write code on-demand because that's what I get paid to do. I've tried being super-neat and uni-language, sloppy as hell and multi-language, and have settled on the processes that work best for me to keep our clients happy.

        I don't pretend to offer a solution for everyone in every situation, but in a small company with high-profile clients, results are the only things that matter. I find that using a fast, compiled "core" with flexible, highly-documented "glue" keeps me from having to work too much overtime, and allows other developers to get up to speed quickly.

        Documentation is KEY to my strategy. Without it, I don't think any of my other comments are relevant. I'm not an OO fascist but it sure does make documenting and segmenting code easier, for run-of-the-mill business and controller apps.

        Again, this is just one programmer's experience.
    • Re:oh god yes (Score:5, Insightful)

      by pi_rules ( 123171 ) on Tuesday November 20, 2001 @05:37PM (#2592801)
      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.
      • maybe your arguments would make more sense. But I can't really be bothered to futz with the internals of Postgres or Apache or qmail or [...] every time I need to change something.

        And the other employees of the company want to change things, our clients want things changed, no spec is ever firm, etc... eventually, at least in the line of work I'm doing, it dawns on just about everyone that the "logic" and the "presentation" are not only separate, but often so totally unrelated that one or two hooks will suffice. That's where my break happens.

        The whole "MVC" idea says the same thing, in so many words. I'm just using the best tool for the job, and I've done this sooooooo many times, our business is soooooooo specialized, and our clients expect things sooooo fast (cause we always turn things out pretty fast) that, rather than being a conscious decision to eschew CMM or OOP or whatever the PHB buzzword of the week is, I simply got the damn job done, producing some reusable libraries along the way.

        It's also worth noting that all of this *COULD* be in C/C++ or Perl alone, but I don't feel that Perl is good for anything other than glue, and I don't want to dive into a shit load of C code every time a client requests a change.

        Anyways, that's just my job experience. Yours may be totally different, and probably is, if you write device drivers or microcode for a living, work on huge integrated apps, and so on. Then I'd probably want to stay in one language with *maybe* a scripting language for unit tests and prototyping interfaces.
    • got some latitude in my paradigms

      Yeah, I bet it really helped you to leverage your synergy to grow your productivity.
  • by Hiro Antagonist ( 310179 ) on Tuesday November 20, 2001 @05:07PM (#2592552) Journal
    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 didn't get the impression that he was talking about using 5+ languages on a project. Two or three is perfectly reasonably, under certain circumstances.

      I personally use Perl, C/C++, and PL/SQL in tandem with each other. Each language performs certain tasks better (or easier) than the other. I find this can make supporting the code 'simpler.' It's much easier to write a small PL/SQL stored proc for some actions than to muck around with C/C++ for the same task. And Perl is great for automating file movements (ftp files from a to b, run processes q and z on them).

      Use what gets the job done. It's not *that* difficult to find developers who know 2 or 3 languages.
    • by KyleCordes ( 10679 ) on Tuesday November 20, 2001 @06:08PM (#2593091) Homepage
      [Not only does my employer need to find someone who can code in C, C++, Java, Perl, Python, shell script, and assembler]

      You are certainly right in the extreme case, but this is often overdone. If your employer is not hiring people who can learn a bit of Python when they need it, perhaps they should hire different people. If you can save a lot of time and money why adding a second language to a project, it may well be worthwhile. Adding the 5th language very likely is never worth it.
  • Maintainability (Score:4, Insightful)

    by Xawen ( 514418 ) on Tuesday November 20, 2001 @05:07PM (#2592553)
    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.
  • by Ars-Fartsica ( 166957 ) on Tuesday November 20, 2001 @05:08PM (#2592555)
    People mix languages out of necessity for accomodating legacy code.

    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.

    • 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 [xs4all.nl] 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.
    • by tgke ( 258215 )
      You are right that languages are often mixed because of legacy code, and mixing languages can create maintanance issues.

      But, those issues can be reduced if a proper the entire system is properly design, with clean and well documented interfaces.

      And performance IS an issue, but only in certain, often small sections of the entire code base. Rapid development in a protoyping language as Python, and optimizing using compiled C modules does not sound like a bad idea to me.

      Time you win during the development cycle can be well spend in the important testing and refactoring stages.

      And don't worry, in larger projects, refactoring WILL be needed. ;-p
  • by javester ( 260116 ) on Tuesday November 20, 2001 @05:08PM (#2592560)
    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".
  • Policy... (Score:2, Insightful)

    by AcidDan ( 150672 )
    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 =)
  • by harangutan ( 315386 ) on Tuesday November 20, 2001 @05:10PM (#2592572)
    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.
  • Not a fan.. (Score:4, Informative)

    by Xzzy ( 111297 ) <sether@tr u 7 h . o rg> on Tuesday November 20, 2001 @05:10PM (#2592578) Homepage
    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.

    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 ./foo.sh than it is to dork with the up arrow.
  • by ez76 ( 322080 )
    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."
  • what a nightmare!
    Here is that Bank software you waned, the interface is written in VB, Java and C++, the middle tear is in C, PERL, and fortran, and the back end is cobol, fortran and informix.
    yeah, that would be good.
    Too often when someone says a language has a weaknes, what they really mean is "Its too hard to learn the language really well".
    • Was this suppose to be funny? You've actually descibed my perception of corporate applications to a tee. Lots of little individual things written in whatever language the consultant of the year wanted to use.
    • ahh yes, the average IT type -

      USE ONE LANGUAGE!!! we are all idiots who can only learn one language, and we MUST use it for every single project, on matter how inapplicable it is.

      Informix 4GL doesnt have file access? who cares, make a temporary database table!!!

      VB isnt known for its alogorithm capabilities, screw that, write a schedulign algorithm in it...

      BUT whatever you do, dont use something that works, everything is a nail, and we've got this golden hammer.

      no thanks, been there, done that. you end up with code that is written in languages ill-suited for the purpose.

  • Depends (Score:3, Insightful)

    by Frijoles ( 16015 ) on Tuesday November 20, 2001 @05:13PM (#2592602)
    "Do you guys use this kind of method, or do you try to do everything in one program?"

    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 .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.

    What you do on your own time, that's a different story. Whatever suits your fancy.
    • Whereas if the app was written in Cobol without the CLR (I'm going to assume there is some kind of COBOL.NET), you not only can't maintain the app, you can't even script the pieces with another language. Standards are good, but sometimes that standard happens to be cobol (proof that there is no god).
  • Imagine trying to install it on a machine without one of the 80 billion interpreters or libraries or virtual machines your code needs in order to run? Is it multiplatform? How do you maintain this stuff? Do you get paid to write it, or is this simply stuff you write for yourself and use by yourself? I guess, if the former, there's quite a bit of job security there. But I'd shoot code that looked like that, just by the sound of it.
  • What do you mean? (Score:2, Insightful)

    by aspillai ( 86002 )
    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
  • First, I think that a developer needs to know several languages, both LLL and HLL.
    Now, I think that it's prefferable to do a project in one language, that way it's much easier to mention, and you don't have to move from one way of thinking to the other.
    That said, there are some inherited weeknesses and strengths to languages, which is why I think that sometime it's important to mix languages. (For example, creating a fortran library to do the number crunching, or c dll for string handling)
    When I mix languages, I usually end up in writing roughly 90% of the application in one language, and using another just to support its weak points (VB for major string handling, frex.)
  • doh! (Score:5, Insightful)

    by Chundra ( 189402 ) on Tuesday November 20, 2001 @05:16PM (#2592625)
    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.
  • by bluGill ( 862 ) on Tuesday November 20, 2001 @05:19PM (#2592660)

    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.

    • 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.
      Yes it is easy to pick up a new language. Languages are not the problem, it's the libraries. If the multi-language apps are all using the same libraries or are fairly self contained, then fine. Otherwise there's a lot of knowledge invested in the different libraries each langauges is supported by.
    • by scrytch ( 9198 ) <chuck@myrealbox.com> on Tuesday November 20, 2001 @07:34PM (#2593551)
      Imperative languages are pretty much isomorphic. Learn one that's sufficiently rich and you pretty much know 'em all.

      The story gets different when you start with other paradigms. Try teaching yourself Haskell or prolog in a morning. And it's languages like that that are often a reason to pick one over the other, because the problem space demands it. I could write a web form processor with db access in any language ... but trying to write a fraud detection system in C is like trying to build a house with a hammer (actually the fraud detection system I'm thinking of was written in APL ... yowza)
    • I belive that I can learn any computer language you wish me to program in, in under a week.

      you obviously never experienced perl.

      Some parts of perl confuse even Larry Wall at times.

      The only language on the planet that is obfuscated from the start! (That is a loving joke... I love to program in perl... but some expressions are fricking bizzare.)
    • by carlfish ( 7229 ) <cmiller@pastiche.org> on Tuesday November 20, 2001 @09:46PM (#2594012) Homepage Journal
      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
  • 0100100100100000011101110110000101110011
    0010000001101010011101010111001101110100
    0010000001101011011010010110010001100100
    0110100101101110011001110010111000100000
    0010000001010110011001010111001001111001
    0010000001100110011001010111011100100000
    0111000001100101011011110111000001101100
    0110010100100000011101110110111101110101
    0110110001100100001000000110001001100101
    0010000001100001011000100110110001100101
    0010000001110100011011110010000001100100
    0110111100100000011101000110100001100001
    0111010000101110
    • 0101100101100101011000010110100000101100
      0010000001100010011101010111010000100000
      0111010001101000011011110111001101100101
      0010000001110111011010000110111100100000
      0110001101100001011011100010000001110010
      0110010101100001011001000010000001010011
      0110110001100001011100110110100001100100
      011011110111010000101110
  • by Kefaa ( 76147 ) on Tuesday November 20, 2001 @05:23PM (#2592691)
    I stick with one, or in some cases two. The basic reasons are:

    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.

    • As developers now tend to be the most expensive part of a project

      Now that we've done away with those silly things like analysis, design, requirements gathering, integrated testing, et al, I guess that does just leave developers holding the bag.
  • by avdi ( 66548 ) on Tuesday November 20, 2001 @05:23PM (#2592692) Homepage

    This approach to software has been codified into a Design Pattern [c2.com]: Alternate Hard and Soft Layers [c2.com]. From the WikiWiki page [c2.com]:

    By virtue of the
    FirstRuleOfOptimization [c2.com], go ahead and write most of your code in the highest level language you can find.

    By virtue of the ThirdRuleOfOptimization [c2.com], when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

    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 [swig.org] makes this pattern very easy to apply in real life.

  • mix Python, a language that is fast to write with, with time-critical functions as libs written in C (using the Python/C API)... get the best of both... use python as a glue for your C code
  • Hmmm - I spend a fair amount of my time maintaining a web site that is a mix of PHP/Java/Perl.

    I hate it becaue basic functionality on the site is coded in each language, and has to be maintained or changed in at least 3 places every time an update has to be made.

    So I guess I would say that the lack of ability to share working code from one language base to another in this implementation is a hell of a good reason to avoid this approach like the plague.
  • I'm starting to standardize on PHP, but for a while I would do chunks in ASP and then have them hit other chunks of the apps in PHP and it was a mess.

    It was convenient at the time though because I knew how to do pieces of the code in each language quickly and easily.
  • We do this at my company. The web apps are all written in PHP; most of the small "helper" apps are either Perl scripts or bash shell scripts, depending on the size; and the large, complex programs are written in Java. Finally, key server components that require extremely high throughput are coded in pure C in order that they run as fast as possible.

    This works well for the reasons stated in the story. However, my main complaint is that getting your development workstation set up such that you can use and debug all of these languages effectively takes a little doing. Things have gotten easier: a few years ago installing JDK's was kind of a pain, but today they come in RPM form which makes it easy. Ditto for PHP.

    The other big problem is the context switch required, not only the languages themselves (which I don't find it hard to move between, especially with a good syntax-highlighting editor like vim) but rather the different tools. The Perl debugger is very similar to, but not completely the same as, gdb. So I find myself hitting the wrong keys when I'm switching back and forth between debugging Perl and C. PHP, on the other hand, uses good ol' fashioned "printf" debugging, so no problem there. :)
  • I don't think there's anything wrong with your method. Certainly if you can coordinate everything, your approach has definite advantages.

    Personally, I've found that a good knowledge of C can pretty much be used to fix any limitations of any other language (and pretty much every language has better string-handling routines than C ;). It's also a great glue language, so that if you've got one language that doesn't query a database, but it can interact with C, then you can write the C stuff to query the database and have the other portion of the program call that. Pretty much everything out there has a C-based API.

    In my case, I coded a messageboard website in PHP, which does everything really well, except that when it came time to work in a search engine for the site, I figured I wouldn't want to go through some sequential parsing of all the files through PHP each time because it would probably be superslow and interpreted each time.

    Now, you can redirect from a php page to a c-based cgi page and vice-versa (just have to know your HTTP headers), and you can code sockets in c in linux pretty easily. So what I have is a daemon process running in the background in C, with all the information indexed in a binary search tree (from when it was loaded) and ready to receive connections. The php search page hands off to the cgi page, which queries the daemon with some data, receives the resulting data, and redirects the output as part of the header to a php page, which displays the results. The search daemon in the background is all c-based, with queries to postgresql, and the way it's set up now, could receive CRON commands to rebalance the tree, repopulate the tree, add new messages to be indexed, dump all the contents to an XML file, etc.

    Now, PHP has bindings to pretty much every database worth its salt, does great string manipulation, can interact with XML files, can interact with LDAP (I think), has some socket capabilities, and they're working on making it work with GTK+ and also be CORBA compatible. PHP combined with a web-browser can pretty much create the perfect client, and of course, you do whatever the hell you want with the server...

    The main problem is having a good protocol to communicate between everything. That's nothing to scoff at. But I still think your approach is sound.
  • Since everyone is bashing the concept, I'll gladly take the stance accepting it.


    If you write the core of the program in C/C++, the part that's slower or extreemely common and then let the rest be implemented in say, Perl or PHP (or some other script language) you have the benefits of higher maintainability with quick and easy development.


    Take any perl program and port it to C, it might be a little harder. Imagine how much more of a hassle a BBS (or slashcode) would be if written only in C.


    Now imagine the same program written only as perl. You don't get the beneifits of speed (lets not assume mod_perl :)).


    Now what if the core parts of slashcode were written in C and less complex or higher maintained parts were written in Perl, you get the best of both worlds. This is how shell programming almost works, no? You write the simple logic which would be a pain to write in C to use C programs that do other things well.


    It adds the complexity of knowing 2 languages, but if both lanugages are not bad languages (don't dare pick on perl :P ) no one should have a problem learning them. One shouldn't use more than 2. SQL and regexp are acceptable since they are very limited, but adding a third or fourth into the mix only adds complexity as it takes away either from quick development or maintainability.

  • This is where these technologies work great! You create modules that you can use in a variety of languages from a variety of languages. With COM, you can write it in C++ (MFC,ATL), Java, VB, and other languages. CORBA I believe works similarily. With .NET, you have a standard API set you can use in any language. Build many modules, use them in many applications, and make your applications smaller.

  • Framework (Score:2, Interesting)

    by mugnyte ( 203225 )
    For a long time, many of the readers of /. have laboured to put together a private, then public "Framework"

    While not discussing the merits of such an endeavor, they almost always have a productivity gain result, with the added propeller-head feature of making the dev team "kings of the castle" of How It Should Be Done.

    Every OS is merely an minimal acceptable level of a framework.

    By writing applications in a single language, platform or environment, you leverage your knowledge in the language. BFD. BUT! When you organize it on a grand scale as a Framework, you can make extraordinary differences...and you avoid the hodge podge of applications that may or may not live as long as your users need them.

    In my world, enterprise applications written in a massive and ever-more-portable / feature-filled / wrappable C++ framework are the norm. They last years and become somewhat of a family hierloom that we take pride in.

    We have budding frameworks (both built and purchased) for VB and Delphi - but they slip and slide through versions way too often. Ever 3 years the language is updated to take advantage of the Next Big Thing. In a lower-level framework, you can add in these features because you're closer to the understanding of basic toolset.

    Combined with a Component take on development, one can merely add a object to the mix and suddenly the security model, status reporting, version control and documentation stay compatible.

    If you are trying to use different frameworks to achieve solid goals merely from your single opinion of "best for the job" - you are missing a lot of management skills.

    mug
  • by Tyrall ( 191862 )
    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.

    -----
  • I like ActiveScripting in windows for this. I can write an application in any COM language and inculde the script control. I can share objects between script and application code, I can call one script langugage from another, and the choice of languages is fairly good (JScript, Perl, Python, TCL....O.K. - I admit I've even used VBScript for some date calculation stuff). Doing it all this way means you can debug it in one place, and leverage the strength of the different languages that are available. The final application has a lot of flexability too. Store you scripts in external files you can just edit them in a plain old text editor, rather than edit/re-compile/deploy. I agree with the other posters who note that you may be creating problems for management, but it's not like they've never create problems for developers in their whole lives is it?
  • Cart? Horse? (Score:3, Insightful)

    by Lumpish Scholar ( 17107 ) on Tuesday November 20, 2001 @06:35PM (#2593244) Homepage Journal
    I tend to use C++ as my controlling program, and then execute Perl, PHP, or Java ...

    That's very ... unusual. You're using C++ as your "glue" language, and a higher level language for the code where your inner loop resides?
  • I have never combined languages (except when using web stuff. I would be interested in the hows, whens, whys, etc of it. Are there any good book people can recomend?
  • You may already be doing this ...

    If you've got a system that's half C++, half (for example) Perl, you might consider either extending Perl to support your C++ code, or embedding Perl (interpreter and your code) in your C++ code. For Perl, it's documented in chapter 21 of the Blue Camel (3rd edition). I assume the same tricks can be applied to PHP. C++ and Java can play well together with native methods, I believe.

    I'll point out the downside: This still requires your successor(s) to know both languages, plus the "glue" between them.

    (Forget about being hit by a bus; you may want to move on inside your current organization. The harder it is for your successor(s) to support this system, the more likely it'll be a boat anchor around your ankles, when it comes to job mobility.)
  • by WndrBr3d ( 219963 ) on Tuesday November 20, 2001 @06:44PM (#2593277) Homepage Journal
    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 [amazon.com]) 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 ;-)
  • On any given page in my current project you are seeing the results of VBscript or JavaScript running on the server (ASP), usually JS running on the browser(for DHTML effects and validation), XML/XSLT (formatting large result sets and general neato-ness), and FoxPro (the database. Don't laugh, I'm trapped in an M$ shop, and FoxPro is the most subversive dev tool we use (no licensing for server, just whip up a COM, and it kicks M$QL's ass))


    This seems pretty common in the Web world, and yes, it explains alot... but I definitely try to pick the right tool for the job (dates are easier to handle in VBS, but forget about regular expressions, that's a job for JS).
    I think I'd get bored quick if I had to develop in on language. Then again, it might lead to a deep understanding of the language.

    Of course, I could be wrong.

  • Perl + PHP (Score:3, Interesting)

    by justinstreufert ( 459931 ) on Tuesday November 20, 2001 @06:58PM (#2593349) Homepage
    I worked at eGrail [egrail.com], whose flagship product is coded in a mixture of both PHP and Perl. Web user interface is in PHP with a fast internal parsing system written in Perl.

    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

  • The pros and cons of using multiple languages have been detailed already here, so I won't repeat them en masse. Suffice it to say that the pros boil down to the flexibility to use the right tool(s) for the job all the time, while the cons boil down to extra overhead getting your tools to work together, and getting your developers up to scratch in using them all.

    From personal experience, this leads to certain "good" uses of the tools, and some "bad" ones. Below are my "best choice" times to use multiple languages.

    1. On a large project, the main program is written in a single language (e.g., in my current case, C++) and other languages are used for independent supporting tools (e.g., our fairly involved build process uses Perl and Python scripts, our installer uses XML source data, etc.).
    2. If you're working on a genuinely multi-tier project, given well-defined communication protocols between tiers, what each is written in can be independent of all others. For example, given a web front-end to an e-shop, you might sensibly write the front-end using scripting tools, the back end in C++ and the database using a full-fledged DBMS.
    3. Your main bit of code is written using a relatively high-level language, and after profiling, you optimise by recoding specific routines in a lower-level language for better performance.
    I'll just note here that in each of these cases, the languages are being used in complementary parts of a project, but never simultaneously on the same part without a very well-defined interface between them.

    Personally, I'd say that going further and trying to use multiple languages on different pieces of the same basic development is asking for trouble. The drawbacks start to seriously outweigh the benefits if you're not very careful. I'm sure it has been done effectively somewhere, but I've never seen such a case myself.

  • This will make you millions...

    Lisp + Perl + C
  • All I can say is that debugging must be a pain in the ass.
  • by LoveMe2Times ( 416048 ) on Tuesday November 20, 2001 @08:27PM (#2593751) Homepage Journal
    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.
  • Think about your favourite shrinkwrapped software. Chances are it doesn't only contain one executable.

    As an example, my employer makes a product which includes a processor-intensive number crunching program, a compiler, a file format converter and a reporting tool. The number crunching program is in C++ (to keep a cap on performance). The file format converter needs to be in something which can be interfaced with C so it can use some third-party libraries. The compiler, however, has no other requirements and is not time-critical, and so is being rewritten in Haskell for ease of implementation.

    The point being that even if it's hard to get two languages to talk to each other, multi-language application suites are more common than you think.

    (Although, even Emacs is written mostly in Lisp...)

  • I think the best way to go is to write all the time-critical portions of your program in Java. Then, write a Java VM in Perl. Then, write a Perl interpreter in BASIC. Then, write a BASIC interpreter in Python. Then, write a Python interpreter in shell. Then, write a shell interpreter in C++. Then, compile that C++ program and run it under an x86 simulator written in COBOL. Then, write a COBOL interpreter in Pascal. Then, write a Pascal interpreter in Prolog. Then, write a Prolog interpreter in Smalltalk. Then, write a Smalltalk interpreter in awk, and use M4 macros to convert that into a C program, which you compile and run natively on the machine.

    Now remember, the previous paragraph applies only to the time-critical portion of your program. The other 99% of it should be hand-coded and highly optimized machine language.

  • Weird languages (Score:4, Interesting)

    by YoJ ( 20860 ) on Wednesday November 21, 2001 @02:37AM (#2594752) Journal
    A lot of people seem to be saying that it is dangerous to use "alternative" languages for major projects because people that must maintain the code may not be familiar with the language. This is undoubtedly a valid concern. One neat idea to get around this is to use a high-level language as a tool for creating a project written in a lower level language. For example, if the target application is some sort of GUI app, then someone may decide to use Java. But Java is not a particularly high-level language, so you decide to use Lisp. You create a Lisp "environment" that facilitates creating Java source code. Lisp functions create abstract data types representing Java programs with certain attributes, e.g. widgets and widget behaviors. Then you write a Lisp function that translates the data structure into valid Java source code. Developing the program then becomes less of a mundane Java programming task, and more high-level and fun.

    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.

You can be replaced by this computer.

Working...