[erlang-questions] Attracting Functional Programmers

G Bulmer <>
Sun Oct 7 17:14:43 CEST 2007


David

Interesting points. While I agree with most of your points, I think  
there is a fairly well understood model which seeks to address and  
organise a broad picture for technology adoption. A key approach is  
to focus on things that the adopter will recognise. I don't feel  
these are economic (in it's simple sense), or even very technical.

First, let me say that I believe Erlang/OTP has 3 key 'sweet spots'
1. Highly available, robust, systems. We can economically build  
Erlang systems which can provide extreme availability, deal with  
failure and 'heal' in a much wider range of circumstances than any  
economically viable alternative. Why would anyone *ever* build a  
system with inferior availability? I don't think it's simple economic  
grounds, because Erlang/OTP technology is cost competitive , and  
there is some evidence (unlike many other 'productivity  
technologies') that its productivity can offset "ramp-up costs" and/ 
or higher salaries.
2. Scaleability, Erlng/OTP can scale to support every size of  
enterprise, utility, national and international system. I think you  
could run the next Olymics on Erlang/OTP. Or the UK National Health  
service. Property 1 makes Erlang/OTP compelling. Again, I don't think  
it's the economics of the technology which is preventing this.
3*. Taking advantage of many-core processors. I believe there are  
many different types of problems/ Erlang/OTP is well suited to, from  
small grained problems upwards. Once more, though, I don't feel it is  
the economics of the technology which needs to be overcome.

Summary, in these three areas, Erlang is the most mature and  
commercially viable technology available.
IMHO, it's that simple.

I can assert that because if there was a better technology, we would  
all know about it (and I wouldn't be here !-)

To some extent, these are independent, and so could be pursued  
differently. I think 3 becomes 'killer' as numbers of cores  
increases, but today, 1 and 2 are, IMHO 'killer' if we can overcome  
the actual obstacles. I do not believe the obstacles are economic

I am a fan of "Crossing the Chasm:
Marketing and selling technology products to mainstream customers:  
Marketing and Selling Technology Products to Mainstream Customers"
by Geoffrey A. Moore
http://www.amazon.co.uk/Crossing-Chasm-technology-mainstream- 
Technology/dp/1841120634/ref=pd_bbs_sr_1/202-3897543-8546206? 
ie=UTF8&s=books&qid=1191761111&sr=8-1
(and his other book, Riding the Tornado)

This provides a rich model of technology adoption from creation,  
through visionaries, early adopters, early majority, main stream and  
eventually luddites (yes the day may eventually come when people  
think Erlang/OTP is very old, and the world has moved on. I vaguely  
recall, when designing Ada, the DoD thought 40 years was the  
*minimum* useful life for their purposes). I you are interested in  
this area, and haven't read it, I strongly recommend you do. I think  
he covers all of David's points, in the more general case, along with  
some evidence.


A key message of Geoffrey Moore is identify a target market, and  
focus on the early adopters (I think Erlang is well past the  
visionary stage). This largely means adjusting the product to fit the  
key needs of a specific market (preferably specific customers). If  
I've understood your points David, this is what you believe too. I  
believe Erlang/OTP has already done this for telecoms, but questions  
remains as to whether there is more to be done for other markets. For  
example, I believe that a few more pieces would make Erlang much more  
attractive to manufacturing industries. Similarly, a little work to  
enable 'rich client' (AKA AJAX-style) web applications, etc. I accept  
that, to experienced Erlang-ers these things may be no more than  
hours, or a few weeks, but, you aren't the adopter. For *potential  
adopters* it may seem a very far away goal.

Moore goes onto explain, once you've got the early adopters, go after  
the "more aware" members of the target market sector, the early  
majority. To capture the "early majority"; resolve their issues by  
make the product attractive to them. This is usually not technology  
or functionality issues. I think the target users in this group are  
companies; developers are often visionaries and early adopters. For  
companies, it is about forms of risk, credibility and publicity.  
Ericsson and a few others are the early adopters, and the detail of  
their use and experience is critical collateral for taking Erlang  
further to the early majority. The purpose of this collateral is to  
reassure potential adopters that the technology is low-risk; that it  
works well enough that they "won't get fired for buying in to it",  
and it has a lifetime. I believe Open Sourcing helps, but, there are  
many, many more dead Open Source projects than live ones; the vibrant  
community around Erlang is very important too.

But key, is the evidence from actual users, who deploy it at similar  
or better levels of scale, availability and value to their business,  
because two key benefit are deploying Erlang/OTP at scale in highly- 
available applications. This evidence doesn't come from inspection of  
the functionality, or by designing and running benchmarks, or  
anything else that a a small group of people could complete  
internally in a couple of months feasibility study.

When a prospective adopter looks at Erlang they need evidence. As an  
example, imagine I was some company reading about Erlang with a view  
to potentially using it. I could read that Ericsson uses Erlang in a  
product, and that would help demonstrate that it has got beyond the  
lab. Unfortunately I can't directly find out if the product is  
successful, has been widely purchased, is it still in production, or  
whether it is in a niche used by one customer who has subsequently  
given up using it. IMHO succesfully marketing technologies does not  
require 'rocket science', just making sure the right information is  
easily available.

Other valuable evidence for  prospective adopter are things like  
support cost, etc, etc. Some of these are commercialy sensitive, and  
we may need to find ways to keep everyone happy.

For any adopter, a key issue is "how do I get support?" For example,  
what would happen to his notional adopter if they adopted Erlang/OTP  
for one project, but went no further? A bad answer is "that would be  
a career or economic disaster"! As an adopter, I would not want the  
burden of retaining an in-house team of Erlang/OTP experts who are so  
familiar with Erlang/OTP's internals that they could fix any problem.  
I would want to know how I get support from a 3rd party, at a  
reasonable price, and likely to be there whan I need them for the  
forceable future. I believe Ericsson handle this through their  
commercial license, but that may mean I couldn't experiment with a  
smaller, lower cost, potentially lower risk, project on Open Source  
Erlang/OTP first. Being forced to *START* with commercial Erlang/OTP  
makes adoption more complex, expensive and less likely.

The Erlang community could deal with this. Maybe it could offer a  
service, maybe through Erlang.org, whereby a customer could buy a  
'bug fix'. [Microsoft sell 'an incident' where you can buy a fix to a  
problem for approximately $100, but lets not get side tracked onto  
them.]

None of this is to say that *I* am unconvinced. After meeting the  
folks who build Erlang, I am much, much happier. The point I am  
trying to make is, I shouldn't need to stake my reputation and  
judgement when proposing Erlang in a project. The evidence should be  
available so that the decision process to choose Erlang is rationale  
and transparent, and the cost and risks are easily and clearly  
identifiable upfront, with no surprises.

So, I think Erlang/OTP adoption would be significantly improved by  
gathering and organising up evidence of its successful and continued  
use, and more simply and clearly defining the markets in which it is  
a 'good fit'. It is useful to define the markets, and not just the  
properties of the applications, so that potential adopters can  
recognise that it is already ready for them.

HTH
G Bulmer

PS * - I would like to qualify point 3, about Erlang and many-core.  
There are applications, where alternatives are very relevant too. For  
example image processing using photoshop or the gimp, where even  
finer grained data-parallel technology is extremly effective. So,  
though it is completely practical to write a gimp plugin for image  
processing with Erlang/OTP (I have written one using NVIDIA CUDA, so  
I can speak from experience), technologies which implement even finer  
grained parallelism are also relevant. But this isn't to detract from  
the point, just remind us that it isn't necessarily one size fits all.


> On 10/6/07, G Bulmer <> wrote:
>> During the CUFP workshop, people talked about attracting developers
>> to FP.
>> The Haskell web site was compared to the Python (I think) web site.
>> I believe the pitch for Haskell was much weaker than the Python  
>> pitch.
>>
>> I took a stab at a few 'marketing' statements for Haskell. My
>> intention is to stimulate debate because I do feel there are
>> unnecessary barriers to recruitment. I do not expect my suggestion to
>> survive :-)
>>
>> You may want to take a look at http://groups.google.com/group/cufp/
>> topics
>> I am G B-)
>
> I think it's a fascinating subject.  If you don't mind my trying to
> foist off some of my own work on you, I've written about it a little
> bit.
>
> http://www.welton.it/articles/programming_language_economics.html
>
> My take is that if you introduce a new language, and you don't have
> millions of dollars to push it (Java, C#), you're going to have to
> find some niche, and do it an order of magnitude better than the
> competition.  Something that's not just an incremental improvement,
> but a clearly superior way of doing things, where "things" means
> something that matters to your average industry programmer.
>
> To my way of thinking, this would explain why Erlang is getting a lot
> of attention from people these days - it does concurrency really well.
>  That one thing, which is seen as increasingly important in a
> multi-core future, is enough for people to pick up Erlang and look at
> it.  In the past, Tk was enough to get people interested in Tcl, the
> promise of very easy dynamic web pages got people interested in PHP,
> Ruby on Rails got people interested in Ruby, and so on.  Of course,
> that's not the only way languages grow in popularity - Python
> gradually built up a following by being simple, clean and practical
> for a wide variety of tasks.  It does seem to help a lot though - if
> you get that "killer app", people will, at least for a while, ignore
> other shortcomings in a language, which is crucial, because it's very
> likely that a newcomer won't have huge libraries, books, user groups
> and some of the other positive externalities that come with
> popularity.
>
> -- 
> David N. Welton
> http://www.welton.it/davidw/




More information about the erlang-questions mailing list