June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Thierry Goubier

Hi Esteban, Le 09/06/2018 Ã 08:37, Esteban Lorenzano a Ã©critÂ : > > >> On 9 Jun 2018, at 00:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Thomas Dupriez wrote >>> I got stuck countless times when >>> reading pharo code, because there was a message send to a variable I >>> didn't know the type of, so I couldn't know which method was being >>> called (because there were multiple methods with that name in the >>> system). So the only solution was to place a breakpoint and get that >>> method to be executed. >> >> That is an interesting perspective. I usually browse senders. This almost* >> always seems to work, except when the message selector is very generic and >> reused in different contexts (e.g. #next) > > then you can scope your senders. There are 99% of possibilities your message is sent within the context of the class or package you are looking for. Then a simple question is: - how do you scope your senders of command? A typical discovery / new user will do "senders of" first, and then discover the result is far too large. Now, does he has to backtrack on its exploration, choose a scope and call 'senders of' again? Thierry > Esteban > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > >

June 9, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Esteban Lorenzano

> On 9 Jun 2018, at 00:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Thomas Dupriez wrote >> I got stuck countless times when >> reading pharo code, because there was a message send to a variable I >> didn't know the type of, so I couldn't know which method was being >> called (because there were multiple methods with that name in the >> system). So the only solution was to place a breakpoint and get that >> method to be executed. > > That is an interesting perspective. I usually browse senders. This almost* > always seems to work, except when the message selector is very generic and > reused in different contexts (e.g. #next) then you can scope your senders. There are 99% of possibilities your message is sent within the context of the class or package you are looking for. Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

June 9, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Sean P. DeNigris

Thomas Dupriez wrote > I got stuck countless times when > reading pharo code, because there was a message send to a variable I > didn't know the type of, so I couldn't know which method was being > called (because there were multiple methods with that name in the > system). So the only solution was to place a breakpoint and get that > method to be executed. That is an interesting perspective. I usually browse senders. This almost* always seems to work, except when the message selector is very generic and reused in different contexts (e.g. #next) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 8, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Thierry Goubier

Le 08/06/2018 Ã 19:43, Nicolas Cellier a Ã©critÂ : > ... > > Yes, I don't know these languages enough, but it's indeed an extensible > specification of types (as expectations). > And this have values both for tools (compiling/browsing/static checks) > and humans. > Oh, and if it helps browser, then it helps humans, because browser is > for humans. Yes. And the browser is a very limited view of what is currently underway... > Our Smalltalk way would be to use many small Traits specifying the API > and have optional type hints using those Traits > (wasn't it a Strongtalk experiment?) Not sure. My view at the moment is that we have three ways to reach that point: expressing intent, or guessing it (or learning it). I think most code already contain enough information for the last two to work reasonably well, and approaches that forces you to add optional type hints (another level of information, that is) are rooted in the past. > But note that such static analysis imposes more limits on code than > necessary: > If I have some method like this: > myMethod > Â myInstVar doSomething > > Then a naive static inferencer will deduce that myInstVar can't be an > instance of MyPartlyPolymorphicClass > because it does not responds to doSomething . Yes. This is a first concern with types: they rejects incomplete programs (this is a point discussed in the paper Ben linked). > However, it's a lot more involved to analyze whether myMethod is ever > reached... > For example, if myMethod send was protected with a guard clause or > exception handling... > > mainMethod > Â Â Â myInstVar likesToDoSomething ifFalse: [^self]. > Â Â Â myInstVar doSomething > > anotherMethodSendingDoSomething > Â Â Â [myInstVar doSomething] onError: [IncorrectInput raise] > > IOW, since myMethod is not private, I can't guaranty that the library is > correct. > But a more clever analyzer could guaranty that a certain usage of that > library is. > Even in OCaml or Haskell, I'm not sure whether the type inference would > be powerful enough... Well, using it shows you it is rather impressive... Looking at 'myInstVar doSomething' it nicely express it as any class which answer to doSomething ... And that was the point where I restarted using Smalltalk instead ;) If a static thing with all its complexity (composite types, inheritence, modules, etc...) is just giving you the same duck typing as Smalltalk does, why do I have to put up with all the additional complexity for a so small gain? In the time of a short introductory course to OCaml, you understand that you are spending a lot of time dealing with types, unnecessary dealing with them, fighting with them, fighting with the type inference limitations, fighting with the confusing error messages, and that just to write smalltalk-like code in a smalltalk-like vm (in a less elegant syntax, to boot). > OK, maybe such liberality is not a good feature in the long term > i.e. necessitates implicit knowledge of crooked implicit pre-conditions > that message arguments must meet, > or render the understanding of code difficult, thus the testing, the > review and the modification worse, etc... I think a good system would probably learn from source code analysis and code traces (unit tests execution) to build a complete type model. I think machine learning is nowadays good enough to do that. Remember that you don't need it to be "proven sound", just good enough to help you. Remember that static type checking catches about 5% of the bugs, and probably just easy ones. And that an approximate type checker would probably catch them as well... > But it might be very useful for short term experiments. > Allowing partially correct programs/libraries is an important feature > for the exploring phase. Essential. Thats the power of dynamic langages and environment I'd even state that as a rule: - If you evolve a static type to a language, someone will create a dynamic typed equivalent of that langage (and a community will use it). With a corollary: - since the PL community is only doing static typing, the dynamic typed equivalent will be badly implemented by applying none of the PL research that could help. > > I have differently tainted colleagues still thinking that the type help them > > reading code... > > So, IMO, this assertion reflects the dominant culture rather than intrinsic > > merits. > > I still think that whatever name you use for your variables, you often > convey an idea of a type with your naming choices (i.e. felix is > probably a cat, probably not a dialog box....) > > Agree, type and semantics have some coverage, but as I wrote in answer > to Thomas, such inference requires prior knowledge. Yes. Or better inference. > I once had a colleague choosing completely arbitrary names for > temporaries (like the first name of his children). > Whatever the presence of type declaration (C++), this was really disturbing! > Bad names are bad names, and the type declaration does not help that > much in such case. Agreed. I'm sure someone or a tool can correctly type-guess out of my usual set of variable names... i is allways an int in my code :) Thierry > Nicolas > > > Thierry > > > Nicolas > > >

June 8, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Nicolas Cellier

2018-06-08 17:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 2018-06-08 16:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > > > > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> > >> Hi Ben, > >> > >> Interesting find. > >> > >> ... snip ... > >> > >> > Table 7 makes and interesting assertion that static types are more > >> > important > >> > for readability than preventing bugs. > >> > >> This one is in line with Dan Luu meta-study that static typing catches > >> at best a small proportion of bugs. > >> > >> Note that this is used in Smalltalk, when you write anInteger, aString > >> : you're using a form of typing for documentation. > >> > >> > > Exactly! > > > > And if you transpose this style to static typing you get things like > > Cat *theCat = new Cat; > > Being tainted, I always thought that is was noise... > > You'd better rename your variable felix;) > > This is a good example of noise :) > > What my concern would be is that advances in AI, like the Bayou > completion system, clearly shows that this is noise and that it can be > inferred. > > > Static typing may help the IDE (refactoring and navigating). > > My POV is thus that you enter this information for the tools, not for the > > humans (compiler, navigator, refactoring engine, ...). > > I used to believe that, and then I switched to a slightly different > view, thanks to some use of the OCaml type inference. In some cases, > when you design systems for reuse (for example libraries), you > understand that you're building code generic enough to accept a lot > more than the types you intent to allow (and even static type > inference manages to infer that fact for you). So, to ease reuse and > maintenance of your code, typing the API (either by naming convention > or by restricting types in OCaml) can be a good solution. > > Now, the real need for types is when you want to do high performance > compilation, because compilers are pretty bad at type inference (and > need very precise and limited types to produce efficient code). > > Yes, I don't know these languages enough, but it's indeed an extensible specification of types (as expectations). And this have values both for tools (compiling/browsing/static checks) and humans. Oh, and if it helps browser, then it helps humans, because browser is for humans. Our Smalltalk way would be to use many small Traits specifying the API and have optional type hints using those Traits (wasn't it a Strongtalk experiment?) But note that such static analysis imposes more limits on code than necessary: If I have some method like this: myMethod myInstVar doSomething Then a naive static inferencer will deduce that myInstVar can't be an instance of MyPartlyPolymorphicClass because it does not responds to doSomething . However, it's a lot more involved to analyze whether myMethod is ever reached... For example, if myMethod send was protected with a guard clause or exception handling... mainMethod myInstVar likesToDoSomething ifFalse: [^self]. myInstVar doSomething anotherMethodSendingDoSomething [myInstVar doSomething] onError: [IncorrectInput raise] IOW, since myMethod is not private, I can't guaranty that the library is correct. But a more clever analyzer could guaranty that a certain usage of that library is. Even in OCaml or Haskell, I'm not sure whether the type inference would be powerful enough... OK, maybe such liberality is not a good feature in the long term i.e. necessitates implicit knowledge of crooked implicit pre-conditions that message arguments must meet, or render the understanding of code difficult, thus the testing, the review and the modification worse, etc... But it might be very useful for short term experiments. Allowing partially correct programs/libraries is an important feature for the exploring phase. > I have differently tainted colleagues still thinking that the type help > them > > reading code... > > So, IMO, this assertion reflects the dominant culture rather than > intrinsic > > merits. > > I still think that whatever name you use for your variables, you often > convey an idea of a type with your naming choices (i.e. felix is > probably a cat, probably not a dialog box....) > > Agree, type and semantics have some coverage, but as I wrote in answer to Thomas, such inference requires prior knowledge. I once had a colleague choosing completely arbitrary names for temporaries (like the first name of his children). Whatever the presence of type declaration (C++), this was really disturbing! Bad names are bad names, and the type declaration does not help that much in such case. Nicolas > Thierry > > > Nicolas > > >

June 8, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Nicolas Cellier

2018-06-08 17:06 GMT+02:00 Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr>: > Hello, > I wanted to just write a quick comment, but it turned into an essay, > sorry. ^^ > > Le 08/06/2018 Ã 16:35, Nicolas Cellier a Ã©crit : > > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> Note that this is used in Smalltalk, when you write anInteger, aString >> : you're using a form of typing for documentation. >> >> Exactly! > > And if you transpose this style to static typing you get things like > Cat *theCat = new Cat; > Being tainted, I always thought that is was noise... > You'd better rename your variable felix;) > > Naming variables/arguments according to their type is only half a solution > I think. > Because there are actually two things I would like to know about a > variable/argument when reading code: its type and its meaning. > For example, knowing that an argument named "anInt" is an integer is nice, > but I would also like to know that it's the number of dice the method has > to roll. The two information are very useful to quickly understand the code. > > From what I've seen in Pharo, variables are usually named after their > meaning, while method argument are named after their type, but in an ideal > world I would like to know both the type and the meaning of both the > variables and the arguments. > > That's in my opinion one of the advantages of explicit types for reading > code: you write the type besides the variable/argument, so the name of the > variable/argument can describe its meaning and I have both informations. > > As the Dan Luu overview of studies tend to show ( https://danluu.com/empirical-pl/) one outcome is that, yes, types help to understand the program whatever the language. But types need not be static declarations. They can be in comments, in variable names, or other kind of documentation (that's one reason why class comments matters IMO!). Where this information lies in Smalltalk depends on the kind of variable. - For method arguments, semantic is given by accompanying keyword, like (name: aString). Since methods are short (they should be!) this association is mentally preserved while reading code. The problem comes when the argument can be polymorphic, like aValuable. My recommendation is to document expectations in method comment if it can't be inferred simply. "aValuable: any object understanding value: (a 1-arg block, a Symbol, an Association, ...)" - For instance variables, the name carries a semantic: my personnal recommendation is that the expected type SHOULD be documented in class comment. Once upon a time (st80 years) classes were quite well documented. If it's not the case, you have to browe the inst.var. writers, and thus you fall back to the last case of temporary vriables below. Lacking or incomplete class comments is a criterion of quality... - For temporary variables, you generally either instantiate a class, use a literal or send a message to another variable. In the later case, the problem is to infer the type of returned object, which might involve tracking message chains and class comments. My experience is that this participates to the flat learning curve for beginners. At the beginning, we spend a lot of time exploring the message flow, but once the library is familiar, we don't. But this process has a virtue: it gives a deeper understanding on how things work, and IMO it's beneficial in the long term. Personnally, it participated to the pleasure of programming in Smalltalk. Static typing may help the IDE (refactoring and navigating). > My POV is thus that you enter this information for the tools, not for the > humans (compiler, navigator, refactoring engine, ...). > > I have differently tainted colleagues still thinking that the type help > them reading code... > So, IMO, this assertion reflects the dominant culture rather than > intrinsic merits. > IOW, if you want to create a successfull language, just clone an existing > one :( > > I would agree with your colleagues. I got stuck countless times when > reading pharo code, because there was a message send to a variable I didn't > know the type of, so I couldn't know which method was being called (because > there were multiple methods with that name in the system). So the only > solution was to place a breakpoint and get that method to be executed. This > is not so easy (at least for me) in programs that are not really simple, > because: > 1) I need to have this method executed in its "normal use environment". I > can't just execute it with dummy values as argument, because that will > affect the values the variables will take. > 2) I can look into tests, but since I don't know the program, I have no > idea which tests to run to execute the piece of code. > So in general, it's either asking someone that knows how the program work, > or spending a lot of (annoying) time figuring out how the entire program > flows values to get the type of that one variable. > > Thomas > My experience is that the difficulty for inferring types comes from mega-morphic messages, or messages with false polymorphism. If things are difficult for a type inferencer, it will be difficult for us too. The advantage we have over an automated type-inferencer is if we can infer the type from the semantic, but that indeed requires prior knowledge of the library in use... My conclusion in the case you describe is that you have dealed with complex libraries (maybe with very abstract objects) that would hence deserve more documentation. The problem is worse if you are still in the learning curve for the base Smalltalk libraries (Collection, Stream, Number, ...). I will remind that one drawback of having static type declarations is to severly limit the evolution of the library. For example, once upon a time we had: Collection>>collect: aBlock But we then hacked: Symbol>>value: anObject ^anObject perform: self enabling things like (points collect: #x). If you have static declarations, you can't use such hack untill you rewrite all the type information in the whole Collection library and that's impracticle. Note that we did not take time to rewrite all the type hint information like this Collection>>collect: aBlockOrSymbol or with a neologism: Collection>>collect: aValuable The neologism would help only if properly documented, because it's not a class name, but rather an expectation that the object provides a certain API. The information that we can use a Symbol because (partly) polymorphic with BlockClosure is completely implicit. This has to be learned from tutorials or from reading code examples. One important quality in such case for the library is to have the most uniform rules possible for those conventions.

June 8, 2018

[Pharo 7.0-dev] Build #1027: 21225-Unknown-message-nonBlockTempsIn-sent-in-RBBasicLintRuleTestclasstempsReadBeforeWritten

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1027 was: SUCCESS. The Pull Request #1506 was integrated: "21225-Unknown-message-nonBlockTempsIn-sent-in-RBBasicLintRuleTestclasstempsReadBeforeWritten" Pull request url: https://github.com/pharo-project/pharo/pull/1506 Issue Url: https://pharo.fogbugz.com/f/cases/21225 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 8, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Thomas Dupriez

Hello, I wanted to just write a quick comment, but it turned into an essay, sorry. ^^ Le 08/06/2018 Ã 16:35, Nicolas Cellier a Ã©critÂ : > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > > Note that this is used in Smalltalk, when you write anInteger, aString > : you're using a form of typing for documentation. > > Exactly! > > And if you transpose this style to static typing you get things like > Â Â Â Cat *theCat = new Cat; > Being tainted, I always thought that is was noise... > You'd better rename your variable felix;) Naming variables/arguments according to their type is only half a solution I think. Because there are actually two things I would like to know about a variable/argument when reading code: its type and its meaning. For example, knowing that an argument named "anInt" is an integer is nice, but I would also like to know that it's the number of dice the method has to roll. The two information are very useful to quickly understand the code. From what I've seen in Pharo, variables are usually named after their meaning, while method argument are named after their type, but in an ideal world I would like to know both the type and the meaning of both the variables and the arguments. That's in my opinion one of the advantages of explicit types for reading code: you write the type besides the variable/argument, so the name of the variable/argument can describe its meaning and I have both informations. > Static typing may help the IDE (refactoring and navigating). > My POV is thus that you enter this information for the tools, not for > the humans (compiler, navigator, refactoring engine, ...). > > I have differently tainted colleagues still thinking that the type > help them reading code... > So, IMO, this assertion reflects the dominant culture rather than > intrinsic merits. > IOW, if you want to create a successfull language, just clone an > existing one :( I would agree with your colleagues. I got stuck countless times when reading pharo code, because there was a message send to a variable I didn't know the type of, so I couldn't know which method was being called (because there were multiple methods with that name in the system). So the only solution was to place a breakpoint and get that method to be executed. This is not so easy (at least for me) in programs that are not really simple, because: 1) I need to have this method executed in its "normal use environment". I can't just execute it with dummy values as argument, because that will affect the values the variables will take. 2) I can look into tests, but since I don't know the program, I have no idea which tests to run to execute the piece of code. So in general, it's either asking someone that knows how the program work, or spending a lot of (annoying) time figuring out how the entire program flows values to get the type of that one variable. Thomas

June 8, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Thierry Goubier

2018-06-08 16:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > 2018-06-08 14:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> Hi Ben, >> >> Interesting find. >> >> ... snip ... >> >> > Table 7 makes and interesting assertion that static types are more >> > important >> > for readability than preventing bugs. >> >> This one is in line with Dan Luu meta-study that static typing catches >> at best a small proportion of bugs. >> >> Note that this is used in Smalltalk, when you write anInteger, aString >> : you're using a form of typing for documentation. >> >> > Exactly! > > And if you transpose this style to static typing you get things like > Cat *theCat = new Cat; > Being tainted, I always thought that is was noise... > You'd better rename your variable felix;) This is a good example of noise :) What my concern would be is that advances in AI, like the Bayou completion system, clearly shows that this is noise and that it can be inferred. > Static typing may help the IDE (refactoring and navigating). > My POV is thus that you enter this information for the tools, not for the > humans (compiler, navigator, refactoring engine, ...). I used to believe that, and then I switched to a slightly different view, thanks to some use of the OCaml type inference. In some cases, when you design systems for reuse (for example libraries), you understand that you're building code generic enough to accept a lot more than the types you intent to allow (and even static type inference manages to infer that fact for you). So, to ease reuse and maintenance of your code, typing the API (either by naming convention or by restricting types in OCaml) can be a good solution. Now, the real need for types is when you want to do high performance compilation, because compilers are pretty bad at type inference (and need very precise and limited types to produce efficient code). > I have differently tainted colleagues still thinking that the type help them > reading code... > So, IMO, this assertion reflects the dominant culture rather than intrinsic > merits. I still think that whatever name you use for your variables, you often convey an idea of a type with your naming choices (i.e. felix is probably a cat, probably not a dialog box....) > IOW, if you want to create a successfull language, just clone an existing > one :( Thierry > Nicolas > >> By the way, I wrote for fun a small metalink-based run-time >> type-checker using method argument names. To be used when running unit >> tests :) >> >> Regards, >> >> Thierry

June 8, 2018

Re: [Pharo-dev] Weird Warnings at startup

by Sven Van Caekenberghe

> On 8 Jun 2018, at 16:52, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I think you have stored some settings that are not valid anymore for the new version. And it looks related to Compiler and Quality Assistant options. Ha, I never consciously put them there, I never save preferences. I deleted system-settings.ston in {preferences}/pharo/7.0 - Hurray for GT Inspectors ;-) Thank you. > On Fri, Jun 8, 2018 at 4:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > For a couple of days I am seeing a number of weird warnings at startup (via Growl/inform). Here is a screenshot: > > <Screen Shot 2018-06-08 at 16.45.23.png> > > It seems to go away once the image is in use. > > Sven > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

June 8, 2018