Self-interest October 1992

self-interest@lists.selflanguage.org

19 participants
21 discussions

Re: Where to use SELF - your opinion
by jmaloney＠Eng.Sun.COM 31 Oct '92

31 Oct '92

Here's where I think we agree: 1. memory-unsafe languages are bad 2. different levels of bug-finding effort are useful in different situtations 3. typechecking is a useful because it finds many bugs 4. typechecking doesn't necessarily find all bugs, so testing will always be necessary 5. predictable performance is good 6. all things being equal, good performance is is better, and is sometimes worth sacrificing other things for Here's where we partially disagree: 1. languages without static typing necessarily require more runtime overhead (space, time, or both) [My position: you're right but how low can we push the overhead? At some point, it may be worth paying the extra overhead in exchange for program reliability, ease-of-evolution, or speed-of-development. We usually don't need efficiency badly enough to write in assembler, after all. Perhaps some day we won't need efficiency badly enough to write in C++ or C.] 2. the value of typechecking [We both agree it is valuable, but I think you value it more highly than I do. I used to program in Mesa, which had a much stronger type system than C. When I first started working in Smalltalk it made me very nervous to try my programs because I knew they had bugs. They did, but the cost of encountering a bug was so low, I soon got over my psychological addiction to the security of typechecking. I've been doing most of my programming in Smalltalk and Self for four or five years now and whenever I use C I'm shocked at how difficult it is to find bugs, even using the Think C symbolic debugger. I suspect that you use C and C++ much more than I do and are thus more viscerally aware of how much tedious debugging the type system is saving you from. On the other hand, I've been doing exploratory programming and am keenly aware of how much restructuring I do as my program evolves. I don't want to have to push a lot of type information around every time I make a design change, as I did in Mesa.] I'd like to see a single memory-safe language with a flexible, discretionary type system. During exploratory development, type errors could be discovered at only at run time. As parts of the system become mature and stable, the programmer could add type annoations to help the system find errors and to make the program more understandable to the reader. Type errors would be reported but could be ignored if the programmer chose to run a partially correct program. Ralph Johnson's typed-Smalltalk was supposed to do some of these things but I'm not sure how far he got with it. Re: garbage collection at low levels I've had good luck writing high-perfmance and real-time code in Self and Smalltalk. The time-critical low-level code is carefully written to pre-allocate all the storage it needs. Since it never allocates anything, this code never triggers garbage collection. I think it's better to do things this way than to open the door to the possibility of dangling references by having the programmer explicitely allocate and free storage. It would really be interesting to get some data on the reliability of "production" Smalltalk programs (i.e., programs that are pretty carefully tested before being given the the customer). -- John

3 2

Re: Where to use SELF - your opinion
by chambers＠cs.washington.edu 31 Oct '92

31 Oct '92

I agree with most of your comments, Peter. Certainly an interesting discussion. But one comment of yours I think should be clarified: > I was trying (in my mind) to separate implementation and language > characteristics. I do believe that it is intrinsic that a language without > static typing will require substantially more runtime overhead -- whether > space or time -- than one with static typing, to deliver the same average > level of performance. I think you're thinking of a kind of static typing that goes beyond mere protocol checking. Just knowing protocols often doesn't help performance. What the compiler needs is additional information about representations and particular implementations. Types in C++, e.g., specify both protocol and partial representation information. Ideally, the programmer should be able to say protocol to get type checking and safety, and add pragma-like annotations to variables or expressions or methods to convey additional restrictions to the compiler that are expected to improve performance. This strategy is in line with my goal of a "high-level systems programming language", where the semantics of the system is written at a high level, but the programmer could get control over the generated code through pragma-like things. As a test case, I'd like to be able to write the Self or Cecil implementation in such a language, both the low-level run-time and GC code and the high-level method lookup and compiler code. -- Craig

2 1

Re: Where to use SELF - your opinion
by chambers＠cs.washington.edu 31 Oct '92

31 Oct '92

John wrote: > I'd like to see a single memory-safe language with a flexible, > discretionary type system. During exploratory development, type > errors could be discovered at only at run time. As parts of the > system become mature and stable, the programmer could add type > annoations to help the system find errors and to make the program > more understandable to the reader. Type errors would be reported > but could be ignored if the programmer chose to run a partially > correct program. Ralph Johnson's typed-Smalltalk was supposed to > do some of these things but I'm not sure how far he got with it. I think you may be confusing TS with Cecil. Cecil does (or is intended to do) exactly what you describe. TS's incremental types are low-level performance enhancers and were unsafe as implemented. TS had signature types, but I think these must be added everywhere to use them. Its type inferencer was very slow. -- Craig

1 0

Re: Where to use SELF - your opinion
by John.Maloney＠Eng.Sun.COM 31 Oct '92

31 Oct '92

Peter: Perhaps I didn't make this clear, but the question I was answering was "Is it appropriate to use languanges like Self and Smalltalk-80 to deliver applications?" My arguments are based only on the properties of the programming languages, not on other practical concerns like whether commercially available implementations exist. If we stick to these assumptions, then you can't criticize the Self language on the basis of its current implementation. Yes, the current implementation does not use memory efficiently and suffers from unpredictable execution time and compile pauses. But these are not inherent defects of the language. All these problems can be solved using non-inlining dynamic translation (Deutsch-Schiffman style), with some loss of performance, and we are developing ways to use less memory and compilation time yet still achieve performance somewhere between Smalltalk and C/C++. Minor nit: You forgot to mention "unsafe pointer bugs" in your list of C/C++ costs. How would you compare C/C++ and Smalltalk in this framework? Is there any data available on the reliability of applications written in C/C++ versus those written in Smalltalk? -- John

2 2

Re: Where to use SELF - your opinion
by Randall.Smith＠Eng.Sun.COM 29 Oct '92

29 Oct '92

> > I would summarize your message as follows: > > C/C++: > costs: writing type declarations > finding memory management bugs > > benefits: > type errors caught at compile time > consistently fast execution > better documentation of programmer's intentions > > Self: > costs: much larger run-time memory requirements > much less predictable execution time > > benefits: > faster turnaround for source changes > no memory management errors > > (The fast turnaround problem is being addressed by the C++ vendors, as I'm > sure you noticed at OOPSLA.) > > Reading this balance sheet, I would conclude that C/C++ are good for some > things, and Self is good for other things. For production code, I think > C/C++ have clear advantages, especially since (as I *didn't* note above) > there is no commercial-style Self implementation (with documentation, > support, portability, etc.) > > Peter > I'd sort of agree, except here are some thoughts on the "type errors caught" and "better documentation of programmer's intentions" items. We could use the concreteness of Self to advantage. When compiling a method, all messages sent to self can be "type checked" as to wheather or not they will be understood. Also, the programmer can set values for temporary slots in a method at compile time - we do this as an informal programming practice today to represent illustrative values for temporaries. (We could imagine doing this for arguments as well.) This could be supported by the environment in an optional kind of way..."Warning: This method sends '<' to 'temp3' which currently contains a matrix. A matrix does not understand '<'. Click on 'abort,' or click on 'ok' to continue." The value of this is diluted slightly by dynamic inheritance, and the fact that Self is, after all, untyped...slots can hold anything anyway, and on occasion certainly will hold things very different than the compile-time value. As a motivational story: I thought the Smalltalk browser was improved somewhat when the support for "concrete class variables" was added: you could select a class variable in a method's text, say "inspect" .. and lo and behold, there was the actual class variable object in the flesh! I'm proposing that Self is in a position to do this for any send-to-self name that appears in a method, plus use the information to provide hints to the programmer when compiling. When it comes to intention declaration, this scheme could compete favorably with C's static type declaration scheme, which is kind of a bummer anyway (not optional, and can prevent reuse by its narrow view of type.)

1 0

Re: Where to use SELF - your opinion
by John.Maloney＠Eng.Sun.COM 28 Oct '92

28 Oct '92

We appreciate your interest in Self. Self in its current form is a vehicle for research in two areas: 1. programming language design 2. advanced language implementation techniques The current system is not intended to be the kind of product that anyone would depend on for producing commercial software. However, I don't see any deep impediments to producing a more memory-efficient version of the system capable of delivering speedy and reliable application programs, including programs such as MS Word. You might argue that compile-time type-checking in a requirement for production software. I disagree. People currently write application programs in type-unsafe languages such as C, C++, and assembler. They rely on extensive testing to find all the bugs that the compiler doesn't catch. Self is a pointer-safe language with automatic storage management: these two features eliminate a large class of extremely subtle errors. While Self does not detect type errors until run-time, when an error is encountered it is extremely easy to find and fix the bug. Furthermore, the rapid turn-around time possible with Self encourages more thorough testing in the early stages of development. A growing number of people are developing production software in Smalltalk, which also lacks compile-time type checking. The major drawbacks of using Smalltalk are speed and the limited number of Smalltalk system vendors. Our implementation techniques have addressed the speed problem with such languages, so I think Self (or Smalltalk) would be a great language for developing applications if only there were more vendors out there. I'll be interested to hear your reactions to these opinions. -- John

2 1

Where to use SELF - your opinion
by Johannes Ernst 27 Oct '92

27 Oct '92

Since a while I am looking at your SELF. Needless to say, that I am impressed. But I have one major question: What is you opinion where is the place for SELF in Software industry or what do your industry partners say about it. It is clear that SELF will not be the best joice when, say, MS Word has to be programmed. Nor am I sure whether it is at all possible to use it for a real-life product. In my opinion it works best in early specification/definition/ design-phases but then the question of the language for the final version has to be answered. Do you have any comments, I am very interested in this question. Johannes Ernst (ernst(a)lrs.e-technik.uni-erlangen.de) Institute for Computer Aided Circuit Design University of Erlangen-Nuremberg, Germany

1 0

Re: Weak Arrays
by David.Ungar＠Eng.Sun.COM 24 Oct '92

24 Oct '92

My own experience bears out the utility of these things, but I recall (from the days when I helped Frank Jackson design and implement the PPS collector) that somehow the existence of weak pointers cluttered up all the storage management code. Maybe we just didn't find the cleanest way to do it. Dave > From urs(a)otis.Stanford.Edu Fri Oct 23 09:45:08 1992 > Resent-Message-Id: <9210231641.AA00852(a)otis.Stanford.Edu> > Subject: Re: Weak Arrays > To: self-interest(a)myself.stanford.edu > Date: Fri, 23 Oct 92 17:45:34 BST > In-Reply-To: <Yetqg_u0=c_L9fuvAO(a)cello.ecn.purdue.edu>; from "William R > Burdick" at Oct 22, 92 10:01 pm > X-Mailer: ELM [version 2.3 PL11] > Resent-To: real-self-interest(a)otis.Stanford.Edu > Resent-Date: Fri, 23 Oct 92 9:41:24 PDT > Resent-From: Urs Hoelzle <urs(a)otis.Stanford.Edu> > > >mistakes, please) In ParcPlace's Smalltalk 4.0, they started using a gener- > >ational garbage collector (like Self does) and they included a new type of > >collection called a 'WeakArray,' which they use to solve exactly this type > >of problem. A weak array can have objects it references garbage collected > >right out from under it. Weak arrays are also periodically 'informed' when > >their elements die, so that you can do some cleaning up if you want. > > > >I'm sure this kind of thing isn't all that hard to implement (for all I know, > >Self may already have something like this). This would be a usefull addition > >to the wish-list, if it isn't there, though.. > > > > -- Bill > I've just implemented weak referees (WeakArray, WeakOrderedCollection etc) > and finalization (objects with a finalize method get sent finalize when they're > about to die) in my deferred reference counting collector. It took three days > to do (because I made some stupid mistakes). If you have a working garbage > collector that you understand and some spare bits in objects (you can usually > shrink the size field) it should be very easy to implement. > > I don't like the fact that the ParcPlace scheme > 1. indivisibly links WeakArrays & finalization > 2. only gives you WeakArray > > My scheme keeps weak references and finalization orthogonal, and allows > any object with indexed fields to have weak references if it uses a 'weakAtPut' > primitive in place of the standard weakAtPut. > > -- > Eliot Miranda, Lecturer email: eliot(a)dcs.qmw.ac.uk > Department of Computer Science ARPA: eliot%dcs.qmw.ac.uk(a)nsf.ac.uk > Queen Mary Westfield College UUCP: eliot(a)qmw-dcs.uucp > Mile End Road, LONDON E1 4NS Tel: 071 975 5229 (+44 71 975 5229) > Fax: 081 980 6533 (+44 81 980 6533) > >

1 0

Weak Arrays
by William R Burdick 23 Oct '92

23 Oct '92

On Oct 15, Ole Agesen replied to James Noble about using cannonical mirrors that constructing a mirror table in Self would make un-collectable objects in the table. (I'm using a primitive mailer, right now, so pardon the mistakes, please) In ParcPlace's Smalltalk 4.0, they started using a gener- ational garbage collector (like Self does) and they included a new type of collection called a 'WeakArray,' which they use to solve exactly this type of problem. A weak array can have objects it references garbage collected right out from under it. Weak arrays are also periodically 'informed' when their elements die, so that you can do some cleaning up if you want. I'm sure this kind of thing isn't all that hard to implement (for all I know, Self may already have something like this). This would be a usefull addition to the wish-list, if it isn't there, though.. -- Bill

2 1

re: Why Aren't Mirrors Canonical
by David.Ungar＠Eng.Sun.COM 15 Oct '92

15 Oct '92

Actually, I believe this is not the best way to go-- instead of putting state in and canonizing the mirrors, I think you should make a new object that contains the state that uses the mirror as a client. That way, other folks could write their own kinds of reflection and still use the base-level mirrors, which only contain protocol tied to the implementation. I hope this is clear-- Dave > R James Noble writes: > > Can anyone see any problems with this approach? Just out of (self) > > interest, why aren't mirrors canonical at the VM level? (speed?) > > There's no deep reason, we just didn't think it was necessary. But > you have a good point, we should probably change this. (By the way, > activation mirrors are canonical even today.) > > -Urs

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest October 1992