herrington_d

Isn't the case study.... too contrived and trivial? The largest code change is 800 lines so it can readily fit in a model's context.

However, there is no case for more complicated, multi-file changes or architecture stuff.

it does not always work in my experience due to complex type definitions. Also extra tool calls and time are needed to fix linting.

The logic above can support exactly the opposite conclusion: LLM can do dynamic typed language better since it does not need to solve type errors and save several context tokens.

Practically, it was reported that LLM-backed coding agents just worked around type errors by using `any` in a gradually typed language like TypeScript. I also personally observed such usage multiple times.

I also tried using LLM agents with stronger languages like Rust. When complex type errors occured, the agents struggled to fix them and eventually just used `todo!()`

The experience above can be caused by insufficient training data. But it illustrates the importance of eval instead of ideological speculation.

Hi, ast-grep author here. thanks for sharing the video!

production quality is amazing! I also did some youtube video recently. It is not easy and end product is far from polished.

Really appreciate your help introducing the tool to more people, thanks!

One thing AE provides but not coroutines is type safety. More concretely AE can specify what a function can do and cannot do lexically in code. A generator/coroutine cannot.

For example, a function annotated with say `query_db(): User can Datebase` means the function can call database and the caller must provide a `Database` handler to call the `query_db`.

The constraint of what can do and not is pretty popular in other programming fields, most notably, NextJS. A server component CANNOT use client feature and a client component CANNOt access server db.

Calling other languages like "none of the tooling" in the "why" section sounds like a huge self-roasting since CCL does not have, say, highlighting/LSP/FFI for adoption.

My point is that type error recovery is the property of the type system. Not the property of structural code editor.

This is a pretty fair comment. I wonder how structural editing figures out things like formatting/searching/diffing and copy/paste across different editors.

Since Skip is maintaining a reactive cache. How is the cached stored? I would speculate it would a distributed in-memory database so the computation service can scale. But I wonder how the system can recover and rebuild the cache if the cache is down.