tyg13

Must we, every time the limitations of AI are discussed, always imagine some simpleton human to defend it? It's trite and rarely adds anything to the conversation. The point is to judge the model on its merits. If this is a good world model, then it's a good world model. It doesn't matter whether or not a human can recollect every detail about a familiar neighborhood. It's irrelevant

I don't think it's that people online need to have more unstructured discussion, or "not get to the point" -- it's that there's no real sense of community in a lot of online spaces. Why would I spend a bunch of time idly having Seinfeldian conversations with strangers with whom I have no rapport or continuity? The vast majority of people who will read my social media comments will be completely invisible to me. All the years of commenting and interacting online have predictably resulted in precisely zero lasting relationships.

If the point of not getting to the point is to build trust, then there has to be a relationship in which that trust is invested. Otherwise, not getting to the point is just more invitation for someone to take issue or dismiss what you're saying, to divert the discussion, or to completely miss the actual points you want to discuss.

I think this is both true and untrue. For a long time, I was an AI skeptic, perhaps even a hater. A chauvinist for writing code by 'hand.' But it's become very difficult, as I've gradually migrated to AI-authoring of code, to go back to writing code by hand and retain the same velocity.

Part of this is certainly that my hand-authoring code skills have atrophied, sure, but my workflow has also radically changed. Previously, I would spent a lot of time and focus on a single work item, and only context switch to other tasks whenever I would wait on CI or a long build. It meant that I spent a lot of time understanding one thing at a time, and interruptions (forced context switches) incurred a massive switching cost.

Now, having moved to largely AI-authored code, I find myself necessarily working on multiple threads at the same time. This means I can meaningfully progress each of those threads in parallel, with a much-reduced overhead on context switching, since I don't have my head down focusing on all the details of the work. And if the task really demands it, I can still stop and focus on one thread to sketch out the code manually, think about the concepts more deeply, etc.

It's a very different workflow, and there are certainly downsides, but the upside is that the rate of which I've been able to put up good-quality PRs has measurably increased. It's not quite 2x, and it's certainly not 10x, but it's definitely noticeable. I do understand a bit less, but there was always more work than time to understand things in full detail. I guess only time will tell if that missing understanding was actually vital to the long-term success of my work.

Yeah, the problem with "not fighting it" is that you'll naturally do what feels the best in the moment, and having fun will always feel the best in the moment over doing something boring.

The fall only comes later when all your having fun leads to a lot of not having fun (work piles up, relationships sever, projects fail etc.) I find living in a certain amount of fear of fun is healthy. If I feel like I've been having fun for too long, I've probably been neglecting something important that is going to really ruin my fun later.

I say all this, as I scroll through HackerNews looking for hits of dopamine instead of continuing trying to fix the CI issues that have been paralyzing my work for almost a day now. That's not good to be a fun conversation in my 1-1 if I ignore it for much longer...

pretty sure Krugman himself said his prediction was intentionally pessimistic to counter the hyper-optimism of his peers. and in fairness, he wrote that at the height of the dot-com bubble.

actually, thinking about it more, I wonder if we'll see something similar with LLMs where, the bubble will eventually pop, but the technology won't disappear, and we'll see it quietly improve and integrate further into our lives over time. probably not that wild of a prediction to make, but I do wonder still

Ah, but you see, it was a general purpose programming language. A general purpose, functional, optionally-typed programming language, with its own optimizing compiler and build system. In fairness, it wasn't originally developed to be our in-house language, but it was the creation of the CTO.

It was fun while it lasted and I had a lot of fun working on it. But it was really not a good business fit. The programmatic macro system was supposed to allow us to build customer-facing DSLs on top of it, but everybody just wanted Python anyways.

Yup, and every time it breaks, you've got to pester someone whose job probably isn't maintaining that thing actively.

I worked at a startup with massive NIH syndrome, once. We even used our own in-house programming language, because it was "better than anything else out there on the market." It did have a lot of nifty features that others don't have: a pretty novel type system, programmatic macros, a built-in build system and other fun bells and whistles -- but also not-so-fun ones like having no syntax highlighter, LSP, or debugger, and having to constantly shuffle around your code to avoid ICEs in the compiler.

The compiler wasn't the product, but we found ourselves fighting that thing more actively than any of the real problems our custom programming language was supposed to solve. The CTO found himself spending all his nights and weekends mostly trying to get the compiler to not explode.

A few years later, after I had long left (for that reason, among many) I heard they switched to Python. Can't imagine how long it took them to get that all rewritten.

Must we always see this restated every time? It's getting a bit stale always seeing these kinds of comments on articles about LLM.

The incessant need to constantly leave "the code doesn't work like <bad implementation>, it works like <good implementation>" frustrates me to no end. No amount of directions against it in project MEMORY, CLAUDE.md, or even embedded in the prompt seem to be able to stop it from doing this. I don't understand how it could have gotten into the training because I've legitimately never seen an actual person write code comments like this.

I too have settled into a kind of dual Claude/GPT model setup. I will often use one to review the other's work, or critique the other's plan in some way. Sometimes I'll have Claude implement a feature one way, then have GPT do it the other way, then have them both review each other's implementation. Then synthesize a final plan from the previous implementations+reviews.

I might just be having fun with models, but I have actually noticed their capabilities vary somewhat, and so my (perhaps vain) hope is that by using both, one can catch each the other's blindspots. It's still unclear to me if that's consistently happening, but I am making substantial progress in my personal and professional projects, so something seems to be working.

most large companies, maybe, but small-to-medium-sized businesses can and will tell you to take a hike. there are no consumer protections in the US regarding returns beyond the goodwill of the company

Exactly. You as the programmer know that the loop counter won't overflow, and in general, essentially nobody would actually write it that way. But if you don't assume it can't happen, the possibility for signed overflow is everywhere in address computations.

This is also a major blocker for auto-vectorization. Can't coalesce a load of a[i], a[i+1], a[i+2], a[i+3] into a load of a[i:i+3] if there's a possibility that `i+1`, `i+2` or `i+3` wrapped around (thus causing your "contiguous" load to be non-contiguous). This is a big reason why you shouldn't use `unsigned` for loop counters, especially if they're going to be used as an index into an address calculation.

I see what you're going for, but I don't see how your example is UB. If `p` is a pointer, and, after your `if (p)` check, `p` is dereferenced unconditionally, then yes, your check for `p == NULL` could be removed, and the code under the `if` would be removed as well. But the example you've constructed is not UB.