Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!amara!chionia!tom From: tom@chionia.amara.uucp (Tom Doehne) Newsgroups: comp.software-eng Subject: Re: Re: What's a PC? (What's the best environment) Message-ID: Date: 25 Oct 88 21:05:54 GMT Article-I.D.: chionia.TOM.88Oct25170554 References: <9@helens.stanford.edu> <39400002@m.cs.uiuc.edu> <4935@garfield.MUN.EDU> <197@ai.etl.army.mil> <396@uwslh.UUCP> Sender: tom@amara.UUCP Organization: Applied Dynamics International, Inc. Lines: 94 In-reply-to: lishka@uwslh.UUCP's message of 24 Oct 88 21:09:21 GMT In article <396@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes: >In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: > >>The best software development environment on the planet earth is a lisp >>machine. This is a "PC" in the generic sense. It is the quality of the >>supporting environment that makes this so. Those of us who know and ...regrets deleted... > Do other people in this group feel this way as well? Yes, I feel this way. My reasons are below. > I agree >that Lisp environments typically have some nice features and tools, >but... opinion of Lisp as a difficult unstructured language omitted... > Aside from the language, the Xerox 1108 workstations do not seem >to offer that much more than modern environments for other languages. >Windowing is now common. Browsers are becoming common. >Language-oriented editors are becoming common. Symbolic debuggers are >becoming common. Interpretters for compiled languages (such as C) are >becoming common. Although most language environments do not offer all >of the above features, most of them are present. On my Amiga, I have >everything listed above except the interpreter (although not as well >integrated; what do you expect for mostly PD software? ;-). Are Lisp >environments still *that* much better for development.? The greatest shortcoming is that all those things are not integrated in non Lisp-machine environments, lacking the tremendous advantages integration gives. I worked on a Symbolics 3670 for the last two years, and feel that it is one of the finest development environments available for rapid prototyping. The integration of the parts of the environment give the following benefits: The editor not only `knows' about the language, but about the program you are writing. With a keystroke or two, it will load the definition of the function your cursor is on, so it can be edited. Or it will let you cycle through all calls to a function. Incremental compilation of a selected part of the edit buffer is useful, as are things like setting trace and breakpoints. Cutting from the editor to an interpreter or vice versa is helpful, especially if you want some idea of what an expression will do in the program and don't want to type it twice. I also liked being able to call up documentation by positioning the cursor on the function name and hitting --d. In the debugger, it is nice to be able to invoke the editor on an offending function definition, change and recompile it, then return to the debugger window and reinvoke the call from a point just before the problem occurred. (An advantage of an interpretive language.) It is also possible to grab the values of variables in the debugger, operate on them, return the resulting value(s) as the function's result(s), and continue with execution. This is especially nice for ignoring a bug that is fairly unimportant so that you can test what you are working on at the moment. Finally, the Symbolics debugger gives you numerous options for continuing execution when you enter it (if it can). Finally, you can `inspect' any data object on the stack, and follow all the pointers easily, by invoking the Inspector. The inspector (a data browser) made it easy to follow pointers, examine nested data structures, and edit them. Since you can call it from your code, you can easily stub a function by calling the inspector with a list of parameters. When it is called play with the parameters in the inspector to get the value the function should return, and exit the inspector giving it that value to return (a matter of a few mouse clicks). Helps a lot with testing, especially if someone else doesn't have the function written, but you have a good idea of what it should return. It's also possible to simply try things out on a command line interpreter, then cut the sequence from the interpreter and paste it into the editor to turn it into part of your program. The latest Symbolics online documentation is quite impressive. Not only can you go through list of sections that contain a certain string, but the sections are hypertext, so you can go from one topic to a related one mentioned there. It supports diagrams not just text. It has a tree structured summary for browsing. And the ability to shove topics to one side (literally) and take them up later. Even days later (you can permanently store the list of topics you have). I won't mention the support for OOPS, except to say it's fairly nice. Disclaimer: These opinions are mine, and don't reflect those of my current employer or my former one. -- ------------------------------------------------------------------- Tom Doehne Applied Dynamics International tom%amara.UUCP@umix.cc.umich.edu 3800 Stone School Rd. ...(uunet|umix)!amara!tom Ann Arbor, Mi 48108 -------------------------------------(313)973-1300-----------------