3 ms·
> I told them I thought the readability was improved by having all the words together, but maybe it made it difficult to learn. I noted Arthur had recently anno
by icsa 12y ago
> I told them I thought the readability was improved by having all the words together, but maybe it made it difficult to learn. I noted Arthur had recently annotated edit.k[1] and asked them if that layout made it easier for beginner programmers to learn to read.
The issue, for me, is not readability but context. Even a word or two (e.g. cuts, begins, dims) helps greatly to establish the context of the code. Like having a map before hiking.
When I write k/q, I use the same layout as Arthur with the additions of comments for each definition on the same line beyond column 80 or 132. Works well for wide monitors.
E.g.
c::a$"\n";b::0,1+c;d::(#c),|/-':b / (c)uts, (b)egins, (d)ims
I've also experimented with folding editors to keep comments above their respective definition while only taking up one line when folded. Some editors (e.g. - jedit) can display the folded text as a tool tip without expanding the fold.
/ Docs
(c)uts
(b)egins
(d)ims
c::a$"\n";b::0,1+c;d::(#c),|/-':b
I hope this is useful or helpful.
- geocar 12y agoIt is interesting. Can you talk more about context? How exactly does it help you? I don't think: c::a$"\n";b::0,1+c;d::(#c),|/-':b / (c)uts, (b)egins, (d)ims is more clear than: c::a$"\n";b::0,1+c;d::(#c),|/-':b Or for that matter: ⚁::⚀$"\n";⚂::0,1+⚁;⚃::(#⚁),|/-':⚂ because they are just symbols to me, and one symbol is as good as another (except for the amount of space they take up on the screen and the ease in recognising it; I don't have many variables named lowercase L).
- icsa 12y agoTL;DR - Map symbols or uses of operators to meanings. Context is semantics/meaning. I.e. - hints, documentation, use case, approach, etc. It's not about the code but the description of the code. The above code is the same, however, the comments loads the basic intentions into my mental cache. I can then read/use the code without having to analyze every definition completely. This is especially helpful for k operators that can be overloaded by type or meaning. E.g. x!y can be create dict, table -> keyed table, keyed table -> table, integer -> enumerated value, ... A hint (outside of the code) helps me out quite a bit. Btw, the code above can be written as: d::(#c),|/-':b::0,1+c::a$"\n" Which seems more clear, given the context.
- geocar 12y ago> I can then read/use the code without having to analyze every definition completely. What does `(c)uts` tell you? I'm not actually familiar with this term. > This is especially helpful for k operators that can be overloaded by type or meaning We know the types of the data when we're tracing the code path. > Btw, the code above can be written as: d::(#c),|/-':b::0,1+c::a$"\n" You should let Arthur know.
- icsa 12y ago> What does `(c)uts` tell you? Cut points (by \n, in this case) if one were to use the cut operator _ to tokenize a by leading \n. It's hint/reminder of the purpose of the definition. N.B. - This feature (i.e. str$chr) is undocumented in k.txt. I would normally use &a="\n". However, as soon as I saw Arthur's comment, it made sense (and uses less memory). > We know the types of the data when we're tracing the code path. My goal is to avoid having to trace the code path and to understand the definition in isolation (or as isolated as possible). E.g. - you were able to add HOME/END functionality for your Mac without understanding the entire code path. > d::(#c),|/-':b::0,1+c::a$"\n" > You should let Arthur know. Will do. He definitely appreciates concision. Btw, I'm using k5 for daily use. Are you? If so, we could share notes.