Wouter van Oortmerssen

This is great, and I'll definitely be playing with this tomorrow.

I also can't seem to stop myself going off half-cocked and writing language interpreters[1][2] and virtual machines[3]. It's really quite addictive, and gives you a "I really made something" feeling that a new backup script or CRUD app doesn't quite provide.

I too actually started off writing a stack/RPN-style language for the exact reason that I didn't want to do a proper parser, but then realized that, for properly recursive structures like in Joy[4], it really makes it easier to just write a parser. And it turns out that a recursive descent parser really isn't that difficult, conceptually, once you spend the brain-time to work one out yourself[5]. Like most things programmatic, it's tough to wrap your mind around until you've done it once, then it's just a matter a typing and bugfixing.

Along with the aforementioned Joy (which is a stunningly elegant language), some other languages I find inspiring are rhoScript (http://www.rhoscript.com/), Pico Lisp (http://picolisp.com/wiki/?home), and the very clever WadC editor (http://strlen.com/wadc-editor), which implements a DSL and interactive environment for describing Doom levels in code, rather than by dragging vertices in a purely graphical editor (This isn't as crazy as it sounds if you're unfamiliar with the limitations of Doom levels, since they are constrained to certain types of simplified geometry that lend themselves well to this).

In short, keep it…

Changing jobs in 2005 caused me to switch from taking notes on paper to doing it electronically.

My new employer provided a tablet PC with a stylus running Windows and [OneNote](https://products.office.com/en-US/onenote). Taking notes on that system with excellent handwriting recognition was a revelation. The tablet was pretty clunky by today's standards, but it worked well. It was particularly useful for generating meeting notes in real time and projecting them during meetings.

After moving to another employer, I no longer had access to such a tablet but used [TiddlyWiki](https://tiddlywiki.com) to keep my notes. It was great until the number of notes became large (in the thousands).

After that, I became an early adopter of [Evernote](https://evernote.com). It was an adequate note-taking app, but the killer feature for me was searching for text in images. At that time, we put meeting notes up on a whiteboard. After the meeting, I could take a picture of the whiteboard, insert it in Evernote, and search it any time after that. I maintained a subscription to Evernote until the end of 2016 until they got squirrely about their subscriptions and some privacy issues.

After several years absence, I went back to TiddlyWiki. It was very much improved. But after importing thousands of notes, it became too slow at editing. The search was on for another system.

I looked at several open-source tools under active development:

* [TreeSheets](http://strlen.com/treesheets/) has been…

He must be referring to https://dl.acm.org/doi/pdf/10.1145/2935323.2935331 ?

Just looking at refs for the moment: Henglein and Hinze's discriminators are interesting, whenever you come back up for air. (are they also amenable to sorting codata?)

The oft-cited R Bernecky is, IIRC, also known as "Boolean Bob" for his SWAR-style algos. EDIT: nope, confused him with R Smith: https://aplwiki.com/wiki/Bob_Smith

(I once asked Boolean Bob if any of his tricks went back to the card processing days —I could even believe the keyed tree* might?— but he was too young to know, and the people he'd have liked to ask are no longer available.)

EDIT: Aardappel also has some interesting languages: https://strlen.com/#programming-languages

* for manipulating Bills of Materials despite the linearity of card decks?

EDIT2: compare "§3.2.1 Constructing Node Coordinates" (p34) with [T in "Table 1.19 Full list matrices of the tree of Fig. 1.16" in A Programming Language (p50): https://archive.org/details/aprogramminglanguage1962/page/n66/mode/1up

Fc 1 0 0 0 0 1 1 0 0 0 1 1 1 0 0 1 1 1 1 0 1 1 1 1 1 1 1 1 1 2 1 1 1 1 3 1 1 2 0 0 1 1 2 2 0 Ec 1 0 0 1 1 0 1 1 1 1 1 2 1 1 3 1 2 0 1 3 0 1 3 4 1 3 5 1 3 6 [all three appear to be 1-origin, probably due to the phenomenon mentioned in the footnote on p49 of APL]

I think the future is in languages that offer "opt-in" borrow checking, so you can use it where it makes sense. After all, most of a program should prefer simplicity over performance, and only optimize where it matters. I think this is the path towards a more Pythonic Rust.

Some languages that are going this direction, including D [0] and Vale [1]. Vale's particular insight is that we can get the benefits of borrow checking with isolates (from Pony) and integrating "pure blocks" and pure functions into the type system, so to speak.

> ... breaks ownership is automatically transformed in a reference counted object ...

Some languages actually do this! Lobster [2] uses borrow-checker-like semantics and falls back on reference counting. And worth mentioning is HVM [3], which falls back to cloning.

[0] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

[1] https://verdagon.dev/blog/zero-cost-memory-safety-regions-part-1-immutable-borrowing

[2] https://www.strlen.com/lobster/

[3] https://github.com/HigherOrderCO/HVM

It reminds me of the False programming language (http://strlen.com/false-language), versions of which I've implemented on small micros I've worked on for similar purposes. False is a tiny but fairly powerful stack-based language the author originally implemented a compiler for in 1024 bytes of 68k machine code. False pulls some great ideas from Forth and (anachronistically) Factor.

Perhaps it's because of the AT90USB162's RAM restrictions (512 bytes), but it seems having a "stack" of just one item and non-nestable loops is pretty restrictive. Oh, and no + - * / operators.

I don't think adding nestable loops and a stack of say 5 items (10 bytes of RAM) and math operators would hurt much, and it'd certainly add to the power of a language like this -- perhaps changing it from a tiny debugging tool to a useful "scripting" language.

Want to see what happens falls too much in love with DRY? He invents an "automatic refactoring system" that automatically DRY-ifies a whole program: http://strlen.com/restructor/ (not that great an idea in hind-sight, as the page explains).

Interesting to see all the comments here that make it seem obvious that "fanatic DRY" is bad. Historically, there was a wave of OO love where a lot of people went crazy with wrapping every program element in deep layered class hierarchies. DRY (and OAOO, YAGNI etc) was maybe a backlash to that, and some go too far with it. Now we all seem in love with "leave the redundancy in the code", which is another backlash. What's the next backlash? Maybe we'll finally focus on how to balance these factors rather than seeing some extreme as the silver bullet?