Streaming HTML and Transfer-Encoding: chunked have existed since 1999 at least. I don't actually care about this argument one way or the other, but you can continue updating the site with HTML/CSS indefinitely, zero js required, simply by never completing page load.

Depends on the writer.

Speaking only for myself, I _love_ coding. But I haven't done refactoring by applying a needle (with a steady hand) to a roll of magnetic tape in _YEARS_ /snark.

I love monkey-patching some python or js. But never have I ever suggested that anyone would should do it. Writing everything in Haskell sounds lovely but I wouldn't advise that either.

I honestly don't care what language I'm writing in. LLMs bring us back to the smalltalk days: your code is data and your data is code. LLMs bring a translation layer so that even if you're writing some high-level language, some DSL that exists only on some 1-off platform that no one else is aware of, _everybody_ has access to a self-bootstrapping codebase.

I feel more empowered to _code_ than ever: now, every single input carries semantic weight that gets carried through the "compiler." Every claim of determinism can much more easily be fuzz-tested and made more robust. "'sup, this broke, fix yo" and "Would you be so kind as to fix this error?" contain semantic context that actually affects the output of the generated code. That restores empowerment around code _authorship_ while still preserving the guarantees we want from the published artifact.

"Deep understanding" doesn't disappear when you gain the ability to be more expressive. "Deep understanding" disappears when people become incurious.

I loved it. It was cathartic to read, too. It's really a rather short story. There's no accounting for taste.

Back in those times we made a distinction between nerds and geeks, with geeks really being a sort of subset of nerds that was just interested in the technicals.

I always found attempted distinctions between nerds and geeks to be kinda fake. As long as I've been alive, there's been so much overlap that any distinction is at best a slight and unreliable shade of meaning (e.g. nerd "sounds" a shade more academic/grades focused, but "computer geek" and "computer nerd" are synonyms).

I think that distinction was invented post-facto. For most people they were pretty much synonyms in every day usage.

Some artists use a brush, but others use a chisel.

And then there's the bullshit artists.

Just because we never had the option of a chisel before doesn't mean all chiselers are bullshit artists.

For me, one of the big improvements is the ability to legitimately work via text message. That probably sounds dystopian in a bunch of ways to some people. But there are times that I want to work, but couldn't, previously.

Now I can work from wherever, whenever, by speaking into my headphones, and have it persist. Sure, I want to be in front of a screen to do final syntax review, but I don't mind planning out architecture and guiding an LLM towards a cohesive result while going for a walk or jog. That's just not a workflow that would have been viable 3 years ago.

I always thought of myself as merely ADD, but your comment is so incredibly relatable across all dimensions that I find myself wondering how far along the autism spectrum I am. Although, in my personal opinion, neither term is especially helpful: it's not a sensory/executive processing disorder if it's clearly benefiting both yourself and the people around you. It might make being sociable difficult, but that's the tradeoff for being willing to engage your mind in ways that others filter out as "too much information."

I’d be really careful with language like. For me the sensory and executive components are clearly disordered and border line disabling all on their own., and while it is what “me” is, it certainly isn’t making me or anyone around me happier, or their lives easier. Like - I carry a shoulder bag with industrial earmuffs and extremely dark sunglasses at all times because I cannot function in sensory overload. It is not a super power, and framing it that way is dismissive of those of us not on the very mildest end me of the spectrum.

I apologize. I didn't mean to suggest it is a super power, and it has also been a struggle in my life. I find it useful to frame this way because the struggle is not only because of the way that I am, but also because of the way everyone else is. I'm not asking anyone to change on my behalf, but it took me a long time to accept myself as I am. It took me a long time to accept that I didn't need to change for the benefit of everyone else.

They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.

Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?

You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work.

It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.