[racket-dev] [plt] Push #24958: master branch updated

An hour and a half ago, Matthias Felleisen wrote:
> 
> Eli, could you share w/ us why 
> 
>  tool/optimization-coach .. with everything in it for this software
>  tool/future-visualizer ..  with everything in it for this software
> 
> is a bad idea? Perhaps I am old but I do see a lot of value in a
> deep hierarchical organization. [...]

* One reason is from a simple code organization point of view.  I
  referred to the unix filesystem convention as an example of this:
  - On Windows, every application is in its own directory (there used
    to be files in the Windows directory, but they strongly push away
    from that)
  - On Linux, the Foo application will usually have /usr/bin/foo,
    /usr/lib/libfoo, /usr/share/doc/foo, /usr/share/lib/foo,
    /usr/share/icons/foo.png, /usr/share/info/foo.info,
    /usr/share/man/man1/foo.1 etc etc etc.
  - And the new kid on the block inherits a lot of unix-isms, but goes
    even further than windows in having the executable itself be a
    Foo.app that contains everything it needs...

  Now, in our tree we have a little of both -- for example, there are
  collects/foo/tests directories in some cases, and collects/tests/foo
  in other cases, and scribblings are similarly organized in two ways
  too.

  I think that the single directory is ultimately easier to deal
  with, even when there is a package system that can keep track of
  files in different places.  There are *many* advantages that you can
  get out of it.  To name a few:
  - It's easy to switch things around so that collects/foo is actually
    in its own repository, managed separately from the whole tree (and
    I think that getting to that point is absolutely inevitable)
  - It's easy to package it up and ship it somewhere -- just zip it,
    and send it with instructions for where to unzip it.
  - Things like ownership become very easy: you know that if it's in
    xrepl/* then you complain to me, and it's easy for me to see when
    someone else commits to xrepl so I can look at it.

* Having said that, note that it isn't completely disjoint from using
  the directory structure in a way that follow its use -- the only
  thing is that the main "package name" comes first, and then a
  subdirectory like "tool" or "tests".

  *But* -- there is also danger in abusing the directory tree too much
  as a replacement for keywords/tags.  Say that there's some
  "foo/tool/inspector" and later "foo/tool/profiler", what happens
  when there's a type inspector -- which keyword "comes first" in the
  hierarchy?  (Incidentally, the first point makes this question easy
  for *me*: it's whatever foo's author wants to do...)

* Finally, there are a few minor exceptions.  "typed" can have
  subdirectories that are owned by other people, "file"/"net"/"data"
  etc are designed to be hosts for very common "keyword-like" uses.


> Perhaps Google will eventually accommodate all these people who
> don't like hierarchical organizations with search tools that find
> everything, including their misplaced car keys, reading glasses, and
> wallets. But we don't have such a tool for finding things in our
> collects/ tree and until we have such a search perhaps we should
> exploit the file system that we do have.

Actually we probably do...  I've set up a google code mirror, and they
most likely have tools to search it.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!