Smalltalk

Generalized collection access and Smalltalk evolution

February 15, 2005 13:00:52.757

There has been an interesting discussion in the vwnc mailing list about generalized collection access, but it begs the question I keep asking but never get an answer to; namely, what is the process by which Smalltalk can evolve? In this case, it would be evolution of the core class libraries, but the larger question includes the syntax and semantics of the entire language.

Sure, people can always extend whatever classes they want (one of the beauties of Smalltalk), but what's the process for getting changes evaluated in a systematic way and either rejected or incorporated in the "official" language? Or are we stuck forever with the Blue-book definition of Smalltalk?

Of course, there have been some changes over the last 25 years, but they've been completely at the (dare I say) whim of individual vendors. There seems to be little (if any) discussion of language issues among the increasing number of Smalltalk vendors. Is this the best this community can do?

I asked these question at the last Smalltalk Solutions, at a panel discussion on the future of the language, suggesting that maybe the Smalltalk Industry Council had a role to play. The response I got was that STIC was strictly a volunteer effort by already overworked people. OK, but that doesn't answer the question: should there be an "official" process by which Smalltalk can evolve?

Comments

Extending Smalltalk

[Peter William Lount] February 15, 2005 15:05:13.445

I have a series of articles and resources going at Extending Smalltalk that is attempting to provide a focal point for this important discussion.

"Our aim is to explore these variations/extensions and see which ones are the future of Smalltalk. Smalltalk.org is prepared to be a clearing house for existing and proposed enhancements to Smalltalk. One central place for all the materials on this important topic. Send in any and all related materials. Send in your proporsals, comments, desired objectives, goals and outcomes. Let the community know your, and your company's, point of view on any and all Smalltalk Language enhancements and extensions. Vendors and other version providers, let the community know your important point of view on the matter."

Generalized collection access and Smalltalk evolution

[ Rich Demers] February 15, 2005 16:19:25.108

Comment by Rich Demers

Peter,

It's great that you are accumulating this material, but that is not enough by itself.

  • You need a process

    by which the material can be evaluated.
  • You need an organization to execute the process.
  • And you need a way to document and publish the material the process accepts. Whether any vendors actually build what's in the document is another story entirely, but don't discount its importance.

You might want to look up the following entries in my blog on this subject:

Generalized collection access and Smalltalk evolution

[ James Robertson] February 15, 2005 16:27:04.908

Comment by James Robertson

Rich,
What extensions would you expect at the language level?

Generalized collection access and Smalltalk evolution

[ Rich Demers] February 15, 2005 19:48:48.042

Comment by Rich Demers

Jim,

Mostly, I'm trying to say that the door should not be completely and absolutely closed to language (syntax and semantics) changes; that it should be possible to propose such changes to the Smalltalk community for evaluation and possible inclusion. Here's a couple of possibilities that I have seen in the past (plus some of my own opinions):

  1. Evaluated literal arrays of the form: 

    	x := 10.
	y := #(1 x 30 (x   4) 50)

    which would eliminate a lot of with:with: with: ugliness.
  2. Keyword methods with optional arguments, optional argument order, and optional default argument values. This would eliminate a lot of essentially duplicated methods created just to provide better interfaces.
  3. Support for functional programming operators, such as FScript has proposed. This would do as much to enhance the power of the language as Smalltalk's enumeration methods. The syntactic changes required appear to be minor.
  4. Cleanup and completion of some of the Core class protocols. For example, there is a #copyFrom:to: method but there is no #copyFrom: (to end) or #copyTo: (from start) method (which I always find annoying and create as extensions). There are a lot of other examples like this that can be cited.
  5. Protocols should become real objects, and members of a nameSpace.
  6. Events should become real objects, and members of a nameSpace. I predict that this one is going to hit VW hard when advanced GUI tools based on Pollock are developed.
  7. Bundles and packages should become part of the language, and not just Store artifacts. They too should be members of a nameSpace.

More than anything else, we need to better cohere as a functioning community, and not just as a bunch of slightly related special interests.

Generalized collection access and Smalltalk evolution

[ James Robertson] February 15, 2005 20:10:17.442

Comment by James Robertson

Well, I'm not too sure about some of those. Protocols? Right now, they are just strings. If you put methods in a namespace (which is what you seem to be hinting at), you end up with a rather large tool/presentation problem. Personally, I think that particular cure might be worse than the disease. Events are objects already - go look it up :)

traits first

[Sascha Doerdelmann] February 16, 2005 4:18:21.310

Before you start to change the class hierarchy or the interfaces of any common class, you'll need the means for a proper design. Code organisation into namespaces, packages and protocols is useful but I doubt that you get to a clean design as long as you don't have traits or mixins as part of the core system.

Cheers Sascha

Generalized collection access and Smalltalk evolution

[ Rich Demers] February 16, 2005 8:37:16.737

Comment by Rich Demers

Sascha,

You may be right about traits and mixins, but how would you expect them to ever make it into the base language if there is no community process for evaluating ideas (good and bad). Frankly, if such a process were ever to be initiated, it would do best to start with small proposals (such as, evaluated literal arrays) and gain some experience before tackling more global ones.

Generalized collection access and Smalltalk evolution

[ Rich Demers] February 16, 2005 9:00:57.899

Comment by Rich Demers

Jim,

This isn't the right forum for evaluating individual ideas. What I'm saying is that the Smalltalk community needs such a forum. Otherwise, it is just too easy to "file and forget" and stick with the status quo. And that, in the long run, is death -- the basic lesson of evolution.

Having said that, I'll address some of your points in other blog entries.

[Smalltalk Musings] Generalized collection access and Smalltalk evolution

[ Travis Griggs] February 16, 2005 13:13:06.552

Comment by Travis Griggs

Rich, why not try this experiment. Take it upon yourself to maintain a set of useful extensions. Create a package in the OR. You've actually done that already. Now start putting stuff in there. You probably need to refrain from putting your own extensions in there. Just harvest other peoples'. Maybe in time, other people will help referee which extensions are deemed worthy to be added in. For starters, you have to assume that responsibility yourself. I'd be very supportive of seeing such a thing. I'd even volunteer to help, but I don't think that would be good. I post lots of whacky/controversial/whatever extensions already, so I don't think I'd be a good candidate for acting as a judge of what might be "important to the community." It's not a big process or body. But it's a start. And a start may grow into something more. But a rant won't.

Shaping Evolution with Iterative Design

[Peter William Lount] February 16, 2005 14:01:20.949

Shaping Evolution with Iterative Design has a few comments related to these proposals.

I agree with you Richard that more than the article series is needed.