10 ms·
Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]
- falava 15y agoYou may also want to look at this other great video: Stuart Halloway: "Simplicity Ain't Easy" http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694 http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy...
- ExpiredLink 15y agoThis kind of arrogance has no future.
- ironchef 15y agoUgh. Why don't they release the presos as opposed to having to deal with synchronous video?
- jhickner 15y agoIf you mean just the slides, most of them are in this github repo: https://github.com/strangeloop/2011-slides https://github.com/strangeloop/2011-slides
- abscondment 15y agoFor some reason, these slides are only available in a flash widget that's synchronized with the video. Here's a little script to grab the flash and build a PDF for yourself. ImageMagick and swftools required. #!/bin/bash for s in {1..39}; do wget http://www.infoq.com/resource/presentations/Simple-Made-Easy/en/slides/$s.swf; done for swf in *.swf; do swfrender $swf -o $swf.png && rm $swf; done convert `ls *.png -x1 | sort -n | xargs echo` slides.pdf rm -f *.swf.png [Edit: required packages]
- markokocic 15y agoI agree with "teach a man to fish ...", but you know, some people are far away from the sea (linux) so just providing them with the fish (pdf) is also a good option.
- malkia 15y agoThat was Easy! (pun intended) Great talk by Rich Hickey, and thanks for the script.
- ironchef 15y agoAwesome! Thx!
- puredanger 15y agoThis was done at Rich's request. I've asked whether we can release them now that the video is available.
- JoshTriplett 15y agoAny chance of releasing the videos somewhere that doesn't require Flash?
- puredanger 15y agoNo, sorry.
- ludwigvan 15y agoI watched it fine on my iPad, it should be viewable in an HTML5-mp4 capable browser I guess.
- JoshTriplett 15y agoSure enough, if I fake my User-Agent as an iPad, I get a <video> tag referencing a .mp4, which I can then download and watch. Now if only infoq would provide a "download" link pointing to the same .mp4.
- spooneybarger 15y agoI have no interest in seeing slides, I want video.
- jasonwatkinspdx 15y agoThis is my number one gripe about infoq. I love skimming slides to see if it's worth investing an hour in watching a talk.
- neopanz 15y agoI empathize, but at the same time, 5 min. of slide browsing would not drive the point home. People are trying to skimp when they should invest the time. Relax, reserve yourself an hour and enjoy the talk. This is a good one, and getting signals through sound, visual and text will leave a better imprint in our brains.
- gregwebs 15y agoA good talk. Leave it to a lisper though to call testing and type-checking "guardrail programming". Hickey says instead you should reason about your programming without acknowledging that testing and type-checking are ways to have executable documentation of your reasoning about your program. Testing does in fact feedback into complexity - if something is hard to test it may be due to complexity that you realize you should get rid of.
- postfuturist 15y agoHe says relying on tests and type-checking to verify a program still does the right thing after making changes is "guardrail programming".
- jemfinch 15y agoNone of us do "guardrail driving", but we still put guardrails on roads.
- jurjenh 15y agoHowever, on most highways the guardrails are only on the dangerous sections. So sticking with this analogy, we should only need to use testing in the more intricate / complex parts of our code. However, current testing best practice seems to be to test everything possible, thus potentially wasting a lot of time and effort into aspects with a low ROI. There could be some lesson in this...
- bitops 15y agoThat's an interesting point. I've noticed that as I grow as an engineer, I still place a high importance on tests, but the type of tests I write and how I write them has changed a lot. When I first started testing it seemed like the world suddenly got really scary and now I had to test everything. I ended up testing ridiculous stuff, things that the language would provide by default. (I did this in many languages which is why I don't mention a specific one). What I've found valuable as I do testing (I do TDD) is that it has made me change how I think about design and composability. I agree that there should be a greater focus on "what is appropriate to test" but even knowing how to write tests and what to test is a skill in itself.
- deleted 15y ago[deleted]
- jsmcgd 15y agoFor me this was the best talk I've seen in a long while. It reminded me of how I felt when I first read PG's essays, someone articulating your own suspicions whilst going further and deeper and bringing you to a place of enlightenment and clarity. BTW for those of you who haven't watched it, this talk is not Clojure specific.
- jcromartie 15y agoHowever it's a great advertisement for Clojure, since the set of things he highlights as enabling simplicity is pretty much a subset of Clojure (or included libraries, like core.logic). I'd be interested in seeing someone present a different and convincing set of concepts. At this point, I think Rich has put together a very good toolset.
- brianm 15y agoWell, yes, IIRC he described one of his major goals with Clojure as enabling simplicity, or something like that. That Clojure's design follows his views on simplicity seems natural. Non-Clojure examples would help make the point. He does bring up examples from Haskell (such as type classes) in the talk in places, but doesn't dive deeply into them.
- loumf 15y agoSQL and Prolog were also cited, but yes, nothing very deep (which I think is fine for this talk) I would love to see the programs that are generated from this philosophy.
- bitops 15y agoYour comment made me take heart if I understand it correctly. Sometimes I feel I'm the only person out there who thinks SQL has a certain beauty and elegance. I find it a little funny sometimes to hear all these "web scale" folks put down SQL, and then praise something like MongoDB because you can do map/reduce. I saw a presentation by the author of the Lift framework in Scala and he made a bit of a joke saying "gosh...all this FP stuff...the folks who created SQL heard about that a long time ago".
- neopanz 15y agoI feel smarter having watched this talk: it gives you tools to think about thinking as you come up with new designs. Also love how Rich manages to find the right metaphors to illustrate abstractions, he's a great communicator.
- deleted 15y ago[deleted]
- va_coder 15y agoGreat presentation, but it got me thinking. Am I wasting my time trying to get software just right? Is it worth my time to learn Clojure or Haskell, when I don't even know what I'll use it for? How many programmers do you know that are learning all kinds of languages and technologies and methodologies and other things to improve the quality of the software they write and yet will probably sit at a desk writing code for the next 30 years? As opposed to starting a business, getting financial free, etc. Take the guy from Duck Duck Go. He wrote all of that in Perl; talk about easy, but not always so simple (to maintain). What if he spent his time learning Lisp and Monads instead of writing an app that lots of people use?
- tlrobinson 15y agoI find I can't learn a language very well without having a real project to use it on anyway.
- va_coder 15y agoThat's true. I'm just thinking my time might better be spent thinking about business ideas, and then trying those ideas out on Heroku. As opposed to learning about some technology that may make me a better programmer but may not really help me get to where I want to be, which is having a successful product that I own equity in. Is it really worth my time to learn the intricacies of functional programming? Am I still going to be writing code for some corporate overlord 5 or 10 years from now?
- fogus 15y agoAm I still going to be writing code for some corporate overlord 5 or 10 years from now? Isn't that up to you?
- takeoutweight 15y agoI fear you've missed the thrust of Rich's talk. Functional programming may seem "intricate" because it is unfamiliar, but if you're willing do do a little bit of up-front unlearning of the massively complex (but familiar) tools you're used to, you may find yourself able to work on projects of a much bigger scale and functionality. See the slide at 17:20 -- easy stuff (perl,ruby, blurb) gives you 100% speed at the beginning of a project. If you don't expend effort into making things simple, you will "invariably slow down over the long haul."
- spaznode 15y agoI can't add anything more to what @jsmcgd said but Rich's strange loop talk really brightened my day and more importantly gave me the tools to express what I sometimes try to share with other developers in the clearest way possible. Thanks man, really awesome talk. Invaluable if more people could start thinking this way. (which it sounds like oracle/java 7,8,.. will also help to do whether they like it or not and that's also awesome for that general clump of dev brethren)
- deleted 15y ago[deleted]
- agentultra 15y agoGreat talk. Simplicity is, of course, key; but a few of his applications of these principles are misguided IMO. Ex: The "Parens are hard!!" slide. He suggests that parens are "overloaded" in CL/Scheme because they are used to wrap functions, data, and structures all the same. However he completely misses the fact that by representing everything with parens, CL/Scheme remove a lot of complexity in software written in those languages. AFAIK, the only languages that do macros right are homoiconic. Anything else is too complicated. Just look at Perl 6 and Haskell macros. They require learning special syntax and really crazy semantics. Using them will probably just make your program more difficult to understand. He also "rails" against testing. He misses the virtues of a proper testing infrastructure in producing reliable software: if you don't test it, how do you know if it works? Because you reasoned about it? How do you know you're reasoning is correct? True, "guard rail" testing isn't a crutch that will automatically produce reliable software. But I think Rich relies too much on this narrow view of testing to make his point. Testing is good and necessary. And the jab to the Unix philosophy? ("Let's write parsers!"). Isn't that what we do on the web anyway? AFAIK, HTTP is still a text-based protocol. Any server that speaks the protocol has to parse a string at some point. So what was he getting at there? The Unix philosophy is about simplicity and has a lot to offer in terms of how one can design software to be simple. Overall though, it's a great talk. I just think that if he wants to get pedantic then he could be a little more thorough and less opinionated. Everything he said about designing simple systems I pretty much agree with, but I think he glosses over some finer points with his own bias of what simplicity means.
- swannodette 15y agoHaving written a bit of Scheme and Clojure - Clojure's distinction between data structures make many things simpler - from writing code to writing macros. As far as his comments on testing - I suggest you read this, http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey.html http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey....
- radarsat1 15y agoImportantly, it should be mentioned that despite the way it distinguishes between different data structures, Clojure manages to retain the advantage of "representing everything with parens" by instead making sure that everything implements a common _interface_, (i.e., seq). In other words, as opposed to CL or Scheme, it separates logical list manipulation from the physical data structure, giving the best of both worlds. That's a big advantage for Clojure.
- typicalrunt 15y agoSlightly OT: What's the name of the template used in his presentation? It's beautiful and has a nice contrast of colours.
- puredanger 15y agoThat's a stock Keynote theme called Industrial.
- plinkplonk 15y agoThe interesting thing about this talk is how Hickey's (very valid) distinction between "easy/familiar" and "simple/unentangled" can be applied to argue for powerful type systems like Haskell's or OCaml's. Likewise with the "benefits vs tradeoffs" argument.
- shoover 15y agoLikewise, some points in the talk brought to mind the OO SOLID principles. It's unfortunate that much of the discussion I saw on HN and twitter after this talk was argument about the value and purpose of testing. More useful would be examining the point of the talk and considering any common ground between Rich's "Simplicity Toolkit" and where things stand now with languages that aren't Clojure. Take your language of choice. If you're not in a Lisp already, you can't do much about syntax vs. data, but what about the rest? Is it easy to work generically with data and values instead of making custom classes and mutable objects for every piece of data? Is it possible? Can we make it better? Are there persistent collections or managed refs available? Can we write them as libraries? Within the language's polymorphism construct, can we extend a type we don't control to our abstractions without creating adapters and more complexity around value and identity? What about transactions?
- nebaneba 15y agoAt 55:20 he says, if you have A calling B all the time, you should "Stick a queue in there." What is an example of this?
- automagical 15y agohes talking events i guess, instead of A saying "B do this" it just pushes "i want this done" in a queue. and someone else, may be B, could dequeue and get it done. this decouples A and B.
- chousuke 15y agoI suppose he means that instead of A calling B directly, A should put work in a queue and B should consume from it, thus decoupling the two entities.
- ShardPhoenix 15y agoGood talk - reminds me of Yegge's recent rant about the Service Oriented Architecture, but coming from another angle (internal use vs. external).
- vseloved 15y agoRich is a good philosopher. Although it's often hard to strictly follow your own principles in your real-life work - and Clojure shows that often ;)
- Sikul 15y agoCan anyone explain how pattern matching causes complexity?
- mnicky 15y agosee http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/c2t7a9f http://www.reddit.com/r/programming/comments/lirke/simple_ma...
- malkia 15y agoI wonder what would Rich think of automake, autoconf and cousins? is it simple, is it easy, or simply esoteric? It confuses the hell out of me :)