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.
Dear World,
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.
Enjoy!
The Pharo Team
Recently, AITO (Association Internationale pour les Technologies Objets) announced that I received the Dahl-Nygaard Junior Award for my work on modeling and visualization of evolution and interplay of large numbers of objects.
It’s a great honor for me. And it’s a complete surprise. So much so that when I received the phone call I asked Eric Jul, the president of AITO, if he is sure he called the right person. Go figure.
I did not consider myself in the research game anymore. At least not in the research game I used to play. Since five years I am far from the writing papers business. I participate in program committees only occasionally. I am almost entirely focused on solving concrete engineering problems. I do not even go to academic conferences. And, I am not financed by any research entity either.
I just checked the list of previous recipients, and all of them were/are university professors. Except me. I clearly am not playing that kind of game. Hence the surprise of getting an award for my research contributions.
Talking about contributions, it is humbling to think that my work got through a process of nomination and selection by people I look up to. I had no idea that my work was regarded as meaningful in those circles.
Five years ago, when I left the ivory tower of academia and descended on the muddy industrial soil, I thought that I am leaving the research world. I also thought that the tools and techniques I saw and developed in research should unilaterally enlighten engineers. Little did I know that the mud comes with its own type of beauty without which nothing can grow. Getting my hands dirty was the best research decision I ever made.
I learnt rather painfully that there is a large gap between what researchers typically tackle and what engineers typically need. In essence, none of the tools I was accustomed to were useful for solving the concrete problems I encountered. They were solving somewhat similar problems, but not those I had. As a consequence, I started to build individual solutions. In each situation I applied the one method I knew: the scientific method. I drove decision making through analysis and experimentation. It was almost like during the research time, only this time I did not have to fabricate problems, and I had to deliver working executable solutions.
It was (and still is) both risky and rewarding. The risk came from using methods that were perceived as being unconventional. The reward came from the experiments I did and lessons I could learn. For example, as I built many analysis tools along the way, I noticed that there was no repeatable concrete solution. There were only classes of solutions such as a metric or a visualization, but no concrete metric and visualization had a high repeatable value. This observation led to the development of humane assessment through which I argue that software engineers have to build their own tools.
To validate my claim, I was stubborn enough to only build analysis solutions using Moose. I solved Java problems with a Pharo system. This was rather crazy at the time, but it consistently produced inexpensive solutions. I consequently could show how a proper platform can drive the cost of custom analyses close to zero. And since this worked on other languages, it was only natural to want to have the same power in the one programming language I enjoy. Hence, in the recent years I worked on building a new bread of development tools around Pharo that foster analysis and decrease assessment costs.
It might appear that I did much, but I argue that everyone is building impressive things in their own ways, only without necessarily distilling the lessons into a coherent theory. If I managed to reach any value, it is just because I applied discipline, I allowed myself to dream differently, and I had the patience of letting ideas brew for years. The course of nature did the rest. For example, because I noticed that the act of preparing and giving demos had a significant effect on how I designed systems. After 10 years of looking at this, I could formulate the demo-driven hypothesis and back it up with multiple case studies. I am doing similar experiments now with the influence of reflective principles on organizational design. You can try it, too. You might be surprised at the results.
I am still not sure whether what I do these days is research or just what engineering should be in the first place. Perhaps the distinction is not relevant anymore. Thinking about it I realize now that during my research years, I spent most of my time engineering, while since I am in industry, I spend a significant amount of time researching. We should reconsider the reasons that led to such a deep separation between engineering and research in our field. This chasm tends to make the two worlds artificially incompatible, and this benefits nobody. On the one hand, researchers need concreteness to anchor hypotheses to reality. On the other hand, engineers need to see the conceptual parts of their seemingly boring concrete problems. I can attest both that it is liberating to be exposed to concrete problems, and that there exist at least an interesting facet to any problem.
Working for 12 years around the same kind of projects might look like a tedious journey. Yet, it does not feel long at all. That is because I never worked alone. For the credit granted to me these days, I have to thank all the people that I had the privilege of working with. They aren’t few either. Just take a look at a picture with all those with whom I committed open-source code over a part of my journey (the picture was provided by Yuriy Tymchuk and it shows my commit interactions as seen on smalltalkhub.com until December 2013).
Add those with whom I worked on closed source projects. Add those with whom I interacted in no directly visible way. They all contributed to my evolution. I am lucky enough to be surrounded by brilliant people that make me uncover new inspiring things every day. This is a true gift that I do not take for granted.
The recognition that comes with an award like this one brings with it an overwhelming feeling. Yet, receiving an award is not what kept me going through this journey. Any significant journey can stumble on doubts and be sidetracked by luring paths. I had my share of those, and my inside fire could have not lasted so long without the warm support of my beautiful wife. One smile at a time, she and our joyful kids remind me that we are on an amazing journey whose most exciting part is yet to come.
How do you find innovation? How do you build it? And how do you bring it to fruition?
I have long been concerned with this topic, and I promote a simple approach called demo-driven innovation. Its main points are:
- Challenge your own assumptions.
- Design around a story.
- Demo to get feedback.
- Listen to uncover.
- Enable it all.
The essence comes from the realization that the main enemies of innovation are your own assumptions. Once you accept this, exposing these assumptions becomes a priority, and showing them through demo-able stories is the most important tool you have.
I am continuously surprised at how focusing early on the stories you tell yourself and others, rather than only on the technical details, makes your ideas leaner and suppler. Over the past decade, I had the opportunity to work with dozens of people and I found that it applies to many different situations like ranging from research to engineering, and even to management.
Now, demo-driven has just received a teaser website at http://demodriven.com.
If you feel teased and want more details, feel free to contact me.