[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
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@eranova.si> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr>; Squeak <squeak-dev@lists.squeakfoundation.org>; 'VWNC' <vwnc@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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of dimitris chloupis [thekilon@yahoo.co.uk] Sent: Saturday, January 28, 2012 11:50 AM To: Pharo-project@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@eranova.si> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr>; Squeak <squeak-dev@lists.squeakfoundation.org>; 'VWNC' <vwnc@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
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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Lawson English [lenglish5@cox.net] Sent: Saturday, January 28, 2012 2:16 PM To: pharo-project@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
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@eranova.si> *To:* "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr>; Squeak <squeak-dev@lists.squeakfoundation.org>; 'VWNC' <vwnc@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
Janko, Am 28.01.2012 um 21:08 schrieb Janko Mivšek <janko.mivsek@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
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
Janko, Am 28.01.2012 um 23:37 schrieb Janko Mivšek <janko.mivsek@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
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@gmail.com> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@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
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@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@gmail.com> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@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
Reference, please :) I fully believe it. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt@gmail.com] Sent: Sunday, January 29, 2012 7:44 AM To: Pharo-project@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@yahoo.co.uk<mailto:thekilon@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@gmail.com<mailto:mhaupt@gmail.com>> To: "Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>" <Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@eranova.si<mailto:janko.mivsek@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
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=0C... ________________________________ From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt@gmail.com] Sent: Sunday, January 29, 2012 7:44 AM To: Pharo-project@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@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@gmail.com> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@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
ok I think I found something you may like this http://codemonkeyism.com/comparing-java-and-python-is-java-10x-more-verbose-... ________________________________ From: dimitris chloupis <thekilon@yahoo.co.uk> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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=0C... ________________________________ From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt@gmail.com] Sent: Sunday, January 29, 2012 7:44 AM To: Pharo-project@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@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@gmail.com> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@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
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@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-...
From: dimitris chloupis <thekilon@yahoo.co.uk> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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=0C...
From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt@gmail.com] Sent: Sunday, January 29, 2012 7:44 AM To: Pharo-project@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@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@gmail.com> To: "Pharo-project@lists.gforge.inria.fr" <Pharo-project@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@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
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@eranova.si> To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis <thekilon@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@eranova.si> *To:* "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr>; Squeak <squeak-dev@lists.squeakfoundation.org>; 'VWNC' <vwnc@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
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@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@eranova.si> *To:* Pharo-project@lists.gforge.inria.fr; dimitris chloupis < thekilon@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@eranova.si> *To:* "Pharo-project@lists.gforge.inria.fr" <Pharo-project@lists.gforge.inria.fr>; Squeak <squeak-dev@lists.squeakfoundation.org>; 'VWNC' <vwnc@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
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
On 28 January 2012 22:06, Hilaire Fernandes <hilaire.fernandes@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.
On 28.01.2012 22:27, Igor Stasenko wrote:
On 28 January 2012 22:06, Hilaire Fernandes<hilaire.fernandes@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
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.
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/testRep... Cheers Philippe
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/testRep...
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
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/testRep...
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
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/testRep...
Cheers Philippe
Stef
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
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@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
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
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
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@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/testRep...
Cheers Philippe
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
On 29 January 2012 18:48, Philippe Marschall <kustos@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... 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/testRep...
Cheers Philippe
-- Best regards, Igor Stasenko.
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@beta9.be> | To: Pharo-project@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. |
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
exactly what I meant, glad you see it that way too. ________________________________ From: Hilaire Fernandes <hilaire.fernandes@edu.ge.ch> To: pharo-project@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
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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr, "Squeak" <squeak-dev@lists.squeakfoundation.org>, "VWNC" <vwnc@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 | |
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
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@beta9.be> | To: "The general-purpose Squeak developers list" <squeak-dev@lists.squeakfoundation.org> | Cc: "VWNC" <vwnc@cs.uiuc.edu>, Pharo-project@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 | | | |
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Saturday, January 28, 2012 2:08 PM To: The general-purpose Squeak developers list Cc: VWNC; Pharo-project@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
On 29 January 2012 00:04, Schwab,Wilhelm K <bschwab@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Saturday, January 28, 2012 2:08 PM To: The general-purpose Squeak developers list Cc: VWNC; Pharo-project@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.
Hi Igor, Am 29.01.2012 um 00:11 schrieb Igor Stasenko <siguctua@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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt@gmail.com] Sent: Sunday, January 29, 2012 1:07 AM To: Pharo-project@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@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
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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr, "Squeak"<squeak-dev@lists.squeakfoundation.org>, "VWNC"<vwnc@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 | |
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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr, "Squeak" <squeak-dev@lists.squeakfoundation.org>, "VWNC" <vwnc@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
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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr | Cc: "Dale Henrichs" <dhenrich@vmware.com>, "The general-purpose Squeak developers list" | <squeak-dev@lists.squeakfoundation.org>, "VWNC" <vwnc@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@eranova.si> | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | <squeak-dev@lists.squeakfoundation.org>, "VWNC" | > | <vwnc@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 |
2012/1/28 Dale Henrichs <dhenrich@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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr | Cc: "Dale Henrichs" <dhenrich@vmware.com>, "The general-purpose Squeak developers list" | <squeak-dev@lists.squeakfoundation.org>, "VWNC" <vwnc@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@eranova.si> | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | <squeak-dev@lists.squeakfoundation.org>, "VWNC" | > | <vwnc@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, 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@gmail.com> | To: "The general-purpose Squeak developers list" <squeak-dev@lists.squeakfoundation.org> | Cc: "VWNC" <vwnc@cs.uiuc.edu>, "Janko Mivšek" <janko.mivsek@eranova.si>, Pharo-project@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@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@eranova.si> | > | To: Pharo-project@lists.gforge.inria.fr | > | Cc: "Dale Henrichs" <dhenrich@vmware.com>, "The general-purpose | > | Squeak developers list" | > | <squeak-dev@lists.squeakfoundation.org>, "VWNC" | > | <vwnc@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@eranova.si> | > | > | To: Pharo-project@lists.gforge.inria.fr, "Squeak" | > | > | <squeak-dev@lists.squeakfoundation.org>, "VWNC" | > | > | <vwnc@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 | > | | > | |
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@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
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@wart.ca> | | The idea of building the git workflow on top of metacello strikes me | as being somewhat ambitious.
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@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@wart.ca> | | The idea of building the git workflow on top of metacello strikes me | as being somewhat ambitious.
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@wart.ca> | To: "The general-purpose Squeak developers list" <squeak-dev@lists.squeakfoundation.org> | Cc: "VWNC" <vwnc@cs.uiuc.edu>, "Janko Mivšek" <janko.mivsek@eranova.si>, Pharo-project@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@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@wart.ca > | | | | The idea of building the git workflow on top of metacello strikes | | me | | as being somewhat ambitious. | | | | |
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, 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
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.
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
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
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@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
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
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
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
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
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@finworks.biz> | To: Pharo-project@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 | |
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@finworks.biz> | To: Pharo-project@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
On 29 January 2012 23:03, Otto Behrens <otto@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
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
On 31 January 2012 15:59, Otto Behrens <otto@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
On 1 February 2012 14:44, Damien Pollet <damien.pollet@gmail.com> wrote:
On 31 January 2012 15:59, Otto Behrens <otto@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/... 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
On 1 February 2012 16:12, Frank Shearar <frank.shearar@gmail.com> wrote:
On 1 February 2012 14:44, Damien Pollet <damien.pollet@gmail.com> wrote:
On 31 January 2012 15:59, Otto Behrens <otto@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/... 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.
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@gmail.com> | To: Pharo-project@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@gmail.com> | wrote: | > On 1 February 2012 14:44, Damien Pollet <damien.pollet@gmail.com> | > wrote: | >> On 31 January 2012 15:59, Otto Behrens <otto@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/... | > 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. | |
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/b79df4a2cd63200a8a1712fe629d... [9] http://groups.google.com/group/metacello ----- Original Message ----- | From: "Damien Pollet" <damien.pollet@gmail.com> | To: Pharo-project@lists.gforge.inria.fr, "Bruni camillo" <camillobruni@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@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 | |
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
Getting deeper in FSGit and it looks like it has a Monticello mapping ... now to work:) Dale ----- Original Message ----- | From: "Stefan Marr" <smalltalk@stefan-marr.de> | To: Pharo-project@lists.gforge.inria.fr | Cc: metacello@googlegroups.com, "Bruni camillo" <camillobruni@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 | | |
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
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@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
On 29 January 2012 16:29, Steve Wart <steve@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@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
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
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
On Sun, Jan 29, 2012 at 11:39 AM, Philippe Marschall <kustos@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
200 5+year smalltalkers - that's an army capable of almost anything... ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich@vmware.com] Sent: Saturday, January 28, 2012 1:07 PM To: The general-purpose Squeak developers list Cc: VWNC; Pharo-project@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@eranova.si> | To: Pharo-project@lists.gforge.inria.fr, "Squeak" <squeak-dev@lists.squeakfoundation.org>, "VWNC" <vwnc@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 | |
On 28 January 2012 23:58, Schwab,Wilhelm K <bschwab@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.
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, January 28, 2012 6:07 PM To: Pharo-project@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@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.
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@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
participants (20)
-
Chris Muller -
Dale Henrichs -
Damien Pollet -
dimitris chloupis -
Frank Shearar -
Guido Stepken -
Göran Krampe -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
laurent laffont -
Lawson English -
Michael Haupt -
Otto Behrens -
Philippe Marschall -
Schwab,Wilhelm K -
Stefan Marr -
Steve Wart -
Stéphane Ducasse -
Sven Van Caekenberghe