4 ms·

The problem with these sentiments is that complexity is relative--what one developer finds simple another can completely reasonably find complex. So yes, excess

by tikhonj 15y ago

The problem with these sentiments is that complexity is relative--what one developer finds simple another can completely reasonably find complex. So yes, excess complexity is bad, but what defines excess? Are two Python nested for-loops significantly "more complex" than, say, foldM? I think so, but others obviously disagree--van Rossum thinks even normal folds are more complex! The real interesting question is not whether you should strive to make your code complex (clearly not) but rather what "less complex" actually entails. Does this mean less moving parts? More parts that are simpler? More verbose code that is more explicit? Less verbose code that is easier to read at a glance? More math? Less math? Code that looks uniform? Code specialized to the given domain (and therefore less uniform)? I have strong opinions on these questions, but I have no answers. I've met others with strong opinions exactly the opposite of mine. They don't have the answers either. It is, ultimately, not an easy question.

spacemanaki 15y ago
An interesting assertion in Rich Hickey's Simple Made Easy talk is that simple and complex are almost objective qualities, at least when you accept the definitions he puts forth (simple: one fold/braid with no interleaving). I think he's right, but I'm not sure I agree entirely, only because I haven't spent enough time thinking about it and trying to apply the ideas to real world problems. I do think that most programmers can call out complexity without a lot of disagreement. What you describe regarding fold vs for-loops touches on his definition of easy, that is to say "close at hand". Fold is easy for a functional programmer, for-loops for a Python programmer. Their simpleness might be a different matter. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
kalininalex 15y ago
The answer actually IS objective. The limit of complexity is defined by the fact that our short-term memory can simultaneously hold only five entities, plus or minus two. So, if the code requires one to hold more than seven elements in mind simultaneously - no one will be comprehend it, even the programmer who wrote it. I once inherited a module written by a more junior developer. He indiscriminately used several dozen global variables that were used and modified in various parts of the program without much of a system. I spent about two months trying to understand how the module worked without much success. Ultimately, I had to completely re-write it (with great difficulty) to get rid of global states, and bring the number of entities affected by each function to under five-to-sever. This biological limitation affects our development tools. That's why we have object-oriented programming. The goal is to keep the number of items we have to deal with at any moment under that magical limit of five to seven. Incapsulation is a key component of OOP used for this purpose. Without it all will be lost. Sometimes I think of an alien race capable of keeping track of 100 items simultaneously, and try to imagine what their programming languages look like.. :)
- dennisgorelik 15y ago
  That limitation is not exactly biological. I'm pretty sure that alien mind (or artificial mind) would have pretty similar limitation. It could be "10 entities" instead of "5 entities", but the number of simultaneous entities in "processing model" would not be much higher. The real reason for such limitation is that number of possible connections between objects is growing very quickly. For example, 2 entities connect with each other by 1 connection. 3 entities connect by 3 connections. 4 entities connect by (4 * (4-1)) / 2 = 6 connections 5 entities -- 10 connections. 7 entities -- 21 connections. 10 entities -- 45 connections (4.5 times higher than for 5 entities). Number of possible connections between entities defines complexity of the model.
  - kalininalex 15y ago
    Good point. Connections make the situation even worse (for aliens). Interestingly, it's about the same for humans: 3-4 entities produce 3-6 connections. Both are in the same neighbourhood. The limitation is biological though (http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...).
    - sirclueless 15y ago
      I think what Dennis means is that there is a philosophical reason why working memory is limited, and it's not just an idiosyncrasy of organic meat-brains. Of course the specific number is highly affected by human biology.
- grncdr 15y ago
  The question that comes to mind for me: how do we define "entities" in the context of writing software? Especially given gorelik's observation that complexity really derives from the combinatorial explosion of connections, are objects with internal state the best way to manage that complexity? If every call of a public method from another object is a connection in the graph our entities are an (object, message) pair, and a situation involving 3 objects with 3 public methods each exceeds our limitations. Contrast this with a pure-functional approach. If you can express your algorithm with immutable data and operations that create new transformations of that data, you could (hypothetically) have fewer things in mind at any one time: the data being operated on, and the single operation being performed. It doesn't break down quite so cleanly in reality, but use of pure functions where possible largely obviates the benefits of state encapsulation as provided by most modern OO languages.

by tikhonj 15y ago

spacemanaki 15y ago

An interesting assertion in Rich Hickey's Simple Made Easy talk is that simple and complex are almost objective qualities, at least when you accept the definitions he puts forth (simple: one fold/braid with no interleaving). I think he's right, but I'm not sure I agree entirely, only because I haven't spent enough time thinking about it and trying to apply the ideas to real world problems. I do think that most programmers can call out complexity without a lot of disagreement. What you describe regarding fold vs for-loops touches on his definition of easy, that is to say "close at hand". Fold is easy for a functional programmer, for-loops for a Python programmer. Their simpleness might be a different matter. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

kalininalex 15y ago

The answer actually IS objective. The limit of complexity is defined by the fact that our short-term memory can simultaneously hold only five entities, plus or minus two. So, if the code requires one to hold more than seven elements in mind simultaneously - no one will be comprehend it, even the programmer who wrote it. I once inherited a module written by a more junior developer. He indiscriminately used several dozen global variables that were used and modified in various parts of the program without much of a system. I spent about two months trying to understand how the module worked without much success. Ultimately, I had to completely re-write it (with great difficulty) to get rid of global states, and bring the number of entities affected by each function to under five-to-sever. This biological limitation affects our development tools. That's why we have object-oriented programming. The goal is to keep the number of items we have to deal with at any moment under that magical limit of five to seven. Incapsulation is a key component of OOP used for this purpose. Without it all will be lost. Sometimes I think of an alien race capable of keeping track of 100 items simultaneously, and try to imagine what their programming languages look like.. :)

dennisgorelik 15y ago
That limitation is not exactly biological. I'm pretty sure that alien mind (or artificial mind) would have pretty similar limitation. It could be "10 entities" instead of "5 entities", but the number of simultaneous entities in "processing model" would not be much higher. The real reason for such limitation is that number of possible connections between objects is growing very quickly. For example, 2 entities connect with each other by 1 connection. 3 entities connect by 3 connections. 4 entities connect by (4 * (4-1)) / 2 = 6 connections 5 entities -- 10 connections. 7 entities -- 21 connections. 10 entities -- 45 connections (4.5 times higher than for 5 entities). Number of possible connections between entities defines complexity of the model.
- kalininalex 15y ago
  Good point. Connections make the situation even worse (for aliens). Interestingly, it's about the same for humans: 3-4 entities produce 3-6 connections. Both are in the same neighbourhood. The limitation is biological though (http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...).
  - sirclueless 15y ago
    I think what Dennis means is that there is a philosophical reason why working memory is limited, and it's not just an idiosyncrasy of organic meat-brains. Of course the specific number is highly affected by human biology.
grncdr 15y ago
The question that comes to mind for me: how do we define "entities" in the context of writing software? Especially given gorelik's observation that complexity really derives from the combinatorial explosion of connections, are objects with internal state the best way to manage that complexity? If every call of a public method from another object is a connection in the graph our entities are an (object, message) pair, and a situation involving 3 objects with 3 public methods each exceeds our limitations. Contrast this with a pure-functional approach. If you can express your algorithm with immutable data and operations that create new transformations of that data, you could (hypothetically) have fewer things in mind at any one time: the data being operated on, and the single operation being performed. It doesn't break down quite so cleanly in reality, but use of pure functions where possible largely obviates the benefits of state encapsulation as provided by most modern OO languages.