Squeak-dev January 2012

squeak-dev@lists.squeakfoundation.org

65 participants
121 discussions

Re: [squeak-dev] Smalltalk for small projects only?
by mkobetic＠gmail.com 06 Feb '12

06 Feb '12

"Janko Mivšek"<janko.mivsek(a)eranova.si> wrote: > Ralph Johnson in his InfoQ interview made an interesting observation: > > 2:55 minute: "Smalltalk made an fundamental error ... image ... you can > build something with 4-5 people what 50 people can build in Java, but if > you take 200 people in Java ... it is really designed for small systems > ... " > > Are we because of the image really destined for relatively small > projects and small systems (of Java 50 people project size)? The "image" argument is one of the easiest to pick when you want to justify your xenophobic reaction to an unfamiliar environment you're about to enter ("... but they are green and have antennas...", never mind that the antennas may actually be useful for something). But there's nothing fundamental about Smalltalk that requires an image, c.f. there are a few Smalltalks that don't make you use one (e.g. Smalltalk/X). It's just frozen state, many IDEs and editors allow you to freeze their state (e.g. Eclipse workspace), it would be a royal pain having to reopen the files you were working on manually every time, wouldn't it. I think the problem is that most newbies, when being introduced to Smalltalk, are immediately confronted with "the image" as if it was something fundamental, like they couldn't get any further until they grok it. But there's nothing preventing you from never saving the image. Just commit your source code (and it could just as easily be a common file based VC in the back there) and quit the image. Always start from a fresh one and load the code back in. In this mode there's (superficially*) no difference between Smalltalk and any other IDE, you write your code, you run it, debug it, commit it, etc. You can completely forget the image if you want, it's just that most seasoned smalltalkers (the ones doing the introduction) have learned to take advantage of the image and using it in all kinds of creative ways, so they want to pass the knowledge along and manage to freak the newbies out in the process. (*) the real difference between Smalltalk and other IDEs, that may or may not be an issue in any particular case, is that the IDE runs in the same memory space using the same code base as the application, so your development can crash the IDE, while other IDEs prefer to crash on their own :-). But I disagree that the image is some sort of technical obstacle to scalability, I think it's completely orthogonal. The only place where it's hard to ignore the image with the image based Smallltalks is deployment. At this stage the image is the "compiled object code", in the same sense that a shared library is "compiled object code". You can (and some do) deploy as a clean base image, load the application code on start and launch the application. That's no different from a java or python app, their base image is just burned into the VM. But it's so much easier to make that snapshot when all of this is finally loaded in memory and ready to run. It loads faster, there are no scattered files to hunt down in the dark corners of the filesystem, makes perfect sense in many (most?) cases. If people are freaked out that they don't need to mess with CLASS_PATH, or PYTHONPATH or what have you, well, it would be quite easy to "fix that", wouldn't it. You could say that every piece of software "has an image". When it is loaded it initializes its runtime structures, lays them out in memory and starts running. Nothing fundamentally different from the base image case, the "image" is just burned into the executable. If the VM was simply embedded in every saved smalltalk image and the resulting file was turned into an executable, you can't really tell the difference. The image just wouldn't be portable anymore. So I could agree that the image can be an obstacle to adoption if you rub it in people's face, but it can just as easily be mostly ignored. It's not significant unless you make it so in your development process.

8 12

Smalltalk for small projects only?
by Janko Mivšek 02 Feb '12

02 Feb '12

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

20 39

Building Cog with vm-display-fbdev
by Michael J. Zeder 01 Feb '12

01 Feb '12

hello everbody, I want to build the CogVM (latest revision from squeakvm.org/svn/branches/Cog), but with the vm-display-fbdev module (for linux framebuffer device) as default. Now I am a bit stuck in understanding the make process. Just leaving out the "--without-vm-display-fbdev" as argument to the configure script does not lead to it being included in the compile process. Also I don't find the exact location in the scripts, where to tell that the vm-display-fbdev should not only be included, but shall also replace the default display-X11-module. Thanks for your help, best regards Michael

3 4

4.3 - new Bug in Locale >> primTimezone?
by Jon Hylands 01 Feb '12

01 Feb '12

Hi everyone, I've ported some of my code into Squeak 4.3 (was running in 4.2 before), and ran into a weird issue comparing Date objects. When you execute "Date today", it produces a Date object with DateAndTime localTimeZone's offset, which is set upon image startup to be Locale >> offsetLocalToUTC, which in turn calls Locale >> primTimezone. On a 4.2 image, on both my XP and Windows 7 machines, that primitive returns -300 (minutes), which is -5 hours, which is correct (since I live in SW Ontario, Canada, which is EST). On a 4.3 image, with or without updates, that method returns -240, which is -4, which is clearly wrong at this point in time. - Jon

3 3

Fwd: [vwnc] Smalltalk for small projects only?
by Janko Mivšek 01 Feb '12

01 Feb '12

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

2 1

Daily Commit Log
by commits＠source.squeak.org 01 Feb '12

01 Feb '12

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2012-January/005180.ht… Name: Kernel-eem.668 Ancestors: Kernel-cmm.667 Rip out the "prevent me debugging myself" primitive 19 from ContextPart>doPrimitive:method:receiver:args:. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-January/005181.ht… Name: XML-Parser-ael.35 Ancestors: XML-Parser-bf.34 Fix needed to make removeElement: work in subclass XMLElement ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-January/005182.ht… Name: Monticello-bf.493 Ancestors: Monticello-cmm.492 use more sensible ordering when showing version history =============================================

1 0

The Trunk: Monticello-bf.493.mcz
by commits＠source.squeak.org 31 Jan '12

31 Jan '12

Bert Freudenberg uploaded a new version of Monticello to project The Trunk: http://source.squeak.org/trunk/Monticello-bf.493.mcz ==================== Summary ==================== Name: Monticello-bf.493 Author: bf Time: 31 January 2012, 11:37:31.927 am UUID: bab611f2-407f-4a06-9168-5cc5180db0fc Ancestors: Monticello-cmm.492 use more sensible ordering when showing version history =============== Diff against Monticello-cmm.492 =============== Item was changed: ----- Method: MCAncestry>>topologicalAncestors (in category 'ancestry') ----- topologicalAncestors + "Answer all ancestors in topological order (that is, children always come before all their ancestors). If multiple such orderings are possible, arbitrate by time stamp." - ^ Array streamContents: + [:s | | frontier next | - [:s | | frontier f | frontier := MCFrontier frontierOn: self. + next := self. + [ frontier remove: next. + s nextPut: next. + next := frontier frontier detectMax: [:v | v timeStamp]. + next isNil] whileFalse]! - [f := frontier frontier. - s nextPutAll: f. - frontier removeAll: f. - f isEmpty] whileFalse] ! Item was changed: ----- Method: MCVersionHistoryBrowser>>infos (in category 'accessing') ----- infos + ^ infos ifNil: [infos := ancestry topologicalAncestors]! - ^ infos ifNil: [infos := ancestry withBreadthFirstAncestors]!

1 0

Fwd: [vwnc] Smalltalk for small projects only?
by Janko Mivšek 31 Jan '12

31 Jan '12

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

Another video tutorial
by Lawson English 31 Jan '12

31 Jan '12

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 1

Future of SCM (was Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?)
by Göran Krampe 31 Jan '12

31 Jan '12

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

6 7