- Pharo-users - lists.pharo.org

Re: [Pharo-users] Smalltalk Argument

by Peter Fisk

Thank you Joachim! That is the most honest assessment of the situation of Smalltalk in 2017 that I have ever seen. And I agree with you 100%. We need a new Smalltalk which is both "cool" and can seamlessly integrate with all of the latest web technologies. I will be releasing a new Smalltalk framework very shortly called "Smalltalk Express". The interpreter is written in the "Go" language and can run on all of the major web platforms such as Google, Heroku, etc. I use Pharo to manage the Smalltalk code. Here is a new blog that I have started to discuss the project. https://smalltalkexpress.quora.com/ Also, I have reserved the web address "smalltalk.express" for use once the code goes live. There is a video in the blog post so you can get an idea of where things stand right now. -- Peter On Fri, Oct 20, 2017 at 3:23 AM, jtuchel(a)objektfabrik.de < 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 > > > -- > ----------------------------------------------------------------------- > 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 Dimitris Chloupis

Actually you need to read the small letters bellow the graph "% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it" which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am surpised its only 67% of Smalltalkers that actually love Smalltalk and that Rust comes first. I was expecting a 90%. But then Rust has been the most hyped language these past few years. But does not change the fact that maybe 99% of the coders have not even heard of Smalltalk and a 60% of Rust. The bottom line is that the excuses for not using a language can no longer stand in 2017 (1) But I wont find coders for it (2) But I wont find libraries for it (3) But I wont find documentation for it Let's take (1) , why you even need to find someone that already knows the language? Do we realise there are people with zero coding experience that have made built milti million dollar empires . Almost 2 decades ago I remember reading about q surfer that loved to surf but also made surf boards. So inside his naiveness said "well let's make an e-shop" and he made alone one of the first e-shops selling surf boards and he made millions. So we have this guy that knows nothing about coding, I think I remember him saying that he did not even know how to use a computer before, on one side that in a period of few years has made a multi million dollars software. On the other side we have experienced coders, that most likely have battled with code bases of millions of lines of code , university degree, masters and doctorate and they cannot do what a surfer did ? Seriously.... (2) That's my favourite , libraries. We live in 2017 when even my grandmother's language run on JVM and has JS compiler and we still debate libraries availability ? Seriously. You can use ANY library from ANY language and is not even hard. I made Pharo use Python libraries and it took me a few hundreds lines of code just to make a simple socket bridge. (3) This one is the most logical, even when I i started coding in Pharo and to be fair Pharo was still on very early releases there was minimal documentation and the one I found was outdated. Still no problemo, I am a coder, I can read code. You will be reading tons and tons of code anyway, documentation in any language will never take you far. Why ? Because the vast majority of users prefer the easy and generic features. A minority of people dive deep into a library and the ones they do rare document it. You are more likely to find specialised information in mailing and forums than in documentation documents. Of course even there you may get no answer so you end up testing and learning yourself. Wont mattter even if it is Java. Plus there are tons and ton of project made in languages very unpopular that did great, Ruby On Rails is an example. One library it was all it took to put Ruby on map. Even C was introduce through the Unix operating system. New language, out of nowhere and wait those people using an unknown language wanted to make one of the best OSes of all time. So no, even though I rarely get into a language debate because of how religious people , there is no for not using Pharo but any unpopular language out there. Because in the end what it will matter the most is the determination of the coder to output efficient code. If you are passionate about something nothing can stop you and especially these bad excuses. Pretty much the most important ingredient for any very successful software product. On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani <dellani(a)pobox.com> wrote: > 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

Bloc texts font size

by Steven Costiou

Hi, i am trying to set the font size of a BlTextElement, and i do not have much success. I use the following code to add the text element, where 'model' is a string. First, if the string is '0.0' then the font size is correct (see screenshot). But, if for example the value is '21.0' then the font size is wrong (see the other screenshot). I don't understand, i've tried variants but it seems to me that this code was the right way to do it. Sometimes, a '9' would be displayed at the correct font size, sometimes not. Any ideas ? text := BlTextElement new text: ((BrRopedText string: model) attributes: {(BrTextForegroundAttribute paint: (Color green alpha: 0.8)). (BrFontSizeAttribute size: 60). (BrFontWeightAttribute weight: 50). (BrFontGenericFamilyAttribute monospace). "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); yourself. text constraintsDo: [ :c | c frame horizontal alignCenter. c frame vertical alignCenter ]. "text is added to a parent BlElement" self addChild: text Second, i don't have the impression that changing the font family does have any effect (but maybe its my local setup i don't know...). Steven.

Oct. 20, 2017

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

by Denis Kudriashov

So you want to stub message to *any* instance of class. Right? Conceptually, in Mocketry/StateSpecs way, it should looks like: (Instance of: Something) stub askForName willReturn: 'new'. or: (Kind of: Something) stub askForName willReturn: 'new'. But it will not really works. It will work only on instances which are already "stubbed". Making it really transparent will require crazy magic underhood. And I am not sure that it is really possible. Because generally it should cover existing instances and not just newly created during test. And for simple case: to automatically stub new instances their classes should be stubbed with special constructors. But system do not know what exact class side messages are constructors. So now you can just use simple mock which will be returned as simple stub from concrete constructor of your class: some := Mock new. some stub askForName: 'new'. Something stub new willReturn: some. I think it looks not not bad and no crazy magic is evolved. And of course you can replace mock with real instance if you want: some := Something new. some stub askForName: 'new'. Something stub new willReturn: some. 2017-10-20 14:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Yes, but in that case you stub messages to the class itself. For your > example it means: > > Something stub askForName willReturn: 'new'. > > Something askForName should be: 'new' > > > > 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> 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] using mocketry to mock subcall

by Peter UhnÃ¡k

Ah, right. I was expecting that other objects sending the message will receive the mocked result. Thanks, Peter On Fri, Oct 20, 2017 at 2:21 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Yes, but in that case you stub messages to the class itself. For your > example it means: > > Something stub askForName willReturn: 'new'. > > Something askForName should be: 'new' > > > > 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> 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] using mocketry to mock subcall

by Denis Kudriashov

Yes, but in that case you stub messages to the class itself. For your example it means: Something stub askForName willReturn: 'new'. Something askForName should be: 'new' 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > 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] 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