4 ms·

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

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.

swannodette 15y ago
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.html http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey....
- radarsat1 15y ago
  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 worlds. That's a big advantage for Clojure.
  - agentultra 15y ago
    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.
    - radarsat1 15y ago
      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.
      - agentultra 15y ago
        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.
IvarTJ 15y ago
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.
subb 15y ago
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.
chousuke 15y ago
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.
- gruseom 15y ago
  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.
  - chousuke 15y ago
    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. :)

swannodette 15y ago

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.html http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey....

radarsat1 15y ago
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 worlds. That's a big advantage for Clojure.
- agentultra 15y ago
  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.
  - radarsat1 15y ago
    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.
    - agentultra 15y ago
      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.

IvarTJ 15y ago

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.

subb 15y ago

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.

chousuke 15y ago

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.

gruseom 15y ago
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.
- chousuke 15y ago
  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. :)