Hey Everybody, This is just a quick note to let you know that we're going to be kicking off a series of Smalltalk Meetups this January. The first is going to be held at the Starbuck's in Chinatown (800 7th St., NW, Washington, DC, 20001) at 7:00PM on January 20th, 2005. More information and an RSVP form can be found at:
http://smalltalk.meetup.com/9/events/3796510/
I don't think I need to tell anyone in this group about the joys of Smalltalking. But from time to time I feel a bit isolated. All my peers are rambling on and on about how wonderful Java is, or even Python. Just once I would like to sit amongst people who are crazy about Smalltalk while sipping coffee. So if you're in the Washington, DC area, we would love to have you attend.
This meeting is intended to be the kick-off for a series of monthly meetings of the Washington, DC Smalltalk community. We're organizing our meetups on the meetup.com site and will be putting together a program for future meetings after hearing what people's interests are at this meeting.
As most of my recent Smalltalking has been done with Squeak, I'll likely be giving a brief intro to Squeak for any attendees that are interested. James Robertson of CinCom has already RSVP'd. Though he's not scheduled to deliver a presentation, he's a very good resource for getting more information about the ParcPlace / Digitalk branch of the Smalltalk tree.
-Sincerely, -Matt Hamrick
matthew you can use my presentation images to have fun and show squeak to others Have fun this is the most important point.
Stef
On 18 déc. 04, at 17:23, Matthew S.Hamrick wrote:
Hey Everybody, This is just a quick note to let you know that we're going to be kicking off a series of Smalltalk Meetups this January. The first is going to be held at the Starbuck's in Chinatown (800 7th St., NW, Washington, DC, 20001) at 7:00PM on January 20th, 2005. More information and an RSVP form can be found at:
http://smalltalk.meetup.com/9/events/3796510/
I don't think I need to tell anyone in this group about the joysof Smalltalking. But from time to time I feel a bit isolated. All my peers are rambling on and on about how wonderful Java is, or even Python. Just once I would like to sit amongst people who are crazy about Smalltalk while sipping coffee. So if you're in the Washington, DC area, we would love to have you attend.
This meeting is intended to be the kick-off for a series ofmonthly meetings of the Washington, DC Smalltalk community. We're organizing our meetups on the meetup.com site and will be putting together a program for future meetings after hearing what people's interests are at this meeting.
As most of my recent Smalltalking has been done with Squeak, I'lllikely be giving a brief intro to Squeak for any attendees that are interested. James Robertson of CinCom has already RSVP'd. Though he's not scheduled to deliver a presentation, he's a very good resource for getting more information about the ParcPlace / Digitalk branch of the Smalltalk tree.
-Sincerely, -Matt Hamrick
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
I used to think that my current situation in life has been determined as a result of the sum total of past events and I was sorta stuck with what had gone before. Now, I prefer to think of my present as being determined by my desired future. Get a clear picture in mind of the desired future and today's decisions become much easier, being made towards achieving the desired future. At each decision point, the decision can be made towards improving the quality of that future picture by bringing it into clearer focus.
From this point of view, I think it may be best to get a clear view of the future of Squeak, then do today what is necessary to create that picture without worrying about the backward compatibility. Those that need to and want to, will do the required changes to also partake in that desired future, those that don't can remain with whatever works for them. The backwards compatibility issues I believe could most appropriately be dealt with by those parts of the system that have the issues, thereby reducing the inertia for going forward.
In the past, if this way of thinking would have been in vogue, we would most likely already be running with Craig's 'Flow' in the system. I'm assuming from other opinions that would be a good thing...
The desired future of Squeak determines what we do today, as opposed to what was done in the past... Of course.
Mark Twain evidently wrote: "Twenty years from now you will be more disappointed by the things you didn't do than the ones you did."
Ken G. Brown
An earlier comment by Avi suggested adding a prefix to Flow's stream classes so that both the current stream classes and Flow's stream classes could run in parallel. However, if Flow is the future, perhaps it would be better to add the prefix to the current stream classes instead. This would force all current projects to be converted to the new class names, but would make the future cleaner.
However, what I hear Craig saying is that he wants to resolve some other issues before including Flow into the current release of Squeak, and that there are some packaging issues which *may* prevent it from ever being included. Because of the great work Craig has done, not to mention the potential benefits of Flow and a minimal system, it would be sad if this stays relegated to a spoon :-)
Brian.
On Dec 18, 2004, at 2:09 PM, Ken G. Brown wrote:
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
I used to think that my current situation in life has been determined as a result of the sum total of past events and I was sorta stuck with what had gone before. Now, I prefer to think of my present as being determined by my desired future. Get a clear picture in mind of the desired future and today's decisions become much easier, being made towards achieving the desired future. At each decision point, the decision can be made towards improving the quality of that future picture by bringing it into clearer focus.
From this point of view, I think it may be best to get a clear view of the future of Squeak, then do today what is necessary to create that picture without worrying about the backward compatibility. Those that need to and want to, will do the required changes to also partake in that desired future, those that don't can remain with whatever works for them. The backwards compatibility issues I believe could most appropriately be dealt with by those parts of the system that have the issues, thereby reducing the inertia for going forward.
In the past, if this way of thinking would have been in vogue, we would most likely already be running with Craig's 'Flow' in the system. I'm assuming from other opinions that would be a good thing...
The desired future of Squeak determines what we do today, as opposed to what was done in the past... Of course.
Mark Twain evidently wrote: "Twenty years from now you will be more disappointed by the things you didn't do than the ones you did."
Ken G. Brown
you are right. :) but the key difficulty is how to evolve as fast of possible without totally frustrating your clients. So I think that **soon** we will have a set up a plan for the future :). Wait and see we are preparing something :)))
happy christmas Stef
On 18 déc. 04, at 22:09, Ken G. Brown wrote:
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
I used to think that my current situation in life has been determined as a result of the sum total of past events and I was sorta stuck with what had gone before. Now, I prefer to think of my present as being determined by my desired future. Get a clear picture in mind of the desired future and today's decisions become much easier, being made towards achieving the desired future. At each decision point, the decision can be made towards improving the quality of that future picture by bringing it into clearer focus.
From this point of view, I think it may be best to get a clear view of the future of Squeak, then do today what is necessary to create that picture without worrying about the backward compatibility. Those that need to and want to, will do the required changes to also partake in that desired future, those that don't can remain with whatever works for them. The backwards compatibility issues I believe could most appropriately be dealt with by those parts of the system that have the issues, thereby reducing the inertia for going forward.
In the past, if this way of thinking would have been in vogue, we would most likely already be running with Craig's 'Flow' in the system. I'm assuming from other opinions that would be a good thing...
The desired future of Squeak determines what we do today, as opposed to what was done in the past... Of course.
Mark Twain evidently wrote: "Twenty years from now you will be more disappointed by the things you didn't do than the ones you did."
Ken G. Brown
"Ken G. Brown" kbrown@tnc.ab.ca wrote:
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
The principle Ken and others are stating is great. My suggestion is simply that we should focus on changes that really are useful. We should not just move things around because we think it looks nicer. Lots of people are building on top of Squeak, and we shouldn't cause them grief unless there is actually a reason for it. And we most certainly should not break our own code all the time. That's no way to move forward.
As an example, renaming of classes and methods is a poor bargain. Yes, arguably the new names are better. (Though arguably, in many cases the old names were better, too!!) This is a minor change. This is a change that no one will regret having seen when they are old. But, it is a change that very easily breaks lots of code. Why do it?
And if we must do it for some good reason, please let's have a grace period, and not remove the old name until -- at *least* -- the maintained code on SqueakMap has been moved over. Don't just pull the rug out one day.
Overall, while we must break a few eggs as time goes on, we don't need to jump around and stomp on the whole batch.
Lex
Ken G. Brown wrote:
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
I used to think that my current situation in life has been determined as a result of the sum total of past events and I was sorta stuck with what had gone before. Now, I prefer to think of my present as being determined by my desired future. Get a clear picture in mind of the desired future and today's decisions become much easier, being made towards achieving the desired future. At each decision point, the decision can be made towards improving the quality of that future picture by bringing it into clearer focus.
From this point of view, I think it may be best to get a clear view of the future of Squeak, then do today what is necessary to create that picture without worrying about the backward compatibility. Those that need to and want to, will do the required changes to also partake in that desired future, those that don't can remain with whatever works for them. The backwards compatibility issues I believe could most appropriately be dealt with by those parts of the system that have the issues, thereby reducing the inertia for going forward.
In the past, if this way of thinking would have been in vogue, we would most likely already be running with Craig's 'Flow' in the system. I'm assuming from other opinions that would be a good thing...
1. Adopt Craig's Spoon (Squat..?) kernel as the humble beginnings of Squeak version n+1.
2. Make it able to use version-controlled packages with dependencies etc. Like Debian (to quote other wiser people). Perhaps using Monticello? (p.s. is that pronounced montisello or montichello?)
3. Make a set of core packages. Libaries, Morphic-base, Dev-tools, Compiler etc. Use current Squeak code and existing SqueakMap packages to make these packages.
4. Repeat for Squeak n+2.
I'm a big fan of writing everything from scratch. That way, you get a fresh perspective and you don't have to carry old crud with you. Squeak suffers from old crud - I don't touch much of the core code, but some of it just makes me wonder why its there. I also wonder why I can't download an image which doesn't have a Bach tune and talking heads in it.
I think that this community (and excuse my preaching here) needs to break itself up a bit. People need to break the image into separately managed projects, perhaps even being so radical as to have separate mailing lists and version control for each project source.
Example of breaking up the image into projects: http://minnow.cc.gatech.edu/squeak/2460.html
Mikevdg.
Michael van der Gulik wrote:
I think that this community (and excuse my preaching here) needs to break itself up a bit. People need to break the image into separately managed projects,
Actually this is taking place.
There are packages on SqueakMap called RemoveXYZPackage And then the package itself XYZPackage.
What we could need is additionel help doing these pairs of packages. Both are needed. One for doing the minimal image starting from the basic image and the other for doing the full image (or various variants of it)
Hannes
At 10:51 20.12.2004, Mikevdg wrote:
Example of breaking up the image into projects: http://minnow.cc.gatech.edu/squeak/2460.html
Mikevdg.
Looks interesting, but the above URL does not appear to be valid. Do I need something special to access postings on Squeak Swiki?
Greetings --Trygve
Trygve Reenskaug trygver@ifi.uio.no wrote:
At 10:51 20.12.2004, Mikevdg wrote:
Example of breaking up the image into projects: http://minnow.cc.gatech.edu/squeak/2460.html
Mikevdg.
Looks interesting, but the above URL does not appear to be valid. Do I need something special to access postings on Squeak Swiki?
Drop the .html:
http://minnow.cc.gatech.edu/squeak/2460
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Brian Murphy-Dye -
goran.krampe＠bluefish.se -
Hannes Hirzel -
Ken G. Brown -
Lex Spoon -
Matthew S. Hamrick -
Michael van der Gulik -
stéphane ducasse -
Trygve Reenskaug