HN user
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.
I also have a tree-sitter Rust rewrite. Though I cannot find it more useful for end users... https://github.com/HerringtonDarkholme/tree-sitter
it does not always work in my experience due to complex type definitions. Also extra tool calls and time are needed to fix linting.
There are researches backing some sort of "typed language is better for LLM". Like https://arxiv.org/abs/2504.09246, Type-Constrained Code Generation with Language Models, where LLM's output is constrainted by type checkers.
Also https://arxiv.org/abs/2406.03283, Enhancing Repository-Level Code Generation with Integrated Contextual Information, uses staic analyzers to produce prompts with more context info.
Yet, the argument does directly translate to the conclusion that typed language is rigorously better for LLM without external tools. However, typed language and its static analysis information do seem to help LLM.
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.
the blog lacks the review of one critical player effect.ts https://effect.website/docs/error-management/two-error-types...
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.
Better type information. Because the program is always in a valid state the type checker can always run and give meaningful feedback.
Note that programs can be syntactically well-formed but ill-typed. For example `let x = true + 1` has valid syntax but produces an "undefined" type for the variable `x`, if the type system does not support type error recovery.
A quote from the great paper from POPL 2024, https://hazel.org/papers/marking-popl24.pdf
If a type error appears _anywhere_, the program is formally meaningless _everywhere_
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.
The feature dates way back to perhaps 2006, per Jetbrains' PDF archive[1]. Jb also updated their structural search UI/UX in 2018[2]. It is possible that users do not buy in the idea of SSR. Alternatively, it may be caused by the fact that Jb SSR's mixed language support. [3][4][5]
[1] https://www.jetbrains.com/idea/docs/ssr.pdf [2] https://www.youtube.com/watch?v=YeGPO-UHTbs [3] https://www.jetbrains.com/help/idea/structural-search-and-re... [4] https://www.jetbrains.com/help/go/structural-search-and-repl... [5] https://www.jetbrains.com/help/pycharm/structural-search-and...
This blog post delves into the design space of code search, with a particular focus on how queries are designed and used.
We're thrilled to introduce typed AST in @ast-grep/napi, addressing a long-requested feature for AST manipulation from the early days of this project.
In this blog post, we will delve into the challenges addressed by this feature and explore the design that shaped its implementation. We also believe this post can serve as a general guide to crafting balanced TypeScript types.
Curiously the claim sounds like learning this programming language is equivalent to reading the whole DDIA book. :P
Cool! is it possible to support structural search like ast-grep[1]? ast-grep has some interactive mode but it is nothing near Scooter.
Yes, ast-grep already has its own rule syntax [1]. But still parser performance and binary size are critical factors for a general tool.
Hi! ast-grep[1] author here. It is a tree-sitter based syntax tool to search tool.
I wonder how you transition from tree-sitter to other builtin parsers? Tree-sitter gave a unified interface to all languages. Using language native parsers will require significant work for various FFI if I am not wrong.
Thank you for sharing this! While AI excels at providing general advice, it often falls short on delivering contextual insights specific to your code. I’m thrilled to see that ast-grep can be effectively used alongside AI to add more value for developers. Great job!
This can also be achieved via ast-grep by the command `sg -p 'database' -r 'db'`.
New guide for ast-grep rewriters! A powerful construct to perform complex code transformation!
A comprehensive guide explains why using code to search code can be more subtle than it looks.
ast-grep is a structural code search tool that leverages syntax trees to find patterns in source code. But it was hard to extract a sub-language embedded inside a document.
ast-grep now supports a feature to handle language injection, allowing you to search for code written in one lanuage within documents of another language.
Glad to see Google employee still has 20% of their time to do side projects! Python UI is especially interesting for ML/LLM folks who can build demos without changing tech stack.
I appreciate OP's ideas about how this project is compared to Streamlit?
Authoring in DSL can improve efficiency and productivity, but in my experience DSL itself brings benefits to a limited extent. It can be easier to read and write, but these benefits require one to understand the business model behind the DSL, which is usually more time-consuming.
Having a strong validation and observation toolset based on the DSL brings more value than the language itself. DSL constrains its semantics so it is easier to build tools on it.
ast-grep is based on tree-sitter parsers and most of the time is spent on parsing.
There is some optimization to [skip parsing](https://github.com/ast-grep/ast-grep/blob/9f8ed5fb2abf35d928...) but generally I don't expect ast-grep can beat ripgrep or amber. (but sometimes ast-grep can beat grep due to parallel processing)
Hey! ast-grep author here. I believe what you want is probably what https://github.com/ast-grep/ast-grep can help you.
More specifically for the "string constant" search/replace, you can see the playground example!
https://ast-grep.github.io/playground.html#eyJtb2RlIjoiUGF0Y...
No AI, No LLM, No BS, just Pure C and WASM (with a little bit of magic)