|History of code completion email@example.com (2001-10-20)|
|Re: History of code completion firstname.lastname@example.org (Lex Spoon) (2001-10-21)|
|Re: History of code completion email@example.com (2001-10-23)|
|Re: History of code completion firstname.lastname@example.org (Jan Gray) (2001-10-23)|
|Re: History of code completion email@example.com (2001-10-23)|
|Re: History of code completion firstname.lastname@example.org (Geoff Wozniak) (2001-10-27)|
|Re: History of code completion email@example.com (Marco van de Voort) (2001-11-05)|
|Re: History of code completion firstname.lastname@example.org (2001-11-08)|
|Re: History of code completion email@example.com (Richard Heathfield) (2001-11-08)|
|Re: History of code completion firstname.lastname@example.org (Lex Spoon) (2001-11-08)|
|Re: History of code completion email@example.com (2001-11-11)|
|Re: History of code completion firstname.lastname@example.org (Rodney M. Bates) (2001-11-11)|
|Re: History of code completion email@example.com (Joachim Durchholz) (2001-11-14)|
|From:||firstname.lastname@example.org (Gene Wirchenko)|
|Date:||8 Nov 2001 01:16:55 -0500|
|Organization:||Posted via Supernews, http://www.supernews.com|
|Posted-Date:||08 Nov 2001 01:16:55 EST|
Lex Spoon <email@example.com> 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
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
>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
>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
>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.
Return to the
Search the comp.compilers archives again.