jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/18/89)
In article <135300010@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > > >I said >>> There is no essential difference between Smalltalk messages and C++ >>> virtual functions. > >psrc@pegasus.ATT.COM said >>Well, not really. >and mentioned perform:. > >I've used Smalltalk heavily for the last four years, and C++ off >and on for the last three years. I still say that there is no >practical difference between messages and virtual functions. One >... >The big advantage of Smalltalk untyped messaging is that it is much >better suited to experimental programming. Virtual functions are >closely tied to C++'s type system, which forces the programmer to >decide interfaces early. When the interfaces turn out to be wrong, >as usually happens, the programmer has to make lots of revisions. >However, from a high-level design point of view, I don't think that >there is much difference between them. I've thought about this and some of the other OOP issues and have come up with a simple list of what I think would be "fixes" and desirable enhancements to the current crop of programming environments. Now, I am hardly working on the cutting edge of programming environments here at State, and I'd be interested in the reactions of people who are into this sort of thing. If you folks will mail me responses I'll summarize and post them in a week or two with a revised "ideal environment" ... The basis of the list is my experience with large C projects (and other "conventional" language projects), Smalltalk, C++ and a variety of projects on the Mac. Pardon me if the terminology is loose, but I haven't made much of an effort to formally edit the list. --- THE IDEAL PROGRAMMING ENVIRONMENT ... THE ENVIRONMENT The system is object-oriented. The basis would be something like Smalltalk. A "workspace" is a hierarchical environment, organized as a DAG (i.e., something like multiple inheritance is allowed). While the programmer is "in" a node of a workspace he has access to all of the features of that node and all the features of the parent nodes. There is a system workspace to which all users have access. It cannot be modified by nonprivileged users. There is a public workspace to which all users can make submissions. Anyone can read these submissions; only the submitter can delete and/or modify them. Each user has a private workspace of his own. Classes and methods can be tagged with one or more "project" ids so that they can be copied or removed easily from a workspace. The contents of a workspace node are persistent objects. Text files, programming tools, etc., are all treated as objects. Objects are modified only by their own methods. Most editing and perusal takes place in browsers. The programmer is able to modify the object being browsed using the browser itself, if the object can be meaningfully modified. The browsers are "smarter" than many existing browsers and contain fast cross-referencing tools. All changes to source code are automatically logged. Changes can be periodically compressed and checkpointed by explicit command, and possibly at the system's suggestion (with the user's approval). A tool permits the easy recreation and inspection of earlier versions, the "forking" of variant versions, and the later merging of variants. All tools can provide output with varying verbosity. Tools can be made to generate detailed statistics databases which can be browsed by the truly curious programmer. The source code to all tools is available for inspection and modification. If a user customizes a tool, he is not required to copy the entire tool into his workspace (unless he wants to); instead, he need keep only the changed parts. The system is robust and will never generate unhandled hardware exceptions except through gross internal error. Furthermore, it is failsafe and crashproof and will not be inconsistent when restarted if it is terminated unexpectedly by power failure, low-level system error or similar problem. Full scavenging and garbage-collection is provided and cannot be turned off, though it can be tuned. THE LANGUAGE & COMPILER Declarations are implicit (i.e., not required by the compiler) but a detailed interface can always be generated for the programmer. (Something like Eiffel's _short_.) There are tools to generate documentation from source code. There is no default checking to ensure that objects understand messages; however, there are tools available to verify that all references that can be statically bound are consistent. Polymorphism and other devices that permit and encourage the writing of generic code and reusable code are fully supported. Changes in the source code require the least possible amount of recompilation. References to objects are dynamically bound by default, thus eliminating a lot of recompiling and linking, although the option of an optimized static binding is available. A variety of dataflow analysis tools are available to the programmer, as well as intelligent editing tools that can perform "automatic" modularization of source code and other types of optimization, so that the compiler's optimizations can be viewed explicitly, in the high-level language, whenever possible. The programmer is free to recommend or prohibit optimizations, and the compiler/linker will, by default, note those cases where it "disapproves" of the programmer's recommendations, and will provide statistics to back its claims. Objects' instance variables are private and their values cannot be modified externally (i.e., by methods not belonging to that class or its superclasses). The compiler is allowed to optimize indirect references through accessor methods to direct references, if it can do so robustly. It is not possible to specify pointers to anything other than a complete object. The compiler is only allowed to generate such pointers internally when it can verify their validity or when it generates suitable range- checking code along with them. Range-checking by the compiler cannot be turned off in those cases where dataflow analysis cannot guarantee the validity of arguments. Debugging support is fast and is automatically provided. There is a negligible speed penality for comprehensive debugging support, although some increase in object code size occurs. The debugger allows the program to run while it interactively displays the statistics of program execution. Whenever execution of a method is interrupted because of an exception or user interrupt, the user can debug, recompile, and RESUME EXECUTION if it is possible to preserve the context at which execution was interrupted. Static bindings might be dropped and replaced with dynamic bindings in order to allow this to occur. The user can also resume at some other sensible point, i.e., higher in the current call chain, or at the head of the event loop. The language also allows the user to specify "checkpoints" at which the program can be restarted. --- v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.