Re: my two cents
Explain to me why that document is a "must", because I don't get it. Somebody has to put their foot down, put some weight in his or her butt, push back, and say, "BULLSHIT. I don't get it."
Looking at Richard Hamming's three questions:
1. I am simultaneously interested in open, reflective, dynamically distributed and dynamically federated systems
2. I am a practitioner, so the most important problem is squishing out applications for my company
3. This is a hobby, and for a hobby I want to build something that radically changes the future -- anything less is a complete waste. I consider all databases and graphical user interfaces to be examples of 1, and so my interests map out all over the place. One big problem in a field this large would be dangerously myopic.
Also, Richard Hamming or Todd Proebstring isn't going to hire me, so these questions are pretty irrelevant to this discussion (for me).
What I possess is an extremely closed-minded and visionary type of personality, and a desire to settle for nothing less. The last thing I am going to do is appeal to Todd for what I should be doing or asking Alan Kay or Ian Piumarta about. I should just go directly to Alan or Ian and push back on their ideas. A much better article than Todd's powerpoint would be Accept Defeat: The Neuroscience of Screwing Up http://www.wired.com/magazine/2009/12/fail_accept_defeat/all/1
To summarize what I don't find Todd's presentation:
1. Everything he said of value is obvious to anyone with any perspective at all
2. It's all been said before
3. "Flight Data Recorders" is a fancy way to say all software is a living system, and computer scientists suck at studying living systems, and programmers lack sufficient tools for repairing living systems
4. "Flight Data Recorders" biggest disadvantage is not mentioned: dealing with purity
5. "Checkpoints/Undo": the biggest flaw in this idea is always the same, and is the same as my criticism of Warth and Kay's Worlds idea: you are *still* moving the program counter, and so state *is* changing. Any attempt to hide the fact the program counter seems like an abstraction failure to me.
6. "Checkpoints/Undo" does not mention attribute grammars as a current solution.
7. "Checkpoints/Undo": Completely goes against the earlier point in the powerpoint that smart algorithms will do more for performance than compiler optimization
8. Compiler optimization vs. algorithms in general is a false dichotomy in a maximally open, maximally reflective system, and I'll claim anyone who thinks this dichotomy is real will not push themselves into an *extreme position* necessary to radically innovate
9. "Disruptive Database Integration" appears to be LINQ, which relies on monad comprehensions and does not facilitate metalogic substitution. LINQ hits a complexity wall early, and currently Visual Studio and .NET Assembly compilation introduces real abstraction barriers to how people think about database integration. Typed data access has never been a real problem, it is a red herring only MS Research would latch onto, because it looks cool and sells VS licenses.
10. "Disruptive Parsing": Working with Concrete Syntax Trees only makes sense if you need to work with concrete syntax trees; advocating unnecessary abstraction weight seems silly
11. "Disruptive XML Manipulation": Misses the point that hardwiring data interchange to XML means weak service encapsulation and disallows for extreme late-binding between the client and server; this raises questions about versionability, immediately
12. "Disruptive constraint solvers": In my experience, the biggest problem with constraint solvers today -- in terms of putting them into a language -- is that they are mostly designed by people who don't have professional training and experience designing languages
13. "Distributed programming": Performance matters. The speed of light is your bottleneck. Stuff like fault tolerance isn't that complicated and the bigger issue will be what to distribute and how to distribute it, e.g. fast algorithms for dynamic reconfiguration that don't have long system pause characteristics
I'm going to conclude by saying the three stumbling blocks are size, complexity and trustworthiness. Paying attention to all of Todd P's "big problems" just puts your focus on solutions-oriented thinking, rather than fundamentals-oriented thinking.
<div>
<p>Explain to me why that document is a "must", because I don't get it. Somebody has to put their foot down, put some weight in his or her butt, push back, and say, "BULLSHIT. I don't get it."<br><br>Looking at Richard Hamming's three questions:<br><br>1. I am simultaneously interested in open, reflective, dynamically distributed and dynamically federated systems<br>2. I am a practitioner, so the most important problem is squishing out applications for my company<br>
3. This is a hobby, and for a hobby I want to build something that radically changes the future -- anything less is a complete waste. I consider all databases and graphical user interfaces to be examples of 1, and so my interests map out all over the place. One big problem in a field this large would be dangerously myopic.<br><br>Also, Richard Hamming or Todd Proebstring isn't going to hire me, so these questions are pretty irrelevant to this discussion (for me).<br><br>What I possess is an extremely closed-minded and visionary type of personality, and a desire to settle for nothing less. The last thing I am going to do is appeal to Todd for what I should be doing or asking Alan Kay or Ian Piumarta about. I should just go directly to Alan or Ian and push back on their ideas. A much better article than Todd's powerpoint would be Accept Defeat: The Neuroscience of Screwing Up <a href="http://www.wired.com/magazine/2009/12/fail_accept_defeat/all/1">http://www.wired.com/magazine/2009/12/fail_accept_defeat/all/1</a><br><br>To summarize what I don't find Todd's presentation:<br>1. Everything he said of value is obvious to anyone with any perspective at all<br>2. It's all been said before<br>3. "Flight Data Recorders" is a fancy way to say all software is a living system, and computer scientists suck at studying living systems, and programmers lack sufficient tools for repairing living systems<br>
4. "Flight Data Recorders" biggest disadvantage is not mentioned: dealing with purity<br>5. "Checkpoints/Undo": the biggest flaw in this idea is always the same, and is the same as my criticism of Warth and Kay's Worlds idea: you are *still* moving the program counter, and so state *is* changing. Any attempt to hide the fact the program counter seems like an abstraction failure to me.<br>
6. "Checkpoints/Undo" does not mention attribute grammars as a current solution. <br>7. "Checkpoints/Undo": Completely goes against the earlier point in the powerpoint that smart algorithms will do more for performance than compiler optimization<br>
8. Compiler optimization vs. algorithms in general is a false dichotomy in a maximally open, maximally reflective system, and I'll claim anyone who thinks this dichotomy is real will not push themselves into an *extreme position* necessary to radically innovate<br>
9. "Disruptive Database Integration" appears to be LINQ, which relies on monad comprehensions and does not facilitate metalogic substitution. LINQ hits a complexity wall early, and currently Visual Studio and .NET Assembly compilation introduces real abstraction barriers to how people think about database integration. Typed data access has never been a real problem, it is a red herring only MS Research would latch onto, because it looks cool and sells VS licenses.<br>
10. "Disruptive Parsing": Working with Concrete Syntax Trees only makes sense if you need to work with concrete syntax trees; advocating unnecessary abstraction weight seems silly<br>11. "Disruptive XML Manipulation": Misses the point that hardwiring data interchange to XML means weak service encapsulation and disallows for extreme late-binding between the client and server; this raises questions about versionability, immediately<br>
12. "Disruptive constraint solvers": In my experience, the biggest problem with constraint solvers today -- in terms of putting them into a language -- is that they are mostly designed by people who don't have professional training and experience designing languages<br>
13. "Distributed programming": Performance matters. The speed of light is your bottleneck. Stuff like fault tolerance isn't that complicated and the bigger issue will be what to distribute and how to distribute it, e.g. fast algorithms for dynamic reconfiguration that don't have long system pause characteristics<br><br>I'm going to conclude by saying the three stumbling blocks are size, complexity and trustworthiness. Paying attention to all of Todd P's "big problems" just puts your focus on solutions-oriented thinking, rather than fundamentals-oriented thinking.<br><br></p>
<div class="gmail_quote">On Mon, Mar 1, 2010 at 5:53 PM, Dirk Muysers <span dir="ltr"><<a href="mailto:dmuysers@...">dmuysers <at> hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote">
<div bgcolor="#ffffff" name="Compose message area">
<div>Everybody in this discussion should have read the
following:</div>
<div> </div>
<div><a title="http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAYQFjAA&url=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Ftoddpro%2Fpapers%2Fdisruptive.ppt&rct=j&q=proebsting+%2Bdisruptive&ei=TUSMS8PRKYS80gSKpMjRCw&usg=AFQjCNGlGioXg3dL2G5rekpa-U8dKuZAtg
CTRL + Click to follow link" href="http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAYQFjAA&url=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Ftoddpro%2Fpapers%2Fdisruptive.ppt&rct=j&q=proebsting+%2Bdisruptive&ei=TUSMS8PRKYS80gSKpMjRCw&usg=AFQjCNGlGioXg3dL2G5rekpa-U8dKuZAtg" target="_blank">http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAYQFjAA&url=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Ftoddpro%2Fpapers%2Fdisruptive.ppt&rct=j&q=proebsting+%2Bdisruptive&ei=TUSMS8PRKYS80gSKpMjRCw&usg=AFQjCNGlGioXg3dL2G5rekpa-U8dKuZAtg</a></div>
</div>
<br>_______________________________________________<br>
fonc mailing list<br><a href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br>
</blockquote>
</div>
<br>
</div>
RSS Feed