[plt-dev] `rico' and ".rkt"

Matthew Flatt wrote:
> * Some of us have discussed collapsing `setup-plt', `mzc', `planet',
>   `plt-help' and (in case I've overlooked any) other miscellaneous
>   programming tools into a single `rico' executable.

I see that as mixing apples and oranges.  Then there's a strong risk
of it ending up like cvs, where I could never remember which
'-something' options I could use or not use in combination with which
'update', 'log', etc. sub-command, and where the same obscure
'-something' option had a different meaning depending on which
'update', 'log', etc. sub-command I was in the middle of using (or was
it that the same option had a different meaning depending on whether
it appeared before the sub-command name or after?  I can't remember
now, nor do I want to...)

Robby Findler wrote:
>FWIW, part of this is motivated from the fact that we're coming from a
>situation where the dev tools are spread out among a bunch of
>executables and you'd never really guess where some of the
>functionality is (quick: where is zo-file decompilation?).

But it's only going to move the problem by one word to the right by
adding the word 'rico' in front (quick: which combination of rico
sub-command and option does zo-file decompilation?)

I think it would be more useful to keep separate commands and just
have them all start with the same prefix to make them easier to find.
This is is fact what svn does for all its svnadmin, svnsync, etc.,
commands.  I type 'svn' in my shell followed by two tabs and I get:

svn                              svnlook
svn-populate-node-origins-index  svnmucc
svnadmin                         svnserve
svnauthz-validate                svnsync
svndumpfilter                    svnversion

Well chosen names with a common prefix go a long way (I wouldn't call
some of the svn-related programs listed just above "well named" but
you get the idea).

Neil Van Dyke wrote:
> I think that ".racket-source" would be an annoyingly long filename  
> extension for many people who would use Racket.

I'll second that.  Using tab-completion only works if the file already
exists.  Long extension names are also a pain when listing files in a
shell because it reduces the number of columns and makes the listing
needlessly long.  So, as far as I'm concerned, the shorter the better.

And while we're at it, I'd vote for a short extension name that's also
easy to type on a keyboard (because something like 'scrbl' isn't
exactly easy on the fingers...) :-)

Philippe