k on pdp11 - Hackdot

Re:k on pdp11 by zozbot234 on Tuesday January 09, 2024 @02:37PM (#38930839)

The nice thing about the "decoded" syntax is that it's extensible - you can design your own operations like "encode" and "reshape". But if you don't care about that, then a terse syntax allows you to read more code at a glance once you've become familiar with it. (Of course APL-like languages have other pitfalls, such as most operators being overloaded based on arity, such that meaning can change completely depending on the context. This is barely acceptable for a "terse" syntax where every operation has to be denoted by a single character but becomes quite silly otherwise.)

[ Parent | on HN ]

Re:k on pdp11 by vidarh on Tuesday January 09, 2024 @03:02PM (#38931230)

Yeah, I experimented with Ruby for it, and frankly I'm not adverse to golfing it down a bit, but I find there is a big gulf between people like me who treats text (whether code or not) as something to skim, find elements of to study in isolation, "zoom in and out" of, and navigate by shape.

I'm extremely picky about syntax and formatting because of how I process code, because even layout and formatting matters for me in how I digest and work with code, and my recall of code is often "visual" in that I remember the shape of different parts of the code I work with.

APL/J/K etc. throw off everything about that for me. I need to sit down and decode symbol by symbol. I get that I'll get faster at recognising them the more I try, but it's too visually compact for me.

On the other end of the spectrum you have at least a subset of users of these languages who see code as something to read symbol by symbol beginning to end with perhaps some referencing back. I get that if you treat code that way, then it's nice for it to be tiny and compact, and it doesn't matter as much whether or not the layout is conducive to skimming and jumping around if that's not how you process code.

The same groups, to me, also seem to correlate with a preference for language vs. maths, though maybe I'm just biased because I'd firmly be in the language camp.

I'm not sure how reconcilable those two ways of reading code really are.

On the other hand, I also deeply care about being able to see the important bits of the code at the same time, and so I tend to spend a lot of time decomposing my projects into small pieces and focus on size more than many "in the language camp", and I guess that's part of the reason why these languages still fascinate me, though I'd have to scratch my eyes out if I had to read code in them on a daily basis.

[ Parent | on HN ]