Future of Coding - Moldable Development: Tudor Girba

Episode Date: February 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. https://futureofcoding.org/episodes/036Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello and welcome to the future of coding. This is Steve Krause. So today we have Tudor Gerba on the podcast. And Tudor is a really interesting person for me to interview here. And if you haven't heard about him and his work, you're in for a real treat. Tudor is involved with the Pharaoh project, which is kind of like a small talk operating system modern day reincarnation thing and it's really cool he's working on something called the glamorous toolkit which is built on top of pharaoh which is a development environment that looks really nothing like any ide you've ever seen before it really um rethinks the way programming is done in a creative way. And so he talks about the vision behind that and, um, some of his other projects.

It's a, it's a really fun conversation. And, um, it's one where he, he does a lot of the talking. It, it, he has, he has a, he's a really brilliant guy with a lot of counterintuitive and interesting things to say. And so I kind of just stay quiet and let him say those things. So I hope you enjoy. And before we bring in Tudor, I just am going to say the quick message from our sponsor. 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, so email jobs at repl.it if you're interested in learning more. And now I bring you Tudor Gerba. Welcome, Tudor. Welcome. Thank you for having me. Yeah, thanks for taking the time to tell us about what you're working on. So 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? Yeah, sure. So I've been into the area of software analysis, software evolution. I started my PhD and then postdoc in 2002 until 2009. And then 2009, I started to, I created a method, which is called Humane Assessment, and then went into industry to validate it. And basically, the idea of the method was to tackle the problem of code reading. I guess we're going to go into this a little later, or better yet, of not reading code. And so three years ago, I ended up co-founding a company, and so here we are. Very cool. Yeah, so I guess let's start with this humane assessment. What was the goal behind that?

Right. Well, we started from an observation. I found it really curious that in the 2010s, we would still have research papers saying that developers spend 50% of their time reading code. What was curious about it was that I could also read papers from the 80s that were saying basically the same thing. So my question was, so what's the difference? How did we improve the situation? Because everybody seemed to agree that that was a problem. But it also seemed that whatever we have tried didn't really make a dent.

So, yeah, the question was, how do we change this? And 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 not the right way, but perhaps a fresh view would have been in order. So I've been working on, during my research, I led the work on this platform, which is called Moose. It's a platform for software analysis, well, software and data analysis. And basically the longest living, probably, such platform in research.

It actually started, wow, I think now, when was it, 96, so a long time ago. And I started to work on it in 2002. And the goal of that platform was to support research. So essentially we needed to write papers about new approaches in software analysis and software evolution and software visualizations. And so we created a platform such that we can churn faster ideas in this field. And 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. So 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. And their life will be much better. So I started with the first problem, the first case study or first real, at 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 I got the second one and the third one and the fourth one,

the fifth one. And the assumption there was that there would be something that pops up as being repetitive. And the only repetitive thing that I found was that there would be something that pops up as being repetitive. And 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 the tools. And that was fascinating because tweaking the tools means that there is no button. There's nothing to click on. And so, if there's nothing to click on, it goes against this idea that you would

give a cookie cutter that will be applicable to all systems. And so, then I realized that perhaps that is the special thing with software. So 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. And as a consequence, there is no way we can predict the specific problems from the outside. So when we predict the specific problems from the outside. So when we look at the project from the outside, we don't know the exact problems that people will have inside that project. We can't 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. So understanding some dependencies is important. But how those dependencies, you know, which dependencies, what kind of dependencies, how are they actually captured? Because most of the time people just look, for example, just take the 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 sharp or JavaScript, and you look at the calls in there, 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. And it's all fine, except that most systems that I'm looking at today have real significant dependencies that don't look like that. There is a string in between.

So the JavaScript, this module over here, will have a string that will denote some other component that will be injected here at runtime. And then that's the dependency. And that mapping is somewhere else defined. So, if you don't know how that mapping is defined, you will not find the dependency. So, what appears to be a generic problem, it's actually not. It depends on the context. The details depend on the context. So, 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. So the only solution that I imagined was that we needed to get people, the developers, to create their own tools. Because there is no clicking tool assumes that if it's applicable on your system and it's applicable on my system, by definition it means that it has to capture what's common between our systems.

But it also, by definition, it cannot capture what's different. And our value comes from what's different and not from what's common. So in order for the tool to be relevant, it must be contextual. So that's the essence of humane assessment. It started from this realization that, well, we have a problem. So when we say 50%, you know, of the time allocated to reading, we're actually talking about the single largest most, you know, the single largest expense we have in our job. And then here's the funny thing. So, I've been spending several years talking with several thousand developers. And I'm asking them if they agree with this statement that they spend this huge amount of time. I usually ask them if

they spend 50% of their time. Usually half the people that I ask answer that they spend at least 50% of their time. This is by far the largest expense we have spent on one single activity. But then I asked them the other question which is, well, so when was the last time you talked about how you read code? That is, how you do the reading. Not about the code you read, but about how you do the reading. And it turns out that that's not much of a conversation subject. Well, if it is in a subject of conversation, it can't be optimized.

You cannot inspect and adapt 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. And we think that it isn't because, you know, reading also happens to be the most manual possible way to extract information out of data. And by the way, you know, 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, so not when you learn, but when you're in a project, most of the time, so the large majority of the time, The goal of the reading effort is to understand enough to make a decision. So from that perspective, I look at software engineering as being primarily a decision-making business because that's what occupies most of our time, rather than a construction business,

which is what we have optimized for for the last 50 years. So yeah, I started at that, you know, 2009 with this, 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. And I created this method by which I say that there is a systematic approach to spend this 50% of the budget. And it is applicable in many different situations. So for the last nine years, I have not found a situation which it is not applicable. And the essence of it is that we should create the tools that will match our context. So I just want to like uh get clearer on the

some of the terms to kind of go back over the stuff you just said um so this humane assessment uh methodology it's it's what you just described as the like decision making it's like thinking about software development as decision making which i think makes a lot of sense and so um this glamorous toolkit project we're going to talk about later that you've been working on um my understanding is that the glamorous toolkit enables the humane assessment or or is that not quite right can the is a humane assessment like is it possible to do it like in any project right um so humane assessment is something it possible to do it in any project? Right. So humane assessment is something that you want to do in any project. And it's applicable.

It has a very wide range of applicability in that it's, how should I put it so we get i guess sorry if you could yeah you might be about to do this but if you could give like a concrete example like take us one cycle through the humane you know with a with like a sample problem right and there are at least three different you know talking about humane assessment there there are three different application areas that I see. So when people, for example, let's say when people look at, let's just take code problems, like things that people assume to be maybe architecture related problems or so. So there we have, I see problems split into a space in the following ways. And rather than seeing analysis, you know, when people think about software analysis,

maybe you have dynamic analysis versus static analysis, or maybe you have bytecode analysis versus source code analysis, or maybe you have one version versus many versions, or maybe you have something that is textually represented versus a visual thing. And that's all interesting. These are all interesting decomposition on this page. But if you think about the problem, like me as a receiver,

as the one that wants to utilize the results of the analysis for making a decision, it's not really useful. It's not guiding. It's very interesting for a tool vendor to decompose the space like that. And that's why we actually start to, we have industries around these notions. You know, for example, we have an industry around monitoring, as if monitoring would be a completely different subject than, you know, 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. So a different way to look at this space is to look at the kinds of problems that people have. And they are distinguished through 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 a one-time occurrence? So what do I mean by that?

Let's say if you have a bug, ideally, that should be a one-time occurrence. And this is that bug, right? And then you solve the bug. You have to spend the time to solve the bug. And I call that thing, that time, the energy that you spend there, I call that one a spike assessment because it's very, very well defined. You know exactly when the bug starts. You know exactly how the bug looks like.

And as soon as you can write a test, you know exactly when your bug is done, right? So that's one way to look at it. On the other hand, right, as soon as you're having that test, now the test is of continuous interest and it moves into a different space. So now let's take an analogy and then move this one to something, whatever people call architecture. 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 plus one answers. And so, which

is actually quite funny because, you know, most books that I read on social architecture, usually on chapter two or three, where they talk about, you know, what architecture is, they all kind of say exactly the same thing. And 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 plus one definition, which is a fascinating point of view because we can go into that one as well. So I have a different perspective.

I think that we're asking the wrong question. So rather than asking, you know, what architecture is, I ask, what is architecture for? And that's a different thing because, you know, usually people talk about architecture before they want to do something, before they want to make a decision. That's when architecture is interesting. So it's funny for me, it's interesting. It was an interesting observation to see how, you know, from whatever angle you look at software, it somehow boils down to how do we make decisions? The other thing about architecture is that whenever people talk about architecture and something is not architecture,

all of a sudden that means that somewhere there is a line and if you cross that line, you're in non-architectural land. And if you go back, then you're in the architectural land. And in the architectural land, you use, you know, because it's a different land and you have different tools than in the non-architectural land. And I don't know what those tools are because one of the things we saw is like, let's say dependencies. We can talk about dependencies between classes or really a micro level

or we can talk about dependencies between systems. There's still dependencies. You will still think of them in the same way, but for some reason, one is treated as if it's an architectural problem and the other one is treated as if it's a detailed problem. The thing about software is that, you know, it's like, you know, 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. So it isn't. Those details matter. There is no detail that you can take away. Then you say, well, it doesn't matter. At some point, for some context, that detail will matter. So let's say the other thing about architecture, when people think about architecture is that they think of it as, you know, you equip yourself with some

tools such as you can build architecture. That means that there are some problems that are not architectural and then there are some somehow of lesser importance. But let's take a very concrete problem. Let's say your system is down, right? And it's down because of some issue in the configuration that, you know, when during the deployment somehow made the system to crash, to not be responsive. So now, is that an architectural problem? Because it's just one line in the configuration. People would 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. So all of a sudden, why do I have that arbitrary distinction between, you know, what is architecture? I don't know. But I can go back. So going back to humane assessment, the reason why people, well, I believe people have put so much emphasis in architecture was because there was a time when we were writing these long, you know, large plans before we would start building. And as soon as we would go out of the script, we would leave the script and, you know, trail along somewhere, then we would know we are lost and then the whole thing is doomed. So the assumption there was that we need to have discipline

to follow the plan to the point. And these were also we started to instill the idea that we have people that think and people that implement, which I also think is wrong. Or not necessarily wrong, but yeah, it is wrong. But it's also, I mean, it's not fulfilling and it doesn't match and it doesn't utilize our abilities to the best of our potential. Yeah, I would agree with that. Right.

So coming back to, so what's an example? Let's talk about architecture. What's an example of an architectural issue? So let's say that I have, I just look into the code and all of a sudden I see, oh, somebody is using my private API. So it's four o'clock in the afternoon at 5, I have to go and pick up my kids. So it's 4 o'clock, and I see somebody is using my private implementation. And because of that, I cannot refactor my code.

And because of that, I cannot really nicely implement the function that I want to implement. And, well, at that time, I have two choices, or probably more, but 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, you know, is using that private implementation. So at that moment, it's a little tricky because now it's not just a technical problem, but they actually have to go and engage with somebody, right? They 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're not available. So what's going on? How do I deal with that? Because it's not just a pure technical problem. So, the other thing, so the solution from my perspective, one solution would be to actually document this problem.

But when I say document, I don't mean because now if I can specify exactly what the problem is, that is this code or this private implementation should not be called, let's say, from outside of my bounded context, because always it's a nice, you know, it's very popular, this notion of a bounded context. Let's say that I have a bounded context. Maybe I mean a monolith. I want to split it into microservices. So, we have decided to use these bounded contexts. And now I don't want people to use, I want people to use me, my bounded context only through the public API. So I can now specify exactly how that thing should look like. Well, I can either, you know,

write a confluence page about that, or I can write a tool that does the checking. So 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, you know, maybe we have three different valuations for that specific thing, even if I originally maybe only have seen one such valuation. So now imagine that there is a team, the team always assumes that such problems occur all

the time. Because 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 that I have many architects. Well, if I have many architects,

it means that architecture is a negotiation, right? It's how do we, it's a commons from this perspective. And the question is, how do we it's a commons from this perspective. And the question is, how do we organize the negotiation? It's funny because when we have the problem between negotiation, the need to organize the negotiation between technical and non-technical people, we started to put all sorts of mechanisms in place, for example, a daily stand upup 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 get in time, and then they can make decisions. And now the question is, how do we negotiate technical problems? Because here's another question that I very often ask. People ask, is architecture as important, do you find that architecture is as important as functionality, at least in the long run? People say yes. Well, let's see what does it mean. Well, you know, functionality is treated first of all, is considered a business asset. That is, you know, it's the thing that makes the system valuable, right? All the functionality is important as architecture also immediately

follows that architecture is a business asset. And then the question is, well, how do I invest in this business asset? And I can see, well, you know, in functionality I have testing and I have specific, maybe even roles, I spend, I have specific practices that really take care that the functionality is in the place where I want it to be or of 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 that I put into our functionality? Can I put the same, do I put anything similar into the architecture?

Well, it turns out no. But what if I could do this, right? Coming back to our dependency problem, what 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 architectural test, it's not a functional decomposition of the world, it's a structural decomposition of the world. And it's equally important to the functional one.

And so once you have this, now we have an opportunity to have, 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 problem and say, well, this is an opportunity to understand why are there different points of view. Because nobody, if you assume that nobody is, you know, if everybody is doing their right or doing their best to do things, then that means that nobody is just, you know, 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. So imagine that you have a meeting in which you can immediately, you can just in that meeting or that stand-up, let's say, we call it the 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 detection that actually shows there is a problem somewhere in the system. And then so me, that I was the one that was, I'm the stakeholder of that problem because I discovered the problem. And so me as a 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. So now if you talk about those things, maybe the first one is, oh yeah, I didn't know that this was the rule. I just did it by mistake, but I can no problem. I can call the public API. The second one says, yeah, I think that's just, that's not really much of a problem. But the third one says, well, I did it on purpose.

What do you mean you did it on purpose? You called my private implementation on purpose. Didn't we just discuss about the context, the bounded context, and then the wish to go towards microservices and so on? I say, yeah, but you know, I have a different use case. Look, you have designed your component for single calls, right? You have to optimize it for things that maybe come from the UI or so. So single types of requests, but I have a batch node and I want to work with your model, but I need a batch.

I need deeper connection to the database because I need to send much more data through it. 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. And what just happened, these kind of conversations are very interesting because I've ran this one multiple occasions. And in one occasion for 3 and 1 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 to actually see that this thing actually works. And it did work. And we could have, 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 this stand-up was actually not to disseminate information, but to actually make decisions. Figure out, do we go this way or do we go that way? And it turned out that in more than 90% 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. And so the only, the differentiator between the two scenarios is the input.

When the input is open-ended, then the result is usually open-ended. When the input is confined to 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. And so it has to be very, very concrete and it has to be very, very specific. And if you can make these economics to work, then you can change the way you make decisions about software. So this was, right, so I saw I had a problem in my case. I mean, 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, you know, architecture usually is something that you care about for a long time or for all the time, continuously.

So 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. That 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. But it's not just about code. So we look at very often code is the most prominent 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.

And then this is what do you do when you have text in front of you and you need to understand it. And then you read it. But code isn't text. This is what 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.

And yet we're doing this where we're 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 challenged even the most basic assumptions we have around us. If you think about just most IDEs that we have around today, every time a new one appears, quite a few appeared recently, they all start from advertising the editor. Because the act of construction is what captures the conversation. So I think that's a problem.

And it took a while to understand why is it that we cannot get out of that loop. And at some point, I went back to the work of Marshall McLuhan. And 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 one article, which I find a really brilliant summary, it's a couple of pages from John Culkin. And one of the things he's coining there is as a summary of some of the points

that Marshall McLuhan's making is this phrase that took off afterwards, which is, we shape our tools and thereafter our tools shape us. I got stuck, that statement stuck in my mind for a while and I couldn't figure out exactly what do I do with it. And then it hit me because, you see, if the tools that we use end up changing or shaping the way we're going to 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 will determine the way we're going to think.

Let's see, how does it one look like so i just i just ran a on twitter i just ran a poll and i asked people if um if they if they check their phone within five minutes of waking up yeah and uh it's it's really funny because most people do check it within five minutes of waking up or maybe 10 minutes and um the interesting thing is that this need did not exist 10 years ago because the tool wasn't there 10 years ago. There was nothing to watch on the phone when waking up 10 years ago. So that means that it's really a striking correlation that basically should lead us to 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. 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, let's say, well, something's wrong with the data, and maybe you have some sort of a relational database of some other form of database, and maybe you 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, they refine the query, they look at the result, they refine the query, look at the result, and find the query, look at the 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. But now if you take the same developer and you give the developer a problem in source code, then you'll find that developers will spend a lot of the time scrolling. But scrolling is just gathering information out of data. That's why people do the reading. And so the two different spaces are actually not different. They are exactly the same kind of problem, the 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 you look at a typical database, the first thing that you see in that database tool is a big query box. It's a big query box on top and you write query, and you look at the data at the bottom. So what do people do? They write a query, look at the data. And when you open a typical IDE, well, you see a giant text editor. So what do you do?

You scroll. And so the only... 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 do we, our perception of source code. But just because, you know, 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 a 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 navigatable. It does not have to be read. In fact, developers, most developers I know, are paid specifically to automate, 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. And 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 try and make them into decision-making problems. So you talk about clicking problems and buttons and how they don't allow for generalized solutions why is that exactly right so because the button assumes the problem right i encode you know in the behavior of that button i have encoded what i think your problem is going to be and i cannot tell what the problem with your specific problem i cannot tell i can only predict classes of problems, but not the specifics. So as I said, like 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. Yeah, so this is how we look at tools. We look at tools. 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 runtime problems, static problems. That is, you start with a hypothesis, and then you construct the experiment, you apply an analysis, you get some results, you interpret the results,

if you're confident, you make a decision. If not, you repeat. But the thing there, the key element there, is the experiment, the analysis. Because for most problems, for most practical problems, there is no ready-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. So yeah, so in our case, with humane assessment, what I said was the essence of it is you ask 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 try to craft it.

And that's the key. So the interesting is how do you make or customize that, create the experiment to give you the right data? And the reason why people, you know, why 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 it's very slow and it's very inaccurate. But other than that, it can deal with any context, right? It can just jump from a source code or a class or whatever, maybe a function, and then just quickly go into a

configuration. And the eyes will just completely handle that transition. A tool might have much more difficulty doing that. So that's why it's so tempting to use the reading. The problem with it is it doesn't scale. So if people think that they understand the whole scope, well, 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.

And then you don't have to be, because now, you know, maybe nine years ago, when data science was not so pervasive, you know, it was a little bit more, you know, people wouldn't necessarily understand that it's possible to make decisions in a different way. But now we have, you know, companies are, 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, right?

A Jupyter notebook is exactly that. It's an analysis. It's a crafted tool for a specific purpose to ideally support a kind of a decision. And it's highly contextual, and its effectiveness is measured through the decision that is being made on it, right? 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. And yeah, so this whole thing we started from in this, to practice this, I started it through the lenses of the Smooth Analysis Platform platform and the goal,

right? Because as I said, we just, we optimize the platform to be able to do experiments faster. And all of a sudden it turned out it's very, very practical. This ability to have, to be able to build an analysis, a query of visualization in an interactive browser, to build in minutes, like literally minutes, and maybe a few, maybe 10 lines of code or so. And then just take that tool, apply it to a problem, and sometimes use it for 30 minutes and then throw the whole tool away.

It's absolutely possible, right? It's absolutely economically feasible. And then it completely, it opens up a whole new way to start thinking. But the key there is that to make it economically viable is that the cost of the tool, 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, to build an environment where you can systematically

build these tools. So, yeah, this, three years ago, we took that idea, well, actually, no, about seven years ago, we started to, I just realized 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 moose and I'm using it 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. That was 2010, 2011. And so this is when this idea of multiple tools started to shape up. And then a few other people, including Andre Kish, who did a brilliant PhD on this subject, and Alex Acerel, who then joined the team to create further tools to refine that inspector and then create a different kind of debugger that would basically be customizable.

If you think about an inspector, all inspectors in the world basically show you a tree. Whenever you look at an object, you see a tree.

That's the widget, a tree with key and values. Because the people look at their tools and then they say, the inspector, and then they say, well, the inspector should show me the interior of the object. And you want it to say, well, what if I want the inspector to help me understand the object? And so in that situation, the example that I give often is really this. So imagine you have a dictionary or, you know, in Java,

maybe it's called a map, right? So you have key values, right? Keys and values. And you want to take, 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. People draw a table, right? Because that's what you do with keys and values. You put them in a table. It's very

natural. So that table seems to be interesting from a communication perspective because when people wanted to communicate what they knew to somebody else, they use this picture. And now the question is, why is that picture on the napkin? Why is it not on the screen? Because it's not like a difficult to draw picture. It's just a table. So this is when we turned this idea of the inspector around and said, well, 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 I want to look at the Intel data structure. Sometimes I just want to see the table. Sometimes I might want to see a different thing, like how much space do different parts of my object occupy, for example, if it's a memory problem or so. And then it turned out that different objects would be very interesting to look at from various different kinds of perspectives. So for example, if you look at a directory, you want to see the contents of that directory.

You don't really care much about what's inside that, you know, how the directory object is internally represented and so on. And so we created a first environment around that idea. So we were originally a team of five with Uri Kobelka as well and Stefan Reichardt. And that first version got into Pharo. So P-H-A-R-O, that's pharo.org. That's the language that we use, language and environment that we use. And yeah, so that was the first incarnation of this project called the Glamorous Toolkit, which is a moldable IDE. So the idea of this IDE was,

well, if this assessment, if your main assessment works so well for, you know, for supporting these decisions, but kind of through an external tool, the question would be, how would the development experience look like once we start to make it the core

experience. Because ideally, we want to, and we did not start from an editor. So for the last, essentially, seven years, we work on this problem. And we only started to work on the editor in the last year or couple of years. Because that's the, you know, editing ideally should be the thing that happens after you know what you want to edit. So, yeah. And then it turns out that there's actually a lot, there are a lot of new, there's a lot to learn from, by looking at the software development from this perspective. So, yeah. And then three years ago, I co-founded a company called Fink, F-E-N-K. And the stated goal of our company is to reshape the development experience.

And we are now producing the next generation of the Glamorous Tool toolkit that you can find at gtoolkit.com. And a couple of months ago in September, we reached the very first visible alpha version that can be now downloaded. And since then, we're going to release new versions until we reach something that is stable or production ready, let's say. So what's the story behind the name Think? Yeah, so Think stands for feel and think. Because what I noticed is that a lot of our work is dominated by objective facts. And I also noticed that developers are not really happy. I literally ask people if they love working with legacy systems.

And people actively hate it. And that's fascinating because this is what occupies most of our time, right? And so it follows that we dislike our job for most of our time. And as Chad Fowler once noticed, was that is... So software is probably the only domain in which legacy has a negative connotation and i think i think we should change that and a lot has to do to me with the fact that we have forgotten to 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 and that we should actively invest

in our pursuit of happiness. So anyway, that's the story behind the name. So I really like your metaphor that up until now, we've thought of programming as like it's construction, like we're building physical artifacts such as bridges. But that's the wrong metaphor because bridges have a specification that you know up front and then you build to the spec and then over time 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. And software is much more about decision making than it is about adhering to a rigid specification. So it makes me wonder, is a better metaphor for programming, maybe like business, you know, like, like, business people start with a business and they iterate and they make decisions over time

that they don't adhere to like a rigid business plan. Would that be a better metaphor than construction for programming? Yeah, that could be one thing. But another thing to compare with is philosophy. Maybe not necessarily because of the, because of the decision-making aspect of it, that the, so in software we have this, we make dozens of decisions per day and usually in, with only partial, partial data available.

So it's from that perspective is highly stressful. There are other kinds of, I think, areas in which people can, or there are not that many other places where humans are subjected to this type of stress, but there is a different way to look at. So another poll that I ran recently on Twitter was that I asked people, do you create or do you implement software? And most people think

or they define their work as being creation work. Because I was wondering about... I'm very much interested in the feedback loops and in the effects that the feedback loops have or the invisible effects that they have. And one of those, right, 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, right? We have stories that we transform into tasks and then we implement those. So there's a certain kind of thinking that goes into that type of decomposition. But if you look at the job of implement, of 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, you know, software implies the translation. So the software development or programming implies the translation of my understanding of the world into a format that is then executable. And that is very much similar to philosophy. And I look at it, you know, from that perspective, I look at programming as being executable philosophy. And I think that's much more interesting. It's much more appealing. Because then the whole process of, you know, there's an assumption somehow, there's an implicit assumption that

there is a good and a bad way to do things. And I think that there isn't. I think there are only variations and there needs to be playfulness because otherwise you will just not be able to explore the whole thing. And much in the same way as a philosopher would choose a paradigm to look at the system at the and the world in a way through by ideally decomposing the world in very few principles and then trying to see how far can those principle principles get you to describe and express, you know, or explain the facts around you and maybe describe your point of view towards those facts. And so coming back to your 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. But on the other hand, we can also focus on the method of decision. It's a way philosopher would puts emphasis on what, how do I decompose the world such that a new problem that appears is trivial to answer because it's just an instantiation of what's something I already know.

And that seems to me is much more, you know, I look at programming as being the largest philosopher experiment that we have conducted as human species. And I think we should probably look at it more and, you know, build maybe the tools around it to support that view. Yeah, because the thing is, so, you know, I was saying that developers are not particularly happy about their job. And again, there's somewhat of an expectation that, first of all, software has to be in certain form. And on the other hand, there is the discrepancy between what I think I want to do and what I actually can do.

And 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. And it's highly frustrating. And I can totally understand that. And to the point in which now, so after I've practiced multiple development and humane assessment for the last nine years and multiple development for the last five, and 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. And I very much pay attention to how much I smile. And I smile a whole lot more when I have, especially when I have interesting problems. Because all of a sudden, I can take a problem that otherwise looks tedious because, you know, just think about it. It gets me a little bit pumped up when I see, you know, a developer having an exception, the first thing a developer does is to paste it in Google.

It's crazy, right? Because basically, we have gave up the idea, we have gave up the, our, we assume that we are unable to have, we don't have any chance to solve that problem on our own. That all this discovery that comes from this philosophical perspective, it's not. It doesn't exist because we have created software and we are equipping ourselves in a way that prevents us from actually discovering things. So to my mind, Stack Overflow has success

exactly because environments and languages and libraries are failing on a large scale. So, yeah. And that's the primary goal we are having is actually to start the conversation. As I said, like we do not talk at all about how we read code. And in the end, we just end up pasting our exception on Google and hoping that somebody has asked the same question

as TechOverflow. And then copy-pasting that solution, trying it locally without necessarily understanding cause and effect. That's not how creation should happen. This is not how... By the way, the reason it's called humane assessment is because I think that if you see a person plowing the field with the bare hands, you will tell, well, that's inhumane. So when I see a developer having to scroll and make decisions by scrolling through, you know, a million lines of code, I think that's inhumane.

The humane way would be to make it appropriate for whatever fits the human brain. And yeah, so I think that we are right now not treating our developers and ourselves in the right way. Yeah, I would agree. And it's sad. Yeah, I'm totally not sad. I think that, so I'm very much convinced that, first of all, when we as an industry, when we 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.

So, for example, microservices became a real public subject maybe around 2014. And 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. And that's crazy. And that's amazing at the same time. So once we understand that something is worthwhile having a conversation about, we do very, very quickly improve the situation dramatically. And that is what I, the primary, our primary intention is to start that conversation. And now we built the IDE or 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 build 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, but it's actually very, very concrete. And people can start to feel and touch it because i think this is what changes people's minds yeah i would definitely agree that this is the kind of vision that you need to see to to understand and to really feel what it is that you're trying to get at um so i just have to say thank you for taking the time to give me

a video demo of the system a few days ago, because even just 90 minutes of watching you interact with it has been very influential in my thinking over the past week. Yeah, it's really one of those systems you have to see to believe and to get a sense of it. It's really one of those systems you have to see, to believe, and to get a sense of. 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 really 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.

Thank you. Indeed. We will, we will definitely, we are actually definitely working on that. So there's a couple of, as I said, so far, we have focused a lot on creating the first incarnation of, let's say, the complete or not if people watch or follow our Twitter feed at Fing.com, there we do a really interesting experiment from our perspective. And that is we post pictures or small animated videos with tiny details. And those details, and afterwards,

maybe there's a small description, a sentence or so, and then the picture. And those things get retweeted, for example, or they get liked. And 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.

You can go and see them at ping.com. And so what's interesting about that experiment, as I said, with the Twitter feed is that we're taking, we're also practicing something we call demo-driven design and development. And that's the idea that we want to, so we want our system to tell a story at the end. And for the system to tell the story, we have to build the story in the system. And by story, I don't mean that use a 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.

And we want to build these stories into our system. And so what you're seeing there are actually absolutely irregular artifacts that are being produced as a result of normal development. And we've done many, we're doing, you know, also we actually, we're funding ourselves. We are a consulting company as well. And one of the kinds of projects we're doing is we are actually helping people tell stories about their system.

And those stories may be either technical in terms of maybe, you know, architecture. So how do you decide, how do you make decisions about architecture and so on? Another one would be about how do you describe your domain in some form? So, you know, ideally in a live form. Usually people describe it in documents that are typically static and difficult to maintain and so on. But, yeah, so we're also creating,

we take the domain and then we model it. But the interesting thing is not the model itself, which is, let's say, you take a domain-driven design approach. At the end, you get which is, let's say, you take a domain-driven design approach, at the end you get the model, let's say. But the interesting thing is that because we are in a moldable system, we can project various kinds of views onto that system and wind them with a fluent documentation. And that really changes how we can engage with people because we can take absolutely arbitrary details

of other systems and make them understandable and approachable by other people. And very often the people we engage with are actually non-technical people. Imagine taking the core of your system and describing it in a way that a non-technical people, that non-technical person could relate to and start having a meaningful conversation about within, let's say, five to 10 minutes. That's the promise.

That's the idea. I understand that this is abstract and I know that people have to 10 minutes. That's the promise. That's the idea. I understand that this is abstract and I know that, you know, people have to see it. And so we're creating, we will definitely create a lot more. You will see a lot more visual descriptions of our workflow in the near future.

So either through our social media channels or just make a way to OGToolkit.com. So 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. Right. So as I said, Glamorous Toolkit is an IDE and currently it's an IDE for FIRO. It's implemented in FIRO and it is an IDE for FIRO. And it has a number of, it's not just a,

it's not a monolithic tool. It's rather a uniform set of components that basically fit together. So one of the things we look 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. And so the goal here is to allow, so the Glamorousrs toolkit is a moldable development environment and moldable for us means that it's the is the property of the environment that allows the developer to mold to adapt the environment to the specific problem to the specific context of the of the current in maybe investigation for example when we look at the inspector or whatever the current focus is, the environment should adapt to that focus

rather than the developer should adapt to the environment. And that's this point of view, we think lends itself better to creating more humane interfaces. So moldability for us is a core property. lends itself better to creating more humane interfaces. So moldability for us is a core property, is the property we want, the first property, the most important property we want to optimize around.

And 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 the, this is the expressivity part of it. So 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. So this is the expressivity thing. And 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 on the inspector, that's the, 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. I said before I was talking about the map or a dictionary of key values. You want to look at that as being a table, but maybe if I inspect an instance of a file, let's say that if you're in an object-oriented systems, which Caro is, if I inspect the instance of a file,

and the file in that instance points to a directory, then what I would like to see in the inspector, I would like to see the contents of that directory. And I would like that presentation to be shown to me just like I see it in the normal, in a typical file browser tool. So we have these different views and the succinctness part of it,

of the environment is how much does it, or 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're able to look at an object and say, oh, I want a different view. You'll take a few minutes, create that view, and then continue the investigation.

So that's what we envisage as part of the workflow of the developer. So that also implies that the developer knows or can, has that skill of adapting the environment to whatever is needed in the current context. And that's obviously, that's a skill. It's a new kind of a skill. And we think that that's actually an essential skill, software engineering. So 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. And 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. And so imagine, you know, similar, 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.

And for each of the columns 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 you will give you the next object and then this is how you can navigate through the system and it's it's very interesting 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 and so to allow the developer to customize things. So the other part of it is about the Glamorous Toolkit is, you know, like 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, the only means that it also follows that we cannot give a clicking tool because a clicking tool implies the problem. It's 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. And so our solution to that is to provide 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 developer should be quickly able to resort to programming, fill that gap, to create maybe an extra view, or just write a query, or transform the data from one thing to another, and then continue probably the investigation again in the UI. And all of that should happen seamlessly in the same workflow.

So doing like this, let's imagine a couple of workflows. So 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, maybe that XML has some sort of configurations and we want to, maybe that XML has some sort of configurations. And we want to, maybe the configurations have a specific tag,

which, for example, denote, I don't know, a job or a service or something like that. And 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? So normally people maybe open up a file finder or a command line, you go into the correct folder, and you find the file,

and you open the file in a text editor. So that's another tool. And in the text editor, because maybe if the editor is reasonable, and these days most editors understand XML, then you will have some syntax highlighting. But maybe your configuration file, let's say, has a thousand lines, which, of course, it shouldn't have, but it's not unheard of. And maybe your tags, the ones that you're looking for,

your service tags, for example, they are spread throughout those 1,000 files. So what do people then do? Maybe people do, maybe they press Command-F or Control-F and then they do a file 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 is we parse that XML file. And then after we get a 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 are actually is a possible workflow, except that they typically would happen in multiple different environments. So navigating the files, 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 X

path would be another tool, which would probably be some sort of a code editor or something like that. So in our case, all of these actions, they happen just in a plain inspector. So navigating to the file, looking at the file directory gives me the contents. Clicking on any of the directories gives me the next directory. Looking at a file that points to the XML will give me a view on the 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. And because I'm in an inspector and the inspector gives me a full programming language or makes the 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. And the document now knows that I can write an X path over it and will give me an editor for writing an X path, and I'll write the X path.

And then executing the X path over the document will give me a collection of elements. And now the collection of elements shows me a list, and I will click on 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. So that's just one of those kinds of examples in which we classically look at these problems and we see different silos. And 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 workflow.

The necessary, let's say, code is actually not large at all. 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, oh, here's, you can write an SQL query, for example, if it's a database, if it's an SQL database. And then you write an SQL query and the result is going to be what? So it's going to be another result object.

And how do you display a result of a query, of an SQL query? Well, you'll display it as a table, for example. So there will be a view there that shows you a table. And so, yeah, again, it's everything, all of these will just happen 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. So yeah, that's maybe the gist of the glamorous toolkit. 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 transcript, we call it.

And 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. And it can, those artifacts can be inserted even while you type, for example, by the syntax highlighter.

So imagine that instead of just saying, oh, this text is bold, you say, because of what you've typed, I will insert a certain picture just below that. So you take even a boring tool like a console. Now, instead of just, you know know just putting outputting text you can output whole widgets or whole objects and represent that 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 with graphical parts because we have implemented our own graphical stack in order to implement our IDE. And more recently we utilize this console or the transcript

just to debug, to visually debug animations. And it's such a simple tool. And again, people would look at it as a reasonably boring and an interesting thing that you just need to have. And except we think that it can be an interesting place. So transcript is one of those tools. Another one is documenter. So documenter is a little, we think it's a little hard to describe because on the one hand is a notebook. So imagine a data notebook that is writing the IDE.

On the other hand, 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. And all these things are happening, so you can embed into this editor various kinds of graphical things,

and you can just have reasonably appealing documents that you have that combine textual and graphical representations and even code that you can put in there, except that we never really copy the code that we 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. And so the writing of the documentation boils down to simply having a few lines or few pieces of text that provide the context of the story that you want to describe, but the real code isn't really in the document. The real code is usually in another place, maybe in the code or maybe in examples that you write about our code. And 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 provide, we can build up live documents that can be utilized for all sorts of purposes, going from all the way from highly technical things to tutorials, to including business or documents that are relevant for business people, for non-technical people. So those will be a couple of those tools. Then we have a debugger.

And then we have a whole coder experience. So this text editor that we created lends itself to implement a new, we think is an interesting experience of playing with code. For example, imagine that you can see that the certain, maybe you're referred to a method and as you refer to that method, you want to see, expand that method right in place, in the same place.

And then, so you can do that right in the same editor. So these are a few of those tools that we have. So next to those tools, we also have the engine. So I mentioned briefly examples. So we're no longer working following TDD, so test-driven development. since now a few years, we're working exclusively using example-driven developments. So examples are these, is based on an idea that a colleague of mine from the PhD time, so made it or brought it to my attention, and he did his original he did his phd on that topic

um is this idea that so when we write tests very often people say testing is the tests are very useful for understanding the systems maybe the first thing people would 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 interest in the test is in the setup part.

So that is, how do you construct a complicated object? And most systems, whenever you go beyond the trivial, most systems have a reasonably complicated dance to set up an interesting state that then afterwards you can build on. And there is a very interesting knowledge that you can extract from looking at tests. But a normal TDD workflow basically does like this.

You write an assertion, right? And then you make the assertion green. And at the moment when the assertion is green, you stop working with the test. In our case, we do it a 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 return that object. It's just a simple change. And as I said, that idea was introduced by Marcus Geli in his PhD. And it's very interesting what happens once you start to build on top of that idea.

So now, because my tests just return an object, it means that I can use that object for 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 reusability, setup and the test, and that's it. While 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 without requiring any extra setup. And so if I do that, then I can just build up my test scenario and I can describe complicated objects simply by composition of other smaller objects. When I do that and I combine the fact that I have a return value, and given that in our inspector, objects are a very rich place to, so the 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 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, it has an interesting value because it has the 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. So when I start to combine that one, so that idea, so example gives me a piece of code that produces an interesting object, and that is also asserted, so it's guaranteed to have a certain property.

If I have that example, then I can immediately use, so refer to that example, and then combining with the view, I can embed that one into the documentation. So writing and composing documents can become very, so it's on the one hand, it's cheap. On the other hand, the writing of the documentation becomes an exciting activity. And because, yeah, so that's a, you know, we don't look at our work as implementing features.

We want to change the experience of developing software. And usually we look at the places where, which let's say people want to have, but don't like to do it or something like that. So such as documentation is one of those cases. So everybody likes a good documentation, but everybody knows that documentation is typically not in a good state. And also everybody knows everybody doesn't or most people don't really like to write documentation.

So we've set ourselves to say, is it possible to create an experience that actually changes this whole space? And 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 immediately or very quickly, documentation gets out of date. And it's very heavy to, first of all, to figure out. Second of all, it's very heavy to test and ensure that the documentation is up to date. So in our case, we never copy anything. And the main pieces, which are, for example, in these examples,

they already are tested because they are tests, because we have the assertions there. So a lot of solutions, they 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. Everything should be interesting. Because when we say executable philosophy, we really mean it.

So it should be exciting. Right. So that's a brief overview of the Glamorous Toolkit. Thank you. That was wonderful. So I think I want to highlight one of the things that you touched on, just in case, because you said a lot of things there just in case someone who's listening kind of got lost. So what I remember from watching you,

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 inspect that and you inspect that. So it was like this, this pipeline of inspections. So like one of the things you showed me, you'd start with the world object, which is like, you know, the state of the entire, everything you're looking at. And you can inspect a piece of that. And then you may, you can use a different kind of inspector to inspect a piece of that.

And then, and, and, you know, infinite, it was like an infinite pipeline of inspectors and each inspector was um like a gui so like maybe you would have a query box at the bottom you could like you know click on it and and you know and and each inspector had like 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? Yeah, that's a very good description. Thank you. But yeah.

Okay, great. So 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 like go to use some other tool, the I has failed. And what this always makes me think of is I use regular expressions fairly often. And every single time I have to like open a browser, open a tab and go to regexper.com which is like a regular expression playground and and then i actually save they have a feature where you can save your your regular expression and the examples that you use to test it and i like i copy and paste a link

to that and put it in a comment right above the regular expression in the code to help me and whoever comes after me to understand what was like in my head when i was doing that um but clearly it would be great if if we could you know put that right into the tool um but but then i think the question for me when you start thinking this way is where does it end uh like does he if the ide fails when you leave it like does the whole computer is the whole operating system become the ide is that is that where it ends uh yes basically so that was if you look if you look back at the original uh small talk world uh small talk you know work of around small talk the machine was a small talk machine um well, that was the original idea of it. So the operating system just happens to be some, you know,

pragmatic inconvenience. There's no conceptual reason why we need to have it. In fact, it's just one of those, you know, 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. And there's also, for example, around FIRO, there's work that looks at taking FIRO and using it as the operating system.

There is work around something like FIRO-S. That's the idea of it. But yeah, so eventually, if we look at it, and if we consider the 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. So if you look, for example, at his work around dynamic land, which is amazing to watch, then you see that there is no boundary there either. So we can, and all the work around devices and wearables, they blur that line. And even there, it's not needed. So, you know, in the end, the boundary is provided by the brain.

So whatever your imagination is, that's what computation should become. Other than that, I don't think 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 are don't exist anymore so i think yeah yeah i think it that's quite a um it'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, these meager holes that we can push data out from

one end to another. And on our computers, text is really the way you do it. When you want to get data from one place to another, you're like copy and paste the text and put it somewhere else. And that's part of why text is so important as like a data format because of the composability of our apps is so bad. And so I think sometimes I dream about a world where there are less app boundaries or maybe even no app boundaries and that seems like that's kind of what the glamorous toolkit and pharaoh is pointing towards a world where it's not

like i i build an app and it's like a contained thing and and you just use it um but but it's it's like a different metaphor yeah what is the metaphor that replaces the appliance metaphor for you yeah so so you know first there are a couple of already some assumptions that exist in, in the sentences that you described, but so you're, you're, you're accurate in, in, in what you have said, or from my perspective, except the text doesn't have to be the, the lowest level of, of, or the lowest common denominator. It 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. And as a consequence, we have all these problems that go around it. So if you look, for example, at there is work in metamodeling or around semantic web that actually try to

go beyond that, that limitation. In fact, it doesn't have to be there. There is no real good reason for us only relying on that. It 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 abstractions. When bytes are no longer problematic, or this 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, for me, is the boundary. Now about the apps. So apps, to a good extent, from my perspective, apps, they are also – I was talking about feedback loops. And here we have another feedback loop that ties some developments with economic incentives.

So if I need to – if what I can sell is an app, if people want to buy an app, then it's an app I will build. If people want to buy, you know, but then if you look at the macro scale, there's a shift between, so from individual apps to, for example, services. And so when we go towards services that are just available around the world, and I create my new service just by composing other services, now there's a whole new kind of reusability. The data, all of a sudden the abstraction level has increased. So, 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 structured things.

Maybe it's a JSON, or maybe if you're lucky, you even have a more of a GraphQL type of, of an entry point to a service. So you can describe the data that you are interested in. And that service is that service responsibility to give you that data in the format that you have asked it for, or in the shape that you have asked it for,

not in the format. But even there, this is not really, it's still dead data, right? Ideally, you want to have rich data that understands what it is. So the original idea of the object, of object-oriented programming, had nothing to do with classes or methods. It was about objects that know how to exchange and understand messages.

And that, to me, is a very interesting and a beautiful way to look at or decompose problems. And it's not even, you know, people say, oh, you know, and a beautiful way to look at or decompose problems. And it's not even, you know, people say, oh, you know, object orientation is completely different than functional programming. And then we start to have religions around the tool. And if you look at the original work

and the difference is much more blurred, there is actually much less difference than what people understand now by the two terms. And 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.

And so that's how I think, that's what I see, and that's what I see the future is should focus, what we should be focused on in the future. And now when we go in Faro, so in the Glamorous Toolkit, when we use Glamorous Toolkit for developing Faro code, then we do take advantage of the fact that we have a much higher level of abstraction when that's 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. And now on top of that, just as a layer on top of it, the object not just knows how to answer to messages, it knows how to present itself to the human. So, I mean, these views in the inspectors are basically very similar to how you would write an S string in maybe in Java, except that we don't write, we don't transform it to a string only, we transform it to a widget, so an interactive user interface. And then we don't transform it into just one interactive

interface, we can transform it into many so that we can accommodate better the point of view the user or the human wants to look and engage with the object that is in focus right now. But 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. So another project we have, another component in the Glamrs toolkit, at least in the original one, and we're working on the next generation,

is called Spotter. And that's a way to search through objects, similarly to how you inspect through them. But in this case, you start from an object, and then the object will say, oh, I know how to be searching this and this and this and this way. So it will list you different categories of searches that are possible. And each of that, every search on that category will give you some results. And every result is another object and then gives you another context that can be searched in different ways. And you start to, if you link this into a user

interface, then you all of a sudden you have a completely different way of searching, right? So the search, the way you interact with it, the way you visualize it, the way you interact with it, the way you search through it, and even the way you debug behavior. So we think, so our debugger is also multiple in that a library should, you know, 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 don't, I maybe want to abstract away all the inner calls inside that 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 a hundred different step in, step out type of, you know, debugging actions.

So the debugger now knows that given that this library is on the stack, it will give me a button which says go go 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 will also know what is your code. And 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. But so if you put all these together, right, then we have something that the brain is much more comfortable working with. And the programming becomes, so all this 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. And 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. 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's 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 of abstraction

at the place or the level that I'm interested in, and then investigate there, then all of a sudden, I have a completely different economical setup. And so my incentives have changed. And as a consequence, my behavior will have changed. So we started from this idea that we have silos. And indeed, we do have silos. But I think a lot of those silos are very highly correlated with the economic incentives.

So if you look, for example, at data and social networks, for example, there's a lot of, it's not the, let's say the common good, whatever that is. However, we define that one that drives that, but rather the economic incentives around that media. That's what drives the behavior, that what drives the siloing. And so a different kind 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. I'm really glad you brought up Wikipedia because I think that's the perfect counterpoint to how software is built. Excuse me. It's a perfect counterpoint to how software is built. Excuse me. It's a perfect counterpoint to how software is built. And 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. And yeah, it's just somehow open and more open source. And so I guess, yeah, 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. But we're seeing a lot of excitement around these new kinds of social networks, like Mastodon and other like federated decentralized social networks trying to solve this problem. And then we could have, that would like unlock the problem of like social networks being siloed. And we can have like open source collectively created social networking platforms and social networking tools. And you could, I feel like you could do the same thing for almost any kind of software application in such a way that like potentially there would be

like a new economic software world order like i know that the the way things are today if you want to make money you build an app and you sell it or you build a sas product you know sas kind of changed economics i'm thinking you know how can we take these ideas you're talking about and and use them to like envision a new a new kind of world uh where economics are very, very different. Like an example would be now I pay for like monitoring software for my business. Like 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. You know, 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 can improve it and I can get the improvements. We all get the benefits of open source, but the tools we actually use in this idyllic way. Do your thoughts run in this direction ever? Yeah, I think

definitely. 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. And we also see, for example, in the open source space, we see that there are problems with the maintenance cost.

Basically, everybody expects to utilize open source software for free, but not necessarily to contribute. Well, I think... Then you end up with... Sorry. Go ahead. Go ahead. I was going to say that that's the point.

The problem with open source today is that it was... so I think, here, let me start over. So I think when the idea of open source came about, like the Richard Solomon 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 like very much everyone was working on the software together. So it was a commons. And it was like 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 what I feel like this multiple development environment would enable is returning to the ideals of open source, where it's much more possible for, instead of 0.1% of developers being maintainers, it could be more like 10% of developers or 50%. I don't know. But I feel like that's the whole selling point or one of the selling points of multiple development. So I think that 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. So here's why. So I think, and again, just like I come back to this takeover flow 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 the, you know, under the hood, which is what you need to do when you need to go and maintain something. But what if the cost of looking under the hood is actually not as high as we think of

it? What if they are one or two orders of magnitude less? Then all of a sudden, you know, whenever there is a dramatic price drop, we have, you know, economics get inverted and a whole new kind of behavior can emerge. We see this, for example, that the nicest example that I have seen recently is there was a TED talk by Al Gore in 2016 showing that, you know, the predictions that were made in terms of CO2 emissions and so on, they 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 outperformed the best or the most optimistic predictions that we had 10 years ago. And 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, a whole new economic model is available that generates a whole new kind of equilibrium and you just cannot predict it until you're there. So what we are seeing... Sorry, I missed the Al Gore example. The cost of what went down?

The cost of the ultimate energy. So the cost of solar. I see. The price went... 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, that's an exponential curve, the adoption rate. And so, but that adoption rate was unpredictable 10 years ago. And the reason it was unpredictable

is because whenever the drop, the price drops, then a whole new economic behavior is enabled that is unpredictable before you have it, before you have that possibility. Same thing happens with the apps. So if you look at the apps on the iPhone, for example, when the iPhone came by, I always like to give this example. Most, you know, I still remember in 2007, 2008, you would see most reviews were comparing the keyboard, you know, the speed of the keyboard and how fast and how accurate you can type on the iPod, on the iPhone, as compared with BlackBerry. And 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. 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 now we have economic models to target niches, we target context. And so you can tailor exactly what you want, theoretically,

by through those little, you know, because the level of granularity has dropped. And it's economically feasible for us to produce those small pieces, the apps. And now it's me, the user, that just assembles my experience to deal with my context. So most apps in the world are not used by most people. And as I said, that's exactly what makes them interesting.

But now this behavior that 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 cost of looking under the hood is too large. And 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 the nature 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 another magnitude, but probably more. And once you do that, a whole new economic model is possible. A whole new kind of economic behavior is possible. And we don't know where this one 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. As a result, our main goal is to optimize at this moment in time, to optimize or change the experience of looking under the hood

of whatever software it is right so so the behavior of me getting an error about my system and then copying that one going onto the in google pasting it there and then hoping that somebody asked the question and answered it on Stack Overflow, that behavior that is at this moment is incredibly detrimental. And so the only reason we do, in fact, I'm saying that 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 a reason for it. That shouldn't happen. That's not the best case scenario. And 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 the next levels. Okay. That's very fair. That makes a lot of sense. So 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.

And the way you made this come home to me when you were showing me the demo was you you pressed on the world object which was like when you when you went when you popped open the inspector and you clicked on the world object then it the preview of the world object was the world so it like became kind of a fractally thing. Like the whole, the whole screen was put inside, put inside of itself. And you can like kind of pop around and inspect various parts of the GUI that you're actually using to inspect itself. And so 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. And so, yeah, I wanted to figure out why is that and why is it such a unique

concept? So it's not a unique concept in that it was there since a long time. So if you look at the graphical, every graphical user interface has one rendering tree. The problem is when people want to say, oh, and now I want a visualization, for example, and all of a sudden I'll open the pane and in that pane, because I don't have the capability to draw a line, which is in my graphical user interface, I will start employing another library that maybe I'll have a canvas there if I'm in HTML, maybe I have an SVG there. And then I will draw 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 tree. And those two rendering trees, they have different properties. They are different kinds of rendering trees. And when they are different, they are different worlds. And because they are different worlds,

you cannot connect the two. So I cannot just say, oh, I want to have a visualization here. And in that visualization, I want to reuse, 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. And now it's all of a sudden, it's a very complicated technical problem. And all because, the reason for that was that because I could not draw, you know, I don't know, a graph or a chart. And so, and that's the reason why I'm now,

so 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. So that's the reason why we have spent for 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 six, seven years. No, four or five years before. Before we started this new generation. But what we realized was that we needed much more flexibility in terms of what we can express visually. So, I mean, just imagine that you're, as you see, let's say you put a graph and you want to have a graph of the dependencies.

So you see here's a module, here's another module. And maybe you'll double, you want to zoom into one of the modules and then you will see the classes there. And right there, right in the same screen, you want to double click on that class and you want to see the code of it, because why not? And maybe you don't just want to see the code, you want to edit the code. All of a sudden that means that you need to have a full-fledged editor with everything that that editor comes with.

But now you're inside of visualization and typically, so that means that you should not be in a different world. You have to be in the same world where the editor was, 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, let's say, more normal widgets kind of things, and representable in the same rendering tree,

then these kinds of combinations, this possibility to express these interface and these interactions, they're trivial. They're essentially limited by the imagination and not by what's technically possible. Another thing that we have was that our editor is also rendered in the same rendering tree up to the, if even if you want to, to the level of the character.

But at the moment, for most practical cases, the level of the word is good enough. So every word in the editor is an element, is a first class element that is just composed, just of normal, is part of the overall rendering tree. 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 that you're looking at or interactable interactable to interactive so that's why you can make a kind of different kind of interface that you can have editors that are really really live and visual and so we don't have to have here's the textual world and here's the visual world it can be intertwined in absolutely arbitrary fashion or the way the way the designer wants to without having the limit yeah so i'm i'm sold um i think this is great. And so now my question is, how do we build something like this? I guess my question is about your, you know, how you built your graphical stack. But I think I just want to add like 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 evolving standard thing. And so I think the main thing I'm worried about in going to a single rendering tree world is that somehow you lose that. And so anyways, I'm curious, how do we get this single rendering tree?

Like what can we, what do we add to Like, what do we add to HTML? Or what do we add to the canvas? Like, yeah, 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? Oh, so that's a good question. So actually, to answer the question about HTML or not, so the rendering tree is a property of the, if you go to that world, to the browser world, the rendering tree is a property of the browser primarily,

not of the HTML. So it's an underlying property. But because the question is, why can I not describe in the HTML canvas? Why can I not utilize HTML elements as nodes from the former graph, for example? This is at the moment not possible. And that's, and then the standard, if you look at this, 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. So for us, it was, you know, as I said, this is not the first. If you look at the original text, if you look at the Gengo 4 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 a pattern about how to not create multiple instances of a character, A, for example, that you might want to use in an editor. So there do exist things in the past that have created these kinds of rendering trees.

And the challenge there is, how do you make it fast? So how do you make it, because when you have these one rendering trees, you have highly flexible graphical possibilities. But on the other hand, whenever you have highly flexible graphical possibilities. But on the other hand, you, whenever you have flexibility, the question is how do you make it fast? So, you know, our, in our, our target was, can we open a hundred megabytes text in less than a second and start editing, editing that one in less than a

second, so that was our, let's say, benchmark. So, and so it took a good part of the last three years to figure that problem out. And so now I think it'd be very interesting if people will start to look at our work and then, you know, go and improve that now that we can have answered the question of how do you make it not just conceptually be possible, which we knew that is possible before, but also make it practically possible. And after

you have the technical advancement, after that, usually 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 what, 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 inside.

Of course, there is always a need or 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 a black box. Right now, for most interesting graphical applications, people are forced to use a black box by the standard. And so that shouldn't be the case. All right.

That makes sense. Okay. Yeah. So, you know, more about 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. That is, if I need only one single, 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, it looks to us that we're using multiple concepts when just one should be enough. And then when we said we formulated this goal to have one rendering tree for everything we're going to build, and we just optimized around that one.

And it seems to me that people don't formulate. So we optimize too much for what is immediately tangible. And so when we said that one, you know, one rhetoric tree, we actually didn't have much experience of building graphical, you know, 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 you will have a chance to potentially get to it.

But what I notice in practical settings is that people, because something does not appear to be tangible, don't even set up to try to do it. And 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 start investing. And that kind of looked interesting for a long time. And I think it's kind of detrimental today because it prevents you from investing into,

investing energy into work that, just because of a principle and not because it's immediately profitable, or you don't know whether it's profitable because you don't know if it's maybe even possible. So yeah, that's, I just wanted to say that one. So it's because I think that we should push more the conversations towards principles without necessarily regarding what's immediately tangible,

what's immediately practical. And 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. And you only find those assumptions if you actually start to challenge the the why's that the reason as to why something is the way it is at the moment and so i think that um you know that's why i'm i'm interested in

having or focused on um on 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 principle based and people engage into formulating arguments, listening to the other arguments, and then formulating maybe counterarguments or alternatives, inevitably this one leads to leaps.

And yeah, so and again, 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's data and build tools for it and so on for a reasonably long amount of time. And there wasn't much of a traction around that conversation. And so that's the reason why we wanted to create and embody that idea into something that people can touch. And now that 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 one allows us to lead. Yeah, that's a really interesting thesis, a conversation focused one. So I want to just ask a quick question. If you could compare Pharaoh, the Glamorous Toolkit to other modern day small talk projects? I don't know if you would group them together the way I just did,

but to me, the Lively Web, Lively Kernel, and Morphic, 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. Right. So they have a similar goal, right? So for example, if you look at Morphic,

it was not even invented in the small talk world, but it comes from self a long time ago. And at its time, it was an absolutely beautiful concept. And in that situation, in the original Morphic, was one rendering tree. And then again, the question is, how do you bring it to today? And how do you make the kinds of interfaces that we want to dream about today?

Not those that we were dreaming about 30 years ago. So yeah, everything that happens around reflective systems, whether this is small talk or has a different flavor to it, I think those are highly interesting, and we are definitely in that space. Now, the Glamorous Toolkit, we talked a lot about the Glamorous Toolkit in the context of developing for FIRO. But the Glamorous Toolkit is actually a platform for IDEs or for for tools for tools that are meant for humans that

want to think about or work with computation and um within the bounds of a computer at the moment so um so that with the if you look at the moose project, for example, there you will see that there's quite a significant knowledge to how to deal with other languages, to how to deal with other systems. But not even just languages, but really systems. Because the goal, the idea of moldable development is not just to focus on a language, so to have an IDE for a language. We want to have IDEs for systems and even IDEs for problems inside those systems. So it's a different level of grand narrative.

And in that space, that space of moldability, at this very moment, Glamrs 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 when the, you know, the screen would show your text all the time. But now we don't have, we no longer have that kind of limitation. And now we can, you know now we can update the constraints to what is possible

today. So from the moldability idea is closely related to Emacs. Another source of similarity that people see when they look at just the last couple of weeks I demoed Glamorous Toolkit quite extensively and people see oh this looks very similar to intentional programming which it does and 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 not just one intention.

There are many. And when we apply the intentionals, they don't have to be necessarily, 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.

And 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 these are actual snippets of code that we link directly into documents, they do look like little 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 the writing to the reading. So those two things are actually

decomposed. 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 all of those views that we talked about, they are models, but the way we organize them, they're different.

So there's a whole lot of inspiration that we draw from and we try to combine them in a unique environment. And 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 this small talk legacy or legacy, like in a good thing, in a good, the good, the good interpretation of the legacy term so we have that part the small top part and on the other hand we have all these other kind of um inspirations going from modeling to the programming to visual visual representation so all the visualization frameworks that exist there there there exist similarities there except in case, they're all in one single place. Cool. So one of the phrases you just used is that the Glamrs toolkit is not an IDE for a language, but it's an IDE for systems, a whole systems.

And when we were talking and you were demoing the system, is not an IDE for a language, but it's an IDE for systems, like whole systems. And 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. Like another one of the things you said was that everything should be explainable at any

given time without resorting to drawing on the whiteboard. Anytime you feel the urge to draw on the whiteboard, that means you need to build a different visualization that will then live in the system for forever and people can use it as a part of their toolkit. So yeah, I don't know if I kind of summarized it a bit, but I'm wondering if you could talk more on this IDE for systems setup. Right. So because 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, you know, 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. And so this way we started, in fact, 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, because people say, oh yeah, but maybe that's too expensive to have an IDE just for a system. And that's why we said, well, okay, if you think that for a system is too expensive,

how would you feel if you would have to, if you would want to or be proposed to adapt your environment for every individual object 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 are 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 higher level of abstractions. And so you mentioned, you know, like the IDE, the I in the IDE stands for integrated, and it's true. But what we really think that integrated should be is not just about the developer, but also 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 non-technical 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, like somebody does not understand anything, so you're given the task, you're defined 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 design the process and the way the interactions

between people happen, you know, are based on this assumption that normal humans cannot look inside the box. And that's, I think that's a wrong assumption. So once this is possible, once that assumption is no longer valid, then complete different kinds of workflows are possible. And as you said, we think that it 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 non-technical persons and later on between non-technical persons. And then maybe we will not even have much of a distinction between technical and non-technical persons eventually once the

incentives exist. Because if you look at, for example, the history of, you know, of mathematics, for a long time in the history, mathematics was a skill that are handled by a much larger audience. And when we still have those mathematicians there, the skill of mathematics is intertwined now with the actual domains in which mathematics are applicable. And 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 opposed to, or as compared with the rest of the population. But I think that we will see a progression or let's say diffusion of this skill and the combination of that skill

with the domain and 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. And once that is happening,

then we will see all sorts of new kinds of behaviors that will emerge from it. And so this idea of an environment that the IDE should be installed on the business person computer, I think that that will not be as ridiculous as it sounds today in just five to 10 years. I think it's a really optimistic and beautiful vision. So just 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 could you unpack it for us? But you said it's already the longest. So I'm not sure you're asking that one. Okay, so I'll try to make it short, which doesn't say much because we are consultants. That's how we earn our money. So, okay, let's see how short it can be.

So the idea about this came, I read a few papers around year 2000. There was this massive investment into, you know, 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 nine. 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, it followed that we should have been, we wanted to invest the energy or the people wanted to invest the energy to browse through them, such that the economy doesn't fail at first of January 2000. And the economy didn't fail, but it didn't fail because of these, I think, success that this browsing of all of these sources had.

But this 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 mainframe or large mainframe still in use. So one study once said that there was an estimated 10,000 large mainframe, 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. And 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. So 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. And 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. And 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. So when I talk, for example, I was at an architecture conference last week and I was talking there with many architects and a few hundred of them. And 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. And if you would stop the systems, because, you know,

when we started to talk about hardware and software in the 50s, not we, but they, when they had to name the things, one was large as a house, and so we called that one hardware. And the other one was this thing that you could just put in and out as you wanted. They called that one software. And nowadays, the funny thing is that the hardware, because we probably called it hardware,

only fits in my pocket. And the 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 and it's not just the mainframes because nowadays we are deploying you know millions or even more of of sensors and those sensors they have to be updated and of course a lot a lot of the like a lot of the focus today is placed on 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. except that the problems, you know, when you look over time,

the problems, a 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. 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 or even probably more important, but at least as important as our ability

to properly able 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 recycle,

before I can take something apart, I first have to understand the parts. So, but if the ability to understand those parts depends on our ability to read, then we see the fundamental of the problem unfold in that we're trying to match an exponential growth with the speed of recycling that is kept in speed, because reading is kept in speed. We cannot really enhance reading.

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.

And I believe that we have not really seen the problem because we were still able to exponentially grow the developer population. But we are kind of at this very moment, we are running out of places to draw extra qualified developers. So I think we will soon leave or get into that. We will see that problem. And the solution, from my perspective, is to,

it's interesting how everything goes back to this problem of manually trying to go through the software systems. And I think that the only possible answer is to have a function, the recyclability to have it to be a function not of our ability to read, should not be a function, 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 the system,

definitely not linear or even worse, super linear function on the, depending on the size of the system. And the only way to do that is to utilize the computer to go and do the, let's say the boring and the repetitive task of crunching the data and transforming it into information. So 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 it. This idea has, I think, a reasonable or has a reasonable chance to advance the conversation. I don't think that it's going to be the ultimate solution, but definitely increase or improves the core pushes the problem with at least a decade or maybe more if we, if we will go in that way. So yeah, that's why I define my, my title as being a softer environmentalist. Because I think that, you know, 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 is, you know, people don't really talk about it that much.

In fact, at this moment, not many talk about the systemic problem. Because it's 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 and reasoning you know, reasoning about a system to make decisions about what to do next.

And 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. And so my kids will only know a world of software. And because of that, because software is everywhere and it's just going to be in 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 know this over the last 100 years that if we build an economy on top of vectors that are unsustainable, it doesn't lead us in a good place. Was this short enough? It works. It works for me.

I think it's a really, like as 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, you're really concerned about starting conversations that aren't being had. And, and that's, you know, you know, this whole, this whole talk was, you know, mostly about the multiple development and our tools. And that's one big conversation that's not being had. But then, you know, right at the end there,

we just slip in a whole nother conversation that is really important that you think we're not having as much as we should. Yes. But you can say, you know, instead of unique and so on, you can also say strange because it's also applicable. Yes. Well, I think I'm like expecting that the reactions to this podcast are going to be like, who is this guy? Where did he come from? Cause I think cause you have such, you've been working on this,

these problems for so long and you have such wonderful thoughts on them. And and, and so much of what you have to say isn't in the mainstream conversation about improving programming. So I think, I feel like there's going to be some self-flagellation of like how haven't we known about this guy before well yes so and that's the reason we having this company so first i i people shouldn't make a lot of you know of me because i i really work the team and um but uh but really the thing is I'm very much

when there is no conversation you just do not there's too much stimuli around us at this moment we do not we don't have a shortage of stimuli that can excite our senses so the core

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 a fundamental problem of the world we live in today. And so it's not enough today to create a new concept. You also, I think, it also lies in the responsibility of the creator to also transform it into a logical conversation. Yeah. So 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. Well, thank you very much. By the way, thank you for being so patient with all the, you know, given the duration of everything that just took place here. No, it's wonderful.

The more, the better. So before we close, I like to finish episodes 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.

Great. Thank you. So yeah, you can find me on Twitter. I am G-I-R-B-A Girba. And, or you can go to my website, tudorgirba.com, T-U-D-O-R-G-I-R-B-A.com. But probably the more interesting things that are happening these days around me are happening around the company, which is called Fink. So I go to Fink.com, F-E-N-K.com. And you can also find us on Twitter.

So F-E-N-K.com, sorry, F-E-N-K.com on Twitter. That's our handle. And we definitely love any type of interaction. So we now made Glamrs Toolkit public. We now reached version 0.4.0, so it's not yet the one. But we love to have people that would like to have the conversation with us. And so if you do try anything we have played with or put forward

in some form, please do engage with us in either by, as I said on Twitter, or we'll probably also open some channels or other channels of communications, such as chat on our websites. And, but just, or otherwise just contact us by email and then you'll find those emails. So my personal email is tudor at tudor.irba.com

and Fink you can contact it at contact at Fink.com. And yeah, the other obvious link is gtoolkit.com. That's the Glamrs Toolkit website. Great. Well, thank you again for your time. And I hope to speak to you soon. Yeah. Thank you very much.

It was a pleasure. Okay. Bye. Bye. Thanks so much for listening. If you enjoyed that conversation, I bet you'd feel right at home in the Future of Coding Slack group.

You can join at futureofcoding.org slash slack. If you'd like to support the podcast, I'd appreciate your help in a few ways. You can leave a review on whatever platform you're listening or recommend it to a friend. If you want to support directly, you can do so at patreon.com slash stevekraus. If you have any tips or suggestions on how to make this podcast better, please reach out to me directly with any of that. Thanks again for listening and I'll catch you next time.