[erlang-questions] OT: Programming Language Selection as a Business Strategy
Sun Apr 15 01:30:36 CEST 2007
2007/4/15, Perrog <>:
> I'm new to this list, but I found this thread quite intresting...
> 2007/4/14, Ulf Wiger <>:
> > It's probably more accurate to say that Erlang was developed in an
> > laboratory in response to a perceived technology need. Bjarne Däcker's
> > thesis gives some good background on this:
> > It also mentions that Erlang was banned in 1998, due to perceived
> > needs.
> Does this mean Erlang should be avoided outside Ericsson's CS-lab as
> much as possible? :-)
He he, 1998 was a loong time ago, and a huge amount of Erlang code
has been written at Ericsson since then. (:
2007/4/14, Ulf Wiger <>:
> > I agree with Thomas that essays like "beating the averages" give an
> > interesting angle on this question. Large companies will also worry
> > the cost of diversity and lock-in effects. This is most likely much less
> > a problem in small companies.
> > For large companies, aspects that will have measurable consequences
> > include: [E.N. Cost of training support staff... Difficulty...
> Re-training costs...
> > Difficulty...Difficulty... expensive redesign.
> > ... wouldn't you want to try to eliminate the above challenges, if
> possible? —end of E.N.]
> Who said this only concern large companies...?
I think there are a couple of reasons:
- Small companies are less likely to have specialized support staff,
and several different design centers, so the risk of such disparity
is much lower.
- Designers working for small companies may be, on average, more
forward, adaptive, and versatile, than their counterparts in large
companies. I used to work in a small company myself, and had
to dabble with all sorts of things - even hardware repair. I wouldn't
dream of doing that in my present job, since we have a world-class
hardware design team in our unit. (:
- There may also be a tendency among large companies to run large
projects (because that's how it's done...), leading to bloated code,
leading to bigger problems along the lines I described.
So, while these problems will surely exist in small companies as
well, I think they are far less pronounced.
In addition to all aspects above, mainstream languages usually comes
> with a large library (e.g. .Net/WinFX) and special designed tools
> (e.g. Visual Studio.)
> If problems becomes more transparent if solved in Erlang, what are
> these type of problems really? What kind of Design Patterns make
> Erlang beat the average?
Given that Erlang is the answer, what is the question? (:
It's too late for me to try to answer that. Briefly though - for several
problem domains, one most likely won't easily beat the average
using Erlang, since the domain-specific libraries are missing.
OTOH, those problem domains might not be the most interesting
for someone trying to come up with a new product.
In more uncharted terrain, it might be interesting that languages
like Erlang really don't need much more than a unix shell and a
decent text editor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions