[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.technology.ldt] Re: Beyond textual represenations...
|
I'm a big fan of this approach. I think Roedy Green's "SCID" Student Project
Writeup has a really good summary of benefits:
http://mindprod.com/projects/scid.html
That said, this is what VisualAge (Smalltalk, Java) did (but didn't have all
the bells & whistles), and caused quite an uproar because people couldn't
"see" their files.
The problem is paradigm shift. Most folks don't want to give up "files" just
because they're used to "files". Some argue that they can't use "grep" (to
them I say the IDE can do **way** better than grep b/c of context). And the
bigger issue -- their favorite source control tool...
But it's mostly a comfort thing that we may never get over.
Of course there's also the "proprietary" issue. Just last week I had someone
ping me asking what a VisualAge ".dat" file was. I dusted off an old VAJ CD
and imported/exported the source code for him.
So...
I'd love to have the power of SCID, but methinks there needs to be a "file"
representation as well.
A virtual file system would be nice here, but still runs the problem of
someone saving a copy of the database on a CD, coming back three years later
and not being able to use the code in a new tool. Of course the only way to
make this work is to make it really obvious to the user that they should
export the code.
Eclipse does a good bit of file processing and stores some data info, but
I'd love to have a SCID... (Esp b/c I like tab characters, I hate cuddled
"else"s, and other stylistic things...)
My 50c...
-- Scott
"Guillaume Pothier" <gpothier@xxxxxxxxx> wrote in message
news:d1fm9d$93j$1@xxxxxxxxxxxxxxxxxx
>I am really glad that the LDT project has been created.
> Many of the posts to this newsgroup discuss ASTs and parsers, assuming
> that a programming language's primary representation will always be its
> textual form.
>
> As far as I am concerned, I anticipate the day when the primary from of a
> programming language is its AST, or even better, Abstract Syntax Graph.
> Given the currently available computing power of the machines used by
> developpers today, I think it is no luxury to start thinking of replacing
> the traditional bunch of source files stored in a hierarchical filesystem
> by a graph of objects backed by some database system.
>
> There are a few obvious benefits to do so, even in the simple case of
> Java-only developments:
> - No more source code formatting hell and obnoxious merge conflicts caused
> by formatting differences between developpers.
> - Elimination of the parsing step from the compilation
>
> I think the first thing LDT should provide is a new storage metaphor based
> on ASTs (or ASGs). Of course, this representation issue does not solve all
> the problems LDT proposes to deal with, but it would be a great foundation
> for implementing new language support.
>
> Regards,
> Guillaume Pothier