3 ms·

This has been on my todo list for a while, as I like Simon Wardley, but I've never quite got round to using it. But I use Emacs a lot, and Emacs was the thing t

by tom_ 2y ago

This has been on my todo list for a while, as I like Simon Wardley, but I've never quite got round to using it. But I use Emacs a lot, and Emacs was the thing that sprang to mind when reading the blurb. It looks like there's this similar vibe of making custom tools easy, with there being an expectation that this is something the average user will actually do. Compare and contrast the experience of extending Emacs with, say, writing a Visual Studio Code extension. (N.B., it has not escaped my notice that Visual Studio Code is more popular...) The GUI possibilities of Emacs are a bit limited though. Glamorous Toolkit looks better in that respect. I need to actually try it! Something possibly similar is Studio: https://github.com/studio/studio https://github.com/studio/studio - also Smalltalk. But seemingly dead (or at least sleeping). I encountered this via its author's RaptorJIT project, a fork of LuaJIT apparently intended to turn it into something maintainable by mere mortals: https://github.com/lukego/blog/issues/19 https://github.com/lukego/blog/issues/19 - some videos here: https://www.youtube.com/@lukego/streams https://www.youtube.com/@lukego/streams

nathan_compton 2y ago
With the advent of language models I really despair of new technologies catching on. LLMs are deceptive in their intelligence, as far as I can tell - they can seem expert in one domain and then fail absurdly on some new take on similar ideas that don't appear in the training data. Consequently, one loses a lot of productivity when switching to a fringe technology, even if its better. Startup types used to say that its not enough to be better than the current solution - you have to be 100 times better to justify the switching cost, and with LLMs it seems like that is like 1000x. It sucks.
- tudorgirba 2y ago
  You seem to consider LLMs for their ability to generate code and consider it to be 10x an improvement over not using them. Still, even assuming this is correct (which is not yet anywhere close to being certain), as long as there will be humans deciding what goes into production, decision making will be the bottleneck to address. If people rely on reading, it's too slow. Way too slow. If people only look at the system from outside, they will be making uninformed decisions. Moldable Development offers a different option :)
  - nathan_compton 2y ago
    I think part of your challenge here is that the idea of system exploration kind of applies to almost everything a software engineer or data scientist does and while the demo material makes it clear that you can use Gtk for that kind of thing, its kind of hard to think specifically, at this moment, what one might use it for, because the problem space is so general and it seems like Gtk is maybe also very general, which means there is a little bit of work to apply it to a particular problem right out of the gate. I find myself wanting to talk about this in more detail, but this account is anonymous - could I email you?
    - tudorgirba 2y ago
      Please do feel free to email! Or contact me on social media.
tudorgirba 2y ago
If you look closer at Studio, you might find that its frontend was based on an older version of GT :). Luke did a nice job on it and he learnt the environment by himself when it was rather crude. How you create contextual tools is secondary. Emacs' ability to create extensions is certainly interesting. But here are some questions to consider: - how many contextual tools do you have for your system? 10s, 100s, 1000s? - or, for how many and what kind of questions don't you have contextual tools? and why is that? At the extreme, when practicing Moldable Development, we tend to address dozens of questions per day per developer through contextual tools :)

by tom_ 2y ago

nathan_compton 2y ago

With the advent of language models I really despair of new technologies catching on. LLMs are deceptive in their intelligence, as far as I can tell - they can seem expert in one domain and then fail absurdly on some new take on similar ideas that don't appear in the training data. Consequently, one loses a lot of productivity when switching to a fringe technology, even if its better. Startup types used to say that its not enough to be better than the current solution - you have to be 100 times better to justify the switching cost, and with LLMs it seems like that is like 1000x. It sucks.

tudorgirba 2y ago
You seem to consider LLMs for their ability to generate code and consider it to be 10x an improvement over not using them. Still, even assuming this is correct (which is not yet anywhere close to being certain), as long as there will be humans deciding what goes into production, decision making will be the bottleneck to address. If people rely on reading, it's too slow. Way too slow. If people only look at the system from outside, they will be making uninformed decisions. Moldable Development offers a different option :)
- nathan_compton 2y ago
  I think part of your challenge here is that the idea of system exploration kind of applies to almost everything a software engineer or data scientist does and while the demo material makes it clear that you can use Gtk for that kind of thing, its kind of hard to think specifically, at this moment, what one might use it for, because the problem space is so general and it seems like Gtk is maybe also very general, which means there is a little bit of work to apply it to a particular problem right out of the gate. I find myself wanting to talk about this in more detail, but this account is anonymous - could I email you?
  - tudorgirba 2y ago
    Please do feel free to email! Or contact me on social media.

tudorgirba 2y ago

If you look closer at Studio, you might find that its frontend was based on an older version of GT :). Luke did a nice job on it and he learnt the environment by himself when it was rather crude. How you create contextual tools is secondary. Emacs' ability to create extensions is certainly interesting. But here are some questions to consider: - how many contextual tools do you have for your system? 10s, 100s, 1000s? - or, for how many and what kind of questions don't you have contextual tools? and why is that? At the extreme, when practicing Moldable Development, we tend to address dozens of questions per day per developer through contextual tools :)