It's a "must" in a hyperbolic sense - Dirk is just excited about a good presentation. I think any idea that encourages attempts at discovering perspectives different from those in fashion is important - this presentation falls into that category.
Cheers, Andrey On Tue, Mar 2, 2010 at 10:18 AM, John Zabroski <[email protected]>wrote: > 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. > > On Mon, Mar 1, 2010 at 5:53 PM, Dirk Muysers <[email protected]> wrote: > >> Everybody in this discussion should have read the following: >> >> >> 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 >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
