5 ms·

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 program

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

koliber 2y ago
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.
mapcars 2y ago
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.
- tudorgirba 2y ago
  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.
- pjmlp 2y ago
  Exactly the same way as using an IDE, their genesis trace back to the various workstation environments at Xerox PARC, Smalltalk, Interlisp-D, Tajo/Xerox Development Environment (XDE) with Mesa, Mesa/Cedar, and their influence in other programming language ecosystems. The way Java IDEs work on their virtual project filesystem mimics a Smalltalk image for example.
  - tudorgirba 2y ago
    Nice point!
photonthug 2y ago
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.
chris_st 2y ago
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!
chris_st 2y ago
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.
- tangentstorm 2y ago
  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 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.
  - tudorgirba 2y ago
    I remember that guest! :)
- tudorgirba 2y ago
  Thank you for the suggestion. We are indeed doing that both publicly and privately. We do learn a lot from this. I very much agree that it is hard to remember the beginner's mind. I also find that a larger challenge is that there isn't a single beginner's mind, but many. When the space is large and there are many paths, people can come from different directions. Finding commonalities seems to be significantly more difficult in that situation. But this still leaves the problem of how to explain it before people work with the environment. The conversations in posts like these are very helpful, for example. I'd be interested in other suggestions that could help with that.

koliber 2y ago

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.

mapcars 2y ago

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.

tudorgirba 2y ago
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.
pjmlp 2y ago
Exactly the same way as using an IDE, their genesis trace back to the various workstation environments at Xerox PARC, Smalltalk, Interlisp-D, Tajo/Xerox Development Environment (XDE) with Mesa, Mesa/Cedar, and their influence in other programming language ecosystems. The way Java IDEs work on their virtual project filesystem mimics a Smalltalk image for example.
- tudorgirba 2y ago
  Nice point!

photonthug 2y ago

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.

chris_st 2y ago

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!

chris_st 2y ago

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.

tangentstorm 2y ago
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 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.
- tudorgirba 2y ago
  I remember that guest! :)
tudorgirba 2y ago
Thank you for the suggestion. We are indeed doing that both publicly and privately. We do learn a lot from this. I very much agree that it is hard to remember the beginner's mind. I also find that a larger challenge is that there isn't a single beginner's mind, but many. When the space is large and there are many paths, people can come from different directions. Finding commonalities seems to be significantly more difficult in that situation. But this still leaves the problem of how to explain it before people work with the environment. The conversations in posts like these are very helpful, for example. I'd be interested in other suggestions that could help with that.