[SoC] topics

[stephane ducasse]

I like sake and this is not a build for Smalltalk.
I asked lukas to be part of the mentors for the web related topics.

Stef

On 29 mars 07, at 20:00, Brian Rice wrote:

> 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
>
> _______________________________________________
> Soc mailing list
> Soc at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/soc
>