[throwaway743950]

Glamorous toolkit has always looked interesting to me, but feels a bit unapproachable. It just feels so foreign between smalltalk and a whole sort of philosophy that goes with it.

For those with more experience, is it still relevant? Can the same be accomplished with python and jupyter notebooks?

[edwardog]

Yes, still relevant. The same can be accomplished with other tools, but it will probably be more difficult.

The idea of Glamorous Toolkit is that it’s a collection of tools you use to solve software problems by making little explanatory tools. You might start out with some bigger problem like “I need to make this service fast”, come up with a question like “what does the flow of data I care about look like through the service?” and then try to answer that question by making tools that could analyze/visualize logging output or a stack trace or whatever makes sense in your software’s context.

The technique of “making little tools that explain to help answer a question” is Moldable Development, similar to how Test Driven Development is “make a failing big feature test loop, write little tests and make them pass until the big one passes”.

You can make little tools to explain away questions you have while you’re working with plugins or shell scripts or whatever you’re comfortable with and that’s “Moldable Development”. The Glamorous Toolkit just happens to be a nice system of tools that make it easy to make more little tools to help explain away problems.

Hope that helps! Lmk if you want to see some examples.

Source and bias: I worked closely with the developers before I had to take a break from work and computer stuff.

[seagreen]

What a great idea. I believe in this a trillion percent, due to the personal experience of watching myself and a stronger developer tackle similar problems at the same time. I relied on my brain and the standard tools of my system. He of course did the same, but also made a custom visualizer for the core of the algorithm. Night and day improvement!

So I'm a believer in the principles. But I'm also curious about throwaway743950's question. What are the things in the Glamorous Toolkit that concretely make it better for this style of programming than traditional tools? You say "[it] just happens to be a nice system of tools that make it easy to make more little tools", but that's got to be downplaying it. Switching environments is an agonizingly costly thing to do. What rewards await those who make the jump? Rubies? Emeralds? Custom views-with-nested-sub-custom-views? Curious (but not yet won over) readers want to know.

[g00z]

I would add one thing that makes GT very different from other tools and is very hard to recreate, is that these tools are ACTUAL objects and the things you see, are also ACTUAl objects, and not just a dummy representation of them as you see in other dataviz tools like plotting libraries or shell scripts.

This means your tools and visualizations are just a specific context-specific view of your objects. Meaning you aren't limited in how these tools can interact with said objects, because you are never working with static data, it's always with the actual objects.

It's hard to put into words, but it's similar to the difference between println debugging and a lisp repl or smalltalk debugger. They technically do the same thing but the actual implementation of them makes a world of difference.

[skeledrew]

Actually it wouldn't be difficult to add similar view protocols to Python objects as well (I used GT extensively a couple years ago). Pretty much everything is possible, but the live debugger and driller would be really difficult to replicate, which is where GT really shines for me. Alas it was just too much to properly bridge it with Python, where the majority of my work lies, and GT becomes overwhelmed when passed a fraction of data Python handles with ease.

[g00z]

Simple views sure, but tools like the driller or debugger are great examples of what I'm trying to highlight about when I say having the views work over actual objects is really important.

Because if it wasn't for the fact the graphical stack was implemented as smalltalk objects, you couldn't build tools like the driller or debugger since they would have to be implemented as a secondary piece of software that loses the original context.

Like for example, I built a custom tool for myself when I was working on this p2p network and had a section of the codebase with some non obvious control flow, since it was handling multiple different p2p networks at the same time. Normally this is where you include a diagram in the docs, but in about an hour I built a custom code editor for the class, that visualized all the control flow and explained the cases in a flow diagram by simply introspecting on the methods defined in the class. And this tool never fell out of sync like a static diagram, since it wasn't hardcoded by me. And from that point on, I worked within this tool whenever hanlding anything related to this.

And fwiw, the python story is pretty seamless from my usage of it a few months ago. I was able to integrate and use python libraries into this project without much hassle.

[tudorgirba]

Over the last couple of years we added a reasonably extensive infrastructure for working with Python from within GT. You can define contextual inspector views both in GT and in Python for live Python objects, for example. There is also a debugger for Python.

Also, GT is now also a distributed Smalltalk system, too. We use it in productive settings to compute large jobs on large data sets :)

[ssivark]

I think moldable development needs a few tutorials demonstrating concrete use cases. Without those it feels promising in the abstract, but I doubt many developers are able to connect with it and figure out how to actually use it.

It feels so open ended that I wouldn’t know where to start. And I’ve actually spent several hours exploring Glamorous Toolkit!

[tudorgirba]

Thank you for the interest and for taking the time to explore the environment!

There are quite a number of videos and explanations now, but we are still struggling to package them in a way that seems more approachable.

We would need help with this. If you are interested, I would offer to have a session with you that we record and in which we go through your questions and I provide live explanations. Join us on Discord and we take it from there: https://discord.gg/FTJr9gP

[actionfromafar]

Definitely needed. Grug want help. Grug not understand how do CRUD with Glamourous Toolkit. Grug want see.

[tudorgirba]

Me here. Or on Discord. Can show :)

Or look at: https://book.gtoolkit.com/working-with-the-postgresql-relati... (in the environment you can load the code which comes with live documentation)

[verdverm]

> but we are still struggling to package them in a way that seems more approachable

Normal documentation pages on a website would be a good place to start. Don't bury them in a tool I have to download and fumble through

[tudorgirba]

Thank you for the suggestion.

The documentation is available online at book.gtoolkit.com (linked from the menu of gtoolkit.com). Would you see ways to improve that visibility?

When consumed in the environment, that book contains live snippets that can be explored.

[verdverm]

> and then try to answer that question by making tools that could analyze/visualize logging output or a stack trace

We already have industry standards for doing this. Why would I want to build some micro-tool/throw-away code to do what another tool does much better and battle tested?

[smj-edison]

1. In many cases you need something very specific that an existing tool doesn't do well

2. All the tools work together

3. All the tools are tracked in a central repository

[verdverm]

That's the pitch but it does not seem the reality. It seems like the exact opposite of unix philosophy, one tool to rule them all, rather than doing one thing really well.

I can achieve the same with unix philosophy, using the tools and languages I already know.

[tudorgirba]

Nice point.

Indeed, it is possible to build tools elsewhere. The question is: do you build them, and if yes, when?

What we show with GT is that it is possible to build such tools for every development problem. This leads to thousands of micro tools per system that should co-exist.

GT is not a large tool to rule them all. In the Unix analogy, it is Unix, not one of the tools :).

This still leaves the question of why would want to build those tools when there are standard tools already? Because systems are highly contextual. This means we can predict classes of problems but not specific ones, which then means that any clicking tool built before the problem is known will not be addressing the specificity of that problem.

This is actually not that new of an idea. Testing is already done like that. We do not download tests from the web and run them on our system. We develop them as part of development after we know the problem. It's that contextualization that makes us stop every time a single test fails as we know that each of them captures something that our system specifically cares about.

Now, a test is a tool. We can extend the same idea to any other tool.

Does this address the question?

[verdverm]

I think you believe we all struggle with your framed problem and your tool is some panacea. In reality, every tool and process has its limitations and rough edges, including yours as you've hopefully gleaned in comments here.

Being married to a specific tool like GT is limiting. GT doesn't work with most industry languages _today_, even though _in theory_ it could. It's written and scripted in a language few use, which makes it unapproachable

[tudorgirba]

Nice summary!

4. New contextual tools can be built inexpensively :)

[ElevenLathe]

I've played with GT and even pull it out every once in a while for small tasks, though I haven't in about 6 months.

I think the idea is good, but it's a tough sell for working programmers because the whole culture of it is so foreign. I think there's a version of GT that would do well if it described itself in terms of paradigms working coders know (POSIX, IDEs, blub-y languages, text files) instead of in terms of SmallTalk. Maybe something nearly as cool can be done as a VSCode plugin? I personally think of it as kind of a supercharged Emacs for SmallTalkers.

[tudorgirba]

Thank you for giving it a try and suggestion.

The first goal was to help us explore how far can the idea of contextual tools go. It helped discover what today we call Moldable Development. It is also the first extensive case study of Moldable Development, itself offering 5+K contextual tools that we used to develop the environment itself. And when we work on a system, we build thousands more.

That said, now that we know what Moldable Development is, it can be copied. We want people to copy it. Our worry though is that we want people to copy everything, not only the visible parts.

For example, I understand the Emacs parallel. But think of this: while Emacs can be extended, how many extensions do you actually use that are specific to your system? We literally use thousands. Per system. That quantitative difference leads to a qualitative difference and it's made possible because of the totality of the environment.

[ElevenLathe]

I think a supercharger changes a passenger car engine qualitatively too!

So are there plans to copy GT/moldable development somewhere outside of Pharo/Smalltalk?

[tudorgirba]

Moldable Development is not specific to Smalltalk. We already show how it works for other languages. Some ideas are already inspiring other environments, like Clerk.

In the meantime, consider GT as an extensive blueprint of what's possible. If there is one thing we learnt is that the technology is the smallest investment. The real investment is in learning how to exploit the idea of contextual tools for solving hard problems. That's what takes the longest, but the difference to how those problems are approached today can be measured in orders of magnitude.