3 ms·

Does anybody here have an idea why? I have heard reasons ("interfacing languages is a mess" and "you'd have to learn several languages" being the main ones), b

Does anybody here have an idea why? I have heard reasons ("interfacing languages is a mess" and "you'd have to learn several languages" being the main ones), but none I found compelling (especially when the alternative is C++). If it's irrational to reject multi-language solutions (I believe it is), why do people keep doing it?

to3m 14y ago
Tool support is usually poor, particularly for debugging. Interfacing languages is a mess, whether obviously (if you do it by hand) or hidden away (if you use SWIG). More code to deal with and step through. Higher chance of really ugly, hard-to-diagnose side effects from making a mistake on the C side. People working in both languages will regularly introduce bugs or perf problems because they get the languages mixed up as they're working. If you have less-technical people working in the higher-level languages, they'll will work around bugs in the C side, so you never hear about them until you fix them and break everything. I've worked on a number of mixed-language projects, and these same issues keep cropping up. Perhaps it depends on the team, but that is not something not everybody gets the chance to choose. My current mixed-language program (tcl/C++) is working out OK, with just me working on it, but tool support is poor, and hand-writing the language interfaces is annoying. (Notable exception: Visual Studio 2010 looks to offer pretty decent mixed native/managed debugging, and the CLR has good C++ interop support.)
- Ogre 14y ago
  Another exception, mixed Python and C/C++ debugging is apparently possible in gdb these days: http://misspent.wordpress.com/2012/03/24/debugging-cc-and-cpython-using-gdb-7s-new-python-extension-support/ http://misspent.wordpress.com/2012/03/24/debugging-cc-and-cp... I haven't had the opportunity to try it yet, I only heard about it a couple of days after the last time it would have been really really useful (naturally). But I know it's going to come up sometime.
  - to3m 14y ago
    Well well well... I've long liked the look of gdb 7 and its python scripting, and now it is looking better and better! I like it when I can retire a longstanding problem. (Luckily there's never any shortage of further problems to replace it with, so I won't run out of things to talk about.) Now seems doubly annoying that Apple make you use lldb or crappy old gdb 6 for iOS.
michael_miller 14y ago
It increases complexity. Your build system needs to be configured to support all the languages, you need code style guidelines for each of the languages, you need rules about when to use each language, you need to ramp up each new team member on the languages, etc. All this is overcomable of course, but it stacks the odds against using multiple languages.
stonemetal 14y ago
"interfacing languages is a mess" The little bit I have seen of multi language code would say that that holds, especially if the languages involved are not C and something else(What does a Python dictionary look like in Haskell? Answer: Crap unless you do a bunch of translation work). Debugging tools don't tend to work across language boundaries. etc. Maybe I gave up to quickly, but multiple languages in one executable just doesn't seem worth it. Writing components in different languages and have them communicating over some sort of shared bus, web services, whatever is simple and fairly effective.
Nelson69 14y ago
I think there is a bit of history missing here. When the DoD started what became the Ada mandate, they had some insane number of languages and projects scattered about. I don't remember the exact number but think something like 450-500 and this was from the 1960s and 70s when they still weren't terribly digital. At the macro level, that's impossible to maintain. I think a large part of the multi-language dislike came out of that. There is a giant difference between 3-6 languages and 400, it's also harder to get good people once you add a new technology to the stack that they need to know. There are generations of developers and IT/IS guys that have been trained and warned of the dangers of polyculture. That's why people keep doing it.

to3m 14y ago

Tool support is usually poor, particularly for debugging. Interfacing languages is a mess, whether obviously (if you do it by hand) or hidden away (if you use SWIG). More code to deal with and step through. Higher chance of really ugly, hard-to-diagnose side effects from making a mistake on the C side. People working in both languages will regularly introduce bugs or perf problems because they get the languages mixed up as they're working. If you have less-technical people working in the higher-level languages, they'll will work around bugs in the C side, so you never hear about them until you fix them and break everything. I've worked on a number of mixed-language projects, and these same issues keep cropping up. Perhaps it depends on the team, but that is not something not everybody gets the chance to choose. My current mixed-language program (tcl/C++) is working out OK, with just me working on it, but tool support is poor, and hand-writing the language interfaces is annoying. (Notable exception: Visual Studio 2010 looks to offer pretty decent mixed native/managed debugging, and the CLR has good C++ interop support.)

Ogre 14y ago
Another exception, mixed Python and C/C++ debugging is apparently possible in gdb these days: http://misspent.wordpress.com/2012/03/24/debugging-cc-and-cpython-using-gdb-7s-new-python-extension-support/ http://misspent.wordpress.com/2012/03/24/debugging-cc-and-cp... I haven't had the opportunity to try it yet, I only heard about it a couple of days after the last time it would have been really really useful (naturally). But I know it's going to come up sometime.
- to3m 14y ago
  Well well well... I've long liked the look of gdb 7 and its python scripting, and now it is looking better and better! I like it when I can retire a longstanding problem. (Luckily there's never any shortage of further problems to replace it with, so I won't run out of things to talk about.) Now seems doubly annoying that Apple make you use lldb or crappy old gdb 6 for iOS.

michael_miller 14y ago

It increases complexity. Your build system needs to be configured to support all the languages, you need code style guidelines for each of the languages, you need rules about when to use each language, you need to ramp up each new team member on the languages, etc. All this is overcomable of course, but it stacks the odds against using multiple languages.

stonemetal 14y ago

"interfacing languages is a mess" The little bit I have seen of multi language code would say that that holds, especially if the languages involved are not C and something else(What does a Python dictionary look like in Haskell? Answer: Crap unless you do a bunch of translation work). Debugging tools don't tend to work across language boundaries. etc. Maybe I gave up to quickly, but multiple languages in one executable just doesn't seem worth it. Writing components in different languages and have them communicating over some sort of shared bus, web services, whatever is simple and fairly effective.

Nelson69 14y ago

I think there is a bit of history missing here. When the DoD started what became the Ada mandate, they had some insane number of languages and projects scattered about. I don't remember the exact number but think something like 450-500 and this was from the 1960s and 70s when they still weren't terribly digital. At the macro level, that's impossible to maintain. I think a large part of the multi-language dislike came out of that. There is a giant difference between 3-6 languages and 400, it's also harder to get good people once you add a new technology to the stack that they need to know. There are generations of developers and IT/IS guys that have been trained and warned of the dangers of polyculture. That's why people keep doing it.