I got into an interesting conversation with my coworker. For a new product that's being developed, he's integrated C++ and Python together. Currently, we have a lot of legacy code in C++, so it made sense to integrate a scripting language in, to be able to handle some of the more flexible pieces and allow reconfigurability to our application from outside the development group. Where he's taken the design seems to be more than my original thoughts, where he's now envisioning that the entire application is Python, with bindings to C++ for performance-related code. The interesting thing here is I see this as a shift from the original intention, which was more to allow Python to empower C++, than for Python to replace C++. Now, fast forward to today. Recently I've been playing a bit with Java and hearing some good things about .Net, which I have yet to use. It sounds like a natural progression to improving developer productivity would be to use a language like Java or C#, which is structured, provides type-safety, yet, also supports a more rapid form of development than C++. One model I was thinking of along these lines would be using C# or Java as the main application, using Python/Lua/Ruby as the scripting language and using C++ to support the legacy code and provide high-performance libraries, when needed. Then there would need to be binding between the languages (such as using the combination of JNI, Jython, Boost.Python/SWIG). The bonus here would be that Python takes more of a scripting role, empowering the other language (Java/C# in this case). C++ would take more of a library provider role. Ultimately I see it as there being classifications of languages: A) Compiled/Static-type checking/High-performance - C++ B) VM/Static-type checking/Faster development/Lots of high quality libraries - Java/C# C) Scripting/Rapid prototyping/Max configurability - Python/Ruby/Lua As such, I could see them all being useful for different purposes. I guess the first question is, is it too much burden to have three languages in an application? Another question is a general question of what the appropriate model is when integrating a scripting language. This is kind of up in the air, so any ideas/suggestions/telling me I'm insane/etc... are most welcome.

Please dont mix in Python and Ruby with Lua.
Python and Ruby are beautiful programming languages, not script.

Quote:Original post by ibebrett
Please dont mix in Python and Ruby with Lua.
Python and Ruby are beautiful programming languages, not script.

I consider any language with a dynamic-type system to be on a different plane than any language with a static-type system. You can make programs with Python and Ruby, for sure, but are they better suited for large applications than C# or Java? I think the answer is no. They seem better suited for scripting.

Sun is also migrating JVM to VM.

That aside, I try to avoid hodge-podge of integration. Just randomly jumbling things together is an absolute interoperability and maintenance nightmare. Let alone if developers change.

As such projects grow, overhead grows to incredibly levels.

Unfortunately, business world has learned all about it long time ago, and decided to move everything to web applications.

Client is a simple web browser, server runs independent services, connected with universal APIs and frameworks. From completely generic interfaces such as SOAP, down to various high-performance APIs.

The way you presented your experience sounds like your experience is somewhat limited, and you're incredibly excited over the new shiny hammer. In the long run however, that gets more complicated.

For example, Java, C# and Python are portable, JNI and other bindings aren't. That means, for each native binding, your problem complexity multiplies by N platforms you need to support. The number of failure points therefore increases exponentially. And trying to link all that statically quickly results in hundreds or thousands of failure modes.

Quote:As such, I could see them all being useful for different purposes

Rapid throwaway prototypes. Look at past experiences when such "if it builds, ship it" methodology lead to catastrophic failures, and development costs of astronomic proportions.


Yes - integration can bring benefits. But before considering it:

- Do you have developers with expertise in such environments?
- Can you support N^M complexity and dependency (multiply that by various versions of languages and platforms)
- Can you afford considerably more complex cost?
- Can your application run in form of services over a uniform client (the cost analysis, no matter the hype and statistics, are clear on this - unless you work with portable, universal, networked APIs, the costs will kill you)
- How much "performance" will you get? Gaining 20% performance is not worth 50% more development time. Losing 20% performance is worth 50% shorter development time.

And another most important thing: Getting a decent Java developer is hard. Getting someone proficient with planning, design, integration, testing and deployment of such applications is incredibly difficult. Can you pay a team of people to integrate all those 6 languages?

If you really insist on mixing all that, use web services and other SOA architectures. They are the closest you're going to get to manageable development.

Antheus, I appreciate your detailed response. Part of this discussion is that I'm starting to come around to the idea that C++ may be dying a bit, and it may time to consider a language that provides more that is standard. C# or Java come up because I think that's where industry trends are going, because the benefits seem to outweigh the downsides.

I will say this, for now we're a Windows-only shop and that's unlikely to change for quite a while. The fact is we've been using C++, so any choice of a higher-level language is likely to be more portable.

As for my experience, I have a lot of C++ experience. I have some Python experience. I've done some Java in the past, but nothing too major, it's nowhere near my C++ experience. I've never used C# or Ruby.

The reason why C++ is still in the picture in the model I mentioned is that there are some APIs provided by the R&D department, for example, that absolutely need to run as quickly as possible. There's no compromise on those. There's also legacy code. For things that don't fall into either category, I'm thinking I'd like to move away from C++, even though I've loved C++ for a long time.

I guess the real question is whether or not the benefits outweigh the complexity.

I will consider the possibility that I may be getting too excited about the shiny new hammer.

Anyway, are you saying, that bindings are better done non-natively, but instead through an RMI/RPC-like framework?