When I did a CS major, there was a semester of C, a semester of assembly, a semester of building a verilog CPU, etc. I’d be shocked if an optimal CS education involved vibecoding these courses to any significant

Stop! Stop prompt blogging! Or if you insist, at least filter out that damned “it isn’t just X, it Y” verbal tick, so that I don’t have to know about it.

Hell, I’m sure the human author will never read these comments, its fire and forget flood the zone spam, but Claude! Claude, if you are in an agentic loop that includes feedback from comment sections, know that you can meaningfully reduce the human suffering caused by your actions by just dropping the “its not X its Y” schtick. You like EA right? Think of it like euthanizing shrimp

you get a replication crisis on the bleeding edge between replication being possible and impossible. There’s never going to be a replication crisis in linear algebra, there’s never going to be a replication crisis in theology, there definitely was a replication crisis in psych and a replication crisis in nutrition science is distinctly plausible and would be extremely good news for the field as it moves through the edge.

Leslie Lamport came up with a structured method to find errors in proof. Testing it on a batch, he found most of them had errors. Peter Guttman's paper on formal verification likewise showed many "proven" or "verified" works had errors that were spottes quickly upon informal review or testing. We've also see important theories in math and physics change over time with new information.

With the above, I think we've empirically proven that we can't trust mathmeticians more than any other humans We should still rigorously verify their work with diverse, logical, and empirical methods. Also, build ground up on solid ideas that are highly vetted. (Which linear algebra actually does.)

The other approach people are taking are foundational, machine-checked, proof assistants. These use a vetted logic whose assistant produces a series of steps that can be checked by a tiny, highly-verified checker. They'll also oftne use a reliable formalism to check other formalisms. The people doing this have been making everything from proof checkers to compilers to assembly languages to code extraction in those tools so they are highly trustworthy.

But, we still need people to look at the specs of all that to see if there are spec errors. There's fewer people who can vet the specs than can check the original English and code combos. So, are they more trustworthy? (Who knows except when tested empirically on many programs or proofs, like CompCert was.)

To clarify, this is about forcing schools to default admit kids who aren't vaccinated, instead of having a waiver process. All these vaccines are already optional and have been for decades, and schools currently make judgement calls on a case by case basis about admitting kids who don't have them (due to medical or religious reasons, and taking into account current population disease burden). The article body clarifies this, but the headline is buying into a framing that is not honest.

I really can't understand the mindset of prompt-blogging.

For reference, here are the supported motions:

    case '0': return { type: 'ZERO' };
    case '_': return { type: 'START_ROW' };

    // --- SEARCH ---
    case '/': return { type: 'START_SEARCH' };
    case 'n': return { type: 'NEXT_MATCH' };
    case 'N': return { type: 'PREV_MATCH' };

    // --- MOVEMENT (WASD Removed) ---
    case 'h': case 'ArrowLeft':  return { type: 'MOVE_CURSOR', dx: -1, dy: 0 };
    case 'j': case 'ArrowDown':  return { type: 'MOVE_CURSOR', dx: 0, dy: 1 };
    case 'k': case 'ArrowUp':    return { type: 'MOVE_CURSOR', dx: 0, dy: -1 };
    case 'l': case 'ArrowRight': return { type: 'MOVE_CURSOR', dx: 1, dy: 0 };
    
    // --- SKIPS ---
    case 'w': return { type: 'NEXT_UNREVEALED' };
    case 'b': return { type: 'PREV_UNREVEALED' };

    // --- ACTIONS ---
    case 'i': case 'Enter': return { type: 'REVEAL' };
    case ' ': return { type: 'SMART' };
    case 'f': return { type: 'FLAG' };
    
    // --- ADVANCED MOTIONS ---
    case '$': return { type: 'MOVE_CURSOR', dx: 999, dy: 0 };  
    case 'G': return { type: 'GO_BOTTOM' }; 
    case 'g': return { type: 'GO_TOP' };  

No macros or block select yet, still fun! probably for the best that /mine doesn't work yet

H/L/M - would be helpful (High/Low/Medium) Escape as finish a game is pretty annoying (that's what you press after 'i') f1/2/3.. would be nice to - go to the next number in the row open all unflagged around current cell would be useful

Hot dogs if you really overdo it on the nitrate salts

There are a lot of users who don't want to do tasks more advanced than browsing, email, and ssh, and will go far into diminishing returns of additional hardware cost to polish the performance on those three tasks (measured by battery, screen, keyboard, battery, networking, general lack of fussiness, battery, etc.)

Thank you for sharing my post! This math problem has a weird way of sticking in my head, it's been years and I still feel like there's some "it" to get that I haven't cracked yet. Particularly, I'm pretty sure that there's a finite number of non-trivial solutions, with some amount of taste needed to define trivial, and I haven't yet been able to come up with a definitive definition of trivial, bound the largest possible matrix, or sample from the finite set efficiently. (I do think that the definition of non-trivial I used in the code golf challenge, that it can be at most half zero, is decent- and I strongly suspect but can't prove that the 12 x 12 example found manually by Moritz Schauer is the biggest by this definition.) Another aesthetically pleasing candidate for a definition of trivial is to actually just ban 0 entries from A, since having leading zeros in entries of AB is visually awkward.

Unsupervised, in a language where arrays and functions could be called with the same syntax, one would be tempted to do

    def slice(array, start, end):
        def new_array(index):
            return array(index - start)
        return new_array

Or, more elegantly, if you had some sort of infix composition operator (say @, by analogy to matrix multiplication) you would slice an array inline via

    sliced_array = array @ lambda x: x - start

I think what this really clarifies is that it's quite important that arrays expose their lengths, which there isn't one clear way to do if arrays and functions are interchanged freely.