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?"
Sometimes I do. Sometimes I don't.
When I develop web applications, I tend to mix languages. That's really the only time, though.
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.
Ive always felt that using multiple languages for applications is a very good idea. The ability to use perl for something like parsing data for a c program comes to mind as a very obvious example. You get the performance of C with the ease and power of programming (the parsing part atleast) in perl. However i think there are probably some serious preformance drawbacks to using this method, though im really not sure. Anyone care to enlighten?
Oh Well, Whatever, Nevermind...
It really depends, I tend to combine Perl and C/C++ alot for SSI's and utilities that I write. I suppose whatever works...Might be tough if cross-platform developing matters to you though.
perl -e 'printf("mmm %x\n", 3735928559)'
I like mixing C and Java statements in my programs. It makes writing easier, and drives the compiler crazy!
...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.
Your question sounds like you are fairly good at several programming languages, but have not really mastered a major one.
May I ask why use many programs when perhaps one will do? In your case C++
Help end the use of Sigs. Tomorrow
I can see the merit in building applications out of several languages. Several programs here at work are mixs of several langauges. But, interfaces between the languages need to be build (or borrowed via libraries), and these can add significant amounts of work. Also, debugging, it can be painful.
I am not a script!
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.
I'm curious. Under what circumstances do you call each of the languages you mentioned?
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".
With more than one developer, this would also put a significant strain on the person in charge of maintaining (and levelling) the development schedule. Whew!
This is the way to go. This is what makes UNIX wonderful. Small apps which call other small apps to get things done. It's what UNIX is built on.
Should be a no-brainer unless you come from the Windose world...which I know little about.
I do the complete opposite and code in Java and use it to control C/C++. Ive found this to work best due to C/C++ can give me a "closer to machine" than Java whereas my main logic, being in Java, ports real fast. An example would be creating a game and using C/C++ to do the graphics and using Java to do all the games logic or functionality.
Whatever works for ya.
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 =)
Sounds backwards to me. I usually use Python as my "control program" You can extend Python with C or C++. And use Java libraries directly when programming in Jython.
Python: www.python.org
Extending Python: www.python.org/doc/current/ext/ext.html
Jython: www.jython.org
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 usually just use Python, and then code an extension module or find an executable to use a system call out to some executable for the processor/memory intense parts -- but those are few and far between. I've also used a little Jython, which is Python's Java implementation, and that works well, too, especially when interfacing with Java apps.
I once wrote a fairly complex XML to HTML converter, the GUI in wxPython, the conversion in XSLT, and Python code to "manage" it. Works wonderfully.
I see you have taken my advice from yesterday
love is just extroverted narcissism
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
i just program in whatever language my boss tells me to. if i don't know it, then i'll learn it. (hooray for google) typically for web programming i'll use vbscript server side and javascript on the client side.
THERE IS NO DATA. THERE IS O
"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-
Nearly all of the projects I've worked on for the last 4-5 years have had significant portions written in multiple languages. Different tools can really help out in certain situations. With component based designs, it really isn't that different from gluing together different submodules written in the same language. From the user's perspective, they don't know if their using something written in Matlab, C, or Fortran (I'm in a scientifc computation research area if you can't guess from that).
For the current project I'm working on, there are Java front-ends that the user sees and a parallel computation engine in Fortran 95 + MPI running on a remote Beowulf cluster on the back end. We've also got a single system back-end written in C that we can plug in. But each component is typically handled by a different group so it's not required that everyone know each language being used.
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?"
Whew, at first I thought he was serious (but perl dead.) Then as I went further and further I thought "I'm no programmer, but if IIRC from my early CIS classes, C was faster than the likes of java. By the time we got to Alan Cox and the Kernel in VB it was way to obvious it was a joke.
Thanks for a good laugh.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
My day job revolves around distributed systems architecture. I haven't met a software architect that was not fluent in at least five programming languages. The reality is, you use whatever happens to be required for the task. The right tool for the job, period. It doesn't matter if it's kewl or not, just that it gets things done.
Sometimes you also have to use whatever it is that the client (or your employer, if you're not a consultant) decided to standardize on, and that's not always fun (FoxPro comes to mind).
My point is, we are in the business of creating solutions to problems through software, not feeling cool because we get to use this or that language that we happen to just *love*. That's for hobbyist coders.
As a bonus, this mindset will always take you far higher than the standard "well, I only know F++, and I really don't care for anything else" attitude among programmers.
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
What an asshole
Instead of running separate processes, how about using the bindings that the languages have for each other? Most languages can bind with C; all you have to do is use that capability of the languages, rather than worry about forking and pipes.
I can't say that I don't give a fuck. I've just run out of fuck to give.
The most common form of language-mixing for me is using inlne assembly in C++ code. Obviously this isn't portable (unless I can #ifdef in a C++ version of the code for other architectures) but there have been several occasions where this is useful because portability isn't a concern. I don't want to write my entire application in assembly, but for raw number-crunching, hand-coding a tight routine using a good algorithm can be hard to beat. In this case, the cost of the context-switch is very low.
Other environments may be different. If you're building something that is essentially a shell script, then you're already calling various tools to do your work, be they written in C, Perl, or whatever. In this case, the shell is your "glue".
Back in the Windows world, plenty of projects use VB for their glue, and the gurus are left to build components using C++. Or web apps are built with ColdFusion, and middleware written by a different team using Java.
I think this kind of multi-language approach is more common when you have easily separatable tasks and the cost of using a different language is not large. (In the middleware example above, using Java instead of CF for your middleware might not be a big problem if the middleware is already running on a separate server and you're using SOAP or something similar to access your middleware's API.)
Certainly where I work we use different languages for our projects, but we're in a web environment where it's easier to build things this way.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
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.
The disadvantages should be apparent:
M A I N T E N A N C E
Do you guys use this kind of method, or do you try to do everything in one program? What
p aradigm (we'll just say 'object' for now) and then identify the most concise, clean, and efficient way to implement the individual objects. If Java has a clean way to implement it, do it in Java. If it makes more sense to write it in Perl, do it in Perl.
advantages or disadvantages do you see in creating one program compared to many programs?
I would tend to shy away from the term program. Instead, I try to think in terms of objects/components/modules/modular-piece-of-your-
The real problem that arises is how to hook these different languages together. If these objects can or will ultimately reside on different boxes, then CORBA or some other object brokering/naming service could suffice. Or you could just talk via your own protocol (whatever you choose) over sockets since many languages support sockets. The reason I make a big deal about the interconnections between objects is that I've seen this done badly before. I once worked for a DoD-contractor and the program was written in C, Ada, and ksh. The interface between the different languages' modules was so horrible you couldn't tell what was calling what and when the program crashed, the exception handling mechanism was so bizarre that you couldn't actually tell what happened. This was due in part to the dissimilarity of the error checking facilities in the different languages.
So, the gist of it is use different languages if it makes sense. If using different languages is not absolutely necessary, don't do it because you'd only be making the system harder to maintain by requiring a maintainer or mainteners to have experience with languages X, Y, AND Z instead of just language X.
"Computer Science is no more about computers than astronomy is about telescopes." - E.W. Dijkstra
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."
I try to keep everything under one roof, it's easier for maintenance and debugging.
What advantages or disadvantages do you see in creating one program compared to many programs?
Well on the advantages side, i can only see one. You can actually design well enough to use specific languages for specific jobs and get their full strength. However, i find that most of the time, your productivity or amount of headaches aren't really affected by this advantage.
On the bad side, i usually picture multiple languages applications as big spaghetti bowls. However, this isn't true in many cases.
( ex: using pre-compiled C apache modules in Perl really, really helped my project a lot and it didn't affect the quality of its structure. )
Conclusion: No matter the tools, everything always falls down on the developer's shoulder. Whether you use multiple languages or not, it won't affect the quality of your applications, only your skills at using them will.
A hammer is only effective in the hands of a well skilled carpenter.
That's also true for the entire toolkit.
several communal programs: better for "power-users".
That about sums up my opinion on the matter.
I have to see that for myself first...
this is computer programing. I know people who tought themselves Basic in a morning. I belive that I can learn any computer language you wish me to program in, in under a week. I can read well written programs in most lanuages without any learning time. I'm not special, any compitent programer can do it.
However after attempting to teach myself Spanish for 6 months I still couldn't hold even a basic conversation (and I had a year of spanish a few years back). Once I learn spanish I won't have much a head start should I need to learn Russian or Chinese. Learning those two wouldn't give me much advantage if I need Hebrew.
People think of programing languages as if it is something special to know a lot. Really you know zero (most people), one (a lot of people, normally basic), or all of them, including ones that have not been invented yet, though you will need a refresher before you would use one.
Mastering a programing language takes expirence, and that only comes with time, but a good programer in his first week with a new language can already prove that good programers are 10 times as productive as bad programers, even if the bad programer has been using that language for 10 years.
I know people who know 20 programing languages, I'm not impressed. I know people who are fluent in 17 human languages, and I'm impressed. In school I was once given the task of learning 12 languages in 10 weeks, and I had 2 other classes besides. It was no big deal, in fact learning 3 languages was trivial compared to using one language (C) to write a program in anouther class, even though I knew that language very well.
Use the language that is right for the job. TCL is designed to make your programs scriptable. Perl is great for string manipulation. There is no reason you can't combine both, someone who needs to maintain you code will not find it difficult to learn the ones needed.
PLEASE PLEASE PLEASE make sure that you write nice, well commented code. As an example of the above, monday I was digging into someone else's C++ code. Even though I haven't done C++ is years, it was no problem reading C++. However the lack of comments was a problem. I can make changes, but I can't be sure I make the right ones without knowing what the programer was thinking. this is far more important than what language it is written in.
This could be useful, for multi-tier apps, or for various parts of app development.
For multi-tier apps, you could have a domain-specific language at the back end. This interfaces with C, which is the main server app. Then various languages come above that, for various views. For example, a web interface could be in PHP or Perl, an interactive interface in Java or C++, etc.
The project I'm working on is mostly C. The build system, however, is mostly Perl. The two parts of the system are cleanly separated, and there's very little reason for them to talk to each other (although the build system does pass build-time configuration to the app).
I can't say that I don't give a fuck. I've just run out of fuck to give.
I've worked for CDS for three years, and I hate the people who write crap I can't understand, but am expected to support. Make it clear to management what you are doing and use lots of libraries. *please*
Having worked on a rather large chunk of code which my group "inherited" from another stable of developers who liked to "learn new technology" I have a few words of caution:
Using multiple languages is a Good Thing(tm) if, and only if, they are not used to take shortcuts, learn on the job, or avoid writing "hard" code. I'm a rabid anti-Java zealot, not because I think the language is bad, but because it is often used in places it shouldn't be. I've had to maintain a lot of fairly poor quality Java code because the previous developer was learning it at the time. The number of times I've seen a really bad use of Java because it was easier than writing good C is depressing. On the other hand, I've seen people build vast empires of C to replace what clearly should have been a nice Java or Perl program, simply because they perfer C, and have a personal adgenda. (heh... I've never done that.... nooo....)
The other fun thing to consider is that 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.
Using the right tool for the job is a nice thing, but I've found a lot of developers (myself included) tend to want to use the language they are currently tinkering with wherever possible. The old saying about "when your only tool is a hammer..." extends nicely to "when the closest tool is a hammer..."
0100100100100000011101110110000101110011
0010000001101010011101010111001101110100
0010000001101011011010010110010001100100
0110100101101110011001110010111000100000
0010000001010110011001010111001001111001
0010000001100110011001010111011100100000
0111000001100101011011110111000001101100
0110010100100000011101110110111101110101
0110110001100100001000000110001001100101
0010000001100001011000100110110001100101
0010000001110100011011110010000001100100
0110111100100000011101000110100001100001
0111010000101110
It's implemented in just about every language. It's a silly concept, but it works; and is not that hard to get working.
I'm currently writing an app in Perl & Java; back end in Java, web front-end in Perl. I could have switched Java for C++, doesn't matter. Or Perl and PHP.
I use this language, for everything I do:
http://www.webcom.com/nazgul/intercal.html
There is no need for other languages, as this one does it all.
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
For Mash, we have a C++ base that provides all of the lower-level multicast multimedia functionality and we use Tcl/Tk to create the applications. The C++ code lets us implement the low-level functionality (such as JPEG decoding, RTP transport, etc.) efficiently, but using Tcl/Tk to interface with the C++ makes it very easy to develop applications, test new ideas, and not worry too much about cross-platform UI.
Of course, you can't take a normal Tcl/Tk binaries and just arbitrarily call compiled C code, so we do require custom tclsh and wish binaries which have the C++ objects built into it. Our custom binary lets you define a C++ class as a subclass of TclClass. Then, we use otcl and tclcl within tclsh and wish to refer to those C++ classes as Tcl objects.
The title of the article is an oxymoron. In my practice I've seen people only trying to stick with one language, it becomes a real mess and a performance blow heterogeneus environment is used.
All JNI stuff is still pretty weak and there's a performance trade off.
just my 2 cents
http://dtum.livejournal.com
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
There's nothing wrong with using the best tool for a given job, and with mixing and matching the tools you have to solve a problem quickly. I could build an okay table with just a chisel, but work would proceed faster and better if you let me use a hammer, a saw, and a plane as well.
That said, I think it's important to think hard about the expense that multiple languages will bring to the care and feeding of a project. If your system is written in four languages, your project will require maintenance from either one engineer who knows all four languages, or four engineers who each know one of 'em. What's more, you've now got four tools to maintain ("Hey Joe, what version of the compiler were you using when you wrote this? It won't build for me.") If you're talking about writing quick and dirty tools for short term use, then fine. If you're talking about building a system that's important to the long term health of your buisiness, consider that standardizing on a more compact set of tools may save a lot of money and time in the long run.
Obviously, there are tradeoffs. You need to find a reasonable balance between rapid development, stability, ease of long term maintenance, cost, quality, and performance. You probably won't achieve that balance either by insisting on using the same tool for every job, or by using a different tool for every job.
it really all depends on the architecture. the idea of just writing parts of an application in different languages is nothing new, and certainly is not a bad idea since different languages might have different strengths. but the idea of just hooking up code developed using different languages, doesn't make much sense. instead, if the given application has the necessary architecture support this is another story. for example, you make your application modular, and allow then for on the fly addition of modules written in different languages. still, regardless of how it is actually implemented, one of the strengths of mixing languages in a development could be the ability of allowing, lets say, users to modify the behavior of your program in a controlled manner.
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.
That you believe fortran
is dead reveals the kind of
coding you do. I suspect
that you spend your days
doing cash register apps
for 7-11. Maybe inventory
tracking type things for
a douche-bag company.
Fortran has its place(for better or
worse). Think weather forecasting,
satellite data processing, climate
modelling, and computational physics.
But you dont know a PDE from
The turd Report's special taco, so
none of what I say matters.
So have fun doing VB coding.
Many of us out here are concerned with
scientific computing, and for that
fortran90 will be around for quite
some time.
In my group we are implementing using a multi-language model currently. We are doing this to combine Ansi C's number crunching with MFC's interfaces and Lisp's Symbol Manipulation. Due to interface and speed requirements this is the only choice.
We have only had one problem associated with this that is at the edges. Past experience has shown that with no documentation on the api's we are stuck unless "the guy who wrote it" is in. But this is true of any project, poor documentation and bad code causes problems. It seems to me that maintainability issues are the same, it's the code not the language(s).
IMHO the Java bandwagon was jumped on by a bunch of rookies that would/could not take the time to learn C++. Java has a lot of good points, however
1) It is proprietory. You guys would be screaming about this if it belonged to Microsoft and not Sun.
2) It is missing features that C++ programmers take for granted- enums and templates spring to mind.
3) It leads to bloat. Case in point- Limewire. Gnutella is a simple network protocol yet Limewire's memory footprint is 35M under windows 2000. Compare this with Bearshare (C++) which occupies around 3-4M.
C++ is a complex language, however, if you take the time to learn it, you will be rewarded. The C++ standard library is a thing of beauty, perfectly abstract, yet efficient and extensible. I have ploughed through a lot of rookie Java code in the last 5 years and 95% of it does not use any of the OOP features of Java. That's why I refer to it as the VB of the new millenium. Rookies hack out a few classes and then claim that they written an OOP system. Sadly, a lot of Java hacks do not understand the concept of over-riding a method, of course a lesser % don't know what a virtual function is.
Hopefully it can be filtered out just as quickly.
As for the language -- my programs are usually small and foisted on the web, so perl, php, bash, csh, sql, and c.
I have even used Pascal recently -- but that was just to modify some earlier made code.
Click here or here.
People reuse legacy code because it's easier than starting from scratch. When it's not, code reuse is bad.
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.
Time to get some more experience. Oh, it hurts it hurts! Make it work for you.
How about performance? Integrating multiple languages means invoking multiple runtimes and address spaces.
Performance is as performance does. Using more than a single variable invokes more than one address space. So what?
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
I don't think it's completely necessary for anyone to mix languages. Certain languages have certain downfalls so if you pick a language to do a job, you need to ensure that the selected language will indeed do what you need given the constraints of the application. Having said that, it does give you some flexibility in your app if you mix languages, particularily if you use some kind of scripting language to access your lower level code.
A good example of this would be some kind of modelling application. You really don't want to bother spending time updating the program if you're just letting the user create widgets, and they have to wait for you to release version x to include the latest ones. So adding something like Python to a C++ app would be great for this. Let the user extend the app in whatever way he wants by providing simple primitives (that they themselves could be created with scripting) and a whole new world should open up for you.
Of course this all depends on the application. I think modularity and language interoperability should be used with caution. Don't do it just for the hell of it and don't do it because it's cool. If you think the app will benefit from it (the benefits don't have to be immediately obvious) then go ahead and have a little fun while you're at it.
liB
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 agree that Visual basic is fast, but I find it hard to port to other platform. To get both portability and speed increase I'd use BASIC.
I've done this before, and it's a valid approach in a lot of cases. What you need is a situation where the strengths of the languages, and the differences between them, is so apparent that this makes sense.
Some cases where it works:
1) One part of the team is significantly less skilled or experienced than another
In this case, you may have a set of junior coders who aren't up to writing the complex, performance-sensitive portions of the application... but they understand basic programming practices and theory, and they can knock out small chunks of code in something like Perl, Python, etc. In that case, writing a C/C++ back end that can exec these scripts (or has a built-in interpreter) can be a real win.
2) The application itself is divided up into several logical parts that have very different needs.
This might be the case with the system above... it's a fast main driver program that can be customized via a scripting interface. Being able to write "plugins" in a simpler language can be a real win, both in development (allows rapid prototyping) and in production (more configurable for end users!)
3) The "application" is actually several disparate systems that are only loosely tied.
In this case, who cares what language you use? Focus on the interconnect points, make those robust, and you have a very flexible system.
4) You need as much performance as possible, or platform requirements dictate a certain language.
In that case, you just bite the bullet and write that C++ native library to hook into your Java app (or link in the Fortran math libs you need). I tend to dislike this, simply because it can be such a nightmare when it goes wrong... again, the interconnect points and the chances of lib A crashing app B better be well understood.
It's a strange world -- let's keep it that way
Sure, its nice to use an array() (hehe) of programming languages. But then you get fired, then someone like me gets called to work on this un-maintainable pile of mess.
.Net is gonna fix.... right?
But that's what
Huper the "Anonymous Coward"
You don't know any shit do you? If Linux Kernel is written 100% in Visual Basic, how can you say that It's only for El33T MS h4ck3rs ?
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
Great joke!
Let's see the errors:
COBOL, Fortran, and Perl have yet to be retired.
Java just turned 6, VB just turned 11 or 12.
C is markedly faster than Java or VB
Garbage collectors perform the same sort of memory management, often in a less optimal fashion
The FSF has marketing people?
Harsh restrictions of the BSD license?
Rewrite the Linux kernel in VB?
With Stallman's support?
I thought Torvalds was a Finn! Darn those sneaky Swedes!
Did I miss anything?
Wow! you're a dork.
I personally like the idea of writting small or medium sized programs that solve pieces of the problem, much in the Unix spirit. Huge monolithic programs are difficult to read and mantain. If you make several programs with well defined behaviour, you are giving a non-programmer (say, a sys admin) the possibility to make new things using those tools.
In my company we all know C++ and Perl, and we use a combination of both for a lot of things. I prefer not to use shell-scripts, because Perl is perfectly fine for that.
For problems like that, I tend to work with languages that have good support for multiple programming paradigms, or, to use fewer buzzwords, languages that let me easily abstract the problem in various ways. Some ways of abstraction will map more easily onto certain parts of large problems - logic programming, functional programming, OOP, straight old procedural thought, or concurrent programming might be the best fit for a section of a problem.
Trying to stick a large, multifaceted problem into (for example) the OOP mode of thought is an exercise in pain.
Languages such as those in the Lisp family (Common Lisp, Scheme, Dylan..) or my current project, Oz, all easily support various means of abstraction.
The phrase 'easily support' is important though. It's *possible* to do functional programming in Java, but I sure as hell don't want to.
You rule. =)
There should be a moratorium on the use of the apostrophe.
Max V.
NeXTMail/MIME Mail welcome
I know someone that has the receiving end of this. It's a patch quilt of "use this perl module version with this version of perl...don't use the new version, that version of perl broke it" and other maintenance nightmares. The *real* problem isn't the fact they used a certain language. It's just that it's all completely undocumented, the the code is spaghetti. If you're going to write programs like that, just document what you did for the next guy who has to deal with it.
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.
Our current project (which involves lots of different hardware and platforms) uses C, C++, Java, Python, SQL, XML, HTML, specialize SNMP MIBs (sort of a language), microcode, a very machine-specific machine code, several minor scripting languages (bash and csh scripts, make, etc) and some languages made up for specific purposes.
Somehow, it all seems to work together. One thing is for sure, a single language would never work.
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...
Are you sure you're on the right board? Perhaps you should read the tagline under
This is just a stupid .."I know 15 languages" ego trip question. Get with the program and ask somethign worthwile. (pun is intentional)
These days, XML must be the most overused tool around, great in the right situation, painful in the wrong ones.
My point is that so many apps in big companies feel they have to incorporate XML and often XSLT aswell. Now while you may not consider XML as a language in itself (more of a data representation) XSLT certainly is a language - it just so happens that the programs are XML compliant. So many apps that are 'Pure Java', are really using 2 languages Java and XSL and its all too easy for business logic to seep into the stylesheets.
Not knocking the commonly used idea totally, it is great when applied in the right situation.
I hate it when people ask me this question. I'm a computer scientist, and a language is simply a tool that I use to get my job done. I may have more or less direct experience with one language, but I have been trained to understand the foundations upon which all languages were built. One project I worked on, I did some really advanced things with JavaScript (I don't like to admit this), and when I started, I had never used JavaScript before.. but I am a scientist, and I used the language like I have been formally educated to.
Just my $0.02.
Absolutely. You should always use the best tool for the job.
Case in point, at where I work now, I inherited a Perl script which handles software sales on our website. It's an ugly bastard of a thing -- 1300 lines, like 60K long, no naming scheme on the variables, etc.
So, rather than try to figure out all this code, I instead wrote a nice little Perl module that I use to call PHP code. Even went so far as to design a little communications protocol so that the PHP code can pass back values and the Perl can parse them and pass those variables to other PHP scripts.
Is it a bit resource intensive? Yep. But the tradeoff is that I did this in a fraction of the time that it would have taken me to hack on the existing Perl code, and since there's a big crunch to get this done on time, the boss is happy and I look good.
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
Isn't this exactly what Microsoft is trying to achieve with the CLR in dotNET? Write objects in any language, and call them transparently from any other language. I know ActiveState has ported PERL and Python. I'm not sure if anyone has done PHP.
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.
This is a fairly common practice in VB development. I often use .DLLs written in other languages (VC++, etc) to make up for weaknesses in VB, and to generally improve performance where the VB equivalent would be a nasty piece of code.
Other than that, I don't usually mix languages. I've some tricky things with C/PHP, but limited.
Skiers and Riders -- http://www.snowjournal.com
I deal with lots of legacy code in FORTRAN that is as much as 30 years old... very robust, very well tested code that would take years to rewrite in another language. I also use newer stuff written in C/C++, Matlab, Perl, Python, and some other languages developed in house.
Being able to tie together different languages saves a lot of development time. It's very useful when I just need to solve a problem and move on... which is what I do 99% of the time and I almost never have to write code that will be used again after a few months.
The biggest problem I run into is that most books on various languages do a horrible job at documenting basic syntax in a way I can look up in the index quickly and I spend a lot of time trying to remember if language X uses if-elsif-else-fi or if-elseif-else-end or whatever.
...and porting to different systems isn't that big a deal if the platforms are all different flavors of unix (which anymore means you use anything but windows)...
There are 10 types of people in this world, those who can count in binary and those who can't.
And because SlashDot.Sucks.The.Big.One won't let me post just that, here's an explanation:
Writing a program in ALL C++ or ALL Java reduces the dependencies you need to write that program. Nothing is worse than finding a peice of software you would LOVE to use and discovering it required 60 different libraries, all of which are out of date on your system. With RPM distributions this quickly becomes a nightmare, and is currently the primary reason why I have never used Galeon, for example.
Isn't the MS .NET thing all about this?
Everything compiles to a common language with a proper object linking model right?
I get the feeling that you can right a handler for a button press in whatever language you like.. ( MS Supported of coarse!! )
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
Multilingual programming is used all the time for things like games. Ever heard of QuakeC? For games it's incredibly handy to have a highly optimized back-end with a simple to use front end. Our current project at work is working along these lines. It has a C++ back-end with any platform specific code, or code that must be highly optimized (such as the 3D renderer). The front-end however is all Python. This is great. We get fast (to write), high level programming with Python and a fast (to run), optimized for the platform back-end in C++.
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.
Personally,
I think that it is perfectly acceptable to expect a programmer to know many languages (5 at least). Learning the intricacies of each language might be a pain, and keeping them straight also.. however, this is why we have multiple languages. People said "Hey, this language doesn't do 'x' very well, we need to do 'x'" and they made a new language. Furthermore, once one understands the concepts behind programming, learning a new language is not very difficult, syntax, and the different capabilities/intricacies, should not be a problem. So, I say mix and match. Use the tool that gets the job done fast/efficiently.
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
I try to use each and every unix system call in each application i write. It is supposed to precache all of the system code so that if you ever need to call the system call again, it it already in memory.
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
And sometimes it even works!
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.
I've used CORBA on two projects.
Project 1:
- C++ through and through (even a C++ OODBMS emulation layer (nightmare!))
- fairly brain-dead ecommerce stuff
Project 2:Major relevant difference? In the first app (which I inherited, and was in no way responsible for) was so poorly designed that absolutely everything from the front end NSAPI DLLs to the backend to the db emulation code had to be compiled into one gigantic package -- absolutely zero compartmentalization of behavior.
In the second app, we have very clear boundaries of responsibility, such that each bit of code is largely testable independently.
The bottom line is that if you're going to use multiple languages for a single project, just make sure that each part has a clearly defined role. This helps with development, testing, and replacing team members if need be.
It's called a linux distribution. The *nix way... vi, tail, grep, cat, etc... The m$ way--WORD.
I agree that every language has its pros and cons. And I also agree that leveraging the best from various languages is a logical, rational and utopic idea.
But the truth is, for a business developing software in house (or outsourced), every new language equals a new skill. That skill either needs to be hired, trained or outsourced. Even if the difference is only Java vs. M$ Java (C#). If things break down and no one is around that can fix it (or knows how to, or takes too much time to), money is lost, and the performance gains are irrelevant.
I usually recommend to clients to set standards and stick to them. If, however, multiple languages are what's truly necessary or fit the company "vision" to do the job, be consistent in their applications and usage. For example (and this purposely stupid, to illustrate my point):
- Java for all database & data access modules
- Visual Basic & COM for all middleware & business rule modules (objects)
- PHP for all web application presentation
- PowerBuilder for all client side GUIs
Then at least a company can match skillset to experience based on the standard. The cost of ownership is at least reasonable. (Unless of course the company was stupid enough to use PowerBuilder for GUIs, then I'd quit:)
My other recommendation is to stick with a high level languages only. Although performance is lost, the cost saved on maintenance is far more imporant for a business. A high-level language, like Java for example, that is is powerful enough yet accesible, goes a long way vs. C++ in a business environment. (I know this last line will definately cause a few flames;)
Cheers
This will make you millions...
Lisp + Perl + C
All programing is mixture of languages...
The OS is language
The programs like sed / grep / awk / find use a languages.
TCP is a langauge, APPC/APPN, modems
Even if you "ONLY" write C++ - you don't. You use the editer's language to write. The compiler's language to compile.
Every API is a langauge.
You think not??
They all have syntax, verbs, methods, and anything else you want to claim as only in a langauge. What else is a API but a language, maybe simple... take (s)(F)printf... but still a language.
The only true OS/Langauge that I know is Forth. The editor, OS, & language are parts of the same thing.
Real Basic is cross platform in ways Java can only dream of. The Ease and power of VB, but available for both MacOS and Windows.
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
This sounds like an absolute nightmare to debug! Having lots of languages doing different bits executing as individual processes probably means that there is no posibility of using a debugging tool to generate a clear stack back trace showing functions and arguments. In fact, this type of system probably requires many different debuggers all running the various parts at the same time, something that is going to be difficult to manage, prducing diagnostics that are hard to visualise/comprehend and using a hell of a lot of memory.
I wouldn't like a heisen-bug to get into *that* system.
-- Mike
I'm willing to bet that most of the posters on here saying that using more than one language isn't a good idea (for whatever reason) haven't done much web programming. For a fairly normal browser plugin project that I worked on, we used the following:
1) C++ for the actual plugin.
2) JavaScript for webpages embedding the plugin.
3) Perl for CGI backends.
4) SQL (duh).
5) Wise Installer script for the installer
6) Delphi (Pascal) for a game builder app that made games to be played in the plugin. This app loaded the plugin as a normal dll.
If you're doing integration between technologies, you'll almost invariably wind up using different languages. Often times, you have no choice. Also, this isn't meant to be offensive, but people that think C/C++ is one language are naive. Generally, you have to ship clients executables, so you're limited to languages that compile natively (with the possible exception of Java). You generally can run whatever you want on your own servers. Then you have web browsers that are their own funky platform. If you can get away with using only one language, congratulations!, but don't expect that all the time.
I've had a havana omelet or 2 in my days.
I do have to wonder who designs toilets, though. We can thank al gore's low water toilet for the fact that you can't buy a shitter that cleans up in one flush. I can only assume toilet designers are all small dicked fools. Or like washing their peckers in fecal water.
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.
Visual Basic Modles
.Net code snippets? That's "Dawdles". Or were you trying to get at the collection of components and APIs? That's "Motleys".
I can't tell what you mean here by "Modles". Do you mean VB error-checking? That's "Muddles". Do you mean the prolific use of goto? That's "Noodles". Were you commenting on VB
Or maybe you had some dyslexic thing going on and really meant "seldom". That would make the original sentence: "I develop the Application Interface and Simple Functions using Visual Basic seldom..."
Yeah, that's probably the best way to go. Although the correct adverbial use is "seldomLY".
(jk. I teach VB. You need a sense of humour...)
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
C++, C#, Perl, VB, OK I don't use VB anymore. I have always worked this way, but now I have a platform that is designed for it. It is a good thing I am more interested in programming than analysing someones business practices. Fourty below and I don't give a ...
Actually I'm a student in electronic. We often have to program some chip like the 68HC11. When we have to program this sort of thing we habitualy use some language know as small-c. In that we add some chunk of code in assembler for efficiency, because some time we have to manage with the execution time who is critical. The problem with C is the language took a lot of time to process even if it's faster to code.
I sometimes dream of mixing languages to get the best from each. However, wherever I work, the boss tends to pick out everything for me, which usually means VB on a completely Microsoft platform.
Mi klopodas varbi por Esperanto.
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});
Sir Troll,
I'm am a bit stunned that you got responses at all to your anti-C post. I guess Satire is visible only to those who choose to see. Me? I'm looking for a laugh, not a fight.
Troll on!
I like to pick a few languages that cover the spectrum and work in that. C++ for the bulk of the application, with a perl interpreter built in for parsing, heavy text processing, and cases where flexibility is much more important than speed. (Also perl on the server side of course) ASM for where speed is critical. (Yeah, yeah, it STILL makes a difference for the sake of portability)
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.
Debugging tends to be easy.
Using files as a way to save data between diffrent portions, I can put in what I want and check that each portion gives me what I want.
It's only if you try it all at once (with out checking each part first) that you have problems.
=================
Unix is very user friendly, it's just picky about who its friends are.
I consider myself a good programmer. It's been my experience that depending on the complexity of the language, it takes between six months to a year of experience in a language before you are fluent. Fluency is not mastery, it's the point at which you can sit in front of the code and write in such a way that you are using the language, not wrestling with it. And you can't write good code when you're fighting the language.
As for reading a language. Sure, you can read any program immediately, provided the syntax is familiar, and the code is well named and well commented. On the other hand, there are always unfamiliar syntaxes - take someone who's only coded in C and Perl, and put them in front of Lisp or Smalltalk, and they'll need a couple of days work just to be able to parse it.
You can learn enough to slap a program together in a week, provided the syntax of the language isn't particularly alien, but it's not going to be one you're proud of the week after, when you've learned a little bit more. You'll know the syntax and control structures. You'll have some idea of the shape of the main libraries, and you'll know where in the documentation to look if you need to know more.
I've done this before - I remember having three days to learn enough of a particular language to fool a customer into thinking I knew what I was doing. And I did, we got the tender, I continued to learn more over the ensuing weeks, and the customer was happy with me. Looking back, my total unfamiliarity with the language probably cost this customer many thousands of dollars in lost productivity, for all the time I took looking up library functions in the language documentation, and all the time I spent inefficiently re-implementing functions that were already available, but that I wasn't aware of enough to know to look for them.
A week of study will qualify you to painstakingly inch through other peoples code with piles of documentation at hand, and get a pretty good gist of what the code is doing. It'll qualify you to write something artificial for your CS class. It'll qualify you to make simple logical changes real code. It will NOT qualify you to write, or make significant changes real code.
The syntax of a language is only the smallest, and easiest part of it to learn. The libraries, the idioms are far more important. Knowing all the weird letters you can stick at the end of a regexp in Perl. Knowing that double-checked locking in Java doesn't work. Knowing which collection in the STL is most suited to the data you're storing. Would you trust the maintenance programmer you've just hired and taught C in a week not to introduce an exploitable buffer overflow?
Charles Miller
The more I learn about the Internet, the more amazed I am that it works at all.
And some of my Stallmanist friends wonder why I keep supporting Red Hat.
With a move like that, I think I'll definitely put my money into them by purchasing RH 8.0 when it comes out.
Even if it's just for publicity, it's a stroke of genius.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
My philosophy is to get really good at one and stick with it. And I mean get really good with it. Know all the ins and outs, sleep with the O'Reilly book, know what modules are available and where to download them from. Overall, you will be more productive, because you of your deeper knowledge, because you will have a ready library of objects and subroutines to re-use, and because you won't have to expend the mental energy fixing trivial mistakes (like whenever I switch from perl to C, I spend half a day putting $ in front of the variables).
This is especially true for rapid prototyping and one-off scripts where if you switch to a language you use less you have to pull up the man page (like bash or awk for me)
It is less true if you are going to work on the project for a year or two because you can spend the time getting really good at whatever language you use.
Choosing the best language for a task needs to trade off time it takes to run vs time it takes to develop and generally, cpu cycles are much cheaper than your brain's cycles.
The commonality I see in all these threads is that if the project is well-implemented (design docs, code comments, good division of labor between modules, etc.), it is ok. Otherwise it will be a maintenance nightmare.
This can be said of almost any software project.
That being said, if you have a MASTERED, say, C, C++, Perl, and Java, you must have a compelling reason to switch languages for a particular subsystem. I don't advise it for the singular reason that it complicates the build process. That in turn complicates the automated testing process. And on and on.
Also, in the 4 languages I listed, there are few tasks that are not readily accomplished if you are not reinventing the wheel.
There are some exceptions to this rule, so it is soft, but I would be loathe to switch languages. I have developed on large-scale platforms in C, Perl, and Java, and I have had to write less than 10 functions in a language other than what I was using as the main development language.
John McNair
On a side note, I don't think an application implemented in a few languages will be all that hard to maintain, as long the languages in question are not the more cryptic ones like Sather or Eiffel. If the main programming languages are C++, Java, Perl, VB whatever, chances are that most programmers can handle maintenance.
Phemur
I know very little about programming, these comments are more about the general idea of multi-language programs in a buisness world i guess you could say..
I think from a corporate standpoint, its a tough sell. They think $$$. When something like this shows up, this is what they think:
1 - A group of developers (or just one) wants to use a few languages to complete a project that, lets say, the company will depend on for a few years. They are unsure as of how long these people/person might be working for them, they have maintainability to think of. Sure you could tell them that it would end up better this way, but they just see it as more money being spent. More money being spent hiring better trained developers, and so on.
2 - They see a group of developers (or just one) that can do the same project with one language. They now only have to worry about one single language, and hiring a developer that knows one language is much easier and cheaper.
Who do you think they will chose?
From the standpoint of a coder, I would say use the tools that are given to you. Given that, you have 2 choices:
1 - Make a program only using one language. You feel that if you do it this way, it would be more standard, easier to maintain, but you see that there might be some parts of the project that could pose some problems. Nothing that couldn't be done of course, but you may have to do some things with your code that shouldn't 'need' to be done.
2 - You take the same project, and see that the same language you were thinking of in the first scenario could do most of what you want pretty easily. The difficult sections, you find that there are other languages out there, such as perl, that could do something fairly easily. By doing this, you one, become a better coder, knowing not only how a certain langauge works, but how it could interface with other languages. You will start to understand that each language was written to do certain tasks.(some may incorporate many many things, but they never intended for their language to do everything humanly possible 5 years down the road).
Each language has strong points and weak points. It is your job to understand these tools, and use them in a way that will get what you want done. If it means using one application, then go ahead and do so. Don't try to force something without knowing if there are easier options, better ways of doing things.
It seems that people are more locked into using a single language(or even lets say a group of languages like visual basic/c++) when you are in a corporate enviorment, as you may not really be the one who decides on what you are going to use. You get an email that says do this and you do it.
Anyway, the above is just my opinion on the subject, I am no expert and I don't claim to be. This of course does not apply to every situation out there either.. The above is more of a general way of looking at a lot of things, but I hope I got my point across..
Zeno
Then you are not seeing the big picture. Have worked with too many people that just do not get it. They are all the same. Just because it is a "byte ordering protocol" it is still a language, if you do not place the bytes in the correct sequence - the message is not "under stood".
There is so much more than the language that the executable is written it.
.properties that contain program knowledge, .ini files, .html files (or templates) .xml configuration files, $ENVIRONMENT variables squirrelling away little bytes that affect the execution.
You've got
Anyone who writes things "100% in Java" are causing themselves problems.
Take advantage of all the different syntaxes available to access all the different resources (data, cpu cycles, network, etc).
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.
take someone who's only coded in C and Perl, and put them in front of Lisp or Smalltalk
C programmers make a big deal of going out of the way to make their programs completely unreadable. They think it's fun.
Larry Wall is GOOD enough at perl to write some truely beautiful GIBBERISH that actually does something.
with LISP you don't even have to try.
Almost all non-trivial LISP programs are so recursive, even an old, bald, blind LISP master who spends most days contemplating fully-functional AI can't tell you what the code will do at a glance.
it takes some skill to write working, unreadable gibberish in C and PERL, but ALL (almost) LISP programs are unreadable gibberish.
... 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
I worked for three years on a medium-sized telco project. It started in Java, and kept growing.
Due to management decision (they did not want to invest in a proper RDBMS until the system reached a "critical" size) we had to persist most of the state of the system in a series of small files, organized in directories and subdirectories. Files were simple key/value sets, in plain ASCII text.
It worked fairly well, because we were able to react to changes and new requests fairly fast, and by leveraging the various Unix text-processing utilities we could create simple scripts for quick and dirty statistics, reports and so on.
When the dataset started growing we decided that plain shell scripts were not enough anymore (especially considering that the developers were not very fluent in Unix scripting). We did a brief survey, invested in a couple of books, and started using Perl to supplement our needs.
It worked very well. Most of the utilities were coded in Perl (or recoded to substitute the original scripts), and it proved invaluably useful to finally migrate our data to Oracle when management finally allowed use to move on.
I've left the project, but I still keep in contact with them, and for what I understand Perl is still used alongside with Java. The rule of thumb is that the main application is completely Java, but everything else (i.e. utilities, DB maintenance, ad-hoc reporting) is done in Perl.
What we did from the start is to always keep the two things clearly separate, and use the data as the only interface point between the two languages.
Our experience has been mostly positive, and Perl proved to be easy enough to learn/use for our needs (nobody claims to be or have become a Perl Guru, btw).
I'd be wary to use more than 2 languages (we even minimized PL-SQL usage for exactly this reason), though. And I'd prefer not to intermingle them as the original poster seems to do on a regular basis. I'd really prefer not to invoke processes written in "X" by a process created in "Y".
Our Perl stuff was either invoked by command line or launched by cron. Our choice could have been influenced by problems in invoking external processes in Java, but all in all I am very satisfied by the choice we made, and things worked well enough for us.
One of the problems we had was the fact that we never found a good IDE to work on both Java and Perl (on Solaris). The best bet would have been (IMHO) VisualSlickedit, but the expense was vetoed by the management.
(Yeah, I know, we should have used EMACS...)
This was not a major showstopper, but I think it would have been nice to be able to check, say, usage of a constant string like "OPEN" in both Java and Perl sources at the same time, from inside the same tool, in case we wanted to replace it with "UNPROCESSED" or "PENDING".
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
then theres the database management too!
I can't imagine delivering a successful product to our customer without using some sort of scripting system (Perl preferable, but cshell works too) to manage all those applicatioins and keep everything running together happilly
As for the DB stuff, SQL*Plus with the ProC compiler has been awesome. So theres another case of a happy fit
As a c++ coder who specializes in Oragle SQL, I find sql*Plus a pefect fit
Also, I use cgi/perl scripts to manage the web pages and sometime even some XML. So I say, yes, you should use multiple languages if it makes sense for your project.
~WBGG~ "And I'm so sad like a good book I can't put this Day Back a sorta fairytale with you" ~Tori Amos
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
This was very funny the first time it was posted a couple of weeks ago. Now it is just boring.
This approach is to my knowledge more
and more used in science nowadays :
for instance, use well established
linear algebra or computational chemistry
routines in FORTRAN (which I never
saw mentioned in the discussion,
although it is a typical example of
a powerful high and low level language that
many people - rightly- want to keep at large)
and fancy graphic stuff in C/C++, scripted
by Tcl/Tk, perl, whatever.
Google passes Turing test : see my journal
Guys, can we please have a YHBT. YHL. HAND moderation option? I can't mod this post otherwise...
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++!)
How else are programs ever written then in pieces?
When you compile with C you make an object for
each source file. Technically that is as many programs as source files.
Your question shows you as a junior person in the software field.
Your lack of understanding on systems and software is clear in that OF COURSE systems and 'applications' are always written in parts. That is the client/server model.
Maybe you should look at some UNIX shell scripts and see what I am talking about. Why do you think that pipes were invented? Code has always been written in pieces as tiny apps all the way back into the dark ages of the 1970s.
Go back to school and listen this time!
the choice of langauge is like the choice of hammer for a carpenter. Do you ask a cabinet maker what kind of hammer he uses? It is the final product that matters.
When computers had low memory, programs had to be swapped in and out. And so, of course, they were ALWAYS written in pieces. It is a tribute to your lack of education that you would think that they should be monolithic. ABSOLUTELY NOT.
Monolithic code is a tribute to shrink-wrap code. It is good to protect the vendor and copyright owners, so use it for that. But for anything that is for the long term legacy of software should be broken into pieces and presented as tight and useful modules. Anything else is a kludge.
Is there a book that tells this? It should be obvious to anyone but a novice! Even Microsoft gets this which is why they have DLL.
Or, how about this, why don't you go to a LINUX box and read the man pages of the *.a archive files, their theory and use.
Have GUI builders really made programmers this stupid for this kind of topin on Slash DOT?
One more point: If systems aren't designed in pieces (and who cares what language the pieces are written in) then the WHOLE THING needs to be redistributed if a small part is flawed. do I need to say more?
You've uncovered my old secret of productivity. In dinosaur times when my group was using AT&T unix with Bourne shell and C (not C++) I would crank out instant solutions with things like
s=system('grep Mycod data.txt | tail -1');
On a related note, Leo Chin of DEC told a class of programmers "Secret of productivity you find where somebody did something like what you want to do and make it do what you want." A wise man, Mr. Chin, but it took a while to adjust to his Chinglish (or would that be Englese?) syntax. His advice is even more meaningfull in these days of Open Software and the FSF.
Every API is a langauge.
:-)?
I think the difference of opinion is around when a language is a general purpose programming language or not. I seem to remember one definition of a 'proper' programming language used to be whether you could write a version of either a compiler or interpreter for that language in itself (e.g., could you write a VB program that reads VB files and executes them?). These languages (C,ASM, Java, COBOL, VB etc) can be used pretty much interchangeably, in as much as any program written in one could be written in any other (it may take considerably longer, or run considerably slower, on one than the other, but the same overall task could be achieved in any of them).
Languages like HTML, TCP, modem AT commands etc, however, are rather specific protocols that do (usually) one specific thing, e.g. transmit data, display screens etc. I'm reasonably sure that you could not write a tool to display html pages in pure html, or write a data transfer interepreter in TCP.
The only true OS/Langauge that I know is Forth. The editor, OS, & language are parts of the same thing.
Never used Pick then
PHP sucks as a batch language. We need to generate tables and searches. We use C++ and SQR for batch work/update. We use SAS for reporting. PHP and PL/SQL work well for web applications although PL/SQL appears to be slower than Christmas coming to a 5 year-old.
The more I use PHP, the more I like it. But even in web applications, I need some background threads running.
BUT JUST WAIT FOR C#!!! Things will run faster, colors will be brighter, whites will be whiter and THE SOUTH WILL RISE AGAIN!!!!
If you aren't part of the solution, there is good money to be made prolonging the problem
Java is simply unsuited for some things by virtue of its JVM. It eliminates many of the power pieces that your OS may provide.
I have a wonderful example that would be best served with a shared memory segment and a couple of semaphores, routine things I've done in C or C++ that simply can't be done routinely in Java.
There's also the JVM memory limits. My web app is also routinely running out of memory at the default JVM settings. We've had to push the memory settings up and up to make sure the thing stays running. I simply hate the idea that when there's memory out there I can't simply use it. I've got to stop and reconfigure the app server and start all over again.
Also, for apps that routinely go through large pieces of dynamic memory allocation, the JVM's garbage collector simply doesn't keep up. It's nice to not have to worrry about freeing allocated memory, but dammit, when I want that memory freed I want to do it and know it's available again. Someone needs to give me a JVM with a free method as an extension.
For these reasons, and probably a few more, Java IMHO is not suited for large scale server processes.
- Sig this!
Don't you fools realize that any significant system -- not just your retarded pet projects or homework assignments -- is almost always coded in multiple languages? Different tasks, different tools. Complain about the "skill set" or "maintenance issues" after you get a real job and know what the hell you are talking about. Get some experience, get some wisdom and then -- oh wait, you won't be reading this site after you do that. Never mind.
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
Well, if you're that professionally diverse to be able to handle that many languages THAT well, I am sure your company will pretty much be forced to keep you around. Either that, or your team is pretty well set for life. I'd be surprised that this would stay a living entity for long.
In my experience, IT managers are becoming more and more tech saavy (although probably a bit slighted by tech companies one way or another -- i.e. MS vs. Sun vs. Linux). Eventually, someone with buying power is going to look at the support mish-mash and cut you out like yesterday's rotten grapes. In my book, its best to become the best at one or three core languages and stick to those until they are dead in the water, and even then, keep tabs on those old languages. Who would have known two years ago (1999-2000) that COBOL developers would be in such high demand.
Maintainability of the app is also core. Sure you developed it, but for who and how will it be supported. If you're a consultant, you're probably releasing this into the wild to be supported by near non-tech saavy people who at most will use the app and do basic monitoring. If you are developing in-house and supporting it locally, you might be able to afford such "advantages" as multiple languages might afford.
In closing, remember Perl's motto... "There is always more than one way to do something." If you find a language that cannot live up to that credo.. maybe its time to look for another language?
In fact, this is how much of the OpenVMS operating system is written (facilitated by the fact that the OS has a Unified Calling Standard such that all system calls and data structures are uniformly available from any programming language). The OS and its libraries were written in a mix of C, C++, Pascal, BLISS, Macro (a sort of processor-neutral meta-assembly language), and FORTRAN, although much of it was rewritten in C to facilitate the VAX to Alpha port (and now the Alpha to IA-64 port).
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***
There is something so wonderful and beautiful about writing a suite of small apps to replace a singular large app.
We are currently in the process of converting a monolithic C++/VB project to several small C++ applications glued together with Perl and using wxWindows as the new GUI. All of the code relies on STL instead MFC now, and in factoring the jobs of the software, we have been able to bring order to the code, thus making it much easier to maintain than before.
I have noticed that some of the comments posted here indicate such factoring may complicate things. Perhaps, if you don't have programmers fluent in Perl, but for us, the opposite is true. Things are much simpler now. Compile time is greatly reduced in our situation. Instead of sitting on our butts waiting for the monster to compile, we wait only seconds for the small section to compile. Also, code is reusable without having to recompile at all; simply link it to a new project, and there you go. The automation layer has been eliminated, and thus our code base can be recompiled easily for *nix and Mac platforms. Perl is so very powerful for linking small programs together, and if it not for the sad fact that Windows pipes are a joke, well, don't get me started...
Featuritis is the bane of the programmer
so for four fucking years you have listened to gay rock - isn't that saying something.
come on you bitch.
Where I work, that is called bad engineering and will help you lose your job (not keep it).
- 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
When I write stuff at work, a lot of the time most of the code is application-specific; Mentor Graphics AMPLE script, for example. That is augmented with shell scripts so I can awk and grep the text output to give my engineers some readable reports. When things go beyond what these tools can accomplish, I fire up gcc.
Another PC board design tool I support runs on Windows and uses VB as its scripting language (eww!); for that, I have DOS ports of gawk, sed and grep, and of course gcc. They have added VB extensions for interacting with the internals of the design tool but BASIC just doesn't cut it when you need to parse text for handling funky reports.
I suppose I'm not your usual developer, but it breaks up the day.
- the Insane Multitasker
"A generation which ignores history has no past and no future." -- Robert Heinlein
Eiffel does not deserve to be lumped in with your other selections.
Any PHB that was intelligent enough to allow Eiffel to be used is worth keeping.
Eiffel's approach to OO is the best I've seen yet for an imperative language. I highly recommend reading Bertrand Meyer's "Object Oriented Software Construction, 2nd Edition". It will make you a better programmer even if you choose to stay with a more mainstream OO language.
Eiffel has received a bad reputation in the past for having slow compilers, and even slower, fat executables. This is all in the PAST though. The latest batch of compilers are very fast and generate fast, small code.
What difference does changing languages to most of you mean? 99% of everybody I see write a program in any language, writes C. I have seen hundreds of self-proclaimed "real Scheme hackers" use a dozen local variables in function; complex state is their definition of incredible code. I have seen even more "Perl gurus" write C with line noise, not understanding the unique features of perl that make it almost a concatenative language at times. I cannot count the number of C++ or Java twirps that have never seen the simple "TheEmptyTreeNode" as control-flow (or even worse, the ones that think it is poor style) -- these are usually the people that have never thought of the idea of removing explicit control flow from their code. Has everybody forgotten about the idea of constant data and as little state as possible, keeping with the Knuth maxim of code being as simple as possible (but no simplier). Has C wedged everybody's mind into thinking that every segment of code must be littered with control statements. Here is a challenge next time you code: write the code with as few control statements as possible, using every idiom you know and trick you can think of to remove all the if, switch, for, while, do, and related from your code and try to treat everything generically.
As much as I have a love-hate relationship with a certain APL derivative, they have the best programmers I have ever seen. They don't worry about performance, except when needed (and they have some extreme views of what is truly fast). They use a few big generic data structures and operate on them uniformly; they do not litter the landscape with a thousand different structures (that are all mostly similar and should be handled the same anyways). They write very terse code, where one screen of text can tell you the entire picture; nobody has to page through 30 pages of code to understand even the most complex operations. Why cannot more programmers be like this?
I'm working on a project with a server written in C++ that uses XML to communicate with a Java client.
I wrote a lengthy Perl script that parses the C++ classes (whose instantiated objects are transmitted via XML), and generates equivalent Java classes. This allows autogeneration of the Java classes whenever the C++ classes are tweaked.
The Java classes can parse incoming XML and populate themselves accordingly. They can also generate outbound XML. There are setters/getters for all members.
No one at my company has ever seen this done before.
Blue
I tend to use C++ as my main language, but when it comes to mixing languages, Python is always at the top of my list, and I recommend it always, especially when dealing with multiple inheritance, or parsing.
"Journies lead to knowledge but Passion Lights the Way"
~=NeuroMorphus=~
python >>>
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))