Charging for self-hosted runners is like a corkage fee but you still need to open the bottle yourself.

> it happens when they give Claude too much autonomy. It works better when you tell it what to do, rather than letting it decide. That can be at a pretty high level, though. Basically reduce the problem to a set of well-established subproblems that it’s familiar with. Same as you’d do with a junior developer, really.

Equating "junior developers" and "coding LLMs" is pretty lame. You handhold a junior developers so, eventually, you don't have to handhold anymore. The junior developer is expected to learn enough, and be trusted enough, to operate more autonomously. "Junior developers" don't exist solely to do your bidding. It may be valuable to recognize similarities between a first junior developer interaction and a first LLM interaction, but when every LLM interaction requires it to be handheld, the value of the iterative nature of having a junior developer work along side you is not at all equivalent.

I didn’t say they are equivalent, nor do I in any way consider them equivalent. One is a tool, the other is a person.

I simply said the description of the problem should be broken down similar to the way you’d do it for a junior developer. As opposed to the way you’d express the problem to a more senior developer who can be trusted to figure out the right way to do it at a higher level.

This feels like a rediscovering/rewording of Kernighan's Law:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." ~ Brian Kernighan

It's an old saying, I think Einstein is cited most often for it... something like this according to Google:

"We cannot solve our problems with the same thinking we used when we created them."

> I tried to teach her to code a few months back and it was hilarious. We started with "First download VS Code". We never made it to another step.

This has been a serious regression in the industry for a while: popular operating systems (I'm looking at you, Windows) don't encourage and are not set up for their users to program or even do the bare minimum of random automation unless it's embedded in an application and meant for automating just that application (excel macros).

You are encouraged and directed to install and use "apps" which are either a one-size-fits-all lowest common denominator or a tries-do-everything dog's breakfast frustration.

The Commodore 64 turned on instantly and said "READY." and effectively gave you a blank canvas to poke (no pun intended) at. It was BASIC, but it was a real (if simple and limited) programming language and you could get immediate feedback and satisfaction from playing with it to learn what it could do. The syntax of BASIC is simple, the stdlib is comprehensive and unopinionated. There was nothing to download to get started to try to get that initial dopamine hit and to start to realize the true power of what computers can do and what you could make them do.

If you want a better chance at getting someone excited about programming, there are much better places to start than VSCode. pico8, scratch, even the browser's developer toolbar is more accessible than VSCode.

I read comments such as:

>> I don't get it. LLMs are supposed to have 100% bridged this gap from "normie" to "DIY website." What's missing?

as less sincere and more facetious, calling out that every single "AI" company is massively overhyping their capabilities and use-cases. You did the same thing in a more detailed fashion, enumerating all the constraints that AI can't address, and others that speak to the reasons that small businesses don't have websites independently of the tooling/services that are ostensibly able too make it easier or remove barriers.

//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.

It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.

I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.

Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations.

(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

Is gccgo a joke to you?

Maybe? It's stuck at 1.18 without generics and no one has replaced its maintainer, Ian Lance Taylor, who seems to have moved on after leaving Google.

But to be fair to alternative toolchains, TinyGo and TamaGo are also a thing.

Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.

I meant gccgo specifically, I don't doubt he's still active with Go in general.

Good luck compiling on a toolchain that doesn't know about //go:embed or /* */import "C" comments.

Popularity and reputation are not the exact same thing. Reputation is about trust and predictability, while popularity is about awareness of the person and/or their reputation.

But your points largely stands. However, reputation is one of many tools that can be used to assess the worthiness of giving some work attention, but should be given a relatively low weight compared to other tools. Giving reputation a low, but non-zero weight allows bad actors to be rightfully put in their place and allows someone the ability and chance to "clean up" their reputation with effort.

When I first considered this in the late 90's I was inspired by Google's Page Rank algorithm, and wanted something akin to that for humans in a social network.

My core idea (back in the early 00's when I cam up with it originally) was to identify a small cadre of trustworthy individuals in various sectors - lets say finance, computing, healthcare, etc (but more granular) and give them high trust (maybe a manual score of 10). Then let who they score, and who those people score "trickle down" as it does in Googles page rank. It was a variation on what Google later called trust rank, I suppose.

It would have either failed to launch completely or turned into a dystopian nightmare akin to China's Social Credit System. It may have even turned out worse than China's system because the goals of finance do not always align with the goals of humanity.

A more modern implementation could be built on the block chain and be made very profitable... while it crushes us all.

This is such a common position in just about every professional industry, codified legally or as personal belief, that it barely qualifies to be called out as unique to Dijkstra.

Yes, who would say structured programming is bad these days, though maybe it wasn’t a popular sentiment at the time. Though I find this thread funny, “Dijktra was elitist, oh no, he did the gatekeeping, what horror, let’s abandon structured programming and seeing programming as a discipline altogether”.

Luck here isn't referring to some invisible dice roll whose randomness can not be explained or is just a correlation (like no rain on your wedding day would be), it's refers to variables that the person can not influence. Being born into a rich family is lucky for that baby, and the baby can't have done anything about it.

A forgery isn't a subjective assessment. A forgery is intentionally made inaccurate claim of the origin of something. If the by-line is claiming it was made by someone who didn't make it, it's a forgery no matter how good of a copy it is judged to be.