First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
ha ha, I hear you
Annotations are one of the things which I don't find beautiful, though they are useful.
The question is, though, how do we do what annotations do without annotations?
:) Russell
On 26/12/2010, at 7:12 AM, Jan-Paul Bultmann wrote:
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
I didn't say that they are useless :D But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors. They also create a problem that is best known form XML, what is property and what is content. Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information. They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them. Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about. When describing a Object we can no longer say it is composed of slots, and those slots hold information. We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
Cheers Jan On Dec 26, 2010, at 8:21 AM, ungar@mac.com wrote:
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
All of my least favorite Self features have the same cause - strings or numbers where objects would work better. Certainly annotations are a more "proper" way of doing what was a "pun" in Self 1 and 2 using parent priorities, but I would be happier if these annotations were full Self objects instead of strings that have to be parsed in wierd way to extract the information we need from them.
Another place with this problem is the parameters of fail blocks. In fact, this made Ole Agesen's application extraction scheme a lot less useful since primitive handling code always had to include fancy string methods. Replacing this parsing with a small set of exception objects would be a huge improvement, in my opinion.
The layout stuff in Morphic used to (I haven't looked since 1995) encode stuff like left/middle/right as 1, 2 or 3. This required lots of tests that would go away if simple alignment objects were used instead.
About the annotations, in my tinySelf 0 I just had a special constant slot with the value for the object annotation, but never did come up with a good scheme for the slot annotations.
-- Jecel
On Dec 26, 2010, at 5:12 AM, Jan-Paul Bultmann wrote:
I didn't say that they are useless :D
No, but you implied that when you said that you hated them and that their functions could be performed by invisible slots, whatever that means.
But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors.
Sorry, but everything happens in the VM: slots, methods, method invocation, and objects. Resend, too. So, I don't see why annotations are any more magical than anything else.
They also create a problem that is best known form XML, what is property and what is content. Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information. They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them.
When you speak of property and content, you embrace a dichotomy that is context-relative without owning up to its multiordinality. In other words, just as with deep-copy, what is property vs content depends on one's purpose at the moment. Methods already contained lots of "meta information", for instance temporary variable names, indentation, etc. etc. Yes, it would be nice to handle all of that better--see Simonyi's intentional programming--BUT, in Self there is a clear distinction: what we thought of as a method--remember we started from Smalltalk--was in the method; what we thought of as in the environment (including the transporter) went into the annotations. When I read your remarks, I feel that you haven't thought about as many scenarios, or as many previous systems, as one would have to do to understand the design space and all of the tradeoffs involved. Many of my own designs for, say the transporter, seemed great for the first few objects saved, but failed miserably later on.
Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about.
When I read the above, I wondered if perhaps you had not heard of the principle of progressive disclosure. Once designs a conceptual system so it can be learned in pieces. In the case of Self, there is a run-time story of objects and slots. No annotations. They have no effect on the dynamic behavior of base-level programs.
Then, as you learn more, you can encounter object and slots comments, and finally the transporter.
I understand simplicity differently than you do. Following Shannon's information theory, simplicity has to do with how much once has to hear, given one's prior (i.e. what you know already), to understand a system. Again, I would love to see a system that did all Self does, without something like annotations. Design one, make it work, make it work on the scale of programs that Self does, and I would be delighted to read about it.
When describing a Object we can no longer say it is composed of slots, and those slots hold information.
Yes we can, when describing its dynamic behavior. You seem to not understand or to discount the idea of context.
We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.
Yes, when it's time to file something out, or name it.
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No. But I'm afraid that I just don't resonate with any of these criticisms of yours.
Take care,
- David
Cheers Jan On Dec 26, 2010, at 8:21 AM, ungar@mac.com wrote:
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
David,
I would be interested in a bit more discussion on the below except. It touches on something that has been bugging me lately in thinking about languages and systems.
1) I started with Smalltalk and generally still like it bee than almost any other system. 2) I have been using Ruby lately and find I like it better for the following reasons: a) There is more in the "language" and less in the "library". b) There is a way to say things like "add this method to that class" that are library calls in Smalltalk that make metaprogramming a natrual part of the language rather than calling APIs that are not as well covered. c) The idea that you assemble an "image" at run-time from source files lends itself to better versioning and partitioning of components. In particular when the components are developed independently by different groups.
While it could be said that all of the above can be accomplished with Smalltalk, and for the most part has, having it "in the language" feels very different. At the same time the ability to manipulate "code" as objects generated the best tool suite in 50 years, because it was easy to add to and customize with the same tools as was used for system development.
There were some wonderful tools built for Smalltalk, browsers that supported good commenting style while allowing scrolling of text, browsers that performed versioning and allowed CM type history operations, and lots of refactoring tools. The fact that good Smalltalk developers thought about manipulating objects when programming and when running code is a huge difference from editing text files, but never quite got to the maturity of editing source code. In particular when trying to package and reuse capabilities.
What was needed almost seems like a unified multi-user environment with CM aspects and run-time aspects and a good packaging approach to allow reuse of parts of the system, rather than a continued single-user focus. Or it might be enough to be able to really package up objects/behavior and safely introduce it into a new system?
Any comment?
Michael
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No. But I'm afraid that I just don't resonate with any of these criticisms of yours.
Take care,
- David
Michael,
Cannot comment on Ruby, haven't used it.
So many systems follow the Unix notion that everything is fundamentally a linear stream of bytes. It was fine for PDP-11s, but to me it seems very outmoded. I always liked the more physical metaphors that Randy pioneered. So, yes, a unified multi-user environment working on the physical stuff of software. Kansas was a start. Change management (always be suspicious of a term like that, "management" means that we don't really know enough about what we are talking about to use a real word) for me would be best handled with an Us-like system, in which everything, everything, is perspective-dependent along an arbitrary multiplicity of perspectives. That doesn't solve the problem, merely provides a nice general framework in which to embed various dimensions of reflection, versions, authority, security, etc.
- David
On Dec 27, 2010, at 7:18 PM, Michael Latta wrote:
David,
I would be interested in a bit more discussion on the below except. It touches on something that has been bugging me lately in thinking about languages and systems.
- I started with Smalltalk and generally still like it bee than almost any other system.
- I have been using Ruby lately and find I like it better for the following reasons:
a) There is more in the "language" and less in the "library". b) There is a way to say things like "add this method to that class" that are library calls in Smalltalk that make metaprogramming a natrual part of the language rather than calling APIs that are not as well covered. c) The idea that you assemble an "image" at run-time from source files lends itself to better versioning and partitioning of components. In particular when the components are developed independently by different groups.
While it could be said that all of the above can be accomplished with Smalltalk, and for the most part has, having it "in the language" feels very different. At the same time the ability to manipulate "code" as objects generated the best tool suite in 50 years, because it was easy to add to and customize with the same tools as was used for system development.
There were some wonderful tools built for Smalltalk, browsers that supported good commenting style while allowing scrolling of text, browsers that performed versioning and allowed CM type history operations, and lots of refactoring tools. The fact that good Smalltalk developers thought about manipulating objects when programming and when running code is a huge difference from editing text files, but never quite got to the maturity of editing source code. In particular when trying to package and reuse capabilities.
What was needed almost seems like a unified multi-user environment with CM aspects and run-time aspects and a good packaging approach to allow reuse of parts of the system, rather than a continued single-user focus. Or it might be enough to be able to really package up objects/behavior and safely introduce it into a new system?
Any comment?
Michael
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No. But I'm afraid that I just don't resonate with any of these criticisms of yours.
Take care,
- David
On 28.12.2010, at 03:43, ungar@mac.com wrote:
On Dec 26, 2010, at 5:12 AM, Jan-Paul Bultmann wrote:
I didn't say that they are useless :D
No, but you implied that when you said that you hated them
Just because you hate to go to the dentist, doesn't mean you shouldn't :)
and that their functions could be performed by invisible slots,
That was not a solution proposal merely a stylistic element of the cry. To show that I had preferred anything else, as long as it was based on existing concepts.
whatever that means.
But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors.
Sorry, but everything happens in the VM: slots, methods, method invocation, and objects. Resend, too. So, I don't see why annotations are any more magical than anything else.
They also create a problem that is best known form XML, what is property and what is content. Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information. They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them.
When you speak of property and content, you embrace a dichotomy that is context-relative without owning up to its multiordinality. In other words, just as with deep-copy, what is property vs content depends on one's purpose at the moment. Methods already contained lots of "meta information", for instance temporary variable names, indentation, etc. etc. Yes, it would be nice to handle all of that better--see Simonyi's intentional programming--BUT, in Self there is a clear distinction: what we thought of as a method--remember we started from Smalltalk--was in the method; what we thought of as in the environment (including the transporter) went into the annotations. When I read your remarks, I feel that you haven't thought about as many scenarios, or as many previous systems, as one would have to do to understand the design space and all of the tradeoffs involved. Many of my own designs for, say the transporter, seemed great for the first few objects saved, but failed miserably later on.
Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about.
When I read the above, I wondered if perhaps you had not heard of the principle of progressive disclosure. Once designs a conceptual system so it can be learned in pieces. In the case of Self, there is a run-time story of objects and slots. No annotations. They have no effect on the dynamic behavior of base-level programs.
Then, as you learn more, you can encounter object and slots comments, and finally the transporter.
Yes, but those concepts aren't based on what you learned before.
I understand simplicity differently than you do. Following Shannon's information theory, simplicity has to do with how much once has to hear, given one's prior (i.e. what you know already), to understand a system. Again, I would love to see a system that did all Self does, without something like annotations. Design one, make it work, make it work on the scale of programs that Self does, and I would be delighted to read about it.
When describing a Object we can no longer say it is composed of slots, and those slots hold information.
Yes we can, when describing its dynamic behavior. You seem to not understand or to discount the idea of context.
We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.
Yes, when it's time to file something out, or name it.
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
To me "the language" is the minimal set of concepts everything else can be build of. Like the 7 base functions and s-expressions in lisp.
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No.
C'mon I love self, I admire what you have created and the soul and ideals the system has, In a world where everybody tries to stamp computer science as a branch of mathematics and cold hearted logic, self is one of the few things with humans in mind. I didn't want to attack you or self, but have the feeling that it maybe came across like that, if so, I am sorry.
But I'm afraid that I just don't resonate with any of these criticisms of yours.
You don't have to resonate with them, you shouldn't because you probably spend a lot of time with the concepts I am criticizing and if you shared my point of view you had already thought that yourself and done something about it. So there was nothing left for me to criticize :) ( hope that makes sense). So what looks to you as a perfect solution might not be optimal from my perspective since I am focussing on other points. It is not that I saw annotations and thought, man they suck, but I saw that they were developed together with the transporter and though, writing a program should not alter the whole system.
Point is. If we all had the same view of an Ideal programming world I'd be rather boring.
And on why I choose to use the word "hate". To me annotations feel like a white flag. The confession that prototype based languages are not up to class based ones when it comes to real live problems. Sure they are as good at runtime, but of course they are, at runtime the two families look almost the same. The goal of prototypes was to feel more natural to the programmer, wasn't it? If it then forces him to do the whole thing he needs to do in a class based language, what's the point. So there you have it, I hate them because they broke my heart :) And since I suppose, I am by far one of the youngest here (20) one might forgive me a bit of fire and passion ;)
Take care,
- David
You too :) Jan
Cheers Jan On Dec 26, 2010, at 8:21 AM, ungar@mac.com wrote:
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
On Dec 28, 2010, at 7:11 AM, Jan-Paul Bultmann wrote:
On 28.12.2010, at 03:43, ungar@mac.com wrote:
On Dec 26, 2010, at 5:12 AM, Jan-Paul Bultmann wrote:
I didn't say that they are useless :D
No, but you implied that when you said that you hated them
Just because you hate to go to the dentist, doesn't mean you shouldn't :)
"Should" is a problematic word for me, unless accompanied by an "if". Without an "if" it reflects an unstated agenda that the speaker is not taking responsibility for. "You should go to the dentist" hides an agenda. "If you want your teeth to last, you should go to the dentist" makes the agenda clear. If you want a stratification between base-level object-oriented programming (as I understand it) and meta-level facilities needed to support an IDE, you should include a means to associate meta-level data with your objects and slots. These are called "annotations" in Self.
and that their functions could be performed by invisible slots,
That was not a solution proposal merely a stylistic element of the cry. To show that I had preferred anything else, as long as it was based on existing concepts.
What you call "existing concepts" as far as I can tell (object, slot, inheritance) were designed precisely to be a minimal set needed for execution. Why would one expect that a set of concepts designed for program execution would also fit the task of organizing the elements of a program to fit a human mind?
whatever that means.
But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors.
Sorry, but everything happens in the VM: slots, methods, method invocation, and objects. Resend, too. So, I don't see why annotations are any more magical than anything else.
They also create a problem that is best known form XML, what is property and what is content. Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information. They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them.
When you speak of property and content, you embrace a dichotomy that is context-relative without owning up to its multiordinality. In other words, just as with deep-copy, what is property vs content depends on one's purpose at the moment. Methods already contained lots of "meta information", for instance temporary variable names, indentation, etc. etc. Yes, it would be nice to handle all of that better--see Simonyi's intentional programming--BUT, in Self there is a clear distinction: what we thought of as a method--remember we started from Smalltalk--was in the method; what we thought of as in the environment (including the transporter) went into the annotations. When I read your remarks, I feel that you haven't thought about as many scenarios, or as many previous systems, as one would have to do to understand the design space and all of the tradeoffs involved. Many of my own designs for, say the transporter, seemed great for the first few objects saved, but failed miserably later on.
Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about.
When I read the above, I wondered if perhaps you had not heard of the principle of progressive disclosure. Once designs a conceptual system so it can be learned in pieces. In the case of Self, there is a run-time story of objects and slots. No annotations. They have no effect on the dynamic behavior of base-level programs.
Then, as you learn more, you can encounter object and slots comments, and finally the transporter.
Yes, but those concepts aren't based on what you learned before.
If you say so. When I say that an annotation describes an object for the programming at the meta-level, and that an annotation is composed of objects, it reuses the notion of object. Of necessity it introduced the notion of meta-level. Systems that you may be more used to, tend to not even try to have a programming environment but just rely on text files. Or, in the case of Smalltalk, lack stratification and so give up many advantages. (See the paper by Gilad Bracha and me on reflection.)
I understand simplicity differently than you do. Following Shannon's information theory, simplicity has to do with how much once has to hear, given one's prior (i.e. what you know already), to understand a system. Again, I would love to see a system that did all Self does, without something like annotations. Design one, make it work, make it work on the scale of programs that Self does, and I would be delighted to read about it.
When describing a Object we can no longer say it is composed of slots, and those slots hold information.
Yes we can, when describing its dynamic behavior. You seem to not understand or to discount the idea of context.
We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.
Yes, when it's time to file something out, or name it.
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
To me "the language" is the minimal set of concepts everything else can be build of. Like the 7 base functions and s-expressions in lisp.
Again, where is the programming environment? Or if there is one, where is the stratification?
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No.
C'mon I love self, I admire what you have created and the soul and ideals the system has, In a world where everybody tries to stamp computer science as a branch of mathematics and cold hearted logic, self is one of the few things with humans in mind. I didn't want to attack you or self, but have the feeling that it maybe came across like that, if so, I am sorry.
Thank you. In the doing of Self, I learned many things, and tried to put them into the papers. It was disheartening to read your message because I would rather people learn from the work as opposed to spreading thoughts that would, in my view, lead to others repeating my own mistakes.
But I'm afraid that I just don't resonate with any of these criticisms of yours.
You don't have to resonate with them, you shouldn't because you probably spend a lot of time with the concepts I am criticizing and if you shared my point of view you had already thought that yourself and done something about it. So there was nothing left for me to criticize :) ( hope that makes sense). So what looks to you as a perfect solution might not be optimal from my perspective since I am focussing on other points. It is not that I saw annotations and thought, man they suck, but I saw that they were developed together with the transporter and though, writing a program should not alter the whole system.
But I don't believe you were simply focussing on other points. I believed you to be ignoring fundamental tradeoffs, and heading down a blind alley. I wanted to head off anyone going in that direction. That was the point of the transporter paper.
Point is. If we all had the same view of an Ideal programming world I'd be rather boring.
And on why I choose to use the word "hate". To me annotations feel like a white flag. The confession that prototype based languages are not up to class based ones when it comes to real live problems. Sure they are as good at runtime, but of course they are, at runtime the two families look almost the same. The goal of prototypes was to feel more natural to the programmer, wasn't it? If it then forces him to do the whole thing he needs to do in a class based language, what's the point. So there you have it, I hate them because they broke my heart :) And since I suppose, I am by far one of the youngest here (20) one might forgive me a bit of fire and passion ;)
I don't think that the Self environment forces one to "do the whole thing he needs to do in a class-based language". The statement itself is not very precise. If you want to be understood, you should try to write a bit more carefully. (same for "hate") I benefitted a lot from Korzybski's Science and Sanity, but if you google "e prime" you can find a lot on the web.
I love youth, fire, and passion. What worries me is the power of an idea, because I have seen some ideas lead to wasted effort, or even destructive outcomes in some cases. Sometimes, even with the best of intentions.
When Ritchie invented C, he left out array bounds checks. I think that decision was appropriate for its time and for the slow hardware with small memories that he and Ken Thompson had to work with. However, the idea of C took hold, and that omission led to lots of problems with buffer-overrun security vulnerabilities later. For me, it was a classic example of an idea outlasting its appropriateness.
If you are young, and inexperienced, it is far better to qualify your thoughts and speak carefully, lest others take them out of context and suffer as a result. With care, one can write in a manner that combines both passion and qualification. To do otherwise is to fail in one's responsibility to one's peers, as I see it.
- David
Take care,
- David
You too :) Jan
Cheers Jan On Dec 26, 2010, at 8:21 AM, ungar@mac.com wrote:
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
First of all I wish you all the best :D.
I hate annotation. They are like a language in a language. Why not create invisible slots or something that are simply hidden my the outliner. C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. This has kept me up all week, what a relief.
Happy Holidays, Jan
Yahoo! Groups Links
That was one of the things I liked most about Self: All meta information was on a Mirror interface rather than the executable object. This makes the API cleaner and clearer since the run-time object only has what the domain requires, while the infrastructure, IDE, human, etc support methods reside on one or more reflective objects derived or associated with the run-time domain object. This makes "domain specific languages" un-needed since the programming language is as close to the domain as possible, while relegating non-domain topics to objects for which those topics "are" their domain. It would be cleaner if things like annotations were objects in the "IDE" or "Tool" domain rather than encoded strings, but that appears to be a practical choice in terms of object tree overhead and could be hidden by a Mirror that presented an object level facade to the annotation domain.
Michael
On Dec 28, 2010, at 5:24 PM, ungar@mac.com wrote:
On Dec 28, 2010, at 7:11 AM, Jan-Paul Bultmann wrote:
On 28.12.2010, at 03:43, ungar@mac.com wrote:
On Dec 26, 2010, at 5:12 AM, Jan-Paul Bultmann wrote:
I didn't say that they are useless :D
No, but you implied that when you said that you hated them
Just because you hate to go to the dentist, doesn't mean you shouldn't :)
"Should" is a problematic word for me, unless accompanied by an "if". Without an "if" it reflects an unstated agenda that the speaker is not taking responsibility for. "You should go to the dentist" hides an agenda. "If you want your teeth to last, you should go to the dentist" makes the agenda clear. If you want a stratification between base-level object-oriented programming (as I understand it) and meta-level facilities needed to support an IDE, you should include a means to associate meta-level data with your objects and slots. These are called "annotations" in Self.
and that their functions could be performed by invisible slots,
That was not a solution proposal merely a stylistic element of the cry. To show that I had preferred anything else, as long as it was based on existing concepts.
What you call "existing concepts" as far as I can tell (object, slot, inheritance) were designed precisely to be a minimal set needed for execution. Why would one expect that a set of concepts designed for program execution would also fit the task of organizing the elements of a program to fit a human mind?
whatever that means.
But they are one of those black magic things that happen in the VM and don't emerge out of existing concepts a bit like resends. Even though they are implemented nicely through the use of mirrors.
Sorry, but everything happens in the VM: slots, methods, method invocation, and objects. Resend, too. So, I don't see why annotations are any more magical than anything else.
They also create a problem that is best known form XML, what is property and what is content. Should a comment go into the method or in to the annotation, why is the storeString stuff not in the annotation as well as prototype information. They could be purely for meta information like store-strings, comments and categorisation, but then we should put everything that is not necessary for the function of the object into them.
When you speak of property and content, you embrace a dichotomy that is context-relative without owning up to its multiordinality. In other words, just as with deep-copy, what is property vs content depends on one's purpose at the moment. Methods already contained lots of "meta information", for instance temporary variable names, indentation, etc. etc. Yes, it would be nice to handle all of that better--see Simonyi's intentional programming--BUT, in Self there is a clear distinction: what we thought of as a method--remember we started from Smalltalk--was in the method; what we thought of as in the environment (including the transporter) went into the annotations. When I read your remarks, I feel that you haven't thought about as many scenarios, or as many previous systems, as one would have to do to understand the design space and all of the tradeoffs involved. Many of my own designs for, say the transporter, seemed great for the first few objects saved, but failed miserably later on.
Even though they tend to contradict the principle of simplicity in my opinion, when they are there they should be part of the family and not some distant cousin you don't talk about.
When I read the above, I wondered if perhaps you had not heard of the principle of progressive disclosure. Once designs a conceptual system so it can be learned in pieces. In the case of Self, there is a run-time story of objects and slots. No annotations. They have no effect on the dynamic behavior of base-level programs.
Then, as you learn more, you can encounter object and slots comments, and finally the transporter.
Yes, but those concepts aren't based on what you learned before.
If you say so. When I say that an annotation describes an object for the programming at the meta-level, and that an annotation is composed of objects, it reuses the notion of object. Of necessity it introduced the notion of meta-level. Systems that you may be more used to, tend to not even try to have a programming environment but just rely on text files. Or, in the case of Smalltalk, lack stratification and so give up many advantages. (See the paper by Gilad Bracha and me on reflection.)
I understand simplicity differently than you do. Following Shannon's information theory, simplicity has to do with how much once has to hear, given one's prior (i.e. what you know already), to understand a system. Again, I would love to see a system that did all Self does, without something like annotations. Design one, make it work, make it work on the scale of programs that Self does, and I would be delighted to read about it.
When describing a Object we can no longer say it is composed of slots, and those slots hold information.
Yes we can, when describing its dynamic behavior. You seem to not understand or to discount the idea of context.
We have to say that a Object is composed of slots and Meta information in form of an annotation object, and those slots hold Information and meta information.
Yes, when it's time to file something out, or name it.
So it is not the idea that a Object can hold meta information that I don't like, it is more the fact that we should embrace them as a part of the language we are proud of, (like the totally awesome namespace ;) and cloning ) or we should find a different way.
I really don't understand the gripe. You seem to want to embrace a concept of "the language" that has no meaning to me. Is the environment part of your "language"? It certainly makes a different for the programming experience. What about the pre-programmed pieces that come with the image? What about the concurrency model? What about the fact that, in Self, you can split up your methods with no performance cost whatsoever? I would say that's part of "the language" since it changes how you program. What about the quality of the syntax error messages?
To me "the language" is the minimal set of concepts everything else can be build of. Like the 7 base functions and s-expressions in lisp.
Again, where is the programming environment? Or if there is one, where is the stratification?
Every one of these things both is and is-not the "language." All matter. I have heard many with too much mathematical training assert that Scheme Lambdas are "the same as" Smalltalk blocks. But there is a huge difference in syntactic weight, and incorporation into common idioms.
What Randy & I cared about was the complete experience, the ability to unleash creativity. Is the result of that project perfect? No.
C'mon I love self, I admire what you have created and the soul and ideals the system has, In a world where everybody tries to stamp computer science as a branch of mathematics and cold hearted logic, self is one of the few things with humans in mind. I didn't want to attack you or self, but have the feeling that it maybe came across like that, if so, I am sorry.
Thank you. In the doing of Self, I learned many things, and tried to put them into the papers. It was disheartening to read your message because I would rather people learn from the work as opposed to spreading thoughts that would, in my view, lead to others repeating my own mistakes.
But I'm afraid that I just don't resonate with any of these criticisms of yours.
You don't have to resonate with them, you shouldn't because you probably spend a lot of time with the concepts I am criticizing and if you shared my point of view you had already thought that yourself and done something about it. So there was nothing left for me to criticize :) ( hope that makes sense). So what looks to you as a perfect solution might not be optimal from my perspective since I am focussing on other points. It is not that I saw annotations and thought, man they suck, but I saw that they were developed together with the transporter and though, writing a program should not alter the whole system.
But I don't believe you were simply focussing on other points. I believed you to be ignoring fundamental tradeoffs, and heading down a blind alley. I wanted to head off anyone going in that direction. That was the point of the transporter paper.
Point is. If we all had the same view of an Ideal programming world I'd be rather boring.
And on why I choose to use the word "hate". To me annotations feel like a white flag. The confession that prototype based languages are not up to class based ones when it comes to real live problems. Sure they are as good at runtime, but of course they are, at runtime the two families look almost the same. The goal of prototypes was to feel more natural to the programmer, wasn't it? If it then forces him to do the whole thing he needs to do in a class based language, what's the point. So there you have it, I hate them because they broke my heart :) And since I suppose, I am by far one of the youngest here (20) one might forgive me a bit of fire and passion ;)
I don't think that the Self environment forces one to "do the whole thing he needs to do in a class-based language". The statement itself is not very precise. If you want to be understood, you should try to write a bit more carefully. (same for "hate") I benefitted a lot from Korzybski's Science and Sanity, but if you google "e prime" you can find a lot on the web.
I love youth, fire, and passion. What worries me is the power of an idea, because I have seen some ideas lead to wasted effort, or even destructive outcomes in some cases. Sometimes, even with the best of intentions.
When Ritchie invented C, he left out array bounds checks. I think that decision was appropriate for its time and for the slow hardware with small memories that he and Ken Thompson had to work with. However, the idea of C took hold, and that omission led to lots of problems with buffer-overrun security vulnerabilities later. For me, it was a classic example of an idea outlasting its appropriateness.
If you are young, and inexperienced, it is far better to qualify your thoughts and speak carefully, lest others take them out of context and suffer as a result. With care, one can write in a manner that combines both passion and qualification. To do otherwise is to fail in one's responsibility to one's peers, as I see it.
- David
Take care,
- David
You too :) Jan
Cheers Jan On Dec 26, 2010, at 8:21 AM, ungar@mac.com wrote:
I put annotations in to support the other world; not the world at execution-time, but the world at programming time. I have yet to see a model of execution that supports all of the structure a programmer needs to impose upon the world. For instance, if you are going to file out a subset of objects or slots and then file them in to another world of objects, I am convinced that you need more information than just what is needed to run the objects. See my OOPSLA transporter paper for details.
Also, it is very useful to have categories within a single object. At run-time you need just one object, but at concept-time, you need some way to group things, although a strict hierarchy may not be optimal.
So, if you need some information that plays no role in execution, it must only exist in the reflective domain. I don't see how you get anything much different than annotations, but I would enjoy seeing proposals.
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D
It's easy to complain about something, but think about why it's there and how else you would do it. In my experience, one ends up sweeping dirt around under the carpet; it doesn't go away. Once in a while there is a nice unification. If you don't like annotations, let's see you find that unification.
- David
On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:
Not sure I'd have been quite so diplomatic about it - but I don't disagree.
> First of all I wish you all the best :D. > > I hate annotation. > They are like a language in a language. > Why not create invisible slots or something that are simply hidden my the outliner. > C'mon they managed to do the fricking namespaces with objects and slots... why then staple something on top later. > This has kept me up all week, what a relief. > > Happy Holidays, Jan > > > ------------------------------------ > > Yahoo! Groups Links > > >
Just one more question :) Why are the storeString:IfFail: and prototype methods in the base domain and not accessible via reflection?
Cheers Jan, not native speaker btw.
An excellent question!
Coming from Smalltalk, it seemed reasonable and useful for an object to be able to create a store-string for itself at base level. For example a point knows about the "@" method, to it's compelling that, as part of its non-meta-level behavior it should know to do ( <x storeString> ) @ (<y storeString>). The prototype method is needed to implement storeString, since the prototypical point cannot be rebuilt the same way. However, I think one could make a good case that the identity of the prototype belongs at the meta-level, so perhaps the prototype methods would have been better done that way, with a upshift in the storeString method. Mirrors came after points, so it may have been partly historic. printString is another interesting case. Every decision has its plusses and minuses, and Randy presciently saw the drawbacks of introducing stratification. However, in my own and many other's opinions, the benefits of stratification greatly outweigh the drawbacks. For instance, remote mirrors--outliners on foreign objects--are much easier in a mirror-based system, as are transparent forwarders.
- David
On Dec 28, 2010, at 5:21 PM, Jan-Paul Bultmann wrote:
Just one more question :) Why are the storeString:IfFail: and prototype methods in the base domain and not accessible via reflection?
Cheers Jan, not native speaker btw.
2010/12/26 ungar@mac.com
Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
David,
Could you say something about what prompted this change in Ly with respect to Self? What made you decide that it is preferable to have all non-constant slots copied down?
Is there a paper on Ly?
Regards,
Sekhar
Sekhar,
There is a short Onward paper on Ly in the latest SPLASH/OOPSLA, but it doesn't cover the object model.
I was aiming for a simpler model at the expense of expressiveness. Something that would be as easy as possible to learn.
- David
On Dec 28, 2010, at 3:21 AM, Chandrasekhar Ramakrishnan wrote:
2010/12/26 ungar@mac.com Copy-down is a bit of a different matter. It sort of straddles programming time and run time, though only REFLECTIVE run-time. Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system design is better. (I think so.) In Ly, all non-constant slots are copied-down, as part of the language.
David,
Could you say something about what prompted this change in Ly with respect to Self? What made you decide that it is preferable to have all non-constant slots copied down?
Is there a paper on Ly?
Regards,
Sekhar
-- C. Ramakrishnan cramakrishnan@acm.org
self-interest@lists.selflanguage.org
-
Chandrasekhar Ramakrishnan -
Jan-Paul Bultmann -
Jecel Assumpcao Jr. -
Josh Flowers -
Michael Latta -
Russell Allen -
ungar＠mac.com