cant you do most of this with smalltalk too, or erlang?
I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done
I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done
Let's way you wanted to do a web application using LLMs. Using a web framework would cost less tokens than using the vanilla underlying language (Python, PHP, whatever..), which is again way less tokens than building up from assembly (an LLM should be able to do this given enough time and compute).
https://news.ycombinator.com/item?id=21232352 (Oct 2019)
https://news.ycombinator.com/item?id=4766191 (Nov 2012)
https://news.ycombinator.com/item?id=694700 (July 2009)
* in the older sense of "token", meaning that one measures a program in AST size rather than lines of code
---
Edit: ok, this is what I get for not reading the article:
> For LLMs, less code means fewer tokens, and tokens are what you pay for so you spend less on development
Ironically, this comment of mine from a few days ago touches on a lot of the points from this article and was flagged to death:
https://news.ycombinator.com/item?id=49924013
Note also that WebAssembly's text format is S-expression based. For conciseness I presume?
There's a "zen" moment felt by folks who've written lots of macros (experienced in Lisps and Forths) where, when designed properly, you really feel like you've "grown" a language and have really walked up the abstraction ladder. My thesis is that macro heavy code when the author designs the macros well are very readable. That an agent's output when stacked upon macros can be a lot simpler to read and understand than in languages where the syntax is less fungible. And if you leave a project for a while and come back, an agent is a perfect tool to help you read your macros and familiarize yourself with the abstraction surface again.
Just a theory though.
I agree with your point
There is also a phenomenon I've named "brevity collapse." Often, when shrinking a codebase, you find you need less glue. Additionally, because it is smaller, you can hold more of it in your head and see more opportunities for shrinkage. Surprising things happen when the bones of your language get more efficient---it's more like going from elephant to flea than elephant to grizzly bear. The smaller scale means there's less "overhead" code, which means you can go smaller still.
Pithiness. A human might need to be able to read and understand the code. If the code is much longer than it could have been, it will take much longer to read and understand it.