From: yon@smltlk.enet.dec.com (David A. Yon)
Newsgroups: comp.lang.c,comp.windows.ms.programmer
Subject: Re: Please.  (Was Re: I Hope the BC++ IDE Editor Supports OLE Soon)
Date: 15 Apr 92 17:18:51 GMT
Reply-To: yon@smltlk.enet.dec.com (David A. Yon)
Followup-To: comp.lang.c, comp.windows.ms.programmer
Organization: Digital Equipment Corporation


In article <537@lax.lax.pe-nelson.com>, twbrown@PE-Nelson.COM (Tom W. Brown)
writes:
|>In article <1992Apr13.192943.28164@cbnewsc.cb.att.com>, tjr@cbnewsc.cb.att.com
(thomas.j.roberts) writes:
|>|> From article <kuede7INN40h@alhena.usc.edu>, by ajayshah@alhena.usc.edu
(Ajay Shah):
|>|> > ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
|>|> > 
|>|> >>I'm excited about the potential for using OLE in a compiler's text
editor.
|>|> >>In addition to leaving voice annotations, etc., documentation could be
inserted
|>|> >>in-line.  The documentation could be diagrams, word processor text, voice
|>|> >>samples, even animated video.
|>|> > 
|>|> 
|>|> However, I, too, do not believe that animation/audio objects in source
code
|>|> will help developers. As alluded to above, nothing can take the place
|>|> of an intelligent, well though out design - that takes thought,
experience,
|>|> time, and effort.
|>|> 
|>
|>I'll second this; consider:
|>
|>  1) Not only does the original request call for a fairly significant
|>     modification of the program editor, but it calls for a _major_
modification
|>     of the preprocessor and compiler which currently handle only "flat
text".
|>     Perhaps if you use a pre-preprocessor that takes an annotated source
file
|>     and generates flat ASCII this concern goes away at the expense of
another
|>     step in the compilation process.
|>
|>     I haven't tried, but if you do this now in something like Word for
Windows
|>     and "Save As" a text file, is the result compilable?  If so, then maybe
|>     that's all you need.
|>
|>  2) This would seem to have a major impact on source code portability which,
|>     to the extent it currently exists, is based on ASCII portability.  It
will
|>     be some time before OLE is a truly portable convention for embedded
|>     files.
|>
|>  3) IMHO it takes less time to write a standard C comment that adequately
|>     explains a data structure or algorithm than it would take to create some
|>     graph or animation.
|>
|>

WARNING...the following inflammatory rambling is not directed at the original
posters...it's directed at the state of software tools in general...

Sigh... Have we been brainwashed beyond all hope?  Programmers are the ultimate
example of shoemaker's children running around without shoes!  Here we are in
the
90's, and compilers (and hence the programming process) have not changed since
the
sixties!!  WHEN ARE WE GOING TO BREAK AWAY FROM THIS ARBITRARY NOTION THAT CODE
IS AN ASCII FILE???? 

Source Code is a representation of a flow of execution and various other items
necessary for a computer to accomplish a task.  Most modern programs are 
inherently complex.  Yet we continue to slave away using tools that are based
on premises of 25 or more years ago.

This debate has centered around trivial implementation details, not the
fundamental
issue of whether ASCII text is a sufficiently expressive medium to make the
programmer productive enough to meet the constantly increasing demands that 
software engineering places upon them.  In reference to the above posting:  Why
should the embedded objects or hyper-links live in the source file itself, when
a 
meta-file would do the job quite nicely without having to rewrite your compiler?
These details are not the issue.  What I want to know is:

1) Why can't I get my 45 MIP workstation to even do something as simple as
   let me assign colors and/or fonts to comments, variables, keywords, 
   and function declarations?  This alone would make browsing code much
   easier, without breaking a single compiler.

2) Why can't the code editor provide the visual annotations which delineate
   semantics in my code?  Why should I have to constantly insert commented
   seperators between C functions?  An outline-format, or even a function-based
   browser (with individual functions popping up in different windows) could
   prove very useful without all the hassle of having to do it in ASCII.

3) Why do I need syntax to delineate code blocks or scoping?  Why can't I use
   my workstation to say: "Here, let's create a new function foo, which has 
   a scope of bar, and has the following local variables... etc"

4) Why can't the code-browser reference the appropriate places in my 
   design documents or specifications if I need to know more about what
   the code should be doing?  How about referencing a test-validation
   database, to see if the code in question is passing or failing 
   regression tests?

All of the above can be implemented in such a way as to preserve existing
compilers.  The computers we use to write code have more than enough muscle
to pull these feats off.  So why aren't they in general use?  I submit that
it's because programmers don't perceive the need for them, so the demand just
isn't there.  I, for one, would welcome the change.

...writing this posting on a 45-MIP graphics marvel using emacs and the 7x9
font...

--
David Yon
yon%smltlk.cbm.dec.com@decwrl.dec.com <--- use this address