93 karma · joined August 10, 2024
Also, remind me, when did the Ukrainian parliament last celebrate the Nazi collaborator (Bandera) during its new years posts?
But yes, it takes an amazing amount of arrogance to look at a simple exploration of music theory from first principles and respond with "this isn't music theory"
Recommending The Jazz Theory Book to someone starting from scratch, especially someone self studying, is like recommending CLRS or TAOCP to someone who asks "I'm curious about learning the basics of algorithms and data structures, any good books for self study?" And of course that happens all the time too. Chapter 1 is "here's what intervals like major 3rd and perfect fifths are", Chapter 2 is "here's the major scale and all its diatonic modes and ii-V-I progressions", Chapter 3 is "here's how you might use the Phyrigian mode to play over a Sus flat-9 chord" (pg 48).
Recommending Schoenberg and Messiaen as steps to get a sufficient surface of topics covered for "music theory" is performance art in its own regard. Bravo!
There's another level of imprecision here in common usage, which is that big-O is strictly an upper bound, meaning that Merge Sort is O(N!). What they really mean is big-Theta, a "tight" bound, in which Merge Sort would be θ(n log n).
But for simplicity's sake, let's use big-O to mean "tightly bound" like people do in casual discussion, and further let's say we're talking about runtime as the size of the function based on its domain:
There is no such thing as big-O performance bounded by a "real-life data structure". The entire point of big-O is that it is asymptotic analysis. You could define a number H, where H is the time to the heat death of the universe, and Python's sets and dictionaries would never be O(H). Because you could for your set/dict runtimes of f(n) still find a constant C and k such that f(n) > C*H for n > k. One example would be setting k to H*C + 1, and that works for either f(n) ∈ O(1) or f(n) ∈ O(n^2).
You can analyze algorithms with respect to real physical limitations, but at that point you are not talking about their "big-O" performance. So the author, despite being "top 2% of scientists" in his field, which is "software performance", seems to still be lagging behind your average freshman compsci student who crammed for their complexity analysis exam.
>Can we say that since every real-life data structure size is bounded by some constant, it is O(1)? If not, why?
>>You may, yes.
Very powerful thinking coming from someone who is "a software performance expert. He ranks among the top 2% of scientists globally (Stanford/Elsevier 2025) and is one of GitHub's top 1000 most followed developers"
Little tip if you're vibe(ish) coding: Use some sort of memory system (be it markdown files, wiki, lightweight issue tracker, etc.) and tell it to put full context for feature work in the ticket, enough that a new session can work the ticket, including acceptance criteria. Then have the implementation agent do a /goal to drain the work items until they'll done/closed (only close when acceptance criteria is met) or blocking human interaction, putting all important context from the work into comments on the work item during closing.
It will pile all its dense verbiage into those work items when it closes them, and, in my experience, will only bubble up significant questions and notes to you the user if they are significantly important.
You don't have to think about all that shit you posted. Future coding agents do. So I also make sure it searches for related work items before creating a new one. I use Fable 5 xhigh to plan the work items (costs very little because there aren't many output tokens) and Opus 5 med/high to drain the work item queue.
I had it build a significant system at work last week in my spare time, enough that it would have been 4 or 5 sprints worth of work. Cost me ~$250 in Opus 5 credits (on my company dime, I would have used a subscription or cheaper model and it would have been much less) and ~$40 in Fable 5 credits. You know how much Opus 5 ruminating on system design I had to read? Literally none. I saved my time reading things for reading the code it produced in the places I knew would be need to be modular and extensible, so that I made sure future work wouldn't have a lot of tech debt to pay when it came time to extend it.