It's not an inability. It's just that there's no reason for complexity.
C++, for example, is a language built around managing complexity. k, on the other hand, is a language built around avoiding complexity. SLACK is an actual language! It does all of the things you really need an actual language to do! And yet the implementation's not particularly complex.
bash isn't really at all similar; bash is actually more like Swift or Javascript than k is like bash. bash is for extremely complex programs: programs that are other programs taped together.
k takes the reverse position: there's absolutely no reason you should ever, ever, ever create something complex if a simple solution will do.
If you can create a programming language, an operating system, a windowing system, a database that can handle millions of terabytes of data without flinching, etc. all without complexity, why would you opt for the more-complex solution?
Complexity kills manageability, clarity & fun. Simplicity allows you to do the same things, faster, and without sacrifices.
EDIT:
In some ways, you can consider this very similar to Chuck Moore's philosophy on programming, although taking a different approach to it. I'm paraphrasing here, so forgive me if I get the quote wrong, but something along the lines of 'FORTH will do anything you could possibly want, but it won't do everything'.
If you accept the premise that a language shouldn't be infinite, which isn't particularly controversial[1], it becomes much less of a leap to think, "Wait, why not allow the programmer to expand where they need, and just not throw in what they don't? It'll take less overall cognitive load!"
Now, that's why FORTH is pretty interesting as a language. k, on the other hand, doesn't really lend itself to being expanded (there are solutions to expanding the language itself; many people & companies do). However, it takes the same philosophy externally rather than internally: "We're not going to give you everything, we're going to give you a method of creating anything in a highly-efficient way."
An analogy that I think works fine: k is LEGO to your average programming language's pre-built kits of Lincoln Logs.
[1] This is why Lisp is dead (Common Lisp killed it) and C is still going strong, despite the former being great (except Common Lisp) and the latter being...highly-controversial, and why when a simple Lisp was released it blew up for quite a while despite absolute mismanagement (Clojure).
C++, for example, is a language built around managing complexity. k, on the other hand, is a language built around avoiding complexity. SLACK is an actual language! It does all of the things you really need an actual language to do! And yet the implementation's not particularly complex.
bash isn't really at all similar; bash is actually more like Swift or Javascript than k is like bash. bash is for extremely complex programs: programs that are other programs taped together.
k takes the reverse position: there's absolutely no reason you should ever, ever, ever create something complex if a simple solution will do.
If you can create a programming language, an operating system, a windowing system, a database that can handle millions of terabytes of data without flinching, etc. all without complexity, why would you opt for the more-complex solution?
Complexity kills manageability, clarity & fun. Simplicity allows you to do the same things, faster, and without sacrifices.
EDIT:
In some ways, you can consider this very similar to Chuck Moore's philosophy on programming, although taking a different approach to it. I'm paraphrasing here, so forgive me if I get the quote wrong, but something along the lines of 'FORTH will do anything you could possibly want, but it won't do everything'.
If you accept the premise that a language shouldn't be infinite, which isn't particularly controversial[1], it becomes much less of a leap to think, "Wait, why not allow the programmer to expand where they need, and just not throw in what they don't? It'll take less overall cognitive load!"
Now, that's why FORTH is pretty interesting as a language. k, on the other hand, doesn't really lend itself to being expanded (there are solutions to expanding the language itself; many people & companies do). However, it takes the same philosophy externally rather than internally: "We're not going to give you everything, we're going to give you a method of creating anything in a highly-efficient way."
An analogy that I think works fine: k is LEGO to your average programming language's pre-built kits of Lincoln Logs.
[1] This is why Lisp is dead (Common Lisp killed it) and C is still going strong, despite the former being great (except Common Lisp) and the latter being...highly-controversial, and why when a simple Lisp was released it blew up for quite a while despite absolute mismanagement (Clojure).