Post #110,827
7/22/03 5:56:45 AM
|
It is a fundamental difference
In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking. A major difference is flexibility.
In a MOO system I can always send a message to another Object, and if he doesn't know what to do with it he can forward it to someone else, or state that he doesn't understand it, look at the message and fiure out what to do, etc. It is up to the receiving object to decide what to do (not the compiler). Not only that, but the messages themselves can be stored, modified, etc. A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases. In fact Proxy objects are typically implemented like that. This is why distributed systems are so much simpler and cleaner in Smalltalk.
In a FOO system none of this possible. If the system is statically typed like Java, the compiler won' let me do this, and if the system is dynamically typed the call will fail. There are no messages that can be looked at, stored etc. This makes a FOO system much less flexible. For example to write a proxy in Java was a non-trivial task, they had to introduce special API's just to do this.
|
Post #110,832
7/22/03 6:28:12 AM
|
More Questions
bluke: In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking.
Can you give some concrete examples of the different ways of thinking? You mention distributed systems in your message. Any others?
bluke: A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases.
Is this a hard requirement? Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help?
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,838
7/22/03 7:23:18 AM
|
Re: More Questions
bluke: In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking.
Can you give some concrete examples of the different ways of thinking? You mention distributed systems in your message. Any others?
The ability to capture messages can be very useful. For example, undo/redo can be implemented using this (you trap every message sent and then you can either undo them or redo them quite easily as you have the original message). Logging security can be done with this facility as well.
The other place its shows is in areas like constructing new objects, conditional logic, etc.. In Java, you have a special keyword new and a constructor is called. In Smalltalk, all you do is send a message to the class object to create a new instance, perfectly logical. In Java if then else is a language construct. In Smalltalk it is a message send. When you think in terms of messages, it makes sense to send a message for everything including object creation and conditionals.
bluke: A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases.
Is this a hard requirement? Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help?
I am not an expert on type inference or Haskell, but I don't see how it would help. For example how would it handle a proxy object which can take any message and just forwards it somewehere? A static type system would just impose constraints. Of course, using DoesNotUnderstand is not the normal way of doing things in Smalltalk, so type inference might be useful in those other cases.
|
Post #110,840
7/22/03 7:54:36 AM
|
Re: More Questions
bluke: The ability to capture messages can be very useful. [undo/redo and logging mentioned]
I agree with the above, however ...
bluke: The other place its shows is in areas like constructing new objects, conditional logic, etc.. [...]
These examples are not so clear to me. Exactly how does the MOO-ness of a language contribute to object construction and conditional logic. For example, it is possible (although tedious) to do condition logic in Java (I've done it). However, most of the tedium would be aleviated by a simple anonymous closure syntax and relaxed type rules. Given those, I'm not sure how a message based system (ie. the ability to reify messages) would contribute.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,842
7/22/03 8:03:03 AM
|
It relates more to the mindset
In a FOO like language you are calling functions, therefore to call a function like new is not out of synch with the language, in a MOO language where everything is messages then everything is messages including object construction.
Again, this is more related to mindset and feel then anythng concrete.
|
Post #110,857
7/22/03 9:52:34 AM
|
In past discussions with Freep...
...one of the things that he talked about was the ability to use the mechanism to do some creative dispatching - specifically a mechanism that emulated multiple-dispatch or a Visitor type scenario.
|
Post #110,848
7/22/03 8:42:30 AM
|
Where does polymorphism fit in?
I had a brief discussion with a colleague today about what polymorphism was. It seems to me that a MOO-type language would handle polymorphism better because the determination about what type of object it is occurs at invocation time, whereas in a FOO-type language, this could not be so because the compiler needs to know the object type.
Except it doesn't. C++ is a FOO-type language, but it supports polymorphism.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #110,854
7/22/03 9:37:43 AM
|
Polymorphism via inheritance/interface
Static languages achieve their polymorphism either through a common base class or an interface implemented by the class. In dynamic languages, you just call the method and it either responds or it doesn't. This means that the Types in dynamic languages are much more fluid.
|
Post #110,881
7/22/03 11:19:07 AM
8/21/07 5:45:22 AM
|
Example
GLORP (Generic Lightweight Object Relational Persistence) allows you to specify queries as blocks of code.
db readManyOf: User where: [:user | user username = 'Blanchard' && user password = 'passW0rd' ].
given a table: CREATE TABLE USER (USER_NAME varchar(60), PASSWORD varchar(60))
how can this work?
The second argument to readManyOf:where: is a block of code. The block is evaluated with a MessageLogger standing in for user. ie
readManyOf: aClass where: aBlock
| aMessageLogger |
aMessageLogger := MessageLogger forClass: aClass
aBlock value: aMessageLogger.
The MessageLogger's doesNotUnderstand is examining the messages and producing an equivalent SQL translation based on some attribute to column mapping data it has. Since even the operators are actually messages, this is relatively straightforward to do. In Smalltalk that is.
This is just plain impossible in Java/C++/Object Pascal/etc.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,885
7/22/03 11:45:27 AM
|
Re: Example
GLORP [...]
Fascinating. I've thought about this problem, but assumed that the code block would have to be parsed. Executing the block and tracing the messages is a great example of "out of the box" thinking.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,883
7/22/03 11:28:48 AM
8/21/07 5:45:29 AM
|
Statically Typed Smalltalk
Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help? The project was called Strongtalk. [link|http://www.cs.ucsb.edu/projects/strongtalk/pages/index.html|http://www.cs.ucsb.e.../pages/index.html] "The Strongtalk system was developed in secret in the mid-90's by a small startup company. Before the Strongtalk system could be released, the company was acquired by Sun Microsystems, Inc. to work on the Java\ufffd virtual machine[1]. Development of Strongtalk was halted at that point, so very few people have ever had a chance to see the Strongtalk system in action." There is some work going on in VM optimization to duplicate this and provide optional static typing. Optional static typing makes optimization much easier and consequently the thing can run faster by taking advantage of more highly optimized routines. [1] - Fuckers.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,870
7/22/03 10:41:22 AM
|
Statically Typed MOO
bluke: [...]A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases. [...]
I've been thinking on this. Suppose our statically typed language had a rule that if a class implements "does_not_understand(m: METHOD; args: TUPLE)", then any method calls that would normally cause a compile error would instead be compiled to call "does_not_understand" instead, manifesting the data for the message. There would also have to be a "send(m: METHOD; args: TUPLE)" method defined in Object that would do the obvious.
Modern Eiffels already support the TUPLE for reflection and agents (i.e. lightweight anonymous closures), so I don't expect that the above would present any technical obstacles.
In other words, a statically typed MOO language is not inconceivable.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,872
7/22/03 10:47:24 AM
|
The other possible avenue
is something like what they are doing with AspectJ wherein you set up Aspects that will intercept (i.e. place themself before or after function calls). Apsects can be defined with wildcards, such that any method that matches the expression can be captured. Hence, you could set up an aspect to capture all function calls of a certain pattern - even if the pattern did not currently have a function that met that pattern.
|
Post #110,876
7/22/03 10:54:10 AM
|
Do you know how they do that?
After all in the end AspectJ compiles into regular Java.
|
Post #110,878
7/22/03 11:02:54 AM
|
Compiler generates the necessary calls
Currently doesn't handle calls to non-existent functions, but it does allow you to intercept function calls (before and after). Theoretically, you could extend this to look for calls to non-existent functions and have the AspectJ compiler trap them, but it does assume that you can determine that it doesn't exist at compile time.
Not saying that this is a clean solution, but if you were trying to add said capability onto a static language, it might help to look at how AspectJ goes about it's business of intercepting "messages".
|
Post #110,904
7/22/03 1:00:28 PM
8/21/07 5:46:10 AM
|
AspectJ is code generation
and thus violates Blanchard's law (Systems that require code generation lack sufficient power to tackle the problem at hand).
I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,915
7/22/03 2:19:07 PM
|
A comment and a question ...
Todd: I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either.AOP is still maturing and I don't think most people understand how to use it effectively. Besides, I have a theory that a highly dynamic language with good reflection will do the many AOP-ish things without the need for full AOP. In other words, there is less need in Smalltalk for AOP. Now for the question regarding Blanchard's law ... In Ruby, we can write ... class Point\n attr_accessor :x, :y\n ...\n end which will generate four methods (getters and setters for both x and y). It is essentially the same as writing ... class Point\n def x\n @x\n end\n def y\n @y\n end\n def x=(value)\n @x = value\n end\n def y=(value)\n @y = value\n end\n ...\n end Does this count as code generation?
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,919
7/22/03 2:37:04 PM
8/21/07 5:46:27 AM
|
Not really
the code is trivial and amounts to naked attributes.
C++ templates OTOH do count - as does Java RMI/C++ CORBA (generation of proxies as a standard development technique - primarily required to satisfy the compiler in a FOO environment).
My GLORP interface library will create missing attributes and accessors based on schema requirements - but this is hardly "code generation" - rather its dynamic object reshaping.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,932
7/22/03 3:57:21 PM
|
Pushing the limits of Blanchard's Law
As you might guess, I like to push the limits a bit. Hope you don't mind. (I'll even tie this question back to message based OO). I hadn't heard of Blanchard's law, so a google search brought up this ... Yeah but it [dynamic Java proxies] breaks Blanchard's law of code generation. Dynamic proxies basically construct classes and load them on the fly by generating code to forward interface calls to implementations. So the system relies on code generation (binary code generation in this case) to do its thing. -- tblanchard@mac.com ([link|http://lists.xml.org/archives/xml-dev/200210/msg01206.html|http://lists.xml.org...210/msg01206.html]) I'm assuming this is the Blanchard for whom the law is named. Keeping the above quote in mind, consider the following code ... class SlowProxy\n def initialize(target)\n @target = target\n end\n def method_missing(sym, *args, &block)\n @target.send(sym, *args, &block)\n end\nend It uses method_missing (Ruby's equivalent of doesNotUnderstand) to forward messages to the proxy target. It works great, but is a bit slower than a hand written proxy because :method_missing overhead. We can rewrite it slightly to do the following ... class FastProxy\n def initialize(target)\n @target = target\n end\n\n def method_missing(sym, *args, &block)\n define_forwarding_method(sym)\n self.send(sym, *args, &block)\n end\n\n def define_forwarding_method(sym)\n self.instance_eval %{\n def #{sym.to_s}(*args, &block)\n @target.#{sym.to_s}(*args, &block)\n end\n }\n end\nendThe first time a method is called on the proxy, it dynamically defines a specific forwarding method of that name. Further calls of that same method will no longer go through the :method_missing mechanism. The code generation piece is quite similar to that in the attribute example earlier. But since this dynamic proxy generates method definitions on the fly (just as the Java version does), does that mean this code runs afoul of Blanchard's law as well? It would seem it does. Seems inconsistent to me. --
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,933
7/22/03 4:09:32 PM
|
I don't think the basic argument is so much
against code generation - especially runtime code generation - so much as it is about using code generation at compile time to trick the compiler into bypassing the static type checking. Smalltalk can generate code on the fly as well, and methods can be attached dynamically in much the same way that you showed in Ruby.
One question, though. Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing. Just thinking that same methods are temporary methods (closures or delegates), that have a limited lifetime or change according to the context.
|
Post #110,940
7/22/03 4:35:10 PM
|
Re: I don't think the basic argument is so much
ChrisR: [...] as it is about using code generation at compile time to trick the compiler into bypassing the static type checking
But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages.
Oh well. Moving on.
ChrisR: Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing.
Yes. remove_method(symbol) will remove it from the current class, but leaves any definitions in the super classes intact. undef_method(symbol) will remove it from the entire class hierarchy.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,946
7/22/03 5:03:54 PM
|
Should probably let Todd defend his Laws....but.... :-)
But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages. I'm guessing, but I don't think the question is whether code generation (or macros) is inherently and evil in and of itself - it can be a useful technique in limited circumstances. The problem is when you begin to rely on such techniques as a workaround to the Type system - and yes it's biased against Static Typing because ST tends to want to prevent you from doing things. In the case you cite, you could have handled the missing_method with any number of techniques - including generating a function on the fly.
|
Post #110,948
7/22/03 5:14:31 PM
|
Still sounds arbitrary ...
ChrisR: and yes it's biased against Static Typing because ST tends to want to prevent you from doing things.
So it is OK to do if you don't need it. But if it you do need it, then it is not ok.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #110,951
7/22/03 5:20:45 PM
|
On par with "Eval"
Which was how we got into this thread in the first place. Eval and Dynamic Code generation are powerful features. The problem is that when you start requiring these facilitaties to get around the barrier put up by the compile (aka Static Typing), then they are no longer luxories. It is indicative of the fact that you are fighting the language in order to achieve your ends.
Of course, it's the Blanchard Law, so I'll let him be more specific about the intents. Just trying to further the conversation. :-)
|
Post #110,963
7/22/03 6:10:00 PM
8/21/07 5:51:08 AM
|
Well said
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,964
7/22/03 6:11:20 PM
8/21/07 5:51:13 AM
|
No its not
Your example does not rely on code generation to work - it uses it as an optimization. You could (and do) make it work without the code generation.
There's the razor.
If the only way to accomplish a task is code generation - then the tool is not appropriate for the task.
As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,982
7/22/03 7:48:18 PM
|
Ok, I get it.
I was trying to use the law in determining when code generation is a good idea. That's not what the law is for. It is a measure of the power and/or flexibility of your implementation language.
I'm ok with that.
Todd: As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P
Heh, clever line. :-)
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van As to whether this is designed by me to punish static languages. Turnabout is fair play. :-PEmde Boas)
|
Post #110,987
7/22/03 8:17:05 PM
8/21/07 5:51:33 AM
|
Yep
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #110,937
7/22/03 4:28:15 PM
|
Oh yeah
I had dinner with THAT Blanchard once. Much clearer thinker than our Todd.
:D
I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
|
Post #118,380
9/21/03 5:20:53 PM
|
What is your reasoning for this "law"?
Sorry that I am coming to this thread late...
When I hear something like that I automatically think that the underlying reasoning is sort of like that which lies behind using structured flow control mechanisms rather than goto. Namely that the structured mechanisms make it easier to express your thoughts in ways which you or someone else can figure out later.
For instance this is why I prefer to see closures where eval could do the job. And I have heard similar reasoning from Paul Graham on why it is better to use macros rather than eval as well.
Was that your reasoning, or did you have a different motivation?
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,427
9/22/03 10:32:55 AM
|
OT re: coming to this thread late
Man, this is going to be like when Scott put in the [link|http://z.iwethey.org/forums/actions/content/random|Random Post] link.
===
Implicitly condoning stupidity since 2001.
|
