goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Wed Apr 17 10:31:22 UTC 2002
cg at cdegroot.com (Cees de Groot) wrote:
> <goran.hultgren at bluefish.se> said:
> >2. The "development model" is different. People need to learn a few
> >things before they understand the image-concept etc. [...] Smallscript
> >does that now, but hey - proprietary, non x-platform etc. Not really a
> >mass contender IMHO.
> - Java startup time is slow as h^Hwell.
> - GNU Smalltalk is geared towards scripts
> - Smalltalk without the image is, IMHO, not where new people should start.
> Without the image, it's just a nice language - again, IMHO, most of the
> speed increase can be attributed to the image and the development
> environment, not to something particularly nice to the barebones language
> (which, after all, has some serious contenders by now: Python 2.2 and Ruby,
> for example).
I agree. The trick is probably to not try to compete on those languages
Ok, they got the script-are locked down. Fine. Code in small textfiles.
"How quaint" as someone said (Tim?).
But Squeak offers you an WORLD OF OBJECTS to swim in! :-)
> >3. Squeak (being the largest "free" Smalltalk) suffers from poor
> >documentation. Compared to Python/Ruby it seems very disorganized. In
> >reality the code is probably just fine, but good reference documentation
> >etc. has been lacking. I think we can do better.
> We can do *way* better, but someone seems to have displaced the PIE source
> code... ;-)
> >4. Even though the syntax is great (I do NOT argue for changing it) it
> >might "scare off" newbies initially. On the other hand - a good tutorial
> >can teach the syntax in about 3 minutes so I don't really think it's a
> >problem. Might be just a myth.
> I think it's a myth. But an important one to dispell.
> >1. Polish the webpresence for Squeak. The website doesn't look so
> >"cool". This takes time and dedication...
> It's not about coolness, it's about completeness. Compare Python.org with the
> Squeak stuff.
And coolness. :-) Seriously, I agree but I also think the polish is
I know myself - if I stumble upon a site (for a language) which seems
amateurish I think "Hmmm, ok these guys don't have a clue about HTML,
why should they have a clue about programming?". Do note though that
strict, clean, fastloading sites with a "good look". Perhaps like this
Looking at the HTML source I notice though that it's not as "proper" as
I would like, but...
> One of the ideas I'm having (in reference to the earlier thread of full-text
> searching on the mail archive) is to use Harvest (a distributed search engine)
> to at least bring all the Squeak resources together behind a single search
> interface. Would that be an idea?
Sounds pretty good. I have my little SqueakMap that I need to get off my
chest which hopefully will make it mucho more nice to find
modules/goodies/code. Darn, so little time. Perhaps I should just post
what I have sofar... And get some help! :-)
> >2. Produce good reference docs by integrating some form of documentation
> >tools in the environment.
> See PIE comment, above (I think I blabbered about documentation somewhere
> on this list earlier this year). Personally, I think we should first to
> strive to make documentation available inside Squeak in an optimal way
> (books, with all sorts of embedded Morphs) and only think about "legacy
> web access" later on. That'll probably provide the right mindset to do
> something really great in this area.
I agree. But perhaps we should just take "small steps". A few simple
things we could start with:
1. Add some form of filtering in the Hierarchy browser based on
categories/modules. When a newbie open up a hierarchy to find out which
class to use, say on "Morph" (cough) he/she drowns in morphs. And why?
Because lots of those classes are not in the Morphic categories - it
should be possible to filter out "application classes" like MinesTile
2. Write these damn class comments. We are all at fault here - christ,
there isn't even a class comment for "Set"! Couldn't someone just write
a snippet that finds all classes (in the base categories/modules)
without comments and place that list on a Swikipage. Then we could just
"sign up" on them, write a good comment (without risking someone else
doing duplicate work) and submit those as "[ENH] Comment for: Xxx". We
(the harvesters) could then fasttrack those since we know it's just a
comment on a class which didn't have one to begin with.
> >3. Add more examples (and perhaps functionality) on simple Smalltalk
> >scripting. There are numerous very good webframeworks available for/in
> >Squeak and they should be able to attract people. Perhaps killerapps
> >such as them should be presented more agressively on www.squeak.org.
> It probably all starts with moving squeak.org from <insert whoever it
> maintains here> to a more community-supported effort.
Yep. How about moving it all to a CVS server or a renderSwiki or
something? To make it easy for a selected few to change it and keep it
alive. And we could also throw a little "Web Site Design Competition" to
whip up a few samples for how it could look. And then we can vote on it
(I can tweak my voting mechanism on SqueakDot to be able to have other
choices than Yes/No. :-)
More information about the Squeak-dev