This seems like a really weird thing to optimise for - would you mind saying more? I've never found myself thinking "man, I wish my function could _do more_".
> This syntax is very readable.
Objectively, by any measure, this isn't true.
Every summer we spend about a week training interns with K, and they proceed to read, modify and write real production code with it during their tenure. Interns come from a mix of backgrounds- computer science, various engineering degrees, etc. This seems compelling evidence that K is learnable.
If you find K unreadable, consider spending a week or two seriously working with it. You might be surprised how you feel afterwards.
Right, but the one follows from the other.
I'm passingly familiar with K, Q, and a+. I've worked with Borror and I kind of own an a+ compiler. I think if you define "readable" to mean "you can learn it with two weeks intensive tuition" the fine, yeah, it's readable. But to me, lightning-fast speed doesn't make up for terse-to-the-point-of-dumb syntax.
+/&~&/(!1000)!/:3 5
Some time ago I built an environment for livecoding graphics experiments with K, and the concision of the syntax makes it delightfully easy to experiment and make changes as I build up programs piece by piece. Here's a recording I made which illustrates all the intermediate steps of a simple way to draw a Voronoi diagram:
https://i.imgur.com/YZkYyDs.gif
K notation is a powerful medium of communication when I'm whiteboarding ideas with coworkers, scribbling on a napkin, or tapping an idea into my phone on the subway. I don't write K because I think doing so paints me as some sort of Ubermensch, I write K because I find it crisp and beautiful; An elegant K solution to a thorny problem is poetically satisfying!
No, but I also don't find myself wishing the entire project read like regex does. "If only our entire suite of enterprise software was made up of regexes..."
I use k/q on and off and after a couple of weeks away, you basically need to relearn it. The massive advantage of R and Python is even after time away, it’s still perfectly legible.
Breaking stuff down costs, as well - you have to make it clear how something is going to be used. You might write a helper function for one bit in particular, and then rely on additional levels of abstraction to make it clear how this function should be used.
Instead, if you can allow your functions to become semantically larger, you don't need to explain and protect your modularisation. Helper functions with one use are inlined (it's very common that these things have names longer than their definition). Instead of a large tower of abstraction, you just have two levels: the level of the data, and the level of the problem. Your entire program is written as functions, each of which does something in the problem domain, and for each, each definition is immediately clear about what it is doing with the data.
There was an article here, a while ago, called 'smaller code, better code', and with accompanying comments, that explain this better than I can.
Readability is relative. It's a category error to speak of it without saying who the reader is. Is Sanskrit readable?
Completely disagree, and I think the people spending the 2010's clearing up screeds of idiomatic perl 5 would side with me :)
Point being that translating from unfamiliar syntax to familiar is always a challenge.