Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hope For Multi-Language Programming?

Soulskill posted more than 5 years ago | from the one-and-done dept.

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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Languages (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27020591)

Programming Languages are just tools. And, surprise, languages of the same type are equivalent.

Go study the fundamentals of CS.

The rest will follow.

Re:Languages (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27020801)

good point. He needs to learn fundamentals, like how to eat out a spic's asshole, how to suck off a nigger, and how to take aryan brotherhood cock up the ass That will come in handy when he's in prison. and that's not the sort of thing you can learn from a website number.

Re:Languages (1, Insightful)

BadAnalogyGuy (945258) | more than 5 years ago | (#27020805)

Yes, it may be true that languages are essentially equivalent, but that doesn't mean that some languages don't make some tasks easier for the programmer than the other.

If you had a task that had serious text processing, surely you would use C++ over Haskell or Lisp. On the other hand, if you needed to do AI, you would use Forth instead of Pascal. Graphics means using a well supported library, so Perl/Tk is the better choice than Java/Swing.

So while programming languages may be equivalent at some theoretical baseline, they are designed to address specific issues and often provide better support for some tasks and worse support for others. Using a combination of languages is a very good idea, but it also takes a lot of discipline to keep interfaces well defined.

Re:Languages (4, Insightful)

Antique Geekmeister (740220) | more than 5 years ago | (#27020921)

If I had serious text processing, I'd use Perl. And do.

Re:Languages (4, Funny)

CarpetShark (865376) | more than 5 years ago | (#27021265)

If I had serious text processing, I'd use Perl. And do.

I have serious text processing to do every time I see perl's syntax ;)

Re:Languages (3, Informative)

FishWithAHammer (957772) | more than 5 years ago | (#27020973)

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 (4, Insightful)

1gig (102295) | more than 5 years ago | (#27021055)

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 (0, Flamebait)

atraintocry (1183485) | more than 5 years ago | (#27021215)

Tk is never a good choice.

Re:Languages (0)

Anonymous Coward | more than 5 years ago | (#27021251)

I am astounded at the stupidity of the Slashdot moderating audience to mod you +5 insightful, rather than +5 funny.

Re:Languages (2, Insightful)

blool (798681) | more than 5 years ago | (#27021427)

Oh wow, my eyes glazed over the sentence the sentenced that had "serious text processing" in it. I am not very familiar with Forth so the next part seemed plausible. Finally my tired eyes spotted an anomaly; surely Java/Swing is on par if not more "well supported" than Perl/Tk. But the comment said +4 insightful my mind protested! Oh wait a second, whats this? It's bad analogy guy! I've seen his comments before I remember, amused at how I had caught the joke just barely before it passed over my head. (A look at the 6 other comments here shows that there was plenty of *whoosh* to go around though)

Re:Languages (1)

un_om_de_cal (1387133) | more than 5 years ago | (#27021495)

If you had a task that had serious text processing, surely you would use C++ over Haskell or Lisp. On the other hand, if you needed to do AI, you would use Forth instead of Pascal. Graphics means using a well supported library, so Perl/Tk is the better choice than Java/Swing.

Hint to slashdot mods: all the examples are reversed.

so ... (2, Funny)

reiisi (1211052) | more than 5 years ago | (#27021523)

the mods were reversed, too.

The moderators expected all the slashdot crowd to understand what was going on, right?


It's a big umbrella (3, Interesting)

cptdondo (59460) | more than 5 years ago | (#27020605)

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.

Running exec helps (0)

Anonymous Coward | more than 5 years ago | (#27020727)

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.

Re:It's a big umbrella (1)

thebigbadme (194140) | more than 5 years ago | (#27020795)

So it all comes out in the wash, and as the great Yogi Berra said " When you come to a fork in the road, take it. "

there, fixed that for ya

Re:It's a big umbrella (3, Interesting)

jerep (794296) | more than 5 years ago | (#27021045)

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 maintain compiled executables for simple tasks.

On a side note: I also recently found out about rdmd [] a few days ago, you might want to add that to your shell's arsenal ;)

Re:It's a big umbrella (2, Insightful)

avanderveen (899407) | more than 5 years ago | (#27021115)

"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 experiences. Experience in functional programming languages (and scripting) goes a long way for your ability to efficiently and effectively use an imperative language. This is why a lot of colleges and universities are starting to teach Scheme as an introductory language instead of Java.

There is hope for a multi-language development process, just make sure that your capable with the languages that are more prevalent

Depends, really (4, Interesting)

Shados (741919) | more than 5 years ago | (#27020607)

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:Depends, really (1)

BadAnalogyGuy (945258) | more than 5 years ago | (#27020829)

How do you like F#?

Re:Depends, really (5, Interesting)

Shados (741919) | more than 5 years ago | (#27020891)

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 :)

A bit too general and a bit too fanboy (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27021259)

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 ?

I do like formal programming, it has its role. I just wish that your article was more "real".

Re:Depends, really (0)

Anonymous Coward | more than 5 years ago | (#27021357)

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 :)

Let's just hope this company doesn't blow up the stock market again, or there vaguely will be hell to pay, linux or no :)

Re:Depends, really (1)

lokedhs (672255) | more than 5 years ago | (#27020919)

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.

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:Depends, really (1)

Shados (741919) | more than 5 years ago | (#27020953)

That was an example of my personal responsibilities:) We have more unix machines than Windows, hehe.

Re:Depends, really (0)

Anonymous Coward | more than 5 years ago | (#27021085)

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.

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.

When all you have is a hammer, everything looks like a nail... I wish this book, the Unix Hater's Handbook got a sequel: []

Re:Depends, really (1)

ClosedSource (238333) | more than 5 years ago | (#27021179)

"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).

Re:Depends, really (0, Interesting)

Anonymous Coward | more than 5 years ago | (#27021335)

the text was always the customization of optimized and specialized c code. the ratio of script to binary was always very small. and most of the text (for perl) quickly compiled into large swatchs of native c library segments. the power of the unix model was the ability to adapt it.

it wasnt that you had programs piping large volumes of text around. it is more often void main return values and signals or the occasionsal 1 line of text returning from highly cached microprograms. yes there is tremendous overhead in invoking those apps, but they are almost always the startup process.

consider that the windows alternative is vb + COM libraries (in mem shared library + state references). that is all fine and good for efficiency, but my experience is tremendously less stability. consider the com equvalents in linux. kde and gnome. yes you can use them without persistent services - but we dont. so instead of highly stable single processes that use locks and file based resources, we have buggy interdependent code. one process hang takes down a bunch of services. i have to kill 3 processes every time pidgin locks evolution-data which locks evolution which locks beagle and tomboy notes. this happens daily when i have integration enabled. If they stuck to the old way of a few rpcs and direct file accesses and maybe a few named pipes then life would still feel like unix. But noooo we have to be windowsy.

Yes, .NET may actually be the best bet (3, Insightful)

benjymouse (756774) | more than 5 years ago | (#27021457)

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 member resolution principles.

And the good thing is that because of Mono all of this will (eventually) be available platforms beyond Windows as well.

Aside: PowerShell is another example of a (dynamic) "language" tapping into the .NET ecosystem. Instead of opaque small "tools" which

  • often have their own small scripting languages (think awk, sed, grep)
  • are opaque in the sense that you can only send them off with an input stream and wait for them to produce an output stream (i.e. no interaction)
  • are text-based so that any other data type has to be serialized/parsed to/from text

PowerShell uses objects in the pipeline. Tools can interact with the objects (they can invoke methods, set/get properties). Tools can create new finer grained objects and interact with them, e.g. a download class, remote control Internet Explorer Windows, Word documents. Basically anything which exposes its functionality through a COM or .NET class.

StupidPeopleTrick (5, Insightful)

StupidPeopleTrick (1006681) | more than 5 years ago | (#27020641)

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

Yep (5, Insightful)

Sycraft-fu (314770) | more than 5 years ago | (#27020887)

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:StupidPeopleTrick (1)

plover (150551) | more than 5 years ago | (#27021169)

Maintenance can be really expensive, especially if you have to maintain a bunch of old projects written in 25 different languages. So for all the reasons you just mentioned, a really big, monolithic, waterfall shop may have standardized on just a few languages, and you won't get a real choice. They will probably tell you when you are being interviewed that the job will be C++ or Java or C#, and the scripting language will be perl or vbscript or sh or whatever they use, so it shouldn't be a surprise.

Re:StupidPeopleTrick (1)

TapeCutter (624760) | more than 5 years ago | (#27021225)

Yes, total freedom to mix and match is great from the developer's POV but in an enterprise setting application developers rarely get to see the full system, even something seemingly inoccuous such as changing an error/log message can have upstream consequences that exceed the cost of development by more that an order of magnitude.

Is there a contradiction... (1)

PaulBu (473180) | more than 5 years ago | (#27021317)

... 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.

do not sweat it and enjoy! (4, Informative)

jackb_guppy (204733) | more than 5 years ago | (#27020649)

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..... (5, Interesting)

phantomfive (622387) | more than 5 years ago | (#27020663)

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?

Re:One time..... (1)

FlyingGuy (989135) | more than 5 years ago | (#27021315)

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:One time..... (1)

cyborch (524661) | more than 5 years ago | (#27021403)

Whoa! Hold back on the anger kiddo. Are you looking for a job and missed an opportunity you really wanted? There are many reasons not to hire a guy. One could be a really bad attitude - kind of like the one you just demonstrated.

Re:One time..... (1)

BorgDrone (64343) | more than 5 years ago | (#27021433)

That much experience huh? So why did you pass him up?

Mabye he passed them up.

Re:One time..... (2, Interesting)

phantomfive (622387) | more than 5 years ago | (#27021511)

The main problem with old guys I've found is that they are inflexible (that's a gross generalization, of course, and not always true). In his particular case he was looking for a consulting gig, not a full time position, and applying for a job was his way to try to get in the door. I had another old guy sit in the interview and tell me how he had spent six months at his previous job working on something his employer had asked him not to, but he had also done some amazing technical stuff. It's not always about technical ability...

My suspicion is that anyone who's been around that long and who has all their marbles in a row doesn't need to look for a job very often. They are either rich, in management, or have connections.

Don't understand the premise (2, Interesting)

quax (19371) | more than 5 years ago | (#27020667)

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.


Re:Don't understand the premise (0)

Anonymous Coward | more than 5 years ago | (#27020837)

I have to say, I didn't understand the author's premise either.

Has there been a trend in business to only focus on one language for everything? Not from what I've seen.

If anything, I think you'll NEED to learn different languages (which is actually more like learning different methodologies) if you wish to KEEP a career as a developer.

On the other hand, I don't think its such a great idea to try to master EVERYTHING, or try learning EVERYTHING at the expense of not being "competent" with the "core" languages that will be your bread and butter.

Its best to have a good grasp of basic computer science, and then understand the philosophic methodologies driving the creation of a particular language. For example, there is no point in learning LISP if you don't realize its about stack oriented processing and object oriented processing. There's no point in learning C in order to write scripts that process text patterns.

Yes (5, Interesting)

H0p313ss (811249) | more than 5 years ago | (#27020669)

Should I suck it up and learn to do all my programming in C++/Java?


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 (4, Insightful)

Anonymous Coward | more than 5 years ago | (#27020843)


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 (1)

whyloginwhysubscribe (993688) | more than 5 years ago | (#27021437)

Me too. In the last 10 years I've covered many languages but since being made redundant, the last three doing nothing have been the happiest...

Re:Yes (1)

viljun (1267170) | more than 5 years ago | (#27021509)

focusing on a single technology, you don't waste time on the glue.

The original question was if there is any method to avoid the time wasted on the glue when the components are ready. Or is there a fast way to glue things up when the components are ready.

Eclipse (4, Informative)

setagllib (753300) | more than 5 years ago | (#27020683)

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:Eclipse (1)

zippthorne (748122) | more than 5 years ago | (#27020799)

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:Eclipse (1)

PitaBred (632671) | more than 5 years ago | (#27020931)

Some languages work better for different jobs. Depending on what processing jobs your project calls for, choose the language best suited. Hell, even C++ allows inline assembly for jobs where assembly is better suited than letting the compiler choose what registers to fill and so on.

Re:Eclipse (0)

Anonymous Coward | more than 5 years ago | (#27021073)

Eclipse is slow as shit and has huge lack of features (refactoring, method extraction, etc...) SlickEdit is miles ahead for c/c++ development.

Re:Eclipse (1)

ClosedSource (238333) | more than 5 years ago | (#27021191)

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.

Huh? (0)

Vellmont (569020) | more than 5 years ago | (#27020685)

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?

Python (4, Insightful)

Pope Raymond Lama (57277) | more than 5 years ago | (#27020707)

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.
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. do you use .net? Ditto - there is ironpython!
Ah, you need to exchange data from parents of your app in the jvm with native code in .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.

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:Python (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27020889)

This is plain, flat out WRONG. And its not even because I don't like python.

Religious cretins think all morality and all answers come from one philosophy or one language.

Python doesn't do crap if you want to get into functional programming. You can't write a OS kernel in Python. Python can't run on an embedded chip. Good luck using Python to write real-time graphics applications.

I saw this garbage attitude 20 years ago with PASCAL. And even BASIC programmers were wrong.

Re:Python (1)

kiddygrinder (605598) | more than 5 years ago | (#27020975)

I don't even think he was hinting that python was the "one" language, you can possibly tell that by the way he was talking about it works so well with c++ and java.

Re:Python (1)

Jane Q. Public (1010737) | more than 5 years ago | (#27021039)

Sure it does. But flexibility WITH readability counts even more, if you are a professional programmer.

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 (3, Insightful)

smallfries (601545) | more than 5 years ago | (#27021261)

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...

Heh. I'd love to pick an environment (3, Interesting)

NotQuiteReal (608241) | more than 5 years ago | (#27020713)

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)

Re:Heh. I'd love to pick an environment (1)

setagllib (753300) | more than 5 years ago | (#27020719)

Man, I hated the last project where I had to write an HTML script to pipe data between.. wait what?

Bzzzt (1, Informative)

Anonymous Coward | more than 5 years ago | (#27021023)

HTML, while not compiled, is not a scripting language.

Re:Bzzzt (0, Flamebait)

pem (1013437) | more than 5 years ago | (#27021069)

Did you replace the batteries in your smoke detector and in your sarcasm-ometer last fall?

You can (4, Insightful)

Anonymous Coward | more than 5 years ago | (#27020749)

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.

Re:You can (0)

Anonymous Coward | more than 5 years ago | (#27020915)


Do both. (4, Insightful)

Skreech (131543) | more than 5 years ago | (#27020755)

You already know one philosophy. You don't "unlearn" it by learning another. You just learn more. Gain experience!

Re:Do both. (1)

FuryOfTheGods (1466643) | more than 5 years ago | (#27021003)

...You just learn more. Gain experience!

Ding, just hit lvl 80 guys!

Re:Do both. (4, Interesting)

Tablizer (95088) | more than 5 years ago | (#27021027)

You already know one philosophy. You don't "unlearn" it by learning another. You just learn more. Gain experience!

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:Do both. (0)

Anonymous Coward | more than 5 years ago | (#27021103)

Yeah, it's a pretty dumb question he asked. Tune in next time for the high quality, thought provoking Ask Slashdot discourse you have come to expect!

Re:Do both. (3, Informative)

pgn674 (995941) | more than 5 years ago | (#27021171)

Not necessarily. In psychology, interference theory proposes that people forget information because of competition from other material. One kind of interference is retroactive interference [] , which occurs when previously learned information interferes with the retention of new information.

Sometimes you do not notice... (1)

shutdown -p now (807394) | more than 5 years ago | (#27020759)

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.

Re:Sometimes you do not notice... (0)

ljw1004 (764174) | more than 5 years ago | (#27020859)

Agreed. Here at Microsoft it's not uncommon to see a single solution containing sub-projects in two or more of F#, IronPython, C# and Visual Basic.

What's nice is that the object model is shared by all of them: objects, fields, methods, interfaces, inheritance in any language is directly accessible from all the others.

I use each language for its particular strengths -- F# for the rapid prototyping, parsing, maths. Python just for awesomeness. VB or C# for serious big systems. And as you say VB especially for XML literals.

I've also switched my personal web-services from Debian/Apache/PHP or Python over to OpenSuse/Apache/Mono/VB. Call me old-fashioned, but I just found them easier to get right with strong typing.

Re:Sometimes you do not notice... (0)

Anonymous Coward | more than 5 years ago | (#27020941)

Yes, people piss on .NET/mono, and yet don't realize the threat and benefit it presents as a commercial development tool.

Yup, if you wanted to stick to only a hammer in your toolbox, you could learn .NET/, and be sure an enterprise would have no problem hiring you, even after no one uses VB or C# anymore. Provided of course, they had a clue.

My suggestion: Learn QT (-1, Troll)

bogaboga (793279) | more than 5 years ago | (#27020767)

Yes, learn QT [] and help out with KDE [] . I haven't done much programming with QT [] , I am confident when I say it's a lovely, powerful and compelling environment to program in. Its cross platform capabilities cannot be under estimated. VLC [] was created using QT [] .

So go ahead, learn QT [] , help out with KDE [] and make subsequent releases even more formidable.


Can someone mod this link spammer down? (0)

Anonymous Coward | more than 5 years ago | (#27020947)

Can someone mod this idiot with all his double links down? Such behaviour shouldn't be encouraged, it reads like a bad Wikipedia article.

Re:My suggestion: Learn QT (1)

nawcom (941663) | more than 5 years ago | (#27021501)

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. []
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.

Are you daft? (0)

Anonymous Coward | more than 5 years ago | (#27020779)

If someone tells you what to do are you going to do it? Don't bother thinking for yourself.

Cross platform programming and multiple languages (4, Interesting)

drolli (522659) | more than 5 years ago | (#27020781)

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)

JVM languages (0)

Anonymous Coward | more than 5 years ago | (#27020785)

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 (1)

RichiP (18379) | more than 5 years ago | (#27020791)

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.

OpenVMS (1)

Nutria (679911) | more than 5 years ago | (#27020823)

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. []

I don't know about you... (1)

zullnero (833754) | more than 5 years ago | (#27020847)

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.

stay with the Unix philosophy (2, Insightful)

martin-boundary (547041) | more than 5 years ago | (#27020877)

The kitchen sink approach to programming an application is an unstable approach, and usually a symptom of bad or no design. Sooner or later, large monolithic programs end up splitting into a set of libraries or "drivers" and some simple logic, possibly a scripting language designed to build mini-apps on top of a "platform" etc. That's reinventing the unix approach again, in all but name, badly. If you stay with the unix philosophy, at least you'll have a small competitive advantage over time as well as a more flexible mindset to recognize solutions to problems which arise with kitchen sink programs.

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? (4, Funny)

Antique Geekmeister (740220) | more than 5 years ago | (#27020895)

That sounds like an unfortunate step into another layer of short-lived languages. Learn how to actually program: learn C.

Re:So you want to learn object oriented now? (1)

D Ninja (825055) | more than 5 years ago | (#27021049)

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:So you want to learn object oriented now? (2, Informative)

smallfries (601545) | more than 5 years ago | (#27021181)

I would read it as sarcasm. Try reading this manifesto [] 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. Although it helps code maintenance and does a better job of unit management that modules alone, it doesn't change the underlying computational paradigm. I say procedural languages because class-based programming in functional languages is actually a different type of beast although it gets called OO to appeal to people from an imperative background.

Re:So you want to learn object oriented now? (1)

RightSaidFred99 (874576) | more than 5 years ago | (#27021159)

Yeah, those OO languages are just flashes in the pan. Those, and "algorithms". Flashes in the pan. Also, "the web" - another flash in the pan.

You should be able to do both (1)

moocat2 (445256) | more than 5 years ago | (#27020901)

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.

Shell scripting + Python works for me (4, Interesting)

lbates_35476 (901961) | more than 5 years ago | (#27020907)

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.

Don't do it, but support it. (2, Interesting)

SanityInAnarchy (655584) | more than 5 years ago | (#27020983)

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.

Babel project (2, Interesting)

memoryhole (3233) | more than 5 years ago | (#27020985)

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. []

to unlearn (0)

Anonymous Coward | more than 5 years ago | (#27020993)

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.

And where did you learn this "philosophy"??? (2, Insightful)

Jane Q. Public (1010737) | more than 5 years ago | (#27020997)

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.

Through stranger eons... (0)

Anonymous Coward | more than 5 years ago | (#27021007)

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.

What are these mythical one-language projects? (1)

Len (89493) | more than 5 years ago | (#27021035)

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.

Stick With What You Enjoy (0)

Anonymous Coward | more than 5 years ago | (#27021043)

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.

Are you a programmer or not? (3, Insightful)

Weaselmancer (533834) | more than 5 years ago | (#27021067)

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 (2, Insightful)

Kingrames (858416) | more than 5 years ago | (#27021113)

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.

Brittle glue code (4, Insightful)

cerberusss (660701) | more than 5 years ago | (#27021129)

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:Brittle glue code (1)

SanityInAnarchy (655584) | more than 5 years ago | (#27021305)

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 of just a common API?

For that reason, I'd avoid inventing your own protocol from scratch, unless you have the hubris to think there's something wrong with all the existing ones, and that you'll do better. (I know I do, but for now, I can't really find too much wrong with HTTP and things like JSON or YAML for most purposes.) Stick to things that have common libraries, making them easy to interface with from any language. And try to stick to things that are simple enough that you could write your own library... not that you want to.

.net (1)

McBeer (714119) | more than 5 years ago | (#27021193)

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.

The Unix Way was never good at everything (3, Insightful)

AdamInParadise (257888) | more than 5 years ago | (#27021399)

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.

Popular != Monolithic - Java in the console (0)

Anonymous Coward | more than 5 years ago | (#27021525)

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

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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>