Has anyone heard of stack people vs queue people? I don't know where I got it from, but it's been an enduring part of my self-image for a decade now that I'm a stack person.
When something new pops up, a queue continues what they were doing. A stack switches.
Obviously this is a spectrum, but I find it very easy to rationalize that the new tasks are "quick".
Anyway, being a stack is hard with a new project. Every 2 minutes I discover something broken, and now I have to resist working on it.
A minimalist DOM in 50 LoC
Notation:
Implementation:
Render:
Is there a better name for this than "DOM"? A notation for a tree of rectangles, often containing text, to be rendered to screen and united with mouse events.
Rects contain either text or rows/cols of other rects. Other attributes: fg, bg, margin. Margin is margin-top or margin-left depending on whether the rect contains rows or cols.
No inline styling yet (bold, span, etc.), that feels like a separate concern.
This is pretty surprising. (And pretty.) I'm trying to understand why my app goes unresponsive sometimes, so I added a debug dashboard. The top graph shows the memory footprint every second. The bottom shows memory footprint every 10s.
Does it make sense why the top graph when averaged 10x yields the bottom?! Sure doesn't to me.
I'm realizing Pensieve's surface doesn't actually give a good sense of space like say Capstone.
I just spent some time trying to add hyperlinks between a handful of pairs of notes. The notes are seldom next to each other for me to type the id of one into the other.
Then I realized I should just use regular links below notes. The grab mechanism works well. Links can't be inside notes like hyperlinks, but I can't linkify arbitrary text anyway. And I get automatic backlinks.
Research is awesome, but sometimes when you read a paper you just want to add it to your toolbox right now. In a way that fits in with your other tools.
Properties of my tools:
minimal dependencies (no browser!)
cross-platform; runs on Windows
easy for anyone to modify (https://www.inkandswitch.com/end-user-programming)
live; modify without restarting (https://www.youtube.com/watch?v=8Ab3ArE8W3s)
✅ Edit source code from within the app
✅ Edit source code for source code editor from within the app
✅ Create graphical debug experiences for source code editor from within the app
Debugger: a graphical log of what the program did, as demonstrated here.
These tools aren't general-purpose. Instead, they're intended to evolve with the sole app they're used to modify: themselves.
Today I went through and gave every fork of lines.love the ability to modify and debug its own source code. Just press ctrl+e to edit the sources.
It's kinda funny to add a code editor to a text editor. The code editor can hide debug prints, and has a teeny bit of colorization. On the other hand it doesn't (yet) support drawings or selecting text.
Here's the final demo of the project I did for last week's Wheel Reinvention Jam: rethinking development tools to center debug by print. I think you can replace the benefits of debuggers and save on a bunch of complexity in language infrastructure and tooling.
Incredibly inefficient, to check the file system for every single word. So it's in a fork for now while I decide just what to do with this new super power.
It's interesting to compare this approach with Gemini.
Gemini: links on their own line, support arbitrary link text.
Me: inline links are ok, but the text will always be the URL.
As preparation for tomorrow's wheel reinvention jam, I just created a fork of lines.love with all the drawing support ripped out. Time to take it in a new direction.
