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

81–90 of 104 posts

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

#81

Post by agentultra »

radarsat1 wrote: post #60
swannodette wrote: post #46

Earlier quoted context omitted.

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

Importantly, 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 worl…

Big advantage for Clojure over what?

The point I was trying to make about parens is that I think Rich is creating a straw man from them. Parens in CL/Scheme don't have any special meaning other than demarcating lists. A Lisp compiler/interpreter just evaluates lists of symbols at the end of the day.

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

#82

Post by fogus »

amouat wrote: post #73
stuarthalloway wrote: post #40

Earlier quoted context omitted.

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

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

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

#83

Post by shoover »

jcromartie wrote: post #16
jsmcgd wrote: post #13

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

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

Another way to look at it is Clojure is a reification of his thoughts on simplicity.

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

#84

Post by bitsai »

radarsat1 wrote: post #60
swannodette wrote: post #46

Earlier quoted context omitted.

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

Importantly, 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 worl…

Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like:

length

vector-length

string-length

hash-count

set-count

...

Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.", which is one of the many reasons why I enjoy the language so much.

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

#85

Post by radarsat1 »

agentultra wrote: post #81
radarsat1 wrote: post #60

Earlier quoted context omitted.

Importantly, 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 worl…

Big advantage for Clojure over what? The point I was trying to make about parens is that I think Rich is creating a straw man from them. Parens in CL/Scheme don't have any special meaning other than demarcating lists. A Lisp compiler/interpreter just evaluates lists of symbols at the end of the day.

His point is that it puts together (complects.. ha!) lists, the data structure, and list-like operations into one and the same thing, when logically they are separate ideas. He's trying to point out that separating things brings simplicity, even if you end up with more of them, therefore unifying everything under one syntax for example is not necessarily "simpler". You may not agree, that's okay, but it's consistent with what he was saying, not a straw-man.

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

#86

Post by radarsat1 »

bitsai wrote: post #84
radarsat1 wrote: post #60

Earlier quoted context omitted.

Importantly, 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 worl…

Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like: length vector-length string-length hash-count set-count ... Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 func…

> "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."

Oddly enough though, you yourself are pointing out that it is better to have 1 function that operates on 10 data structures. ("length" operates on vectors, strings, hash tables, etc.) On the surface this seems opposed to the quote you chose.

However, it is clearer if you replace "data structure" with "interface". The is classic separation of concerns. When specifying the "what", we can get away with "100 functions operate on one interface", but the efficiency, the "how", can be specified independently based on the choice of data structure implementing that interface.

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

#87

Post by shoover »

plinkplonk wrote: post #63

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

Likewise, 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?

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

#88

Post by bitsai »

radarsat1 wrote: post #86
bitsai wrote: post #84

Earlier quoted context omitted.

Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like: length vector-length string-length hash-count set-count ... Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 func…

> "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." Oddly enough though, you yourself are pointing out that it is better to have 1 function that operates on 10 data structures. ("length" operates on vectors, strings, hash tables, etc.) On the surface this seems opposed to the quote you chose. However, it is clearer if you replace "data structur…

Yes, that is a better way of making the point. Thank you.

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

#89

Post by agentultra »

radarsat1 wrote: post #85
agentultra wrote: post #81

Earlier quoted context omitted.

Big advantage for Clojure over what? The point I was trying to make about parens is that I think Rich is creating a straw man from them. Parens in CL/Scheme don't have any special meaning other than demarcating lists. A Lisp compiler/interpreter just evaluates lists of symbols at the end of the day.

His point is that it puts together (complects.. ha!) lists, the data structure, and list-like operations into one and the same thing, when logically they are separate ideas. He's trying to point out that separating things brings simplicity, even if you end up with more of them, therefore unifying everything under one syntax for example is not necessarily "simpler". You may not agree, that's okay, but it's consistent…

That's where I think he is 'discovering' complexity and in fact creating some.

That code and data can both be represented as lists is a major feature of what makes CL so compelling.

And I suppose that is the major contention -- is 'code as data' a complex idea? I say it's simple. There's no difference between the data structure of the code and the data structures the code acts on, so using the same operations on either should be trivial. With a handful of simple evaluation rules and a small number of special forms you can bootstrap an entire language written entirely in itself. Functions, classes, interfaces, namespaces, the whole nine-yards. The list is just an implementation detail and it's a very simple one that enables some very elaborate structures.

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

#90

Post by swannodette »

agentultra wrote: post #89
radarsat1 wrote: post #85

Earlier quoted context omitted.

His point is that it puts together (complects.. ha!) lists, the data structure, and list-like operations into one and the same thing, when logically they are separate ideas. He's trying to point out that separating things brings simplicity, even if you end up with more of them, therefore unifying everything under one syntax for example is not necessarily "simpler". You may not agree, that's okay, but it's consistent…

That's where I think he is 'discovering' complexity and in fact creating some. That code and data can both be represented as lists is a major feature of what makes CL so compelling. And I suppose that is the major contention -- is 'code as data' a complex idea? I say it's simple. There's no difference between the data structure of the code and the data structures the code acts on, so using the same operations on eith…

There's nothing you've expressed that doesn't apply to Clojure as well. I'm assuming you haven't done much Clojure and thus can't really illustrate what the problem is in practice.
Post reply on HN