[xelxebar]

The author is clearly a novice who has just tinkered with array languages a little. Extrapolating from that to absolute properties of a tool seem a bit overeager, don't you think? For example, do you think you could design a legible analog circuit without significant time learning the craft?

My experience is with APL, but I think it is capable of producing some of the most readable and maintainable codebases out there. I've worked for years in various projects using Python, Java, C, Scheme, and a smattering of many other languages. However, it's really hard to overstate the clarity that comes from data-oriented design and dogged elimination of API boundaries.

It just takes a long time to learn to write good software in good APL style. In many ways all the in vogue best practices these days around declarative and functional programming tend to work antithetically to writing good array code. This means that the learning curve for experienced programmers is, perhaps paradoxically, higher than that of a totally naive beginning coder.

I really wish I knew some way to directly convey the experience of working with APL at a high level. There's really nothing else much like it.

[jcmorrow]

> My experience is with APL, but I think it is capable of producing some of the most readable and maintainable codebases out there.

Cool! Do you have any public examples to point to? I would be curious to see how a larger project looks, given that I only use array languages for side projects, so my code is often not very legible (e.g. https://github.com/jcmorrow/advent_of_code/blob/master/day_2...).

[xelxebar]

My YAML loader[0] is a condensed example of the architecture and techniques I'm thinking of. It's a couple years old, so the code is dirty by my current standards, but the couple of times I've gone back to read it, I have found the YAML-specific concerns to be quite salient.

That said, it's specifically written for an audience that is familiar with YAML detail in particular, parsing more generally, and of course APL expressions of ideas. In fact, that is a big part of what makes the code readable and maintainable: it is optimized for communicating to the expert worker not for on-boarding new developers. The latter is more appropriately handled via other means IMHO.

The poster child for this style of APL is Co-dfns[0]. It's a production APL compiler and a much larger example of the code I'm talking about. The entrypoint to read is cmp/PS.apl.

If you're interested, I'm willing to have a chat and talk more about what makes this kind of APL imminently workable, in which case there are also some personal private examples I could share as well. Feel free to reach out to the contact info on my profile here.

[0]:https://github.com/xelxebar/dayaml/blob/master/Y.apln.

[1]:https://github.com/Co-dfns/Co-dfns

[rak1507]

You won't get anything from vapourware salesmen.

[rak1507]

It seemingly takes a long time to write good software too, co-dfns is infinity+1 years in progress...