Discussion:
[Pharo-project] Smalltalk for small projects only?
(too old to reply)
Janko Mivšek
2012-01-28 15:46:32 UTC
Permalink
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
dimitris chloupis
2012-01-28 16:50:53 UTC
Permalink
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.

You know I dont find it mysterious at all that smalltalk is unpopular as it is. If I go to the python website I know in 4 second why I should use python, if I go to a Java site in 10 seconds I know what Java is good for, if I go to a C/c++ again in seconds it becomes clear what is the goal, even Assembly websites explain in a few lines what the language is all about.

With Squeak and Pharo on the other hand it took me literally hours to figure out what they are good for and by the time I did I was amazed how underhyped smalltalk is. For me at least is the most underhyped piece of software I have ever used.

The issue with image here its easy to totally miss the whole point. An image is loading lighting fast , a java application is not, its also great way to organise object orientated code because it allows you to quickly navigate through it, loading files , is expensive and frankly quite archaic. The idea behind filesystem was created on the basic that computer could only load just a few kbs or even less because of limited memory.

In the age we live , filesystems are unnecessary anyway. I am not saying that hardware storage is , just file systems, and I think smalltalk moves towards that direction. You dont really need files and extensions to separate data and code, OO can do the job just fine in that area.

I cant comment on the specifics of the image I am new to smalltalk and still exploring the basics, but let me say that I would love to take the idea of image abit further maybe following the brilliant architecture of our brains which stores information not in packages but via association, I think this kind of workflow is alot closer to what OO tries to be.

For me the image play a pivot role inside the OO of smalltalk, which unlike Java does not stop at class definition. Besides an oversize clumsy library , smalltalk has very little to be envious of Java.

Regarding huge project I will boldly say that inside a system of gazillion files a single file can easily lost its identity, OO can plays a huge role here, it can create that association I was talking about earlier and it can make sure that the user and coder has immediate access to information that he want to focus on at that particular moment but also has a structure that is obvious and simple to navigate.

About the limitation of an image , i think that is a matter of implementation , obviously smalltalk has not been used as extensively in large projects as Java. But then what stops us from implementing an image that can brake any barrier, even do direct streaming from disk when the memory is not enough or when we dont want to occupy its entirety ?


________________________________
From: Janko Miv?ek <janko.mivsek at eranova.si>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>; Squeak <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu>
Sent: Saturday, 28 January 2012, 17:46
Subject: [Pharo-project] Smalltalk for small projects only?

Hi guys,

Ralph Johnson in his InfoQ interview made an interesting observation:

2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
...? "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120128/faa68dd6/attachment.html>
Schwab,Wilhelm K
2012-01-28 17:12:59 UTC
Permalink
You say "underhyped" as though this is bad - *hype* is BAAAAADD. Junk needs hype to survive.

It took me a while to learn that "creating an application" in ST is "hard" - it's because it's not well supported because the initiated don't waste their time with it _until_ it comes time to deploy, and even then, it's not NEEDED.

We need to teach, not pander, IMHO. Show people that there is a better way and what it is. A glossy ad compliant C# "application" that does what my pharo image can do would be a MONSTER. No one would build such a thing because they probably could not do so.

Keep adding good stuff.

Bill


________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of dimitris chloupis [thekilon at yahoo.co.uk]
Sent: Saturday, January 28, 2012 11:50 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Smalltalk for small projects only?

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.

You know I dont find it mysterious at all that smalltalk is unpopular as it is. If I go to the python website I know in 4 second why I should use python, if I go to a Java site in 10 seconds I know what Java is good for, if I go to a C/c++ again in seconds it becomes clear what is the goal, even Assembly websites explain in a few lines what the language is all about.

With Squeak and Pharo on the other hand it took me literally hours to figure out what they are good for and by the time I did I was amazed how underhyped smalltalk is. For me at least is the most underhyped piece of software I have ever used.

The issue with image here its easy to totally miss the whole point. An image is loading lighting fast , a java application is not, its also great way to organise object orientated code because it allows you to quickly navigate through it, loading files , is expensive and frankly quite archaic. The idea behind filesystem was created on the basic that computer could only load just a few kbs or even less because of limited memory.

In the age we live , filesystems are unnecessary anyway. I am not saying that hardware storage is , just file systems, and I think smalltalk moves towards that direction. You dont really need files and extensions to separate data and code, OO can do the job just fine in that area.

I cant comment on the specifics of the image I am new to smalltalk and still exploring the basics, but let me say that I would love to take the idea of image abit further maybe following the brilliant architecture of our brains which stores information not in packages but via association, I think this kind of workflow is alot closer to what OO tries to be.

For me the image play a pivot role inside the OO of smalltalk, which unlike Java does not stop at class definition. Besides an oversize clumsy library , smalltalk has very little to be envious of Java.

Regarding huge project I will boldly say that inside a system of gazillion files a single file can easily lost its identity, OO can plays a huge role here, it can create that association I was talking about earlier and it can make sure that the user and coder has immediate access to information that he want to focus on at that particular moment but also has a structure that is obvious and simple to navigate.

About the limitation of an image , i think that is a matter of implementation , obviously smalltalk has not been used as extensively in large projects as Java. But then what stops us from implementing an image that can brake any barrier, even do direct streaming from disk when the memory is not enough or when we dont want to occupy its entirety ?
________________________________
From: Janko Miv?ek <janko.mivsek at eranova.si>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>; Squeak <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu>
Sent: Saturday, 28 January 2012, 17:46
Subject: [Pharo-project] Smalltalk for small projects only?

Hi guys,

Ralph Johnson in his InfoQ interview made an interesting observation:

2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
... "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120128/be0ff59d/attachment.html>
Lawson English
2012-01-28 19:16:37 UTC
Permalink
On 1/28/12 10:12 AM, Schwab,Wilhelm K wrote:
> You say "underhyped" as though this is bad - *hype* is BAAAAADD. Junk
> needs hype to survive.
>
> It took me a while to learn that "creating an application" in ST is
> "hard" - it's because it's not well supported because the initiated
> don't waste their time with it _until_ it comes time to deploy, and
> even then, it's not NEEDED.
>
> We need to teach, not pander, IMHO. Show people that there is a
> better way and what it is. A glossy ad compliant C# "application"
> that does what my pharo image can do would be a MONSTER. No one would
> build such a thing because they probably could not do so.
>
> Keep adding good stuff.

In fact, there IS a better way. Igor's NativeBoost and NBOpenGL are a
game-changer.

My video tutorials aren't terribly well done compared to many others out
there, but I do hype them a bit. The ones that get the most attention,
by far, are those that show how to integrate OpenGL and Smalltalk.

You want Pharo/Squeak/Smalltalk to become better used? Ensure that the
most interesting (to the most programmers) aspects become well-known,
and at least as importantly, well-supported.


Lawson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120128/3b5e7432/attachment.html>
Schwab,Wilhelm K
2012-01-28 23:10:42 UTC
Permalink
Thanks for your efforts. But hype the correct parts used properly.

NB is an FFI alternative; it has zip to do with "creating applications" which is code wordism for starting over on every little job you do, because whoever works that way hasn't yet caught on to adding a facade/package to hold the incremental changes that make this small job different from that small job. All the other stuff can be "included" with NO effort by simply leaving it there.

It takes a while to explain this to a smart person because they have a lot unlearn before they can make real progress.


________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Lawson English [lenglish5 at cox.net]
Sent: Saturday, January 28, 2012 2:16 PM
To: pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Smalltalk for small projects only?

On 1/28/12 10:12 AM, Schwab,Wilhelm K wrote:
You say "underhyped" as though this is bad - *hype* is BAAAAADD. Junk needs hype to survive.

It took me a while to learn that "creating an application" in ST is "hard" - it's because it's not well supported because the initiated don't waste their time with it _until_ it comes time to deploy, and even then, it's not NEEDED.

We need to teach, not pander, IMHO. Show people that there is a better way and what it is. A glossy ad compliant C# "application" that does what my pharo image can do would be a MONSTER. No one would build such a thing because they probably could not do so.

Keep adding good stuff.

In fact, there IS a better way. Igor's NativeBoost and NBOpenGL are a game-changer.

My video tutorials aren't terribly well done compared to many others out there, but I do hype them a bit. The ones that get the most attention, by far, are those that show how to integrate OpenGL and Smalltalk.

You want Pharo/Squeak/Smalltalk to become better used? Ensure that the most interesting (to the most programmers) aspects become well-known, and at least as importantly, well-supported.


Lawson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120128/e9d6ea30/attachment.html>
Janko Mivšek
2012-01-28 20:08:56 UTC
Permalink
S, dimitris chloupis pi?e:

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

> You know I dont find it mysterious at all that smalltalk is unpopular as
> it is. If I go to the python website I know in 4 second why I should use
> python, if I go to a Java site in 10 seconds I know what Java is good
> for, if I go to a C/c++ again in seconds it becomes clear what is the
> goal, even Assembly websites explain in a few lines what the language is
> all about.

> With Squeak and Pharo on the other hand it took me literally hours to
> figure out what they are good for and by the time I did I was amazed how
> underhyped smalltalk is. For me at least is the most underhyped piece of
> software I have ever used.

This is a valuable point to consider in the future.


> The issue with image here its easy to totally miss the whole point. An
> image is loading lighting fast , a java application is not, its also
> great way to organise object orientated code because it allows you to
> quickly navigate through it, loading files , is expensive and frankly
> quite archaic. The idea behind filesystem was created on the basic that
> computer could only load just a few kbs or even less because of limited
> memory.
>
> In the age we live , filesystems are unnecessary anyway. I am not saying
> that hardware storage is , just file systems, and I think smalltalk
> moves towards that direction. You dont really need files and extensions
> to separate data and code, OO can do the job just fine in that area.
>
> I cant comment on the specifics of the image I am new to smalltalk and
> still exploring the basics, but let me say that I would love to take the
> idea of image abit further maybe following the brilliant architecture of
> our brains which stores information not in packages but via association,
> I think this kind of workflow is alot closer to what OO tries to be.
>
> For me the image play a pivot role inside the OO of smalltalk, which
> unlike Java does not stop at class definition. Besides an oversize
> clumsy library , smalltalk has very little to be envious of Java.
>
> Regarding huge project I will boldly say that inside a system of
> gazillion files a single file can easily lost its identity, OO can plays
> a huge role here, it can create that association I was talking about
> earlier and it can make sure that the user and coder has immediate
> access to information that he want to focus on at that particular moment
> but also has a structure that is obvious and simple to navigate.
>
> About the limitation of an image , i think that is a matter of
> implementation , obviously smalltalk has not been used as extensively in
> large projects as Java. But then what stops us from implementing an
> image that can brake any barrier, even do direct streaming from disk
> when the memory is not enough or when we dont want to occupy its entirety ?
> ------------------------------------------------------------------------
> *From:* Janko Miv?ek <janko.mivsek at eranova.si>
> *To:* "Pharo-project at lists.gforge.inria.fr"
> <Pharo-project at lists.gforge.inria.fr>; Squeak
> <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu>
> *Sent:* Saturday, 28 January 2012, 17:46
> *Subject:* [Pharo-project] Smalltalk for small projects only?
>
> Hi guys,
>
> Ralph Johnson in his InfoQ interview made an interesting observation:
>
> 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> build something with 4-5 people what 50 people can build in Java, but if
> you take 200 people in Java ... it is really designed for small systems
> ... "
>
> Are we because of the image really destined for relatively small
> projects and small systems (of Java 50 people project size)?
>
> Are we really not able to scale to bigger projects/systems because of that?
>
> Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
>
> [1] http://www.infoq.com/interviews/johnson-armstrong-oop
>
> Best regards
> Janko
>
>
> --
> Janko Miv?ek
> Aida/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
Michael Haupt
2012-01-28 21:29:39 UTC
Permalink
Janko,

Am 28.01.2012 um 21:08 schrieb Janko Miv?ek <janko.mivsek at eranova.si>:
>> 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
Janko Mivšek
2012-01-28 22:37:11 UTC
Permalink
Hi Michael,

S, Michael Haupt pi?e:

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

I think we need to ask Ralph to clarify that. But IMHO his main point is
scaling from 50 to 200 ...

>> 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? ;-)

As I said in first post, there are few exceptions. But they all have
their dev. process developed internally, while there are no common
agreed and used development processes in Smalltalk as there are in
enterprise Java development. Even more funny is that many (like
Agile/Extreme programming) actually comes from that Smalltalk project
"exceptions"...

Best regards
Janko
Michael Haupt
2012-01-29 06:03:46 UTC
Permalink
Janko,

Am 28.01.2012 um 23:37 schrieb Janko Miv?ek <janko.mivsek at eranova.si>:
>> 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
dimitris chloupis
2012-01-29 07:51:50 UTC
Permalink
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 <mhaupt at gmail.com>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
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 <janko.mivsek at eranova.si>:
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/030a7bee/attachment.html>
Michael Haupt
2012-01-29 12:44:48 UTC
Permalink
Dimitris,

this is very interesting; I've always wanted to read that kind of study. Do you have a pointer?

Thanks,

Michael

Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon at yahoo.co.uk>:

> 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 <mhaupt at gmail.com>
> To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
> 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 <janko.mivsek at eranova.si>:
> >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/6129ee7c/attachment.html>
Schwab,Wilhelm K
2012-01-29 14:12:10 UTC
Permalink
Reference, please :) I fully believe it.

Bill





________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt at gmail.com]
Sent: Sunday, January 29, 2012 7:44 AM
To: Pharo-project at lists.gforge.inria.fr; dimitris chloupis
Subject: Re: [Pharo-project] Smalltalk for small projects only?

Dimitris,

this is very interesting; I've always wanted to read that kind of study. Do you have a pointer?

Thanks,

Michael

Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon at yahoo.co.uk<mailto:thekilon at yahoo.co.uk>>:

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 <mhaupt at gmail.com<mailto:mhaupt at gmail.com>>
To: "Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>" <Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>>
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 <janko.mivsek at eranova.si<mailto:janko.mivsek at eranova.si>>:
>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/bf3c1293/attachment.html>
dimitris chloupis
2012-01-29 16:58:00 UTC
Permalink
sorry could not find it , nor I remember the name, I have seen one or two . But in any case I think the comparison is obvious. If you visit the language game , the code?required?by python is usually 2x 3x times less for the same thing.

http://www.google.gr/url?sa=t&rct=j&q=language%20game&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fshootout.alioth.debian.org%2F&ei=U3olT9_qM4mg0QXFm7TOCg&usg=AFQjCNGFEQY5YsieJO4vPgY-7-9VgoiqHw&sig2=oHKbzwA35yA4puN27g1IIA



________________________________
From: "Schwab,Wilhelm K" <bschwab at anest.ufl.edu>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
Sent: Sunday, 29 January 2012, 16:12
Subject: Re: [Pharo-project] Smalltalk for small projects only?



Reference, please :)? I fully believe it.

Bill







________________________________

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt at gmail.com]
Sent: Sunday, January 29, 2012 7:44 AM
To: Pharo-project at lists.gforge.inria.fr; dimitris chloupis
Subject: Re: [Pharo-project] Smalltalk for small projects only?


Dimitris,

this is very interesting; I've always wanted to read that kind of study. Do you have a pointer?

Thanks,

Michael

Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon at yahoo.co.uk>:


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 <mhaupt at gmail.com>
>To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
>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 <janko.mivsek at eranova.si>:
>>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/3ec92a45/attachment.html>
dimitris chloupis
2012-01-29 17:06:46 UTC
Permalink
ok I think I found something you may like?

this

http://codemonkeyism.com/comparing-java-and-python-is-java-10x-more-verbose-than-python-loc-a-modest-empiric-approach/



________________________________
From: dimitris chloupis <thekilon at yahoo.co.uk>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
Sent: Sunday, 29 January 2012, 18:58
Subject: Re: [Pharo-project] Smalltalk for small projects only?


sorry could not find it , nor I remember the name, I have seen one or two . But in any case I think the comparison is obvious. If you visit the language game , the code?required?by python is usually 2x 3x times less for the same thing.

http://www.google.gr/url?sa=t&rct=j&q=language%20game&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fshootout.alioth.debian.org%2F&ei=U3olT9_qM4mg0QXFm7TOCg&usg=AFQjCNGFEQY5YsieJO4vPgY-7-9VgoiqHw&sig2=oHKbzwA35yA4puN27g1IIA



________________________________
From: "Schwab,Wilhelm K" <bschwab at anest.ufl.edu>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
Sent: Sunday, 29 January 2012, 16:12
Subject: Re: [Pharo-project] Smalltalk for small projects only?



Reference, please :)? I fully believe it.

Bill







________________________________

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt at gmail.com]
Sent: Sunday, January 29, 2012 7:44 AM
To: Pharo-project at lists.gforge.inria.fr; dimitris chloupis
Subject: Re: [Pharo-project] Smalltalk for small projects only?


Dimitris,

this is very interesting; I've always wanted to read that kind of study. Do you have a pointer?

Thanks,

Michael

Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon at yahoo.co.uk>:


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 <mhaupt at gmail.com>
>To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
>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 <janko.mivsek at eranova.si>:
>>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/1d087c70/attachment.html>
Michael Haupt
2012-01-29 19:46:45 UTC
Permalink
Hi Dimitris,

the Greek Google link does not work for me for some reason; maybe the shootout server is down ... in any case I strongly doubt that the shootout benchmarks (if that's where the link was supposed to point to) say anything about productivity.

The other link is not what I was expecting, sorry. For one, the blog entry does not really say anything about productivity. It is all about LOC, which is a poor metric for productivity. The blog post certainly does not "prove that by replacing java with python you can scale down developing time by 2-3x times", to quote you. Having to write, say, 50 % of the LOC in no way means you need half the time.

Staying tuned for more,

Michael

Am 29.01.2012 um 18:06 schrieb dimitris chloupis <thekilon at yahoo.co.uk>:

> ok I think I found something you may like
>
> this
>
> http://codemonkeyism.com/comparing-java-and-python-is-java-10x-more-verbose-than-python-loc-a-modest-empiric-approach/
>
> From: dimitris chloupis <thekilon at yahoo.co.uk>
> To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
> Sent: Sunday, 29 January 2012, 18:58
> Subject: Re: [Pharo-project] Smalltalk for small projects only?
>
> sorry could not find it , nor I remember the name, I have seen one or two . But in any case I think the comparison is obvious. If you visit the language game , the code required by python is usually 2x 3x times less for the same thing.
>
> http://www.google.gr/url?sa=t&rct=j&q=language%20game&source=web&cd=1&ved=0CCwQFjAA&url=http%3A%2F%2Fshootout.alioth.debian.org%2F&ei=U3olT9_qM4mg0QXFm7TOCg&usg=AFQjCNGFEQY5YsieJO4vPgY-7-9VgoiqHw&sig2=oHKbzwA35yA4puN27g1IIA
>
> From: "Schwab,Wilhelm K" <bschwab at anest.ufl.edu>
> To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
> Sent: Sunday, 29 January 2012, 16:12
> Subject: Re: [Pharo-project] Smalltalk for small projects only?
>
> Reference, please :) I fully believe it.
>
> Bill
>
>
>
>
>
> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt at gmail.com]
> Sent: Sunday, January 29, 2012 7:44 AM
> To: Pharo-project at lists.gforge.inria.fr; dimitris chloupis
> Subject: Re: [Pharo-project] Smalltalk for small projects only?
>
> Dimitris,
>
> this is very interesting; I've always wanted to read that kind of study. Do you have a pointer?
>
> Thanks,
>
> Michael
>
> Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon at yahoo.co.uk>:
>
>> 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 <mhaupt at gmail.com>
>> To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>
>> 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 <janko.mivsek at eranova.si>:
>> >> 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
>>
>>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/3a6bfbce/attachment.html>
dimitris chloupis
2012-01-29 07:46:22 UTC
Permalink
Very good point . The tools and the libraries sometimes can play more important role than the language itself. However Java seems to constantly loosing developers because if something is a mess for small project for big projects becomes a big mess , just take a look how many gazillion scripting languages Java has , way more than C/C++. ?

I think Java is not that ideal for large project as people think. I will go as far as saying that if it was not such a well marketed product would be an abandoned product by now and not a dominating platform. Companies may like , but coders certainly do not . Companies are attracted by good marketing, but coders are not.?

Coders are attracted , pro coders that is, from what can bring food to their table and pay their bills. And in that respect Java is phenomenal. If I was a big company however Java would be the last thing I would use for big project. As a matter of fact python has gained quite a momentum with huge projects and it is afterall a smalltalk child. Why not smalltalk ?


________________________________
From: Janko Miv?ek <janko.mivsek at eranova.si>
To: Pharo-project at lists.gforge.inria.fr; dimitris chloupis <thekilon at yahoo.co.uk>
Sent: Saturday, 28 January 2012, 22:08
Subject: Re: [Pharo-project] Smalltalk for small projects only?

S, dimitris chloupis pi?e:

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

> You know I dont find it mysterious at all that smalltalk is unpopular as
> it is. If I go to the python website I know in 4 second why I should use
> python, if I go to a Java site in 10 seconds I know what Java is good
> for, if I go to a C/c++ again in seconds it becomes clear what is the
> goal, even Assembly websites explain in a few lines what the language is
> all about.

> With Squeak and Pharo on the other hand it took me literally hours to
> figure out what they are good for and by the time I did I was amazed how
> underhyped smalltalk is. For me at least is the most underhyped piece of
> software I have ever used.

This is a valuable point to consider in the future.


> The issue with image here its easy to totally miss the whole point. An
> image is loading lighting fast , a java application is not, its also
> great way to organise object orientated code because it allows you to
> quickly navigate through it, loading files , is expensive and frankly
> quite archaic. The idea behind filesystem was created on the basic that
> computer could only load just a few kbs or even less because of limited
> memory.
>
> In the age we live , filesystems are unnecessary anyway. I am not saying
> that hardware storage? is , just file systems,? and I think smalltalk
> moves towards that direction. You dont really need files and extensions
> to separate data and? code,? OO? can do the job just fine in that area.
>
> I cant comment on the specifics of the image I am new to smalltalk and
> still exploring the basics, but let me say that I would love to take the
> idea of image abit further maybe following the brilliant architecture of
> our brains which stores information not in packages but via association,
> I think this kind of workflow is alot closer to what OO tries to be.
>
> For me the image play a pivot role inside the OO of smalltalk, which
> unlike Java does not stop at class definition. Besides an oversize
> clumsy library , smalltalk has very little to be envious of Java.
>
> Regarding huge project I will boldly say that inside a system of
> gazillion files a single file can easily lost its identity, OO can plays
> a huge role here, it can create that association I was talking about
> earlier and it can make sure that the user and coder has immediate
> access to information that he want to focus on at that particular moment
> but also has a structure that is obvious and simple to navigate.
>
> About the limitation of an image , i think that is a matter of
> implementation , obviously smalltalk has not been used as extensively in
> large projects as Java. But then what stops us from implementing an
> image that can brake any barrier, even do direct streaming from disk
> when the memory is not enough or when we dont want to occupy its entirety ?
> ------------------------------------------------------------------------
> *From:* Janko Miv?ek <janko.mivsek at eranova.si>
> *To:* "Pharo-project at lists.gforge.inria.fr"
> <Pharo-project at lists.gforge.inria.fr>; Squeak
> <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu>
> *Sent:* Saturday, 28 January 2012, 17:46
> *Subject:* [Pharo-project] Smalltalk for small projects only?
>
> Hi guys,
>
> Ralph Johnson in his InfoQ interview made an interesting observation:
>
> 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> build something with 4-5 people what 50 people can build in Java, but if
> you take 200 people in Java ... it is really designed for small systems
> ...? "
>
> Are we because of the image really destined for relatively small
> projects and small systems (of Java 50 people project size)?
>
> Are we really not able to scale to bigger projects/systems because of that?
>
> Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
>
> [1] http://www.infoq.com/interviews/johnson-armstrong-oop
>
> Best regards
> Janko
>
>
> --
> Janko Miv?ek
> Aida/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/377186ef/attachment.html>
Guido Stepken
2012-01-29 18:38:29 UTC
Permalink
Smalltalk rather has the structure of a human brain, neurons firing around,
reacting to all sorts of events and data. Even for a psychologist it is
impossible to say, what neuron did a wrong job, when the patient suffers
from mental illness. That problem tries to address the Pharo team by giving
the ball of ill neurons a clear hierarcy and new structure, so that
responsbilities can be clearly addressed, parallel to the structure within
the programmers and enterprise hierarchy.

For too long time the crowd of "Alan Kay hackers" have been messing around
in the code, fixing things here and there, destroying lots of things at the
same time.

Squeak is the perfect proof of Kay's incompetence as software project
manager! (I think, he never intended to be one! :-) )

Thats, why Java was such successfull: Clear hierarchy in the code
structure, clear assignable responsibilities, clear assignable costs.

In Smalltalk - impossible. That's why it died out. Too many complications
and administrative overhead besides the programming itself, not mentioned
the costs for lawyers, expert witnesses and court, when trying to answer
the question of guiltyness, case a customer had real damage by software
bugs.
Programmers reality is not the reality outside in the real world!
I'm really very interested watching the great Squeak/Pharo "cleanup" and
how these problems are addressed, if there is a solution existing!?

And finally: LOC, effectiveness of a programming language, speed, has
proofed to be a minor problem in reality!

regards, Guido Stepken
Am 29.01.2012 08:46 schrieb "dimitris chloupis" <thekilon at yahoo.co.uk>:

> Very good point . The tools and the libraries sometimes can play more
> important role than the language itself. However Java seems to constantly
> loosing developers because if something is a mess for small project for big
> projects becomes a big mess , just take a look how many gazillion scripting
> languages Java has , way more than C/C++.
>
> I think Java is not that ideal for large project as people think. I will
> go as far as saying that if it was not such a well marketed product would
> be an abandoned product by now and not a dominating platform. Companies may
> like , but coders certainly do not . Companies are attracted by good
> marketing, but coders are not.
>
> Coders are attracted , pro coders that is, from what can bring food to
> their table and pay their bills. And in that respect Java is phenomenal. If
> I was a big company however Java would be the last thing I would use for
> big project. As a matter of fact python has gained quite a momentum with
> huge projects and it is afterall a smalltalk child. Why not smalltalk ?
>
> ------------------------------
> *From:* Janko Miv?ek <janko.mivsek at eranova.si>
> *To:* Pharo-project at lists.gforge.inria.fr; dimitris chloupis <
> thekilon at yahoo.co.uk>
> *Sent:* Saturday, 28 January 2012, 22:08
> *Subject:* Re: [Pharo-project] Smalltalk for small projects only?
>
> S, dimitris chloupis pi?e:
>
> > 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 :) 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.
>
> > You know I dont find it mysterious at all that smalltalk is unpopular as
> > it is. If I go to the python website I know in 4 second why I should use
> > python, if I go to a Java site in 10 seconds I know what Java is good
> > for, if I go to a C/c++ again in seconds it becomes clear what is the
> > goal, even Assembly websites explain in a few lines what the language is
> > all about.
>
> > With Squeak and Pharo on the other hand it took me literally hours to
> > figure out what they are good for and by the time I did I was amazed how
> > underhyped smalltalk is. For me at least is the most underhyped piece of
> > software I have ever used.
>
> This is a valuable point to consider in the future.
>
>
> > The issue with image here its easy to totally miss the whole point. An
> > image is loading lighting fast , a java application is not, its also
> > great way to organise object orientated code because it allows you to
> > quickly navigate through it, loading files , is expensive and frankly
> > quite archaic. The idea behind filesystem was created on the basic that
> > computer could only load just a few kbs or even less because of limited
> > memory.
> >
> > In the age we live , filesystems are unnecessary anyway. I am not saying
> > that hardware storage is , just file systems, and I think smalltalk
> > moves towards that direction. You dont really need files and extensions
> > to separate data and code, OO can do the job just fine in that area.
> >
> > I cant comment on the specifics of the image I am new to smalltalk and
> > still exploring the basics, but let me say that I would love to take the
> > idea of image abit further maybe following the brilliant architecture of
> > our brains which stores information not in packages but via association,
> > I think this kind of workflow is alot closer to what OO tries to be.
> >
> > For me the image play a pivot role inside the OO of smalltalk, which
> > unlike Java does not stop at class definition. Besides an oversize
> > clumsy library , smalltalk has very little to be envious of Java.
> >
> > Regarding huge project I will boldly say that inside a system of
> > gazillion files a single file can easily lost its identity, OO can plays
> > a huge role here, it can create that association I was talking about
> > earlier and it can make sure that the user and coder has immediate
> > access to information that he want to focus on at that particular moment
> > but also has a structure that is obvious and simple to navigate.
> >
> > About the limitation of an image , i think that is a matter of
> > implementation , obviously smalltalk has not been used as extensively in
> > large projects as Java. But then what stops us from implementing an
> > image that can brake any barrier, even do direct streaming from disk
> > when the memory is not enough or when we dont want to occupy its
> entirety ?
> > ------------------------------------------------------------------------
> > *From:* Janko Miv?ek <janko.mivsek at eranova.si>
> > *To:* "Pharo-project at lists.gforge.inria.fr"
> > <Pharo-project at lists.gforge.inria.fr>; Squeak
> > <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu>
> > *Sent:* Saturday, 28 January 2012, 17:46
> > *Subject:* [Pharo-project] Smalltalk for small projects only?
> >
> > Hi guys,
> >
> > Ralph Johnson in his InfoQ interview made an interesting observation:
> >
> > 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> > build something with 4-5 people what 50 people can build in Java, but if
> > you take 200 people in Java ... it is really designed for small systems
> > ... "
> >
> > Are we because of the image really destined for relatively small
> > projects and small systems (of Java 50 people project size)?
> >
> > Are we really not able to scale to bigger projects/systems because of
> that?
> >
> > Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
> >
> > [1] http://www.infoq.com/interviews/johnson-armstrong-oop
> >
> > Best regards
> > Janko
> >
> >
> > --
> > Janko Miv?ek
> > Aida/Web
> > Smalltalk Web Application Server
> > http://www.aidaweb.si
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/caf771b7/attachment.html>
Hilaire Fernandes
2012-01-28 21:06:20 UTC
Permalink
May be it is time to forget about the image, I mean the name of the
image and change for something else, more in the proximal learning zone
of programmer. It is not an image we have, it is a data base of object,
and we are programming on this object data base.

Hilaire


Le 28/01/2012 17:50, dimitris chloupis a ?crit :
> The issue with image here its easy to totally miss the whole point. An
> image is loading lighting fast , a java application is not, its also
> great way to organise object orientated code because it allows you to
> quickly navigate through it, loading files , is expensive and frankly
> quite archaic. The idea behind filesystem was created on the basic that
> computer could only load just a few kbs or even less because of limited
> memory.


--
Dr. Geo -- http://www.drgeo.eu
Igor Stasenko
2012-01-28 21:27:59 UTC
Permalink
On 28 January 2012 22:06, Hilaire Fernandes <hilaire.fernandes at edu.ge.ch> wrote:
> May be it is time to forget about the image, I mean the name of the
> image and change for something else, more in the proximal learning zone
> of programmer. It is not an image we have, it is a data base of object,
> and we are programming on this object data base.
>

Hmm.. when i started with smalltalk, it was pretty obvious to me from
the very starting
that an image is a bunch of dead bytes, and there's not much you can
do with it at that level.

Apparently people should not use "image" as as interchange product
between project teams.

As for scale.. monticello scales well.
And if you scale to something huge (200 people) , your main problem
will be to organize a process,
and establish a rules.
People were doing huge projects without SCMs in the past.. so it think
organizing large projects is more depending on social organization
rather than on technical limitations of tools they will use.

> Hilaire
>
>
> Le 28/01/2012 17:50, dimitris chloupis a ?crit :
>> The issue with image here its easy to totally miss the whole point. An
>> image is loading lighting fast , a java application is not, its also
>> great way to organise object orientated code because it allows you to
>> quickly navigate through it, loading files , is expensive and frankly
>> quite archaic. The idea behind filesystem was created on the basic that
>> computer could only load just a few kbs or even less because of limited
>> memory.
>
>
> --
> Dr. Geo -- http://www.drgeo.eu
>
>



--
Best regards,
Igor Stasenko.
Philippe Marschall
2012-01-29 14:30:45 UTC
Permalink
On 28.01.2012 22:27, Igor Stasenko wrote:
> On 28 January 2012 22:06, Hilaire Fernandes<hilaire.fernandes at edu.ge.ch> wrote:
>> May be it is time to forget about the image, I mean the name of the
>> image and change for something else, more in the proximal learning zone
>> of programmer. It is not an image we have, it is a data base of object,
>> and we are programming on this object data base.
>>
>
> Hmm.. when i started with smalltalk, it was pretty obvious to me from
> the very starting
> that an image is a bunch of dead bytes, and there's not much you can
> do with it at that level.
>
> Apparently people should not use "image" as as interchange product
> between project teams.
>
> As for scale.. monticello scales well.

No, it does not.

Cheers
Philippe
Sven Van Caekenberghe
2012-01-29 16:02:51 UTC
Permalink
On 29 Jan 2012, at 15:30, Philippe Marschall wrote:

>> As for scale.. monticello scales well.
>
> No, it does not.

Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.

Yes, git has a bit more tools, is a bit more modern, has a lot more usage and polish, but fundamentally I see little difference. The merge will be hard in both cases. All (big) teams struggle here.

BTW: try understanding git internals, let alone try contributing to it, with Monticello you can: it is all Smalltalk.

Again, I am not saying that MC has no flaws, or that we can't or should learn from others and improve, far from it, but the grass in not greener on the other side.

Sven

PS: one of the things that we should take from git, as many others have said on this list, is selective commits.
Philippe Marschall
2012-01-29 17:48:59 UTC
Permalink
On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
>
> On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>
>>> As for scale.. monticello scales well.
>>
>> No, it does not.
>
> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.

The scalability limits of Monticello are well understood. PackageInfo
doesn't scale, at all. You put too many classes in a package, and
snapshotting gets really slow. Don't believe me? Make a change in
Morphic which has only 200 classes and save it.

And it's not like loading is any faster. Seaside takes 10 minutes to
build from locally cached [1] packages, only 12 seconds go to running
tests [2]. This makes C++ compilation times seem fast by comparison.

[1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
[2]
http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/

Cheers
Philippe
Sven Van Caekenberghe
2012-01-29 18:16:51 UTC
Permalink
On 29 Jan 2012, at 18:48, Philippe Marschall wrote:

> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
>
> And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison.
>
> [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
> [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/

I thought the thread and your remark were about the fact that it was functionally not possible to scale to larger teams. That is where is see no real difference.

If you refer to scaleability purely on technical terms, speedwise, then yes we have room to improve ;-)
I worked with Pharo slices, I have built images containing Seaside.
Building bigger well known open source software from scratch usually takes quite some time too.

We, as a community have to improve our tools, it will be a lot of work but work _is_ being done right now, think of the compiler, loader, networking, file access, package management.

This very small hack already makes a difference: http://code.google.com/p/pharo/issues/detail?id=5222 and we need many more.

Sven
Stéphane Ducasse
2012-01-29 18:41:20 UTC
Permalink
Yes took me 10 hours to install GTK and it crashed on me?
So ? I do not see this discussion going anywhere.


On Jan 29, 2012, at 7:16 PM, Sven Van Caekenberghe wrote:

>
> On 29 Jan 2012, at 18:48, Philippe Marschall wrote:
>
>> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
>>
>> And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison.
>>
>> [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
>> [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/
>
> I thought the thread and your remark were about the fact that it was functionally not possible to scale to larger teams. That is where is see no real difference.
>
> If you refer to scaleability purely on technical terms, speedwise, then yes we have room to improve ;-)
> I worked with Pharo slices, I have built images containing Seaside.
> Building bigger well known open source software from scratch usually takes quite some time too.
>
> We, as a community have to improve our tools, it will be a lot of work but work _is_ being done right now, think of the compiler, loader, networking, file access, package management.
>
> This very small hack already makes a difference: http://code.google.com/p/pharo/issues/detail?id=5222 and we need many more.
>
> Sven
Stéphane Ducasse
2012-01-29 18:39:29 UTC
Permalink
>>> No, it does not.
>>
>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.
>
> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.


You confuse artifacts and models.
Give me 1 engineer full time and we fix that.


> And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison.
>
> [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
> [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/
>
> Cheers
> Philippe


Stef
Philippe Marschall
2012-01-29 19:50:37 UTC
Permalink
On 29.01.2012 19:39, St?phane Ducasse wrote:
>
>>>> No, it does not.
>>>
>>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.
>>
>> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
>
>
> You confuse artifacts and models.

No, because in the real world compared to the Smalltalk Theoretic
Perfect World it doesn't matter how things could scale, it matters how
things do scale. See [1]

[1] http://c2.com/cgi/wiki?SufficientlySmartCompiler

Cheers
Philippe
Guido Stepken
2012-01-29 20:12:19 UTC
Permalink
I often discuss with Frank Lesser about Smalltalk compiler internals. He
has written a Smalltalk VM (GVM), that is written in Assembler and jits
Smalltalk directly dynamically into Intel machine code, that is *faster*
than C in normal cases, expecially when fine tuned, able to run VS, VA,
Squeak, Dolphin, Lesser Smalltalk in their own namespace, and MP!!! Sounds
strange, because of different implementations (bytecode, callbacks...). GC
runs on a 2.nd processor, what means, no more interruptions, Real Time
Availability!!! If you want, you can control all traffic signs of NY within
one Intel machine.

He proofes, that Smalltalk, expecially Pharo is far away from being at the
end.... :-)

(And yes, i try to convince him to take part in the "language shootout" and
make his GVM MIT license) :-)

regards, Guido Stepken
Am 29.01.2012 20:51 schrieb "Philippe Marschall" <kustos at gmx.net>:

> On 29.01.2012 19:39, St?phane Ducasse wrote:
>
>>
>> No, it does not.
>>>>>
>>>>
>>>> Please elaborate: I really can't see the difference between doing a
>>>> merge (either an easy one or a more diffucult one over multiple files,
>>>> spread over a couple of days, with intervening changes by others) using
>>>> either Monticello or Git.
>>>>
>>>
>>> The scalability limits of Monticello are well understood. PackageInfo
>>> doesn't scale, at all. You put too many classes in a package, and
>>> snapshotting gets really slow. Don't believe me? Make a change in Morphic
>>> which has only 200 classes and save it.
>>>
>>
>>
>> You confuse artifacts and models.
>>
>
> No, because in the real world compared to the Smalltalk Theoretic Perfect
> World it doesn't matter how things could scale, it matters how things do
> scale. See [1]
>
> [1] http://c2.com/cgi/wiki?**SufficientlySmartCompiler<http://c2.com/cgi/wiki?SufficientlySmartCompiler>
>
> Cheers
> Philippe
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/25aed463/attachment.html>
Philippe Marschall
2012-01-29 22:08:18 UTC
Permalink
On 29.01.2012 21:12, Guido Stepken wrote:
> I often discuss with Frank Lesser about Smalltalk compiler internals. He
> has written a Smalltalk VM (GVM), that is written in Assembler and jits
> Smalltalk directly dynamically into Intel machine code, that is *faster*
> than C in normal cases, expecially when fine tuned, able to run VS, VA,
> Squeak, Dolphin, Lesser Smalltalk in their own namespace, and MP!!!
> Sounds strange, because of different implementations (bytecode,
> callbacks...). GC runs on a 2.nd processor, what means, no more
> interruptions, Real Time Availability!!! If you want, you can control
> all traffic signs of NY within one Intel machine.
>
> He proofes, that Smalltalk, expecially Pharo is far away from being at
> the end.... :-)
>
> (And yes, i try to convince him to take part in the "language shootout"
> and make his GVM MIT license) :-)

You didn't get my point. My point is tools suck until you fix them. Just
saying you could fix them doesn't fix them.

To rehash the argument:
Me: Monticello doesn't scale
Stef: we could make Monticello scale

Now does this make Monticello scale? In the STPW it does. It the real
world it doesn't until somebody goes there and fixes Monticello.

So what are we discussing the real world or the STPW?

Cheers
Philippe
Philippe Marschall
2012-01-29 20:04:10 UTC
Permalink
On 29.01.2012 19:39, St?phane Ducasse wrote:
>
>>>> No, it does not.
>>>
>>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git.
>>
>> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it.
>
>
> You confuse artifacts and models.
> Give me 1 engineer full time and we fix that.

Linus wrote git in two weeks. We would stop all work on the kernel until
we had an SCM that satisfied all this requirements including being fast
and scalable. Isn't Smalltalk supposed to make you super productive?

Cheers
Philippe
Chris Muller
2012-01-29 21:31:24 UTC
Permalink
But the goal of making the image smaller is congruent with the goal of
making Morphic smaller, which would be congruent with the desire for
Monticello to be "scalable". So the solution should be smaller
packages, not more and bigger tools.

Besides, the measure of scale you've chosen is an build /
initialization step, which can much more afford to be "slow",
especially if the dream is to just have it sit and build 24 hours a
day.

A better non-scaling measure to recognize in Monticello, IMO, is using
FileBased repositories, which require enumeration of an ever-growing
number of versions for many of its operations.

Using a database-backed MC repository solves that.



On Sun, Jan 29, 2012 at 11:48 AM, Philippe Marschall <kustos at gmx.net> wrote:
> On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
>>
>>
>> On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>>
>>>> As for scale.. monticello scales well.
>>>
>>>
>>> No, it does not.
>>
>>
>> Please elaborate: I really can't see the difference between doing a merge
>> (either an easy one or a more diffucult one over multiple files, spread over
>> a couple of days, with intervening changes by others) using either
>> Monticello or Git.
>
>
> The scalability limits of Monticello are well understood. PackageInfo
> doesn't scale, at all. You put too many classes in a package, and
> snapshotting gets really slow. Don't believe me? Make a change in Morphic
> which has only 200 classes and save it.
>
> And it's not like loading is any faster. Seaside takes 10 minutes to build
> from locally cached [1] packages, only 12 seconds go to running tests [2].
> This makes C++ compilation times seem fast by comparison.
>
> ?[1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
> ?[2]
> http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/
>
> Cheers
> Philippe
>
>
Philippe Marschall
2012-01-29 22:03:34 UTC
Permalink
On 29.01.2012 22:31, Chris Muller wrote:
> But the goal of making the image smaller is congruent with the goal of
> making Morphic smaller, which would be congruent with the desire for
> Monticello to be "scalable".

What are you talking about? I chose Morphic because it was the first
package I found that had more than a dozen classes.

> So the solution should be smaller
> packages, not more and bigger tools.

You should chose the package size on what makes sense from a software
design point of view, not what the scalability limit of your tools is.

> Besides, the measure of scale you've chosen is an build /
> initialization step, which can much more afford to be "slow",
> especially if the dream is to just have it sit and build 24 hours a
> day.
>
> A better non-scaling measure to recognize in Monticello, IMO, is using
> FileBased repositories, which require enumeration of an ever-growing
> number of versions for many of its operations.
>
> Using a database-backed MC repository solves that.

What are we discussing here? What is or the STPF?

Cheers
Philippe
Igor Stasenko
2012-02-01 15:55:01 UTC
Permalink
On 29 January 2012 18:48, Philippe Marschall <kustos at gmx.net> wrote:
> On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
>>
>>
>> On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>>
>>>> As for scale.. monticello scales well.
>>>
>>>
>>> No, it does not.
>>
>>
>> Please elaborate: I really can't see the difference between doing a merge
>> (either an easy one or a more diffucult one over multiple files, spread over
>> a couple of days, with intervening changes by others) using either
>> Monticello or Git.
>
>
> The scalability limits of Monticello are well understood. PackageInfo
> doesn't scale, at all. You put too many classes in a package, and
> snapshotting gets really slow. Don't believe me? Make a change in Morphic
> which has only 200 classes and save it.

so don't make too many classes in one package.

>
> And it's not like loading is any faster. Seaside takes 10 minutes to build
> from locally cached [1] packages, only 12 seconds go to running tests [2].
> This makes C++ compilation times seem fast by comparison.
>
Bah..
read this
http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-packages-with-fuel/

So?. if you have followed the previous steps, then just open
?Fuel.image? (a new Pharo 1.3 image where Fuel is loaded but seaside
is not), paste the previous code into a workspace and execute it. Of
course that it depends on the machine, but here (Mac Book Pro i5), it
only takes 10 seconds.

And we can store packages serialized by Fuel.

Actually we're not speaking about scale in same sense.
It is not about package size or time they load (i can always put an
infinite loop in one of #initialize methods of my class, so it will
take an infinite time to load a package with it ;) , but putting a
bunch of developers to work on a single project.
MC has some deficiencies, but not in that regard.

> ?[1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend
> ?[2]
> http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testReport/
>
> Cheers
> Philippe
>
>



--
Best regards,
Igor Stasenko.
Göran Krampe
2012-01-29 23:25:23 UTC
Permalink
On 01/29/2012 05:02 PM, Sven Van Caekenberghe wrote:
> PS: one of the things that we should take from git, as many others have said on this list, is selective commits.

If I ever get around to picking up Deltas again it would make a really
good tool to enable this on top of current MC (or any other tool of course).

I do have an itch with Deltas but might end up pushing it into Amber first.

regards, G?ran
dimitris chloupis
2012-01-29 07:48:09 UTC
Permalink
exactly what I meant, glad you see it that way too.


________________________________
From: Hilaire Fernandes <hilaire.fernandes at edu.ge.ch>
To: pharo-project at lists.gforge.inria.fr
Sent: Saturday, 28 January 2012, 23:06
Subject: Re: [Pharo-project] Smalltalk for small projects only?

May be it is time to forget about the image, I mean the name of the
image and change for something else, more in the proximal learning zone
of programmer. It is not an image we have, it is a data base of object,
and we are programming on this object data base.

Hilaire


Le 28/01/2012 17:50, dimitris chloupis a ?crit :
> The issue with image here its easy to totally miss the whole point. An
> image is loading lighting fast , a java application is not, its also
> great way to organise object orientated code because it allows you to
> quickly navigate through it, loading files , is expensive and frankly
> quite archaic. The idea behind filesystem was created on the basic that
> computer could only load just a few kbs or even less because of limited
> memory.


--
Dr. Geo -- http://www.drgeo.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/97832fd1/attachment.html>
Dale Henrichs
2012-01-28 18:07:36 UTC
Permalink
Janko,

I think the limitation for Smalltalk lies in source code management tools/styles ...

With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...

In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...

There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...

The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...

There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).

Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.

Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)

Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...

Dale



----- Original Message -----
| From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| To: Pharo-project at lists.gforge.inria.fr, "Squeak" <squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
| Sent: Saturday, January 28, 2012 7:46:32 AM
| Subject: [squeak-dev] Smalltalk for small projects only?
|
| Hi guys,
|
| Ralph Johnson in his InfoQ interview made an interesting observation:
|
| 2:55 minute: "Smalltalk made an fundamental error ... image ... you
| can
| build something with 4-5 people what 50 people can build in Java, but
| if
| you take 200 people in Java ... it is really designed for small
| systems
| ... "
|
| Are we because of the image really destined for relatively small
| projects and small systems (of Java 50 people project size)?
|
| Are we really not able to scale to bigger projects/systems because of
| that?
|
| Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
| still...
|
| [1] http://www.infoq.com/interviews/johnson-armstrong-oop
|
| Best regards
| Janko
|
|
| --
| Janko Miv?ek
| Aida/Web
| Smalltalk Web Application Server
| http://www.aidaweb.si
|
|
Sven Van Caekenberghe
2012-01-28 19:08:08 UTC
Permalink
Dale,

On 28 Jan 2012, at 19:07, Dale Henrichs wrote:

> Janko,
>
> I think the limitation for Smalltalk lies in source code management tools/styles ...
>
> With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
>
> In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
>
> There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
>
> The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
>
> There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
>
> Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
>
> Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
>
> Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
>
> Dale

I want to respectfully disagree (and I even don't understand some of your remarks, or the underlying implications, given your excellent work on Metacello and some much other contributions to Smalltalk).

Yes, the very old way of passing images around was arcane and did not scale (I did this too in the 80'ies early 90'ies).

But today, with Monticello and Metacello things are quite different, not perfect but totally acceptable.

When building Smalltalk applications I am using code written by hundreds of people during tens of years, this works out very well.

In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related. Merging, branching, solving conflicts there is no different than with Monticello, IMHO.

Organizing big teams is plain hard, in any language. Clear separations/responsabilities/interfaces are the only answer.

Sven
Schwab,Wilhelm K
2012-01-28 23:04:56 UTC
Permalink
EEEEEEKkkkkk :)

"In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related."

No, it's cool, it's EASY. "You just" check in your code and merge it. How dare you suggest that ****anything*** could go wrong during this sacred maneuver. If it does, just change SCM and blame the old one. By the time anyone figures out it did no good at all to switch, you've been promoted. Cool, eh?

/satireOff.

________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven at beta9.be]
Sent: Saturday, January 28, 2012 2:08 PM
To: The general-purpose Squeak developers list
Cc: VWNC; Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

Dale,

On 28 Jan 2012, at 19:07, Dale Henrichs wrote:

> Janko,
>
> I think the limitation for Smalltalk lies in source code management tools/styles ...
>
> With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
>
> In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
>
> There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
>
> The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
>
> There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
>
> Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
>
> Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
>
> Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
>
> Dale

I want to respectfully disagree (and I even don't understand some of your remarks, or the underlying implications, given your excellent work on Metacello and some much other contributions to Smalltalk).

Yes, the very old way of passing images around was arcane and did not scale (I did this too in the 80'ies early 90'ies).

But today, with Monticello and Metacello things are quite different, not perfect but totally acceptable.

When building Smalltalk applications I am using code written by hundreds of people during tens of years, this works out very well.

In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related. Merging, branching, solving conflicts there is no different than with Monticello, IMHO.

Organizing big teams is plain hard, in any language. Clear separations/responsabilities/interfaces are the only answer.

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

:)

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

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



> /satireOff.
>
> ________________________________________
> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven at beta9.be]
> Sent: Saturday, January 28, 2012 2:08 PM
> To: The general-purpose Squeak developers list
> Cc: VWNC; Pharo-project at lists.gforge.inria.fr
> Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?
>
> Dale,
>
> On 28 Jan 2012, at 19:07, Dale Henrichs wrote:
>
>> Janko,
>>
>> I think the limitation for Smalltalk lies in source code management tools/styles ...
>>
>> With a file-based language 200 engineers can contribute to the project ... ?each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
>>
>> In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
>>
>> There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
>>
>> The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
>>
>> There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
>>
>> Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
>>
>> Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
>>
>> Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
>>
>> Dale
>
> I want to respectfully disagree (and I even don't understand some of your remarks, or the underlying implications, given your excellent work on Metacello and some much other contributions to Smalltalk).
>
> Yes, the very old way of passing images around was arcane and did not scale (I did this too in the 80'ies early 90'ies).
>
> But today, with Monticello and Metacello things are quite different, not perfect but totally acceptable.
>
> When building Smalltalk applications I am using code written by hundreds of people during tens of years, this works out very well.
>
> In traditional file bases language like Java or C using a traditional SCM, you will immediately hit problems when even a couple of people work on parts of code that are closely related. Merging, branching, solving conflicts there is no different than with Monticello, IMHO.
>
> Organizing big teams is plain hard, in any language. Clear separations/responsabilities/interfaces are the only answer.
>
> Sven
>
>
>
>



--
Best regards,
Igor Stasenko.
Michael Haupt
2012-01-29 06:07:01 UTC
Permalink
Hi Igor,

Am 29.01.2012 um 00:11 schrieb Igor Stasenko <siguctua at gmail.com>:
> 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
Schwab,Wilhelm K
2012-01-29 10:27:36 UTC
Permalink
Yes, but that also takes a mythical being: a manager with the cojones to say "blame me, that was my decision."




________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt at gmail.com]
Sent: Sunday, January 29, 2012 1:07 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

Hi Igor,

Am 29.01.2012 um 00:11 schrieb Igor Stasenko <siguctua at gmail.com>:
> 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
Lawson English
2012-01-28 19:36:21 UTC
Permalink
Spoon would address many of these issues in a Smalltalk-centric way, I
think.


L.

On 1/28/12 11:07 AM, Dale Henrichs wrote:
> Janko,
>
> I think the limitation for Smalltalk lies in source code management tools/styles ...
>
> With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
>
> In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
>
> There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
>
> The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
>
> There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
>
> Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
>
> Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
>
> Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
>
> Dale
>
>
>
> ----- Original Message -----
> | From: "Janko Miv?ek"<janko.mivsek at eranova.si>
> | To: Pharo-project at lists.gforge.inria.fr, "Squeak"<squeak-dev at lists.squeakfoundation.org>, "VWNC"<vwnc at cs.uiuc.edu>
> | Sent: Saturday, January 28, 2012 7:46:32 AM
> | Subject: [squeak-dev] Smalltalk for small projects only?
> |
> | Hi guys,
> |
> | Ralph Johnson in his InfoQ interview made an interesting observation:
> |
> | 2:55 minute: "Smalltalk made an fundamental error ... image ... you
> | can
> | build something with 4-5 people what 50 people can build in Java, but
> | if
> | you take 200 people in Java ... it is really designed for small
> | systems
> | ... "
> |
> | Are we because of the image really destined for relatively small
> | projects and small systems (of Java 50 people project size)?
> |
> | Are we really not able to scale to bigger projects/systems because of
> | that?
> |
> | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
> | still...
> |
> | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
> |
> | Best regards
> | Janko
> |
> |
> | --
> | Janko Miv?ek
> | Aida/Web
> | Smalltalk Web Application Server
> | http://www.aidaweb.si
> |
> |
>
>
Janko Mivšek
2012-01-28 20:16:55 UTC
Permalink
Dale,

I agree with you that source code management is where we are weak. A
process therefore, as James already said.

In SCM VisualWorks is ahead in my opinion, even that Store is also not
perfect yet. But it would be useful to reuse some of ideas in Monticello
based SCM tools too. With Metacello we got a good packaging tool, so,
where to go to be even better? I think SCM tool integration into code
browser can be next and relatively easy step. As Store is integrated
into VW code browser.

Janko

S, Dale Henrichs pi?e:
> Janko,
>
> I think the limitation for Smalltalk lies in source code management tools/styles ...
>
> With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...
>
> In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...
>
> There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...
>
> The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...
>
> There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).
>
> Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.
>
> Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)
>
> Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...
>
> Dale
>
>
>
> ----- Original Message -----
> | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
> | To: Pharo-project at lists.gforge.inria.fr, "Squeak" <squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
> | Sent: Saturday, January 28, 2012 7:46:32 AM
> | Subject: [squeak-dev] Smalltalk for small projects only?
> |
> | Hi guys,
> |
> | Ralph Johnson in his InfoQ interview made an interesting observation:
> |
> | 2:55 minute: "Smalltalk made an fundamental error ... image ... you
> | can
> | build something with 4-5 people what 50 people can build in Java, but
> | if
> | you take 200 people in Java ... it is really designed for small
> | systems
> | ... "
> |
> | Are we because of the image really destined for relatively small
> | projects and small systems (of Java 50 people project size)?
> |
> | Are we really not able to scale to bigger projects/systems because of
> | that?
> |
> | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
> | still...
> |
> | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
> |
> | Best regards
> | Janko
> |
> |
> | --
> | Janko Miv?ek
> | Aida/Web
> | Smalltalk Web Application Server
> | http://www.aidaweb.si
> |
> |
>
>

--
Janko Miv?ek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel: 01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565
Philippe Marschall
2012-01-29 15:09:26 UTC
Permalink
On 28.01.2012 21:16, Janko Miv?ek wrote:
> Dale,
>
> I agree with you that source code management is where we are weak. A
> process therefore, as James already said.
>
> In SCM VisualWorks is ahead in my opinion, even that Store is also not
> perfect yet. But it would be useful to reuse some of ideas in Monticello
> based SCM tools too. With Metacello we got a good packaging tool, so,
> where to go to be even better? I think SCM tool integration into code
> browser can be next and relatively easy step. As Store is integrated
> into VW code browser.

Wow, Store. Did you know that Store is so bad that some of the biggest
Cincom success stories paid a really huge, undisclosed sum so that they
don't have to use it?

If something cries 1995 then it's handing a SQL connection to the
client. Your "interface" is the database schema. It ties the database
schema to the client. You change the schema and you have to update all
of the clients unless you "fake" the old schema with updatable views (if
your RDBMS even supports this) and give the changed tables new names.

Also security becomes more or less impossible to do. Once you have write
access to the public Store repository you can more or less do anything
you want to do on any project unless implement it using triggers. And
then there are all the possible DoS attacks like SELECT FOR UPDATE.

Cheers
Philippe
Steve Wart
2012-01-29 16:29:32 UTC
Permalink
Big legacy projects are still using Envy for VisualWorks less for the
reasons listed below, but mostly because it's extremely difficult to
migrate to Store without doing a "big bang" and most of these projects
don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar
with 2 or 3 of these "success stories"). Many of the big Smalltalk projects
were mostly done using Envy, and it's a powerful tool, in spite of its
limitations. If there was a reliable way to move the latest changes from a
set of Envy configuration maps into Store, it would make it much easier to
get away from ancient, buggy and unsupported SCMs (like Envy/GemKit).

But I confess I am not a big fan of Store. It works and has some good
features, but it's VW-only and the model is not acceptable for modern
development practices, never mind security issues and whatnot.

I would like to know better what Ralph was talking about in this interview.
It's hard to generalize about this sort of thing without starting a huge
rambling flame war or similarly unenlightening cascade of posts.

I would personally like to see a git backend for Smalltalk that works
across all dialects. VisualWorks really threw a monkey wrench into things
by adding proprietary extensions but as we've seen with Seaside, if there's
a common need, the community can rally together and come up with some
reliably mechanisms to support all versions of the language.

How would git work? Source code in files, how quaint, and all that?

I don't think it's that hard. In Smalltalk a compilation unit is a method,
so you store one file per method. Get rid of the changes file. Index things
so everything doesn't grind to a halt.

Maybe I'm missing something, but I think this is the way to go. Are there
any fundamental problems with this approach (other than resources and
funding and the usual perfectly valid excuses)?

Cheers,
Steve

On Sun, Jan 29, 2012 at 7:09 AM, Philippe Marschall <kustos at gmx.net> wrote:

> On 28.01.2012 21:16, Janko Miv?ek wrote:
>
>> Dale,
>>
>> I agree with you that source code management is where we are weak. A
>> process therefore, as James already said.
>>
>> In SCM VisualWorks is ahead in my opinion, even that Store is also not
>> perfect yet. But it would be useful to reuse some of ideas in Monticello
>> based SCM tools too. With Metacello we got a good packaging tool, so,
>> where to go to be even better? I think SCM tool integration into code
>> browser can be next and relatively easy step. As Store is integrated
>> into VW code browser.
>>
>
> Wow, Store. Did you know that Store is so bad that some of the biggest
> Cincom success stories paid a really huge, undisclosed sum so that they
> don't have to use it?
>
> If something cries 1995 then it's handing a SQL connection to the client.
> Your "interface" is the database schema. It ties the database schema to the
> client. You change the schema and you have to update all of the clients
> unless you "fake" the old schema with updatable views (if your RDBMS even
> supports this) and give the changed tables new names.
>
> Also security becomes more or less impossible to do. Once you have write
> access to the public Store repository you can more or less do anything you
> want to do on any project unless implement it using triggers. And then
> there are all the possible DoS attacks like SELECT FOR UPDATE.
>
> Cheers
> Philippe
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/eaefa761/attachment.html>
Frank Shearar
2012-01-29 18:02:05 UTC
Permalink
On 29 January 2012 16:29, Steve Wart <steve at wart.ca> wrote:
> Big legacy projects are still using Envy for VisualWorks less for the
> reasons listed below, but mostly because it's extremely difficult to migrate
> to Store without doing a "big bang" and most of these projects don't have
> 200+ developers anymore anyhow (disclaimer: I'm only familiar with 2 or 3 of
> these "success stories"). Many of the big Smalltalk projects were mostly
> done using Envy, and it's a powerful tool, in spite of its limitations. If
> there was a reliable way to move the latest changes from a set of Envy
> configuration maps into Store, it would make it much easier to get away from
> ancient, buggy and unsupported SCMs (like Envy/GemKit).
>
> But I confess I am not a big fan of Store. It works and has some good
> features, but it's VW-only and the model is not acceptable for modern
> development practices, never mind security issues and whatnot.
>
> I would like to know better what Ralph was talking about in this interview.
> It's hard to generalize about this sort of thing without starting a huge
> rambling flame war or similarly unenlightening cascade of posts.
>
> I would personally like to see a git backend for Smalltalk that works across
> all dialects. VisualWorks really threw a monkey wrench into things by adding
> proprietary extensions but as we've seen with Seaside, if there's a common
> need, the community can rally together and come up with some reliably
> mechanisms to support all versions of the language.

(a) Count me in on a git-based backend (I use github! Without chunk
format!) and (b) I know of at several git-using projects
- Tim Felgentreff's Gitocello (https://github.com/timfel/gitocello)
dumps chunk format into a git repo (tracked as you use Monticello)
- GSOC 2010 had a proposal
l(http://gsoc2010.esug.org/projects/git-mercurial) - Goran, did this
get off the ground? Or is the r
- Tony Garnock-Jones wrote a git repository implementation
(http://www.squeaksource.com/Git.html)
- Pharogenesis (https://github.com/pharogenesis/pharogenesis and
http://scg.unibe.ch/research/Pharogenesis) defines what looks like a
reasonable mapping, and that comes from
- GitFS (http://www.squeaksource.com/GitFS.html)

I suspect that most of the pieces of the puzzle are just lying around
waiting for someone to plug them together! (Clearly writing TO the
repository is trivial. You'd also want the reverse: "oh, the repo's
updated; load the new versions of things." This is where things might
get tricky, because the load order of things may be important.)

> How would git work? Source code in files, how quaint, and all that?

Easy enough to address that perception though: "no, source code in an
object database (for lo, that's what git is)"!

> I don't think it's that hard. In Smalltalk a compilation unit is a method,
> so you store one file per method. Get rid of the changes file. Index things
> so everything doesn't grind to a halt.
>
> Maybe I'm missing something, but I think this is the way to go. Are there
> any fundamental problems with this approach (other than resources and
> funding and the usual perfectly valid excuses)?

Really, I suspect it's just that no one has sufficient
time/interest/energy. Well, there's definitely _interest_ :)

frank

> Cheers,
> Steve
>
>
> On Sun, Jan 29, 2012 at 7:09 AM, Philippe Marschall <kustos at gmx.net> wrote:
>>
>> On 28.01.2012 21:16, Janko Miv?ek wrote:
>>>
>>> Dale,
>>>
>>> I agree with you that source code management is where we are weak. A
>>> process therefore, as James already said.
>>>
>>> In SCM ?VisualWorks is ahead in my opinion, even that Store is also not
>>> perfect yet. But it would be useful to reuse some of ideas in Monticello
>>> based SCM tools too. With Metacello we got a good packaging tool, so,
>>> where to go to be even better? I think SCM tool integration into code
>>> browser can be next and relatively easy step. As Store is integrated
>>> into VW code browser.
>>
>>
>> Wow, Store. Did you know that Store is so bad that some of the biggest
>> Cincom success stories paid a really huge, undisclosed sum so that they
>> don't have to use it?
>>
>> If something cries 1995 then it's handing a SQL connection to the client.
>> Your "interface" is the database schema. It ties the database schema to the
>> client. You change the schema and you have to update all of the clients
>> unless you "fake" the old schema with updatable views (if your RDBMS even
>> supports this) and give the changed tables new names.
>>
>> Also security becomes more or less impossible to do. Once you have write
>> access to the public Store repository you can more or less do anything you
>> want to do on any project unless implement it using triggers. And then there
>> are all the possible DoS attacks like SELECT FOR UPDATE.
>>
>> Cheers
>> Philippe
>>
>>
>
Göran Krampe
2012-01-29 23:25:51 UTC
Permalink
On 01/29/2012 07:02 PM, Frank Shearar wrote:
> - GSOC 2010 had a proposal
> l(http://gsoc2010.esug.org/projects/git-mercurial) - Goran, did this
> get off the ground?

AFAIK, not really.

regards, G?ran
Philippe Marschall
2012-01-29 19:39:59 UTC
Permalink
On 29.01.2012 17:29, Steve Wart wrote:
> Big legacy projects are still using Envy for VisualWorks less for the
> reasons listed below, but mostly because it's extremely difficult to
> migrate to Store without doing a "big bang" and most of these projects
> don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar
> with 2 or 3 of these "success stories"). Many of the big Smalltalk
> projects were mostly done using Envy, and it's a powerful tool, in spite
> of its limitations. If there was a reliable way to move the latest
> changes from a set of Envy configuration maps into Store, it would make
> it much easier to get away from ancient, buggy and unsupported SCMs
> (like Envy/GemKit).

So in something like ten (10) years they haven't managed to migrate
await form said SCMs?

Cheers
Philippe
Steve Wart
2012-01-29 19:58:29 UTC
Permalink
On Sun, Jan 29, 2012 at 11:39 AM, Philippe Marschall <kustos at gmx.net> wrote:

> On 29.01.2012 17:29, Steve Wart wrote:
>
>> Big legacy projects are still using Envy for VisualWorks less for the
>> reasons listed below, but mostly because it's extremely difficult to
>> migrate to Store without doing a "big bang" and most of these projects
>> don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar
>> with 2 or 3 of these "success stories"). Many of the big Smalltalk
>> projects were mostly done using Envy, and it's a powerful tool, in spite
>> of its limitations. If there was a reliable way to move the latest
>> changes from a set of Envy configuration maps into Store, it would make
>> it much easier to get away from ancient, buggy and unsupported SCMs
>> (like Envy/GemKit).
>>
>
> So in something like ten (10) years they haven't managed to migrate await
> form said SCMs


OOCL and JP Morgan are still using Envy (although I've heard that JPM has
purchased a license from IBM and maintains an in-house fork with the latest
version of VW). I believe UBS has migrated to Store, but their team is very
small and tight-knit. It's been very hard for big distributed shops to
migrate SCM from Envy to Store. I think that Cincom has provided consulting
support for that but I don't think they've provided any stats on the cost
or effort to migrate a typical project.

VA shops continue to use Envy as a supported and effective SCM but I
haven't used VA commercially, but I'm assuming it works for them.

It's not surprising that this old stuff doesn't get migrated given how IT
projects are funded in general. When you've got hundreds of Java servers
spewing errors all day, it's hard to get excited about some old Smalltalk
stuff that just keeps the business chugging along.

Cheers,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/0fdc2339/attachment.html>
Michael Haupt
2012-01-28 21:34:41 UTC
Permalink
Karl,

Am 28.01.2012 um 20:39 schrieb karl ramberg <karlramberg at gmail.com>:
> Is there any work done on managing live images with several developers ?

I'm not all sure I understand your question, but: http://www.hpi.uni-potsdam.de/hirschfeld/misc/etc/index.html

Best,

Michael
Schwab,Wilhelm K
2012-01-28 22:58:48 UTC
Permalink
200 5+year smalltalkers - that's an army capable of almost anything...




________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich at vmware.com]
Sent: Saturday, January 28, 2012 1:07 PM
To: The general-purpose Squeak developers list
Cc: VWNC; Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

Janko,

I think the limitation for Smalltalk lies in source code management tools/styles ...

With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ...

In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale...

There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs...

The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ...

There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:).

Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one.

Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:)

Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ...

Dale



----- Original Message -----
| From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| To: Pharo-project at lists.gforge.inria.fr, "Squeak" <squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
| Sent: Saturday, January 28, 2012 7:46:32 AM
| Subject: [squeak-dev] Smalltalk for small projects only?
|
| Hi guys,
|
| Ralph Johnson in his InfoQ interview made an interesting observation:
|
| 2:55 minute: "Smalltalk made an fundamental error ... image ... you
| can
| build something with 4-5 people what 50 people can build in Java, but
| if
| you take 200 people in Java ... it is really designed for small
| systems
| ... "
|
| Are we because of the image really destined for relatively small
| projects and small systems (of Java 50 people project size)?
|
| Are we really not able to scale to bigger projects/systems because of
| that?
|
| Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
| still...
|
| [1] http://www.infoq.com/interviews/johnson-armstrong-oop
|
| Best regards
| Janko
|
|
| --
| Janko Miv?ek
| Aida/Web
| Smalltalk Web Application Server
| http://www.aidaweb.si
|
|
Igor Stasenko
2012-01-28 23:07:32 UTC
Permalink
On 28 January 2012 23:58, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> 200 5+year smalltalkers - that's an army capable of almost anything...
>
without good commander, this is not an army but a bunch of individuals.

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

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



--
Best regards,
Igor Stasenko.
Schwab,Wilhelm K
2012-01-28 23:19:45 UTC
Permalink
Understood. BTW, I'm a GOOD commander. I design stuff and parcel things out to troops to kick some and then report back, making myself available along the way. If it goes wrong, it's ON ME, not my people.

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



________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua at gmail.com]
Sent: Saturday, January 28, 2012 6:07 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

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

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

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



--
Best regards,
Igor Stasenko.
Dale Henrichs
2012-01-28 21:31:22 UTC
Permalink
Janko,

Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...

I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.

I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...

Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...

I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.

We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.

Dale

----- Original Message -----
| From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| To: Pharo-project at lists.gforge.inria.fr
| Cc: "Dale Henrichs" <dhenrich at vmware.com>, "The general-purpose Squeak developers list"
| <squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
| Sent: Saturday, January 28, 2012 12:16:55 PM
| Subject: Re: [Smalltalk for small projects only?
|
| Dale,
|
| I agree with you that source code management is where we are weak. A
| process therefore, as James already said.
|
| In SCM VisualWorks is ahead in my opinion, even that Store is also
| not
| perfect yet. But it would be useful to reuse some of ideas in
| Monticello
| based SCM tools too. With Metacello we got a good packaging tool, so,
| where to go to be even better? I think SCM tool integration into code
| browser can be next and relatively easy step. As Store is integrated
| into VW code browser.
|
| Janko
|
| S, Dale Henrichs pi?e:
| > Janko,
| >
| > I think the limitation for Smalltalk lies in source code management
| > tools/styles ...
| >
| > With a file-based language 200 engineers can contribute to the
| > project ... each engineer can checkout a version of the system
| > work in isolation then commit his or her work to the shared
| > repository resolve conflicts and move on .... other engineers can
| > easily integrate the work and so on ... the source code management
| > tools scale ...
| >
| > In the mid nineties at ParcPlace systems the image was passed
| > around from engineer to engineer so that he or she could integrate
| > their work into the production image... this doesn't scale...
| >
| > There have been proprietary source code management tools that have
| > been created over the years. You can bet that the large companies
| > that are invested in Smalltalk are using systems that are based on
| > these proprietary systems, but you can also bet that they've had
| > to customize those systems for their needs...
| >
| > The file-based SCM systems work out of the box and don't care what
| > language or even development process that is being used ... they
| > are managing files ...
| >
| > There is no standard SCM for Smalltalk and none of the file-based
| > SCMs really fit Smalltalk. When we are arguing about whether git
| > or mercurial is better on the Pharo list, I will retract that
| > statement:).
| >
| > Without a standard SCM, the first thing that a 200 person
| > engineering groups needs to do to start using Smalltalk is figure
| > out (for themselves) how to share their work and keep 200
| > individual images in synch ... I'm not necessarily convinced that
| > anyone has really solved this one.
| >
| > Personally I believe that the problem is surmountable, but for
| > whatever reason the Smalltalk community hasn't focussed on
| > seriously addressing the SCM issue .... in the last 30 years or
| > so:)
| >
| > Being able to repeatably build images based on a minimal core image
| > is certainly headed in the right direction, but we still have a
| > ways to go on the tools front ...
| >
| > Dale
| >
| >
| >
| > ----- Original Message -----
| > | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| > | To: Pharo-project at lists.gforge.inria.fr, "Squeak"
| > | <squeak-dev at lists.squeakfoundation.org>, "VWNC"
| > | <vwnc at cs.uiuc.edu>
| > | Sent: Saturday, January 28, 2012 7:46:32 AM
| > | Subject: [squeak-dev] Smalltalk for small projects only?
| > |
| > | Hi guys,
| > |
| > | Ralph Johnson in his InfoQ interview made an interesting
| > | observation:
| > |
| > | 2:55 minute: "Smalltalk made an fundamental error ... image ...
| > | you
| > | can
| > | build something with 4-5 people what 50 people can build in Java,
| > | but
| > | if
| > | you take 200 people in Java ... it is really designed for small
| > | systems
| > | ... "
| > |
| > | Are we because of the image really destined for relatively small
| > | projects and small systems (of Java 50 people project size)?
| > |
| > | Are we really not able to scale to bigger projects/systems
| > | because of
| > | that?
| > |
| > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
| > | still...
| > |
| > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
| > |
| > | Best regards
| > | Janko
| > |
| > |
| > | --
| > | Janko Miv?ek
| > | Aida/Web
| > | Smalltalk Web Application Server
| > | http://www.aidaweb.si
| > |
| > |
| >
| >
|
| --
| Janko Miv?ek
| Svetovalec za informatiko
| Eranova d.o.o.
| Ljubljana, Slovenija
| www.eranova.si
| tel: 01 514 22 55
| faks: 01 514 22 56
| gsm: 031 674 565
|
Frank Shearar
2012-01-28 21:45:04 UTC
Permalink
2012/1/28 Dale Henrichs <dhenrich at vmware.com>:
> Janko,
>
> Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...
>
> I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.

Um, do you mean Metacello or Monticello? Metacello seems like the
maven of Java world: "Here's what this artifact contains, its
dependencies, where you can find them, etc. etc."

> I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...
>
> Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...

A build should be a single command, with no customisation required at
all. This is especially important in large projects. Being able to
customise/parameterise a build means having an artifact but not
knowing what went into building it.

Otherwise, I agree. Luckily, more and more folks are starting to use
Metacello, and building images up from some small base.

frank

> I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.
>
> We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does ?pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.
>
> Dale
>
> ----- Original Message -----
> | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
> | To: Pharo-project at lists.gforge.inria.fr
> | Cc: "Dale Henrichs" <dhenrich at vmware.com>, "The general-purpose Squeak developers list"
> | <squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
> | Sent: Saturday, January 28, 2012 12:16:55 PM
> | Subject: Re: [Smalltalk for small projects only?
> |
> | Dale,
> |
> | I agree with you that source code management is where we are weak. A
> | process therefore, as James already said.
> |
> | In SCM ?VisualWorks is ahead in my opinion, even that Store is also
> | not
> | perfect yet. But it would be useful to reuse some of ideas in
> | Monticello
> | based SCM tools too. With Metacello we got a good packaging tool, so,
> | where to go to be even better? I think SCM tool integration into code
> | browser can be next and relatively easy step. As Store is integrated
> | into VW code browser.
> |
> | Janko
> |
> | S, Dale Henrichs pi?e:
> | > Janko,
> | >
> | > I think the limitation for Smalltalk lies in source code management
> | > tools/styles ...
> | >
> | > With a file-based language 200 engineers can contribute to the
> | > project ... ?each engineer can checkout a version of the system
> | > work in isolation then commit his or her work to the shared
> | > repository resolve conflicts and move on .... other engineers can
> | > easily integrate the work and so on ... the source code management
> | > tools scale ...
> | >
> | > In the mid nineties at ParcPlace systems the image was passed
> | > around from engineer to engineer so that he or she could integrate
> | > their work into the production image... this doesn't scale...
> | >
> | > There have been proprietary source code management tools that have
> | > been created over the years. You can bet that the large companies
> | > that are invested in Smalltalk are using systems that are based on
> | > these proprietary systems, but you can also bet that they've had
> | > to customize those systems for their needs...
> | >
> | > The file-based SCM systems work out of the box and don't care what
> | > language or even development process that is being used ... they
> | > are managing files ...
> | >
> | > There is no standard SCM for Smalltalk and none of the file-based
> | > SCMs really fit Smalltalk. When we are arguing about whether git
> | > or mercurial is better on the Pharo list, I will retract that
> | > statement:).
> | >
> | > Without a standard SCM, the first thing that a 200 person
> | > engineering groups needs to do to start using Smalltalk is figure
> | > out (for themselves) how to share their work and keep 200
> | > individual images in synch ... I'm not necessarily convinced that
> | > anyone has really solved this one.
> | >
> | > Personally I believe that the problem is surmountable, but for
> | > whatever reason the Smalltalk community hasn't focussed on
> | > seriously addressing the SCM issue .... in the last 30 years or
> | > so:)
> | >
> | > Being able to repeatably build images based on a minimal core image
> | > is certainly headed in the right direction, but we still have a
> | > ways to go on the tools front ...
> | >
> | > Dale
> | >
> | >
> | >
> | > ----- Original Message -----
> | > | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
> | > | To: Pharo-project at lists.gforge.inria.fr, "Squeak"
> | > | <squeak-dev at lists.squeakfoundation.org>, "VWNC"
> | > | <vwnc at cs.uiuc.edu>
> | > | Sent: Saturday, January 28, 2012 7:46:32 AM
> | > | Subject: [squeak-dev] Smalltalk for small projects only?
> | > |
> | > | Hi guys,
> | > |
> | > | Ralph Johnson in his InfoQ interview made an interesting
> | > | observation:
> | > |
> | > | 2:55 minute: "Smalltalk made an fundamental error ... image ...
> | > | you
> | > | can
> | > | build something with 4-5 people what 50 people can build in Java,
> | > | but
> | > | if
> | > | you take 200 people in Java ... it is really designed for small
> | > | systems
> | > | ... ?"
> | > |
> | > | Are we because of the image really destined for relatively small
> | > | projects and small systems (of Java 50 people project size)?
> | > |
> | > | Are we really not able to scale to bigger projects/systems
> | > | because of
> | > | that?
> | > |
> | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
> | > | still...
> | > |
> | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
> | > |
> | > | Best regards
> | > | Janko
> | > |
> | > |
> | > | --
> | > | Janko Miv?ek
> | > | Aida/Web
> | > | Smalltalk Web Application Server
> | > | http://www.aidaweb.si
> | > |
> | > |
> | >
> | >
> |
> | --
> | Janko Miv?ek
> | Svetovalec za informatiko
> | Eranova d.o.o.
> | Ljubljana, Slovenija
> | www.eranova.si
> | tel: ?01 514 22 55
> | faks: 01 514 22 56
> | gsm: 031 674 565
> |
>
Steve Wart
2012-01-29 16:42:59 UTC
Permalink
The idea of building the git workflow on top of metacello strikes me as
being somewhat ambitious.

To do merge properly (which is one of the huge strengths of git), using a
single .gz file seems likely to be extremely complex.

clone is just copying a .gz file?

pull/push are ftp upload/download of entire .gz file? git has some safety
features that would be tricky to implement on top of metacello I think

branch and checkout operations in git are crazy fast because of the clever
model it uses

monticello/metacello have the advantage of cross dialect support
(Squeak/Pharo/GemStone and VW to some extent), but it seems the semantics
may not be rich enough.

Of course this is just an impression. If someone has some more detailed
thoughts I would be keen to hear them.

Thanks,
Steve

2012/1/28 Dale Henrichs <dhenrich at vmware.com>

> Janko,
>
> Metacello itself needs work to make it usable by groups of developers ...
> the lack of merge capability is a real hindrance to being able to have
> multiple folks work on the same project and use Metacello ...
>
> I imagine that a Metacello configuration is the moral equivalent of a git
> repository. It should be possible to find "moral equivalents" of the
> various git operations: clone, push, pull, branch, checkout, merge, commit.
> It is something that I will be looking into in the not too distant future,
> since I want to improve the usability of Metacello for groups of developers.
>
> I agree that integrated tools is another area that needs attention....
> when it is time to commit your work there are just too many different
> windows and browsers that you have to monkey with to save your work ...
>
> Another area that shouldn't be neglected is the notion of basing things on
> a minimal core image and automated builds for individuals ... We've got
> folks doing good things with Jenkins but I sense that with each
> installation there are things that still need to be customized in the build
> process itself. It should be dead simple, like compiling a c file when you
> know the path to an image...
>
> I think we may focus too much on the in-image tools and not enough on the
> external tools that are just as important.
>
> We need to make it easy for a developer (in a team of developers) to check
> out a version of a minimal1 image, do a reproducible build of the correct
> version of the project, then fire up the image and do his or her
> development thang, commit/push/pull/merge/bang and then the next developer
> does pull/merge/build/boom to pick up the changes for her image and so on
> ... This involves more than just in-image tooling.
>
> Dale
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/e2486018/attachment.html>
Dale Henrichs
2012-01-28 22:36:57 UTC
Permalink
Frank,

No I meant what I said .... I'm not talking in a literal sense, but a functional sense ....

With Metacello I can 'clone' version 3.0.6 of Seaside30, i.e., make a local copy of all of mcz files that make up version 3.0.6 in local directory. If I load the files into an image I can edit the files including add new files, etc. and then 'commit' version 3.0.7 to my local directory, which includes new versions of files and a new version of the configuration. I can 'push' my local files (mcz and config) to the common repository and even 'pull', but when it comes to 'merge' it all falls apart, because 'merge' is not supported at the Metacello level. Monticello does a great job with merging and Metacello needs to step up to the plate on merge:)

Totally agree with you about builds...if customization is required, then each person around the world that does "a build" is not guaranteed to et exactly the same results...

Dale

----- Original Message -----
| From: "Frank Shearar" <frank.shearar at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, "Janko Miv?ek" <janko.mivsek at eranova.si>, Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, January 28, 2012 1:45:04 PM
| Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only?
|
| 2012/1/28 Dale Henrichs <dhenrich at vmware.com>:
| > Janko,
| >
| > Metacello itself needs work to make it usable by groups of
| > developers ... the lack of merge capability is a real hindrance to
| > being able to have multiple folks work on the same project and use
| > Metacello ...
| >
| > I imagine that a Metacello configuration is the moral equivalent of
| > a git repository. It should be possible to find "moral
| > equivalents" of the various git operations: clone, push, pull,
| > branch, checkout, merge, commit. It is something that I will be
| > looking into in the not too distant future, since I want to
| > improve the usability of Metacello for groups of developers.
|
| Um, do you mean Metacello or Monticello? Metacello seems like the
| maven of Java world: "Here's what this artifact contains, its
| dependencies, where you can find them, etc. etc."
|
| > I agree that integrated tools is another area that needs
| > attention.... when it is time to commit your work there are just
| > too many different windows and browsers that you have to monkey
| > with to save your work ...
| >
| > Another area that shouldn't be neglected is the notion of basing
| > things on a minimal core image and automated builds for
| > individuals ... We've got folks doing good things with Jenkins but
| > I sense that with each installation there are things that still
| > need to be customized in the build process itself. It should be
| > dead simple, like compiling a c file when you know the path to an
| > image...
|
| A build should be a single command, with no customisation required at
| all. This is especially important in large projects. Being able to
| customise/parameterise a build means having an artifact but not
| knowing what went into building it.
|
| Otherwise, I agree. Luckily, more and more folks are starting to use
| Metacello, and building images up from some small base.
|
| frank
|
| > I think we may focus too much on the in-image tools and not enough
| > on the external tools that are just as important.
| >
| > We need to make it easy for a developer (in a team of developers)
| > to check out a version of a minimal1 image, do a reproducible
| > build of the correct version of the project, then fire up the
| > image and do his or her development thang,
| > commit/push/pull/merge/bang and then the next developer does
| > ?pull/merge/build/boom to pick up the changes for her image and so
| > on ... This involves more than just in-image tooling.
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | Cc: "Dale Henrichs" <dhenrich at vmware.com>, "The general-purpose
| > | Squeak developers list"
| > | <squeak-dev at lists.squeakfoundation.org>, "VWNC"
| > | <vwnc at cs.uiuc.edu>
| > | Sent: Saturday, January 28, 2012 12:16:55 PM
| > | Subject: Re: [Smalltalk for small projects only?
| > |
| > | Dale,
| > |
| > | I agree with you that source code management is where we are
| > | weak. A
| > | process therefore, as James already said.
| > |
| > | In SCM ?VisualWorks is ahead in my opinion, even that Store is
| > | also
| > | not
| > | perfect yet. But it would be useful to reuse some of ideas in
| > | Monticello
| > | based SCM tools too. With Metacello we got a good packaging tool,
| > | so,
| > | where to go to be even better? I think SCM tool integration into
| > | code
| > | browser can be next and relatively easy step. As Store is
| > | integrated
| > | into VW code browser.
| > |
| > | Janko
| > |
| > | S, Dale Henrichs pi?e:
| > | > Janko,
| > | >
| > | > I think the limitation for Smalltalk lies in source code
| > | > management
| > | > tools/styles ...
| > | >
| > | > With a file-based language 200 engineers can contribute to the
| > | > project ... ?each engineer can checkout a version of the system
| > | > work in isolation then commit his or her work to the shared
| > | > repository resolve conflicts and move on .... other engineers
| > | > can
| > | > easily integrate the work and so on ... the source code
| > | > management
| > | > tools scale ...
| > | >
| > | > In the mid nineties at ParcPlace systems the image was passed
| > | > around from engineer to engineer so that he or she could
| > | > integrate
| > | > their work into the production image... this doesn't scale...
| > | >
| > | > There have been proprietary source code management tools that
| > | > have
| > | > been created over the years. You can bet that the large
| > | > companies
| > | > that are invested in Smalltalk are using systems that are based
| > | > on
| > | > these proprietary systems, but you can also bet that they've
| > | > had
| > | > to customize those systems for their needs...
| > | >
| > | > The file-based SCM systems work out of the box and don't care
| > | > what
| > | > language or even development process that is being used ...
| > | > they
| > | > are managing files ...
| > | >
| > | > There is no standard SCM for Smalltalk and none of the
| > | > file-based
| > | > SCMs really fit Smalltalk. When we are arguing about whether
| > | > git
| > | > or mercurial is better on the Pharo list, I will retract that
| > | > statement:).
| > | >
| > | > Without a standard SCM, the first thing that a 200 person
| > | > engineering groups needs to do to start using Smalltalk is
| > | > figure
| > | > out (for themselves) how to share their work and keep 200
| > | > individual images in synch ... I'm not necessarily convinced
| > | > that
| > | > anyone has really solved this one.
| > | >
| > | > Personally I believe that the problem is surmountable, but for
| > | > whatever reason the Smalltalk community hasn't focussed on
| > | > seriously addressing the SCM issue .... in the last 30 years or
| > | > so:)
| > | >
| > | > Being able to repeatably build images based on a minimal core
| > | > image
| > | > is certainly headed in the right direction, but we still have a
| > | > ways to go on the tools front ...
| > | >
| > | > Dale
| > | >
| > | >
| > | >
| > | > ----- Original Message -----
| > | > | From: "Janko Miv?ek" <janko.mivsek at eranova.si>
| > | > | To: Pharo-project at lists.gforge.inria.fr, "Squeak"
| > | > | <squeak-dev at lists.squeakfoundation.org>, "VWNC"
| > | > | <vwnc at cs.uiuc.edu>
| > | > | Sent: Saturday, January 28, 2012 7:46:32 AM
| > | > | Subject: [squeak-dev] Smalltalk for small projects only?
| > | > |
| > | > | Hi guys,
| > | > |
| > | > | Ralph Johnson in his InfoQ interview made an interesting
| > | > | observation:
| > | > |
| > | > | 2:55 minute: "Smalltalk made an fundamental error ... image
| > | > | ...
| > | > | you
| > | > | can
| > | > | build something with 4-5 people what 50 people can build in
| > | > | Java,
| > | > | but
| > | > | if
| > | > | you take 200 people in Java ... it is really designed for
| > | > | small
| > | > | systems
| > | > | ... ?"
| > | > |
| > | > | Are we because of the image really destined for relatively
| > | > | small
| > | > | projects and small systems (of Java 50 people project size)?
| > | > |
| > | > | Are we really not able to scale to bigger projects/systems
| > | > | because of
| > | > | that?
| > | > |
| > | > | Ok, there are few exceptions of course (JPMorgan, OOCL, ..),
| > | > | but
| > | > | still...
| > | > |
| > | > | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
| > | > |
| > | > | Best regards
| > | > | Janko
| > | > |
| > | > |
| > | > | --
| > | > | Janko Miv?ek
| > | > | Aida/Web
| > | > | Smalltalk Web Application Server
| > | > | http://www.aidaweb.si
| > | > |
| > | > |
| > | >
| > | >
| > |
| > | --
| > | Janko Miv?ek
| > | Svetovalec za informatiko
| > | Eranova d.o.o.
| > | Ljubljana, Slovenija
| > | www.eranova.si
| > | tel: ?01 514 22 55
| > | faks: 01 514 22 56
| > | gsm: 031 674 565
| > |
| >
|
|
Dale Henrichs
2012-01-28 22:57:24 UTC
Permalink
Sven,

Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ...

How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:)

Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ...

As I said, I don't think the problem is insurmountable...and I do think we are getting better.

It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"...

Dale

----- Original Message -----
| From: "Sven Van Caekenberghe" <sven at beta9.be>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, January 28, 2012 11:08:08 AM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
|
| Dale,
|
| On 28 Jan 2012, at 19:07, Dale Henrichs wrote:
|
| > Janko,
| >
| > I think the limitation for Smalltalk lies in source code management
| > tools/styles ...
| >
| > With a file-based language 200 engineers can contribute to the
| > project ... each engineer can checkout a version of the system
| > work in isolation then commit his or her work to the shared
| > repository resolve conflicts and move on .... other engineers can
| > easily integrate the work and so on ... the source code management
| > tools scale ...
| >
| > In the mid nineties at ParcPlace systems the image was passed
| > around from engineer to engineer so that he or she could integrate
| > their work into the production image... this doesn't scale...
| >
| > There have been proprietary source code management tools that have
| > been created over the years. You can bet that the large companies
| > that are invested in Smalltalk are using systems that are based on
| > these proprietary systems, but you can also bet that they've had
| > to customize those systems for their needs...
| >
| > The file-based SCM systems work out of the box and don't care what
| > language or even development process that is being used ... they
| > are managing files ...
| >
| > There is no standard SCM for Smalltalk and none of the file-based
| > SCMs really fit Smalltalk. When we are arguing about whether git
| > or mercurial is better on the Pharo list, I will retract that
| > statement:).
| >
| > Without a standard SCM, the first thing that a 200 person
| > engineering groups needs to do to start using Smalltalk is figure
| > out (for themselves) how to share their work and keep 200
| > individual images in synch ... I'm not necessarily convinced that
| > anyone has really solved this one.
| >
| > Personally I believe that the problem is surmountable, but for
| > whatever reason the Smalltalk community hasn't focussed on
| > seriously addressing the SCM issue .... in the last 30 years or
| > so:)
| >
| > Being able to repeatably build images based on a minimal core image
| > is certainly headed in the right direction, but we still have a
| > ways to go on the tools front ...
| >
| > Dale
|
| I want to respectfully disagree (and I even don't understand some of
| your remarks, or the underlying implications, given your excellent
| work on Metacello and some much other contributions to Smalltalk).
|
| Yes, the very old way of passing images around was arcane and did not
| scale (I did this too in the 80'ies early 90'ies).
|
| But today, with Monticello and Metacello things are quite different,
| not perfect but totally acceptable.
|
| When building Smalltalk applications I am using code written by
| hundreds of people during tens of years, this works out very well.
|
| In traditional file bases language like Java or C using a traditional
| SCM, you will immediately hit problems when even a couple of people
| work on parts of code that are closely related. Merging, branching,
| solving conflicts there is no different than with Monticello, IMHO.
|
| Organizing big teams is plain hard, in any language. Clear
| separations/responsabilities/interfaces are the only answer.
|
| Sven
|
|
|
|
Dale Henrichs
2012-01-28 23:20:27 UTC
Permalink
Karl,

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

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

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

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

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

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

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

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

Dale

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

----- Original Message -----
| From: "karl ramberg" <karlramberg at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, January 28, 2012 11:39:22 AM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
|
| On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs < dhenrich at vmware.com
| > wrote:
|
| You are talking about dealing with source code, but what about the
| live objects in the image? Is there any work done on managing live
| images with several developers ? This is where Smalltalk excels and
| would be very interesting instead of falling back to the rebuild
| from source strategy.
|
| Karl
Guido Stepken
2012-01-28 23:47:07 UTC
Permalink
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/a3e9bac8/attachment.html>
Lawson English
2012-01-28 23:47:35 UTC
Permalink
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
>
>
>
Sean P. DeNigris
2012-01-29 04:28:51 UTC
Permalink
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).

--
View this message in context: http://forum.world.st/Smalltalk-for-small-projects-only-tp4336237p4337616.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Chris Muller
2012-01-29 21:21:05 UTC
Permalink
But the point I think Lawson is making is that there has not yet been
sufficient effort by anyone other than Craig to determine, for sure,
what the exact feasibility of the Spoon system is.

A MNU is too-trivial an issue to give up on the Spoon dream, given the
potential leverage it could offer on the problem of building up from a
micro-image..

On Sat, Jan 28, 2012 at 10:28 PM, Sean P. DeNigris
<sean at clipperadams.com> wrote:
>
> 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).
>
> --
> View this message in context: http://forum.world.st/Smalltalk-for-small-projects-only-tp4336237p4337616.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
Sean P. DeNigris
2012-01-29 22:08:42 UTC
Permalink
Chris Muller-3 wrote
>
> A MNU is too-trivial an issue to give up on the Spoon dream

Obviously. I was speaking to the over simplification that
no-one-being-willing-to-give-feedback was the key impediment to a bright
future, not to Spoon's value.

--
View this message in context: http://forum.world.st/Smalltalk-for-small-projects-only-tp4336237p4339393.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stéphane Ducasse
2012-01-29 08:25:56 UTC
Permalink
+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:)
mkobetic
2012-01-29 00:38:27 UTC
Permalink
"Janko Miv?ek"<janko.mivsek at 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.
Dale Henrichs
2012-01-29 01:30:47 UTC
Permalink
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 at gmail.com
| To: "Janko Miv?ek" <janko.mivsek at eranova.si>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, "Squeak" <squeak-dev at lists.squeakfoundation.org>, Pharo-project at 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 at 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.
|
|
laurent laffont
2012-01-29 08:37:01 UTC
Permalink
200 developers on a project ? Scaring ..... They should use another
technology than Java to go under 50 developers. They will save a lot of
money :)

Laurent

2012/1/28 Janko Miv?ek <janko.mivsek at eranova.si>

> Hi guys,
>
> Ralph Johnson in his InfoQ interview made an interesting observation:
>
> 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> build something with 4-5 people what 50 people can build in Java, but if
> you take 200 people in Java ... it is really designed for small systems
> ... "
>
> Are we because of the image really destined for relatively small
> projects and small systems (of Java 50 people project size)?
>
> Are we really not able to scale to bigger projects/systems because of that?
>
> Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
>
> [1] http://www.infoq.com/interviews/johnson-armstrong-oop
>
> Best regards
> Janko
>
>
> --
> Janko Miv?ek
> Aida/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/0cf58443/attachment.html>
Dale Henrichs
2012-01-29 18:09:57 UTC
Permalink
+100 for your documentation efforts Stef!

Dale

----- Original Message -----
| From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "Pharo-project at lists.gforge.inria.fr Development" <Pharo-project at lists.gforge.inria.fr>
| Sent: Sunday, January 29, 2012 12:25:56 AM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
|
| +1
| Metacello is the way to go!
| Dale I will update the chapter as soon as you decide the new API :)
| I'm working on a nice process document for our little community. Stay
| tuned :)
|
| Stef
|
|
| > My opinion that being able to build images from scratch (easily and
| > reproducibly) is a "requirement" to get in the door for
| > mainstream projects... giving mainstream developers the
| > opportunity to work in a image-based environment will set them
| > free:)
|
|
|
laurent laffont
2012-01-29 18:45:42 UTC
Permalink
Stef efforts are amazing.

I started a course on Pharo this week. All students have their PBE. Very
important.

Laurent

On Sun, Jan 29, 2012 at 7:09 PM, Dale Henrichs <dhenrich at vmware.com> wrote:

> +100 for your documentation efforts Stef!
>
> Dale
>
> ----- Original Message -----
> | From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
> | To: "The general-purpose Squeak developers list" <
> squeak-dev at lists.squeakfoundation.org>
> | Cc: "Pharo-project at lists.gforge.inria.fr Development" <
> Pharo-project at lists.gforge.inria.fr>
> | Sent: Sunday, January 29, 2012 12:25:56 AM
> | Subject: Re: [squeak-dev] Smalltalk for small projects only?
> |
> | +1
> | Metacello is the way to go!
> | Dale I will update the chapter as soon as you decide the new API :)
> | I'm working on a nice process document for our little community. Stay
> | tuned :)
> |
> | Stef
> |
> |
> | > My opinion that being able to build images from scratch (easily and
> | > reproducibly) is a "requirement" to get in the door for
> | > mainstream projects... giving mainstream developers the
> | > opportunity to work in a image-based environment will set them
> | > free:)
> |
> |
> |
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/067ecc39/attachment.html>
Dale Henrichs
2012-01-29 18:26:19 UTC
Permalink
Sven,

I think the issue is one of mechanics

... Imagine a small system where we have 5 engineers doing 2 commits per day with an average of 4 mcz files touched per commit ... that's 40 modified mcz file per day ... 10% of the commits are aimed at a bugfix release on an earlier version of the product, 10% of the commit are aimed at adding features for the next functional release and 80% of the commits are aimed at the next incremental release ...

In this scenario a Smalltalk team would struggle. I don't think the out-of-the-box toolset can handle this (for Squeak and Pharo)...It certainly can be done in Smalltalk, but I think it would require some additional tools customization/development.

Your comment about git is right on:

"Yes, git has a bit more tools, is a bit more modern, has a lot more usage and polish"

Those things are missing from the Smalltalk toolset. The Smalltalk tool set _can_ be improved ... is being improved ... but it has fallen behind...

At some level we are competing with git more than we are competing with other languages...

Dale

----- Original Message -----
| From: "Sven Van Caekenberghe" <sven at beta9.be>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Sunday, January 29, 2012 8:02:51 AM
| Subject: Re: [Pharo-project] Smalltalk for small projects only?
|
|
| On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
|
| >> As for scale.. monticello scales well.
| >
| > No, it does not.
|
| Please elaborate: I really can't see the difference between doing a
| merge (either an easy one or a more diffucult one over multiple
| files, spread over a couple of days, with intervening changes by
| others) using either Monticello or Git.
|
| Yes, git has a bit more tools, is a bit more modern, has a lot more
| usage and polish, but fundamentally I see little difference. The
| merge will be hard in both cases. All (big) teams struggle here.
|
| BTW: try understanding git internals, let alone try contributing to
| it, with Monticello you can: it is all Smalltalk.
|
| Again, I am not saying that MC has no flaws, or that we can't or
| should learn from others and improve, far from it, but the grass in
| not greener on the other side.
|
| Sven
|
| PS: one of the things that we should take from git, as many others
| have said on this list, is selective commits.
|
Dale Henrichs
2012-01-29 19:13:46 UTC
Permalink
Steve,

I have two comments:

1. "inventing the future" doesn't happen by considering
how "ambitious" it may seem. In the end it is probably
easier than you think and harder than I think. If it was
real easy, I'd have been done by now:)

2. I propose a race:

You start working on your git backend for Smalltalk and
I'll continue working on Metacello, first one to "git work
flow" wins ... But then the real winners will be the Smalltalk
Community...

I have said this before: "I can hardly wait until someone
invents the replacement for Metacello---it will give me
more time for other projects:)"

Dale

----- Original Message -----
| From: "Steve Wart" <steve at wart.ca>
|
| The idea of building the git workflow on top of metacello strikes me
| as being somewhat ambitious.
Steve Wart
2012-01-29 19:47:34 UTC
Permalink
Hi Dale

First let me apologize for using such a horrible IT euphemism. I have been
hanging around software politicians for far too long. I think you deserve
all the credit for coming up with an elegant and effective configuration
management system that has brought many parts of the Smalltalk community
together to build common, useful and practical tools.

Regarding your race suggestion, I think you are right that having more
choices will be good for the community. I can't claim that I don't have
resources available - I can come up with a few hours a week to work on
this. I'll start with the links Frank posted, but I think the two
approaches in the end may share some common features.

I've been thinking about this idea for a long time but without feedback I
haven't had the courage to start. Maybe I can finally help.

Cheers,
Steve

On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs <dhenrich at vmware.com> wrote:

> Steve,
>
> I have two comments:
>
> 1. "inventing the future" doesn't happen by considering
> how "ambitious" it may seem. In the end it is probably
> easier than you think and harder than I think. If it was
> real easy, I'd have been done by now:)
>
> 2. I propose a race:
>
> You start working on your git backend for Smalltalk and
> I'll continue working on Metacello, first one to "git work
> flow" wins ... But then the real winners will be the Smalltalk
> Community...
>
> I have said this before: "I can hardly wait until someone
> invents the replacement for Metacello---it will give me
> more time for other projects:)"
>
> Dale
>
> ----- Original Message -----
> | From: "Steve Wart" <steve at wart.ca>
> |
> | The idea of building the git workflow on top of metacello strikes me
> | as being somewhat ambitious.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120129/d8a445ae/attachment.html>
Dale Henrichs
2012-01-29 20:24:37 UTC
Permalink
Steve,

Ah yes, the old "it's too hard to do the right thing, so let's do what we want to do" argument. Haha ... no offense taken. As you mention it is easy to fall into that trap.

While it's true that I put a lot of effort into Metacello, it isn't true that "I deserve all the credit" ... nothing happens in a vacuum, significant contributions were made by Stef, Doru, Mariano, Alexandre and others (I guess this is the season for the Academy Awards:) ... thanks, and enough of that:)

Metacello was created to address a specific set of problems that I was having while working on GLASS and those problems were being experienced by a wider group of folks than just myself and the users of GLASS, which lead to it's broad acceptance ...

With that said, I always maintain that there are "more than one way to skin a cat." And Metacello just happens to be one of the ways to skin the cat.

I've been living in the Smalltalk community for most of the last 25+ years so just I don't have the familiarity with the other configuration management systems to do a good job of integrating them into the Smalltalk development environment ...

My take is that it will be "too hard" (right back at ya:), especially for me.

To the extent that I have the time I am willing to offer you (or anyone else working in the area on alternate approaches) constructive criticism as well as advice about what I consider the "barriers to acceptance" are going to be ...

Dale

----- Original Message -----
| From: "Steve Wart" <steve at wart.ca>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, "Janko Miv?ek" <janko.mivsek at eranova.si>, Pharo-project at lists.gforge.inria.fr
| Sent: Sunday, January 29, 2012 11:47:34 AM
| Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only?
|
|
| Hi Dale
|
| First let me apologize for using such a horrible IT euphemism. I have
| been hanging around software politicians for far too long. I think
| you deserve all the credit for coming up with an elegant and
| effective configuration management system that has brought many
| parts of the Smalltalk community together to build common, useful
| and practical tools.
|
| Regarding your race suggestion, I think you are right that having
| more choices will be good for the community. I can't claim that I
| don't have resources available - I can come up with a few hours a
| week to work on this. I'll start with the links Frank posted, but I
| think the two approaches in the end may share some common features.
|
| I've been thinking about this idea for a long time but without
| feedback I haven't had the courage to start. Maybe I can finally
| help.
|
| Cheers,
| Steve
|
|
| On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs < dhenrich at vmware.com
| > wrote:
|
|
| Steve,
|
| I have two comments:
|
| 1. "inventing the future" doesn't happen by considering
| how "ambitious" it may seem. In the end it is probably
| easier than you think and harder than I think. If it was
| real easy, I'd have been done by now:)
|
| 2. I propose a race:
|
| You start working on your git backend for Smalltalk and
| I'll continue working on Metacello, first one to "git work
| flow" wins ... But then the real winners will be the Smalltalk
| Community...
|
| I have said this before: "I can hardly wait until someone
| invents the replacement for Metacello---it will give me
| more time for other projects:)"
|
|
| Dale
|
| ----- Original Message -----
|
|
| | From: "Steve Wart" < steve at wart.ca >
| |
| | The idea of building the git workflow on top of metacello strikes
| | me
| | as being somewhat ambitious.
|
|
|
|
|
Otto Behrens
2012-01-29 22:03:42 UTC
Permalink
Hi,

We've built a little package that allows us to save all our source in
git. We've been developing with this for 3 months now, and it's pretty
stable. I put a project on github,
https://github.com/finworks/smallsource that contains some more info
on it. Yes, there's more work to do, but there's hope. The repo
contains some examples that I just saved from the image.

In short, we save and load all the monticello packages on our project
as smalltalk source files. We use git to merge and not monticello. We
use metacello, but watered down to essentially just dependencies.

I just want to say thanks to all you people who put in such great
effort into Smalltalk. We are using Smalltalk to create a business and
are slowly getting somewhere.

We've been using git for about 3 years now. This came from a need to
manage files, such as scripts, resources (images and stuff), documents
and recorded selenium (ide) tests with smalltalk code. So, we just
whacked all of this, including our monticello packages into the git
repo.

As you can imagine, storing binary files in a git repo, especially
fairly large packages and lots of integrations / merges / versions,
grew the git repo quite a bit. We also needed to clone the git repo
all over. So we decided to give it a shot and write to files.

It took about 2 weeks to get going and another to sort out some pain,
but the package in the smallsource repo have not changed for 3 months.

We are 5-6 developers on the project, committing numerous times a day.
We currently have about 1100 classes (find repo -type d | wc -l gives
us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
gives us 23545) managed in this way.

I'm keen to talk about how we can really "do the right thing" and
solve this source code management monster. I know this approach needs
work (I'll list some issues on the project, that I think needs
attention) and I also realise that there could be better approaches.

Here's another idea: we can map class definitions and method
definitions directly to git objects. Git has a great object model
which will allow us to directly track the complete history of a method
or class definition, with commit details and what not. In a sense, I
feel that a tight integration between a smalltalk environment and git
will be a fantastic solution - something like envy, but on git, with
all the fanciness that comes with git!

The only problem with this is a very tight coupling with git. Do we want that?

Thanks again
Otto
Sven Van Caekenberghe
2012-01-29 22:09:44 UTC
Permalink
Otto,

On 29 Jan 2012, at 23:03, Otto Behrens wrote:

> Hi,
>
> We've built a little package that allows us to save all our source in
> git. We've been developing with this for 3 months now, and it's pretty
> stable. I put a project on github,
> https://github.com/finworks/smallsource that contains some more info
> on it. Yes, there's more work to do, but there's hope. The repo
> contains some examples that I just saved from the image.
>
> In short, we save and load all the monticello packages on our project
> as smalltalk source files. We use git to merge and not monticello. We
> use metacello, but watered down to essentially just dependencies.
>
> I just want to say thanks to all you people who put in such great
> effort into Smalltalk. We are using Smalltalk to create a business and
> are slowly getting somewhere.
>
> We've been using git for about 3 years now. This came from a need to
> manage files, such as scripts, resources (images and stuff), documents
> and recorded selenium (ide) tests with smalltalk code. So, we just
> whacked all of this, including our monticello packages into the git
> repo.
>
> As you can imagine, storing binary files in a git repo, especially
> fairly large packages and lots of integrations / merges / versions,
> grew the git repo quite a bit. We also needed to clone the git repo
> all over. So we decided to give it a shot and write to files.
>
> It took about 2 weeks to get going and another to sort out some pain,
> but the package in the smallsource repo have not changed for 3 months.
>
> We are 5-6 developers on the project, committing numerous times a day.
> We currently have about 1100 classes (find repo -type d | wc -l gives
> us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
> gives us 23545) managed in this way.
>
> I'm keen to talk about how we can really "do the right thing" and
> solve this source code management monster. I know this approach needs
> work (I'll list some issues on the project, that I think needs
> attention) and I also realise that there could be better approaches.
>
> Here's another idea: we can map class definitions and method
> definitions directly to git objects. Git has a great object model
> which will allow us to directly track the complete history of a method
> or class definition, with commit details and what not. In a sense, I
> feel that a tight integration between a smalltalk environment and git
> will be a fantastic solution - something like envy, but on git, with
> all the fanciness that comes with git!
>
> The only problem with this is a very tight coupling with git. Do we want that?
>
> Thanks again
> Otto

This sounds very interesting/promising !

Do you have a writeup/article describing your approach ?

First question: does your system deal with packages as we know them, with extensions ?

Sven
Otto Behrens
2012-01-29 22:12:37 UTC
Permalink
> Do you have a writeup/article describing your approach ?

Some stuff in the README on the
https://github.com/finworks/smallsource. Let me know what you need.
I'm writing more as we speak... :-)

> First question: does your system deal with packages as we know them, with extensions ?

Yes, with extensions. Have not tried traits though.
Sven Van Caekenberghe
2012-01-29 22:24:14 UTC
Permalink
Otto,

On 29 Jan 2012, at 23:12, Otto Behrens wrote:

> Some stuff in the README on the
> https://github.com/finworks/smallsource. Let me know what you need.
> I'm writing more as we speak... :-)

How can one try this out ?
What to load/install ?

Thx,

Sven
Otto Behrens
2012-01-29 22:46:00 UTC
Permalink
> How can one try this out ?
> What to load/install ?

I added something in the README:

To use it, take a Pharo-1.3 image and just load MonticelloFileTree.
Open a monticello browser and select a package. +Repository has a new
menu item called "file tree"; select any directory on your PC. Save
the package there. You should see a directory <package name>.tree in
the directory after you saved. The GemStone-Extensions package
contains the gemstone hacks to make it work in GLASS.

HTH
Otto Behrens
2012-01-29 23:00:14 UTC
Permalink
Oh, and make some changes in a file (method). Change the timestamp in
the file to be more recent. Load the package. The change should be in
your image.

On Mon, Jan 30, 2012 at 12:46 AM, Otto Behrens <otto at finworks.biz> wrote:
>> How can one try this out ?
>> What to load/install ?
>
> I added something in the README:
>
> To use it, take a Pharo-1.3 image and just load MonticelloFileTree.
> Open a monticello browser and select a package. +Repository has a new
> menu item called "file tree"; select any directory on your PC. Save
> the package there. You should see a directory <package name>.tree in
> the directory after you saved. The GemStone-Extensions package
> contains the gemstone hacks to make it work in GLASS.
>
> HTH
Göran Krampe
2012-01-29 23:43:54 UTC
Permalink
Hi all!

I held a presentation regarding SCM in general a few weeks back as part
of a course and in that presentation I try to end it with a view ahead
about what is the Next Step for SCM. So let me go "dreaming" here for a
minute. :)

As many in this thread has correctly identified the main "issue" with
SCM is that when several developers work on the *same* codebase in
parallell it gets hairy, no matter which tool you use. Most open source
projects actually do *not* do that, we normally work on smallish
*different* packages or just a few people on the same package - so we
normally don't get to feel the real *hurt* that a large commercial
project often does. At least that is my perception.

Yes, MC and git are great. Darcs is in some respects even greater in
this particular area (merging, cherry picking etc). But these tools do
not capture what I like to call "developer intent" very good.

git and Darcs etc just manage files, they don't even know what language
we are using. Darcs has something in the "right direction" and that is
the token replace change, which is a small step towards "smarter change
types".

MC knows it is Smalltalk source it is dealing with, but doesn't really
use that knowledge as much as it could.

Deltas that I started working with (and came quite far with the help of
Matthew Fulmer and a few others) goes a few steps further. A Delta
distinguishes developer intent in greater detail than MC and could
potentially be "smarter" because of that.

And this is where the general future of SCM lies I think, in two areas:

- Making SCM tools aware of developer intent. If I use RB to do a
refactoring for example, why not *record that* and not just record the
effects of the recactoring on the source code? If I rename a method in a
class, and fix all senders of it, why not record it as a *method
rename*? That way, if it is merged into another environment it can be
handled much smarter and we could for example fix even more senders.

- Real time collaboration. If we can sit in a shared (in some controlled
fashion) development environment in some kind of real time model, then
lots of merging and conflicts would just say PUFF and go up in smoke. We
are beginning to see this now with the new IDEs running "on the web"
because suddenly it gets very natural to experiment in that direction.

regards, G?ran
Janko Mivšek
2012-01-31 13:12:34 UTC
Permalink
Hi guys,

This idea about realtime non-invasive notifications of others activity
in the group is actually interesting and quite close what we are seeing
in realtime web apps recently. I namelly see the Facebook-like business
collaboration as a growing trend and one of more interesting innovations
there is how to get notified without being disturbed, non-invasive
therefore. I think we can copy some ideas from there to our tools too.

Janko


S, G?ran Krampe pi?e:

>>> - Real time collaboration. If we can sit in a shared (in some
>>> controlled fashion) development environment in some kind
>>> of real time model, then lots of merging and conflicts would just say
>>> PUFF and go up in smoke. We are beginning to see
>>> this now with the new IDEs running "on the web" because suddenly it
>>> gets very natural to experiment in that direction.

>> Real-time collaboration in the sense of getting code updates from
>> other developers immediatedly is probably not very
>> helpful, as it would distract a lot.

> Code changes is one thing you probably want to *control* (which is why I
> wrote "in some controlled fashion") but some examples of stuff you
> really would like to get "immediately" are:
>
> - Developer X is modifying "your" code. No, not committed yet - but
> perhaps you should talk to X :)
>
> - Visual queue/notification that developer X just managed to break your
> unit tests
>
> - Developer X is right now writing new code that references classes that
> you in turn have modified in your uncommitted code... or sending
> messages whose implementations you in turn have modified in your
> uncommitted code.
>
> ...and so on, there are numerous "tell tales" that there will be
> interesting issues down the road - and these signals could be exposed to
> the developers in various ways. Open your mind - it is not all about
> sharing commits of code :)




--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
Stéphane Ducasse
2012-01-30 10:46:45 UTC
Permalink
Hi otto

how to you deal with conflict due to the for example move of methods due to file out?

Stef



> Hi,
>
> We've built a little package that allows us to save all our source in
> git. We've been developing with this for 3 months now, and it's pretty
> stable. I put a project on github,
> https://github.com/finworks/smallsource that contains some more info
> on it. Yes, there's more work to do, but there's hope. The repo
> contains some examples that I just saved from the image.
>
> In short, we save and load all the monticello packages on our project
> as smalltalk source files. We use git to merge and not monticello. We
> use metacello, but watered down to essentially just dependencies.
>
> I just want to say thanks to all you people who put in such great
> effort into Smalltalk. We are using Smalltalk to create a business and
> are slowly getting somewhere.
>
> We've been using git for about 3 years now. This came from a need to
> manage files, such as scripts, resources (images and stuff), documents
> and recorded selenium (ide) tests with smalltalk code. So, we just
> whacked all of this, including our monticello packages into the git
> repo.
>
> As you can imagine, storing binary files in a git repo, especially
> fairly large packages and lots of integrations / merges / versions,
> grew the git repo quite a bit. We also needed to clone the git repo
> all over. So we decided to give it a shot and write to files.
>
> It took about 2 weeks to get going and another to sort out some pain,
> but the package in the smallsource repo have not changed for 3 months.
>
> We are 5-6 developers on the project, committing numerous times a day.
> We currently have about 1100 classes (find repo -type d | wc -l gives
> us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
> gives us 23545) managed in this way.
>
> I'm keen to talk about how we can really "do the right thing" and
> solve this source code management monster. I know this approach needs
> work (I'll list some issues on the project, that I think needs
> attention) and I also realise that there could be better approaches.
>
> Here's another idea: we can map class definitions and method
> definitions directly to git objects. Git has a great object model
> which will allow us to directly track the complete history of a method
> or class definition, with commit details and what not. In a sense, I
> feel that a tight integration between a smalltalk environment and git
> will be a fantastic solution - something like envy, but on git, with
> all the fanciness that comes with git!
>
> The only problem with this is a very tight coupling with git. Do we want that?
>
> Thanks again
> Otto
>
Otto Behrens
2012-01-30 11:40:02 UTC
Permalink
Hi,

> how to you deal with conflict due to the for example move of methods due to file out?

If someone edited a method that I moved to another class git picks it
up and does not see a conflict, it includes the change on the new
class. If both of us changed the method and I moved it, then git picks
up a conflict and I have to edit the file. If the method was renamed
by me and edited by someone else, it does not pick up a conflict, it
sees it as a delete and modify conflict.

I am sometimes quite amazed how it picks up what happened, but it
does; we have not had problems that are in the way. I think it has to
do with the nice object model git has, as well as the fact that it
does not store deltas, but objects indexed by hashes.

Cheers
Otto
Stéphane Ducasse
2012-01-30 16:30:18 UTC
Permalink
On Jan 30, 2012, at 12:40 PM, Otto Behrens wrote:

> Hi,
>
>> how to you deal with conflict due to the for example move of methods due to file out?
>
> If someone edited a method that I moved to another class git picks it
> up and does not see a conflict, it includes the change on the new
> class. If both of us changed the method and I moved it, then git picks
> up a conflict and I have to edit the file. If the method was renamed
> by me and edited by someone else, it does not pick up a conflict, it
> sees it as a delete and modify conflict.
>
> I am sometimes quite amazed how it picks up what happened, but it
> does; we have not had problems that are in the way. I think it has to
> do with the nice object model git has, as well as the fact that it
> does not store deltas, but objects indexed by hashes.

ok I understand non textual handling would help for that.
With svn of textual? this could be another story.
>
> Cheers
> Otto
>
Damien Pollet
2012-01-31 12:50:43 UTC
Permalink
On 29 January 2012 23:03, Otto Behrens <otto at finworks.biz> wrote:
> Here's another idea: we can map class definitions and method
> definitions directly to git objects. Git has a great object model
> which will allow us to directly track the complete history of a method
> or class definition, with commit details and what not.

You mean having the class definition in a blob of its own?
>From what I see, that's already kinda what you're doing, except you
have the class comment in there as well?


--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Otto Behrens
2012-01-31 14:59:28 UTC
Permalink
Hi,

> You mean having the class definition in a blob of its own?
> From what I see, that's already kinda what you're doing, except you
> have the class comment in there as well?

Yes, essentially we have that. Would like to clean it up by only
having what's necessary in there.

I was wondering more if it is possible to do without having a file
system checkout of the class definition. In other words, if the class
definition in the image could serve as the working copy of the object
in the git repository. I must read more on what the other guys did
with the git interfaces (such as gitfs and gitosis) to understand what
it comes down to.

If this is possible, it would make merging, loading and committing
essentially one step.

The disadvantage could be a tight coupling with git.

Otto
Damien Pollet
2012-02-01 14:44:37 UTC
Permalink
On 31 January 2012 15:59, Otto Behrens <otto at finworks.biz> wrote:
> I was wondering more if it is possible to do without having a file
> system checkout of the class definition. In other words, if the class
> definition in the image could serve as the working copy of the object
> in the git repository. I must read more on what the other guys did
> with the git interfaces (such as gitfs and gitosis) to understand what
> it comes down to.
>
> If this is possible, it would make merging, loading and committing
> essentially one step.

Have you seen what Camillo did?
http://www.squeaksource.com/FSGit
https://github.com/dh83/fs-git-test

Note the layout with class comment in a README file, etc :)

There is a also nearly working implementation of the git network
protocol (stubbed using the git binaries ATM).


> The disadvantage could be a tight coupling with git.

is that really a disadvantage, compared to a tight coupling with monticello?


--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Frank Shearar
2012-02-01 15:12:31 UTC
Permalink
On 1 February 2012 14:44, Damien Pollet <damien.pollet at gmail.com> wrote:
> On 31 January 2012 15:59, Otto Behrens <otto at finworks.biz> wrote:
>> I was wondering more if it is possible to do without having a file
>> system checkout of the class definition. In other words, if the class
>> definition in the image could serve as the working copy of the object
>> in the git repository. I must read more on what the other guys did
>> with the git interfaces (such as gitfs and gitosis) to understand what
>> it comes down to.
>>
>> If this is possible, it would make merging, loading and committing
>> essentially one step.
>
> Have you seen what Camillo did?
> http://www.squeaksource.com/FSGit
> https://github.com/dh83/fs-git-test
>
> Note the layout with class comment in a README file, etc :)

That is _exactly_ the right thing to do! Bravo, Camillo! Also note how
Nested-Package-Names end up looking like you might expect.

Is there any necessity for storing a chunk? For instance in
https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side/as%20yet%20unclassified/a.st
we have

!AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni 1/23/2012 19:15'!
a
| a |
^ a! !

with the ugly chunk !s. The only thing we can't directly regenerate is
the timestamp: modulo that, we know the class name, the category (the
name of the directory you're in), the author (from the author of the
git commit). You'd have a disconnect between the git commit time and
the time in the chunk which would, IIRC, be the time you hit Alt-S in
your browser? Or would that be file-out time, which would likely then
be the timestamp in the git commit?

> There is a also nearly working implementation of the git network
> protocol (stubbed using the git binaries ATM).
>
>
>> The disadvantage could be a tight coupling with git.
>
> is that really a disadvantage, compared to a tight coupling with monticello?

With the added advantage of the git ecosystem thrown in for free - git
hosting, rss feeds on git repositories, and a host of other things
that would not need to be reinvented for Smalltalk. Letting us, to get
to the punchline, do _more interesting work_.

frank

>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
Igor Stasenko
2012-02-01 15:20:12 UTC
Permalink
On 1 February 2012 16:12, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 1 February 2012 14:44, Damien Pollet <damien.pollet at gmail.com> wrote:
>> On 31 January 2012 15:59, Otto Behrens <otto at finworks.biz> wrote:
>>> I was wondering more if it is possible to do without having a file
>>> system checkout of the class definition. In other words, if the class
>>> definition in the image could serve as the working copy of the object
>>> in the git repository. I must read more on what the other guys did
>>> with the git interfaces (such as gitfs and gitosis) to understand what
>>> it comes down to.
>>>
>>> If this is possible, it would make merging, loading and committing
>>> essentially one step.
>>
>> Have you seen what Camillo did?
>> http://www.squeaksource.com/FSGit
>> https://github.com/dh83/fs-git-test
>>
>> Note the layout with class comment in a README file, etc :)
>
> That is _exactly_ the right thing to do! Bravo, Camillo! Also note how
> Nested-Package-Names end up looking like you might expect.
>
> Is there any necessity for storing a chunk? For instance in
> https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side/as%20yet%20unclassified/a.st
> we have
>
> !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni 1/23/2012 19:15'!
> a
> ? ? ? ?| a |
> ? ? ? ?^ a! !
>
> with the ugly chunk !s. The only thing we can't directly regenerate is
> the timestamp: modulo that, we know the class name, the category (the
> name of the directory you're in), the author (from the author of the
> git commit). You'd have a disconnect between the git commit time and
> the time in the chunk which would, IIRC, be the time you hit Alt-S in
> your browser? Or would that be file-out time, which would likely then
> be the timestamp in the git commit?
>

Good question, Frank.
But i want to go even further by saying:
why we cannot associate an arbitrary meta-information per method and
store it along with method?

Today we storing the category, author and stamp.
Tomorrow we may want to add something more (link to documentation,
link to previous version etc etc)
And i think , at least in GitFS Camillo can do it pretty easy.
If you have 1 file per method, make 2 files per method, i.e.:

methodname.st
methodname.meta

and in meta, we can store everything we want in a form we want. while
.st is for storing purely smalltalk source code, and nothing else.

--
Best regards,
Igor Stasenko.
Dale Henrichs
2012-01-30 17:33:44 UTC
Permalink
Otto,

This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that..

I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go...

Dale

----- Original Message -----
| From: "Otto Behrens" <otto at finworks.biz>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Sunday, January 29, 2012 2:03:42 PM
| Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
|
| Hi,
|
| We've built a little package that allows us to save all our source in
| git. We've been developing with this for 3 months now, and it's
| pretty
| stable. I put a project on github,
| https://github.com/finworks/smallsource that contains some more info
| on it. Yes, there's more work to do, but there's hope. The repo
| contains some examples that I just saved from the image.
|
| In short, we save and load all the monticello packages on our project
| as smalltalk source files. We use git to merge and not monticello. We
| use metacello, but watered down to essentially just dependencies.
|
| I just want to say thanks to all you people who put in such great
| effort into Smalltalk. We are using Smalltalk to create a business
| and
| are slowly getting somewhere.
|
| We've been using git for about 3 years now. This came from a need to
| manage files, such as scripts, resources (images and stuff),
| documents
| and recorded selenium (ide) tests with smalltalk code. So, we just
| whacked all of this, including our monticello packages into the git
| repo.
|
| As you can imagine, storing binary files in a git repo, especially
| fairly large packages and lots of integrations / merges / versions,
| grew the git repo quite a bit. We also needed to clone the git repo
| all over. So we decided to give it a shot and write to files.
|
| It took about 2 weeks to get going and another to sort out some pain,
| but the package in the smallsource repo have not changed for 3
| months.
|
| We are 5-6 developers on the project, committing numerous times a
| day.
| We currently have about 1100 classes (find repo -type d | wc -l
| gives
| us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
| gives us 23545) managed in this way.
|
| I'm keen to talk about how we can really "do the right thing" and
| solve this source code management monster. I know this approach needs
| work (I'll list some issues on the project, that I think needs
| attention) and I also realise that there could be better approaches.
|
| Here's another idea: we can map class definitions and method
| definitions directly to git objects. Git has a great object model
| which will allow us to directly track the complete history of a
| method
| or class definition, with commit details and what not. In a sense, I
| feel that a tight integration between a smalltalk environment and git
| will be a fantastic solution - something like envy, but on git, with
| all the fanciness that comes with git!
|
| The only problem with this is a very tight coupling with git. Do we
| want that?
|
| Thanks again
| Otto
|
|
Janko Mivšek
2012-01-30 18:07:46 UTC
Permalink
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:
> Otto,
>
> This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that..
>
> I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go...
>
> Dale
>
> ----- Original Message -----
> | From: "Otto Behrens" <otto at finworks.biz>
> | To: Pharo-project at lists.gforge.inria.fr
> | Sent: Sunday, January 29, 2012 2:03:42 PM
> | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
> |
> | Hi,
> |
> | We've built a little package that allows us to save all our source in
> | git. We've been developing with this for 3 months now, and it's
> | pretty
> | stable. I put a project on github,
> | https://github.com/finworks/smallsource that contains some more info
> | on it. Yes, there's more work to do, but there's hope. The repo
> | contains some examples that I just saved from the image.
> |
> | In short, we save and load all the monticello packages on our project
> | as smalltalk source files. We use git to merge and not monticello. We
> | use metacello, but watered down to essentially just dependencies.
> |
> | I just want to say thanks to all you people who put in such great
> | effort into Smalltalk. We are using Smalltalk to create a business
> | and
> | are slowly getting somewhere.
> |
> | We've been using git for about 3 years now. This came from a need to
> | manage files, such as scripts, resources (images and stuff),
> | documents
> | and recorded selenium (ide) tests with smalltalk code. So, we just
> | whacked all of this, including our monticello packages into the git
> | repo.
> |
> | As you can imagine, storing binary files in a git repo, especially
> | fairly large packages and lots of integrations / merges / versions,
> | grew the git repo quite a bit. We also needed to clone the git repo
> | all over. So we decided to give it a shot and write to files.
> |
> | It took about 2 weeks to get going and another to sort out some pain,
> | but the package in the smallsource repo have not changed for 3
> | months.
> |
> | We are 5-6 developers on the project, committing numerous times a
> | day.
> | We currently have about 1100 classes (find repo -type d | wc -l
> | gives
> | us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
> | gives us 23545) managed in this way.
> |
> | I'm keen to talk about how we can really "do the right thing" and
> | solve this source code management monster. I know this approach needs
> | work (I'll list some issues on the project, that I think needs
> | attention) and I also realise that there could be better approaches.
> |
> | Here's another idea: we can map class definitions and method
> | definitions directly to git objects. Git has a great object model
> | which will allow us to directly track the complete history of a
> | method
> | or class definition, with commit details and what not. In a sense, I
> | feel that a tight integration between a smalltalk environment and git
> | will be a fantastic solution - something like envy, but on git, with
> | all the fanciness that comes with git!
> |
> | The only problem with this is a very tight coupling with git. Do we
> | want that?
> |
> | Thanks again
> | Otto
> |
> |
>
>

--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
Janko Mivšek
2012-01-30 21:19:35 UTC
Permalink
-------- Prvotno sporo?ilo --------
Zadeva: Re: [vwnc] Smalltalk for small projects only?
Datum: Mon, 30 Jan 2012 19:27:31 +0000
Od: Niall Ross <niallfr at btinternet.com>

Dear Janko,
(tried to send this to Pharo and squeak mailing lists as well as
well as vwnc and you - got a hiccough; trying again just to vwnc and you).

The largest Smalltalk project I've experienced was Kapital. They were
approaching 70 developers in 4 locations in 2005 and IIUC are larger
now. They use an in-house process based on Envy. Frequent rebuilding
of images is forced by aging of Envy repositories, properly committed
stuff being copied over. Thus developers are obliged to use correct
process or lose code. I described the process briefly in a secondary
talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent
info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A
developer I knew there had practical experience of a rival's attempt to
replicate their achievement in Java, using comparable resources, that
crashed and burned.

I've worked in two teams of 15 - 20 developers (one on a single site,
one at two sites), each of which were verifiably matching systems
maintained by ~100 developers in rivals. These were both in the
insurance domain. In one of these, Envy-based, each developer rebuilt
their image each day - the process took quite a few minutes but was
valuable. In the other, images were eternal (yes, I do mean that!); it
would take a long time to describe their process and even longer to
convince readers that, contrary to what I at first thought and what most
of you will think, it was a viable development process.

All the other Smalltalk teams I've worked in, prior to coming to Cincom,
were in single figures and used Store or Envy. One of them was
verifiably rivalling a sytem of 10s of people in another language.

Conclusions:

1) As your Smalltalk project gets large, you will need to put process
and tools in place on top of what Envy, or Store, or, as Dale says,
Monticello and Metacello, give you out-of-the-box at the moment. (It is
news to me if Java projects of 200 people do not find the same, but I
defer to those with more - which means any - experience of being in a
200-person Java project to correct me if that is not so - or is less so
in some important respect.)

It would be good if Smalltalk projects that find themselves growing into
this area could get a tool/add-on that conveyed existing experience and
solutions instead of having to re-roll their own superstructure on
existing tools. (In Cincom, we are attempting to use our own
development-process and build-process-improvement work to achieve this.)

2) Combining Kapital experience with the ratio one can justify between
'Smalltalk developers needed to do' and 'Java developers needed to do',
persuades me that there is no limit on the complexity of problem
Smalltalk can attack relative to its rivals.

3) I agree with Dale that making the minumum image smaller is the way to
go. (Again, we wish to do this in VW; as always, such efforts progress
slowly in background while we meet immediate requirements.)

Yours faithfully
Niall Ross


--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
Janko Mivšek
2012-01-31 18:17:58 UTC
Permalink
-------- Prvotno sporo?ilo --------
Datum: Tue, 31 Jan 2012 10:07:34 -0800
Od: Jon Paynter <kittle31 at gmail.com>

> Dear Niall,
> Thanks for comprehensive report, the biggest project reported so far.
> I forwarded it to Squeak and Pharo mailing lists.
> Has anyone data for other big Smalltalk projects/systems, like OOCL
> etc?

OOCL has 2 smalltalk projects
The small one with 2,200 classes and 2 developers

The larger one ranged from 20-50 developers (my guess), and currently
has 24,000 classes. And the last time it was measured (a few years ago)
we had around 8million lines of code.


And my own personal $0.02 on productivity:
One place I worked at as a contractor was a java shop. I was just
learning java, so my skills at that time were lousy. We had a small
project to do, and I managed to get 2 weeks of time from the local java
expert. She came highly recommended by everyone, and after watching her
work, she was in deed VERY good. After 2 weeks of struggle, we failed
to finish the project.
Afterwards, I sat down and did the project in visualworks ( from
scratch) in 1 day.

Experience matters, but using the right tool for the job is where its at.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pripet del sporo?ila
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120131/ef873fff/attachment.ksh>
Janko Mivšek
2012-01-31 18:19:52 UTC
Permalink
-------- Prvotno sporo?ilo --------
Datum: Tue, 31 Jan 2012 07:54:58 -0600
Od: Peter Hunsberger <peter.hunsberger at gmail.com>


With all due respect to the experience of everyone here, people really
need to give up on this naive belief that Smalltalk development is any
more efficient than development in any other language. The simple fact
is that within the Smalltalk community a large portion of the developers
have been using the tools for a long time and are very good at using
them. Throw them at another environment and they are not as efficient.
However, if you take new developers and throw them at a Smalltalk
project it takes longer to get them up to speed than throwing them at a
Java project simply because of the fact that Smalltalk is not
as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so
I've seen both sides of this issue for a long time, so let me related
some anecdotal experience:

I'm currently working on a Smalltalk project that has about about 50 man
years of effort in it over 10 years. Prior to this I worked on a Java
and XSLt project that had about the same effort over the same period.
Both have web based GUI's with a fair amount of JavaScript and the
usual HTML crud and use a relational DB back end (SQL server and Oracle
respectively). The Smalltalk project has had a mix of very experienced
Smalltalk developers and inexperienced ones. The Java project was
mainly junior and intermediate experience devs. I'd say the overall
architecture and design was about equivalent; very different, but
equally well done and comprehensive. The projects are very similar in
concept and execution. The Java project had about twice as many
function points (some pretty major) implemented and four times as many
use cases supported at the point I switched to the Smalltalk project.
For the most part this has little to do with the language itself.
Rather, it is mainly, the supporting infrastructure that one is able to
draw on in Java projects and this includes Eclipse, Git, etc. Open
Source projects also played a big part of this, in the Java world one
can pull in large chunks of functionality at very low cost (eg. XSLt 2.0
processors and pipelines, Spring, Hadoop, you name it) that are just not
quite matched in the Smalltalk world. You can often get close, but it
seems that there is always something missing, if only because the teams
supporting the Smalltalk projects are often much smaller and just can't
quite keep up with the every changing specs and requirements.

Bottom line, don't kid yourself that there is any inherent advantage in
using Smalltalk development over any other language. It is faster for
experienced devs in small projects, but if you've got to pull a team
together from scratch for some medium to large complexity enterprise
scale project it is probably not going to fair as well.

Now onto the main question posed here....

I have also worked on a successful 200 man year project (C and C++ in
this case), which broke down to a little less than 100 people over a
little more than 2 years. This was in the telecom world and involved
many main frame billing interfaces and switching equipment interfaces,
all very mission critical. In this case about 60% of the team was heads
down developers. The rest of it was dedicated testers, tech writers,
business analysts, project managers and managers. Here again the
supporting infrastructure played an important role. Business analysts
could write up use cases that got stored in a repository (a proprietary
system) that could be used to generate test case stubs and documentation
stubs. The development team tracked progress and bug reports in the
same repository and source code version control was tied to the
repository. End user documentation was stored in the repository and
version controlled. It was simple to know what was going on anywhere in
the project and to know where the problems were and what code did what
and to see the entire life cycle of any portion of the code base from
customer requirement to final deliverable. I know of no
support infrastructure that even comes close in the Smalltalk world and
would consider it madness to even consider taking on such a project
using Smalltalk.

Peter Hunsberger


On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont
<laurent.laffont at gmail.com <mailto:laurent.laffont at gmail.com>> wrote:

200 developers on a project ? Scaring ..... They should use another
technology than Java to go under 50 developers. They will save a lot
of money :)

Laurent


2012/1/28 Janko Miv?ek <janko.mivsek at eranova.si
<mailto:janko.mivsek at eranova.si>>

Hi guys,

Ralph Johnson in his InfoQ interview made an interesting
observation:

2:55 minute: "Smalltalk made an fundamental error ... image ...
you can
build something with 4-5 people what 50 people can build in
Java, but if
you take 200 people in Java ... it is really designed for small
systems
... "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems
because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pripet del sporo?ila
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120131/f76e3253/attachment.ksh>
Dale Henrichs
2012-02-01 18:45:13 UTC
Permalink
I haven't completely grokked the entire FSGit experience, however the piece that has intrigued me with the filetree repository that Otto has done is the fusion between monticello and "git" (technically filetree doesn't depend upon git, it just stores monticello package information in a structured directory tree). So filetree can be used as the basis for integrating any file-based SCM into Smalltalk...personally I will focus on git...

Basically, I have taken myself up on the challenge to provide a git workflow experience for Smalltalk:) and my approach is to create a fusion of Monticello, Metacello, and git...

For an alternate SCM to get traction within the community, I think that there needs to be easy migration between this alternate approach and Monticello and for me filetree was the missing piece ...

If you want to see what I am currently up to, take a look at the metacello project on github[1]. Take a look at the network view[2] of the project. I've pushed the Metacello code for 1.0-beta.31[6] (the latest release) into the repository using filetree[3], essentially a fork of Otto's smallsource project[4]. I've also pushed the code for my current work-in-progress for 1.0-beta.32[5]. Finally I created the MetacelloGitProject[7] branch for the project, where I have started doing development (one must eat their own dog food!) using github as the sole repository for my code (other than local clones on my work desktop machine and my home laptop). You can look at one of my commits[8] from last night where you can see a nice difference view that actually involves changes to 4 monticello packages ...

I do a fair amount of the actual loading manually as I'm still trying to get a feel for using git in development...FSGit looks very interesting as well, if we are going to use git, then having a Smalltalk interface to git is a requirement ... filetree is SCM neutral, but I am building an extension of filetree that is aimed at git (in git, the repository is versioned not the individual files, so it is an interesting challenge to integrate into Monticello).

I am very encouraged that the fusion of Monticello, Metacello and git is coming together pretty nicely (i.e., without tons of work)...this is very early work, so I don't recommend anyone actually try to use the project (it is only 2 days old:) as there is a fair amount of hand holding that I have to do right now ...

However, if you are interested in contributing then I encourage you to fork the metacello project on github[1] and get busy. I will report progress and solicit feedback in general on the metacello mailing list[9], but if there is interest in collaborating we'll just use github for the nitty gritty communication.

Dale

[1] https://github.com/dalehenrich/metacello
[2] https://github.com/dalehenrich/metacello/network
[3] https://github.com/dalehenrich/filetree
[4] https://github.com/finworks/smallsource
[5] https://github.com/dalehenrich/metacello/tree/1.0-beta.32
[6] https://github.com/dalehenrich/metacello/tree/1.0-beta.31
[7] https://github.com/dalehenrich/metacello/tree/MetacelloGitProject
[8] https://github.com/dalehenrich/metacello/commit/b79df4a2cd63200a8a1712fe629dbcc8c6d0a3a7
[9] http://groups.google.com/group/metacello
----- Original Message -----
| From: "Damien Pollet" <damien.pollet at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr, "Bruni camillo" <camillobruni at gmail.com>
| Sent: Wednesday, February 1, 2012 6:44:37 AM
| Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
|
| On 31 January 2012 15:59, Otto Behrens <otto at finworks.biz> wrote:
| > I was wondering more if it is possible to do without having a file
| > system checkout of the class definition. In other words, if the
| > class
| > definition in the image could serve as the working copy of the
| > object
| > in the git repository. I must read more on what the other guys did
| > with the git interfaces (such as gitfs and gitosis) to understand
| > what
| > it comes down to.
| >
| > If this is possible, it would make merging, loading and committing
| > essentially one step.
|
| Have you seen what Camillo did?
| http://www.squeaksource.com/FSGit
| https://github.com/dh83/fs-git-test
|
| Note the layout with class comment in a README file, etc :)
|
| There is a also nearly working implementation of the git network
| protocol (stubbed using the git binaries ATM).
|
|
| > The disadvantage could be a tight coupling with git.
|
| is that really a disadvantage, compared to a tight coupling with
| monticello?
|
|
| --
| Damien Pollet
| type less, do more [ | ] http://people.untyped.org/damien.pollet
|
|
Stefan Marr
2012-02-01 19:02:16 UTC
Permalink
On 01 Feb 2012, at 19:45, Dale Henrichs wrote:

> I haven't completely grokked the entire FSGit experience, however the piece that has intrigued me with the filetree repository that Otto has done is the fusion between monticello and "git" (technically filetree doesn't depend upon git, it just stores monticello package information in a structured directory tree). So filetree can be used as the basis for integrating any file-based SCM into Smalltalk...personally I will focus on git...
>
> Basically, I have taken myself up on the challenge to provide a git workflow experience for Smalltalk:) and my approach is to create a fusion of Monticello, Metacello, and git...

Cool!

Camillo, did you plan be in Brussels on Saturday for the sprint? Would that be something to pair on for a few hours?

Best regards
Stefan



--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
Dale Henrichs
2012-02-01 18:51:27 UTC
Permalink
Igor,

Otto's filetree stores monticello package meta data in the repository as well ... the basic model is to store the Monticello meta data ... having spent the last two days developing with filetree I have noticed an interesting side effect of storing meta data and source ... when you merge (using the git level merge) you end up having to resolve conflicts in the meta data and the source code ... I assume that this is a solvable problem (maybe even git has an answer?), but it is worth considering ...

Another thing to consider with meta data is that with a file-based system folks will very likely do edits to the source files directly including potentially the meta data files .... like a said, maybe git has a way to hide meta data files from mere mortals, but if not one must be a bit careful...

Dale

----- Original Message -----
| From: "Igor Stasenko" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Wednesday, February 1, 2012 7:20:12 AM
| Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
|
| On 1 February 2012 16:12, Frank Shearar <frank.shearar at gmail.com>
| wrote:
| > On 1 February 2012 14:44, Damien Pollet <damien.pollet at gmail.com>
| > wrote:
| >> On 31 January 2012 15:59, Otto Behrens <otto at finworks.biz> wrote:
| >>> I was wondering more if it is possible to do without having a
| >>> file
| >>> system checkout of the class definition. In other words, if the
| >>> class
| >>> definition in the image could serve as the working copy of the
| >>> object
| >>> in the git repository. I must read more on what the other guys
| >>> did
| >>> with the git interfaces (such as gitfs and gitosis) to understand
| >>> what
| >>> it comes down to.
| >>>
| >>> If this is possible, it would make merging, loading and
| >>> committing
| >>> essentially one step.
| >>
| >> Have you seen what Camillo did?
| >> http://www.squeaksource.com/FSGit
| >> https://github.com/dh83/fs-git-test
| >>
| >> Note the layout with class comment in a README file, etc :)
| >
| > That is _exactly_ the right thing to do! Bravo, Camillo! Also note
| > how
| > Nested-Package-Names end up looking like you might expect.
| >
| > Is there any necessity for storing a chunk? For instance in
| > https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side/as%20yet%20unclassified/a.st
| > we have
| >
| > !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni
| > 1/23/2012 19:15'!
| > a
| > ? ? ? ?| a |
| > ? ? ? ?^ a! !
| >
| > with the ugly chunk !s. The only thing we can't directly regenerate
| > is
| > the timestamp: modulo that, we know the class name, the category
| > (the
| > name of the directory you're in), the author (from the author of
| > the
| > git commit). You'd have a disconnect between the git commit time
| > and
| > the time in the chunk which would, IIRC, be the time you hit Alt-S
| > in
| > your browser? Or would that be file-out time, which would likely
| > then
| > be the timestamp in the git commit?
| >
|
| Good question, Frank.
| But i want to go even further by saying:
| why we cannot associate an arbitrary meta-information per method and
| store it along with method?
|
| Today we storing the category, author and stamp.
| Tomorrow we may want to add something more (link to documentation,
| link to previous version etc etc)
| And i think , at least in GitFS Camillo can do it pretty easy.
| If you have 1 file per method, make 2 files per method, i.e.:
|
| methodname.st
| methodname.meta
|
| and in meta, we can store everything we want in a form we want. while
| .st is for storing purely smalltalk source code, and nothing else.
|
| --
| Best regards,
| Igor Stasenko.
|
|
Dale Henrichs
2012-02-01 20:12:58 UTC
Permalink
Getting deeper in FSGit and it looks like it has a Monticello mapping ... now to work:)

Dale

----- Original Message -----
| From: "Stefan Marr" <smalltalk at stefan-marr.de>
| To: Pharo-project at lists.gforge.inria.fr
| Cc: metacello at googlegroups.com, "Bruni camillo" <camillobruni at gmail.com>
| Sent: Wednesday, February 1, 2012 11:02:16 AM
| Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
|
|
| On 01 Feb 2012, at 19:45, Dale Henrichs wrote:
|
| > I haven't completely grokked the entire FSGit experience, however
| > the piece that has intrigued me with the filetree repository that
| > Otto has done is the fusion between monticello and "git"
| > (technically filetree doesn't depend upon git, it just stores
| > monticello package information in a structured directory tree). So
| > filetree can be used as the basis for integrating any file-based
| > SCM into Smalltalk...personally I will focus on git...
| >
| > Basically, I have taken myself up on the challenge to provide a git
| > workflow experience for Smalltalk:) and my approach is to create a
| > fusion of Monticello, Metacello, and git...
|
| Cool!
|
| Camillo, did you plan be in Brussels on Saturday for the sprint?
| Would that be something to pair on for a few hours?
|
| Best regards
| Stefan
|
|
|
| --
| Stefan Marr
| Software Languages Lab
| Vrije Universiteit Brussel
| Pleinlaan 2 / B-1050 Brussels / Belgium
| http://soft.vub.ac.be/~smarr
| Phone: +32 2 629 2974
| Fax: +32 2 629 3525
|
|
|
Janko Mivšek
2012-02-02 11:47:08 UTC
Permalink
-------- Prvotno sporo?ilo --------
Datum: Wed, 1 Feb 2012 11:54:22 -0500
Od: Paul Baumann <paul.baumann at theice.com>

Peter's point that "that there is [not] any inherent advantage in using
Smalltalk development over any other language" is true by the criteria
that he defined to judged it.

It is funny to see "Smalltalk efficiency" is being framed by a standard
of high resource requirements, and that Java having twice as many
function points and four times as many cases for equivalent architecture
and design was somehow a less relevant measure. One might observe that
having such a wide variety of similar tools for a language like Java can
indicate a limitation of reuse and extension. Smalltalk syntax is less
restrictive in how a framework can be reused and extended; that is a
better criteria to judge efficiency of the language.

"Smalltalk" is syntax and a basic class library; it is not defined by
the availability of a vendor features. IBM failures are more relevant
than a Smalltalk failure. Large IBM projects of that era failed from
Analysis Paralysis. A common goal was compliance with the latest buzz
that IBM sold. There were a multitude of management styles in vogue at
that time and all could be characterized as top-down management. The
"60% heads down developers" were given static designs that had a high
and continuous cycle of costs as theory met reality. Large amounts of
dumb and redundant code would be generated early. Code inertia and
resistance to change would preclude opportunity that is discovered later
(like the ability to eliminate thousands of classes with a single
reusable type). The result is as predictable as any top-down management
style. All design problems were prevented from being fixed until they
caused serious and recognizable problems. The management styles of the
time promised theoretical efficiencies of scale that had been determined
from earlier failures with less malleable languages than Smalltalk.
Effectiveness of these feudalistic management styles had yet to be
recognized as Dark Ages in the context of software development.
Smalltalk does well when individual developers are given opportunity and
responsibility, and to the extent that implementation is not restricted.
Success with Smalltalk is about rewarding independent action that
furthers an objective goal. Management of a Smalltalk project is about
providing healthy incentives while minimizing barriers to change.
Top-down management (sold by IBM) was more to blame than "Smalltalk".

Smalltalk is successfully used for large mission-critical projects that
affect global markets. It doesn't take even a dozen Smalltalk developers
to do that. Smalltalk can be more efficient than other languages when a
compatible management style is used. Smalltalk struggled through the
Dark Ages of project management while more popular languages were
developed outside of those conditions. Smalltalk is a victim of timing,
management, and vision. The more popular languages provide opportunity
of market more so than opportunity of syntax. Languages have evolved to
be increasingly more malleable like Smalltalk; that is recognition of an
advantage that Smalltalk has always had rather than proof that Smalltalk
never was more efficient.

Some people value opportunity of syntax that Smalltalk offers and have
the vision to leverage that to a competitive advantage. Other people
recognize that the availability of resources and frameworks can also be
leveraged as an advantage over Smalltalk. It is possible to find success
or failure either way.

Paul Baumann


*From:*vwnc-bounces at cs.uiuc.edu [mailto:vwnc-bounces at cs.uiuc.edu] *On
Behalf Of *James Robertson
*Sent:* Tuesday, January 31, 2012 14:10
*To:* VWNC NC
*Subject:* Re: [vwnc] [Pharo-project] Smalltalk for small projects only?

Ironically, I worked on a telecom project <in that domain> over a decade
ago, with more people involved. Still in production, too.

On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote:

With all due respect to the experience of everyone here, people really
need to give up on this naive belief that Smalltalk development is any
more efficient than development in any other language. The simple fact
is that within the Smalltalk community a large portion of the developers
have been using the tools for a long time and are very good at using
them. Throw them at another environment and they are not as efficient.
However, if you take new developers and throw them at a Smalltalk
project it takes longer to get them up to speed than throwing them at a
Java project simply because of the fact that Smalltalk is not
as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so
I've seen both sides of this issue for a long time, so let me related
some anecdotal experience:

I'm currently working on a Smalltalk project that has about about 50 man
years of effort in it over 10 years. Prior to this I worked on a Java
and XSLt project that had about the same effort over the same period.
Both have web based GUI's with a fair amount of JavaScript and the
usual HTML crud and use a relational DB back end (SQL server and Oracle
respectively). The Smalltalk project has had a mix of very experienced
Smalltalk developers and inexperienced ones. The Java project was
mainly junior and intermediate experience devs. I'd say the overall
architecture and design was about equivalent; very different, but
equally well done and comprehensive. The projects are very similar in
concept and execution. The Java project had about twice as many
function points (some pretty major) implemented and four times as many
use cases supported at the point I switched to the Smalltalk project.
For the most part this has little to do with the language itself.
Rather, it is mainly, the supporting infrastructure that one is able to
draw on in Java projects and this includes Eclipse, Git, etc. Open
Source projects also played a big part of this, in the Java world one
can pull in large chunks of functionality at very low cost (eg. XSLt 2.0
processors and pipelines, Spring, Hadoop, you name it) that are just not
quite matched in the Smalltalk world. You can often get close, but it
seems that there is always something missing, if only because the teams
supporting the Smalltalk projects are often much smaller and just can't
quite keep up with the every changing specs and requirements.

Bottom line, don't kid yourself that there is any inherent advantage in
using Smalltalk development over any other language. It is faster for
experienced devs in small projects, but if you've got to pull a team
together from scratch for some medium to large complexity enterprise
scale project it is probably not going to fair as well.

Now onto the main question posed here....

I have also worked on a successful 200 man year project (C and C++ in
this case), which broke down to a little less than 100 people over a
little more than 2 years. This was in the telecom world and involved
many main frame billing interfaces and switching equipment interfaces,
all very mission critical. In this case about 60% of the team was heads
down developers. The rest of it was dedicated testers, tech writers,
business analysts, project managers and managers. Here again the
supporting infrastructure played an important role. Business analysts
could write up use cases that got stored in a repository (a proprietary
system) that could be used to generate test case stubs and documentation
stubs. The development team tracked progress and bug reports in the
same repository and source code version control was tied to the
repository. End user documentation was stored in the repository and
version controlled. It was simple to know what was going on anywhere in
the project and to know where the problems were and what code did what
and to see the entire life cycle of any portion of the code base from
customer requirement to final deliverable. I know of no
support infrastructure that even comes close in the Smalltalk world and
would consider it madness to even consider taking on such a project
using Smalltalk.

Peter Hunsberger

On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont
<laurent.laffont at gmail.com <mailto:laurent.laffont at gmail.com>> wrote:

200 developers on a project ? Scaring ..... They should use another
technology than Java to go under 50 developers. They will save a lot of
money :)

Laurent

2012/1/28 Janko Miv?ek <janko.mivsek at eranova.si
<mailto:janko.mivsek at eranova.si>>

Hi guys,

Ralph Johnson in his InfoQ interview made an interesting observation:

2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
... "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pripet del sporo?ila
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120202/9e428e2d/attachment.ksh>
Janko Mivšek
2012-02-02 11:48:26 UTC
Permalink
-------- Prvotno sporo?ilo --------
Datum: Tue, 31 Jan 2012 07:54:58 -0600
Od: Peter Hunsberger <peter.hunsberger at gmail.com>


With all due respect to the experience of everyone here, people really
need to give up on this naive belief that Smalltalk development is any
more efficient than development in any other language. The simple fact
is that within the Smalltalk community a large portion of the developers
have been using the tools for a long time and are very good at using
them. Throw them at another environment and they are not as efficient.
However, if you take new developers and throw them at a Smalltalk
project it takes longer to get them up to speed than throwing them at a
Java project simply because of the fact that Smalltalk is not
as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so
I've seen both sides of this issue for a long time, so let me related
some anecdotal experience:

I'm currently working on a Smalltalk project that has about about 50 man
years of effort in it over 10 years. Prior to this I worked on a Java
and XSLt project that had about the same effort over the same period.
Both have web based GUI's with a fair amount of JavaScript and the
usual HTML crud and use a relational DB back end (SQL server and Oracle
respectively). The Smalltalk project has had a mix of very experienced
Smalltalk developers and inexperienced ones. The Java project was
mainly junior and intermediate experience devs. I'd say the overall
architecture and design was about equivalent; very different, but
equally well done and comprehensive. The projects are very similar in
concept and execution. The Java project had about twice as many
function points (some pretty major) implemented and four times as many
use cases supported at the point I switched to the Smalltalk project.
For the most part this has little to do with the language itself.
Rather, it is mainly, the supporting infrastructure that one is able to
draw on in Java projects and this includes Eclipse, Git, etc. Open
Source projects also played a big part of this, in the Java world one
can pull in large chunks of functionality at very low cost (eg. XSLt 2.0
processors and pipelines, Spring, Hadoop, you name it) that are just not
quite matched in the Smalltalk world. You can often get close, but it
seems that there is always something missing, if only because the teams
supporting the Smalltalk projects are often much smaller and just can't
quite keep up with the every changing specs and requirements.

Bottom line, don't kid yourself that there is any inherent advantage in
using Smalltalk development over any other language. It is faster for
experienced devs in small projects, but if you've got to pull a team
together from scratch for some medium to large complexity enterprise
scale project it is probably not going to fair as well.

Now onto the main question posed here....

I have also worked on a successful 200 man year project (C and C++ in
this case), which broke down to a little less than 100 people over a
little more than 2 years. This was in the telecom world and involved
many main frame billing interfaces and switching equipment interfaces,
all very mission critical. In this case about 60% of the team was heads
down developers. The rest of it was dedicated testers, tech writers,
business analysts, project managers and managers. Here again the
supporting infrastructure played an important role. Business analysts
could write up use cases that got stored in a repository (a proprietary
system) that could be used to generate test case stubs and documentation
stubs. The development team tracked progress and bug reports in the
same repository and source code version control was tied to the
repository. End user documentation was stored in the repository and
version controlled. It was simple to know what was going on anywhere in
the project and to know where the problems were and what code did what
and to see the entire life cycle of any portion of the code base from
customer requirement to final deliverable. I know of no
support infrastructure that even comes close in the Smalltalk world and
would consider it madness to even consider taking on such a project
using Smalltalk.

Peter Hunsberger


On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont
<laurent.laffont at gmail.com <mailto:laurent.laffont at gmail.com>> wrote:

200 developers on a project ? Scaring ..... They should use another
technology than Java to go under 50 developers. They will save a lot
of money :)

Laurent


2012/1/28 Janko Miv?ek <janko.mivsek at eranova.si
<mailto:janko.mivsek at eranova.si>>

Hi guys,

Ralph Johnson in his InfoQ interview made an interesting
observation:

2:55 minute: "Smalltalk made an fundamental error ... image ...
you can
build something with 4-5 people what 50 people can build in
Java, but if
you take 200 people in Java ... it is really designed for small
systems
... "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems
because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


--
Janko Miv?ek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pripet del sporo?ila
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120202/8d0d15b1/attachment.ksh>
Continue reading on narkive:
Loading...