"Janko Mivšek"janko.mivsek@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.
+1
On Jan 28, 2012, at 7:38 PM, mkobetic@gmail.com wrote:
"Janko Mivšek"janko.mivsek@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.
James Robertson http://www.jarober.com jarober@gmail.com
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@gmail.com | To: "Janko Mivšek" janko.mivsek@eranova.si | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" squeak-dev@lists.squeakfoundation.org, Pharo-project@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@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. | |
Outside the micro-image, we use tools like that on the project I work on - I'll be talking about them at the STIC conference (and they are in the Cincom public Store right now, name BuilderBundle).
We start from visual.im
-- load Store tools -- load application code -- save development image -- build runtime image, save it -- compress the runtime (using VW tools) -- run tests, report on results -- copy all final files (dev image, runtimes, and reports) to a share drive location -- send email to specified recipient as to build results
That whole process could run on an automated basis, but we still have some process hurdles sitting in front of that. Bottom line though, getting a clean build out of this process has been working for us for months. To be honest, the idea of a micro-image isn't all that interesting to me. Unless you're building for embedded/mobile platforms, having a 20 MB deployment image is a non-issue, and the base image (visual.im above) is already in a known state.
On Jan 28, 2012, at 8:30 PM, Dale Henrichs wrote:
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:
- decide which base image (thing choosing between Squeak 4.3 and Pharo 1.3) to use for development
- run image build script starting with the micro-image that produces a deployment image and a development image
- fire up development image and write code using all of the nifty in-image development tools
- committing your work involves saving your code and updating the build script
- 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@gmail.com | To: "Janko Mivšek" janko.mivsek@eranova.si | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" squeak-dev@lists.squeakfoundation.org, Pharo-project@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@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. | |
James Robertson http://www.jarober.com jarober@gmail.com
James,
I know that some folks follow this development pattern, but it isn't the norm.
I'm postulating that following this development pattern would be a "good thing" on multiple fronts, it should be the norm for getting started with any smalltalk platform... if individual developers want to build an image and never build from scratch again, then that is their choice, but I think it should be a choice rather than the standard practice ...
The idea of a micro-image is what appeals to me ... when you have a micro-image as a starting point it is much easier to consider and use alternate base library implementations which in turns make it easier to move the language forward ... it also acts as a forcing function for tools since you start having to consider that the tools aren't in your application issues which sorta brings us back around the the idea of Declarative Smalltalk I mentioned before ...
Dale
----- Original Message ----- | From: "James Robertson" jarober@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "VWNC NC" vwnc@cs.uiuc.edu | Sent: Saturday, January 28, 2012 5:46:48 PM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | Outside the micro-image, we use tools like that on the project I work | on - I'll be talking about them at the STIC conference (and they are | in the Cincom public Store right now, name BuilderBundle). | | We start from visual.im | | -- load Store tools | -- load application code | -- save development image | -- build runtime image, save it | -- compress the runtime (using VW tools) | -- run tests, report on results | -- copy all final files (dev image, runtimes, and reports) to a share | drive location | -- send email to specified recipient as to build results | | That whole process could run on an automated basis, but we still have | some process hurdles sitting in front of that. Bottom line though, | getting a clean build out of this process has been working for us | for months. To be honest, the idea of a micro-image isn't all that | interesting to me. Unless you're building for embedded/mobile | platforms, having a 20 MB deployment image is a non-issue, and the | base image (visual.im above) is already in a known state. | | On Jan 28, 2012, at 8:30 PM, Dale Henrichs wrote: | | > 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@gmail.com | > | To: "Janko Mivšek" janko.mivsek@eranova.si | > | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" | > | squeak-dev@lists.squeakfoundation.org, | > | Pharo-project@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@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. | > | | > | | > | | James Robertson | http://www.jarober.com | jarober@gmail.com | | | | |
Am 29.01.2012 02:46, schrieb James Robertson:
We start from visual.im
-- load Store tools -- load application code -- save development image -- build runtime image, save it -- compress the runtime (using VW tools) -- run tests, report on results -- copy all final files (dev image, runtimes, and reports) to a share drive location -- send email to specified recipient as to build results
In the VA Smalltalk project that I've been working in for more than 10 years, we've been doing something similar for quite a long time (not from the beginning, but at least 5-6 years). There's one builder image (which is created by loading just one app into a virgin VAST image) which is started from a batch file passing the relevant parameters which specify what config maps should be loaded, what if any tests should be run and whether a runtime image should be built. This image is being used by a number of small batch files for unit tests and runtime image construction. It's not automated yet (mostly because I can't be bothered with finding out how to set up repeating jobs on Windows), but running it is just a matter of double-clicking on a batch file, so it's not a big deal. Of course, with ENVY you get very powerful version control, so this project could successfully be built by about 20 developers, at that time targeting OS/2 and VAST 6.0, and has been pushed through several VAST versions, survived a target platform change to Windows, has been extended to include functionality previously supplied by an additional software system which was unavailable for reasons I won't go into here. Although this is not a "huge" project it shows that projects with a significant number of developers can be developed robustly in Smalltalk. The image is definitely not a problem for us - during development, it's very handy to always have everything available in the morning just as you left it when going home, and for deployment it's just another way of packaging the application. Much easier than, say, Java apps which consist of oodles of .jar files and xml configurations and whatever.
I have always been under the impression that the obstacles to using Smalltalk in many organization are a combination of badmouthing, misinformation, histories of bad licensing policies and perceived vendor instabilities. The PPS/Digitalk merger, although it is clearly history, did its thing, as well as the Instantiations phoenix-from-the-ashes stunt.
What can one do about it? Seriously, I don't have an answer. We're mostly technical guys, and those normally don't have a say in the decisions about project tools. I'd be interested in seeing analyses of large Smalltalk projects and the reason they either succeeded or floundered. What were the actual reasons for DabbleDB to go under, why couldn't Teleplace make enough money to survive, ...? Was it the technology, or was it that companies initiated by mostly technical people have a hard time surviving when facing economical upheaval?
Cheers, Hans-Martin
Hans-Martin Mosner wrote:
What were the actual reasons for DabbleDB to go under ...?
DabbleDB didn't go under. It was purchased by Twitter, who moved it to San Francisco, in order for Twitter to make use of its Smalltalk expertise and the Trendly product.
The question is merely: why did Twitter choose to close down the DabbleDB product (rather than sell the business or recruit a maintenance staff)?(*)
Another useful question: what is Twitter doing successfully with Smalltalk that helps to change the world?
David
* p.s. The answer may be more of a business one: could a tiny business like DabbleDB compete with established products like Access, Excel, Sybase, dBase and SQL Server, just by being easier to use? (Not to mention several other data management tools that were on the lips of business and office administration types before DabbleDB.)
On Sun, Jan 29, I wrote:
DabbleDB didn't go under. It was purchased by Twitter, who moved it to San Francisco, in order for Twitter to make use of its Smalltalk expertise and the Trendly product.
I since looked deeper and read that Trendly was a Ruby product. I don't know if Smallthought Systems used Smalltalk at Twitter or not.
David
On 01/29/2012 09:21 PM, David Corking wrote:
Hans-Martin Mosner wrote:
What were the actual reasons for DabbleDB to go under ...?
DabbleDB didn't go under. It was purchased by Twitter, who moved it to San Francisco, in order for Twitter to make use of its Smalltalk expertise and the Trendly product.
Mmm, my impression is rather that Twitter buys small talented companies simply because it is easier to find really good people that way instead of hiring (if you have loads of money to spend). They have done it before, and they probably told the Smallthought guys that they didn't want them to be distracted by their old stuff - thus "shutdown".
The question is merely: why did Twitter choose to close down the DabbleDB product (rather than sell the business or recruit a maintenance staff)?(*)
Simplest path. All other paths take money, time, legal to be involved, etc etc.
Another useful question: what is Twitter doing successfully with Smalltalk that helps to change the world?
No idea, but I did recently note that Avi is not there anymore ;)
regards, Göran
Hans-Martin,
(mostly because I can't be bothered with finding out how to set up repeating jobs on Windows)
Try running "taskschd" from the command line. also: http://technet.microsoft.com/en-us/library/cc721931.aspx
Cheers, Darius ______________
On Sun, Jan 29, 2012 at 10:18 AM, Hans-Martin Mosner hmm@heeg.de wrote:
Am 29.01.2012 02:46, schrieb James Robertson:
We start from visual.im
-- load Store tools -- load application code -- save development image -- build runtime image, save it -- compress the runtime (using VW tools) -- run tests, report on results -- copy all final files (dev image, runtimes, and reports) to a share
drive location
-- send email to specified recipient as to build results
In the VA Smalltalk project that I've been working in for more than 10 years, we've been doing something similar for quite a long time (not from the beginning, but at least 5-6 years). There's one builder image (which is created by loading just one app into a virgin VAST image) which is started from a batch file passing the relevant parameters which specify what config maps should be loaded, what if any tests should be run and whether a runtime image should be built. This image is being used by a number of small batch files for unit tests and runtime image construction. It's not automated yet (mostly because I can't be bothered with finding out how to set up repeating jobs on Windows), but running it is just a matter of double-clicking on a batch file, so it's not a big deal. Of course, with ENVY you get very powerful version control, so this project could successfully be built by about 20 developers, at that time targeting OS/2 and VAST 6.0, and has been pushed through several VAST versions, survived a target platform change to Windows, has been extended to include functionality previously supplied by an additional software system which was unavailable for reasons I won't go into here. Although this is not a "huge" project it shows that projects with a significant number of developers can be developed robustly in Smalltalk. The image is definitely not a problem for us - during development, it's very handy to always have everything available in the morning just as you left it when going home, and for deployment it's just another way of packaging the application. Much easier than, say, Java apps which consist of oodles of .jar files and xml configurations and whatever.
I have always been under the impression that the obstacles to using Smalltalk in many organization are a combination of badmouthing, misinformation, histories of bad licensing policies and perceived vendor instabilities. The PPS/Digitalk merger, although it is clearly history, did its thing, as well as the Instantiations phoenix-from-the-ashes stunt.
What can one do about it? Seriously, I don't have an answer. We're mostly technical guys, and those normally don't have a say in the decisions about project tools. I'd be interested in seeing analyses of large Smalltalk projects and the reason they either succeeded or floundered. What were the actual reasons for DabbleDB to go under, why couldn't Teleplace make enough money to survive, ...? Was it the technology, or was it that companies initiated by mostly technical people have a hard time surviving when facing economical upheaval?
Cheers, Hans-Martin
I agree with Dale that being able to automate building of images is essential for large projects -- because it provides a necessary starting point of coordination among the large group that, itself, is capable of advancing forward (thus advancing the entire group with it).
Whether this function should be part of the SCM toolset -- I'm not sure..
We've gotten by for at least the last 4 years using a very simple procedure for building our images. We use SVN to keep version history of three .st scripts:
vanilla.st app.st deluxe.st
What we do is use a make script to launch the stock Squeak 4.3 image with vanilla.st script as input. It's just an Installer script that loads latest versions of our base frameworks we need: Seaside, Magma, etc. and saves as vanilla.image.
Next, the make script launches the just-saved vanilla.image with app.st as input. That script loads our proprietary application code and saves as app.image.
app.image is then launched with deluxe.st as input. This one adds developer tools, etc.
The only time we need to update any of the .st scripts is when we make a new package -- a rare occurrence anymore.
So, with SVN and make, we have "one button" ability to produce 3 tiers of images.
An all-Smalltalk tool to do the same -- one that did not require make and SVN, would be nice.
- Chris
On Sat, Jan 28, 2012 at 7:30 PM, Dale Henrichs dhenrich@vmware.com wrote:
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@gmail.com | To: "Janko Mivšek" janko.mivsek@eranova.si | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" squeak-dev@lists.squeakfoundation.org, Pharo-project@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@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. | |
Chris,
Agreed ... the only required link to SCM is during the code loading ...
As I have suspected, this operation is being done by individual development groups (because they consider it a requirement), but as a community we don't provide out-of-the-box support and we should ...
Dale
----- Original Message ----- | From: "Chris Muller" asqueaker@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Sent: Sunday, January 29, 2012 1:14:06 PM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | I agree with Dale that being able to automate building of images is | essential for large projects -- because it provides a necessary | starting point of coordination among the large group that, itself, is | capable of advancing forward (thus advancing the entire group with | it). | | Whether this function should be part of the SCM toolset -- I'm not | sure.. | | We've gotten by for at least the last 4 years using a very simple | procedure for building our images. We use SVN to keep version | history | of three .st scripts: | | vanilla.st | app.st | deluxe.st | | What we do is use a make script to launch the stock Squeak 4.3 image | with vanilla.st script as input. It's just an Installer script that | loads latest versions of our base frameworks we need: Seaside, | Magma, | etc. and saves as vanilla.image. | | Next, the make script launches the just-saved vanilla.image with | app.st as input. That script loads our proprietary application code | and saves as app.image. | | app.image is then launched with deluxe.st as input. This one adds | developer tools, etc. | | The only time we need to update any of the .st scripts is when we | make | a new package -- a rare occurrence anymore. | | So, with SVN and make, we have "one button" ability to produce 3 | tiers | of images. | | An all-Smalltalk tool to do the same -- one that did not require make | and SVN, would be nice. | | - Chris | | | On Sat, Jan 28, 2012 at 7:30 PM, Dale Henrichs dhenrich@vmware.com | wrote: | > 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@gmail.com | > | To: "Janko Mivšek" janko.mivsek@eranova.si | > | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" | > | squeak-dev@lists.squeakfoundation.org, | > | Pharo-project@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@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. | > | | > | | > | |
Hey all!
On 01/29/2012 02:30 AM, Dale Henrichs wrote:
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:
- decide which base image (thing choosing between Squeak 4.3 and Pharo 1.3) to use for development
- run image build script starting with the micro-image that produces a deployment image and a development image
- fire up development image and write code using all of the nifty in-image development tools
- committing your work involves saving your code and updating the build script
- 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 ...
Now... the above model is exactly what we used in Gjallar. We used a build script using Installer (Metacello was not around - and frankly, Metacello seems so... complicated to me) and a base image, trivially simple but worked fine.
Aother "silly simple trick" was that I took the role as "trunk" so everyone knew that gk-snapshots were regularly picking up other people's contributions. This took some "merge load" off people.
But I can't really see why any reasonably large project would *not* use a process similar to this, and I can't see how this would "force our tools to improve" either.
regards, Göran
PS. The process worked fine but our team was never that large. Yes, we started feeling the "scale problem" with MC, but the fact that you get away with "larger commits" with MC took off some of the pain. Though of course not optimal, smaller commits would of course be The Right Thing.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Dale Henrichs -
Darius Clarke -
David Corking -
Göran Krampe -
Hans-Martin Mosner -
James Robertson -
mkobetic＠gmail.com