Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

medium.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#51

Post by gabiteodoru »

rak1507 wrote: post #16
gabiteodoru wrote: post #4

Earlier quoted context omitted.

I agree with you, though in the q world people tend to take it to the extreme, like packing a whole function into a single line rather than a single screen. Here's a ticker plant standard script from KX themselves; I personally find this density makes it harder to read, and when reading it I put it into my text editor and split semicolon-separated statements onto different lines: https://github.com/KxSystems/kdb-tick…

There's a difference between one line and short/terse/elegant. {m:(x,x)#til x*x; r:til[x]-x div 2; 2(flip r rotate')/m} generates magic squares of odd size, and the method is much clearer. This isn't even golfed as the variables have been left.

Do you know which method is this? Euler's by any chance? And do you have an idea how one would prove that it creates a magic square? It's actually one of my inspirations for writing this, the relationship between the code that does something and the proof that the code actually does what it claims. I'd argue an LLM would find the proof helpful if it were asked to generalize an existing function in some way

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#52

Post by bonesss »

nextaccountic wrote: post #25
neprotivo wrote: post #12

This approach of solving a problem by building a low-perplexity path towards the solution reminds me of Grothendieck's approach towards solving complex mathematical problems - you gradually build a theory which eventually makes the problem obvious. https://ncatlab.org/nlab/show/The+Rising+Sea

> you gradually build a theory which eventually makes the problem obvious. Which incidentally is how programming in Haskell feels like

“A good engineer will solve your problem in 5 days. A great engineer will spend 3 days figuring out how to solve it in 2.”

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#53

Post by kelas »

quotemstr wrote: post #19
krackers wrote: post #6

Earlier quoted context omitted.

When Q folks try to write C: https://github.com/kparc/ksimple

Representative example: //!malloc f(a,y(x+2,WS+=x;c*s=malloc(y);*s++=0;*s++=x;s)) //! Reminds me a bit of both the IOCCC and 70s Unix C from before anyone knew how to write C in a comprehensible way. But the above is ostensibly production code and the file was last updated six months ago. 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 perc…

author of the annotated version here.

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

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#54

Post by habitue »

bonesss wrote: post #52
nextaccountic wrote: post #25

Earlier quoted context omitted.

> you gradually build a theory which eventually makes the problem obvious. Which incidentally is how programming in Haskell feels like

“ A good engineer will solve your problem in 5 days. A great engineer will spend 3 days figuring out how to solve it in 2. ”

...and will also have a deeper understanding of the problem that will help solving other problems down the line?

Re: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#55

Post by socketcluster »

ahussain wrote: post #42
socketcluster wrote: post #41

I was kind of taken aback by the author's definition of 'terse'. I was expecting a discussion about architecture not about syntax aesthetics. 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 inventi…

I'd bet a lot of people are trying to optimize their codebases for LLMs. I'd be interested to see some examples of your ASI-unlocking codebase in action!

If you're interested, I added my email to my profile 'about' section. I could try to screen record my next feature development on one of my side projects.

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: Don't Force Your LLM to Write Terse [Q/Kdb] Code: An Information Theory Argument

#56

Post by kelas »

dapperdrake wrote: post #11
krackers wrote: post #6

Earlier quoted context omitted.

When Q folks try to write C: https://github.com/kparc/ksimple

When EAX and RAX take too long to type.

oh no, not really.

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.

Post reply on HN