Don't Force Your LLM to Write Terse [q/kdb] Code: an Information Theory Argument
Posted3 months agoActive2 months ago
medium.comTechstory
calmmixed
Debate
80/100
Large Language ModelsProgramming LanguagesCode Quality
Key topics
Large Language Models
Programming Languages
Code Quality
The article argues that LLMs may struggle with terse code, using Q/Kdb as an example, and sparks a discussion on the trade-offs between code terseness and LLM accuracy.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
31
Day 7
Avg / period
7.6
Comment distribution53 data points
Loading chart...
Based on 53 loaded comments
Key moments
- 01Story posted
Oct 13, 2025 at 8:44 AM EDT
3 months ago
Step 01 - 02First comment
Oct 13, 2025 at 10:09 AM EDT
1h after posting
Step 02 - 03Peak activity
31 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 27, 2025 at 4:59 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45567746Type: storyLast synced: 11/20/2025, 3:10:53 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
* LLMs don't understand the syntax of q (or any other programming language).
* LLMs don't understand the semantics of q (or any other programming language).
* Limited training data, as compared to kanguages like Python or javascript.
All of the above contribute to the failure modes when applying LLMs to the generation or "understanding" of source code in any programming language.
I use my own APL to build neural networks. This is probably the correct answer, and inline with my experience as well.
I changed the semantics and definition of a bunch of functions and none of the coding LLMs out there can even approach writing semidecent APL.
From what I understand, the terseness of array languages (Q builds on K) serves a practical purpose: all the code is visible at once, without the reader having to scroll or jump around. When reviewing an LLM's output, this is a quality I'd appreciate.
this is not writing in assembly, and definitely not in bytecode.
but if you are indeed an elite intel(R) assembly coder, and old enough for eax and rax to have taken too much toll on you, or your time away from your family, and of your career as a computer programmer in general - you should probably consider a more modern, more simple and elegant isa, which is now omnipresent, royalty-free, has a huge encoding margin for custom extenstions, and spares you from the childhood trauma of 16 GPRs. it is called riscv.
k family languages isn't asm. it doesn't expect you to hardly ever need anything other than x,y,z in terms of function arguments. this is why they are so conveniently implicitly auto-declared for you in your function - just reference them, done.
it is useful, man. it works.
Is there some kind of brain surgery you have to undergo when you accept the q license that damages the part of the brain that perceives beauty?
Whitney kind of set the stage for this but it got adopted informally as a style by the people at IPSA (I. P. Sharp Associates) and spread throughout the industry.
Whitney style C isn't great for everything but it's not bad for interpreter writing and other text/stream touching tasks.
> representative example
this is grossly taken out of context (which is explicitly stated at the very top of the corresponding readme, https://github.com/kparc/ksimple).
ioccc is often brought up in such HN rants, but the comparison is off mark completely. if you can't read this, you're better off writing some python or some such. this works exactly because it is not obfuscated. this code can't be more regular. tripwires (lack of malloc errno check, possible overflow of refcount) are given as exercises.
> Is there some kind of brain surgery you have to undergo when you accept the q license that damages the part of the brain that perceives beauty?
this code has absolutely zero to do with commercial system k4/kdb+, where did you get that idea? this is published under MIT license. would you like to be reminded of the terms, or fancy an explanation of what they mean? all of them implicitly state that if you're unhappy with the terms you're very welcome to walk away.
hopefully, no brain surgery required for you, god forbid. just an open mind, in methaphorical sense, healthy sense of humour and common sense that the less you type the more you think.
you are also welcome to share examples of code which tickle your sense of beauty, authored by you or someone else.
now, stand straight and defend your argument. we're all ears.
1 line should do 1 thing - that's something C has established, and I realized that putting conceptually different things on the same line destroys readability very quickly.
For example if you write some code to check if the character is in a rectangular area, and then turn on a light when yes, you can put the bounds check expressions on the same line, and most people will be able to read the code quickly - but if you also put the resulting action there, your code readability will suffer massively - just try it with some code.
That's why ternary expressions like a = condition? expr1: expr2 kinda controversial - they're not always bad, as they can encode logic about a single thing - if said character is friendly, turn the light color should be green, otherwise red - is a good example - but doing error handling there is not.
I haven't been able to find any research that backs this up (didn't try very hard tho), but I strongly believe this to be true.
A nice thing is that some other principles, like CQRS, can be derived from this, for example CQRS dictates that a function like checkCharacterInAreaThenSetLightState() is bad, and should be split up into checkCharacterInArea() and setLightState()
An important question for this also is what qualifies for "single thing"; you can look at a "for (int i = 0; i < n; i++) sum += arr[i]" as like 5 or more things (separate parts), 2 things (loop, body), or just one thing ("sum"). What array languages enable is squeezing quite a bit into the space of "single thing" (though I personally don't go as far as the popular k examples of ultra-terseness).
- iterate through the array arr,
- sum its elements
of course, since C is a low level language, implementation details seep in there but those are the 2 major logical concepts that mentally can be quickly parsed as a single unit each.
Some languages allow reductions on collections, so the actual iteration becomes logically part of that single unit, so it might count as one, but I'd say that's the absolute upper bound of complexity you should stuff into a singlwe line.
The goal here is to make every statement conform to a template so that your brain quickly recognizes it and you can move on, rather than you having to break it apart bit by bit to figure out the goal.
Human language has roughly, say, 36% encoding redundancy on purpose. (Or by Darwinian selection so ruthless we might as well call it "purpose".)
The purpose is being understandable by a person of average intellect and no specialized training. Compare with redundancy in math notation, for example.
The purpose probably is keeping human speech understandable through the often noise-filled channel of ambient sound. Human speech with no redundancy would have a hard time fighting the noise floor.
It’s a bizarre language.
https://ncatlab.org/nlab/show/The+Rising+Sea
Which incidentally is how programming in Haskell feels like
Is this... just to be clever? Why not
aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.Some brief notations make sense. Consider, say, einsum: "ij->ji" elegantly expresses a whole operation in a way that exposes the underlying symmetry of the domain. I don't think q's line noise style (or APL for that matter) is similarly exposing any deeper structure.
Asking humans to change for the sake of LLMs is an utterly indefensible position. If humans want terse code, your LLM better cope or go home.
I see no reason to believe LLMs can write working let alone good or high-quality code, nor that the adjustments to my workflow or expectations will be small. But sure, if such a thing happened, I would probably welcome it.
Meanwhile, there are people who write good and high-quality working code faster than me, and they all write as much as possible on one line with the most bare-bones of text editors, so I will continue to learn from them, rather than the people who say LLMs are helping them. Maybe you should reconsider.
Use the tool according to how it works, not according to how you think it should work.
To use your nailgun analogy as an example: Waddling in with your LLM and demanding the q community change is like walking into a clockmaker's workshop with your nailgun and demand they accommodate your chosen tool.
"But I can't fit my nailgun into these tiny spaces you're making, you should build larger clocks with plenty of space for my nailgun to get a good angle!"
No, we're not going to build larger clocks, but you're free to come back with a tiny automatic screwdriver instead. Alternatively you and your nailgun might feel more at home with the construction company across the street.
I could be wrong. Time will tell.
This assertion is intuitive, but it isn't true. Per-token entropy of the long proof can be larger if the long proof is not minimal.
For example, consider the "proof" of "list the natural numbers from 1 to 3, newline-delimited." The 'short proof' is:
"1\n2\n3\n" (Newlines escaped because of HN formatting)
Now, consider the alternative instruction to give a "long proof", "list the natural numbers from 1 to 3, newline-delimited using # for comments. Think carefully, and be verbose." Trying this just now with Gemini 2.5-pro (Google AI Studio) gives me:
"# This is the first and smallest natural number in the requested sequence.\n 1
# Following the first, this is the second natural number, representing the concept of a pair.\n 2
# This is the third natural number, concluding the specified range from 1 to 3.\n 3"
We don't have access to Gemini's per-token logits, but repeating the prompt gives different comments so we can conclude that there is 'information' in the irrelevant commentary.
The author's point regains its truth, however, if we consider the space of all possible long proofs. The trivial 'long' proof has higher perplexity than the short proof, but that's because there are so many more possible long proofs of approximately equal value. The shortest possible proof is a sharp minimum, but and longer proofs are shallower and 'easier'.
The author also misses a trick with:
> Prompted with “Respond only with code: How do you increment i by 1 in Python?”, I compared the two valid outputs: i += 1 has a perplexity of approximately 38.68, while i = i + 1 has a perplexity of approximately 10.88.
… in that they ignore the equally-valid 'i = 1 + i'.
While setting this up, I realized I hadn't used chat templates in my original measurements (rookie mistake with an Instruct model!). Re-running with proper methodology completely flips the results - the terse version actually wins.
I'll add a correction note to the article once AWS/Medium comes back online, and will write a proper follow-up with all the corrected experiments. Your comment literally made the research better - thank you!
https://pastebin.com/VVT74Rp9
Personally I don't like short variable names, short function names or overly fancy syntactical shortcuts... But I'm obsessed with minimizing the amount of logic.
I want my codebases to be as minimalist as possible. When I'm coding, I'm discovering the correct lines, not inventing them.
This is why I like using Claude Code on my personal projects. When Claude sees my code, it unlocks a part of its exclusive, ultra-elite, zero-bs code training set. Few can tap into this elite set. Your codebase is the key which can unlock ASI-like performance from your LLMs.
My friend was telling me about all the prompt engineering tricks he knows... And in a typical midwit meme moment; I told him, dude, relax, my codebase basically writes itself now. The coding experience is almost bug free. It just works first time.
I told my friend I'd consider letting him code on my codebase if he uses an LLM... And he took me up on the offer... I merged his first major PR directly without comment. It seems even his mediocre Co-pilot was capable of getting his PR to the standard.
I'm also kind of interested to see how others use LLMs for coding. I can speak for myself having worked on both good and bad code-bases; my experience is that it works MUCH better on those 'good' codebases (by my definition).
Re-running with proper methodology completely flips the results - the terse version actually wins. I'll add a correction note to the article once AWS/Medium comes back online and will write a follow-up with the corrected experiments.
This is open science working as intended - community scrutiny improves the work. Thank you all for the engagement, and especially to Majromax for the challenge that led to discovering this!
> Due to a global hosting outage, Medium is currently unavailable. We’re working to get you reading and writing again soon.
> — The Medium Team
Dang.