[erlang-questions] Erlang Intro/Evangelism Presentation -- Starbucks!

[Edmond Begumisa]

On Sat, 08 Jan 2011 22:19:22 +1100, Michael Turner  
<michael.eugene.turner@REDACTED> wrote:

> "What do you do when your highly optimised procedures have to run on  
> slower
> sequential processors? "
>
> How often is that *truly* a requirement?

It's not now. But the worry (which I don't necessarily agree with) is that  
it will be in the near future.

> In those cases where it is, these
> people who sell tools to parallelize legacy code are offering something
> Erlang can't offer, except perhaps through NIF interfaces to those highly
> optimized procedures.  Either way, you're re-architecting the app.  And
> requiring that the app be re-architected in a way that necessitates  
> learning
> a new language will lose out pretty often to doing it in a way that
> preserves existing skill-sets.  Companies like to get human skill-sets  
> built
> for free, ideally by their competitors.  Up-front investments in  
> training --
> even for conventional technologies -- are one of the hardest things to  
> sell
> to management, in corporate life.
>

Probably true. But I am reminded of something very interesting Ulf has  
just pointed me to...

"The Innovator's Dilemma (C. Christensen) as quoted by Todd A. Proebsting  
...

"… companies [languages] that did everything right---were in tune with  
their competition, listened to their customers, and invested aggressively  
in new technologies---*still* lost their market leadership when confronted  
with disruptive changes in technology…"

http://ll2.ai.mit.edu/talks/proebsting.ppt

- Edmond -


> People keep saying Erlang is a simple language, implying that getting  
> over
> the learning curve must therefore be a simple matter.  No.  Erlang is a
> *small* language, but one that incorporates some powerful ideas and
> idiosyncratic approaches, requiring some time to digest.  I'd had  
> exposure
> to Prolog (helpful in understanding that "=" is pattern-match, not
> assignment, and in getting used to the odd convention for symbols where
> capitalization means "variable").  I had some experience in Lisp  
> (helpful in
> understanding how Erlang handles lists).  I'd also gotten some  
> experience in
> parallel programming in more conventional terms (albeit in C- and  
> C++-coded
> apps).  And yet, Erlang was not, and is still not, easy for me.  No  
> amount
> of repetition of Erlang's selling points is going to make much dent in  
> that
> sense of difficulty.  Only long hard practice will get me to the point  
> where
> I find Erlang programs as readable -- or more readable -- than their more
> conventional equivalents.  And businesses don't pay employees for long,  
> hard
> practice.  They don't pay them for learning.  That's just a cost, a
> necessary evil to be minimized.  They pay employees for results that some
> customer will pay for, ideally tomorrow, though all too often the  
> deadline
> was yesterday.
>
> -michael turner
>
> On Fri, Jan 7, 2011 at 11:54 PM, Edmond Begumisa <
> ebegumisa@REDACTED> wrote:
>
>> On Sat, 08 Jan 2011 00:42:54 +1100, Michael Turner <
>> michael.eugene.turner@REDACTED> wrote:
>>
>>  "... I started to think about how Starbucks processes drink orders.
>>> Starbucks, like most other businesses is primarily interested in
>>> maximizing
>>> throughput of orders. More orders equals more revenue. As a result they
>>> use
>>> asynchronous processing ..."
>>>
>>> Starbucks might actually be an interesting metaphor here, instructive  
>>> for
>>> thinking about how to write Erlang apps, but I beg to differ about  
>>> what's
>>> being optimized.
>>>
>>> Starbucks is NOT optimizing throughput.  It's optimizing replicability.
>>>
>>> I must explain: I come from Berkeley, a town that lives on espresso.   
>>> At
>>> certain cafes, I could routinely see two people behind the counter
>>> delivering twice as much espresso per minute as Starbucks does with  
>>> five
>>> or
>>> six people behind the counter.
>>>
>>> What Starbucks is optimizing is how to rapidly deploy relatively slow,
>>> lower-skill employees to provide a consistent experience of a  
>>> relatively
>>> even flow of order processing, a sense (for the customer) that  
>>> inexorable
>>> progress is being made.  So long as this continues to attract a flow of
>>> customers who've never known better, it will work.  And I have to  
>>> admit,
>>> I've gotten used to finally getting to the Starbucks counter, ordering  
>>> a
>>> capuccino, and having two other employees echo my order, even though  
>>> it's
>>> rarely under three minutes before I actually get the drink.  But at  
>>> first
>>> I
>>> couldn't stand it. In some of the cafes I got used to in Berkeley,  
>>> someone
>>> at the counter would often be taking my order before I even got to the
>>> cash
>>> register, and putting the drink in front of me by the time I had my  
>>> wallet
>>> out to pay the cashier.  THAT was some real throughput.  Not to mention
>>> that
>>> watching these people furiously take orders, crank out drinks and  
>>> collect
>>> money was like being at a martial arts performance.
>>>
>>> Sometimes the way to speed something up is to parallelize it.   
>>> Sometimes
>>> the
>>> way to speed it up is with a fast uni-processor running highly  
>>> optimized
>>> procedures.
>>>
>>
>> Food for thought: What do you do when your highly optimised procedures  
>> have
>> to run on slower sequential processors? (i.e when your program has to  
>> run on
>> newer hardware)
>>
>> If your procedures are already optimised to death, your only option is  
>> to
>> _try_ and parellise. I think that's what's getting peoples knickers in  
>> knots
>> regarding multi-core.
>>
>>
>>  But sometimes what you're trying to optimize isn't speed of
>>> operations, really, but growth.  Starbucks was in fact doing that last.
>>>  It's optimizing for blanketing cityscapes with its storefronts, as it  
>>> has
>>> in Tokyo.  Optimizing throughput -- which requires optimizing  
>>> employees --
>>> would only have slowed that growth process. Those cafes in Berkeley I
>>> worshipped for their ferociously pirouetting baristas were wonderful,  
>>> but
>>> they would never scale.  Starbucks scaled.  A good process structure in
>>> Erlang also scales.  That's the real lesson in any such analogy, I  
>>> think.
>>>
>>>
>> Interesting observation -- I hadn't thought of the replication angle or
>> process structure.
>>
>> In terms of "Optimizing throughput": I think the point of the article
>> though was to illustrate an alternative to two-phase commit.  
>> Specifically,
>> the use of async message-passing techniques to avoid blocking  
>> transactions
>> improving throughput in the process. I think async message-passing +
>> non-blocking operations and the impact this has on responsiveness is an
>> important lesson for Erlang newcomers and/or can be used as a "pitch" to
>> sell the environment to those thinking about dipping their feet and  
>> needing
>> a reason to jump in. Well, at least it was for me :)
>>
>> - Edmond -
>>
>>
>>  -michael turner
>>>
>>>
>>>
>>> On Fri, Dec 17, 2010 at 9:48 PM, Edmond Begumisa <
>>> ebegumisa@REDACTED> wrote:
>>>
>>>  MESSAGE-PASSING @ STARBUCKS
>>>>
>>>> "... I started to think about how Starbucks processes drink orders.
>>>> Starbucks, like most other businesses is primarily interested in
>>>> maximizing
>>>> throughput of orders. More orders equals more revenue. As a result  
>>>> they
>>>> use
>>>> asynchronous processing ..."
>>>>
>>>> "... we can see that the real world is often asynchronous. Our daily
>>>> lives
>>>> consists of many coordinated, but asynchronous interactions...
>>>> asynchronous
>>>> messaging architecture can often be a natural way to model these  
>>>> types of
>>>> interactions... also means that often we can look at daily life to  
>>>> help
>>>> design successful messaging solutions ..."*
>>>>
>>>> http://www.eaipatterns.com/ramblings/18_starbucks.html
>>>>
>>>> I hope I'm not too late with this, but I really liked this old  
>>>> article by
>>>> Google's Gregor Hohpe on asynchronous message passing. He wasn't  
>>>> talking
>>>> explicitly about Erlang but the content should resonate  
>>>> instantaneously
>>>> with
>>>> Erlang programmers while at the same time being insightful for
>>>> non-Erlangers. You might want to reference a few of his well-worded
>>>> analogies for evangelising some of the core ideas built into Erlang.
>>>>
>>>> *Joe Armstrong made a similar compelling argument at the beginning of  
>>>> his
>>>> book. As a relatively new Erlang programmer myself, _THIS_ is the main
>>>> line
>>>> of argument that convinced me to try out the Erlang environment.
>>>> Particularly the implications on concurrency which I had struggled  
>>>> with
>>>> in
>>>> other environments (in retrospect, it was because those environments
>>>> didn't
>>>> have these ideas built-in or actively encouraged -- I've found Erlang
>>>> does a
>>>> lot of hand-holding to make sure you do the sane thing in order to  
>>>> avoid
>>>> painting yourself into a corner -- something you could emphasise in  
>>>> your
>>>> presentation.)
>>>>
>>>> - Edmond -
>>>>
>>>>
>>>> On Sat, 04 Dec 2010 05:43:34 +1100, Ryan Zezeski <rzezeski@REDACTED>
>>>> wrote:
>>>>
>>>>  I've been tasked with giving an introductory level presentation on
>>>> Erlang
>>>>
>>>>> at
>>>>> work.  The focus is on why you would use Erlang and what does it look
>>>>> like
>>>>> on the surface level.  We have a lot of your standard Java/C#/C
>>>>> developers
>>>>> and this will act as a potential launching pad to introducing Erlang  
>>>>> to
>>>>> the
>>>>> company.  There is the potential for a large number of people to  
>>>>> video
>>>>> conference into this possibly spanning several countries so I really
>>>>> want
>>>>> to
>>>>> knock this out of the park.
>>>>>
>>>>> I'm writing as an inquiry for links to any prior art that I may use  
>>>>> for
>>>>> inspiration or even steal and use as my own.  Anything that you think
>>>>> might
>>>>> be helpful is appreciated, even input on possible approaches.  I'd
>>>>> really
>>>>> like to hear from people who have done this sort of thing before,  
>>>>> i.e.
>>>>> pubic
>>>>> speaking on Erlang.
>>>>>
>>>>> Thanks,
>>>>> -Ryan
>>>>>
>>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>>>
>>>> ________________________________________________________________
>>>> erlang-questions (at) erlang.org mailing list.
>>>> See http://www.erlang.org/faq.html
>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>>
>>>>
>>>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/