Re: [squeak-dev] Re: [Pharo-project] 16rff is looking for a fix :)
Locked
Re: [squeak-dev] Re: [Pharo-project] 16rff is looking for a fix :)
 
|
On Thu, Feb 11, 2010 at 2:59 PM, Andreas Raab <[hidden email]> wrote: Eliot Miranda wrote: Doh!
I agree. But every little bit helps :) The reality is that there's no way to address his issues because there's no single owner of the brand. Balkanization (which is precisely the right term) happens when you don't have a strong central power which can keep everyone at bay (such as Yugoslavia did before it fell apart). Java for example is owned by Sun and Sun went to court with Microsoft to ensure brand integrity. Unless you have an owner of "Smalltalk" (whatever that is) there isn't going to be a consistent set of libraries because everyone can and will push into different directions. I disagree. I think the community has managed to agree on the utility of several things. Many of the Squeak collection extensions have found their way into VisualWorks for example because they're clearly useful and convenient. I think the problem with the standard is architectural, and that that architectural limitation was built-in from the get-go It was intended to be something the vendors could agree upon, not a useful standard. The issue for the vendors was in having a check-box for Smalltalk compared to other languages; C had a standard, C++ had a standard, so Smalltalk needed one. ut the standard wasn't useful for the community, and I think as a result hasn't been that useful for the vendors. Being x3j20-compatible didn't mean enough.
But at the time things were very different. Test suites were not in widespread use and no one had developed one yet. A good thing to come out of x3j20 and the first CampSmalltalk was a test suite. The web was in its infancy; there was no javadoc or www.python.org/doc/. Squeak was very young. So it's not surprising that the standard failed to be that useful. The world changed very quickly soon there-after.
A differently-architected standard could be useful and a gently unifying force. But it needs to address the challenges of standardising Smalltalk as it exists in its current context, not as it was in the early 90's.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [Pharo-project] 16rff is looking for a fix :)
|
|
Eliot Miranda wrote:
> I disagree. I think the community has managed to agree on the utility > of several things. Many of the Squeak collection extensions have found > their way into VisualWorks for example because they're clearly useful > and convenient. I think the problem with the standard is architectural, > and that that architectural limitation was built-in from the get-go It > was intended to be something the vendors could agree upon, not a useful > standard. The issue for the vendors was in having a check-box for > Smalltalk compared to other languages; C had a standard, C++ had a > standard, so Smalltalk needed one. ut the standard wasn't useful for > the community, and I think as a result hasn't been that useful for the > vendors. Being x3j20-compatible didn't mean enough. As much as I agree with the standard being problematic in itself, I'd still think that the main issue is elsewhere. In its shortest form, this comment on Ken's blog sums it up nicely: "what if we do not like VW Namespace?" The point is that your assumption of universal agreement on what "the standard" entails is simply naive. There will be things that some people like and others that they don't. If you want them all to agree and to actually implement what the standard says, you'll end up with a watered down version like ANSI Smalltalk (which is weak enough that people can pick and choose and still claim to be "compliant"). But if you want a strong, consistent, meaningful standard then you'll face resistance (i.e., "what if we do not like feature xyz"). And then the question becomes: What'cha gonna do about it? As it stands it's a no-win situation and the only way to break out of it is to write new libraries that can be used anywhere. Seaside / Grease is one interesting direction, perhaps Xtreams can become another one. Throw in a portable and free collections, numerics, and network package and you're halfways there. To me, that's the only way to get this done. Don't write a standard - write code instead! Make it portable, get other projects to use it, and just leave the vendors in the dust. Define a brand, perhaps "Common Smalltalk Libraries" that a group can own and control and define that you can call yourself "CSL compliant" if you pass the tests provided by CSL. All of them. Cheers, - Andreas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |