I've been building an editor for plain text where you can also seamlessly insert line drawings. http://akkartik.name/lines.html The link doesn't get into it because I don't expect people coming to the product for the first time to care, but I've paid at least as much attention to making it hackable as usable. Easy to build, uses a platform that is also easy to build, lots of tests in the Mu style if you look inside the source.

Your screenshot reminds me of the thread on Blocks (https://futureofcoding.slack.com/archives/C5U3SEW6A/p1654258083008629). What you have there looks like a prototype for a plain-text version of blocks. Could blocks in the Web world be made as hackable? Probably not. But is there some interesting intermediate?

I went through the install process and I think the technological base layer of LUA + LOVE is really gonna hold this work back. Lots of basic stuff like a caret and copy and paste are missing on the plain text side. Then on the drawing side there is only one tool so no embedded text for instance. Now you could add those things, its early days, it's a prototype etc. but adding those things would be so much work as it would be quicker to rewrite on another system. WDYT? I love the concept but it seems you could start 200 steps into the future if the base layer is switched to a notebook technology like Jupyter, Observable, Notion, and you embed the drawing layer with an off the shelf component like tldraw..com https://twitter.com/tmcw/status/1262608002055434240

Is copy paste not working for you?!

no, CMD + C, CMD + V on mac does not work for me.

You just hit #1 on HN

@Tom Larkworthy Your comment is a perfect illustration of the state of computing today. You are right, of course, but your approach also means giving up hackability, and accepting a ton of dependencies that may well make the project unusable two years from now. If you opt for the easy path in today's computing environments, it almost always implies fragility and incidental complexity.

Yeah, @Konrad Hinsen's right about my motivations. I allude to them briefly in OP. Basically, I'm exploring whether Lua and LÖVE might be a decent "thin waist" of the computing stack if you're willing to make some compromises on features and requirements. I've given up on the hackability of their dependencies like SDL. But once you install SDL and so on, LÖVE is very easy to build. (At least on Linux.) Give me time, @Tom Larkworthy. I have this condition: I'm unable to meet (all the) people where they are, I feel the need to nudge (some of the) people to where I want them to go. My previous two projects were built on machine code and text mode, respectively. Perhaps my next project will be up where everyone else is 🙂 I might even see the Observable light. Switching the shortcuts to

Cmd

is easy to do and I might just make a separate download for that[1]. (Sorry you caught me right before I went to bed last night.) But the other issues you mention at https://news.ycombinator.com/item?id=31637910#31638826 are indeed frustrating. [1] One larger issue here is that the shortcuts for editing text are not very discoverable. For the drawing stuff you can hover on a drawing and hit

ctrl-h

and so on. But there isn't something analogous for text. Partly because I don't know yet where to put it. I don't have an information architecture yet for the canvas, I'm still using it in an indisciplined way as an array of pixels.

@Konrad Hinsen notebooks are good for hackability, Jupyter is open source (BSD). LOVE does not aim for backwards compatibility and the program lines.love is a binary blob, so it is probably gonna cause the fragility in 2 years time you would hope to avoid. @Kartik Agaram OK maybe LUA is enough for what you are hoping to do. I just want to save you time because this particular application seems to beg SVG, but maybe that does not translate to the other things you want to build. Good luck you certainly struck a nerve in people's desire for simple tools which is very interesting and a potential head wind.

lines.love is a zip file containing text Lua source code. Do you consider that a binary blob?! I'm also not sure what you mean that LÖVE does not aim for backwards compatibility: https://love2d.org/forums/viewtopic.php?t=81656#top

Beyond my comment yesterday, I just want to generally +1 the LOVE/Lua approach. After a glorious stint with TI-BASIC, most of my work has been based around plaintext (terminal/Vim/embedded C/Python), and the shifting sands of web/GUI frameworks have been a longtime block on visual experiments. They’re just never fast or flexible enough for the sort of things I want to do (invariably around real-time hardware interaction and visualization) without some major wrestling against text/doc-oriented assumptions. I’m a bit embarrassed I slept on game engines for so long, as they pretty much all have to be built on some habitable sense of physics. Most come with heavyweight game dev assumptions, but LOVE2D is just a lightweight wrapper around SDL2, and LuaJIT has shockingly fast/seamless C interop if needed. I’ve recently moved to the LOVR fork for my own prototyping, which manages to be even lighter weight & a bit more compatible with mainstream graphics workflows. https://lovr.org/

lines.love is a zip file containing text Lua source code. Do you consider that a binary blob?!

I do not! That's great! And now I see your source!

I'm also not sure what you mean that LÖVE does not aim for backwards compatibility: https://love2d.org/forums/viewtopic.php?t=81656#top

that link literally spells out they will not aim for backwards compatibility Anyway, pros and cons. I can now see how LUA + graphics at the system level could be handy, and I do now appreciate LOVE is quite hackable too + fast to develop as you can skip a compile step too, which I am a big fan as well. Thanks for your patience with my questions, I will keep system LUA in mind!

Thanks! I'm not sure I have a leg to persuade you to switch to it or anything like that. All I can do is explain my design constraints and their implications. You have a very rigorous definition of compatibility! I don't think anything on the Javascript side will meet it either. Me, I think good faith attempts to keep minor versions compatible are plenty. Beyond a point compatibility is a ball and chain tying us down to the past.

JS written in 1995 should still run today. As discussed in your link. LOVE code written for 0.8.9 will not run on 0.9.0 This is not an important point but I also like don't want you mistakenly think there is something unachievable about backwards compatibility. But yes I agree the main drawback apart from the extra work is backwards compatible systems like JS and Java just seem to accumulate mistakes which are impossible to flush. [1] https://hemanta.io/backwards-and-forwards-compatibility-in-javascript

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features? And this doesn't take into account all the cross-browser issues that have plagued its history, all the packages in the npm eco-system, etc. Compare pages like https://love2d.org/wiki/11.0 (search for 'deprecat')

@Tom Larkworthy Yes, Jupyter is Open Source. That doesn't make it hackable. It's a huge pile of code, with only small parts of the API documented and stable. A few years ago, I worked on a project involving Jupyter notebooks for reproducible research. We abandoned it because we couldn't keep up with the rate of breaking changes in Jupyter. There were also architectural issues: Jupyter's two-process model (kernel separate from notebook) made it very hard to do what we wanted (keep a reliable log of all code executed in the kernel).

@Kartik Agaram hey sorry i missed this, been turtling. probably the main reason is that i find there to be less artifice in working with GPU shaders, vectors/matrices, binary data for FFI interop, and things of that sort. there are obviously some extra features added as well, but im just using the core events+graphics loop