Absolutely I agree. K and APL like languages have an excellent philosophy. I've found that you can carry this philosophy over to a lot of other languages as lon

Absolutely I agree. K and APL like languages have an excellent philosophy. I've found that you can carry this philosophy over to a lot of other languages as long as they have some respectable level of composability. Going on a bit of a tangent but I feel like just about the entirety of software divides fairly cleanly into five cases more or less regardless of the scenario. The first case is scripting for automation or duct taping services together. Shell scripts are more or less ubiquitous so they serve the purpose well. The second case is application scripting DSLs. These are definitely oriented towards an end-user and most likely need to be usable without too much prior programming experience. These end up much like the first case where they end up serving as a high level duct tape. If possible non turing complete DSLs should be preferred or if something fully featured is absolutely necessary, something like lisp or lua or possibly even a prolog-like language works well. The third case is data based programming. This covers most of the "interesting" code that people write. I'd argue that this applies to any ML, control theory, data processing, compilers, graphics applications, and other algorithmic code. This is arguably best suited to APL-like languages(functional and array based). The only exception to this would probably situations where encoding properties into a type system could prove useful. Things like differentiable programming benefit from this and APL like languages don't really have the tooling to handle these cases as far as I'm aware. The fourth case is user interface, hardware abstraction, and/or systems programming. I'd argue that low level languages with strong type systems and zero cost abstractions like Rust or Boost/Metatemplated C++ cover almost all of these cases. Being able to encode formal properties into the system through variable bounds, Hoare logic, and state machines while still being able to interact in a "low level" way is extraordinarily useful. Surprisingly in this sense, creating a user interface is very similar to interfacing with hardware over SPI, I2C, USB, etc. The fifth case is quick and dirty prototyping. The languages in the prior cases work perfectly fine for this but sometimes the very high level duck typed languages such as lisp, lua, and python end up being easier for when just trying to flesh out an idea. I'd argue that this case shouldn't see production and should really only be used for prototyping and academic work. Rant over. I definitely think APL derived languages need to make a resurgence as they could definitely improve the ergonomics, readability, and reliability of developing the "interesting" stuff which is honestly the class of application that desperately needs this.