August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: OverlyComplex

by csrabak＠bol.com.br

> El miÃ©, 19-08-2009 a las 00:04 -0300, csrabak(a)bol.com.br escribiÃ³: Miguel, > > Em 18/08/2009 22:25, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > > > >> Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey(a)whidbey.com > > > escreveu: > > >> [snipped] [snipped] > > Maybe you can tell us how much time would you estimate for a java (or > better yet, c++) version of Seaside or maybe of GLORP, that were made > for a significant part of their initial life for a single person. > This kind of repts have been used for year to attempt to prove a lot of non provable things: a similar argument was used to attempt to "demonstrate" that Linus Torvalds could have written the kernel for Linux [which applies for the requirement of yours "...significant part of their initial life for a single person."] Other languages/technologies all have histories, but see: this in logic is considered the fallacy of cherry picking, where an interesting and sufficiently high profile case can be shown off (a famous one is the developmet of the Viaweb site [http://en.wikipedia.org/wiki/Viaweb] The issue about productivity and discussions about differences thereof due languages is the _average_ productivity for the mass of active users. > I *am* times more productive in Smalltalk than in Java or PHP or C, even > if I can not show an *enterprise* benchmark the kind of ones that Garner > and friends so happily like to show in magazines and flyers. > I don't deny you can be, as I am. I can tell why it is in my case. If you and we cannot show hard data on an *enterprise* benchmark (I represent in this country one of the friends and used to work to the mentioned) you'll a *lot* of difficulty on convincing companies to embrace this technology. > So, a lot of people here can attest that indeed it is more productive to > work in Smalltalk taht in other languages, and that is the reason why > this *myth* persist. Maybe subjective, maybe not. We know that when we > work in Smalltalk and think how much more time/work/effort/boredom will > take to do the same on other languages. > My contribution to this debate is that if we don't bring demonstrable data to become facts, we will continue to be heard as some kind of hacker of a wacky or semi-defunct language (depending upon the thoughts of the listener). > > > Today, due the minute participation of Smalltalk in world production > > of new funcionality, you cannot find in any commercial or publicly > > available database on productivity (like ISBSG http://www.isbsg.org/) > > it mentioned by itself, but only lumped as OTHER 4GL). > > > > For a more or less uptodate and public reference, give a look at > > http://www.qsm.com/?q=resources/function-point-languages-table/index.html > > > > > > WTF. From the page: > > What is a gearing factor? The gearing factor is simply the average > number of Source Lines of Code (SLOC) per function point in the > completed project. It is calculated by dividing the final code count > for a completed project by the final function point count. SLOC counts > are logical, not physical line counts. > > Nuts, is this how the *enterprise* projects are evaluated? > That is absolute non-sense. What is the difference between logical and > physical line counts? The main point of the text you read is that the evaluations should be done asap in IFPUG Funtion Points or similar metric. The proviso thy put there is to allow different coding practices to be accomodated without inflating the outcomes. A lot of languages allow more than a logical statement to put in a single line, or for aesthetical reasons break a single statement in more than a single line. > > > >Or maybe there is something which > > >increasing their productivity? > > > > As you make the rept "are they all genious", I counter with: would you > > accept/believe that all managers who're responsible for development > > worldwide are "pointed haired bosses" which cannot discover if such a > > thing as 'silver bullet' existed? > > > > Most productivity is obtained due discipline, processes, trained and > > motivated people, and one of the last factors is programming language > > syntax. Programming language technology obviously has a role, > > otherwise it would be indifferent programming in (say) Smalltalk, > > versus (say) assembly. > > More non-sense, the process isn't a factor. The very same person can do > sometimes the same work in a week or in a night with coffee. A single *task* yes! A complete project like the Pharo revamp of a renewed Squeak *not*! That's where processes come into play and modify the outcomes. > WE ARE NOT machines producing nails in a predictable, constant over > time, unaffected by personal affairs. This factory model doesn't work > and has never worked. And the ever increasing complexity and irreal > methods created to try to measure people are a sad result of this way of > thinking. Agreed. It is not for this that development processes are for. It would become out topic here so I refrain of further discussion. > I believe that the work we do is more akin to the artistic disciplines. This kind of thinking is an attempt to evade the necessary debate. Most of software development is not of pure conception but turning into some usable artifact the conception. I would quote T.A.Edison on his saying about "1% inspiration and 99% transpiration.", processes is to make us more productive in 99% part of the job! > Will you try to measure the work done by a musician? or a painter? When [s]he is composing, probably not (but: get a look at the Movie and Advertising industries), when they're playing or the painter is applying the picture in church's roof, *yes*. > That is why the pointed haired bosses depiction and Dilbert cartoons are > so popular. I agree they are popular, but remember that geeks and nerd depictions are also popular! Regards, -- Cesar Rabak

Aug. 19, 2009

Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect?

by Schwab,Wilhelm K

Damien, Stef, How far should we go to clean it? A good start would be to simply remove the lookups from #printOn:, but my idea of a real fix is to move SocketAddress to be a subclass of Object so both the name and number can be independently (even lazily) resolved (not during #printOn: though). The move would mean that a socket address would no longer be a byte array. Dolphin copes with that by #asParameter which allows objects to customize how they appear to the outside world. If Pharo has a similar concept, the change would be easy; otherwise, some surrounding code would have to change to access the address' "number" aspect vs. simply operating on the address itself. With a small push in the right direction (re #asParameter or equivalent), I think I see what to do and will tackle it if you want me to do so. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Wednesday, August 19, 2009 9:19 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect? On Fri, Aug 14, 2009 at 9:19 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > SocketAddress>>printOn: looks like it does some questionable things, but I am fuzzy on what exactly is happening and what should be done about it. Â My thought would be that the address should have name and number aspects, that resolving would do the respective lookups, and that inspecting should not attempt the lookups. Â Do you agree? Â How broken is the implementation? > > I cant' say that I am thrilled about addresses being inherited from ByteArray - I suppose it can happily be the address and have an iv for the name, but what if one knows the name and later wants to resolve the number? Â This sounds like a job for a subclass of Object with named variables. Â Anybody agree or disagree? I saw some problems which appeared while printing a socket address on Windows (primitive has failed). So, cleaning that would be cool, thank you. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by Ken.Dickey

From: "Ellen.Dickey" <Ellen.Dickey(a)whidbey.com>Â Â (occasional) To: Pharo-project(a)lists.gforge.inria.fr Date: Yesterday 08:38:13 pm >>Note that there is no attempt to change oddities of Smalltalk syntax. I apologize to the list for calling Smalltalk syntax "odd". Coming from Scheme, I certainly know better. Â I am certainly for minimalist syntax. I prefer (< lowBound x highBound) to ((lowBound < x) && (x < highBound)) and (+ 1/2 1/3 1/6) to (1/2) + (1/3) + (1/6) What can I say, I am lazy and a bad typist. Note that Scheme has zero (count 'em 0) precedence rules and 3+1/2i parses as a single number, not three numbers, two math "operations" and a coercion. I did mention that I am only an occasional Smalltalk user and I have used a lot of programming languages. Also, I am used to posting to systems which let me preview and exit my postings. This was a draft. Again, I apologize. -KenD

Aug. 19, 2009

Re: [Pharo-project] WeakSet growth (issue 1047)

by StÃ©phane Ducasse

henrik please create new threads else people may miss your posts On Aug 19, 2009, at 4:41 PM, Henrik Johansen wrote: > I updated this issue with a solution which is simpler and less > intrusive than the one in Mantis, > and don't suffer from any Concurrency-issues not present already. > (You could argue they solve different problems, but the impact of not > recycling nilSlots is much less important with this patch, since > WeakSets won't tend to grow as large) > > I'd be grateful if someone would read my reasoning/test the patch, and > give feedback whether there are scenarios where it's not a valid > solution. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 19, 2009

Re: [Pharo-project] WeakSet growth

by Henrik Johansen

> From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > I'd be grateful if someone would read my reasoning, and give > feedback whether there are .... argh, this was meant to be ended with: "scenarios in which it does not lead to adequate performance". Cheers, Henry

Aug. 19, 2009

[Pharo-project] WeakSet growth (issue 1047)

by Henrik Johansen

I updated this issue with a solution which is simpler and less intrusive than the one in Mantis, and don't suffer from any Concurrency-issues not present already. (You could argue they solve different problems, but the impact of not recycling nilSlots is much less important with this patch, since WeakSets won't tend to grow as large) I'd be grateful if someone would read my reasoning/test the patch, and give feedback whether there are scenarios where it's not a valid solution. Cheers, Henry

Aug. 19, 2009

Re: [Pharo-project] Seaside Testing in Seaside one click image

by Damien Cassou

Hi Stan, 2009/8/15 stan shepherd <stan.shepherd414(a)gmail.com>: > Hi David, I ran up your most recent Seaside Testing in the one click > experience. It works fine, but one of the tests failed, because > WAAllTests has been changed. The attached version passes all tests > green. this is related to Seaside and not to Pharo. Please post to the Seaside mailing list: http://seaside.st/community/mailinglist -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 19, 2009

Re: [Pharo-project] question on browser buttons

by Damien Cassou

2009/8/14 Michael Roberts <mike(a)mjr104.co.uk>: > folks, just wondering what people think about the big 'blue' class > browser buttons. Â Pharo is looking really nice, but i tend to prefer > somewhat smaller, plainer buttons. Â e.g on the test runner, or the > preference browser. the browser ones are twice as high! Â they just > seem to stick out a bit. > > is it easy to switch off these blue buttons, or make all buttons consistent? Please open a bug report. Also, if you could try to fix it... :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 19, 2009

Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect?

by Damien Cassou

On Fri, Aug 14, 2009 at 9:19 PM, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > SocketAddress>>printOn: looks like it does some questionable things, but I am fuzzy on what exactly is happening and what should be done about it. Â My thought would be that the address should have name and number aspects, that resolving would do the respective lookups, and that inspecting should not attempt the lookups. Â Do you agree? Â How broken is the implementation? > > I cant' say that I am thrilled about addresses being inherited from ByteArray - I suppose it can happily be the address and have an iv for the name, but what if one knows the name and later wants to resolve the number? Â This sounds like a job for a subclass of Object with named variables. Â Anybody agree or disagree? I saw some problems which appeared while printing a socket address on Windows (primitive has failed). So, cleaning that would be cool, thank you. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 19, 2009

[Pharo-project] Fwd: Cuis :)

by StÃ©phane Ducasse

Begin forwarded message: > From: Juan Vuletich <juan(a)jvuletich.org> > Date: August 19, 2009 2:25:21 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: Cuis :) > > Hi Stef, > > StÃ©phane Ducasse wrote: >> I spent some times and I will regularly continue to pay attention >> that good fixes are integrated into pharo. >> I would be interested in the textMorph cleans. Do you have them in >> cs? > > You mean those in "Text cleanup and refactoring"? Yes... Just check > the updated CategoriesAndChangeSets.txt. On each new release of Cuis > I update it, and I also update the zip with all the changes. > >> Here is the list of my current inspection. >> http://code.google.com/p/pharo/wiki/CUISTreatedItems > > Good! Just a couple of notes: > - In "0207-AvoidCreatingDelays-jmv.1.cs Juan does not reset the > waitDelay to 50ms, this is suspect..." > Right. This was later fixed. > - In "0213-ForkAnswersNil-jmv.5.cs Lukas was afraid it could break > some code in external packages, so this change of API must be well > documented if ever adopted." > Code using the result value of #fork and friends is most likely > already broken. It would be great to have an easy way to spot those > users, but not having it, I prefer to move forward, and later fix > buggy code. For instance, I'm integrating Shout into Cuis right now. > Shout uses the returned value from #fork, so I had to fix it. So, it > indeed breaks code in external packages, and you need to make a > decision. > - In " 0173-offList-jmv.1.cs Already in Pharo + class ProcessX ? + > removeSelector #offList ", class ProjectX is the remains of class > Project. Cuis does not support Projects.

Aug. 19, 2009