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 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 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.
Sam ty sig.
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.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Not necessarily. In psychology, interference theory proposes that people forget information because of competition from other material. One kind of interference is retroactive interference, which occurs when previously learned information interferes with the retention of new information.
Properly written swing is fine, and i have used without complaints from clients. It looks and performs rather well with openJDK. The problem is that 99% of swing out there are by 1st year students learning how to write any code at all, let alone competent GUI front end. But it is just another gui api with all the pros and cons that seem to come with them all.
The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
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.