ivanb (u/ivanb) - Readit News

ivanb commented on I Wrote a Scheme in 2025 maplant.com/2026-02-09-I-... · Posted by u/maplant

vindarel · 4 days ago

JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)

ivanb · 2 days ago

We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.

ivanb commented on Claude Code is being dumbed down? symmetrybreak.ing/blog/cl... · Posted by u/WXLCKNO

bcherny · 5 days ago

Hey, Boris from the Claude Code team here. I wanted to take a sec to explain the context for this change.

One of the hard things about building a product on an LLM is that the model frequently changes underneath you. Since we introduced Claude Code almost a year ago, Claude has gotten more intelligent, it runs for longer periods of time, and it is able to more agentically use more tools. This is one of the magical things about building on models, and also one of the things that makes it very hard. There's always a feeling that the model is outpacing what any given product is able to offer (ie. product overhang). We try very hard to keep up, and to deliver a UX that lets people experience the model in a way that is raw and low level, and maximally useful at the same time.

In particular, as agent trajectories get longer, the average conversation has more and more tool calls. When we released Claude Code, Sonnet 3.5 was able to run unattended for less than 30 seconds at a time before going off the rails; now, Opus 4.6 1-shots much of my code, often running for minutes, hours, and days at a time.

The amount of output this generates can quickly become overwhelming in a terminal, and is something we hear often from users. Terminals give us relatively few pixels to play with; they have a single font size; colors are not uniformly supported; in some terminal emulators, rendering is extremely slow. We want to make sure every user has a good experience, no matter what terminal they are using. This is important to us, because we want Claude Code to work everywhere, on any terminal, any OS, any environment.

Users give the model a prompt, and don't want to drown in a sea of log output in order to pick out what matters: specific tool calls, file edits, and so on, depending on the use case. From a design POV, this is a balance: we want to show you the most relevant information, while giving you a way to see more details when useful (ie. progressive disclosure). Over time, as the model continues to get more capable -- so trajectories become more correct on average -- and as conversations become even longer, we need to manage the amount of information we present in the default view to keep it from feeling overwhelming.

When we started Claude Code, it was just a few of us using it. Now, a large number of engineers rely on Claude Code to get their work done every day. We can no longer design for ourselves, and we rely heavily on community feedback to co-design the right experience. We cannot build the right things without that feedback. Yoshi rightly called out that often this iteration happens in the open. In this case in particular, we approached it intentionally, and dogfooded it internally for over a month to get the UX just right before releasing it; this resulted in an experience that most users preferred.

But we missed the mark for a subset of our users. To improve it, I went back and forth in the issue to understand what issues people were hitting with the new design, and shipped multiple rounds of changes to arrive at a good UX. We've built in the open in this way before, eg. when we iterated on the spinner UX, the todos tool UX, and for many other areas. We always want to hear from users so that we can make the product better.

The specific remaining issue Yoshi called out is reasonable. PR incoming in the next release to improve subagent output (I should have responded to the issue earlier, that's my miss).

Yoshi and others -- please keep the feedback coming. We want to hear it, and we genuinely want to improve the product in a way that gives great defaults for the majority of users, while being extremely hackable and customizable for everyone else.

ivanb · 4 days ago

One thing this specific feature was letting me do is seeing when Claude Code takes a wrong turn, read a wrong memory MD file. I used to immediately interrupt and correct its course. Now it is more opaque and there is less of a hint at CC's reasoning.

ivanb commented on Xfce is great rubenerd.com/xfce-is-grea... · Posted by u/mikece

ivanb · a month ago

That 500x313 screenshot of the desktop does not help any argument.

ivanb commented on 2026 will be my year of the Linux desktop xeiaso.net/notes/2026/yea... · Posted by u/todsacerdoti

ivanb · a month ago

It will be mine as well but only because consumer agentic AI became available and good. Only it makes all quirks and hardware incompatibilities bearable. I tell it to investigate the problem and it does an incredible amount of digging to help find the cause and eventually, after several iteration, either fix it or implement a good enough crutch. Even then it takes minutes to hours and I would take months.

ivanb commented on I'm returning my Framework 16 yorickpeterse.com/article... · Posted by u/YorickPeterse

ivanb · 2 months ago

What's is the deal with Linux and suspend? It seems only a select few combinations of hardware and software can handle suspend and resume. AMD is commonly praised for their Linux drivers but my all-AMD system crumbles down on power state transitions and especially suspend-resume. I never though words "data", "fabric", "sync" and "flood" can be used together, but now they are a common sight in my logs.

ivanb commented on Steam Frame store.steampowered.com/sa... · Posted by u/Philpax

ivanb · 3 months ago

It was so thoughtful of them to use IR tracking. Bed time gaming becomes much easier. I wonder if there was a choice between color passthrough and IR tracking and they chose the latter. Good choice!

ivanb commented on Thoughts on Mechanical Keyboards and the ZSA Moonlander masteringemacs.org/articl... · Posted by u/TheFreim

ivanb · 5 months ago

The whole area is full of contradictions:

- mechanical keys - reduced movement;

- buy a custom build - have industrial build quality;

- barely any movement - good blood flow;

- avoid rolling - type fast;

- concave keyboards - tenting;

- fewer keys - minimal;

- uniformly shaped keys - touch typing feedback;

- keep hands on the keyboard - move pointer precisely;

- custom layout - conventional shortcuts.

This is ridiculous. I no longer take this field seriously. I get it, we get bored and need a new toy sometimes. Some indeed acquired a medical condition and need medical equipment to type now.

I noticed when I exercise I can sit comfortably on a firm basic stool, and when I don't I become a princess on a pea.

How about we start with the basics? Good posture, correct hand positions, monitor at the right level, exercise, nutrition. Then an IBM Model M would suffice.

ivanb commented on SQL needed structure scattered-thoughts.net/wr... · Posted by u/todsacerdoti

ivanb · 5 months ago

One limitation of JSON is its limited set of types. For example, for decimal numbers one has to resort to stringly typing representation because DB connection libraries assume that JSON numbers are floating point. Note that JSON numbers are just sequences of digits, nothing more. There is no attached precision semantic.

Another example is UUIDs. Instead of transferring 16 bytes, the libraries deal with wasteful string representation. I'm sure you can bring another examples.

Nonetheless, for majority of data JSON as DB output format is alright.

ivanb commented on Jujutsu for everyone jj-for-everyone.github.io... · Posted by u/Bogdanp

ysofunny · 6 months ago

also, demonstrating a marked improvement in the experience.

it really does seem like we all gonna be using jj soon enough

I recall pijul.org that was another working prototype of better git

and I wonder how much overlap is there in the way they have made the improvements.

ivanb · 6 months ago

Supposedly, Pijul doesn't have the "force-push to trunk" problem. This alone makes it interesting.