Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!hplabs!parcvax!susser From: susser@parcvax.UUCP Newsgroups: comp.lang.smalltalk Subject: Re: Translating Smalltalk Message-ID: <346@parcvax.Xerox.COM> Date: Wed, 10-Jun-87 14:32:54 EDT Article-I.D.: parcvax.346 Posted: Wed Jun 10 14:32:54 1987 Date-Received: Sat, 13-Jun-87 08:57:54 EDT References: <245100008@orstcs> Reply-To: susser@parcvax.xerox.com.UUCP (Josh Susser) Organization: Xerox Special Information Systems, Pasadena CA Lines: 44 Keywords: caching [burp] In article <245100008@orstcs> budd@orstcs.cs.ORST.EDU (Tim Budd) writes: > >The real problem in translating Smalltalk is the notion of Blocks. Blocks >must carry with them the context in which they were defined, and there is >no way to easily simulate this dynamic binding is a staticly scoped >language like C. (This is a classic funarg problem). > >Which leads one to wonder if a language similar to Smalltalk, but without >blocks, could be defined. I think yes. And if this were done, could you >build interpreters/compilers and generate efficient machine code without >sacrificing the nice features of Smalltalk; i.e., experimental programming, >rapid prototyping, reusability. I think yes. Finally, if you did this, >could you use optional declarations of object class to speed things up by >eliminating the method lookup; (the idea being that you produce and debug >your code, then insert declarations to speed it up); I think yes. > >Watch this space for future announcements. > >--tim budd, oregon state university, budd@oregon-state.csnet (Apply flame retardant here...) All of us who have experience with Smalltalk acknowledge the need for better performance from Smalltalk systems. But I think there is an undesirable trade-off of functionality for performance with the strategy you describe. Sure, you can build Smalltalk without blocks, but the ability to abstract code as data is an extremely powerful tool that makes all sorts of things possible, and Smalltalk would not be nearly as wonderful without it. Try thinking about Lisp without function variables. Likewise for static-typed early-bound method lookup. This strategy will indeed give you some performance increase, but it destroys the ideologically pure polymorphic nature of Smalltalk. With a completely late bound system, the level of interface is message protocol. A method doesn't care what kind of object it is sending a message to, as long as it can respond properly. I could build a ByteArray subclass LargeFloat that acts like an infinite-(or nearly)-precision Float, and it would work everywhere that Float would. Once you have early-binding, all bets are off. Somebody is going to early bind some methods that refer to Floats, and my new class won't work. There is a huge difference between a polymorhic system and a mostly polymorphic system. I think we can do better that what you propose. Much of Smalltalk's apparently bad performance has to do with processor technology. A 68000 has a great deal of support for running procedural languages, but none for late-bound ones. Even so, a 68000 runs Smalltalk fairly well. Imagine the performance one could get from a processor designed to run a language like Smalltalk. Fortunately, there are a number of people working on building machines to do just that. It used to be that it was important to have code that ran blindingly fast, even if somebody had to spend two years writing it, because processor power wasn't that great. Now, as processors become more powerful, it is becoming more important to write code quickly even if it runs a little slower. As processor speed approaches the unbelievable, programming speed will become more important. If I can write something in Smalltalk in a month that runs at speed X and you can write something in C in a year that runs at speed 2X then I win because everyone is going to be buying my program for 11 months before yours is even done. At least that's how it would work in an equitable world. Flames gladly accepted. --Josh Susser Susser.pasa@Xerox.com susser@parcvax.xerox.com "My people are the people of the dessert," said T.E.Lawrence, picking up his fork.