105 karma · joined February 10, 2019
I'd still be interested if you have a specific point you disagree with in relation to what I wrote above and in particular, what we wrote in our little book (the link is above) specifically about the topic of this conversation.
But ask yourself: how many things have been expressed this way? For example, what about security? Business domain documentation? Performance? Architecture? Discovering APIs? etc
It's not that the idea is not useful. It's that it's incomplete. We should not get stuck on it.
Or contact me on social media.
orgmode is certainly interesting, but again, its goal is a (small) subset of what is achievable with GT :). And as you say, even that is hard for beginners.
> Lastly, it is a bold statement to say something like "we have discovered a new development methodology, and have designed this toolkit around that philosophy". Such a statement requires a ton of evidence that such a methodology is useful, and currently there simply is not enough.
I am well aware of what that statement says. I did not utter it in the first 10 years of this journey. But by now, I do believe we do have the evidence, and a good deal of it is even available publicly and freely. Of course, there is still this little issue of people actually taking the time to evaluate that evidence. If people are not going to look at the evidence, it's never going to be enough. And that's just fine because eventually, some people will look at it :).
Moldable Development is first and foremost about the interface. AI is an engine. The interface is the thing you interact through. Like the chat. Or the editor with chat abilities. That little layer is worth paying attention to. Because it will define how you think about your interactions with AI.
>The only problem is that they seem to get unwieldy after a certain point. The view of all the different tools / libraries that come with it at the end of the presentation shows that.
That view at the end does not show that they get unwieldy at all. It shows that the contextual tools were needed everywhere. If the cost of tools is so low that you can amortize the cost of a tool on the first use, you can literally throw them away after that first use. In fact that's the fate of most tools. Those thousands of tools that you can see in a GT distribution are those that proved to be reusable. Many more were not :)
There were many tools that showed some visualization. But what we try to show with GT is that there exists a way to tackle arbitrary problems. This is possible because we see the environment itself as being a language made out of visual and interactive operators that can be combined in many ways.
Indeed, we regard software engineering as being primarily decision making. This is a stark departure from the typical perception of software engineering as a construction activity.
Once you take this path, the tools are going to be different. So different that they will appear odd to most people used to the other point of view.
For example, a typical development environment will start with an editor. But editing should come after reading. So, that design is really not that ideal. Having the editing come at the end is perhaps more appropriate. And there are several other such consequences that stem from that original difference in points of view.
In GT, we have integration with LLMs as well, including programatic ways to create interfaces for it.
MCP is certainly interesting.
I am glad you found the demos interesting. I’d be interested what made them attractive from your point of view.
Still, even assuming this is correct (which is not yet anywhere close to being certain), as long as there will be humans deciding what goes into production, decision making will be the bottleneck to address. If people rely on reading, it's too slow. Way too slow. If people only look at the system from outside, they will be making uninformed decisions.
Moldable Development offers a different option :)
GT works on all desktop OSes (and on Android). It works with Git for all sources. It can interoperate with the file system. It works with other runtimes like JS or Python. It works with the debugger adapter protocol to help accommodate other runtimes. It works with language servers, too. It even interoperates with an embedded webbrowser (through WebView on Mac and Windows) both ways.
That's not quite a lack of interoperability, or?
In fact, you might not need MCP for that either. There already exist programmable abilities to work with LLMs within the environment.
We really do not advertise our marketing ability. Only that we are researchers and engineers that might have found a solution to a large engineering problem :).
Or put it differently, would you rather take engineering advice from marketeers? :)
In any case, we wrote a bit about what we think of the intersection between Moldable Development and GenAI as explanations here: https://medium.com/feenk/rewilding-software-engineering-a360...
I agree that the message is not yet clear for most. We can see it in these threads quite well. Now, this is not the first one we are trying, and we will continue to try further :).
The sentence you provide is certainly interesting because it is relatable. The problem is that it talks about a fraction of what we want to convey.
At this point in time, as we do not know how to convey the idea succinctly, we are looking for people that will take the time to look at the more elaborate explanations. It turns out that there exist such people. It seems to me that you might be inclined to look at it, too.
Please do let me know if you do. I would offer to show you around. And who knows, perhaps you can contribute a better presentation for what this is. What do you think?
Glamorous Toolkit is indeed built by the team at feenk, which is a company. However, we created the company to fund the research, not the other way around. Everything we do is free and open-source.
Our goal is not to build Glamorous Toolkit, but to validate the idea that what we call Moldable Development (programming through contextual tools) leads to explainable systems.
We start from legacy systems because that's a hard problem that is not yet solved. If we are to find a new way of working, it should work in the least favorable conditions. With legacy systems, we have extreme combinations of technologies and inter-twinned domain knowledge that we have to make sense of.
At first the approach was called humane assessment, but along the way we found that it actually does change forward engineering as well. For example, we've seen cases in which startups produce pitches for investors right from the development environment. Or teams that put a face on domain-driven design by showing the domain to business people from the development environment leading to co-development. Glamorous Toolkit itself is an extensive case study of Moldable Development, too.
More recently, we also apply the same ideas to creating editing experiences as well. Imagine editors of generic languages that understand the framework or the domain and that offer inline activities.
Yet another application area is that of code transformation. It turns out that we can describe large scale code transformations through contextual transformations as well. This then allows us to evolve large code bases seamlessly.
This can work if creating a new experience is inexpensive. And this can be achieved if we can compose the overall experience out of tiny pieces. Micro tools like views in the inspector, custom debuggers, dedicated editors or even transformations.
There are a few more details at moldabledevelopment.com including the beginning of an open book I am writing with Simon Wardley.
Does this address your questions?
Moldable Development is different from Literate Programming in at least two ways: - Literate Programming is focused on a single narrative. In contrast, a system can be seen in many ways. - Literate Programming has a fixed environment, and mixes text and code. In contrast, Moldable Development emphasizes the importance of the tool as an essential artifact through which to explain the system.
While Literate Programming does talk about explaining systems, I find it too limiting. Instead, we start from the observation that figuring systems out to know what to do next is the single most expensive activity in software engineering; thus it's more interesting to regard software engineering as a decision making activity about an ever changing system. This stands in contrast to the pervasive idea of software engineering as a construction activity. Optimizing for decision making leads to a new set of practices that are not an increment compared to what those typical used today.
Glamorous Toolkit looks odd exactly because we optimized for something else that others disregard.