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

[Ulf Wiger]

Wild guess, but...

Basically, since your management started interfering based
on advice from a close friend of the VP, any justification
beyond that point will serve mainly to cloud the fact that
the decision was made irrationally in the first place (or,
more precisely, irrationally from the company's point of
view, as it was mainly self-serving and not necessarily in
the best interest of the company.)

Once you start suspecting that, it's best to bail out of
the debate, since the arguments in favour of the decision
will be tempting to attack -- and attacking them is likely
to hurt your career in the company. You need to have very
powerful friends, an excellent case, and extreme motivation
to take on upper management and try to expose their
incompetence in a specific case.

(They may not even be incompetent -- I'm sure all managers
once in a while move too fast on some issue, and find out
later that they had trusted the wrong advisor. Once they do,
they still have to figure out what's worse: having their
bad judgement exposed, which means they lose authority,
or go with a less-than-optimal decision? In order _not_ to
lose face, you have to carefully establish a leadership style
where you own up to your mistakes and change your mind
publicly and honestly when needed. This takes a lot of natural
authority, if you're to pull it own. You can't fake it.)

Still, let's succumb to the temptation and attack those
arguments, shall we?  ;)

Den 2005-09-04 11:35:17 skrev Dev Functional <devfunctional@REDACTED>:


> 1)  It was pointed out that while each language will have merits and  
> strength, however, together they would have both interop (performance)
> and maintenance issues.

a) the only way to establish that there are performance issues is
    to measure. Most likely, in a modular system written in C++, you
    will split the application into several unix processes, using
    socket or pipe communication between them, which will put you
    in roughly the same dilemma. If you don't, you may
    well run into maintenance issues with different threads vying for
    the same memory -- whose solution may well lead to performance
    problems, as you start calling by value rather than by reference,
    and putting in more semaphores than you actually need.
    Another common issue with C++ development projects where teams
    have to interop, is that they gradually move into a situation
    where each subsystem has its own class structure, and marshalling
    is done in the subsystem interfaces -- leading to lots of copying
    and restructuring of data. As Serge pointed out, many ambitious
    C++ projects suffer severe rot during maintenance.


> 2)  It was stated that it is better to fight with the nuances of one  
>     language, rather than drool on the strength of each of them
>     independently and then face licensing issues, interop issues,
>     performance issues, support issues, not to speak of the
>     maintenance.

"Drool"? If those were the very words used, I'd say your management
has an attitude problem towards its engineers.

Still, it was pointed out in this forum as well, that going with
one of the languages Erlang, Lisp, Prolog, might be a better solution
than using all three.

>
> 3)  It was pointed out that today even Ericcsson does not use Erlang
>     for its new product development. Why ?

I've answered this. For a more detailed answer, read Bjarne Däcker's
excellent thesis "[Erlang] - A Case Study of Technology Introduction"
(http://www.erlang.org/cslab/publications/bjarnelic.pdf)



> 6)  It was pointed out that Prolog, CLISP are themselves 
>     [implemented] in C! So, if there is a smart idea present
>     eg. backtracking, we can see the implementation and use
>     it in the code. There is no need to take the complete
>     load of the language, since we don't want all the features
>     any way.

Not really worthy of comment. Whoever said that cannot have looked
inside e.g. a Prolog evaluator or e.g. the Erlang VM. Sure you can
find small bits of code to reuse... but they clearly don't know what
they're talking about in this regard. (For the record, I haven't looked
inside a Prolog evaluator either).


>      The performance slide related to yaws was mentioned and the  
>      management wondered why the world hasn't moved on to yaws by
>      ditching oh-so-slow Apache ?

So they start by saying that performance is important; you show
them that good performance is attainable; they respond by saying
(in a word) performance is not that important after all?


> 8)  The management has decided to organize 4 week long formal rigorous  
>     training in C++ and Template Programming.

Four weeks is a start, but will not be nearly enough.


> 9)  The decision has been taken by the management and the tools to be  
> used are
>      - C++ (user land), g++4
>      - C     (kernel land) gcc4
>      - STL
>      - Boost Library
>       There is no license fees to be paid to anybody.

Only consultant fees etc. to some good friend of the boss. ;-)



> 11)  The management also highlighted that if the languages
>      so far used (prolog,lisp,erlang) were so great then
>      the capitalists would have grabbed them up long time
>      ago and made lots of money by now by developing and
>      selling products.

What a wonderful metric!


>      So, either the capitalists are fools or the current
>      development team !

Again, your management seems to have an attitude problem!
And no, venture capitalists are usually not fools. They are
usually not software engineers either. And among those who
recognize and love the strengths of those tools, very few
know how to talk to a venture capitalist.


> It was also pointed out that Google does lot of work related to
> information retrieval, inference, distributed computing over
> thousands of compute nodes but does not use Erlang ! Why ?

Who knows? Maybe they do use Erlang (to my knowledge they don't)



> In the final analysis, the project will proceed with the above
> made decisions and I will need to abide by these decisions
> if I am to keep my job.

You will still need stuff like test rigs, simulators, etc.
There may be pockets where you can apply some fun engineering
as long as you don't make a big deal out of it.

Good luck. Getting pounced on is never fun, but if you
insist on using great technology, it's bound to happen
every once in a while. Many of us have been there. (:

/Uffe
-- 
Ulf Wiger