From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: RE: [9fans] source code as data not text 
From: anothy@cosym.net
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20010618152511.B7DBA19A08@mail.cse.psu.edu>
Date: Mon, 18 Jun 2001 11:24:40 -0400
Topicbox-Message-UUID: bcdf9d62-eac9-11e9-9e20-41e7f4b1d025

//In my opinion, you're on the right track.

so how do you deal with the concerns raised? for one, the probability that a
database-based source code repository would lock you into a specific vendor?
and while i'm not entirely clear on what exactly lac was refering to, can you
deny the usefulness of being able to "grep ^foo(" in code, or suggest that a
databasse system would make that easier somehow? again, as noted earlier,
db-based source code systems are another failure to use the little-tools
model appropriatly.

and as dan points out, SCCS/CVS style stuff is not what's at issue here.

//In fact, you'd be surprised how many big software companies are already
//moving that way...

much to my dismay, i believe you. but then, i'm often suprised how many big
companies are doing _lots_ of things i consider stupid. PeopleSoft, anyone?

the most involved syntax highlighting i find useful is paren/bracket/quote/&c
matching. i could imagine an editor that did that well (acounting for the
language-specific escapes and such) being quite nice. more than that i've not
found useful, and it's distracting and damaging to people who're learning.
and what acme's got now is good 95 times out of 100.
-α.