Slashdot Mirror


Hope For Multi-Language Programming?

chthonicdaemon writes "I have been using Linux as my primary environment for more than ten years. In this time, I have absorbed all the lore surrounding the Unix Way — small programs doing one thing well, communicating via text and all that. I have found the command line a productive environment for doing many of the things I often do, and I find myself writing lots of small scripts that do one thing, then piping them together to do other things. While I was spending the time learning grep, sed, awk, python and many other more esoteric languages, the world moved on to application-based programming, where the paradigm seems to be to add features to one program written in one language. I have traditionally associated this with Windows or MacOS, but it is happening with Linux as well. Environments have little or no support for multi-language projects — you choose a language, open a project and get it done. Recent trends in more targeted build environments like cmake or ant are understandably focusing on automatic dependency generation and cross-platform support, unfortunately making it more difficult to grow a custom build process for a multi-language project organically. All this is a bit painful for me, as I know how much is gained by using a targeted language for a particular problem. Now the question: Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"

6 of 371 comments (clear)

  1. StupidPeopleTrick by StupidPeopleTrick · · Score: 5, Insightful

    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

  2. One time..... by phantomfive · · Score: 5, Interesting

    One time at my company, a programmer who must have been in his 50s came in with a resume that had no less than 25 programming languages. I was interviewing him, so I asked him, "Which of all these languages do you like most?" I figured he'd have some nuanced answer dealing with precision in Ada or flexibility in Lisp, or the happiness of Perl. Nope. "Shell scripting" he said. My jaw nearly dropped. He said, "It easily lets me tie all these different building blocks together. No other language can do that." He didn't end up working with us but it was one of the most educational interviews I ever did. I like interviewing more experienced programmers, even if they don't end up working for us, just because something interesting ALWAYS happens. I could tell you stories........

    As for the question, I think in part he's right, it is good to have a separate mailer from the browser from the calendaring program, and have ways for them to communicate. Some systems do work in this way, for example, most chess programs will let you change your chess engines, separating the front end from the back. Might want to check how they do it. Other programs on OS X will let you manipulate variables and send messages using applescript or automator. Also, on OS X, there's no reason to not use awk or sed. But definitely learn C++ and Java, they're used everywhere and once you know one, the other's not too difficult.

    Maybe if you were more specific in the question you asked we could answer better? Or were you just trying to encourage all programmers on slashdot to program more modularly?

    --
    Qxe4
    1. Re:One time..... by FlyingGuy · · 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.

      --
      Hey KID! Yeah you, get the fuck off my lawn!
  3. Yes by H0p313ss · · 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.

    --
    XML is a known as a key material required to create SMD: Software of Mass Destruction
  4. Yep by Sycraft-fu · · 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.

  5. Re:Depends, really by Shados · · 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 :)