Pondering: how important is it for a making environment to be made from the same medium you’re making with if your main goal isn’t making interfaces? The Jupyter ecosystem has come quite far despite relatively few people using it to write JS: https://twitter.com/cmastication/status/1299366037402587137?s=21

I'm not entirely sure what meaning you have for "made from the same medium". If it helps, some of the specific terms of art for making the thing in itself are: meta-circularity (which is where a compiler is written in the language it compiles, like ClojureScript and gcc) and bootstrapping (which is, IIRC, where an interactive system is implemented entirely using things that can be edited from within that system at runtime, like some Smalltalk implementations). I'm going to assume you're referring to that sort of thing, perhaps in a slightly broader sense, which in my mind would include Jupyter being used to edit the same language it's implemented in. As for how important it is — I would say it depends on what the goals of the environment are. It's a tradeoff. Without knowing for sure what sense of "interfaces" you mean (GUIs? FFIs?), there are plenty of good reasons to do it, like the one mentioned in the tweet, or like wanting to prove that the system you're building is expressive enough to express itself (eg: if Jupyter could only handle ASCII, that would be a lack of expressive power needed to be a general JavaScript editor). On the other hand, there are a ton of reasons not to do it — perf, often being the #1 cited reason I've seen, but also simplicity, in that you might not want to spend the effort to make your environment so expressive that it can express itself.

That was PL302 in a four-minute lesson, nicely done

Thanks for the very clear answer in spite of the slightly muddled question @Ivan Reese ! I feel like a big part of why I was drawn to VSCode (from sublime text) was knowing I could write extensions in JS instead of Python. Realizing that not every language/ecosystem aspires/has good ergonomics for used for GUI/editor toolmaking makes me think that if someone wanted to change the Jupyter situation, it may be more efficient trying to get JS devs curious about plugin-making then modifying Jupyter so that plugins could be written using the science scripting languages eg Python/Julia/R.

In the best case, the environment is "made of something you want to make with" and is completely interactive. The biggest failing of projects like Atom and VSCode is that although they run inside a live environment they do not provide a REPL that allows code execution in the context of the editor itself. This makes plugin development a static compile-test-run sort of affair rather than an interactive "build up from small pieces" experience.

Sort of ruins the fun.

I hate to bring up the tired old distinction of "product vs process", but let me see if it has new life in this context. Is self-bootstrapping important? Is the software at hand supposed to be a concrete product providing a reliable experience, or is it a fluid process for experimenting toward experiences we haven't imagined yet? In "The Computer Revolution Hasn't Happened Yet", Alan Kay talked about Squeak as a tool to help you build the next version of itself. In contrast, he says that commercial Smalltalk didn't change much once it was released. It's difficult to build software products with a moving foundation. I think there's a fundamental tension between (r)evolutionary software-as-process and commercial software-as-product. The balance between progress and stability is tough to strike. On a different note, one thing I like about self-bootstrapping systems is the conceptual unity. Once you "get it", you get a LOT. That's one reason I too jumped to VSCode--writing plugins using the same tech those plugins are supposed to work with reduced cognitive load. But then I got annoyed with VSCode because of the compile-test-run cycle. VSCode is a product, not a process. There is an essential staticness to it. You can't tinker with it to create something fundamentally other than what it is. That's why I started experimenting with a self-bootstrapping JS editor. Ideally, application development and editor live-tinkering should be the same fundamental process. Ideally, I think end-user development abstractions should be built directly on top of developer constructs (e.g., hadron.app). I think self-bootstrapping, if taken to its limit, offers the chance to build a deep ubiquitous language for communication between users and developers in building pliable software.

"How important..." for reaching which goal? Jupyter is a development environment like most others, in that it is a tool designed by tool designed for end users who are not supposed to modify it. So the toolchain used for Jupyter development is something Jupyter users don't care much about - otherwise they probably wouldn't use Jupyter. Personally, I find tools that I can adapt myself much more empowering, and for reaching that goal it helps a lot to have a single medium. But such tools are rare, most people have never experienced one, and so they are not asking for it.

@Cameron King The thing you're feeling here is why I've been using emacs for 35 years. While it's easy for me to imagine a new (especially more graphically capable) environment built around some language I like more than elisp, such a thing would absolutely need to be "emacsy" in this sense.

@Jack Rusher Same for me. My biggest hope for a worthy successor to Emacs is https://gtoolkit.com/. It addresses what is for me the biggest limitation of Emacs: the lack of graphics.

@Konrad Hinsen I also really like Glamorous Toolkit. It's always good to see any system that embraces the old Smalltalk/D-Lisp philosophy of interaction and malleability! 🙂