What Languages is Arthur Whitney Style Code Possible in?
9 points by veqq
9 points by veqq
The goals of modern C-replacements seem exactly opposed to it which really obscures things and mostly results in mocking responses, but I'm curious where else you can do stuff like: https://github.com/kparc/ksimple using macros to succinctly overload core operators into a DSL.
My first guess is "all of them". The essence of Whitney style is to find a set of idioms in the language you are using to write extremely terse code. Macros can be leveraged for this, but macros are not a requirement for writing terse code. APL has no macros. You can write extremely terse code in Haskell without macros, using functional programming idioms, such as point-free programming.
It seems to me that Go would be more challenging, but I'm not a Go programmer, so I'll leave that puzzle to others.
Ruby https://github.com/camping/camping/blob/main/lib/camping.rb
Prolly Common Lisp or at least you can hack de readtable
Jelly is a Golflang it is likely https://github.com/DennisMitchell/jellylanguage
Although my take away from APL is to learn to read code, not scan it.
I wish I had saved the reference, but I remember reading a quite long scanned piece about the history of APL which included samples of code from people who were just starting out, to intermediates, to experts. The beginner code was structured very imperatively, with lots of lines and whitespace. After that the code got terser and terser.
Examples like Whitney's are superexpert. It's someone very knowledgeable levering all the languages features to show how terse it is - because that's the main point of APL/k/q, it's terse[1]. The promise is that terseness == productivity, but there's very little evidence for that, unless you happen to be Arthur Whitney.
[1] yes I know all about how the modern APL descendants are used in finance and helping people there make lots of money. But that's basically the only mainstream usage of the language family.
According to Iverson, the inventor of APL, the original main point of APL was to be Notation as a Tool of Thought. It's a language for humans, for thinking about, expressing and communicating mathematical algorithms.
When I was a teenager, I transitioned from Basic to APL, and wrote a lot of APL in a breezy, imperative style, but I still had access to the full expressiveness of APL, and it was a big step up from Basic. I wrote code that fit my brain, and APL was better for that than Basic.
The APL community seemingly fetishizes super code-golfed Whitney style code. I think that's how you get status and attention on the internet using APL code. And I've read a lot of advocacy about why this is desirable, including Aaron Hsu's essays. But this just feels to me like a social game (and every active language community has dogma and competition and social status games around how you write code). But I care more about notation as a tool of thought, as an accelerator for my thought, and I'd rather write code that fits my brain, and for me that doesn't necessary mean as short and cryptic as possible. The claims that other people make about APL, that extreme terseness is the most important thing, don't necessarily work for me.
fetishizes super code-golfed Whitney style code
Returning to C after forgetting everything, I found his much clearer and easier than other styles. I struggle with many aspects of C, but using simple DSL with fewer foot guns is easy (the names can be better but the primitives are great!) My curiosity's whether the new C-likes can eliminate those foot guns (e.g. by including strings directly) but not require 20x the knowledge I have. But there's certainly sample bias involved!
macros are not a requirement for writing terse code
At least for me, terseness isn't quite the point of that style. Macros remove boilerplate (which writes itself, or which I can't write well like memory management), distilling meaningful decisions. Beta-reduction is also ...the clearest part of C to me, especially versus bit munging and trying to track state in other people's code.
as cryptic as possible
With the macros on one side and the code on the other, constantly moving my head I slowly stop needing to look at the macros. Unfortunately, there's no equivalent help/cheatsheet for why things are named as they are etc. a, w only makes sense from prior APL exposure etc. I am somewhat curious to try to expand out the names of a.h and try to use it with other libraries like k-lib (hilarious name collision).