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

▲

0xpgm 2 hours ago | parent | next [-]

Presumably a DSL would allow you to do more heavy lifting in your specific domain with less tokens.

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

	▲	copperx 29 minutes ago \| parent \| next [-]
		But writing good DSLs requires one to be great at going up the ladder of abstraction. Not that LLMs can't do it, but they stuggle and choose the path of least resistance. That's easier even if it results in more code.
	▲	dang 2 hours ago \| parent \| prev [-]
		I hadn't thought of that! Writing a program in fewer tokens* has been Lisp's advantage all along. If, because of token economics, the same advantage accrued at the LLM level, I dare say certain people would be pleased (as would I): 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

▲

Karrot_Kream 2 hours ago | parent | prev | next [-]

Readability for yourself. I find the biggest issue with lots of LLM assisted development is that the agent harness can generate code faster than I can read it. I'm the bottleneck.

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.

▲

misterchocolat 3 hours ago | parent | prev | next [-]

sure I agree the LLM doesn't need a DSL to get work done. The point is more that the DSL holds the opinions of whoever built the product

▲

UncleOxidant 3 hours ago | parent | prev | next [-]

I think what they're saying is that in CL you create DSLs that are tailored for the domain and that will result in lower token use. Not sure about that claim, would like to see some data to backup that assertion. Wouldn't you then need to supply the LLM with a "programming manual" for this new DSL? Wouldn't that cost tokens?

	▲	invalidOrTaken 3 hours ago \| parent \| next [-]
		sure, but input tokens are way cheaper than output. 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.
	▲	ellg 3 hours ago \| parent \| prev [-]
		im saying the inverse, if your thesis is "cl is the best language for AI" I dont think macros really are a killer feature here I agree with your point

▲

jaggederest 3 hours ago | parent | prev [-]

Smalltalk, in image based systems, absolutely. Erlang not as much, it's more of a "crash the actor and try again" than "rewind, pause, and handle errors in-system"