Squeak-dev February 2012

squeak-dev@lists.squeakfoundation.org

62 participants
155 discussions

The Trunk: Kernel-cmm.669.mcz
by commits＠source.squeak.org 04 Feb '12

04 Feb '12

Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.669.mcz ==================== Summary ==================== Name: Kernel-cmm.669 Author: cmm Time: 3 February 2012, 5:55:11.175 pm UUID: 5ddec343-01ad-4e76-b32c-299fac68ec09 Ancestors: Kernel-eem.668 Introduced Timespan class>>defaultOffset. This is the offset that will be used for creation of all Timespans when an offset is not specified. When an offset is specified or involved in construction or calculation, the result is now produced in terms of the source offset. For example, Date today now produces a globalized date by default. However, "Date starting: (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours)" produces a Date.whose start is expressed in terms of UTC+2. The default defaultOffset is Duration zero so that Squeak will have fast, globalized Dates out of the box. Globalized Dates are common for applications. Legacy localized Dates can be obtained by evaluating "Date localize" so that, when an offset is not specified or otherwise involved in the input, the local offset will be used. =============== Diff against Kernel-eem.668 =============== Item was changed: Timespan subclass: #Date instanceVariableNames: '' classVariableNames: '' poolDictionaries: 'ChronologyConstants' category: 'Kernel-Chronology'! + !Date commentStamp: 'cmm 2/3/2012 17:30' prior: 0! - !Date commentStamp: '<historical>' prior: 0! Instances of Date are Timespans with duration of 1 day. + + Their default creation assumes a start of midnight of UTC to provide the fast, globalized Dates out of the box. The legacy behavior that creates Timezone-sensitive Dates can be used by sending #localizedDates. + ! - Their default creation assumes a start of midnight in the local time zone.! Item was changed: ----- Method: Date class>>julianDayNumber: (in category 'squeak protocol') ----- + julianDayNumber: aJulianDayNumber + ^ self starting: + (DateAndTime + julianDayNumber: aJulianDayNumber + offset: self defaultOffset)! - julianDayNumber: aJulianDayNumber - - ^ self starting: (DateAndTime julianDayNumber: aJulianDayNumber)! Item was changed: ----- Method: Date class>>starting: (in category 'squeak protocol') ----- starting: aDateAndTime + ^ self - ^ super starting: aDateAndTime midnight duration: Duration oneDay! Item was changed: ----- Method: Date class>>year:day: (in category 'squeak protocol') ----- + year: year day: dayOfYear + ^ self starting: + (DateAndTime + year: year + day: dayOfYear + hour: 0 + minute: 0 + second: 0 + offset: self defaultOffset)! - year: year day: dayOfYear - - ^ self starting: (DateAndTime year: year day: dayOfYear) - ! Item was changed: ----- Method: Date class>>year:month:day: (in category 'squeak protocol') ----- + year: year month: month day: day + ^ self starting: + (DateAndTime + year: year + month: month + day: day + hour: 0 + minute: 0 + second: 0 + offset: self defaultOffset)! - year: year month: month day: day - - ^ self starting: (DateAndTime year: year month: month day: day)! Item was changed: ----- Method: DateAndTime class>>julianDayNumber: (in category 'squeak protocol') ----- + julianDayNumber: anInteger + ^ self + julianDayNumber: anInteger + offset: self localOffset! - julianDayNumber: aJulianDayNumber - - ^ self basicNew - ticks: aJulianDayNumber days ticks offset: self localOffset; - yourself! Item was added: + ----- Method: DateAndTime class>>julianDayNumber:offset: (in category 'squeak protocol') ----- + julianDayNumber: anInteger offset: aDuration + ^ self basicNew + ticks: anInteger days ticks + offset: aDuration ; + yourself! Item was changed: ----- Method: DateAndTime class>>now (in category 'ansi protocol') ----- now + ^ self nowWithOffset: self localOffset! - | nanoTicks msm | - - nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. - - (LastTick < nanoTicks) ifTrue: [ - LastTick := nanoTicks. - ^ self todayAtMilliSeconds: msm]. - - LastTickSemaphore critical: [ - LastTick := LastTick + 1. - ^ self todayAtNanoSeconds: LastTick] - - " - [ 10000 timesRepeat: [ self now. ] ] timeToRun / 10000.0 . - - If calls to DateAndTime-c-#now are within a single millisecond the semaphore code - to ensure that (self now <= self now) slows things down considerably by a factor of about 20. - - The actual speed of a single call to DateAndTime-now in milliseconds is - demonstrated by the unguarded method below. - - [ 100000 timesRepeat: [ self todayAtMilliSeconds: (self milliSecondsSinceMidnight) ] ] timeToRun / 100000.0 . 0.00494 0.00481 0.00492 0.00495 - - "! Item was added: + ----- Method: DateAndTime class>>nowWithOffset: (in category 'squeak protocol') ----- + nowWithOffset: aDuration + | nanoTicks msm | + + nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. + + (LastTick < nanoTicks) ifTrue: [ + LastTick := nanoTicks. + ^ self todayAtMilliSeconds: msm offset: aDuration]. + + LastTickSemaphore critical: [ + LastTick := LastTick + 1. + ^ self todayAtNanoSeconds: LastTick offset: aDuration] + + " + [ 10000 timesRepeat: [ self now. ] ] timeToRun / 10000.0 . + + If calls to DateAndTime-c-#now are within a single millisecond the semaphore code + to ensure that (self now <= self now) slows things down considerably by a factor of about 20. + + The actual speed of a single call to DateAndTime-now in milliseconds is + demonstrated by the unguarded method below. + + [ 100000 timesRepeat: [ self todayAtMilliSeconds: (self milliSecondsSinceMidnight) ] ] timeToRun / 100000.0 . 0.00494 0.00481 0.00492 0.00495 + + "! Item was changed: ----- Method: DateAndTime class>>todayAtMilliSeconds: (in category 'squeak protocol') ----- + todayAtMilliSeconds: milliSecondsSinceMidnight + self deprecated: 'Use todayAtMilliSeconds:offset:.'. + ^ self + todayAtMilliSeconds: milliSecondsSinceMidnight + offset: self localOffset! - todayAtMilliSeconds: milliSecondsSinceMidnight - - "This is usually only during system startup..." - self waitForOffsets. - - ^ self basicNew - setJdn: DaysSinceEpoch - seconds: (milliSecondsSinceMidnight // 1000) - nano: (milliSecondsSinceMidnight \\ 1000 * 1000000 ) - offset: self localOffset - - " - [ 100000 timesRepeat: [ self fromMilliSeconds: self milliSecondsSinceMidnight. ] ] timeToRun. - "! Item was added: + ----- Method: DateAndTime class>>todayAtMilliSeconds:offset: (in category 'squeak protocol') ----- + todayAtMilliSeconds: milliSecondsSinceMidnight offset: aDuration + + "This is usually only during system startup..." + self waitForOffsets. + + ^ self basicNew + setJdn: DaysSinceEpoch + seconds: (milliSecondsSinceMidnight // 1000) + nano: (milliSecondsSinceMidnight \\ 1000 * 1000000 ) + offset: aDuration + + " + [ 100000 timesRepeat: [ self fromMilliSeconds: self milliSecondsSinceMidnight. ] ] timeToRun. + "! Item was changed: ----- Method: DateAndTime class>>todayAtNanoSeconds: (in category 'squeak protocol') ----- + todayAtNanoSeconds: nanoSecondsSinceMidnight + self deprecated: 'Use todayAtNanoSeconds:offset:.'. + self + todayAtNanoSeconds: nanoSecondsSinceMidnight + offset: self localOffset! - todayAtNanoSeconds: nanoSecondsSinceMidnight - - "This is usually only during system startup..." - self waitForOffsets. - - ^ self basicNew - setJdn: DaysSinceEpoch - seconds: (nanoSecondsSinceMidnight // 1000000000) - nano: (nanoSecondsSinceMidnight \\ 1000000000 ) - offset: self localOffset - ! Item was added: + ----- Method: DateAndTime class>>todayAtNanoSeconds:offset: (in category 'squeak protocol') ----- + todayAtNanoSeconds: nanoSecondsSinceMidnight offset: aDuration + + "This is usually only during system startup..." + self waitForOffsets. + + ^ self basicNew + setJdn: DaysSinceEpoch + seconds: (nanoSecondsSinceMidnight // 1000000000) + nano: (nanoSecondsSinceMidnight \\ 1000000000 ) + offset: self localOffset + ! Item was changed: ----- Method: DateAndTime>>asSeconds (in category 'smalltalk-80') ----- asSeconds "Return the number of seconds since the Squeak epoch" + ^ (self - (self class epoch offset: offset)) asSeconds! - - ^ (self - (self class epoch)) asSeconds! Item was changed: ----- Method: DateAndTime>>makeUTC (in category 'squeak protocol') ----- makeUTC + "Make the receiver's timezone UTC." - "Change the receiver's timezone to UTC. Like #asUTC, but modifies the receiver and is much faster." self primOffset: Duration zero! Item was changed: ----- Method: DateAndTime>>midnight (in category 'squeak protocol') ----- midnight + "Answer a DateAndTime starting at midnight of the same timezone offset as the receiver." + ^ self class basicNew - "Answer a DateAndTime starting at midnight local time" - - ^self class basicNew setJdn: jdn seconds: 0 nano: 0 + offset: offset! - offset: self class localOffset - ! Item was changed: ----- Method: Month class>>month:year: (in category 'squeak protocol') ----- + month: month year: year - month: month year: year "Create a Month for the given <year> and <month>. <month> may be a number or a String with the name of the month. <year> should be with 4 digits." + ^ self starting: + (DateAndTime + year: year + month: month + day: 1 + hour: 0 + minute: 0 + second: 0 + offset: self defaultOffset)! - - ^ self starting: (DateAndTime year: year month: month day: 1) - ! Item was changed: ----- Method: Month class>>starting:duration: (in category 'squeak protocol') ----- starting: aDateAndTime duration: aDuration "Override - a each month has a defined duration" | start adjusted days | start := aDateAndTime asDateAndTime. adjusted := DateAndTime + year: start year + month: start month + day: 1 + hour: 0 + minute: 0 + second: 0 + offset: start offset. + days := self + daysInMonth: adjusted month + forYear: adjusted year. - year: start year - month: start month - day: 1. - days := self daysInMonth: adjusted month forYear: adjusted year. ^ super starting: adjusted + duration: (Duration days: days)! - duration: (Duration days: days) - ! Item was changed: Magnitude subclass: #Timespan instanceVariableNames: 'start duration' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Chronology'! + Timespan class + instanceVariableNames: 'defaultOffset'! !Timespan commentStamp: 'dtl 7/11/2009 16:35' prior: 0! I represent a duration starting on a specific DateAndTime.! + Timespan class + instanceVariableNames: 'defaultOffset'! Item was changed: ----- Method: Timespan class>>current (in category 'squeak protocol') ----- current + ^ self starting: (DateAndTime nowWithOffset: self defaultOffset)! - - - ^ self starting: DateAndTime now! Item was added: + ----- Method: Timespan class>>defaultOffset (in category 'configuring') ----- + defaultOffset + ^ defaultOffset! Item was added: + ----- Method: Timespan class>>globalize (in category 'configuring') ----- + globalize + "By default, Timespans will be created with a local timezone's offset." + defaultOffset := Duration zero! Item was added: + ----- Method: Timespan class>>initialize (in category 'initialize-release') ----- + initialize + self globalize! Item was added: + ----- Method: Timespan class>>localize (in category 'configuring') ----- + localize + "By default, Timespans will be created with a local timezone's offset." + defaultOffset := DateAndTime localOffset! Item was changed: ----- Method: Timespan class>>new (in category 'squeak protocol') ----- new "Answer a Timespan starting on the Squeak epoch: 1 January 1901" + ^ self starting: (DateAndTime new offset: self defaultOffset)! - - ^ self starting: DateAndTime new - ! Item was changed: ----- Method: Year class>>year: (in category 'squeak protocol') ----- + year: aYear + ^ self starting: + (DateAndTime + year: aYear + month: 1 + day: 1 + hour: 0 + minute: 0 + second: 0 + offset: self defaultOffset)! - year: aYear - - ^ self starting: (DateAndTime year: aYear month: 1 day: 1).!

1 0

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

04 Feb '12

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2012-February/005183.h… Name: SystemReporter-cmm.19 Ancestors: SystemReporter-laza.18 Report Failed Tests and Errors as a list of debuggable expressions. =============================================

1 0

The Trunk: SystemReporter-cmm.19.mcz
by commits＠source.squeak.org 03 Feb '12

03 Feb '12

Chris Muller uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-cmm.19.mcz ==================== Summary ==================== Name: SystemReporter-cmm.19 Author: cmm Time: 2 February 2012, 11:16:52.731 pm UUID: 6d7357ee-74c3-4003-bb37-8598bf8ae096 Ancestors: SystemReporter-laza.18 Report Failed Tests and Errors as a list of debuggable expressions. =============== Diff against SystemReporter-laza.18 =============== Item was added: + ----- Method: SystemReporter>>printDebugExpressionFor:on: (in category 'private') ----- + printDebugExpressionFor: methodSignature on: aStream + | compiledMethod | + compiledMethod := Compiler evaluate: methodSignature. + aStream + nextPut: $( ; + nextPutAll: compiledMethod methodClass name ; + nextPutAll: ' selector: #' ; + nextPutAll: compiledMethod selector ; + nextPutAll: ') debug.'! Item was changed: ----- Method: SystemReporter>>reportTestRunner: (in category 'reporting') ----- + reportTestRunner: aStream + testRunner ifNil: + [ | runAllTests | - reportTestRunner: aStream - testRunner ifNil: [| runAllTests | runAllTests := UIManager confirm: 'Running all Tests\will take long time' withCRs. runAllTests + ifTrue: [ testRunner := TestRunner new runAll ] + ifFalse: + [ categoriesSelected remove: #SUnit. + ^ self changed: #categorySelected ] ]. + self + header: 'SUnit Results' + on: aStream. + aStream nextPutAll: testRunner statusText ; cr ; cr. + self + header: 'Failed Tests' + on: aStream. + testRunner failedList do: + [ : each | self + printDebugExpressionFor: each + on: aStream. + aStream cr ]. - ifTrue: [testRunner := TestRunner new runAll] - ifFalse: [ - categoriesSelected remove: #SUnit. - ^self changed: #categorySelected]]. - self header: 'SUnit Results' on: aStream. - aStream nextPutAll: testRunner statusText; cr; cr. - self header: 'Failed Tests' on: aStream. - testRunner failedList do: [:each | aStream nextPutAll: each; cr]. aStream cr. + self + header: 'Errors' + on: aStream. + testRunner errorList do: + [ : each | self + printDebugExpressionFor: each + on: aStream. + aStream cr ]! - self header: 'Errors' on: aStream. - testRunner errorList do: [:each | aStream nextPutAll: each; cr] - !

1 0

Are we getting trunk commit e-mails?
by Chris Muller 03 Feb '12

03 Feb '12

This would seem to be an essential part of our development process. Does anyone know how this process works?

3 3

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

Re: [vwnc] [Pharo-project] Smalltalk for small projects only?
by Alan Knight 02 Feb '12

02 Feb '12

I don't think it is a naive belief. There are actually differences between languages, and they do matter in the success of projects. I think the widespread disdain for Java in the development world at large is partly a recognition of this. This is just a bit of apocryphal and vaguely-remembered evidence, but I remember a discussion at a conference a few years back, and I think the participants were Alistair Cockburn and Martin Fowler. They were talking about "Design Starts" and successful completions of projects and the ratio between them as a metric. And were talking about various factors, but mentioned that in Smalltalk, though the number of starts was always low, the ratio of design starts to completions had been extraordinarily high. Equally apocryphal, I'm fond of saying that we have some large customers who are in the process of converting their applications from Smalltalk to another technology. Some of them have been doing so for many, many years. > ------------------------------------------------------------------------ > > Peter Hunsberger <mailto:peter.hunsberger@gmail.com> > 31 January, 2012 8:54 AM > > > 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 > > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > ------------------------------------------------------------------------ > > laurent laffont <mailto:laurent.laffont@gmail.com> > 29 January, 2012 3:37 AM > > > 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 > > > ------------------------------------------------------------------------ > > Janko Mivšek <mailto:janko.mivsek@eranova.si> > 28 January, 2012 10:46 AM > > > 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 > >

1 0

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

02 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

1 0

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

02 Feb '12

-------- Prvotno sporočilo -------- Datum: Wed, 1 Feb 2012 11:54:22 -0500 Od: Paul Baumann <paul.baumann(a)theice.com> Peter's point that "that there is [not] any inherent advantage in using Smalltalk development over any other language" is true by the criteria that he defined to judged it. It is funny to see "Smalltalk efficiency" is being framed by a standard of high resource requirements, and that Java having twice as many function points and four times as many cases for equivalent architecture and design was somehow a less relevant measure. One might observe that having such a wide variety of similar tools for a language like Java can indicate a limitation of reuse and extension. Smalltalk syntax is less restrictive in how a framework can be reused and extended; that is a better criteria to judge efficiency of the language. "Smalltalk" is syntax and a basic class library; it is not defined by the availability of a vendor features. IBM failures are more relevant than a Smalltalk failure. Large IBM projects of that era failed from Analysis Paralysis. A common goal was compliance with the latest buzz that IBM sold. There were a multitude of management styles in vogue at that time and all could be characterized as top-down management. The "60% heads down developers" were given static designs that had a high and continuous cycle of costs as theory met reality. Large amounts of dumb and redundant code would be generated early. Code inertia and resistance to change would preclude opportunity that is discovered later (like the ability to eliminate thousands of classes with a single reusable type). The result is as predictable as any top-down management style. All design problems were prevented from being fixed until they caused serious and recognizable problems. The management styles of the time promised theoretical efficiencies of scale that had been determined from earlier failures with less malleable languages than Smalltalk. Effectiveness of these feudalistic management styles had yet to be recognized as Dark Ages in the context of software development. Smalltalk does well when individual developers are given opportunity and responsibility, and to the extent that implementation is not restricted. Success with Smalltalk is about rewarding independent action that furthers an objective goal. Management of a Smalltalk project is about providing healthy incentives while minimizing barriers to change. Top-down management (sold by IBM) was more to blame than "Smalltalk". Smalltalk is successfully used for large mission-critical projects that affect global markets. It doesn't take even a dozen Smalltalk developers to do that. Smalltalk can be more efficient than other languages when a compatible management style is used. Smalltalk struggled through the Dark Ages of project management while more popular languages were developed outside of those conditions. Smalltalk is a victim of timing, management, and vision. The more popular languages provide opportunity of market more so than opportunity of syntax. Languages have evolved to be increasingly more malleable like Smalltalk; that is recognition of an advantage that Smalltalk has always had rather than proof that Smalltalk never was more efficient. Some people value opportunity of syntax that Smalltalk offers and have the vision to leverage that to a competitive advantage. Other people recognize that the availability of resources and frameworks can also be leveraged as an advantage over Smalltalk. It is possible to find success or failure either way. Paul Baumann *From:*vwnc-bounces@cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] *On Behalf Of *James Robertson *Sent:* Tuesday, January 31, 2012 14:10 *To:* VWNC NC *Subject:* Re: [vwnc] [Pharo-project] Smalltalk for small projects only? Ironically, I worked on a telecom project <in that domain> over a decade ago, with more people involved. Still in production, too. On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote: With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience: I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements. Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well. Now onto the main question posed here.... I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk. Peter Hunsberger On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont(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

1 0

keeping up with lively-kernel (morphic)
by Lawson English 02 Feb '12

02 Feb '12

It seems to me that the most active place where development of Morphic is taking place is in the context of Lively Kernel. Is anyone tracking what the LK people are doing and seeing how it can be backported, or used to create a new version, or integrated with the current version of Morphic or Cuis, etc? Lawson

3 3

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

Jump to page: