4 ms·
I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designin
by DannoHung 15y ago
I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designing something that is intentionally complicated or hard to understand. In a certain sense, the problem that a tool maps to must reflect the inherent nature of what it works upon, but the designer of the tool should always intend to make the tool a map more fit for human use.
Many of the things Gerrand cites were not created full form with the problems and uses clearly understood. This led to iteration and backwards compatibility, which introduced complications because now there were many ways to do things and not all suited for each other. I don't think his argument is that everything should be simple, but that the design should not feel iterative and piled upon. Instead it should reflect a consistency of vision for a problem and its solution.
If I may offer an example: In Haskell, the Prelude defines many types and functions which are imported into all modules (sort of similar to namespaces). Many of these functions have commonly understood names but only apply to certain data types. Within the extended set of libraries available in Haskell, there are many other implementations of these functions in terms of more general data types. The types represented are not simple, really, though they are limited and isolated in purpose.
Ideally, if one could go back and rewrite history, these more general functions and data types would be the ones exposed by the Prelude. Instead, the Prelude provides an earlier and less consistent view of common functions and datatypes, while the more consistent view is somewhat obscured inside of a number of neatly organized libraries.
Both the Prelude and the hierarchy of libraries seek to solve the solution of common tools for working with data and functions, but one has a more clear cut and comprehensible perspective while the other has an older, less consistent view.
- krig 15y agoI agree with you to a point, but I think this is also an issue that is more complicated than it may seem at first glance. A lot of the time, the older, more complex version had some initial design that solved a particular problem but didn't fully consider some alternative use cases. A redesign might capture these other use cases, but inevitably the evolution of a library also contains a lot of tweaks and fixes for smaller but not insignificant cases that are easily lost in the redesign. Often the new technology appears cleaner at first but then grows more complex as it starts getting used and those corner cases and missing bits accumulate, or it may actually have lost some functionality that seemed arcane to the redesigners but was actually a desired feature by some set of users. A problem is rarely as simple as it may appear before it is actually deployed and used.