Hey, good to hear from you. Yes, this is my bailiwick. For the past few years I've been writing code transformation tools. The semantic "essence" you mention is usually in what the industry calls an AST (abstract syntax tree), and in other data (symbol tables, at a minimum). This is very analogous to what optimizing compilers do.
And in our case we're often dealing with larger patterns. Like isolating presentation layer, business rules, and data access layer stuff, and translating them differently. The OMG's "Patterns Group" is even trying to standardize this AST data. (Although that effort sounds only marginally useful to me.) There is also the Eclipse Metadata Framework, which I haven't had much chance to look at, but sounds promising from what I've read. For us, the "old code" comes in a wide variety of forms. It seems the industry has phases where there are more and then less programming languages to choose from. (It looks to me like we're transitioning into a "more languages" phase right now.) Most of our clients want to modernize code from the previous "more languages" phase (prior to the popularity of C). My own work is entirely in the automation, but overall, the percent that is automated varies wildly from project to project. Sometimes the automation is only used to obtain statistics or spot problematic patterns, but our large projects are all about creating maintainable and modern versions of large legacy systems. So, uh, that's my answer. What was the question? -Jeff On Sun, Dec 27, 2009 at 5:33 PM, Linas Vepstas <linasveps...@gmail.com>wrote: > 2009/12/27 Thien-Thi Nguyen <t...@gnuvola.org>: > > > As years go by, i have come to venerate old code per se less and > > less. > > Heh. As the years go by, I have come to venerate any code, > old or new, less and less. It's always broken, and never actually > does what you want, anyways. > > > I think it would be cool to write tools to distill the > > essence of old code, recasting into new code. That is what > > compilers do, after all... Dreaming, i'd like to see compilers > > that go beyond: > > > > compilation > > source ---------------------> "executable" representation > > > > to > > > > grok-db -----+<-------+ > > v | > > compilation | > > source ---------------+----> "executable" representation > > > > where grok-db contains the analysis results of (this and other) > > source, both present and past. > > Well, taking away two lessons from the recent past: > -- "optimizing" compilers try to "grok" some small portion of the > code, and re-arrange it in such a way that its more efficient. > The challange is to "grok" ever-larger pieces. > > -- There are companies that specialize in taking :"legacy" code, > written in strange old language dialects, and automatically > modernizing/re-writing them to run on modern h/w. I don't really > understand what the "old code" is, or exactly how much of the > re-write process is automated, but its apparently a big business > (i.e. big businesses that have lots of old code buy these things) > I have a friend who works in this area, Jeff Wilkinson, perhaps > he can comment. > > --linas >
