| Oliver Wong 2005-07-25, 10:02 pm |
|
"jce" <defaultuser@hotmail.com> wrote in message
news:_b0Ee.12377$iG6.10246@tornado.tampabay.rr.com...
>
> I was talking more about the typical in use code generators - taking UML,
> MetaData, Designs, or GUI whizz bang drag and drop apps to create code in
> which you add functionality. I know that if you drop a table on a form
> and attach a database query to fill it, you don't have to write ANY code -
> even the SQL has a designer these days - I think you should be able to
> understand what the tool produced. It _should_ be readable - if it's not
> the tool should be replaced with one that is.
It depends a lot of what you want to do with the resulting code. I haven't
done C# programming with Microsoft Visual Studio in a while, but I remember
that you could have two views of your application: a GUI editing view, and a
code editing view. You could perform modifications from either view, and
they would stay in "sync", to a limited degree. That is, MSVS.Net would put
a comments around a block of code basically saying "Don't touch this". If
you did edit that code, then the GUI editing view would become very 
and probably very bad things happen to your source code. I never really
explored that path too deeply, so I don't know in detail what happens.
The point is, because the comment made it very clear to me that I wasn't to
touch that code, at the time I really didn't care what the code looked like,
or if it was readable (in fact, the MSVS editor hides that portion of the
code; you could only see it if you opened up your source code file in a
plain text editor).
Of course, I haven't been in the programming industry long enough to worry
about "What if my vendor goes bankrupt and/or stops supporting my tools?" I
can imagine that that is a very valid concern in the long term, but if
you're relatively confident that you're not gonna need to touch a certain
piece of code again, and if it's cheaper (in money, time or staff) to use
the tool that doesn't generate readable code, then certainly you shouldn't
disregard that option outright.
> If it wasn't important to understand any outputs then everything should
> generate just 0's and 1's as an output targetted per CPU, right?
"Everything" is a dangerous word in the above sentence, but of course
you knew that. I just wanted to point out a situation you might not be
familiar with in which it's desirable to output source code, even though you
don't expect anyone to read it.
Let's say I want to write a tool that generates programs; perhaps one of
those "instant game makers" where you just drag and drop players and
enemies, and you'll have a working game, with no programmign skills
nescessary. If I knew the C language very well, but I knew almost nothing of
assembly, it would be a lot easier for me to make my tool generate C code,
and then call an existing compiler, than to actually study assembly myself,
as well as compiler theory and optimization theory, and actually generate
machine code myself.
- Oliver
|