<br><br><div><span class="gmail_quote">2007/4/15, Perrog <<a href="mailto:perrog@gmail.com">perrog@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I'm new to this list, but I found this thread quite intresting...<br><br>2007/4/14, Ulf Wiger <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>>:<br>> It's probably more accurate to say that Erlang was developed in an Ericsson

<br>> laboratory in response to a perceived technology need. Bjarne Däcker's<br>> thesis gives some good background on this:<br>><br>> It also mentions that Erlang was banned in 1998, due to perceived business

<br>> needs.<br><br>Does this mean Erlang should be avoided outside Ericsson's CS-lab as<br>much as possible? :-)</blockquote><div><br>He he, 1998 was a loong time ago, and a huge amount of Erlang code <br>has been written at Ericsson since then. (:

<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2007/4/14, Ulf Wiger <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>

>:<br>> I agree with Thomas that essays like "beating the averages" give an<br>> interesting angle on this question. Large companies will also worry about<br>> the cost of diversity and lock-in effects. This is most likely much less of

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

<br>><br>> ... wouldn't you want to try to eliminate the above challenges, if possible? —end of E.N.]<br><br>Who said this only concern large companies...?</blockquote><div><br>I did.<br>I think there are a couple of reasons:

<br><br>- Small companies are less likely to have specialized support staff,<br>  and several different design centers, so the risk of such disparity<br>  is much lower.<br>- Designers working for small companies may be, on average, more

<br>  forward, adaptive, and versatile, than their counterparts in large <br>  companies. I used to work in a small company myself, and had <br>  to dabble with all sorts of things - even hardware repair. I wouldn't<br>

  dream of doing that in my present job, since we have a world-class<br>  hardware design team in our unit. (:<br>- There may also be a tendency among large companies to run large<br>  projects (because that's how it's done...), leading to bloated code,

<br>  leading to bigger problems along the lines I described.<br><br>So, while these problems will surely exist in small companies as <br>well, I think they are far less pronounced.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

In addition to all aspects above, mainstream languages usually comes<br>with a large library (e.g. .Net/WinFX) and special designed tools<br>(e.g. Visual Studio.)<br><br>If problems becomes more transparent if solved in Erlang, what are

<br>these type of problems really? What kind of Design Patterns make<br>Erlang beat the average?<br></blockquote></div><br>Given that Erlang is the answer, what is the question?  (:<br><br>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.

<br><br>In more uncharted terrain, it might be interesting that languages <br>like Erlang really don't need much more than a unix shell and a <br>decent text editor.<br><br>BR,<br>Ulf W<br>