[SoC] topics
stephane ducasse
stephane.ducasse at free.fr
Fri Mar 30 09:37:15 UTC 2007
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
>
More information about the Soc
mailing list