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

[Dev Functional]

On 8/25/05, Roger Larsson <roger.larsson@REDACTED> wrote:
> On Thursday 25 August 2005 08.18, Dev Functional wrote:
> > Hello
> >
> > 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 Consultant is Directore's close friend's nephew !

> >    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?

Estd Time = 
   Training Time in C++  
   +  Redesign in OO 
   +  Implementation Time
   +  Debugging Time.

about 6 months (which is double time).


> 
> > 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 ?

> 
> 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...
> 

You are absolutely correct here !

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

Apology,  ANN is Aritificiale Nuerale Network.

> 
> > 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.

> 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.

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

kind regards
Dev.