The thing is if you get rid of the pressure to be notation you get rid of the pressures that makes APL what it is. You could definitely make an array language with words but you'd end up with something more like Factor with it's cleave/spread/apply combinators (you work on a factor inspired concatenative language right?).
Yeah, that’s fair. I don’t imagine such a language would be well liked by the APL/J/K purists (“You’re missing the point!”), just that it could bring the school of thought to the masses—and maybe as a side effect, encourage people to check out the “real deal”. More of a marketing decision than a technical one.
You wouldn’t necessarily have to use explicit dataflow combinators in a wordy array language, but if you did, you might as well go all-in on function-level programming and do a concatenative language. And yeah, I’m working on a Kitten, a CPL with static types—apart from the paradigm and some similar standard APIs, it doesn’t actually have a whole lot in common with Factor; the feel I’m going for is more like postfix OCaml/Rust, whereas Factor is pretty Lispy/Smalltalky.
I don’t imagine such a language would be well liked by the APL/J/K purists (“You’re missing the point!”)
Meh. I'm not interested in code golf. I find it mostly disappointing that discussions of APL and its descendants rarely include anything of substance about the array programming model. Everyone argues about whether the constant-factor size change from glyphs/words is worth it, but what I actually find interesting is the flexible code reuse you get from having every function automatically work on arbitrarily large data.
Exactly, I think the semantics & interactive mode of programming have a lot of value, and it’s a shame they seem to get less attention than they deserve just because the notation is inscrutable to newcomers.
