moose VS gtoolkit

GitHub Discussions as their forum: https://github.com/idaholab/moose/discussions

In our codebase ( https://github.com/idaholab/moose ) tabs are the first thing looked for in our continuous integration system. A tab will be an INSTANT fail.

git --version # timeout=10 git --version # 'git version 2.32.0' git ls-remote -h -- https://github.com/idaholab/moose.git # timeout=10 Found 7 remote heads on https://github.com/idaholab/moose.git [poll] Latest remote head revision on refs/heads/master is: 1d1b703aef983bb75174883f145cd0d26f10d167 Done. Took 0.18 sec Changes found ```

> with very little way to find and eliminate them.

The best Smalltalk these days is GlamorousToolkit: https://gtoolkit.com/

It has a sort of git in it, so you can easily "rollback" your image to previous states. So going back and forth in history is trivial.

The community is tiny. The fact that it was called "Perl6" for 20 years (Raku is from after 2019 I think) absolutely doesn't help in anything, the least in adoption. The historical churn in terms of VM (experimental in Haskell, dead Parrot, JVM, current MoarVM), the lack of planned features (macros!) for long years, and the slow death of Perl over a similar time frame - all that (and more) means not many people use it, even if they happen to know about it.

On the other hand, there's a similarly tiny - or smaller - community around Glamorous Toolkit (a Smalltalk distribution) that managed to produce one of the most hackable and rich LLM clients out there: https://github.com/feenkcom/gt4llm https://gtoolkit.com/ Here, though, LLMs are so close a match for the community interests that it just had to happen...

I simply have to recommend Glamorous Toolkit to anyone interested in visual programming: https://gtoolkit.com

It focuses on the kind of visual programming the article argues for: Class layout, code architecture, semantics. It's one of the best implementations I have seen. The authors are proponents of "moldable development", which actively encourages building tools and visualizations like the ones in the article.

I have been pondering about this issue for a while. Maybe it is inevitable that successful systems turn into big balls of mud eventually once the "inflection" point has been reached and (slow) deterioration begins.

It is somewhat of a clichè but I think that documentation and tooling can make a difference, but it is very difficult to design the process and the tooling to be as frictionless as possible. Tudor Girba and his team at feenk have been doing a lot of interesting work in that area, that's worth a look [1, 2].

The software in question might be an entangled mess, a large part of it might be even inherent due to its requirements or technical constraints, but if that messy web can be readily augmented with background information and sign-posts I think the situation could be significantly improved.

On a related note, there has been a project at Xerox PARC called PIE (Personal Information Environment) which has put forward the idea of organizing software and its artifacts (source code, various kinds of documentation) as a network. Although that particular concept has never been adopted in any major programming system as far as I know, I think that it has huge potential, especially if the software, as a network, can be collaboratively navigated and extended with additional information, where and when needed.

Now that all does not change the fact that we are still dealing with a ball (or a web) of mud, but at least it is accessible.

[1] https://feenk.com/

[2] https://gtoolkit.com/

[3] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-81-3...

You mentioned you're passionate about good tooling, would you mind if I asked you what your thoughts are on Glamorous Toolkit[1] and how it compares to other tooling you've seen?

[1] https://gtoolkit.com/

Your ideas sounded very much like a mixup of Common Lisp with SLIME, Smalltalk interactivity and Unison-like storage of code in a database instead of files.

I've tried all of them, I think the closest thing I've seen to what you describe, which I also find very attractive, is the GT Smalltalk environment: https://gtoolkit.com/

Have you tried that? They call this idea "moldable development" as you can "mold" your environment to your needs.

Even though I loved it, I ended up not using it much, mostly because it's a bit too heavy to keep handy for exploration all the time when needed (it takes like 1GB of RAM even when idle!)... as I already can do most of that with emacs, which is much lighter, I just stick with it.

> This power that Smalltalk systems have where the code runs in a GUI that is also the editor/debugger/etc has deeply fascinated me recently.

Have you tried emacs?

> And I'd like to actually understand a tool that I'd have to dive into that deeply, and I think I'll never have the time to truly understand all of the VM, the classes, etc.

I've recently tried to do that myself with Smalltalk via the Glamorous Toolkit[1] (a beautiful, modern Smalltalk environment based on Pharo). Because the programming environment itself comes with a Book teaching it, you can basically just read it as a normal digital book, but with the superpower that everything is editable and interactive: you can change the book itself, every code example is runnable and you can inspect the result objects right there, change it, modify the view for it... they say it's "moldable development" because you almost literally mold the environment as you write your code and learn about the platform.

> And I'd like to be able to create applications that run without shipping the entire Smalltalk VM.

That's why even though I really enjoyed SmallTalk, I can't really see it as anything more than a curiosity. I tried using it at least for my own occasional data exploration because it has good visualisation capabilities and super easy to use HTTP client/JSON parser etc., but the system is so heavy (1GB+ of RAM) that I couldn't justify keeping it open all the time like I do with emacs, on the offchance that I might need to use it for some small task.

Anyway, perhaps that's something you might be interested in.

[1] https://gtoolkit.com/

I have been building a drawing and animation system in Pharo (smalltalk) for a few months, using a really neat new UI called glamorous toolkit.

Last time I tried to "hydrate" thousands of SQL rows into objects and both Pharo and the Glamorous Toolkit froze up. Maybe that is to be expected, but I've done that a million times on the JVM without any problems.