## Good meetings and reading

### Questioning the idea of crusade
    
I've been doing a lot of questioning these days. Today I did my questioning with Omar Rizwan and my cofounder Eli. Maybe Bret's importing of the idea of "cause" from social activism into engineering isn't such a great idea? Maybe it's more fun and useful to solve problems for real people on their own terms - without having a bait-and-switch reason why.

### Finishing Learnable Programming
    
Technically not 100% finished, given that I need to read all references, and I'm [not entirely done](/notes/no-silver-bullet) with No Silver Bullet.

Author: Steve Krouse

_data/git-log.json

@@ -340,7 +340,44 @@ This reminds me of my idea to build a more human-readable regex. I continue refl
 
 ## Okay then
 
-...
+> The design principles presented in this essay can be used as a checklist to evaluate a programming system for learning.
+
+I am the only person I am aware of to [take this seriously](https://medium.com/@stevekrouse/woof-d9adf2110fc6).
+
+To evaluate this checklist, as a checklist, I'd have to say that it's more provacative than it is helpful.
+
+### These are not training wheels
+
+> A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" 
+
+Yep, I get this question a lot.
+
+> This is a reasonable question, but it's somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change.
+
+I'm not sure I buy this argument anymore. It's like asking, how the ICE will *interact* with horses, not benefit them. That would be akin to asking, how do these changes benefit programmers, which is not what these people are asking.
+
+> Here is a more useful attitude: Programming has to work like this... Given these requirements, how do we redesign programming?
+
+This is an emperical claim about the usefulness of a given attitude towards solving a problem. I am doubtful that it this is true.
+
+#### No Silver Bullet
+
+Hard to believe I've never read this before! Notes continued [here](/notes/no-silver-bullet).
+
+## Footnotes
+
+My acquaintance Christina Cacioppo (which makes sense) and Stripe's Patrick Collison (which is more confusing) gave feedback on this essay.
+
+And *another* imporing to read Mindstorms! I didn't realize he says it *4* times!
+
+## Reflections...
+
+Well it'd take so much time to reflect on my reflections on this essay that I don't even want to go there.
+
+But I will say that I got a lot out of this. It's difficult to imagine a world where I haven't read Will Wright, Fred Brooks, and the other tangents I went down here. I have a much deeper sense of Bret's world now that I've gotten a sense of his influences. I am excited to dig into Tufte, possibly tomorrow morning!
+
+This is less related to this particular essay, but... I'm also beginning to detect a communication style that Bret (and others in social activism) use that is compelling (because it plays off of our favorite emotion: outrage), but not helpful for solving problems. It makes me wonder where the "get up and go" to persue a social cause comes from, if not from outrage (or the desire to be right, or to achieve high status). That is, I am theorizing that people with social causes are *less*, not more, concerned with the happiness of other people, despite them purporting to work on their behalf. If they were truly interested in the needs of other people, why not help people in the terms which they want to be helped?
+
 
 <script>
 

notes/bret-victor/learnable-programming.md

@@ -0,0 +1,73 @@
+---
+title: No Silver Bullet
+---
+
+# [No Silver Bullet](http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBullet.html)
+
+Hard to believe I've never read this before!
+
+> Skepticism is not pessimism, however. Although we see no startling breakthroughs--and indeed, I believe such to be inconsistent with the nature of software--many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road.
+>
+> The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.
+
+Wow, this is a really powerful metaphor for me. It makes me think of Bret's "Future of Programming" DBX talk where he makes fun of how little progress we've made since the 1950s. But what if that's because back then there was so much more progress to be made? What if we've reached a plateu for *essential* reasons? What if the things we are trying to improve about software are difficult and take time, and would be better tackled slowly, and in the context of solving real world problems: that's where React and Cycle came from.
+
+## Does It Have to Be Hard?--Essential Difficulties
+
+### Complexity
+
+He says programming has large number of states, side-effects, duplication, non-composibility. Seems like functional programming solves many of these problems.
+
+### Conformity
+
+I'm not sure if he's talking about conforming to other software or to people's requirements here. If software, then he's talking about composibility/modularity/abstraction again, FP topics. If people, then that's essential complexity and not a problem in my book.
+
+### Changeability
+
+Software changes much more than most products. Huh this is so obvious but I never thought about it. Along with the complexity section, he makes strong arguments for why software development is *better* than other engineering displines. It's just that we hold it to a higher standard.
+
+### Invisibility
+
+> Software is invisible and unvisualizable. 
+
+Haha - this is directly attacked in Learnable Programming.
+
+## Past Breakthroughs Solved Accidental Difficulties
+
+### Unified programming environments
+
+Yeah, Unix really did get composibility right. It's like Haskell without the types.
+
+And that's what stinks about Unix: it's all one datatype: text. Unix with good types, a Haskell based OS, that would be cool.
+
+## Hopes for the Silver
+
+Lol, Ada.
+
+## Reflections
+
+His main argument is that in order to argue for a silver bullet, one must argue that 9/10 of the time programmers spend is on accidental complexity.
+
+> An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work involved in designing a program product. I doubt it.
+
+This is compelling. But a false way to analyze this. It focuses your attention on the *activities* of programmers, instead of on their *outputs*. If, for example, there was a one-button way to take an application from someone's brain and encode it to a binary program, that would be a many-order-of-magnitude shift in productivity. 
+
+Or another less crazy example is that building a in-browser text-editor is accidental complexity, only in the context of being able to use CodeMirror as a drop in solution. 
+
+In other words, essential vs accidental complexity is *context-dependent* in that it depends upon what you have to build upon.
+
+
+
+
+<script>
+
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+
+</script>
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>