21–30 of 56 posts
LLMs were created to use the same interface as humans (language/code). 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.
> Let’s start with an example: (2#x)#1,x#0 is code from the official q phrasebook for constructing an x-by-x identity matrix. Is this... just to be clever? Why not (!x)=/:!x aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.
q)x:1000
q)\t:1000 sum (til x)=/:(til x)
889
q)\t:1000 sum (til x)=/:(til x)
871
q)\t:1000 sum (2#x)#1,x#0
602
q)\t:1000 sum (2#x)#1,x#0
599
LLMs were created to use the same interface as humans (language/code). 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.
Use the tool according to how it works, not according to how you think it should work.
LLMs were created to use the same interface as humans (language/code). 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.
Do you swing a nailgun? 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.
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
Which incidentally is how programming in Haskell feels like
LLMs were created to use the same interface as humans (language/code). 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.
Disagree. If some small adjustments to your workflow or expectations enable you to use LLMs to produce good, working, high-quality code much faster than you could otherwise, at some point you should absolutely welcome this, not stubbornly refuse change.
Earlier quoted context omitted.
Do you swing a nailgun? Use the tool according to how it works, not according to how you think it should work.
Chances are hell is going to freeze over before people start writing verbose q code. Q being less verbose than alternatives is the whole point. Nobody is feeling any pressure to bend over backwards to accommodate the guy who struggles to get by when his LLM can't explain a piece of code to him. To use your nailgun analogy as an example: Waddling in with your LLM and demanding the q community change is like walking in…
I could be wrong. Time will tell.
> Let’s start with an example: (2#x)#1,x#0 is code from the official q phrasebook for constructing an x-by-x identity matrix. Is this... just to be clever? Why not (!x)=/:!x aka. the identity matrix is defined as having ones on the diagonal? Bonus points AI will understand the code better.
The vibe I get from q/kdb in general is that its concision has passed the point of increasing clarity through brevity and is now about some kind of weird hazing or machismo thing. I've never seen even numpy's verbosity be an actual impediment to understanding an algorithm, so we're left speculation about social and psychological explanations for why someone would write (2#x)#1,x#0 and think it beautiful. Some brief n…
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…
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.
> I think the aesthetic preference for terseness should give way to the preference for LLM accuracy, which may mean more verbose code 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.
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…
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()