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?"
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 at my company, a programmer who must have been in his 50s came in with a resume that had no less than 25 programming languages. I was interviewing him, so I asked him, "Which of all these languages do you like most?" I figured he'd have some nuanced answer dealing with precision in Ada or flexibility in Lisp, or the happiness of Perl. Nope. "Shell scripting" he said. My jaw nearly dropped. He said, "It easily lets me tie all these different building blocks together. No other language can do that." He didn't end up working with us but it was one of the most educational interviews I ever did. I like interviewing more experienced programmers, even if they don't end up working for us, just because something interesting ALWAYS happens. I could tell you stories........
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?
Qxe4
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.
XML is a known as a key material required to create SMD: Software of Mass Destruction
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
I've been programming for going on 35 years and have tried a BUNCH of different languages and approaches. I'm glad I've finally settled on writing virtually 100% of my code in Python (using C only when performance is an absolute must). That plus some shell scripts seems to work for almost any project that I've come across in the last 5 years. Python brings lots of tools, good support system, etc. and I'm finding that concentrating on a single language means I'm deepening my understanding with every program I write and adding to a robust personal library of reusable functions and classes that make writing bulletproof code a pleasure. I can be VERY productive because of the high level nature of the code. It is almost like writing pseudo-code once you get a good understanding. I write for Windows and Linux (not much on the Mac). I've written Windows Services, COM objects, GUI programs (with wxWindows), as well as normal batch programs and scripts. On Linux I've written daemons, GUI programs, and background batch processing scripts. What is great is that I only need the one language. I have just never felt at home in the GUI IDE world that seems so popular with some.
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.
Table-ized A.I.
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
-V-
Who can decide a priori? Nobody.
-Sartre