rixed

Isn't he famous for getting caught?

Except that most of the time a workload is made memory-hungry by terrible technical decisions ("self-describing" text data encodings come to mind).

I wish they were. Displaying an error message to the user, asking to try again later, is way too cheap in my opinion.

Please do not see any malice in this naive question, but why is that an obsolete model? Back in the days I had very different displays that I could use to display various windows of a flight simulator (some dedicated to some instruments, the big one for the front view, for instance) and it was quite nice. It sounds like that would not be easy to replicate with a single shared frame buffer, but maybe I'm wrong (I've been using nothing but a small laptop screen for decades)

Exploit paths in unloaded modules, I guess.

Two full time projects at the same time:

1. Helping to make ActivityPods apps working on top of https://nextgraph.org/ (instead of SOLID).

2. https://cloudywithachanceoflatency.net, network monitoring done right (according to me), for humans and AI SREs (still WIP but quite fun already).

And when I get a chance, accepting some small paying contracts to pay bills. Weird times.

Ultimately, I find it likely that TLS will become a tool to prevent users from accessing foreign content (browsers stubbornly refusing to show untrusted sites in the name of security, slowly getting there), more than a tool to prevent eavesdropping on users secrets.

Just to let you know you are not alone, stranger; but also to advise you to be careful when touching on group identities.

An agent can easily use a text cli tool, not an interactive TUI.

Yep, but that could still cause issues (those entries could be used as signals, or be mount points for currently unmounted partitions, etc). rmdir anything that start with "/" should be an absolute no-go.

To say nothing about running a sequence of shell commands without the -e option.

One hour ago, while looking casually at a package.json, I saw this and was horrified:

  rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js

Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory that works both on linux and windows!".

Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.

The industry is the process by which convenient crap like this gets standardized.

Agreed 100%. It's sad when the harness floods the context with a whole MCP response and then see the model dumping everything to disk to process it with a script. That's something the harness should do whenever the result is large: dump the json into a file and just say to the model: "your data is in /tmp/foo.json, it's very large so be careful with it", but I don't remember having ever seen that; maybe some harnesses do it? Depending on what the model is after it might want to filter for this or that, no need to load everything in the context.

I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.

But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.

Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.

My personnal solution to this is CTRL+W.

  > Problem 1: It Devours the Context Window

Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command.

  > Problem 2: Low Operational Reliability

If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol.

  > Problem 3: Overlaps with Existing CLI/API

Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP? But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean).

  > Provide CLI -> API -> docs, in that order

Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.

Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained.

That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.

/newest not so much, but I'm trying to visit /shownew (with showdeads) every now and then. I believe that's really why HN is for, and voting there a service duty.

There is a native toplevel hidden in OCaml5 source tree (not installed by default). So you can basically enter an expression, and the compiler will turn it into native code and dynamically load it. Interactive REPL with native code was not possible before that (apart from a short lived experiment long ago, if memory serves me well).

The PPX macro system is far from perfect, that's the whole point of this idea: with the native REPL + an s-expression syntax, you have lisp-like macros for free.

Sounds simple. Would you also have a story to explain why Europe never managed to develop an independent IT industry either?

According to IA this is mostly a myth though.

I'm pretty confident that in such a case they just hire the name, and that people doing the actual work will be hired on purpose with the required qualifications.

Certainly that can't be right, or there would not be so many old bureaucratic organizations out there.

Now that the native ocaml repl has landed, can't we just slap a s-expression syntax on top of ocaml and call it a day? We would have homoiconicity and the macros that go with it, and still could call "(compile `some-code)". Isn't that enough?

Like many corporate behaviors I believe we tend to rationalize them too much. Most job posts for management ask for previous experience with "implementing AI". Managers don't want to be left out any more than devs. Devs rewrite everything in the language-du-jour, managers max out tokens.

Nice follow up to "Big tech's hierarchical organisation has come for Wikipedia"

  multimodal models with environmental grounding may eventually have an analog [of affect]. text-only agents can’t.

I'd be curious to hear an explanation about why text can't. Or equivalently, why multimodal could.

Apologies for the phrasing, I should have written "form your own judgment"

  branch names are just a summarization of your commit messages

What kind of dev workflow leads to this surprising opinion?