Drag-and-drop makes the digital graspable, but building it well is fiddly enough that many don’t bother. Declarative Dragging (with Josh Horowitz & Jeff Heer, #uist2026 best paper award), lets you make an element draggable just by listing the states dragging it can reach.

stacks and stacks

Trying to learn rhombus (@racketlang) lately, the control flows syntax is so elegant and intuitive: docs.racket-lang.org/rhombus-guide/…

- test should be considered part of the program
- the same for properties
- PBT and runtime checks should be able to be derived from props
- var name should be considered part of the doc. Docstring should not repeat what is already implicated by the var name.

ive been writing all my rough stuff in typst. also i have a string diagram generator for on-the-fly working

the only thing I one-shotted on Codex Plus plan is the 5 hour usage limit.

no one:
claude: BSD sed has no \b, so the rename didn't apply. Redoing it with perl.

well actually, might just be my skill issue

Maybe I’m wrong, but I believe dependent types are a great fit for low-level programming because correctness there is relatively stable and easy to express formally. High-level features are different beasts. How do you formalize something like “Send no more than three notifications per day, except for urgent events”, let alone verify it? Things close to the business end are unstable in both meaning and priority. There is a case to be made for decoupling types and properties here. We can’t capture all the invariants we want, but we can choose to put some of what we can in types, some in properties, and we can leverage many existing tools to give us sufficient assurance. This is not to say dependent types are not worth it at high levels, though. I just think they need a friend in a separate proof system, ideally built into the same language.

I need a word to describe: "I saw a bug. I don't understand the bug. LLM came up with a fix I don't understand either. But it fixed the bug."
I really don't want to waste reviewer's time and make them think that I'm an idiot when attaching a gen-ai fix in a bug report.

I think today's time is the turning point for AI labs to optimize for human communication rather than some "task"-related benchmaxxing in model training. The cost-benefit structure has made trading off readability for unreadable code golf not reasonable anymore.

I wonder what proxy they will come up to model the readability of codebase (not just code, but also a readable architecture design). Using Fable to evaluate Opus's code is definitely not good, because Fable has no issues with overused jargon and putting changing log in comments.

I am resistant to use LLM to help me read a book. I have fear that if I don't read it from cover to cover, I'll get lazy and disrespect the knowledge and the author.

I just tried. It's good and efficient. I should probably do that more often. It's a skill to learn.

其实仔细想想, 我的恐惧是由于我过度神圣化了书本. 我幻想只要一页一页读完, 我就一定会获得什么. 我至少可以说"我读完了XXX". 我可以划掉这本书不再读.

一些证据:
- 我对paper也有类似的恐惧. 但是没有书来得多
- 我很少重读书 因为我觉得"读完了"

Google Shell Style Guide:
<google.github.io/styleguide/she…>

Bash Pitfalls: <mywiki.wooledge.org/BashPitfalls>

this critique is unfair because "computer science" as a field is less of a single field and more like at least 3 loosely overlapping domains:

1. (computer) science: the study of the actual machines we have: CPUs, caches, memory, networks, operating systems, databases, compilers, and algorithms. this is mostly the world of the von neumann machine, and roughly what an undergraduate CS curriculum centers on.

2. theoretical (computer science): complexity theory, information theory, turing machines, quantum computing, lambda calculus, and type theory. this is the mainstream mathematical theory of computation, and probably the part most criticisms of “computer science” are aimed at.

3. (theoretical computer) science: proof theory, category theory, philosophy, linguistics, and to a large extent just general mathematics. not many really know about it, and it's also just generally really hard because you start needing to know graduate level mathematics. topology, abstract linear algebra, functional analysis, differential geometry, ... are very often used. "computers" in this case don't necessarily mean "equivalent to turing machines" anymore, and often times are intentionally weakened to obtain better structural properties (ala Lafont's interaction combinators). furthermore, it is the upstream of most domain shifting ideas in computer science. to say that "computer science" only studies things like turing machines ignores an incredibly important and unusually generative part of the field

borrow checking? linear logic, via girard.

types? proof theory, via gentzen and curry–howard.

monads and algebraic effects? category theory and universal algebra, via lawvere, moggi, wadler, and many others.

so complaints about “computer scientists” usually need several asterisks. the field is not just intellectually fragmented, it's also sociologically fragmented! these communities often publish in different venues, use different standards of evidence, require different mathematical backgrounds, and are sometimes housed in entirely different departments.

Ok, this is in fact amazingly good.

claude.ai/share/1caa35ab…

I don't understand why the migration target is Python (Python is my main language btw). I'd at least choose a language with ADT. OCaml? Scala? The conclusion might mean that Haskell was the wrong choice at the very beginning. LLM only makes correcting this error easier.