It’s time we rethought the text editor. Our editors today are largely the same. Perhaps some are more feature-rich than others, some are lighter weight, but they all fundamental follow the same UI paradigm and support the same activities. Yet these activities only make up a tiny portion of what we as software engineers spend our day doing.

You mean the experience of iteratively modifying programs? As opposed to just text or other forms of data/media, I mean.

This is the project I’ve been thinking about and working on. I currently writing an essay. I have also explored creating an editor from “scratch” and learned a lot in the process. I’m hoping to continue again on that path with some small tweaks to the approach. https://jimmyhmiller.github.io/editor-experience

I see. I gather you want to support the full spectrum of creation from passive media all the way to the reactive behaviors we call code. Right?

Maybe? But I definitely want to focus on your run of the mill programmer. No attempt at end-user programming. No attempt to abstract away code.

have u tried observablehq.com?

@Tom Larkworthy Yeah, I think its cool. But not quite the level of change I think we need. Notebooks are neat and observable’s dataflow is nice. But I’m more interested in building systems and working on existing systems than self-contained small code exploring data. It also is (from what I can tell) mainly a set of pre-defined tools that you use. There doesn't seem to be a way of building up higher level abstractions in the moment and saving and reusing them. That said, there is a lot to learn from observable. They’ve done a good job of marketing and also focusing on getting people to dive in and remix things.

no notebooks are ES6 modules, notebooks are libraries, you can depend on them in external npm package.json if you want. You can build very big abstractions in observable. I made an Oauth server in observable https://observablehq.com/@endpointservices/auth

Yeah, maybe I was a bit unclear. I mean new UI for the notebook itself. New ways of interacting with code. New abstractions for the tool itself, not the application you are building. You can definitely build up applications there.

You can build dataviz to support understanding of an inline systems, which to me is a big step up from the IDE. You could also build a low-code tool if you want, but you have to do it from scratch, but it is possible. Using react sucks though, I am trying to figure out a better workflow for importing react components.

Yeah, definitely a big step up. Just not the step I personally want to take. I want to be able to open a big existing codebase and, in the process of coding it, start building up my own tools for working in that codebase. I think its just a different use case

Is that a meta codebase for browsing a codebase?!

anyway, I am not trying to convert you to observable, just thought your idea of custom tooling, just wanted to make sure you fully appreciated another existing perspective on a FoC topic. I am not entirely sure you understand the customization capabilities of Observable. I write custom tools for programing needs often, here is a notebook used to reverse enigneering the firebase realtime database protocol https://observablehq.com/@tomlarkworthy/rtdb-protocol. It hooks into the firebase client logging output. Having output interleaved with code on a hot code reloading substrate enables you to build tools as you need them, without disturbing program state, and without context switching. Having a ton of dataviz tools nearby enables powerful UIs without much effort

Is that a meta codebase for browsing a codebase?!

well it's not really for browsing, just understanding what is happening, I see it more of an observability tool. But it is very meta because its written in the same environment it profiles. You just import it into whatever notebook you are struggling with and it will give you insights into the reactive runtime evaluation.

You are almost certainly right that I don't fully appreciate what observable enables. I should use it more deeply and for a real program. At the same time you are also pointing out a problem area I know I have, which is articulating what it is I find lacking about notebooks. The examples you linked to are great and definitely give me something to learn from and think about. But they aren't what I'm looking for. I need to spend the time to articulate that more clearly.

@Jimmy Miller You should take a serious look at Glamorous Toolkit (http://gtoolkit.com/) if you haven't done so already. It's probably not exactly what you are aiming for, but I guess there is a lot of overlap. The use case of "I want to be able to open a big existing codebase and, in the process of coding it, start building up my own tools for working in that codebase." is close wo what is discussed in the "software assessment" channel of the Glamorous Toolkit Discord, the main difference being a focus on exploring/analyzing the code rather than producing more of it.

Funny was just gonna quote Tudor https://twitter.com/girba/status/1554789026539999232?t=f9ZYZlaO78c6gLww_S8dZw&s=19

@Konrad Hinsen My current writing has two appendices 1) SmallTalk 2) Notebooks. This definitely reinforces I was right on having those. :) I’ve look at Glamorous Toolkit, but also need to dive in more. It definitely has a lot of overlap with my vision on things. Maybe I just need to dive in, but I’ve always been a bit confused. It says multi-language, but I see all the examples being in smalltalk. When there is code that isn’t smalltalk, it looks like the code is being treated as data. I’m guessing that is what you mean by software assessment. So does the multi-language mean “assess multiple languages” or write in multiple languages? But yeah, completely agree take observable, Glamorous toolkit, and early lighttable demos and mash them all together and you are starting to get something in the same ballpark as what I am looking for.

@Jimmy Miller I guess the confusion comes from the discrepancy between a stated long-term goal (full support for many languages) and the current state of the toolkit (full support for Smalltalk, "read-only" analysis for a few other languages, with partial code editing support in notebooks).

Ahh that makes sense. Thanks. That goal makes it way more appealing to me. Will definitely be spending some time with it :)

So to sum up so far... For existing projects and languages, you @Jimmy Miller want something like a moldable development where you can build throwaway tools in throwaway time. My question then is one of liveness. How much do you want the IDE to work with source/parses vs integration with a runtime/debugger of chosen language?

@wtaysom What I don’t want is walled garden. There should not be one language privileged above the rest. But I definitely want live code execution and integration. I want that integration to really go both directions, the editor knows things about your program, but your program can also affect the editor in a first class way. Admittedly not privileging one language adds some complexity, but I don’t think it is insurmountable. That privilege is one of my problems with both SmallTalk approaches and Observable.

@Jimmy Miller Not privileging any one language is difficult mainly because most languages we have today were designed to be islands. Building bridges between them is hard work and probably not much fun either. The most advanced bridge building infrastructure I know is Graal/Truffle, but it's also the kind of monster code base I wouldn't be happy to depend on. I have seen a demo of TruffleSqueak used as a development environment for Python, which was quite impressive.

I have some ideas. But they are admittedly sketchy right now. Focusing on one language will definitely let you go deeper. I'd be happy with the tradeoff of getting less for any one given language in order to support more. Agree on not relying on graal. I think there are ways of feeling like you have deeper language integration than you do by combining static information (language server protocol) and printf style output with rich graphical support. But I also think there are promises in approach like those taken by things like rr and replay.io. Even ignoring the time travel, capturing systems calls can be very powerful. Very simple example. Imagine you can have a browser devtools network tab like experience for all your languages. There is no technical reason you couldn't do this today. There are a number of different ways to get that kind of information (proxy, sys calls, ebpf, etc).

If all you need/want is a language bridge for user interfacing, then I agree low-level magic like Graal is neither required nor beneficial. But if you want to work on 1 GB data structures in memory from more than one language, I don't see how to get there without a common compiler or runtime to ensure ABI compatibility. Today we consider in-memory interfacing part of a language, but more coarse-grained interfacing (network, files, ...) language-neutral. Maybe this could change...

Yeah my goal is not that all languages can interopt or work on the same data. The goal isn't a bunch of languages at once. I just don't want a language to be privileged for extension of the editor, or the common tooling of the editor. So I can't make my extension system some python or js library you need to call. Extension needs to be data oriented.