I am glad that AI provides what you are looking for.
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.
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 :).
No, AI is not Moldable Development. AI can help Moldable Development (mostly as an optimization).
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.
I am not sure why you are saying that I am not paying attention to how AI is impacting software development. I just pointed you to a chapter that shows that it's not a competitor at all. Moldable Development and GenAI are complementary :)
In GT, we have integration with LLMs as well, including programatic ways to create interfaces for it.
Well, I have seen reasonably important systems being written in Smalltalk, but these were not advertised too publicly because... well, they were considered a competitive advantage :).
Glamorous Toolkit is built in Smalltalk, but it is not intended for you to build systems using Smalltalk. It is a technology for building development environments for your systems. That's not quite the same. Oh, and we use it in corporate settings just fine, too :).
In the meantime, you can use Lepiter pages and program Python from there and inspect Python objects with inspector views defined either in Python or in Pharo :).
You seem to consider LLMs for their ability to generate code and consider it to be 10x an improvement over not using them.
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.
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.
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.