December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Comments or no integration: a simple choice for you

by HernÃ¡n Morales Durand

Hi Stef, To me class comments are not *that* useful. Most of the time I search explanations for contexts of use, which usually involves many classes and methods everywhere. I would remove packages which doesn't include at least some brief or general comments of the main classes or methods, this is less effort for a developer to remember and to document. Or it could be a start. HernÃ¡n 2010/12/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > I decided that I will not integrate any code that is not documented in Pharo. > > I strongly suggest to remove from Pharo-dev packages whose classes are not commented. > I'm not sure that I will look at code or answer question to code that is not commented. > We should change our mindset and it seems that we do not care, so we should take radical decisions: > Â Â Â Â less changes, less progress, more comments. > > And for once I will not bash the past. Smalltalk was always with methods fully documented. > We are just plain lazy and this is a shame. > > Stef > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Dec. 7, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Dennis Schetinin

2010/12/7 <csrabak(a)bol.com.br> > Sean, once you really get to metal subtleties and other nuances on the > language and syntax appear to bug your team. Have you ever heard of > John McSweeney's "Smalltalk âTrapsâ" pieceÂ¹? > Just to compare: http://www.javapuzzlers.com/contents.html :) -- Dennis Schetinin

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by HernÃ¡n Morales Durand

Tudor, You cannot convince someone which have already choosen an option. Cheers 2010/12/6 Tudor Girba <tudor.girba(a)gmail.com>: > Hi, > > I believe Smalltalk is perceived in the following way: > 1. Smalltalk is cool: 0.01% > 2. What is Smalltalk?: 19,99% > 3. Smalltalk is dead: 80% > > It is hard to convince the 2nd category to look at something new. Why should they? But, if it's hard to convince someone of something new, you need a miracle to convince someone that something is not dead. But, I think that a miracle like this can be administrated in the form of cool and kicking creatures and then tell them that they kick because of Smalltalk :) > > Cheers, > Doru > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Dec. 7, 2010

[Pharo-project] Creating a Dev Image

by Guillermo Polito

Well I've gone very far by now :). I created a configuration that at least loads :P. There are two problems so far: 1) ECompletion + TextEditor. ECompletion sends #model to TextEditor and It does not understands it. It is easily fixed adding the accessor. 2) Opening an omnibrowser throws a MessageNotUnderstood: TextMorphForShoutEditor>>findText. Which I will have a look tomorrow. The version of ConfigurationOfPharo is 1.2-beta2 I've to sleep now :). Tomorrow I'll open an issue for 1) if everyone agrees. With whom should I talk to get 2) fixed? Lukas, Alain? Cheers!

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by Guillermo Polito

Do we have marketing people? We need someone selling smalltalk to business people. :P In most cases (at least here in Argentina), the technology is decided by non technical people (like managers or customers) because they heard something called java and someone recommended it to them... Sad. On Mon, Dec 6, 2010 at 10:43 PM, <csrabak(a)bol.com.br> wrote: > Em 06/12/2010 18:21, Tudor Girba < tudor.girba(a)gmail.com > escreveu: > > > Hi, > > I believe Smalltalk is perceived in the following way: > > 1. Smalltalk is cool: 0.01% > > 2. What is Smalltalk?: 19,99% > > 3. Smalltalk is dead: 80% > > I think your assessment is not that far from reality... :-( > > > It is hard to convince the 2nd category to look at something > > new. Why should they? But, if it's hard to convince someone of > > something new, you need a miracle to convince someone that something > > is not dead. But, I think that a miracle like this can be > > administrated in the form of cool and kicking creatures and then > > tell them that they kick because of Smalltalk :) > > I agree on the feeling, I only think we all miss a very important > tactical point here: in what realm is Smalltalk superior to other > technologies? While we cannot answer this without hesitation and > without half escuses on why this 'superiority' don't show itself, > we're stuck to feelings and trying to present cherry picked 'examples' > of the qualities of our pet language/technology. > > The issue some cool and kicking creatures could have been done is not > enough, we need also to be certain we can get newcomers and have them > quickly up to speed in doing so. _That_ has lead other ('younger') > languages to their present status. > > -- > Cesar Rabak > >

Dec. 7, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

---- On Mon, 06 Dec 2010 14:52:53 -0800 jaayer wrote ---- > > > > >---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote ---- > >>Is anyone else bother[ed] by this inconsistency? > >Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary > and updates SmallDictionary's implementations of those messages to return the same value Regardless of what comes of those packages I uploaded, SmallDictionary>>remove: and SmallDictionary>>remove:ifAbsent: returning two different values is clearly a bug. Looking at it again, I was wrong about SmallDictionary>>remove:ifAbsent: returning the key; it does return the removed association. Which means at a minimum, SmallDictionary>>remove: only needs to have a ^ inserted at its beginning to fix the discrepancy. > - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and > #remove:ifAbsent: returning the key of the removed association. >The second package adds #testRemove and > #testRemoveIfAbsent to DictionaryTest (through a trait). > > >

Dec. 7, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by jaayer

---- On Mon, 06 Dec 2010 15:42:01 -0800 Igor Stasenko wrote ---- >On 7 December 2010 00:18, jaayer wrote: >> >> >> >> >> ---- On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko Â wrote ---- >> >>>On 6 December 2010 23:52, jaayer Â wrote: >>>> >>>> >>>> >>>> >>>> ---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer Â wrote ---- >>>> >>>>>Is anyone else bother[ed] by this inconsistency? >>>> >>>> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's implementations of those messages to return the same value - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and #remove:ifAbsent: returning the key of the removed association. The second package adds #testRemove and #testRemoveIfAbsent to DictionaryTest (through a trait). >>>> >>>> >>> >>>Hello, jaayer. >>> >>>The point about Dictionary inconsistency was raised multiple times before. >>>I was among ones of those who did that couple of years ago. >>>What can i say? >>>While it is much better to have consistency, >>>in fact it doesn't really changes much. I don't think that #remove: in >>>a form you proposed will be any userful. >>>I would really keep it simply #shouldNotImplement , because it is >>>unclear what is a least surprising behavior of this method for >>>Dictionary. >>>One might argue, that its more userful to make it same as #removeKey:, >>>other one could point that its should be symmetrical to #add: , >> >> #add: is not part of the ANSI protocol. It is, however, part of the ANSI protocol: >> add: >> addAll: >> remove: >> remove:ifAbsent: >> removeAll: >> >> One could make the argument that if Dictionary elects to implement part of it, it might as well implement the rest too. >> >>>but hey, then #do: should be also symmetrical to #add: , isnt? And so >>>it should iterate over associations , not just values. So, it is a can >>>of worms, once you open it , you can never finish the endless >>>discussions :) >>>It is just works in a way how we like (defined). It is like an >>>imaginary numbers in math where sqrt(-1) == i and basta :) >> >> Right... I wasn't planning on going there, but are we basically stuck with #do:, #select: #collect:, #includes: and other such messages operating on the Dictionary's values rather than its associations, forever? > >i think that most sane developers trying to avoid using inconsistent >methods with dictionaries , which inherited from Collection protocol. >So, instead of #do:, they using #valuesDo: , dict values select: >instead of dict select: and so on. >Because otherwise, what is the point of introducting #valuesDo:, which >completely duplicating #do: behavior? I see nothing, except an attempt >to introduce an explicit and more appropriate protocol for Dictionary. >And then ban Collection methods, with questionable behavior (depending >on who is questioning ;) ). I am not sure if you realize this or not, but "dict values select:" and "dict select:" do two different things. The former selects the values of "dict" into a new collection, as one would expect, while the latter actually creates a new dictionary by filtering the associations from "dict" based on the values of those associations. Another datum, assuming you were unaware of the difference, for the unintuitiveness and relative uselessness of the enumeration protocol of Dictionary. When have you ever really needed something like what Dictionary>>select: or Dictionary>>collect: provides? How often are you interested only in the values of a dictionary and not their corresponding keys? It may be ANSI, but it was poorly thought out, and it stinks. A Dictionary is an unordered collection of associations. That means #add:, #do:, #select:, #size, #includes: and other messages belonging to the basic protocol Dictionary inherits from Collection should operate on associations and not association values. At least, I suspect that's how it would be done if it could be done anew, without any concern for existing standards or backwards compatibility. >> >>>-- >>>Best regards, >>>Igor Stasenko AKA sig. >>> >>> >> >> >> > > > >-- >Best regards, >Igor Stasenko AKA sig. > >

Dec. 7, 2010

Re: [Pharo-project] Smalltalk in small steps ?

by csrabak＠bol.com.br

Em 06/12/2010 18:50, James Ladd < james_ladd(a)hotmail.com > escreveu: > Hi All, James, > As some of you may know I am writing a Smalltalk for the Java > Virtual Machine and it is coming along well. http://redline.st with > source on http://github.com > Recently I came across a series of blog posts by Peter Michaux on > Scheme from scratch and I wondered: > Would it be worth while for the Smalltalk community, and language > enthusiasts if I were to do the same with Redline Smalltalk, that > is, make each features implementation part of a blog post and a > 'work along' ? If you follow the same line than Michaux's I have to say it will be an expenditure of resources for a very small audience indeed. If you pay attention to the "Prerequisites" <quote> This exploration is not for novice programmers. It is a tutorial introduction for novice language implementor and enthusiasts from the perspective of a novice language implementor and enthusiast. </quote> > Would you like to see this and or work along with Redline ? It is interesting to see how issues of an implementation are being solved. You may get some ideas and suggestions from readers of your blog. HTH -- Cesar Rabak

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by csrabak＠bol.com.br

Em 06/12/2010 18:21, Tudor Girba < tudor.girba(a)gmail.com > escreveu: > Hi, > I believe Smalltalk is perceived in the following way: > 1. Smalltalk is cool: 0.01% > 2. What is Smalltalk?: 19,99% > 3. Smalltalk is dead: 80% I think your assessment is not that far from reality... :-( > It is hard to convince the 2nd category to look at something > new. Why should they? But, if it's hard to convince someone of > something new, you need a miracle to convince someone that something > is not dead. But, I think that a miracle like this can be > administrated in the form of cool and kicking creatures and then > tell them that they kick because of Smalltalk :) I agree on the feeling, I only think we all miss a very important tactical point here: in what realm is Smalltalk superior to other technologies? While we cannot answer this without hesitation and without half escuses on why this 'superiority' don't show itself, we're stuck to feelings and trying to present cherry picked 'examples' of the qualities of our pet language/technology. The issue some cool and kicking creatures could have been done is not enough, we need also to be certain we can get newcomers and have them quickly up to speed in doing so. _That_ has lead other ('younger') languages to their present status. -- Cesar Rabak

Dec. 7, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by csrabak＠bol.com.br

Em 06/12/2010 17:35, Sean P. DeNigris < sean(a)clipperadams.com > escreveu: > csrabak wrote: > > e persons needed about the same than the Java colleagues (which > > worked a complimentary part of the project) to become proficient > > and productive in Smalltalk. by the time I was "proficient and > > productive in Smalltalk," I had > > ered the equivalent of an OS! From threading, to windows, the main > > t loop - all things that were magically behind the scenes in C, > > C++, and > > Ruby to an extent (which at the outer GUI level was down in the > > same ). Whereas, it really did take only one reading to grok the > > syntax. > > Well, comparing C, even C++ which normally hasn't automatic garbage collection, is somewhat stretching the argument... but; even with those "idiosyncrasies" as soon the size of the application grows up, these perks of Smalltalk quickly become less noticeable, while on the other hand the fact Smalltalk being dynamic dispatched takes its toll in the needing of programmers attention to avoid the attribution of wrong objects to instance variables as there is no type checking... > csrabak wrote: > > Smalltalkers take sometimes at face value certain things that > > clash > > in al world: the famous simplicity of the syntax (which Stef's > > famous stcard example) of Smalltalk is mpletely flared by the > > overwhelming complexity of the class libraries. > > > fact that mastering anything takes time - is orthogonal to the book > e. The majority of books I came across in C++ (and needed copies of > in y office I worked, to the point where I got a $50 a month Safari > books cription) were related to the language, not the libraries - > full of , gotchas, and other advice to not trip over the > complexities of the uage itself - before even considering the first > library! Sean, once you really get to metal subtleties and other nuances on the language and syntax appear to bug your team. Have you ever heard of John McSweeney's "Smalltalk âTrapsâ" pieceÂ¹? > ease of use of a library is a function of the design skill of the > ary developers. But I bet you it was much easier to *write* that ary > than it would have been in a static language in a non-live ronment > ;-) While the libraries are for 'endogenous' use, yes, as soon we need to have functionality to put our apps in the same stand as the other technologies are right now, the issues start to become all the same... And them the advantages of Smalltalk as platform vanishes against ones more coupled to present technology. Have you tried to automate an Office application with any flavor of Smalltalk lately? Did you see the thread "Is there a good example of an app using SqueakDBX to output data?" All the simplicity of Smalltalk is lost as soon you need to fit the square peg in the round hole... :-| my 0.019999... -- Cesar Rabak [1] http://www.jmcsweeney.co.uk/computing/m206/traps.doc

Dec. 7, 2010