Hacker News: herrington_d

New comment by herrington_d in "Kotlin creator's new language: talk to LLMs in specs, not English"

herrington_d — Thu, 12 Mar 2026 16:28:33 +0000

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.

New comment by herrington_d in "Show HN: I ported Tree-sitter to Go"

herrington_d — Wed, 25 Feb 2026 23:11:09 +0000

I also have a tree-sitter Rust rewrite. Though I cannot find it more useful for end users... https://github.com/HerringtonDarkholme/tree-sitter

New comment by herrington_d in "Typed languages are better suited for vibecoding"

herrington_d — Mon, 04 Aug 2025 02:44:30 +0000

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

New comment by herrington_d in "Typed languages are better suited for vibecoding"

herrington_d — Mon, 04 Aug 2025 01:46:23 +0000

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.

New comment by herrington_d in "Typed languages are better suited for vibecoding"

herrington_d — Mon, 04 Aug 2025 01:36:38 +0000

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.

New comment by herrington_d in "AST-Grep [video]"

herrington_d — Mon, 09 Jun 2025 21:27:42 +0000

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!

New comment by herrington_d in "Why Algebraic Effects?"

herrington_d — Sat, 24 May 2025 19:23:12 +0000

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.

New comment by herrington_d in "Better Error Handling"

herrington_d — Mon, 21 Apr 2025 00:55:20 +0000

the blog lacks the review of one critical player effect.ts https://effect.website/docs/error-management/two-error-types...

New comment by herrington_d in "CCL: Categorical Configuration Language"

herrington_d — Sat, 11 Jan 2025 16:59:02 +0000

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.

New comment by herrington_d in "The evolution of a structural code editor"

herrington_d — Mon, 06 Jan 2025 22:55:14 +0000

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

New comment by herrington_d in "The evolution of a structural code editor"

herrington_d — Mon, 06 Jan 2025 18:15:41 +0000

> 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_

New comment by herrington_d in "The evolution of a structural code editor"

herrington_d — Mon, 06 Jan 2025 18:04:38 +0000

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

New comment by herrington_d in "Skip – The Reactive Framework"

herrington_d — Sun, 29 Dec 2024 02:04:10 +0000

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.

New comment by herrington_d in "Design Space for Code Search Query"

herrington_d — Thu, 26 Dec 2024 15:38:16 +0000

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...

New comment by herrington_d in "[dead]"

herrington_d — Thu, 26 Dec 2024 00:30:52 +0000

This blog post delves into the design space of code search, with a particular focus on how queries are designed and used.

New comment by herrington_d in "[dead]"

herrington_d — Sun, 22 Dec 2024 16:35:50 +0000

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.

New comment by herrington_d in "The Acton Programming Language"

herrington_d — Fri, 06 Dec 2024 05:57:03 +0000

Curiously the claim sounds like learning this programming language is equivalent to reading the whole DDIA book. :P

New comment by herrington_d in "Show HN: Scooter – Interactive find and replace in the terminal"

herrington_d — Fri, 15 Nov 2024 21:50:45 +0000

Cool! is it possible to support structural search like ast-grep[1]? ast-grep has some interactive mode but it is nothing near Scooter.

1: https://ast-grep.github.io/

New comment by herrington_d in "Mergiraf: a syntax-aware merge driver for Git"

herrington_d — Mon, 11 Nov 2024 03:58:03 +0000

Yes, ast-grep already has its own rule syntax [1]. But still parser performance and binary size are critical factors for a general tool.

https://ast-grep.github.io/guide/rule-config.html

New comment by herrington_d in "Mergiraf: a syntax-aware merge driver for Git"

herrington_d — Sun, 10 Nov 2024 05:51:21 +0000

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.

[1]: https://ast-grep.github.io/