[Pharo-dev] Empirical Analysis of Programming Language Adoption

Ben Coman btc at openinworld.com
Sat Jun 9 04:21:42 EDT 2018

On 8 June 2018 at 23:06, Thomas Dupriez <thomas.dupriez at 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 at 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.

Has anyone looked at capturing all types assigned to variables while unit
tests are running?
What mechanisms do we have available that might help do this?

Then we might hovering over a variable to display the percentage actual
occurrence of types in that variable.
(A side effect is this could be an indication of test code coverage.)

> 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.

Makes me think a useful feature would be "what tests run that pass this
point", and run one of them breaking at "this point".
Then you'd quickly have a live stack to peruse.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20180609/c450739d/attachment.html>

More information about the Pharo-dev mailing list