[SoC] topics

[Brian Rice]

Hi Ralph,

On Mar 29, 2007, at 9:17 AM, Ralph Johnson wrote:

> The proposals tend to fall into several categories, and there are some
> proposals that are very similar.  There are in fact five proposals
> (from four people) that propose adding a module to Seaside to make it
> like Ruby on Rails.  I think that this topic has the biggest potential
> to make an impact.  Seaside is powerful, but it is not easy to learn
> for people who do not already know Smalltalk well.  If there was a
> "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside
> (and Squeak) could really take off.
>
> It looks to me like these proposals are being overlooked by the
> mentors, perhaps because none of us are web developers or have used
> Ruby on Rails.  I haven't use it either, but I have read the
> documentation and I can see why it has made such a big impact.  I'd
> love to see Squeak capture some of that market.  So, I urge mentors to
> read these proposals and to vote on them.

I am familiar with Ruby on Rails (I used it to mock up a couple of  
social-sharing microcontent sites with tagging and AJAX-y goodness),  
but I'm not really giving them intense attention, simply because this  
is a very obvious set of improvements to make, and RoR has enough  
documentation that it's been enough to point students to the Seaside  
components and documented information (scattered in blog posts and  
mailing list comments, mostly) corresponding with particular features  
of Rails.

The real issue (if there really is one) is that the mentors aren't  
Seaside experts who've been using it in production for a long time.  
Basically half of those guys are on the DabbleDB project, and then  
there's Todd working with an old client of theirs, and the  
NetStyles.ch group. Seaside doesn't feel like something we have a  
strong link to its pulse, the direction it's going.

> There are a lot of tool-oriented proposals.  I tend to like them, but
> other mentors do, too, so I won't say much about them.

Yes, they're obvious as well, and the only main desire is that the  
tools for Squeak start to really integrate to the point that we won't  
have a reason to fork on basic functionality again.

> There are a couple of proposals to make something like "rake" for
> Squeak.  I don't understand these.  I've built several large systems
> in Smalltalk and never felt the need for make.  I don't know rake, and
> when I read the proposals I feel like I am missing something.  Could
> someone explain why we need something like this?

I came up with this idea, and it does require some justification,  
since Squeak is not file-based and code is not "built" but either  
installed or not.

Martin Fowler explained the essence of Rake pretty well here:
http://www.martinfowler.com/articles/rake.html

To summarize, Sake would be an object-oriented domain language for  
tasks and dependencies, minus the script-oriented, life-within-one- 
invocation nature of Rake itself. Rake is more expressive and easier  
to work with than either Make or Ant (or SCons, python's dialect), on  
its own.

If we had Sake, then building Squeak VMs might be more easily done in  
it rather than Makefiles. This might offer a lot of integration  
benefits. The other issue is that building Squeak systems (images)  
declaratively using the Installer tool could be entirely automated  
without having to write custom procedural scripts. But mainly, the  
idea is that you could place a simple UI on this language which would  
show you the tasks and dependencies and even, say, give simple color- 
coded indication of which tasks have fallen out of date due to  
external changes or code changes or whatever.

It's entirely possible that class-side #initialize methods could  
benefit from this, but that's relatively debatable. I've seen enough  
#initialize methods and preambles and postscripts to see a dependency- 
tracking pattern in them, and a DSL for it might be a reasonable  
solution.

The configuration issue, providing a flexible language for  
specifying, detecting, and adjusting/merging configurations, would be  
a big benefit above the Preferences system that Squeak currently has,  
but I am unsure if it makes sense yet to compare these two things,  
and think a student might be able to explore this reasonably well.

The benefits might be vague and unknown right now, but Sake would be  
unprecedented as a kind of entity (persistent, object-oriented build  
system within a live environment), so I can't just assert its  
usefulness without having the legwork done to make it available. I  
think it would at least be worth an undergraduate paper publication.

--
-Brian
http://briantrice.com