#36 - Moldable Development: Tudor Girba
02/13/2019
Tudor Girba builds tools and techniques for improving the productivity and happiness of software teams. He currently works on the Glamorous Toolkit, a “moldable development environment” for Pharo, that developers can easily adopt to suit their needs. Tudor is a self-proclaimed “software environmentalist”, sounding the alarm about how quickly we create code, and how slowly we recycle it.
Programmers spend roughly 50% of their time reading code. But, as Tudor Girba likes to ask, “When was the last time you talked about how you read code?” Likely never. Isn’t that curious? We talk endlessly about static vs dynamic typing, agile vs waterfall methodologies, and unit vs functional vs integrated testing, but don’t spare any breath on the single activity we spend most of our time on.
Clearly we aren’t reading code for pleasure. Our goal is to read the minimum necessary to understand enough to make a decision. Software engineering is primarily a decision-making business, “rather than a construction business, which we optimized for, for the last 50 years.”
This bias is embedded in our tools. Where do we read our code? In an editor! If you are charged with solving a bug in the code, what do you do? You scroll. This is in stark contrast to how you’d approach an inconsistency in the database: you start with the query box, write a query, look at the data, refine the query, etc.
Yet code is data as much as the data in a database is data. It’s highly structured and can be just as massive. But because we we use a textual notation for input and are focus on the inputting, we use a text editor to understand our code. And because our text editor doesn’t have a query box, we don’t query. We scroll.
We shape our tools and thereafter our tools shape us.
John Culkin / Marshall McLuhan
The irony is we don’t make this mistake with the tools we build for others. We build web browsers, data analyzers, customer-relationship managers (CRM), content managers (CMS), media players, music sequencers, and game simulators. “The systems we build actively prevent end-users from ever seeing the raw data. And yet those end users make better decisions for it. So we in software know how to transform data problems into decision-making problems. That’s a skill we can utilize for rethinking the way we do our business.”
What would it look like to re-imagine software engineering as a decision-making? Let’s start with meetings. If software is about decision making, the goal of meetings should likewise be making decisions. “Do we go this way or do we go that way?” Tudor found that as a rule of thumb, decisions should take five minutes. If they take longer, stop the discussion and go back to gather data until the argument is clear one way or the other. The sum of this work is the Humane Assessment, a methodology for making software engineering decisions. In 2009, Tudor put his method to the test:
if this method would work, it has to work in the crappiest place that I can find or in the crappiest system that I can find. So I was actually looking around for one of those, and I picked one and then I led the development in that company for three and a half years to actually see that this thing actually works, and it did work.
This decision-making methodology is only half the battle. We still need the proper tools to gather the relevant data to support those decisions. In his consulting practice, Tudor built custom tools for each client. He assumed that eventually he’d be able to abstract over patterns and build a generalized tool. But he found no such cookie-cutter solution. He realized that “software is the most contextual thing we’ve ever created as the human species, and as a consequence we can’t build a generic software analysis tool.”
To be relevant, the tool must understand your specific context, for example the specifics of your build system or how you resolve dependencies. But there’s no off-the-shelf tool for that. The only people who understand your context in all its little details is you and your teammates. You need to make your own tools to understand your system.
But who’s got time for that? If the trade-off is reading code manually vs building myself a custom code-analysis tool, I’ll muscle through reading line-by-line. What if we could drastically reduce the time and cost of building our own tools?
Currently, Tudor and the team at feenk, works on the Glamours Toolkit. They call it a “moldable development environment,” because it empowers developers to quickly and easily adapt it to specific problems and contexts. Influenced by Smalltalk and Emacs, the Glamorous Toolkit aims to be an environment you can customize to help you understand your specific system.
They consider it a failure of their IDE any time you have to resort to drawing on the whiteboard to explain your system. The tool is designed to make it really cheap to build custom visualizers for whatever objects you want to inspect. It then saves these visualizers whenever it encounters another such object in the future. For that matter, they consider it a failing any time you have to leave the IDE for any reason. After all, the “I” stands for “integrated”. Googling for documentation, libraries and example code is suboptimal. The tool should have a built-in support for such questions. The worst offense is copying and pasting errors and hoping for an answer on Stack Overflow. That’s implicitly admitting that we don’t have any chance to understand our own problems. Code is only a black box today because we don’t yet have the right tools to look under the hood.
But the stakes are higher than 50% of your professional life.
Code lives for a long time. There are many companies that still run software on mainframes. The speed at which we can recycle old code is capped by the speed at which we can understand old code. Currently this is linear because we read code line-by-line. At the same time, the body of software grows exponentially year over year, way outpacing our ability to recycle it.
We mass-produce programmers to mass-produce code to eat the world with software before the next startup beats us to it. From this perspective, we behave very much like the plastic industry, focusing exclusively on production without regards to what happens when our product is no longer needed. Alongside the landfills of plastic, we are bequeathing our children mountains of code that nobody understands. Nobody wants their legacy to be code. Nobody likes legacy code.
Clearly the answer isn’t read faster. There’s simply too much code. Just like we built tools to recycle certain kinds of plastics, we need to build tools to help us better understand and recycle our old code. We need moldable development environments.
Transcript
Transcript sponsored by Repl.it
Corrections to this transcript are much appreciated!
SK:
Hello and welcome to the Future Of Coding. This is Steve Krouse. Today we have Tudor Girba on the podcast. Tudor is a really interesting person for me to interview here. If you haven't heard about him and his work, you're in for a real treat. Tudor is involved with Pharo Project, which is kind of like a Smalltalk-operating-system, modern-day-reincarnation thing. It's really cool. He's working on something called, the Glamorous Toolkit, which is built on top of Pharo, which is a development environment that looks nothing like any IDE you've ever seen before. It really rethinks the way programming is done in a, creative way. He talks about the vision behind that, and some of his other projects. It's a really fun conversation. It's one where, he does a lot of the talking. He's a really brilliant guy with a lot of counterintuitive and interesting things to say. I kind of just stay quiet and let him say it, say those things. I hope you enjoy. Before we bring in Tudor, I just am gonna say the quick message from our sponsor.
SK:
Repl.it is an online REPL for over 30 languages. It started out as a code playground, but now it scales up to a full development environment, where you can do everything from deploying web servers, to training ML models, all driven by the REPL. They're a small startup in San Francisco, but they reach millions of programmers, students and teachers. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. Email jobs@repl.it. R-E-P-L.IT if you're interested in learning more.
TG:
Now I bring you Tudor Girba. Welcome Tudor.
TG:
Yeah. Welcome. Thank you for having me.
SK:
Yeah. Thanks for taking the time to tell us about what you're working on. Before we get into what you're working on now, maybe, could you give us a bit of your background and your context as it relates to the future of coding.
TG:
Yeah sure. I've been into the area of software analysis, software evolution. I started my PhD and then post doc in 2002 until 2009. And then, 2009, I started to ... I created a method, which is the Humane Assessment. And then, went into industry to validate it. Basically, the idea of the method was to tackle the problem of code reading. I guess we go into this a little later, or better yet, of not reading code. Well, so three years ago, I ended up co-founding a company. Here we are.
SK:
Very cool. Yeah. I guess, let's start with this Humane Assessment. What was the goal behind that?
TG:
Right. Well, now it started from an observation. I found it really curious that in 2010, we would still have research papers saying that developers spend 50% of their time reading code. Well, what was curious about it was that, I could also read papers from the 80s that were saying basically the same thing. My question was, "What's the difference? How did we improve the situation?" Everybody seemed to agree that there was a problem. It also seemed that whatever we have tried, didn't really make the dent. Yeah, the question was, how do we change this?
TG:
Maybe, if after 30 years, whatever we tried didn't work, perhaps the way we looked at the problem was not quite, maybe not necessarily the right way, but perhaps a fresh view would have been in order. During my research, I led the work on this platform, which is called, Moose, it's a platform for software analysis, small software end data analysis. Basically, the longest living probably, such platform in research, it actually started, well, I think now ... When was it, '96? Long time ago. I started to work on it in 2002. The goal of that platform was to support research.
TG:
Essentially we needed to write papers about new approaches in software analysis and software evolution and software visualizations. We created a platform such as we can churn faster ideas in this field. It turned out that we ended up creating a platform with which we can create new analysis or even new kinds of analysis at a very rapid pace and at very low costs.
TG:
With this experience I said, "Well, okay, let's go in industry and find the problem for which to build the tool on which developers will click. They're life will be much better." I started with the first problem, the first case study or first real ... That time I was doing consulting. First consulting project to try to figure out some architectural problem, try to get the team to evolve it from there. And then, it got to second one and the third one and the fourth, and the fifth one.
TG:
The assumption there was, that there would be something that pops up as being repetitive. The only repetitive thing that I found was that nothing was repetitive. In order to be relevant, to create a relevant solution, I always had to tweak with tools. That was fascinating. Tweaking the tools means that there is no button. There's nothing to click on. If there's nothing to click on, it goes against this idea that you would give a cookie-cutter, that would be applicable to all systems.
TG:
I realized that perhaps that is the special thing with software. That's the basic observation, was that in fact, software is the most contextual thing we've ever created as human species, at such a small scale. As a consequence, there is no way we can predict this specific problems from the outside. When we look at the project from the outside, we don't know the exact problems that people will have inside that project.
TG:
We can predict the classes of problems. For example, I can say, with almost certainty that, in any project, there will be issues with dependencies or related with dependencies. Understanding some dependencies is important. How those dependencies, which dependencies, what kind of dependencies, how are they actually captured?
TG:
Most of the time, people just look for example, just take this simple thing of dependencies. We often just look at the source code. Let's say maybe it's Java, or I don't know, C# or JavaScript. You look at the calls in there. All right? You say, "Well, if this class or this method calls this other method, well, then all of a sudden it means that there's a dependency there. It's all fine, except that most systems that I'm looking at today have real significant independencies that don't look like that. There's a string in between. The JavaScript of this module over here will have a string that will denote some other components that will have injected here at run time. That's the dependency. That mapping is somewhere else defined. If you don't know how that mapping is defined, you will not find that dependency.
TG:
What appears to be a generic problem, it's actually not. It depends on the context. Details depend on the context. To be relevant, the tool must understand those details. The only ones that can understand the details are actually the people that are in the context. The only solution that I imagined, was that we needed to get people, the developers to create their own tools.
TG:
There is no clicking tool. A clicking tool, a clicking tool assumes that your ... You know, if it's applicable in your system, and it's applicable in my system. By definition it means that it has to capture what's common between our systems. Also by definition, it cannot capture what's different. Our value comes from what's different and not from what's common. In order for the tool to be relevant, it must be contextual. That's the essence of Humane Assessment. It started from this realization that, well have a problem. When we say 50%, of the time allocated to reading, we're actually talking about the single largest expense we have in our job. That is the funny thing. I've been spending several years talking with several thousand developers. I'm asking them if they agree with this statement that they spend this huge amount of time ... Are you asking if they spend 50% of their time, usually half the people they ask, that they ask, answer that, well they spend at least 50% of the time. Right?
SK:
Yeah.
TG:
This is by far the largest expense we have, spent on one single activity. I asked them the other question which is, "When was the last time you talked about how you read code, it is how you do the reading? Not about the code the, you read, but about how you do the reading." It turns out that, that's not much of a conversation subject. Well, if it isn't the subject of conversation, it can't be optimized. It cannot be expected to act on it, because you know, it's not a subject of conversation. It's just assumed to be the way it is and you just go on. We think that it isn't.
TG:
Reading also happens to be the most manual possible way to extract information out of data. By the way, when people read code, they actually don't read code like they do, Harry Potter. They read code in a, different way, because the goal of the reading effort most of the time, is not when you learn, but when you're into a project. Most of the times, a large majority of the time, the goal of the reading effort is to understand enough to make a decision. From that perspective, I look at software engineering as being primarily decision making business. That's what occupies most of our time, rather than a construction business, which is what we have optimized for the last 50 years.
TG:
Yeah. I started it then, 2009 from this idea that, how would it be if software engineering would be a decision making business or if you look at it like that? I created this method by which I say that there is a systematic approach to spend this 50% of the budget. It is applicable in many, different situations though, for the last nine years, I have not found a situation, which is not applicable. The essence of it is that we should create the tools that will match our context.
SK:
That was wonderful. I'm glad I asked the right question to get you to say those words. I've seen you say them on the internet. It's a really beautiful vision. That was great. I just wanna get clear on some of, the terms to kind of go back over the stuff you just said.
SK:
This Humane Assessment methodology, it's what you just sort of described as the decision making. It's like thinking about software development as decision making, which I think makes a lot sense. This Glamorous Toolkit project we're gonna talk about later, that you've been working on ... My understanding is that the Glamorous Toolkit enables the Humane Assessment or is that not quite right? Is the Humane Assessment ... Is it possible to do it in any project?
TG:
Right. Humane Assessment is something that you want to do in a project. It's applicable, it has a very wide range of applicability in that, it's ... How should I put it? We get ...
SK:
I guess ... Sorry. If you could, yeah. You might be about to do this, but if you could give a concrete example. Take us one cycle through the Humane, with a sample problem.
TG:
Talking about Humane Assessment, there's three different application areas that I see. Let's just take code problems, things that people assume to be maybe architectural related problems, or so. I see problems split into a space, in the following ways. Rather than seeing analysis ... People think about software analysis. Maybe we have dynamic analysis, versus static analysis or maybe you have byte-code analysis, versus source code analysis, or maybe you have one version versus many versions, or maybe you have something that's textually represented versus a visual thing. That's all interesting. These are all interesting, the composition on the space.
TG:
But if you think about the problem, like me as a receiver, as the one that wants to utilize the results of this analysis for making the decision, it's not really useful. It's not very ... It's not guiding. It's very interesting for tool vendor to decompose a space like that. That's why we actually start to ... We have industries around these notions. For example, we have an industry around monitoring. As if monitoring would be completely different subject than a dynamic analysis. It isn't. It's very much the same, and yet we have two different kinds of industries there, simply because of the term.
TG:
A different way to look at this space, is to look at the kinds of problems that people have. There we distinguish some of these problems along two dimensions. On the one hand I look at, is this problem occurring, is this of interest all the time, or is it just one time occurrence?
TG:
What do I mean by that? Let's say, if you have a bug, well ideally that should be a one time occurrence. This that bug. And then, you solve the bug. You have to spend the time to solve the bug. I call that thing, that time, the energy to just spend there, I call that one a spike assessment. It's very, very well defined. You know exactly when the bug starts. You know exactly how the bug looks like. As soon as you can write a test, you know exactly when your bug is done, right? That's one way to look at it.
TG:
On the other hand, right, as soon as you're having that test ... Now the test is of continuous interest. It moves into a different space. Now, let's take that analogy and move this one to something, whatever people call architecture.
TG:
I say whatever people call architecture, because you have this joke that if you put N people in a room and you ask them, what architecture is, you get N + 1 answers, which is actually quite funny. Most books that I read on software architecture, usually on chapter two or three, where they talk about what architecture is, they all kind of say exactly the same thing. It kind of works like this. Say, "Oh, here's what other people say about architecture. Here's my definition," and then we have the N + 1 to finish it, which is a fascinating point of view. We could go into that one as well. I have a different perspective. I think that we are asking the wrong question. Rather than asking what architecture is, I ask what is architecture for. That's a different thing. Usually, people talk about architecture, before they want to do something, before they want to make a decision. That's when architecture is interesting. It's funny for me ... It's interesting. It was an interesting observation to see how, for whatever angle you look at software, it's somehow boils down to how do we make decisions.
TG:
The other thing about architecture is, that whenever people talk about architecture and something is not architecture, all of a sudden it means that somewhere there is a line. If you cross that line, you're in no architectural land. If you go back, then you're in the architectural land. In the architectural land, you use ... It's a different land and you have different tools than in the, no architectural land. I don't know what those tools are.
TG:
One of the things we saw is like, let's say dependencies. We can talk about dependencies between classes on really a micro level, or we can talk about dependencies between systems. They're still dependencies. You will still think of them in the same way. For some reason, one is greeted as if it's an architectural problem and the other one is treated as if it's a detail problem. The thing about software is that ... You know, it's like ... People say that software is like writing. It's like writing, except that if you put a column in the wrong place, on page 237, the whole system crashes. It isn't.
TG:
Those details matter. There is no detail that you could take away, then you say, "Well, it doesn't matter." At some point, for some context, that detail will matter. Let's say ... The other thing about architecture, when people think about architecture, is that they think of it as ... You equip yourself with some tool, such as you can build architecture. That means that there are some problems that are not architectural, and some of those are somehow of lesser important. Let's take a prob ... Let's say, your system is down. Right? It's down because of some issue in the configuration, when during the deployment, somehow made the system to crash, to not be responsive.
TG:
Now, is that an architectural problem? It's just one line in the configuration. People will say, "Well no." Yeah, but if it costs your business a lot of money, is it not a relevant problem? Well, yes it is a relevant problem. All of a sudden, why do I have that arbitrary distinction between, what is architecture, I don't know.
TG:
I can go back ... Going back to Humane Assessment ... The reason people ... I believe people have put so much emphasis in architecture, was because there was a time when we were writing these long, large plans, before we would start building. As soon as we would go out of the script, would leave the script and trail along somewhere, that we would know we were lost and then the whole thing is doomed. The assumption there was, that we need to have discipline to follow the plan to the point. This is also where we started to instill the idea that we have people that think and people that implement, which I also think is wrong. Not necessarily wrong, but it is wrong. It's also ... I mean, it's not fulfilling. It doesn't match. It doesn't utilize our abilities to do the best of our potential.
SK:
Yeah. I would agree with that.
TG:
Right. Coming back to ... What's an example ... Let's talk about architecture. What's an example of an architectural issue? Let's say that I have ... I just look into the code and all of a sudden I see, "Oh, somebody's using my private API." Right. It's four o'clock in the afternoon. At five I have to go pick up my kids. It's four o'clock. I see someone is using my private implementation. Because of that, I cannot refactor my code, and because of that I cannot really implement the function that I want to implement.
TG:
Well, at that time I have two choices, or problem more. Two come to mind. One would be to put an if, right there in the code, deal with the difference and just go ahead, implement my functionality the way I see fit, or the way it is described in whatever task I got. And then I go home at five o'clock. The other thing would be to stop and now have a conversation and find out why somebody is using that private implementation.
TG:
At that moment, it's a little tricky. Now, it's not just a technical problem, but I actually have to go and engage with somebody. I have to find out who that somebody is. I have to go and talk with that person, and now maybe I can disrupt them, maybe they're available, maybe they are not available. What's going on? How do I deal with that? It's not just a pure technical problem. The other thing ...
TG:
The solution from my perspective, one solution would be, to actually document this problem. When I say document, I don't mean ... Now if I can specify exactly what the problem is that is this code, this private implementation should not be caught let's say, from outside of my bonded context. Always, it's a nice ... You know, it's very popular, this notion of a bonded context. Let's say I have a bonded context. Maybe I'm in. On the list, I want to split into micro services. We have decided to use this bonded contexts, and now I don't want people to use ... I want people to use me, my bonded context only through the public API. I can now specify exactly how that thing should look like.
TG:
Well, I can either write a conference page about that, or I can write a tool that does the checking. Let's imagine that I'm actually going and writing that tool. Maybe the writing of the tool cost me a few minutes. And then, I put it into the continuous integration. Tomorrow, we see, or in a few minutes, we see that, that issue ... Maybe we have three different valuations for that specific thing. Even, if I originally we only have seen one such validation.
TG:
Now imagine that there is a team, the team always assumes that such problems occur all the time. Here's the thing, right? If there is no more an architect, if all developers are architects, well, why all developers are architects because the only architecture that matters is in the code. Well, it follows and I have many architects, only if I have many architects, it means that architecture is a negotiation. Right? It's common from this perspective.
TG:
And the question is, how do we organize the negotiation? It's funny because when we had the problem between negotiation, the need to organize a negotiation between technical and non technical people, we started to put all sorts of mechanisms in place. For example, a daily stand up or maybe a planning session or so, or a review. And those are in fact opportunities in which negotiations can happen. People can make decisions, first of all they can informed, and then can make decisions.
TG:
And now the question is "How do we take negotiate technical problems?" Here's another question that I very often ask people and I ask them "Do you find that architecture is as important as functionality of this in the long run?" People say yes. Well then let's see, what does it mean? Well, you know, functionality is treated, first of all, is considered a business asset and it's the thing that makes us this invaluable. If all the functionality is important as architectures also immediately follows that architecture is a business aspect.
TG:
And then the question is, "Well, how do I invest in this business asset?" And I can see, well, look in functionality, I have testing and I have this specific maybe even roles I spent, I have specific practices that really take care that the functionality is in the place where I wanted to be, or have the quality that I want it to be. But then what happens with the code? What kind of investments do I have in the code? Is there anything that is similar to the testing effort I put into our functionality? Do I put anything similar into the architecture or the ties? No. But what if I could do this?
TG:
Coming back to our dependency problem, but if I can just take those minutes, implement the test, and now we have a failing test. And now once I have that failing test or failing check, in this case it's an architecture ... It is not a functional decomposition of the world. It's a structurally composition of the world. And it's equally important to the functional one.
TG:
And so once you have this, now we have an opportunity to network because we see that there is a discrepancy between what we think the world is like and how the world actually is. So now it means that we can look at this problem and say well, somebody screwed up. Or we can look at the problems as "Well, this is an opportunity to understand why are there different points of view?" If everybody's doing doing their best to do things, then that means that nobody is just... Every time there is a mistake, that's an opportunity to understand why did that mistake appear? And in fact, it's not really a mistake, it's just more of an opportunity.
TG:
So imagine that you have a meeting in which you can immediately, in that meeting or that stand-up, let's say, and we call it a "daily assessment stand-up." We talk about only the problems for which we already have data. It is, you can only talk if you have a deduction that actually shows there's a problem somewhere in the system. And then so it would mean that I was the one, I'm the stakeholder of that problem because I discovered a problem. And so me as the stakeholder I say, "Well, nobody should call this. Nobody should call my internal API." And that's very interesting because now I'm the stakeholder and I want to push. I have a first class interest to make change happen. And then everybody in the team has to listen, and then they can potentially contribute.
TG:
So now if we talk about those things, maybe the first one would say, "Oh yeah, I didn't know that this was the rule, I just did it by mistake. But no problem, I can call the public API." The second one says, "Yeah, I think that's not really much of a problem", but the third one says, "Well, I did it on purpose."
TG:
"What do you mean you didn't on purpose? You called my private implementation on purpose? Didn't we just discuss about the bounded context and then the wish to go towards microservices?"
TG:
I say, "Yeah, but I have a different use case. Look, you have designed a component for single calls. You've optimized it for things that maybe come from the UI or so. So single types of requests. But I have a batch mode and I want to work with your model, but I need deeper connection to the database. Because I need to send much more data through it."
TG:
"Oh, I didn't know that you have a batch mode" and boom, all of a sudden communication just happened. And maybe a different solution will ensue from that.
TG:
What just happened? These kind of conversations are very interesting. So I've ran this on multiple occasions, and in one occasion for three and a half years, I took a job in one of the, let's say, based on my consulting experience, I looked around and I said, well, if this method would work, it has to work in the crappiest place that I can find or in the crappiest system that I can find. So I was actually looking around for one of those, and I picked one and then I led the development in that company for three and a half years. And to actually see that this thing actually works, and it did work.
TG:
So I was timing how long it would take. So basically our rule of thumb was if we did not reach a decision within five minutes, we would stop the discussion and go back to gathering more data. Because the arguments were not clear enough. That's why the conversation would take so long. So the goal of the stand-up was actually not to disseminate information, but to actually make decision. Figure out "Do we go this way or do we go that way?" And it turned out that in more than 90 percent of the cases, decisions would be reached within less than five minutes. And that's fascinating because if you take the same people and you talk about architecture in general, you could talk for three hours and at the end of it you don't have a decision.
TG:
And so the differentiator between the two scenarios is the input. When the input is open ended, then the result is usually open ended. But if the input is confined to a very, very concrete data, decisions are found within minutes. And this is a big, big difference. It looks very similar, but it makes a huge difference. So it has to be very, very concrete and it has to be very, very specific. If you can make these economics to work, then you can change the way you make decisions about software.
TG:
So I saw I had a problem in my case. I had a problem, a one-time problem. "Oh, I cannot refactor this one because there are some dependencies." And then I moved it into the continuous space, which is an interest that will be architecture, usually it's something that you care about for a long time or for all the time, continuously. So in the way we moved it is exactly the same way, just like I did with functionality. I took whatever I knew and then I transformed and documented with an automatic check. This automatic check is self-maintainable because we know when it fails and it becomes also the input and the fuel for the decision-making engine as a team. So those are, as I say, a typical scenario for Humane Assessment.
TG:
But it's not just about code. So we look at very often code is the most predominant artifact that we have, but everything around our system is interesting and everything around our system, including code, is data. So we've been looking at code as text for a long time. What do you do when you have text in front of you and you need to understand it? We read it.
TG:
But code isn't text. It just so happens that we, most of the time, use a textual notation to input the code. By the way, where do we do the reading? We do it in an editor. That's interesting because the editor was not created for reading. Its main purpose was to input code into the computer. Yet this is where we'd be spending most of our time to do the reading. And I think because we have not talked seriously about how we do the reading, is that we have not used even the most basic assumptions we have around us. If you think about just most ideas that we have around today, every time a new one appear, quite a few appeared recently. The all start from advertising the editor, because the act of construction is what captures the conversation. So, I think that's a problem.
TG:
It took a while to understand why is it that we cannot get out of that loop? At some point, I went back to the work of Marshall McLuhan. It was interesting because at some point I was reading some more by chance basically. I was reading some of his work and then what other people have said about his work, and listening because most of his work is actually in audio format. And in one article, I find it a really brilliant summary. It's a couple of pages from John Culkin. And one of the things he is coining there is, as a summary of some of the points of Marshall McLuhan, is this phrase that took off afterwards, which is "We shape our tools and thereafter our tools shape us."
TG:
That statement stuck in my mind for awhile and I couldn't figure out exactly what do I do with it? And then it hit me, because if the tools that we use end up changing or shaping the way we're gonna think about the problem, it should follow that we should be very careful with the kinds of tools that we expose ourselves to. Because they would determine the way we're gonna think.
TG:
Well, let's see how does one look like? So on Twitter, I just ran a poll and I asked people if they check their phone within five minutes of waking up. And it's really funny, because most people do check it within five minutes of waking up or maybe ten minutes. And the interesting thing is that this need did not exist ten years ago, because the tool wasn't there ten years ago. There was nothing to watch on the phone when waking up ten years ago. So that means that it's really a striking correlation that basically should lead us to a conjecture that the tool is the one that has manufactured the need. And that's interesting, right? Especially with the latest introduction in IOS of the tracking, the mechanism to track your screen-time as a way to change the feedback loop.
TG:
So that's interesting, but let's bring this type of observation closer to home. So if I say, when you give a developer a problem in a database and say, well something's wrong with the data, and maybe have some sort of relation database or some other form of database, and maybe have a million entries there or so. And then you say, well let's look at that. Let's look at those problems. And the first thing that people do is that they write a query. They write a query, they refine, they look at the data, they look at the result and find the query, and look at the result and find the query, look at their result. And then at some point maybe do experiments and then make a decision and then do something about it. That's usually what happens in that data space.
TG:
But now if you take the same developer and you give the developer a problem in source code, then you'll find a developer will spend a lot of the time scrolling. But scrolling, it's just gathering information out of data. That's why people do the reading and the thing. So the two different spaces are actually not different. They're exactly the same kind of problem, same class of problem, but yet they are treated very differently. It's quite fascinating to see, to observe the correlation between this behavior and the kinds of interfaces that we expose ourselves to. So if we look at a typical database, the first thing that you see in that database tool is a big query box, right? It's a big square box on top and you write a query and you look at the data at the bottom.
TG:
So what do people do? They write a query, look at the data. And when you open a typical IDE, well, you'll see a giant text editor. So what do you do? You scroll. Just because we don't have a pervasive query box, it's interesting to see how that thing correlates very, very strongly with our behavior and how our perception of source code. But just because, I was talking about dependencies before. So if I can say that A depends on B, all of a sudden I said, well, there is a node A and there's node B, and then there is an edge between them. So I just constructed the graph, which means that that problem is a graph problem, which means it's a data problem. So if it's a data problem, well, it should be queryable. It should be visualizable, it should be navigable. It does not have to be read.
TG:
In fact, most developers I know are paid specifically to automate and make other end users make decisions about raw data that they will never see. The systems we build actively prevent end-users from ever seeing the raw data. And yet those end users will make better decisions for it. So we possess, we in software, we know how to transform data problem into decision-making problems. That's a skill and we can utilize that skill for rethinking the way we do our business. So when we have our problem, we should not fall down to the most manual possible way of doing things because we already know how to take data problems and make them into decision-making problems.
SK:
So you talked about clicking problems and buttons, and how they don't allow for generalized solutions. Why is that exactly?
TG:
Because the button assumes the problem, right? If I code the behavior of that button, I haven't coded where I think your problem is going to be and I cannot tell, with your specific problem, I cannot tell. I can only predict classes of problems but not the specifics. So as I said, I know that you will need to look for dependencies. I just don't know which ones. And you're definitely never interested in all of them.
TG:
So in order to have a systematic way to approach this decision-making space, and again it doesn't matter whether you're looking at run-time problems, static problems, problems in the database, all of them, from my perspective, they really require exactly the same kind of thinking. The scientific method is very, very applicable. That is, you start with a hypothesis and then you construct an experiment, you apply an analysis, get some results, you interpret the results. If you're confident, make a decision. If not, you repeat.
TG:
So but the thing there, the key element there, is the experiment, the analysis. Because for most problems, for most practical problems, there is already-made analysis. So it's very, very important to ask the question, what is the perfect analysis for this one? It's important to ask what's the perfect analysis, not because you will have the perfect analysis, because you want to stretch your imagination to understand what would the perfect thing be. And by perfect we mean "What's the cheapest or what's the one kind of analysis that will give me the most thorough answer for my problems so that I can make the decision in the shortest amount of time, and with the largest confidence I can?"
TG:
So yeah, so in our case with, with Humane Assessment, what I said was the essence of it is you asked the question before you apply the analysis. You have to ask the question, "What is the interesting experiment, what is the interesting analysis?" And if you don't have it, you craft it. Or at least you're try to craft it. And that's the key. So the interesting thing is how do you make customized ... create the experiment to give you the right data?
TG:
And the reason why people, why what you're reading is so alluring is because reading is the most malleable tool we have at our disposal. We can read anything. The only problem with it is very slow and it's very inaccurate. But other than that, it can deal with any context, right? They can just jump from source code of a class or whatever else, maybe a function, and then quickly go into a configuration. And the eyes will just completely handle that transition. While a tool might have much more difficulty doing that.
TG:
So that's why it's so tempting to use the reading. The problem is that it doesn't scale. So people think that they understand the whole scope while they cannot, because simply in a system you have maybe billions of details, and they simply cannot fit in your head. So whenever you think that you know what the system is, you're probably wrong in some form.
TG:
And then you don't have to be because, maybe nine years ago when data science was not so pervasive, people wouldn't necessarily understand that it's possible to make decisions in a different way. But now we have companies since at least five years, they massively invest in their ability to make decisions about all sorts of unforeseen data, specifically by employing or by building up their programming skills to craft new tools. Jupiter notebook is exactly that. It's an analysis-crafted tool for a specific purpose to ideally support that kind of a decision. And it's highly contextual and its effectiveness is measured through the decision that is being made on it.
TG:
And then we know, now, that there are other ways, and the only thing we need to do is just start looking at software as being data or in everything around our system to be data.
TG:
We started from within this to practice this. I started it through the lenses of this news analysis platform, and the goal, because as I said, we just optimize the platform to be able to do experiments fast and all of a sudden turn around, it's very, very practical. This ability to be able to build an analysis, a query, a visualization, in interactive browser, to build in minutes, literally minutes, and maybe ten lines of code or so. And then just take that tool, apply to a problem and sometimes use it for 30 minutes and then throw the whole tool away. It's absolutely possible. It's absolutely economically feasible, and then it completely opens up a whole new way to start thinking.
TG:
But the key there is then, to make it economically viable is that the cost of the crafted tool has to be as low as possible. And ideally in our case, the target is for it to cost minutes. And we discovered that there is actually a science to build that, build an environment where you can systematically build these tools.
TG:
Three years ago we took that idea, or actually now what, seven years ago, we started to just realize that I was having some issues with some objects, I remember. I was trying to understand some objects in my fire image, so in my code. And then I said, "Well look, I have this moves that I'm using to analyze other people's problems. Well, I should be able to more systematically use it for my own problems." And then I built an inspector around it.
TG:
That was 2010, 2011. And so when this idea of multiple tools started to shape up, and then a few other people, including Andrea Kish, who did a brilliant PhD on this subject, and Alex Asirell, who then is going to create a further tools to refine that inspector, and then create a different kind of debugger, that would basically be customizable.
TG:
Think about an inspector. All inspectors in the world basically, show you a tree of, whenever you look at an object, you see a tree. A tree with key and values. Because the people look at their tools and then the inspector and then they say, "Well the inspector should show me the interior of the object." And you wanted to say, well, what if I want what if the inspector to help me understand the object?
TG:
And so in that situation, the example that I give often is really this. Imagine you have a dictionary or in Java or maybe it's called a map. So you have key-values, keys and values, and you have a data structure like that in your code, and now you want to describe this. Take a napkin and describe this object to your colleague. So when I give people this chance and I say, well, draw these key values to your colleague. Choose whatever presentation it is, and then draw it.
TG:
People draw a table. That's what you do with keys and values. You put them in a table. It's very natural. The table seems to be interesting from a communication perspective. When people want to communicate what they knew to somebody else, they use this picture. The question is, why is this picture on the napkin? Why is it not on the screen? Because it's not a difficult to draw picture. It's just a table.
TG:
This is when we turn this idea of the inspector around and said there is no one single point of view to look at an object. There are many points of view to look at an object. Sometimes they want to look at detailed data structure. Sometimes they just want to see the table. Sometimes they might want to see a different thing, like how much space do different parts of my object occupying, for example, if it's a memory problem or so.
TG:
It turned out the different objects would be very interesting to look at from various different kinds of perspectives. For example, if you look at a directory, you're going to see the contents of that directory. You don't really care much about what's inside that ... how the directory object is internally represented and so on.
TG:
We created our first environment around that idea. We were originally a team of five with Yurik Bilka as well and Stefan Reichart. That first version got into Pharo. So P-H-A-R-O. That's pharo.org. That's the language that we use, the language and environment that we use. That was the first incarnation of this project called the Glamorous Toolkit, which is a moldable IDE.
TG:
The idea of this IDE was if the assessment ... If the Humane Assessment works so well for supporting these decisions, what kind of external tool, the question would be "How would the development experience look like once we start to make it the core experience?" We did not start from an editor. For the last essentially seven years, we worked on this problem, and we only started to work on the editor in the last year or couple of years. Anything ideally should be a thing that happens after you know what you want to edit. Then it turns out that there's actually a lot of new ... There's a lot to learn by looking at software development from this perspective.
TG:
Then three years ago, I co-founded a company called Feenk. F-E-E-N-K. The stated goal of our company is to reshape the development experience and we are now using a next generation of the Glamorous Toolkit. You can find it at gtoolkit.com. A couple months ago, in September, we reached our very first visible alpha version. It can be now downloaded. Since then, we released a couple more. About once a month, we're gonna release new versions until we reach something that is stable or production ready, let's say.
SK:
So what's the story behind the name Feenk?
TG:
Feenk stands for feel and think. What I notice is that a lot of our work is dominated by objective facts. I also noticed that developers are not really happy. I literally ask people if they love working with legacy systems. People actively hate it. That's fascinating because this is what occupies most of our time. It follows that we dislike our job for most of our time. As Jeff Fowler once noticed is ... So software is probably the only domain in which "legacy" has a negative connotation. I think we should change that. A lot has to do with the fact that we have forgotten that we are human beings and that we are only complete if we feel. That we should not just focus on facts, that things are not dry. We should actively invest in our pursuit of happiness. So that's the story behind the name.
SK:
I really like your metaphor that up until now we've thought of programming like it's construction. We're building physical artifacts such as bridges, but that's the wrong metaphor. Bridges have a specification that you know upfront, and then you build to the spec and then over time, you maintain the original spec. But software is entirely different. When we start, we barely know what we want, and then we evolve the artifact as we go and it grows over time. Not only do we have to maintain the old things, but we grow it over time. So we really needed a better metaphor. Software is much more about decision making than it is about adhering to a rigid specification. It makes me wonder is a better metaphor for programming like business. Business people start with a business and they iterate and they make decisions over time. They don't adhere to a rigid business plan. Would that be a better metaphor than construction for programming?
TG:
Yeah that could be one thing, but another thing to compare with is philosophy. Not necessarily because of the decision making aspect of it. In software, we make dozens of decisions per day and usually only with partial data available. It's from that perspective it is highly stressful. There are not that many other places where humans are subjected to this kind of stress.
TG:
But there is a different way to look at it. Another poll that I ran recently on Twitter was I asked people if they create or implement software. Most people define their work as being creation work. I am very much interested in the feedback loops and the visible effects that they have. One of those that I mentioned, the tools. Another one is our processes. How do we describe processes? We talk about backlogs and tasks, and we have to go and implement those tasks. We have stories and we transform into tasks and then we implement those.
TG:
There's a certain kind of thinking that goes into that type of composition. But if you look at software development as an implementation job, then a developer is not much different than a scribe. It's perfectly fine to be a scribe. It's just not a particularly exciting job. However, if you look at it as a creation act, then all of a sudden, software implies the translation, or software developing or programming implies the translation of my understanding of the world into a format that is then executable. That is very much similar to philosophy. I look at it from that perspective. I look at programming as executable philosophy. I think that's much more interesting. It's much more appealing.
TG:
There's an implicit assumption that there is a good and bad way to do things. I think that there isn't. I think there are only variations. There needs to be playfulness because otherwise you will not be able to explore the whole thing. Much in the same way as a philosopher would choose a paradigm and look at the world in a way by ideally decomposing the world in very few principles and then trying to see how far those principles can get you to to describe and express or explain the facts around you and maybe describe your point of view towards those facts.
TG:
Coming to the question, which other domains are there? Yes, on the one hand we can focus on the act of decision, but on the other hand, we can also focus on the method of decision. A philosopher puts emphasis on "How do I decompose the world such that a new problem appears is trivial to answer because it's just an extension of something I already know?"
TG:
I look at programming as being the largest philosophy experiment that we have conducted as the human species. I think that we should probably look at it more and build the tools around it to support that view.
TG:
The thing is, I was saying that the developers are not particularly happy about their job. There is somewhat of an expectation that first of all, software has to be in a certain form. On the other hand there is a discrepancy between what I think I want to do and what I actually can do. A lot of it has to do with the fact we're spending the largest chunk of our time doing the most manual possible way. It's highly frustrating and I can totally understand that to the point in which now, after I've practiced Moldable Development and Human Assessment for the last nine years and Moldable Development for the last five, I can now say they program fundamentally differently than I did five years ago. I don't think in the same way. I don't approach problems in the same way.
TG:
I very much pay attention to how much I smile. I smile a whole lot more when I have interesting problems. All of a sudden, I can take a problem that otherwise looks tedious ... Just think about. That gets me a little bit pumped up.
TG:
When I see a developer having an exception, the first thing a developer is to paste it in Google. It's crazy. Basically we have given up our ... We assume that we don't have any chance to solve that problem on our own. All this discovery that comes from this philosophical perspective and it's gone. It doesn't exist because we have created software and we are equipping ourselves in a way that prevents us from actually discovering things. To my mind, Stack Overflow has success exactly because environments and languages and libraries are failing on a large scale.
TG:
The primary goal we're having is actually to start the conversation. As I said, we do not talk at all about how we read code. At the end, we end up pasting our exception on Google and hoping that somebody has asked the same question on Stack Overflow. Then copy pasting that solution, trying it locally without necessarily understanding cause and effect. That's not how creation should happen.
TG:
The reason it is called Humane Assessment is because I think that if you see a person plowing the field with the bare hands, we would say that's inhumane. When I see a developer having to scroll and make decisions by scrolling through million lines of code, I think that's inhumane. A humane way would be to make it appropriate for whatever fits the human brain. I think that we are right now not treating our developers and ourselves in the right way.
SK:
Yeah I would agree. It's sad.
TG:
Yeah it would be. I am totally not said. I'm very much convinced, first of all, when we as an industry consider something worthy of conversation, we can very rapidly, and especially in the last years, can very rapidly iterate very quickly over that subject and regenerate a whole lot of innovation. For example, micro-services became a real public subject maybe around 2014. Now, just within the space of a few years, you have whole new businesses and business models that were completely unpredictable just four years ago. That's crazy. And that's amazing at the same time.
TG:
Once we understand that something is worthwhile having a conversation about, we do very, very quickly improve the situation dramatically. Our primary intention is to start that conversation. We built our IDE, first of all, because we want to be happy when we build our systems. But at the same time, we want it to be a very concrete start point for that global conversation. So we built both the theory and the concrete technology that goes with it such that the conversation is not just abstract like we have the conversation now. It's actually very, very concrete. People can start to feel and touch it. This is what changes people's minds.
SK:
Yeah I would definitely agree that this is the kind of vision that you need to see to understand and to really feel what it is that you're trying to get at. I just have to say thank you for taking the time to give me a video demo of the system a few days ago. Just 90 minutes of watching you interact with it has been very influential in my thinking over the past week. It's really one of those systems you have to see to believe to get a sense of it. It's such a large beautiful vision that you're tackling. It's so different than anything I've seen in the past, that I think many people have seen in the past. It reframes the whole idea of what programming is, what an operating system is, what an IDE is. It really needs to be seen to be believed. Hopefully, you'll have a video where other people will be able to see the system like I did.
TG:
Thank you. Indeed. We are actually definitely working on that. So far we have focused a lot on creating the first incarnation of the complete, or the first incarnation of our vision. What's interesting, for example, is if people follow our Twitter feed at feenk.com, there we do a really interesting experiment from our perspective. That is we post pictures or small animated videos with tiny details. Those details, enough that maybe there is a small description, a sentence of so, and then the picture. Those things get retweeted for example of they get liked.
TG:
What's interesting about it is that those pictures are actually ... This is how we communicate with one another internally in the team. By the way, I was mentioning five people before. One of them is not in the current team, but there are six others that are working with us. We can go and see them at feenk.com.
TG:
What's interesting about that experiment, as I said with the Twitter feed, is that we're practicing something called demo-driven design and development. That's the idea that we want our system to tell a story at the end. For the system to tell the story, we have to build the story in the system. By story, I don't mean we user story, that people assume or somehow make equal to a use case or a requirement or so. I actually mean a real story. Something that gets a mind to start to have an interest. Captures the imagination in some form.
TG:
We want to build the stories into our system. What you're seeing there are actually regular artifacts that are being produced as a result of normal development.
TG:
We're funding ourselves. We are a consulting company as well. One of the kinds of projects we're doing is we're actually helping people tell stories about their system. Those stories can be rather technical in terms of architecture. How do you make decisions about architecture or so?
TG:
Another one would be about how do you describe your domain in some form, ideally in a live form. Usually people describe it in documents. They are typically static, difficult to maintain and so on. We are also creating ... We're taking the domain and we model it. The interesting thing is not the model itself, which is let's take a domain-driven design approach, and at the end you get the model, let's say. The interesting thing is that because we are in a moldable system, we can project various kinds of views onto that system and align them with the fluid documentation.
TG:
That really changes how we can engage good people because we can take absolutely arbitrary details about their systems and make them understandable and approachable by other people and very often the people we engage with are actually non-technical people. Imagine reaching the core of your system, describing it in a way that non-technical people could relate to and start having a meaningful conversation about within five to ten minutes. That's the promise. That's the idea.
TG:
I understand that this is abstract, and I know that people have to see it. While we're creating, we will definitely create a lot more. You will see a lot more visual descriptions of our work flow in the near future. Either through our social media channels or just feenk.com.
SK:
I think now is probably a good time to be a little bit more concrete about this Glamorous Toolkit you are working on and what the current version looks like.
TG:
Right. As I said, Glamorous Toolkit is an IDE and currently it's an IDE for Pharo, and it's implemented in Pharo and it is an IDE for Pharo. It has a number of ... it's not a monolithical tool, it's rather a uniform set of components that basically fit together. So one of the things we're looking at, one particular point of view we take when we build IDEs, is that we look at the IDE as a language, rather than a set of features. So the goal here is to allow ...
TG:
The Glamorous Toolkit is a moldable development environment, and moldable for us means that it's the property of the environment that allows a developer to mold, to adapt the environment to the specific problem, to the specific context of the whatever the current focus is. The environment should adapt to that focus rather than the developer should adapt to the environment. This point of view we think lends itself better to create a more humane interfaces.
TG:
So moldability for us is a core property. It is the property we want, the first property, the most important property we want to optimize around. So there are a couple of interesting points there. So one of them is on the one hand, you want to adapt to as many contexts as possible. So we look at it as this is the expressivity part of it. The environment should allow you to take let's say an arbitrary context and then allow you to adapt the environment to that context as much as possible, regardless of what the context is. That sounds a little abstract but we'll get a bit concretely later. This is the expressivity thing.
TG:
The other one is the succinctness. So that is, how much does it cost you to adapt to that particular context? So for example, to create a new analysis or we were talking about an inspector and views in the inspector, that would be let's say the most basic thing we have in our environment, is an inspector. Except that our inspector is a place you want to spend time in, because it's a rich place. So every object can be looked at from different perspectives.
TG:
Before I was talking about the map or a dictionary of key values. We want to look at that as being a table, but maybe if I inspect an instance of a file, let's say that if we are an object-oriented system, which Pharo is. If I inspect the instance of a file and that instance points to a directory, and what I would like to see in the inspector, I would like to see the contents of the directory and I would like that presentation to be shown to me just like I see it in a typical file browser too.
TG:
So we have these different views and the succinctness part of it, of the environment, is about how much does it cost you to create such a new view. In our case, we want to bring that cost to minutes. So imagine that you are able to look at an object and say, "I want a different view." You'll take a few minutes, create that view, and then continue the investigation. That's what we envisaged as part of the workflow of the developer. That also implies that the developer has that skill of adapting the environment to whatever is needed in the current context. It's a new kind of a skill. We think that that's actually an essential skill in software engineering.
TG:
Now, I was saying that we look at the IDE as a language, and it's a language made of operators that are both visual and interactive. Then with those, you want to also assemble a larger view. So an individual view of an object is interesting, but when you start to compose multiple of them and navigate through them, then you start to get ... you have something we call an inspection workflow.
TG:
So imagine an interface similar to the file Finder on Mac, so we have a Miller columns type of interface, and where each column is an object or represents an object. For each of the columns you have different views and you can switch between them, and each of those views is not just a view, but it's actually interactive. That is, you can go and click on any of those things that you see there and then clicking on those will give you the next object and then this is how you can navigate through the system. It's very interesting how many kinds of use cases you can compose with those, just by having views one next to each other. So yeah, again, we look at the Glamorous Toolkit as being a language and then we essentially focus a lot on creating these kinds of operators that afterwards can be reutilized in various different situations to allow the developer to customize things.
TG:
The other part about the Glamorous Toolkit is, given the variability that we were talking about, so we look at software as being data and given that we cannot predict the exact problems that the developers will have, it means that it also follows that we cannot give a clicking tool, because the clicking tool implies the problem. Inside the click, the click assumes the specific problem, but if we cannot know the details of that problem, there's no way we can provide the button.
TG:
So our solution to that is to provide an environment that you can program. So customizing and molding the environment is a combination between, some of it is visual and some of it is ... at the moment when the visuals have ended, let's say, so there's some part of the navigation that is not implemented, is not provided, there's no UI for that, then the developers should be quickly able to resort to programming, fill that gap, so create maybe an extra view or just write a query or transform the data from one thing to another, and then continue the investigation again in the UI. All of that should happen seamlessly in the same workflow.
TG:
Doing like this, let's imagine a couple of workflows. One of them is very often, that occurs very often is that of maybe going through the file system and then maybe finding the XML that was of interest. And maybe the configurations have a specific tag, which for example denote, I don't know, a job or a service, or something like that. Then we want to find out, in that XML, we want to find out how many of those there are, or which are those specific services for example that are defined in that configuration. So how would we go about doing that in a typical scenario?
TG:
So normally, people maybe open up the file Finder or a command line. You go to the correct folder and you find the file. You open the file in a text editor, so that's another tool. In the text editor, because maybe if the editor is reasonable, and these days most editors understand XML, then you will have some syntax terminating, but maybe your configuration file let's say has 1,000 lines, which of course it shouldn't have, but it's not unheard of. Maybe your tags, the ones that you're looking for, your service tags for example, they are spread throughout those 1,000 lines. So what do people then do?
TG:
Maybe they press Command+F or Control+F and then they do a find search. But if you do a file-search, it means that you consider that XML to be a plain text file, which of course the XML isn't. Instead what we should do, we should parse that XML file and then after we get the document out of it, maybe we should write an XPath against that document. So maybe this is all possible, but I mean, everything I described here actually is a possible workflow except that they typically would happen in multiple different environments. So navigating the file system would be in one way, viewing a text would be in another tool, and then writing the XML, the parser, and maybe a little XPath would be yet another tool which will probably be some sort of code editor or something like that.
TG:
So in our case, all of these actions, they're happening just in a plain inspector. So navigating to the file. So looking at the file directory gives you the contents. Clicking on any of the directory has given me the next directory. Looking at a file that points to the XML will give me a view on that text, so the contents of the file, and potentially those contents will be highlighted because I know that this is an XML file, and that will happen right there in the inspector. Because having an inspector an inspector gives me a full programming language or makes a full programming language available, I can always just write a script which says, "Parse this file," and it parses that file and the result would be another object, which will be a document. The document now knows that I can write an XPath over it, and it will give me an editor for writing an XPath, and I'd write that XPath. Then executing the XPath over the document will give me a collection of elements and now the collection of elements shows me a list and I will click one of those elements and all of a sudden now I have a highly scoped browser exactly for what I'm looking for. So nothing else that is not interesting is presented to me. So only now I might do the reading to maybe evaluate the things that I wanted to look at.
TG:
That's just one of those kinds of examples in which we classically look at these problems and we see different silos. So different verticals of different tools while in fact there are no silos. It's just one single space. It's actually very easy to accommodate all this. To accommodate all this workflow with the necessary let's say code is actually not large at all.
TG:
Similar workflow would be on a database. So if I have an object which represents the connection to a database, then the inspector will know to say, "You can write an SQL query", for example, if it's an SQL database. Then you write an SQL query and the result is going to be what? It's going to be another result object, and how do you display a result of an SQL query? Well you'll display it as a table. So there will be a view there that shows you a table. So yeah, again, all of these would have just happened in exactly in the same tool with one single type of investment, with one way of thinking, and all of a sudden we have just accommodated databases. And maybe the necessary code, just to implement all of these is measured in ... maybe it's less than 100 lines or something like that.
TG:
So we have several of these little or different, on the one hand tools, on the other hand we have engines. So another tool would be maybe just a console or a transcript as we call it, except that in our case the console is based on this new kind of a text editor that we implemented, and we can talk about that one too, and that's a text editor that allows you to embed arbitrary artifacts, graphical artifacts right there in the text editor. Those artifacts can be inserted even while you type, for example by the syntax highlighter. So imagine that instead of just saying, "This text is bold," you say, because of what you have typed, "I will insert a certain picture just below that."
TG:
You take even a boring tool like a console, now instead of just outputting texts, you can output whole widgets or whole objects that come with widgets that you can interact with right in the console. So it's very interesting. For example, we do a lot of things with graphical parts because we have implemented our own graphical stack in order to implement or our IDE. More recently we utilized this console or the transcript just to debug, to visually debug animations. It's such a simple tool, and again, people would look at it as a reasonably boring and uninteresting thing that you just need to have. Except we say that it can be an interesting place. So a transcript is one of those tools.
TG:
Another one is Documenter. Documenter is a ... it's a little hard to describe because on the one hand it's a notebook, so imagine a data notebook that is writing the IDE. On the other hand, it's the same technology we use to document code, so to describe the technical parts or the non-technical parts of the code that we write. On the other hand, the same tool is also a place where you can write tutorials about the code that you should write.
TG:
So you can embed into this editor various kinds of graphical things and you can just have reasonably appealing documents that combine textual and graphical representations, and even code that you can put in there. Except that we never copy the code that you put there. We just link to it, and because of the environment and the liveliness of it, that code is essentially always up to date in the documentation.
TG:
So the writing of the documentation boils down to simply having a few lines, a few pieces of text that provide the context of the story that you want to describe, but the real code isn't really into document. The real code is usually in another place, maybe in the code or maybe in examples that you write about our code. When we start to combine those examples, which provide us with some objects, and then combine those objects with the different views, then we can build up live documents that can be utilized for all sorts of purposes going all the way from highly technical things to tutorials, to including business or documents that are relevant for business people, for nontechnical people. Those would be a couple of those tools.
TG:
Then we have a debugger and then we have the whole text editor experience. For example, imagine that you referred to a method, and you want to expand that method right in place in the same place, so you can do that right in the same editor. So, these are a few of those tools that we have.
TG:
Next to those tools, we also have the engines. So, I mentioned briefly examples. So we're no longer working following TDDs or test-driven development. Since now a few years, we're working exclusively using example-driven development. So examples are based on an idea that a colleague of mine from the PhD time brought to my attention and he did his PhD on that topic.
TG:
Tests are very useful for understanding the systems. Maybe the first thing people will do when they understand the system, they start from looking at the test, and that's an interesting place to look at indeed. But if you think about that, and what people do look at is very often the setup part. So not necessarily the assertion, the assertion is also interesting, but a great deal of interestingness in a test is in the setup part.
TG:
So that is, how do you construct a complicated object? And most systems, whenever you go beyond the trivial, low systems have a reasonably complicated dance to set up an interesting state that then afterwards you can build on. There is a very interesting knowledge that you can extract from looking at tests. But a normal TDD workflow, basically there's like this way; you write an assertion, and then you make the assertion green, and at the moment when the assertion is green, you stop working with the test.
TG:
In our case, we do it slightly different. So we also have an object that we set up. We write an assertion, except that our test or "example" as we call it, returns the object. So, a test just creates an object, writes an assertion, and then nothing happens, there's no return value. In our case, we just returned an object, just that simple change. As I said, that idea was introduced by Markus Gaelli in his PhD. It's very interesting what happens once you start to build on top of that idea.
TG:
So, now because my test just returned an object, it means that I can use that object for the another example. It also means that if I follow that path, I don't need a setup, because what is a setup? A setup is just creating the interesting objects that you will potentially use for your tests. But there is always just a two-layer of reusability, setup and the test, and that's it. Well, in our case, because you can just call any method you want from the system, and every one of these example methods, they will return you an object, and without requiring any extra setup. So if I do that, then I can just build up my test scenario and I can describe complicated object simply by composition of other smaller objects.
TG:
When I do that and I combined the fact that I have a return value, and given that in our inspector is a very rich place where you can look at an object and understand the object, I can combine the two very nicely. So in our case, our workflow, we don't stop when the ... when the assertion is green, that's actually when we actually start to exploit the example, because once the assertion is green, it means that the object that I just created is has an interesting value because it has that property in it that I have just asserted, which means that now I can construct on top of it. But to construct on top of it, I first have to understand it and this is what the inspector now provides.
TG:
When I start to combine that one, the example which gives me is a piece of code that produces an interesting object, and that is also guaranteed to have a certain property, then I immediately embed that one into the documentation. So writing and composing documents can becomes on the one hand cheap, on the other hand an exciting activity.
TG:
We don't look at our work as implementing features. We want to change the experience of developing software. Usually we look at the places which let's say people want to have done but don't like to do it. Documentation is one of those cases. Everybody likes good documentation, but everybody knows that documentation is typically not in a good state, and also most people don't really like to write documentation. So we set ourselves to say, "Is it possible to make an experience that actually changes this whole space?"
TG:
When you look at the reasons why people don't like to write the documentation and why the documentation isn't up to date, it's mostly because people have to copy paste a lot and then very quickly, documentation gets out of date, and it's very heavy first of all to figure out. Second of all, it's very heavy to test and ensure that the documentation is up to date.
TG:
So in our case, we never copy anything. The main pieces, which are these examples, already are tested because they are tests, because we have assertions there. So a lot of solutions come together once you start to look at the core reason why something is an unpleasant job, because we really think that nothing about programming is boring, and nothing should ever remain boring. When we say executable philosophy, we really mean it. So it should be exciting. So that's a very short overview of the Glamorous Toolkit.
SK:
Thank you. That was wonderful. I think I want to highlight one of the things that you touched on, just in case someone who's listening kind of got lost. What I remember from watching you use the Glamorous Toolkit was that the inspector was this kind of thing that you would ... you'd start with some sort of object and then you would inspect it and then you'd inspect that and you'd inspect that. So it was like this pipeline of inspections.
TG:
One of the things you showed me is you'd start with the world object, which is like the state of the entire world, everything you're looking at, and you can inspect a piece of that and then you can use a different kind of inspector to inspect a piece of that. It was like an infinite pipeline of inspectors and each inspector was a GUI. So like maybe it would have a query box at the bottom, you could click on it, and each inspector had multiple views for the same object, and then each inspector would allow you to pop open another inspector to inspect a piece of it in more detail. Is that an accurate description?
TG:
Yeah, that's a very good description. Thank you.
SK:
Okay, great. I really love everything you just said and it reminded me of something I've heard you say before, that we often forget what IDE stands for. The I stands for integrated, and whenever you leave the IDE to go use some other tool, the I has failed.
SK:
What this always makes me think of is: I use regular expressions, fairly often, and every single time I have to open a browser, open a tab and go to regexr.com, which is a regular expression playground, and then I actually save the regular expression and the examples that I used to test it. I copy and paste the link to that and put it in a comment right above the regular suppression in the code to help me and whoever comes after me to understand what was in my head when I was doing that. But clearly, it would be great if we could put that right into the tool. But then I think the question for me when you start thinking this way is where does it end? If the IDE fails when you leave it, does the whole computer and operating system become the IDE? Is that where it ends?
TG:
Yes, basically. If you look back at the original Smalltalk world, the work around Smalltalk, the machine was a Smalltalk machine, or that was the original idea of it. So the operating system just happens to be some pragmatic inconvenience. There's no conceptual reason where we need to have it. In fact, it's just one of those rather arbitrary boundaries I think, that we ended up having because it was just a way to circumvent some practical limitations. It's not a conceptual need to have it.
TG:
There's also work that looks at taking Pharo and using it as the operating system, PharoOS. If we considered a computer to be the context, then everything about that computer should be accessible and understandable to a human brain. So we have to make that computer to be approachable in that way. But even that assumption that everything should be bound to the computer is not necessarily true.
TG:
So if you look for example at this work around Dynamicland, which is amazing to watch, then you see that there is no boundary there either, and all the work around devices and wearables, they blurred that line, and even there it's not needed. In the end, the boundary is provided by the brain. So whatever your imagination is, that's what computation should become. Other than that, everything else is just an arbitrary boundary that maybe we happen to have it, just to circumvent some sort of limit that existed sometime in the past, and most of those limits actually don't exist anymore.
SK:
I think that's quite a controversial claim that a lot of the boundaries we have around our software don't need to exist maybe. For example, the obvious one that comes to mind is apps. Right now all of our data and all of our interfaces are siloed into these apps and we're allowed these APIs, or these tiny little, meager holes that we can push data out from one and into another.
SK:
On our computers, text is really the way you do it. When you want to get data from one place to another, you copy and paste the text and put it somewhere else, and that's part of why text is so important as a data format, because the composability of our apps is so bad.
SK:
So I think sometimes I dream about a world where there are less app boundaries, or maybe even no app boundaries. That seems like that's kind of what the Glamorous Toolkit and Pharo is pointing towards, a world where it's not I build an app and it's like a contained thing and you just use it. But it's a different metaphor. What is the metaphor that replaces the appliance metaphor for you?
TG:
Yeah. There are a couple of some assumptions that exist in the sentences that you described. So you're accurate in what you have said, except that texts doesn't have to be the lowest common denominator. It's just so happens that we ended up with it as the lowest common denominator, but there is no real reason to have it as such. It's just one of the data structures, but it's just one of those happenings that just have us ended up using it as the lowest level of interchange, as a consequence we have all these problems that go around it.
TG:
For example, there is work in meta-modeling or around Semantic Web that actually tried to go beyond that limitation. In fact, it doesn't have to be there. There is no real good reason for us only relying on that. There used to be when characters were expensive. When you would measure things in terms of bytes, then it's really, really expensive to have high levels of abstraction. When bytes are no longer problematic, or it is not the unit that you care about, then all of a sudden abstraction becomes much cheaper and it's much more desirable. So that to me is the boundary.
TG:
Now about the apps... I was talking about feedback loops, and here we have another feedback loop that ties some developments with economic incentives. So if what I can sell is an app, if people want to buy an app, then it's an app I will build. If you look into at the macro scale, there's a shift from individual apps to for example services. So when we go towards services that are just available around the world, and I create my new service, just like composing other services, now there's a whole new kind of reusability. The data, all of a sudden the abstraction level has increased, and it's definitely not text anymore. It's a little better. It's not the best place to be in. So maybe you'll have more structure things, maybe it's a JSON or maybe if you're lucky you even have more of a GraphQL type of an entry point to a service, so you can describe the data that you are interested in, and its that service responsibility to give you that data the shape that you have asked for.
TG:
But even there, this is not it's still data. Ideally you want to have rich data that understands what it is. So, the original idea of object oriented programming had nothing to do with classes or methods. It was about objects that know how to exchange and understand messages. That to me is a very interesting and beautiful way to look at or to compose problems. People say, "Object orientation is completely different than functional programming," and then we start to have religions around the two. If you look at the original work, the difference is much more blurred. There is actually much less difference than what people understand now by the two terms.
TG:
So, yeah, but at the end, you want behavior. You want the semantics, as much semantics as possible, associated with the things that you see or you interact with, or the kinds of things that you get through some sort of a pipe that is connected to you. So that's what we should be focused on in the future.
TG:
When we use Glamorous Toolkit for developing Pharo code, then we do take advantage of the fact that we have a much higher level of abstraction on the object that we have to play with. The object has behavior, understands messages. So I don't necessarily care about how it's internally structured. I can interact with it from the outside.
TG:
Now on top of that, just as a layer on top of it, the object not just knows how to answer the messages, it knows how to present itself to the human. These views in the inspectors are basically very similar to how you would write a string maybe in Java, except that we don't transform it to a string only, we transform it to a widget. So an interactive user interface. Then we don't transform it into just one interactive user interface, we can transform it to many so that we can accommodate better the point of view that whatever human wants to look and engage with the object that is in focus right now.
TG:
In fact, it's not just the way you look at it and how you interact with it, but it's also for example, how you search it. Another component in the Glamorous Toolkit is called Spotter, and that's a way to search through an object, similarly to how you inspect through them. But in this case, you start from an object and then the object will say, "I know how to be searched this and this and this in this way." So it will list your different categories of searches that are possible, and every search on that category will give you some results and every result is another object and then gives you another context. It can be searched in different ways. If you link this into a user interface, then all of a sudden you have a completely different way of searching, the way you interact with it, the way you visualize it or you interact with it, and even the way you debug behavior.
TG:
So our debugger is also moldable... When you execute a library, you don't necessarily care about the details in that library. What you care about is mostly the way you use the library from the outside. So if I call a library, I maybe want to abstract away all the inner calls inside the library. I just want to see when I go from one part of my code to the next part of my code, regardless of whether or not I went through 100 different step in, step out type of debugging actions.
TG:
So the debugger now knows that given that this library is on the stack, it would give me a button which says, "So to the next time, I go to your code," and the debugger knows, because if I know that this is the code of the library, then I'll also know what is your code. If I know what is your code, then I can just go to the next time I hit your code. It's actually very easy. So if you put all these together, then we have something that the brain is much more comfortable working with and the programming becomes...
TG:
All these idea of how do we understand enough to make a decision, so what we talked about before about software assessment, becomes a conversation that I have with my environment, and I continuously mold my environment to just fit the kind of view that I have on that world.
TG:
The level of abstraction at which my conversation is happening is almost at the level at which I think, and that to me I think is the goal, right? We want to bring that abstraction as high as possible, but also within practical cost bounds. Because if it costs me a month to build up a tool to investigate the problem for 10 minutes, that is not useful. But if it costs me 10 minutes to go investigate the problem, so to build up the tool that will help me raise the level abstraction at the place, or at the level that I'm interested in, and then investigate there, then all of a sudden I have a complete different economical setup. So my incentives have changed and as a consequence my behavior will have changed.
TG:
So, it started from this idea that we have silos, and indeed we do have silos, but I think a lot of those silos they are very highly correlated with the economic incentives. So if you look for example at data in social networks for example, it's not the common good we want. That's what drives the behavior, that's what drives the silo idea.
TG:
A different type of a scenario you find in Wikipedia, which is driven by other kinds of incentives and you have other kinds of behaviors that are taking place there. This is why people go for references there and they start to have much more defensive points of view when they go nowadays and consume data coming from social networks that are driven by economic incentives.
SK:
I'm really glad you brought up Wikipedia because I think that's the perfect counterpoint to how software is built. I have been toying with the idea or the dream of how can we make software development more like Wikipedia, in that it's a free thing that's open and collaborated on in a group. It's kind of a hard vision to articulate, but one of the other things you just mentioned was social networks, and part of why they're closed is for business model reasons and that makes a lot of sense. We live in a capitalist world and so surveillance capitalism in terms of advertising makes sense from a business perspective.
SK:
We're seeing a lot of excitement around these new kind social networks like Mastodon and other federated decentralized social networks trying to solve this problem. Then we could have that would unlock the problem of social networks being siloed, and we can have open source collectively-created social networking platforms and social networking tools. I feel like you could do the same thing for almost any kind of software application in such a way that ... potentially there would be a new economic software world-order. I know that the way things are today, if you want to make money, you build an app and you sell it, or you build a SaaS product. SaaS kind of changed economics.
SK:
I'm thinking how can we take these ideas you were talking about and use them to envision a new kind of world where the economics are very, very different. An example would be now I pay for monitoring software for my business. There are all these SaaS businesses that we pay for, but if the software paradigms were slightly different, we wouldn't even have to pay for them anymore. It could be something, instead of it's a business that I pay $100 a month for, I could build it in an afternoon and then when someone else wants to use it, I could just give it to them for free because it costs me nothing, and they could improve it and I can get the improvements. We all get the benefits of open source from the tools we actually use in this idyllic way. Do your thoughts run in this direction ever?
TG:
Yeah, definitely. Now, the thing about it on the other hand is you also want to have things that are sustainable. So creating something now is one way, but creating something that will last you for two years is another thing. We also see for example in the open source space, we see that there are problems with the maintenance costs basically. Everybody expects to utilize open source software for free but not necessarily to contribute. Then you end up with-
SK:
Sorry.
TG:
Go ahead. Go ahead.
SK:
I was going to say that that's the point. The problem with open source today is that it was ... Let me start over. I think when the idea of open source came about, like the Richard Stallman-era of open source, the idea was we're all programmers and we're all working on the software together. So it was a commons, and it was very much everyone was working on the software. But then it kind of shifted and now we have a very small percentage of people who actually maintain open-source software and a large percentage of people who use it blindly. But I feel what moldable development environment would enable is returning to the ideals of open source where it's much more possible, instead of 0.1% of developers being maintainers, it could be more like 10% of developers, or 50%, I don't know. I feel like that's the whole selling point or one of the selling points of moldable development.
TG:
I think you touched on an interesting point. Is that the selling point of it? I don't think so, but it's an interesting application area. Here's why. I think, and again, just like I'd come back to the Stack Overflow thing, right? So, we got so used to this idea that whatever we use is a black box that nobody even tries to look inside, under the hood, which is what you need to do when you need to go and maintain something. But what if the costs of looking under the hood is actually not as high as we think of it? What if they it is one or two orders of magnitude less? Whenever there's a dramatic price drop, we have economics getting [inaudible 00:46:35] and the whole new kind of behavior can emerge.
TG:
The nicest example that I have seen recently is there was a TED Talk by Al Gore in 2016 showing that the predictions that were made in terms of CO2 emissions came true, unfortunately, over the last decade. But the solution seems to also come in form of another exponential curve. So the CO2 emissions do evolve exponentially. But at the same time, the solution seems to come from the adoption of all these alternative sources of energy, and that's interesting. It's a very interesting behavior that was not necessarily predictable. In fact, the actual behavior heavily out performed the best of the most optimistic predictions that we had 10 years ago. It's very interesting to notice how that behavior correlates with the drop in price. So as soon as something drops under a certain threshold, or a whole new economic model is available that generates a whole new kind of equilibrium, and you cannot predict it until you're there. So what we are saying-
SK:
Sorry. I missed the Al Gore example. The cost of what went down...?
TG:
The cost of the alternative energies. So the cost of using solar....
SK:
Alternative?
TG:
Right.
SK:
I see.
TG:
The price went many, many orders of magnitude dropped over the last decade, and as a consequence, we see that drop in the price correlated with the adoption rate, which is an exponential curve, the adoption rate. But that adoption rate was unpredictable 10 years ago. The reason it was unpredictable is because whenever the price drops, a whole new economic behavior is enabled that is unpredictable before you have it, before you have that possibility.
TG:
Same thing happens with the apps. If you look on the apps on the iPhone for example. When the iPhone came by I still remember it, 2007, 2008, you would see most reviews were comparing the keyboard. The speed of the keyboard and how fast and how accurate you can type on the iPhone as compared with a BlackBerry. All those comparisons completely missed the apps because the apps, they introduced a whole new world simply because they dropped the price of one app. So every app on the iPhone is much less capable than an app on the desktop. But on the other hand, they are also much cheaper.
TG:
So an app on the iPhone can be built by one person, which now leads to a whole new economic model in which ... so, you see most apps are not useful for most people, which is exactly what makes them useful, because ... and now we have economic models to target niches, we target context. So you can tailor exactly what you want theoretically through those little ... because the level of granularity has dropped, and it's economically feasible for us to produce those small pieces, the apps. Now it's me, the user, that just assembles my experience to deal with my context.
TG:
So most apps in the world are not used by most people. As I said, that's exactly what makes them interesting. But now this behavior, so now we have literally hundreds of millions of apps, this was not predictable 10 years ago. So now coming back to our problem, we see the way we look at it is that the reason why people do not peek under the hood of whatever they're looking at, is because the perceived costs of looking under the hood is too large. The reason why it's too large, this cost, is because of the tools that we use to look under the hood. So by changing that nature, the nature of the tool, we think that we can drop that cost with at least an order of magnitude, but probably more.
TG:
Once you do that, a whole new economic model is possible. A whole new kind of economic behavior is possible. We don't know where this ones will lead, so that's the side effect I was more thinking about. But our direct goal isn't necessarily to change open source, although I do think that this will happen or could happen. Our main goal is to change the experience of looking under the hood of whatever software it is.
TG:
So the behavior of me getting an error about my system and then copying that one, going in Google, pasting it there and then hoping that somebody asked a question and answered it on Stack Overflow, that behavior, that is at this moment is incredibly detrimental. There must be a dictionary somewhere where under the definition of hopelessness, that's like the poster child example. Like you have a problem with your system and you go somewhere else to find the reason for it. That shouldn't happen. That's not the best case scenario. Once we change that, I think a lot of things can be rethought afterwards, but we have to change the foundation first before we can imagine next levels.
SK:
Okay. That's very fair. That makes a lot of sense. One of the topics that I think we didn't explicitly talk about in this conversation yet that you've mentioned before and really stuck with me is the concept of a single rendering tree. The way you made this come home to me when you were showing me the demo was when you pressed on the world object. You popped open the inspector and you clicked on the world object, then the preview of the world object was the world. So it became kind of a fractal-y thing, like the whole screen was put inside of itself and you can kind of pop around and inspect various parts of the GUI that you're actually using to inspect itself.
SK:
You mentioned that this is only possible, and the other sorts of things you mentioned where you take the documentation, you link it and you embed something inside of itself, inside of itself, kind of infinitely. All that's only possible with this single rendering tree. So yeah, I wanted to figure out why is that and why is it such a unique concept?
TG:
It's not a unique concept in that it was there since a long time. If you look at every graphical user interface, has one rendering tree. The problem is, when people want to say, "And now I want a visualization," for example, and all of a sudden I don't have the capability to draw a line in my graphical user interface. I will start employing another library. Maybe canvas if I'm in HTML or maybe SVG. Then I will draw in there, except that that one, what's inside that canvas, it's another rendering tree. So I have a rendering tree in another rendering tree, and those two rendering trees, they have different properties. They are different kinds of rendering trees.
TG:
They are different worlds, and because they are different worlds, you cannot connect the two. So I cannot just say, "I want to have a visualization here, and in that visualization, I want to put another editor. When I double click on something, I want that to become an editor. So I want to now take the editor, which exists in the outer world, and put it in the inner world." Now all of a sudden it's a very complicated technical problem, and all because I could not draw a graph or a chart. I was not able to do that so I created another world, which made sense when I optimized for that case. But it makes less sense when I really want to have fluid interfaces that I can just interact with as I see them on the screen.
TG:
That's the reason why we have spent a good part of the last three years... most of our effort was actually in creating the graphical stack. So we knew how to create the IDE before because we worked for it for about four or five years before we started this new generation. What we realized was that we needed much more flexibility in terms of what we can express visually.
TG:
Let's say you put a graph, and you want to have a graph of the dependencies, that you see here's a module, here's another module, and maybe you want to zoom into one of the modules and then you will see the classes there. Right there, right in the same screen, you want to double click on that class and you want to see the code because why not?
TG:
Maybe you don't just want to see the code, you went to edit the code. Suddenly that means that you need to have a full-fledged editor with everything that that editor comes with. But now you're inside the visualization and typically, so that means that you should not be in a different world. You have to be in the same world where you can use the editor in the first place that you already have. So, once you have this ability, once you can unify and have graphical representations and normal widgets kind of things, and they're representable in the same rendering tree, then these kinds of combinations are trivial. They are essentially limited by imagination and not by what's technically possible.
TG:
Another thing that we have was that our editor is also rendered in the same rendering tree up to the, even if you want to to the level of the character, but at the moment for more practical cases, the level of the word is good enough. So every word in the editor is a first class element that is just a part of the overall rendering tree. And as a consequence, that's the reason why we can just add arbitrary artifacts and embed them right into what appears to be a text editor. But otherwise, it's essentially just a giant visualization tree that you're looking at or interacting with.
TG:
That's why you can make different kind of interfaces that you can have editors that are really, really live and visual. So we don't have to have here's the textual world and here's the visual world. They can be intertwined in absolutely arbitrary fashion or the way the designer wants to, without having the limit.
SK:
I'm sold, I think this is great. So now my question is, how do we build something like this? I guess my question is about how you built your graphical stack, but I think I just want to add an extra nuance that I feel like we can talk about the detriments of HTML, CSS and JavaScript, but there's something to be said. I guess, particularly for like HTML, that it's an open standard universal format. I don't have the right words to describe what I'm getting at, but HTML works on different browsers, so different browsers can implement the HTML spec in different ways. It's not like a binary proprietary format. It's like this open involving standard thing.
SK:
So I think the main thing I'm worried about in going to a single rendering tree world is that somehow you lose that. So anyways, I'm curious, how do we get this single rendering tree? What do we add to HTML or what do we add to the canvas? Basically, how do we do it and how do we do it in such a way that it doesn't tie us to a specific proprietary closed box thing?
TG:
That's a good question. Actually, to answer the question about HTML... the rendering tree Is a property of the browser, not of the HTML. So it's an underlying property. Because the question is, why can I not describe HTML in the canvas? Why can I not utilize HTML elements as loads from the former graph for example? This is at the moment not possible.
TG:
Typically standards are very often correlated with what's possible technically, and there's an interesting synergy that happens between technical advances and the evolution of standards. So I wouldn't be so much worried about that.
TG:
If you look at the original text, if you look at the Gang of Four book on design patterns, there are patterns there that are about text editors, which if you look at the flyweight pattern for example, there's about how to not create multiple instances of a character, A, for example, that you might want to use in an editor. So they're doing these things in the past with, that created these kinds of rendering trees, and the challenge there is how do you make it fast? When you have these rendering trees, they're highly flexible graphical possibilities. But on the other hand, whenever you have flexibility, the question is how do you make it fast?
TG:
Our target was can we open 100 megabytes texts in less than a second and start editing in less than a second? So that was our benchmark. It took a good part of the last three years to figure that problem out. So now I think it'd be very interesting if people will start to look at our work and then go and improve that one now that we kind of answered the question of how do you make it not just conceptually possible, which we knew that is possible before, but also make it practically possible. After you have the technical advancements, after that, usually the standards, they can follow that. So I wouldn't be so much worried about the black box part of it. I'd be much more worried about having or forcing people to express things in a box, which is why for example an HTML canvas is. It's a box, which from the point of view of the HTML is a black box, because nobody knows what you will put him aside.
TG:
Of course, there is always a need, or it might always occur, you might always have that need for whatever technical reasons. But for most practical purposes, we should not be forced to have to utilize the black box. Right now, for most, interesting graphical applications, people are forced to use a black box by the standard. So that shouldn't be the case.
SK:
All right, that makes sense. Okay. Yeah.
TG:
More about this. This rendering tree, again, we look at everything about the IDE to be as a ... we look at it as a language, a language made of operators. If I need only one single concept to express something, then I shouldn't use two. So that's why, right? We looked at the space, the kinds of possibilities we had three years ago, and we saw, well, looks to us that we're using multiple concepts when just once should be enough. Then when we said we formulated this goal to have one rendering tree for everything we're going to build, we just optimized for that.
TG:
It seems to me that people don't formulate. So we optimize too much for what is immediately tangible. When we said one rendering tree, we actually didn't have much experience of building whole graphical stacks before. So it was not predictable that we are even able to do it, but it just sounded like the normal thing to aim for. So first you have to aim for it and then now you will have a chance to potentially get to it. But what I noticed in practical settings is that people, because something does not appear to be tangible, don't even set up to try to do it. This is, again, this behavior is often correlated with environments where people are asked to estimate or provide the business case scenario for whatever type of effort that they will invest in, that is that you need to understand the profit before you're start investing.
TG:
I think it's kind of detrimental today because it prevents you from investing energy into work just because of a principle and not because it's immediately profitable. You don't know whether it's profitable because you don't know if it's maybe even possible. So, yeah, just wanting to say that one. So it's because I think we should push more the conversations towards principles without necessarily regarding what's immediately tangible, what's immediately practical. Once we will have those kinds of conversations, all sorts of new kinds of opportunities appear because innovation comes from challenging assumptions that are no longer true or maybe they never were true. You only find those assumptions if you actually start to challenge the whys, the reason as to why something is the way it is at the moment.
TG:
That's why I'm focused on generating or triggering conversation. I'm interested in the subject of the conversation, rather than in the immediate results of that conversations. Because when the conversation is, it's principle based and people engage into formulating arguments, listening to the other arguments and formulating maybe counterarguments are alternatives, inevitably this leads to leaps.
TG:
To make people jump or leap away, go away from what is immediately possible, I tried to talk about that idea of code reading and we should look at software as data and build tools for this and so on, for a reasonably long amount of time, and there wasn't much of attraction around that conversation. So that's the reason why we wanted to create and embody that idea into something that people can touch. Now if they will touch it, then perhaps this will lead to the conversation. But the goal is not the tool, the goal is the conversation, because only that allows us to leap.
SK:
Yeah, that's a really interesting thesis, a conversation-focused one. I want to just ask a quick question. If you could compare Pharo, the Glamorous Toolkit to other modern-day Smalltalk projects. I don't know if you would group them together the way I just did, but to me, like the Lively Web, Lively Kernel, and morphic.js, to me they're conceptually in a similar bucket in my brain. So I was wondering if you could just distinguish them from each other.
TG:
Right. They have a similar goal, right? For example, if you look at Morphic, but it's not even invented in the Smalltalk world, but it comes from Self a long time ago. At its time it was an absolutely beautiful concept, and in that situation, the original morphic was one rendering tree. Again, the question is how do you bring it to today and how do you make the kinds of interfaces we want to dream about today? Not those that we were rendering about 30 years ago. So yeah, everything that happens around reflective systems, whether this is Smalltalk or as a different flavor to it, I think those are highly interesting and we are definitely in that space.
TG:
Now the Glamorous Toolkit, we talked a lot about the Glamorous Toolkit in the context of developing for Pharo, but the Glamorous Toolkit is actually, it's a platform for IDEs, or for tools that are meant for humans and want to think about or work with computation, within the bounds of a computer at the moment. So, if you look at the MOOSE Project for example, there you will see there's quite a significant knowledge with how to deal with other languages, or how to deal with other systems. But not even just languages but like really systems, because the idea of moldable development is not just to focus on the language, that we have an IDE for a language, we want to have IDEs for systems, and even IDEs for problems inside those systems.
TG:
So it's a different level of granularity. In that space, that space of moldability, at this very moment, the Glamorous Toolkit is in a reasonably unique place. It does draw from other places such as, for example, if you look at Emacs. That's a very interesting ecosystem and it was a beautiful, still is a beautiful model, but it is bounded to the text representation of things, and that is no longer necessary. It used to be. It was a very interesting thing that the screen would show your text all the time, but now we no longer have that kind of limitation. Now we can update the constraints to what is possible today. So, the moldability idea is closely related to Emacs.
TG:
Just the last couple of weeks I demoed Glamorous Toolkit quite extensively and the people see and say, "This looks very similar to intentional programming," which it does. "It looks very similar to literate programming," which it does. But it's all happening in one environment and there are significant differences to those. So there is no just one intention. There are many, and when we apply the intentionas, they are not necessarily runtime intentions. So we take a much more pragmatic approach to that space. But rather we just project things even to the level of an individual object, and the goal there is to optimize for the decision-making process of a human. So to just offer enough information to that human so that the human can make the decision.
TG:
Then with the literate programming, so if you look at our documents where we can embed and compose those documents out of various kinds of artifacts, whether these are examples or whether it's our extra snippets of code that reference the documents, they do look like literate programming, except that they are part of ... So the documents that we created, we can have many of those documents, and we don't tie their writing to the reading. So those two things are actually decomposed.
TG:
Another thing that people seem to associate our work with is model-driven engineering, which is definitely what we don't necessarily do, not really do. What we do is more something we call model-centric engineering. That is, we treat the core ... the ground truth is always the code and the runtime and everything else is just a projection on that. So it's a different perspective on how we approach the modeling part. We do have models because of all those views that we talked about, they are models, but the way we organize them there are different. So there's a whole lot of inspiration that we draw from and we try to combine them in a unique environment.
TG:
So on the one hand we have these reflective abilities with Pharo, which allows us to introspect very cheaply and elegantly on our own system, and also adapt the system, while the system is running, so that's where the Smalltalk legacy come in. So, we have that part, the Smalltalk part, and on the other hand we have all these other kinds of inspirations going from programming to visual representations, or all the visualization frameworks that exist there, there exist similarities there, except in our case they are all in one single place.
SK:
Cool. One of the phrases you just used is that the Glamorous Toolkit is not an IDE for a language, but it's an IDE for systems, whole systems. When we were talking and you were demoing the system, you mentioned how it could be like an IDE for running your whole restaurant and you could have developers and business people live in the same world with the same underlying data, but with different views or projections on top of that data. Another one of the things you said was that everything should be explainable at any given time without resorting to drawing on the whiteboard. Any time you feel the urge to draw on the whiteboard, it means you need to build a different visualization that'll then live in the system for forever and people can use it just as a part of their toolkit. So yeah. I don't know. I kind of summarized it a bit, but I'm wondering if you could talk more on this, the IDE for systems setup.
TG:
Right. A language is already great, but if you use one language and I use the same language, our value does not come from the fact that we use that language. Our value comes from whatever we build on top of the language. So in order for the tool to be really effective, it needs to understand that context because context is the most interesting thing in software. So the tools need to be able to adapt to that context.
TG:
So, for a long time, maybe first two, three years of the research around the Glamorous Toolkit, the original version, we spent on just figuring out how do we change or how do we customize and mold the environment for one individual object, and how do we make that one economically feasible? Because if to change the large scope, people say, "Yeah, but maybe that's too expensive to have an IDE just for a system."
TG:
And we say "Well, okay. If you think that for a system it's too expensive, how would you feel if you would have to, if you would want to or we propose to adapt your environment for every individual object, or types of objects that you have in your system?"
TG:
That would be a much more interesting problem to solve because if you solve that one, then you have a whole different ... As I said, if you change the cost structure, then a whole new kind of behaviors are possible because they're feasible economically. So we spent most of our energy on dealing with the cells. Once we knew how to handle the cells, then the rest is actually just a matter of just you want to do it, and it's a natural progression because once you are able to extract value by just adapting the view, one view for one single object, then you will immediately want to apply that value to a higher level of abstractions.
TG:
So you mentioned like the IDE, the I in the IDE stands for integrated, and it's true. But what we really think that integrate it should be is not just about the developer but also a bit about everybody that has to say anything about the system. That I think would be true integration, and that's when we would also start to see co-creation between nontechnical and technical people, because right now we still have ... I was talking about creation versus implementation, and a lot of it is drawn from the idea that somebody does not understand anything so you'll just give him ... you're given the task, you define the output, or the black box boundary, because they will never, ever have the chance to look inside. So then all those constraints, the way we designed the process, and the way the interactions between people happen, are based on this assumption that normal humans cannot look inside the box. I think that's a wrong assumption.
TG:
So once this is possible, once that assumption is no longer valid, then complete different kinds of workflows are possible. As you said, we think that pairing should not just happen between two technical persons, but it would be very interesting to see pairing and live conversations about the system happening between technical and nontechnical persons, and later on between nontechnical persons. Then maybe we will not even have much of a distinction between technical and nontechnical persons eventually, once the incentives exist.
TG:
If you look at, for example, the history of mathematics, for a long time in the history, mathematics was a skill that was possessed by very, very few people, and those were mathematicians. Nowadays, at least the basics of mathematics are handled by a much larger audience. Well, we still have those mathematicians there, the skill of mathematics is intertwined now with the actual domains in which mathematics are applicable. I think that's the progression that we probably will see with programming as well. So nowadays we have developers and that's a skill on its own and there's a reasonable small amount of people as compared with the rest of the population. But I think that we will see a progression or let's say a diffusion of the skill and the combination of that skill with the domain. Then for this to happen, the cost of teaching this and learning programming, and learning the systems that you want to program, that cost has to decrease significantly. Once that is happening, then we will see all sorts of new kinds of behaviors that will emerge from it. So this idea of an environment in which the IDE should be installed on the business person's computer, I think that that will not be as ridiculous as it sounds today in just five to 10 years.
SK:
I think it's a really optimistic and beautiful vision. So, the last question I want to ask, because this is already the longest podcast I've done by far, is: you call yourself a software environmentalist, and I love that phrase and I love your reasoning behind it. So, do unpack it for us.
TG:
You said it's already long but still you ask me another one. Okay. I'll try to make it short, which doesn't say much because we are consultants and that's how we earn our money. So, okay, let's see how short we can make this...
TG:
Around year 2000, there was these massive investment into the year 2K problem. For the younger audience, that's the year 2000 problem. So, dates in the COBOL time, in the mainframe time, where again, bytes were expensive. People would not want to waste four digits for representing a year. They would just use two of them, implying that the first two digits would be one line. So when the year 2000 came, all of a sudden that assumption was no longer true and then given that those mainframe are running our economy, we wanted to invest the energy browse through them so that the economy doesn't fail at 1st of January, 2000.
TG:
The economy didn't fail, but it didn't fail because of the success that the browsing all of these sources had. But that was a very large cost. But one of the things that came out of it was these interesting observations that we still have this huge amount of mainframes still in use. So one study once said that there was an estimated 10,000 large IBM mainframe systems, still in use around the year 2000, and that number probably didn't drop dramatically in the last couple of decades from my private conversations.
TG:
So, here's the problem with that one. It's not that people want to have those things around. They don't, but it seems that we are unable to remove them. So at the same time, we have software that grows. The body of software grows exponentially year over year, which means that on the one hand we create software exponentially. So we have an exponential growth. On the other hand, we seem to be unable to recycle our old systems. So from that perspective, we behave very much like the plastic industry where we focus exclusively on how we produce things. We drop the cost of producing something with not much regard of what's happening with the things that we produce after we no longer want them. So I think that we have that behavior and I also think that we are right now drowning in software, and software that we don't necessarily want.
TG:
When I talk, for example, I was at an architecture conference last week and I was talking there with many architects, a few hundred of them. Many of them still have mainframe systems in their organizations and it's not that they want to have them there, they cannot remove those things. If you would stop the systems, because when they started to talk about hardware and software in the '50s, when they had to name the things, one was large as a house. So we called that one hardware. The other one was this thing that you could just pull in and out as you wanted, and they called that one software.
TG:
Nowadays, the funny thing is that the hardware, because we probably called it hardware, it fits in my pocket. But he software is now the problematic part because the assumption used to be that we can remove the software anytime we want. But in fact we cannot, because if you would stop those mainframe systems for example, the economy would probably collapse. So that's not a feasible thing to do.
TG:
And it's not just the mainframes, because nowadays we're deploying millions or even more of sensors, and those sensors, they have to be updated. Of course a lot of the focus today is placed, when it comes to quality and the security of the software, is about the bugs that we put in place. So we say, "Well, we should have more better testing," and so on. I think that's absolutely a valid point of view except that the problems ... when you look over time, perfectly reasonable functionality today can appear to be buggy tomorrow simply because the environment has changed. Something in the environment of that system has changed.
TG:
So, our ability to adapt the system is as important as our ability or even probably more important, but at least as important as our ability to produce it today. So from that perspective, if we are unable to recycle old systems, then we have a problem, right? Now, if you look at the reason why we cannot recycle old systems, I think there are many, but one of them is that before I can take something apart, I first have to understand the parts. But if the ability to understand those parts depends on our ability to read, then we see the fundamentals of the problem unfold in that we're trying to match an exponential growth with the speed of recycling that is capped in speed, because the reading is capped in speed. We cannot really enhance reading.
TG:
Well actually people have tried, so there was this very interesting quote by Woody Allen who said, "I read War and Peace in a couple of hours and it was about Russia." So yeah, you can do it that way, but that's not really useful. So we cannot really increase the speed of reading, and as a consequence we cannot increase the way or the speed with which we recycle systems. I believe that we have not really seen the problem because we were still able to exponentially grow that developer population. But we are kind of at this very moment, we are running out of places to draw extra-qualified developers. I think we will soon get into that and we will see that problem.
TG:
It's interesting how everything goes back to this problem of manually trying to go through sort of the software systems. I think that the only possible answer is to have a function, the recyclability to be a function, not of our ability to read, should have it be a function that does not depend on the size of the system, or ideally, or as little as possible on the size of this, and definitely not linear or even worse, super linear function, depending on the size of the system. The only way to do that is to utilize out the computer to go and do the, let's say the boring and the repetitive task of crunching data and transforming it into information.
TG:
This is why from that perspective, moldability, this idea of getting the computer to show me the system or whatever is in that system, whatever details I want from the system, at whatever level of abstraction I want... This idea has I think a reasonable chance to advance the conversation. I don't think that it's going to be the ultimate solution, but definitely improves or pushes the problem with at least a decade or maybe more if we'd go in that way. So yeah, that's why I define my title as being a software environmentalist, because I think that the problem that we're having is very similar to the problem that we're having in the real world, environmentalism crisis, but this one people don't really talk about it that much.
TG:
In fact, at this moment not many talk about the systemic problem, because this is not something that you can individually solve. It's not a system-specific problem. It's a global problem. Everybody seems to have this problem, just like everybody seems to be having the same kind of behavior when they approach reasoning about a system to make decisions about what to do next. I think that if we systematically reshape that understanding, that conversation, and we show completely different other kinds of paths that open up economical models, then we have also the chance of fixing the problem. I think the problem is important because software is not a niche issue.
TG:
So my kids will only know a world of software, and because of that, because software is everywhere and all of it is just going to be more and more places, we are reshaping the whole world on top of software. So we really need to get a good understanding of what that software is because we noticed over the last hundred years that if we build an economy on top of vectors that are unsustainable, it doesn't lead us in a good case.
TG:
Was it short enough?
SK:
It works. It works for me. I think it's a really ... Many of the things you've said here, it's a very fresh, unique take. Yeah, and I think you say it best yourself that you were really concerned about starting conversations that aren't being had and that's ... this whole talk was mostly about the moldable development in our tools and that's one big conversation that's not being had. But then right at the end there, we just slip into a whole another conversation that is really important that you think we're not having as much as we should.
TG:
Yes, but you can say, instead of unique and so on, you can also say strange, because it's also applicable.
SK:
Yes. Well I think I'm expecting that the reactions to this podcast are going to be like, "Who is this guy? Where did he come from?" Because you have such ... you've been working on these problems for so long and you have such wonderful thoughts on them, and so much of what you have to say isn't in the mainstream conversation about improving programming. So I feel like there's going to be some self-flagellation of like, "How haven't we known about this guy before?"
TG:
So first, people shouldn't make a lot of me because I really work with a team. But really the thing is... at this moment we don't have a shortage of stimuli that can excite our senses. So, the biggest problem, whenever we did not hear about a big issue, it's not because we were ignorant. It's just because that's the fundamental problem of the world we live in today. So it's not enough today to create a new concept. I think it also lies in the responsibility of the creator to also transform it into logical conversation.
SK:
Yeah. On that note, thank you for this conversation. It's definitely, I can say from, because we've talked a few times now, that I can say that you have succeeded in me. You have sparked I guess both mentally just in my own head and also the conversations I've been having with other people since we first started talking, so much more of what I have to say and the ways in which I think have been influenced by your ideas. So you've succeeded in me and hopefully through this public conversation, we can help you succeed with many more people.
TG:
Well, thank you very much. By the way, thank you for being so patient with all the ... given the duration of everything that just took place here.
SK:
No, yeah. It's wonderful. The more the better. So before we close, I like to finish up, so it's by giving my guests a chance to expose their public API, the different ways in which they want people to interact with them: Slack, Twitter, email. If you're looking for volunteers or employees, anything you want people to interact with you, now's the time.
TG:
Great. Thank you. You can find me on Twitter. I am @girba, or you can go to my website tudorgirba.com. But probably the more interesting things that are happening these days around me are happening around the company, I would just call it feenk, so I don't do feenk.com, You can also find us on Twitter @feenkcom.
TG:
We definitely love any type of interactions. We now made Glamorous Toolkit public, we now reached version 0.4.0, so it's not yet at one. But we love to have people that would like to have the conversation with us. So if you do try anything we have played with or put forward in some form, please do engage with us either by, as I said, on Twitter or we'll probably also open some other channels of communication such as chat on our websites.
TG:
Otherwise, just contact us by email, and you will find those emails. My personal email is tudor@tudorgirba.com, and feenk you can contact it at contact@feenk.com. Yeah. The other obvious link is gtoolkit.com, that's the Glamorous Toolkit website.
SK:
Great. Well, thank you again for your time and I hope to speak to you soon.
TG:
Yeah, thank you very much. It was a pleasure.
SK:
Okay. Bye.
TG:
Bye.