Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

infoq.com

Post reply on HN
Print view View original

91–100 of 104 posts

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

#91

Post by amouat »

fogus wrote: post #82
amouat wrote: post #73

Earlier quoted context omitted.

I'm sorry; I think I'm being dense - what is their use in that context? (I don't disagree with your main point, but I don't quite see where those techniques fit in).

Some examples off the top of my head that use these techniques: * code generators: Visual Studio, Eclipse * monkey patching: RSpec * natural language DSL: Cucumber

Thanks! Very good examples.

I can see how monkey patching could be useful in mocking or something similar. I've never really used a language that supports it though.

I'm not entirely sure what Eclipse's code generation has to do with testing, but given the other examples I'll assume I'm being stupid again ;) I'm actually working with a lot of EMF generation stuff at the minute which can be quite painful.

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

#93

Post by Kafka »

loumf wrote: post #29
brianm wrote: post #27

Earlier quoted context omitted.

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

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

If I'm not mistaken he also mentions LINQ wich is a wonderful extensions of C# and the .NET Framework. It feels like LINQ and Clojure could be a interesting match.

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

#94

Post by gruseom »

chousuke wrote: post #70
agentultra wrote: post #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…

Clojure is homoiconic just as much as CL and Scheme are. It just happens to use more than one datastructure to represent code. The "oneness" in other lisps does not make things simpler, nor, in my opinion, easier. The reason why parens (lists) in traditional lisps are not simple is that they complect several different purposes. In contrast Clojure uses list forms (almost) exclusively for "active" expressions such as…

The reason why parens (lists) in traditional lisps are not simple is that they complect several different purposes.

You've repeated what Hickey says in the talk, but I'm not sure I buy it. [Deleted boring stuff about boring parens here.]

The trouble with the general argument is that you can add constructs that are individually simpler but nevertheless make a system more complex. It's overall complexity that we should seek to minimize.

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

#95

Post by malkia »

abscondment wrote: post #6
jhickner wrote: post #5

Earlier quoted context omitted.

If you mean just the slides, most of them are in this github repo: https://github.com/strangeloop/2011-slides

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

That was Easy! (pun intended)

Great talk by Rich Hickey, and thanks for the script.

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

#96

Post by malkia »

markokocic wrote: post #72
abscondment wrote: post #6

Earlier quoted context omitted.

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

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

This is in no way Linux specific - most likely OSX can do it, and with enough time cygwin too. Probably BSD's and others...

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

#98

Post by skew »

jemfinch wrote: post #20
postfuturist wrote: post #7

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.

I enjoyed being a passenger for some "guardrail driving"

http://www.eurail.com/planning/trains-and-ferries/high-speed...

These too run on rails.

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

#99

Post by chousuke »

gruseom wrote: post #94
chousuke wrote: post #70

Earlier quoted context omitted.

Clojure is homoiconic just as much as CL and Scheme are. It just happens to use more than one datastructure to represent code. The "oneness" in other lisps does not make things simpler, nor, in my opinion, easier. The reason why parens (lists) in traditional lisps are not simple is that they complect several different purposes. In contrast Clojure uses list forms (almost) exclusively for "active" expressions such as…

The reason why parens (lists) in traditional lisps are not simple is that they complect several different purposes. You've repeated what Hickey says in the talk, but I'm not sure I buy it. [Deleted boring stuff about boring parens here.] The trouble with the general argument is that you can add constructs that are individually simpler but nevertheless make a system more complex. It's overall complexity that we should…

How does adding several independent simple things make systems more complex in a way that is unavoidable (ie. incidental complexity, not problem complexity)? The interaction between simple elements will be explicit, whereas complex elements by definition interact in ways that you can't control.

Of course, sometimes the complex tool might be exactly what you need to solve your problem, making things easier. But in cases where you need only a part of the functionality of this tool, the complexity bites you as all the unneeded functionality (along its cost) is forced on you.

What sort of "overall complexity" does having several data structures in code introduce? As Rich Hickey says in his talk, complexity is not about cardinality.

In Clojure's model, the elements are distinct, and as such there is more simplicity in the system than in lisps where you have to understand the difference ("untangle" the complexity) between several different uses of lists to get anywhere.

I also think having several datastructures makes code easier to read due to the visual differences, but that's a separate discussion. :)

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

#100

Post by dvogel »

chousuke wrote: post #66
jurjenh wrote: post #45

Earlier quoted context omitted.

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

I think to begin with it's futile to try to cover all relevant behaviour in tests as you introduce new code. Some basic functionality tests will do fine to prevent anyone from completely breaking the code, as well as providing fair documentation as to what the developer expects the code to do. However, I think regression tests are useful. Once you find a bug and fix it, the things learned from fixing the bug can be e…

Your regression tests sound very similar to what I call perl tests. The perl community was ahead of it's time by distributing a test suite with packages on CPAN. Tests that come out of bug fixes tend (at least for me) to be complexity tests. Essentially they are a 2x2 test of the interaction of pairs of conditional paths with some interaction between them. This dovetails nicely with Rich's point -- keep things simple but in those few inevitable areas where complexity will arise, make sure you can reason about them. I just write regression tests around them to ensure that my reasoning about them is correct. Rich skips the tests because he's better at remembering or re-reasoning through them again :)
Post reply on HN