Live data from Hacker News

Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

medium.com

81–90 of 154 posts

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#82
Cognitive load in LLMs: When LLMs are faced with syntactic complexity (Lisp/J parentheses/RL-NOP), distractors (cat facts), or unfamiliar paradigms (right-to-left evaluation), the model’s performance degrades because its "attention bandwidth" is split or overwhelmed. This mirrors human cognitive overload.

My question: is there a way to reduce cognitive load in LLMs?, one solution seems to be process the input and output format so that the LLM can use a more common format. I don't know if there is a more general solution.

Edit: Cat attack https://the-decoder.com/cat-attack-on-reasoning-model-shows-...

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#83

Cognitive load in LLMs: When LLMs are faced with syntactic complexity (Lisp/J parentheses/RL-NOP), distractors (cat facts), or unfamiliar paradigms (right-to-left evaluation), the model’s performance degrades because its "attention bandwidth" is split or overwhelmed. This mirrors human cognitive overload. My question: is there a way to reduce cognitive load in LLMs?, one solution seems to be process the input and out…

Isn't the whole idea of Lisp that there is _no_ syntactic complexity? Lisp programs are roughly a serialized AST.

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#84
post #35

Earlier quoted context omitted.

APL was designed as a notation for math; if you pronounce it properly, it makes more sense than numpy: The 10 by 10 reshaping of counting to 100

Numpy: Counting to 100, then reshaped to 10 x 10. Doesn't really seem all that different to me.

It’s not very different, but it’s the numpy way is not the math way: when you talk math, you say “the exponent of the absolute value of the cosine of x”, like in APL, not “take x, get its cosine, then take the absolute value, and then get its exponent”

In fact, for many things, you so the math way in numpy as well. But in other things, the dot/object-oriented way is preferred.

APL is just consistent, terse, mathematical notation.

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#85

Cognitive load in LLMs: When LLMs are faced with syntactic complexity (Lisp/J parentheses/RL-NOP), distractors (cat facts), or unfamiliar paradigms (right-to-left evaluation), the model’s performance degrades because its "attention bandwidth" is split or overwhelmed. This mirrors human cognitive overload. My question: is there a way to reduce cognitive load in LLMs?, one solution seems to be process the input and out…

Isn't the whole idea of Lisp that there is _no_ syntactic complexity? Lisp programs are roughly a serialized AST.

[deleted]

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#87
post #85

Earlier quoted context omitted.

Isn't the whole idea of Lisp that there is _no_ syntactic complexity? Lisp programs are roughly a serialized AST.

[deleted]

I'm not disputing that LLMs are bad for Lisp code, I'm just saying I don't think "syntactic complexity" is a correct explanation for why that is.

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#88

Cognitive load in LLMs: When LLMs are faced with syntactic complexity (Lisp/J parentheses/RL-NOP), distractors (cat facts), or unfamiliar paradigms (right-to-left evaluation), the model’s performance degrades because its "attention bandwidth" is split or overwhelmed. This mirrors human cognitive overload. My question: is there a way to reduce cognitive load in LLMs?, one solution seems to be process the input and out…

Isn't the whole idea of Lisp that there is _no_ syntactic complexity? Lisp programs are roughly a serialized AST.

I usually use deepseek (gratis) for code, and when using defun and let it usually lacks one (or more) closing parenthesis. So the way to mark the end is not well understood by this LLM, or perhaps that the height of the AST is usually bigger than in python.

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#89
post #50

Another example of this is Claude placing unnecessary imports when writing Python, because it's hedge-importing modules that it suspects it might need later.

Is it hedging or did the training data just have lots of unecessary imports?

You already know the answer. Claude is not an intelligent sentient thing.

Re: Why LLMs Can't Write Q/Kdb+: Writing Code Right-to-Left

#90

Cognitive load in LLMs: When LLMs are faced with syntactic complexity (Lisp/J parentheses/RL-NOP), distractors (cat facts), or unfamiliar paradigms (right-to-left evaluation), the model’s performance degrades because its "attention bandwidth" is split or overwhelmed. This mirrors human cognitive overload. My question: is there a way to reduce cognitive load in LLMs?, one solution seems to be process the input and out…

Isn't the whole idea of Lisp that there is _no_ syntactic complexity? Lisp programs are roughly a serialized AST.

Agreed, Gleam as a language has very few, generalized syntactic constructs compared to most procedural languages. There's enough of a signal in the data to be able to answer queries about the language; but when writing, LLMs universally trip over themselves. The signal from other nearby languages is too strong and it ends up trying to do early returns, if statements, even loops on occasion.
Post reply on HN