Live data from Hacker News

Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

infoq.com

41–50 of 104 posts

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#41

Great 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 f…

To me, Clojure is about as productive as banging out a script in Ruby. It's way more productive than writing the same thing in any language where I can't (easily, or at all) just fire up a REPL and start hacking.

I can actually just crank out code that I use. It can be quick and messy. Clojure is not concerned with type theory and provable correctness.

But the end result of a quick hack, in Clojure, is often something (or is made of of parts) that can be applied to other problems by pulling it out into a library, or by abstracting one more argument to a function, etc..

I think someone like Gabriel Weinberg could get along just fine in Clojure, with much the same spirit as hacking Perl, but maybe with better results.

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#42
post #38

Earlier quoted context omitted.

Why do you consider code generators, monkey patching & DSLs to be "testing tools"?

I don't. I refer here only to their use in that context.

I see this mostly in Java. Outside, you can deal with simple dsls (it "should something") and simple functions (equal x, y).

But yeah, on Java and C# land, the complexities of the type system and the class based OO complect the testing, yielding this big complex testing system (which are large enough to be called testing frameworks).

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#43
post #4

A 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…

Difficulty of writing a test can certainly be a complexity indicator, but in my experience the evidence is against testing having served this purpose very well to date, at least for the kinds of complexity addressed in this talk. If you look at around 31:27 in the talk, you will see ten complex things, with proposed simple alternatives. If testing helped people feel the pain of complexity and discover simple things,…

Just look at this. He keeps rolling out what is usually hard earned wisdom gained over years of time of experience while constantly striving to improve yourself and any software you work on.

Do yourself a favor and take the shortcut of listening to this talk..not to say he may not join a cult religion at some future point in time and come out with crazy crackpot ideas then but everything I've seen and read so far are things that all senior+ quality engineers should find some common agreement with.

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#44
Great 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.

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#45

Earlier quoted context omitted.

He says relying on tests and type-checking to verify a program still does the right thing after making changes is "guardrail programming".

None of us do "guardrail driving", but we still put guardrails on roads.

However, 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...

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#46

Great 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…

Having 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....

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#47

Great 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…

Without being confident enough to have voiced it earlier, I thought similar thoughts. Clojure appears to depart from something that characterizes both traditional Lisp and Unix systems – having one universal interface, with a big emphasis on one. Though by the definitions he outline, that would perhaps be easy more than simple.

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#48

Earlier quoted context omitted.

This was done at Rich's request. I've asked whether we can release them now that the video is available.

Any chance of releasing the videos somewhere that doesn't require Flash?

I watched it fine on my iPad, it should be viewable in an HTML5-mp4 capable browser I guess.

Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011 [video]

#50

Earlier quoted context omitted.

He says relying on tests and type-checking to verify a program still does the right thing after making changes is "guardrail programming".

The slide where this comes up (~15:45) is about debugging. I think the point Rich is trying to make on that slide is that a bug in production passed the type checker and all the tests. Therefore, tests are not solving the problem of building high quality systems. Rather, tests (and type safety) are "guardrails" that warn when you when you are doing something wrong (they are reactive). As Rich said on Twitter ( https:…

Thanks for distilling it. Your comment makes me want to watch the presentation and also to perhaps take a closer look at Clojure. Good thoughtful reply.
Post reply on HN