Comment by geocar | Hacker News Reader

Comment by geocar | Hacker News Reader

Parent Full thread

I'm sorry: It wasn't an intentional dodge. It really was getting late in the day.

Only one person was hostile. They wanted to point out that there was no point in writing it all on one line "just to be unreadable".

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.

I don't think they liked being referred to as beginner programmers because he mentioned that he lectures at Cambridge, so of course they know how to program.

But most people were very encouraging: A lot of people wanted to share something they didn't like about different programming languages, and wanted some ideas about how they can learn more.

I got asked to read some more snippets of code [2] so that people could see this and get a better feel for it.

I got a couple of questions about syntax highlighting and development tools, and if there might be some middle-of-the-road solutions that were terse but not-as-terse.

Also: Beers.

[1]: http://kparc.com/edit.k

[2]: http://nsl.com/k/sudoku/

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

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

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

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

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

> as soon as I saw Arthur's comment, it made sense

Interesting.

I'd like to talk more about this part.

> If so, we could share notes.

Sure. You want to email me your details?

Sure thing. What's your email address?

I don't believe they teach rhetoric as a standard component of one's education anymore. The default position is not one of charity but of doubt. A symptom of our time.

I felt as though you were about to make a very critical point and I would very much like to know what it was.

It's on the tip of my tongue; I'm not yet articulate enough to describe this thought clearly.

I had a go here:

https://news.ycombinator.com/item?id=8476294

I'm still working on it though...

Reply on news.ycombinator.com