On Feb 20, 2007, at 11:57 PM, Alan Lovejoy wrote:
Your comment made me think of the difference in attitude between French speakers and English Speakers.
I don't find this analogy particularly compelling. I don't think people are really trying to keep Smalltalk 'pure'. I think they're trying to find ways to improve it. Lots of things have been tried - multiple inheritance, prototype based vs class based models, access control wrappers, etc... The cool thing is you can make it what you want already. The trick is getting your nifty thing adopted into the standard package.
Other programming languages have been stealing from Smalltalk for decades. It's time we returned the favor.
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
I have been looking at erlang recently and find some of the parallel/ process/queue constructs interesting and would love to try to bring some of that over and try building a high performance web server based on those patterns.
And then, of course, there are interesting technologies that have nothing to do with the language but would make a great addition to the platform. Like Supple http://www.cs.washington.edu/ai/supple/ - a really nifty demo I saw last year.
So there is lots of great stuff to steal - but not much of it from the mainstream languages - they mostly seem to ape the last generation and then take a little lunge in the direction of Smalltalk.
-Todd Blanchard
Todd Blanchard wrote:
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
Really? Namespaces? Modules? Interfaces? Every even remotely mainstream language I am aware about has at least two out of these three - you don't find those worthwhile?
So there is lots of great stuff to steal - but not much of it from the mainstream languages - they mostly seem to ape the last generation and then take a little lunge in the direction of Smalltalk.
I must admit I'm not particularly impressed with that overall assessment.
Cheers, - Andreas
On Feb 21, 2007, at 12:40 AM, Andreas Raab wrote:
I must admit I'm not particularly impressed with that overall assessment.
Then don't vote for me. Sheesh.
Given that AFAICS you've spent the better part of your career hacking Smalltalk rather than working in the mudpits, I'm not giving your view from a distance a lot of weight.
I have years of full time development in these languages - C++ expert, Java expert, Objective C expert. Smalltalk - I'm just pretty good.
Namespaces I've seen the effect of in C++, Java and VW. I think they are a bigger PITA than they are worth. Honestly, I prefer sticking two letter prefixes in front of stuff.
Modules are so overloaded you'll have to define what you mean.
Interfaces - not a fan of the hardwired interface ala Java. I do like informal protocols as implemented in ObjectiveC. Specifically, I like that I can define a protocol, and then ask an object if it conforms to the protocol without having to go back and say "this object will implement this protocol". Not that explicit protocols isn't occasionally useful, but I think the current subclassResponsibility mechanism gets the same point across.
Todd Blanchard wrote:
Given that AFAICS you've spent the better part of your career hacking Smalltalk rather than working in the mudpits, I'm not giving your view from a distance a lot of weight.
This is certainly fair as a personal point of view. But since you are running for a position as a representative of the Squeak community, I would like you to answer the question with your hat as a (potential) member of the SqF board. Is a discussion of these issues even worthwhile in your understanding? Should we actively pursue changes? Do we need to protect the pureness of Smalltalk? (I'm trying to phrase these questions as unloaded as possible since I am honestly interested in learning more about your view on these issues)
I have years of full time development in these languages - C++ expert, Java expert, Objective C expert. Smalltalk - I'm just pretty good.
I didn't question your expertise (but thanks for giving background, it *is* helpful to understand the perspective with which you look at Squeak). I was interested in finding out if you see Squeak (both language and system) moving or not. If you would like to see it moving or not. And perhaps into which direction (but this is a loaded question if there ever has been one so you don't need to answer). Etc. If I was poking a little to directly, I apologize. I'm trying to get a "feel" for you and (honestly) you have been making statements which you either haven't thought through very well or which you need to back up with serious evidence and detail.
You can't just go around and say "every language asymptotically approaches Smalltalk" and "there has been nothing worth stealing from the mainstream" as a representative for Squeak. It will get you laughed out of the room, and I'll be amongst the laughing (and silently embarrassed to have voted for people that make such silly statements).
Cheers, - Andreas
On 2/21/07, Andreas Raab andreas.raab@gmx.de wrote:
Should we actively pursue changes?
[I take it you won't mind getting answers from other candidates :-)]
Yes.
The biggest weakness in Smalltalk/Squeak atm is that it doesn't scale well. At the very least, something in the area of namespacing is needed - this is one thing that Java got right. And personally, I think Goran's approach should be adopted ASAP because it is minimal while getting a long way into the direction of solving the problem at hand.
Beyond that - modules, components, or what you want to call them. I'm a Jini adept, and I've seen the power of having a network of cooperating components work for you. I also like E a lot, and think that some sandboxing system is required to scale Squeak - we must clean up the kernel to make it fully capability-based (also something that Java got more right than most people assume).
Also - I'm discussing this sort of stuff with a friend who's experimenting with a homebrew language - these components should carry around more information than just bytecode. They need to be "multimedial" in a sense, carrying diagrams, design notes, maybe even various partly-complete views of the source code, whatever it takes to make components (and sets of components) understandable to "users".
As what the board's role should be here: encouragement, and actively rallying to get things included. Also, I think that the primary focus of financial support should be in this area.
Oh- and the dogma of backwards compatibility has done more unnecessary damage than I can begin to tell, IMNSHO, so I'm all for easing/releasing that restriction between major releases.
Cees de Groot wrote:
On 2/21/07, Andreas Raab andreas.raab@gmx.de wrote:
Should we actively pursue changes?
[I take it you won't mind getting answers from other candidates :-)]
Of course. I'm interested in getting a basic feeling for what the candidates think about rate of change, directions of change, how (or if) to deal with them etc. And your comments are right on topic.
Cheers, - Andreas
Yes.
The biggest weakness in Smalltalk/Squeak atm is that it doesn't scale well. At the very least, something in the area of namespacing is needed - this is one thing that Java got right. And personally, I think Goran's approach should be adopted ASAP because it is minimal while getting a long way into the direction of solving the problem at hand.
Beyond that - modules, components, or what you want to call them. I'm a Jini adept, and I've seen the power of having a network of cooperating components work for you. I also like E a lot, and think that some sandboxing system is required to scale Squeak - we must clean up the kernel to make it fully capability-based (also something that Java got more right than most people assume).
Also - I'm discussing this sort of stuff with a friend who's experimenting with a homebrew language - these components should carry around more information than just bytecode. They need to be "multimedial" in a sense, carrying diagrams, design notes, maybe even various partly-complete views of the source code, whatever it takes to make components (and sets of components) understandable to "users".
As what the board's role should be here: encouragement, and actively rallying to get things included. Also, I think that the primary focus of financial support should be in this area.
Oh- and the dogma of backwards compatibility has done more unnecessary damage than I can begin to tell, IMNSHO, so I'm all for easing/releasing that restriction between major releases.
From: "Cees de Groot" cdegroot@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 10:47:19 +0100
On 2/21/07, Andreas Raab andreas.raab@gmx.de wrote:
Should we actively pursue changes?
[I take it you won't mind getting answers from other candidates :-)]
Yes.
The biggest weakness in Smalltalk/Squeak atm is that it doesn't scale well. At the very least, something in the area of namespacing is needed - this is one thing that Java got right. And personally, I think Goran's approach should be adopted ASAP because it is minimal while getting a long way into the direction of solving the problem at hand.
I don't agree that Java got it right. Java just stuck something in there. We can do, and I believe have done, better. That is, I think there are better implementations of a namespace type system out there to be adopted.
From the mainstream world, python is pretty good as is Haskell.
IMO a simple "stick colons in it" doesn't do anything but add two characters per class and make the code uglier. We can do better.
_________________________________________________________________ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...
Cees de Groot wrote:
Beyond that - modules, components, or what you want to call them. I'm a Jini adept, and I've seen the power of having a network of cooperating components work for you. I also like E a lot, and think that some sandboxing system is required to scale Squeak - we must clean up the kernel to make it fully capability-based (also something that Java got more right than most people assume).
More right, but not right. Fortunately, it's right enough to be fixable by a layer on top: http://www.joe-e.org. Likewise for OCaml http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html. I'd love to see Squeak evolve to support a similar level of secure cooperation.
We might start out by pointing out that the board does not set technical policy. Tim has been quite vociferous about that and I agree.
I would say that my statement has been misconstrued.
The question was - What do you believe is the future of Smalltalk? My answer was from a social/market/adoption perspective - you seem to have taken it from a technical roadmap perspective.
What I meant when I said other languages seem to be approaching Smalltalk is that they adopt more ST features all the time and the prejudicial barriers are dropping. It is a fine time to win converts and grow the user base. Consider how many people no longer think garbage collection is an intolerable drain on performance. IOW, I think the future of Smalltalk is bright and that it can gain mind/ marketshare as a language. So I see a future of growing user base and rising visibility.
On Feb 21, 2007, at 1:33 AM, Andreas Raab wrote:
Is a discussion of these issues even worthwhile in your understanding?
Yes. As with anything, there are things that drive me nuts about Squeak that could be improved. I do understand that a better packaging system is needed and am open to ideas about how best to approach it. PackageInfo is pretty good, but we could do better. I'd like to see a system that allowed package unloading as well. Such a thing would undo package overrides.
Should we actively pursue changes?
Yes - with some caution. I'm still waiting to see how Traits plays out. Certainly other forks can be taken to try stuff.
Do we need to protect the pureness of Smalltalk?
No, but we do need to protect the stability. My platform - if you bothered to go read it, is about making Squeak useful for making commercial quality things. http://wiki.squeak.org/squeak/5922
-Todd Blanchard
Todd Blanchard wrote:
The question was - What do you believe is the future of Smalltalk? My answer was from a social/market/adoption perspective - you seem to have taken it from a technical roadmap perspective.
To be blunt, I have imagined you giving a talk at O'Reilly and being asked by the audience "So what is the future of Squeak and Smalltalk?". And I was cringing reading that response in the face of twenty years of blatant stagnation of Smalltalk compared to almost daily visible progress in other (both mainstream and not) languages.
Cheers, - Andreas
I can see that now that youve mentioned it - but that's not the context in which I answered it.
There are many futures being pursued. Some will pan out - some won't. I can't really tell what will. I could go down the laundry list of nifty efforts that will benefit me most - like exupery, seaside, pier/magritte, better networking, traits... but you know these as well as I do. Plus there are a number of pain points around code management/modularity that could use attention. The key is to stay alert and look for opportunities.
On Feb 21, 2007, at 11:20 PM, Andreas Raab wrote:
Todd Blanchard wrote:
The question was - What do you believe is the future of Smalltalk? My answer was from a social/market/adoption perspective - you seem to have taken it from a technical roadmap perspective.
To be blunt, I have imagined you giving a talk at O'Reilly and being asked by the audience "So what is the future of Squeak and Smalltalk?". And I was cringing reading that response in the face of twenty years of blatant stagnation of Smalltalk compared to almost daily visible progress in other (both mainstream and not) languages.
Cheers,
- Andreas
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 02:14:38 -0800
The question was - What do you believe is the future of Smalltalk? My answer was from a social/market/adoption perspective - you seem to have taken it from a technical roadmap perspective.
What I meant when I said other languages seem to be approaching Smalltalk is that they adopt more ST features all the time and the prejudicial barriers are dropping. It is a fine time to win converts and grow the user base. Consider how many people no longer think garbage collection is an intolerable drain on performance. IOW, I think the future of Smalltalk is bright and that it can gain mind/ marketshare as a language. So I see a future of growing user base and rising visibility.
This is exactly how I took your statement. Though I can understand Andreas wanting to get it clarified.
Do we need to protect the pureness of Smalltalk?
No, but we do need to protect the stability. My platform - if you bothered to go read it, is about making Squeak useful for making commercial quality things. http://wiki.squeak.org/squeak/5922
Purity? For me personally, it depends on what is meant. If you mean sticking to the blue book 100%, then no of course not. But changes need to take us forward not backward.
Smalltalk is IMO the most productive environment there is, and that needs to be preserved. So changes like, for example, trying to make the image file oriented instead of image oriented would be very negative in my mind.
_________________________________________________________________ Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month. Intro*Terms http://www.NexTag.com
Not that all of these languages are object-oriented programming languages. Several features found in functional, logic or constraint languages might be interested to integrate. Note the (really excellent) paper of Philippe Mougin and Stephane Ducasse, that integrated APL-like constructs with Smalltalk collections.
OOPAL: Integrating Array Programming in Object-Oriented Programming , Philippe Mougin, Stéphane Ducasse. OOPSLA 2003 (18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications). Technical Paper, October 2003, Anaheim, USA.
On 21 Feb 2007, at 21 February/09:55, Todd Blanchard wrote:
On Feb 21, 2007, at 12:40 AM, Andreas Raab wrote:
I must admit I'm not particularly impressed with that overall assessment.
Then don't vote for me. Sheesh.
Given that AFAICS you've spent the better part of your career hacking Smalltalk rather than working in the mudpits, I'm not giving your view from a distance a lot of weight.
I have years of full time development in these languages - C++ expert, Java expert, Objective C expert. Smalltalk - I'm just pretty good.
Namespaces I've seen the effect of in C++, Java and VW. I think they are a bigger PITA than they are worth. Honestly, I prefer sticking two letter prefixes in front of stuff.
Modules are so overloaded you'll have to define what you mean.
Interfaces - not a fan of the hardwired interface ala Java. I do like informal protocols as implemented in ObjectiveC. Specifically, I like that I can define a protocol, and then ask an object if it conforms to the protocol without having to go back and say "this object will implement this protocol". Not that explicit protocols isn't occasionally useful, but I think the current subclassResponsibility mechanism gets the same point across.
I'm well aware (and a big fan of) Philippe's work. In fact, I built this with it: http://objectiveclips.com
Last I checked - ProjectX was using it for its constraints mechanism.
-Todd Blanchard
On Feb 21, 2007, at 2:03 PM, Roel Wuyts wrote:
Not that all of these languages are object-oriented programming languages. Several features found in functional, logic or constraint languages might be interested to integrate. Note the (really excellent) paper of Philippe Mougin and Stephane Ducasse, that integrated APL-like constructs with Smalltalk collections.
OOPAL: Integrating Array Programming in Object-Oriented Programming , Philippe Mougin, Stéphane Ducasse. OOPSLA 2003 (18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications). Technical Paper, October 2003, Anaheim, USA.
On 21 Feb 2007, at 21 February/09:55, Todd Blanchard wrote:
On Feb 21, 2007, at 12:40 AM, Andreas Raab wrote:
I must admit I'm not particularly impressed with that overall assessment.
Then don't vote for me. Sheesh.
Given that AFAICS you've spent the better part of your career hacking Smalltalk rather than working in the mudpits, I'm not giving your view from a distance a lot of weight.
I have years of full time development in these languages - C++ expert, Java expert, Objective C expert. Smalltalk - I'm just pretty good.
Namespaces I've seen the effect of in C++, Java and VW. I think they are a bigger PITA than they are worth. Honestly, I prefer sticking two letter prefixes in front of stuff.
Modules are so overloaded you'll have to define what you mean.
Interfaces - not a fan of the hardwired interface ala Java. I do like informal protocols as implemented in ObjectiveC. Specifically, I like that I can define a protocol, and then ask an object if it conforms to the protocol without having to go back and say "this object will implement this protocol". Not that explicit protocols isn't occasionally useful, but I think the current subclassResponsibility mechanism gets the same point across.
Hi!
Todd Blanchard wrote:
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
Really? Namespaces? Modules? Interfaces? Every even remotely mainstream language I am aware about has at least two out of these three - you don't find those worthwhile?
Ah. Yummy. That word again. :) Totally disregarding the point Andreas is trying to make (which I agree on btw), let me ramble off:
- Namespaces. In my opinion this one is a hard one. Sure, we do need it from time to time in different scenarios, but it sure is hard IMHO to introduce a solution that doesn't "hurt" the feeling of Smalltalk. Including my own proposal which tries damn hard though.
- Modules. This one would be neat to have in some fashion. I consider the word to mean "independently deployable unit" btw. Today MC is more or less grabbing this space (in a fashion) but with an SCM focus instead of deployment focus.
Sidenote: I have toyed with an idea that a Module would simply consist of a serialized object chunk (normally a Set of classes a la an mcz snapshot) that has required inputs in the form of a list of globals and offered outputs in the form of a list of globals. Loading a module would be possible even if the required input globals weren't complete - it should then create a temporary binding that another Modules later can "fill in". This would make load order independent. Sure, it would not deal with "extension methods" a la MC - but perhaps it shouldn't?
- Interfaces. Yes, might be neat to have. Traits touch on this a bit and we also have SmallInterfaces (which I never have looked at). I really don't know if it would hurt more than it would help.
But... that doesn't mean that I advocate Squeak to stand still language-wise. I love the fact we got Traits - even though it hasn't taken off yet AFAIK - anyone using them btw?
regards, Göran
On Wed, 21 Feb 2007 01:10:19 -0800, Stéphane Rollandin lecteur@zogotounga.net wrote:
Göran Krampe wrote:
I love the fact we got Traits - even though it hasn't taken off yet AFAIK - anyone using them btw?
I'm waiting for the tools to be ready...
Yeah, it is sort of a struggle.
On 21 févr. 07, at 10:10, Stéphane Rollandin wrote:
Göran Krampe wrote:
I love the fact we got Traits - even though it hasn't taken off yet AFAIK - anyone using them btw?
I'm waiting for the tools to be ready...
like everybody else but nobody is helping. too bad. no time.
Stef
On 2/21/07, Göran Krampe goran@krampe.se wrote:
Sidenote: I have toyed with an idea that a Module would simply consist of a serialized object chunk (normally a Set of classes a la an mcz snapshot) that has required inputs in the form of a list of globals and offered outputs in the form of a list of globals.
Would be neat.
On stealing/enhancing: Aspect/S, SmallInterfaces, Traits, Squeak/E, ... - there's a lot already. However, contrary to mainstream languages, we're at such a high level that it is *hard* to adopt enhancements that really make the language better...
Yes and no.
I was at a Prolog conference once, and they were saying the exact same thing about Prolog, which made me laugh my head of (having heard this so many times at Smalltalk conferences). Lisp people also seem to think that Lisp is perfect...
Broadening this a bit: these three language families (Logic programming, functional programming and (pure) object-oriented programming are all considered 5th generation languages. I often wonder why none of these well-designed, clean languages were never really popular. I actually believe that this is one of the deep, underlying reasons: people that embrace this language and get it are so hooked that they are absorbed and never get out again. This is what Andreas is pointing to.
On 21 Feb 2007, at 21 February/10:25, Cees de Groot wrote:
On 2/21/07, Göran Krampe goran@krampe.se wrote:
Sidenote: I have toyed with an idea that a Module would simply consist of a serialized object chunk (normally a Set of classes a la an mcz snapshot) that has required inputs in the form of a list of globals and offered outputs in the form of a list of globals.
Would be neat.
On stealing/enhancing: Aspect/S, SmallInterfaces, Traits, Squeak/E, ... - there's a lot already. However, contrary to mainstream languages, we're at such a high level that it is *hard* to adopt enhancements that really make the language better...
From: Roel Wuyts Roel.Wuyts@ulb.ac.be Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 23:03:54 +0100
Broadening this a bit: these three language families (Logic programming, functional programming and (pure) object-oriented programming are all considered 5th generation languages. I often wonder why none of these well-designed, clean languages were never really popular. I actually believe that this is one of the deep, underlying reasons: people that embrace this language and get it are so hooked that they are absorbed and never get out again. This is what Andreas is pointing to.
But don't just assume that because Java is popular and Squeak isn't as much, that Java is right and Smalltalk is wrong. Maybe we really *do* have the best system and it just hasn't been adopted.
They say the worse something is, the more it will be advertised, and in my experience this has been true.
_________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTE...
I would like to use traits (will start making an app with a complex domain model) but the tool support is not sufficient. I think it is not a fair claim that we've got Traits if we have no tools :(
regards, Danil
Göran Krampe wrote:
But... that doesn't mean that I advocate Squeak to stand still language-wise. I love the fact we got Traits - even though it hasn't taken off yet AFAIK - anyone using them btw?
regards, Göran
Have you tried TraitsOmniBrowser (http://www.squeaksource.com/ TraitsOmniBrowser.html)? Also, the OmniBrowser in the image has basic support for Traits. Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Adrian
BTW, Monticello supports Traits too
On Feb 21, 2007, at 11:06 , danil osipchuk wrote:
I would like to use traits (will start making an app with a complex domain model) but the tool support is not sufficient. I think it is not a fair claim that we've got Traits if we have no tools :(
regards, Danil
Göran Krampe wrote:
But... that doesn't mean that I advocate Squeak to stand still language-wise. I love the fact we got Traits - even though it hasn't taken off yet AFAIK - anyone using them btw?
regards, Göran
-- View this message in context: http://www.nabble.com/Squeak- Foundation-Board-2007-Candidates-tf3253392.html#a9078181 Sent from the Squeak - Dev mailing list archive at Nabble.com.
I tried TraitsOmniBrowser and as I recall I could not be productive with it. However it was half-year ago and I will take a fresh look. Adrian, sorry if my post sounded like a harsh complain (it was a complain indeed), but my intent was not all that negative. I just wanted to bring up this topic again (in a bit provocative way, I admit) and also to stress two points:
1) There are people who care about traits and who appreciate any work in this direction. 2) Discussions popup from time to time, in which traits benefits are questioned basing on the fact that they are not used widely, although they are in the image for a quite a lot of time. I would like to counter this train of thought by telling that we can not say traits concept failed, because nobody used them.
So, please see my post in this context. I personally believe that traits are benefitial and I would like to apply them and to see if it is true.
Regarding the help, I would like to offer help in this case. In fact when I miss something, I'm trying to do it silently myself. But in this case I'm just not sure if I'm quilified - this is language infrastracture topic and I'm more 'userland' kind of guy. But if you need help - could you please describe what kind of help do you expect? If not me - probably other interested could jump in.
Regards, Danil
Adrian Lienhard wrote:
Have you tried TraitsOmniBrowser (http://www.squeaksource.com/ TraitsOmniBrowser.html)? Also, the OmniBrowser in the image has basic support for Traits. Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Adrian
BTW, Monticello supports Traits too
Hi Danil,
Thanks for making your points clear. My "rant" was meant as a general remark -- to argue that without initiative the tools will not get better over night... Here some background: I put a fair amount of time into a smooth integration of Traits into 3.9 (which I originally implemented for 3.7) and for example also made Monticello Traits-aware. I also said that I cannot put work into the UI. Daniel, Andrew, and Tom then worked on the TraitsOmniBrowser but somehow the effort got stuck just a bit before being really usable out of the box. I think, people that are interested in using Traits and need a more sophisticated UI than the current OmniBrowser in 3.9 should join forces and improve the TraitsOmniBrowser. (This browser btw. has some other nice features unrelated to Traits as well.) I suggest to contact one of the original authors. In general, the SqueakSource repository has global write access so anybody can commit improvements.
Adrian
On Feb 21, 2007, at 13:04 , danil osipchuk wrote:
I tried TraitsOmniBrowser and as I recall I could not be productive with it. However it was half-year ago and I will take a fresh look. Adrian, sorry if my post sounded like a harsh complain (it was a complain indeed), but my intent was not all that negative. I just wanted to bring up this topic again (in a bit provocative way, I admit) and also to stress two points:
- There are people who care about traits and who appreciate any
work in this direction. 2) Discussions popup from time to time, in which traits benefits are questioned basing on the fact that they are not used widely, although they are in the image for a quite a lot of time. I would like to counter this train of thought by telling that we can not say traits concept failed, because nobody used them.
So, please see my post in this context. I personally believe that traits are benefitial and I would like to apply them and to see if it is true.
Regarding the help, I would like to offer help in this case. In fact when I miss something, I'm trying to do it silently myself. But in this case I'm just not sure if I'm quilified - this is language infrastracture topic and I'm more 'userland' kind of guy. But if you need help - could you please describe what kind of help do you expect? If not me - probably other interested could jump in.
Regards, Danil
Adrian Lienhard wrote:
Have you tried TraitsOmniBrowser (http://www.squeaksource.com/ TraitsOmniBrowser.html)? Also, the OmniBrowser in the image has basic support for Traits. Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Adrian
BTW, Monticello supports Traits too
-- View this message in context: http://www.nabble.com/Squeak- Foundation-Board-2007-Candidates-tf3253392.html#a9079698 Sent from the Squeak - Dev mailing list archive at Nabble.com.
2007/2/21, Adrian Lienhard adi@netstyle.ch:
people that are interested in using Traits and need a more sophisticated UI than the current OmniBrowser in 3.9 should join forces and improve the TraitsOmniBrowser. (This browser btw. has some other nice features unrelated to Traits as well.)
I do not agree with you Adrian. I think it would be better to extract what makes TraitsOmniBrowser a cool browser for traits and implement those features into OmniBrowser itself. I don't think having one browser per feature is something we want. I would prefer one browser for everything (traits, dynamic protocols, code coverage...). Moreover, I don't see the point of having a browser not trait aware, this would be stupid in a 3.9 image.
So please do not put more work on the TraitsOmniBrowser anymore. Instead, enhance OmniBrowser with TraitsOmniBrowser features.
I volunteer to help because I like improving tool and I'm working with traits.
On Wed, 21 Feb 2007 03:10:16 -0800, Adrian Lienhard adi@netstyle.ch wrote:
Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
It's challenging to both work with traits for the first time AND figure out how to improve the tools for working with traits. The plus side of Squeak is that it is, at least, relatively easy to make (at least rough drafts of) tools.
Adrian Lienhard wrote:
Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Isn't it more like: To use traits you need tools, to write tools you need to understand traits, and to understand traits you need to use them?
I've been poking around in the traits implementation myself (fairly well documented in [1], and [2]) and although I have a very good understanding about the metaclass relationships in Squeak < 3.9 I found the traits implementation basically impenetrable. If I look at who implements a method and get ten implementors thrown at me where there used to be one or two, it's just not helpful. I stopped digging into it for that reason - the traits class kernel has become completely inaccessible to me.
I'm starting to think that implementing traits using traits may have been a mistake for that very reason. Maybe this should have done as a second step or so. But the way the situation is I think there may only be half a dozen people in the world who have any idea of how that traits kernel works. The rest is doomed to use tools that are simply not up to the job and have basically no chance to really get into it.
Cheers, - Andreas
[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/094009.ht... [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110494.h...
Hi Andreas,
on Thu, 22 Feb 2007 08:36:49 +0100, you wrote:
Adrian Lienhard wrote:
Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Isn't it more like: To use traits you need tools, to write tools you need to understand traits, and to understand traits you need to use them?
I've been poking around in the traits implementation myself (fairly well documented in [1], and [2]) and although I have a very good understanding about the metaclass relationships in Squeak < 3.9 I found the traits implementation basically impenetrable. If I look at who implements a method and get ten implementors thrown at me where there used to be one or two, it's just not helpful. I stopped digging into it for that reason - the traits class kernel has become completely inaccessible to me.
I'm starting to think that implementing traits using traits may have been a mistake for that very reason. Maybe this should have done as a second step or so. But the way the situation is I think there may only be half a dozen people in the world who have any idea of how that traits kernel works.
C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here>
I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo.
No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings.
/Klaus
The rest is doomed to use tools that are simply not up to the job and have basically no chance to really get into it.
Cheers,
- Andreas
[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/094009.ht... [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110494.h...
Klaus D. Witzel wrote:
C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here>
Not sure which part you are referring to here. Whether you mean the number of people really understanding those systems, or whether you mean that the self-implementing part, or whether you mean that the usefulness of any of the above is intrinsically tied to an tool dependency.
I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo.
No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings.
You are of course right. If you interpret it that way, it's not correct. My criticism is elsewhere: I am very upset about how much harder it is to understand traits than any of the things you mention above. I went through the NewCompiler in an afternoon, Seaside took me weekend, I actively hacked on Monticello. In all of these cases I was able to navigate and learn a large and completely unknown (and sometimes not too pretty) code base in a very reasonable amount of time.
In the traits implementation I failed miserably, and I am not quite sure why. That is my criticism of traits. And it is quite possible that this is related to insufficient tools, but I'm sorry, if I can't understand how things ought to work then I won't be able to help building tools for it.
Cheers, - Andreas
Hi Andreas,
on Thu, 22 Feb 2007 09:17:21 +0100, you wrote:
Klaus D. Witzel wrote:
C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here>
Not sure which part you are referring to here. Whether you mean the number of people really understanding those systems, or whether you mean that the self-implementing part, or whether you mean that the usefulness of any of the above is intrinsically tied to an tool dependency.
Let's say: yes.
I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo. No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings.
You are of course right. If you interpret it that way, it's not correct. My criticism is elsewhere: I am very upset about how much harder it is to understand traits than any of the things you mention above. I went through the NewCompiler in an afternoon, Seaside took me weekend, I actively hacked on Monticello. In all of these cases I was able to navigate and learn a large and completely unknown (and sometimes not too pretty) code base in a very reasonable amount of time.
In the traits implementation I failed miserably, and I am not quite sure why. That is my criticism of traits. And it is quite possible that this is related to insufficient tools, but I'm sorry, if I can't understand how things ought to work then I won't be able to help building tools for it.
I agree [with the implication as well as its anaphor :-]
Smalltalk (Squeak) was built and is maintained by an elitarian group of people (a), also the packages.
And "it" is being used, debugged and extended by an even more so elitarian group of people (b), which on SqP are called users (!). "it" being libraries, classes, methods, or whatsoever code (even isolated lines).
The (b)'s are even more skilled (resp. a second kind of skill) because they clean-up the junkyard[1] produced by (a) raisedTo: time.
For the time being, the application of Traits to itself seems to transcendent some of the (b)'s :)
But Traits must become usable for the (b)'s, no question.
/Klaus
[1] as an example, with Java you can't expect that your changes to core classes (example: java.lang.Class) will ever make it into the mainstream; this is an example of the kind code that I think is on the developer's junkyard.
Cheers,
- Andreas
Andreas. This is true that the Traits implementation could be done without traits and be more understandable. This could be simply done by flattening those traits. The implementation is not that complex. At least to me the compiler looks more complex. Traits are simple. Have a look at the master of Adrian. Monticello is really complex to me I can never find what I should extend or call. I read MC2 and this is much simpler to my eyes. When I program MC I copy and paste since in general I cannot find what I have to do (lost in ancestor working copies and the rest).
Stef
On 22 févr. 07, at 09:17, Andreas Raab wrote:
Klaus D. Witzel wrote:
C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here>
Not sure which part you are referring to here. Whether you mean the number of people really understanding those systems, or whether you mean that the self-implementing part, or whether you mean that the usefulness of any of the above is intrinsically tied to an tool dependency.
I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo. No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings.
You are of course right. If you interpret it that way, it's not correct. My criticism is elsewhere: I am very upset about how much harder it is to understand traits than any of the things you mention above. I went through the NewCompiler in an afternoon, Seaside took me weekend, I actively hacked on Monticello. In all of these cases I was able to navigate and learn a large and completely unknown (and sometimes not too pretty) code base in a very reasonable amount of time.
In the traits implementation I failed miserably, and I am not quite sure why. That is my criticism of traits. And it is quite possible that this is related to insufficient tools, but I'm sorry, if I can't understand how things ought to work then I won't be able to help building tools for it.
Cheers,
- Andreas
On Feb 22, 2007, at 08:36 , Andreas Raab wrote:
Adrian Lienhard wrote:
Of course the tools are not perfect. Instead of helping to improve the situation people tend to complain. Unfortunately this will not bring us forward. But hey, its not that important, is it?
Isn't it more like: To use traits you need tools, to write tools you need to understand traits, and to understand traits you need to use them?
I don't think you need to understand its internal details to be able to build tools. You do not need to enhance kernel but use the interface that is there already. E.g., Trait>>#users will return you all classes and traits that use a trait. Its just that this kind of information is lacking in the UI.
I've been poking around in the traits implementation myself (fairly well documented in [1], and [2]) and although I have a very good understanding about the metaclass relationships in Squeak < 3.9 I found the traits implementation basically impenetrable. If I look at who implements a method and get ten implementors thrown at me where there used to be one or two, it's just not helpful. I stopped digging into it for that reason - the traits class kernel has become completely inaccessible to me.
Just to make that clear. This contradicts to your mail [3]. Since [2] the traits structure of the kernel was simplified. You even looked at this and you said in [3] that it indeed helps you to understand how this all works. I do not want to start a new endless discussion.
I'm starting to think that implementing traits using traits may have been a mistake for that very reason. Maybe this should have done as a second step or so.
We first implemented it without traits. But since we wanted to keep the old metaclass hierarchy largely unchanged the resulting code duplication just made it unmaintainable. Traits seemed like an obvious solution to that.
[...]
[1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005- August/094009.html [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- October/110494.html
[3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- October/110526.html
Cheers, Adrian
Adrian Lienhard wrote:
I don't think you need to understand its internal details to be able to build tools. You do not need to enhance kernel but use the interface that is there already. E.g., Trait>>#users will return you all classes and traits that use a trait. Its just that this kind of information is lacking in the UI.
That's certainly part of it but not exclusively. For anything that is truly useful you will need to understand a lot about the implementation. Consider a simple example, like removing a method. If you want to build a useful tool, you need to know whether the method you remove originates from the class or from a trait and if so, which one. As far as I know there is no method directly answering that information so you need to know the implementation of traits to write that method. Etc.
Often you need that to understand the implementation to know how and where a tool is allowed to temporarily violate (or extend) the constraints. The browser, for example, pre-parses class definitions and checks whether actually executing it could cause harm (like changing a class definition not currently visible to the user). If the browser wouldn't do that it would be a good amount less usable. But for that you need to know how class interact and what can go wrong if you execute the class definition without pre-parsing it.
So I think you really do need to understand the implementation to write a useful tool. It is possible to get to a certain point without that but usually these points are trivial and not very useful. Case in point: Traits>>users. It is no problem for me to to change the class browser to show that bit of information. I have done it. But that is not enough by far.
I've been poking around in the traits implementation myself (fairly well documented in [1], and [2]) and although I have a very good understanding about the metaclass relationships in Squeak < 3.9 I found the traits implementation basically impenetrable. If I look at who implements a method and get ten implementors thrown at me where there used to be one or two, it's just not helpful. I stopped digging into it for that reason - the traits class kernel has become completely inaccessible to me.
Just to make that clear. This contradicts to your mail [3]. Since [2] the traits structure of the kernel was simplified. You even looked at this and you said in [3] that it indeed helps you to understand how this all works. I do not want to start a new endless discussion.
I think you misunderstand that message. I didn't say (and I didn't mean to say) that suddenly traits became all clear and simple and obvious ;-) I said (and I meant to say) that I understand some aspects now better (like the dual hierarchical structure) which lead me to conclude that it also makes me understand a lot better what I dislike about traits.
But really, I haven't grok-ed the implementation by a long shot. To give you an example, here is a simple question: Where do I find the addSelector:* and removeSelector:* family of methods and why? I can give you the answer for 3.8 (without looking at the code): Those methods must in Behavior with a few overrides in ClassDescription (where they manipulate the organization). They can't be higher in the hierarchy since they affect behaviors and they can't be lower since they should be shared between classes and meta classes. So without looking at the code I can deduce where these methods must be found. In 3.9 I can't give you that answer - I have no idea why addSelector:withMethod:notifying: is in one set of traits and addSelector:withMethod: is in another set of them and what the organizing principle behind it is.
Anyway, you are right, we had that discussion already. All I'm saying is that if you read that message of mine as saying "oh, now I got it" then you read it wrong.
Cheers, - Andreas
From: Göran Krampe goran@krampe.se Reply-To: goran@krampe.se, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 09:59:52 +0100 (CET)
- Interfaces. Yes, might be neat to have. Traits touch on this a bit and
we also have SmallInterfaces (which I never have looked at). I really don't know if it would hurt more than it would help.
Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is.
_________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTE...
J J wrote:
Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is.
So you have used traits? In which project? Can I see the code? I've been constantly on the lookout for good examples of traits use but so far I have only found a few toy academic projects that look beautiful (and go and scale nowhere) and one realistic real-world use (the traits implementation itself) which to me is a bunch of spaghetti code and where I am very curious how maintenance will work out over the next years.
Cheers, - Andreas
Andreas Raab andreas.raab@gmx.de writes:
J J wrote:
Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is.
So you have used traits? In which project? Can I see the code? I've been constantly on the lookout for good examples of traits use but so far I have only found a few toy academic projects that look beautiful (and go and scale nowhere) and one realistic real-world use (the traits implementation itself) which to me is a bunch of spaghetti code and where I am very curious how maintenance will work out over the next years.
Wasn't there a big collections refactoring done with traits? I have been meaning to dig it up and read through it, but have never found the time.
Here's one use of them, though, that I use all the time in Scala's variation on traits. You can make Squeak's Magnitude be a trait instead of an abstract class. That is, given a < method, which is abstract in Magnitude, you can have Magnitude define all the other methods for you.
Or closer to your heart, Andreas, how would you like to have a Rectangular trait for all those #left, #right, #topLeft, etc. methods? It would require a #rectangle method, which for Rectangle is "yourself" and for Morph is "bounds". Then all these helper methods would get defined for you by the trait.
This usage of traits may be small one by one, but they are enough to convince me thre are some very nice uses of traits that are not available in Smalltalk. What they do is take a thin interface and widen it to a rich interface. They let you *define* classes using the thin interface, and *use* them with the rich interface.
Anyway, I don't know anything about the Squeak version. My day jobs have kept me too busy to look into Squeak's traits as I would like to. However, I can vouch for the feature, just based on the above examples.
-Lex
Lex Spoon wrote:
Wasn't there a big collections refactoring done with traits? I have been meaning to dig it up and read through it, but have never found the time.
This was one of the academic exercises I was referring to, see here:
http://citeseer.ist.psu.edu/581397.html
Also, its main focus was on squeezing entropy out of the system (i.e., eliminate code duplication) not necessarily improvements in design (the paper claims some but I'm pretty sure that *any* serious bit of refactoring of a 20 year old class hierarchy could improve a few things ;-)
Here's one use of them, though, that I use all the time in Scala's variation on traits. You can make Squeak's Magnitude be a trait instead of an abstract class. That is, given a < method, which is abstract in Magnitude, you can have Magnitude define all the other methods for you.
How interesting. Does Scala use traits extensively?
Or closer to your heart, Andreas, how would you like to have a Rectangular trait for all those #left, #right, #topLeft, etc. methods? It would require a #rectangle method, which for Rectangle is "yourself" and for Morph is "bounds". Then all these helper methods would get defined for you by the trait.
Did I mention toy examples before? ;-) Yes, that is one of those. Unfortunately, in real code I only ever have that problem in about a single base class so it's usually not worth creating an extra entity (trait). In addition, I have found that I prefer to carefully choose which parts of the interface to expose and which ones not - Players in Tweak expose a partial set of rectangle operations, a partial set of collection operations but not both to the full extent simply because that would be crazy overload. Where I need the full interface I prefer aspects so that if you really really need #squishedWithin: you say "player bounds squishedWithin: aRectangle" instead. Which gives you the advantage of providing a useful, filtered interface as the default without eliminating access to the full interface. And finally, the rectangle interface is very stable and hardly ever changes so evolution of interfaces isn't really an issue either.
This usage of traits may be small one by one, but they are enough to convince me thre are some very nice uses of traits that are not available in Smalltalk. What they do is take a thin interface and widen it to a rich interface. They let you *define* classes using the thin interface, and *use* them with the rich interface.
So where are these uses? Can you point me to any in real applications?
Anyway, I don't know anything about the Squeak version. My day jobs have kept me too busy to look into Squeak's traits as I would like to. However, I can vouch for the feature, just based on the above examples.
Well, I'm still on the lookout trying to find a really convincing example of use for traits. If you can point me to one (e.g., point me to actual code in an actually running system) I'd really appreciate it.
Cheers, - Andreas
Hi!
From: Göran Krampe goran@krampe.se
- Interfaces. Yes, might be neat to have. Traits touch on this a bit and
we also have SmallInterfaces (which I never have looked at). I really don't know if it would hurt more than it would help.
Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is.
AFAIK Traits is not intended as "specification of protocol" that you can check against (during runtime or in some interesting way - compile time). Sure, they *are* comprised of a bunch of methods - and sure - we could probably (mis)use them as interfaces/protocol-specifications - but... I couldn't really say at this point because alas, I haven't used them yet. :)
Ok, let me take the opportunity to flesh out a trivial idea:
As most people know a java interface is a "named bunch of messages" that a class (or its superclasses of course) can declare it implements. But this is early binding, right?
I would be more interested in "late" binding where I could do:
someThingy respondsToProtocol: aProtocol
...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
This means in practice that the code using someThingy (written later by developer X) can declare what messages it actually intends to send to someThingy instead of the other way around. IMHO this decouples the writing of someThingy from the code using it *in time*.
Now... one place where this might be useful is in unit tests. Or hey, I dunno, just felt like a Smalltalkish way of using "interfaces". :)
regards, Göran
PS. Btw, anyone recall the syntactic changes that was introduced in one of the older VWs? Perhaps around version 2.5 or so. The Compiler could actually parse "parameter type checks using some <...>-syntax IIRC" but when I looked closer in the code it didn't actually do anything with it yet. Eh... have no idea why this popped up in my head right now. ;)
Göran Krampe wrote:
I would be more interested in "late" binding where I could do:
someThingy respondsToProtocol: aProtocol
...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
Funny you should mention this. I had the same idea a while ago but the trouble is that you want a really, REALLY fast check (as fast as isFoo effectively so that you can say: "true isA: Boolean" and be that the speedy equivalent of "true isBoolean") and to do this you need some way of caching the result effectively (and invalidate it as the class changes). Alas, I could never come up with a scheme that was as fast as I needed it to be (if you have any ideas, I'm all ears).
Cheers, - Andreas
Hi Andreas, on Fri, 23 Feb 2007 08:52:52 +0100, you wrote:
Göran Krampe wrote:
I would be more interested in "late" binding where I could do: someThingy respondsToProtocol: aProtocol ...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
Funny you should mention this. I had the same idea a while ago but the trouble is that you want a really, REALLY fast check (as fast as isFoo effectively so that you can say: "true isA: Boolean" and be that the speedy equivalent of "true isBoolean") and to do this you need some way of caching the result effectively (and invalidate it as the class changes). Alas, I could never come up with a scheme that was as fast as I needed it to be (if you have any ideas, I'm all ears).
Here's the scheme that is as fast as I needed it to be:
during method lookup, treat aProtocol as the object you want to cache.
The rest follows immediately.
/Klaus
Cheers,
- Andreas
On Feb 22, 2007, at 11:46 PM, Göran Krampe wrote:
As most people know a java interface is a "named bunch of messages" that a class (or its superclasses of course) can declare it implements. But this is early binding, right?
I would be more interested in "late" binding where I could do:
someThingy respondsToProtocol: aProtocol
...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
Get a mac. :-)
ObjectiveC has Protocols (which I think were the inspiration for Java's interfaces). Protocols can be formal (the class declares it implements a protocol explicitly and the compiler whines if you leave something out) or informal - you implement it but you don't declare it.
There is a lovely method in Cocoa conformsToProtocol: that does just what you're asking. I don't know how it works, but if I were to implement such a thing in Squeak in a cheap and cheerful way - I would reify a protocol as a class and attache protocols to existing classes much the way PoolDictionaries work now only instead of importing shared constants, you are using it to enforce a set of methods. How tools prompt you to make sure you conform to the protocol you declare is an exercise left to the implementer.
-Todd Blanchard
Todd Blanchard a écrit :
On Feb 22, 2007, at 11:46 PM, Göran Krampe wrote:
As most people know a java interface is a "named bunch of messages" that a class (or its superclasses of course) can declare it implements. But this is early binding, right?
I would be more interested in "late" binding where I could do:
someThingy respondsToProtocol: aProtocol
...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
Get a mac. :-)
ObjectiveC has Protocols (which I think were the inspiration for Java's interfaces). Protocols can be formal (the class declares it implements a protocol explicitly and the compiler whines if you leave something out) or informal - you implement it but you don't declare it.
There is a lovely method in Cocoa conformsToProtocol: that does just what you're asking. I don't know how it works, but if I were to implement such a thing in Squeak in a cheap and cheerful way - I would reify a protocol as a class and attache protocols to existing classes much the way PoolDictionaries work now only instead of importing shared constants, you are using it to enforce a set of methods. How tools prompt you to make sure you conform to the protocol you declare is an exercise left to the implementer.
-Todd Blanchard
To be fast, you could rely on message sending
respondsToProtocol: aProtocol ^self protocolChecker perform: aProtocol symbolicName
protoclChecker would answer an anonymous subclass of ProtocolChecker ProtocolChecker would implement doesNotUnderstand as: - checking if all methods of protocol are understood (needs a link back to associated class) - implement a new method (aProtocol symbolicName) answering true or false
In order to inherit protocol, you would have to construct ProtocolChecker hierarchy like the metaclass one...
Adding or deleting in the methodDictionary would trigger a self protocolChecker flushCache in all subclasses.
The flushCache should also be invoked whenever a Protocol definition changes
And Andreas, please don't ask how this would mix with Traits!
Of course, this is overkill compared to a simple <Dictionary of Protocol>
Nicolas
Did you read the paper of benny saedh on my web page on dynamic interface? Because may be this is what you are looking for?
Stef
On 23 févr. 07, at 08:46, Göran Krampe wrote:
Hi!
From: Göran Krampe goran@krampe.se
- Interfaces. Yes, might be neat to have. Traits touch on this a
bit and we also have SmallInterfaces (which I never have looked at). I really don't know if it would hurt more than it would help.
Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is.
AFAIK Traits is not intended as "specification of protocol" that you can check against (during runtime or in some interesting way - compile time). Sure, they *are* comprised of a bunch of methods - and sure - we could probably (mis)use them as interfaces/protocol-specifications - but... I couldn't really say at this point because alas, I haven't used them yet. :)
Ok, let me take the opportunity to flesh out a trivial idea:
As most people know a java interface is a "named bunch of messages" that a class (or its superclasses of course) can declare it implements. But this is early binding, right?
I would be more interested in "late" binding where I could do:
someThingy respondsToProtocol: aProtocol
...where aProtocol is more or less just a bunch of selectors. The main difference is of course that the class (or any of its superclasses) of someThingy doesn't need to *declare* that it implements aProtocol - it just has to actually do it. :)
This means in practice that the code using someThingy (written later by developer X) can declare what messages it actually intends to send to someThingy instead of the other way around. IMHO this decouples the writing of someThingy from the code using it *in time*.
Now... one place where this might be useful is in unit tests. Or hey, I dunno, just felt like a Smalltalkish way of using "interfaces". :)
regards, Göran
PS. Btw, anyone recall the syntactic changes that was introduced in one of the older VWs? Perhaps around version 2.5 or so. The Compiler could actually parse "parameter type checks using some <...>-syntax IIRC" but when I looked closer in the code it didn't actually do anything with it yet. Eh... have no idea why this popped up in my head right now. ;)
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 00:40:18 -0800
Todd Blanchard wrote:
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
Really? Namespaces? Modules? Interfaces? Every even remotely mainstream language I am aware about has at least two out of these three - you don't find those worthwhile?
So there is lots of great stuff to steal - but not much of it from the mainstream languages - they mostly seem to ape the last generation and then take a little lunge in the direction of Smalltalk.
I must admit I'm not particularly impressed with that overall assessment.
Cheers,
- Andreas
_________________________________________________________________ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...
J J wrote:
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
Modules is one area where IMO Java shines. Not necessarily because of the language part but because of the whole ClassLoader/JAR/Applet pipeline (just run Dan's SqueakOnJava in the browser and then think about what must be true to be able to handle that in a reasonably secure fashion). It's the best deployment solution I am aware of. In the namespace area I think Python wins hands-down, because they manage to tie namespaces (and modules) into the object model so nicely. Traits better than Interfaces? Well that remains to be seen.
Cheers, - Andreas
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Thu, 22 Feb 2007 22:05:50 -0800
J J wrote:
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
Modules is one area where IMO Java shines. Not necessarily because of the language part but because of the whole ClassLoader/JAR/Applet pipeline (just run Dan's SqueakOnJava in the browser and then think about what must be true to be able to handle that in a reasonably secure fashion). It's the best deployment solution I am aware of.
Ah, I wasn't thinking about them from that angle. Good point.
In the namespace area I think Python wins hands-down, because they manage to tie namespaces (and modules) into the object model so nicely. Traits better than Interfaces? Well that remains to be seen.
Interfaces in Java are mostly just a pain IMO. They provide a few extra protections here and there, and give the programmer hints as he browses the code, but since you can't add a default implementation to them they just enforce a certain level of code duplication. At least in my experience and most of the Java programmers I know (admittedly not the whole world).
So from a usefulness point of view I think Traits already should be better, and once the tools support them they will give the same hints the Java implementation does at least.
_________________________________________________________________ Dont miss your chance to WIN 10 hours of private jet travel from Microsoft® Office Live http://clk.atdmt.com/MRT/go/mcrssaub0540002499mrt/direct/01/
Hi JJ,
on Fri, 23 Feb 2007 16:51:04 +0100, you wrote:
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Thu, 22 Feb 2007 22:05:50 -0800
J J wrote:
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
Modules is one area where IMO Java shines. Not necessarily because of the language part but because of the whole ClassLoader/JAR/Applet pipeline (just run Dan's SqueakOnJava in the browser and then think about what must be true to be able to handle that in a reasonably secure fashion). It's the best deployment solution I am aware of.
Ah, I wasn't thinking about them from that angle. Good point.
In the namespace area I think Python wins hands-down, because they manage to tie namespaces (and modules) into the object model so nicely. Traits better than Interfaces? Well that remains to be seen.
Interfaces in Java are mostly just a pain IMO. They provide a few extra protections here and there, and give the programmer hints as he browses the code, but since you can't add a default implementation to them they just enforce a certain level of code duplication. At least in my experience and most of the Java programmers I know (admittedly not the whole world).
You can use Java's interfaces for modeling the dynamic binding[1] of Smalltalk ;-) At runtime, no change is needed in the JVM. But the existing gcj's require you to cast message sends. To get rid of the cost of the casts I run a small utility which patches the bytecodes in the .class files with noops. May sound crazy at first sight but, it works and I know of no bytecode verifier which complains (so much for the static checking == safe software mythodology ;-)
Here's how:
- create an empty interface, name it smalltalk - make a distinct new interface for each method - the latter extends the former
Then when you want to expose an implementor, just use " implements " as before, for example "implements smalltalk.doIt, smalltalk.printIt".
You can extend all the existing public non-final library classes with the above. The JVM will only throw an exception if an implementor is actually missing (like DNU does). And your instance variables and args and temps will be of the singular type smalltalk.
When time permits (rare) I work on a compiler which reads Smalltalk source code and emits JVM bytecode (already compiles itself). But blocks and exceptions will be a pain :(
So from a usefulness point of view I think Traits already should be better, and once the tools support them they will give the same hints the Java implementation does at least.
IMO Java's interfaces and Traits do not compare. To give a nogo example: with traits you can mix required methods and provided methods. Translated this means that your library classes would be abstract (and as a consequence cannot be instantiated within their own library). So people use newInstance() and then cast (sometimes preceded by Class.forName and other expensive reflections), all the way down the bloat.
/Klaus
P.S. from the doc of newInstance() "Use of this method effectively bypasses the compile-time exception checking that would otherwise be performed by the compiler". Not compile-time safe, that is.
----------- [1] http://www.ibm.com/developerworks/java/library/j-cb11076.html
J J wrote:
Interfaces in Java are mostly just a pain IMO. They provide a few extra protections here and there, and give the programmer hints as he browses the code, but since you can't add a default implementation to them they just enforce a certain level of code duplication. At least in my experience and most of the Java programmers I know (admittedly not the whole world).
The main problem is the (mostly) static nature of interfaces in Java. E.g., declaring them is a pain, otherwise I would disagree. If you want to share a default implementation use a subclass - one of the big problems I see with traits is that their interfaces get so specific that an *alternative* implementation becomes effectively impossible (therefore completely loosing the point about interfaces as abstractions).
For example, look at TAccessingMethodDictDescription (which is simply the first in the browser) - it is practically impossible to reimplement this (or any other) of the current traits for the class kernel in any way that doesn't exactly follow the current implementation (like if TAMD is responsible for accessing the method dictionary then we should be able to reimplement MD access without affecting any other trait, right?).
As I see it, there are *way* too many dependencies between these traits and interfaces can help to abstract from these dependencies. For sharing (default or not) implementation, Java (as well as Squeak) has a single inheritance tree which works for almost all purposes just fine. If you use delegation instead of inheritance it works for *everything* just fine and, IMO, typically results in a better set of collaborators because suddenly these roles become objects themselves.
So from a usefulness point of view I think Traits already should be better, and once the tools support them they will give the same hints the Java implementation does at least.
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Cheers, - Andreas
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Fri, 23 Feb 2007 22:35:35 -0800
The main problem is the (mostly) static nature of interfaces in Java. E.g., declaring them is a pain, otherwise I would disagree. If you want to share a default implementation use a subclass - one of the big problems I see with traits is that their interfaces get so specific that an *alternative* implementation becomes effectively impossible (therefore completely loosing the point about interfaces as abstractions).
Does it have to be this way, or are you looking at a... less then optimal use of a workable technology.
You asked before if I had used traits, and of course I haven't. I haven't felt the need to reach for them so far, and I am under the impression that the tools aren't ready anyway.
But I have used Type classes in Haskell which is where I am taking my vantage point from. For those who may not know, type classes just specify a specific "interface" (set of functions), and any type that wants to be in that type class must provide an implementation. The class definition can specify default implementations. For example:
class Eq where (==) lhs rhs = not (lhs != rhs) (!=) lhs rhs = not (lhs == rhs)
Now, as you notice, the definitions of those functions seem to depend on each other. The compiler would detect this and make an error, of course, if someone tried to use them both. It is simply a way to ensure that an instance must supply either one, but they don't have to supply both.
For me, this provides everything that Java interfaces do (including type safety. You can say e.g. my new function works on any type, so long as it implements the Eq class) and more, since the default implementation avoids so much code duplication [1].
I hear what you are saying about "use a base class", but does my base class still have to say "implements"?
Either way, this feels to me like another manifestation of a problem I always had with Java: implementation inheritance. I may make 3 totally different window widgets, and by rights each one would "implement" a draw API, but I will have to invent another class for them all to inherit to avoid duplicating a bunch of unrelated code. People reading my code may wonder why "3DGameWindow" is in the same tree as "TaskBarClockWidget", but it is just to save code duplication.
This is what I have hopes that Traits can help me avoid. I only inherit when there is an inheritance relationship present, and Traits are for the code that is in common but only as a coincidence (e.g. a car and a plane can both drive on a street, but the only thing I see in common are the wheels).
Personally my inheritance trees never get very deep. Normally just one level down.
For example, look at TAccessingMethodDictDescription (which is simply the first in the browser) - it is practically impossible to reimplement this (or any other) of the current traits for the class kernel in any way that doesn't exactly follow the current implementation (like if TAMD is responsible for accessing the method dictionary then we should be able to reimplement MD access without affecting any other trait, right?).
Is this a problem with the technology (Traits), or the implementation?
As I see it, there are *way* too many dependencies between these traits and interfaces can help to abstract from these dependencies. For sharing (default or not) implementation, Java (as well as Squeak) has a single inheritance tree which works for almost all purposes just fine. If you use delegation instead of inheritance it works for *everything* just fine and, IMO, typically results in a better set of collaborators because suddenly these roles become objects themselves.
Well that is a good technique. I don't personally see Traits as hammer or a silver bullet, but I do think they (at least have potential to) fill a hole [1].
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes).
Well, C++ was my favorite language for a long time (before I met Smalltalk :), and I have used it quite a bit. And I couldn't agree more. The only useful purpose I ever saw MI serve was just what you said.
And this is one thing I am paying attention to with the Traits stuff. There has been talk of adding variables to Traits and I (strongly) disagree with this idea. At that point, IMO it Traits would just be brining in MI through the back door. What I always think when I, or anyone else, came up with the need to do MI is "rethink the design". In every case I have ever seen, some other pattern has always been a better choice.
But since Traits can't have variables, I would expect them to be useful in many of the same ways Haskell type classes are. I could be wrong, but I hope I'm not and I can't think of a technical reason Traits must create fragility.
Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
I understand your concerns. I never want to see Smalltalk go down the MI road either. But for me, the presence of variables is what differentiates between MI and "interfaces with default implementations".
My point of view comes from seeing a system that has this and seems to work very well. I don't know what your experiences are, but if it's limited to C++ then I don't wonder at your skepticism. :)
But I also wonder if it is sort of a "hot button" issue. I mean, there are things to be frustrated/embarrassed about here (e.g. releasing something into the image that appears to have no means of maintaining).
[1] Imagine the situation you would be in in Java if all class that can be compared for equality must implement this interface! Every single class that implemented the interface would have one of those two functions just be a "not" of the other. And I don't think your solution of making a base class is going to work here because we may also want classes like Ord (less than, greater than) and so on. You would need a base class for every possible combination.
Of course the solution is to not have such a class, but is this the right solution? Shouldn't we have some fine grained reflective way of knowing if the class supports a specific protocol like equality?
_________________________________________________________________ Refi Now: Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-17727&moid=7...
J J wrote:
The main problem is the (mostly) static nature of interfaces in Java. E.g., declaring them is a pain, otherwise I would disagree. If you want to share a default implementation use a subclass - one of the big problems I see with traits is that their interfaces get so specific that an *alternative* implementation becomes effectively impossible (therefore completely loosing the point about interfaces as abstractions).
Does it have to be this way, or are you looking at a... less then optimal use of a workable technology.
Of course it doesn't have to be that way. But one of the hardest things to do is to be honest about how particular features of languages *actually* work out. It's like MI in C++ - of course there are ways of using it "right" it's just nobody seems to use it that way (although I will admit that my experience is dated - after having burned my fingers several times I never used MI again other than in the Java way, that is by using abstract virtual base classes).
[... snip ...]
I hear what you are saying about "use a base class", but does my base class still have to say "implements"?
That depends on your particular flavor of interfaces. BTW, I do see your point about Haskell but note that in your example you have both given the definition as well as the constraint on a particular interface - in my understanding this is more like specifying type algebra or pre/post condition and not as much about actually providing the code for the implementation.
Either way, this feels to me like another manifestation of a problem I always had with Java: implementation inheritance. I may make 3 totally different window widgets, and by rights each one would "implement" a draw API, but I will have to invent another class for them all to inherit to avoid duplicating a bunch of unrelated code. People reading my code may wonder why "3DGameWindow" is in the same tree as "TaskBarClockWidget", but it is just to save code duplication.
That's why I mentioned delegation. You could have an object encapsulating the drawing policy and have your three classes delegate to it. In which case you not only get the interface but also the ability to dynamically change the drawing policy - at the cost of (at least) one slot for the object representing the policy. To me, this is a much cleaner way of dealing with the problem you are describing while preserving all of the good properties of objects.
For example, look at TAccessingMethodDictDescription (which is simply the first in the browser) - it is practically impossible to reimplement this (or any other) of the current traits for the class kernel in any way that doesn't exactly follow the current implementation (like if TAMD is responsible for accessing the method dictionary then we should be able to reimplement MD access without affecting any other trait, right?).
Is this a problem with the technology (Traits), or the implementation?
There is not enough evidence to draw a conclusion yet. The evidence is that this implementation seems to have a problem towards that end and the implementation was strongly driven by the desire to eliminate code duplication (more so than to structure it into logical aspects). I think that the attempt to eliminate duplicate code at all costs using traits may ultimately lead to this effect simply because if you try to squeeze all the entropy out of the system then the result will be a static structure.
Interfaces on the other hand, precisely *because* of the overhead they require tend to be more minimal, therefore more abstract and therefore more easily to maintain and (re)implement.
Well that is a good technique. I don't personally see Traits as hammer or a silver bullet, but I do think they (at least have potential to) fill a hole [1].
Are we talking about a hole in Java or in Squeak? Your example only applies to Java, not to Squeak (which has had #=, #==, #~~ and #~= in Object from its very first day). For that particular problem we didn't need traits. Now, I'm not saying there aren't places in which traits can be usefully applied - in fact I am *dying* to see a good use case. One where they actually help to make things simpler, structures clearer, more easy to understand.
But since Traits can't have variables, I would expect them to be useful in many of the same ways Haskell type classes are. I could be wrong, but I hope I'm not and I can't think of a technical reason Traits must create fragility.
I need to read more about Haskell's type classes - I never looked too closely at them. Do they actually specify implementation or is it all type algebra (like in your example before)?
But I also wonder if it is sort of a "hot button" issue. I mean, there are things to be frustrated/embarrassed about here (e.g. releasing something into the image that appears to have no means of maintaining).
Of course it is frustrating. But what is worse is that while the paper examples all look fine I just haven't been able to find an improvement in understanding or design when I look at the (admittedly only) example of a real-world use. If that is the future with traits then it is a bleak future indeed. And of course it is quite possible that tools are missing, that early explorations go wrong but at least we should be honest enough to reflect critically on the artifact that was produced and see what is right and see what is wrong.
Cheers, - Andreas
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Traits vs. Interfaces (was Re: election details *PLEASE READ*) Date: Sat, 24 Feb 2007 01:21:59 -0800
Does it have to be this way, or are you looking at a... less then optimal use of a workable technology.
Of course it doesn't have to be that way. But one of the hardest things to do is to be honest about how particular features of languages *actually* work out. It's like MI in C++ - of course there are ways of using it "right" it's just nobody seems to use it that way (although I will admit that my experience is dated - after having burned my fingers several times I never used MI again other than in the Java way, that is by using abstract virtual base classes).
Well I agree. When people use something badly we must always ask ourselves if it was because the feature itself is bad. And we must be prepared to say yes. Two examples would be... the entire C++ language and the entire Perl language. It's always funny when people say "this is unreadable/unmaintainable!" and proponents simply say "but you *can* write readable code with it!".
I don't want Squeak/Smalltalk to be laughed at in this way, but at this point I feel, as you say, we don't have overwhelming evidence yet as my two examples do.
[... snip ...]
I hear what you are saying about "use a base class", but does my base class still have to say "implements"?
That depends on your particular flavor of interfaces. BTW, I do see your point about Haskell but note that in your example you have both given the definition as well as the constraint on a particular interface - in my understanding this is more like specifying type algebra or pre/post condition and not as much about actually providing the code for the implementation.
Well, I don't know what theories the Haskell community may try to place around what is happening, but I know what it actually does: it's just code implementations of those functions. If you wanted you could override both of those in your new type to just return False. The only constraint that was put in place was the function type signature (takes two of type anything as arguments and returns a boolean).
In fact you can use type classes to actually do OO, complete with (compile time) function overrides based on type. This I know from experience because I translated my Smalltalk Recurrence rules to Haskell directly, and it worked. :)
That's why I mentioned delegation. You could have an object encapsulating the drawing policy and have your three classes delegate to it. In which case you not only get the interface but also the ability to dynamically change the drawing policy - at the cost of (at least) one slot for the object representing the policy. To me, this is a much cleaner way of dealing with the problem you are describing while preserving all of the good properties of objects.
Yes, this is one reason I don't personally do a great deal of inheritance. I find that other relationships are often more appropriate.
Is this a problem with the technology (Traits), or the implementation?
There is not enough evidence to draw a conclusion yet. The evidence is that this implementation seems to have a problem towards that end and the implementation was strongly driven by the desire to eliminate code duplication (more so than to structure it into logical aspects). I think that the attempt to eliminate duplicate code at all costs using traits may ultimately lead to this effect simply because if you try to squeeze all the entropy out of the system then the result will be a static structure.
Yea, lack of tools are really hurting us here. Does anyone have a diagram or something on what traits are in the image, dependencies, etc.?
Interfaces on the other hand, precisely *because* of the overhead they require tend to be more minimal, therefore more abstract and therefore more easily to maintain and (re)implement.
But, as in my Eq, Ord example, this overhead may also ensure they are never used for one of things I think they are most applicable for.
Well that is a good technique. I don't personally see Traits as hammer or a silver bullet, but I do think they (at least have potential to) fill a hole [1].
Are we talking about a hole in Java or in Squeak?
I meant in OO in general. Not to say OO is flawed, just that this is a piece that was not part of the concept in the beginning (since it was probably decided that inheritance can handle all the cases, which is true. It's just a question of organization) that probably needs to be. And I feel safe saying this given the fact that every (most?) language that supports OO has some way of doing it.
Your example only applies to Java, not to Squeak (which has had #=, #==, #~~ and #~= in Object from its very first day). For that particular problem we didn't need traits.
I would disagree here. Well, not that you don't *need* traits. Obviously Smalltalk wasn't crippled without them, but something that fits this role (at least the role I envision them filling) does make things clearer IMO.
For example, you mentioned that Squeak has #=, #== etc, and that is true. And testing if an object is the same instance as another (#==) does make sense for all objects. But does #=? Are all objects capable of being able to compared to other objects for equality? What about #<, #>?
It is a powerful capability Squeak/Smalltalk has to ask an object if it implements a method. But in the case where someone asks if an object implements #=, what they really want to ask is "are you an object that can be compared to another for equality?". And that implies not only #=, but at least unequal as well.
I don't know exactly what Traits have been used for in the image, but I see them as the solution to the "protocol" question that comes up from time to time. You can do the same thing with inheritance but you end up with either really odd trees (e.g. ObjectWithEquality, ObjectWithoutEquality, ObjectWithEqualityAndOrdering), or a lot of #shouldNotImplement.
But since Traits can't have variables, I would expect them to be useful in many of the same ways Haskell type classes are. I could be wrong, but I hope I'm not and I can't think of a technical reason Traits must create fragility.
I need to read more about Haskell's type classes - I never looked too closely at them. Do they actually specify implementation or is it all type algebra (like in your example before)?
My example before was showing the actual implementation. What you may be thinking of is that often the default implementation isn't given, just the type signature. This would have looked like:
class Eq a where (==) a -> a -> Boolean -- takes any type, followed by another of that same type (!=) a -> a -> Boolean -- and returns a Boolean.
In that case, you are just specifying what functions must be present, and giving their type signature. What I showed above gave two default implementations (and left out the type signature to be deduced by the compiler). That way, if you go against the tide an decide only to implement (!=) then == will work sensibly (since it just calls not on the results of your ==).
But I also wonder if it is sort of a "hot button" issue. I mean, there are things to be frustrated/embarrassed about here (e.g. releasing something into the image that appears to have no means of maintaining).
Of course it is frustrating. But what is worse is that while the paper examples all look fine I just haven't been able to find an improvement in understanding or design when I look at the (admittedly only) example of a real-world use. If that is the future with traits then it is a bleak future indeed. And of course it is quite possible that tools are missing, that early explorations go wrong but at least we should be honest enough to reflect critically on the artifact that was produced and see what is right and see what is wrong.
Well, I think the tools are the problem here. Either there are not any, or at least no one seems to know where they are (I know I don't, and I see the question come on the list just about anytime says "Traits").
And I suppose another problem is, Traits are kind of an advanced feature. The case of Eq, Ord and similar are very simple. But what about Seaside? Should render classes all inherit from one, or are they simply unrelated classes that happen to have a specific trait (the ability to render) in common?
My take in this would be rendering classes inherit, but classes that get rendered may just have "renderable" trait since many of them (at least the ones I make) are complete domain objects that just happen to implement the #renderOn: message.
But even in this contrived example, we can see that there can be ambiguity in how they are used, and therefor they can be used wrong. Whether this is a "this language is unreadable/unmaintainable!" level issue is something we will have to discover.
_________________________________________________________________ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline
On Feb 24, 2007, at 1:21 AM, Andreas Raab wrote:
It's like MI in C++ - of course there are ways of using it "right" it's just nobody seems to use it that way
You can say that about any 10 features of C++. It is why I bailed on it.
Virtual inheritance BTW, while theoretically available - didn't become reliably implemented across compilers until around 1996. Considering that I started using C++ in 1992 - I never felt comfortable using it as everytime I tried some platform somewhere would turn out to have a broken implementation.
Pure abstract virtual base classes was the only thing that worked well.
Templates were like that too - the only ones that worked were the ones you could inline.
Ah the memories - must remember to get them wiped.
-Todd Blanchard
You really ought to look into ObjectiveC's Protocols. Because they blow interfaces all to hell in terms of flexibility and Java's interfaces are borrowed from that (if one is to believe the Gosling apologists).
I really like ObjectiveC's protocols and categories. To me, traits look like categories with the class parameterized. This is to say - you can declare a set of extension method in ObjectiveC as an extension on a particular class. It would be nice to be able to declare that set of extension methods, then say later on to what classes they should be applied (which is kind of what traits does).
I really dislike Java's interfaces because they still leave you copying and pasting code like crazy or hand stitching glue.
They only semi-sane strategy I've seen for sharing code is to store it in the interface as static methods (you can put static methods in an interface with implementation).
Then, you get to hand write a bunch of glue like this:
interface Foo { abstract void bar(); static void bar_impl(Foo f) { /*default implementation of foo */} }
class Baz implements Foo { void bar() { return Foo.bar_impl(this); } }
Which seems like a lot of busy work to me and makes me develop facial ticks everytime I contemplate using a large interface widely. -Todd Blanchard
On Feb 23, 2007, at 10:35 PM, Andreas Raab wrote:
Java interfaces are "nothing but abstract virtual base classes in C+ +" - which coincidentally, was the only way that MI ever worked in C ++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent).
On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Forgive me, but I am not familiar with "All the problems Multiple Inheritance got wrong". I will be testing out how Multiple Inheritance works in Squeak, since I have made it my top priority to get ThingLab [1] working in a recent Squeak system. ThingLab adds multiple inheritance [2] and a constraint solver to Smalltalk, and both have at least a good theoretical reason to be there, but I cannot test the implementation yet, since such a change currently breaks squeak. Multiple Inheritance has at least a solid theory; I have not had much experience with an implementation.
[1] http://wiki.squeak.org/squeak/607 Links to ThingLab papers and code.
[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html Chapter 3 of the ThingLab paper. Section 2 contains a defense of ThingLab's multiple inheritance.
How is the Thinglab rework going? What needs to be done to get it running? How about in 3.8?
Cheers,
Alan
-------------
At 11:32 PM 2/28/2007, Matthew Fulmer wrote:
On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Forgive me, but I am not familiar with "All the problems Multiple Inheritance got wrong". I will be testing out how Multiple Inheritance works in Squeak, since I have made it my top priority to get ThingLab [1] working in a recent Squeak system. ThingLab adds multiple inheritance [2] and a constraint solver to Smalltalk, and both have at least a good theoretical reason to be there, but I cannot test the implementation yet, since such a change currently breaks squeak. Multiple Inheritance has at least a solid theory; I have not had much experience with an implementation.
[1] http://wiki.squeak.org/squeak/607 Links to ThingLab papers and code.
[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html Chapter 3 of the ThingLab paper. Section 2 contains a defense of ThingLab's multiple inheritance.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
The problems with MI are basically the same as manual memory management: (a) to easy to shoot yourself and anyone near you and (b) hinders composability/encapsulation.
The problem is, if you have multiple inheritance then from now on people probably need to know what classes any class they inherit from inherit from themselves, since you may be introducing the same base classes from different hierarchies points.
There are ways to deal with it of course, but for me it is a red flag that maybe I am walking down the wrong road when I see such things. Especially when an "interfaces with default implementations" seems to work so well.
From: Matthew Fulmer tapplek@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Thu, 1 Mar 2007 00:32:32 -0700
On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Forgive me, but I am not familiar with "All the problems Multiple Inheritance got wrong". I will be testing out how Multiple Inheritance works in Squeak, since I have made it my top priority to get ThingLab [1] working in a recent Squeak system. ThingLab adds multiple inheritance [2] and a constraint solver to Smalltalk, and both have at least a good theoretical reason to be there, but I cannot test the implementation yet, since such a change currently breaks squeak. Multiple Inheritance has at least a solid theory; I have not had much experience with an implementation.
[1] http://wiki.squeak.org/squeak/607 Links to ThingLab papers and code.
[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html Chapter 3 of the ThingLab paper. Section 2 contains a defense of ThingLab's multiple inheritance.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_________________________________________________________________ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...
Matthew Fulmer wrote:
On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Forgive me, but I am not familiar with "All the problems Multiple Inheritance got wrong". I will be testing out how Multiple Inheritance works in Squeak, since I have made it my top priority to get ThingLab [1] working in a recent Squeak system. ThingLab adds multiple inheritance [2] and a constraint solver to Smalltalk, and both have at least a good theoretical reason to be there, but I cannot test the implementation yet, since such a change currently breaks squeak. Multiple Inheritance has at least a solid theory; I have not had much experience with an implementation.
[1] http://wiki.squeak.org/squeak/607 Links to ThingLab papers and code.
[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html Chapter 3 of the ThingLab paper. Section 2 contains a defense of ThingLab's multiple inheritance.
There is a newer constraint solver package called *Cassovary, that Joshua Gargus ported to Squeak. I have a changeset I can digg up if you are interested.
Karl *
Andreas Raab andreas.raab@gmx.de writes:
J J wrote:
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
Modules is one area where IMO Java shines. Not necessarily because of the language part but because of the whole ClassLoader/JAR/Applet pipeline (just run Dan's SqueakOnJava in the browser and then think about what must be true to be able to handle that in a reasonably secure fashion).
Security I'll give you. That would be great if Squeak could do that. Python, incidentally, can do such things with its module system. We could have that too, but having it plus also keeping our existing code running is a really hard pair of features.
Anyway, the rest of Java's modules system I don't like at all. Let me mention two major problems.
First, it is troublesome to assemble groups of jar's along with their dependencies for both compilation and execution. It takes a while to track down all the necessary jar's, and it is hard to debug errors having to do with using the wrong version or with jar's that are only accessed on some control paths. To contrast, the ELF loader on Linux blows it away. You compile with -lm and get the math library plus its dependencies. You then run the resulting executable, with no extra arguments at all. Why doesn't Java work like that? Is C technology too advanced?
Second, linking jar's of different versions gives a lot of spurious errors. Package Universes for Squeak has a big advantage over the same thing for Scala in that department. It is rare for a Scala package to remain usable for longer than a couple of months, because the packages it links against keep getting changes in the signatures and the Java type checker complains. To contrast, some of the packages in the 3.9 stable universe are over a year old.
It is to the point that Scala users periodically request on the list that its version of package univeres use a non-JAR format. I wish I had time to design one, because I think they are right. JAR is an awkward format.
-Lex
Hi Lex -
Your criticism is well received and understood but unless you have an alternative it is also utterly pointless. We can discuss the various flaws in the Java module system to death but it doesn't change the fact that it is there and it actually works. If you do know of any alternatives that allow for scalable and reasonably secure deployment of code in effectively unknown environments, I'll happily look at them. If they are better than Java, great. It's just ... that so far there are so damn few (if any) alternatives.
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
Cheers, - Andreas
Lex Spoon wrote:
Andreas Raab andreas.raab@gmx.de writes:
J J wrote:
Namespaces ok, but the way they have been done is not always that great. Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo.
Modules is one area where IMO Java shines. Not necessarily because of the language part but because of the whole ClassLoader/JAR/Applet pipeline (just run Dan's SqueakOnJava in the browser and then think about what must be true to be able to handle that in a reasonably secure fashion).
Security I'll give you. That would be great if Squeak could do that. Python, incidentally, can do such things with its module system. We could have that too, but having it plus also keeping our existing code running is a really hard pair of features.
Anyway, the rest of Java's modules system I don't like at all. Let me mention two major problems.
First, it is troublesome to assemble groups of jar's along with their dependencies for both compilation and execution. It takes a while to track down all the necessary jar's, and it is hard to debug errors having to do with using the wrong version or with jar's that are only accessed on some control paths. To contrast, the ELF loader on Linux blows it away. You compile with -lm and get the math library plus its dependencies. You then run the resulting executable, with no extra arguments at all. Why doesn't Java work like that? Is C technology too advanced?
Second, linking jar's of different versions gives a lot of spurious errors. Package Universes for Squeak has a big advantage over the same thing for Scala in that department. It is rare for a Scala package to remain usable for longer than a couple of months, because the packages it links against keep getting changes in the signatures and the Java type checker complains. To contrast, some of the packages in the 3.9 stable universe are over a year old.
It is to the point that Scala users periodically request on the list that its version of package univeres use a non-JAR format. I wish I had time to design one, because I think they are right. JAR is an awkward format.
-Lex
On 1 mars 07, at 06:59, Andreas Raab wrote:
Hi Lex -
Your criticism is well received and understood but unless you have an alternative it is also utterly pointless. We can discuss the various flaws in the Java module system to death but it doesn't change the fact that it is there and it actually works. If you do know of any alternatives that allow for scalable and reasonably secure deployment of code in effectively unknown environments, I'll happily look at them. If they are better than Java, great. It's just ... that so far there are so damn few (if any) alternatives.
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example. May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Stef
stephane ducasse wrote:
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example.
Here are some "simple" issues: How do Parcels deal with conflicting modifications to base classes? Say, one that says "Object>>isCommon ^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't allow modifications to base classes which, really, isn't such a bad thing from the point of view of modularity)
Another one: Which assurances do parcels give in terms of security? As far as I know there is no bytecode verifier, parcel have full access to the entire Smalltalk namespace (covered by ClassLoaders in Java), there are no limitations in terms of what operations a parcel can perform (nil become: true; Java had a good set of fixes in this area to get it right and not to leak ambient authority) and I don't think VW even knows what a sandbox is.
A third one: Which namespace are parcels loaded into? Can two different versions of parcels be loaded side-by-side? How (if at all) do they affect each other? Etc.
May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects and change sets and it seems to work, too. Sorta. Kinda. :-)
Cheers, - Andreas
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
Kind of JARs in Smalltalk? Pleeeeeease, please, please, please don't do that, no! *scream*
I've done Java in my main job since 1996 till last year from very small projects up to very large applications. And we allways have been fighting with JARs. They are a kind of a DLL hell, but only for the Java environment. Especially if you integrate different open source and commercial frameworks. They all use other frameworks, but almost every time in a different version. So you're fighting with the order inside your CLASSPATH every day and sometime have no way to resolve the conflicts. *sigh*
.NET has version numbers in their assemblies. So you can deploy the same assembly in different versions in the same system. But still own installed applications are depending on those external assemblies. That often leads to problems too.
What I really like when working with VisualWorks is, that I integrate the right parcels into my image, most time without version conflicts. And if there's one detected through my tests I can fix it inside my image. This image is then deployed en bloc, well tested and not relying on the admin to configure the libs the right way.
mue
On 1 mars 07, at 10:22, Andreas Raab wrote:
stephane ducasse wrote:
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example.
Here are some "simple" issues: How do Parcels deal with conflicting modifications to base classes? Say, one that says "Object>>isCommon ^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't allow modifications to base classes which, really, isn't such a bad thing from the point of view of modularity)
yes but you cannot have extra behavior and subclass does not solve the problem. I can show a lot of problems where not having class extension can be killing you.
Another one: Which assurances do parcels give in terms of security? As far as I know there is no bytecode verifier, parcel have full access to the entire Smalltalk namespace (covered by ClassLoaders in Java), there are no limitations in terms of what operations a parcel can perform (nil become: true; Java had a good set of fixes in this area to get it right and not to leak ambient authority) and I don't think VW even knows what a sandbox is.
A third one: Which namespace are parcels loaded into? Can two different versions of parcels be loaded side-by-side? How (if at all) do they affect each other? Etc.
I think so. In fact in VW3.0 there were a hidden namespace just to be able to have atomic unloading.
May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects and change sets and it seems to work, too. Sorta. Kinda. :-)
Cheers,
- Andreas
On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:
stephane ducasse wrote:
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example.
Here are some "simple" issues: How do Parcels deal with conflicting modifications to base classes? Say, one that says "Object>>isCommon ^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't allow modifications to base classes which, really, isn't such a bad thing from the point of view of modularity)
Last one wins.
Not that the fact that the Java does not allow modifications to baseclasses (nor even subclassing in most cases), causes us all kinds of problems.
Another one: Which assurances do parcels give in terms of security? As far as I know there is no bytecode verifier, parcel have full access to the entire Smalltalk namespace (covered by ClassLoaders in Java), there are no limitations in terms of what operations a parcel can perform (nil become: true; Java had a good set of fixes in this area to get it right and not to leak ambient authority) and I don't think VW even knows what a sandbox is.
Security is the one and only advantage of JARs, I fully agree.
A third one: Which namespace are parcels loaded into? Can two different versions of parcels be loaded side-by-side? How (if at all) do they affect each other? Etc.
A temporary one because the load is atomic and can be reverted. Once the load succeeds the code is put in the image. Parcels work pretty well for code deployment. See the paper Eliot and I wrote for ESUG a couple of years ago (it is on my webpage).
May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects and change sets and it seems to work, too. Sorta. Kinda. :-)
rofl :-)
Cheers,
- Andreas
2007/3/5, Roel Wuyts Roel.Wuyts@ulb.ac.be:
On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:
stephane ducasse wrote:
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example.
Here are some "simple" issues: How do Parcels deal with conflicting modifications to base classes? Say, one that says "Object>>isCommon ^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't allow modifications to base classes which, really, isn't such a bad thing from the point of view of modularity)
Last one wins.
Not that the fact that the Java does not allow modifications to baseclasses (nor even subclassing in most cases), causes us all kinds of problems.
Another one: Which assurances do parcels give in terms of security? As far as I know there is no bytecode verifier, parcel have full access to the entire Smalltalk namespace (covered by ClassLoaders in Java), there are no limitations in terms of what operations a parcel can perform (nil become: true; Java had a good set of fixes in this area to get it right and not to leak ambient authority) and I don't think VW even knows what a sandbox is.
Security is the one and only advantage of JARs, I fully agree.
A third one: Which namespace are parcels loaded into? Can two different versions of parcels be loaded side-by-side? How (if at all) do they affect each other? Etc.
A temporary one because the load is atomic and can be reverted. Once the load succeeds the code is put in the image. Parcels work pretty well for code deployment. See the paper Eliot and I wrote for ESUG a couple of years ago (it is on my webpage).
At ESUG 2006 James Robertson said he doesn't use Parcels for code deployment because they are just not reliable (of course he doesn't use store either). He uses change sets (or .st files, I don't remember exactly) instead.
Philippe
May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects and change sets and it seems to work, too. Sorta. Kinda. :-)
rofl :-)
Cheers,
- Andreas
Note that JAR files are not really what I would call a module mechanism; I am currently fighting them in the context of a not-quite- trivial application with lots of dependencies and boy, I wish that they would be somewhat more robust. Dependency management, version management and is simply not handled. Let alone proper packaging with 'open classes' or 'class extensions' (so that you cannot even properly deploy a visitor pattern independently from the hierarchy it works on, actually the key of that pattern). Or another one of my favourites, which was properly handled in the Envy system btw, conditional loading of modules/code. No such luck :-(
The people at Eclipse had to work around all of this; all the plug-in stuff of Eclipse is done via their own mechanism built on top of Java such that they actually can deploy plug-ins a bit easier. And even then it is not possible to unload (!!!!!) any code, and the result is a difficult beast with XML config files that interact with the JARs things etc. Ugly, ugly, ugly.
I haven't looked at it in any detail, but if you want to look at module mechanisms from mainstream languages that are being used I would look at the one in C#. At least you have major and minor version numbers ;-) Anybody had a look at that ?
On 01 Mar 2007, at 1 March/10:22, Andreas Raab wrote:
stephane ducasse wrote:
In short: What impresses me about the Java solution is not that it's flawless - what impresses me is that it works, that people actually use it to deploy code and this code actually works in the way intended.
But do you think that VW, VA code does not work once deployed? I would like to understand why Jar are better than parcels for example.
Here are some "simple" issues: How do Parcels deal with conflicting modifications to base classes? Say, one that says "Object>>isCommon ^true" and one that says "Object>>isCommon ^false"? (Java simply doesn't allow modifications to base classes which, really, isn't such a bad thing from the point of view of modularity)
Another one: Which assurances do parcels give in terms of security? As far as I know there is no bytecode verifier, parcel have full access to the entire Smalltalk namespace (covered by ClassLoaders in Java), there are no limitations in terms of what operations a parcel can perform (nil become: true; Java had a good set of fixes in this area to get it right and not to leak ambient authority) and I don't think VW even knows what a sandbox is.
A third one: Which namespace are parcels loaded into? Can two different versions of parcels be loaded side-by-side? How (if at all) do they affect each other? Etc.
May be I should post to VW to see what are the problem with deployed code in VW. A parcel in VW has dev and depl prerequisites and it seems to work too.
Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with projects and change sets and it seems to work, too. Sorta. Kinda. :-)
Cheers,
- Andreas
+1. Python was mentioned before, but I use a little python every day at work (and a lot on some days). It's not a bad language as script languages go, but what does it have that is special really? A flexible module system. That is seriously the only thing I can think of.
And I am with you on Erlang as well. I have been thinking about what it would take to make a Squeak package that does that. In fact, looking at Squeaksource I think I saw some that might already be close. :)
I think making Commanche a viable web serving platform end-to-end would be a bin win. A lot of synergy is there to be had for such systems.
And watching people get excited about Eclipse being able to run a little code and then change it "live" was a pretty vivid demo of what you are saying (I've been saying it a while myself) about languages trying to converge on smalltalk.
From: Todd Blanchard tblanchard@mac.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: election details *PLEASE READ* Date: Wed, 21 Feb 2007 00:24:33 -0800
On Feb 20, 2007, at 11:57 PM, Alan Lovejoy wrote:
Your comment made me think of the difference in attitude between French speakers and English Speakers.
I don't find this analogy particularly compelling. I don't think people are really trying to keep Smalltalk 'pure'. I think they're trying to find ways to improve it. Lots of things have been tried - multiple inheritance, prototype based vs class based models, access control wrappers, etc... The cool thing is you can make it what you want already. The trick is getting your nifty thing adopted into the standard package.
Other programming languages have been stealing from Smalltalk for decades. It's time we returned the favor.
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
I have been looking at erlang recently and find some of the parallel/ process/queue constructs interesting and would love to try to bring some of that over and try building a high performance web server based on those patterns.
And then, of course, there are interesting technologies that have nothing to do with the language but would make a great addition to the platform. Like Supple http://www.cs.washington.edu/ai/supple/ - a really nifty demo I saw last year.
So there is lots of great stuff to steal - but not much of it from the mainstream languages - they mostly seem to ape the last generation and then take a little lunge in the direction of Smalltalk.
-Todd Blanchard
_________________________________________________________________ Want a degree but can't afford to quit? Top school degrees online - in as fast as 1 year http://forms.nextag.com/goto.jsp?url=/serv/main/buyer/education.jsp?doSearch...
On 21 févr. 07, at 09:24, Todd Blanchard wrote:
On Feb 20, 2007, at 11:57 PM, Alan Lovejoy wrote:
Your comment made me think of the difference in attitude between French speakers and English Speakers.
I don't find this analogy particularly compelling. I don't think people are really trying to keep Smalltalk 'pure'. I think they're trying to find ways to improve it. Lots of things have been tried
- multiple inheritance, prototype based vs class based models,
access control wrappers, etc... The cool thing is you can make it what you want already. The trick is getting your nifty thing adopted into the standard package.
Other programming languages have been stealing from Smalltalk for decades. It's time we returned the favor.
I'm in favor of that - but honestly, there hasn't been a lot worth stealing from the mainstream.
I have been looking at erlang recently and find some of the parallel/process/queue constructs interesting and would love to try to bring some of that over and try building a high performance web server based on those patterns.
And then, of course, there are interesting technologies that have nothing to do with the language but would make a great addition to the platform. Like Supple http://www.cs.washington.edu/ai/supple/
- a really nifty demo I saw last year.
Sounds really interesting for small devices. Thanks for the pointer.
So there is lots of great stuff to steal - but not much of it from the mainstream languages - they mostly seem to ape the last generation and then take a little lunge in the direction of Smalltalk.
-Todd Blanchard
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Alan Kay -
Andreas Raab -
Blake -
Cees de Groot -
Damien Cassou -
danil osipchuk -
Frank Mueller -
Göran Krampe -
J J -
Karl -
Klaus D. Witzel -
Lex Spoon -
Mark S. Miller -
Matthew Fulmer -
nicolas cellier -
Philippe Marschall -
Ramon Leon -
Roel Wuyts -
stephane ducasse -
Stéphane Rollandin -
Todd Blanchard