Hope For Multi-Language Programming? 371
chthonicdaemon writes "I have been using Linux as my primary environment for more than ten years. In this time, I have absorbed all the lore surrounding the Unix Way — small programs doing one thing well, communicating via text and all that. I have found the command line a productive environment for doing many of the things I often do, and I find myself writing lots of small scripts that do one thing, then piping them together to do other things. While I was spending the time learning grep, sed, awk, python and many other more esoteric languages, the world moved on to application-based programming, where the paradigm seems to be to add features to one program written in one language. I have traditionally associated this with Windows or MacOS, but it is happening with Linux as well. Environments have little or no support for multi-language projects — you choose a language, open a project and get it done. Recent trends in more targeted build environments like cmake or ant are understandably focusing on automatic dependency generation and cross-platform support, unfortunately making it more difficult to grow a custom build process for a multi-language project organically. All this is a bit painful for me, as I know how much is gained by using a targeted language for a particular problem. Now the question: Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"
It's a big umbrella (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
I agree, I've done both a lot of shell scripts, web scripts and compiled languages programming; it all comes down to what your goal is, there's no perfect combination of languages for every scenario.
Personally I prefer having a core program written in a compiled language (C++, D), with a bundled library for scripting (LUA, Python) for I do mostly cross-platform programming these days.
However, when doing system admin tasks and automation, nothing beats shell scripts, it takes too much time to write and maint
Re: (Score:2, Insightful)
"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?"
No, DON'T unlearn ten years of philosophy. DO learn to do programming in C++/Java/(insert other, imperative programming language here).
Simply by learning a new language, you should not lose abilities and ideals you gained with others (goes for scripting too). You should build on your previous
Re: (Score:2)
Depends, really (Score:5, Interesting)
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)
Re: (Score:2)
Definitely. You also work in a shop where all kinds of different operating systems are supported and used. Windows XP, Windows Vista, Windows 2008... See?
Re: (Score:2)
That was an example of my personal responsibilities:) We have more unix machines than Windows, hehe.
Yes, .NET may actually be the best bet (Score:4, Insightful)
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
Re: (Score:3, Insightful)
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 member resolution principles.
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance? Or how are you going to map classic objects with modifiable state to stateless, side-effect-free languages like Haskell? I'd imagine that that's not going to be pretty, no matter what the underlying runtime can supposedly do, because the unpretty-ness is a function of the semantic gap between the languages themselves, not of some feature set (or lack thereof) in the r
Re:Yes, .NET may actually be the best bet (Score:4, Informative)
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance? Or how are you going to map classic objects with modifiable state to stateless, side-effect-free languages like Haskell? I'd imagine that that's not going to be pretty, no matter what the underlying runtime can supposedly do, because the unpretty-ness is a function of the semantic gap between the languages themselves, not of some feature set (or lack thereof) in the runtime.
Yes, of course. What .NET really did was to standardize on some common feature set and model. Languages are still pretty distinct, and e.g. F# has a lot of stuff that simply doesn't map well to anything in C# land; but they have some common ground, and that common ground is much more high-level than what we had in C. What more, this approach is extensible - they needed to add dynamic languages such as Python and Ruby in 4.0, and the existing conventions did not cover that, so DLR was born; and now C# and VB are also moving to it in the next release, and any other future dynamic language on .NET likely will, too.
This comes at the expense of languages themselves having to support that common model. For some it's natural, because they were designed around it - see C# and VB. Others - C++ and F# - are different, and they essentially have to add some subset specifically for dealing with that model; so e.g. in C++ on .NET you still have full power of ISO C++, and it does compile to CIL bytecode, but it's unusable from other languages; and then you have C++/CLI, a set of language extensions that allows you to create and use CLS-compliant types. That separation is very distinct and clear. With F# it's somewhat more blurry, but even so, there are some clear differences between the traditional FP constructs that are F#-specific on .NET (ADTs, curried functions, and tuples, for example) - which don't map nice to any other language; and the F# object model, which pretty much follows CLS closely, with only a few twists.
On the whole, it's hard to say it's a perfect approach, but it certainly provides for better multi-language interop than the traditional C FFI solution. Pragmatically, it works.
Re: (Score:3, Insightful)
Re:Depends, really (Score:5, Interesting)
I was introduced to functional programming via C# 3.0, with the lambdas, LINQ, and better delegate support. Not quite "real" functional programming, but its a nice gateway drug, and have been hooked since then (thats background info just to say I'm no expert, but no dummy either).
F# is pretty slick. Its basically a "real" functional language, that still allows it to be easy to integrate with "real business", including databases, IO, and has great support for tooling since its based on .NET. So its pretty much the "perfect" functional language, for the "real" world. (I know many are better from a theoretical or scientific point of view, but i'm talking purely pragmatic here).
That said, I didn't use it much. What I can say, is we have an army of PhDs implementing -extremely- complex algorithms here (functions being passed around with several douzens levels of nested function types, to do very, very complex modeling in a couple lines of code...), and they swear my F# now (they've been using it since early technology previews, and are getting ready to push large amounts of code in it in production...its working awesome, supposingly).
Sorry I'm vague on the details... but what I can say, is its good enough for one of the largest linux-centric company in the world to shift some of its code to it. Nuff said :)
Re: (Score:3, Interesting)
"That said, I didn't use it much. What I can say, is we have an army of PhDs implementing -extremely- complex algorithms here (functions being passed around with several douzens levels of nested function types, to do very, very complex modeling in a couple lines of code...)"
If you do OOP, you're effectively doing the same thing when you're passing objects around: every method and every method of every class type that those methods work on is a "level of nested function type".
Also, it sounds like they're eff
Re: (Score:3, Interesting)
Yes, OOP is indirectly the same thing. The Strategy design pattern is just a way to implement functional-like paradigm to non-functional language.
Its still not as easy or elegant, and the compiler cannot optimize as aggressively, and some stuff will take a whole lot more code. Thats why the base functional paradigms were added to VB.NET and C#.
They're also not building domain specific languages at all. Its just the mathematical model (not model as in a DSL model, but really, as in a math one) is extensive,
Re:Depends, really (Score:4, Interesting)
Very good question. I personally looked at Scala and thought it looked pretty good, but that I didn't try at all (just read the documentation). If I had to guess, I'd say its a mix of Microsoft support (which, while I know i'm saying this on Slashdot, is actually pretty damn good, and you have tons of support calls included with MSDN subscriptions, volume licensing agreements, etc), the fact that the language is just really well designed, the better, faster interop with native code (so if you have to do something in C/C++/Assembly, you won't lose 90% of the performance bonus in the interop layer), and that some of these algorithms have to be integrated with thick client software on desktop machines, as Office plugins, etc.
The last 2 are probably the biggest deal. You know for sure you can interop (well) with anything and everything, that it can run on the servers (most are Unix, and its by far the preference, but we can put a Windows server without affecting users if we really need to) and on the client integrated with basically anything. Almost anything that can be extended will support some kind of COM/COM+ or .NET interop model of some kind. Doing it with Scala is not impossible, but far more annoying. And if the F# code needs to be distributed, WCF tends to be better than many alternatives, etc etc.
So in short (and again, its just a guess. I always tend to be quite curious too when a Windows solution gets selected over a Unix one, since we're not locked in on Windows much if at all), easier to extend, and better corporate support.
Re: (Score:2)
"As much as I like Linux, I don't think I ever brought into the "unix" way. Communicating via text is fine, but it doesn't seem really efficient."
I have a background in traditional embedded systems and the idea that OS's like Linux actually call text-based command-line tools before the system boots boggles my mind.
Unix definitely served the needs of the times it was created in (i.e. small programs performing small tasks).
StupidPeopleTrick (Score:5, Insightful)
Yep (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Is there a contradiction... (Score:2)
... 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.
Re: (Score:2)
The point of my sig is that we all live in ideological, intellectual, and emotional cages of one kind or another, recgonition of that allows one to cautiously venture outside their cage and draw insight from other peoples POV. In the case of software development I have spent the last 20yrs in the developers cage flinging the occasional turd at architects, testers, s
Re: (Score:3, Funny)
"The more languages, the more of a pain for support, debugging, and dev hand-off."
You forgot to add job security to that. :-)
do not sweat it and enjoy! (Score:5, Informative)
The world ebbs and flow. One day it C, another RPG or CL or ADA or PHP or ...
Do what you like to do.
What you may want to, is join a project that is more inline with Linux as whole versus a single app. Ubuntu or another general distro, or help with a small single use distro like IPCop. They should be glad to have some one like you help out.
One time..... (Score:5, Interesting)
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?
Re: (Score:2)
That much experience huh? So why did you pass him up? Were you intimidated by his skill set or was it that he didn't fit into your ( sounds like some 20 something kids club ) post modern punk world?
Re: (Score:2)
Re: (Score:3, Interesting)
Re:One time..... (Score:5, Insightful)
And the main problem I have found with young guys is they have absolutely no appreciation for talent and can't stand it when they are in a position to hire because quite frequently it eclipses their own by an order of magnitude (that's a gross generalization, of course, and not always true). But the by far the biggest problem I have found to be more and more true these days is that some kid manages to get himself hired because he has a degree in java, manages to keep his nose clean and then gets to hire more talent as the project gets bigger and in most every case they turn down anyone with a vastly superior skill set that was born more then 3 years before they were because they prefer a quiet well lit office that doesn't stink of BO and stale junk food. I might be wrong, but somehow I doubt it very much.
Now you are probably thinking, "Must be some old fuck" and you would be right I am part of the over 50 crowd who has a very current skill set and has 30 years of programming experience to back it up. I am a consultant and I am frequently hired by CEO's and CFO's who are at their whits end with the "kids" that got hired by the other kids that got the job then decided the lights were brighter and more sparkley someplace else after talking management into using the latest and greatest hair brained library written in a language that uses tabs for scoping.
Mostly what I am is a janitor, a very very well paid one, but a janitor never the less, cleaning up messes left by kids.
Don't take offense because one of these days you (if you are any good) will be doing the same thing in 30 years and why? Not because you "need" the money but because you, like me, will hopefully have some ethics about our craft.
Re:One time..... (Score:4, Insightful)
using the latest and greatest hair brained library written in a language that uses tabs for scoping.
I'm with you for all but this. And, BTW, I'm 40, with 20 years of experience. I was skeptical about Python, but I've recently started working on a significant project written in it, and I think it's a fine language. It does require a decent editor to keep the indentation clean (and the recommended practice, BTW, is not to use tabs at all for indentation, only spaces), but assuming you don't abuse the dynamic nature of the language, Python code tends to be some of the clearest and most readable of any language I've used.
Python is a fine language (and not a particularly new one, being roughly contemporary with Java). Like any sufficiently-powerful language, inexperienced programmers -- and especially very *clever* inexperienced programmers -- can make a huge mess.
I'm sure that's little consolation when faced by such a mess, but (and I'm sure you're fully aware of this), the problem is the messmakers, not the toolset.
Re: (Score:3, Insightful)
Like any sufficiently-powerful language, inexperienced programmers -- and especially very *clever* inexperienced programmers -- can make a huge mess.
True enough, but I've found that because Python is not yet that popular, it's still drawing mainly above-average programmers. Maybe 2% of the Python code I see is awful, versus over 90% for Perl. I think part of this is due to Perl's inherent flaws, but surely another part is due to the fact that every Joe learning to program is pointed at Perl (which can't end well, and doesn't).
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
written in a language that uses tabs for scoping
This sounds like a half-baked (and incorrect) jab at Python's syntax. Sounds like someone's skill set isn't quite as current as he thinks... :-)
That notwithstanding, I also find after decades that programming involves a great deal of janitorial work. I'm trying to convince myself that this is a good thing, as it means that I will always be able to find a job cleaning up these messes. But, it does kind of suck cleaning up vomit written in Perl, C++, and (god help me) RPG...
Re: (Score:3, Interesting)
How is this not flamebait? I have worked with young guys who don't know what they are doing, and I have worked with old guys who don't know what they're doing.
Incompetence knows no age limit. Neither does competence by the way. In your case, FlyingGuy, I would not hire you (if I were doing hiring) and it has nothing to do with your age, but rather with your bad attitude.
FWIW, I am a younger programmer and I have found two things (major generalization forthcoming). 1) The older developers have taught me
Don't understand the premise (Score:3, Interesting)
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.
Yes (Score:5, Interesting)
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.
Re:Yes (Score:4, Insightful)
meh...
In my 23+ years of professional development, administrative and engineering roles, I've found that you stick to what you're best at, and learn new things in between...
Unless the command prompt disappears, there will always be shell-scripting and that strung together happiness of well written, single-purpose shell scripts doing their jobs together as though a well orchestrated symphony.
Re:Yes (Score:5, Funny)
Oh, no! The command prompt disappeared.....
Eclipse (Score:5, Informative)
Eclipse is a fantastic platform for multi-language development, especially if your primary languages are C, C++, Python, Ruby, etc.
All you need to do is create a C++ Makefile Project, then use the makefile to wrap your build system (e.g. ant, scons, actual makefile, whatever). You can build any number of binaries and launch them (or scripts) from the powerful launch profile system.
Basically, Eclipse projects have "facets" - they can cram in features from multiple language development kits and mostly remain compatible. You still sometimes have to do the glue work yourself, but in general C/C++/Python are very easy to mesh. It is therefore easy to have a project with C libraries being loaded by Python, and so on.
Re: (Score:2)
So.. what is the benefit of separating the languages for a single project? Other than taking bits from things developed in several languages?
If you're starting from scratch, wouldn't it be better to be homogeneous?
Re: (Score:2)
Re: (Score:2)
Things may have changed but the last time I tried using Eclipse for C++ development I found that it compared favorably with Visual Studio 97.
Re: (Score:2)
In a multi-language environment nothing beats a capable text editor like Vim or Emacs.
From my experience Eclipse is good for Java, awful for everything else. Eclipse plugins always have some unfixed in-your-face bugs, and while working on a C++ project (with CDT, which is in good shape compared to the rest) I just gave up and switched back to Emacs.
Also, you always need to make little tweaks here and there, and waiting for Eclipse to load the whole project just so you can edit a simple file ... is just pain
Python (Score:5, Insightful)
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"!
Re: (Score:2)
Sorry you don't like Ruby's ability to use terse syntax... but in Ruby you also have the ability to make your code as readable as you like. Your choice... unlike Python.
You seem to be trying to make the point that choices are a bad thing?
Re:Python (Score:4, Insightful)
I'd agree with this completely. I've worked on a few large multi-language projects, and had to combine flavours of asm, C, C++, perl, prolog, bash, maple, haskell, java and a few others together to get what I want. After years of working this way, and stumbling over the questions posed in the article (integrating build processes, dev environment etc) I had my arm twisted into using Python. What a joy it has turned out to be.
As someone with a background in functional programming (most of my PhD was implemented in Haskell) the "functional" programming support in Python is a bit barren - but list comprehensions and bound methods are powerful enough for most tasks. The shell integration is nice, and the regexps are simple enough that I hardly touch perl these days (thank god...). Sage replicates most of the functionality that I would use maple or magma for.
A sibling (AC) poster complains that Python is not "the one true language" (tm) that the parent asserts it is. Well the parent makes no such assertion. I would assert that if you want a single True Language then Python would be a good candidate for you. But if you like multi-language programming then Python is good glue. Personally I like it as glue, shockingly other people may have different uses for it. Lastly, a general word on the whole monolithic application vs small tools in multiple languages. This isn't a new debate that has sprung up in the past decade. It has always been there. There isn't even really a debate, because the two approaches are building tools for disjoint sets of users.
If you eat your own dog-food, it's vital that you have the quickest turnaround time possible on adding new features and trying out new ideas. In a sense you are continually prototyping, never finishing. You are your own end-user, although occasionally other people may pretend. As a result your target audience is highly literate in the languages that you are using, and wants to maximise the power of the tools with a programmatic interface. The unix-philosophy was constructed to service this case.
If your target user is a non-programmer, who simply wants to be able to perform a task then you will need to wrap up the functionality in a non-programmatic way. GUIs are the best way (so far) of doing this. Because there is no intention of exposing an external call interface the overhead of mapping from language to language becomes pure overhead and there is a natural tendency towards a single monolithic language approach.
The interesting gap between these two areas is when your target audience spans the non-technical and the technical. This is where monolithic applications with APIs and scripting interfaces appear. I've got to say that AppleScript is quite cute in this area, purely because it's pervasive enough that it reminds me of Arexx all those years ago...
Re:Python (Score:5, Interesting)
Just to expand on a couple of your points:
But if you like multi-language programming then Python is good glue.
If you eat your own dog-food ... You are your own end-user, although occasionally other people may pretend.
If your target user is a non-programmer, who simply wants to be able to perform a task then you will need to wrap up the functionality in a non-programmatic way. GUIs are the best way (so far) of doing this. Because there is no intention of exposing an external call interface the overhead of mapping from language to language becomes pure overhead and there is a natural tendency towards a single monolithic language approach.
Almost 100% of *my* code is python these days, but I use it glue together any number of my old scientific applications that are often written in C. You can turn an archaic, unusable program into a slick, modern GUI or web service with very little code.
Most important here, though, are your points about who your target audience is. I think the submission author is missing that point, and it deserves to be made in no uncertain terms.
I am a scientist and a programmer. When I am writing for myself, I want to spend time on my data, not my program. So, I bang something out unix style - command line only, text I/O, move on with life. Usually, that happens in Python, but it might be in C, R, MatLab - whatever. Programs from my PhD are almost strictly command line. My co-workers from that part of my life had to learn command line if they wanted to work with my stuff. And you know what? They all did. Some of them got quite good at it, and I had more than a few inquiries about learning to program - they all saw the utility of what I was doing.
After finishing my PhD, I've worked a little for a start up and a government agency, both based on my PhD research. In both cases, I've played the role of the scientifically literate programmer. My users are somewhat tech savvy, but with few exceptions, they don't want command line tools.
A few of my old tools are still in use, though, just because they do one thing so very well, and a handful of people took the time to learn them. In return, I save them hours every day, which make those few tech savvy souls very happy.
The trend - what is likely to keep me employed for years to come - is building GUI/web programs for people who are good scientists, but don't understand.
I take a hybrid approach. What my end user sees is a standard Windows GUI. They happily click buttons to find some raw data, and then their analyzed data pops up automatically in Excel.
Behind the scenes though, my code is an amalgam of programs, most of which can still be run command line, just like they always could. The GUI code is wxPython, and it quite happily runs on Windows and Linux. I think it would run on a Mac, too, but I haven't had occasion to try it yet. It looks native in all of those environments, it never does anything to scare the users, and yet I can still do most of my analysis command line when I need to.
I'm currently developing a DNA sequence database. User interaction will all be web-based, data analysis will largely be a mixture of Python, MatLab, and C programs behind the scenes. My users won't have to care how their data gets analyzed - it'll just magically show up in the form they need it. They focus on further analysis and interpretation. Given who my users will be, this is a Very Good Thing(tm).
The point, though, is that my programming spans everything the submission discusses. These approaches aren't orthogonal. Pick the right one for the code you are working on.
If you are coding for yourself or for very tech savvy scientists, stay command line. It's easier to code and debug, and you'll get more done.
If you are selling to Joe Sixpack, a GUI with a Staples-style 'Easy Button' is probably the right choice. Add advanced options as stand-alone
Re: (Score:2)
It is not the Grail, just an embeddable scripting engine like many others.
Re: (Score:2)
Heh. I'd love to pick an environment (Score:4, Interesting)
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)
Re: (Score:2)
Man, I hated the last project where I had to write an HTML script to pipe data between.. wait what?
You can (Score:4, Insightful)
Do both. (Score:5, Insightful)
You already know one philosophy. You don't "unlearn" it by learning another. You just learn more. Gain experience!
Re:Do both. (Score:4, Interesting)
I don't think that's entirely true. I find the more languages I know the more times I accidentally write a statement from the wrong language or pause because I mix up the syntax in my head and have to remember which was which. There are more erroneous paths for neuron signals to travel down. I congratulate you for having a photographic mind, but we are not all that lucky.
Re: (Score:3, Informative)
Sometimes you do not notice... (Score:2)
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 b
Cross platform programming and multiple languages (Score:5, Interesting)
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 (Score:2)
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.
Re: (Score:2)
"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."
I thought that both GNOME and KDE (or more correctly, GTK+ and QT) had recently settled on D-BUS for inter-process messages on a single machine. There are D-BUS bindings for a variety of native (i.e. compiled) languages, and also for most popular interpreters and VMs, e.g. Python, Java, Mono, Ruby, Perl, etc., so it's cert
OpenVMS (Score:2)
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 [hp.com]
I don't know about you... (Score:2)
stay with the Unix philosophy (Score:3, Insightful)
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.
So you want to learn object oriented now? (Score:5, Funny)
Re: (Score:2)
That sounds like an unfortunate step into another layer of short-lived languages. Learn how to actually program: learn C.
Are you being sarcastic or something? In case you aren't, OO is here to stay (and has been for quite some time). It is an extremely powerful paradigm and I think it would be good for the author to take time to learn it.
C is fine for a lot of things (and the best tool for jobs such as embedded systems). That doesn't make OO "short-lived" or obsolete or anything along those lines.
Re: (Score:2, Informative)
I would read it as sarcasm. Try reading this manifesto [pbm.com] and updating Fortran to C to account for 20 years of shift in the industry. Anyone not using C is just eating Quiche.
Although his joke went over your head, it is worth pointing out that OO is not a paradigm. I know wikipedia thinks that it is, and so do a hoard of practically illiterate researchers publishing crap papers in junk conferences. But that doesn't make it true. Object Orientation is just a method of organisation for procedural languages. Alth
Re: (Score:2)
Do you realize that closures and OOP objects are semantically identical? Both are a function(s) and associated state. The only differences are syntactic (ignoring the unforgivable lack of GC in some languages claiming to be object oriented)
Re: (Score:2)
Shell scripting + Python works for me (Score:4, Interesting)
Don't do it, but support it. (Score:3, Interesting)
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.
Re: (Score:2)
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.
If there is one thing I positively hate, it's that.
The reason why is simple: those TCL/TK-and-then-call-a-commandline-tool apps never, never, never deal with error conditions correctly. In other words, it works while everything is fine and dandy - and then when the shit hits the fan, as it invariably does, you must still go out and delve into the commandline. And by definition that happens at a time when you have other problems to deal with.
So just Don't Do It, Ok?
Babel project (Score:3, Interesting)
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 [llnl.gov]
And where did you learn this "philosophy"??? (Score:3, Insightful)
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.
Re: (Score:3, Informative)
What are these mythical one-language projects? (Score:2)
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.
Are you a programmer or not? (Score:4, Insightful)
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.
Using one language (Score:3, Insightful)
Brittle glue code (Score:5, Insightful)
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.
Re: (Score:2)
Your subject actually seems very insightful...
Consider that any protocol you use will have to have an implementation in every language you're using, otherwise there's no point. That means that to tweak the protocol, you need to tweak the same code in each language, unless you use a shared library -- say, a C library that each language now has bindings to. But if you do that, you still have some of the same problem (maintaining the bindings), and a lot less of the point -- why have a protocol at all, instead
The Unix Way was never good at everything (Score:4, Insightful)
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.
Make it scriptable (Score:2)
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#
One solution... (Score:2)
It's all in the tools (Score:2)
history repeating (Score:2)
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 softw
gphnzykrzwki (Score:4, Interesting)
MultiLanguage Programming thoughts... (Score:3, Insightful)
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.
Re: (Score:2)
Re:Languages (Score:4, Interesting)
For many years now I've successfully developed with a multi-language model in Windows...
I do my low level code in C++ and encapsule it in a COM/ActiveX object, which I then can call from a Javascript script launched by the OS (through WScript.exe), server-side ASP pages and client-side DHTML pages or HTML Applications (HTA files). Both the "classical" COM/DCOM/ActiveX architecture and the new .NET were made to support integration of different languages and low level and high level code.
It's also possible to integrate Windows COM components and DLLs through Python scripts.
Through this model I developed quite a number of reusable parts which in practice I was able to integrate to a variety of projects. Having this separation between low level code and high level scripting as "glue" works great for me... it forces a layered design, makes for smaller binaries and cuts a lot on compilation times.
Re:Languages (Score:5, Insightful)
Re:Languages (Score:5, Funny)
I have serious text processing to do every time I see perl's syntax ;)
Re: (Score:3, Insightful)
What you describe about Perl is quite correct. And for many odd-ball functions and forms of processing, someone has already published a CPAN module for it, and in many (not all!) cases it's good enough.
But the level you mention, almost _everything_ is written in C. Many software packages that are allegedly in C++ could be switched to ANSI C in a single afternoon with s competent programmer, and in fact gcc's quiet compilation of both without error has led to a lot of people writing mostly C when they think
Re: (Score:3, Insightful)
...with varying levels of support (Score:3, Interesting)
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 l
Re:Languages (Score:4, Informative)
Graphics means using a well supported library, so Perl/Tk is the better choice than Java/Swing.
Um...I do not think "well supported library" means what you think it means. Tk is old and crufty. Swing isn't much better, but if you're doing graphics you're almost certainly doing it with SDL or some other accelerated system, and you wouldn't use Swing for that either.
Re:Languages (Score:4, Insightful)
Graphics means using a well supported library, so Perl/Tk is the better choice than Java/Swing.
Um...I do not think "well supported library" means what you think it means. Tk is old and crufty. Swing isn't much better, but if you're doing graphics you're almost certainly doing it with SDL or some other accelerated system, and you wouldn't use Swing for that either.
Tk is not as old and crufty as you think. It has been updated allot recently
Java/Swing actually has a very fast fully accelerated OpenGL drawing pipeline that is even supported on Linux. And yes many graphics heavy applications are buildt using Java/Swing The problem with swing is that it takes some heavy study time to learn how to do it correctly and not make your interface suck. But done correctly Java can keep up with most things out there. It's the done correctly part that is hard.
Re:Languages (Score:5, Informative)
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
Forth is more like a RPN programable calculator on steroids, it's stack based and used more for embedded systems, but I haven't looked at it in decades. In it's day it was used in 8 bit PC's to replace BASIC as a programming language.
so ... (Score:3, Funny)
the mods were reversed, too.
The moderators expected all the slashdot crowd to understand what was going on, right?
Re:Huh? (Score:5, Funny)
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? :)
Re: (Score:3, Informative)
If you're looking at it organically, you are understanding as much as you can at fi