January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smalltalk for small projects only?

by dimitris chloupis

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=0… ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt(a)gmail.com] Sent: Sunday, January 29, 2012 7:44 AM To: Pharo-project(a)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(a)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(a)gmail.com> >To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)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(a)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 > > >

Jan. 29, 2012

Re: [Pharo-project] Block explained continued

by StÃ©phane Ducasse

but I'm not finished. There are points I want to really understand. On Jan 29, 2012, at 3:52 PM, Edgar J. De Cleene wrote: > > > > On 1/29/12 1:40 PM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > >> I did another pass on the Block chapter I'm writing and I would like to know >> if I'm not saying something wrong. >> Here is what I wrote. >> >> The following examples shows that escaping blocks jumped to their home context >> but do not unwind the stack after this point. >> \ct{valueWithExit} is defined on the class BlockClosure as follows. >> >> \begin{code}{} >> BlockClosure>>valueWithExit >> self value: [ ^nil ] >> \end{code} >> >> \begin{code}{} >> BExp>>assert: aBoolean >> aBoolean ifFalse: [Error signal] >> >> BExp>>testValueWithExitBreak >> | val | >> [ :break | >> 1 to: 10 do: [ :i | >> val := i. >> i = 4 ifTrue: [break value]. >> ] >> ] valueWithExit. >> self assert: val = 4. >> \end{code} >> >> \ct{testValueWithExitBreak} shows that the block \ct{break} is created and >> activated once and as effect it cancels the rest of the computation. >> >> The following method \ct{testValueWithExitContinue} shows that just the >> computation left from the block activation is skipped (here \ct{val := val + >> 1. last := i}, when i = 4) and this is why the value of \ct{val} is 9 and not >> 10. >> In this example, a new block is created >> >> >> \begin{code}{} >> BExp>>testValueWithExitContinue >> | val last | >> val := 0. >> 1 to: 10 do: [ :i | >> [ :continue | >> i = 4 ifTrue: [continue value]. >> val := val + 1. >> last := i >> ] valueWithExit. >> ]. >> self assert: val = 9. >> self assert: last = 10. >> \end{code} >> >> Pay attention here \ct{valueWithExit} is not equivalent to \ct{value: [^nil]} >> because it changes the home context of the block. >> In the first case the homeContext of the block is not the method >> \ct{testValueWithExitContinue} while in the second it is. >> Put a self halt before the assert: to convince you. In one case, you will >> reach the halt while in the other not. > > > Happy you was writing a Block chapter. > Add as many examples you found and say where we could read some preview. > If you wish I volunteer on help with Spanish translate when ready. > > As always you work inspire us in SqueakRos (181 members today) > > Edgar > > >

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Steve Wart

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(a)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 > >

Jan. 29, 2012

Re: [Pharo-project] [Smalltalk for small projects only?

by Steve Wart

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(a)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 > > >

Jan. 29, 2012

Re: [Pharo-project] FOSDEM2012 smalltalk devroom 5 feb, sprint 4 feb

by Marcus Denker

> 09:30 Norbert Hartl, Take a small REST. Simple approaches for REST in smalltalk > 10:00 Stephane Ducasse, Marcus Denker, The next steps for the Pharo Vision > I checked for trains... the *first* train from Lille arrives 9:45 in Bruessels Midi Sundays. I don't feel like booking a Hotel in Bruessels, I have to admit. -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Sven Van Caekenberghe

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.

Jan. 29, 2012

[Pharo-project] Block explained continued

by StÃ©phane Ducasse

I did another pass on the Block chapter I'm writing and I would like to know if I'm not saying something wrong. Here is what I wrote. The following examples shows that escaping blocks jumped to their home context but do not unwind the stack after this point. \ct{valueWithExit} is defined on the class BlockClosure as follows. \begin{code}{} BlockClosure>>valueWithExit self value: [ ^nil ] \end{code} \begin{code}{} BExp>>assert: aBoolean aBoolean ifFalse: [Error signal] BExp>>testValueWithExitBreak | val | [ :break | 1 to: 10 do: [ :i | val := i. i = 4 ifTrue: [break value]. ] ] valueWithExit. self assert: val = 4. \end{code} \ct{testValueWithExitBreak} shows that the block \ct{break} is created and activated once and as effect it cancels the rest of the computation. The following method \ct{testValueWithExitContinue} shows that just the computation left from the block activation is skipped (here \ct{val := val + 1. last := i}, when i = 4) and this is why the value of \ct{val} is 9 and not 10. In this example, a new block is created \begin{code}{} BExp>>testValueWithExitContinue | val last | val := 0. 1 to: 10 do: [ :i | [ :continue | i = 4 ifTrue: [continue value]. val := val + 1. last := i ] valueWithExit. ]. self assert: val = 9. self assert: last = 10. \end{code} Pay attention here \ct{valueWithExit} is not equivalent to \ct{value: [^nil]} because it changes the home context of the block. In the first case the homeContext of the block is not the method \ct{testValueWithExitContinue} while in the second it is. Put a self halt before the assert: to convince you. In one case, you will reach the halt while in the other not.

Jan. 29, 2012

Re: [Pharo-project] [Smalltalk for small projects only?

by Philippe Marschall

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

Jan. 29, 2012

Re: [Pharo-project] Block explained continued

by Edgar J. De Cleene

On 1/29/12 1:40 PM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > I did another pass on the Block chapter I'm writing and I would like to know > if I'm not saying something wrong. > Here is what I wrote. > > The following examples shows that escaping blocks jumped to their home context > but do not unwind the stack after this point. > \ct{valueWithExit} is defined on the class BlockClosure as follows. > > \begin{code}{} > BlockClosure>>valueWithExit > self value: [ ^nil ] > \end{code} > > \begin{code}{} > BExp>>assert: aBoolean > aBoolean ifFalse: [Error signal] > > BExp>>testValueWithExitBreak > | val | > [ :break | > 1 to: 10 do: [ :i | > val := i. > i = 4 ifTrue: [break value]. > ] > ] valueWithExit. > self assert: val = 4. > \end{code} > > \ct{testValueWithExitBreak} shows that the block \ct{break} is created and > activated once and as effect it cancels the rest of the computation. > > The following method \ct{testValueWithExitContinue} shows that just the > computation left from the block activation is skipped (here \ct{val := val + > 1. last := i}, when i = 4) and this is why the value of \ct{val} is 9 and not > 10. > In this example, a new block is created > > > \begin{code}{} > BExp>>testValueWithExitContinue > | val last | > val := 0. > 1 to: 10 do: [ :i | > [ :continue | > i = 4 ifTrue: [continue value]. > val := val + 1. > last := i > ] valueWithExit. > ]. > self assert: val = 9. > self assert: last = 10. > \end{code} > > Pay attention here \ct{valueWithExit} is not equivalent to \ct{value: [^nil]} > because it changes the home context of the block. > In the first case the homeContext of the block is not the method > \ct{testValueWithExitContinue} while in the second it is. > Put a self halt before the assert: to convince you. In one case, you will > reach the halt while in the other not. Happy you was writing a Block chapter. Add as many examples you found and say where we could read some preview. If you wish I volunteer on help with Spanish translate when ready. As always you work inspire us in SqueakRos (181 members today) Edgar

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Philippe Marschall

On 28.01.2012 22:27, Igor Stasenko wrote: > On 28 January 2012 22:06, Hilaire Fernandes<hilaire.fernandes(a)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

Jan. 29, 2012