soft-eng@MITRE.ARPA (Alok Nigam) (11/11/88)
Soft-Eng Digest Thu, 10 Nov 88 V: Issue 43 Today's Topics: CASE and the Nov '88 Dr. Dobbs Document Editing System Objective-C References on Function Point metric sought Structured Editor vs. Text Editor Structured Editor vs. Text Editor -- Summary (Long) Trellis/Owl What's a PC? (What's the best environment) ---------------------------------------------------------------------- Date: 8 Nov 88 07:22:54 GMT From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu (David Phillip Oster) Subject: CASE and the Nov '88 Dr. Dobbs The inside back cover of the Nov. '88 issue of "Dr. Dobbs magazine of Software Tools" has a funny article about CASE. Basically, the editor tried to get an article on CASE for his magazine. Applying CASE tools to the writing process, in this case, slowed the process down by a factor of five. ------------------------------ Date: 8 Nov 88 18:24:25 GMT From: panda!teddy!jpn@husc6.harvard.edu (John P. Nelson) Subject: Document Editing System I am looking for information on software engineering-oriented documentation systems. We are currently using "troff" for all of our documents, occasionally using "pic" to imbed pictures and diagrams (we have an internally written tool that generates "pic" output). While this fills our needs for the short term, I'm sure that there must be better solutions. We have over 50 diskless SUN workstations, and we would like to take advantage of the CPU power at our disposal. Most of the WYSIWYG documentation programs seem heavily oriented towards producing end-user documentation. As engineers, we like to use the information in our documents in various ways: not just as a end-product hard-copy. Ideally, we would like to use some kind of CASE system, but most of these seem like vaporware at the moment. Barring that, we would like to use a document system with an open interface: that lets us get information in and out of the system easily, (perhaps storing the documents in some kind of database?) We would like to be able to imbed pictures into our documents, but our needs are simple: we mostly generate block diagrams, flow-charts, that sort of thing. I would like to hear from anyone who is actually USING such a system, along with it's pluses and minuses. If you did a comparison investigation of several such systems, I'd really like to hear your conclusions. What I don't need is to be swamped with more vaporware. Thanks in advance. I'll summarize any results that I get (unless you specificly ask me not to include your response). ------------------------------ Date: 10 Nov 88 07:32:37 GMT From: seanjiam@umn-cs.arpa (Sean Jiam) Subject: Objective-C I am interested in getting any materials related to Objective-C. Objective-C is an object oriented language developed by Brad Cox at PPI. Could anyone please send me references about the language? Or send me any typeset documents about the language by E-mail ? My E-mail address is seanjiam@umn-cs.cs.umn.edu.arpa. ------------------------------ Date: Tue, 08 Nov 88 08:38:35 PST From: jon@june.cs.washington.edu Subject: References on Function Point metric sought I keep seeing mention of a technique for estimating effort, cost, or errors in software projects based on something called "function point analysis". I don't know much about it, but it is apparently based on assessing the functionality described in the specification, which seems obviously more useful than measures based on the size or other measurers of the code (which you don't really know until you're almost done with the project). Although I've seen it mentioned in trade papers like COMPUTERWORLD, and a recent posting in SOFT-ENG DIGEST says it is the basis for a software cost estimating product, I have never seen a paper in a journal that describes how the metric is calculated, and presents data showing how its predictions match with actual experience. COMPUTERWORLD says it was introduced in 1979 by A.J. Albrecht, and IBM researcher, but I find no articles by that author in THE IBM SYSTEMS JOURNAL since 1979 (actually there is one, but it has nothing to do with function points or any other metrics). ------------------------------ Date: 4 Nov 88 20:40:00 GMT From: <Bill Smith> wsmith@cs.uiuc.edu Subject: Structured Editor vs. Text Editor I will try to briefly respond to the points raised by Johnny Martin. First, one should not make generalizations about an editor based on such a short description. Leif is a complex program that is more than a "background syntax checker." It contains an incremental parser that efficiently maintains a parse tree that may be consulted to visualize the syntactic structure of the program as well as locate errors. Leif is definitely not slow. Secondly, there are other ways of categorizing language oriented editors. Martin's categorization begs the question by implying that "True SDE's have great power" and thus must abandon text editing commands to provide this power. Leif does not yet provide all of the transformational power of the ideal philosopher's stone SDE but it provides enough power to be worthwhile. While emphasizing that a nice user interface is "a godsend," he assumes that text editing does not fit in such a user interface. Consider Richard Waters article "Program Editors Should not Abandon Text Commands." Syntax directed editing is possible within a framework of textual editing and Leif proves that. The transformation and holophrasting capabilities espoused by Martin are possible within the Leif framework although they have not been implemented yet. I believe researchers at Berkeley are also independently developing an editor with similar capabilities to Leif. Transformational commands are valuable, but is it possible to proved a complete set of such commands? Many transformations should be based on semantic information which may be unavailable because of undecidability of understanding some aspects of programs. Martin implies that a programmer only wants to use a language oriented editor on a fixed, standardized language. In my research, Leif demonstrates that there is a demand for easily constructed language oriented editors. In Leif, it takes only a few hours to create an useful editor once a lexical analyzer and LALR grammar have been written. The problem of creating a useful set of transformations is difficult and time consuming. Similarly, writing emacs lisp code to edit in a new language-sensitive mode is non-trivial. By quickly developing an editor for a special purpose language, the quality of the language may be improved through an iterative design process. This same design process may be used to teach compiler design techniques. Leif allows many different languages to be edited with no modifications to the user interface. The original question that started this discussion demonstrates that the design of language oriented editors still pose several research questions. The foremost research issue is the user interface. Leif provides a user interface that is radically different that that provided by Xinotech's Program Composer that Martin champions. Finally, evidence that language oriented editors (or syntax directed editors) are not a solved problem is that they are not widespread and they have only a limited user community. Research should continue to improve the tools available to programmers beyond the limited editing techniques available now. ------------------------------ Date: 8 Nov 88 22:35:18 GMT From: gandalf.cs.cmu.edu!ntanaka@pt.cs.cmu.edu (Nobuyoshi Tanaka) Subject: Structured Editor vs. Text Editor -- Summary (Long) Thank you for your responses. I must summarize the result but it is hard job for me to summarize them without spoiling them. So, I will COLLECT (not summarize) all the responses. I apologize... Some responses were posted not e-mailed, so I will not include them. Thanks again. --Nobu ______________________________________________________________________ From: uwslh!lishka@spool.cs.wisc.edu (Fish-Guts) Although "Structured" and "Text" editors are two different conceptual models, in the real world there are many editors that are not simply "Structured" and not simply "Text-Oriented." For instance, I use Gnu-Emacs at work, which has different "major-modes" for enterring text or code. One mode (called "text-mode") word-wraps and justifies all the text that I type in so that I can concentrate on writing, and forget exactly how I am formatting a particular line. This is sort of a "structured-English" mode. Another mode allows one to enter text, but formats it in a style suitable for C-code...this mode aids greatly in writing programs, because the editor formats the text correctly. If one wants more structure, Gnu-Emacs can be programmed (using a built-in Lisp language) to rigidly control the structure of a language (although noone has done this for anything but Lisp to date). Other editors I have used are *mush* more structured. One of the editors on the Xerox 1108 Lisp-Workstations *only* allowed legal Lisp code to be enterred; everything was rejected before even inserting the text. This editor was *highly* structured towards Lisp, and was sort of a pain to use. One of my favorite editors came with a C-environment that was sold for the Commodore 64. The basic editor was completely unstructured; i.e. you could enter anything you wanted. However, it had a command that allowed one to run a C-syntax-checker over the current edit-buffer to make sure the code that you had just written conformed to the Kernighan-Ritchie standard. If the above sounds too technical, don't worry. I am just trying to give examples of "real-world" editors, which typically are *not* just "Structured" editors and are *not* just "Text" editors. Most are somewhere between the two extremes. If you are looking for an excellent (although very large) editor, I would recommend Gnu-Emacs. It is essentially free (you need only pay the shipping charge), but it is only available for Unix. It is also monstrous (the executable alone is 1 megabyte, and the support files needed must consume over 2 megabytes), and has an amazing amount of functions, which makes it a bit hard to learn initially. However, once one knows the basics, there is a lot of power available. ______________________________________________________________________ From: johnm@uts.amdahl.com (John Murray) The XEDIT component of IBM's VM/SP mainframe opsys is a very powerful text editor. It has a macro interface to the standard VM command languages EXEC & REXX. Macros are commonly used to format the screen displays, set reserved and protected fields, etc. Thus, you can use the editor to build full-screen interactive menus, for example. Since the macro programs take over every time the user hits Enter, or a function key, the facility can be used to do syntax checking on the fly, justification, pretty-printing, etc. At Amdahl, we use XEDIT & REXX extensively to check and format Assembler source code. There is an imitation of XEDIT for IBM PCs called KEDIT available from Mansfield Software, which works with Mansfield's Personal REXX. But it's not nearly as good as the real thing. ______________________________________________________________________ From: celerity!jjw@ucsd.edu I suspect I will not be alone in saying this. Most Emacs editors provide exactly this capability. It is possible to define editing packages which define how to recognize and format various kinds of blocks depending on the kind of file being editted. "Standard" packages are often supplied and it is possible to define your own if you don't like the standard. It is also possible to redefine what key strokes cause which editing operations so if you want you can make your Emacs behave like vi, Wordstar, ... ______________________________________________________________________ From: DORFMAN@ECLA.USC.EDU On October 25 you inquired about Structured Editors in the Software Engineering Digest. Mr. Gary Pace of my organization (Lockheed Missiles & Space Co., Sunnyvale, Calif.) suggested that you contact Xinotech Research about their editor called Program Composer: Xinotech Research, Inc. Technology Center, Suite 213 1313 Fifth St. SE Minneapolis, Minn. 55414 612-379-3844 Mr. Pace may be contacted at 408-742-7791; or I will forward to him any messages you send via E-mail. We would also be interested in your summary of responses. Merlin Dorfman 408-756-8204 DORFMAN@ECLA.USC.EDU ------------------------------ Date: 8 Nov 88 05:03:42 GMT From: kehyoe@umn-cs.arpa (Ong Keh Yoe) Subject: Trellis/Owl I was wondering if anyone could send me any articles in nroff / troff or TeX / LaTeX format or even plain text on an Object Oriented Programming Language, called Trellis / Owl. I have a presentation soon, and my material presently is very sparse. Trellis / Owl has been developed at DEC. My main interests are on it's language features to support OOP. Please send me any material by E-Mail to kehyoe@umn-cs.cs.umn.edu.arpa. ------------------------------ Date: 8 Nov 88 00:05:12 GMT From: texbell!killer!pollux!ti-csl!pf%csc.ti.com@bellcore.bellcore.com (Paul Fuqua) Subject: What's a PC? (What's the best environment) >N.B., most if not all of the advantages of an integrated LISP >environment cited in the above articles are also present in >Smalltalk. That's the point: it's not the language, per se, it's the integrated environment. Lispms just seem to be better-known. And, gradually, environments for lesser languages are catching up to those that already exist for Lisp and Smalltalk (check out Saber-C). So what got Lisp and Smalltalk there first? My vote goes to the object-oriented aspect of both languages, which is also filtering out to lesser languages (I see C++ as a broader dialect of C). > It also supplies real structure >for your data, instead of forcing everything to look like a list. Most modern Lisps provide lists, arrays, structures, and "objects" (as in Flavors or CLOS). ------------------------------ End of Soft-Eng Digest ******************************