srt@CS.UCLA.EDU (06/03/87)
David Krowitz gave us a nice summary of some of the nice features of Aegis. The opposite side of the coin is: What's wrong with Aegis? Where did Apollo screw up? I'm a little dissatisfied with the Display Manager, which is very window-oriented. It is easy enough to write any kind of graphics inside a particular window, but very difficult to write anything that deals with the screen as a whole (unless you usurp the whole screen). To pick a trivial example, try and write a program that crawls a crab around the background portion of the display without being in borrow mode. Or write a program that changes the background pattern. I also dislike the fact that you have to specifically acquire the display (and interrupt all other display processing) in order to perform graphics in a window. Amongst other things, it can make debugging graphics code an incredible bitch. -- Scott
Bruce_Howard@UB.CC.UMICH.EDU.UUCP (06/04/87)
Most of what David Krowitz points out is true. I must disagree,
however, on one point: the naming scheme for function calls. I
find the inclusion of a $ in names quite obnoxious. This serves
only to maintain the largely artificial difference between system
(kernel) calls and library function calls. As systems isolate
the programmer from the specific hardware more and more, such
naming segregation really is not necessary in most cases.
The naming scheme, while resulting in descriptive function names,
also results in function names that are too long and too similiar
to each other. When I quickly scan down a section of code, a
series of function calls beginning with the same words are easily
confused.
Aegis has a lot going for it and has implimented features that are
quite advanced. In my opinion, Apollo is moving in the right direction.
However, I find the fact that it is still wedded to Apollo hardware
quite distressing. With the development of the NCS and increasing
connectivity through UNIX networking code, this may become a moot
point...we shall see.
Bruce Howard @ caen.engin.umich.edui91@nikhefh.UUCP (06/05/87)
In article <668935@ub.cc.umich.edu> Bruce_Howard@UB.CC.UMICH.EDU writes: >Most of what David Krowitz points out is true. I must disagree, >however, on one point: the naming scheme for function calls. I >find the inclusion of a $ in names quite obnoxious. This serves >only to maintain the largely artificial difference between system >(kernel) calls and library function calls. As systems isolate >the programmer from the specific hardware more and more, such >naming segregation really is not necessary in most cases. > >The naming scheme, while resulting in descriptive function names, >also results in function names that are too long and too similiar >to each other. When I quickly scan down a section of code, a >series of function calls beginning with the same words are easily >confused. > I, in return, have to disagree with this. One major problem with the Unix system and function calls is that they have very trivial names, which easily can result in name clashes between user routines and system routines. We for example in the High Energy Physics world work in huge collaborations with a lot of different computers (mostly VAX, IBM, Cray). Now it happened that somebody wrote a subroutine package in which the trivial name TOPEN is used. This package is used heavily throughout the collaboration. Now changed our institute to an Unix machine and what happens, TOPEN (3F) turns out to be a Unix routine to open a tape file. And, of course, a lot of our programs need both routines in the same program ===> CLASH!!! A lot of problems could have been avoided if the Unix system naming scheme would have been more like that of Apollo or VAX (with $ and _). Regards, Fons Rademakers -- Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics. Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands UUCP: {decvax,cernvax,uck,unido,vmucnam,seismo}!mcvax!nikhefh!i91 BITNET: nikhefh!i91@mcvax.bitnet Telex: 10262 (hef nl)
mishkin@apollo.UUCP.UUCP (06/05/87)
Most of what David Krowitz points out is true. I must disagree,
however, on one point: the naming scheme for function calls. I
find the inclusion of a $ in names quite obnoxious. This serves
only to maintain the largely artificial difference between system
(kernel) calls and library function calls.
You've mistaken what's going on here. Kernel calls and library calls
are named exactly the same way. "gpr_$init" happens to be a procedure
in a user space global library; "proc2_$get_info" happens to be a procedure
in the kernel (i.e. an SVC). Names can be interpreted as one of:
<manager name>$<operation name>
<interface name>$<operation name>
By "manager", I mean a particular (non-generic) piece of code that
implements a particular piece of functionality. By "interface", I mean
something more generic -- an interface might be implemented by a number
of different managers. For example, the "ios_" interface is implemented
by both the managers for "uasc" type objects and "case" (source history
file) type objects.
Note that all manager and interface names chosen by Apollo end with "_"
to keep them from conflicting with names chosen by customers. (I.e.
if you're writing your own code using our conventions, you names should
look like "foo$do_this".)
Of course, we can't do anything about the names of standard Unix library
and system calls. DOMAIN/IX uses the standard names for those.
The naming scheme, while resulting in descriptive function names,
also results in function names that are too long and too similiar
to each other. When I quickly scan down a section of code, a series
of function calls beginning with the same words are easily confused.
Of course, this is a matter of esthetics, but personally I'd rather have
it our way. First of all, it minimizes name conflicts while still allowing
people to use "good names" (e.g. "open") instead of creating funny variants
of the good names. Second, I find it useful in looking at a piece of
code to know what subroutines calls are likely to be related. I think
that as the set of library and system calls on Unix grew (esp. in 4.2),
it became very hard to keep track of things (and also, they used up more
good names).
-- Nat Mishkin
Apollo Computer Inc.
-------gore@nucsrl.UUCP (06/06/87)
/ nucsrl:comp.sys.apollo / mishkin@apollo.UUCP (Nathaniel Mishkin) / > >[Using prefixes such as "<facility>_"] >minimizes name conflicts while still allowing >people to use "good names" (e.g. "open") instead of creating funny variants >of the good names. Second, I find it useful in looking at a piece of >code to know what subroutines calls are likely to be related. I think >that as the set of library and system calls on Unix grew (esp. in 4.2), >it became very hard to keep track of things (and also, they used up more >good names). > > -- Nat Mishkin The way I see it, this argument is about how AEGIS and Unix go about compensating for what really is a programming language deficiency. In many of the newer languages, you can prefix the routine name with the name of the library from which it came, if there is a naming clash, and not use the prefix if there is no clash. This problem will disappear when the outdated languages become obsolete. Sigh... maybe next century... (:-( & (:-) Jacob Gore Northwestern University, Computer Science Research Lab {gargoyle,ihnp4,chinet}!nucsrl!gore gore@EECS.NWU.Edu (for now, only from ARPA)