(responding to Scott and Jon)

>> Logically speaking, I can't see why, if any tool
>> were *really*
>> good at forward-engineering, one would ever want to
>> reverse-engineer.
>

> (Scott)
> What happens if you have some people on the team who
> prefer "visual programming" via modeling and others
> who prefer "text programming" via a code editor?
> Wouldn't you need reverse engineering then?

Good point, let's see what happens when we get there?

I'm starting from the analogy where people used to
code at assembler level but nowadays very few, if any,
write assembler; we all write source code for compiler or
at some level more abstract still. However, these two
paradigms are both 'textual'. I expect there will be some
abstract textual form equivalent to the visual modelling
we do currently, assuming there's a demand for it.

> (Jon)
> In addition, one might want to use reverse engineering of
> machine-generated source to:
>
> * see what the code looks like in a different view(s).
> * see code added manually outside of generator
> * check for compliance with intentions of the fwd engineering tool

Different views? If the source is already in the modelling tool,
a good tool would give us the different views.

See the code outside a generator? Sure, I used to look at
the assembly code. I don't any more, and don't know
anyone who does, but I guess some people must, somewhere.
Having seen generated code, it reminds me of why I stopped
looking at disassembled code. It seemed to become too
complicated working out what was really happening.

Check for compliance? I usually do that by seeing whether the
tests pass, though I have spotted a bug in a compiler before now
when I couldn't work out why the code didn't work.

True, these are all good points, but I think if we got a really
good forward generation tool, they would not be relevant for
long, or perhaps only to specialists.

Paul Oldfield.


[Non-text portions of this message have been removed]