35 ms·

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 doe

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. :)
  - gruseom 15y ago
    Adding things means more things, which means more complexity. Doing so is a net win only if the new things subtract more complexity than they add. To figure out whether they do, you have to consider the system as a whole. That much is clear. Do we know how to do that? Not really. Empirical studies favor the simplest measurement of program complexity: code size. So that part is roughly taken care of. But I don't know of a good definition of "system". What counts as a single system and what counts as separate interacting systems, or subsystems? It's in the eye of the beholder. If I take 90% of a program and call it a library, has my program become 1/10 as complex? Rich says his definition of simplicity is objective, but it's not. What determines whether a construct has a single purpose? It's whether or not, on inspection, you think it does. S-expressions seem to me to have a single purpose: to group things. How those groups of things are treated by the evaluator is a separate concern. You, following Rich, say no, they have 3 purposes. Ok. Why not 4? A function call and a macro call have different purposes; why conflate those? (I have no trouble reading function calls in s-expressions, but sometimes run into trouble not knowing that they are really macro calls, so this is not a made-up point.) We have no objective basis for this type of discussion, only emotions and beliefs. Concepts like "readability" are hopelessly relative, but appeals to "ease of future change" are no better; to put it politely, they depend on individual perspective and experience; to put it bluntly, we imagine them.
    - chousuke 15y ago
      I don't agree with your assessment that adding things necessarily increases complexity. Assuming these things are simple (in the objective sense as defined by Rich), actually suitable for the problem, and used correctly, then any complexity arising from their use is necessary to solve the problem, and can't be avoided. The definition of a system in this case is anything with one or more components that accomplishes a particular purpose. It still seems you're using a different definition of complexity than I am. To me, complexity implies unnecessarily intertwined elements. In your hypothetical library situation, the answer is likely no. Your program still depends on the "library" code in ways that make the two not treatable as standalone entities, so no complexity has been removed. An inherently complex tool may solve the specific problem it's built for, but it does not combine well with other tools. A simple tool tries to keep itself standalone so that can be freely combined with other simple tools to provide functionality that the original authors of either tool might not have envisioned. Clojure has many examples of this idea in action, but it's not the only language to exhibit simplicity. I think Rich's definition of simple is straightforward and objective. For example, Clojure protocols fit the definition. They give you freely extensible polymorphism based on object types. Protocols don't even provide a direct way to do inheritance. That can be done by using a map of functions that you modify as needed, but requires no explicit support. Your defense of s-expressions is rather puzzling. The evaluator defines what s-expressions (lists) mean in CL, and depending on context, there are multiple meanings that are completely separate. Certainly you can argue that Clojure conflates macro and function calls too (it is justified to me though, since they're all operators), but it has at least reduced complexity by not conflating binding and grouping with those elements. As an added benefit, with few exceptions, whenever you see a list form in Clojure you can assume it's either a function call or a macro of some sort.

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. :)
- gruseom 15y ago
  Adding things means more things, which means more complexity. Doing so is a net win only if the new things subtract more complexity than they add. To figure out whether they do, you have to consider the system as a whole. That much is clear. Do we know how to do that? Not really. Empirical studies favor the simplest measurement of program complexity: code size. So that part is roughly taken care of. But I don't know of a good definition of "system". What counts as a single system and what counts as separate interacting systems, or subsystems? It's in the eye of the beholder. If I take 90% of a program and call it a library, has my program become 1/10 as complex? Rich says his definition of simplicity is objective, but it's not. What determines whether a construct has a single purpose? It's whether or not, on inspection, you think it does. S-expressions seem to me to have a single purpose: to group things. How those groups of things are treated by the evaluator is a separate concern. You, following Rich, say no, they have 3 purposes. Ok. Why not 4? A function call and a macro call have different purposes; why conflate those? (I have no trouble reading function calls in s-expressions, but sometimes run into trouble not knowing that they are really macro calls, so this is not a made-up point.) We have no objective basis for this type of discussion, only emotions and beliefs. Concepts like "readability" are hopelessly relative, but appeals to "ease of future change" are no better; to put it politely, they depend on individual perspective and experience; to put it bluntly, we imagine them.
  - chousuke 15y ago
    I don't agree with your assessment that adding things necessarily increases complexity. Assuming these things are simple (in the objective sense as defined by Rich), actually suitable for the problem, and used correctly, then any complexity arising from their use is necessary to solve the problem, and can't be avoided. The definition of a system in this case is anything with one or more components that accomplishes a particular purpose. It still seems you're using a different definition of complexity than I am. To me, complexity implies unnecessarily intertwined elements. In your hypothetical library situation, the answer is likely no. Your program still depends on the "library" code in ways that make the two not treatable as standalone entities, so no complexity has been removed. An inherently complex tool may solve the specific problem it's built for, but it does not combine well with other tools. A simple tool tries to keep itself standalone so that can be freely combined with other simple tools to provide functionality that the original authors of either tool might not have envisioned. Clojure has many examples of this idea in action, but it's not the only language to exhibit simplicity. I think Rich's definition of simple is straightforward and objective. For example, Clojure protocols fit the definition. They give you freely extensible polymorphism based on object types. Protocols don't even provide a direct way to do inheritance. That can be done by using a map of functions that you modify as needed, but requires no explicit support. Your defense of s-expressions is rather puzzling. The evaluator defines what s-expressions (lists) mean in CL, and depending on context, there are multiple meanings that are completely separate. Certainly you can argue that Clojure conflates macro and function calls too (it is justified to me though, since they're all operators), but it has at least reduced complexity by not conflating binding and grouping with those elements. As an added benefit, with few exceptions, whenever you see a list form in Clojure you can assume it's either a function call or a macro of some sort.