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?"
do not sweat it and enjoy! (Score:5, Informative)
The world ebbs and flow. One day it C, another RPG or CL or ADA or PHP or ...
Do what you like to do.
What you may want to, is join a project that is more inline with Linux as whole versus a single app. Ubuntu or another general distro, or help with a small single use distro like IPCop. They should be glad to have some one like you help out.
Eclipse (Score:5, Informative)
Eclipse is a fantastic platform for multi-language development, especially if your primary languages are C, C++, Python, Ruby, etc.
All you need to do is create a C++ Makefile Project, then use the makefile to wrap your build system (e.g. ant, scons, actual makefile, whatever). You can build any number of binaries and launch them (or scripts) from the powerful launch profile system.
Basically, Eclipse projects have "facets" - they can cram in features from multiple language development kits and mostly remain compatible. You still sometimes have to do the glue work yourself, but in general C/C++/Python are very easy to mesh. It is therefore easy to have a project with C libraries being loaded by Python, and so on.
Re:Languages (Score:4, Informative)
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.
Bzzzt (Score:1, Informative)
Re:Do both. (Score:3, Informative)
Re:So you want to learn object oriented now? (Score:2, Informative)
I would read it as sarcasm. Try reading this manifesto [pbm.com] and updating Fortran to C to account for 20 years of shift in the industry. Anyone not using C is just eating Quiche.
Although his joke went over your head, it is worth pointing out that OO is not a paradigm. I know wikipedia thinks that it is, and so do a hoard of practically illiterate researchers publishing crap papers in junk conferences. But that doesn't make it true. Object Orientation is just a method of organisation for procedural languages. Although it helps code maintenance and does a better job of unit management that modules alone, it doesn't change the underlying computational paradigm. I say procedural languages because class-based programming in functional languages is actually a different type of beast although it gets called OO to appeal to people from an imperative background.
Re:Languages (Score:5, Informative)
Re:Cross platform programming and multiple languag (Score:1, Informative)
Interesting. I am an experiment physicist myself, although I have spent my recent past in the pharmaceutical industry.
My first analysis programmes were a mix of FORTRAN and MODULA-2. A bit exotic perhaps, but it worked well enough once we had figured out the calling conventions. However, it was hard to port when we moved from a VAX/VMS mainframe to Ultrix workstations. Digital had a tool to convert binaries, so we actually compiled on the VAX and then converted the binary for Ultrix, instead of properly porting it.
In the 1990s we moved to (much cheaper) Linux machines, and then I too opted for a mix of Tcl/Tk and C, although I later converted most of it to Tcl and C++. I didn't see any reason to prefer C to C++, although it is probably best to use a subset of C++ features and avoid environments like Visual C++ -- I usually worked with g++ and a good editor. The problem with Tcl was that the code became difficult to maintain as the project grew, because IIRC it didn't even have namespace support at the time.
When I moved to industry I found that my colleagues had adopted a mixture of LabView and C. LabView, at least in that version, turned out to be an even worse choice for integrating a complex system, to the extent that it was easier and quicker to modify the low-level libraries than to modify to high-level wrapper code. I preferred to replace the C part with completely new code written in C++, rather than attempting to correct the bugs in the LabView code.
Today, if I had to do it again, I would probably rewrite most of it a mix of Jython, Java, and C. I think that is more or less the state of the art in this industry, offering a good compromise between performance and flexibility. Typically Matlab or R are thrown in to handle more complex analysis of images and numerical data. For remote calls, people usually try WebServices before they decide that these fall far short of meeting performance requirements, and then they either improvise something or opt for solutions such as Zero-C ICE.
However, in my current working environment language choices are made at some stratospheric management level, instead of by programmers, and they decided to do everything in .NET because MS gave them a good deal and any software a righteously minded person could ever want :-/ I don't particularly dislike .NET, but there are several good reasons not to do this.
C++ and python (Score:2, Informative)
Re:And where did you learn this "philosophy"??? (Score:3, Informative)
Re:Languages (Score:3, Informative)
Forth is more like a RPN programable calculator on steroids, it's stack based and used more for embedded systems, but I haven't looked at it in decades. In it's day it was used in 8 bit PC's to replace BASIC as a programming language.
Re:StupidPeopleTrick (Score:2, Informative)
That depends on the complexity of the languages.
A Bash script that invokes awk uses two "swallow" languages and is going to be a lot simpler than some crazy conglomeration of, say, C++ and Perl.
Re:One time..... (Score:1, Informative)
That's funny, I'm 24 and I spend most of my time at work cleaning up horrible code written by people older than me. Talent--or the lack thereof--shows up at any age.
Re:Buzzwords (Score:3, Informative)
If you're looking at it organically, you are understanding as much as you can at first, doing a little functionality, hopefully delivering it, then moving on, getting small wins, and the system gets more functional over time... naturally.
In the former approach, you are doing all the planning when no-one has the faintest idea what needs to be actually done. In the latter method, you are doing small, incremental, plans right before you start working on a component, when you have the most information possible, and you are dealing with specific clients for specific requirements.
Organic: not just for produce any more...
Re:Yes, .NET may actually be the best bet (Score:4, Informative)
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance? Or how are you going to map classic objects with modifiable state to stateless, side-effect-free languages like Haskell? I'd imagine that that's not going to be pretty, no matter what the underlying runtime can supposedly do, because the unpretty-ness is a function of the semantic gap between the languages themselves, not of some feature set (or lack thereof) in the runtime.
Yes, of course. What .NET really did was to standardize on some common feature set and model. Languages are still pretty distinct, and e.g. F# has a lot of stuff that simply doesn't map well to anything in C# land; but they have some common ground, and that common ground is much more high-level than what we had in C. What more, this approach is extensible - they needed to add dynamic languages such as Python and Ruby in 4.0, and the existing conventions did not cover that, so DLR was born; and now C# and VB are also moving to it in the next release, and any other future dynamic language on .NET likely will, too.
This comes at the expense of languages themselves having to support that common model. For some it's natural, because they were designed around it - see C# and VB. Others - C++ and F# - are different, and they essentially have to add some subset specifically for dealing with that model; so e.g. in C++ on .NET you still have full power of ISO C++, and it does compile to CIL bytecode, but it's unusable from other languages; and then you have C++/CLI, a set of language extensions that allows you to create and use CLS-compliant types. That separation is very distinct and clear. With F# it's somewhat more blurry, but even so, there are some clear differences between the traditional FP constructs that are F#-specific on .NET (ADTs, curried functions, and tuples, for example) - which don't map nice to any other language; and the F# object model, which pretty much follows CLS closely, with only a few twists.
On the whole, it's hard to say it's a perfect approach, but it certainly provides for better multi-language interop than the traditional C FFI solution. Pragmatically, it works.
Re:One time..... (Score:3, Informative)