Title
#share-your-work
Kartik Agaram

Kartik Agaram

06/05/2022, 5:46 PM
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.
❤️ 14
Konrad Hinsen

Konrad Hinsen

06/06/2022, 6:54 AM
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?
💡 1
Tom Larkworthy

Tom Larkworthy

06/06/2022, 7:08 AM
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
❤️ 1
Kartik Agaram

Kartik Agaram

06/06/2022, 8:18 AM
Is copy paste not working for you?!
Tom Larkworthy

Tom Larkworthy

06/06/2022, 8:22 AM
no, CMD + C, CMD + V on mac does not work for me.
8:22 AM
ok I see, it works with CTRL which is the wrong button for mac
8:26 AM
ok yeah great, I can CTRL + C to copy from your program, then CMD + V to paste it into slack, so its using system clipboard and its just the shortcuts are wonky.
Chris Knott

Chris Knott

06/06/2022, 9:37 AM
You just hit #1 on HN
🔥 2
Konrad Hinsen

Konrad Hinsen

06/06/2022, 11:53 AM
@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.
Kartik Agaram

Kartik Agaram

06/06/2022, 2:13 PM
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.
🍰 2
Tom Larkworthy

Tom Larkworthy

06/06/2022, 6:56 PM
@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.
Kartik Agaram

Kartik Agaram

06/06/2022, 7:20 PM
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
daltonb

daltonb

06/06/2022, 8:15 PM
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/
❤️ 1
Tom Larkworthy

Tom Larkworthy

06/06/2022, 10:29 PM
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!
Kartik Agaram

Kartik Agaram

06/06/2022, 10:39 PM
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.
Tom Larkworthy

Tom Larkworthy

06/06/2022, 10:56 PM
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
Kartik Agaram

Kartik Agaram

06/07/2022, 1:54 AM
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')
2:08 AM
I take that back. The 'other changes' section also lists incompatibilities. The color values one in particular has bitten me in the past: https://merveilles.town/@akkartik/108088992493918033 Retreating to Konrad's original comment, I think compatibility guarantees are a poor way to try to keep a system running. If it's truly hackable, incompatibilties should be minor obstacles.
2:10 AM
@daltonb I'm curious how you evaluated that LOVR is more lightweight than LÖVE.
Konrad Hinsen

Konrad Hinsen

06/07/2022, 6:52 AM
@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).
🤔 2
6:54 AM
Workin in the notebook is a different story, of course, and I guess that's what you were mainly suggesting. But it's not that much better. All graphics output in Jupyter is done via widgets, which require learning a language and ecosystem different from what is used in the notebook. Plus widgets are much more exposed to changes in the Jupyter API.
6:57 AM
Generalizing a bit, Jupyter is quite typical for a product developed by a large but weakly structured community. Conway's law explains how this affects the code structure. There are two situations in which you can use Jupyter productively: as an "end user" with a profile closely corresponding to the Jupyter team's target profile, or as a tool developer integrated with the Jupyter community. Jupyter is hackable only for the second category.
🤔 2
6:58 AM
I don't know enough about @Kartik Agaram’s Lua + Löve ecosystem to compare, but I'd expect it to be rather different.
daltonb

daltonb

06/29/2022, 5:39 PM
@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