las@apr.UUCP (12/08/87)
In article <3476@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE) writes: >In article <1336@saturn.ucsc.edu> wolf@ssyx.ucsc.edu (Mike Wolf) writes: >>The latest editor for VMS is called the Language Sensitive Editor. >>I found the LSE more of an annoyance then anything else... >For editors such as you describe, I'd agree. An editor that just >understands the syntax is, in my opinion, useless - it makes some >trivial things easier and other trivial things harder. The last >such editor I tried to use got junked after 2 hours, when I found >out <Wouldn't let him use white space or place comments in legal places> >It was also grindingly slow. >On the other hand, a REAL language sensitive editor would be very >useful. Imagine placing the cursor on an identifier and being able >with one click or keystroke to bring up its declaration. Overload >resolution and cross-module resolution done for you. Imagine being >able to see the fully qualified name of the identifier, with another >click. Imagine it tracking the range of a numeric expression as you >type, and displaying that range in a little box. And so on. Hmmm. Yes, an editor which understands the semantic structure of the target language would be nice. Such an editor would understand the elements of the language, such as type and data declarations. Then if it would help you keep track of the various entities in your program (type declarations, data items, functions, etc...) and assist you in composing and using them, THEN we might have a language sensitive editor. I'm unfamiliar with VAX LSE, but my experience with language sensitive editors parallels the earlier-mentioned complaints. They may be more accurately characterized as syntax-sensitive editors (SSE's). Worse, they may even turn out to be STYLE-sensitive editors (another kind of SSE) and this is what some (many? most?) alledged LSE's turn out to be. Programming style is, in my experience, a rather sensitive issue; maybe even as controversial as "which language is best." I'm very particular about MY style of programming, but rather more open minded about YOUR style (although I have seen some practices which are really bad). I don't want to debate style or criticize YOUR style, but I don't want to do it YOUR way and I will not be forced to do so. STYLE-sensitive editors impose style without offering sufficient compensitory benefits so keep'em away from me! By the way, can anyone name any LSE's which go beyond syntax-checking? regards, Larry -- "The only thing worse than being talked about is not being talked about." - Oscar Wilde, James Whistler or George Bernard Shaw depending on who you ask Name: Larry A. Shurr (cbosgd!osu-cis!apr!las or try {cbosgd,ihnp4}!cbcp1!las)
jbn@glacier.STANFORD.EDU (John B. Nagle) (12/10/87)
Syntax-sensitive editors have been around for a while, one of the first
being the Cornell Program Synthesizer running on a Terak in the mid 1970s.
One of the basic problems with systems of this type is that they
interfere with continuous typing, and are more a nusance than a help to
fast typists.
About three years ago, this idea showed up at a venture capital show as
a "word processor for people who can't write", a mouse-driven system which,
using menus and submenus, allowed the user to create text by selecting words,
while restricting the user to valid English sentences. The user was
restricted to a subset of English, but one broad enough to allow for most
business needs. It was very slow and painful to use. The authors were unable
to obtain funding.
There are useful programming environments. Rational Machines has gone
furthest in this direction. Their system is designed to coordinate the work
of large teams of programmers developing integrated systems of Ada programs.
Version control has been carefully thought out, so that one can express
ideas such as development mainlines and sidelines, remerging divirgent
development paths, and intelligent automatic recompilation including
damping out of hidden changes. (This last would work nicely for Modula,
too, with appropriate tools. The notion is that if A uses B and B uses
C, and C changes, then B and C must be recompiled, but if the exported
interface of B didn't change, then A need not be recompiled. This is
non-trivial to implement, because if B imported a type from C and
mentioned that type in an exported definition, then A really would have
to be recompiled. In huge Ada programs, the cost of a low-level change
can be very high without tools smart enough to do just the recompilations
really needed, high enough that people hesitate to make changes in
places where they should be made.)
John Nagle