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.
So I'm to understand that application programming has only occurred in the last 10 years? That's strange, as I distinctly remember using programs that don't necessarily communicate with each other via stdin/stdout more than 10 years ago.
Anyway, there's plenty of room for multi-language programming. One example of this is SOAP. Another example is CORBA.
This is obviously more complicated than simple standard IO programming with grep/awk/sed and the like, but how many programs outside of some simple shell scripts really use that?
AccountKiller
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.
I have done a lot of shell programming as well. It was one of the reasons I avoided coding in PHP. Finally one of my PHP devs told me to run my shell scripts using an exec command. So I broke the seal and added PHP to my language library. I rarely make shell calls but occasionally they are useful, especially as an interface to existing scripts.
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.
If someone tells you what to do are you going to do it? Don't bother thinking for yourself.
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
Forget your philosophy.
It's funny you say this, because I find things these days are much MORE amenable to choosing your desired language than ever before.
Here's the nuts and bolts of it: Java is not the greatest language in the world, but it runs everywhere you probably need to run, has tons of well tested libraries, and people who talk about "the enterprise" all the time are comfortable with Java-based stuff. Now comes the cool part: there are great languages that run on the JVM. Like Clojure. Choose one. Actually, just choose Clojure and be done with it.
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.
Can someone mod this idiot with all his double links down? Such behaviour shouldn't be encouraged, it reads like a bad Wikipedia article.
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
Has anyone here ever "unlearned" anything? I have, for sure, forgotten plenty ... but never something that I've gone so far as to have "learned" in a philosophical sort of sense. I say to devour java/c++/ruby/whatever and put everything that you've learned up until this second into it. Commands are objects, pipes are interfaces. Reuse. Recycle.
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.
Go with what you know and if there is an interest in other languages and techniques, then move on to that, because even if a language or technique falls out of favor, it will come back to haunt us. Remember Cobol? It's the Cthulhu of languages IMHO.
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.
I have coded in nothing but assembly language and C for the past 25 years. I still enjoy programming day and night, I still feel challenge and satisfaction, and I have neither financial nor technical reasons to stop wielding the tools that I am most familiar with in favor of something that I would feel suboptimal with. If you enjoy building things using the Tao of Unix method, then stick with it.
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.
I work in J2EE generally, however this has not prevented me from following the unix philosophy. The use of ant makes it easy to utilize a number of java widgets that do one thing and chain them together. Generally done as task1 followed by task2. So while it's not as clean as piping, it does allow me to make utilities that do one thing well. In particular I backported a number of gui based utilities that did this, but didn't offer a command line version.
Java does make the command line syntax of calling a utility a little gross, but it's at least doable. It'd be nice to configure the installed jvm so that you could store a bunch of jars in a common location and just call java jarname instead of java -j jar (or worse if the jar is poorly packaged:
java -j jar fully.qualified.package.to.the.MainClass
).
There is also the issue that java has poor support in the command line (no chance for something like ncurses). You have to implement your own java console to regain the control of the screen in that fashion. Anyone know any good libraries for doing this?
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.
Personally I use JavaScript to drive a C-written graphics engine, much like Emacs and Lisp. The core hereby provides low-level graphics routines and file formats while the JavaScript-VM allows for the implementation of custom scenegraphs and animation.
This works perfectly for me and I really get the best of both worlds. I think the important point is to design for scriptability from the very beginning and not attach the scripting language later on.
For the (horrible amounts of) glue code between C and JavaScript, I wrote a code generator which is available at [1].
-Thomas
[1] http://sourceforge.net/projects/jsapigen
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.
you can also script on top of Java:
here
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.
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........
If you have the time, why not start a weblog and share them? Share the knowledge.
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
OK, now listen up. This will be an education for you.
You design your system, white board it, do whatever
you do to come up with the pieces.
Then, for each piece, you develop a project.
You shop each project-piece out. You find the best solution for each part. You try different solutions for each part. Each part can also be
aggrigations of parts that are written in different languages as well.
Of course you don't have to use the same
tools for each solution. One part might be in
PHP, another in compiled C, another a set of
bash scripts. How they interact, what they do together, the artifacts that they create, the
connections that they need, the IPC they use, all
of that is up to you, lead project manager, to have your team devise (maybe your team is just you).
If you want to see how this is done in the real
world I suggest you study how to create the specification files for RPM. RPM is what yum uses. Or maybe you use subversion? Or perhaps you like apt?
All of these source control solutions are useful. if you study any of them you will
learn a lot about how real world packages work.
Also, having various pieces means that you have
other parts, building blocks, for other projects
as you are laying there, afterwork, relaxing
and yet unable to get your code-head to stop
coding, your design-brain to stop designing.
You will suddenly see the mutability of
software. The aggrigations of pieces might be
reengineered if you have the budget. Or you can
use new pieces that you find out on the internet
to replace something that is costly to design.
After you have all of your parts working
Then you create a 'package' in rpm or in apt, that
groups all of the pieces together! you distribute
that as a installable package. What that does
is go and get the various pieces and
it installs all of the pieces so that you can
use them. And you can install them on different machines.
And then if any piece gets upgraded only it
might need to be upgraded, and not everything.
And then you are putting out a project that may be written in
many langauges. Your clients will not know
or care. They install your RPM and they are done.
Things are up and working.
This method is tried and proven and works. It is
how all modern Linux distributions do things.
As a matter of fact a Linux distribution
for a desktop is just such a collection of
packages.
You can make a bootable CD that boots linux and
your project as a demo disk for your clients
once your stuff works.
If you don't do open source you will need
to have a huge budget up front to buy all of
the tools for your propriatory system and you
will need to deal with the crazy-ness of
whatever random things the vendor does
and their policies of submission. And I mean
submission to their hedgemony.
PS: Most of the 'parts' that you will need
for your final aggrigate have most likely already
been developed, either open source or otherwise).
For example: I created a touch screen qwerty keyboard that used festival to speak the words
that were typed. It was exceptionally easy.
I wrote the keypad program to output ASCII and
ran it with a pipe into festival.
The 'pipe into festival' part was just a
'hey, I can do this too' kind of thing. and I did
and it worked the first time. Didn't have to
develop anything.
Only thing if my company were to use this
they would need to worry about following
the licenses.
Good luck
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.
As soon as it is available, writing the firmware for flying cars and finishing off Duke Nukem Forever will be a cinch.
With a common call sequence (and some understandable ways data can be passed) you can mix any languages you like which can be compiled to that sequence. (For interpretive ones you need glue.) This can be advantageous, where one language may for example be especially good at handling structured I/O and another may have some computational facilities that make the part of the problem you are trying to solve easy to solve and easy enough to see that the solution is correct.
Those who claim this is unstable ignore the value of getting the program right (friend of accuracy and of security) or appear to be getting lazy about picking up a different language (should be the work of a week or two).
This has been done in some systems; OpenVMS had this facility in the 1980s if not before, and its built in make facilities are not language specific. The main problems they had to solve to get there were arranging common calling/linkage systems, and some RTL naming conventions so that the link-time namespace did not have massive collisions. This last may be more difficult in unix due to its historical base, but essentially it never showed up within a language; the name prefixes were usually invisibly added by compilers and resolved by linkers. If you wanted to call a c++ library element from, say, cobol, yes, you needed to be aware of the conventions. This was not common though.
Knowing multiple languages is however a good thing, and being able to use the pieces to solve your problems, where you can choose the best language for each part, is mightily helpful and can make for a smaller, faster, cleaner design.
If your staff objects because God told them to use and not to pollute it with , consider that mental ossification and laziness can occur at any age and that these are not good qualities to keep around.
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."
Imho the question demands a Zen answer. If you think, that the command line is the path to enlightenment, than you haven't understood the first thing about programming.
There are reasons why people use java and there are reasons why people use awk...
Now go and do some one handed clapping.
"Grow" ... "organically"? What is this, a fucking tomato garden? Are you fertilizing it with goat shit? After you're finished are you going to take the end product and sell it at a farmer's market?
If you answered "no" to all of the above questions, why the fuck are you using words like "organic" to describe your project?
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.
Facebook was grown organically in several different languages, so theirs may be a good example to learn from. To create an easily extensible website, they needed a uniform way of connecting everything together. They created Thrift to cope with this problem, and have released it as open source. From the web page, it supports "C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml."
the original post was about using The Right Language/Tool For The Task(tm).
That's like using SQLite instead of hand-coding your own equiv. into your app.
*Not* about using random languages.
Dividing The Problem up into an orthogonal set of sub-problems, and designating specific solutions to each one CAN be much more capable than OneSizeSortaMaybeFitsMost coding.
Using different toolkits for different portions of the problem is essentially the Same Thing, dontchaknow...
Cheers.
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.
Hi started programming in "2nd generation languages". No it's all 3GLs (Java, C, C++, C#, Python, Bash, whatever), all 3GLs, so I feel quite old.
However I keep studying and improving and I realize it's really not about the language anymore. It's all about abstraction and modelization.
OOA / OOD is the name of the game for me nowadays. Working in the RT/E field where you can have one "abstraction" (I don't way to say one "object" for the heavy bias it carries towards certain languages) representing incredibly complex machines made of hundreds -if not thousands- of subparts just feels like magic.
Kernels are made using ASM and C. Real World [TM] applications having 4 nines of uptime are designed using OO methodologies (excepted for certain very particular, very trivial, mostly DB-only apps, coded mostly in 4 GLs like SQL, but this is not a majority). For everything in between there are toy languages. And there's a use for toys languages.
I often do quick prototyping piping scripts but once the "real thing" needs to be done, for the Real World [TM], there's no match...
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.
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.
What about mono? Supports lots of languages. Multi-platform, modern, large & growing community. Great IDE.
in my experience, you never need more than two languages for any project: a fast one where performance counts, and an expressive one where speed of development counts.
there are some exceptions of course. for example, when you're integrating pre-existing components, or when you use another language as part of your build process (lex, yacc, perl generated source files etc.).
but for the most part, you'll get the most milage out of two well chosen languages, and many of the classic combinations are X + C.
The language in which you write is an interface to various things:
* The computer's hardware
* Algorithm libraries that do things you need correctly and perhaps efficiently
* Other processes on other computers, written in other languages (the focus of much discussion here)
* Other developers
The last one may not seem as important as the others the day you choose the language, but it may well be in a year or three. Consider the best language for making clear what you've done, extending it, porting it, etc, and you will have chosen well.
Tying stuff together with byte streams is incredibly primitive. That's why they had Lisp machines - everything is a Lisp object. Tying the world together with one language to rule them all is a far more powerful paradigm. The trouble is, not many languages are up to the task of such an exalted job. C certainly isn't. Lisp is. Some object languages are.
The missing link is an object file system. WHen the file system is all about byte streams it gives you the false impression that everything should boil down to byte streams. Wrong answer! Everything should boil down to objects. A Lisp machine + CLOS + an object file system. Common everyday OSes like Linux, Windows etc are holding back the future, but that's where we are right now.
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.
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;
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.