At 07:03 PM 1/19/05 -0500, Timothy Fitz wrote: >On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne ><stephen.thorne at gmail.com> wrote: > > "Flat is better than nested" has one foot in concise powerful > > programming, the other foot in optimisation. > > > > foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable > lookup. > >I find it amazingly hard to believe that this is implying optimization >over functionality or clarity. There has to be another reason, yet I >can't think of any. Actually, this is one of those rare cases where optimization and clarity go hand in hand. Human brains just don't handle nesting that well. It's easy to visualize two levels of nested structure, but three is a stretch unless you can abstract at least one of the layers. For example, I can remember 'peak.binding.attributes' because the 'peak' is the same for all the packages in PEAK. I can also handle 'peak.binding.tests.test_foo' because 'tests' is also always the same. But that's pretty much the limit of my mental stack, which is why PEAK's namespaces are organized so that APIs are normally accessed as 'binding.doSomething' or 'naming.fooBar', instead of requiring people to type 'peak.binding.attributes.doSomething'. Clearly Java developers have this brain-stack issue as well, in that you usually see Java imports set up to have a flat namespace within the given module... er, class. You don't often see people creating org.apache.jakarta.foo.bar.Baz instances in their method bodies.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4