Hacker News Reader

t-kalinowskion How I over-engineered my book

Seeing that list of tools you're using in automations, I'm guessing you'll enjoy this, as another tool to add to the pile: https://t-kalinowski.github.io/yamark/

(disclosure: I wrote it)

t-kalinowskion Haystack: Open-Source AI Framework for Production Ready Agents, RAG

One project I’d add to the comparison is raghilda from Posit:

https://posit-dev.github.io/raghilda/

raghilda is deliberately narrower than LangGraph/Haystack/etc. It focuses on the RAG parts: document ingestion, chunking, embedding, storage, and retrieval. It’s meant to leave the pieces visible and replaceable rather than wrap the whole application in a framework.

It also composes well with the other parts of the Posit ecosystem: chatlas for LLM interaction, and Shiny for building interactive apps around the result.

My bias is that orchestration is often better hand-rolled for the specific application. Once the framework gets too far removed from the actual steps, it tends to bring in a lot of complexity you probably don’t need. In the end, most of these pieces are not that complicated.

Disclosure: I’m one of the authors of raghilda.

t-kalinowskion In defense of YAML

I wonder if YAML is better than JSON for LLMs, because the indentation keeps the nesting level information local to the content.

t-kalinowskion Slumber a TUI HTTP Client

Because YAML is the worst config format, except for all the others.

https://opensource.posit.co/blog/2026-05-21_in-defense-of-ya...

t-kalinowskion Quarkdown – Markdown with Superpowers

Memories are failable :) Here is the PR you merged June of last year, changing the file extension from `.qmd` to `.qd` after a discussion about Quarto: https://github.com/iamgio/quarkdown/pull/90

t-kalinowskion Refuse to let your doctor record you

Counterpoint from a doctor: https://substack.com/inbox/post/189714240

Scribes _feel_ good in the short-term, but it's not clear if they're actually good on longer time horizons.

t-kalinowskion Show HN: Marimo pair – Reactive Python notebooks as environments for agents

Very cool!

We’ve been exploring a similar direction too, but with a plain REPL and a much thinner tool surface. In our case, it’s basically one tool for sending input, with interrupts and restarts handled through that same path. Marimo seems to expose much richer notebook structure and notebook-manipulation semantics, which is a pretty different point in the design space.

It seems like the tradeoff is between keeping the interaction model simple and the context small, versus introducing notebook structure earlier so the model works toward an artifact at the same time it iterates and explores. Curious how you think about that balance.

Repo: https://github.com/posit-dev/mcp-repl

t-kalinowskion Show HN: TUI-use: Let AI agents control interactive terminal programs

I agree that at first glance, it seems like tmux, or even long-running PTY shell calls in harnesses like Claude, solve this. They do keep processes alive across discrete interactions. But in practice, it’s kind of terrible, because the interaction model presented to the LLM is basically polling. Polling is slow and bloats context.

To avoid polling, you need to run the process with some knowledge of the internal interpreter state. Then a surprising number of edge cases start showing up once you start using it for real data science workflows. How do you support built-in debuggers? How do you handle in-band help? How do you handle long-running commands, interrupts, restarts, or segfaults in the interpreter? How do you deal with echo in multi-line inputs? How do you handle large outputs without filling the context window? Do you spill them to the filesystem somewhere instead of just truncating them, so the model can navigate them? What if the harness doesn’t have file tools? And so on.

Then there is sandboxing, which becomes another layer of complexity wrapped into the same tool.

I’ve been building a tool around this problem: `mcp-repl` https://github.com/posit-dev/mcp-repl

So tmux helps, but even with a skill and some shims, it does not really solve the core problem.

t-kalinowskion Show HN: Rv, a Package Manager for R

Posit offers something similar to Microsoft’s CRAN Time Machine, but it works not only for CRAN, but also for Bioconductor and PyPI. You can add a date to the Public Posit Package Manager URL to access a snapshot of all packages from that day.

For example: https://packagemanager.posit.co/cran/2025-03-02

You can browse available snapshot dates here: https://packagemanager.posit.co/client/#/repos/cran/setup?sn...

This also works for PyPI and Python packages: https://packagemanager.posit.co/pypi/2025-03-04/simple

t-kalinowskion I don't like NumPy

Or, don't even write the fortran manually, just transpile the R function to fortran: https://github.com/t-kalinowski/quickr

t-kalinowskion LLMs get lost in multi-turn conversation

This was the main reason I wrote promptdown. I want to be able to edit the full chat history every turn, and the append-only standard chat interfaces don't make that easy.

https://github.com/t-kalinowski/promptdown

t-kalinowskion Generalizing Support for Functional OOP in R

The Python interop is in the blog post because it makes for convenient and compact examples, not because it motivated any of the features.

If you're interested in what motivated S7, you may enjoy this talk Hadley gave: https://www.youtube.com/watch?v=P3FxCvSueag (R7 was the working name for the package at the time)

t-kalinowskion RStudio: Integrated development environment (IDE) for R

R does have namespaces. Take a look at the NAMESPACE file found at the root of every R package, which defines the symbols and methods exported by the package.

Note for many R packages, the NAMESPACE file is autogenerated from roxygen docs: https://cran.r-project.org/web/packages/roxygen2/vignettes/n...

t-kalinowskion Tidyverse 2.0.0

It's a new OOP system for R.

repo: https://github.com/RConsortium/OOP-WG

talk: https://www.youtube.com/watch?v=P3FxCvSueag&t=258s