11 ms·
Leaked transcript of censored Bret Victor talk
- brohee 13y ago"I could tell you more stories from the Golden Age: Spreadsheets, HyperCard, Delphi, Visual Basic. These were all enormous successes, allowing normal people to get shit done. They are despised by all true hackers. Because normal people can use them to get shit done. That is our greatest fear." I'm actually a lot more frightened to be called for the cleanup...
- jaekwon 13y agoTitle is misleading. It's not actually a transcript of the talk.
- jroll 13y agoThis is great stuff, but I'm not sure what he means by "censored from the Internet". The video as posted is the entirety of the talk given at DBX. Was a longer talk given elsewhere?
- IanChiles 13y agoI'm tempted to say that this is satire of some kind, but I'm not completely sure...
- DanielStraight 13y agoI don't feel putting words in people's mouth is a good way to make a point, especially in a way that could be misleading at a casual glance. If you disagree with Bret, surely there is a better, more constructive way to explain your position. (That is, of course, based on the overwhelming likelihood that these aren't actually Bret Victor's words.)
- lkrubner 13y agoThe comments on this Hacker News page are a bit odd. The linked article is clearly offered as a bit of playful satire. In the same way that you are not suppose to read "A Modest Proposal" and conclude that we should all eat babies, likewise, you are not suppose to read this and believe these are Bret Victor's thoughts.
- coldtea 13y agoOT, but the casual reference to an obscure 18th century article by Jonathan Swift might make this comment indecipherable without Google for most people.
- nmcfarl 13y agoAs a counterpoint: For my social circle it's not remotely in the obscure category. I suspect that none of my friends or coworkers would have to look it up on Google... This is what a liberal arts education is for. -- Of course I realize that not everybody is lucky enough/even wants to get a liberal arts education, but the social/educational structure of America is not something I'm looking to attack this comment.
- doktrin 13y agoI thought this was part of a standard HS education? That is at least where I first encountered it. I also have a liberal arts education, but those fruitful years were reserved for prevaricating on and dissecting various obscure and convoluted logical arguments related to phenomenology.
- coldtea 13y ago>I thought this was part of a standard HS education? That is at least where I first encountered it. If you assume everybody on HN is an American, maybe.
- mjackson 13y agoThis is brilliant stuff. And yes, it's satire. Wish I could upvote a bazillion times.
- pertinhower 13y agoWhy are people upvoting this post? It's attention-baiting and deceptive.
- seanmcdirmid 13y agoBecause its good?
- derefr 13y ago> These were all enormous successes, allowing normal people to get shit done. They are despised by all true hackers. Because normal people can use them to get shit done. That is our greatest fear. No; I have to object to this specifically. Normal people can't "get shit done." Not really, not successfully. People, when you let them build their own tools in Excel and Access and what-have-you, end up with rosters full of incorrect and incomplete and invalid information, things split into so many different places that nobody can find anything any more, and interfaces that require inexplicable cargo-cult rituals and avoiding otherwise valid input states to use. Their stuff works 95% of the time; they just aren't used to a world where "5% failure rate" means "silently and consistently eats any customer's file if their name has a ç in it" instead of just "has to be restarted every hour." The thing programmers do--it isn't using arcane languages, recognizing mysterious error codes, memorizing APIs or libraries. We aren't here just because the difficulty of typing "/[A-Z]+?/" grants us job security. The thing programmers do--or more generally, the thing Engineers do--that other humans need us for, that machines can't do for us (yet), is to formalize murky ideas. People who don't have training in Engineering have no fucking idea how to go about doing this. You know the old joke of there being a button labelled "Do What I Mean"? It's a joke because 99% of the people who would press that button don't know what they mean; there would be no coherent thing for the button to do--even if it could read their thoughts--but to interrogate them for hours to get them to decide what they really want. The few of us--the Engineers--we can sit down, and without any further prodding, think out what we want to have happen. Then it's a simple matter of just writing it down. The compiler, the language, none of those are really problems, compared to knowing what you want to happen. Note that Bret's talks and essays are focused, by-and-large, on the iterative rapid-prototyping model: using computers as tools to help us explore options, so that we can more quickly figure out "what we want." But even if you know that you want a Sudoku solver, you can't iterate out a Sudoku solver. You have to know that what you want to do is to put these constraints, in this order, on these numbers--and that's an algorithm. People--not us Engineers, but people--they don't understand algorithms. You need an Engineer to take the statement "I want a Sudoku solver" and formalize that into "I want to use this algorithm." Just like you need an Engineer to take the statement "I want this bridge-support anchored to the riverbed here" and translate that into materials and rigging that will take the tensions and stresses without shearing. Neither COBOL, nor SQL, nor HyperCard, nor AppleScript, nor Inform, nor any other "human-friendly" language, ever served to allow anyone to express a clearly-defined thought they wouldn't have been able to express in a language with more "punctuation-y" syntax. Learning what "<=" or "&&" represent is a small, fixed cost at the beginning of attempting to solve problems. Learning what they mean--what the formalism is there, and what its consequences are--takes years, and requires that you think like an Engineer. That step is required whether you are using C, COBOL, LabView or Prolog. To get shit done, you must first know what done shit looks like; perfect, robust, unbreakably done shit. And only Engineers really do. Just like how people who aren't artists, if asked to draw someone's face, will end up drawing the abstraction of a face; people who aren't Engineers, if asked to formalize a system, will end up describing the vague, hard-AI-complete, "and then it just does what you'd expect okay!?" system that, in practice, isn't a system at all.
- bsaunder 13y agoSo I can see where Bret is coming from, many of this thoughts resonate with my ideas, but I'm not so sure there's an intentional conspiracy so much as just a simple alternate perspective that hackers have. We naturally think of things slightly different than non-programmers. Part of the reason the tools he mention were despised by "all true hackers" is that they were limiting frameworks. We, almost by definition, tend to dislike limitations (especially when we can wield all of the power of lower level languages). I was just pondering the other day with a co-worker, what it would be like to write a web server in xl (not sure you could, or would, but what would the mental model be like). It was an interesting experiment. It's a similar reason to why we tend to prefer libraries to frameworks. I like code that helps me get things done quicker, but not if it enforces some mental models or comes with implementation limitations. Just yesterday I was working around a problem with a certain framework that wasn't making the right system calls the way I needed it. I knew what I wanted from it but couldn't twist the right nobs to get it to happen.
- ilaksh 13y agoI think the real reason is more along the lines of what they are suggesting. Programming means writing obscure ASCII codes. Programmers are afraid to use any tool or language that doesn't look like source code or is easy to use. Because if you are doing that, then you aren't programming. And therefore, you're not a programmer. If its not complex or difficult for normal people to do, then you are not really programming, and therefore not a real programmer. All programmers are therefore afraid of tools that make programming easier, because they are afraid they will be judged by others as not being programmers. This is the main thing holding back programming.
- paulrademacher 13y agoAlthough HN policy is to change the original post title if it is misleading, adding "[satire]" in this case ruins it. Please allow the smart HN community to discover for themselves what this post is trying to say.
- jashkenas 13y agoYou're right. I put it in because it seemed like so many folks were flagging it down. But hey, let 'em flag.
- jonathanedwards 13y agoIronic that the author decries the hacker cult of cleverness by posting a clever satire.
- coldtea 13y agoNot very ironic. He doesn't decry cleverness per se, just using cleverness as a barrier from "the multitudes". (If I'm allowed the hacker cult of pedantry).
- tel 13y agoThere's a false dichotomy between educated and uneducated which is perpetuated by schools, indeed may be their entire point of existence. There's also a dichotomy between exploring an idea and solving a problem. Being ignorant is less good than being informed, but informing yourself is expensive. Becoming complacent due to your perceptions of your intelligence is foolish. Not exploring something because it's not in your skillful sweet spot can lead to failure to innovate. So, there's nothing surprising here. If you educate yourself more you'll tap into a wealth of knowledge about how to get things done more powerfully. If you use that as an excuse to step away from solving problems then you'll likely solve fewer problems, so hopefully you'll investigate things with greater theoretical validity (or else why bother?). More people using tools means that more people will become more informed and get more stuff done. Tools should not be made as to be inaccessible. But a technique or idea often begins as inaccessible and there may even be no way to make it more accessible. This does not mean that it is invalid and it may be that it gives people who master it greater power. Whenever learning, don't learn for learning's sake and don't learn to meet some end point defined by your teacher---seek what the master's sought. They often are solving real, practical problems and by training yourself to look for that perspective you can understand how to arm yourself with their knowledge in the way that they did. A person who generates knowledge in effort to solve a hard problem is usually one who is more than willing to throw that knowledge away if it does not serve them. Many problems are no longer as hard of problems as they once were. This is directly due to the fact that advanced technologies have become increasingly approachable and because larger bases of people have improved their mental technologies so as to use them. This is a great thing, but it's not an end state---harder problems still exist and gains can be made by tackling them. People can learn more things and more powerful ideas can be made the foundations of new mental technology to improve anyone's ability to solve problems. None of this is controversial.
- norswap 13y agoFirst I'm not sure if the words the author is putting in Brett's mouth are supposed to be ironic (i.e. the author argues against that line of reasoning) or not. I'm going to take them at face value. The post conveys the false idea that mathematical purity/simplicity and use simplicity are at opposite ends of an imaginary spectrum. If anything, the optimal is somewhere at their intersection. That is, the ideal tool should be mathematically simple and sound, while still being intuitive. We should also admit that we do not know of a good, reliable method to write good programs; and this fact is completely independent of the programming language used. Languages have different properties. Some are beginner-friendly, others scale well to large system, some both; but in all cases, what's valuable is the thinking that leads to the program. In another commenter's words: formalizing murky idea.
- DannoHung 13y agoAh another person talking shit about category theory. Category theory will make things simpler. Just give it time, it's very hard to work with that level of generality when you're not used to it and the dogma has not prepared you and the tools are all new.
- seanmcdirmid 13y agoOk, we can stop with the satire now. We all know monads are part of a long running inside joke that we normal humans will never really get.
- astrobe_ 13y agoHaskell 1.0: 1990. CAML: 1985. When then?
- DannoHung 13y agoWell, given that Haskell 1.0 didn't use category theoretic structures in any serious capacity and it's IO was based on lazy streams, I'd say it's already made things easier in Haskell. How long did it take for calculus to make things easier for most people?
- nbouscal 13y agoWhenever you actually put in the time and effort to learn and understand the abstractions. There are plenty of people who have done so and who are enjoying the benefits of having done so. I'm still a novice by comparison, and I still find my understanding of category theory as implemented in Haskell to make my life easier on a very regular basis, to the extent that coding in other languages for my day job is becoming more and more painful as time goes on.
- beyondcompute 13y agoThe person speaks about design. When system (our programming tool) is visible (read Donald Norman's "Design of Everyday Things"), provides immediate feedback, shows clearly defined constraints than the system is usable. When "you need the Category theory to use the system" (the theory is magnificent, it's a marvel of human mind, etc. Nobody spoke anything bad about the theory itself) than it's an embarrassingly awkward attempt to conceal one's failure at designing usable programming tool.
- teyc 13y agoFor any detractors of Excel and Access, I've news for you: "Software is eating up programmers" Programming as a fundamental activity, simply doesn't scale. The level of training required to get competent requires many years of training, while software is able to "download" a braindump of the best practices. For instance, Excel is used for a lot of business analysis. Business analysis, you say? How is 65535 rows sufficient? Excel, for instance has an engine that can process large amounts of data that's hosted externally using a vertical columnar compression. While a competent programmer with years of training may be able to do this themselves, they will not be able to beat on price when a person armed with half an hours tutorial can perform the same task on Excel. Yes, there are monstrosities and errors http://www.businessweek.com/articles/2013-04-18/faq-reinhart-rogoff-and-the-excel-error-that-changed-history http://www.businessweek.com/articles/2013-04-18/faq-reinhart... with Excel. The question is whether these errors are any easier to discover in a computer program. The reason we aren't seeing more of these software is because programmer-types don't think very hard about non-programmer's programming problems. I hope with Jon and Brett's work, we push the boundaries further, and make computer programs easier to modify and easier to reason (note: not just easier to write). In both Brett's and Jon's works, you don't avoid writing code. You just find it easier to figure out what effect a code change has. I saw the comment about using a traffic cone as a mutex. Again, this is a symptom of the dismal state of tools rather than the idea behind the tools themselves. VisualSourceSafe still performs pessimistic check outs. Imagine if the entire sourcecode of a project is in one single file, then better tools would evolve to find code, and allow many people modify it at the same time. We already know how to lock a database, provide MVCC. One day, programming will be very similar.
- the_cat_kittles 13y agoLetting off a little steam about this topic is good, it's irritating to me too. Hopefully this doesn't get taken out of context and actually attributed to Bret though.
- groby_b 13y agoThis is fantastic - I am completely in support of this. Remembering how much money the few people who still remembered COBOL made in the 1990s, I can't wait to clean up after the "normal people" get their "shit done".
- cLeEOGPw 13y agoLooks like somebody just read " How 'One Weird Trick' Conquered The Internet" article and used all the techniques described there to deceive HN users. Maybe this is an experiment. If so, you all must be ashamed that such a big part of you fell for it. And even trying to have a moderate discussion on a matter. "Hackers hate him! How 1 weird trick would help 5 year olds learn programming!" turns out work here as well as for others, all you need is more advanced deception.