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?
I can see some merit in that, but if you pass on maintenance to someone else, you could have just increased the number of people required to support the project, or require the new developers to learn more new languages before they can be useful. It's easier to find someone skilled in foo than to find someone that knows foo, bar, baz, etc.
...just the cost of the context switch can be enought to deter one from this.
Cross platform development just got that much more complex.
Add in the cost (not always $) of additional development tools, maintaining such a beast, and obtaining the required knowledge/skills can make your approach daunting - esp on large scale multideveloper projects.
I am very small, utmostly microscopic.
When you start using several different languages, you now need a person with several skills to maintain it. Trying to find a mid-level programmer who is strong in 5 unrelated languages is much more expensive than a mid-level programmer with 2 primary languages in his toolbox.
Personally, I write something end-to-end with one language because its nice to be consistent.
- A
I 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.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
I'd go insane if I tried to use a compiled language for frequently-changing applications (eg. web interfaces to purchasing systems, database large object manipulation & indexing, etc.) but likewise I'd grow old waiting for things to happen if the cores weren't in C.
Personally I dislike C++ because I find it harder to port than ANSI C. But I wrote plenty of it when I was learning how to program (before I learned Scheme and Perl and Java and got some latitude in my paradigms). Either C or C++ is great for speed and hooking into the OS or an Apache module or whatever. It's also less tempting for admins or rookies to mess with C code because bad code may not compile.
On the other hand, object-oriented (or at least modular) PHP and Perl code, and decently-written Java code, is much easier to adapt to changing demands. I stick with PHP and Perl, myself, and I use Perl as kind of a glue-core layer between C applications and PHP interfaces. If I had more time I'd probably write the hooks as PHP extensions, but Perl is just so damn powerful when you use it right.
I'm not sure what people are thinking when they specify that everything on a project "needs" to be done in Java or whatever. It's not particularly hard to use my code, since it's all just calls to libraries that automagically do the hard stuff. More importantly, I tend to use POD or Javadoc-style comments in everything, and don't put it anywhere else. That way I am forced to keep it all up to date, because that's where *I* remind myself what arguments to feed what methods!
Remember that what's inside of you doesn't matter because nobody can see it.
I will do this sometimes for code that is intended for short-term, internal-only use, as I can often save quite a bit of valuable time.
If the code has to be maintained, forget it; what if I leave the company? Not only does my employer need to find someone who can code in C, C++, Java, Perl, Python, shell script, and assembler, but they have to find someone who knows how all the languages work together. Debugging is also a bit more difficult, as you have to jump between languages, and it can nastily confusing.
For code which is supposed to be release-quality, this is out of the question; you can't expect all of your clients to install Python because GUIs in Java are grotty, or install Perl because you don't want to screw with hashes and regexps in C. Release code also needs to be maintained, and there is going to be some developer turnover; it'll be easier to replace coders who leave when you don't need to list five languages as "required" on the employment-availablity posting.
--
I Hit the Karma Cap, and All I Got Was This Lousy
I think that by designing one larger program, you leave the maintainer (even if it is yourself) with an easier job. It is much much less painful to use one compiler to change one set of source files, in one language. Maybe it's just me, but I always seem to have problems shifting gears between more than two languages at once. And C compilers don't like perl a whole lot.....
This goes double if your code is open source. There is enough hard to read, poorly organized code out there that anything that is unified (in style, language, etc.) is helpful. Call me old fasioned, but simpler is usually better.
Mixing multiple languages creates huge maintainence issues - will the API for integrating the languages give you enough breathing room in the future?
How about performance? Integrating multiple languages means invoking multiple runtimes and address spaces.
What about debugging? The small amount of experience I have had integrating Perl and C clearly indicates that debugging large apps written in multiple languges is extremely difficult - forget about your IDE or traditional single debugger.
Use a screwdriver to drive in screws. Use a hammer to drive in a nail. And sometimes, if I need something really quick and dirty, you can just staple it in.
Having language religion is bad!!!!
Also, there's much to be said about the life of applications. Save for COBOL, how many old-style two-tier client-server apps are still around with no plans of being retired.
Also, I second the motion that using scripting languages is not a bad idea. For those parts of a system that get executed repeatedly, it makes sense to go with a compiled language.
For those program paths that are called occasionally, its not a bad idea to use "glue code".
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 spent some time dorking with tcl a ways back and it's always been touted as a "glue" language for bringing lots of pieces together.
./foo.sh than it is to dork with the up arrow.
Ultimately I decided I didn't like it because unerringly, at some point, you'll want your "pieces" to talk to each other more intimatley than your "glue" will provide (without substantial effort anyways). Keeping my pieces to modules or at the very least individual C libraries means I can have my stuff talk amongst itself in whatever form the language provides.
My suspicion is that having lots of executables laying around increases run time / memory usage as well because the system has to deal with that many more processes getting created.
And that's not even getting into the readability issues of having a piece of software use a random number of different languages..
The only "language" I've ever found the glue idea even remotely useful was in shell scripting, because the massive bulk of my scripts are just done to automate repetitive shell commands and it's a lot easier to type
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".
The Kruger Dunning explains most post on
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-
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.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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.)
--
Two witches watched two watches.
Which witch watched which watch?
Looks like you have it backwards. If you're going to mix languages, why not do your control code in some high level language and then call your c++ or c from that? I guess it really depends on what you're doing, though.
Lately I've been using python a good deal. I write the major features in python because it's wicked fast and yet scales well. Once you have a program written in python it's pretty damn easy to convert modules to C or C++ (especially with SWIG) for optimization.
My reasoning is simple. Hack out the major features quickly, look at where your bottlenecks are, then optimize those 1) in python if possible (maybe just a bad algorithm)...otherwise 2)in c/c++. It just seems counter productive to me to have some c/c++ code calling modules written in some higher level language. The glue languages of choice are perl, python, and shell.
Then again, if what you're doing works well for you, by all means use it.
Actually, I've been working on a pretty large programming project recently, and I find that breaking up the task into several different small programs, written in different languages for convenience, actually makes debugging easier. This allows me to test each program chunk individually under controlled conditions. Compare this to a single monolithic executable, and seeding loops with printf commands to figure out just where it segfaults. This also enables me to identify problem code much earlier in the development process.
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."
this is computer programing. I know people who tought themselves Basic in a morning. I belive that I can learn any computer language you wish me to program in, in under a week. I can read well written programs in most lanuages without any learning time. I'm not special, any compitent programer can do it.
However after attempting to teach myself Spanish for 6 months I still couldn't hold even a basic conversation (and I had a year of spanish a few years back). Once I learn spanish I won't have much a head start should I need to learn Russian or Chinese. Learning those two wouldn't give me much advantage if I need Hebrew.
People think of programing languages as if it is something special to know a lot. Really you know zero (most people), one (a lot of people, normally basic), or all of them, including ones that have not been invented yet, though you will need a refresher before you would use one.
Mastering a programing language takes expirence, and that only comes with time, but a good programer in his first week with a new language can already prove that good programers are 10 times as productive as bad programers, even if the bad programer has been using that language for 10 years.
I know people who know 20 programing languages, I'm not impressed. I know people who are fluent in 17 human languages, and I'm impressed. In school I was once given the task of learning 12 languages in 10 weeks, and I had 2 other classes besides. It was no big deal, in fact learning 3 languages was trivial compared to using one language (C) to write a program in anouther class, even though I knew that language very well.
Use the language that is right for the job. TCL is designed to make your programs scriptable. Perl is great for string manipulation. There is no reason you can't combine both, someone who needs to maintain you code will not find it difficult to learn the ones needed.
PLEASE PLEASE PLEASE make sure that you write nice, well commented code. As an example of the above, monday I was digging into someone else's C++ code. Even though I haven't done C++ is years, it was no problem reading C++. However the lack of comments was a problem. I can make changes, but I can't be sure I make the right ones without knowing what the programer was thinking. this is far more important than what language it is written in.
0100100100100000011101110110000101110011
0010000001101010011101010111001101110100
0010000001101011011010010110010001100100
0110100101101110011001110010111000100000
0010000001010110011001010111001001111001
0010000001100110011001010111011100100000
0111000001100101011011110111000001101100
0110010100100000011101110110111101110101
0110110001100100001000000110001001100101
0010000001100001011000100110110001100101
0010000001110100011011110010000001100100
0110111100100000011101000110100001100001
0111010000101110
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
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
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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.
This sig has been temporarily disconnected or is no longer in service
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.
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.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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.
;). 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.
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
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.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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
-
ping -f 255.255.255.255 # if only
That's where good commenting technique comes into play. As a good programmer I always put at the top, in a comment "If you break this [program/script/set of scripts] and want me to fix it, you'll have to pay my consulting fee of 80 dollars an hour, minium of 10 hours."
See, comments can fix any problem.
=================
Unix is very user friendly, it's just picky about who its friends are.
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.
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.
this is my sig.
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
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.
Remember that what's inside of you doesn't matter because nobody can see it.
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
lest you facilitate a dialogue with my supervisor.
my sourcebook for business-speak -- Action Item Man comics
yeah, you got me... I'll go back to my TPS reports now.
Remember that what's inside of you doesn't matter because nobody can see it.
I 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?
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
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?
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
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.
Remember that what's inside of you doesn't matter because nobody can see it.
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.)
Stupid job ads, weird spam, occasional insight at
Being a Visual Basic developer, I feel who better to know its short comings as a language. For the last few months, I've been doing cross language applications for windows.
;-)
Basically, I develop the Application Interface and Simple Functions using Visual Basic Modles and ActiveX Classes.
-but- For Intense Number Crunching, I weave Visual C++ DLL's that have all the function calls that would normally chew and grind Visual Basic to a halt (Floating Point Number Calculations, Loops on Data, and Byte Cyphers).
There's a wonderful book on the topic by A! Press (I know.. I'm a Wrox man myself) called "C++ for VB Programmers" (Link) which explains the process of using Win32 DLL's and ATL COM DLL's in your VB Application.
This process leaves VB doing what it does best, looking pretty. It also lets C++ do what it does best..... all the work
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.
ceci n'est pas un 'sig'
There are definite advantages to this design; PHP is probably the easiest language in which to write a web GUI, and Perl greatly simplified the process of building the incredibly complex parser.
The disadvantages: eGrail has (or at least had) a ridiculously long list of dependencies; one needed both a working web server with PHP4 and many extensions, not to mention Perl 5 with a host of 3rd party modules. TWO seperate database interface libraries are required.
I think it was a good thing for eGrail, but it's a carefully balanced tradeoff.
Justin
"Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
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.
- 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.).
- 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.
- 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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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).
I've finally had it: until slashdot gets article moderation, I am not coming back.
This will make you millions...
Lisp + Perl + C
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.
All I can say is that debugging must be a pain in the ass.
Hammer of Truth
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.
It leads to bloat. Case in point- Limewire.
Rookie C++ code is going to be just as crappy, if not more so due to the complexity of the language as rookie Java code. Probably MUCH worse in terms of stability, too. C++ may be able to give you better performance, but it WON'T give you better code than what can be achieved in Java, and it certainly will be less stable, harder to maintain and be a less productive place to develop in.
As far as I am concerned, C++ is a design error. Indiscriminant inclusion of features the the designers now regret and a STL library that anyone who wants the performance of a compiled language needs to avoid has lead to a nightmare language.
The fact is that the biggest problems in producing good applications - stability and consistent design are not addressed by bolting OOP features onto what is really a procedural high level assembler.
C++ is a Frankenstein's Monster of a language.
If you worked for me, I would fire you on the spot.
According to this logic, a programmer shouldn't take some extremely useful c/c++ libraries, write some perl or python wrappers around them, and then whip up an application in perl or python utilizing them? Suppose doing that would be something really useful and it would simplify their job. For the sake of argument, suppose that Joe Hacker was doing this at work, and that he hasn't written those particular wrappers before. He would:
And therefore break every one of your grossly misinformed guidelines. At the same time, he would be creating something that would alow other people to get their jobs done easier. Welcome to the world of abstraction, my close-minded friend.
if you're calling interpretated languages, you need to remember that the burden for prereq's on your target platform is going to be huge
Please explain. If you mean prerequisite memory and cpu cycle consumpiton, yeah I'll agree. Usually a constant (time and space complexity-wise) penalty is NOT a problem though, and it's hardly a "burden". If you mean prerequisite Things You Need To Do To Get Things Working, then that's simply not true.
The programs like sed / grep / awk / find use a languages.
TCP is a langauge, APPC/APPN, modems
This is gibberish. He is talking about mixing together multiuple turing-complete programming languages.find and the TCP/IP protocol do not qualify. In the case of the latter, it is a byte ordering protocol, not even a "syntax" per se.
by Porting I assume you mean going from Windows -> *nix....I guess it depends on the scripting language you choose. If you choose VBScript then porting will not be an option (and perhaps you should go and sit in a quiet dark room for a while) but if you choose something like python...you can always port you "main compiled application" to Java (assuming you didn't develop it in Java in the first place) and interact with python via jython. Or write it in C/C++. I'm not sure about Perl ('cause I have zero knowledge about it) but I assume there are ways to do it. Porting from one OS to another is fairly involved anyway (from what I hear), is that what you meant by porting? As far as being all web-based goes - what did I say that gave you the impression it was all web-based? I've imbedded active scripting into desktop apps before (and I will probably do it again).
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...)
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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.
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.
C/C++ is the default language for system software.
I would say that C is the default language for system software. Not C++.
I would rather have features available then not.
I would rather have useful features than not. Much of what I see in C++ seems less useful than I would hope.
why does a 10 line Java program require a 30 megabyte VM ?
It doesn't require any such thing.
gcj -O5 --main=hello hello.java
ls -l a.out
-rwxrwxr-x 1 eric eric 73117 Nov 20 22:36 a.out
Templates. Again, you DON"T have to use them.
Templates are evil because their definitions are not type checked in parameterized form. This often leads to problems that are the devil's own work.
The fact is that C++ compilers are forced into heuristic methods for evaluating static type safety rather than the mathematical surety that Java's design permits. Which would you rather have?
Crappy software can be written in both languages. The argument that C++ automatically produces crap code is ridiculous.
I merely propose that the skill of the programmer is the primary determinant of code quality.
C++ is a STANDARD, that was reached using a democratic process.
In other words it was designed by a committee of people with no overarching vision of what the language should be. No wonder they started with a horse and arrived at a camel.
Political arguments are irrelevant when evaluating the technical merits of a language.
However, from what I've seen most of the Java code out there is PROCEDURAL.
Sturgeon's law states that 90% of everything is crap. This is overly optimistic when it comes to code.
One of the reasons that I originally learned Java is that it seems to have become the default language in much of the Design Pattern and OOP/OOD literature. Clearly there is a reason for this - and the reason is that Java is very good at expressing good ideas in software design in a clear fashion. I have found that in my own work this is a very valuable language feature.
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.
What you are really pointing at is bad programmers. And bad programmers abound in any language. Higher level languages just get more of them. I've seen exactly the same thing you are talking about even in C++ where programmers believed they were doing the right thing but had no objects at all, and couldn't even explain what object oriented meant. The funny thing is, when I suggested to this one guy that he might as well just code in C, his response was "but I heard C is too hard to learn". If only it were hard enough to keep him from being a programmer.
now we need to go OSS in diesel cars
... when taken to extremes (my Pair agrees with this and we've got several test cases to prove it).There are good cases though for mixing a few languages.
Using 6 or more languages on a project is clearly not a good thing. but I can think of two reasons for using more than one language:
1. Cost. An example, C++ is fast, powerful, flexible but good C++ programmers are scarce, incredibly sexy and expensive (although not expensive enough). It's also a painful way of doing GUIs. Given that you need the performance of C++ but only for part of the application, why not just right the performance critical bit in the "expensive language"?
2. Architecture. Separating a system into parts written in different languages forces you to think about clean interfaces. If there is a language barrier, then there's no way of shortcutting. May seem painful to some, but the benefits will show.
I don't think that you can ever say that you should never do mixed language programming. How many systems have, in addition to their main code, a load of SQL?
This sig made only from recycled ASCII
This is why my choices are C, PHP, and Java. And a little bit of machine specific assembler for a few architectures thrown in for fun. The core of my programming (I think bottom up, so my "core" is the low level parts) is done in C, and I do include some OO design in there, too. When I do need a full-fledged OO language, I go to Java. And PHP fills in the gaps to make quick web pages. I never got into C++ and now days I sure am glad I never made that mistake. I love C and I can do a whole lot in it where other people would flee. But where I need to do full OO, there are things in C that just should not be done and C++ loses its advantages so I might as well go with Java.
now we need to go OSS in diesel cars
I would have said:
/. system moderated your article as funny, it got +1 interesting, +1 underrated and +1 funny)
And that my friend, is called job security
"he best job security you'll *ever* have is the ability to quickly get
a new job."
(I am glad the
Well, guess what, Linux is pretty darn big and yep it's written in lots of languages. And Corba is built to let you do the same kind of thing for big systems. As long as you aren't building a time bomb maintenance-wise, you should consider carefully the post above about the design pattern for alternation of hard and soft layers. It's not cut and dry.
I just posted in a previous thread reasoning about using Perl in a large project. For one thing, Perl is already a big system and it is written in Perl, C, C++, and whatever else you may want. You can call object code modules from Perl, wrap them in Perl Modules, and even write code from other languages inline inside your Perl programs (compiled automatically).
I do think you should seriously consider scrapping PHP. It is really not that great and if you are using Perl there is no excuse not to separate design from code. Also it is backwards to control Perl, a high-level language, with C++, a low-level language. The final answer is that there are valid systems for both multi-language and single-language implementations, but your choice is likely to have a big effect on the performance, maintainability, packability, and development schedule/paradigm so think hard about it! (But please stop lobotomizing Perl by calling it from C++!)
I don't have any one favorite programming language, and I tend to choose the best tool for the job. I don't know Java, and never really cared for C++, but I use C, Perl, PHP, various shell scripting, and even VB...
If I'm writing an app for *n[ui]x, I usually stick with C for anything serious (where a shell script won't do). I may hand off certain tasks to other languages though.
When doing Windows programming (though I mostly use Linux, I do find myself working with Windows sometimes), I always choose VB for the interface, and any computational stuff goes in a DLL written in plain C. As much as I hate to admit it here, VB is the quickest way to build a usable interface on Windows IMO (and I have lots of BASIC background). It works well with DLLs written in any language (with the right calling convention), and this is a perfect example of using the best tool for the job.
When I'm asked what lanugage do you use, my response is simply whatever language(s) is/are best for the task at hand. Would you ask a mechanic what tool do you use, a wrench or a ratchet? Though it's not exactly the same thing, we do have many tools, some of which are more appropriate for a particular task. I wouldn't use bash to decode MP3 data, and I wouldn't use C to write a startup or installation script, though many times the choice isn't that obvious.
NGWave - Fast Sound Editor for Windows
The impoverished languages you're accustomed to using require 2-5x the amount of code to get the same functionality as in Scheme or Lisp. You have to slow down and stop scanning large blocks of code to see what trival task is being accomplished. Instead, take it one keyword at a time.
You are right, though, that blind LISP masters can't tell you what code will do at a glance. They have to wait for their screen readers.
- C++ for core modules
- Java for portable libraries and GUIS
- PHP for some Web front-end
- Perl in form of an off-the-net free software which does mirroing (thanks to the author of it, BTW).
- Python in form of a quickly assembled propotype (to be refined, but it will stay Python) when my customer told me: why don't you do
... (initial reqs did not call for it, but this is much an impromptu project).
And yes, if I leave my company would have problems with Perl and Python modules (and lesser problems with PHP, also). But in both chase it was matter of $$$ ( in terms of developer time) and I still think I've made the right decision. BTW, Python can be learned on the flight, so my only worry is the perl program (which anyway works fine and probably wont be ever touched).Ciao
----
FB
I was talking about the working set size, not the object file size. The smallest of Java programs requires a huge VM to be loaded into memory.
This Java program requires NO VM to be loaded. The working set size is 73K. Java can be compiled to native code, eliminating the need for the JVM.
73K is about 500 times smaller than your posited 30MB JVM.