(Prolog + LISP + Erlang) with integration issues versus C++

[Roger Larsson]

On Thursday 25 August 2005 08.18, Dev Functional wrote:
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
>  1. Prolog (enumerating device drivers, goal seek)
>  2. LISP   (classical AI stuff, inference)
>  3. Erlang (server, communication and distributedness)
>
> The products we have used are
>  1. gprolog
>  2. clisp
>  3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
>
> The team has quickly built the components (less than 3 months)
> and proven the idea.
>
> The management is worried about our choice of three languages
> and has strongly suggested a relook at this strategy.
>
> The External Consultant (Subject Matter Expert) has suggested that -
> 0. since the individual components are implemented,
Does the External Consultant have enough experience/data to
make these claims?

>    the idea is partially proven

Idea is proven but not only that - it is mostly implemented too!
Reimplementation in any language will take time...

Is there an estimate on how much time this reimplementation
will take?

> 1. the language barriers will cause problems in integration
>    and performance
Performance problems can never be assumed to show up,
only measured...

My suggestion would be to try to make a very simple interface
between the components. Keep them in separate
processes, and use sockets/pipes/... Data transmitted could be
specified on byte level, as plain text, or as XML.

A1. Implement the glue
A2. Measure performance problem.
A3. Try to solve performance problem with hardware
A4. Tune or reimplement the measured to be problematic part.
A5. Repeat from A2. until performance is acceptable
A6. Start selling (the hardware of this solution will be expensive)
A7. Earn money
A8. Try to solve the cost problem (will disappear over time)

B1. Reimplement everything in C++, probably quick and dirty due
      to time to market concerns.
B2. Test for implementation problems (wrong results fast)
B3. Fix bugs 
B4. Repeat from B2, until quality is acceptable
B5. Start selling
B6. Earn money
B7. Maintain spaghetti code

> 2. the long-term success and reach of the product will be
>    based on complete implementation in C++.

What about the short time - time to market?

> 3. The Visualizer will be implemented in OpenGL and C++ based modules
>    will be quite easy to integrate.

Yet another component and language!
Suggest that the External Consultants firm could do this implementation.
That could be their agenda anyway...

> 4. C++ performance will be good if a ANN component is added later
>    due to customer request.

ANN?

> 5. Multi-language maintenance costs will be high
The complexity of the individual components in C++ will (probably) be higher.
Number of source code lines will definitely be.

>
> The team is disappointed, since the effort in learning the languages
> will be wasted. The 6 developers are from C/Java background.
Knowledge is never a waste - I assume you have been payed :-)

Let me add a problem of my own:

6. If the target environment is embedded devices. The size of runtime needed
for any of the suggested languages, including C++, could add to the cost of
the device - especially if all these languages were needed everywhere.

/RogerL

>
> Greatly appreciate if the more experience members of this group
> share their experiences and put forward the suggestions.
>
> I need to present a case for the proposed solution, on the coming
> Monday.
>
> Thanks in advance.
>
> thanks
> Dev.