nickm12

Yes, definitely. And the same program can run on completely different architectures. But it has a well-defined semantics that must be preserved by the compiler or runtime.

I'm not saying it's all mathematical purity. Programming languages themselves have specs and sometimes they are ambiguous or allow undefined behavior. Compilers have bugs. But the gap between the source code and program behavior is typically extremely thin and language implementations work towards making it airtight.

If a compiler doesn't preserve the semantics of the program, that's a bug in the compiler. Programs in GCed languages mostly don't describe the behavior of how memory is managed and that is left to the compiler and runtime.

You're welcome! I'm struggling with when and how to look at the code and what really matters now. I personally work across multiple codebases that each have teams of 5-7 developers, so someone else was always doing the work and I personally never could read or understand all the code.

What I want to preserve in the AI-code-gen age that I still can form a high-level "theory of the program" and be able to dive deep and understand parts of it, both with and without AI. I'm concerned that we're headed towards a world where it's not possible to understand or modify even the simplest programs without a swarm of agents that you direct with incantation.md files.

It is something completely new and we should be thinking about it as such. Analogies can help us here, and I think the analogy of "instructing a software team" is a much more useful analogy than "instructing a compiler" and the latter clouds our thinking.

Proof that Djikstra was an AI model!

As I said, "AI models don't replace compilers, they replace software developers" so yes, I agree that AI models are like humans.

while both LLMs and humans are not 100% deterministic, I don't think that's the interesting part. It's both true that there are many assembly language programs that implement a C program and that there are many valid programs (in any programming language) that correctly implement a natural language spec. But there's a significant qualitative difference between the two types of translation and that would be true regardless of whether the translations are stochastic.

I send this article to everyone who tells me how English is now a high-level programming language, the next level of abstraction up the chain from machine language to <their favorite language>. This analogy tends to be followed by "Just like most programmers never look at assembly code, looking at higher-level source code is going to become something only a few people do".

Dijkstra's arguments tend not to change their minds. I think the analogy takes hold because there is a kernel of truth in it. AI models now give us the magical ability to program in natural language, but the implication that an AI model is a form of compiler is deeply flawed. AI models don't replace compilers, they replace software developers. The reason software developers rarely look at assembly code is that compilers (and emulators and VMs) are able to precisely preserve the semantics of the original program.

A natural language spec is not a program, and there are many possible programs that can meet the spec. Software engineers and AI models turn specs into code, but the code is not the spec I think the analogy clouds our thinking about the value of programming languages as a tool for formally describing what the computer should do and enforcing properties of the program that should not be left to either humans or AI models to uphold.

> At Linear, we have always valued intuition over ... data.

I don't believe it's that straightforward. "Intuition" and data are both ways of learning about the world and they complement each other. Sometimes the insights only come when you dig into why intuition and data disagree. The same can be said of process. Processes embody our best practices. But sometimes we should deviate and sometimes we should discard or rebuild them.

These are all tools in the toolbox.

Yes, there are many real world programmers who like this. And yes, many who are distressed at this. I find both aspects in myself. As a programmer, I much enjoy having agents write in languages like bash scripting or SQL that have a lot of quirks and I don't use frequently enough to be proficient with. But I miss programming in my favorite languages. I also see AI devaluing skills I've spent decades honing.

+1 I've been surprised at the relative lack of grief about this from working programmers. Certainly there is some, and I've read a number of posts on Hacker News from programmers working through these feelings, but it feels like the minority view.

No. Coding agents are great at simplifying, they just need to be told to do it.

I often see agents skip opportunities for simplification when not explicitly prompted. I have mixed feeling about this, but for now I think it's probably for the best that they stick to the script versus take initiative for things they haven't been told to do.

Agreed. Coding agents are an excellent tool for navigating an codebase to deeply understand the code (certainly better than grep!). My existential question is more about whether deeply understanding the code is worth doing at all. If your identity as a programmer was based around being the one who understood the code the best, why is that valuable when anyone can use the agents the same way?

Not the GP, but I think I have a similar urge to go deep in understanding details. I definitely find myself different than many peers who are more comfortable operating with ambiguity.

"A clean interface contract" is actually all I need to stop pulling the thread, but I find that is rare in large software systems. More typical is that the provided interface lacks details about edge cases, such that multiple behaviors could meet the interface. That's what makes me want to dive deeper and figure out what those cases are, what I think is the best behavior, and what the system actually does.

This post reads like it was written by a Common Lisp fan who is looking for a reasons to say that Common Lisp is good for AI agents, rather than an AI agent user evaluating what languages are really best.

I've heard fans of both statically typed and dynamically typed languages advocate for their language. The static type fans say that the rigorous compilation process gives the LLM a fast iteration loop with clear messages from the compiler on what invariants aren't being upheld. The dynamically typed languages advocates talk about fewer tokens, the popularity of the language in the training data, and so forth. Guess what, these are the exact same arguments these communities made for human developers.

Personally, I don't know the answer. The industry has swung back and forth on this over the decades. Before AI code-gen static languages were on the upswing for a variety of reasons, including runtime efficiency and much better ergonomics thanks to modern type inference engines. I suspect those reasons are still valid, and also that statically typed languages give LLMs a leg up because it is easier to reason about them locally thanks to declared types and information hiding.

Ok, not execs, but director and senior-director-level positions.

I remember Snow Leopard as a particularly stable release, but it's been so long this could easily be misremembering. One other thing that was notable about Snow Leopard, though, was that it was the last release before the iOSification of the Mac. Starting with Lion, Apple increasingly tried to unify the platforms and bring ideas and designs from iOS to the Mac, with mixed success.

For myself Snow Leopard holds a special place as the last "pure Mac" release and a culmination of a decade of Mac OS X releases. I skipped over Lion and Mountain Lion, finally getting back on the upgrade train with Mavricks, so I ran Snow Leopard for about four years.

Glad that the ebay execs who did this got prison sentences. I really wonder what kind of environment could make six high-ranking people think this was acceptable.

I believe both that code should be self-documenting but also that comments and documentation are a critical part of the code. Comments and documentation explain the functional contract of the code and why implementation choices were made.

Even if you have tests for an edge case, a comment inline with the code that explains why this edge case exists and why it is handled the way it is adds value to the code.

Yes, I've seen this a bunch too and agree completely. Sometimes I've also see Claude comments reference details about the calling or even code in completely different modules.

There are many reasons I don't like it, but a top one is that it falsely implies that you somehow need to know these details about the removed code/calling code etc to understand this code as its written in this revisions.

During the rise of agentic assistance, I've gotten the advice that "If the generated code isn't what you want, fix the steering, not the code". I've also been advised to not change the sometimes verbose comments and documentation that agents write because "it will help them the next time they look at the code".

I've been skeptical and these guidelines validate this. I continue to document code and write specs as I've always done. If an agent produces poor output or misunderstands, I use that as an opportunity to improve the docs, but in a way that that aims to be accessible for human peers, not the quirks of the current generation of models.

I'm with you in not wanting to see these types of comments in my code. I aim for each revision of the code to stand on its own, and not reference its past or future. There are exceptions and nuances, of course, such as TODO comments or comments related to ongoing migrations. I try to keep these short and reference tasks in the issue tracker, which are going to be more useful to anyone who happens to be reading the code.

I've heard the argument that leaving these comments in, helps support future AI code generation. In this example, it was important to you at the time you made the change that create_* functions have defaults, so having this in the code captures that knowledge for later agents. It's similar to a more general argument that you should leave (correct) AI-generated code alone because it will be easier for the AI to "understand" code it generated that your modified version of it.

I see the validity in these arguments, but I don't think we should be so deferential to these models. The first part of this comment ("Now create_background params have default values") is completely redundant with the function signature and as no place in the code. The second part ("the same as create_screen") is genuine knowledge that is worth capturing for the agent, but it should be captured at a higher level doc about the codebase, rather than tacked onto some arbitrary function as a comment.

It's strange that he shows the graphs with the age of vulnerabilities going up without any real commentary on it (except to say that it's an argument that the number of bugs is not close to zero). I'm not so sure—I think a deeper analysis needs to be done that accounts for the fact that the project itself is aging and also accounts for code churn.

For example, if bugs were introduced and detected via a mostly uniformly random process, but most of the code was written in the early part of the project's lifecycle, then you would expect the age of bugs to go up over time (since there is less young code). Even if the code addition rate was constant, if developers were producing fewer bugs over time, then the age of the bugs would increase, since older code would be buggier.

It's been a while since I taught anyone to juggle, but I generally disrecommended scarf juggling. It's fine if you want some quick validation, but the hand movements are so different from balls/bags that I don't think the skills are transferable.

I prefer the method described in the original post. Just start with one ball and get that right, then two, then three. It's a bit like the Karate Kid, though. Students don't find it as satisfying because they want to jump ahead before they've got the movement down.

1) I would generally use BBSes daily. Probably for an hour in the evening or however long I could tie up the family phone line. I would log into two or three, read and respond to messages. Very much like reading email at the end of the day. I forget what I started with, but once I found ZTerm for Mac I did not go back. https://en.wikipedia.org/wiki/ZTerm

2) I'm honestly not sure how I found my first. Possible I found some number at the local library, possible a friend in high school gave me one. Once you found one, you could learn about others from that one. There was a real culture of different sysops trying to get you to use their board (but only up to a point because it used phone lines)

3) It's really difficult to know. There was no equivalent to web search or a way to see what everyone else was doing. I'd expect the popularity followed some kind of power law, but everyone used a different subset of boards.

4) It's difficult for me to remember. Probably much shorter messages that would seem "simple" by today's standards.

Team CLI. I generally think we should build tools that are usable by humans and agents alike. An anti-pattern is having to use an agent to do something because you didn't build a human-accessible one. Another anti-pattern are MCP (Model Context Protocol) interfaces that are not managing any context.

That said, MCP could be an effective way to sandbox what an agent can do with a tool. Also, it seems plausible to me that a tool that actually provided information to a model via the MCP protocol could be more useful than a CLI tool which operates in the "silence means success" mode of most unix CLI tools.

Basically, make a design choice for _reasons_ and not just because you like that TLA of the option you picked.

This is a really nice take and matches my experiences as well. It also calls out one of the biggest incongruity of this current age: the sudden desire from management to have good specs and documentation for the benefit of the coding assistants.

For the first time in my career, I've seen an engineering org add "improve tech documentation" as a high-level goal. It makes me sad that it was never worthwhile to do for the engineers, but now we need it for the coding assistants who can't tell that our docs really out of date. On the flip side, the coding assistants will actually read the docs, unlike many engineers.

This is such a strange take. The definition of "magic" in this post is apparently "other people's code" and it even admits that that no practical program can avoid depending on other people's code. I think what the author is really saying that they like to minimize dependencies and abstractions, particularly in web client development, and then throws in a connection to coding assistants.

I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.

Python crossed the chasm in the early 2000s with scripting, web applications, and teaching. Yes, it's riding an ML rocket, but it didn't become popular because it was used for ML, it was chosen for ML because it was popular.

Because you generally cannot test every possible input, output pair.

Yes, because no one conflates an engineer with a compiler. But there are people making the argument that we should treat natural language specs/prompts as the new source and computer language code as a transient artifact.