sidedishes

This is very nice! Someone I know made one of these too a while back with a similar UI - https://gkpotter.com/projects/rgb/

Robert McKee's book 'Story' has a wondrous second part to the poem. I look up it to whenever hit with this dilemma.

(First, a retelling of the original)

High above the forest floor, a millipede strolled along the branch of a tree, her thousand pairs of legs swinging in an easy gait. From the tree top, song birds looked down, fascinated by the synchronization of the millipede's stride. “That's an amazing talent,” chirped the songbirds. “You have more limbs than we can count. How do you do it?” And for the first time in her life the millipede thought about this. “Yes,” she wondered, “how do I do what I do?” As she turned to look back, her bristling legs suddenly ran into one another and tangled like vines of ivy. The songbirds laughed as the millipede, in a panic of confusion, twisted herself into a knot and fell to the earth below.

(The second part)

On the forest floor, the millipede, realizing that only her pride was hurt, slowly, carefully, limb by limb, unraveled herself. With patience and hard work, she studied and flexed and tested her appendages, until she was able to stand and walk. What was once instinct became knowledge. She realized she didn’t have to move at her old, slow, rote pace. She could amble, strut, prance, even run and jump. Then, as never before, she listened to the symphony of the songbirds and let music touch her heart. Now in perfect command of thousands of talented legs, she gathered courage and, with a style of her own, danced and danced a dazzling dance that astonished all the creatures of her world.

A similar question was asked in the milkytracker thread too! Check out BassoonTracker. https://github.com/steffest/BassoonTracker

Bassoon tracker is really well made and fits the bill (though not with WASM I believe): https://github.com/steffest/BassoonTracker

I believe they all come from the single book, Dictionary of Obscure Sorrows, referenced in the blog. All the terms in there are new words! (The breakdown you have is what I would've guessed too, though.)

I've beaten myself up many times in college for seemingly forgetting everything after classes finish. I spent a bunch of time trying to figure out how to learn and retain better. I tried Anki a bit but would inevitably forget things as soon as I stopped too. Forgetting is frustrating, and a situation where I -know- that I knew something before but not anymore is doubly so. But.. ultimately I think I've arrived at this view as well.

Your brain is not wired to remember things that you don't use. If you want to continue remembering, you have to continue engaging with the topic, and a lot of the advice in this thread is IMO just that (just, with a specific regimen / kind of engagement). It's completely natural to forget.

In fact, I'd go further and suggest embracing the forgetting and relearning cycle. If you really need to revisit the topic, you can relearn it again, and it'll be faster than the first time. And maybe you'll forget another time -- that's OK too, you can pick it up again even faster. In the end it's the discipline of relearning (the particular topic, and in general!) that actually continuously hardens. IMO there are parallels between this mindset and SRS -- though without the shame when you forget or miss a day of practice.

Related only through 3b1b, but someone did a deeper investigation into a few different ways to sample uniformly in a circle and (even though the point here is mathematical interest) benchmarked them! https://youtube.com/watch?v=4y_nmpv-9lI

I'd initially misread this, thinking it was an article on how a lot of websites that look pretty can be surprisingly horribly unusable.

Related is Kevin MacLeod [1]'s music [2], who you've almost -certainly- heard before. He has thousands of royalty-free CC music and has become deeply entrenched in (at least my perception of) early 2010s internet BGM.

[1] https://en.wikipedia.org/wiki/Kevin_MacLeod [2] https://incompetech.filmmusic.io/

bytebeat is so cool.. this music compo site has more resources for those curious [1] , along with a stellar collection of bytebeat songs [2]

[1] https://battleofthebits.org/lyceum/View/bytebeat+(format) [2] https://battleofthebits.org/browser/Format/bytebeat

A similar cute trick for making a coin with arbitrary bias p out of a fair coin: go through the (possibly infinite) binary expansion of p, flipping once for each digit. If you flip tails on a 1 or heads on a 0, go to the next digit and repeat. If you flip heads on a 1 or tails on a 0, stop and take that as your flip. (And if you get to the end of the expansion, you can think of it as only 0s now, so interpret it as tails)

I agree -- that sort of rhythm may be to the point and good for some goals of technical writing, but is pretty sterile. My favourite quote about sentence pacing:

This sentence has five words. Here are five more words. Five-word sentences are fine. But several together become monotonous. Listen to what is happening. The writing is getting boring. The sound of it drones. It’s like a stuck record. The ear demands some variety. Now listen. I vary the sentence length, and I create music. Music. The writing sings. It has a pleasant rhythm, a lilt, a harmony. I use short sentences. And I use sentences of medium length. And sometimes, when I am certain the reader is rested, I will engage him with a sentence of considerable length, a sentence that burns with energy and builds with all the impetus of a crescendo, the roll of the drums, the crash of the cymbals–sounds that say listen to this, it is important.

(Gary Provost)

I don't understand why it's more or less weird to say the base case is wrong vs. the inductive case is wrong. If H(n) is 'all sets of horses of size n contain horses of the same colour', the linked argument seems like

H(1) is true

H(n) => H(n+1) (with a sleight of hand that it's only for n >= 2)

It seems to me like changing either the argument to assert H(2) is true, or the scope of the second statement to include n = 1, would be enough. It seems the fault of both statements equally to not fit with the other, so why is it weirder to say the base case is wrong?

I've been doing one-hour time limit song writing challenges and in those I need to write accompaniment fast. I gotta say, this generation is a really close reduction of what I actually do -- come up with some accompaniment figure over a chord or two, then transpose it and tweak chord tones for the next measure. Maybe add a part or do something different if it's a section change. IMO this post is a great example of how to mix variation and repetition to balance interest and familiarity.

Even if the generation itself has limitations it seems like a great springboard for manual touches like dissonance tweaking, or new sections, or fills / transitions -- arguably the cool creative part after all anyway! There's a lot of repetition in music, and when writing, it's hard to decouple it from points of interest. A workflow that enables such is very exciting.

(Taking this opportunity to share my multiplayer piano roll editor: https://yuxshao.github.io/ptcollab/ )

Even though it's not about human languages, it is funny to think about how you would definitely learn a human language too if you pored through its entire literary canon.

I think the 'if' is the first point you list, and the 'only if' is saying that if Mozilla doesn't spell it out honestly then they'd not be willing to entertain which is a bit strange but logically equivalent to the second point you have.

PICO-8 is fantastic! If you know the platformer Celeste, it started off originally as a PICO-8 game for a game jam. It really feels to me as an exemplar of 'constraints beget creativity'.

This is super exciting! I've been exploring this space of collaborative music editing too (and will shameless plug a multiplayer piano roll DAW I worked on [1]) and had some thoughts.

1. When collabing with friends it was slow for us to iterate because we (and a lot of people) just send files back and forth. It was hard to sketch things out without having some other kind of whiteboard. Of course others who can communicate musical ideas better through words probably would handle this a lot better.

2. Multiplayer editing was really fun in comparison. The magical moment is when you're working on some section and you listen to the song again and you realize someone else has added something on top of what you were doing earlier. It's like the song has taken on a life of its own.

3. Even with multiplayer it's still hard to coordinate and you can't get around planning even with rich tools. If the song was gonna be serious and not just doodles, we usually had to voice-chat to discuss what'll go in each section, then sorta divvy up parts. I guess the upshot is that even with the ability to be 'maximally' present with others, many people, myself included, work best with some amount of private creative freedom.

When I jammed in a bigger group, flows like relays or Monsquaz swap [2] that gave people that freedom, then at specific moments let them intermingle, seemed to work best for getting something out at the end. (If it was a free-for-all people usually ended up doing their own thing in some measures they staked for themselves out in the roll. Or otherwise people just spammed meme songs like Megalovania everywhere.)

[1] https://github.com/yuxshao/ptcollab [2] https://swap.monsquaz.org/

Oops, that was my misunderstanding in the first paragraph :)

Maybe a clearer example w.r.t. the base^exponent value would be another highly structured class of long passwords, instead of short passwords. For example, those that are just a 2-character sequence repeated 20 times (e.g. abab...ab). You can still say that it'll take maybe up to 26^40 tries for an attacker to guess this, but that number should be more obviously too charitable, since less entropic classes of passwords are more likely to be guessed first.

More generally, this kind of counting analysis depends on your choice of attacker, and it's plausible for attackers to be more sophisticated than just trying all the strings in lexicographical order. A more concrete but still practical attack sketch adapted to the frequency of password schemes today could be: guess dictionary word combinations first, starting with common/short words/phrase lengths, then repeat with small perturbations, then more perturbations, and so on until you search all the remaining strings.

Then, the number of tries for such an attacker to find a 3-word passphrase with a few changes would be much closer to (some small constant) * (# dictionary words)^3 than (# characters)^(string length). Of course, you can still say that such an attacker would take at most (# characters)^(string length) tries to get it, but such an upper bound isn't as useful when the password is much more structured and easy to guess with a slightly more sophisticated attacker.

(Yet another way to put it: one shouldn't expect a password that's 'slightly out of reach' to be significantly more secure than a password that follows a scheme exactly - a more sophisticated attacker would test neighbouring passwords as it brute-forces the combinations in the scheme)

To your first point, I think it's about priors about password choices. To take an extreme example, even if a site allows up to 32 alphanumeric characters, we don't just say passwords on this site are uniformly secure under metric (26+26+10)^32 because theoretically a brute-force approach would have to go through up that many permutations. (Such a number is an upper bound on your password security.)

In particular, short passwords with up to 8 characters are weaker because they form a small and common subset of passwords that people often draw from, and attackers exploit that by trying short passwords first.

Passwords that are 3 dictionary words, with possibly some small perturbations like punctuation inserts or replacements (which helps but only expands the space so much), also form a relatively small subset of passwords that people increasingly draw upon, and attackers aware of this will tailor their brute-force search accordingly.

I had the same confusion until I read the proof, though maybe I missed something earlier too. This corresponds to the validity condition in the last section.

Both generals start with either 0 or 1, and the condition is that if both started with 0 (i.e., initially wanted to individually retreat), they should both output 0. Likewise for 1. The thing about Eve deciding which value the generals start with may also be confusing; a better way to think of it is that 'no matter what both generals start with, this validity condition holds'.

I think Norman's The Design of Everyday Things rings incredibly true to this story and its lessons.

There are so many examples in that book where users, frustrated or inconvenienced by the (high-tech) complexity of their tools, devise their own (low-tech) way to use a tiny subset of the features that just barely gets the job done for them--though perhaps not as creatively as writing on the screen here. One is the emergence of scrappy post-it-note instruction guides for basic tasks people would tape next to overengineered phone systems in the 90s. He also presents the concept of a 'gulf of evaluation' that makes contextualizes the difference between designer expectations and actual use (or the difficulty of getting feedback that would bridge this gulf).

The book---in its latest version, intentionally---omits discussions about modern software, but it does more than enough to prove its point with simple everyday examples. I'd highly recommend giving it a read to anyone!

Reminds me of this story where a car was 'allergic' to vanilla ice cream: https://news.ycombinator.com/item?id=13347852

A great guide to typography for the reader with a few hours to spare is Butterick's Practical Typography: https://practicaltypography.com/

Typically just a restatement: 吃了。

No, but that's spoken Japanese. Different phrases are prevalent between spoken and written Japanese, as a workaround for those ambiguities.

Well, in English spaces certainly carry weight, partly because the word unit has so many characters. In languages like Chinese and Japanese, units /are/ the characters (or a few of them). Particles then make natural separators in strings of kanji.

There are a lot of homophones between Chinese loanwords in Japanese. A writing system like Romaji that only records the phonetic information would be no more useful than just hiragana (which might then arguably more useful as it aligns with the syllables?)

That it's the fastest is pretty surprising to me. Both Binet and matrix multiplication require exponentiation to n, which can be done in O(log n) multiplications (not n-1) using a clever recursion (and indeed numpy uses it). 2x2 matrices aren't exactly the hardest to multiply either, but I figured that the floating point operations with the Binet formula would enough baggage that would make it slower than the matrix method. Edit: I just saw Someone's comment - I guess that explains it.

Surprised to see this on HN! I played this when I was young and it was a great, charming substitute for the Nintendo games my parents refused to buy me, haha.