4 ms·

XML parser: https://a.kx.com/a/k/examples/xml.k https://a.kx.com/a/k/examples/xml.k

by kick 7y ago

kick 7y ago
Ray-tracer: http://www.nsl.com/k/ray/raya.k http://www.nsl.com/k/ray/raya.k
- kick 7y ago
  Graphical spreadsheet application: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm
  - brazzy 7y ago
    With 5 to 10 lines of comment per one line of code, it starts to become readable. You're still left constantly wondering "what do a and x mean in this context, again?" 3/10, would definitely not want to use for any kind of real work.
    - kick 7y ago
      John Earnest links to his tutorial in the Stages of Denial post; if you click it and give it a read, you'll probably understand much easier. But you shouldn't feel pressured to use k: people who advocate for k play the role of a Cassandra who can drown her tears in dollar bills.
      - brazzy 7y ago
        A Cassandra... or a victim of Stockholm Syndrome.
- magicalhippo 7y ago
  So how would this look like if it also needed to handle triangles? And we want textures, so we need texture coordinates and a way to specify per-object materials. Also, the original code just uses bounding spheres, we probably want something better like a kd-tree. In the original code[1] these changes are trivial to make, even for someone new to the code base. How would they look in k? As others I struggle to see past the terseness, but maybe it would make more sense if I could see the program evolve. [1]: https://web.archive.org/web/20070822025008/http://www.ffconsultancy.com/languages/ray_tracer/comparison.html https://web.archive.org/web/20070822025008/http://www.ffcons...
brokensegue 7y ago
is this like a code golf example? or what you expect "good" K to look like?
- kick 7y ago
  Which part do you not understand? In any case, raya.k is quite splendid. Did you check that one out? It's very clean and quite simple. (I linked to it right below that one.)
  - jshevek 7y ago
    The question doesn't imply failure to understand. I'm also curious whether this is considered a good example of k code, which is clear and readable to people proficient in k.
  - brokensegue 7y ago
    literally any of it. I don't know perl but I can read and modify well written perl scripts in a pinch with maybe a little googling. I know several major languages and this program looks like noise to me. is it standard to give functions terrible names? and to not pull out constants to make things understandable? i'm unclear what semi-colons, colons and commas do here or why the lines are so long.
    - magicalhippo 7y ago
      > I know several major languages and this program looks like noise to me. 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.
      - PeterisP 7y ago
        "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.

XML parser: https://a.kx.com/a/k/examples/xml.k https://a.kx.com/a/k/examples/xml.k

by kick 7y ago

XML parser: https://a.kx.com/a/k/examples/xml.k https://a.kx.com/a/k/examples/xml.k

kick 7y ago

Ray-tracer: http://www.nsl.com/k/ray/raya.k http://www.nsl.com/k/ray/raya.k

kick 7y ago
Graphical spreadsheet application: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm
- brazzy 7y ago
  With 5 to 10 lines of comment per one line of code, it starts to become readable. You're still left constantly wondering "what do a and x mean in this context, again?" 3/10, would definitely not want to use for any kind of real work.
  - kick 7y ago
    John Earnest links to his tutorial in the Stages of Denial post; if you click it and give it a read, you'll probably understand much easier. But you shouldn't feel pressured to use k: people who advocate for k play the role of a Cassandra who can drown her tears in dollar bills.
    - brazzy 7y ago
      A Cassandra... or a victim of Stockholm Syndrome.
magicalhippo 7y ago
So how would this look like if it also needed to handle triangles? And we want textures, so we need texture coordinates and a way to specify per-object materials. Also, the original code just uses bounding spheres, we probably want something better like a kd-tree. In the original code[1] these changes are trivial to make, even for someone new to the code base. How would they look in k? As others I struggle to see past the terseness, but maybe it would make more sense if I could see the program evolve. [1]: https://web.archive.org/web/20070822025008/http://www.ffconsultancy.com/languages/ray_tracer/comparison.html https://web.archive.org/web/20070822025008/http://www.ffcons...

brokensegue 7y ago

is this like a code golf example? or what you expect "good" K to look like?

kick 7y ago
Which part do you not understand? In any case, raya.k is quite splendid. Did you check that one out? It's very clean and quite simple. (I linked to it right below that one.)
- jshevek 7y ago
  The question doesn't imply failure to understand. I'm also curious whether this is considered a good example of k code, which is clear and readable to people proficient in k.
- brokensegue 7y ago
  literally any of it. I don't know perl but I can read and modify well written perl scripts in a pinch with maybe a little googling. I know several major languages and this program looks like noise to me. is it standard to give functions terrible names? and to not pull out constants to make things understandable? i'm unclear what semi-colons, colons and commas do here or why the lines are so long.
  - magicalhippo 7y ago
    > I know several major languages and this program looks like noise to me. 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.
    - PeterisP 7y ago
      "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.