- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?
by Janko MivÅ¡ek Jan. 31, 2012

Jan. 31, 2012

-------- Prvotno sporoÄilo -------- Datum: Tue, 31 Jan 2012 07:54:58 -0600 Od: Peter Hunsberger <peter.hunsberger(a)gmail.com> With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience: I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements. Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well. Now onto the main question posed here.... I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk. Peter Hunsberger On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: 200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :) Laurent 2012/1/28 Janko MivÅ¡ek <janko.mivsek(a)eranova.si <mailto: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

1 0

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?
by Janko MivÅ¡ek Jan. 31, 2012

Jan. 31, 2012

-------- Prvotno sporoÄilo -------- Datum: Tue, 31 Jan 2012 10:07:34 -0800 Od: Jon Paynter <kittle31(a)gmail.com> > Dear Niall, > Thanks for comprehensive report, the biggest project reported so far. > I forwarded it to Squeak and Pharo mailing lists. > Has anyone data for other big Smalltalk projects/systems, like OOCL > etc? OOCL has 2 smalltalk projects The small one with 2,200 classes and 2 developers The larger one ranged from 20-50 developers (my guess), and currently has 24,000 classes. And the last time it was measured (a few years ago) we had around 8million lines of code. And my own personal $0.02 on productivity: One place I worked at as a contractor was a java shop. I was just learning java, so my skills at that time were lousy. We had a small project to do, and I managed to get 2 weeks of time from the local java expert. She came highly recommended by everyone, and after watching her work, she was in deed VERY good. After 2 weeks of struggle, we failed to finish the project. Afterwards, I sat down and did the project in visualworks ( from scratch) in 1 day. Experience matters, but using the right tool for the job is where its at.

1 0

[Pharo-project] Another video tutorial
by Lawson English Jan. 31, 2012

Jan. 31, 2012

Latest squeak tutorial. Connectors how-to: http://www.youtube.com/watch?v=H1LveflchAU as an aside, it seems to me that Connectors should be ported back to Pharo, because it can be very useful I am finding. Lawson

2 2

Re: [Pharo-project] Enthousiasm is the main currency among developers
by Marcus Denker Jan. 31, 2012

Jan. 31, 2012

On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: > This article is really encapsulates the attitude and what is wrong with programming in general. The attitude of superiority and intelligence that seems to plague coders and being the biggest obstacle to progress. Yes! The "Everyone is dumb but me" phenomenon... What those "intelligent" people don't get is that complexity is inherently exponential. So even if you are 10 times more intelligent than me (very well possible), it is *completely* irrelevant considering that complexity grows non-linearly. If you combine this with the notion of Evolution: that it is impossible to creat "the perfect" out of nothing, yet entropy grows when you incrementally improve things... than this has some very serious consequences. > For me the main problem with is the whole aura of "elitism" , what better example than Lisp, where beginners are attacked and be excluded. We had the same effect in Squeak at the end. No progress, every improvement was actively fighted against, if needed with the nice argument that one can do it even better, and only "the best" is worth for Squeak. Another thing that "intelligent" people don't get is that critizising is trivial: You can *always* do better, there is no perfection. It's an endless process. This implies that one has to accept and embrace imperfection if one wants to have a future. Else you end up never finishing anything, the death of any incremental progress. Pharo was started with the explicit goal to do as many mistakes as possible, as fast as possible. Marcus -- Marcus Denker -- http://marcusdenker.de

9 13

Re: [Pharo-project] Which COG VM?
by Marcus Denker Jan. 31, 2012

Jan. 31, 2012

On Jan 22, 2012, at 10:50 AM, Johan Brichau wrote: > > I think somebody that maintains the website needs to replace the VM that is linked on the download page with the latest VM built in Jenkins. > > I had the same issues but when I switched to the latest built on Jenkins, I had no issues anymore. > We need to once and for all finish to have a *complete* continous integration setup... we really should push towards that, else the on-click will be always out of date. Now there are lots of tiny trivial unimportant steps to go there that somehow never get done... I have put this on my TODO list, but it will take a while, sadly. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] Enthousiasm is the main currency among developers
by Marcus Denker Jan. 31, 2012

Jan. 31, 2012

On Jan 31, 2012, at 12:10 PM, Frank Shearar wrote: > On 31 January 2012 14:44, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: >> I agree whole heartedly after a month of Pharo being used as a tool for >> newbies. >> >> a) Crashes... Make sure to run an up-to-date vm and image (and yes, the downloads are not up to date...) And it's important that people report problems. If problems are not reported, it is as if they would not exist. >> b) Bugs in basic functionality: Morphic as well as in other places Morphic is just crap. But what can we do else than slowly fixing what we see? >> c) The User Guide is not in synch with the current stable Pharo.. in simple >> images of browsers.. We just can't update pharo by example for every release... the day has just 24 hours. But it is true that the version right now is far too old. (based on a horibly slow 1.0 with a completely different browser...) In general there are two options: -> give up and do something else -> fix the problems, step by step. -- Marcus Denker -- http://marcusdenker.de

2 2

Re: [Pharo-project] OneClick on website's first page?
by Marcus Denker Jan. 31, 2012

Jan. 31, 2012

On Jan 26, 2012, at 2:01 PM, Janko MivÅ¡ek wrote: > Hi guys, > > For newcommers it would be really good to put a "Stable Pharo OneClick" > on the first place of Downloads section on first page at > http://www.pharo-project.org. > But that we have? No? http://www.pharo-project.org/pharo-download -- Marcus Denker -- http://marcusdenker.de

5 8

Re: [Pharo-project] Future of SCM (was Smalltalk for small projects only?)
by Janko MivÅ¡ek Jan. 31, 2012

Jan. 31, 2012

Hi guys, This idea about realtime non-invasive notifications of others activity in the group is actually interesting and quite close what we are seeing in realtime web apps recently. I namelly see the Facebook-like business collaboration as a growing trend and one of more interesting innovations there is how to get notified without being disturbed, non-invasive therefore. I think we can copy some ideas from there to our tools too. Janko S, GÃ¶ran Krampe piÅ¡e: >>> - Real time collaboration. If we can sit in a shared (in some >>> controlled fashion) development environment in some kind >>> of real time model, then lots of merging and conflicts would just say >>> PUFF and go up in smoke. We are beginning to see >>> this now with the new IDEs running "on the web" because suddenly it >>> gets very natural to experiment in that direction. >> Real-time collaboration in the sense of getting code updates from >> other developers immediatedly is probably not very >> helpful, as it would distract a lot. > Code changes is one thing you probably want to *control* (which is why I > wrote "in some controlled fashion") but some examples of stuff you > really would like to get "immediately" are: > > - Developer X is modifying "your" code. No, not committed yet - but > perhaps you should talk to X :) > > - Visual queue/notification that developer X just managed to break your > unit tests > > - Developer X is right now writing new code that references classes that > you in turn have modified in your uncommitted code... or sending > messages whose implementations you in turn have modified in your > uncommitted code. > > ...and so on, there are numerous "tell tales" that there will be > interesting issues down the road - and these signals could be exposed to > the developers in various ways. Open your mind - it is not all about > sharing commits of code :) -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

[Pharo-project] Artifacts Mirroring
by Camillo Bruni Jan. 31, 2012

Jan. 31, 2012

hi everyone, I thought about mirroring the fresh artifacts from our jenkins server to the google-code site. Like this we would have at least a second place to download fresh builds even if the jenkins site is down again. What do you think?

4 8

[Pharo-project] End of startup script behavior
by Sven Van Caekenberghe Jan. 31, 2012

Jan. 31, 2012

Guys, Maybe I missed this, but did something change with the behavior at the end of a startup script between 1.3 and 1.4 ? It used to be that the image kept on running unless you asked it to quit explicitly, now it seems that the image automatically quits unless you keep it busy. Can someone confirm this ? Was this intentional ? What would be the recommended way to keep the image open ? Somehow something like [ (Delay forDuration: 1 hour) wait ] repeat. seems so silly, but it works. Thx, Sven

3 3