Comment by vessenes

2 years ago

I have a longstanding fascination with K and other "modern" APL derivatives.

There are a few intersecting truisms about coding that I believe: one is that people's working memory varies: some have an immense amount, some less. Humans definitely process spatially better than in time series (e.g. comparing side by side rather than turning over a page.)

This implies you should prefer succinct code and languages because they are less memory load for engineers working on them.

At the same time, a corollary is that a smaller standard library / language is generally better, in that less needs to be learned by an engineer for full coverage of the language.

Another truism is that some people's processing speed is higher than others, and in general I think of the combination of working memory + speed as roughly equivalent to "g", general intelligence.

K occupies this weirdo place though, because it's absolutely succinct, a very small language as counted by number of atoms supported by the interpreter, and also incredibly hard to scan.

One of the K intros I read mentioned that the language is designed to be something that takes down your thinking; essentially the idea is that the workflow is "drink coffee with fellow PhDs, annotate on the chalkboard, and then when ready, capture it directly." This seems about right to me with my own K/J/Q experiences -- the bulk of the time is spent thinking about structuring a problem solution.

I compare this to go, a language I love for its long-term readability and maintainability, where I spend a lot of time writing boilerplate and dealing with errors in-situ.

At any rate, somehow there's a sort of event horizon of terse solution making where you come out the other side and need a 170 IQ to feel comfortable, and Mr. Whitney lives where he lives, and I live where I live. :)

People complaining about how ugly the C code is here are definitely missing the point: he has bent C's preprocessor to his will in order to encapsulate how he thinks about coding: essentially functional, vectorized. It's using C to write a DSL for solving programming problems interesting to Arthur Whitney.

I think it's fascinating on those terms. In a world where you have to read 10,000 lines of code from 100 developers, the C is terrible, and hard to parse. In a world where you will mostly write code to a style you've honed over 40+ years, it's super expressive, minimal, pared down to what matters, and probably fits his brain perfectly.

22 comments

vessenes

Reply
userbinator  2 years ago

One analogy I like to tell people who are overcome with shock and horror at APL-family languages is to compare it to someone used to Latin-family human languages looking at something like Chinese for the first time --- it's likewise totally "unreadable" at first glance, but then you realise that over a billion people can read and write that language fluently every day, many of which may also struggle with a Latin-family language as they've never seen one before.

I'm not convinced that APL is "incredibly hard to scan" for someone who is familiar with it; it's just a matter of experience. While I'm by no means experienced in APL either, a visually similar thing I did frequently in my younger days was reading x86 instructions not in a disassembler nor hexdump, but displayed as CP437. It was not hard, and I can still remember ┤, PQRS, ═!, and ├ as "MOV AH", "PUSH AX; PUSH CX; PUSH DX; PUSH BX", "INT 21", and "RET" respectively. Here's an example:

    ò║•═!├Hello world!$

Edit: looks like HN swallowed a byte, but you can sort of see what I mean.

  • icsa  2 years ago

    Another analogy

    Would you rather write/read:

    DIVIDE X BY 5 GIVING Y

    or

    y=x/5; / this would be considered "noisy" by C programmers, relative to COBOL

    The first is COBOL (designed to make code easier for "normal" people to read. The second is C/Java/Python/Javascript (which looks more like the math that we learn in grade school).

    k/APL/J simple moves further in the direction of the algebraic notation you already know. The difference is more operations/algorithms.

    When you read the one-character symbols in K as algorithms versus characters, it makes much more sense. In addition, you can read "faster" in k than in other languages, relative to the functionality being expressed.

    When I review C/Java/C++, I print out the source code and write the equivalent k code in the margin. The compression ration is typically 10-20X. Doing so speeds up my work significantly when I go back over the reviewed code.

  • RodgerTheGreat  2 years ago

    As a moderately experienced K programmer, I find K easy enough to "scan". Common idioms immediately stand out as recognizable "words" that are suggestive of what a routine does before you fully parse it:

    @& (filtering)

    @< or @> (sorting)

    @\: (folding)

    ,/ (flattening)

    +\ (a running total)

    etc.

    It's also easy to notice, e.g. in K3, a reserved name like "_f" and immediately know you're looking at a recursive procedure.

    • omaranto  2 years ago

      In what sense is @\: folding? Doesn't it take a list of functions on the left and a thing on the right, and returns the list of values obtained by applying each function to the thing?

  • graemep  2 years ago

    Another is regular expressions. They look entirely incomprehensible if you see one with no prior knowledge, but once you get used to them they are fairly easy to understand.

blibble  2 years ago

my fascination with Q/kdb/K/... disappeared once I had to debug it in production

you want a stack trace? tough luck, you'll get back:

`type

and that's it

  • vessenes  2 years ago

    Oh absolutely. Pg talks at some point about how LISP macros can create a sense of godlike power / mania, and I think there's some of that in APL-land too. The true titans don't need to debug in the traditional sense - a whole program fits on a single screen, they can load it in their head, reason about it, and see what happened.

    Non-titanic engineers accidentally generate bugs in these languages with high "floor" IQ requirements, and debugging someone else's K code is terrible. Debugging your own K code is terrible, not less because when you get help you will feel very, very stupid indeed :)

alfiedotwtf  2 years ago

Awesome comment.

In your opinion, what would be a language that comes closer to K’s functionality but at the same time be understandable to mere mortals?

  • omaranto  2 years ago

    In my opinion, the language that comes closest to K's functionality and is also understandable by mere mortals is K itself. It is obviously extremely close to K's functionality and is a very simple language, the only reason it doesn't seem simple is that most people are used to verbose languages. A couple of days of practice is enough to make K readable, in my experience.

    Also, I am constantly amazed at how concise K is, easily rivaling not only conventional languages but also much larger array languages like APL or J. Arthur Whitney's taste in selecting primitives is out of this world.

  • gsinclair  2 years ago

    I recommend checking out uiua.org for fun. The docs are well written and the concepts, while foreign to most, are ultimately accessible and interesting.

    k and uiua are in different branches of the APL family.

jimberlage  2 years ago

…fits his brain perfectly.

This is super accurate, and interesting in the context of the repo. It’s clearly not the most accessible language or style - I wonder if someone who has hyper optimized for themselves in the way Arthur has can write an effective teaching language. It requires a theory of mind for minds that are probably quite different in the general case.

zozbot234  2 years ago

I don't know about Golang but there are languages where this sort of highly domain-optimized, super terse syntax could be embedded as a domain-specific sublanguage, in a significantly less hackish way than what C allows.

  • vessenes  2 years ago

    I'm not that knowledgeable, and def not a C apologist, but what language are you thinking of? To my eyes, that is some heavy abuse of the preprocessor in a way that I don't think almost any modern "safe" language could possibly countenance.

    I read that code like he got the expressivity benefits of a lisp macro system with close-to-the-metal C speeds in like 100 lines of code. I'm curious what else could do this.