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

[Roger Larsson]

On Thursday 25 August 2005 11.20, Dev Functional wrote:
> On 8/25/05, Roger Larsson <roger.larsson@REDACTED> wrote:
> > Is there an estimate on how much time this reimplementation
> > will take?
>
> Estd Time =
>    Training Time in C++
>    +  Redesign in OO
>    +  Implementation Time
>    +  Debugging Time.
>
> about 6 months (which is double time).

Is this 6 months times X person? What is X?
But there is a part before "Redesign in OO"!
All currently used languages are very strong in certain areas,
and since they were selected for this reason they are most certainly used!
Sow how to implement Erlangs processes in C++, and Lisp and Prologs
AI stuff? You need to search for and find, probably even buy, solid libraries
that solve these problems without doing any implementation yourself.
If you try to reinvent the wheel and do everything yourselves - 6 years will 
probably not be enough!


>
> > > 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.
>
> All the controller code is in Erlang !
> What is the procedure to call gprolog functions from Erlang ?
> What is the procedure to call clisp functions from Erlang ?

Add Erlang processes that work as a proxy against gprolog and clisp.
When they receive a message they convert it to any suitable form
and pass it using socket/streams to the actual process (does not even
have to be located on the same computer).

> > > 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...
>
> You are absolutely correct here !
>

Doing a OpenGL visualizer in 6 months might be challenging enough!

> > > 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 :-)
>
> Yes. However, with change of language, the project gets outsourced
> through External Consultant Firm.

I would never have guessed...

>
> > 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.
>
> The target environment is a rack mount Storage Appliance with 1Gb RAM,
> dual Xeon processor and 600 Gb SCSI hard disk space.
>
> The key objection is that Backup software appliance needs performance
> and Erlang+Prolog+clisp is not a good idea.

What kind of performance? I would assume disk and network not CPU!

>
> Now that you know the nature of the product, what is your recommendation ?
>

Dual AMD64 with more RAM :-)

/RogerL