Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
I'd say that the biggest driver is process, not language. Using version control tools and sane build process, the image is utterly irrelevant
On Jan 28, 2012, at 10:46 AM, Janko Mivšek wrote:
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
James Robertson http://www.jarober.com jarober@gmail.com
+ 1
Managing 200 people is not equal to 20 times a team of 10. You have to split in teams and each one will work on its own project, synchronized….. I think that this has nothing to do with language. May be if you have interfaces and component like structure it may help you.
Stef
On Jan 28, 2012, at 5:12 PM, James Robertson wrote:
I'd say that the biggest driver is process, not language. Using version control tools and sane build process, the image is utterly irrelevant
On Jan 28, 2012, at 10:46 AM, Janko Mivšek wrote:
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
James Robertson http://www.jarober.com jarober@gmail.com
Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Dale
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr, "Squeak" squeak-dev@lists.squeakfoundation.org, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] Smalltalk for small projects only? | | Hi guys, | | Ralph Johnson in his InfoQ interview made an interesting observation: | | 2:55 minute: "Smalltalk made an fundamental error ... image ... you | can | build something with 4-5 people what 50 people can build in Java, but | if | you take 200 people in Java ... it is really designed for small | systems | ... " | | Are we because of the image really destined for relatively small | projects and small systems (of Java 50 people project size)? | | Are we really not able to scale to bigger projects/systems because of | that? | | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | still... | | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |
Dale,
On 28 Jan 2012, at 19:07, Dale Henrichs wrote:
Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Dale
I want to respectfully disagree (and I even don't understand some of your remarks, or the underlying implications, given your excellent work on Metacello and some much other contributions to Smalltalk).
Yes, the very old way of passing images around was arcane and did not scale (I did this too in the 80'ies early 90'ies).
But today, with Monticello and Metacello things are quite different, not perfect but totally acceptable.
When building Smalltalk applications I am using code written by hundreds of people during tens of years, this works out very well.
In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related. Merging, branching, solving conflicts there is no different than with Monticello, IMHO.
Organizing big teams is plain hard, in any language. Clear separations/responsabilities/interfaces are the only answer.
Sven
Sven,
Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ...
How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:)
Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ...
As I said, I don't think the problem is insurmountable...and I do think we are getting better.
It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"...
Dale
----- Original Message ----- | From: "Sven Van Caekenberghe" sven@beta9.be | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 11:08:08 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | Dale, | | On 28 Jan 2012, at 19:07, Dale Henrichs wrote: | | > Janko, | > | > I think the limitation for Smalltalk lies in source code management | > tools/styles ... | > | > With a file-based language 200 engineers can contribute to the | > project ... each engineer can checkout a version of the system | > work in isolation then commit his or her work to the shared | > repository resolve conflicts and move on .... other engineers can | > easily integrate the work and so on ... the source code management | > tools scale ... | > | > In the mid nineties at ParcPlace systems the image was passed | > around from engineer to engineer so that he or she could integrate | > their work into the production image... this doesn't scale... | > | > There have been proprietary source code management tools that have | > been created over the years. You can bet that the large companies | > that are invested in Smalltalk are using systems that are based on | > these proprietary systems, but you can also bet that they've had | > to customize those systems for their needs... | > | > The file-based SCM systems work out of the box and don't care what | > language or even development process that is being used ... they | > are managing files ... | > | > There is no standard SCM for Smalltalk and none of the file-based | > SCMs really fit Smalltalk. When we are arguing about whether git | > or mercurial is better on the Pharo list, I will retract that | > statement:). | > | > Without a standard SCM, the first thing that a 200 person | > engineering groups needs to do to start using Smalltalk is figure | > out (for themselves) how to share their work and keep 200 | > individual images in synch ... I'm not necessarily convinced that | > anyone has really solved this one. | > | > Personally I believe that the problem is surmountable, but for | > whatever reason the Smalltalk community hasn't focussed on | > seriously addressing the SCM issue .... in the last 30 years or | > so:) | > | > Being able to repeatably build images based on a minimal core image | > is certainly headed in the right direction, but we still have a | > ways to go on the tools front ... | > | > Dale | | I want to respectfully disagree (and I even don't understand some of | your remarks, or the underlying implications, given your excellent | work on Metacello and some much other contributions to Smalltalk). | | Yes, the very old way of passing images around was arcane and did not | scale (I did this too in the 80'ies early 90'ies). | | But today, with Monticello and Metacello things are quite different, | not perfect but totally acceptable. | | When building Smalltalk applications I am using code written by | hundreds of people during tens of years, this works out very well. | | In traditional file bases language like Java or C using a traditional | SCM, you will immediately hit problems when even a couple of people | work on parts of code that are closely related. Merging, branching, | solving conflicts there is no different than with Monticello, IMHO. | | Organizing big teams is plain hard, in any language. Clear | separations/responsabilities/interfaces are the only answer. | | Sven | | | |
IMNSHO, if you have a team of 200 doing <any> software development in any language, then you have a big IT shop. That also means you have a pretty onerous process in place that will bring all forward motion to a halt. I'd go so far as to say that if you think you need 200 people for your project, go outside and light $100 bills on fire instead. It will burn less money, and annoy fewer people.
On Jan 28, 2012, at 5:57 PM, Dale Henrichs wrote:
Sven,
Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ...
How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:)
Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ...
As I said, I don't think the problem is insurmountable...and I do think we are getting better.
It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"...
Dale
----- Original Message ----- | From: "Sven Van Caekenberghe" sven@beta9.be | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 11:08:08 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | Dale, | | On 28 Jan 2012, at 19:07, Dale Henrichs wrote: | | > Janko, | > | > I think the limitation for Smalltalk lies in source code management | > tools/styles ... | > | > With a file-based language 200 engineers can contribute to the | > project ... each engineer can checkout a version of the system | > work in isolation then commit his or her work to the shared | > repository resolve conflicts and move on .... other engineers can | > easily integrate the work and so on ... the source code management | > tools scale ... | > | > In the mid nineties at ParcPlace systems the image was passed | > around from engineer to engineer so that he or she could integrate | > their work into the production image... this doesn't scale... | > | > There have been proprietary source code management tools that have | > been created over the years. You can bet that the large companies | > that are invested in Smalltalk are using systems that are based on | > these proprietary systems, but you can also bet that they've had | > to customize those systems for their needs... | > | > The file-based SCM systems work out of the box and don't care what | > language or even development process that is being used ... they | > are managing files ... | > | > There is no standard SCM for Smalltalk and none of the file-based | > SCMs really fit Smalltalk. When we are arguing about whether git | > or mercurial is better on the Pharo list, I will retract that | > statement:). | > | > Without a standard SCM, the first thing that a 200 person | > engineering groups needs to do to start using Smalltalk is figure | > out (for themselves) how to share their work and keep 200 | > individual images in synch ... I'm not necessarily convinced that | > anyone has really solved this one. | > | > Personally I believe that the problem is surmountable, but for | > whatever reason the Smalltalk community hasn't focussed on | > seriously addressing the SCM issue .... in the last 30 years or | > so:) | > | > Being able to repeatably build images based on a minimal core image | > is certainly headed in the right direction, but we still have a | > ways to go on the tools front ... | > | > Dale | | I want to respectfully disagree (and I even don't understand some of | your remarks, or the underlying implications, given your excellent | work on Metacello and some much other contributions to Smalltalk). | | Yes, the very old way of passing images around was arcane and did not | scale (I did this too in the 80'ies early 90'ies). | | But today, with Monticello and Metacello things are quite different, | not perfect but totally acceptable. | | When building Smalltalk applications I am using code written by | hundreds of people during tens of years, this works out very well. | | In traditional file bases language like Java or C using a traditional | SCM, you will immediately hit problems when even a couple of people | work on parts of code that are closely related. Merging, branching, | solving conflicts there is no different than with Monticello, IMHO. | | Organizing big teams is plain hard, in any language. Clear | separations/responsabilities/interfaces are the only answer. | | Sven | | | |
James Robertson http://www.jarober.com jarober@gmail.com
On Sat, Jan 28, 2012 at 06:37:52PM -0500, James Robertson wrote:
IMNSHO, if you have a team of 200 doing <any> software development in any language, then you have a big IT shop. That also means you have a pretty onerous process in place that will bring all forward motion to a halt. I'd go so far as to say that if you think you need 200 people for your project, go outside and light $100 bills on fire instead. It will burn less money, and annoy fewer people.
Indeed.
It would be interesting to know if anyone can cite a real world example of someone who thought that a software project could be accomplished by a team of 200 people, and it actually turned out to be true.
Dave
On 1/28/12 8:58 PM, David T. Lewis wrote:
On Sat, Jan 28, 2012 at 06:37:52PM -0500, James Robertson wrote:
IMNSHO, if you have a team of 200 doing<any> software development in any language, then you have a big IT shop. That also means you have a pretty onerous process in place that will bring all forward motion to a halt. I'd go so far as to say that if you think you need 200 people for your project, go outside and light $100 bills on fire instead. It will burn less money, and annoy fewer people.
Indeed.
It would be interesting to know if anyone can cite a real world example of someone who thought that a software project could be accomplished by a team of 200 people, and it actually turned out to be true.
Dave
How many people in the Windows team?
Well, OK, a reliable project...
L.
It would be interesting to know if anyone can cite a real world example of someone who thought that a software project could be accomplished by a team of 200 people, and it actually turned out to be true.
The Boeing 777 fly-by-wire system... Never a plane crash due to a software bug... written in Ada. http://archive.adaic.com/projects/atwork/boeing.html http://www.citemaster.net/getdoc/9240/yeh98_777-fbw.pdf http://www.springerlink.com/content/gr578227271350x7/
But, I still love Smalltalk for expressing/representing general ideas which change as people's thinking changes and as cellular biology changes rather than engineering a completely known domain. Like the difference between A.I. and A.G.I.
- Darius
*Honeywell's massive effort on the 777 involved over 550 software developers
*. The company built the AIMS computer as a custom platform based on the AMD 29050 processor. It was unique among aviation systems for integrating the other computers' functions; in other systems, each function resides in a different box [the central maintenance had its own box with its own input/output (I/O), its own central processing unit (CPU), etc.]. AIMS combines all these functions and shares the CPU and I/O among them: it uses the same signals for flight management and for displays, so that the data comes in only once instead of twice; one input circuit provides data to all of the functions; each of the functions gets a piece of the CPU, as in a mainframe computer, where systems use part of the CPU but not all of it; and every function is guaranteed its time slot. Engineer Jeff Greeson said that "The federated system is obsolete. Putting all the functions in one box is a jump ahead in technology that we've brought to the industry."
Honeywell's Airplane Information Management System (AIMS) project consists
of the largest central computer on the jetliner; it runs 613,000 new lines of code (defined as body semicolons), taking up 15,656 kilobytes (KB) of disk space and 4,854 KB of random-access memory (RAM). With redundancy, the software runs to 46,191 KB and 10,732 KB of RAM. A multiprocessor, rack-mounted system, the AIMS replaced many of the line-replaceable units and reduced hardware and software redundancy.
It would be interesting to know if anyone can cite a real world example of someone who thought that a software project could be accomplished by a team of 200 people, and it actually turned out to be true.
Dave
How many people in the Windows team?
Well, OK, a reliable project...
L.
On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs dhenrich@vmware.com wrote:
Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Dale
You are talking about dealing with source code, but what about the live
objects in the image? Is there any work done on managing live images with several developers ? This is where Smalltalk excels and would be very interesting instead of falling back to the rebuild from source strategy.
Karl
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr, "Squeak" < squeak-dev@lists.squeakfoundation.org>, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] Smalltalk for small projects only? | | Hi guys, | | Ralph Johnson in his InfoQ interview made an interesting observation: | | 2:55 minute: "Smalltalk made an fundamental error ... image ... you | can | build something with 4-5 people what 50 people can build in Java, but | if | you take 200 people in Java ... it is really designed for small | systems | ... " | | Are we because of the image really destined for relatively small | projects and small systems (of Java 50 people project size)? | | Are we really not able to scale to bigger projects/systems because of | that? | | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | still... | | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |
On 1/28/12 12:39 PM, karl ramberg wrote:
You are talking about dealing with source code, but what about the live objects in the image? Is there any work done on managing live images with several developers ? This is where Smalltalk excels and would be very interesting instead of falling back to the rebuild from source strategy.
Check out Craig Latta's Spoon project.
L.
Karl,
Am 28.01.2012 um 20:39 schrieb karl ramberg karlramberg@gmail.com:
Is there any work done on managing live images with several developers ?
I'm not all sure I understand your question, but: http://www.hpi.uni-potsdam.de/hirschfeld/misc/etc/index.html
Best,
Michael
On Sat, Jan 28, 2012 at 10:34 PM, Michael Haupt mhaupt@gmail.com wrote:
Karl,
Am 28.01.2012 um 20:39 schrieb karl ramberg karlramberg@gmail.com:
Is there any work done on managing live images with several developers ?
I'm not all sure I understand your question, but: http://www.hpi.uni-potsdam.de/hirschfeld/misc/etc/index.html
I was thinking about versioning and merging of live objects in the image instead of saving source code for versioning. I guess Spoon is doing what I was talking about.
Do you have any documentation of the multi user RBS extension ?
Karl
Karl,
Am 28.01.2012 um 23:10 schrieb karl ramberg karlramberg@gmail.com:
Am 28.01.2012 um 20:39 schrieb karl ramberg karlramberg@gmail.com:
Is there any work done on managing live images with several developers ?
I'm not all sure I understand your question, but: http://www.hpi.uni-potsdam.de/hirschfeld/misc/etc/index.html
I was thinking about versioning and merging of live objects in the image instead of saving source code for versioning. I guess Spoon is doing what I was talking about.
Ah, ok.
Do you have any documentation of the multi user RBS extension ?
I don't; the people at HPI should know more details.
Best,
Michael
Karl,
For the types of project that would employ a team of 200, you need to be able to reliably reproduce the state of an image, from scratch, 5 years after development has completed ...
I invite you to read Allen Wirfs-Brock's paper on "Declarative Smalltalk"[1]. Here are some excerpts:
Smalltalk does not include the concept of a program as a distinct entity. In practice, a Smalltalk program is the state of a virtual image when work is declared completed.
Lack of a program definition in traditional Smalltalk environments leads to an undue reliance on the virtual image. Images can become obsolete or broken. Because the program is encoded in the image, the program is in danger of becoming inaccessible if the image becomes outmoded or corrupt.
The manual and unreliable nature of the initialization of Smalltalk programs leads to a number of program errors. Especially prevalent after reconstruction of a program in a new image are errors where program elements have an initial value of nil instead of some other value as originally intended by the programmer.
The use of a declarative specification model has little direct impact upon Smalltalk programmers. Even though Smalltalk has traditionally been implemented using an imperative program description model, the perception of most Smalltalk programmers is of a declarative model. This is because Smalltalk programmers typically create and edit programs using a browser that presents the classes that make up the program in a declarative style.
Disclaimer: I worked with Allen Wirfs-Brock in the nineties (engineer on the Team/V team) while he was developing his ideas for Declarative Smalltalk, so I am somewhat biased in my thinking:)
My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
Dale
[1] http://www.smalltalksystems.com/publications/_awss97/SSDCL1.HTM
----- Original Message ----- | From: "karl ramberg" karlramberg@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 11:39:22 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | You are talking about dealing with source code, but what about the | live objects in the image? Is there any work done on managing live | images with several developers ? This is where Smalltalk excels and | would be very interesting instead of falling back to the rebuild | from source strategy. | | Karl
For this to work, we need Spoon and tools designed around Spoon, I think.
One thing that I have heard is that *no one* has really stepped up and given feedback to Craig. I was one of the most "expert" people around simply because I had downloaded his latest version.
Hint hint, folks.
L.
L. On 1/28/12 4:20 PM, Dale Henrichs wrote:
[...] My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
Dale
On Sun, Jan 29, 2012 at 12:47 AM, Lawson English lenglish5@cox.net wrote:
For this to work, we need Spoon and tools designed around Spoon, I think.
One thing that I have heard is that *no one* has really stepped up and given feedback to Craig. I was one of the most "expert" people around simply because I had downloaded his latest version.
Hint hint, folks.
L.
It does not run on my machine.
"This application has failed to start because the application configuration is incorrect"
Seems to be a linking to right shared dll that cause this.
Karl
L.
On 1/28/12 4:20 PM, Dale Henrichs wrote:
[...]
My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
Dale
+1 Metacello is the way to go! Dale I will update the chapter as soon as you decide the new API :) I'm working on a nice process document for our little community. Stay tuned :)
Stef
My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
+100 for your documentation efforts Stef!
Dale
----- Original Message ----- | From: "Stéphane Ducasse" stephane.ducasse@inria.fr | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "Pharo-project@lists.gforge.inria.fr Development" Pharo-project@lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 12:25:56 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | +1 | Metacello is the way to go! | Dale I will update the chapter as soon as you decide the new API :) | I'm working on a nice process document for our little community. Stay | tuned :) | | Stef | | | > My opinion that being able to build images from scratch (easily and | > reproducibly) is a "requirement" to get in the door for | > mainstream projects... giving mainstream developers the | > opportunity to work in a image-based environment will set them | > free:) | | |
+1.000.000 for your documentation efforts Stef! noobs like me , are extremely happy with them ;)
________________________________ From: Dale Henrichs dhenrich@vmware.com To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Cc: "Pharo-project@lists.gforge.inria.fr Development" Pharo-project@lists.gforge.inria.fr Sent: Sunday, 29 January 2012, 20:09 Subject: Re: [squeak-dev] Smalltalk for small projects only?
+100 for your documentation efforts Stef!
Dale
----- Original Message ----- | From: "Stéphane Ducasse" stephane.ducasse@inria.fr | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "Pharo-project@lists.gforge.inria.fr Development" Pharo-project@lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 12:25:56 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | +1 | Metacello is the way to go! | Dale I will update the chapter as soon as you decide the new API :) | I'm working on a nice process document for our little community. Stay | tuned :) | | Stef | | | > My opinion that being able to build images from scratch (easily and | > reproducibly) is a "requirement" to get in the door for | > mainstream projects... giving mainstream developers the | > opportunity to work in a image-based environment will set them | > free:) | | |
Stef efforts are amazing.
I started a course on Pharo this week. All students have their PBE. Very important.
Laurent
On Sun, Jan 29, 2012 at 7:09 PM, Dale Henrichs dhenrich@vmware.com wrote:
+100 for your documentation efforts Stef!
Dale
----- Original Message ----- | From: "Stéphane Ducasse" stephane.ducasse@inria.fr | To: "The general-purpose Squeak developers list" < squeak-dev@lists.squeakfoundation.org> | Cc: "Pharo-project@lists.gforge.inria.fr Development" < Pharo-project@lists.gforge.inria.fr> | Sent: Sunday, January 29, 2012 12:25:56 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | +1 | Metacello is the way to go! | Dale I will update the chapter as soon as you decide the new API :) | I'm working on a nice process document for our little community. Stay | tuned :) | | Stef | | | > My opinion that being able to build images from scratch (easily and | > reproducibly) is a "requirement" to get in the door for | > mainstream projects... giving mainstream developers the | > opportunity to work in a image-based environment will set them | > free:) | | |
On Jan 29, 2012, at 7:45 PM, laurent laffont wrote:
Stef efforts are amazing.
I started a course on Pharo this week. All students have their PBE. Very important.
Excellent!
I'm working on the next one :) But it will be deeper and I'm learning new stuff too so this is why I'm slow. Stef
Laurent
On Sun, Jan 29, 2012 at 7:09 PM, Dale Henrichs dhenrich@vmware.com wrote: +100 for your documentation efforts Stef!
Dale
----- Original Message ----- | From: "Stéphane Ducasse" stephane.ducasse@inria.fr | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "Pharo-project@lists.gforge.inria.fr Development" Pharo-project@lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 12:25:56 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | +1 | Metacello is the way to go! | Dale I will update the chapter as soon as you decide the new API :) | I'm working on a nice process document for our little community. Stay | tuned :) | | Stef | | | > My opinion that being able to build images from scratch (easily and | > reproducibly) is a "requirement" to get in the door for | > mainstream projects... giving mainstream developers the | > opportunity to work in a image-based environment will set them | > free:) | | |
In my experience - using the project I'm on as an example - a fresh build takes on the order of 20 minutes (using a remote Store repository across a slow link. Using SQLlite from local disk, it's closer to 5-7 minutes).
That's for building up, from a base visual.im (this is VisualWorks)
-- a development image -- a runtime -- a change report -- the SUnit run results
If you need synching more often than that, I'd say that you have a problem that is not solvable by tools.
This project involves around 5500 classes across nearly 200 packages (Store packages)
If you automate that (which is pretty easy), then you can have a server do builds as often as you need them, and toss the results out onto a share drive.
On Jan 28, 2012, at 2:39 PM, karl ramberg wrote:
On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs dhenrich@vmware.com wrote: Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Dale
You are talking about dealing with source code, but what about the live objects in the image? Is there any work done on managing live images with several developers ? This is where Smalltalk excels and would be very interesting instead of falling back to the rebuild from source strategy.
Karl
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr, "Squeak" squeak-dev@lists.squeakfoundation.org, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] Smalltalk for small projects only? | | Hi guys, | | Ralph Johnson in his InfoQ interview made an interesting observation: | | 2:55 minute: "Smalltalk made an fundamental error ... image ... you | can | build something with 4-5 people what 50 people can build in Java, but | if | you take 200 people in Java ... it is really designed for small | systems | ... " | | Are we because of the image really destined for relatively small | projects and small systems (of Java 50 people project size)? | | Are we really not able to scale to bigger projects/systems because of | that? | | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | still... | | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |
James Robertson http://www.jarober.com jarober@gmail.com
Dale,
I agree with you that source code management is where we are weak. A process therefore, as James already said.
In SCM VisualWorks is ahead in my opinion, even that Store is also not perfect yet. But it would be useful to reuse some of ideas in Monticello based SCM tools too. With Metacello we got a good packaging tool, so, where to go to be even better? I think SCM tool integration into code browser can be next and relatively easy step. As Store is integrated into VW code browser.
Janko
S, Dale Henrichs piše:
Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Dale
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr, "Squeak" squeak-dev@lists.squeakfoundation.org, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] Smalltalk for small projects only? | | Hi guys, | | Ralph Johnson in his InfoQ interview made an interesting observation: | | 2:55 minute: "Smalltalk made an fundamental error ... image ... you | can | build something with 4-5 people what 50 people can build in Java, but | if | you take 200 people in Java ... it is really designed for small | systems | ... " | | Are we because of the image really destined for relatively small | projects and small systems (of Java 50 people project size)? | | Are we really not able to scale to bigger projects/systems because of | that? | | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | still... | | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |
Janko,
Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...
I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.
I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...
Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...
I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.
We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.
Dale
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr | Cc: "Dale Henrichs" dhenrich@vmware.com, "The general-purpose Squeak developers list" | squeak-dev@lists.squeakfoundation.org, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 12:16:55 PM | Subject: Re: [Smalltalk for small projects only? | | Dale, | | I agree with you that source code management is where we are weak. A | process therefore, as James already said. | | In SCM VisualWorks is ahead in my opinion, even that Store is also | not | perfect yet. But it would be useful to reuse some of ideas in | Monticello | based SCM tools too. With Metacello we got a good packaging tool, so, | where to go to be even better? I think SCM tool integration into code | browser can be next and relatively easy step. As Store is integrated | into VW code browser. | | Janko | | S, Dale Henrichs piše: | > Janko, | > | > I think the limitation for Smalltalk lies in source code management | > tools/styles ... | > | > With a file-based language 200 engineers can contribute to the | > project ... each engineer can checkout a version of the system | > work in isolation then commit his or her work to the shared | > repository resolve conflicts and move on .... other engineers can | > easily integrate the work and so on ... the source code management | > tools scale ... | > | > In the mid nineties at ParcPlace systems the image was passed | > around from engineer to engineer so that he or she could integrate | > their work into the production image... this doesn't scale... | > | > There have been proprietary source code management tools that have | > been created over the years. You can bet that the large companies | > that are invested in Smalltalk are using systems that are based on | > these proprietary systems, but you can also bet that they've had | > to customize those systems for their needs... | > | > The file-based SCM systems work out of the box and don't care what | > language or even development process that is being used ... they | > are managing files ... | > | > There is no standard SCM for Smalltalk and none of the file-based | > SCMs really fit Smalltalk. When we are arguing about whether git | > or mercurial is better on the Pharo list, I will retract that | > statement:). | > | > Without a standard SCM, the first thing that a 200 person | > engineering groups needs to do to start using Smalltalk is figure | > out (for themselves) how to share their work and keep 200 | > individual images in synch ... I'm not necessarily convinced that | > anyone has really solved this one. | > | > Personally I believe that the problem is surmountable, but for | > whatever reason the Smalltalk community hasn't focussed on | > seriously addressing the SCM issue .... in the last 30 years or | > so:) | > | > Being able to repeatably build images based on a minimal core image | > is certainly headed in the right direction, but we still have a | > ways to go on the tools front ... | > | > Dale | > | > | > | > ----- Original Message ----- | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | vwnc@cs.uiuc.edu | > | Sent: Saturday, January 28, 2012 7:46:32 AM | > | Subject: [squeak-dev] Smalltalk for small projects only? | > | | > | Hi guys, | > | | > | Ralph Johnson in his InfoQ interview made an interesting | > | observation: | > | | > | 2:55 minute: "Smalltalk made an fundamental error ... image ... | > | you | > | can | > | build something with 4-5 people what 50 people can build in Java, | > | but | > | if | > | you take 200 people in Java ... it is really designed for small | > | systems | > | ... " | > | | > | Are we because of the image really destined for relatively small | > | projects and small systems (of Java 50 people project size)? | > | | > | Are we really not able to scale to bigger projects/systems | > | because of | > | that? | > | | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | > | still... | > | | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | > | | > | Best regards | > | Janko | > | | > | | > | -- | > | Janko Mivšek | > | Aida/Web | > | Smalltalk Web Application Server | > | http://www.aidaweb.si | > | | > | | > | > | | -- | Janko Mivšek | Svetovalec za informatiko | Eranova d.o.o. | Ljubljana, Slovenija | www.eranova.si | tel: 01 514 22 55 | faks: 01 514 22 56 | gsm: 031 674 565 |
2012/1/28 Dale Henrichs dhenrich@vmware.com:
Janko,
Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...
I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.
Um, do you mean Metacello or Monticello? Metacello seems like the maven of Java world: "Here's what this artifact contains, its dependencies, where you can find them, etc. etc."
I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...
Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...
A build should be a single command, with no customisation required at all. This is especially important in large projects. Being able to customise/parameterise a build means having an artifact but not knowing what went into building it.
Otherwise, I agree. Luckily, more and more folks are starting to use Metacello, and building images up from some small base.
frank
I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.
We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.
Dale
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr | Cc: "Dale Henrichs" dhenrich@vmware.com, "The general-purpose Squeak developers list" | squeak-dev@lists.squeakfoundation.org, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 12:16:55 PM | Subject: Re: [Smalltalk for small projects only? | | Dale, | | I agree with you that source code management is where we are weak. A | process therefore, as James already said. | | In SCM VisualWorks is ahead in my opinion, even that Store is also | not | perfect yet. But it would be useful to reuse some of ideas in | Monticello | based SCM tools too. With Metacello we got a good packaging tool, so, | where to go to be even better? I think SCM tool integration into code | browser can be next and relatively easy step. As Store is integrated | into VW code browser. | | Janko | | S, Dale Henrichs piše: | > Janko, | > | > I think the limitation for Smalltalk lies in source code management | > tools/styles ... | > | > With a file-based language 200 engineers can contribute to the | > project ... each engineer can checkout a version of the system | > work in isolation then commit his or her work to the shared | > repository resolve conflicts and move on .... other engineers can | > easily integrate the work and so on ... the source code management | > tools scale ... | > | > In the mid nineties at ParcPlace systems the image was passed | > around from engineer to engineer so that he or she could integrate | > their work into the production image... this doesn't scale... | > | > There have been proprietary source code management tools that have | > been created over the years. You can bet that the large companies | > that are invested in Smalltalk are using systems that are based on | > these proprietary systems, but you can also bet that they've had | > to customize those systems for their needs... | > | > The file-based SCM systems work out of the box and don't care what | > language or even development process that is being used ... they | > are managing files ... | > | > There is no standard SCM for Smalltalk and none of the file-based | > SCMs really fit Smalltalk. When we are arguing about whether git | > or mercurial is better on the Pharo list, I will retract that | > statement:). | > | > Without a standard SCM, the first thing that a 200 person | > engineering groups needs to do to start using Smalltalk is figure | > out (for themselves) how to share their work and keep 200 | > individual images in synch ... I'm not necessarily convinced that | > anyone has really solved this one. | > | > Personally I believe that the problem is surmountable, but for | > whatever reason the Smalltalk community hasn't focussed on | > seriously addressing the SCM issue .... in the last 30 years or | > so:) | > | > Being able to repeatably build images based on a minimal core image | > is certainly headed in the right direction, but we still have a | > ways to go on the tools front ... | > | > Dale | > | > | > | > ----- Original Message ----- | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | vwnc@cs.uiuc.edu | > | Sent: Saturday, January 28, 2012 7:46:32 AM | > | Subject: [squeak-dev] Smalltalk for small projects only? | > | | > | Hi guys, | > | | > | Ralph Johnson in his InfoQ interview made an interesting | > | observation: | > | | > | 2:55 minute: "Smalltalk made an fundamental error ... image ... | > | you | > | can | > | build something with 4-5 people what 50 people can build in Java, | > | but | > | if | > | you take 200 people in Java ... it is really designed for small | > | systems | > | ... " | > | | > | Are we because of the image really destined for relatively small | > | projects and small systems (of Java 50 people project size)? | > | | > | Are we really not able to scale to bigger projects/systems | > | because of | > | that? | > | | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | > | still... | > | | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | > | | > | Best regards | > | Janko | > | | > | | > | -- | > | Janko Mivšek | > | Aida/Web | > | Smalltalk Web Application Server | > | http://www.aidaweb.si | > | | > | | > | > | | -- | Janko Mivšek | Svetovalec za informatiko | Eranova d.o.o. | Ljubljana, Slovenija | www.eranova.si | tel: 01 514 22 55 | faks: 01 514 22 56 | gsm: 031 674 565 |
Frank,
No I meant what I said .... I'm not talking in a literal sense, but a functional sense ....
With Metacello I can 'clone' version 3.0.6 of Seaside30, i.e., make a local copy of all of mcz files that make up version 3.0.6 in local directory. If I load the files into an image I can edit the files including add new files, etc. and then 'commit' version 3.0.7 to my local directory, which includes new versions of files and a new version of the configuration. I can 'push' my local files (mcz and config) to the common repository and even 'pull', but when it comes to 'merge' it all falls apart, because 'merge' is not supported at the Metacello level. Monticello does a great job with merging and Metacello needs to step up to the plate on merge:)
Totally agree with you about builds...if customization is required, then each person around the world that does "a build" is not guaranteed to et exactly the same results...
Dale
----- Original Message ----- | From: "Frank Shearar" frank.shearar@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, "Janko Mivšek" janko.mivsek@eranova.si, Pharo-project@lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 1:45:04 PM | Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only? | | 2012/1/28 Dale Henrichs dhenrich@vmware.com: | > Janko, | > | > Metacello itself needs work to make it usable by groups of | > developers ... the lack of merge capability is a real hindrance to | > being able to have multiple folks work on the same project and use | > Metacello ... | > | > I imagine that a Metacello configuration is the moral equivalent of | > a git repository. It should be possible to find "moral | > equivalents" of the various git operations: clone, push, pull, | > branch, checkout, merge, commit. It is something that I will be | > looking into in the not too distant future, since I want to | > improve the usability of Metacello for groups of developers. | | Um, do you mean Metacello or Monticello? Metacello seems like the | maven of Java world: "Here's what this artifact contains, its | dependencies, where you can find them, etc. etc." | | > I agree that integrated tools is another area that needs | > attention.... when it is time to commit your work there are just | > too many different windows and browsers that you have to monkey | > with to save your work ... | > | > Another area that shouldn't be neglected is the notion of basing | > things on a minimal core image and automated builds for | > individuals ... We've got folks doing good things with Jenkins but | > I sense that with each installation there are things that still | > need to be customized in the build process itself. It should be | > dead simple, like compiling a c file when you know the path to an | > image... | | A build should be a single command, with no customisation required at | all. This is especially important in large projects. Being able to | customise/parameterise a build means having an artifact but not | knowing what went into building it. | | Otherwise, I agree. Luckily, more and more folks are starting to use | Metacello, and building images up from some small base. | | frank | | > I think we may focus too much on the in-image tools and not enough | > on the external tools that are just as important. | > | > We need to make it easy for a developer (in a team of developers) | > to check out a version of a minimal1 image, do a reproducible | > build of the correct version of the project, then fire up the | > image and do his or her development thang, | > commit/push/pull/merge/bang and then the next developer does | > pull/merge/build/boom to pick up the changes for her image and so | > on ... This involves more than just in-image tooling. | > | > Dale | > | > ----- Original Message ----- | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | To: Pharo-project@lists.gforge.inria.fr | > | Cc: "Dale Henrichs" dhenrich@vmware.com, "The general-purpose | > | Squeak developers list" | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | vwnc@cs.uiuc.edu | > | Sent: Saturday, January 28, 2012 12:16:55 PM | > | Subject: Re: [Smalltalk for small projects only? | > | | > | Dale, | > | | > | I agree with you that source code management is where we are | > | weak. A | > | process therefore, as James already said. | > | | > | In SCM VisualWorks is ahead in my opinion, even that Store is | > | also | > | not | > | perfect yet. But it would be useful to reuse some of ideas in | > | Monticello | > | based SCM tools too. With Metacello we got a good packaging tool, | > | so, | > | where to go to be even better? I think SCM tool integration into | > | code | > | browser can be next and relatively easy step. As Store is | > | integrated | > | into VW code browser. | > | | > | Janko | > | | > | S, Dale Henrichs piše: | > | > Janko, | > | > | > | > I think the limitation for Smalltalk lies in source code | > | > management | > | > tools/styles ... | > | > | > | > With a file-based language 200 engineers can contribute to the | > | > project ... each engineer can checkout a version of the system | > | > work in isolation then commit his or her work to the shared | > | > repository resolve conflicts and move on .... other engineers | > | > can | > | > easily integrate the work and so on ... the source code | > | > management | > | > tools scale ... | > | > | > | > In the mid nineties at ParcPlace systems the image was passed | > | > around from engineer to engineer so that he or she could | > | > integrate | > | > their work into the production image... this doesn't scale... | > | > | > | > There have been proprietary source code management tools that | > | > have | > | > been created over the years. You can bet that the large | > | > companies | > | > that are invested in Smalltalk are using systems that are based | > | > on | > | > these proprietary systems, but you can also bet that they've | > | > had | > | > to customize those systems for their needs... | > | > | > | > The file-based SCM systems work out of the box and don't care | > | > what | > | > language or even development process that is being used ... | > | > they | > | > are managing files ... | > | > | > | > There is no standard SCM for Smalltalk and none of the | > | > file-based | > | > SCMs really fit Smalltalk. When we are arguing about whether | > | > git | > | > or mercurial is better on the Pharo list, I will retract that | > | > statement:). | > | > | > | > Without a standard SCM, the first thing that a 200 person | > | > engineering groups needs to do to start using Smalltalk is | > | > figure | > | > out (for themselves) how to share their work and keep 200 | > | > individual images in synch ... I'm not necessarily convinced | > | > that | > | > anyone has really solved this one. | > | > | > | > Personally I believe that the problem is surmountable, but for | > | > whatever reason the Smalltalk community hasn't focussed on | > | > seriously addressing the SCM issue .... in the last 30 years or | > | > so:) | > | > | > | > Being able to repeatably build images based on a minimal core | > | > image | > | > is certainly headed in the right direction, but we still have a | > | > ways to go on the tools front ... | > | > | > | > Dale | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Janko Mivšek" janko.mivsek@eranova.si | > | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | > | squeak-dev@lists.squeakfoundation.org, "VWNC" | > | > | vwnc@cs.uiuc.edu | > | > | Sent: Saturday, January 28, 2012 7:46:32 AM | > | > | Subject: [squeak-dev] Smalltalk for small projects only? | > | > | | > | > | Hi guys, | > | > | | > | > | Ralph Johnson in his InfoQ interview made an interesting | > | > | observation: | > | > | | > | > | 2:55 minute: "Smalltalk made an fundamental error ... image | > | > | ... | > | > | you | > | > | can | > | > | build something with 4-5 people what 50 people can build in | > | > | Java, | > | > | but | > | > | if | > | > | you take 200 people in Java ... it is really designed for | > | > | small | > | > | systems | > | > | ... " | > | > | | > | > | Are we because of the image really destined for relatively | > | > | small | > | > | projects and small systems (of Java 50 people project size)? | > | > | | > | > | Are we really not able to scale to bigger projects/systems | > | > | because of | > | > | that? | > | > | | > | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), | > | > | but | > | > | still... | > | > | | > | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | > | > | | > | > | Best regards | > | > | Janko | > | > | | > | > | | > | > | -- | > | > | Janko Mivšek | > | > | Aida/Web | > | > | Smalltalk Web Application Server | > | > | http://www.aidaweb.si | > | > | | > | > | | > | > | > | > | > | | > | -- | > | Janko Mivšek | > | Svetovalec za informatiko | > | Eranova d.o.o. | > | Ljubljana, Slovenija | > | www.eranova.si | > | tel: 01 514 22 55 | > | faks: 01 514 22 56 | > | gsm: 031 674 565 | > | | > | |
The idea of building the git workflow on top of metacello strikes me as being somewhat ambitious.
To do merge properly (which is one of the huge strengths of git), using a single .gz file seems likely to be extremely complex.
clone is just copying a .gz file?
pull/push are ftp upload/download of entire .gz file? git has some safety features that would be tricky to implement on top of metacello I think
branch and checkout operations in git are crazy fast because of the clever model it uses
monticello/metacello have the advantage of cross dialect support (Squeak/Pharo/GemStone and VW to some extent), but it seems the semantics may not be rich enough.
Of course this is just an impression. If someone has some more detailed thoughts I would be keen to hear them.
Thanks, Steve
2012/1/28 Dale Henrichs dhenrich@vmware.com
Janko,
Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...
I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.
I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...
Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...
I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.
We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.
Dale
Steve,
I have two comments:
1. "inventing the future" doesn't happen by considering how "ambitious" it may seem. In the end it is probably easier than you think and harder than I think. If it was real easy, I'd have been done by now:)
2. I propose a race:
You start working on your git backend for Smalltalk and I'll continue working on Metacello, first one to "git work flow" wins ... But then the real winners will be the Smalltalk Community...
I have said this before: "I can hardly wait until someone invents the replacement for Metacello---it will give me more time for other projects:)"
Dale
----- Original Message ----- | From: "Steve Wart" steve@wart.ca | | The idea of building the git workflow on top of metacello strikes me | as being somewhat ambitious.
Hi Dale
First let me apologize for using such a horrible IT euphemism. I have been hanging around software politicians for far too long. I think you deserve all the credit for coming up with an elegant and effective configuration management system that has brought many parts of the Smalltalk community together to build common, useful and practical tools.
Regarding your race suggestion, I think you are right that having more choices will be good for the community. I can't claim that I don't have resources available - I can come up with a few hours a week to work on this. I'll start with the links Frank posted, but I think the two approaches in the end may share some common features.
I've been thinking about this idea for a long time but without feedback I haven't had the courage to start. Maybe I can finally help.
Cheers, Steve
On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs dhenrich@vmware.com wrote:
Steve,
I have two comments:
"inventing the future" doesn't happen by considering how "ambitious" it may seem. In the end it is probably easier than you think and harder than I think. If it was real easy, I'd have been done by now:)
I propose a race:
You start working on your git backend for Smalltalk and I'll continue working on Metacello, first one to "git work flow" wins ... But then the real winners will be the Smalltalk Community...
I have said this before: "I can hardly wait until someone invents the replacement for Metacello---it will give me more time for other projects:)"
Dale
----- Original Message ----- | From: "Steve Wart" steve@wart.ca | | The idea of building the git workflow on top of metacello strikes me | as being somewhat ambitious.
Steve,
Ah yes, the old "it's too hard to do the right thing, so let's do what we want to do" argument. Haha ... no offense taken. As you mention it is easy to fall into that trap.
While it's true that I put a lot of effort into Metacello, it isn't true that "I deserve all the credit" ... nothing happens in a vacuum, significant contributions were made by Stef, Doru, Mariano, Alexandre and others (I guess this is the season for the Academy Awards:) ... thanks, and enough of that:)
Metacello was created to address a specific set of problems that I was having while working on GLASS and those problems were being experienced by a wider group of folks than just myself and the users of GLASS, which lead to it's broad acceptance ...
With that said, I always maintain that there are "more than one way to skin a cat." And Metacello just happens to be one of the ways to skin the cat.
I've been living in the Smalltalk community for most of the last 25+ years so just I don't have the familiarity with the other configuration management systems to do a good job of integrating them into the Smalltalk development environment ...
My take is that it will be "too hard" (right back at ya:), especially for me.
To the extent that I have the time I am willing to offer you (or anyone else working in the area on alternate approaches) constructive criticism as well as advice about what I consider the "barriers to acceptance" are going to be ...
Dale
----- Original Message ----- | From: "Steve Wart" steve@wart.ca | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC" vwnc@cs.uiuc.edu, "Janko Mivšek" janko.mivsek@eranova.si, Pharo-project@lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 11:47:34 AM | Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only? | | | Hi Dale | | First let me apologize for using such a horrible IT euphemism. I have | been hanging around software politicians for far too long. I think | you deserve all the credit for coming up with an elegant and | effective configuration management system that has brought many | parts of the Smalltalk community together to build common, useful | and practical tools. | | Regarding your race suggestion, I think you are right that having | more choices will be good for the community. I can't claim that I | don't have resources available - I can come up with a few hours a | week to work on this. I'll start with the links Frank posted, but I | think the two approaches in the end may share some common features. | | I've been thinking about this idea for a long time but without | feedback I haven't had the courage to start. Maybe I can finally | help. | | Cheers, | Steve | | | On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | | Steve, | | I have two comments: | | 1. "inventing the future" doesn't happen by considering | how "ambitious" it may seem. In the end it is probably | easier than you think and harder than I think. If it was | real easy, I'd have been done by now:) | | 2. I propose a race: | | You start working on your git backend for Smalltalk and | I'll continue working on Metacello, first one to "git work | flow" wins ... But then the real winners will be the Smalltalk | Community... | | I have said this before: "I can hardly wait until someone | invents the replacement for Metacello---it will give me | more time for other projects:)" | | | Dale | | ----- Original Message ----- | | | | From: "Steve Wart" < steve@wart.ca > | | | | The idea of building the git workflow on top of metacello strikes | | me | | as being somewhat ambitious. | | | | |
On Sat, Jan 28, 2012 at 10:07 AM, Dale Henrichs dhenrich@vmware.com wrote:
Janko,
I think the limitation for Smalltalk lies in source code management tools/styles ...
With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
False. We used change sets to exchange small deltas. We constructed base-line images (analogous to releases), but I never got an image from someone else except as a context in which a bug was easily reproducible. By the late 90's we were using parcels to exchange components, and composing the image from these components.
There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
I disagree. If you've ever used e.g. svn to manage something even medium-sized you'll find out it handles merge and distribution far worse than e.g. Monticello or Store. The main difference is definition-level differencing and decomposition into components. Typical copmponents in a file-based system are spread over a set of files, often with components tangling with each other in certain files. This still happens in Smalltalk, but to a lesser extent, being more manageable with package overrides and e.g. schemes such as menu pragmas to provide soft integration of overlapping components.
There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
This is a straw man. Here's a scheme that works and scales. Routinely produce a new baseline image which has the accepted main line merged into it. People take this image, load their components into it and program relative to it. Then they commit to the central repository when ready (being able to use their own local repositories for their own branches etc). This scheme has appeared in various guises, from the original Smalltalk group (6-monthly baselines, meetings to decide the contents of the base image) to e.g. weekly builds at Qwaq.
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
Personally I find Monticello significantly more powerful than mercurial or svn, that I have a lot of experience with. I disagree also that no-one has focussed on the issue Both Cincom has put in significant effort into Store, and the Squeak community (yourself included) has put significant effort into Monticello.
Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
Sure, but one can put together something for Smalltalk by hand in very little time. If you compare building an automated bootstrap for Smalltalk (I just did one for Newspeak over the last few days) compared to using e.g. ANT, there's not much difference, except that the Smalltalk one is easily debuggable.
If there is a difference it is the self-containedness of Smalltalk vs the catholicism of file-based tools. Smalltalk falls flat on its face when one wants to do ANT-like things that build other than purely Smalltalk artifacts. Things like ANT are far weaker but far more general tools than their Smalltalk equivalents. For me this comes dow to not enough emphasis on Smalltalk as a platform, where platform is something that supports integrating with the surrounding ecosystem. In Squeak the FFI, file system and external process interfaces are really weak. A good challenge would be to reimplement ANT (a Java application) in Squeak/Pharo. That would force us to address real weaknesses.
Dale
----- Original Message ----- | From: "Janko Mivšek" janko.mivsek@eranova.si | To: Pharo-project@lists.gforge.inria.fr, "Squeak" < squeak-dev@lists.squeakfoundation.org>, "VWNC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] Smalltalk for small projects only? | | Hi guys, | | Ralph Johnson in his InfoQ interview made an interesting observation: | | 2:55 minute: "Smalltalk made an fundamental error ... image ... you | can | build something with 4-5 people what 50 people can build in Java, but | if | you take 200 people in Java ... it is really designed for small | systems | ... " | | Are we because of the image really destined for relatively small | projects and small systems (of Java 50 people project size)? | | Are we really not able to scale to bigger projects/systems because of | that? | | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but | still... | | [1] http://www.infoq.com/interviews/johnson-armstrong-oop | | Best regards | Janko | | | -- | Janko Mivšek | Aida/Web | Smalltalk Web Application Server | http://www.aidaweb.si | |
2012/1/31 Eliot Miranda eliot.miranda@gmail.com
A good challenge would be to reimplement ANT (a Java application) in Squeak/Pharo. That would force us to address real weaknesses.
I can vouch for this. I wrote Filesystem because trying to write Mason using FileDirectory was too painful.
Colin
On 02/01/2012 06:17 AM, Colin Putney wrote:
2012/1/31 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>
A good challenge would be to reimplement ANT (a Java application) in Squeak/Pharo. That would force us to address real weaknesses.I can vouch for this. I wrote Filesystem because trying to write Mason using FileDirectory was too painful.
AFAIK this has already been done by Keith Hodges (for Squeak building - not general building) in multiple layers (Bob the Builder, Sake etc):
http://www.squeaksource.com/Bob.html http://www.squeaksource.com/Packages.html http://www.squeaksource.com/Sake.html
...but perhaps you meant for "generic software building".
regards, Göran
2012/1/31 Göran Krampe goran@krampe.se
On 02/01/2012 06:17 AM, Colin Putney wrote:
2012/1/31 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.**com eliot.miranda@gmail.com>>
A good challenge would be to reimplement ANT (a Java application) in Squeak/Pharo. That would force us to address real weaknesses.
I can vouch for this. I wrote Filesystem because trying to write Mason using FileDirectory was too painful.
AFAIK this has already been done by Keith Hodges (for Squeak building - not general building) in multiple layers (Bob the Builder, Sake etc):
http://www.squeaksource.com/**Bob.htmlhttp://www.squeaksource.com/Bob.html http://www.squeaksource.com/**Packages.htmlhttp://www.squeaksource.com/Packages.html http://www.squeaksource.com/**Sake.htmlhttp://www.squeaksource.com/Sake.html
...but perhaps you meant for "generic software building".
Yes. ANT is cross-platform and generic. I expect Squeak/Pharo would need lots of work beyond Colin's new file system and OSProcess to provide similar functionality. I think it would be a great driver to get the right support.
regards, Göran
200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :)
Laurent
2012/1/28 Janko Mivšek janko.mivsek@eranova.si
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hi all,
Programming in the large with 50 or 200 programmers... This discussion illustrates that we have moved a long way from Alan Kay's vision of the Dynabook; "/... a laptop personal computer for children of all ages/". A personal computer that contains my personal data. Data that I own and manage with personal programs, some of them written by me. Smalltalk was targeted to be the software system for the Dynabook. A single programmer, often myself.
I have followed this list for some years now, and I miss greater interest in the ultimate end user of the software; the human. I am working with many others on a paradigm that puts the end user in the driver's seat. A paradigm based on objects (not classes) for mental models that are shared and understood by end users and programmers alike. A paradigm that models the realization of use cases. A paradigm that leads to models that can be faithfully implemented in software to ensure that there will be no surprises.
The Squeak environment is essentially based on objects and is an ideal starting point for implementing new paradigms. The Squeak programming environment has to be extended with facilities for describing how ensembles of objects interact to achieve a common goal. It's easy to do in Squeak. So why not?
More at _fullOO.info_.
Cheers --Trygve
On 2012.01.28 16:46, Janko Mivšek wrote:
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
On Tue, Jan 31, 2012 at 05:44:52PM +0100, Trygve Reenskaug wrote:
Hi all,
Programming in the large with 50 or 200 programmers... This discussion illustrates that we have moved a long way from Alan Kay's vision of the Dynabook; "/... a laptop personal computer for children of all ages/". A personal computer that contains my personal data. Data that I own and manage with personal programs, some of them written by me. Smalltalk was targeted to be the software system for the Dynabook. A single programmer, often myself.
I have followed this list for some years now, and I miss greater interest in the ultimate end user of the software; the human.
Thanks for this comment. It is quite striking that the human aspects of this tool for children of all ages are so widely overlooked. But on the positive side we have things like Dr Geo, Etoys, Scratch and others that at show a real interest in learning, exploring, and communicating ideas.
I have to laugh every time I read someone making a comment to the effect that Squeak is not "serious" because it has a silly name. I love the silly name, because it takes a gentle poke at all of us who become distracted into thinking that tools and technology are more important than thinking and communicating.
Dave
I am working with many others on a paradigm that puts the end user in the driver's seat. A paradigm based on objects (not classes) for mental models that are shared and understood by end users and programmers alike. A paradigm that models the realization of use cases. A paradigm that leads to models that can be faithfully implemented in software to ensure that there will be no surprises.
The Squeak environment is essentially based on objects and is an ideal starting point for implementing new paradigms. The Squeak programming environment has to be extended with facilities for describing how ensembles of objects interact to achieve a common goal. It's easy to do in Squeak. So why not?
More at _fullOO.info_.
Cheers --Trygve
On 2012.01.28 16:46, Janko Miv??ek wrote:
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
--
Trygve Reenskaug mailto: trygver@ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
On Wednesday 01 Feb 2012 8:36:45 AM David T. Lewis wrote:
I have to laugh every time I read someone making a comment to the effect that Squeak is not "serious" because it has a silly name. I love the silly name, because it takes a gentle poke at all of us who become distracted into thinking that tools and technology are more important than thinking and communicating.
+1
Classifying work into as productive or unproductive/leisure/entertainment is an artifact of industrial age. Watching kids learn through play is the best antidote to this tendency ;-).
If work is to become play, then tools should become toys .. Lee Felsenstein
Regards .. Subbu
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
Dale Henrichs -
Darius Clarke -
David T. Lewis -
dimitris chloupis -
Eliot Miranda -
Frank Shearar -
Göran Krampe -
James Robertson -
Janko Mivšek -
K. K. Subramaniam -
karl ramberg -
laurent laffont -
Lawson English -
Michael Haupt -
stephane ducasse -
Steve Wart -
Stéphane Ducasse -
Sven Van Caekenberghe -
Trygve Reenskaug