Ben St. John
Posts: 3
Nickname: jbstjohn
Registered: Aug, 2005
|
|
Re: Programmers Shouldn't Touch the Source
|
Posted: Oct 27, 2005 9:09 AM
|
|
Definitely an interesting topic. You seem to have backed off on the the revision idea, but pushed forward other stuff (links to test suites, etc). IMO, most of this can be nicely covered by tags that are maintained by the version control system. And you *will* have version control system, so anything that doesn't use information from it directly will require extra work from developers, which isn't too likely.
And, in fact, is probably the stumbling block to not having all of this meta-information at the moment, rather than any technological issue.
Somewhat conflated with the revisioning, and let's say external, metadata, is the idea of abstracting out programming concepts, or what you could consider internal metadata. But as someone else astutely noted, this is already what most IDE's are doing. Yes, they're each doing it in their own way, but, at least per language, that's somewhat necessary. You need, in your language model, some way of representing every feature of that language. Which leads pretty much to a compiler/interpreter for that language.
What I see as going in the same direction, but perhaps being more useful, are things like Rational's binding of UML diagrams with code, with the certainty of a one-to-one correspondence (or at least the same correspondence as source code has to assembly...).
I would like to see more of this. I'm annoyed, for example, that with most editors, I can't click on a macro, and have it replace in my view, one level of expansion of that macro. Or a "forEach" in C++. It seems that IDEs are going in this direction -- the refactoring possibilities keep getting better, class diagrams too. Still it doesn't seem that things are consistent enough, when hopping between abstraction layers, to be as useful as we'd like.
There are other, perhaps more inherent problems too. Abstractions are often leaky (see Joel Spolsky). And for many things, it's not yet clear what the "most worthwhile" abstractions to have formalized would be. In going from assembly to source code, it was agreed sub-routines, variable names, and some flow control constructs were pretty good ideas (okay, the first two could be seen as assembly vs. machine code...). I think the formalization of some patterns (isn't that nice and vague) might be one the next possible abstraction step. [I.e. diagrams or forms for a Singleton class, or Class Factory, or model/view architecture that puts a lot of "standard" stuff in the background, and maybe enforces some programming contracts -- e.g. your view doesn't change your data, or this function never allocates or frees memory...]
In short, and to get back to your original ideas, I think it will be more important to improve the tools (perhaps including their export/report generation abilities) and to clarify what can be safely abstracted away, than to think about storing code in a particular format. Version control systems mean code is already stored as a database. As long as this can be happily exported, this is a good thing. Tags in this database should take care of external metadata. And a more clearly defined abstraction layer above current source code is needed, for internal metadata.
Cheers, Ben
|
|