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?"
What if you get hit by a bus? (Score:4, Insightful)
Re:What if you get hit by a bus? (Score:2)
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.
Re:What if you get hit by a bus? (Score:2, Insightful)
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.
Re:What if you get hit by a bus? (other case) (Score:2, Insightful)
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.
Re:What if you get hit by a bus? (Score:3, Funny)
--Dan
Re:What if you get hit by a bus? (Score:3, Insightful)
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?
Re:What if you get hit by a bus? (Score:2, Insightful)
You scare me. (Score:2, Insightful)
Re:You scare me. (Score:3, Interesting)
Re:You scare me. (Score:3, Insightful)
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)
Re:Quite the Contrary (Score:5, Interesting)
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
Re:Quite the Contrary (Score:2)
You are supposed to do it anyway, after all.
Language independent process (Score:2)
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)
Re:well (Score:2, Insightful)
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)
Re:well (Score:2, Insightful)
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)
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)
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
Optimization across processes can be tricky... (Score:4, Interesting)
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.
Re:Optimization across processes can be tricky... (Score:2, Insightful)
depends (Score:2)
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.
Re:Optimization across processes can be tricky... (Score:4, Informative)
> 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
Re:Optimization across processes can be tricky... (Score:3, Interesting)
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)
Personally, I write something end-to-end with one language because its nice to be consistent.
- A
Re:Maintainability (Score:2)
But then, my definition of a mid-level programmer must be different than yours is.
Re:Maintainability (Score:2, Insightful)
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)
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)
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)
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.
Re:Think about it (Score:2)
True, but the project must be completed! (Score:2)
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)
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.
Well, if I had time to write domain-specific code (Score:2)
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.
Re:oh god yes (Score:3, Funny)
Yeah, I bet it really helped you to leverage your synergy to grow your productivity.
action items needed (Score:3, Funny)
lest you facilitate a dialogue with my supervisor.
my sourcebook for business-speak -- Action Item Man comics [sentient.com]
yeah, you got me... I'll go back to my TPS reports now.
Release and maintenance problems. (Score:5, Insightful)
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.
Re:Release and maintenance problems. (Score:2, Insightful)
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.
Re:Release and maintenance problems. (Score:4, Interesting)
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)
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.
Generally, a bad idea (Score:5, Insightful)
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.
Re:Generally, a bad idea (Score:2, Informative)
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.
Re:Generally, a bad idea (Score:2, Insightful)
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.
Re:Generally, a bad idea -- your view is! (Score:2)
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.
Languages are a means not an end (Score:3, Insightful)
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)
- 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 =)
A little simplistic (Score:5, Insightful)
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)
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
Languages are tools (Score:2, Insightful)
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."
YIKES! (Score:2)
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".
Re:YIKES! (Score:2)
Re:YIKES! (Score:2)
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)
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.
Re:Depends (Score:2)
Boy, I hope I never run into one of your programs. (Score:2, Interesting)
What do you mean? (Score:2, Insightful)
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
My point of view (Score:2)
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)
Lately I've been using python a good deal. I write the major features in python because it's wicked fast and yet scales well. Once you have a program written in python it's pretty damn easy to convert modules to C or C++ (especially with SWIG) for optimization.
My reasoning is simple. Hack out the major features quickly, look at where your bottlenecks are, then optimize those 1) in python if possible (maybe just a bad algorithm)...otherwise 2)in c/c++. It just seems counter productive to me to have some c/c++ code calling modules written in some higher level language. The glue languages of choice are perl, python, and shell.
Then again, if what you're doing works well for you, by all means use it.
This is not human languages! (Score:5, Insightful)
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.
Re:This is not human languages! (Score:2)
Re:This is not human languages! (Score:5, Interesting)
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
Re:This is not human languages! (Score:2)
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.)
What a load of rubbish. (Score:5, Insightful)
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
that's why I only write in machine code (Score:2, Funny)
0010000001101010011101010111001101110100
0010000001101011011010010110010001100100
0110100101101110011001110010111000100000
0010000001010110011001010111001001111001
0010000001100110011001010111011100100000
0111000001100101011011110111000001101100
0110010100100000011101110110111101110101
0110110001100100001000000110001001100101
0010000001100001011000100110110001100101
0010000001110100011011110010000001100100
0110111100100000011101000110100001100001
0111010000101110
Re:that's why I only write in machine code (Score:2)
0010000001100010011101010111010000100000
0111010001101000011011110111001101100101
0010000001110111011010000110111100100000
0110001101100001011011100010000001110010
0110010101100001011001000010000001010011
0110110001100001011100110110100001100100
011011110111010000101110
Keep it simple - minimize the number (Score:4, Insightful)
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.
Re:Keep it simple - minimize the number (Score:2)
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.
It's called "Alternate Hard and Soft Layers" (Score:4, Insightful)
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]:
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.
mixing it up (Score:2)
Mixed languages (Score:2)
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.
Re:Mixed languages (Score:2)
Actually my preference would be to find a job where I didn't have to maintain this godawful mess.
Configuration files aren't going to help me solve the problem of having to calculate a discount based on some business rule in PHP, Java, Javascript, AND Perl depending on where you are on the site. An external library, which has been pointed out could be written in one language, then called from others is as step in the right direction - but not good enough. If the site was written in ONE language I'd be able to structure the code rationally across the whole site, and use a system like Javadoc to generate the documentation for the site.
Trying to use multiple languages seems to me to be an organizational nightmare for any programming job.
I'm terrible... For web apps I use everything (Score:2)
It was convenient at the time though because I knew how to do pieces of the code in each language quickly and easily.
Yes, we do this (Score:2)
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.
IMHO your approach is fine (Score:2, Interesting)
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.
Benefits... (Score:2)
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
COM, CORBA, and .NET (Score:2)
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)
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
Modular Programming (Score:2, Insightful)
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]?',
you see it in research computing (Score:2, Insightful)
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.
-----
Active Scripting (Score:2)
Porting? (Score:2)
Cart? Horse? (Score:3, Insightful)
That's very
Any good books... (Score:2)
Embed/extend? (Score:2)
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.)
VB Developer and Proud (Score:5, Informative)
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
Re:VB Developer and Proud (Score:3, Insightful)
We used to have our application written this same way. VB GUI front end, C++ business logic back end. The problem we had was that some people on the team were stronger in VB than in C++, and we ended up with business logic creeping into the VB. A few years ago, we decided we had to walk away from that app for future development, and here we are reinventing the wheel today. After five years, we had ended up with more business logic in the VB than in the C++. It's an awful mix. It's tough to maintain, and tough to debug.
On the other hand, I don't think it was necessarily the language that caused the problem. What we had was people developing without understanding the underlying architecture of the application. The VB portion was originally created by a vendor in 1995, and she walked away from it as soon as it compiled. It was thrown over the fence to other coders at that vendor's site, as well as us at that time. Those of us who got in on her initial training were able to carry the design forward, but almost immediately the new hires (and the vendor developers who were not under our direct supervision) started "blending" business logic into the VB.
I think we were doomed to this fate from the get-go because we didn't have strong project control. Any ongoing programming task is going to have issues like this creep in eventually. Multiple languages aren't necessarily the problem, and in some cases can help, but discipline is required to pull it off successfully over the long run.
John
Welcome to the World of Web Development (Score:2, Interesting)
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)
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
Good and bad uses of multiple languages (Score:2)
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.
The Ultimate Language Triple (Score:2)
Lisp + Perl + C
uhh... (Score:2)
Web programming is multi-lingual by nature (Score:4, Informative)
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.
Most "applications" are not one program (Score:2)
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...)
Efficient programming (Score:2, Funny)
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)
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.
Re:A good idea... maybe... (Score:2, Insightful)
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
Re:You make my life HELL! (Score:2, Funny)
See, comments can fix any problem.
Re:Java is the VB of the new millenium (Score:2)
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.
Re:To keep flogging this horse... (Score:2)
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.