As some of you might know, I’ve been doing an internship at INRIA (L’Institut national de recherche en informatique et en automatique — French Institute for Research in Computer Science and Automation) for a month now (and there’s one more to go).
Since my arrival in Lille, I’ve witnessed France win the world cup, the finish of one of the tour de France races, saw the coast of England from the seaside in France, rode a fully automated metro with a baguette in my hand, and travelled to some cities in both France and Belgium. But most importantly, during my internship I’ve been learning a lot of things from people who have a crazy amount of experience not just in programming, but in quality of the software development, since this is basically what my team at INRIA does.
The whole of RMoD team works in Pharo (a pure object-oriented programming language and a programming environment, source), and people who read this blog or know me personally are aware that I’ve been working with the group of people developing Pharo for a while (last year I participated in Google Summer of Code improving the rules in Pharo, more here). And I have known some of my teammates from last year’s conference in Slovenia, so the start of my internship has been pretty smooth. Learning with people who not only know how to make sustainable software but who are also incredibly welcoming and generous with their help and advice has been and continues to be one of the best experiences in my life. It is true that my university, UCU, tries to give us a lot of project experience from the start, but nothing beats actually working with an international team of engineers and researches on a tool that’s actually being used by a lot of people, and where the quality of the work you do will have a lot of impact on the community. So yeah.
Now, more about the technical side of my internship. I’m working on improving the code completion in Pharo. I’ve been looking into it a few months ago and there are some notes about it that can be found here, and then when I came to INRIA last month we also started off with looking at the old code. But then with time we decided it was easier to try and create a new completion engine, sometimes having a look as the old one worked, but mostly completely independent. And that’s mainly what I’m doing right now. I’m getting a lot of assistance from people on the team while I’m both discovering how to design a complex system and how to program in Pharo more effectively (because the possibilities it provides are actually ridiculously good; I often wish some of these things were as easy to do in other languages, but alas).
The main idea for the structure is to have three main classes: the matcher, the completer and the sorter. So far for the completer functionality I’ve developed a little completion engine that uses AST (abstract syntax tree) nodes information to complete strings it receives. Usually the place of the cursor is assumed to be at the end of the string but sometimes we also have an offset parameter which tells us where the cursor is positioned and which enables us to complete things in the middle of the command. For the matcher there is also a little visitor that collects all the fitting completion options based on different conditions (i.e. whether it’s a literal, message or variable node, and more options for each of them). Of course, perhaps one of the most exciting things about this project for me is that I’m getting to seriously improve my TDD (test-driven development) skills. Out of all the languages / programming environments I’ve worked in over the years, Pharo seems to be the most natural for TDD. And not only is TDD nice to do in Pharo, but it’s also the recommended approach to use when programming in it. And so often I would start with tests (with the help of my supervisors we think up of all the cases that could potentially be really important for the best implementation) and then actually program the functionality based on the already existing tests. All I have to do is to run the test, which without the existing implementation would fail and call a window of the debugger, where you can directly create a necessary class or method, write the necessary code, restart, continue, and you’ve done everything right then the test would pass and be made green, and then you move on to the next challenge. Not a day goes by without me telling myself that this is like how all the programming should be like.
Apart from that, for the sorter class implementation, with the help of the Strategy pattern I’ve developed some basic sorting functionality which will give you several options of how you want to do the sorting of the completion results. One of the ambitious ideas is to have the sorting by the closest items (for example, method in the current class then its superclass etc) or by the most recently created or modified elements, which will be cool to have but a bit tricky to implement. And then seeing as Pharo is a dynamic language, I will move on to type inference. Because we would definitely receive better completion results when, if we don’t know the type already, we can at least guess the type with some percentage of accuracy.
Independently, I’ve also designed a little UI tool that helps visualise the existing completion and see what else is needed in an easier way. Next steps would also include looking at the old code some more, either to find out how to better inject the actual code completion suggestion into the text (so far it’s only presented as a list) and implement this completion engine completely separately, or to see how it can be combined with the old system to make the most out of both.
I’m very excited and proud to be working on this project, as well as to be learning from and working alongside people with such an amount of knowledge and experience in software development and research. So I’m very thankful to everyone who made it possible for me to do this internship and everyone who’s helping me with my life in France, too :)