Hacker News Reader

Comment by notafraudster | Hacker News Reader

This is concise in a sort of code golf way, but not substantially faster to write than equivalent R code -- I chose R because math operations are natively vectorized and the basic data type is a vector, and because the language has a user-friendly REPL -- would be, and certainly less readable. I read the linked K documentation and it seems like much of K's syntax was motivated by wanting to get away from "the programmer way of doing things", but the lack of readability would seem to get in the way of that.

Still neat as a toy exercise using what seems like a fun little micro-language.

View on HN

Not really to purposefully be different. If you know the history of APL and K it was to originally make a better and more unified math notation. Both have been in production for a long time (APL since like the 60s and K's original version was 90s)

Both R and APL/K are great for data science and have great tools. I wouldn't call either a toy (not sure if you were just referring to this particular task or the technology in general). K is commonly used in kxsystems's kdb+ product and deep pocketed quants pay top dollar for it.

K is being used in the financial market for at least 25 years, having been dominant through most of this time. It's certainly not a toy language.

Although I'm not a K programmer (I've done some J in the past), the point that K programmers make is that the code IS readable once you get used to it. One of the benefits commonly mentioned is that you can keep the whole program in your mind at once. I can't do that with my own Go and Python programs :)

But with proper code, you shouldn't need to keep the whole program in your mind at once. You need the high-level overview, but the pieces shouldn't require you to know the details about "far away" code.

And yet, they do. We as developers are so bad at building and maintaining abstractions that maybe we should just do away with most of them. I'm not convinced that layers upon layers of abstractions even help at all; K's approach of destroying abstractions is probably a better way to program. I think we've hit an inflection point in the last 10 or 20 years where the stack is so complex that absolutely no one can understand it. This is a natural consequence of abstraction: it never stops and is self-justifying. It's possible that we just need to stop creating "elegant" class hierarchies or free monad or whatever and just write some compact, blazing fast, and unabstracted code. k/q is interesting because it doesn't even really have the tools to create abstractions, so you're forced to actually solve the problem at hand from the get-go. And when you do solve said problem, you realize it's 10x shorter than the abstracted program, all fits on one screen, and is even easier to understand. Once you reach that point, you start to question whether current development practices are just cargo-culting.

At work our program is about a million lines of code (plus third party libraries etc). We've got 124 different customer specific file/data integrations. Most of those integrations are file based, and the majority of them also involve us fetching or uploading via HTTP or (S)FTP.

Doing low-level file I/O, socket I/O, handling low-level HTTP and FTP code for each one that needs it, parsing XMLs from scratch five dozen times, doing all those integrations without abstractions... how is that an improvement?

And reducing line count by a mere 10x would do nothing for keeping it all in the head at one time. Even if you could get it down by 1000x, I don't think you'd accomplish much because the logic still has to be there.

Chuck Moore, the creator of Forth, created a CAD system for microelectronics with a tiny fraction of code that mainstream products required.

With our bloated stacks, the most used CPU instructions that our binaries use are the ones moving data. We are not using the computers to compute, but just to move data around. That just feels wrong. K, APL, Forth and the likes are living proofs that there are other ways to solve complex problems.

> We are not using the computers to compute, but just to move data around. That just feels wrong.

That is because moving data around is a very useful thing.

In fact, our entire product is almost entirely about moving data.

Using it, our customers don't have to move data by hand. They don't have to look at invoices and fill in forms with a pen, put those in an envelope and send it to the government.

Instead our product can do that. And it can be smart about which data to move, when to move it, and where to move it. That's where the small bit of computation comes in.

Do you consider add(a,multiply(b,c)) certainly more readable than a+b*c?

The article shows some nice k idioms that I find much more readable written in a concise form. For example, I find |^... easier than reverse(sort_ascending(...)), or <>... easier than grade_down(grade_up(...)). I guess the solution in other languages would be to define more functions for all these common operations, but then you will need much more documentation for all these extra functions and learn them, so I don't see it as an improvement.

At difference of most golfing languages, the set of k primitives is very small. Many people who criticize k forget that property, but it's a very important one. It would be interesting to see the R version and compare the amount of documentation you need to read to completely understand what each of the programs is doing (ie. to read the program). That would be, in my opinion, a better measurement of readability than a subjective opinion (unfortunately, the k9 documentation is too scarce at this point to make this exercise in a proper way).

Yes. When each function is a single character [1], juxtaposition is enough to show the calling order - eliminating the need for brackets in many cases, and reducing syntactic noise.

[1] There's a handful of two-character primitives, as well as some special callable symbols (eg `freq @), but they don't come up nearly as often as the base set.

> Do you consider add(a,multiply(b,c)) certainly more readable than a+b*c?

No, but it took me 12 years of school education to get to that point. Question is, for a large code base how many symbols are you willing to remember? At some point it hits diminishing returns, doesn't it?

Well, 12 years is an exaggeration. Once you have learned the concepts (which you need to learn independently of which programming language you use), getting used to the symbols is just a matter of a bit of practice. For example, I learnt to multiply with 3x2, but it did not take me 12 years to get used to the 3*2 notation used by most programming languages.

The symbols you have to remember are the ASCII symbols (most of them are used in other programming languages too), with two operations for symbol, plus a few special cases and a bunch of extra functions. In total, less than 50 primitives. I think that any programmer can easily handle that.

There are many people who do not agree with this, but there is objective data (see the papers by Iverson about his efforts to teach mathematics using APL) that say it is easy to learn. In all these threads, most people with experience in array languages say it is not so hard as it looks, although there are some exceptions.

You may prefer other kind of languages or other kind of notation. There certainly is some subjective factor here. But I suggest everyone to give it a try before forming an opinion.

I wouldn't call K a "fun little micro-language." It's an industrial strength highly performant language used in a variety of applications (mostly financial though). Moreover, I don't think K is any less readable than other programming languages, in fact, it might be more readable.

Reply on news.ycombinator.com