I am so conflicted about this project every time it comes up.
I think I understood for quite some time what it wants to do (Though when checking the website there always creeps in doubt, because it is so incomprehensible) and every year when I download the application again, it looks a bit more cleaner, a bit easier to just use. But still, basic things always elude me. Do I really have to read the handbook to figure out how to format text in the knowledge base? Half the windows and symbols just make no sense, etc. Try pressing a button to see what it does and now everything looks different and what even happened?
It seems to glacially improve on that front and I know to really use it, I have to learn to program it, but I am also of the mind basic functionality should be self explanatory. And pharo itself as the basis of this seems so convoluted and complex, I wonder if I even want to get into this.
And then, the community seems to solely be on discord still, and that is then always the point were I bow out and wonder if cuis smalltalk or other systems with simplicity as core tenant are not much nicer to use and I should look there. Of course, in the end, I never get more than surface deep into smalltalk, because while I want the tools to build my own environment, if I need to build them first, there is always more pressing work...
But honestly, a great knowledge base and data visualization I can intuitively just use and then expand later on with my own programs sounds like a dream workspace. It's just, that it is really hard to get into at the moment. I don't know any python, but I could just use jupyter know and learn as I go, but sadly, I never get that feeling here.
I'm basically in the same boat with this and all the smalltalk systems I have tried. The environment is just so foreign. I get the gist for how programming works in pharo (have also looked at Squeak and Cuis), but Python just seems a lot more natural. It is also hard to find snippets of useful code on stack overflow for smalltalk for the things I want to do. Maybe copilot is better there. The more practical problem is I'd never be able to justify using any of this for corporate work.
Even worse there are groups of people who keep praising it and keep us curious through these years. Yet none of remarkable applications built with it except the tool itself.
There were lots of applications written on enterprises, hence why Gang of Four book used Smalltalk and C++, not Java as many think when bashing the book ideas.
That would come later and take the air out of Smalltalk business adoption as IBM and others pivoted away from Smalltalk into Java.
It is no coincidence that while Java has a C++ like syntax, its runtime semantics, the ways how JVM is designed and related dynamism, Eclipse, key frameworks on the ecosystem, and by extension the CLR, all trace back to Smalltalk environment.
Yeah this really exposes how empty and vapid the praise and criticism you see of stuff here is. Of course there are some people here who are well known to be substantial in their experience, but sooo many people clearly are not. The vast majority are just superficial and you can and should ignore them.
For my part, I've never used it in anger. But I like to praise it because it represents a hint of what I wish my tooling were like, and would like to see this concept of moldable development spread outside of the Pharo community. Not just in terms of using it for other languages, but also building it on top of other languages
There are a lot of things I like about Smalltalk, but the parent poster is right, Python is a more practical choice. Not really because it's better-known so much as because it's procedural. Smalltalk is so all-in on object-oriented programming that it puts me in the wrong mental space for just banging out throwaway code for getting a question answered quickly. Instead I'm constantly being pulled toward all this "clean architecture clean code" thinking because that's just such a big factor in my headspace for object-oriented programming. Even if I don't succumb to it, it's still a drain on my executive function.
And then yes, agreed, building on Pharo's UI system is a problem. That's frankly something that the Smalltalk community needs to get away from across the board. It's just too clunky by modern standards. And it would take a lot to convince me to agree to adopting a Pharo-based tool like this at work, out of fear that all the non-native UI stuff would become a major source of accessibility barriers. And I don't quite understand why the Pharo community seems to be so convinced that it's a necessary part of the image-based development paradigm, when lisp has been doing images without tight coupling to a single baked-in graphical IDE for decades.
I keep thinking maybe all it needs to be is something like an extension (or alternative) to the language server protocol for exposing some of the intermediate code analysis artifacts back to the developer. And then I can happily bang on that from a Jupyter notebook.
The absolute majority of Pharo code I've written has been quite procedural and throwaway in character. It's a tool I pull up for a bit of exotic exploratory programming against some remote API or file, typically just a 'script' in whatever the window is called.
In part because it's much easier to boot a fresh image and start hacking than some python3 -m venv incantation that sometimes breaks or breaks something else. There's a lack of libraries though, and now it might be easy to just point the image to a remote git repo to import it but I'm not sure, if it isn't other languages has it easier. At least when you can just copy the algorithm into a file and put the right formula at the top and start using it.
Smalltalk-style tooling is mostly used in small businesses selling to either small or niche businesses. Things like custom ERP in manufacturing, custom CRM in insurance. Some military projects have also been done.
The Pharo folks insist on trying to adapt to industry, and that's also the focus of a lot of their published material, though there's still an academic legacy in there.
For me the tricky thing is to find enough time to study the API:s, the programming language is easy to learn the basics of and then one has to figure out the flow in creating a package and adding code to it, but then it's a slog searching and reading the code for hundreds of classes to figure out where the thing one wants resides. On the other hand, when things break it's usually a breeze, the inspection and debugging is great, unless one does the mistake of redefining some core class and corrupts the entire image.
> unless one does the mistake of redefining some core class and corrupts the entire image
In which case, one does not save that image ;-)
Or if one chose to save a broken image, one goes back to a previous image and reloads all the more recent logged changes up-to and excluding the change that broke things.
FWIW, this project is promoting the ideas behind it as much as its own implementation. Personally, I'm a strong proponent of the underlying concept of "moldable development"; in fact, I think this isn't going far enough[0].
As for:
> Yet none of remarkable applications built with it except the tool itself.
The same is true of Smalltalk in general, and of Lisp, and some other technologies. Lack of wide adoption and large amount of success stories is, alone, not a proof the idea/technology is fundamentally bad. The choices in our industry are strongly path-dependent, driven primarily by popularity contests and first-mover advantage. This dynamic is famously known as "Worse is Better"[5].
What the original essays didn't account for, however, is that whatever gets moderately successful today, becomes a building block for more software tomorrow. As we stack up layers of software, the lower layers become almost completely frozen in place (changing them risks breaking too many things). "Worse is Better" sounds fine on the surface, but when you start stacking layers of "worse" on top of each other, you get the sorry state of modern software :).
So yeah, those ideas may not fit the industry today, but it's worth keeping them in mind as a reference, and try to move towards them, however slowly, to try and gradually improve how software is made.
---
[0] - I write about that regularly; look up my comments with the phrase plaintext "single source of truth"[1] for some entry points, like [2] or [3].
TL;DR: use of such "contextual tools" should become the way we build software. We need to have environments that come packed with various interactive "lenses" through which you can view and edit the common codebase using whatever representation and modality (textual, graphical, or something else) is most convenient for the thing you're doing this minute, switching and combining them as needed[4]. What we consider a codebase now - plaintext files we collaborate on directly - needs to evolve towards being a serialization format, and we shouldn't need to look at it directly, not any more often than today we look at binary object files compilers spit out.
[4] - And saving the combinations and creating new tools easily, too. Perspectives you use to understand and shape your project are as much a part of it as the deployable result itself.
The GT/Pharo technology may be the best, but due diligence always reports that the real problem why neither GT nor Pharo get large sources of funding is that the community is conflictive and full of people with poor human qualities.
Thank you for putting into words your frustrations with trying to grok GT and Pharo, which matches mine. It's too bad because I can sense the fascinating technologies and the possibilities of a great developer experience that are there, but there is a lot of tribal and historic knowledge surrounding smalltalk that can be quite impenetrable.
I have been thinking about my own experience trying to learn Pharo and GT and came to the conclusion that, because of the nature of smalltalk, written form of teaching materials are not effective and in fact even painful to learn from. Nothing wrong with the smalltalk approach of computing, such as GUI-centric and image-based environment. They are what makes it so interesting and an immersive development environment. But video tutorials and live-session hand-holding are what's needed to teach these environments because of the highly interactive nature of smalltalk. The Pharo MOOC exists, but that requires the type of academic-level time and mental commitment of back when I was in school. And as a hobbyist, I have less-demanding options for learning that are also interesting so I end up pausing my efforts to learn Pharo/GT.
It's a tough situation for smalltalk proponents because interactive instruction material are very costly to produce and maintain. And the smalltalk communities are much smaller and they have don't massive corporate sponsors. Even cheaply-made YouTube videos take time and effort, and I am grateful for those who make them out of their enthusiasm for the technology!. But I'm afraid I've been conditioned to watch slick, engaging video content with clear, well-paced voice tracks and accurate captioning.
I do wonder if the smalltalk community could benefit from a beginner-friendly, simplified version of Pharo UI that starts up in a Jupyter notebook interface and expose only limited tooling, to give the learner a taste of what's possible and has some guardrails to prevent the user getting lost. Gradually revealing the Pharo/GT features that way would keep the learner engaged and motivated. Because of the above-mentioned challenges with producing teaching content, self-guided interactive learning tools would be the best bang-for-buck, I think. I thought the Elixir language manual was excellent and it was the first language reference doc I actually enjoyed reading! (Until it got to the string handling... then I ran out of attention span, lol) Elixir also have Livebook.dev which gives notebook interface. Could be a good inspiration.
Another possibly dumb idea I had was that maybe smalltalk is an ideal companion to current LLM tool/function calling APIs, where an LLM can "guide" a live smalltalk environment for developing an application through an API. Since a smalltalk environment is always running, it can also (maybe) feed relevant live state context back to the LLM with some feedback prompts... I suppose a smalltalk envrion can serve as a sort of memory for LLM as well as an agent for modifying the smalltalk environ?
Sorry, didn't mean for this to sound like "you must do this for free for my mild interest in your passion project!" This has been more of a stream-of-consciousness spillage onto this forum because Grumbledour's excellent comment resonated with me. :) And the mention of notebook interface clicked in my head.
Anyway, sorry for ranting, and thank you GT/Pahro team for making something fascinating! Stuff like this is what keeps me in the technology field instead of totally leaving it out of frustration with the where tech meets business!
Awesome. Had a feeling this was going to be a smalltalk thing. Seems to involve/extend moose[1] among other things.
Judging from the comments and such interesting projects languishing in obscurity.. smalltalk / pharo[2] still has a PR problem even though I think a lot of people are kind of fascinated by the ideas of image-based persistence[3]. The typical easy comparisons to VMs, IDEs, and notebooks all seem to fail to capture an important part of the essence. Hence the need for new vocabulary like "moldable development" and "contextual micro tools" which is all part of the appeal and part of the problem. It really is a different kind of thing.
I (still) hope it all catches on a bit more but my sense is that it probably needs to present itself as a bit less academic. Compare the moose touting of "meta-meta-modeling" with something like gritql[4], which focuses more on use-cases, and seems to be gaining in popularity rather than remaining obscure. Seems like maybe it's time for a change in tactics to bring in a wider audience.
Moldable Development is different from programming in Smalltalk. It's not a way of advertising Smalltalk, it's a new way of programming :)
Moose indeed came from academia and was focused on various kinds of analyses. Glamorous Toolkit does include a small part of it, but it is a whole environment.
Thank you for the suggestion related to use cases. Today, people tend to look for specific tools that can be used out of the box for a specific set of problem. Something like gritql fits in that expectation well.
The challenge we face is that Moldable Development is generic and it is applicable in a wide range of scenarios. For example, the video on the front page tries to provide an idea of classes of use cases. The GT book offers many more such case studies. All of these are accommodated uniformly in the same environment with small energy. This is novel and requires awareness which leads to a catch-22 problem.
We try to address this also coming from the larger problem at https://moldabledevelopment.com, including a new book I am writing with Simon Wardley.
We would be interested in suggestions for how to communicate it better.
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.
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.
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.
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.
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.
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.
When I visit that gritql link, the first line of "Usage" already tells me a lot: (1) what problems can it solve, (2) how do I use it and (3) what is entry threshold. This makes it a very cool tool which I am will be using in the future. That's for telling me about it!
(In case you wonder, the answers I saw are: (1) semantics-aware code search/replace with no IDE requirement; or maybe better "grep" with no false positives (2) write queries on command line or in file, and pass them to tool; (3) very low: install the binary, there no need to "import" or "setup project" or any things like those).
Compared to that into, Glamorous Toolkit presets itself much worse. Here were my thoughts when I opened the website: It seems to be some sort of data explorer tool, but it's also kinda weird. For example, the API explorer clearly shows post-processed data, so it's not actually exploring Github API, but rather some sort of binding to it (GhRepo according to the title).. so what's the use of API explorer which requires bindings to be written first? DevOps explorer seems interesting, but I don't care about Jenkins, so what I really want to see is how hard is it to teach it about new system. Maybe it's in the videos, but I am not going to watch long videos unless I am already interested in the tool. Maybe if I click around? Nope, and the blog is not very helpful too... In fact, the comments for the post were much more informative than the website, I love HN!
So, apparently the answers are (1) it can visualize the data, if I am willing to learn smalltalk (2) it's smalltalk, so you create smalltalk classes, and they become stuck in the "image" that you cannot easily share with others nor use with any existing workflows and (3) it's probably a few hours of youtube (the first video alone is 45 minutes) + experimenting before I can get any useful output.
I don't see it ever catching at all, sorry.
Granted, it seems like a general problem with Smalltalk: the collaboration story is bad. It seems every Smalltalk user lives in their own little world, and sharing stuff with other people is an afterthought, at best. Just compare gritql's and GT's homepage: one starts with 3 copy-pasteable commands which would immediately show something cool, another starts with mysterious "Download" button followed by 45 minute video.
The GT people don't like boxing what it is into any specific category. Which isn't great for new users but also makes sense when you use it.
Because it's really not any one thing other than an environment that is built from the ground up for building highly explainable systems, including itself. Think about it like a "meta-tool", or a tool for building tools. Similar to how an operating system is a piece of software used for writing other pieces of software easier.
So naturally this type of workflow lends itself to data analysis. However it's no less applicable in building p2p networks, or working with codebases in other languages.
Regarding sharing code, it's actually really straight forward. Your classes aren't stuck in images, but are normally stored as normal plaintext files and committed into git. The library story is arguable better than in most other languages, because of how flexible smalltalk is.
A question: Why would you say that the Download button is mysterious? I think I might have missed the issue.
Still we now changed the "Download" button to "Get started" that links to a page with more concrete steps. Is this improving the situation from your point of view?
The worry about the enhancements being trapped is interesting. All of GT sources are in Git and extensions can be packaged next to your own project. We will try to address it explicitly in the main page. Would you say that a Frequently Asked Questions section would help with this?
Ok I went and watched the YouTube video. As a few others have mentioned, it seems analogous to iPython notebooks. Basically a bunch of tiny tools that augment your experience working with code, like showing dependencies as a graph, or letting you view dictionaries graphically.
Thank you for taking the time. There is certainly similarity with notebooks. However, the notebook is only a part. For example, the notebooks are part of a knowledge base. They are multi-language.
But the more interesting bit comes from how you can extend the environment to make it fit the context of your problem. For example, a prominent way to extend is by creating contextual inspector views for different objects.
When taken as a whole, we end up with a new kind of a development experience that is centered around contextualizing the environment as part of development. It turns out that this is applicable to a wide range of problems.
For example, the talk video from the page shows examples from several domains:
- it starts by browsing the file system of a React project and then querying the external dependencies from a package.json
- then it goes into static analysis of React components and their dependencies
- then it shows how to explore the data of a REST API and document its usage
- then it goes to work with GraphQL and show how to combine it with imperative code to explore data; and even here, we go a step deeper and answer the question of how the tool worked (i.e., what query was sent to the server when we do not specify pagination completely)
- then it shows how we can work with Python by extending the inspector with Python code
- then it shows how we can also change the editing experience as well and make it contextual
- then it shows how we can document a domain model through executable examples that when combined with contextual views become documentation
- then it shows how to work with the knowledge base and even post live to a social media from it through a dedicated snippet
- then it shows how we can explain a Docker setup and how the commands were derived from templates
- then it shows again social media interactions but this time by browsing posts in inspectors and querying the feed live
- and finally it shows how we can have a dedicated editor for configurations defined in JSON that know how to highlight, complete and navigate based on the schema information
Now, these are not features; they are just some ways you can use the environment for without the need for switching. The book from the environment shows even more such examples for inspiration. Each of these might look similar to some tool somewhere, but the possibility to have all of them in the same environment made out of the same pieces combined in many ways is the differentiator.
Thanks for taking the effort to lay it out for me! I did watch the video, and I think I can see what you are going for. I appreciate the goal - having tooling that dynamically adapts to the problem I am trying to solve sounds like a dream.
My main reservation, at least initially, was that the website comes across too focused on the paradigm for its own sake. Hence my comment - it feels like a PhD project trying to project complexity and impressiveness. Personally I would have appreciated more focus on what it is, and why its useful, not an abstract framing of "moldable development". I hope that's not too harsh - just wanted to give my 2c honestly.
Thank you for the feedback! It is certainly not too harsh :)
The problem is that for any given problem, there might be some solution out there that does something like it. Except that there is no solution anywhere in which you can do all of these. So, we are showing Moldable Development because that is the goal and that is the proposition of the technology. I believe that masking it as something else would not be particularly useful.
We understand that at this point in time, most people do not look for Moldable Development. Most people will consider it once others have taken it and create large value with it. So, right now, we are interested in finding those people because they will convince everyone else :).
The goal was to explore the idea of contextualizing our tools for each development. It is built in Smalltalk (and Rust underneath) because Smalltalk already has the possibility of a live environment that can be changed from within. This allowed us to explore the space at much lower cost. Glamorous Toolkit is the result of that.
Okay your "why not" comment is a little bit on the passive aggressive side, while my question was an actual question about the choice of tech. Happily then you found the strength to actually answer the question in a reasonable way, thanks for that. Also thanks for down-voting my sincere curiosity, helps a lot, and made me feel appreciated.
Is there some way to know the user who down voted here? I wouldn't presume that was the case. Many users here might have downvoted your parent comment because it was terse and appeared combative rather than contributing to the conversation. I have found on HN it is best to enrich one's questions to avoid this look. I also did not detect anything passive aggressive in the 'why not', it's a fair enough initial response (even kept light with a smiley face!) - the good will was further demonstrated by continuing with an actual explanation instead of a snarky comment. It's the nature of online communication that we need to take a step back and take in a number of added variables before we jump to conclusions.
Oh, I did not know there was a way to downvote here, actually. I thought you could only upvote.
Thank you for the kind clarification. Indeed, it describes my intent quite well. Thank you for taking the time to describe how it is perceived from your point of view. I hope this is useful for the initial recipient as well.
I think it's a variant of the Anthropic principle. This project has been around for many years, and if it hadn't been based on Smalltalk at the time, it might not have come into existence. It's a natural extension of how Smalltalk environments approach development tools, pushing it to a new level. For more technical details, refer to https://pharo.org/features.
My "why not" had a smiley next to it because it was meant as a joke. I am not sure what you mean by downvoting, but I did not mean to discourage your curiosity. I am sorry if it came out like that.
p.s. I learnt in the meantime that it's possible to downvote somehow (I still do not know how). But in this case, I actually upvoted you.
First time coming across this project and it's amazing!!
Disclaimer: not used it, but certainly going to try it.
Technology is too fragmented - day to day many of us depend on a ton of tools to go by our (work)days even for simple stuff. Log into console of X, Y & Z platform or tools (say X = Jira, Y = AWS, Z = repo) to introduce a new change/feature/bugfix whatever. Then switch to IDE of choice to eval code, then browser to read the docs, then Google/Claude to ask questions, and then be interrupted by a meeting, take notes, ... and on and on
I see an opportunity here using something like this to unify your entire workflows/data-from-tools/tools into a uniform system you can query to get answers without having to jump through hoops (and give up). It appears investing time in building a repertoire of tools with something of this sort helps one automate or quicken chores (at work or at home even?)
What else could you do with this apart from what's in the demos? Some "can it do this?" questions if anyone who has used this could helpfully answer are:
* organise meeting notes across various topics and auto-compile a searchable "decision log" that you can drill in to dive into the context at a future date?
* connect requirements (specified in excel) to JIRA tickets and Code? so you can jump back and forth in a single GUI
* Log hours you have worked on something
* create up to date management process reference / checklist along with escalation contacts, response templates, ability to engage others on roster, and later bring together all the information into a automated PIR timeline and other details
* display system metrics of deployed services in AWS based on complex rules and provide local alert
* maintain a schedule of your kid's swimming lessons
* Notion like "verification expired" notifications
> I see an opportunity here using something like this to unify your entire workflows/data-from-tools/tools into a uniform system you can query to get answers without having to jump through hoops (and give up). It appears investing time in building a repertoire of tools with something of this sort helps one automate or quicken chores (at work or at home even?)
That intuition is quite right! If you look inside the environment, you will see multiple case studies. These are not things you do with the environment. These are things we've used the environment for. They are examples of what you can build. And if you look closer you will see different classes of problems. These are classes of problems for which the industry offers significant vertical solutions. Yet we show them addressed with much less energy, uniformly and much more contextualized. The idea is that if this is possible, it means it's also possible to produce tools for arbitrary combinations of problems.
If you intend to explore it further, please do let us know how it goes.
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?
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.
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.
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.
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.
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.
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 :)
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!
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
as I reach the limits of Literate Programming and so forth, but not convinced that the added overhead will pay off. Does anyone have a before-and-after of a project where this has been really useful? Bonus points if in Python.
I'd be interested to learn more about the kinds of things you'd expect to get from using Glamorous Toolkit for gcodepreview.
The way I see it, one path would be to make the rendering happen directly in GT (perhaps through an external texture). This would then allow you to see the rendering as views in various Python objects.
"The goal? To make the inside of systems explainable.
[image]
caption: "The need for moldability is pervasive. The treemap shows the classes of Glamorous Toolkit organized in packages. Blue denotes classes that contain at least one contextual view; green shows those that have an example."
I have no idea what that caption, nor the image, means, nor what it has to do with making the inside of systems explainable.
I think it’s probably for the better… but it’s a bit hard for me to judge. I don’t know much about the project, and didn’t understand those details, so I don’t know how important they were, or whether there is a better way to address the issues with what was there.
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?
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.
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.
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.
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.
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 :).
Reading through that website felt to me like trying to read the NKS book. It certainly feels like there's a there "there", but I'm either to unintelligent or can't devote the time to really get it, and then I move on
Thanks. It's certainly not about the reader's intelligence. At this moment, we do not know how to explain it succinctly. So, today it requires time.
We are trying a different way of explaining starting with the overall problem of how to make decisions in software engineering in a book Simon Wardley and I are writing in the open. Perhaps it's of interest and sheds a bit more light: https://medium.com/feenk/rewilding-software-engineering-900c...
I love the ideas presented, and it really highlights how current IDE's have removed power from users. I think (from only reading and watching some videos) that this Glamorous Toolkit is a hybrid between Smalltalk IDE and C.A.S.E. tools.
However, I downloaded the app but cannot figure out how to view my own source code. None of the example videos that I can find, show me how to use an existing local git checkout of source code.
Many comments are comparing Glamorous Toolkit to a JuPyteR notebook. It's worth noting that the comparison falls short because Glamorous Toolkit itself, including all of the UI [1], is implemented in the target language.
The graphical part is one source of difference, but there others as well. For example, chapter 4 in the Rewilding Software Engineering that Simon Wardley and I are writing compares what we call defined explorations (as seen in Jupyter notebooks) with dynamic explorations (as experienced in Glamorous Toolkit):
https://medium.com/feenk/rewilding-software-engineering-a360...
It's the other way around. Python notebooks fall short compared to this because they don't have the same kind of interactivity with the data as GT has.
A single tool in the toolkit is already equivalent to notebooks, at least from what I glimpsed at the introductory video. Then you have the rest of the tools, how it can easily inspect the objects, and probably manipulate them.
This is probably one of the future ways in which we will work in programming in the future, when someone creates some similar tool, around a mainstream language, that can easily interact with LLMs, APIs, and data visualization tools.
In fact, there is already LLM integration including programmable chats with the possibility of contextualizing the interface of each message in the chat :)
We were certainly aware of Intentional Programming. And indeed, Glamorous Toolkit does have a language workbench underneath with which we can create editing experiences for various technologies.
But we started from the "reading" part of software engineering not from the "writing". That's because "reading" the system occupies the largest amount of development effort and it's the least optimized activity. Through contextual tools we can improve it manyfold. And this, it turns out, leads to a new way of "writing" as well. We call it Moldable Development.
I honestly saw all the screenshots and still dont understand even in the slightest bit what exactly your product does. Perhaps you picked a bad name or perhaps the copy on the website doesn't do justice to what the product actually does. Since you pasted some python code somewhere as example in one of the screenshots, I ll ask you a very simple question. I have a 50 line python program. I run your tool, what do I see?
It’s a lot simpler to install nowadays. Just download, install, open the app, and voilà! Tons of self-executing examples are available within the notebook-style windows too.
I also have little idea what this project does or wants to do. Let's just talk about the homepage, especially the above-the-fold portion.
> "Glamorous Toolkit is the Moldable Development Environment"
So it's some sort of an IDE? What does moldable mean?
> "Make systems explainable through contextual micro tools"
What is a "system" in the context of an IDE? "Contextual micro tools" also sounds completely abstract.
> "Each problem about your system is special. And each problem can be explained through contextual development experiences. Glamorous Toolkit enables you to build such experiences out of micro tools. Thousands of them ... per system. It's called Moldable Development."
... this does not help at all. Just more words without meaning.
Next, there's the video. For somebody with zero context so far, why would they sit through a 46 min low quality video?
tudorgirba - if this is your project, you really need to focus on getting the top half of the page right. People won't watch your video, no one will read your book if you can't give them a hook they understand.
Use words and phrases with concrete and well understood meaning with adjectives:
* Don't say "micro tool". Like Posix utilities? What is a tool? What makes it micro?
* Don't say "contextual development". Isn't all development contextual?
* "moldable" - no one knows what this means, don't force them to try and figure it out.
* Don't say "system", it is too abstract.
For example, "Glamorous Toolkit is an IDE for literate programming with first class support for interactive visualizations". If you can't get that sentence right, people just won't invest in learning more about your platform.
It's much better packaged now than n years ago when I stumbled on installation and whatnot and gave up, that's great. If you like me don't like the font size, search the book for how to scale UI, the last snippet on that page show's how to do a global font size change.
PSA: if you're watching the video. Get through the first (or fast forward to) 2 min 3s... The audio quality is much improved at this point. At first I wasn't able to watch on 2x speed with all the noise, but at the 2min mark it was much better.
In a way. It does have a notebook component, but that's just one piece. It's the sum of all pieces that make it a different environment.
From our point of view, the interesting bit is that we show that we can use the idea of contextual tools for every development problem at any abstraction level. That's counter intuitive, but we worked like this for 10 years and we did not find a counter example yet :)
people seem to miss that for technologies like this to succeed, it is not necessary for others to fail. interoperability is (or should be) the most important goal of all software.
the fewer operating systems and environments there are, the lower the incentive to make portability a feature.
OK, so it's like Python notebooks and Smalltalk. so it's like this dynamic thing for transforming data in a rapid feedback, ad hoc, exploratory fly-by-the-seat-of-your pants way. OK. why talk about "capturing domain knowledge" in videos where you're just making a class and sticking a variable in it? what does the class even do anyway if it's just a name with a field that's a bag of data?
It's more like Spacemacs. An opinionated, programmable interface to an operating system that allows you to edit and execute text, browse the web, play git and so on. Just that it has a fleshed out GUI toolkit you interface with, unlike Spacemacs which is heavily text oriented.
With the territory also comes that it's somewhat hard for newcomers to understand why the tool is important to longtime converts. The clear use cases seem mundane. 'You can edit text in it'. 'You can execute code in it'. 'It lets you debug programs'. To which one might respond: 'Yeah, so? Why do I need elisp/Smalltalk? My Electron app already does that and it doesn't come with weird Internet nerds.'
If you get into it and later find that it helped you out to be able to deeply inspect or reprogram your notetaking, program execution, feed reader, git environment, then you'll start to think that it has something special. But that might take a while, and most of the way there you could just as well have used some other tool instead.
I am so conflicted about this project every time it comes up.
I think I understood for quite some time what it wants to do (Though when checking the website there always creeps in doubt, because it is so incomprehensible) and every year when I download the application again, it looks a bit more cleaner, a bit easier to just use. But still, basic things always elude me. Do I really have to read the handbook to figure out how to format text in the knowledge base? Half the windows and symbols just make no sense, etc. Try pressing a button to see what it does and now everything looks different and what even happened?
It seems to glacially improve on that front and I know to really use it, I have to learn to program it, but I am also of the mind basic functionality should be self explanatory. And pharo itself as the basis of this seems so convoluted and complex, I wonder if I even want to get into this.
And then, the community seems to solely be on discord still, and that is then always the point were I bow out and wonder if cuis smalltalk or other systems with simplicity as core tenant are not much nicer to use and I should look there. Of course, in the end, I never get more than surface deep into smalltalk, because while I want the tools to build my own environment, if I need to build them first, there is always more pressing work...
But honestly, a great knowledge base and data visualization I can intuitively just use and then expand later on with my own programs sounds like a dream workspace. It's just, that it is really hard to get into at the moment. I don't know any python, but I could just use jupyter know and learn as I go, but sadly, I never get that feeling here.
I'm basically in the same boat with this and all the smalltalk systems I have tried. The environment is just so foreign. I get the gist for how programming works in pharo (have also looked at Squeak and Cuis), but Python just seems a lot more natural. It is also hard to find snippets of useful code on stack overflow for smalltalk for the things I want to do. Maybe copilot is better there. The more practical problem is I'd never be able to justify using any of this for corporate work.
Even worse there are groups of people who keep praising it and keep us curious through these years. Yet none of remarkable applications built with it except the tool itself.
There were lots of applications written on enterprises, hence why Gang of Four book used Smalltalk and C++, not Java as many think when bashing the book ideas.
That would come later and take the air out of Smalltalk business adoption as IBM and others pivoted away from Smalltalk into Java.
It is no coincidence that while Java has a C++ like syntax, its runtime semantics, the ways how JVM is designed and related dynamism, Eclipse, key frameworks on the ecosystem, and by extension the CLR, all trace back to Smalltalk environment.
Yeah this really exposes how empty and vapid the praise and criticism you see of stuff here is. Of course there are some people here who are well known to be substantial in their experience, but sooo many people clearly are not. The vast majority are just superficial and you can and should ignore them.
For my part, I've never used it in anger. But I like to praise it because it represents a hint of what I wish my tooling were like, and would like to see this concept of moldable development spread outside of the Pharo community. Not just in terms of using it for other languages, but also building it on top of other languages
There are a lot of things I like about Smalltalk, but the parent poster is right, Python is a more practical choice. Not really because it's better-known so much as because it's procedural. Smalltalk is so all-in on object-oriented programming that it puts me in the wrong mental space for just banging out throwaway code for getting a question answered quickly. Instead I'm constantly being pulled toward all this "clean architecture clean code" thinking because that's just such a big factor in my headspace for object-oriented programming. Even if I don't succumb to it, it's still a drain on my executive function.
And then yes, agreed, building on Pharo's UI system is a problem. That's frankly something that the Smalltalk community needs to get away from across the board. It's just too clunky by modern standards. And it would take a lot to convince me to agree to adopting a Pharo-based tool like this at work, out of fear that all the non-native UI stuff would become a major source of accessibility barriers. And I don't quite understand why the Pharo community seems to be so convinced that it's a necessary part of the image-based development paradigm, when lisp has been doing images without tight coupling to a single baked-in graphical IDE for decades.
I keep thinking maybe all it needs to be is something like an extension (or alternative) to the language server protocol for exposing some of the intermediate code analysis artifacts back to the developer. And then I can happily bang on that from a Jupyter notebook.
The absolute majority of Pharo code I've written has been quite procedural and throwaway in character. It's a tool I pull up for a bit of exotic exploratory programming against some remote API or file, typically just a 'script' in whatever the window is called.
In part because it's much easier to boot a fresh image and start hacking than some python3 -m venv incantation that sometimes breaks or breaks something else. There's a lack of libraries though, and now it might be easy to just point the image to a remote git repo to import it but I'm not sure, if it isn't other languages has it easier. At least when you can just copy the algorithm into a file and put the right formula at the top and start using it.
Smalltalk-style tooling is mostly used in small businesses selling to either small or niche businesses. Things like custom ERP in manufacturing, custom CRM in insurance. Some military projects have also been done.
The Pharo folks insist on trying to adapt to industry, and that's also the focus of a lot of their published material, though there's still an academic legacy in there.
For me the tricky thing is to find enough time to study the API:s, the programming language is easy to learn the basics of and then one has to figure out the flow in creating a package and adding code to it, but then it's a slog searching and reading the code for hundreds of classes to figure out where the thing one wants resides. On the other hand, when things break it's usually a breeze, the inspection and debugging is great, unless one does the mistake of redefining some core class and corrupts the entire image.
> unless one does the mistake of redefining some core class and corrupts the entire image
In which case, one does not save that image ;-)
Or if one chose to save a broken image, one goes back to a previous image and reloads all the more recent logged changes up-to and excluding the change that broke things.
https://cuis-smalltalk.github.io/TheCuisBook/The-Change-Log....
FWIW, this project is promoting the ideas behind it as much as its own implementation. Personally, I'm a strong proponent of the underlying concept of "moldable development"; in fact, I think this isn't going far enough[0].
As for:
> Yet none of remarkable applications built with it except the tool itself.
The same is true of Smalltalk in general, and of Lisp, and some other technologies. Lack of wide adoption and large amount of success stories is, alone, not a proof the idea/technology is fundamentally bad. The choices in our industry are strongly path-dependent, driven primarily by popularity contests and first-mover advantage. This dynamic is famously known as "Worse is Better"[5].
What the original essays didn't account for, however, is that whatever gets moderately successful today, becomes a building block for more software tomorrow. As we stack up layers of software, the lower layers become almost completely frozen in place (changing them risks breaking too many things). "Worse is Better" sounds fine on the surface, but when you start stacking layers of "worse" on top of each other, you get the sorry state of modern software :).
So yeah, those ideas may not fit the industry today, but it's worth keeping them in mind as a reference, and try to move towards them, however slowly, to try and gradually improve how software is made.
---
[0] - I write about that regularly; look up my comments with the phrase plaintext "single source of truth"[1] for some entry points, like [2] or [3].
TL;DR: use of such "contextual tools" should become the way we build software. We need to have environments that come packed with various interactive "lenses" through which you can view and edit the common codebase using whatever representation and modality (textual, graphical, or something else) is most convenient for the thing you're doing this minute, switching and combining them as needed[4]. What we consider a codebase now - plaintext files we collaborate on directly - needs to evolve towards being a serialization format, and we shouldn't need to look at it directly, not any more often than today we look at binary object files compilers spit out.
[1] - https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[2] - https://news.ycombinator.com/item?id=42778917
[3] - https://news.ycombinator.com/item?id=39428928
[4] - And saving the combinations and creating new tools easily, too. Perspectives you use to understand and shape your project are as much a part of it as the deployable result itself.
[5] - https://en.wikipedia.org/wiki/Worse_is_better
I am glad you find Moldable Development interesting as a concept.
> in fact, I think this isn't going far enough I would be more than curious to learn more about how you see this space :)
The GT/Pharo technology may be the best, but due diligence always reports that the real problem why neither GT nor Pharo get large sources of funding is that the community is conflictive and full of people with poor human qualities.
Thank you for putting into words your frustrations with trying to grok GT and Pharo, which matches mine. It's too bad because I can sense the fascinating technologies and the possibilities of a great developer experience that are there, but there is a lot of tribal and historic knowledge surrounding smalltalk that can be quite impenetrable.
I have been thinking about my own experience trying to learn Pharo and GT and came to the conclusion that, because of the nature of smalltalk, written form of teaching materials are not effective and in fact even painful to learn from. Nothing wrong with the smalltalk approach of computing, such as GUI-centric and image-based environment. They are what makes it so interesting and an immersive development environment. But video tutorials and live-session hand-holding are what's needed to teach these environments because of the highly interactive nature of smalltalk. The Pharo MOOC exists, but that requires the type of academic-level time and mental commitment of back when I was in school. And as a hobbyist, I have less-demanding options for learning that are also interesting so I end up pausing my efforts to learn Pharo/GT.
It's a tough situation for smalltalk proponents because interactive instruction material are very costly to produce and maintain. And the smalltalk communities are much smaller and they have don't massive corporate sponsors. Even cheaply-made YouTube videos take time and effort, and I am grateful for those who make them out of their enthusiasm for the technology!. But I'm afraid I've been conditioned to watch slick, engaging video content with clear, well-paced voice tracks and accurate captioning.
I do wonder if the smalltalk community could benefit from a beginner-friendly, simplified version of Pharo UI that starts up in a Jupyter notebook interface and expose only limited tooling, to give the learner a taste of what's possible and has some guardrails to prevent the user getting lost. Gradually revealing the Pharo/GT features that way would keep the learner engaged and motivated. Because of the above-mentioned challenges with producing teaching content, self-guided interactive learning tools would be the best bang-for-buck, I think. I thought the Elixir language manual was excellent and it was the first language reference doc I actually enjoyed reading! (Until it got to the string handling... then I ran out of attention span, lol) Elixir also have Livebook.dev which gives notebook interface. Could be a good inspiration.
Another possibly dumb idea I had was that maybe smalltalk is an ideal companion to current LLM tool/function calling APIs, where an LLM can "guide" a live smalltalk environment for developing an application through an API. Since a smalltalk environment is always running, it can also (maybe) feed relevant live state context back to the LLM with some feedback prompts... I suppose a smalltalk envrion can serve as a sort of memory for LLM as well as an agent for modifying the smalltalk environ?
Sorry, didn't mean for this to sound like "you must do this for free for my mild interest in your passion project!" This has been more of a stream-of-consciousness spillage onto this forum because Grumbledour's excellent comment resonated with me. :) And the mention of notebook interface clicked in my head.
Anyway, sorry for ranting, and thank you GT/Pahro team for making something fascinating! Stuff like this is what keeps me in the technology field instead of totally leaving it out of frustration with the where tech meets business!
> I have to learn to program it, but I am also of the mind basic functionality should be self explanatory.
It explains it right on the site: "To learn how to program it, first learn how to learn inside the environment." /s
Awesome. Had a feeling this was going to be a smalltalk thing. Seems to involve/extend moose[1] among other things.
Judging from the comments and such interesting projects languishing in obscurity.. smalltalk / pharo[2] still has a PR problem even though I think a lot of people are kind of fascinated by the ideas of image-based persistence[3]. The typical easy comparisons to VMs, IDEs, and notebooks all seem to fail to capture an important part of the essence. Hence the need for new vocabulary like "moldable development" and "contextual micro tools" which is all part of the appeal and part of the problem. It really is a different kind of thing.
I (still) hope it all catches on a bit more but my sense is that it probably needs to present itself as a bit less academic. Compare the moose touting of "meta-meta-modeling" with something like gritql[4], which focuses more on use-cases, and seems to be gaining in popularity rather than remaining obscure. Seems like maybe it's time for a change in tactics to bring in a wider audience.
[1] https://en.wikipedia.org/wiki/Moose_(analysis) [2] https://en.wikipedia.org/wiki/Pharo [3] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste... [4] https://github.com/getgrit/gritql
Thank you for the comments!
Moldable Development is different from programming in Smalltalk. It's not a way of advertising Smalltalk, it's a new way of programming :)
Moose indeed came from academia and was focused on various kinds of analyses. Glamorous Toolkit does include a small part of it, but it is a whole environment.
Thank you for the suggestion related to use cases. Today, people tend to look for specific tools that can be used out of the box for a specific set of problem. Something like gritql fits in that expectation well.
The challenge we face is that Moldable Development is generic and it is applicable in a wide range of scenarios. For example, the video on the front page tries to provide an idea of classes of use cases. The GT book offers many more such case studies. All of these are accommodated uniformly in the same environment with small energy. This is novel and requires awareness which leads to a catch-22 problem.
We try to address this also coming from the larger problem at https://moldabledevelopment.com, including a new book I am writing with Simon Wardley.
We would be interested in suggestions for how to communicate it better.
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.
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.
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.
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.
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.
When I visit that gritql link, the first line of "Usage" already tells me a lot: (1) what problems can it solve, (2) how do I use it and (3) what is entry threshold. This makes it a very cool tool which I am will be using in the future. That's for telling me about it!
(In case you wonder, the answers I saw are: (1) semantics-aware code search/replace with no IDE requirement; or maybe better "grep" with no false positives (2) write queries on command line or in file, and pass them to tool; (3) very low: install the binary, there no need to "import" or "setup project" or any things like those).
Compared to that into, Glamorous Toolkit presets itself much worse. Here were my thoughts when I opened the website: It seems to be some sort of data explorer tool, but it's also kinda weird. For example, the API explorer clearly shows post-processed data, so it's not actually exploring Github API, but rather some sort of binding to it (GhRepo according to the title).. so what's the use of API explorer which requires bindings to be written first? DevOps explorer seems interesting, but I don't care about Jenkins, so what I really want to see is how hard is it to teach it about new system. Maybe it's in the videos, but I am not going to watch long videos unless I am already interested in the tool. Maybe if I click around? Nope, and the blog is not very helpful too... In fact, the comments for the post were much more informative than the website, I love HN!
So, apparently the answers are (1) it can visualize the data, if I am willing to learn smalltalk (2) it's smalltalk, so you create smalltalk classes, and they become stuck in the "image" that you cannot easily share with others nor use with any existing workflows and (3) it's probably a few hours of youtube (the first video alone is 45 minutes) + experimenting before I can get any useful output.
I don't see it ever catching at all, sorry.
Granted, it seems like a general problem with Smalltalk: the collaboration story is bad. It seems every Smalltalk user lives in their own little world, and sharing stuff with other people is an afterthought, at best. Just compare gritql's and GT's homepage: one starts with 3 copy-pasteable commands which would immediately show something cool, another starts with mysterious "Download" button followed by 45 minute video.
The GT people don't like boxing what it is into any specific category. Which isn't great for new users but also makes sense when you use it.
Because it's really not any one thing other than an environment that is built from the ground up for building highly explainable systems, including itself. Think about it like a "meta-tool", or a tool for building tools. Similar to how an operating system is a piece of software used for writing other pieces of software easier.
So naturally this type of workflow lends itself to data analysis. However it's no less applicable in building p2p networks, or working with codebases in other languages.
Regarding sharing code, it's actually really straight forward. Your classes aren't stuck in images, but are normally stored as normal plaintext files and committed into git. The library story is arguable better than in most other languages, because of how flexible smalltalk is.
Thanks for the feedback.
A question: Why would you say that the Download button is mysterious? I think I might have missed the issue.
Still we now changed the "Download" button to "Get started" that links to a page with more concrete steps. Is this improving the situation from your point of view?
The worry about the enhancements being trapped is interesting. All of GT sources are in Git and extensions can be packaged next to your own project. We will try to address it explicitly in the main page. Would you say that a Frequently Asked Questions section would help with this?
This comes across like someone's PhD project. It's unclear from reading the website what this is useful for and what it actually is.
Ok I went and watched the YouTube video. As a few others have mentioned, it seems analogous to iPython notebooks. Basically a bunch of tiny tools that augment your experience working with code, like showing dependencies as a graph, or letting you view dictionaries graphically.
Thank you for taking the time. There is certainly similarity with notebooks. However, the notebook is only a part. For example, the notebooks are part of a knowledge base. They are multi-language.
But the more interesting bit comes from how you can extend the environment to make it fit the context of your problem. For example, a prominent way to extend is by creating contextual inspector views for different objects.
When taken as a whole, we end up with a new kind of a development experience that is centered around contextualizing the environment as part of development. It turns out that this is applicable to a wide range of problems.
For example, the talk video from the page shows examples from several domains: - it starts by browsing the file system of a React project and then querying the external dependencies from a package.json - then it goes into static analysis of React components and their dependencies - then it shows how to explore the data of a REST API and document its usage - then it goes to work with GraphQL and show how to combine it with imperative code to explore data; and even here, we go a step deeper and answer the question of how the tool worked (i.e., what query was sent to the server when we do not specify pagination completely) - then it shows how we can work with Python by extending the inspector with Python code - then it shows how we can also change the editing experience as well and make it contextual - then it shows how we can document a domain model through executable examples that when combined with contextual views become documentation - then it shows how to work with the knowledge base and even post live to a social media from it through a dedicated snippet - then it shows how we can explain a Docker setup and how the commands were derived from templates - then it shows again social media interactions but this time by browsing posts in inspectors and querying the feed live - and finally it shows how we can have a dedicated editor for configurations defined in JSON that know how to highlight, complete and navigate based on the schema information
Now, these are not features; they are just some ways you can use the environment for without the need for switching. The book from the environment shows even more such examples for inspiration. Each of these might look similar to some tool somewhere, but the possibility to have all of them in the same environment made out of the same pieces combined in many ways is the differentiator.
Does this help in any way?
Thanks for taking the effort to lay it out for me! I did watch the video, and I think I can see what you are going for. I appreciate the goal - having tooling that dynamically adapts to the problem I am trying to solve sounds like a dream.
My main reservation, at least initially, was that the website comes across too focused on the paradigm for its own sake. Hence my comment - it feels like a PhD project trying to project complexity and impressiveness. Personally I would have appreciated more focus on what it is, and why its useful, not an abstract framing of "moldable development". I hope that's not too harsh - just wanted to give my 2c honestly.
Thank you for the feedback! It is certainly not too harsh :)
The problem is that for any given problem, there might be some solution out there that does something like it. Except that there is no solution anywhere in which you can do all of these. So, we are showing Moldable Development because that is the goal and that is the proposition of the technology. I believe that masking it as something else would not be particularly useful.
We understand that at this point in time, most people do not look for Moldable Development. Most people will consider it once others have taken it and create large value with it. So, right now, we are interested in finding those people because they will convince everyone else :).
If you want to learn more about Moldable Development, take a look at the book I am writing in the open with Simon Wardley: https://medium.com/feenk/rewilding-software-engineering-900c...
..and why Smalltalk
Why not? :)
The goal was to explore the idea of contextualizing our tools for each development. It is built in Smalltalk (and Rust underneath) because Smalltalk already has the possibility of a live environment that can be changed from within. This allowed us to explore the space at much lower cost. Glamorous Toolkit is the result of that.
Okay your "why not" comment is a little bit on the passive aggressive side, while my question was an actual question about the choice of tech. Happily then you found the strength to actually answer the question in a reasonable way, thanks for that. Also thanks for down-voting my sincere curiosity, helps a lot, and made me feel appreciated.
Is there some way to know the user who down voted here? I wouldn't presume that was the case. Many users here might have downvoted your parent comment because it was terse and appeared combative rather than contributing to the conversation. I have found on HN it is best to enrich one's questions to avoid this look. I also did not detect anything passive aggressive in the 'why not', it's a fair enough initial response (even kept light with a smiley face!) - the good will was further demonstrated by continuing with an actual explanation instead of a snarky comment. It's the nature of online communication that we need to take a step back and take in a number of added variables before we jump to conclusions.
Oh, I did not know there was a way to downvote here, actually. I thought you could only upvote.
Thank you for the kind clarification. Indeed, it describes my intent quite well. Thank you for taking the time to describe how it is perceived from your point of view. I hope this is useful for the initial recipient as well.
I think it's a variant of the Anthropic principle. This project has been around for many years, and if it hadn't been based on Smalltalk at the time, it might not have come into existence. It's a natural extension of how Smalltalk environments approach development tools, pushing it to a new level. For more technical details, refer to https://pharo.org/features.
That's exactly it.
We chose Smalltalk because we could not have discovered the space (what we now call Moldable Development) within the constraints we had.
My "why not" had a smiley next to it because it was meant as a joke. I am not sure what you mean by downvoting, but I did not mean to discourage your curiosity. I am sorry if it came out like that.
p.s. I learnt in the meantime that it's possible to downvote somehow (I still do not know how). But in this case, I actually upvoted you.
To downvote, you need a minimal amount of karma (something like 500 points)
Good to know. Thanks :)
First time coming across this project and it's amazing!! Disclaimer: not used it, but certainly going to try it.
Technology is too fragmented - day to day many of us depend on a ton of tools to go by our (work)days even for simple stuff. Log into console of X, Y & Z platform or tools (say X = Jira, Y = AWS, Z = repo) to introduce a new change/feature/bugfix whatever. Then switch to IDE of choice to eval code, then browser to read the docs, then Google/Claude to ask questions, and then be interrupted by a meeting, take notes, ... and on and on
I see an opportunity here using something like this to unify your entire workflows/data-from-tools/tools into a uniform system you can query to get answers without having to jump through hoops (and give up). It appears investing time in building a repertoire of tools with something of this sort helps one automate or quicken chores (at work or at home even?)
What else could you do with this apart from what's in the demos? Some "can it do this?" questions if anyone who has used this could helpfully answer are:
* organise meeting notes across various topics and auto-compile a searchable "decision log" that you can drill in to dive into the context at a future date?
* connect requirements (specified in excel) to JIRA tickets and Code? so you can jump back and forth in a single GUI
* Log hours you have worked on something
* create up to date management process reference / checklist along with escalation contacts, response templates, ability to engage others on roster, and later bring together all the information into a automated PIR timeline and other details
* display system metrics of deployed services in AWS based on complex rules and provide local alert
* maintain a schedule of your kid's swimming lessons
* Notion like "verification expired" notifications
* Live tables (say of stock market tickers)
> I see an opportunity here using something like this to unify your entire workflows/data-from-tools/tools into a uniform system you can query to get answers without having to jump through hoops (and give up). It appears investing time in building a repertoire of tools with something of this sort helps one automate or quicken chores (at work or at home even?)
That intuition is quite right! If you look inside the environment, you will see multiple case studies. These are not things you do with the environment. These are things we've used the environment for. They are examples of what you can build. And if you look closer you will see different classes of problems. These are classes of problems for which the industry offers significant vertical solutions. Yet we show them addressed with much less energy, uniformly and much more contextualized. The idea is that if this is possible, it means it's also possible to produce tools for arbitrary combinations of problems.
If you intend to explore it further, please do let us know how it goes.
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?
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.
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.
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.
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.
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.
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 :)
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!
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
Definitely needed. Grug want help. Grug not understand how do CRUD with Glamourous Toolkit. Grug want see.
Previous discussions:
https://news.ycombinator.com/item?id=33267518
https://news.ycombinator.com/item?id=23569799
https://news.ycombinator.com/item?id=42987951
https://news.ycombinator.com/item?id=23235120
It's something I've been considering for my current project:
https://github.com/WillAdams/gcodepreview
as I reach the limits of Literate Programming and so forth, but not convinced that the added overhead will pay off. Does anyone have a before-and-after of a project where this has been really useful? Bonus points if in Python.
Thanks for the links :).
I'd be interested to learn more about the kinds of things you'd expect to get from using Glamorous Toolkit for gcodepreview.
The way I see it, one path would be to make the rendering happen directly in GT (perhaps through an external texture). This would then allow you to see the rendering as views in various Python objects.
Some feedback on the webpage.
"The goal? To make the inside of systems explainable.
[image]
caption: "The need for moldability is pervasive. The treemap shows the classes of Glamorous Toolkit organized in packages. Blue denotes classes that contain at least one contextual view; green shows those that have an example."
I have no idea what that caption, nor the image, means, nor what it has to do with making the inside of systems explainable.
Thank you for the feedback.
We removed the image and pushed the video up. Is this better?
I think it’s probably for the better… but it’s a bit hard for me to judge. I don’t know much about the project, and didn’t understand those details, so I don’t know how important they were, or whether there is a better way to address the issues with what was there.
I think it was not useful if it was not understandable. Thanks again for the feedback :).
I periodically check in on this and I can never understand what its really good for.
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?
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.
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.
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.
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.
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 :).
Reproducible devops
Reading through that website felt to me like trying to read the NKS book. It certainly feels like there's a there "there", but I'm either to unintelligent or can't devote the time to really get it, and then I move on
Thanks. It's certainly not about the reader's intelligence. At this moment, we do not know how to explain it succinctly. So, today it requires time.
We are trying a different way of explaining starting with the overall problem of how to make decisions in software engineering in a book Simon Wardley and I are writing in the open. Perhaps it's of interest and sheds a bit more light: https://medium.com/feenk/rewilding-software-engineering-900c...
I love the ideas presented, and it really highlights how current IDE's have removed power from users. I think (from only reading and watching some videos) that this Glamorous Toolkit is a hybrid between Smalltalk IDE and C.A.S.E. tools.
However, I downloaded the app but cannot figure out how to view my own source code. None of the example videos that I can find, show me how to use an existing local git checkout of source code.
Many comments are comparing Glamorous Toolkit to a JuPyteR notebook. It's worth noting that the comparison falls short because Glamorous Toolkit itself, including all of the UI [1], is implemented in the target language.
[1] https://github.com/pharo-graphics/Bloc
Nice point!
The graphical part is one source of difference, but there others as well. For example, chapter 4 in the Rewilding Software Engineering that Simon Wardley and I are writing compares what we call defined explorations (as seen in Jupyter notebooks) with dynamic explorations (as experienced in Glamorous Toolkit): https://medium.com/feenk/rewilding-software-engineering-a360...
I'm wondering how it falls short ? Just because its not python ?
It's the other way around. Python notebooks fall short compared to this because they don't have the same kind of interactivity with the data as GT has.
A single tool in the toolkit is already equivalent to notebooks, at least from what I glimpsed at the introductory video. Then you have the rest of the tools, how it can easily inspect the objects, and probably manipulate them.
This is probably one of the future ways in which we will work in programming in the future, when someone creates some similar tool, around a mainstream language, that can easily interact with LLMs, APIs, and data visualization tools.
Well said!
In fact, there is already LLM integration including programmable chats with the possibility of contextualizing the interface of each message in the chat :)
I wonder if this was inspired to some degree by projects like Simonyi's Intentional Programming.
https://en.wikipedia.org/wiki/Structure_editor
https://martinfowler.com/bliki/ProjectionalEditing.html
Is gtoolkit the most advanced Projectional Editor or Structure Editor Editor so far?
Nice question.
We were certainly aware of Intentional Programming. And indeed, Glamorous Toolkit does have a language workbench underneath with which we can create editing experiences for various technologies.
But we started from the "reading" part of software engineering not from the "writing". That's because "reading" the system occupies the largest amount of development effort and it's the least optimized activity. Through contextual tools we can improve it manyfold. And this, it turns out, leads to a new way of "writing" as well. We call it Moldable Development.
I honestly saw all the screenshots and still dont understand even in the slightest bit what exactly your product does. Perhaps you picked a bad name or perhaps the copy on the website doesn't do justice to what the product actually does. Since you pasted some python code somewhere as example in one of the screenshots, I ll ask you a very simple question. I have a 50 line python program. I run your tool, what do I see?
Thanks for the question.
You are not supposed to "run" the tool for your program. You start with a question about your program and then build a tool that shows it.
Take a look here at an example of an explanation of a algorithm written in Python (we took Andrej Karpathy's tokenization algorithm): https://x.com/compose/articles/edit/1822723570574688256
If you want more details of how it fits in the larger picture, take a look at chapter 4 of the book I am writing with Simon Wardley about Moldable Development: https://medium.com/feenk/rewilding-software-engineering-a360...
If you have time and inclination to look at these, I'd be interested in feedback.
Maybe this can be made into a mcp agent that was able to create tools that can be called by llm clients...
A couple years ago I spent about 2 hours trying to install this, crawling obscure dependencies, configs, special IDEs, etc before I gave up.
It’s a lot simpler to install nowadays. Just download, install, open the app, and voilà! Tons of self-executing examples are available within the notebook-style windows too.
Hope this helps.
I tried last year. Although the installation instructions were simplified, I couldn't get it to do anything but crash.
I also have little idea what this project does or wants to do. Let's just talk about the homepage, especially the above-the-fold portion.
> "Glamorous Toolkit is the Moldable Development Environment"
So it's some sort of an IDE? What does moldable mean?
> "Make systems explainable through contextual micro tools"
What is a "system" in the context of an IDE? "Contextual micro tools" also sounds completely abstract.
> "Each problem about your system is special. And each problem can be explained through contextual development experiences. Glamorous Toolkit enables you to build such experiences out of micro tools. Thousands of them ... per system. It's called Moldable Development."
... this does not help at all. Just more words without meaning.
Next, there's the video. For somebody with zero context so far, why would they sit through a 46 min low quality video?
tudorgirba - if this is your project, you really need to focus on getting the top half of the page right. People won't watch your video, no one will read your book if you can't give them a hook they understand.
Use words and phrases with concrete and well understood meaning with adjectives:
For example, "Glamorous Toolkit is an IDE for literate programming with first class support for interactive visualizations". If you can't get that sentence right, people just won't invest in learning more about your platform.Project motto:
"Make systems explainable through <unexplainable>contextual micro tools</unexplainable>"
Glamorous Toolkit only claims it can help with making systems explainable.
Making writing in plain English explainable is out of scope :))
It's much better packaged now than n years ago when I stumbled on installation and whatnot and gave up, that's great. If you like me don't like the font size, search the book for how to scale UI, the last snippet on that page show's how to do a global font size change.
Plain Pharo is a really nice environment too.
PSA: if you're watching the video. Get through the first (or fast forward to) 2 min 3s... The audio quality is much improved at this point. At first I wasn't able to watch on 2x speed with all the noise, but at the 2min mark it was much better.
https://m.youtube.com/watch?v=_ztGZpo9I9E&t=2m2s
So .... kind of like iPython notebooks but for building a system?
In a way. It does have a notebook component, but that's just one piece. It's the sum of all pieces that make it a different environment.
From our point of view, the interesting bit is that we show that we can use the idea of contextual tools for every development problem at any abstraction level. That's counter intuitive, but we worked like this for 10 years and we did not find a counter example yet :)
people seem to miss that for technologies like this to succeed, it is not necessary for others to fail. interoperability is (or should be) the most important goal of all software.
the fewer operating systems and environments there are, the lower the incentive to make portability a feature.
OK, so it's like Python notebooks and Smalltalk. so it's like this dynamic thing for transforming data in a rapid feedback, ad hoc, exploratory fly-by-the-seat-of-your pants way. OK. why talk about "capturing domain knowledge" in videos where you're just making a class and sticking a variable in it? what does the class even do anyway if it's just a name with a field that's a bag of data?
It's more like Spacemacs. An opinionated, programmable interface to an operating system that allows you to edit and execute text, browse the web, play git and so on. Just that it has a fleshed out GUI toolkit you interface with, unlike Spacemacs which is heavily text oriented.
With the territory also comes that it's somewhat hard for newcomers to understand why the tool is important to longtime converts. The clear use cases seem mundane. 'You can edit text in it'. 'You can execute code in it'. 'It lets you debug programs'. To which one might respond: 'Yeah, so? Why do I need elisp/Smalltalk? My Electron app already does that and it doesn't come with weird Internet nerds.'
If you get into it and later find that it helped you out to be able to deeply inspect or reprogram your notetaking, program execution, feed reader, git environment, then you'll start to think that it has something special. But that might take a while, and most of the way there you could just as well have used some other tool instead.