Hope For Multi-Language Programming? 371
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?"
It's a big umbrella (Score:4, Interesting)
You can do either. Either way you gain and lose. I personally have a hard time with the kitchen sink approach, preferring C as my programming environment. This leaves me in the cold as far as contributing to, say, mythtv, but then I can contribute to other projects, like lirc.
So it all comes out in the wash. When you come to a fork in the road, take it.
Depends, really (Score:5, Interesting)
Not really "tool based" programming like the unix stuff that was mentionned...but for example where I work, they combine languages. Our .NET stuff will be a mix of raw intel assembly, managed C++, C#, and F# for the algorithms. Mixing purely functional languages with procedurals languages with some functional features seem to be gaining momentum in algorithm heavy fields.
Then there's the occasional java program that will invoke perl scripts for jobs, for example.
Its definately there for large projects. Its just that with the power of more modern environments, the projects have to be MUCH larger before they start warranting to take the overhead of mixing languages/tools to gain efficiency. The extra tools, testing, integration, installation, dependencies, etc that are involved are not worth it for "small" projects (and again, by today's definitions, a "small" project can be quite large, hehe)
One time..... (Score:5, Interesting)
As for the question, I think in part he's right, it is good to have a separate mailer from the browser from the calendaring program, and have ways for them to communicate. Some systems do work in this way, for example, most chess programs will let you change your chess engines, separating the front end from the back. Might want to check how they do it. Other programs on OS X will let you manipulate variables and send messages using applescript or automator. Also, on OS X, there's no reason to not use awk or sed. But definitely learn C++ and Java, they're used everywhere and once you know one, the other's not too difficult.
Maybe if you were more specific in the question you asked we could answer better? Or were you just trying to encourage all programmers on slashdot to program more modularly?
Don't understand the premise (Score:3, Interesting)
I am an IT consultant for a large software vendor. In the last 5 years I worked and developed in Python, JScript, Perl, XSLT, SAS code, SQL, Java and Shell scripts. While it is true that big software packages are usually developed with primarily one implementation language it still holds that to glue things together in an enterprise setting a plethora of languages can still be deployed. I often find that I have the freedom to pick the best tool for the job.
Language free protocols are abundant, object communication often facilitated via XML or JSON. Even on Windows the Scripting host has been around since NT - JScript and VB are natively supported and pretty much any other interpreted language under the sun can sit on top of it. And then there is .Net which has even escaped the confines of Windows.
Just as with human languages the more you mastering the merrier and I find that small is still beautifull.
Yes (Score:5, Interesting)
Should I suck it up and learn to do all my programming in C++/Java?
Yes.
In my 10 years of professional development I've covered many languages, but the last three doing nothing but Java have been the happiest. The second happiest was doing nothing but C++. There's a wonderful economy of scale to focusing on a single technology, you don't waste time on the glue.
Heh. I'd love to pick an environment (Score:4, Interesting)
I'd be even more productive, if I could just master "one thing". As it is, I have to use C, C++, C#, sometimes VB, perl, csh, bash, html, ASP.NET, AJAX, Qt, oh, forget it.
I do ok, doing everything, jack of all trades, and fool at none (or something like that), but I have a nagging feeling that I'd be a GOD if I could concentrate on just one... or broke.
Oooh, shiny! (wanders off)
Cross platform programming and multiple languages (Score:5, Interesting)
Ok. Im not a CS genius, and a matter of fact i am seeing this from purely practical point of view. I am a experimental physicist, and as such i program measurement and evaluation software. I always (at least since 1999) work cross-platform, which means that all applicable parts (e.g. if i dont hav a daq driver for linux, then obvioulsy the application will have no daq) of my applications run on linux and on windows, be it just for easier testing.
My experiences which worked turned out to be pretty much the generic one you would expect
a) Use ANSI C (not C++) for the vectorized operations and interfacing to the system level
b) use a cross-platform scripting language (in combination with SWIG). (tcl, python, jython)
c) If you feel like it, use java.
d) If you can affort it use a already existing Framework which does what you want (in my case: matlab)
e) Refrain from anything platform specific, unless you have to use it.
My best experiences in terms of multi-language+multi-platform where
-tcl+C (Since i started to use tcl in 2007 i always wondered why i did not do that earlier. tcl/tk is lean, easy, fast and
quite stable)
-java+jython+C
Re:Depends, really (Score:5, Interesting)
I was introduced to functional programming via C# 3.0, with the lambdas, LINQ, and better delegate support. Not quite "real" functional programming, but its a nice gateway drug, and have been hooked since then (thats background info just to say I'm no expert, but no dummy either).
F# is pretty slick. Its basically a "real" functional language, that still allows it to be easy to integrate with "real business", including databases, IO, and has great support for tooling since its based on .NET. So its pretty much the "perfect" functional language, for the "real" world. (I know many are better from a theoretical or scientific point of view, but i'm talking purely pragmatic here).
That said, I didn't use it much. What I can say, is we have an army of PhDs implementing -extremely- complex algorithms here (functions being passed around with several douzens levels of nested function types, to do very, very complex modeling in a couple lines of code...), and they swear my F# now (they've been using it since early technology previews, and are getting ready to push large amounts of code in it in production...its working awesome, supposingly).
Sorry I'm vague on the details... but what I can say, is its good enough for one of the largest linux-centric company in the world to shift some of its code to it. Nuff said :)
Shell scripting + Python works for me (Score:4, Interesting)
Don't do it, but support it. (Score:3, Interesting)
Your "Unix Way" is a wheel that's being reinvented as SOA, etc.
Here's the thing: It is possible for one language to be good enough for nearly everything, especially if you pick one with good support for internal DSLs (I like Ruby). Also, while message-passing is a good idea, it's usually slow, and you probably don't want to be designing your own text-based format every time.
Now, you're still going to have DSLs and whole other languages forced on you, occasionally. For example, JavaScript is still the best language for AJAX clients, simply because no one has written a better language that compiles to JavaScript. (That's relative, of course -- if you like Java, then Google Web Toolkit will be perfect.) In fact, with web development, you'll want JavaScript, HTML, CSS, and probably another language (Ruby, Perl, Python, PHP, etc), and SQL, all in the same application.
But, each additional language is that much more for a newcomer to learn, and it's that much more glue. If you communicate with text, how much time are you spending writing text parsers instead of your app?
Of course, ideally, you provide a language-agnostic API, because you may need this application to interact with others. You might even find yourself writing multiple applications...
But the other big win of a huge application is the UI. The Unix commandline has made mashups of many small programs as easy as a pipe character. There's really no equivalent for the GUI -- users will relate better to one big monolith, even if it's just a frontend for a bunch of small tools.
So, I would split application by the UI concept, and share the small, common utilities via shared libraries. That's not far off from the Unix Way, either -- it's not hard to write a small commandline app with a shared library, if you find you need it. It can be annoyingly difficult to go the other way -- for example, Git bindings aren't as easy as they should be.
Babel project (Score:3, Interesting)
Seriously, they're trying to make multilanguage projects possible (if not easy). Ever want a Java object to inherit from both a Python object and a C++ object? Then Babel is your tool. https://computation.llnl.gov/casc/components/babel.html [llnl.gov]
Re:Do both. (Score:4, Interesting)
I don't think that's entirely true. I find the more languages I know the more times I accidentally write a statement from the wrong language or pause because I mix up the syntax in my head and have to remember which was which. There are more erroneous paths for neuron signals to travel down. I congratulate you for having a photographic mind, but we are not all that lucky.
Re:It's a big umbrella (Score:3, Interesting)
I agree, I've done both a lot of shell scripts, web scripts and compiled languages programming; it all comes down to what your goal is, there's no perfect combination of languages for every scenario.
Personally I prefer having a core program written in a compiled language (C++, D), with a bundled library for scripting (LUA, Python) for I do mostly cross-platform programming these days.
However, when doing system admin tasks and automation, nothing beats shell scripts, it takes too much time to write and maintain compiled executables for simple tasks.
On a side note: I also recently found out about rdmd [digitalmars.com] a few days ago, you might want to add that to your shell's arsenal ;)
Re:Depends, really (Score:0, Interesting)
the text was always the customization of optimized and specialized c code. the ratio of script to binary was always very small. and most of the text (for perl) quickly compiled into large swatchs of native c library segments. the power of the unix model was the ability to adapt it.
it wasnt that you had programs piping large volumes of text around. it is more often void main return values and signals or the occasionsal 1 line of text returning from highly cached microprograms. yes there is tremendous overhead in invoking those apps, but they are almost always the startup process.
consider that the windows alternative is vb + COM libraries (in mem shared library + state references). that is all fine and good for efficiency, but my experience is tremendously less stability. consider the com equvalents in linux. kde and gnome. yes you can use them without persistent services - but we dont. so instead of highly stable single processes that use locks and file based resources, we have buggy interdependent code. one process hang takes down a bunch of services. i have to kill 3 processes every time pidgin locks evolution-data which locks evolution which locks beagle and tomboy notes. this happens daily when i have integration enabled. If they stuck to the old way of a few rpcs and direct file accesses and maybe a few named pipes then life would still feel like unix. But noooo we have to be windowsy.
Re:One time..... (Score:3, Interesting)
My suspicion is that anyone who's been around that long and who has all their marbles in a row doesn't need to look for a job very often. They are either rich, in management, or have connections.
gphnzykrzwki (Score:4, Interesting)
Re:Languages (Score:4, Interesting)
For many years now I've successfully developed with a multi-language model in Windows...
I do my low level code in C++ and encapsule it in a COM/ActiveX object, which I then can call from a Javascript script launched by the OS (through WScript.exe), server-side ASP pages and client-side DHTML pages or HTML Applications (HTA files). Both the "classical" COM/DCOM/ActiveX architecture and the new .NET were made to support integration of different languages and low level and high level code.
It's also possible to integrate Windows COM components and DLLs through Python scripts.
Through this model I developed quite a number of reusable parts which in practice I was able to integrate to a variety of projects. Having this separation between low level code and high level scripting as "glue" works great for me... it forces a layered design, makes for smaller binaries and cuts a lot on compilation times.
Re:One time..... (Score:3, Interesting)
written in a language that uses tabs for scoping
This sounds like a half-baked (and incorrect) jab at Python's syntax. Sounds like someone's skill set isn't quite as current as he thinks... :-)
That notwithstanding, I also find after decades that programming involves a great deal of janitorial work. I'm trying to convince myself that this is a good thing, as it means that I will always be able to find a job cleaning up these messes. But, it does kind of suck cleaning up vomit written in Perl, C++, and (god help me) RPG...
Re:Python (Score:5, Interesting)
Just to expand on a couple of your points:
But if you like multi-language programming then Python is good glue.
If you eat your own dog-food ... You are your own end-user, although occasionally other people may pretend.
If your target user is a non-programmer, who simply wants to be able to perform a task then you will need to wrap up the functionality in a non-programmatic way. GUIs are the best way (so far) of doing this. Because there is no intention of exposing an external call interface the overhead of mapping from language to language becomes pure overhead and there is a natural tendency towards a single monolithic language approach.
Almost 100% of *my* code is python these days, but I use it glue together any number of my old scientific applications that are often written in C. You can turn an archaic, unusable program into a slick, modern GUI or web service with very little code.
Most important here, though, are your points about who your target audience is. I think the submission author is missing that point, and it deserves to be made in no uncertain terms.
I am a scientist and a programmer. When I am writing for myself, I want to spend time on my data, not my program. So, I bang something out unix style - command line only, text I/O, move on with life. Usually, that happens in Python, but it might be in C, R, MatLab - whatever. Programs from my PhD are almost strictly command line. My co-workers from that part of my life had to learn command line if they wanted to work with my stuff. And you know what? They all did. Some of them got quite good at it, and I had more than a few inquiries about learning to program - they all saw the utility of what I was doing.
After finishing my PhD, I've worked a little for a start up and a government agency, both based on my PhD research. In both cases, I've played the role of the scientifically literate programmer. My users are somewhat tech savvy, but with few exceptions, they don't want command line tools.
A few of my old tools are still in use, though, just because they do one thing so very well, and a handful of people took the time to learn them. In return, I save them hours every day, which make those few tech savvy souls very happy.
The trend - what is likely to keep me employed for years to come - is building GUI/web programs for people who are good scientists, but don't understand.
I take a hybrid approach. What my end user sees is a standard Windows GUI. They happily click buttons to find some raw data, and then their analyzed data pops up automatically in Excel.
Behind the scenes though, my code is an amalgam of programs, most of which can still be run command line, just like they always could. The GUI code is wxPython, and it quite happily runs on Windows and Linux. I think it would run on a Mac, too, but I haven't had occasion to try it yet. It looks native in all of those environments, it never does anything to scare the users, and yet I can still do most of my analysis command line when I need to.
I'm currently developing a DNA sequence database. User interaction will all be web-based, data analysis will largely be a mixture of Python, MatLab, and C programs behind the scenes. My users won't have to care how their data gets analyzed - it'll just magically show up in the form they need it. They focus on further analysis and interpretation. Given who my users will be, this is a Very Good Thing(tm).
The point, though, is that my programming spans everything the submission discusses. These approaches aren't orthogonal. Pick the right one for the code you are working on.
If you are coding for yourself or for very tech savvy scientists, stay command line. It's easier to code and debug, and you'll get more done.
If you are selling to Joe Sixpack, a GUI with a Staples-style 'Easy Button' is probably the right choice. Add advanced options as stand-alone
Re:Depends, really (Score:3, Interesting)
"That said, I didn't use it much. What I can say, is we have an army of PhDs implementing -extremely- complex algorithms here (functions being passed around with several douzens levels of nested function types, to do very, very complex modeling in a couple lines of code...)"
If you do OOP, you're effectively doing the same thing when you're passing objects around: every method and every method of every class type that those methods work on is a "level of nested function type".
Also, it sounds like they're effectively using F# to build little domain specific languages. Functional programming languages are convenient for that purpose, but the end product tends to be worse than if you had actually designed a domain specific language from scratch.
Re:Depends, really (Score:3, Interesting)
Yes, OOP is indirectly the same thing. The Strategy design pattern is just a way to implement functional-like paradigm to non-functional language.
Its still not as easy or elegant, and the compiler cannot optimize as aggressively, and some stuff will take a whole lot more code. Thats why the base functional paradigms were added to VB.NET and C#.
They're also not building domain specific languages at all. Its just the mathematical model (not model as in a DSL model, but really, as in a math one) is extensive, so the formulas are very, very complex, even when done on paper. One of primary reasons to use a functional language (aside that it goes from paper to code easier) is that its easier to prove the code afterward, which is required by law in some businesses.
Re:One time..... (Score:2, Interesting)
Re:Depends, really (Score:4, Interesting)
Very good question. I personally looked at Scala and thought it looked pretty good, but that I didn't try at all (just read the documentation). If I had to guess, I'd say its a mix of Microsoft support (which, while I know i'm saying this on Slashdot, is actually pretty damn good, and you have tons of support calls included with MSDN subscriptions, volume licensing agreements, etc), the fact that the language is just really well designed, the better, faster interop with native code (so if you have to do something in C/C++/Assembly, you won't lose 90% of the performance bonus in the interop layer), and that some of these algorithms have to be integrated with thick client software on desktop machines, as Office plugins, etc.
The last 2 are probably the biggest deal. You know for sure you can interop (well) with anything and everything, that it can run on the servers (most are Unix, and its by far the preference, but we can put a Windows server without affecting users if we really need to) and on the client integrated with basically anything. Almost anything that can be extended will support some kind of COM/COM+ or .NET interop model of some kind. Doing it with Scala is not impossible, but far more annoying. And if the F# code needs to be distributed, WCF tends to be better than many alternatives, etc etc.
So in short (and again, its just a guess. I always tend to be quite curious too when a Windows solution gets selected over a Unix one, since we're not locked in on Windows much if at all), easier to extend, and better corporate support.
...with varying levels of support (Score:3, Interesting)
I recently had need to access a large Java library from my C app, and was able to do it pretty easily (with ample help from online forums). So yes, you can embed a Java interpreter in C code.
But there's a API documented for embedded Java to unload the VM when you're done with it that turns out to not be implemented. Because of this, embedding Java means incurring a pretty stiff memory usage penalty that isn't transient.
And the 'unload VM' call has stayed unimplemented for several versions of the JRE (at least 1.4 through 1.6). So, while embedding Java in C works, it seems to have less than wholehearted support from Sun.
Re:One time..... (Score:3, Interesting)
How is this not flamebait? I have worked with young guys who don't know what they are doing, and I have worked with old guys who don't know what they're doing.
Incompetence knows no age limit. Neither does competence by the way. In your case, FlyingGuy, I would not hire you (if I were doing hiring) and it has nothing to do with your age, but rather with your bad attitude.
FWIW, I am a younger programmer and I have found two things (major generalization forthcoming). 1) The older developers have taught me very little about programming. Actually, I usually teach them how to code better. Too many of them are confused by templates and don't really know how to do OOP correctly. 2) The older developers have taught me plenty about software development. These guys know best practices, they know the design mistakes they've been burned in the past by, and they know how to spec a problem.
In other words, don't turn to the old guys for what you can learn in school, but do use them as an excellent resource for the rest.