Right - moldable development makes sense to me, but presently I feel like I can do all these things by glueing tools together with Emacs.
If you had an implementation of ggplot style plotting native to Glamorous Toolkit that would definitely catch my attention, though. Nowadays I typically tie together Python, R, and other languages with Emacs being my sort of control center.
I get the impression Glamorous Toolkit could step in here but it seems like such a lift to reach feature parity with a set of tools and GTK doesn't seem to integrate as well with other stuff as Emacs does, partly because Emacs just accepts that throwing around a bunch of text is 80% of what I want.
This has been on my todo list for a while, as I like Simon Wardley, but I've never quite got round to using it. But I use Emacs a lot, and Emacs was the thing that sprang to mind when reading the blurb. It looks like there's this similar vibe of making custom tools easy, with there being an expectation that this is something the average user will actually do. Compare and contrast the experience of extending Emacs with, say, writing a Visual Studio Code extension. (N.B., it has not escaped my notice that Visual Studio Code is more popular...)
The GUI possibilities of Emacs are a bit limited though. Glamorous Toolkit looks better in that respect. I need to actually try it!
If you look closer at Studio, you might find that its frontend was based on an older version of GT :). Luke did a nice job on it and he learnt the environment by himself when it was rather crude.
How you create contextual tools is secondary. Emacs' ability to create extensions is certainly interesting. But here are some questions to consider:
- how many contextual tools do you have for your system? 10s, 100s, 1000s?
- or, for how many and what kind of questions don't you have contextual tools? and why is that?
At the extreme, when practicing Moldable Development, we tend to address dozens of questions per day per developer through contextual tools :)
With the advent of language models I really despair of new technologies catching on. LLMs are deceptive in their intelligence, as far as I can tell - they can seem expert in one domain and then fail absurdly on some new take on similar ideas that don't appear in the training data. Consequently, one loses a lot of productivity when switching to a fringe technology, even if its better.
Startup types used to say that its not enough to be better than the current solution - you have to be 100 times better to justify the switching cost, and with LLMs it seems like that is like 1000x. It sucks.
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.
I think part of your challenge here is that the idea of system exploration kind of applies to almost everything a software engineer or data scientist does and while the demo material makes it clear that you can use Gtk for that kind of thing, its kind of hard to think specifically, at this moment, what one might use it for, because the problem space is so general and it seems like Gtk is maybe also very general, which means there is a little bit of work to apply it to a particular problem right out of the gate.
I find myself wanting to talk about this in more detail, but this account is anonymous - could I email you?
Great to hear that you find Moldable Development meaningful. And it's even more interesting that you can find tools around to tackle your contextual analyses.
ggplot and Grammar of Graphics are very interesting indeed. With GT we have some support, but we focused so far on creating the underlying graphical stack first, one in which everything (including the editor and visualizations) is represented in a single rendering tree. This graphical stack already offers the possibility to create various kinds of graphs. The Grammar of Graphics is of interest for us, and we'll likely look at it in more depth in the near future, because it allows us to define graphs declaratively and serialize them across network.
What kind of analyses do you do? Only for data, or also for systems?
If you had an implementation of ggplot style plotting native to Glamorous Toolkit that would definitely catch my attention, though. Nowadays I typically tie together Python, R, and other languages with Emacs being my sort of control center.
I get the impression Glamorous Toolkit could step in here but it seems like such a lift to reach feature parity with a set of tools and GTK doesn't seem to integrate as well with other stuff as Emacs does, partly because Emacs just accepts that throwing around a bunch of text is 80% of what I want.
I'm a scientist/data scientist.