After reading The AWK Programming Language, I decided to try solving a problem from Advent of Code using AWK. With some free time, I set up my environment and began experimenting. Part 1 was straightforward, but Part 2—a shortest path search with a twist—quickly exposed my deep reliance on functional programming principles. I found myself struggling to adapt my usual functional BFS approach in AWK, a language not built for immutability, lexical scoping, or first-class data structures. I missed key features I take for granted in modern languages: algebraic data types, exhaustive pattern matching, immutability, and the ability to return arrays from functions. The more I tried to force a functional style into AWK, the more tangled the code became. I spent hours wrestling with accidental complexity—things that would be trivial in a more expressive language. I knew AWK wasn’t designed for this. It’s meant for simple text processing and one-liners. But I couldn’t help wondering: what if AWK had evolved? What if it combined its elegant pattern-action model with modern language features? I imagined a functional AWK with: - First-class arrays, including nested and associative ones - Lambda functions and higher-order functions - Lexical scoping instead of dynamic scope - Explicit globals, with everything else local by default - Pipeline syntax for functional composition Rather than building it myself, I turned to an LLM. I asked Cursor Agent with Sonnet 4.5 to generate a full interpreter implementation in Python based on those ideas. To my surprise, it delivered—not just a README with examples, but a working prototype that ran the sample code correctly. I also requested implementations in C, Haskell, and Rust. All compiled and ran, though I haven’t tested them thoroughly. The LLM handled complex features like multi-dimensional arrays, redirection in print statements, closures, and even backwards compatibility with GAWK. The only real struggle was with arbitrary-precision floating-point arithmetic, which it attempted using Taylor series—until I told it to use mpmath, and it fixed the code instantly. The result is FAWK, a new language I never expected to exist. I can now use it to solve Advent of Code puzzles, even if I don’t understand the code under the hood. I’ve updated my mental model: LLMs can now help me build real tools, not just small edits. But this comes with trade-offs. I have no deep understanding of the codebase, so making manual changes will be hard. I also worry about over-relying on the LLM, especially for personal projects like my long-term WIP language Cara, where I want to maintain hands-on control. Performance isn’t a concern yet—FAWK is for throwaway scripts, not production use. But the idea of having it rewritten in Rust via an LLM feels plausible now. For now, I’ll use FAWK on Advent of Code, test its limits, and see what breaks. I expect issues in the form of unimplemented features or edge cases where new language design clashes with old behavior. If you're up for the setup, you can try it yourself at Janiczek/fawk on GitHub. Use at your own risk.