Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.
This is wrong. k programs aren't really random at all. It's not even that complicated; it has less than thirty primitives. It's a notation for representing ideas, and it excels at that.
Dyalog APL is similarly terse, although less so, and the goal of it isn't to be terse. This criticism still gets thrown at it, and is representative of an unwillingness to accept something that mathematics has known for years: notation isn't golfing, it's a convenient way to express thought.
> This is wrong. k programs aren't really random at all.
The k source code posted around here are certainly more random than a similar byte count of say Java code. Try zipping 1000 bytes of either.
> notation isn't golfing, it's a convenient way to express thought
Sure. But up to a point. And it seems to go beyond pure notation. Check out the interpreter posted here: https://bitbucket.org/ngn/k/
It _requires_ a readme file to explain the file names. That's not convenient by any sensible measure. And the same goes for variable and function names. Take the xml parser[1], "xd". How would a new user know what this did without checking the definition?
How would a new user know what this did without checking the definition?
Why would somebody want to know what it does without checking the definition? The definition isn't complex, and the program can be read and kept in your head in the span of a minute. It's also well-commented.
"one of the main goals of the program is to minimize the program size, in terms of bytes." -> so, you're claiming that code-golf is actually the intended goal?
It seems that there's a fundamental disconnect of values here. It seems to me that you're optimizing for something that's nearly insignificant (to me) at the expense of qualities that actually matter for me and almost everyone else.
In essence, if that code could be modified to take twice as many bytes but allow other programmers to save 10 seconds when figuring out what exactly does 'k' (the first symbol introducing in that raya.k example) means in this context, then it should and even must be done. If there's a tradeoff between program size in bytes and readabilty, then there's no question that program size in bytes should be sacrificed for even small improvents in readability.
That raya-k is an excellent example - it's a nice, terse proof-of-concept, but it's not finished until it's been "ungolfed" for maximum readability (and likely at least twice the code size), and is currently not usable for illustrating the language unless you intentionally want to pick a bad, unoptimal (i.e. heavily optimized for a wrong metric at the expense of important things) example as an illustration. Terseness is nice-to have if all other things are equal, but sacrificing readability to improve terseness is ridiculously maladaptive.
That's because it is. As pointed out repeatedly, one of the main goals of the program is to minimize the program size, in terms of bytes.
Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.