Comment by casey2
2 days ago
The bigger problem is that you often end up using more functions, worse algorithms or higher algorithmic complexity, creating your data structure at runtime, since the only datatype you have are arrays.
It's similar to the problem with unix/plan9, lisp or smalltalk. There is it turns out, too much of a good thing.
Such systems are great for learning, but I would make the mistake of building software on them
Common Lisp supports many data structures besides lists, and the same is true of many other Lisps as well.
And Unix is easily the most used family of operating systems on Earth. Every iOS and Mac OS device has a Unix at its core, same with Android, countless computers in data centers running a Linux distribution, probably many other categories of devices as well.
I would hesitate to say building software on Unix is a mistake.
you don't have to represent everything with arrays (k has arrays, dicts, tables, lists)
that said: finding array representations and transformations is usually a great idea for clarity and performance
many problem domains can collapse unnecessary abstractions down to the metal, but many languages and ecosystems make it difficult to "see" when that is the case
array languages have a way of nudging you into fewer abstractions and modeling things in dense arrays where applicable, and you will be surprised how often that is applicable
implementations can be highly efficient and will often make use of SIMD (and other optimizations)
in many cases an idiomatic, simple array language program will beat a naive solution written in C
BQN documentation has a great read on why
https://mlochbaum.github.io/BQN/implementation/versusc.html
the gist is writing in an array language helps because the interpreter has an easier time mapping high level array transformation concepts to optimized vectorized kernels than a C or C++ compiler looking at algol-like code