January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Dale Henrichs

Martin, Very good points ... So here's a little riff on: "Always start from a fresh one and load the code back in" Just imagine if the standard Smalltalk development experience started with a micro-image (a compiler and not much else) and then went through the following steps: 1. decide which base image (thing choosing between Squeak 4.3 and Pharo 1.3) to use for development 2. run image build script starting with the micro-image that produces a deployment image and a development image 3. fire up development image and write code using all of the nifty in-image development tools 4. committing your work involves saving your code and updating the build script 5. either continue development at step 3 or go back to step 2. If the project is successful, there may be demand to actually run on multiple platforms (Squeak 4.3 and Pharo 1.3 or Squeak 4.3 and Squeak 4.4), but then it should be as easy to build two sets of images as it is to build 1 If this were the standard development process for Smalltalk, I think that the SCM tools would be much better overall (the more engineers experiencing pain, the more chance that someone will decide to fix problems) and I think (as you imply) that Smalltalk would be easier for newbies to pick up on their own, since there is a familiar process and the illusion that programs are being created ... and oh yeah that 200 developer team would have the opportunity to fail miserably while using Smalltalk ... Dale ----- Original Message ----- | From: mkobetic(a)gmail.com | To: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> | Cc: "VWNC" <vwnc(a)cs.uiuc.edu>, "Squeak" <squeak-dev(a)lists.squeakfoundation.org>, Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 4:38:27 PM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | "Janko MivÅ¡ek"<janko.mivsek(a)eranova.si> wrote: | > 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)? | | The "image" argument is one of the easiest to pick when you want to | justify your xenophobic reaction to an unfamiliar environment you're | about to enter ("... but they are green and have antennas...", never | mind that the antennas may actually be useful for something). But | there's nothing fundamental about Smalltalk that requires an image, | c.f. there are a few Smalltalks that don't make you use one (e.g. | Smalltalk/X). It's just frozen state, many IDEs and editors allow | you to freeze their state (e.g. Eclipse workspace), it would be a | royal pain having to reopen the files you were working on manually | every time, wouldn't it. | | I think the problem is that most newbies, when being introduced to | Smalltalk, are immediately confronted with "the image" as if it was | something fundamental, like they couldn't get any further until they | grok it. But there's nothing preventing you from never saving the | image. Just commit your source code (and it could just as easily be | a common file based VC in the back there) and quit the image. Always | start from a fresh one and load the code back in. In this mode | there's (superficially*) no difference between Smalltalk and any | other IDE, you write your code, you run it, debug it, commit it, | etc. You can completely forget the image if you want, it's just that | most seasoned smalltalkers (the ones doing the introduction) have | learned to take advantage of the image and using it in all kinds of | creative ways, so they want to pass the knowledge along and manage | to freak the newbies out in the process. | | (*) the real difference between Smalltalk and other IDEs, that may or | may not be an issue in any particular case, is that the IDE runs in | the same memory space using the same code base as the application, | so your development can crash the IDE, while other IDEs prefer to | crash on their own :-). | | But I disagree that the image is some sort of technical obstacle to | scalability, I think it's completely orthogonal. The only place | where it's hard to ignore the image with the image based Smallltalks | is deployment. At this stage the image is the "compiled object | code", in the same sense that a shared library is "compiled object | code". You can (and some do) deploy as a clean base image, load the | application code on start and launch the application. That's no | different from a java or python app, their base image is just burned | into the VM. But it's so much easier to make that snapshot when all | of this is finally loaded in memory and ready to run. It loads | faster, there are no scattered files to hunt down in the dark | corners of the filesystem, makes perfect sense in many (most?) | cases. If people are freaked out that they don't need to mess with | CLASS_PATH, or PYTHONPATH or what have you, well, it would be quite | easy to "fix that", wouldn't it. | | You could say that every piece of software "has an image". When it is | loaded it initializes its runtime structures, lays them out in | memory and starts running. Nothing fundamentally different from the | base image case, the "image" is just burned into the executable. If | the VM was simply embedded in every saved smalltalk image and the | resulting file was turned into an executable, you can't really tell | the difference. The image just wouldn't be portable anymore. | | So I could agree that the image can be an obstacle to adoption if you | rub it in people's face, but it can just as easily be mostly | ignored. It's not significant unless you make it so in your | development process. | |

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by mkobetic＠gmail.com

"Janko MivÅ¡ek"<janko.mivsek(a)eranova.si> wrote: > 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)? The "image" argument is one of the easiest to pick when you want to justify your xenophobic reaction to an unfamiliar environment you're about to enter ("... but they are green and have antennas...", never mind that the antennas may actually be useful for something). But there's nothing fundamental about Smalltalk that requires an image, c.f. there are a few Smalltalks that don't make you use one (e.g. Smalltalk/X). It's just frozen state, many IDEs and editors allow you to freeze their state (e.g. Eclipse workspace), it would be a royal pain having to reopen the files you were working on manually every time, wouldn't it. I think the problem is that most newbies, when being introduced to Smalltalk, are immediately confronted with "the image" as if it was something fundamental, like they couldn't get any further until they grok it. But there's nothing preventing you from never saving the image. Just commit your source code (and it could just as easily be a common file based VC in the back there) and quit the image. Always start from a fresh one and load the code back in. In this mode there's (superficially*) no difference between Smalltalk and any other IDE, you write your code, you run it, debug it, commit it, etc. You can completely forget the image if you want, it's just that most seasoned smalltalkers (the ones doing the introduction) have learned to take advantage of the image and using it in all kinds of creative ways, so they want to pass the knowledge along and manage to freak the newbies out in the process. (*) the real difference between Smalltalk and other IDEs, that may or may not be an issue in any particular case, is that the IDE runs in the same memory space using the same code base as the application, so your development can crash the IDE, while other IDEs prefer to crash on their own :-). But I disagree that the image is some sort of technical obstacle to scalability, I think it's completely orthogonal. The only place where it's hard to ignore the image with the image based Smallltalks is deployment. At this stage the image is the "compiled object code", in the same sense that a shared library is "compiled object code". You can (and some do) deploy as a clean base image, load the application code on start and launch the application. That's no different from a java or python app, their base image is just burned into the VM. But it's so much easier to make that snapshot when all of this is finally loaded in memory and ready to run. It loads faster, there are no scattered files to hunt down in the dark corners of the filesystem, makes perfect sense in many (most?) cases. If people are freaked out that they don't need to mess with CLASS_PATH, or PYTHONPATH or what have you, well, it would be quite easy to "fix that", wouldn't it. You could say that every piece of software "has an image". When it is loaded it initializes its runtime structures, lays them out in memory and starts running. Nothing fundamentally different from the base image case, the "image" is just burned into the executable. If the VM was simply embedded in every saved smalltalk image and the resulting file was turned into an executable, you can't really tell the difference. The image just wouldn't be portable anymore. So I could agree that the image can be an obstacle to adoption if you rub it in people's face, but it can just as easily be mostly ignored. It's not significant unless you make it so in your development process.

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Lawson English

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 > > >

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Guido Stepken

Hi Dale! Quite interesting. Good example for "declarative programming" is Mustache: http://mustache.github.com/mustache.5.html It generally makes cross platform programming easier! :-) Have fun! Guido Stepken > > Karl, ... ... > I invite you to read Allen Wirfs-Brock's paper on "Declarative Smalltalk"[1] ... ... > 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

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Dale Henrichs

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(a)gmail.com> | To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> | Cc: "VWNC" <vwnc(a)cs.uiuc.edu>, Pharo-project(a)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(a)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

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Schwab,Wilhelm K

Understood. BTW, I'm a GOOD commander. I design stuff and parcel things out to troops to kick some and then report back, making myself available along the way. If it goes wrong, it's ON ME, not my people. Find a mainstream "manager" with those kind of cajones and we'll talk. Give me six good people, them, the 194 plus "tools" - they won't have a chance... ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, January 28, 2012 6:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only? On 28 January 2012 23:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > 200 5+year smalltalkers - that's an army capable of almost anything... > without good commander, this is not an army but a bunch of individuals. unfortunatelly, unlike the machines, human intelligence are not summing up linearly. Because then, you could just calculate, like If one developer will do project in 1 month, then 30 should do it in one day. No. Not going to happen :) -- Best regards, Igor Stasenko.

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Igor Stasenko

On 29 January 2012 00:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > EEEEEEKkkkkk Â :) > > "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." > > No, it's cool, it's EASY. Â "You just" check in your code and merge it. Â How dare you suggest that ****anything*** could go wrong during this sacred maneuver. Â If it does, just change SCM and blame the old one. Â By the time anyone figures out it did no good at all to switch, you've been promoted. Â Cool, eh? > :) Because there is no technical solutions for conflicts like: - one developer changed behavior/interface to do things he thinks they should - another developer changed behavior/interface to do things he thinks they should now try to merge it with your "magical" SCM which can resolve such kind of conflicts. :) > /satireOff. > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Saturday, January 28, 2012 2:08 PM > To: The general-purpose Squeak developers list > Cc: VWNC; Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [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 > > > > -- Best regards, Igor Stasenko.

Jan. 28, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Schwab,Wilhelm K

Thanks for your efforts. But hype the correct parts used properly. NB is an FFI alternative; it has zip to do with "creating applications" which is code wordism for starting over on every little job you do, because whoever works that way hasn't yet caught on to adding a facade/package to hold the incremental changes that make this small job different from that small job. All the other stuff can be "included" with NO effort by simply leaving it there. It takes a while to explain this to a smart person because they have a lot unlearn before they can make real progress. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Lawson English [lenglish5(a)cox.net] Sent: Saturday, January 28, 2012 2:16 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Smalltalk for small projects only? On 1/28/12 10:12 AM, Schwab,Wilhelm K wrote: You say "underhyped" as though this is bad - *hype* is BAAAAADD. Junk needs hype to survive. It took me a while to learn that "creating an application" in ST is "hard" - it's because it's not well supported because the initiated don't waste their time with it _until_ it comes time to deploy, and even then, it's not NEEDED. We need to teach, not pander, IMHO. Show people that there is a better way and what it is. A glossy ad compliant C# "application" that does what my pharo image can do would be a MONSTER. No one would build such a thing because they probably could not do so. Keep adding good stuff. In fact, there IS a better way. Igor's NativeBoost and NBOpenGL are a game-changer. My video tutorials aren't terribly well done compared to many others out there, but I do hype them a bit. The ones that get the most attention, by far, are those that show how to integrate OpenGL and Smalltalk. You want Pharo/Squeak/Smalltalk to become better used? Ensure that the most interesting (to the most programmers) aspects become well-known, and at least as importantly, well-supported. Lawson

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Igor Stasenko

On 28 January 2012 23:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > 200 5+year smalltalkers - that's an army capable of almost anything... > without good commander, this is not an army but a bunch of individuals. unfortunatelly, unlike the machines, human intelligence are not summing up linearly. Because then, you could just calculate, like If one developer will do project in 1 month, then 30 should do it in one day. No. Not going to happen :) -- Best regards, Igor Stasenko.

Jan. 28, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Schwab,Wilhelm K

EEEEEEKkkkkk :) "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." No, it's cool, it's EASY. "You just" check in your code and merge it. How dare you suggest that ****anything*** could go wrong during this sacred maneuver. If it does, just change SCM and blame the old one. By the time anyone figures out it did no good at all to switch, you've been promoted. Cool, eh? /satireOff. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Saturday, January 28, 2012 2:08 PM To: The general-purpose Squeak developers list Cc: VWNC; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [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

Jan. 28, 2012