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

[Michael Turner]

"What do you do when your highly optimised procedures have to run on slower
sequential processors? "

How often is that *truly* a requirement?  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.

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