January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Old inspector and explorer

by Sven Van Caekenberghe

> On 05 Jan 2015, at 15:31, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > since youâre working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. > > For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and thatâs the road to mediocrity. > > In any case, sure, I can take notes on usability and share it with you. > > As a start and concrete example take anything that now requires one extra click or keystroke that before was not. Doru is anything but defensive. He literally asks for concrete examples. The goal is to make the workflow better for everyone. >> On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi Sebastian, >> >> I really do not see how your reply applies to the case at hand. >> >> If you have a concrete remark regarding how something is less useful now, please feel free to make it. >> >> Cheers, >> Doru >> >> >> >> On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> +1 >> >> Remember that âoldâ also means that it stands the test of time >> >> We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. >> >> Make productivity go up, never down! >> >> One additional click doesnât sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didnât have before. >> >> UX is King. >> >> No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) >> >> >> >> >>> On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> + 10000 >>> >>> Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. >>> Let people decide!!! >>> >>> Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! >>> I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. >>> >>> >>> Stef >>>> Doru, >>>> >>>> I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. >>>> To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. >>>> >>>> So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. >>>> >>>> Norbert >>>> >>>>> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >>>>> >>>>> Hi, >>>>> >>>>> I think there must be a misunderstanding. >>>>> >>>>> There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. >>>>> >>>>> There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. >>>>> >>>>> What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? >>>>> >>>>> But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> I will add basicInspect in Object so that we can get access to the old inspector. >>>>> I like that people can choose their tools! >>>>> I mentioned that 20 times but people do not care apparently. >>>>> >>>>> Stef >>>>> >>>>> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >>>>> >>>>> Is there a way to get the old tools via shortcut? >>>>> >>>>> I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. >>>>> To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. >>>>> >>>>> Norbert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>> >>> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

Jan. 5, 2015

Re: [Pharo-dev] On Twitter

by Sven Van Caekenberghe

> On 05 Jan 2015, at 15:28, horrido <horrido.hobbies(a)gmail.com> wrote: > > You're quite right. I guess I should focus on *one thing* right now before it > gets lost in the shuffle: Complete and publish my Amber tutorial. I have a > lot of work ahead of me in this one. Not that I have anything against Amber, but why pick that one ? Everybody seems to think something along the lines of 'JavaScript is very popular, if only we get on that platform and we'll be all set' - I don't think that is the case. Even Amber's original developer is now working full time on JavaScript, yet does no longer seem to use it. Also, on technical grounds it could be argued that Amber misses a number of critical Smalltalk features (thisContext, #become:). Furthermore, it is slower and has a only a limited IDE. Other than that, focus is good. > For the time being, I'll cut back on my tweets and Facebook and Google+.

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Sebastian Sastre

> On Jan 5, 2015, at 12:07 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >> >> but not putting it on Object would change the feature since you do want it returning self on that case. > > No. In that case, you want to use ifNil: , not ifNilOrEmpty:. > The only thing Object >> ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, > since it will lead to "are you a collection or single instance?" checks in almost every user of said variable. > Hi Henry, I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but Iâm treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) Whatever the case does your idea pass this test? testIfNilOrEmpty | stuff thing | stuff := nil. self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42. stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ]. self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42.

Jan. 5, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by Ben Coman

Maybe Phratch? Then maybe they start looking under the hood? http://www.phratch.com/ On Mon, Jan 5, 2015 at 10:31 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > Oh, I didn't realize you were focussed on older kids. I'm looking at > introducing Smalltalk at the elementary school level, getting kids hooked > on > Smalltalk at an early age. Probably a full-blown Pharo or Squeak image > would > be overkill. > > > stepharo wrote > > It depends what is the level you are looking for. > > We are working on lectures and books for second and third year > > university students. > > > > Now for kids I do not think that it matters if this the language or > > software is writting in Smalltalk. > > > > Stef > > > > > > Le 4/1/15 23:25, horrido a Ã©crit : > >> I am intrigued. Where can I find more info about Smalltalk education in > >> the > >> schools? I want to see what I can do in Canada. > >> > >> I presume there is a Smalltalk image customized for the classroom and > >> aimed > >> at elementary school students. That's what I'm hoping for. > >> > >> > >> stepharo wrote > >>> ESUG is about the community. Without community then it is terrible. > >>> We set up also a program for teachers. Now in the US there is nearly > >>> nobody teaching smalltalk and this is a pity. > >> > >> > >> > >> > >> -- > >> View this message in context: > >> > http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.h… > >> Sent from the Pharo Smalltalk Developers mailing list archive at > >> Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797846.h… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Jan. 5, 2015

Essay Topics

by horrido

As promised, here is my first list of essay topics. I would like to ask you to submit an essay on one of these topics. Multiple submissions are welcome; if they're good, they will all get published at Smalltalk Renaissance. I will edit the articles for grammar and style. You should look good after I'm done. There's no deadline, but obviously the sooner you can write them, the better. SRP is a fast-moving campaign. If you have other suggestions for essay topics, please let me know. Without further ado, here are the topics... Topic #1: How do modern IDEs, such as Eclipse and IntelliJ and Visual Studio, compare with the tried-and-true Smalltalk development environment? ----- Topic #2: It is the contention of some critics, including Robert Martin <https://www.youtube.com/watch?v=YX3iRjKj7C0> , that Smalltalk did not (does not?) address the needs of the enterprise. Present a counter-argument. Explain how Smalltalk can assist the enterprise in team development, in large-scale development, and in integrating with existing (typically Windows-based) infrastructures. Pay particular attention to the question of RDBMS usage, which is often critical in the enterprise. ----- Topic #3: Some critics complain that Smalltalk does not play well with existing file-based tooling. /Duh!/ Smalltalk is a "new" approach to IDEs and software engineering. We should be advancing this paradigm with new tooling, rather than falling back on the old again and again. Otherwise, things will never change for the better. Make a case for why we should embrace this change now, rather than waiting (for what?). Also, this webpage <http://thoughtstorms.info/view/smalltalkunix/view/smalltalk> poses an interesting argument against Smalltalk. Perhaps someone can tackle it. ----- Topic #4: In the age of multi-core processors and concurrency programming, how is Smalltalk addressing the concerns of developers? ----- Topic #5: How should we address the issue of compatibility (ie, fragmentation) among various implementations of Smalltalk? Does this issue hamper the creation of an ecosystem of libraries and shared code? -- View this message in context: http://forum.world.st/Essay-Topics-tp4797847.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by Sebastian Sastre

since youâre working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and thatâs the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not. > On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Sebastian, > > I really do not see how your reply applies to the case at hand. > > If you have a concrete remark regarding how something is less useful now, please feel free to make it. > > Cheers, > Doru > > > > On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: > +1 > > Remember that âoldâ also means that it stands the test of time > > We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. > > Make productivity go up, never down! > > One additional click doesnât sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didnât have before. > > UX is King. > > No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) > > > > >> On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> + 10000 >> >> Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. >> Let people decide!!! >> >> Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! >> I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. >> >> >> Stef >>> Doru, >>> >>> I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. >>> To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. >>> >>> So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. >>> >>> Norbert >>> >>>> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >>>> >>>> Hi, >>>> >>>> I think there must be a misunderstanding. >>>> >>>> There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. >>>> >>>> There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. >>>> >>>> What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? >>>> >>>> But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>>> I will add basicInspect in Object so that we can get access to the old inspector. >>>> I like that people can choose their tools! >>>> I mentioned that 20 times but people do not care apparently. >>>> >>>> Stef >>>> >>>> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >>>> >>>> Is there a way to get the old tools via shortcut? >>>> >>>> I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. >>>> To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. >>>> >>>> Norbert >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com <http://www.tudorgirba.com/> >>>> >>>> "Every thing has its own flow" >>> >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Jan. 5, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by horrido

Oh, I didn't realize you were focussed on older kids. I'm looking at introducing Smalltalk at the elementary school level, getting kids hooked on Smalltalk at an early age. Probably a full-blown Pharo or Squeak image would be overkill. stepharo wrote > It depends what is the level you are looking for. > We are working on lectures and books for second and third year > university students. > > Now for kids I do not think that it matters if this the language or > software is writting in Smalltalk. > > Stef > > > Le 4/1/15 23:25, horrido a Ã©crit : >> I am intrigued. Where can I find more info about Smalltalk education in >> the >> schools? I want to see what I can do in Canada. >> >> I presume there is a Smalltalk image customized for the classroom and >> aimed >> at elementary school students. That's what I'm hoping for. >> >> >> stepharo wrote >>> ESUG is about the community. Without community then it is terrible. >>> We set up also a program for teachers. Now in the US there is nearly >>> nobody teaching smalltalk and this is a pity. >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.h… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797846.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by phil＠highoctane.be

On Mon, Jan 5, 2015 at 3:04 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > El Mon Jan 05 2015 at 10:50:48 AM, phil(a)highoctane.be <phil(a)highoctane.be> > escribiÃ³: > >> Why not put that into a Trait? >> >> TDefaultValueIdiom>>ifEmptyOrNil: aDefaultObject >> >> So, if wanted,, one can put "uses TDefaultValueIdiom" (I am at a loss for >> a great name here, help!) and do as Sebastian proposes. >> >> This will prevent pollution of Object while at the same time being able >> to have the idiom available (and maybe with more than one form). >> >> > But you can't "hot plug" a Trait to Object to have this behavior > system-wide. Adding a trait involves recompilation AFAIR. > Well, adding a Trait to Object doesn't work (dangerous change). But we can add that to objects we do control. Which may be good enough. P. > > The only thing I'd argue against is the naming. > Otherwise is a very convenient method, when you go outside of the > Smalltalk island and interact with API's not very well crafted or desgned > to err on the "safe" side (empty collections instead o null), asking > whether an object isNull or empty in the same method is really convenient. > > If we get purists, nil shouldn't exist either [1] and they should be > replaced by domain specific abstractions representing the void/undefined. > But we know there is a use case for nil, as IMO, there is a use case for > isEmptyOrNil. > > However, whether you add it to Object in Pharo core image or not isn't > really relevant, whoever wants/needs it can add it afterwards. > > Regards, > > [1] > http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mista… > >

Jan. 5, 2015

Re: [Pharo-dev] On Twitter

by horrido

You're quite right. I guess I should focus on *one thing* right now before it gets lost in the shuffle: Complete and publish my Amber tutorial. I have a lot of work ahead of me in this one. For the time being, I'll cut back on my tweets and Facebook and Google+. -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797843.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Sebastian Sastre

> On Jan 5, 2015, at 12:00 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>>: >> >> one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. >> >> Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. >> >> About #thing being meaningless, sure, Iâve mentioned as general example. I donât see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) >> > My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. > > Norbert Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :) For example Mapless <http://sebastianconcept.github.io/Mapless> (and MiniMapless <https://github.com/flow-stack/MiniMapless>) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now. Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow. Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I donât say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present. Being able to reflect in real-time makes this possible. Is what makes easier to invent the future when they âtouch" each other. If someone else has to deal with the object and code with this uncertainty, you know youâre on the right place for personal mastery <http://www.cs.virginia.edu/~cs655/readings/smalltalk.html> to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself. This is actually a major reason to choose Smalltalk. Thanks again!

Jan. 5, 2015