nemo1618

Centaurs are a transient phenomenon. In chess, the era of centaur supremacy lasted only about a decade before computers alone eclipsed human+computer. The same will be true in every other discipline.

You can surf the wave, but sooner or later, the wave will come crashing down.

Just wait. In a few years we'll have computer-use agents that are good enough that people will stop making APIs. Why bother duplicating that effort, when people can just direct their agent to click around inside the app? Trillions of matmuls to accomplish the same result as one HTTP request.

This strikes me as a very agent-friendly problem. Given a harness that enforces sufficiently-rigorous tests, I'm sure you could spin up an agent loop that methodically churns through these functions one by one, finishing in a few days.

For those curious about division, I wrote a popular uint128 package in Go that uses one of the standard approaches: https://github.com/lukechampine/uint128/blob/3d2701e8e909405...

Here's one attempt: https://x.com/sigilante/status/2013743578950873105

My take: Any gains from an "LLM-oriented language" will be swamped by the massive training set advantage held by existing mainstream languages. In order to compete, you would need to very rapidly build up a massive corpus of code examples in your new language, and the only way to do that is with... LLMs. Maybe it's feasible, but I suspect that it simply won't be worth the effort; existing languages are already good enough for LLMs to recursively self-improve.

Blackpill is that, for this reason, the mainstream languages we have today will be the final (human-designed) languages to be relevant on a global scale.

Eventually AIs will create their own languages. And humans will, of course, continue designing hobbyist languages for fun. But in terms of influence, there will not be another human language that takes the programming world by storm. There simply is not enough time left.

   The skill isn’t being right. It’s entering discussions to align on the problem.
   Clarity isn’t a style preference - it’s operational risk reduction.
   The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.”
   This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone.
   The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
   This isn’t passive acceptance but it is strategic focus.
   This isn’t just about being generous with knowledge. It’s a selfish learning hack.
   Insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
   Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission.

I'm so tired bros

This is conflating two things: The stuck, and the suck.

As the author says, the time you spend stuck is the time you're actually thinking. The friction is where the work happens.

But being stuck doesn't have to suck. It does suck, most of the time, for most people; but most people have also experienced flow, where you are still thinking hard, but in a way that does not suck.

Current psychotechnology for reducing or removing the suck is very limited. The best you can do is like... meditate a lot. Or take stimulants, maybe. I am optimistic that within the next few decades we will develop much more sophisticated means of un-suckifying these experiences, so that we can dispense with cope like "it's supposed to be unpleasant" once and for all.

You certainly do not need to play music at the speed the performer intended! There are whole genres (and subgenres) based on this. :) Personally, I have found that slowing a familiar piece down by ~5% tricks my brain into perceiving it as novel again, which helps me attend to it more closely and appreciate it more.

Conversely, I use this "block pattern" a lot, and sometimes it causes lifetime issues:

    let foo: &[SomeType] = {
        let mut foo = vec![];
        // ... initialize foo ...
        &foo
    };

This doesn't work: the memory is owned by the Vec, whose lifetime is tied to the block, so the slice is invalid outside of that block. To be fair, it's probably best to just make foo a Vec, and turn it into a slice where needed.

Years ago there was a YouTuber, "Surveillance Camera Man," who went around pointing a camera at people with no pretense. Frequently the subjects were upset by this and became aggressive, even violent. I believe the intended message was that this is a natural and justified reaction to being surveilled, and yet there is little outcry because public surveillance is largely invisible and/or faceless (e.g. just a CCTV camera mounted on a building, rather than a stranger invading your personal space).

The YouTube account is no longer around, but you can still watch it on archive.org: https://web.archive.org/web/20190220131525/https://www.youtu...

yep, https://github.com/lukechampine/slouch. Fair warning, it's some of the messiest code I've ever written (or at least, posted online). Hoping to clean it up a bit once the bytecode stuff is production-ready.

I made my own, with a Haskell+Bash flavor and a REPL that reloads with each keystroke: https://www.youtube.com/watch?v=r99-nzGDapg

This year I've been working on a bytecode compiler for it, which has been a nice challenge. :)

When I want to get on the leaderboard, though, I use Go. I definitely felt a bit handicapped by the extra typing and lack of 'import solution' (compared to Python), but with an ever-growing 'utils' package and Go's fast compile times, you can still be competitive. I am very proud of my 1st place finish on Day 19 2022, and I credit it to Go's execution speed, which made my brute-force-with-heuristics approach just fast enough to be viable.

Ha, I'm in a similar position, having given up on it after a few months of sips. At what point did it click for you?

AI does not need to be conscious for it to harm us.

Liquids are also removed (gradually). For someone already in weakened condition, I would be surprised if the process took longer than two weeks.

Your passwords should never be visible on screen anyway: They go straight from a password manager into a censored input field.

yup, less than 24 hours after writing that comment, I found myself embedding a struct so that I could override one method in a test, haha

Over the course of ~10 years of writing Go, my ratio of "embedding a struct" to "regretting embedding a struct" is nearly 1:1.

I do not embed structs anymore. It is almost always a mistake. I would confidently place it in the "you should be required to import 'unsafe' to use this feature" bin.

I'm very interested in this too. We're beginning to see models that can deeply understand a single image, or an audio recording of human speech, but I haven't seen any models that can deeply understand music. I would love to see an AI system that can iteratively explore musical ideas the same way Claude Code can iterate on code.

Time for Hungarian notation to make a comeback? I've always felt it was unfairly maligned. It would probably give LLMs a decent boost to see the type "directly" rather than needing to look up the type via search or tool call.

I'm dipping my toes into decompilation -- specifically, decompiling Super Smash Bros. Melee. Once you get into the groove, it's kinda addicting! Now that I've done a few functions by hand, I'm wondering how to best leverage AI to speed up the process.

Come decompile with us! https://github.com/doldecomp/melee

There are two ways to look at this.

First is that, if the parsing library for your codec includes a compiler, VM, and PGO, your codec must be extremely cursed and you should take a step back and think about your life.

Second is that, if the parsing library for your codec includes a compiler, VM, and PGO, your codec must be wildly popular and adds enormous value.

I think this adds more confusion than it removes.

A list is not a monad. A list is a data structure; a monad is more like a "trait" or "interface." So you can define a List type that "implements" the monad interface, but this is not an inherent property of lists themselves. That's the sense in which a list "is a" monad: the OOP sense.

Haskell's List monad provides a model for nondeterminism. But that certainly isn't the only way List could satisfy the monad interface! It was a deliberate choice -- a good choice, possibly the best choice, but a choice nonetheless.

> Bill, who lives near Aylesbury, said the reason for the request last Wednesday would be revealed in 23 years.

...well?

Many people aren't aware that you can use key: val declarations in arrays

I wonder, what's the "weirdest" expression in Go? Here's one:

   type Foo struct{}
   func (Foo) Bar() { println("weird...") }
   func main() {
    ([...]func(){^^len(`
   
   
   `): (&Foo{}).Bar})[cap(append([]any(nil),1,2,3))]()
   }

Knitting is definitely the O.G. fidget toy for neurodiverse women

I see two downsides. Looking at this snippet:

    my_function (): Unit can AllErrors =
      x = LibraryA.foo ()
      y = LibraryB.bar ()

The first thing to note is that there is no indication that foo or bar can fail. You have to lookup their type signature (or at least hover over them in your IDE) to discover that these calls might invoke an error handler.

The second thing to note is that, once you ascertain that foo and bar can fail, how do you find the code that will run when they do fail? You would have to traverse the callstack upwards until you find a 'with' expression, then descend into the handler. And this cannot be done statically (i.e. your IDE can't jump to the definition), because my_function might be called from any number of places, each with a different handler.

I do think this is a really neat concept, but I have major reservations about the readability/debuggability of the resulting code.

I wonder: if we get superintelligence before 2030, do you think we should revive him ASAP, or wait and do it in 2030?