Auto-Threading Compilers Are Here

[glen ep ropella]

Does anyone have any insight to share about this?

http://developinthecloud.drdobbs.com/author.asp?section_id=2284&doc_id=255275&

--
glen e. p. ropella, 971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Roger Critchlow-2]

My boss sent me the Microsoft Research paper on mutability annotations yesterday, 

  http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf

I've been writing distributed parallel code in Erlang for several years, now, and the immutability of functional data is absolutely necessary, but not sufficient, to make things work.  So I expect that they can annotate their C# with all this mutability markup, making it incredibly ugly and incomprehensible in the process, and that it will work, sort of, some of the time, for limited circumstances.  Probably better than hand built multi-threaded code, but probably not as well as well crafted Erlang trees of supervised processes mutating state via tail calls.  Managing mutability only prevents you from making certain classes of egregious errors, it doesn't solve everything, it just enables you to continue.

We're very successful clock makers as a species.  As long as all the parts of a mechanism are connected together into a causal graph, so we can twiddle this part and see what it does, then we can work things out and make wonderfully complicated clocks.  Hence we make really awesome electrical power generation stations, huge electron factories of enormous complication.  But, when we connect our generators together into grids, we have a history of oops where a squirrel or a tree and an unforeseen causal connection takes millions of dollars of clocks offline in a few minutes.  We fix the problem, and it happens again in a different way.  We understand how to engineer the generator, because it's a clock.  We're still learning how to not engineer the grid on the fly, because it's a parallel distributed system which only works like a clock when it wants to tease us.

-- rec --

On Wed, Dec 5, 2012 at 12:49 PM, glen e. p. ropella <[hidden email]> wrote:

Does anyone have any insight to share about this?

http://developinthecloud.drdobbs.com/author.asp?section_id=2284&doc_id=255275&

--
glen e. p. ropella, <a href="tel:[phone]" value="[phone]">971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[glen ep ropella]

Nice.  Thanks.  My suspicions were piqued when I read Kellogg's
statement: "Honestly though, I don't think FP is ever going to become
fully mainstream."

Roger Critchlow wrote at 12/05/2012 01:32 PM:

> My boss sent me the Microsoft Research paper on mutability annotations
> yesterday,
>
>   http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf
>
> I've been writing distributed parallel code in Erlang for several years,
> now, and the immutability of functional data is absolutely necessary, but
> not sufficient, to make things work.  So I expect that they can annotate
> their C# with all this mutability markup, making it incredibly ugly and
> incomprehensible in the process, and that it will work, sort of, some of
> the time, for limited circumstances.  Probably better than hand built
> multi-threaded code, but probably not as well as well crafted Erlang trees
> of supervised processes mutating state via tail calls.  Managing mutability
> only prevents you from making certain classes of egregious errors, it
> doesn't solve everything, it just enables you to continue.
>
> We're very successful clock makers as a species.  As long as all the parts
> of a mechanism are connected together into a causal graph, so we can
> twiddle this part and see what it does, then we can work things out and
> make wonderfully complicated clocks.  Hence we make really awesome
> electrical power generation stations, huge electron factories of enormous
> complication.  But, when we connect our generators together into grids, we
> have a history of oops where a squirrel or a tree and an unforeseen causal
> connection takes millions of dollars of clocks offline in a few minutes.
>  We fix the problem, and it happens again in a different way.  We
> understand how to engineer the generator, because it's a clock.  We're
> still learning how to not engineer the grid on the fly, because it's a
> parallel distributed system which only works like a clock when it wants to
> tease us.

--
glen e. p. ropella, 971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Marcus G. Daniels]

On 12/5/12 2:32 PM, Roger Critchlow wrote:

> We're very successful clock makers as a species.  As long as all the
> parts of a mechanism are connected together into a causal graph, so we
> can twiddle this part and see what it does, then we can work things
> out and make wonderfully complicated clocks.  Hence we make really
> awesome electrical power generation stations, huge electron factories
> of enormous complication.  But, when we connect our generators
> together into grids, we have a history of oops where a squirrel or a
> tree and an unforeseen causal connection takes millions of dollars of
> clocks offline in a few minutes.  We fix the problem, and it happens
> again in a different way.  We understand how to engineer the
> generator, because it's a clock.  We're still learning how to not
> engineer the grid on the fly, because it's a parallel distributed
> system which only works like a clock when it wants to tease us.
>

Why not make grids like clocks?   Why must members of the grid have
agency?   Central planning!

The observation about isolated external references reminds me of
Control.Monad.ST

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144.2237&rep=rep1&type=pdf
http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Control-Monad-ST.html


Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Steve Smith]

On 12/5/12 12:49 PM, glen e. p. ropella wrote:

Does anyone have any insight to share about this?

http://developinthecloud.drdobbs.com/author.asp?section_id=2284&doc_id=255275&

But more importantly, as always, we must ask:

will it Blend?

Steve Smith wrote at 11/08/2012 10:37 AM:

I have some questions for the list (composed of a mixture of optimists
and pessimists, all technophiles):

1. What do you think of Singularity University and the ideas presented
   in Kotler/Diamandis' book "Abundance"?

Will it Blend? iPad Mini vs Kindle Fire HD vs Nexus 7 http://youtu.be/5MMmLQlrBw

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[glen ep ropella]

Steve Smith wrote at 12/05/2012 03:59 PM:
> On 12/5/12 12:49 PM, glen e. p. ropella wrote:
>> Does anyone have any insight to share about this?
>>
>> http://developinthecloud.drdobbs.com/author.asp?section_id=2284&doc_id=255275&
>>
> But more importantly, as always, we must ask:
>
>    will it Blend?

I think "blended" is a _perfect_ description of most Microsoft technology.

--
glen e. p. ropella, 971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[Roger Critchlow-2]

I have no idea what Kellogg thinks "fully mainstream" might be, or what sort of delusions of being plugged into the real real world would support such opinions.

-- rec --

On Wed, Dec 5, 2012 at 4:19 PM, glen e. p. ropella <[hidden email]> wrote:

Nice.  Thanks.  My suspicions were piqued when I read Kellogg's
statement: "Honestly though, I don't think FP is ever going to become
fully mainstream."

Roger Critchlow wrote at 12/05/2012 01:32 PM:

> My boss sent me the Microsoft Research paper on mutability annotations
> yesterday,
>
>   http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf
>
> I've been writing distributed parallel code in Erlang for several years,
> now, and the immutability of functional data is absolutely necessary, but
> not sufficient, to make things work.  So I expect that they can annotate
> their C# with all this mutability markup, making it incredibly ugly and
> incomprehensible in the process, and that it will work, sort of, some of
> the time, for limited circumstances.  Probably better than hand built
> multi-threaded code, but probably not as well as well crafted Erlang trees
> of supervised processes mutating state via tail calls.  Managing mutability
> only prevents you from making certain classes of egregious errors, it
> doesn't solve everything, it just enables you to continue.
>
> We're very successful clock makers as a species.  As long as all the parts
> of a mechanism are connected together into a causal graph, so we can
> twiddle this part and see what it does, then we can work things out and
> make wonderfully complicated clocks.  Hence we make really awesome
> electrical power generation stations, huge electron factories of enormous
> complication.  But, when we connect our generators together into grids, we
> have a history of oops where a squirrel or a tree and an unforeseen causal
> connection takes millions of dollars of clocks offline in a few minutes.
>  We fix the problem, and it happens again in a different way.  We
> understand how to engineer the generator, because it's a clock.  We're
> still learning how to not engineer the grid on the fly, because it's a
> parallel distributed system which only works like a clock when it wants to
> tease us.


--

glen e. p. ropella, <a href="tel:[phone]" value="[phone]">971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

[glen ep ropella]

Roger Critchlow wrote at 12/05/2012 05:07 PM:
> I have no idea what Kellogg thinks "fully mainstream" might be, or what
> sort of delusions of being plugged into the real real world would support
> such opinions.

When I hear people use that argument, I usually think they're conflating
adoption rates with either specialization or failure.  I think Kellogg
was claiming that FP is a specialist technique, great for moorlocks but
not useful for eloi.  But, to me, it seems more like slow adoption.  I
was interested to hear a web programmer yammer on about "closures" the
other day.

--
glen e. p. ropella, 971-255-2847, http://tempusdictum.com


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org