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?"
Programming Languages are just tools. And, surprise, languages of the same type are equivalent.
Go study the fundamentals of CS.
The rest will follow.
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.
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)
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
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.
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
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.
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
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.
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
Sure, I'd love to pick to do "all my programming in X".
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)
This issue is a bit more complicated than you think.
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!
Quite often "multilanguage" creeps in quite unintentionally; for example, in the last 3 years, I've only worked on one project which didn't contain a significant amount of XSLT - which, like it or not, is a separate language, and quite complicated one at that.
On the other hand, with .NET, it has become a pretty popular approach in Windows land to mix C++ and C# - the former for performance, and also when dealing with messy C/C++ APIs, and the later for high-level business logic and UI; though lines do get blurred sometimes. I think the reason why it is fairly common is because it is so easy to do - you can have a solution with C++ DLLs and C# projects together in it, with a few tricks you can set up dependencies, and calling C API from a DLL is very easy from C# thanks to P/Invoke (and even easier when there's a C++/CLI wrapper) - most of marshalling chores get taken care of automatically. I think this isn't quite as common with Java because JNI is, frankly, a very inconvenient API, and pretty slow as well. Python and others are better, but you still get a lot of boilerplate code in C. Then again, SWIG helps a lot (in all of the above scenarios), and for Python specifically, boost.python is great.
Getting back to .NET, with the late additions, it seems to be going beyond C++ & C# combo now. For one thing, VB actually has some neat features over C# now, most notably language integrated XML literals and queries, so it can be used much in the same way as XQuery. This is actually convenient enough when dealing with a lot of XML that I had used separate VB projects for XML processing in an otherwise fully C# application just for that reason. Then, of course, there's F#, the newcomer that is very handy at certain tasks: text parsing - FParsec is great!; tree and graph processing; and, in general, all sorts of computations, especially parallelizable ones.
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
Gnome has done a good job of adding bindings for many languages (Python, C++, perl, etc.) and to some extent, it even allows GObjects to communicate with one another (dbus). Of course, the holy grail of having all object communicate with each other while running under their respective VM (or natively) is still a ways away. I'm not even sure if that's a goal.
It was designed to let modules written in many languages all link together in one application, so each piece can be written in the language that most suits the problem. To facilitate that goal, all language compilers create a common .OBJ format.
http://h30266.www3.hp.com/odl/vax/opsys/vmsos73/vmsos73/5973/5973pro.html
"I don't know, therefore Aliens" Wafflebox1
But no matter what platform I'm developing on, one language just isn't enough. With every project, there's lots of little one off scripts you write to perform various maintenance or deployment or testing tasks. Maybe I do too much, I don't know, but I've been doing this for about 10 years now, and I can't think of one project that used only one language, and no complete system that didn't integrate some other platform/SDK in somehow.
I'm not sure why you say that there are no multi-language environments. Emacs is a great example of such an environment (and not the only one). There are modes which let you program in just about any language in separate buffers, all at the same time.
The only valid argument I can think of for choosing a single language and sticking with it for everything is that your collaborators may only know how to program in the one language. The big danger for you in that case is obsolescence in a few years, when the world decides that your language is no longer desirable.
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.
That sounds like an unfortunate step into another layer of short-lived languages. Learn how to actually program: learn C.
Being able to create a single large product with a single programming language is a great skill, but so is being able to do Unix shell scripting.
The system/product I have been working on for the last 10 years is two major pieces that is about 90% of the total code base and lots of small pieces. The two major pieces are both essentially a single program that can be developed in unified environment. But we also have lots of small pieces that are shell scripts that are done in the classical Unix spirit.
Being able to work in both ways is a great strength for the engineers who can do that. Those who can only do one or the other are essentially marginalized as that limits what they are able to do.
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.
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.
Don't thank God, thank a doctor!
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
You started using Linux 10 years ago... yet the "monolithic program in one language" was in fact the de facto computing standard for most large programs, from the very beginning... clear back to when Grace Murray Hopper was inventing the first thing that even remotely resembled a modern high-level language.
Nothing has changed in that respect. Sure, you have more options and there is more interoperability today... and it is indeed a "philosophy" to allow such flexibility. But if you think that a hodge-podge of various scripts and languages (which is what you appear to be saying) for large projects was ever any kind of "computing standard", then you got a VERY wrong impression somewhere.
I would like to know about this "philosophy", because I have never encountered it before.
HTML, while not compiled, is not a scripting language.
I've worked on many projects in recent years have that have used multiple languages. E.g. SQL, Java, JSP, HTML & Javascript; or SQL, C++ & Visual Basic. IDEs support multiple languages in one project, and people do take advantage of that.
The work I've been doing is more component-oriented than tool-oriented, but it still comes down to using the right tool for every job.
Learn new things.
The more stuff in your toolbox, the faster you can solve problems. Yes, I know you can solve a lot of the problems you face with the tools you have. It's true you can solve any realistic problem in any Turing complete language. But would you really want to write a pinball simulation in Cobol?
Learn more languages, and you'll develop a feel for when they're appropriate. I've been known to spend a day looking at different languages before starting a project. It saves time later on.
Weaselmancer
rediculous.
Using only one language is like only using one tool. sure, you can use your screwdriver as a hammer but that's what you have a hammer for.
If you can read this, I forgot to post anonymously.
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?
Learn .net and you can mix and match between c++, c#, vb(dunno why you would want to), F# etc. It really gives you more options then anything else I know of.
Hikery.net - The best hiking site ever. Made by yours truly.
... between what you were saying and your /. .signature??? ;-)
As to the distinction between "the lowly developer" and "the wise Architects", I would say, look at the developer, and if he is any good, poor money into his own company!
Paul B.
The Unix Way is a perfectly valid method to develop administrative, text-based tasks targeting a single, well-known platform, but does not scale well toward the development of other types of applications.
First, compared to modern languages like Python or Java, shell scripting sucks. The syntax is awkward and it can only manipulate bits of text. The world has moved on from text. Today, I want to be able to process complex structures, which in many cases cannot be converted to a simple text format.
Second, modern languages have huge libraries, so usually there is no need to use anything but those libraries. Furthermore, using those libraries reduced compatibilities issues. When I develop for the Java 6 platform, I know the code is going to work on every single platform with support for Java 6: Windows, Linux, Solaris, you name it. With the Unix Way, you have to make sure that every single function of every single tool you use is going to behave in the same way on every single platform. This is of course a huge pain in the ass.
But there is no need to fret. You quote Python: from my point of view, it is one of the platforms that can be used exclusively, so your experience is perfectly valuable. Regexp are pretty much the same everywhere.
But I do not really understand your problem. If you're developing applications, you should know all that already. If your software development experience is limited to administering systems, shell scripting is always going to work for you. I guess that in this last case, you may want to try to pick a singe platform (say, Python) for all your dev needs and see how it goes.
Nobox: Only simple products.
What good are multiple languages if all inter-language integration have to be funneled through some narrow C-like basic model?
The problem is not with the languages but rather with the platform on which they are based. As long as the common denominator is C memory blocks or opaque text-serialized objects, integration is always going to be a pain.
Sometimes language pairs are supported by an asymmetric relationship (one of the languages often being C). Using objects/features from one language is usually easier in one direction than in the other. Often there are severe restrictions on the layout of objects/functions. Examples of this is how PHP can use some C based functions/objects, provided they adhere to the "PHP way" of laying out objects. Using PHP functions from C is considerably more involved and certainly does not qualify as minimalistic.
The problem is that these bindings are often just pairs, excluding other languages from richer integration. Sure, you can integrate other languages with C as well, but rarely will the object layout of one language align with the layout of another language. This makes multi-language integration a pain. Going (down) to C level loses a lot of meta information and complicates going up the abstraction chain to another language. Essentially this is a hub-and-spoke problem with the hub being too weak. Another example is Java/JavaFX. It's quite easy to use existing Java classes from JavaFX, but going in the other direction requires a number of ceremonies. And this is still just a pair. Even though the Java platform has been used to implement a rich set of languages, the basic problem is still there: The "hub" (Java) is too weak to describe objects/functions on a the level which would let you pass objects from Jython to JRuby to Groovy to JavaFX to Scala. Java's generics are incompatible with the generics used in Scala. Java (and also the VM) does not support unsigned integers.
Java was always designed to be an abstraction over the underlying platform not to integrate with it. This philosophical difference was actually at the center of Microsofts dispute with Sun over the direction of Java. Microsoft wanted the language to evolve in the direction of facilitating integration with the platforms (one in particular) while Sun wanted to abstract away the world outside Java and have everything remodeled in Java. Microsoft enhanced their Java implementation with the "lacking" features, Sun sued and won and Microsoft completely left Java and went on to design .NET.
Your example illustrates that at least in the area of multiple programming languages, the .NET platform is much more evolved. Unlike Java, Microsoft designed .NET as a multi-language platform from the get-go (although initially for multiple statically typed languages).
The .NET Common Type System (CTS) and common language runtime (CLR) were always (and still is) more advanced and feature rich than the primary driving language, C#. The CTS already supports generics variance (C# and VB don't yet) as part of the platform. (aside: Scala generics while being define-site with variance are merely an internal Scala thing and not compatible with anything else; Java generics based on type erasure are merely a compile-time only and as such doesn't exist for anything else).
The latest development in .NET is to incorporate support for dynamic languages into .NET. C# 4.0 and the CTS will lay out a common principle (a "dynamic" interface) which theoretically can accommodate most known static languages, hybrid languages and dynamic languages on a very high level.
This will enable any language which adhere to this specification to participate in a high fidelity hub-and-spoke architecture. You will essentially be able to pass a IronRuby object to IronPython, C#, VB, F#, Eiffel etc. and interact with it there while still relying on the Ruby
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
The least you can do is call it by it's correct name dammit, Qt! not QT!! This isn't some acronym, it's a damn word. It's pronounced 'Cute'. Though I've also heard a few different ways, due to language differences.http://www.qtcentre.org/forum/f-general-discussion-10/t-how-do-you-pronounce-qt-11347-post61535.html
Piss off with your horrid promo of Qt. I love Qt4 myself, and unlike you I have used it many times, but you seriously just treated Qt like a husband publicly degrading his wife. Shame on you. VLC wasn't created using "QT" it was created in C++. They took advantage of the "Qt" motherfucker, "Qt" toolkit for its GUI.
the mods were reversed, too.
The moderators expected all the slashdot crowd to understand what was going on, right?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Your question has three blocks of scope in programming terms: 1)The philosophical one: No, you should not suck it up and unlearn what you have learnt. Scripting and esoteric languages are here to stay. And if it wasn't the fact that some 'academic' environments tend to snob them, the situation would be better (the academic in quotes is meant as a criticism). 2)The toolkit enabling one: Apart from higher level architectures that support multi language development (Mono .Net, etc), the multi language programmer needs more effective IDEs for support. I tend to use the Eclipse platform, but a tool that handles the 'pipeline' aspect of multi-language programming integgrated in such an IDE is a must.
3)The language glue aspect:Many popular languages such as Python and Perl have specific dedicated mechanisms to use/call C++/Java.
Number 3 means that using C++/Java from Python/Perl and perhaps other languages has never been out of the question.
For more info, shout and I shall discuss details.
The usual answer is to write the core of the application in a relatively low-level language and add a scripting extension which can be used for less CPU-intensive, more rapidly-developed parts (often including the UI). The split between 'core' and 'extensions' varies but some examples are:
Firefox: core C++, UI and many extensions in Javascript.
Emacs: a small core in C, almost everything in Elisp.
Core in Java, scripting in Jython or another language that compiles to JVM bytecode (eg IBM Websphere)
Core in C#, scripting in IronPython, IronRuby, etc.
Core in C, scripting in Scheme (The Gimp's original Script-Fu, see also Guile)
There are other languages designed to be plugged into a C or C++ program, for example Lua and Tcl. You can even embed Perl though it's a little more complex.
-- Ed Avis ed@membled.com
...for C and an intepreted language, such as python, is to make the C program fork(), and let the child exec() the intepreter for the other language and use some sort of IPC (dup:ed pipes comes to mind). A bounded/unbounded buffer may also accomplish this.
Depends on the size of project, length of maintenance and so on. Of course there may always be "the right tool for the job" within a project (e.g. writing an os where some parts would need assembly and some parts c, or a web project where some parts just have to be js). But I'd always be careful when choosing multiple languages over one. How many IDE:s do you need? How many build tools to rebuild all the software? How many testing frameworks? Can your IDE debugger step between language barriers? Is there even an IDE with integrated debuggers for all languages? Can you find new developers that know all the languages, or to you need to have separate developers for each language?
I dare venture that the .NET initiative (and mono) is just that.
Common language runtime, sure. But use any language you want as long as you can bind it to the framework.
[sarcasm] So my next major, multi-megabyte project I will build with brainf*ck.NET. [/sarcasm]
People are not wearing enough hats.
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.
Probably because more and more people start using Linux to do some real work? It's not for geeks/nerds/engineers anymore.
But see below.
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.
It's old, but it works - GNU Cons. Also Google for "pcons", its parallel version.
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?"
This is like "Emacs vs. vi". There are people who to do work need well integrated environment. And there are people who prefer to have bunch of lego blocks and make from them whatever fits better task at hand.
Approach of building integrated, all-in-one, probably language-dependent software is nothing new and expected step in evolution of more or less any software product.
Main reason is that integrated systems have lower entry barrier. Essentially, people get some well-controlled sandbox where nothing can go wrong. Mostly because they do not want to learn - or do not have the time for it. Slap some task oriented UI on top of all of that - and any with knowledge of application field would be able to do his work with the software.
It's kind of funny that somebody brings it up again. Many people in past were dooming *nix to extinction because learning curve (and need to learn *nix philosophy too) is quite steep. Some bits about that are scattered around in ESR's TAOUP.
The only advise I can give you is to look out for application fields where your expertise with *nix and scripting can be advantageous and then change job. But honestly, I still can't recall single company where I did not end up writing bunch of small programs/scripts for whatever internal needs people have. Was it DOS, Windows, Linux or *nix, needs are the same. Even more so when people standardize on some all-in-one solution: I have never seen perfect one, which didn't required some custom hacks.
In the end, from my experience, expertise in making hacks - in making workflow more efficient - is well appreciated. Though more in smaller companies than in larger companies. Just do not limit yourself to Linux, and you'll be fine.
All hope abandon ye who enter here.
The JVM is pretty much ubiquitous. It is also free, open and mature.
There's of course Java, but you also have a multitude of other languages taking advantage of the JVM, e.g. JRuby, Groovy and Jython. See a more complete list here:
http://en.wikipedia.org/wiki/List_of_JVM_languages
My personal favorite is Clojure; a modern lisp taking full advantage of the JVM and Java's extensive libraries.
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.
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?"
What you should do is suck it up and learn a modern build tool like CMake (which you even mentioned in your question).
I have successfully and painlessly used CMake as a build tool for multi-language projects. It's actually quite trivial -- you don't even need to do that much. For example, one source dir might use C++, another C, another D, etc, etc. It's no problem! CMake does all the hard work for you.
The whole question is actually moot to me. Multi-language development is alive and well and has been going on for a long time. It's not even a problem that really needs solving anymore.
Combining of C++ and Python works really smoothly with Boost.Python. C++ objects can look and feel like Python objects, and vice versa.
peut-être.. Although many Ergebnisse sont loco.
while (!asleep()) sheep++
As linux market share grows I think there's going to be a bigger group of people building small specific programs and using stdin and stdout to communicate between them. On the other hand, whereas in the glory days of Unix simple text processing was quite common, the next few decades will probably revolve more around markup like XML or various rich text formats that play less nicely with sed and awk style operations. Nevertheless, I feel that many of the power users of windows will eventually become old school unix types, usin cut for example where they might have previously fired up Exel. Incidentally this is bad news for the bad guys. If people do move back to old school unix philosophy, many of the exploits that rely on monolithic, and therefore messy, programs will be obsolete.
there is a lost art involving inter-program communication which has not really been kept up-to-date as the complexity of applications and users' expectations both increase.
the "simple" principle which you are referring to - of joining (pipelining) applications together to achieve a purpose - was the ethos behind unix that made it so successful.
but - that principle was based on text files.
along came windows and blew that out-of-the water - but not in ways that you might anticipate. what really blew everything away was the use of MSRPC aka DCE/RPC with some small but highly strategic enhancements.
the use of MSRPC in Windows NT took the inter-process communication principle to unprecedented (as far as users were concerned) levels of transparent program boundaries.
the basis of DCE/RPC is that instead of burdening the developer with "rolling their own inter-program file communication", the developer can instead subdivide the application at the API level.
this was so successfully deployed in Windows NT that nobody really even knows that it exists. even the _internal_ teams inside microsoft often assume that an API is "direct" instead of networked, resulting in 2nd level APIs that repeatedly send 10mb of unintialised _crap_ over-the-wire.
then, later on, once the proprietary push of DCOM onto the world failed, microsoft tried again with CLR. CLR has been slightly more successful, as it is not tied historically to the operating system.
the bottom line is that there is plenty of technology out there for cross-application communication that makes it perfectly possible to have really quite sophisticated applications written in different languages.
DCOM. DCE/RPC. JSONrpc. Objective-C. CLR/.NET. even CORBA, god help us.
all of these have varying degrees of sophistication _well_ beyond "pipes and text file formats" that have developers throwing up their arms either in horror or to scratch their heads.
and it's exactly the ignorance and the lack of appreciation for these powerful technologies that leaves you, cthonicdaemon, in the situation that you are presently in.
Projects with multiple languages are harder to maintain and typically make the application more bloated. I can understand a programming language, some inline assembler, and a scripting language, but mixing C, C++, Ruby, and Perl is a nasty mess. C/C++ isn't too bad, but I highly recommend keeping the languages count to a minimum.
Comment removed based on user account deletion
Comment removed based on user account deletion
At work we use primarily two languages: C++ and Perl. Most programs we write have a Perl wrapper that takes care of parsing options, reading configuration files and that kind of thing. Then it creates a text file with key-value pairs and invokes the C++ program, which reads that file for all its parameter settings.
The use of Perl allows for lots of flexibility for configuration, handling of special cases and plain-old hacks. The C++ does the bulk of the work, and here we care more about good interfaces, efficiency and other quality considerations.
I don't particularly care about which specific pair of languages we use, but having this combination of a main programming language (C++) plus a flexible glue language (Perl) is invaluable. At some point in the past more languages were used (C, Tcl, shell scripts), but in a company were about 100 people may have to read each other's code, it's easier if you keep it down so you "only" have to learn 2 languages to join the team.
1. Loose coupling between S/W components is always better then tight integration. Always.
2. Regardless of what other languages you know, learn the shell. It's the language of the system, and it's the language of S/W integration. Sooner or later, you have to integrate your S/W into a larger system, and so there will always be a need for glue.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Ouch... labview... Yes, i also used labview. When talking about big projects beeing difficult to maintain in tcl, all "difficult to maintain" phrases will get strongly relativated in your mind in the moment you use labview.... I rather would code in a mixture or perl, R, and 8051 Assembler instead of maintaining a big (or only moderatly sized application in lv).
I also used webservices. I drew a webserver in Labview, which deliverd xml to a controlling matlab part where it was decoded into matlab source by a fitting xslt. While this solution was interesting, i replaced the labview part of the application two months later in matlab and lived happily ever after (until the end of my phd thesis....)
Integrated Language Environment, the basis of programming on the iSeries. I can easily combine RPGLE, CL (command language), COBOL, C, C++, and JAVA. I can invoke REXX and talk to the internet through other methods as well.
What IBM did for programming and developers in general with the iSeries really needs to get out. I would love to see this level of integration on the pc/mac platforms. IBM takes it so far as that the code is compiled down to a "p-code" level and invoked by whatever hardware layer is present.
http://en.wikipedia.org/wiki/IBM_System_i
http://en.wikipedia.org/wiki/IBM_RPG
Look, I know many look down on systems like this, let alone RPGLE as being old school like COBOL. However we run a billion dollar business with these as do many other big companies (you would be surprised to learn the companies that do) because not only is it robust, secure, and easy to manage, but it is so programmer friendly.
I am sure there are examples in the pc/mac world; well I am not sure; but the ease and level of integration is unparalleled. All I can suggest to geeks and such is look to what works on business platforms and see how those ideas can be extended into other environments. Don't dismiss them. These systems benefited from a lot of knowledge and time. Everytime I hear "rpg is dead" or "cobol is dead" I keep going only to read the same thing five years later.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Anyway, there's plenty of room for multi-language programming. One example of this is SOAP. Another example is CORBA.
is this your argument for or against multi-language programming? :)
I haven't used it myself, but Java Curses is probably worth a try.
The title says it all.
I happen to be a control engineer, so I spend most of my time processing large amounts of data from measurements and experiments. I find C/C++ syntax terrible for matrix/vector stuff, while Fortran (>=95) is well-suited for it, including having damn efficient compilers. I started with Matlab at University, but the licensing issues really got me down.
This is exactly what I'm talking about -- I've chosen languages based on what works in terms of syntax, performance and suitability to the job at hand, but these days popularity and homogeneity seem to be more important for long-term success.
Languages aren't inherently fast -- implementations are efficient
You should develop for the web, lots of languages there.
You can use Javascript, HTML, CSS in the browser, SQL, PHP, Java, C, Perl, TCL, whatever on the server. If you use one the scripting languages, you don't need a makefile or build-system.
It's instant multiplatform as well. :-)
New things are always on the horizon
For one thing, just using one language all the time is boring :-)
My list:
1. Ruby: my default language for small utilities, and for low volume web portals (with Rails/Merb)
2. Java: high performance web and server side stuff
3. Common Lisp: research programming, and some applications requiring very high performance
Then, seldom used:
4. Prolog: seldom use it anymore, but for some things it is the best
5. Smalltalk: research (mostly NLP) and sometimes Seaside
In other words, have a few core languages, but keep an open mind. I found myself not using Erlang after learning it, but knowing Erlang makes it easier to use things like CouchDB that are written in Erlang. Same for Python: it was worth learning the language because I sometimes use programs written in Python.
If I wanted the answer to be correct, I wouldn't. And don't.
e.g., $ perl -e 'print "this should give an error"' > /dev/full but it doesn't
"Not an actor, but he plays one on TV."
every problem looks like a nail that takes 18 months to pound in...
(and 18 months to pull back out when you figure out it's crooked)
"Not an actor, but he plays one on TV."
I have a toolbox at home that contains a pair of pliers.
These pliers have a formed handle that can be used as a screwdriver. I can pry with it, I can pound with it, I can pull small nails, grip, twist and an assortment of other jobs.
It's not particularly good at anything.
I also have a set of combination wrenches that work great for loosening nuts and bolts without buggering them. The pliers just can't do the job.
I have a hammer that can cleanly drive a nail and pull it out too. The pliers would be hard pressed to drive a finishing nail much less pull it.
Programming languages are tools.
Some are better at some tasks than others.
Recently, I have begun using Python. It is a very nice pair of pliers and the proper tool for one specific task - prototyping. It is so good at prototyping that the prototype often BECOMES the finished product.
Python code is so close to pseudocode that often the code documents itself.
Python is pervasive but not as much as C/C++/Java.
However, if I wanted absolute speed of computation, I'd make the finished product using C or C++.
If I wanted cross platform - Java is king.
Python is an excellent glue language for MultiLanguage Programming. Black box your components and call em with Python to tie it all together.
Or use another pair of pliers language that meets your needs.
What I'm getting at is:
There is a proper tool for the job.
Use the proper tool for the job.
Have more than just a pair of pliers in your toolbox.
Use the pliers if it's the right tool.
Codifex Maximus ~ In search of... a shorter sig.
Matlab licensing issues. Yes. everybody has them. Therefore i usually write my code in a way that the substential part (e.g. reading data files, processing etc.) runs also on octave, while plotting sometimes is matlab-specific.
I heard the thing about Fortran bein great for vector operations and i tend to believe it, however most libraries for DAQ are designed for C, so i stick to that.
Python gives you the Rosetta stone for a project combining any other languages you'd like.
I can see where this is going... a Shamwow?
I'll just cut to the chase. There are and will be two universal interface languages:
* C for compiled languages
* javascript for dynamic languages
Javascript is a really, really simple language (in the same nature as C). On the implementation level it's name:value pairs. C for comparison is basically address:value pairs. This gives a nice simple universal platform that anything else can be built on. Python does not have this simple layer that everything is built on.
Javascript also has a syntax that can be used in non-file situations such as a command-line (a javascript shell). Javascript syntax is also a direct dynamic language equivalent to C, which has succeeded in the developer marketplace.
Currently what you find is that Javascript does not have a good interface to the system, without native javascript APIs for open, read, etc, and without a standard set of hooks into C programs. This is entirely because of javascript starting in the web browser, but what you'll see is people developing these and then python going the way of the dodo because javascript can do all the things python does, and better, but it can also do other things such as being the universal glue for dynamic languages.
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...
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.
Posted from my Android phone. Oh, I can change this? There, that's better...
I'm intrigued by what I've read of .NET. It does sound like a desirable thing, at least when viewed from afar.
Unfortunately, though, it's from Microsoft and they have patents and god knows what else to garrote anyone that uses it, any time they like. And they have a considerable track record of doing just that sort of thing. You'd really have to be a fool to walk into that one at this point...
"Not an actor, but he plays one on TV."
I think multi-language program is pretty much the norm, so not sure what this is talking about. At my current job, for our products we use PL/SQL, Java (on the server), and C# and ActionScript on the client, with a bit of JavaScript here and there. For some of the automation-type stuff we use some Python and all the typical UNIX utils including the ones that were mentioned (but these are not things that are actually part of our product).
The typical web app usually requires you to know at least 2 programming languages (some language + JavaScript). Though, JavaScript on the server side and things like GWT are making it possible to code in one programming language.
learn to do all my programming in C++/Java/(insert other well-supported, popular language here)
I would insert Python into that list, as the question author already uses it.
#!/
Hey, it looks like a commercial from Microsoft, vague enough, with the correct buzzwords, talking about big projects done with a few lines of code.
Entrophy goes somewhere, you can write something with three lines of code but you will have tons of code supporting those three lines.
Hey, I can write simulate.object(world) and in one line I will have a world simulator ! WOW !
But what is behind that ?
The answer is very simple if you have the right background.
Do you know Standard ML or CAML? Do you understand the benefits that it offers over e.g. C/C++/Java?
If so, then picture mostly the same thing, but for .NET. That's F#. There are quite a few differences, of course - lack of functors on one hand, "active patterns" on another, etc - but fundamentally it's about the same thing.
OK, so why don't you just call it "INCREMENTAL" development instead of coming up with all these ridiculous buzzwords just for the hell of it, or because you think it sounds cool? (It doesn't. Makes you sound like a bunch of marketing dweebs with an over-inflated sense of job importance.)
I'm sorry but this smells like a shameless plug for Microsoft's dot net.
Dot net is not the solution, because the libraries are still incompatible and dot net doesn't support all platforms, not even most.
Using dot net you can combine code written in many languages but all this code will depend even if only partially on features only present in Windows, in MS flavor of dot net.
Take IronPython for instance, IronPython code doesn't run in Python nor Python code can run in the CLR unless you only use the subset of the standard library that has been ported to the CLR.
But... the future refused to change.
Why did you not use some existing word rather than inventing your own? I suspect you were trying to sound cool by using a modern word, even though it likely dates back to your father's generation.
Go back forty years and look up the word 'entree' . It didn't exist in US English. It is also highly confusing to French speakers, because whoever imported it into English got it wrong. In French, an entree is an appetizer. In English, it's a main course.
language evolves. get over it.
No: there is little hope for "multi-language programming", because the barriers are social, not technical. Every time you add a language to a project, you're raising the bar on the number of languages you need to be familiar with to work on that project.
The academic attitude is that you should learn all languages, and all programming methodologies for the sake of the mental exercise involved, but out in the real world people go hog-wild for things like object-relational mappers -- whose main benefit is to save procedural programmers from the horrors of having to shift gears and think relationally.
There is one possible bright spot I know of in the multi-language world: the development of things like the Parrot virtual machine, which is intended to be an efficient backend for all dynamic languages, including (but not limited to) Perl 6. It seems unlikely to me that this technical achievement is going to bridge the social barriers between the camps of language advocates, but you never know, maybe I'm underestimating Larry Wall's social engineering skills.
By the way: the unix "do one thing and do it well" philosophy has almost never been adhered to by anyone. It's more like "do one thing sort of okay, then trick it out with command-line options, configuration files, and customization languages until you can't tell if it's going to fry eggs or go to the bathroom". In reality, piping together small programs is of extremely limited utility: a pipe is too narrow a communication channel -- that's why perl was such a success, it integrated all of the old shell favorites into one process so the pieces could talk to each other much more easily.
s{ procedural }{object-oriented}x;
How exactly does your pointing out that language evolves refute my assertion that the term "organic" as applied to software is stupid? It's stupid not because it's an "evolution" of language, but just because it's a stupid term that some dipshit came up with to sound intelligent, and other dipshits copied so as not to be left out. The same thing with "going forward" and other bullshit corporate words. It's stupid, and you are stupid for buying into this nonsense.
How exactly does your pointing out that language evolves refute my assertion that the term "dweeb" as applied to language is stupid? It's stupid not because it's an "evolution" of language, but just because it's a stupid term that some dipshit came up with to sound cool, and other dipshits copied so as not to be left out. The same thing with "dork" and other bullshit abusive words. It's stupid, and you are stupid for buying into this nonsense.
I'm ambivalent on this - we use Perl for most of the back end business logic and Java (GWT and POJOs) for the web front end, and it mostly works. Comms are via the DB - actions, changes of status, flags etc - and we dont have to spend a lot of time trying to second guess the other devs. That said, I'm not so crazy about the fact that one of our legacy apps is written in PHP, almost entirely by one guy, and it bears no relation whatsoever to the rest of the codebase. The day he decides to leave, its 'Hey, I noticed that you did some PHP back in the 90s !' ....
Shell scripting isn't going away if you have to tie together lots of different programs. Bash and the other variants are still quite powerful; and are well-supported on Windows. (To be frank, I learned shell scripting on Windows years ago, yet I'm just starting to dip my toe in the Unix waters.)
Today, a lot of tools are moving to use XML. I have mixed feelings about this; as some tools use very weird schemas. However, being well-versed in XML is a "portable" skill.
No, I will not work for your startup
...you didn't have to buy a license for your hammer, pliers, and screwdriver.
Your saw worked exactly the same building a house as it did on some other platform like, say, a deck.
Nor did you have problems when you upgraded your hammer.
When you buy a new screwdriver you don't have to replace all of the screws.
The hand tool analogy is suspect at best.
I am very small, utmostly microscopic.
It might be a little flamey, but the point is valid, mods...