October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] using mocketry to mock subcall

by Peter UhnÃ¡k

Thanks Denis, that did the trick. But I thought that I can also mock at the class level (at least it was shown in the docs). Peter On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Peter. > > You should stub instance instead of class: > s := Something new. > s stub askFor... > > 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> > Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Hi, >> >> maybe I am missing something fundamental, because this seems like an >> obvious scenario >> >> I have a class Something with two methods >> >> Something>>askForName >> ^ UIManager default request: 'Name' >> >> Something>>name >> ^ self askForName , ' suffix' >> >> Now I want to mock out askForName, so I can run it automatically in >> tests... >> >> I've tried just stubbing it... >> >> SomethingTest>>testRenameStub >> Something stub askForName willReturn: 'new'. >> Something new name should be: 'new suffix' >> >> however it still opens the window to ask for the name, so the original >> method is being called. >> >> Right now I have to stub it with metalinks, which doesn't play well with >> some tools (hapao) >> >> SomethingTest>>testRenameMeta >> | link newName | >> link := MetaLink new >> metaObject: [ 'new' ]; >> control: #instead. >> (Something >> #askForName) ast link: link. >> [ newName := Something new name ] >> ensure: [ link uninstall ]. >> self assert: newName equals: 'new suffix' >> >> Thanks, >> Peter >> >>

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Stephane Ducasse

For the record at ESUG at Prague there was a really interesting discussion about namespace and some people working with newspeak mentioned that the namesapce there was a hell. And I trust these people. So good luck. For the record we are working and we are making progress on module system for Pharo but as I explained at ESUG this year. We do not want just to have a namespace. We want a system that does not kill the live programming experience. Imagine you have two browsers opened: - in N3 one one you inherit from a class A import from N1 - then in N1 you decide to move that class A to N2 Should the system discard all the subclasses from A n N3 because it cannot find anymore the class A? This is why we are working on - during year we remove harcoded reference to Smalltalk - Undefined classes (read the IWST 2017 paper) - new class definition - model for class definition - real life programming supporting module system. So each time I hear about namespace, I think that the best way to get a namespace system for Pharo is to help doing something else. This way we can concentrate on building a real working solution for Pharo. But since we have many other things to do then it takes time. Stef On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Absolutely. I have contemplated giving it a try. But when I go look at the > mailing list, it looks like such a lonely place. I still might give it a go. > It looks interesting. > > Jimmie > > > On 10/19/2017 05:20 PM, Ben Coman wrote: > > btw, are you aware that Newspeak is developed on top of the CogVM that > Pharo, Squeak, Cuis all share? > cheers -ben > > On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> > wrote: >> >> I watched this video a year ago and was intrigued. I have not thought >> about it deeply and do not know consequences of this model. However, Gilad >> is a smart man who has thought deeply about these things and has experienced >> consequences as a language designer. But it does sound interesting and I >> wonder if it would potentially be a solution to the namespace or modularity >> problems. >> >> https://youtu.be/pM0Hz4pFDZM >> >> He is talking about Newspeak in 2016 and what I refer to is its use of >> Nested Classes. >> >> No Global Namespace >> No Global Variables >> No Pool Variables >> No Class Variables >> No Class Instance Variables >> >> I have no idea if it would work for Pharo or what would be involved in >> implementing such. Or even if the community or leaders would even care to >> explore that direction. I have not seen it discussed here. >> >> Just wanted to toss his discussion of these ideas into the arena of ideas >> for Pharo. >> >> Jimmie >> >> >> >> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: >>> >>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>>>> >>>>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>>> >>>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>>>> >>>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>>> someone seriously on namespaces until he can cite those faithfully. >>>>> >>>>> Let's start with the misconception that namespaces are about >>>>> modularisation >>>>> >>>> +1 >>> >>> +1 to this as well. >>> >>> Having modularization is like having security, very hard to add them >>> later if you didn't include it in the original design. >>> >>> I'm using VisualWorks these days, and I find its namespaces something >>> more of a hassle than a real use. >>> >>> If we could name Classes with a dot, that could solve most of what >>> namespaces are used for in practice: avoiding name colissions. >>> That's why most of the popular frameworks have prefixes like Zn, WA, >>> RB, and so on and so forth. But now I'm used to prefixes, I don't need >>> them. :) >>> >>> Modularity is a different beast, if you look at how some modules work >>> in JS, like AMD, you see that in practice they avoid collisions by >>> importin what they need from a module, and assign it to a "namespace" >>> (it is not, but works as such), so they get modules first, and >>> namespacing later. >>> >>> Regards, >>> >>> Esteban. >>> >> >> > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by stephan

On 20-10-17 09:23, jtuchel(a)objektfabrik.de wrote: > And, to be honest: what is it we actually are better in by using Smalltalk? Making software that stays maintainable. It might be survivor bias, but smalltalk systems continue to be maintained by far smaller groups of developers than competing technologies. Stephan

Oct. 20, 2017

Engineer Position 1 year

by Stephane Ducasse

Engineer Position 1 year INRIA RMoD are looking for a full-time engineer for helping with developing Pharo in the context of IoT.The focus of this job is "Pharo on embedded and mobile devices for the internet of things" With Pharo, we have developed over the last two years an interactive, remote development environment. It allows embedded, headless software running on typical raspberry pi class hardware to be developed and debugged in an interactive way. It allows programmers to explore and change running headless embedded programs from their desktop development machine. The next step will be to extend this infrastructure to cover the use case of industrial use: Deployment. We want to build a middle-ware to manage, authenticate and script deployed Pharo embedded installations. The engineer will help to develop the Pharo IoT infrastructure, especially with a focus on industrial use: Â·I mprove Pharo for a platform with an industrial focus. Â· Work on a middleware to manage deployed Pharo instances. Â·Realize two small demos: First, as an industrial IoT example, a demo deployed on 20+ devices. Demo 2: Pharo deployed on multiple mobile autonomous robots. Â·Help with creating a website for PharoIOT. We are looking for a candidate with some prior experience with Pharo. In addition: Â· Knowledge in Dynamic Languages (Pharo is a plus but not required) Â·Experience with embedded development is a plus but not required Â·English Work in a research lab, but no paper writing, no teaching, no administration. In addition: Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) Try a lot of good beer (our office is just 10km from the border to Belgium) Program with Pharo all day! Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). Duration: 12 + 12 months Starting date: Feb or March 2016 Salary: 2600-3200 euros brut (french brutto = potentially one month of taxe per year) / month, depending on experience - (56000 Euros paid by the employer before any taxes). Location: Lille (no remote job possible) More about Pharo: http://www.pharo.org INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

On 10/20/2017 10:38 AM, Pavel Krivanek wrote: > > > 2017-10-20 10:20 GMT+02:00 Marten Feldtmann <itlists(a)schrievkrom.de > <mailto:itlists@schrievkrom.de>>: > > I do not want to spoil the party (perhaps I've done this already) > - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should > "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > > As far as I understand it, the question was different. They asked, if > you use Smalltalk, would you like to use it the next year too (or > something like that). Then the number makes more sense. > You are right, look at the legend of the graphic: "% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it" Cheers, Paulo

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Pavel Krivanek

2017-10-20 10:20 GMT+02:00 Marten Feldtmann <itlists(a)schrievkrom.de>: > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > As far as I understand it, the question was different. They asked, if you use Smalltalk, would you like to use it the next year too (or something like that). Then the number makes more sense. -- Pavel > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > > > > The second most loved language by 67% of developers surveyed cannot > simply > > be ruled out because of unfounded concerns. (Thanks again for the > > > -- > Marten Feldtmann > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

I also do not believe my eyes: https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted On 10/20/2017 10:20 AM, Marten Feldtmann wrote: > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > >> The second most loved language by 67% of developers surveyed cannot simply >> be ruled out because of unfounded concerns. (Thanks again for the >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Marten Feldtmann

I do not want to spoil the party (perhaps I've done this already) - but has anyone done a serious inspection of this number: 67%. They have interviewed 64000 persons and 67% of the people should "love" Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the user already using Smalltalk "love" that. By the way - the most loved platform is Linux (69%) ... Marten Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > The second most loved language by 67% of developers surveyed cannot simply > be ruled out because of unfounded concerns. (Thanks again for the -- Marten Feldtmann

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

I think you have nailed it, Joachim! The development environment is per se very productive and easy to use and learn but at the moment you need something that isn't present in your code library, things can get very hard. Well, that's not really new and not only a problem that concerns Smalltalk, but with the greater number of developers in other languages chances are that someone already wrote some code concerning your needs. Well I will go back to my coding here now ;-) Cheers, Paulo On 10/20/2017 09:23 AM, jtuchel(a)objektfabrik.de wrote: > First of all: I'd say the question itself is not a question but an > excuse. I am not arguing there are enough Smalltalkers or cheap ones. > But I think the question is just a way of saying "we don't want to do > it for reasons that we ourselves cannot really express". If you are a > good developer, learning Smalltalk is easy. If you are a good > developer you've heard the sentence "we've taken the goos parts from > x,y,z and Smalltalk" at least twice a year. So you most likely would > like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an > unwillingness of companies to get people trained in a technology. If > Smalltalk was cool and great in their opinion, they wouldn't care. > It's that simple. As a consultant, I've heard that argument so often. > Not ferom Startups, but from insurance companies, Banks or Car > manufacturers who spend millions on useless, endless meetings and > stuff instead of just hiring somebody to teach a couple of developers > Smalltalk. It's just a lie: the shortage of Smalltalk developers is > not a problem. > > And, to be honest: what is it we actually are better in by using > Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of > things that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as > compared to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment > I've used so far. But that is really only true for business code. When > I need to connect to things or want to build a modern GUI or a web > application with a great look&feel, I am nowhere near productive, > because I simply have to build my own stuff or learn how to use other > external resources. If I want to build something for a mobile device, > I will only hear that somebody somewhere has done it before. No docs, > no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as > cool as we like to make ourselves believe, this problem would be > non-existent. If somebody took out their iPad and told an audience: > "We did this in Smalltalk in 40% of the time it would have taken in > Swift", and if that something was a must-have for people, things would > be much easier. But nobody has. > > > I am absolutely over-exaggerating, because I make my living with an > SaaS product written in Smalltalk (not Pharo). I have lots of fun with > Smalltalk and - as you - am convince that many parts of what we've > done so far would've taken much longer or even be impossible in other > languages. But the advantage was eaten by our extremely steep learning > curve for web technologies and for building something that works > almost as well as tools like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like > Google's flutter in Smalltalk, I am ready to bet a lot on a bright > future for Smalltalk. But until then, I'd say these arguments about > productivity are just us trying to make ourselves believe we're still > the top of the food chain. We've done that for almost thirty years now > and still aren't ready to stop it. But we've been lying to ourselves > and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. > That is just an argument they know you can't win. The real question is > and should be: what is the benefit of using Smalltalk. Our > productivity argument is a lie as soon as we have to build something > that uses or runs on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by jtuchel＠objektfabrik.de

First of all: I'd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we don't want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer you've heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. A shortage of developers doesn't exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn't care. It's that simple. As a consultant, I've heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It's just a lie: the shortage of Smalltalk developers is not a problem. And, to be honest: what is it we actually are better in by using Smalltalk? Can we build cool looking web apps in extremely short time? No. Can we build mobile Apps with little effort? No. Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? Are we lying when we say we are so extremely over-productive as compared to other languages? I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I've used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what we've done so far would've taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. Smalltalk is cool, and the day somebody shows me something like Google's flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I'd say these arguments about productivity are just us trying to make ourselves believe we're still the top of the food chain. We've done that for almost thirty years now and still aren't ready to stop it. But we've been lying to ourselves and still do so. I don't think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can't win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. Okay, shoot ;-) Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

Dear Ben, Jimmie, Stephane, Tim, Dimitris, Marten, Davorin, Stephan, Sebastian and James, thank you for your feedback! Your excellent replies will sure help me with my "Smalltalk Argument". Obviously the language cannot be employed to efficiently implement solutions for problems in all domains, but it cannot simply be ruled out just because it is not so visible as other languages clamoring for the spotlight, as Jimmie pointed out. So far I got good results that can talk for themselves thanks to Pharo/Smalltalk. So the problem here, I believe, is really Smalltalk not being the "cool kid in town", which leads to a misperception of the language by the non-versed. This can be certainly be blamed to the lack of a good business oriented OSS Smalltalk years ago, as Ben guessed, but certainly there are other factors, which are not the scope of this discussion. The fact that a good OO-software developer can learn and start to get productive in Smalltalk in a relatively short amount of time, as pointed out by several of you, will make a good argument against the concerns of my colleagues here, which are mainly non-software developers. And surely the willingness to learn a new language is a sign to be looked at in a candidate, as pointed by you too. The second most loved language by 67% of developers surveyed cannot simply be ruled out because of unfounded concerns. (Thanks again for the information, Jimmie). I think there is really a great potential here, and surely there is a greater pool of developer candidates to "draw from" than one can initially imagine/see. Cheers, Paulo On 10/20/2017 12:17 AM, Ben Coman wrote: > > > On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani <dellani(a)pobox.com > <mailto:dellani@pobox.com>> wrote: > > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > > > When Smalltalk comes up on reddit, news.ycombinator, etc, > I often see comments "Used Smalltalk 10 years ago, loved it, but not > in my day job for years ..." > The guess the lack of a good business oriented OSS Smalltalk years ago > may be to blame. > Only supposition, but with the long history of Smalltalker, the pool > to draw from may be greater than first apparent. > The main problem may be that these people are not searching for > Smalltalk jobs due to the perceived availability of jobs. > > > There would obviously be some lag, but for longer term planning, talk > to your local education providers about introducing Smalltalk as the > "best" environment for teaching OO, > and then take the talented students from there.Â Consider contacting > the academic partners here... > http://consortium.pharo.org/ > > > Another approach depending on the project structure might be to "just" > prototype in Smalltalk (because its highly productive to explore a > domain with itsÂ built in data persistence) > and per Fred Brooks plan to throw it away to cleanly implement in a > mainstream language once you "know" what needs to be done.Â Â > I remember seeing one case reported here that the prototype worked so > well that the client didn't bother with the second step. > > > cheers -ben

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

Absolutely. I have contemplated giving it a try. But when I go look at the mailing list, it looks like such a lonely place. I still might give it a go. It looks interesting. Jimmie On 10/19/2017 05:20 PM, Ben Coman wrote: > btw, are you aware that Newspeak is developed on top of the CogVM that > Pharo, Squeak, Cuis all share? > cheers -ben > > On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com > <mailto:jlhouchin@gmail.com>> wrote: > > I watched this video a year ago and was intrigued. I have not > thought about it deeply and do not know consequences of this > model. However, Gilad is a smart man who has thought deeply about > these things and has experienced consequences as a language > designer. But it does sound interesting and I wonder if it would > potentially be a solution to the namespace or modularity problems. > > https://youtu.be/pM0Hz4pFDZM > > He is talking about Newspeak in 2016 and what I refer to is its > use of Nested Classes. > > No Global Namespace > Â Â Â No Global Variables > Â Â Â No Pool Variables > Â Â Â No Class Variables > Â Â Â No Class Instance Variables > > I have no idea if it would work for Pharo or what would be > involved in implementing such. Or even if the community or leaders > would even care to explore that direction. I have not seen it > discussed here. > > Just wanted to toss his discussion of these ideas into the arena > of ideas for Pharo. > > Jimmie > > > > On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > > 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > Am 13.10.2017 um 10:24 schrieb stephan > <stephan(a)stack.nl <mailto:stephan@stack.nl>>: > > On 13-10-17 09:55, Thierry Goubier wrote: > > Because namespaces, by essence, come with serious > issues. I won't take > someone seriously on namespaces until he can cite > those faithfully. > > Let's start with the misconception that namespaces are > about modularisation > > +1 > > +1 to this as well. > > Having modularization is like having security, very hard to > add them > later if you didn't include it in the original design. > > I'm using VisualWorks these days, and I find its namespaces > something > more of a hassle than a real use. > > If we could name Classes with a dot, that could solve most of what > namespaces are used for in practice: avoiding name colissions. > That's why most of the popular frameworks have prefixes like > Zn, WA, > RB, and so on and so forth. But now I'm used to prefixes, I > don't need > them. :) > > Modularity is a different beast, if you look at how some > modules work > in JS, like AMD, you see that in practice they avoid collisions by > importin what they need from a module, and assign it to a > "namespace" > (it is not, but works as such), so they get modules first, and > namespacing later. > > Regards, > > Esteban. > > > >

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Ben Coman

btw, are you aware that Newspeak is developed on top of the CogVM that Pharo, Squeak, Cuis all share? cheers -ben On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > I watched this video a year ago and was intrigued. I have not thought > about it deeply and do not know consequences of this model. However, Gilad > is a smart man who has thought deeply about these things and has > experienced consequences as a language designer. But it does sound > interesting and I wonder if it would potentially be a solution to the > namespace or modularity problems. > > https://youtu.be/pM0Hz4pFDZM > > He is talking about Newspeak in 2016 and what I refer to is its use of > Nested Classes. > > No Global Namespace > No Global Variables > No Pool Variables > No Class Variables > No Class Instance Variables > > I have no idea if it would work for Pharo or what would be involved in > implementing such. Or even if the community or leaders would even care to > explore that direction. I have not seen it discussed here. > > Just wanted to toss his discussion of these ideas into the arena of ideas > for Pharo. > > Jimmie > > > > On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > >> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>> >>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>> >>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>> someone seriously on namespaces until he can cite those faithfully. >>>>> >>>> Let's start with the misconception that namespaces are about >>>> modularisation >>>> >>>> +1 >>> >> +1 to this as well. >> >> Having modularization is like having security, very hard to add them >> later if you didn't include it in the original design. >> >> I'm using VisualWorks these days, and I find its namespaces something >> more of a hassle than a real use. >> >> If we could name Classes with a dot, that could solve most of what >> namespaces are used for in practice: avoiding name colissions. >> That's why most of the popular frameworks have prefixes like Zn, WA, >> RB, and so on and so forth. But now I'm used to prefixes, I don't need >> them. :) >> >> Modularity is a different beast, if you look at how some modules work >> in JS, like AMD, you see that in practice they avoid collisions by >> importin what they need from a module, and assign it to a "namespace" >> (it is not, but works as such), so they get modules first, and >> namespacing later. >> >> Regards, >> >> Esteban. >> >> > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Ben Coman

On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > > When Smalltalk comes up on reddit, news.ycombinator, etc, I often see comments "Used Smalltalk 10 years ago, loved it, but not in my day job for years ..." The guess the lack of a good business oriented OSS Smalltalk years ago may be to blame. Only supposition, but with the long history of Smalltalker, the pool to draw from may be greater than first apparent. The main problem may be that these people are not searching for Smalltalk jobs due to the perceived availability of jobs. There would obviously be some lag, but for longer term planning, talk to your local education providers about introducing Smalltalk as the "best" environment for teaching OO, and then take the talented students from there. Consider contacting the academic partners here... http://consortium.pharo.org/ Another approach depending on the project structure might be to "just" prototype in Smalltalk (because its highly productive to explore a domain with its built in data persistence) and per Fred Brooks plan to throw it away to cleanly implement in a mainstream language once you "know" what needs to be done. I remember seeing one case reported here that the prototype worked so well that the client didn't bother with the second step. cheers -ben

Oct. 19, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

I watched this video a year ago and was intrigued. I have not thought about it deeply and do not know consequences of this model. However, Gilad is a smart man who has thought deeply about these things and has experienced consequences as a language designer. But it does sound interesting and I wonder if it would potentially be a solution to the namespace or modularity problems. https://youtu.be/pM0Hz4pFDZM He is talking about Newspeak in 2016 and what I refer to is its use of Nested Classes. No Global Namespace Â Â Â No Global Variables Â Â Â No Pool Variables Â Â Â No Class Variables Â Â Â No Class Instance Variables I have no idea if it would work for Pharo or what would be involved in implementing such. Or even if the community or leaders would even care to explore that direction. I have not seen it discussed here. Just wanted to toss his discussion of these ideas into the arena of ideas for Pharo. Jimmie On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>> >>> On 13-10-17 09:55, Thierry Goubier wrote: >>>> Because namespaces, by essence, come with serious issues. I won't take >>>> someone seriously on namespaces until he can cite those faithfully. >>> Let's start with the misconception that namespaces are about modularisation >>> >> +1 > +1 to this as well. > > Having modularization is like having security, very hard to add them > later if you didn't include it in the original design. > > I'm using VisualWorks these days, and I find its namespaces something > more of a hassle than a real use. > > If we could name Classes with a dot, that could solve most of what > namespaces are used for in practice: avoiding name colissions. > That's why most of the popular frameworks have prefixes like Zn, WA, > RB, and so on and so forth. But now I'm used to prefixes, I don't need > them. :) > > Modularity is a different beast, if you look at how some modules work > in JS, like AMD, you see that in practice they avoid collisions by > importin what they need from a module, and assign it to a "namespace" > (it is not, but works as such), so they get modules first, and > namespacing later. > > Regards, > > Esteban. >

Oct. 19, 2017

Anoying bug fond in Artefact running in Windows 10

by casimiro.barreto＠gmail.com

When you insert a jpeg from a file, for some reason the file descriptor (stream) is kept open (at least in the Windows end of things). Then, if a second page is to be generated, the following error is shown: 'MessageNotUnderstood: receiver of "reset" is nil PDFJpegElement>>stream: JPEGReadWriter aJPEGReadWriter JPEGReadWriter(ImageReadWriter)>>on: nil Sample code: aPage := PDFPage new. imageStream := FileStream fileNamed: 'lsi-tec.jpg'. aPage add: ((PDFJpegElement fromStream: imageStream) from: 15 mm @ 20 mm; dimension: 40 mm @ 40 mm). imageStream close. Generated report is in annex The only way to recover is to close pharo, start it again. Then the file descriptor (stream) is released and it is possible to go on. Has anyone faced this problem? How to solve it? Best regards, Casimiro Barreto

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Jimmie Houchin

In addition to the excellent replies you have already received I would like to offer this from Stack Overflow. In their 2017 Developer Survey,Â Smalltalk was the second most loved language at 67% of developers surveyed. This is a regular occurrence. Now if you look at the rest of the survey you will see that these are not people using Smalltalk in their job. Smalltalk doesn't appear elsewhere in the survey. It isn't on the radar. However, developers love Smalltalk. Should a shop be open minded enough to use Smalltalk, I do not think it would be difficult to find people who would love to have that opportunity. A good developer can become proficient at Smalltalk in a reasonable amount of time. In addition to the natural virtues of Smalltalk. You also have wonderful communities eager and ready to help people join the family and become productive. The Pharo and Squeak mailing lists are very friendly, with plenty of extremely knowledgeable programmers ready to help. The other nice thing about Smalltalk is that it has history. It is not a fad. It is not an immature child. Many Smalltalkers have more years experience in Smalltalk than some of the creators of other languages have birthdays. There is a vast amount of knowledge and experience in this community that doesn't exist in most places. Because of this environment, an experienced programmer can receive wisdom and understanding and become a better programmer. Do not underestimate the value of gray beard Smalltalkers. A person can read the survey and come away thinking that Smalltalk is irrelevant. It is very relevant. It just isn't as visible as other languages clamoring for the spotlight. It is mature. It doesn't care to be the cool kid. Yes, OSS Smalltalks have some weaknesses that are actively being worked on. We haven't arrived. But we are well on the journey. And to quote our favorite prophet Alan Kay, "The best way to predict the future is to invent it." Join us. Help invent the future. Use Pharo to invent the future you want. There are people out there who want to be a part of this. But they have to pay the bills. Help more people pay the bills with Smalltalk. :) Jimmie On 10/19/2017 02:04 AM, Paulo R. Dellani wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] [Moose-dev] Cannot update GLMTabulator containing list with Separators

by Andrei Chis

Hi, Indeed, seems that #resetElements is missing in GLMFastListOutlineDataSource. I added in in the latest version of Moose/FastTable for Pharo 6.1. Cheers, Andrei On Wed, Oct 18, 2017 at 12:05 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > apparently it is not possible to update a GLMTabulator if it contains a > list pane with separators. Tested in P6 & P7. > > ``` > data := { { #one. #two. #three } asOrderedCollection. { #alpha. #beta } > asOrderedCollection } asOrderedCollection. > > browser := GLMTabulator new. > > browser column: #list; column: #actions. > > browser transmit to: #list; andShow: [ :a | > a fastList > withSeparators > ]. > > browser transmit to: #actions; andShow: [ :a | > a actionList > act: [ :actionList | data last add: #dynamic. browser update ] entitled: > 'Add Item'; > act: [ :actionList | data last remove: #dynamic ifAbsent: [ ]. browser > update ] entitled: 'Remove Item'. > ]. > > browser openOn: data. > ``` > > [image: Inline image 1] > > Thanks, > Peter > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

This is super easy. - You ask here, - Second then you try to grab the best open-minded guys you know and they will use the super cool mooc and learn Pharo in a week or two. You can tell them that we are not teaching Pharo and still students good in Java learn it before their internships. For a good dev it takes really no time to catch up. Stef On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Tim Mackinnon

I'm sure this comes up with many less main stream languages - I think there is a strong argument (particularly if we get the GitHub piece operating smoothly) that the language is so simple that what you creating is domain understanding (not language/tools prowess). Any good developer (particularly a Ruby, Groovy, JS, Objective C or even Python) dev will find Smalltalk a doddle. The complexity is actually in the domain. We also have a vibrant and active community that has been around a long time and is willing to help as well as lots of free online training materials. Put another way - you can use a language like Java but if you left, the complexity of build and deployment and understanding the domain is a huge hurdle even though it's s popular language. I've dipped in and out of Smalltalk throughout my career and a few years ago came back after 10+ years (so had basically forgotten most of it) and was stunned that I was productive in that team after 1 day once they showed me how to inspect items in the UI and navigate to tests. I've never encountered that on a project before. Tim Sent from my iPhone > On 19 Oct 2017, at 08:04, Paulo R. Dellani <dellani(a)pobox.com> wrote: > > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

I would have followed the Python approach. When Guido created Python , it did not try to convince his co-workers about how superior it was compared to other languages. At the time he did not intend to use it even as programming language. That worked to his advantage. Instead it used it for small tasks, usually tiny command line utilities that none would notice. But some did notice and expressed interest , they tried Python for small tiny tasks again mainly command line utilities. The co workers came back with suggestions how to improve it and the rest as they say itâs history. Any project has cracks that you can squeeze another language , the curious will the express interest and wonder âwhat this Pharo is ?â. I think that probably the best way to promote a language instead of trying to convince them how great it is. When language is used for such small tasks none will ask where they will find Smalltalk devs because itâs easy to learn any language for very simple tasks. Humans are curious by nature and they love a nice mystery. You donât have to convert an entire project to Pharo, the import thing is to ignite interest. Or as the saying goes âactions speak louder than wordsâ ;) On Thu, 19 Oct 2017 at 10:05, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by itlists＠schrievkrom.de

Hello Paulo, its a problem to get Smalltalkers - simple as it is. I had contacts with Smalltalkers who wanted to do Smalltalk-"only" jobs - thats impossible to guarantee in a smaller company and perhaps a mind I would not expect from Smalltalker. And the point about "Main Development Language" ... well, the other developers have also their "beloved" language and it would be a much better idea to put their "loved" together with your "loved" language. There are *very* good reason out there to write Windows FAT-Clients in .NET languages or even Mac/Linux/Windows Clients with Xamarin/Microsoft tools or even Java-world languages and HTML-Clients with some good JS-libraries. You have to have very good reasons (and this is NOT productivity) to argue against this and tell the other developers, that you develop superior solutions just because you are doing Smalltalk. This may be true for very specific libraries (and thats not only Roassal) - not available in other systems - but in the normal case, they will simply win (because of the huge amount software written in other languages). The only Smalltalk technology I found out to be worthwhile fighting for (because other are not able to offer a similar solution) today is an object oriented database (e.g. Gemstone/S). Perhaps the Smalltalk community should concentrate on the idea to make their technology open/accessable for other languages in an easy way. This is especially true for database vendors. Database vendors offering Java, C# and python object support and Smalltalk as an integrated script language - that could be a very good argument and a place where Smalltalk can survive. So, the answer is: don't depend on the language, look for developers working with more than one language and insert Smalltalk technology where you *really* get benefit. And the area where Smalltalk is so much better is getting smaller and smaller these days. Marten Am 19.10.2017 um 09:04 schrieb Paulo R. Dellani: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > -- Marten Feldtmann

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Davorin Rusevljan

One way to address this issue is to factor in your development grooming of young Smalltalk developers, which can act as pool of potential full developers for your project. If you can add some of your domain specific issues to their grooming, you could increase your project HR safety quite a lot. Davorin Rusevljan On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by James Ladd

Nice response Sent from my Commodore 64 > On 19 Oct 2017, at 7:02 pm, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > Hi Paulo, > > I think this is not the right question to ask. > The problem is not "Where to find Smalltalk developers?", the problem is rather > "How much effort does it take to help a good experienced OO developer to transition to Smalltalk?" > > OO developers have to steadily gain and learn new technologies and frameworks... > So why not Smalltalk? > Those developers that are not willing to learn a new language just because they consider the trade-offs of not finding a job in that field that easily, might not be the best choice for your team anyway... > > That is my experience... I know more developers missing the "Smalltalk experience" than those hating Smalltalk once they left a team... > > Sebastian > > >> On 2017-10-19 12:04 AM, Paulo R. Dellani wrote: >> Dear all, >> >> after using Smalltalk for several years I developed a passion for the >> language (how not to?), and Pharo is just so great to develop with. >> So thank you guys for keeping this wonderful project running. >> >> Unfortunately, it is not easy to always point out why Smalltalk >> should be employed as "main development language" in a team >> or for a project. In the last discussion of this sort I was confronted >> with the question "where are we going to get new smalltalk >> developers if our startup grows or if you go?". Well, I had no >> good answer to that. What would have you answered? >> >> Cheers, >> >> Paulo >> >> >> > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by stephan

On 19-10-17 09:04, Paulo R. Dellani wrote: > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? Regularly I go to the Esug Conference and the Pharo Days, and this year I had to cancel plans to go to Smalltalks. Those are places where I talk to smalltalkers, new and experienced. Every year there are good developers there who are looking for work, as intern, as a contractor or as an employee. By being there regularly I know who to talk to for different kinds of jobs, and for recommendations. Once in a while I also visit RMoD and HPI, to talk with people teaching smalltalk. The Pharo consortium maintains a list of consultants doing smalltalk work. For a company dependent on Smalltalk, I'd develop a systematic approach to ensuring attractiveness to smalltalk developers. Participation in the Pharo Consortium and presenting at conferences about open source contributions would be part of that, as might be defining research topics or summer jobs for students. Stephan

Oct. 19, 2017