HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mtklein

633 karmajoined 16 anni fa

comments

mtklein
·11 ore fa·discuss
Yeah it makes me sad too. It's a one-way veil, no going back once I experienced the new magic.

Sometimes I pop back into a terminal, mkdir, git init, crack my knuckles to do some all-natural hacking and the sadness sets in before the hour is up... "why am I insisting on doing this the long way? I know this project would be better with me in a different role now."

Coding for me has always been a balance of process and ends. Getting done what I wanted done mattered most, but I can't pretend that I didn't also enjoy being the moving parts of that process. And I am most grateful for what I learned by throwing myself over and over against problems I didn't quite know how to solve. There's a satisfaction to doing a thing well that I always love being a part of, still do, anything, even doing the dishes or laundry.

And just recently with Opus I found myself having some really joyously manic days and weeks, making calls, picking tech, designing APIs, insisting on quality, keeping agents spinning. But Fable just kind of came in with "oh, I can do that all for you too. You can relax," and that was both exactly what I wanted and what started making me realize this had all finally caught up to me.

I never wanted to be management, but I can't unsee that I am more effective now playing Fable's boss than I was the last few months as TLM of a squad of Opuses, and that was more effective than just coding myself the way I love.
mtklein
·21 ore fa·discuss
On about day 2 of using Fable I realized that the .vimrc I'd been maintaining for 15-20 years would probably never change again.

With Opus I still feel like I'm pair coding and want to get in there and make some changes myself, but working with Fable (even Fable managing Opus agents) had me in a completely different mindset, one where I realized I would just be getting in the way.
mtklein
·15 giorni fa·discuss
I have never seen Codex or Claude get manual memory management wrong. I used to be pretty fastidious about using leak sanitizer or other such tools to catch my own memory management issues, and while not quite useless, that sort of testing has dropped way down my list of worries the more I lean on LLMs. I am constantly surprised by how many formerly tedious or error prone tasks stopped being either of those, and I expect to see practice shift away from middle-safe languages like C++ to not just much more safe languages like Rust but surprisingly also to much less safe ones like C and platform specific assembly.
mtklein
·2 mesi fa·discuss
Part of that could be ABI constraints. There are some surprising calling convention differences between a vector and a struct or union with vectors in it, and they vary platform to platform. E.g. on ARM a struct with two 128-bit vectors will pass in two registers where on x86 it must pass via the stack.

Using __attribute__ to tweak calling conventions can often really clean this up, but that's just as obscure and non-portable as the problem it fixes. So you either end up writing weird non-portable code one way or weird non-portable code another... Code working with these types doesn't get to benefit from zero-cost abstraction to the degree we're used to with normal scalar code.
mtklein
·2 mesi fa·discuss
I hate to admit it, but the Corona "Change your Latitude" ads are what locked it in for me.
mtklein
·3 mesi fa·discuss
what I mean here about NaNs is that from a testing perspective, I want to be able to write a test that expects NaN in the same way that I write other expectations, and you can't do that with ==.

    assert(x == 7);    // fine
    assert(y == NaN);  // never true
    assert(y != y);    // this is what you meant
so this equiv() helper fixes that,

    assert(equiv(x, 7));    // fine
    assert(equiv(y, NaN));  // also fine
now, as far as treating NaNs equivalently, the IEEE 754 float format has a huge number of possible representations of NaN, and if you did something like a bitwise comparison, you might think that 0x7fc00000, 0x7f800001, 0xffc00000, 0x7fc0f00d were all different and not equivalent, but they're all NaNs, and I find that when I'm looking for a NaN, I very rarely care about exactly which one I'm looking at. So checking (x!=x && y!=y) admits any two NaNs as equivalent.
mtklein
·3 mesi fa·discuss
My preference in tests is a little different than just using IEEE 754 ==,

    _Bool equiv(float x, float y) {
        return (x <= y && y <= x)
            || (x != x && y != y);
    }
which both handles NaNs sensibly (all NaNs are equivalent) and won't warn about using == on floats. I find it also easy to remember how to write when starting a new project.
mtklein
·3 mesi fa·discuss
Yes, it's a "Brain float", basically an ordinary 32-bit float with the low 16 mantissa bits cut off. Exact same range as fp32, lower precision, and not the same as the other fp16, which has less exponent and more mantissa.
mtklein
·3 mesi fa·discuss
The closest term I know is "just-so story".
mtklein
·4 mesi fa·discuss
I am also not looking forward to the system transitioning from "big experiment, burn money to make it good" to "established business unit, tweak it to death for incrementally more money / personal promotion." We're still in the honeymoon period and I very much expect to hate Waymo in 10 or 15 years when they reach a steady state.
mtklein
·5 mesi fa·discuss
If I remember correctly, the AVX2 feature set is a fairly direct upscale of SSE4.1 to 256 bit. Very few instructions even allowed interaction between the top and bottom 128 bits, I assume to make implementation on existing 128 bit vector units easier. And the most notable new things that AVX2 added beyond that widening, fp16 conversion and FMA support, are also present in NEON, so I wouldn't expect that to be the issue either.

So I'd bet the issue is either newness of the codebase, as the article suggests, or perhaps that it is harder to schedule the work in 256 bit chunks than 128. It's got to be easier when you've got more than enough NEON q registers to handle the xmms, harder when you've got only exactly enough to pair up for handling ymms?
mtklein
·6 mesi fa·discuss
[flagged]
mtklein
·6 mesi fa·discuss
I agree with you, but we must admit that The Expanse has all of spaceships bouncing around, explosion sounds, and superhumans.
mtklein
·7 mesi fa·discuss
This is astonishingly bad power usage for a laptop, a complete dealbreaker: "...early tests show that the SoC already draws about 16 watts at idle..."
mtklein
·7 mesi fa·discuss
This was a nice surprise when learning to code for NES, that I could write pretty much normal C and have it work on the 6502. A lot of tutorials warn you, "prepare for weird code" and this pretty much moots that.
mtklein
·8 mesi fa·discuss
Zig is so good at this, it is also probably the easiest way to cross-compile C.
mtklein
·9 mesi fa·discuss
I think this is _Alignas/alignas.

    struct foo {
        _Alignas(64) float x,y;
        _Alignas(64) int     z;
    };
    _Static_assert(sizeof(struct foo) == 192, "");
mtklein
·9 mesi fa·discuss
I very much used to agree with this, but some time this summer the ChatGPT iOS app started to change this for me. I have definitely had days where I've felt as coding-creative as I can be on a laptop but instead just texting my AI interns to handle the execution while I'm out for a walk.
mtklein
·10 mesi fa·discuss
I don't understand why this article invents and explains a phony ranged-float fix when the real fix from the footnotes would have been just as simple to explain. The deception needlessly undermines the main point of the article, which I completely agree with.