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

[Ulf Wiger (AL/EAB)]

Dev Functional wrote:
> On 9/5/05, Ulf Wiger <ulf@REDACTED> wrote:

> > > 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)
> > 
> 
> Unfortunately, the Thesis also highlights Ericsson's decision 
> to do things in C++ (rather than Erlang). 
> 
> The moment I mentioned this in the discussion, a 1 page 
> printout of the specific page from the thesis was shoved
> on my face. 

I'm sure Bjarne would have some choice words for those who
use his thesis in defense of choosing C++ over Erlang. :)

Let's see what one can find if one reads the _whole_ thesis,
and not just searching for phrases that seem to justify one's
prejudice when lifted out of context. And we should bear in 
mind that Bjarne, while retired now, will always act in what
he thinks is in the best interests of "good old LME"
(LME = LM Ericsson, which was the original name of Ericsson AB,
as well as the initials of its founder, Lars-Magnus):

Lets skip first to the conclusion (p. 49):

  "Was it worth the effort? Did the Erlang development
  produce the desired technical result and did it serve
  the needs for product development? The answer must be
  'yes' on both accounts."

Then, back to the "Backlash" page (p. 37):

  "Once upon a time C++ [St91] was the contender vs.
  Erlang. However, after some large project failures
  C++ fell into disrepute and instead Java [Go96]
  appeared."

Was this the page that they claim tells how Ericsson 
chose C++ over Erlang?

The thesis talks about how the company wanted to move
towards more high-level development tools, such as 
Rational Rose, etc. Ericsson is a _major_ user of 
UML, and was also a major user of SDL (which is now
integrated into UML). It's fair to say that this 
move was in part an attempt to _get away_ from 
e.g. C++ and moving system design up to a higher 
abstraction level. Erlang in a way represents the 
same type of ambition, but building more from the 
ground up. This is also described by Bjarne (p. 22):

  "Programming is both a _top down_ activity from
  requirements and overall structure of the system
  and a _bottom up_ activity based on the 
  _abstractions_ provided by the programming 
  language. Abstractions such as _modules_, 
  _processes_, _higher order functions_, etc. are 
  to the programmer like transistors, capacitors, 
  resistors, etc. to the hardware designer. It is 
  important that the abstractions be few, simple 
  to understand and yet powerful and provide the 
  needed functionality."

Towards the end of page 37, Bjarne hints that 
perhaps the move towards outsourcing development
tools didn't go quite as smoothly as some might
have hoped (Bjarne calls it "some turmoil".)


Let me give you some insider background:

One of the user quotes on p. 32:

  "We believe from project start, and still believe, that 
  if we had tried to use any other technology, we would 
  even remotely have been able to, within the desired time
  frame of roughly 1.5 years, reach the desired level of
  functionality, system software maturity and stability."

was offered by one of Ericsson's most respected system
architects, with years of experience in e.g. C++ 
projects. He was himself a guest researcher at MIT and
participated in research that eventually led to the
development of IDL and RPC (I think -- unfortunately,
Google is not that reliable when it comes to ancient 
history like that. ;) In fact, significant parts of 
the architecture in the C++-based products you mention
bear his signature.


> Apologize to all the esteemed members of this list for
> this non-technical mail.

No need. Many people on this list have, I'm sure, been
in similar battles. Hopefully, it will help some who still
haven't to hear about arguments and counter-arguments,
but perhaps also to recognize when the battle turns 
personal, and away from technical arguments.

In a sense, all of this is "shouting into the wind", as
ROK eloquently put it, but recognizing that this 
particular battle was lost, it doesn't hurt to wrap up,
and hone the arguments until next time.

Finally, a quote worth pondering:
"...focus on interests, not 'positions'. Positions are 
bargaining statements so narrow that for one person to 
win, the other must lose."
(From "Software Deadlines - Software Schedule Negotiating",
Applied Computer Research, Inc.
http://www.acrhq.com/surveys/deadline/sp-sched.htm

/Uffe