Browse files

continuing BV deep dive

  • Loading branch information...
stevekrouse committed Dec 14, 2017
1 parent 8674e0e commit 740cb7efb4bbea260db198af51a7d0692ed84fba
Showing with 67 additions and 3 deletions.
  1. +1 −1 _data/git-log.json
  2. +13 −2 notes/bret-victor/
  3. +23 −0 notes/bret-victor/
  4. +30 −0 notes/

Large diffs are not rendered by default.

Oops, something went wrong.
@@ -29,21 +29,32 @@ Another criticism is that much of the overly consice mathmatic lingo was still u
1. Use the english-word-analogy instead of the notation. Instead of `C(p) / C(0)`, you could just call it the "cliquishness of a network", not even explaining that you normalized it as compared to a regular network.
2. Visualize each sub-component of the equation. If you must expose the normalization computation, do it in a way I can explore. Show me what `C(p)` is as compared to `C(0)` so I can see how the normalization works.
3. [Colorized math equations](
Another idea: instead of small pictures of black circles and lines, the pictures could be much bigger and be of movie stars and movies as edges. That could be quite compelling!
A final point is that the data could be explorable all the way down, as Bret demonstrates in *Ten Brighter Ideas?*. Instead of simply trusting their data in the final graph, we could allow the reader to dynamically generate it based on various assumptions, thus making it fully citable and auditable to the core.
## [Scrubbing Calculator](!/ScrubbingCalculator) - May 31, 2011
Beautiful. Really clever way to get around symbols.
Looks like someone made it real:
One drawback of this interface is that doesn't allow you to import data.
Another is that you have to first make number and then connect them. It would be neat if it could automatically connect numbers with the same text description.
## [The Ladder of Abstraction](!2/LadderOfAbstraction) - Oct 2011
Wow, I didn't realize this piece meant so much to Bret! As he says [here](
> I've seen some people refer to "Inventing on Principle" as my "manifesto", which is understandable, but untrue. If you were to ask me for a personal manifesto, I'd probably have to point you to "Up and Down the Ladder of Abstraction". It uses a programming example, but it's not about programming. It's about a way of thinking. In particular -- a way of using representations to think powerfully about systems.
I've so internatlized walking up and down the ladder of abstraction, both through reading this essay, doing a lot of programming, particularly functional prorgramming, as well as taking and then TA-ing a comptuer architechture class (where we went [from electrons to C](/
As Bret explains, he "adopted the notion of "abstracting over a variable" from computer science. In particular, lambda abstraction corresponds directly to the sort of visual abstraction we're doing here." I'm pretty darn familiar with this proccess. I imagine this article might fall flat on an audience without functional-thinking experience.
## [A Brief Rant](!/ABriefRantOnTheFutureOfInteractionDesign) - Nov 2011
Vision without implementation is hard.
@@ -125,8 +125,31 @@ To compress information, think of it like the Huffman encoding but inside a huma
The key here is that expanding human capability is all abou the tools at the human's disposal, inside their brain and out. A person that seems smarter simply has better software installed. The bright side is: we can copy software between brains.
## Review: [Don't Kill Math](##
[Review published October 27, 2012 by Evan Miller]
> The unifying goal of Victor’s work, as he puts it in his Inventing on Principle talk (for all practical purposes, Victor’s manifesto) is to bring people into closer communion with their creative ideas. I personally applaud this goal, and would be hard-pressed to find anyone who is against it (who can oppose human creativity?).
Huh, that's a good point. This is strange because in that very talk Bret explains that one's crusade needs to be controversial. And yet his goal of bringing people closer to their ideas is something I imagine all people would agree with...
Holy shit this article is both scathing and well-thought-out. It may be the best critique of BV I've seen thus far!
Let's address Evan's points.
Firstly, he characterizes Bret's arguments as attacking "analytic methods." This is slightly confusing because BV uses the term "symbolic" to reference what he's unhappy about.
Secondly, Evan seems to think that Kill Math wants to replace all math with simulations. That's misleading because BV wants to replace symbolic math with "concrete modeling, simulation, and visualization," as stated in [Simulation as a Practical Tool]( Evan doesn't address BV's scrubbing calculator at all, which I think, would alleviate many of his concerns that Bret hates all analytical approaches. He simply wants to make them more concrete by leveraging our new magic paper.
Evan's critique of the "UP and Down the Ladder of Abstraction" ring true, yet I think he misses the point a bit. Bret is describing an approach to thinking about problems, not trying to truly solve one problem. Maybe a better, more real example would've helped.
There are a few things that Evan misses:
1. The reason that symbolic/analytical methods work for him (and people like him, including me) is that we've so thoroughly internalized how moving the knobs on the various bits of the equation will tweak things. I understand ratios physically through lots of suffering through not. What is math?
2. And that's just the basics. More complicated formula terrify me. It's incredibly hard to learn about a new formula from the symbols. How does Evan expect me to visualize `sin(theta) = r/h`? I can't do the inverse sin in my head! Imagine how much our magic computer paper could augment this formula to aid my inuition! Bret isn't saying we should do away with formula, but that we gotta be able to do better now that we have magic paper!
3. Evan talks about equations as being useful for the reader to understand how to model a problem, know what is important and what is irrelevant. I think that's akin to giving the punchline of a joke to a person so they can reason out what the joke must've been. Instead, [like Khalid suggests](, the technical definition is often the last thing you want to see. Humans learn through invention. Thus we should come to formulas the same way their inventors do: with our intuitions first. Symbols last. Concrete *then* abstract.
Finally, Evan scores a nice shot on BV by pointing out that he hides the underlying formula in his Explorable Explanation article. Yet this criticism rings false as he's criticizing the same guy who made [TenBrighterIdeas]( which allows you to see the entire model as well as edit the actual source code.
@@ -0,0 +1,30 @@
title: Halfway There
# Halfway There
_Mar 9, 2013, 9:44 PM_
[I wrote the following note to my students when I was a TA for CIS240 at the University of Pennslyvania.]
Just two short months ago, you came into CIS240 thinking that your iPhone is powered by the sheer willpower of Steve Jobs. However, now you conceptually understand how transistors work and how p- and n- type transistors come together in CMOS circuitry to form logic gates. You understand how they can be used to form useful things like D-flip flops to store state and adders to add those stored numbers. You learnt 2's-complement as a method of interpreting those numbers, and you understand how a 16-bit instruction can dictate control signals to a simplified processor. Finally, you understand how the commands of Assembly provide a thin layer of English abstraction over those binary instructions. So we still don't know exactly how iPhones work, but we can start to see how the iPhone's processor performs basic operations like arithmetic, predicate logic and memory storage.
A main theme of this course is abstraction. We understand p-mos and n-mos, so now we abstract with lines and circles. We understand D-Flip Flops, so now we draw boxes with triangles. We understand control signals, so now we use Assembly to instruct our LC4 processor in its computations. Looking forward into the second half of the semester, we will use our understanding of Assembly to see how C is yet another layer of abstraction over our increasingly complex model of computation. Yet, we are still a far cry of the comforts of a cozy Java IDE. When you want to deal with Strings in Java, you just go about your business creating, concatenating and substringing like it was a god-given right. Well, in C you are your own god and you've got to keep track of how and where you store every single character of your 16-bit ASCII String. And remember the friendly Java garbage collector that you never quite understood but was told to be thankful for? Well now you're going to be truly thankful for it, because in C you are your own garbage collector and you better not lose track of what memory is stored where or you'll be haunted by a pesky Segmentation Fault for hours.
If you have been struggling in this class thus far, don't worry: most of the points of the class have yet to come. You have plenty of chances to redeem yourself. If this class has been easy for you, also don't worry: it is about to get much more interesting and challenging. For most of you, the biggest challenge will be the sheer amount of code you will be expected to write on your upcoming homeworks. Up till now, you may have gotten away with starting your 240 homework the day it was due. This will no longer be possible. You cannot simply write hundreds of lines of code in a language you’ve barely know with error messages that will make you nostalgic for the Java tracebacks you used to hate. Be prepared to spend 10-15+ hours a week on 240 homework very, very soon.
We hope you all had a great, relaxing break and that you'll all excited to be heading back. We can't wait to teach you guys some C!
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
ga('create', 'UA-103157758-1', 'auto');
ga('send', 'pageview');
<script repoPath="stevekrouse/" type="text/javascript" src="/unbreakable-links/index.js"></script>

0 comments on commit 740cb7e

Please sign in to comment.