Last week, I was at ECOOP in Uppsala to receive the Dahl-Nygaard Junior Award. On that occasion, I had the distinct pleasure of giving a keynote on Software Environmentalism. I do not know about others, but for me it was as emotional and exciting as I thought it would be.
Afterwards, I gave an interview over the phone for a piece of news that appeared on National TV (in Romanian).
It was the first time I gave an interview over the phone, and again it proved to become an educating experience. The main thing I learnt is that the more concise you are, the better chances you have to be quoted in the full. It’s like with tweeting, only in speech. And just like with a good tweet, it’s hard to be concise without preparation.
At the end of July I will have the pleasure of giving a keynote at ECOOP. This is a rare treat, and I intend to enjoy it fully. To make it more exciting, at least for me, I will adventure in wild territories and coin the idea of software environmentalism.
Here is the teaser abstract:
Software systems get larger and larger, and they are being created at an ever increasing rate. While this might appear to be great, we are facing a significant long run problem as we need to assess and recycle them.
In fact, the problem is already here: Engineers spend as much as half of the effort on understanding software systems to figure out how to approach subsequent evolutions and the percentage grows with the size and age of the system. In essence, software engineering is more about dealing with existing systems as it is about building systems.
Reverse engineering and program comprehension are established areas that deal with the problem of approaching existing systems. However, in spite of several decades of research and many proposed approaches, the state of practice still shows that, to a large extent, engineers rely on manual code reading as the preferred means to understand the system. The main reason for it is that most existing approaches tend to be generic and ignore the context of systems. This situation does not scale and it should not perpetuate.
We cannot continue to let systems loose in the wild without any concern for how we will deal with them at a later time. Two decades ago, Richard Gabriel coined the idea of software habitability. Indeed, given that engineers spend a significant part of their active life inside software systems, it is desirable for that system to be suitable for humans to live there.
We go further and introduce the concept of software environmentalism as a systematic discipline to pursue and achieve habitability.
Engineers have the right to build upon assessable systems and have the responsibility of producing assessable systems. For example, even if code has often a textual shape, it is not text. The same applies to logs and anything else related to a software system. It’s all data, and data is best dealt with through tools. No system should get away without dedicated tools that help us take it apart and recycle it effectively. For example, every significant object in a system should be allowed to have dedicated inspectors to reveal its various facets and interactions, and every significant library should come with dedicated debugging possibilities.
Who should build those tools? Engineers. This implies that they have to be empowered to do it, and that the cost of building those tools is manageable.
We need to go back to the drawing board to (1) construct moldable development environments that help us drill into the context of systems effectively, (2) reinvent our underlying languages and technologies so that we can build assessable systems all the way down, and (3) reeducate our perception of what software engineering is.
On June 4, I will give a talk at NDC Oslo about Pharo: Playing with live objects.
Pharo is the cool new kid on the object-oriented languages arena. It is Smalltalk-inspired. It is dynamic. It comes with a live programming environment in which objects are at the center. And, it is tiny.
But, most of all, it makes serious programming fun by challenging almost everything that got to be popular.For example, imagine an enviroment in which you can extend Object, modify the compiler, customize object the inspector, or even build your own the domain-specific debugger. And, you do not even have to stop the system while doing that.
In this talk, we show hands-on how live objects look like and we get to play with them in multiple scenarios. We leave it up to you to decide if it is serious enough.
More information about Pharo can be found at: http://pharo.org.
While on holidays in Romania, an old friend, Bogdan Bacila, convinced me to give an interview for the Digi 24 TV station about the Dahl-Nygaard Junior Award that I received this year. This resulted in a piece of news that was broadcasted at the national level, and it was later picked by other news aggregators like Yahoo for Romania.
It was the first time I talked in front of a camera about what I do and that in itself was an educating experience. But, the most interesting part was to observe how messages get picked and how they get transformed.
The interview itself took some 1 hour during which I did my best to explain what I do in laymen terms. However, the TV news slot took about 110 seconds. Obviously, some things had to be compressed.
I had the opportunity of going through the material before it appeared in order to provide my feedback and possible corrections. I did, but at the end that material was again edited at least once by another editor. The result was a highly truncated piece of content.
The message that mattered in the end was that I was the first Romanian to obtain the Dahl-Nygaard award that is one of the most prestigious in the field. This was surprising. I saw myself as the first winner of the award that is not a university professor, but I did not even consider me being the first Romanian to win the award as an important aspect of the matter. Obviously, for the audience it was. And this is what counted.
As for the details, they remain details. For example, the word Junior from Dahl-Nygaard Junior Award was left out, even though it does have a significant meaning for those that know it. For most, the important thing was that the name is mysterious enough to sound important. However, one thing that did make it in the material is that the award is one of the most prestigious and not the most prestigious in the field.
Another thing that was picked out of the several things I said was that I co-founded a research group while in Romania without any resources except from enthusiasm. I mentioned that I started it together with Radu Marinescu and I insisted that his name should be mentioned. Indeed, the longer news piece that came in writing does contain the full name, but the broadcasted one transformed the name of Radu into one of the assistants from Politehnica Timisoara. I found it important for me to not sound as if I would be the center of the universe, and specifically in this case, there was a memory of our common crazy dream of building on top of enthusiasm that I wanted to share and for which I did not want to be the only one to take credit. Yet, from the point of view of the newsmaker and the vast majority of the audience this is just a detail that did not survive.
Even the details about the meaning of my work were compressed to a maximum. Bogdan did a great job summarizing my work as helping engineers from all over the world to understand better what is hidden behind their own lines of code. Note the emphasis on all over the world that makes a difference from the point of view of Romanians. This was completed with me saying that this activity of understanding systems accounts for half of the development budget. 20 seconds. That was all, but I think it does capture the essence.
Interestingly, my opinion about how the research support in Romania has decreased significantly over the last couple of years occupied about the same space. The written news even emphasized that the political environment does have a significant influence on this evolution. This had a controversial nuance to it and it survived almost in full.
All in all, even if there are several things I would still change both in the text and in the images used, the news piece did a reasonable job in particular given the amount of time span. What made me particularly happy was that it ended on a positive note expressing my opinion that Romanians have a great potential, and that students should find and follow the passion in their life. This ending is representative for my thoughts.
Taking a step back, I learnt that seeing how details that I considered important go away can easily turn into sadness. But, if I consider the way the information is being consumed, it is more important to ask what part of the information has the most value for the audience while still being reasonable representative. When it comes to a presentation, everything else is secondary.
Pharo, the programming language, live IDE and core library has a new release!
The past year seemed short as we got busy building more than usual. Many things have changed in Pharo. Here are the highlights:
- The new modular Opal compiler is now the default compiler used in the system.
- The Athens vector graphics canvas is now integrated and it supports Cairo rendering on all platforms.
- Many tools have been rewritten using Spec, a new framework for building user interfaces.
- Versionner and Kommiter are two of the new development tools.
- RPackage, a new package mechanism got enhanced with tags and is fully integrated in the system.
- The debugger model was rewritten to become modular, the inspector received a bump to support multiple views, and the Nautilus code browser supports tags, search and lot more improvements.
- Morphic has seen many cleanings and improvements and the visual theme has been revamped.
These are just the more prominent highlights, but the details are just as important. We have closed 2364 issues in Pharo 3 (compared with 1727 issues in Pharo 2). Take a moment to go through a more detailed recount of the progress: ChangeLogs 3.0.
Pharo is improving on many fronts. Just take a look at the code city of Pharo (built with Pharo for Pharo). Every building is a class, and the red bricks represent the modified methods in Pharo 3.0.
Many things are changing but the system gets more stable. Moving from Pharo 2 to Pharo 3 is almost a matter of just loading the code.
Remember that Pharo is your platform. We thank all the contributors of this release: JeanBaptiste Arnaud, Simon Allier, Philippe Back, Clément Bera, Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Noury Bouraqadi, Johan Brichau, Camillo Bruni, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Bernardo Contreras, Ben Coman, Gabriel Omar Cotelli, Jordi Delgado, Tommaso Del Sasso, Gisela Decuzzi, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Erwan Douaille, Stephane Ducasse, Stephan Eggermont, Pablo Estefo, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Nahuel Garbezza, Leo Gassman, Lucas Giudice, Tudor Girba, Thierry Goubier, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Andre Hora, Alejandro Infante, Ricardo Jacas, Henrik Sperre Johansen, Denis Kudryashov, Pavel Krivanek, Juraj Kubelka, Laurent Laffont, Jannik Laval, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Stefan Marr, Mariano Martinez Peck, Roberto Minelli, Hernan Morales Durand, Eliot Miranda, Fernando Olivero, Nicolas Papagna Maldonado, Nick Papoylias, Nicolas Passerini, Vanessa Peña, Nicolas Petton, Alain Plantec, Guillermo Polito, Damien Pollet, Sergi Reyner, Jochen Rick, Benjamin Van Ryseghem, Ronie Salgado, Camille Teruel, Juan Pablo Sandoval Alcocer, Samir Saleh, Frank Shearar, Igor Stasenko, Aliaksei Syrel, Sebastian Tleye, Yuriy Tymchuk, Andres Valloud, Martin Walk, Hernan Wilkinson.
And many many more who contributed indirectly, by reporting bugs, participating in discussion threads, providing feedback...
Pharo 3.0 is the largest step we took since we started. Yet, it’s just a step. Expect more. Much more.
The Pharo Team