I don't think there is a need for new lists. We've had comp.lang.smalltalk.advocacy and comp.lang.smalltalk. Currently we leave them to the spammers, and trolls, which is a bad sign for outsiders.
Always moving somewhere new and leave old trash around doesn't improve anything, does it? Joachim Am 22.01.2015 13:41 schrieb Bernat Romagosa <tibabenfortlapala...@gmail.com>: > > Hey Richard, > > I believe the only alive cross-dialect space is the #smalltalk IRC channel in > FreeNode. There's an average of 25~30 people online in that channel, which is > not _too_ bad considering the size of our community. Still, compare that to, > say, #lisp, with ~400 users and also being a cross-dialect channel. > > Smalltalkers feel quite strong about their particular dialect. I'm not > criticizing this behavior, I'm just stating facts. I also have strong > feelings for "my dialects" and I don't think this is necessarily bad. > > However, there are some "de-facto" meeting points for all Smalltalks, like > http://world.st. Even though there is no mailing list that joins all of us > together, this space does feature a homogenized list of all forums > (http://forum.world.st/). Planet Smalltalk (http://planet.smalltalk.org/) is > another great one for those of us who use RSS feeds. > > Indeed, it could take quite a while before a generic Smalltalk list was > populated enough, but these two efforts show there might be an interest. > > Cheers, > Bernat. > > 2015-01-22 9:11 GMT+01:00 Martin Bähr <mba...@email.archlab.tuwien.ac.at>: >> >> Excerpts from kilon alios's message of 2015-01-22 08:13:57 +0100: >> > Popularity indeed comes with a high price. Guido the creator of python he >> > has said in one of his presentation that there many people who want to add >> > their libraries to python distribution but they should not want to do that, >> > because once a library is added it become very difficult to change since so >> > many people depend on it to keep backward compatibility. He claimed that >> > even simple bug fixes have to go through lengthy review process. This can >> > be expanded to the entirety of the IDE and the language. >> > >> > This the most important reason why pharo has been moving forward so fast >> > and why popular languages move at glacial speed. >> > I dont want to lose that so yes I dont want for pharo to become popular. >> >> squeak already hast that 'problem' i believe and pharo is actively working to >> counteract it by removing less important things. so i doubt pharo will suffer >> from the pressure to fill it up with new packages any time soon. >> >> in this case it may be a win for all because those who want backwards >> compatibility can choose squeak, and those who want fast paced action may use >> pharo. >> >> also craig with context is working on minimizing the images which i believe >> should help to move more and more things out of the core, allowing you to >> pull >> them back in, making it possible to choose from various versions, based on >> your >> compatibility needs. >> >> ironically, i actually expect to want backwards compatibility in the future. >> but backwards to now, not to a decade ago, so i hope pharo development will >> eventually slow down somewhat. >> >> in addition, the multiple smalltalk implementations also act as a stabilizing >> factor, because people will want to write code that runs on all of them. >> (seaside for example) so pharo can't go that far out of line and make itself >> completely incompatible. >> >> i am also not sure which is better. a large standard library makes for a >> more stable system. >> having lots of important 3rd party libraries can lead to dependency issues... >> >> greetings, martin. >> >> -- >> eKita - the online platform for your entire academic life >> -- >> chief engineer eKita.co >> pike programmer pike.lysator.liu.se caudium.net societyserver.org >> secretary beijinglug.org >> mentor fossasia.org >> foresight developer foresightlinux.org realss.com >> unix sysadmin >> Martin Bähr working in china http://societyserver.org/mbaehr/ >> > > > > -- > Bernat Romagosa.
