Smalltalk for small projects only?

When you say "divided", are you thinking of
   - multiple communicating images??
   - multiple streams of development to be eventually combined into one
image??


On 2012-01-28 18:51, Ralph Johnson wrote:
--
Dennis Smith                                  +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada                     http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Janko Mivšek"<[hidden email]> 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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

+1

On Jan 28, 2012, at 7:38 PM, [hidden email] wrote:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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: [hidden email]
| To: "Janko Mivšek" <[hidden email]>
| Cc: "VWNC" <[hidden email]>, "Squeak" <[hidden email]>, [hidden email]
| Sent: Saturday, January 28, 2012 4:38:27 PM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
|
| "Janko Mivšek"<[hidden email]> 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.
|
|

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Cc: "VWNC NC" <[hidden email]>
| 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: [hidden email]
| > | To: "Janko Mivšek" <[hidden email]>
| > | Cc: "VWNC" <[hidden email]>, "Squeak"
| > | <[hidden email]>,
| > | [hidden email]
| > | Sent: Saturday, January 28, 2012 4:38:27 PM
| > | Subject: Re: [squeak-dev] Smalltalk for small projects only?
| > |
| > | "Janko Mivšek"<[hidden email]> 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
| [hidden email]
|
|
|
|
|

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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 :)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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" <[hidden email]>
|
| The idea of building the git workflow on top of metacello strikes me
| as being somewhat ambitious.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Cc: "VWNC" <[hidden email]>, "Janko Mivšek" <[hidden email]>, [hidden email]
| 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 < [hidden email]
| > 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" < [hidden email] >
| |
| | The idea of building the git workflow on top of metacello strikes
| | me
| | as being somewhat ambitious.
|
|
|
|
|

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Another +1 by me!

Let me add: if 4-5 Smalltalkers equals 50 Java developers. That is a factor of 10. What could you achieve with 50 Smalltalk developers? Or even 200? Let's ask this question!

Cheers
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von stephane ducasse
Gesendet: Samstag, 28. Januar 2012 20:19
An: The general-purpose Squeak developers list
Cc: VWNC NC
Betreff: Re: [vwnc] [squeak-dev] Smalltalk for small projects only?

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I'm interested in a related question - how big are current Smalltalk projects and what size of team is managing them?  I'll just use number of classes as an easy measurement.

I'll report on one project here:
    Classes: approximately 3500 classes
    Developers: 4

Does anybody else have numbers from their projects?

BTW, James and I discussed this thread on the Independent Misinterpretations podcast episode 63:

    AAC:    http://www.jarober.com/blog/blogView?entry=3505289363
    MP3:    http://www.jarober.com/blog/blogView?entry=3505289329

David Buck
Simberon Incorporated
www.simberon.com

Nowak, Helge wrote:

Another +1 by me!

Let me add: if 4-5 Smalltalkers equals 50 Java developers. That is a factor of 10. What could you achieve with 50 Smalltalk developers? Or even 200? Let's ask this question!

Cheers
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [[hidden email]] Im Auftrag von stephane ducasse
Gesendet: Samstag, 28. Januar 2012 20:19
An: The general-purpose Squeak developers list
Cc: VWNC NC
Betreff: Re: [vwnc] [squeak-dev] Smalltalk for small projects only?

+ 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
[hidden email]




    

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1416 / Virus Database: 2109/4775 - Release Date: 01/29/12


  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

It's very hard coming up with a metric. I picked number of classes only because it was the easiest for people to measure. Zipped source file size requires you to file out all your code and penalizes projects that use significant amounts of commenting. As well, methods like windowSpec and image resource methods would significantly increase the zipped source size for code that you don't maintain as source code.

I'll agree that number of classes is a bad measure, but it should allow some level of comparison. If we could directly measure function points that would be best but I'm unaware of tools that do that.

David Buck

---

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 30.01.2012 12:14, David Buck wrote:
> I'm interested in a related question - how big are current
> Smalltalk projects and what size of team is managing them?
> I'll just use number of classes as an easy measurement.
>
> I'll report on one project here:
> Classes: approximately 3500 classes
> Developers: 4
>
> Does anybody else have numbers from their projects?

Classes: > 11000 in active projects,
          more in our repository,
          not counting extensions to shipped libraries
Developers: currently 8

- Collective code ownership.
- Developing in VW
- Started with Envy, migrated to Store.
   Without a repository this would not be possible.
- Nightly build of development and deployment images from Store.
   Some developers use nightly development image, some keep
   their image and load updates from store.
- No image copying between developers.

About 20% of my development time is spent in Java. And every time I
wonder how people cope with the "one class, one file" metaphor when
comparing this to package extensions in VW. This "one file" approach
makes new orthogonal features more difficult than necessary and
requires more effort when merging into a repository.

Regards
   Jan
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Actually, the larger the team, the less you'll accomplish, IMHO.  Why?  Because IT politics will take over, and you'll end up being strangled by process.  This is independent of language/tools.


On Jan 30, 2012, at 4:11 AM, Nowak, Helge wrote:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Wow guys, it is nice for me to see that this thread raised some fruits
already and it seems it will even more in the future :)

Best regards
Janko

S, Dale Henrichs piše:
--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc