I work with it daily in a bank, and I couldnt find a better way to express it. Many colleagues throwing their keyboard in despair at this stupid impossible to remember syntax.
There are a lot of things in various programming languages which are hard to remember, but k and array languages have such a small surface area, not being able to remember it while working with it daily amounts to learned helplessness.
(source: mostly amateur k programmer, also worked with it in a bank, find it vastly easier to read/write/remember than most mainstream languages)
Not that it's impossible to remember, bit it's definitely contrary to most traditional use of the symbols employed in it, though not without logic. My favorite is the functions from io package, called 0, 1, and 2 (yes, numbers) which handle interaction with stdin, stdout, and stderr respectively. In dyadic form they at least have a colon, but in monadic form they look like plain numbers: 1 "Hello world".
I suspect that to study k (and use kdb) efficiently, you need to actively forget what you knew about the syntax of other languages, and study k as a language from Mars that happens to map to ASCII characters somehow.
It is really easy to remember; it is so small that remembering is the least of the issue. The rest is just using it a lot; I find it readable and nice to work with. Unlike other some other languages we get shoved down your throats.
"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
— Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.
I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes.
For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against.
In a living environment the software lives too, and keeps changing and adapting.
you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare
> There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
> That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to.
I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.
In my experience, the vast majority of problems are insufficiently specified. No matter how well you solve the current problem, there are bound to be certain assumptions you've made about the requirements. And when those assumptions don't hold true, your solution may no longer work.
> What do you mean the input file can't be ISO-2WTF encoded?
Debugging problems is part of maintenance, but a small part. Extensibility is probably a much larger part, and what I think of first when someone says "maintenance".
The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
You could also say that the average bank/company should have learned from previous mistakes doing exactly that for many decades. Select a language that is well tested, understood and supported. Set a limit on cleverness and instead focus on maintainability and simplicity.
If only. In my experience, banks end up building a solution that is maintained by 100 mediocre developers that a reasonably smart developer can't make sense of when it behaves erratically or has extremely poor performance.
Which was precisely my point (and I agree with all the responses in this thread), though my wording and light sarcasm seems to have been a bit too dry, and didn't quite take up as intended.
