Hacker News Reader

Comment by tudorgirba | Hacker News Reader

Thank you for the feedback.

Our latest attempt to explain why Glamorous Toolkit exists comes in a book I am writing with Simon Wardley in the open about Moldable Development. See it here: https://medium.com/feenk/rewilding-software-engineering-900c...

If you happen to have the time to look at it, I would be very much interested in feedback. In particular, does the environment makes more sense in the context of the problem described in the book?

View on HN

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.

I'm a scientist/data scientist.

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!

Something possibly similar is Studio: https://github.com/studio/studio - also Smalltalk. But seemingly dead (or at least sleeping). I encountered this via its author's RaptorJIT project, a fork of LuaJIT apparently intended to turn it into something maintainable by mere mortals: https://github.com/lukego/blog/issues/19 - some videos here: https://www.youtube.com/@lukego/streams

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.

Moldable Development offers a different option :)

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?

Please do feel free to email!

Or contact me on social media.

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?

Also, if you have a chance, I would be interested in what you think about the distinction we make between defined and dynamic exploration towards the end of this chapter: https://medium.com/feenk/rewilding-software-engineering-a360...

People shouldn't have to read a book to know what Glamorous Toolkit is good for.

Thank you.

Reading a book is entirely voluntary. I was offering it as a suggestion for the person that had the original question and which seemed interested in learning more.

Reply on news.ycombinator.com