Re: History of code completion

Lex Spoon <lex@cc.gatech.edu> wrote:


>> So I'm quite interested in the history of code completion in IDE's &
>> code editors. Does anyone have any info or personal recollections,
>> or even opinions on the merits/demerits of code completion?


>It used to be much biger than it is nowadays, as I understand it. One
>name for the general area is "syntax-directed editting". I'm a little
>curious, myself, why it hasn't caught on more than it has. I wonder
>how much it's due to a still-prevailing attitude that Real Programmers
>can do it themselves and don't need the help?


          I can do it myself. When I know what I want, I don't want
programs "helping" because they often get it wrong. Word is infamous
for helping (read "sabotaging") in this way. I finally have all of
its nonsense shut off, I think.


          Microsoft Word has the setting for handling automatically
numbering paragraphs under AutoCorrect. Considering that I was doing
what I wanted correctly, I didn't look there until someone else
pointed me to it. I think Microsoft has lots of gall doing that.


          Most of us can type well. I'd rather just type than also have to
worry that a program is going to change what I type.


>Two styles are available for syntax-directed editting. First, the
>editor can force you to only generate syntactic forms. To enter a
>statement, you select from some kind of menu or keyboard command what
>kind of statement you want, and the editor will fill in defaults.


          I'd just as soon type than select from a menu. It's generally
much faster. If the selection involving mousing, it's even worse.
Taking ones hands off the home row is expensive for a touch typist.


>Now, the editor can have a compiled version of the program at all
>times. If you want to change the name of a function, you can select
>that function and then bring up a menu -- the editor will know that
>(a) you have selected a function name, and (b) what functions are in
>scope at that point. Squeak's end-user programming tool is a current
>system that works like this, but it's not practical for general
>programming. (Though there is talk....)


          Will it change all calls, including in other programs? No?
Then, I had better keep track of things. Will it adjust comments to
line them up if the new name is a different length than the old name?
How do I specify this? Whichever way it works, it's unlikely to do it
my way exactly.


>As I understand, programmers who have used traditional tools tend to
>get irritated in systems of this first style. That's too bad; it
>actually sounds to me like it could be a very smooth programming
>experience! Imagine, no syntax errors.... But, I've never actually
>tried it.


          No syntax errors is easy. No semantic errors is the problem.
I'd just as soon look up how a function works if I'm uncertain than to
rely on a program's suggestion.


>The other style is to leave the programmer with a general text editor,
>and then have the editor maintain a parse tree for what the user has
>typed -- essentially compiling while the user types. There are
>algorithms for incremental parsing and incremental analysis, e.g.:
>
>
> Thomas Reps, Tim Teitelbaum, Alan Demers.
> Incremental Context-Dependent Analysis for Language-Based Editors.
> ACM Transactions on Programming Languages and Systems,
> Vol. 5, No. 3, July 1983, 449-477.
>
>It's tricky, though -- a lot of the intermediate stages aren't going
>to be legal code!


          It depends on the language. C won't work when there are fancy
compile-time substitutions.


>This style is used in VB and Smalltalk, and it's used in syntax
>highlighters in, e.g., Emacs. The syntax highlighters in particular
>often rely on heuristics instead of doing strictly correct parses, at
>least if the current buffer has unsyntactic code in it. I honestly
>don't know whether this is due to theoretical limitations or just due
>to a lack of effort by the authors.


          It depends on the language, but I expect theoretical limitations
bite often. Compiler preprocessors probably raise much havoc with
such editors.


>In either style, note that you *have* to have a language-specific
>editor or editor mode for this kind of tool to work. For it to work
>well, you furthermore need the editor to be integrated with the
>compiler (or at least, the editor needs to know about the compiled
>codebase.) For some reason, there is a lot of resistance to such
>integrated development environments, partially because they tend to
>not cooperate well with other languages.


          A language-specific editor means that I may have to work with a
number of editors rather than just one that I prefer.


>In my more cynical moments, I sometimes wonder if software-development
>tools are driven by a desire to make programming remain "fun". What a
>crazy bunch we are!


          I agree with that.


>[I've used both kinds of editors. The first kind is incredibly
>annoying, because there are lots of common and simple text changes
>that are large changes in the parse tree, e.g, move a close brace
>down a few lines past some other statements. The second kind is still


          Quite.


>around. Teitelbaum et al started a company and turned their stuff
>into products. See http://www.grammatech.com/ -John]


          I haven't found them of use.


Sincerely,


Gene Wirchenko

Return to the comp.compilers page.
Search the comp.compilers archives again.