Get your ducks in a row

Duck typing

Rubber ducking

Duck programming

Messaging notifications

Funny that we're hoping to soon build programs that can think like people, but we can't build group text messaging that doesn't suck.

We need a few simple features, each related to the previous:

1) Notify a group of people regarding the start of a conversation, but not each subsequent message in the conversation.

2) Show at a glance if there are unread messages of genuine interest. So allow easily dismissing a whole conversation.

3) Dismissing on your phone should dismiss on your computer and vice versa.

I have a sense of why the feature 1 is hard: people aren't good at selecting threads of conversation. There are three remedies:

• make the UI more clear, perhaps automatically labeling each thread with an automatically generated subject
• make it possible to change the thread that a message is in, after the message was already "sent"
• changing the thread is too late for sounds triggered by notifications, but they could update the "keep up-to-date" style interface of feature 2 above. 
• if notifications are actually working like they should, people will be more motivated to get the thread right in order to get the notification right.

Nostr

Nostr is a really lovely development in social networking. It's certainly not ready for people who don't have dedicated followings, but it's almost already a good additional place to publish. It's simple! I'm jealous; I was trying to come up with something like this.

Otherwise, I just want to mention a couple of points regarding "incentives" to run a nostr server (which they call a "relay", and for which the mandatory functionality is quite simple). It's kind of funny that in the README Fiatjaf doesn't really answer the question about why you might want to run a server. Here's a few possibilities, besides just thinking it's cool:

• the obvious incentive: you want to give particular people a platform.
• even with just the mandatory functionality, users can query for all the posts related to a post. Servers can promote some of those posts over others.
• only servers can see the level of interest for different authors, topics, etc, by logging the requests that they get.

Amazon front page search

Amazon should set the focus to the search field on their front page, so that you can immediately start typing when you hit the page.

I'll bet it's because nobody could demonstrate that it would make them more money.

Google scholar

Google scholar should be in the "⋮ More" menu.

Crowdsourcing programming language

With the embarrassment of riches in the low level programming language space (Zig, Jai, Odin, Beef, V, Jakt, Val, Rust?), I was thinking about what the next high level programming language might look like...

It's got to be open source and have super support for the web. IMHO it should support regular programming as well as interactive (i.e. shell) use. It ought to be fully reactive!

Simply, "reactivity" makes programming more like spreadsheets. Though the flapjax project did this with javascript many years ago, all the hot new javascript frameworks are finally adopting this kind of approach (svelte, solidjs, vue). It's good for GUIs, and it could be great for programming in the general. Imagine View Source for all of programming!

As long as we're talking "high level", it could have all sorts of cool features thrown in, like transparent persistence, CALM consistency support, easily querying JSON and other formats. Implementing features takes a lot of engineering effort however. That's a big lesson from Zig's increasing success: engineering matters a lot. Tangentially, here're a few links in praise of Zig engineering:

• It compiles c better than traditional c compilers do, for a while now actually.
• It's easier to debug than c++, in nerdy ways.
• It will be able to do fancy fast compilation, by virtue of careful use of its complexity budget. If you're curious, see here.

Unfortunately, I have the first virtue of great programmers, so won't muster the necessary engineering myself. That could be the major feature of the next high level language: a notebook/IDE/repl that supports inline extension of itself, and sharing of extensions!

Querying JSON

The state of the art in querying JSON outside of a full program:

• simple, specified, multipy-implemented: jsonpath
• more powerful: jq
• more interactive: fx
• for UNIX afficionados: gron
• which might make you ask how to grep across lines

Lisp Disappointment

Once, I was really excited about "code as data". If you enjoy the power of code, you should love code that works on code, right?

Problem is, almost anything interesting about code working on code isn't about syntax.

Compilers have been optimizing code forever, and there's no indication that it's any easier to optimize lisp.

Static types help to reason about, navigate, and refactor code, and those are not part of traditional lisp. The same goes for referential transparency.

And bidirectional programming provides other amenities that having nothing to do with lisp.

Peer to peer social

Of the communication modes discussed in the previous post, "perusal" is the one that needs the most love right now. We're talking Twitter territory, so this post is timely. Remember "perusal" refers to communication which is both asynchronous and involves broadcasting to many people.

The wonderful thing about Twitter is that, when you read^a something interesting anywhere, you can speak directly to the author about it on Twitter, and they'll respond, as often as not. This feature springs from the famous social media "network effect"; Twitter is where all the authors hang out now, so it's where everyone goes to talk to authors, creating a self-reinforcing cycle. People say that only a paradigm shift can beat an existing network. If new competitors try to compete on features, they'll get squashed by the existing network, which can relatively easily copy those features.

So let's talk about what peer to peer social might look like. That is, a system for perusal-type communication which doesn't depend on any central authority. People agree this is a hard problem. So we'll talk about it in avowedly handwavy manner.

1) It should be http based. Among other advantages, this will help with ramp up and network effects: even before our system takes over the world, its posts will be no worse than blog entries.

2) Its scope should include direct messaging, partly because that'd be nice to have too, but mostly because we can use the relationships between people to bootstrap some kind of trust graph. Much of the social graph is already available in people's phone's Contacts app.

3) It'll have two different roles in the system, which I'll uncreatively refer to as "people" and "servers"^b. Both roles have public-private key pairs. People's apps record each others' public keys, so the system is local first that way. I don't need Facebook to manage my electronic contact for my brother. His app signs his posts, so any server can send them to me, and I'll know that they're really from him.^c

Even for perusal, I don't really need Facebook fanciness to highly rank posts from my brother, or from my favorite musician. It's now easy to communicate with anybody in the world; the hard part is preventing enough of that communication to keep it useful.

4) So servers differentiate by recommending new posts that people want to read, that is, posts from strangers. Continuing the spirit of search engine and social media companies, there's a tension between what I want to read, and what other people want me to read. "Advertising" is when intermediaries get paid to sacrifice the former for the latter. If people know the public keys of all the people that they're already interested in, and those keys are used to sign all posts, there's no longer any robust way to insert advertising into those posts. The natural place for advertising then becomes the feed of new recommended posts.

5) People's apps should employ multiple servers. People can rate posts, and those ratings will be automatically shared and used to pick the best servers, forming a kind of market place for servers. Depending on how expensive it is to run a server, the market will efficiently price the fraction of the recommendations that will be advertising. Now we're really getting handwavy. Who says this can work? Well, we can talk about it more; first let's finish the sketch. :)

6) We also need to support a way for ratings to flow from readers to publishers. Partly because this is something that publishers like, but it needs to be supported natively so that servers can demonstrate to advertisers how effective they are. It's the trust graph which defeats sybil attacks. Attackers can create as many fake people as they like, and those won't matter because the rest of the world doesn't connect to them.

7) So everybody's rating everything, does that mean that all ratings have to be copied everywhere? Distributed consensus and trust algorithms appear to assume so. And of course, there's blockchain. But I hope we can do better. We don't need any of this to be precise, we just need it to more expensive for spammers to game the system than it would be for them to simply run a competing server. Therefore, we ought to have a protocol that enables participants to exchange ratings in a sparse, just in time fashion. We're talking about a kind of guerilla PageRank. Unfortunately, the term "gossip protocol" is already taken, so once we actually figure out his protocol, we'll need a new catchy term for it.

OK, that's about enough speculation for now. There are some major ideas that'll I'd like to talk about in the future: How do we support decentralized topics or groups? How can multiple independent parties evolve the software and the protocol? And of course, how would all of this effort make a system much better than existing centralized networks?

---

a When I say "read", I mean "read, listen to, watch, or otherwise experience".^↩
b Once I say "server", many readers will immediately think "oh, that's federated, not peer to peer". Well I'm still hoping this'll be a bit more dynamic than your typical federated system like email. We'll see :).^↩
c There are a lot of details to get right here, for example post-compromise security ^↩

Communication modes

Nobody answers the phone anymore. 😁

Seriously, nowadays there are three distinct modes of communication:

	Synchronous	One to one
Waiting for your call	yes	yes
Direct messaging	no	yes
Perusal	no	no

"Waiting for your call" means picking up or responding immediately. Nowadays it's restricted to: enjoying real conversations, getting to know somebody, when you're paid to be available, and failures of direct messaging.

"Direct messaging" means that somebody sent a message just to you. I believe the etiquette is that these deserve some response within a day or so, lacking any other clear time constraints. Assuming you're not famous.

Of course asynchronous messaging tools can also be used for synchronous communication. The three dots that indicate the other part is "typing" help distinguish a little.

What we want for "perusal" is a ranked list of items that we can check as infrequently as we want. The things that we are most likely to want should be at the top. Timeliness could certainly be a factor.

From the technical point of view, we want this stuff to be more standardized and unified. For example, it'd be nice to initiate a message to somebody from their Contact in my phone, via Whatsapp because that's their favorite, without me having to remember it. It'd also be nice to have a conversation with two friends at the same time without having to think about compatibility.

We also want our communication to be local first software, and that's what the next post is about.

Zig open interfaces issues

The vibe is that zig will not have native dynamic dispatch support.

That said, there are a few niggles to close out:

• What is the standard pattern for doing that sort of thing?
• Will comptime ducktyping be improved?

SBE Repeating Group Gotchas

SBE is the fastest off-the-shelf way to serialize data.

To help support that, it really prefers you to use fixed length fields. If you need an unknown number of submessages, it's a littler harder...

1. There is very little documentation in general, and for repeating groups it's incomplete. A big omission: you must always explicitly decode every member of every repeating group, in the same order as they are defined in your schema. If you do not do this, your results could be mysteriously corrupted. Alternatively, you could explicitly "skip" the ones you are not interested in, with the relatively new sbeSkip() call. E.g.
   

          
           weWantSerialNumber(carDecoder.serialNumber());
           weWantModelYear(carDecoder.modelYear());
           FuelFiguresDecoder fuelFigures = fuelFigures(); //we don't want fuelfigures

           if (fuelFigures.count() > 0)                    //but if it was encoded...

           {                                               //we must iterate over it anyway

               while (fuelFigures.hasNext())

               {

                   fuelFigures.next();

                   fuelFigures.sbeSkip();

               }

           }
   

           PerformanceFiguresDecoder performanceFigures = performanceFigures();

           if (performanceFigures.count() > 0)

           {

               while (performanceFigures.hasNext())

               {

                   performanceFigures.next();

                   weWantOctaneRating(performanceFigures.octaneRating());
                   performanceFigures.sbeSkip(); //actually needed in the sample

               }                                 //because there's a nested repeating group!

           }
   
   

2. If you're working with code that does not use repeating groups, and you add one, lots of things might break unexpectedly. Because wrapping a decoder with an incorrect blockLength will mostly work if you don't need to decode repeating groups or variable length data fields. You need to use the blockLength on a header message, which in turn needs to be the BLOCK_LENGTH of the encoder. This excludes the length of the repeating groups. On the bright side, nowadays there are wrapAndApplyHeader() convenience methods on both the encoder and decoder objects. 
3. If you want to read repeating groups from the same decoder more than once, you need to call sbeRewind().
4. There's currently a bug in which toString can break repeating groups

Bookmarks and Full Text Search

Bookmarks suck. They don't have to.

They suck because they don't actually work for their primary use cases:

1. where did I read about that cool thing X? 

2. where was that cool article about Y that I didn't have to time to read, but would like to read now?

Heck, at some point I found it easier to google for pages instead of trying to find them in my bookmarks. 

Other use cases should be handled slightly differently:

3. "Bookmarks Bar", "Pin a tab", and "Save a shortcut" features are all useful for commonly-used pages or web apps.

4. "Manage Search Engines" feature is useful for sites that you want to search often.

4. I'll bet Chrome soon adds support for saving tab groups, which will be useful for gathering lots of pages for a particular project, e.g. a bibliography.

Practically speaking, labels and categorization are annoying to add, and don't really help find things later. The titles that maintainers give to web pages are also often unhelpful for retrieval.

The solution is automatic full text search of all bookmarked pages.

That way, you can retrieve a page by anything that you see on the page, without any additional organizational work.

On a Mac, you can get already get this via Spotlight and print with "Save to PDF", though there's some user interaction involved.

Worldbrain's Memex supports full text search of bookmarks well, and for free. I have mixed feelings about it. On the one hand, this feature is implemented by an open source plugin, and the maintainers support local first software. On the other hand, they have a much bigger vision, and it's unclear how much they want to support the free part of it. It currently sports a non-dismissible reddish prompt to register for the cloud support.

Probably I'm Dunning Krugering, but it just doesn't seem like that difficult of a feature to implement. And it feels like a core service. I wonder how Apple and Google might decide to take on a feature like this. There's no reason to end on a low note. If you don't care about sync-ing across your devices, go ahead and install free Memex on your PC, and on your tablet!

iPhone Shul Shush

 Now it's finally possible to silence iPhones in shul (or church or whatever)!

1. Settings / Focus / Do Not Disturb / Add Schedule or Automation / Location
2. enter something to identify your shul, e.g. part of the name
3. select the right one
4. touch Done

Woo!

Now if only there were a way to automatically prompt people to do this when they arrive, using something like airdrop. "This location wants you to be in Do Not Disturb. Is that alright? Yes - silence notifications here, No - continue to notify me and don't ask again, I Don't Know - ask me next time I visit"

Vim plugin idea

When working with verbose logs, you want to suppress uninteresting lines.

So, wouldn't it be cool if you could select two lines, and vim would hide all lines that are similar to them.

1237 boring is blah, all good

1238 boring is foo, all good

1238 WARNING

1240 boring is blah, again

When the user selects the first two lines above, vim would hide lines matching the pattern \d+ boring is \w+, all good.

It'd need the ability to unhide the next or previous line.

We could also get fancy, and support generalizing previous patterns. In the example above, you could later choose the fourth line, and vim would amend the previous pattern to \d+ boring is \w+, [ a-z]*. We'd have to document some decisions about how general to be, e.g. it's not obvious above that we should use \d+ instead of 123\d.

Closest existing thing I could find: https://www.vim.org/scripts/script.php?script_id=2302

Scrolling two files curmudgeonry

It's useful to be able to synchronize scrolling through two files, especially for comparing two files that have too many intraline differences.

Vim supports this, with this annoying incantation:

vim -O oneFile anotherFile -c "windo set scrollbind" -c "windo set scrollopt+=hor" -c "windo set nowrap" -c "windo set cursorbind"

Switch between the windows with: ctrl-w ctrl-w

Nowrap is useful because otherwise different sized lines don't display nicely.

Other annoying things: 

• The documentation can't decide what this feature is called, scroll binding or scrolling synchronously.
• Gvim doesn't seem to support cursorbind.

Though maybe vimdiff is actually better for most similar use cases. It gets the defaults right, and with gvim it seems to get cursorbind right too.

Toki Pona

Toki Pona is a supremely simple constructed language. It's a real Newspeak (from Orwell's 1984), but for good and not evil.

It's very cool. Unfortunately nobody seems to seriously use it for international collaboration. (Apparently this is called auxlang, and obviously English right now is it.)

I was initially grumpy about the "pre-verb" part of speech, but now I believe it's consistent with the general rule that a word modifies its preceding word. For example, a noun precedes its adjectives, and a verb precedes its adverb. So: mi ken pali ==  I can work. mi wile e ken pali == I want the ability to work.

Nullaway @Initializer

Nullaway is the currently most practical solution to the billion dollar mistake.

Its @Initializer annotation is one of its practical features; if an object is not expected to be used until one of its methods in executed, that method can be annotated. Then fields can still be statically guaranteed to be non-null if they are initialized in that method, even if they are not initialized earlier.

Nullaway does not, however, statically guarantee that @Initializer methods are actually executed. Therefore, it's better to initialize non-nullable fields in a constructor.

Poor Man's Projectional Editing

Projectional Editing is programming that goes beyond simple text entry. Notable projects are Lamdu and Jetbrain's MPS and to some extent Intellij itself.

Historically, programmers have been reluctant to stray too far from textual programming. A good compromise approach is to represent language features both textually and graphically. For example, the exponents in LegibleMathematics are both superscripted and ^ prefixed.

We could support the property of always keeping the program valid, and still give the feel of textual editing:

1. as the user types, insert code to make the program valid
   e.g. if the user types if, then we'll insert (true) {}
   
   
2. in the inserted code, automatically select the next bit that isn't forced, to clarify that it will be replaced as the user types
   e.g. in the case of inserted (true) {}, we'll select the (true)
   
   
3. in general, whenever the user types the same thing as the next required bit, just advance the insertion point over it
   e.g. in some existing code if (x) { y(); } the user clicks before the semicolon and types ; }, we won't change anything at all, and just advance the insertion point to after the }
   
   If we want to support whitespace, then we could change the traversed text to use the new whitespace that the user types.

The above behavior enables the user to just obliviously type brand new code and have it work like in a traditional editor.

The third point is inspired by Parinfer, and Parinfer also has an idea for editing existing code. Inserting a brace somewhere automatically removes the following brace, and removing a brace will insert one as late as possible. e.g.

void f() {
    if (foo) {

        bar();

        baz();

    }
    qux();
    quux();

}

Removing the } after baz() will automatically insert one after quux().

Inserting } after bar() will automatically remove the other } in the function.

Of course we want tab completion, and once we have that and the above, we don't have to worry about intermediate invalid edits. In languages with stronger types than java, it could be that there isn't necessarily any automatically choosable value, in which case we'd have to use typed holes. In mainstream languages, we could use null at the worst.

It's nice to default to a value that causes the new code to essentially be an identity function, e.g. if the user types + then we'll append 0. If the user types * then we'll append 1. But of course this isn't always possible.

Changing a symbol usage changes just that one usage. Changing a symbol at its definition (or initialization in python for example), instead refactors the symbol and renames all of its usages. Changing a signature to remove parameters just updates all usages to not supply those parameters. Changing a signature to add parameters updates all usages to supply a default value as above.

Lastly, with this approach we can be very clever about cut & paste. A "cut" which would involve an invalid program is no trouble; when the "paste" comes, we can do the appropriate refactoring. In the example function above, if the user cuts the baz() call, and pastes it outside the function, we can automatically change the code to:

void f() {

    if (foo) {

        bar();

        g();

    }

    qux();

    quux();

}

void g() {

    baz();

}

And of course select the new function name g so that it can be easily changed. And some pastes would be illegal, e.g. pasting qux(); quux() in place of foo.

So, this "always valid" approach is very nice for refactoring. Its main benefit however is to enable powerful live coding, e.g. devcards.

Git gotcha

Since the rise of github, most teams build software using a pull request workflow. Therefore the local "master" branch is a bit of a gotcha. You can commit to it, but that will only ever cause you grief. That is, you'll forget about those commits, and they'll eventually cause a conflict, and you'll get something mysteriously broken when you just want "master". Fix it with this:

       
            git branch -D master
            git branch master origin/master
       
 

And actually consider not having a local master at all, and always using origin/master instead.