In his reply to How long should a name be @darrenwsun raises a point so important it deserves a thread of its own, so I’m promoting it here. Darren wrote:
As a dev using this language and a practitioner of the technology, I'm proud of its unprecedented performance and expressiveness in manipulating data. But when someone from other tech background complain about the steep learning curve and difficulty in reading (most) q code, I usually remain silent: I felt the pain and sometimes I still feel it by "how much succinct one can do something in q with very short names and chaining so many expressions."
Don't get me wrong – the language is beautiful, especially when looked from a mathematical context. It's just that q lives in an era/ecosystem where a complex system usually involves multiple languages/stacks and the others adopt a very different perspective towards what it means by readability/clean.
When I joined the ranks of APL instructors years ago it was well known that students learned APL faster if they had not been exposed to other programming languages. (Ken always warned against confusing unfamiliar and difficult.)
Back in the day, we took that as evidence of the superiority of his notation. Other languages were rubbish! One day all software would be written in APL.
Nowadays we know better. (I have written an application GUI in APL and I intend it to remain a once-in-a-lifetime experience.)
We need to be polyglots. Nothing bad in that: humans have been polyglots since the Old Stone Age. (Only in recent centuries have linguistic communities grown large enough to host monoglots.)
Which leaves us with the barrier of the unfamiliar. Q widened access to kdb+ by letting users exploit their knowledge of SQL. KX Insights is going further by providing access through Python and Web UI. But for those who need to write in q there remains the transition from what (in a recent ArrayCast episode) Joel Kaplan called the one-potato-two-potato approach to – what shall we call it – vector thinking?
Vector thinking focuses on list operations. But Darren is right: the journey from one-potato-two-potato may be exhilarating but it it is not trivial.
A recent article in the RSA Journal on lifelong education stresses the challenge of “unlearning” as part of learning new skills. So here’s my question.
What helped you learn vector thinking?
Last year I led an online workshop on vector thinking. We explored vector solutions in q to a small but non-trivial problem. Participants found it helpful, and I promised to hold another one. Perhaps it’s time? (Respond here to encourage me.)
Hah thanks for the quote, but I feel like you might get me wrong...
Vector thinking/programming is a beauty of the language, and that's a big part of where q's unprecedented performance comes. In this aspect, it's superior than many other popular languages. It took me a while to think vector-ly, but it's worth.
A major part of the learning curve though, mentioned via the previous reply, is coding style. For example, personally I'm not convinced nph is named better than nanosecondsPerHour. Having said that, I'm well aware that there is no point arguing which code style is better. I intended to share a perspective that it's not uncommom for a q dev to also work in other languages, and that sticking to so vastly different styles has its own mental cost (and it's not small).
Yes, I had missed your point: reading a different coding style adds to the effort already required to learn vector thinking!
You found the journey worth the fare, anyway. Me too. And, having made it, I write better code in other languages.
I wonder, can you tell us about anything that helped you learn vector thinking?
Tel: +44 (0)28 3025 2242
Tel: +1 (212) 447 6700
Tel: +61 (0)2 9236 5700