Hacker News Reader

Comment by nathan_compton | Hacker News Reader

I periodically check in on this and I can never understand what its really good for.

Yeah I made a decent effort to dig in, as it seemed interesting, but I still have no idea what this is.

I feel like the reason this isn't an obvious big deal yet, is because we don't have in real life the ideal use case: which would be a really complex vehicle ( like a real world mech). Something that needs a bunch of tweakable manufacturer control systems, but also massive customization through customer code. And maybe this will never exist, because capitalism is all about vendor lock in.

I think you're on to something here. Squeak/Pharo were/are in many ways an interesting and sort of obvious base for building things like IDEs, DAWs, CAD systems, other things that are heavy on interactivity, visualizations, and components. I don't know for sure, but it seems like there would be enough escape hatches for interoperability so it's not like you'd be actually be required to do everything in small talk, and certainly there's FFI (https://books.pharo.org/booklet-uffi/ ). Empowering user customization and such is actually a big downside for commercial activities though. The last paragraph here ( https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste... ) is directly raising the concern of how things can stay proprietary.

Besides that.. increasingly devs themselves are very commercial and not exactly in it for the love of the game. They are actively hostile towards stuff that isn't pushed on them by business, and not very interested in creative activity that pushes the bounds of the possible. I think you can see some of this in the insistence on "it's just a notebook" comparisons here, but before that.. docker was also "just another VM" to most until it was absolutely too big to ignore. It's more than comparing to what you know, it's almost actively refusing to be curious / interested. So maybe it's burnout from unnecessary churn in tech, or maybe people just resist entertaining the idea that interesting new ideas are even possible until it's pretty directly affecting their ability to be hired. Maybe both.

In Glamorous Toolkit we have extensive infrastructure to interoperate with Rust. In fact, the main app is a Rust app that relies on several other Rust plugins. The Pharo Virtual Machine is used as a library :).

I enjoy your comparison with Docker. Indeed, the comparison to what you know is inevitable and it works quite well for incremental news. It works less well for new. But it's still on us, the authors, to try to find ways to communicate differently to appeal to a larger audience especially as our goal is to educate. I am also of the opinion that the most interesting path is to get someone to create outsized value that cannot be ignored. Our current focus is to find those initial someones :).

We actually have quite a number of real life use cases. For example, in one company it's being in used as the only development environment for 100+ developers. We also use it for making sense of and modernize legacy systems that people do not know what to do with anymore.

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?

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.

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

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.

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 :)

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...

Reproducible devops

Reply on news.ycombinator.com