6 ms·

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on t

by chton 12y ago

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. What OO provides is essentially a skeuomorphic element to your code, where your basic units have some resemblance to real items and concepts. This makes it a lot easier to reason about large codebases, and makes them easier to document (in theory). It means the most important thing you need to understand how a piece of business logic works is knowledge of the business. You don't need to know anything about the data, or how the application is composed in order to comply with the needed use case. If you know the concepts and their behaviour in the problem domain, you will be able to make sense of how the code is written. FP has its place, as does procedural code, but advocating either of them as a complete replacement for OO is short-sighted. Claiming FP is a solution to OO's shortcomings is too. Each has its place. If anything, we should be working towards next-generation models, that combine the advantages of both and mitigate the downsides of both.

dragonwriter 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. Honestly, while I think OO programming in the broadest sense does that, I think class-oriented OOP (what the article mostly focusses on) languages, particularly statically-typed class-oriented languages in the C++/Java lineage--don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs. They aren't useless in that respect--there is a reason why they flourished--but there's also a reason that after them an important programming paradigm for several decades, and a dominant one since at least the late 1980s, there's a whole lot of moves away from traditional class-oriented OOP in newer languages. I think that we're seeing a model--which is mostly viewed as being within the FP tradition but which has learned a lot from OOP languages and supports a lot of OO thinking--emerge (and that this article points to a lot of its elements) that provides a framework that better matches the intuition than class-oriented OOP does, while also better supporting building correct, maintainable, easy-to-reason-about systems.
- rockshassa 12y ago
  >don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs My first thought is that this is dependent on implementation. It is possible to write classes in a way that aligns with intuition, but it is sometimes hard to do that, and even if you're great at OOP it is hard to do consistently. I think the Smalltalk message-sending way of thinking has huge value because it is easy to reason with, and facilitates this intuition. That said, I do see tremendous value in FP, and I'm encouraged by the elements of FP that I've seen popping up in Swift. So I guess ultimately I do agree with you. I'd like to see OOP continue to flourish, but borrow elements from the Functional style that make it very difficult to write fragile code.
  - chton 12y ago
    I'm exactly in your camp. I would love to see more functional influence in OO, and more careful thought about what to use at what time.
Terr_ 12y ago
> skeuomorphic No, skeuomorphism involves ornamental details, which are at best hints about how something is to be used. How you break-down the responsibilities of your system and name them is much much more important than that.
- chton 12y ago
  I agree it's not the best word for it, but what I meant is that the elements are made to look and behave similar to their real-life or conceptual analogues. Think of it mostly as the software UI skeuomorphism: we are able to recognize the functions of the software faster because it is designed to look like something we know.
Dewie 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).
- seanmcdirmid 12y ago
  The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Our minds have 50,000+ years of language expertise, and only a couple thousand for formal non linguistic equational reasoning (where things only have structure and are unnameable).
  - swift 12y ago
    I'm not so sure. There's some truth to what you're saying, but by "is a", statically typed OO languages generally mean something much different than what we mean by that in human languages. I find OO's obsession with hierarchy and taxonomy to be profoundly unintuitive.
    - seanmcdirmid 12y ago
      There is much more to OOP than Java.
      - swift 12y ago
        Something like Smalltalk or Ruby is certainly closer to my preferences. The focus on taxonomy is definitely most obvious and most painful in languages with static typing and fewer dynamic features. Can you suggest an OO language that really avoids the issue, though? It seems inherent in the notion of inheritance to me, even interface-only inheritance. Something like Haskell's typeclasses or Rust's traits seems to me like an easier way to model concepts from the real world.
klodolph 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. I would consider this a disadvantage, not an advantage. Human thoughts are imprecise and carry rich but ambiguous connotations. The major advances of mathematics in the 19th century (or thereabouts) onward are closely tied to the divorce of notation and natural language. The ancient version of the Pythagorean theorem is something like, "The area of a square whose side is the length of a hypoteneuse of a right triangle is equal to the sum of the areas of squares whose sides are equal in length to the other two sides." A modern version is more like, "Let a, b, c be the lengths of sides of a right triangle, where c is the length of the hypoteneuse. Then a^2 + b^2 = c^2." You can see as time goes on, the text becomes simultaneously clearer, more concise, and more abstract. This is why natural language programming is doomed to failure. Others have expressed the point better than I do (notably Dijkstra). But you can look at the examples of how inheritance in class-based OOP systems work and you will get sick just looking at them: examples of Dog inheriting from Animal, and Penguin from Bird (but penguins don't fly), et cetera. The real disadvantage here is that once people start thinking about taxonomy in general (which class-based OOP encourages), you're not thinking about programming any more. The difficulty people have with even simple problems like "how do you describe squares and rectangles in a computer program" is another good illustration of how the class-based object-oriented system of thinking is unsuited for solving computational tasks, at least compared to the alternatives.
thunderbong 12y ago
'skeumorphic' - did you mean 'anthropomorphic'?
- chton 12y ago
  I didn't. I meant 'skeuomorphic' as in 'designed with cues that correspond to reality, to indicate corresponding functions and behaviour'. It's a bit more nebulous when applied to real code, since we're thinking in terms of concept and behaviour, but the same thought applies.
arethuza 12y ago
"The big advantage of OO is that it acts as a distillation of how humans think." I first encountered functional programming in the 1980s on my Computer Science degree course a few years before I encountered OOP (CLOS and then C++) and I'm not convinced that OOP is fundamentally closer to "how humans think" than FP. Most programmers these days were taught an OOP language first so think that is most natural - but I don't think there is anything fundamental about that.
- chton 12y ago
  You should try explaining some business logic to a non-technical person some time. If you are able to properly model the problem domain, non-technical people have a much easier time understanding the flow of the code and how it works if it's written in an OO way. This is precisely because they recognize the concepts and ideas they are familiar with and can already reason about. They know that 'a Person pays their Bills by asking a Bank to deposit Money'. This means they can make sense of code that is structured in the same way. FP, for all its advantages and elegance, doesn't offer that same correspondence.
yason 12y ago
The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. What OO provides is essentially a skeuomorphic element to your code, where your basic units have some resemblance to real items and concepts. This makes it a lot easier to reason about large codebases, and makes them easier to document (in theory). It seems to me that you're sort of confusing OOP with programming interfaces. An interface describes a model of how to use a certain piece of code, and indeed a good one can be almost "obvious" and it begins to feel like a "natural" way to reason with it. But it's all about the interface: not about from what kind of language constructs the interface is composed of. Interfaces can be done in object oriented programming too but for some reason, possibly exactly because of the resemblance to real items and concepts and how human people are so fond of those, most interfaces in OOP languages are utter horror. This could be because it's so easy and almost fundamental to create "things that do stuff", i.e. classes in OOP, there will be a lot of them. The design pattern craze kind of formalized that for good, which is why we've all enjoyed our share of abstract factory builder singleton visitor, or whatever. In contrast, you tend to see really good interfaces surprisingly often in... C. As a disclaimer, this is a big reason why I like C language -- it forces you to think simple because it offers so many guns to shoot yourself in the foot and a lot of other places too that you need to focus on what's essential to your program. With an easier but inevitably more complex language, the lull times in the day of programming seem to produce lots of implementation and interfacing complexity that a C programmer would never dare to attempt. C programmers also use paradigms associated with OO but only where appropriate because it's a bit of hurdle to implement those in C. I've also observed that there's a vague parallel between complex (object oriented) interfaces vs. simple (C) interfaces and the Alan Perlis' notion of to better have 100 functions operating on one data structure rather than 10 functions operating on 10 data structures. Good OO interfaces tend to be really simple and short, even so that they're not even particularly OO anymore. The OO, procedural, FP paradigms are mostly orthogonal and can be combined freely in sensible amounts where needed, but they're also orthogonal to concepts such as encapsulation, polymorphism, type hierarchies, and inheritance which themselves aren't tied together either.
- chton 12y ago
  My intention was focused entirely on object oriented modelling and programming. Interface design is a tool to do that, but in and of itself does not provide the correspondence with the way humans think. The core of OO is to have independent objects that combine behaviour and data. Whatever your type system, whatever your language constructs, that core is what provides the advantage. I was considering mostly the basic ideas of OO modelling in general rather than whatever way you choose to achieve that.
chriswarbo 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. Citation needed. Browsing around Google Scholar for variations of "object oriented empirical comparison" shows a huge body of research comparing various OO approaches to each other, but very few comparing OO approaches to anything else. Those which I have been able to find compare OO to procedural code, and find either no significant difference in comprehension levels, or that procedural code is easier to understand (ie. closer to "how humans think") than OO: An empirical study of novice program comprehension in the imperative and object-oriented styles http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-ramalingam.pdf http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-... Assessing the cognitive consequences of the object-oriented approach: A survey of empirical research on object-oriented design by individuals and teams http://arxiv.org/pdf/cs.HC/0611154 http://arxiv.org/pdf/cs.HC/0611154 An exploratory study of program comprehension strategies of procedural and object-oriented programmers http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%20Corritore01-ExploratoryStudyComprehension.pdf http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%2... I've only been able to find one source comparing OO with functional programming, which didn't measure comprehension. Instead, it compared code quality metrics between C++ and Standard ML. Most showed no significant difference, except for SML taking longer to run its tests (it also had more tests), having higher code and library re-use and having a larger number of errors per 1000 lines (although the same number of known errors overall): Comparing programming paradigms: an evaluation of functional and object-oriented programs http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf
- chton 12y ago
  The most commonly cited proponents of this viewpoint are Rosson and Alpert (http://dl.acm.org/citation.cfm?id=1455754 http://dl.acm.org/citation.cfm?id=1455754, behind a paywall). The first study you linked refers to them and a few other explicitly, and uses their research as a basis. It's difficult to find much more than those, because this kind of 'programming philosophy' is rarely under this level of academic scrutiny. Aside from official sources, it's a statement that I didn't think needed much citation. It's absolutely fair to criticize it, but it's a widely-held belief that seems to hold true (at least anecdotally)
pdkl95 12y ago
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... Steve Yegge's "Execution in the Kingdom of Nouns" has some interesting commentary on the idea of OO being in any way how humans think. The allegory has some harsh things to say about Java, which are not my intention in suggesting this link. The observations that objects tend to be nouns while functions tend to be verbs is very interesting. /* footnote 3 is hilarious */
naasking 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. Let's not confuse "how humans think" with "how humans ought to think to self problems effectively". There is little evidence that OO is any better than other principled approaches to programming.
kazagistar 12y ago
> The big advantage of OO is that it acts as a distillation of how humans think. Objects are always a struggle. I see students new to programming take as long as their junior year before they even start to "really get it" and design reasonable classes. Rolling identity, state, values, types, functions, polymorphism, modules, resource management, and who knows what else into a single thing is inherently going to result in something pretty damn complicated, compared to trying to keep those concerns orthogonal and thus only pulling in those that are needed for the task at hand. I would certainly say that OOP-based software engineering has vast advantages in certain cases, but my hypothesis would be that its "ease" advantages is more one of mindshare rather then something inherent in the human mind. This hypothesis, however, is worth extensively testing... for a discipline that relies on stretching human cognitive performance to its limits, we spend far too little time actually figuring out exactly what limits those are.

by chton 12y ago

dragonwriter 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. Honestly, while I think OO programming in the broadest sense does that, I think class-oriented OOP (what the article mostly focusses on) languages, particularly statically-typed class-oriented languages in the C++/Java lineage--don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs. They aren't useless in that respect--there is a reason why they flourished--but there's also a reason that after them an important programming paradigm for several decades, and a dominant one since at least the late 1980s, there's a whole lot of moves away from traditional class-oriented OOP in newer languages. I think that we're seeing a model--which is mostly viewed as being within the FP tradition but which has learned a lot from OOP languages and supports a lot of OO thinking--emerge (and that this article points to a lot of its elements) that provides a framework that better matches the intuition than class-oriented OOP does, while also better supporting building correct, maintainable, easy-to-reason-about systems.

rockshassa 12y ago
>don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs My first thought is that this is dependent on implementation. It is possible to write classes in a way that aligns with intuition, but it is sometimes hard to do that, and even if you're great at OOP it is hard to do consistently. I think the Smalltalk message-sending way of thinking has huge value because it is easy to reason with, and facilitates this intuition. That said, I do see tremendous value in FP, and I'm encouraged by the elements of FP that I've seen popping up in Swift. So I guess ultimately I do agree with you. I'd like to see OOP continue to flourish, but borrow elements from the Functional style that make it very difficult to write fragile code.
- chton 12y ago
  I'm exactly in your camp. I would love to see more functional influence in OO, and more careful thought about what to use at what time.

Terr_ 12y ago

> skeuomorphic No, skeuomorphism involves ornamental details, which are at best hints about how something is to be used. How you break-down the responsibilities of your system and name them is much much more important than that.

chton 12y ago
I agree it's not the best word for it, but what I meant is that the elements are made to look and behave similar to their real-life or conceptual analogues. Think of it mostly as the software UI skeuomorphism: we are able to recognize the functions of the software faster because it is designed to look like something we know.

Dewie 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).

seanmcdirmid 12y ago
The way OOP is taught often doesn't bring up object thinking. But if you believe it is not natural, try thinking mathematically (without nouns or names as unique aliasable identifiers). Or without isa or hasa relationships. Our minds have 50,000+ years of language expertise, and only a couple thousand for formal non linguistic equational reasoning (where things only have structure and are unnameable).
- swift 12y ago
  I'm not so sure. There's some truth to what you're saying, but by "is a", statically typed OO languages generally mean something much different than what we mean by that in human languages. I find OO's obsession with hierarchy and taxonomy to be profoundly unintuitive.
  - seanmcdirmid 12y ago
    There is much more to OOP than Java.
    - swift 12y ago
      Something like Smalltalk or Ruby is certainly closer to my preferences. The focus on taxonomy is definitely most obvious and most painful in languages with static typing and fewer dynamic features. Can you suggest an OO language that really avoids the issue, though? It seems inherent in the notion of inheritance to me, even interface-only inheritance. Something like Haskell's typeclasses or Rust's traits seems to me like an easier way to model concepts from the real world.

klodolph 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. I would consider this a disadvantage, not an advantage. Human thoughts are imprecise and carry rich but ambiguous connotations. The major advances of mathematics in the 19th century (or thereabouts) onward are closely tied to the divorce of notation and natural language. The ancient version of the Pythagorean theorem is something like, "The area of a square whose side is the length of a hypoteneuse of a right triangle is equal to the sum of the areas of squares whose sides are equal in length to the other two sides." A modern version is more like, "Let a, b, c be the lengths of sides of a right triangle, where c is the length of the hypoteneuse. Then a^2 + b^2 = c^2." You can see as time goes on, the text becomes simultaneously clearer, more concise, and more abstract. This is why natural language programming is doomed to failure. Others have expressed the point better than I do (notably Dijkstra). But you can look at the examples of how inheritance in class-based OOP systems work and you will get sick just looking at them: examples of Dog inheriting from Animal, and Penguin from Bird (but penguins don't fly), et cetera. The real disadvantage here is that once people start thinking about taxonomy in general (which class-based OOP encourages), you're not thinking about programming any more. The difficulty people have with even simple problems like "how do you describe squares and rectangles in a computer program" is another good illustration of how the class-based object-oriented system of thinking is unsuited for solving computational tasks, at least compared to the alternatives.

thunderbong 12y ago

'skeumorphic' - did you mean 'anthropomorphic'?

chton 12y ago
I didn't. I meant 'skeuomorphic' as in 'designed with cues that correspond to reality, to indicate corresponding functions and behaviour'. It's a bit more nebulous when applied to real code, since we're thinking in terms of concept and behaviour, but the same thought applies.

arethuza 12y ago

"The big advantage of OO is that it acts as a distillation of how humans think." I first encountered functional programming in the 1980s on my Computer Science degree course a few years before I encountered OOP (CLOS and then C++) and I'm not convinced that OOP is fundamentally closer to "how humans think" than FP. Most programmers these days were taught an OOP language first so think that is most natural - but I don't think there is anything fundamental about that.

chton 12y ago
You should try explaining some business logic to a non-technical person some time. If you are able to properly model the problem domain, non-technical people have a much easier time understanding the flow of the code and how it works if it's written in an OO way. This is precisely because they recognize the concepts and ideas they are familiar with and can already reason about. They know that 'a Person pays their Bills by asking a Bank to deposit Money'. This means they can make sense of code that is structured in the same way. FP, for all its advantages and elegance, doesn't offer that same correspondence.

yason 12y ago

The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. What OO provides is essentially a skeuomorphic element to your code, where your basic units have some resemblance to real items and concepts. This makes it a lot easier to reason about large codebases, and makes them easier to document (in theory). It seems to me that you're sort of confusing OOP with programming interfaces. An interface describes a model of how to use a certain piece of code, and indeed a good one can be almost "obvious" and it begins to feel like a "natural" way to reason with it. But it's all about the interface: not about from what kind of language constructs the interface is composed of. Interfaces can be done in object oriented programming too but for some reason, possibly exactly because of the resemblance to real items and concepts and how human people are so fond of those, most interfaces in OOP languages are utter horror. This could be because it's so easy and almost fundamental to create "things that do stuff", i.e. classes in OOP, there will be a lot of them. The design pattern craze kind of formalized that for good, which is why we've all enjoyed our share of abstract factory builder singleton visitor, or whatever. In contrast, you tend to see really good interfaces surprisingly often in... C. As a disclaimer, this is a big reason why I like C language -- it forces you to think simple because it offers so many guns to shoot yourself in the foot and a lot of other places too that you need to focus on what's essential to your program. With an easier but inevitably more complex language, the lull times in the day of programming seem to produce lots of implementation and interfacing complexity that a C programmer would never dare to attempt. C programmers also use paradigms associated with OO but only where appropriate because it's a bit of hurdle to implement those in C. I've also observed that there's a vague parallel between complex (object oriented) interfaces vs. simple (C) interfaces and the Alan Perlis' notion of to better have 100 functions operating on one data structure rather than 10 functions operating on 10 data structures. Good OO interfaces tend to be really simple and short, even so that they're not even particularly OO anymore. The OO, procedural, FP paradigms are mostly orthogonal and can be combined freely in sensible amounts where needed, but they're also orthogonal to concepts such as encapsulation, polymorphism, type hierarchies, and inheritance which themselves aren't tied together either.

chton 12y ago
My intention was focused entirely on object oriented modelling and programming. Interface design is a tool to do that, but in and of itself does not provide the correspondence with the way humans think. The core of OO is to have independent objects that combine behaviour and data. Whatever your type system, whatever your language constructs, that core is what provides the advantage. I was considering mostly the basic ideas of OO modelling in general rather than whatever way you choose to achieve that.

chriswarbo 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. Citation needed. Browsing around Google Scholar for variations of "object oriented empirical comparison" shows a huge body of research comparing various OO approaches to each other, but very few comparing OO approaches to anything else. Those which I have been able to find compare OO to procedural code, and find either no significant difference in comprehension levels, or that procedural code is easier to understand (ie. closer to "how humans think") than OO: An empirical study of novice program comprehension in the imperative and object-oriented styles http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-ramalingam.pdf http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-... Assessing the cognitive consequences of the object-oriented approach: A survey of empirical research on object-oriented design by individuals and teams http://arxiv.org/pdf/cs.HC/0611154 http://arxiv.org/pdf/cs.HC/0611154 An exploratory study of program comprehension strategies of procedural and object-oriented programmers http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%20Corritore01-ExploratoryStudyComprehension.pdf http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%2... I've only been able to find one source comparing OO with functional programming, which didn't measure comprehension. Instead, it compared code quality metrics between C++ and Standard ML. Most showed no significant difference, except for SML taking longer to run its tests (it also had more tests), having higher code and library re-use and having a larger number of errors per 1000 lines (although the same number of known errors overall): Comparing programming paradigms: an evaluation of functional and object-oriented programs http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf

chton 12y ago
The most commonly cited proponents of this viewpoint are Rosson and Alpert (http://dl.acm.org/citation.cfm?id=1455754 http://dl.acm.org/citation.cfm?id=1455754, behind a paywall). The first study you linked refers to them and a few other explicitly, and uses their research as a basis. It's difficult to find much more than those, because this kind of 'programming philosophy' is rarely under this level of academic scrutiny. Aside from official sources, it's a statement that I didn't think needed much citation. It's absolutely fair to criticize it, but it's a widely-held belief that seems to hold true (at least anecdotally)

pdkl95 12y ago

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... Steve Yegge's "Execution in the Kingdom of Nouns" has some interesting commentary on the idea of OO being in any way how humans think. The allegory has some harsh things to say about Java, which are not my intention in suggesting this link. The observations that objects tend to be nouns while functions tend to be verbs is very interesting. /* footnote 3 is hilarious */

naasking 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. Let's not confuse "how humans think" with "how humans ought to think to self problems effectively". There is little evidence that OO is any better than other principled approaches to programming.

kazagistar 12y ago

> The big advantage of OO is that it acts as a distillation of how humans think. Objects are always a struggle. I see students new to programming take as long as their junior year before they even start to "really get it" and design reasonable classes. Rolling identity, state, values, types, functions, polymorphism, modules, resource management, and who knows what else into a single thing is inherently going to result in something pretty damn complicated, compared to trying to keep those concerns orthogonal and thus only pulling in those that are needed for the task at hand. I would certainly say that OOP-based software engineering has vast advantages in certain cases, but my hypothesis would be that its "ease" advantages is more one of mindshare rather then something inherent in the human mind. This hypothesis, however, is worth extensively testing... for a discipline that relies on stretching human cognitive performance to its limits, we spend far too little time actually figuring out exactly what limits those are.