While I agree in principle about the current practices and the interchangeability of plain text files (proven, I believe, above all through the pipe/redirection system), I don't think that it is necessarily agreeable with a good software development process.
There are two major things I believe are at fault with text file source code:
1. Your software design is dictated by the language definition, not by your desired software engineering princibles. For example, C++ and Java has no way of preventing one object instance from manipulating private members of an instance of the same class. And there is no unbreakable way to tell which class may access which memembers of another class. Programmers (ok, I) are in general lazy and/or have limited capacity/knowledge of the system, and I have met few programmers who read and follow all specifications and documentations at all times. Mostly it's about doing what the source files permit, not the documentation. So it's up to the tools and the discipline of the programmers to maintain the quality. I find source file tools still a bit lacking, and as for the programmers discipline, well...:) Tools that help the programmers adhering to specifications and rules should be essential for quality development.
2. Working within file scope, or file-to-file scope (e.g. class diagrams in Together), only gets you so far. Software design is often about higher level constructs like patterns, modules, protocols, event chains etc where one property affects a lot of source elements. A tool that manages this permits (a) more rapid development and (b) automatic relief from a lot of potential bugs.
I believe that tools that assist these high-level constructs will be an expanding market but are too limited today, instead being in the way, which is what you seem to have experienced with Visual Age.
Together is the tool I know of that has walked the farest along this road, but they (a) aren't broad-scoped enough, and (b) show some problems with using text source files. At the same time though, they prove your point by more or less requiring parallell work with an external IDE, which works nicely thanks to using plain text source files.
Anyway, perhaps I only long for more helpful tools because my brain is getting too old for complicated stuff.:)
Initially, I was happy to see the plugin/generality approach taken with Eclipse.
However, already in the first paragraphs of the documentation, they state that
Eclipse is designed to work with any *file* based data, which breaks the concept
for me.
I am struggling to get rid of file-based software development and instead work with
a database. I don't want to browse.java,.h or.cpp files; I want to work with
classes, attributes, patterns, interfaces, sequences, graphs and a couple of other
nifty higher-level things, and I am working on a toolset to enable this. If I could
integrate that into an existing framework, e.g. Eclipse, that would be cool as
heck.
The problem is that though it is possible to engineer back and forth between source
code and a richer data structure (as shown by Together for example), there is a
need for more data than just the source code. What I need requires metadata to be
connected to and consistent with the code, both within and between classes, modules
etc. This is very, very difficult to maintain in files which you can manipulate
with other tools, or just any text editor. Again, Together shows that by putting
metadata in comments in the source files, you get a vulnerable structure because
you more or less *must* use an external IDE in parallell to work smoothly.
Now, because of this statement in the documentation, I haven't looked any further
into the plugin development for Eclipse. Perhaps I'm mistaken, and it can be made
to work with database-based development, or alternatively, work with consistency
across and within source files. Or, perhaps my mistake is in the direction of my
desire for higher-level development methods and tools; databases and patterns may
not be the way to go. In any of these cases, Eclipse would be awesome.
Now, my final gripe with Eclipse is that after some time evaluating both, IDEA
"feels" just so much nicer than Eclipse. I can't really put my finger on what it
is, but it is like the difference between wearing tailor-made clothes compared to
off-the-shelf ones; both do the job nicely but the former just feels more
comfortable.
Actually, IDEA (used in parallell with Together), with all its while-you-type
assistance and analysis, refactoring and code helpers, is the first tool that has
made me think of abandoning my futile quest of higher-level software development
and just give in to standard products that so many more people are developing to so
much polished results.
And, IDEA is *just barely* bearably slow to use from a pure X terminal.:)
Slashdot Mirror
There are two major things I believe are at fault with text file source code:
1. Your software design is dictated by the language definition, not by your desired software engineering princibles. For example, C++ and Java has no way of preventing one object instance from manipulating private members of an instance of the same class. And there is no unbreakable way to tell which class may access which memembers of another class. Programmers (ok, I) are in general lazy and/or have limited capacity/knowledge of the system, and I have met few programmers who read and follow all specifications and documentations at all times. Mostly it's about doing what the source files permit, not the documentation. So it's up to the tools and the discipline of the programmers to maintain the quality. I find source file tools still a bit lacking, and as for the programmers discipline, well... :) Tools that help the programmers adhering to specifications and rules should be essential for quality development.
2. Working within file scope, or file-to-file scope (e.g. class diagrams in Together), only gets you so far. Software design is often about higher level constructs like patterns, modules, protocols, event chains etc where one property affects a lot of source elements. A tool that manages this permits (a) more rapid development and (b) automatic relief from a lot of potential bugs.
I believe that tools that assist these high-level constructs will be an expanding market but are too limited today, instead being in the way, which is what you seem to have experienced with Visual Age.
Together is the tool I know of that has walked the farest along this road, but they (a) aren't broad-scoped enough, and (b) show some problems with using text source files. At the same time though, they prove your point by more or less requiring parallell work with an external IDE, which works nicely thanks to using plain text source files.
Anyway, perhaps I only long for more helpful tools because my brain is getting too old for complicated stuff. :)
I am struggling to get rid of file-based software development and instead work with a database. I don't want to browse .java, .h or .cpp files; I want to work with
classes, attributes, patterns, interfaces, sequences, graphs and a couple of other
nifty higher-level things, and I am working on a toolset to enable this. If I could
integrate that into an existing framework, e.g. Eclipse, that would be cool as
heck.
The problem is that though it is possible to engineer back and forth between source code and a richer data structure (as shown by Together for example), there is a need for more data than just the source code. What I need requires metadata to be connected to and consistent with the code, both within and between classes, modules etc. This is very, very difficult to maintain in files which you can manipulate with other tools, or just any text editor. Again, Together shows that by putting metadata in comments in the source files, you get a vulnerable structure because you more or less *must* use an external IDE in parallell to work smoothly.
Now, because of this statement in the documentation, I haven't looked any further into the plugin development for Eclipse. Perhaps I'm mistaken, and it can be made to work with database-based development, or alternatively, work with consistency across and within source files. Or, perhaps my mistake is in the direction of my desire for higher-level development methods and tools; databases and patterns may not be the way to go. In any of these cases, Eclipse would be awesome.
Now, my final gripe with Eclipse is that after some time evaluating both, IDEA "feels" just so much nicer than Eclipse. I can't really put my finger on what it is, but it is like the difference between wearing tailor-made clothes compared to off-the-shelf ones; both do the job nicely but the former just feels more comfortable.
Actually, IDEA (used in parallell with Together), with all its while-you-type assistance and analysis, refactoring and code helpers, is the first tool that has made me think of abandoning my futile quest of higher-level software development and just give in to standard products that so many more people are developing to so much polished results.
And, IDEA is *just barely* bearably slow to use from a pure X terminal. :)