← Back to context

Comment by gsf_emergency

3 months ago

Of all the non-esolangs (=exolangs?) APL+kith seem to be almost designorismic/estuarine (formerly, Riverian) beasts..

In your informed opinion, how would it make sense to be thrilled thinking about (not just a semi-dynamic APL (=S-DAPL?) as above but) designing

  a APL-kith for widespread adoption by BOTH (demoscenic)gamecoders & Analysts (the academic variety)???

Specifically, which of the sneering checklist items[0] would be killer to cross off?

[0] https://www.mcmillen.dev/language_checklist.html

(Note in particular that the very APL inspired Wolfram has monopoly with physicists BUT does nothing for engineers

https://www.stephenwolfram.com/media/physics-whiz-goes-into-...

1988

>“But we tricked him, so to speak,” says Nobelist Murray Gell-Mann, who helped to bring Wolfram west. “We gave him a Ph.D.” )

Well, I'm thrilled by something in the neighbourhood, but your widespread adoption there is more a "well known in small circles" kind of thing: instead of selling shovels to the gold miners, the target of demosceners+analysts sounds like selling paint brushes to the garret-dwelling artists?

For me, I guess the killer checklist item is "[X] Programming in this language is an adequate punishment for inventing it".

For this putative APL-kith, I'd guess the combination of "[X] You require the compiler to be present at runtime [X] You require the language runtime to be present at compile-time" would be killer; after all wirth-style compilers, these days, can run out of L1$. However, does sufficient staging run into the "fewer than 100 programmers un-algoled* enough" problem?

(could relative popularity of the square bracket language be because phykers display formulae in order to convey insights, but for imkers the calculations are their own point?)

* on the "[X] Rejection of orthodox systems programming without justification" front, what might be to algol-inspired programming as Thistlethwaite's algorithm is to plain old cube solving? https://news.ycombinator.com/item?id=42426716 instead of reducing the group operators as one proceeds, one would reduce the dynamism as the loops nested... (one of the things I find impressive about the rpython JIT is that it roughly manages to implicitly do that reduction!)