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

61–70 of 104 posts

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

#61

Post by seancorfield »

swah wrote: post #54
jcromartie wrote: post #41

Earlier quoted context omitted.

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

I kinda regret having chosen Clojure for my project. Its not that I can't express ideas in very little code, its just that my workflow is different from languages like Python. In Clojure, it seems that I can't apply the method of spike solution ( http://c2.com/cgi/wiki?SpikeSolution ) and then refactor it into working code like I do with languages like Python or C.

I'm curious why you feel you can't create spike solutions in Clojure?

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

#63

Post by plinkplonk »

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.

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

#64

Post by crc »

va_coder wrote: post #36
spaznode wrote: post #33

Earlier quoted context omitted.

Did you watch the video? He wasn't talking about tools and he wasn't talking about clojure. It was programming in general and if you have to ask if it's worth your time the obvious answer is no.

Yea I did, but I don't take what Rich says as gospel. I think for myself, not just about code but how I allocate my time.

> I think for myself

Then you should think that there may be others who aren't really that concerned about being their own boss and financial freedom(strange as it might sound); others who love learning new perspectives. Other than saying that clojure may not be worth your time, you offer no insight. Thanks for making your preference clear, now can we get back to discussing the talk?

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

#66

Post by chousuke »

jurjenh wrote: post #45
jemfinch wrote: post #20

Earlier quoted context omitted.

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

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 expressed in a test, to prevent similar bugs from happening again. In such a case, the test documents an unexpected corner case that the developer was unable to predict.

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

#67

Post by subb »

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…

I think the Unix philosophy jab is about data. Instead of using string/text file with no form, I think he's suggesting that a standard format (like JSON) could be much simpler.

HTTP is just that, a protocol : a standard way for two entities to communicate. In Unix, there's no protocol, its just text without any standard form, which makes it difficult to write tools.

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

#69

Post by automagical »

nebaneba wrote: post #65

At 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?

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

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

#70

Post by chousuke »

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 function and macro calls. For grouping and binding, vectors (and sometimes maps) are used instead.

In this manner Clojure manages to keep the roles of different data structures in code mostly simple.

Post reply on HN