Hacker News Reader

Some time, take someone who's interested in GT, and sit them down in front of the system and capture video of them using it. And don't tell them a thing. Just watch them interact with the system. See how long it takes them to get stuck in some particular way, or get the UI into some weird state they don't understand. Bring them back, tell them one thing to get them going, and then shut up entirely again and see how far they get.

It's just so incredibly hard to remember that "beginner mind", that you really have to see it in action to understand just how much is in your brain, that you don't even realize.

That exercise will probably help your book more than anything.

Thank you for the suggestion. We are indeed doing that both publicly and privately. We do learn a lot from this.

I very much agree that it is hard to remember the beginner's mind. I also find that a larger challenge is that there isn't a single beginner's mind, but many. When the space is large and there are many paths, people can come from different directions. Finding commonalities seems to be significantly more difficult in that situation.

But this still leaves the problem of how to explain it before people work with the environment. The conversations in posts like these are very helpful, for example. I'd be interested in other suggestions that could help with that.

He has done this many times on his YouTube channel!

For an example, this guest was particularly clever and charming:

https://www.youtube.com/watch?v=FJP2zkl_44o

J/k. It's me. I'm the guest. :)

BUT: this was our talk after he saw my livestream where I was stumbling around trying to do things in GT early on, so it might help other people.

I remember that guest! :)

Whenever you want to market something that has many different uses, it’s important to focus. Pick one of those uses, and focus relentlessly in marketing that. If people are interested, they will come and if the tool will deliver on the promise they will use it. Over time they will notice other uses and a flywheel effect should take over.

These ideas are great, but I don't understand how the whole Smalltalk approach can fit into modern development environments of multiple engineers working on a project, client-server architectures, or even large codebases - TDD helps, but high level of dynamism without typechecking can't be reliable in my experience.

The ability to fix things on the fly and have the whole system as your ide/debugger is nice, but that's not very practical for the end user.

Interesting question.

The primary goal of Glamorous Toolkit is not to be a technology for expressing systems in. Its purpose is to be an environment with which to work with systems written in various technologies.

The differentiator to other environments is that here you can create contextual experiences (made out of micro tools) while you develop.

That said, of course, the first language targeted is the main language in which the environment is built: Smalltalk. And you can build interesting systems with Smalltalk today.

The end user does not have to see the development tools. You can just fine create web applications.

Collaboration is handled through Git (all sources of GT are on GitHub).

You mention TDD. Moldable Development is complementary and can be quite interesting to explore :). And more importantly, you can use GT to employ Moldable Development in your system development.

Exactly the same way as using an IDE, their genesis trace back to the various workstation environments at Xerox PARC, Smalltalk, Interlisp-D, Tajo/Xerox Development Environment (XDE) with Mesa, Mesa/Cedar, and their influence in other programming language ecosystems.

The way Java IDEs work on their virtual project filesystem mimics a Smalltalk image for example.

Nice point!

This reminds me of my days programming Lisp. Toward the end of the four years I spent coding Lisp full time, on Symbolics Lisp machines, I got to where I could say, "Hmmmm, I need to do 'X', I'll bet there's a function called 'backward-hacking-smooth-styled-X'" and I was starting to be correct a surprising number of times.

SO: How do you give this knowledge to new folks? Somewhere on the site I saw a treemap (a large rectangle, divided into hundreds of smaller rectangles, in various colors, grouped into larger rectangles...) which was supposed to be... helpful? Prideful (look at what all we've built!)? What I get out of it is a scary nightmare - you'll never find what you want here! There's just too much!

And watching one of the demo videos, where the person is showing how they analyzed and visualized some react code, and dependencies, etc., it was always, "Oh, we want to see it this other way, shazam! we have an awesomely excellent tool that just makes that pop right out! But only if you know the arcane sequence of calls/invisible GUI actions to get to it.

I used the (slightly ridiculous) example of the Lisp function above, to illustrate something. I REALLY REALLY REALLY wish no one had EVER used the phrase, "Intuitive!" about their tool or user interface. There is nothing intuitive about your UI. But! But! But! The Mac! 1984! I had a Mac in 1984, I'm typing on one now (after a decade of wandering in that other wilderness :-) and I'm here to tell you the Mac UI used to be (and still largely is) discoverable.

That's the magic sauce.

It's great that you know the 12,011 functions and tools inside GT. I'm sure you'll come up with some nice trip that takes a user through some tiny percentage of those, and then dumps them out at the end in the middle of a rather large city, where they're now supposed to know where every building is, and what's in those buildings. And speaking from experience, it's wildly frustrating to have a few tools at hand, none of which really help much in some new problem, and no freaking clue how to find relevant stuff, and just wind up grinding through a lot of code in a language you're not really fluent in, and generally giving up on the whole mess and going back to the tools you know.

For one small example: someone wants to do something with a spreadsheet file someone gave them, and can't find anything about "spreadsheet" in the docs... because they don't know to save the spreadsheet in CSV format, and there are tools that work with that.

As someone else mentioned, perhaps having an LLM set up with all the stuff to be a guide might help.

Lisp and Smalltalk aren't written languages, they're oral traditions (yeah yeah yeah, Little Lisper, SICP, but those are just starters, and not for the Lisp dialect you're using anyway). Videos may be a start, but... man, I don't envy your task.

Good luck!

Thank you.

I am not sure where to start. So, let me start with what we do not claim: intuitive. In fact, I'd be the first to say that our proposition is counter intuitive. Intuition is based on what one is used to and we propose a rather different approach.

People expect easy to use clicking tools. We propose an environment with which you should build the tools you click on. When you refer to the 12,011 functions and tools inside GT, you assume one has to learn them by heart. We suggest that if you learn how to navigate the environment you can bootstrap your way to discovering what exists. Indeed, inside the environment there are literally thousands of tools. The treemap visualization you mention was not for bragging, but a validation: we created thousands of tools in the process of developing the environment itself inside the environment. We built those for engineering purposes and they show that the idea of Moldable Development of programming through thousands of contextual tools per system actually works.

I understand that it's not trivial, and that it can be downright frustrating. But we have seen it working with people that wanted to learn. So, we know it works, but we still have to find a way to communicate it. We seem to have a way to go to find that way of explaining. Until then, we created an environment with extensive examples and a technical book inside. Now we are writing a less technical book about the overall problems it addresses and exploring ways to explain it through videos.

Hope I don't come across as too critical. I totally get it and sympathize since I've recently been through a challenging documentation project that has very similar catch-22s. It's super frustrating that people want a simple story and have no patience for nuance, but that's how it is. Koliber's sibling advice is very practical and would be my tl;dr on this probably but to expand a bit.

There are basically about 5 different kinds of things you can build: tools/apps, libraries, frameworks, services, languages. I'll hazard a guess that most engineers are used to slicing stuff up this way and that much confusion results from arranging docs in terms of case-studies, which is maybe more appealing to management and/or academics? From the perspective of engineers.. "use cases" are expected to be presented as a small bulleted list or similar. Paragraphs are a losing proposition here, because if they want more, then they are ready for a really concrete and runnable tutorial, and almost anything in between will annoy them.

In terms of docs, it's very tempting for inventors but almost always a mistake to add "paradigm" to the main 5, even if it's true. Academics want that up front, but for industry where results beat methodology, paradigms are a "show but don't tell" thing that you have to lead people into very slowly if you even need to address it directly at all. You can break that rule at your peril and capture interest from a few hardcore alpha nerds.. but even then it is best in the context of a well-designed and otherwise practical tutorial in a optional "post-mortem" section dedicated to recap/discussion. Don't mix it with the main tutorial, and always be as ruthless as possible about separating philosophy and pragma. (I see you're on the way, and there's already a separate domain.)

Building stuff that's in several of the 5 categories at once is often the most productive work and by far the most fun, but also the hardest to present. You can't show more than 1 aspect of the big 5 at once, or you risk losing people. And you always have to be really clear about which one you're presenting for consideration. If you can lay things out like that and then cross-reference docs between the tool/language/framework aspects, it enriches the content and makes it feel comprehensive and complete. More importantly though: it gives people that are in the wrong spot some ability to course correct and that reduces frustration that would otherwise make them complain/turn away.

Books and videos are probably for people who are already true believers. Unfortunately getting more people into that category faster actually means making them say "wow!" in ~15 seconds. That's enough time for a 1-liner, a 15 line program, or a gif. Sad but true. The book's mentions python, d3, tons of popular stuff that is a good hook.. but most people probably don't click in, and if they do the level of detail/runnability doesn't feel quite right. I suggest polishing like 3 of those and lifting them to the main page, maybe also involving docker to make a quicker quick-start.

HTH. Explainability and debugging generally are both about to get a LOT more important for obvious reasons the way things are going. And documenting cool stuff is way harder than building it sometimes ;) I'm thinking a lot about how to do these things myself so I'd really welcome drive-by feedback from anyone else if my assumptions about "average impatient engineer" are way off base here.

Thank you very much. This is an extremely useful input.

Would you by any chance be interested to get a tour from me? At the very least you'd get to see what it is, and perhaps in the process you might find ways to explain it.

If you are up for it, please connect with me in some way (the GT Discord, @girba on LinkedIn, @girba on X, @tudorgirba.com on Bluesky) and we'll take it from there.