Smalltalk for small projects only?

On 28 January 2012 23:58, Schwab,Wilhelm K <[hidden email]> wrote:
> 200 5+year smalltalkers - that's an army capable of almost anything...
>
without good commander, this is not an army but a bunch of individuals.

unfortunatelly, unlike the machines, human intelligence are not
summing up linearly.

Because then, you could just calculate, like
If one developer will do project in 1 month, then 30 should do it in one day.
No. Not going to happen :)



--
Best regards,
Igor Stasenko.

On 29 January 2012 00:04, Schwab,Wilhelm K <[hidden email]> wrote:
> EEEEEEKkkkkk   :)
>
> "In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related."
>
> No, it's cool, it's EASY.  "You just" check in your code and merge it.  How dare you suggest that ****anything*** could go wrong during this sacred maneuver.  If it does, just change SCM and blame the old one.  By the time anyone figures out it did no good at all to switch, you've been promoted.  Cool, eh?
>

:)

Because there is no technical solutions for conflicts like:
 - one developer changed behavior/interface to do things he thinks they should
 - another developer changed behavior/interface to do things he thinks
they should

 now try to merge it with your "magical" SCM which can resolve such
kind of conflicts.
:)





--
Best regards,
Igor Stasenko.

Understood. BTW, I'm a GOOD commander.  I design stuff and parcel things out to troops to kick some and then report back, making myself available along the way.  If it goes wrong, it's ON ME, not my people.

Find a mainstream "manager" with those kind of cajones and we'll talk.  Give me six good people, them, the 194 plus "tools" - they won't have a chance...



________________________________________
From: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
Sent: Saturday, January 28, 2012 6:07 PM
To: [hidden email]
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

On 28 January 2012 23:58, Schwab,Wilhelm K <[hidden email]> wrote:
> 200 5+year smalltalkers - that's an army capable of almost anything...
>
without good commander, this is not an army but a bunch of individuals.

unfortunatelly, unlike the machines, human intelligence are not
summing up linearly.

Because then, you could just calculate, like
If one developer will do project in 1 month, then 30 should do it in one day.
No. Not going to happen :)



--
Best regards,
Igor Stasenko.

Karl,

For the types of project that would employ a team of 200, you need to be able to reliably reproduce the state of an image, from scratch, 5 years after development has completed ...

I invite you to read Allen Wirfs-Brock's paper on "Declarative Smalltalk"[1]. Here are some excerpts:

  Smalltalk does not include the concept of a program as a distinct entity. In practice,
  a Smalltalk program is the state of a virtual image when work is declared completed.

  Lack of a program definition in traditional Smalltalk environments leads to an undue
  reliance on the virtual image. Images can become obsolete or broken. Because the program
  is encoded in the image, the program is in danger of becoming inaccessible if the image
  becomes outmoded or corrupt.

  The manual and unreliable nature of the initialization of Smalltalk programs leads to a
  number of program errors. Especially prevalent after reconstruction of a program in a new
  image are errors where program elements have an initial value of nil instead of some other
  value as originally intended by the programmer.

  The use of a declarative specification model has little direct impact upon Smalltalk programmers.
  Even though Smalltalk has traditionally been implemented using an imperative program description
  model, the perception of most Smalltalk programmers is of a declarative model. This is because
  Smalltalk programmers typically create and edit programs using a browser that presents the classes
  that make up the program in a declarative style.

Disclaimer: I worked with Allen Wirfs-Brock in the nineties (engineer on the Team/V team) while he was developing his ideas for Declarative Smalltalk, so I am somewhat biased in my thinking:)

My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door  for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)

Dale

[1] http://www.smalltalksystems.com/publications/_awss97/SSDCL1.HTM

----- Original Message -----
| From: "karl ramberg" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Cc: "VWNC" <[hidden email]>, [hidden email]
| Sent: Saturday, January 28, 2012 11:39:22 AM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
|
| On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs < [hidden email]
| > wrote:
|
| You are talking about dealing with source code, but what about the
| live objects in the image? Is there any work done on managing live
| images with several developers ? This is where Smalltalk excels and
| would be very interesting instead of falling back to the rebuild
| from source strategy.
|
| Karl

Hi Dale!

Quite interesting. Good example for "declarative programming" is Mustache:

http://mustache.github.com/mustache.5.html

It generally makes cross platform programming easier! :-)

Have fun!

Guido Stepken

>
> Karl,
...
...
> I invite you to read Allen Wirfs-Brock's paper on "Declarative Smalltalk"[1]
...
...
> Disclaimer: I worked with Allen Wirfs-Brock in the nineties (engineer on the Team/V team) while he was developing his ideas for Declarative Smalltalk, so I am somewhat biased in my thinking:)
>
> My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door  for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
>
> Dale
>
> [1] http://www.smalltalksystems.com/publications/_awss97/SSDCL1.HTM

For this to work, we need Spoon and tools designed around Spoon, I think.

One thing that I have heard is that *no one* has really stepped up and
given feedback to Craig. I was one of the most "expert" people around
simply because I had downloaded his latest version.

Hint hint, folks.

L.


L.
On 1/28/12 4:20 PM, Dale Henrichs wrote:
> [...]
> My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door  for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)
>
> Dale
>
>
>

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

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

Lawson English-2 wrote

One thing that I have heard is that *no one* has really stepped up and
given feedback to Craig.

This is not totally accurate. After sitting with Craig at the last ESUG, I immediately ran into problems trying to simulate the VM and was unable to get answers on the mailing list (http://forum.world.st/Simulating-the-VM-td3774139.html).

Janko,

Am 28.01.2012 um 23:37 schrieb Janko Mivšek <[hidden email]>:
>> I'm not so sure the people at those Smalltalk firms building software for banks et al. have no project management. Boasting? ;-)
>
> As I said in first post, there are few exceptions. But they all have
> their dev. process developed internally,

have they now? Are you sure? XP, Scrum, Kanban ... all not internal but used in Smalltalk projects.

> while there are no common
> agreed and used development processes in Smalltalk as there are in
> enterprise Java development.

What do you mean? Are there implications that if you use Java, you habe to use a certain process?

> Even more funny is that many (like
> Agile/Extreme programming) actually comes from that Smalltalk project
> "exceptions"...

but those are "standardised" now, and in wide use - by both Smalltalk and Java developers.

Honestly, I think this whole discrimination is a bit artificial.

Best,

Michael

Hi Igor,

Am 29.01.2012 um 00:11 schrieb Igor Stasenko <[hidden email]>:
> now try to merge it with your "magical" SCM which can resolve such
> kind of conflicts.

no tool can ever replace communication. Regardless of programming language used.

Best,

Michael

+1
Metacello is the way to go!
Dale I will update the chapter as soon as you decide the new API :)
I'm working on a nice process document for our little community. Stay tuned :)

Stef


> My opinion that being able to build images from scratch (easily and reproducibly) is a "requirement" to get in the door  for mainstream projects... giving mainstream developers the opportunity to work in a image-based environment will set them free:)

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

Yes, but that also takes a mythical being: a manager with the cojones to say "blame me, that was my decision."




________________________________________
From: [hidden email] [[hidden email]] on behalf of Michael Haupt [[hidden email]]
Sent: Sunday, January 29, 2012 1:07 AM
To: [hidden email]
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

Hi Igor,

Am 29.01.2012 um 00:11 schrieb Igor Stasenko <[hidden email]>:
> now try to merge it with your "magical" SCM which can resolve such
> kind of conflicts.

no tool can ever replace communication. Regardless of programming language used.

Best,

Michael

Maybe not for smalltalk but for python there is a number of surveys that prove that by replacing java with python you can scale down developing time by 2-3x times. By "prove" I mean projects that have actually done that.  Not quite a 10x but I think its impressive non the less and I think the numbers wont be very dissimilar for smalltalk

---

From: Michael Haupt <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Saturday, 28 January 2012, 23:29
Subject: Re: [Pharo-project] Smalltalk for small projects only?

Janko,

Am 28.01.2012 um 21:08 schrieb Janko Mivšek <[hidden email]>:
>> I think this is a post that clearly illustrates the big problem with
>> smalltalk. The very fact that is compared with Java and Java survives.
>
> Yes, that 4-5 peole can do what 50 Java people are needed is both a
> blessing and a curse :)

I wanted to ask this earlier: is there actual evidence for this, or is it just boasting?

> Blessing because of productivity, curse because
> we are not able to scale beyond one highly connected development group.
> We don't have project management practices and tools, while Java guys
> have because they need them from the start.

I'm not so sure the people at those Smalltalk firms building software for banks et al. have no project management. Boasting? ;-)

Best,

Michael