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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc