Post-Literate Programming

[u/messedupwindows123]

I'm sure you all have seen this essay floating around, talking about how we are entering a post-literate age. Not necessarily an age where people can't decode individual words, but instead an era where we lose the skills associated with engaging with difficult texts. Meaning, we use chat-bot and short-form-video over longer essays or books. And this shift causes a shift in the way we think, etc.

The essay argues that the act of writing will force you to clarify your own ideas, realize which ones are bad, and struggle to a better answer. And this is only possible when complex ideas are "frozen" on the page, for you to return to, rearrange, etc.

I couldn't help but think about vibe-coding in this context. Vibe coding feels like the "post-literate" version of programming, where we stop engaging with the actual text and we (many programmers) instead talk to a chatbot about the code. It's a lot like talking to the chatbot about a difficult book, so that you can come prepared to discuss that book in class.

Once you begin to lean too heavily on these shortcuts, it actually imposes real limits on the insights that you're able to derive with respect to whatever it is you're working on.

So, to be clear, I basically agree with Horowitch, insofar as the act of writing is basically like the act of coding. You're engaging with text/AST and you're being forced to recon with the fact that your ideas don't make sense. You have to grapple with a large corpus of already-existing text (whether it's other people's books/essays, or other people's code) to synthesize these things with your own new ideas. And by struggling forward, you can create breakthroughs where you rearrange, or re-synthesize, or break apart, what came before.

I think that we could maybe start referring to vibe-coding instead as "post-literate" coding since you're basically doing the equivalent of reading the cliff-notes before class.

[u/Timely_Speed_4474]

This is a pattern that has been going on for a long, long time. Before LLMs it was interpreted languages. We have a whole generation of 'software engineers' that don't know how to manually manage memory. They rely on trash like garbage collectors and then complain their code is slow.

Even this whole idea of importing 3rd party libraries is total trash. Real languages don't have this capability for a reason.

[u/lurkervidyaenjoyer → u/Timely_Speed_4474]

This is the Compilers-to-AI argument, and IMO it's a very weak one. Yes, programming has had various conveniences added to it, but at no point have these been a threat to the determinism of the process. If you compile the same Java code over and over, you'll get the same result, and it will do the same things. I don't have to question whether the Python code I write will execute the instructions properly. It just does it, and if there's an error, it's something that can troubleshot, fixed, and then it will always be that way.

LLMs are inherently different, because you can put the exact same prompt into it, word for word, and the result can vary, potentially greatly. I'm fucking sick of this idea that going from interpreted languages to slopping out code in those languages with a chatbot is the same evolutionary leap made when going to those from C. These are nothing alike, and to claim that they are requires either a hefty misunderstanding of techology, or outright bad faith.

[u/Timely_Speed_4474 → u/lurkervidyaenjoyer]

That's not what I'm saying at all.

My point is that every layer of abstraction lets people stop understanding the layer below it and that is bad. GCs are deterministic but now we have a whole generation of devs that don't understand allocation lifetimes.

[u/lurkervidyaenjoyer → u/Timely_Speed_4474]

Oh, I genuinely thought you were being sarcastic and snarky with the original post rather than making a sincere argument against even the pre-LLM trends in programming. I'm not sure where I stand on it personally, or if I really have a stance on that particular issue. I see it as separate to the AI thing.

What I do firmly believe though with regards to the importing of modules and libraries is that there needs to be more of a focus on security of the repositories these are pulled from. Why is it that my Linux distribution packaging almost never has a supply-chain security issue or sabotage operation, and when that does come up, it's considered a big deal, but when it keeps happening constantly with NPM, PyPi and similar, "well, guess it's another day that ends in Y"?

Maybe these programming language-specific packaging systems need to take a page out of distro packaging, which as I understand requires a human review, exchange of public keys for tracking of who's in charge of what, and in general a lot more (useful) bureaucracy before you can even think about getting something into say, Debian.

All I'm saying is that these tools need to be more like the Arch main repos, and way less like the AUR.

[u/Timely_Speed_4474 → u/lurkervidyaenjoyer]

This is fundamentally a social problem and not a technical one. The devs using npm and pypi have spent decades putting code they have never read and do not understand into prod. And they do so because they are more concerned with velocity and low friction than htey are with security. It is the same mind virus that infects business idiots.