On 26 Mar 2010, at 21:32, erik quanstrom wrote:
Oh, yeah, lets all learn about namespaces and the counterintuitive
things they do and don't do, and compiling and everything to do when
it goes wrong, and a billion other things JUST to save devs having to
work out a good solution!
mmm. i don't know of any counterintuative things
that namespaces do. do you have an example?
further, you're going to have to know how namespaces
work to use plan 9 interactively or as a developer.
I wish I could put my finger on a specific example. Coming from Linux
I really struggled to understand how name spaces and file servers
worked together for some time. One day it just clicked, and I think it
was well worth learning, but compiling stuff isn't in the same class,
it's a means to an end and more of a chore. I take the perspective
that computers should reduce chores as much as they possibly can. ;)
i think the valid — and deep — question here is how
complicated a namespace one wishes to construct.
i see practical limits to how many entries a human can
understand. the machine of course, doesn't care.
Indeed, and a limit which varies from person to person, hence why I'm
fighting namespace growth. ;) You could say I'm trading one complexity
for another: arguing for growing system directories instead. I find a
good package manager helps a great deal with the filesystem. When you
can query to find which package a file comes from, then query on the
package name to find the docs, config files, executables, anything you
want by filename and then some, that's quite a help with organising.
You know... /opt style might not be so bad after all. It may make the
namespace a long list, but it would be a list which could very easily
be grepped for package name and I'm sure quite a simple script could
find which package a file in the 'bound tree' is really in.
--
Simplicity does not precede complexity, but follows it.
-- Alan Perlis
