Comment by abainbridge | Hacker News Reader

Comment by abainbridge | Hacker News Reader

Parent Full thread

I think this is a fascinating subject that touches on how human general purpose intelligence works. I've spent decades working with C like languages and by now I find them hugely helpful thinking tools.

I did some optimization work on a bilinear bitmap upscaler recently [1]. There were times in the middle of that work where I felt like I was sitting watching someone else do it for me. Not physically watching, but more like a part of my brain was doing it automatically. The amount of state in scope at once is too big to fit into my working memory (maybe I'm weak at this), so the work has to be symbolic manipulation. It feels like there are patterns in the symbol manipulation that my brain can do with minimal effort. Somehow the result is that I can write (hopefully) correct code that is beyond my ability to comprehend without the notation. The fact that I don't understand how I understand it contributes to the feeling that someone else wrote it for me.

The problem I have looking at APL is that it doesn't look like it would help with this kind of work. The examples in the paper are all mathematical and abstract. I'd like to see some real-world practical examples, where performance matters, IO is fiddly and memory layout is part of the API. And instead of the problem domain being "differentiating a polynomial", I'd rather it was decoding the Huffman data out of a JPEG, or implementing a video game's collision detection system. My feeling is that C like notations are better for that type of thing. Maybe that isn't what APL is supposed to be good at. However, the paper starts by saying APL is needed because maths notation is not universal.

[1] https://stackoverflow.com/a/69633678/66088

One possible reason for me not thinking APL is a good notation is that it seems to avoid assigning names to things. I believe good names are a vital tool for a thinking notation. In my bilinear upscaler example, I was initially struggling to understand the code I had found on the web. The variable names were all things like "x1a", "x2". I changed them to things like "srcX" and "weightX". That helped a lot.

And another: types. They seem to be under emphasised in APL. In my bilinear example the original code had lots of "(pixel >> 8) & 0xff" kinds of things to access the colour components. I created a type to allow those to become "pixel.g". That immediately made the code feel easier to understand. (Pleasingly it made the code run faster too).

Prominent APLers think it doesn't need one. I agree, because APL tries to be close to math, and you don't write types when doing math. You use alternate and overloaded operators.

A video on the topic

https://youtu.be/z8MVKianh54

In math, not only are you dealing with an expectation of a multi year commitment among participants in an academic conversation, but people also either define the terms they use or rely on established culture.

Try writting a Math paper with thousands of expressions and you will see how ergonomic it is for the kind of work we do while programing.

The single-letter variable names and the lack of types (beyond some duck-typing using bold and uppercase) is what makes math so difficult to read (for me). There must be tons of errors in math papers that go undetected just because there’s no type checking.

Ok, but let's not forget that math is written by and for mathematicians and not software developers...

Also, any halfway decent math writers (including those writing for domains that use math, but are not strictly done by mathematicians) also define their terms or provide a context. If you're doing physics, the following is perfectly comprehensible (and is useless if you haven't studied at least a bit of physics):

  x(t) = x_0 + v_0 * t + 1/2 * a * t^2

In a physics book, all of those terms would have been defined prior to that statement, but you wouldn't exclude that equation because it's so useful later on (to actually do calculations with, or to solve for the other elements).

If you take any arbitrary APL program or mathematical statement out of context, it's going to be mostly meaningless. I mean, I can tell you what that does above if I've taken algebra but haven't taken the first couple weeks of Physics 101, but I don't know what it means so it's not useful. That's not the fault of the equation and it shouldn't be discarded just because it needs context to fully understand (either context fully stated with it, or an expectation that you've already studied the topic and so a minimal context can be provided and you can fill in the gaps).

Non-executable, untyped, unverifiable notation is a feature, not a bug, because it makes it harder for a peer reviewer to reject your paper.

Imagine if peer reviewer's pdf viewer put red squiggly lines under invalid formulas and equations...

You're wrong. Pro APLers use descriptive names.

I think probably C is a better fit for the kind of things you're doing. Or is it the other way around? The reference implementation for JPEG is in C, and ease of implementation in C was probably a significant criterion for this and other standards. I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL. I wouldn't say that addition modulo specific powers of two is inherently "practical" or "mathematical", it's just what a CPU provides. APL's not interested.

That said, Rosetta Code has many examples of common algorithms in J, an APL relative. I looked up Huffman Coding there and found a link[0] to an implementation that looks okay. But J's likely to stumble on some JPEG-specific details, and you won't get C-level performance with this sort of code.

[0] https://code.jsoftware.com/wiki/Essays/Huffman_Coding

Excellent link to the Huffman example. I think it will take me a lot of study to grok it. I'll consider investing that effort.

> I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL.

That's why I mentioned "performance matters". Those things are common in algorithms where performance matters. If APL isn't interested, then it isn't good for most algorithmic work. Those operations aren't some quirk of current CPU architecture. It is less work in our universe to do bit shifts than multiplies. And bit packing reduces storage and IO, which also saves work at a fundamental level. The same operations are used in FPGA/ASIC designs where the architecture is much more free. Maybe quantum or analogue computers would change that picture a little but that's not what APL is for.

I'd say the main use for a symbolic thought notation is when working on performance critical stuff. If performance isn't critical then I use a simple algorithm and a simple implementation. Higher level system design stuff is usually better done as diagrams than symbolic notation. I guess when working on a large codebase I'm using the structure of the symbolic programming language to help me think about how distant parts of the code interact. But that doesn't sound like something APL would be good at either.

Reply on news.ycombinator.com