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