Slashdot Mirror
Hope For Multi-Language Programming?
chthonicdaemon writes "I have been using Linux as my primary environment for more than ten years. In this time, I have absorbed all the lore surrounding the Unix Way — small programs doing one thing well, communicating via text and all that. I have found the command line a productive environment for doing many of the things I often do, and I find myself writing lots of small scripts that do one thing, then piping them together to do other things. While I was spending the time learning grep, sed, awk, python and many other more esoteric languages, the world moved on to application-based programming, where the paradigm seems to be to add features to one program written in one language. I have traditionally associated this with Windows or MacOS, but it is happening with Linux as well. Environments have little or no support for multi-language projects — you choose a language, open a project and get it done. Recent trends in more targeted build environments like cmake or ant are understandably focusing on automatic dependency generation and cross-platform support, unfortunately making it more difficult to grow a custom build process for a multi-language project organically. All this is a bit painful for me, as I know how much is gained by using a targeted language for a particular problem. Now the question: Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"
The more languages, the more of a pain for support, debugging, and dev hand-off. If the solution is going to make money, make time to think of how you can grow the business (I.E hire developers and develop a position description). Things in this perspective get ugly when you have 5 components developed with 5 different languages.. - SPT
You need to go no further.
Python gives you the Rosetta stone for a project combining any other languages you'd like.
It is a very high level development language, and does have a vast common library, able to "talk" tens of protocols, you can call directly any module compiled into a dynamic library with the CTypes module. .net? Ditto - there is ironpython! .CPP? Use libboost or ctyypes to interface python with the .cpp, and soem xmlrpc to talk with a module in the JVM (oh, it would take you 10, perhaps 12 lines of code to write two methods in python which use the standard library to talk back and forth between both running enviroments.
Also, if your application or parts of it run in the Java VM, no problem, python is there in the form of "jython", enabling you to use this dynamic, multi paradigm and interactive language directly from inside the JVM, with all its standard library, plus full access to any java classes you have in there. Oh..you do you use
Ah, you need to exchange data from parents of your app in the jvm with native code in
Plus, connectivity with the automation interface of hundreds of other software - including OpenOffice, GIMP, Inkscape, all of KDE software through DCOP (kde 3) and DBUS (KDE 4), easy communication to any windows software which does havea COMM interface - and, it even works under GNU/other unixes - just run your windows app and win32 python under the wine emulator (the apps "think" they are ont eh windoews, but sockets and network ports are on localhost across windows and native apps)
Anyway -- too much to try to write in such a shrot space. It obviously have all you are askign for and certainly goes beyond that.
And, pronably you don't know Python yourself , or you would not need to ask such a question - souyou might have the impression itr is a "script" language jsut like some dirty linear scripting tools around one have to sweat a lot of hacks to insert a "for" and a "if" statement. Not such. It is multi paradigm and de-bureaucratized, but it supports a full OO model, written in from scratch, not shoehorned in a later stage of the language like happened with PHP or Perl. Everything in Python is an object. Even integer numbers, and it can give you more flexibility with your classes and objects with features such as meta-classes, computed properties, and such than the majority of OO languages out there.
And before one says "ruby", just a thing: "readability counts"!
-><- no
Well, this ain't going to be a Slashdot pleasing answer, but .NET would seem to be the best environment for multi-language programming.
There are also a number of languages that work in for the Java Virtual Machine. There's Groovy, Scala, Jython etc.
You already know one philosophy. You don't "unlearn" it by learning another. You just learn more. Gain experience!
meh...
In my 23+ years of professional development, administrative and engineering roles, I've found that you stick to what you're best at, and learn new things in between...
Unless the command prompt disappears, there will always be shell-scripting and that strung together happiness of well written, single-purpose shell scripts doing their jobs together as though a well orchestrated symphony.
Becomes a real problem if the multi-language thing is more or less "You use what you like." So you get one dev who likes some obscure language and uses it for his little part. Everything works well so nobody cares. Then he leaves for a different job some day. Time comes around to update his part... and nobody has any idea how to. None of the other staff are skilled in that language. Now you are in for a world of hurt while that gets sorted out.
Multiple languages for their own sake isn't a good idea. Any time you choose a programming language for a project, there should be a reason. That includes the initial language, but certainly applies to any other languages also used. For example suppose you have a web package that's written in Perl. You chose it because your package deals with a lot of text processing and Perl does that well, and also because your target platform supports Perl. Ok, good choice. There are other legit choices, but that's a fine choice. Now you have a client app that goes with it. Perl doesn't work well for that, so you choose C#. You choose that because the client app needs only to run on Windows, isn't speed critical, and needs to be easy to develop a GUI for. Also a good choice.
However you then decide to add a new feature to your server side of the program. You chose Ruby because it is new and seems neat. Bad choice. The server portion is already written in Perl, why add a new language? The "Because it's neat," is a horrible reason. Will Perl not do the job? Then why add more complexity.
Just sticking in new languages at semi-random on a project will do nothing but make it much harder. If there's a real compelling reason to have multiple languages, ok then great. That certainly does happen. However just saying "Let's use more languages for fun," is just setting yourself up for hard times.
If I had serious text processing, I'd use Perl. And do.
Graphics means using a well supported library, so Perl/Tk is the better choice than Java/Swing.
Um...I do not think "well supported library" means what you think it means. Tk is old and crufty. Swing isn't much better, but if you're doing graphics you're almost certainly doing it with SDL or some other accelerated system, and you wouldn't use Swing for that either.
Tk is not as old and crufty as you think. It has been updated allot recently
Java/Swing actually has a very fast fully accelerated OpenGL drawing pipeline that is even supported on Linux. And yes many graphics heavy applications are buildt using Java/Swing The problem with swing is that it takes some heavy study time to learn how to do it correctly and not make your interface suck. But done correctly Java can keep up with most things out there. It's the done correctly part that is hard.
In my experience, using multiple languages in a project will force you to write sizeable amounts of glue code. These processes will have to communicate one way or another and they all have their particular way to do so. So, your glue code is often not that simple but deals with interprocess communication for which a protocol will have to be devised (could be simple, but nevertheless).
Now if that was all, then so be it: write glue code. However, I found most programmers do not heavily check for errors in their normal code, where you have things like exceptions and return values at your disposal.
This becomes much worse when doing interprocess communication. The normal language constructs aren't there, you're communicating using a self-defined protocol. Often this is invented on the spot and does not include a proper way to catch errors and deal correctly with them.
So in my opinion: don't shy away from using multiple languages, but remember that you need a decent amount of time for what could be quite complicated glue code.
8 of 13 people found this answer helpful. Did you?
And the main problem I have found with young guys is they have absolutely no appreciation for talent and can't stand it when they are in a position to hire because quite frequently it eclipses their own by an order of magnitude (that's a gross generalization, of course, and not always true). But the by far the biggest problem I have found to be more and more true these days is that some kid manages to get himself hired because he has a degree in java, manages to keep his nose clean and then gets to hire more talent as the project gets bigger and in most every case they turn down anyone with a vastly superior skill set that was born more then 3 years before they were because they prefer a quiet well lit office that doesn't stink of BO and stale junk food. I might be wrong, but somehow I doubt it very much.
Now you are probably thinking, "Must be some old fuck" and you would be right I am part of the over 50 crowd who has a very current skill set and has 30 years of programming experience to back it up. I am a consultant and I am frequently hired by CEO's and CFO's who are at their whits end with the "kids" that got hired by the other kids that got the job then decided the lights were brighter and more sparkley someplace else after talking management into using the latest and greatest hair brained library written in a language that uses tabs for scoping.
Mostly what I am is a janitor, a very very well paid one, but a janitor never the less, cleaning up messes left by kids.
Don't take offense because one of these days you (if you are any good) will be doing the same thing in 30 years and why? Not because you "need" the money but because you, like me, will hopefully have some ethics about our craft.
Hey KID! Yeah you, get the fuck off my lawn!