gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (09/24/88)
In article <1642@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: [ stuff deleted ] > A classic example of this is types. Some systems mark the elements > on the stack with their type (e.g. PostScript), thus requiring > run time type checking. This is expensive and since it gives > dynamic binding, not good. Hubert Matthews suggested that these ^^^^^^^^^^^^^^^^^^^^^^^^^ > wonder forth chips should be extended to have an extra stack for > this purpose (the do it in hardware approach), this certainly > doesn't deal with the dynamic binding issue though and seems to > be rather a waste of memory and chip space (yes I suppose forth > has plenty of both to waste...) [ more deleted ] >Regards, > >===Fraser WAIT WAIT WAIT WAIT. Just one minute Fraser. While you have had some valid ideas before, this time I think you've made a mistake. Why is dynamic binding bad? You seem to say that besides the issue of run time performance, tagging data elements (for run time checking) gives you the bad feature of dynamic binding. Well tell that to all the users of Smalltalk (which is why I've cross posted this there). No, wait, I just did. ;-) Dynamic binding is GOOD. This is what enables Smalltalk to do some of the things it does - dynamic binding. While it is true that a majority of the "calls" in Smalltalk could use static (compile time) binding, without dynamic binding, we might as well use Ada. In order to truly be an object oriented language, you need dynamic binding - static binding just does not do. Adding object-oriented features to Forth would make it more powerful and easier to use, two of the goals that you have in mind behind your Forth preprocessor. (Note that this will not make Forth and object oriented language in the same sense that Smalltalk is, rather it would simply be a language with object oriented feature, but it could be a start - and Forth and Smalltalk both have a lot in common in many of their design philosophies) BTW: I am currently playing with a modification to a Forth-like language that has a clean implementation of object-oriented message passing, written entirely in C for Unix machines. Maybe I'll even finish it some day. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
orr@cs.glasgow.ac.uk (Fraser Orr) (09/29/88)
In article <498@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >WAIT WAIT WAIT WAIT. Just one minute Fraser. While you have had some valid >ideas before, this time I think you've made a mistake. Why is dynamic >binding bad? There are some things for which a late binding is useful. But general dynamic binding is terible. I want programs to be transparently clear (or as much so as is possible) and dynamic binding is one of the worst types of hidden dependency I know of. Let me give an example. declare a ; # Declare a name a, this is currently unbound procedure b declare c ; # Declare this as a local variable begin c=a ; Process (c) ; end ; procedure d declare A ; # Misstype this, it is supposed to be 'a' begin a=12 ; DoOtherThings () ; end ; (Appoligies, I would have written this in Smalltalk, but my Smalltalk is not really good enough) Now with this fairly straightforward typing error, we have produced a virtually undetectable bug. If 'a' is supposed to be bound to a procedure that returns an integer, it will apparently become a procedure that returns only 12 (only after procedure d has been called). Now if a is a string, since the bindings all change dynamically, this will set off a chain of errors too large to comprehend! Now I know that dynamic binding has advantages, but I think that if you required explicit marking by the programmer that this identifier would have a variable binding (perhaps even stating the set of possible values that it could take) then you'd be onto a winner. This is in fact the approach taken in C++. Where the binding is essentially static, but can be made late by the use of "virtual" functions. Let me reitterate. Use the best tool for the job. Static binding is best in all cases except for its usefulness in inheritance. [Stuff about how static binding is not good enough for an OO language but useful in a language with OO features, deleted] I think that it has yet to be establised that object oriented languages are the best thing. I like object oriented features and use them frequently, but I can't see why people have taken it to the extremes that has happened in Smalltalk. OO programming is a good idea, but use it where it is appropriate. Modeling integers as objects that accept messages etc is inappropriate. This should be modeled in the way in which it is used, that is, as a mathematical object. >BTW: I am currently playing with a modification to a Forth-like language >that has a clean implementation of object-oriented message passing, written >entirely in C for Unix machines. Maybe I'll even finish it some day. You might be interested to read "a User Interface Toolkit in Object Oriented PostScript" by Densmore et al, inComputer Graphics Forum, vol 6, no 3, pp 171-179, Sept 87. In which the authors describe an object oriented feature they added to the PostScript language. >Glenn Andreas Regards, ===Fraser.
ns@cat.cmu.edu (Nicholas Spies) (10/02/88)
In article <1678@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: >I think that it has yet to be establised that object oriented languages >are the best thing. I like object oriented features and use them >frequently, but I can't see why people have taken it to the extremes >that has happened in Smalltalk. OO programming is a good idea, but use >it where it is appropriate. Modeling integers as objects that accept >messages etc is inappropriate. This should be modeled in the way in >which it is used, that is, as a mathematical object. It seems that you would prefer to have a hodge-podge rather than a consistant application of the object-oriented paradigm? Sending messges to integers makes a lot of sense because coersion (short, long, float) is handled in the same matter as the rest of the Smalltalk system. Anyway, real implementations of Smalltalk don't necessarily follow the Smalltalk virtual machine to the letter, in that messages are not instantiated as objects unless errors are encountered and some byte code instructions may in fact be compiled to machine code. Forth is also a "neat" language because it too has a consistant paradigm, using pointers to fold the system up so that it consumes minimal resources. Surely, there is a great value to being able to define your own HL application languages, even if the medium is what you contempuously refer to as a MLL. There is also a great deal to be said about being able to deal with the innards of the language (both in Smalltalk and Forth) rather than programming with a black box from one or another mega-corporation. (Smalltalk may be the product of a mega-corporation, but it is not a black box). Forth is not the "toy" language you make it out to me: a couple of years ago Beth Rather of Forth Inc gave a paper at the Rochester Forth Conference about their development of an integrated computer system for an airport that networked several Vax's, several 100 8086 boards and many thousands of sensors -- with all of the software written in Forth. They got the contract because the previous vendor (who had bought the hardware) couldn't deliver. As I recall, they had a team of 15 programmers... C++ may be great for C programmers who are suddenly discovering the light about OO programming--and have bought into AT&T's vision of the world, but I thought that Objective C was supposed to be even better. I guess when the NeXt machine is revealed to the world we'll hear more about that... -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/05/88)
<<Why is dynamic binding bad?>> Because of the run-time overhead only, NOT because: <...general dynamic binding is... one of the worst types of hidden dependency I know of. Let me give an example. (example deleted)... Now with this fairly straightforward typing error, we have produced a virtually undetectable bug. If 'a' is supposed to be bound to a procedure that returns an integer... (but is actually) a string, since the bindings all change dynamically, this will set off a chain of errors too large to comprehend!> (It's so easy to detect the Smalltalk detractors who are not actually Smalltalk users!) I'm not sure what you're argument is here. Any reasonable combination of dynamic binding, message passing, and incremental compilation should have no trouble detecting the compile-time inconsistency. Although your example is rather difficult to envision as object-oriented code, I think Smalltalk would catch your "typing error" at compile time. If you are referring to run-time behavior (that is, if you told the compiler to accept unbound selectors), the combination of message sending and dynamic binding (often referred to as "polymorphism") causes a rather simple-to-debug run-time error. In your case, the String object would report that it does not understand how to perform the Integer message it just received. Of course, if you want to guarantee that both Strings and Integers respond to a given set of messages, it is quite simple to override the default error handling to enable coercion. (This "lazy mutation" is how Tektronix Smalltalk allows you to change a class definition, and have that change propagate to existing instances.) Hybrid languages, like Ada, C++, and Modula-2 require you to overload the operator for each class or type. Can you spell "maintenance headache"? <...I think that if you required explicit marking by the programmer that this identifier would have a variable binding (perhaps even stating the set of possible values that it could take) then you'd be onto a winner... Static binding is best in all cases except for its usefulness in inheritance...> It's not really useful with inheritance if the language employs "copy down" as opposed to "look up" inheritance. Where it is useful is in combination with true message passing, when it can implement polymorphism. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::