RE: Crazy Ideas Was: Re: Java hiccups

RE: Crazy Ideas Was: Re: Java hiccups

[Kirby, Dave]

Not such a crazy idea.  Take a look at IBM's VisualAge for Java, which does
exactly that (i.e. keep the code in a repository instead of text files).  It
is based on VisualAge for Smalltalk, and of course Smalltalk has done things
this way from the beginning. 

I haven't used VA myself, since I am developing in C++, but I know lots of
Java developers swear by it, especially in the XP community.  You can even
get a refactoring browser for it.

For a discussion on its merits & some links, see
http://www.c2.com/cgi/wiki?VisualAge

Regards,

	Dave Kirby



> -----Original Message-----
> From: Timothy M. Shead [ mailto:tshead@k-3d.com ]
> Sent: 16 January 2001 03:16
> Cc: sourcenav@sourceware.cygnus.com
> Subject: Crazy Ideas Was: Re: Java hiccups
> 
> 
> Ben Elliston wrote:
> 
> > mdejong wrote:
> > 
> >    We are talking about the "right" way to fix it but it is going to
> >    require some work. The GCJ based parser would work for 
> Java code that
> >    would compile, but fuzzy Java parsing is a much harder problem.
> > 
> > Having had a couple of years to ponder this issue, I'm coming to the
> > conlusion that perhaps the correct parsing of correct 
> programs should come
> > before the best-effort parsing of incorrect programs.  
> Perhaps fuzzy parsing
> > should take a back seat?
> > 
> > Ben
> 
> I don't know if y'all have any long-term plans for the future 
> of SN, but 
> if you do, your remark about correctly parsing correct 
> programs reminded 
> me of one of an interesting idea I ran across, one which 
> could eliminate 
> these types of problems: database source management.  The idea being 
> that, instead of "storing" your program source in files, you keep it 
> organized in a central database.  So you'd have tables for classes, 
> methods, functions, etc. just like SN's tables, but with the 
> bodies of 
> functions/methods/etc in the database as well.  There'd never be a 
> "foo.java" or "foo.cpp" - simply a set of "foo" entries in 
> the database. 
>   When it's time to compile, the database dumps the source into 
> temporary file form to feed the compiler.  Advantages would include:
> 
> * Minimize parsing (at least for new projects) - since the 
> code is going 
> into the database as it's written (presumeably through some 
> type of GUI) 
> the parsing can be kept to a bare minimum (with much, much less to go 
> wrong).
> * More complex searches / cross references.
> * Faster compile times - since the database can easily 
> cross-reference 
> function/method calls, it can avoid compiling the ones that 
> are never used.
> * Faster compiled executables - the database could perform static 
> analysis of call patterns, and organize compiled code to 
> minimize cache 
> hits, something that's impractical when working with files.
> * Better source management - tools like CVS track changes to 
> text files 
> at a generic level.  The database could track changes at a 
> per-function/method level, and provide context for a "group" 
> of changes 
> that go together (something CVS doesn't do).  It could advise 
> you when a 
> change is going to affect other people, and advise them when you do.
> * Integrated documentation - it would be possible for the database to 
> help keep documentation in sync with the code - if you change an 
> argument to a function/method, it can (optionally, of 
> course!) nag you 
> to update the corresponding comments.
> 
> Way out there, I know - the idea of abandoning files is 
> scary, but worth 
> looking at :)
> 
> Regards,
> Timothy M. Shead
> 
> 

Re: Crazy Ideas Was: Re: Java hiccups

[Eray Ozkural (exa)]

dave.banham@tde.alstom.com wrote:
> 
> People on this list have equally suggested that SN should be able to produce
> (reverse-engineer) UML diagrams of the source code. A lot of CASE tools already
> do this.

UML... Three magic letters. It makes you deal with code without understanding
it right?

Sorry, just couldn't resist the temptation. :)

If you have a good visualization of code, you probably don't need any
braindead PDL dumps. Except for showing them to the management. Anyway, I
showed non-UML "pretty pictures" of code to our very senior software
engineer and he was equally pleased.

> And the next logical step would be to allow the user to input the
> diagrams and for the code to be generated.

Does this require less cognitive load than writing code?

:)))))


Regards,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Crazy Ideas Was: Re: Java hiccups

[dave.banham]

The fundamental flaw with Tim's suggestion is that it forgets to incorporate the
design process - there is no mechanism for placing the code in the database in
an organised manner. Modern software engineering tools (i.e. CASE tools) already
do this. At one end of the scale there are CASE tools that act as a sort of IDE
by allowing function bodies, etc., to be populated from within the design model,
e.g. Rational Rose from Rational (www.rational.com). At the other end of the
scale the CASE tool generates all the source code from a very detailed model,
e.g. Bridgepoint from Project Technology (www.projtech.com).

People on this list have equally suggested that SN should be able to produce
(reverse-engineer) UML diagrams of the source code. A lot of CASE tools already
do this. And the next logical step would be to allow the user to input the
diagrams and for the code to be generated.

It is probably true to say that if we were all using the latest CASE tools we
wouldn't be using SN since there wouldn't be a need for it. However, *good* CASE
tools tend to cost a lot of money and a fair amount of skill to use effectively.
So I guess that most of us on this list are here because SN is free open source,
is relatively easy to use and, most importantly, doesn't require management
approval to use it.

SN is also a good tool for understanding a diverse code base and this is
probably where it should remain. So rather than expand SN vertically, process
wise, it would be better to expand it breadth wise by providing wide ranging
language support of a high quality.

Regards
Dave Banham




To:
cc:   sourcenav@sourceware.cygnus.com
Subject:  Crazy Ideas Was: Re: Java hiccups



Ben Elliston wrote:

> mdejong wrote:
>
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
>
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
>
> Ben

I don't know if y'all have any long-term plans for the future of SN, but
if you do, your remark about correctly parsing correct programs reminded
me of one of an interesting idea I ran across, one which could eliminate
these types of problems: database source management.  The idea being
that, instead of "storing" your program source in files, you keep it
organized in a central database.  So you'd have tables for classes,
methods, functions, etc. just like SN's tables, but with the bodies of
functions/methods/etc in the database as well.  There'd never be a
"foo.java" or "foo.cpp" - simply a set of "foo" entries in the database.
  When it's time to compile, the database dumps the source into
temporary file form to feed the compiler.  Advantages would include:

* Minimize parsing (at least for new projects) - since the code is going
into the database as it's written (presumeably through some type of GUI)
the parsing can be kept to a bare minimum (with much, much less to go
wrong).
* More complex searches / cross references.
* Faster compile times - since the database can easily cross-reference
function/method calls, it can avoid compiling the ones that are never used.
* Faster compiled executables - the database could perform static
analysis of call patterns, and organize compiled code to minimize cache
hits, something that's impractical when working with files.
* Better source management - tools like CVS track changes to text files
at a generic level.  The database could track changes at a
per-function/method level, and provide context for a "group" of changes
that go together (something CVS doesn't do).  It could advise you when a
change is going to affect other people, and advise them when you do.
* Integrated documentation - it would be possible for the database to
help keep documentation in sync with the code - if you change an
argument to a function/method, it can (optionally, of course!) nag you
to update the corresponding comments.

Way out there, I know - the idea of abandoning files is scary, but worth
looking at :)

Regards,
Timothy M. Shead

Re: Crazy Ideas Was: Re: Java hiccups

[Ian Roxborough]

Mmmmmmmm, yes, something I've heard about a few times.
The biggest benefit would be  NO MORE CODING STANDARDS!
Yippee, no more whining about this coding standard verse
that one.  You just set any coding standard you want in
your editor and nobody will ever care.

And many great advantages for doing code refactoring as well.

A more realistic way would be to store source code in
XML format, which then could be read into either a xref and symbol
database or into a compiler (or into an editor of course).
But when you try to deal with file based languages, Java is bad
for this (path = package name), as is C due to the use of static, you
start to have some problems.

Ian.

"Timothy M. Shead" wrote:
> 
> Ben Elliston wrote:
> 
> > mdejong wrote:
> >
> >    We are talking about the "right" way to fix it but it is going to
> >    require some work. The GCJ based parser would work for Java code that
> >    would compile, but fuzzy Java parsing is a much harder problem.
> >
> > Having had a couple of years to ponder this issue, I'm coming to the
> > conlusion that perhaps the correct parsing of correct programs should come
> > before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> > should take a back seat?
> >
> > Ben
> 
> I don't know if y'all have any long-term plans for the future of SN, but
> if you do, your remark about correctly parsing correct programs reminded
> me of one of an interesting idea I ran across, one which could eliminate
> these types of problems: database source management.  The idea being
> that, instead of "storing" your program source in files, you keep it
> organized in a central database.  So you'd have tables for classes,
> methods, functions, etc. just like SN's tables, but with the bodies of
> functions/methods/etc in the database as well.  There'd never be a
> "foo.java" or "foo.cpp" - simply a set of "foo" entries in the database.
>   When it's time to compile, the database dumps the source into
> temporary file form to feed the compiler.  Advantages would include:
> 
> * Minimize parsing (at least for new projects) - since the code is going
> into the database as it's written (presumeably through some type of GUI)
> the parsing can be kept to a bare minimum (with much, much less to go
> wrong).
> * More complex searches / cross references.
> * Faster compile times - since the database can easily cross-reference
> function/method calls, it can avoid compiling the ones that are never used.
> * Faster compiled executables - the database could perform static
> analysis of call patterns, and organize compiled code to minimize cache
> hits, something that's impractical when working with files.
> * Better source management - tools like CVS track changes to text files
> at a generic level.  The database could track changes at a
> per-function/method level, and provide context for a "group" of changes
> that go together (something CVS doesn't do).  It could advise you when a
> change is going to affect other people, and advise them when you do.
> * Integrated documentation - it would be possible for the database to
> help keep documentation in sync with the code - if you change an
> argument to a function/method, it can (optionally, of course!) nag you
> to update the corresponding comments.
> 
> Way out there, I know - the idea of abandoning files is scary, but worth
> looking at :)
> 
> Regards,
> Timothy M. Shead

Crazy Ideas Was: Re: Java hiccups

[Timothy M. Shead]

Ben Elliston wrote:

> mdejong wrote:
> 
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
> 
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
> 
> Ben

I don't know if y'all have any long-term plans for the future of SN, but 
if you do, your remark about correctly parsing correct programs reminded 
me of one of an interesting idea I ran across, one which could eliminate 
these types of problems: database source management.  The idea being 
that, instead of "storing" your program source in files, you keep it 
organized in a central database.  So you'd have tables for classes, 
methods, functions, etc. just like SN's tables, but with the bodies of 
functions/methods/etc in the database as well.  There'd never be a 
"foo.java" or "foo.cpp" - simply a set of "foo" entries in the database. 
  When it's time to compile, the database dumps the source into 
temporary file form to feed the compiler.  Advantages would include:

* Minimize parsing (at least for new projects) - since the code is going 
into the database as it's written (presumeably through some type of GUI) 
the parsing can be kept to a bare minimum (with much, much less to go 
wrong).
* More complex searches / cross references.
* Faster compile times - since the database can easily cross-reference 
function/method calls, it can avoid compiling the ones that are never used.
* Faster compiled executables - the database could perform static 
analysis of call patterns, and organize compiled code to minimize cache 
hits, something that's impractical when working with files.
* Better source management - tools like CVS track changes to text files 
at a generic level.  The database could track changes at a 
per-function/method level, and provide context for a "group" of changes 
that go together (something CVS doesn't do).  It could advise you when a 
change is going to affect other people, and advise them when you do.
* Integrated documentation - it would be possible for the database to 
help keep documentation in sync with the code - if you change an 
argument to a function/method, it can (optionally, of course!) nag you 
to update the corresponding comments.

Way out there, I know - the idea of abandoning files is scary, but worth 
looking at :)

Regards,
Timothy M. Shead