(Prolog + LISP + Erlang) with integration issues versus C++
Thu Aug 25 11:20:40 CEST 2005
On 8/25/05, Roger Larsson <> 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.
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 ?
More information about the erlang-questions