Determining an Election in K | Hacker News Reader

Determining an Election in K

leahneukirchen.org

77 pointsluu25 comments

Another approach to the 'highest averages' method, using a k9 dict:

    v: 10400 3400 6200
    s: 15

    quotients: ,/v%\.5+!s
    labels:    s/!s*#v              / list of 15x 0, 1, 2. arbitrary; could instead be party names
    top:       s#>labels!quotients  / k dicts can have duplicate keys; can sort items by key(^) or val(<>)
    seats:     `freq@!top           / count appearances of dict's keys

The ability to transform a dict's values while keeping the labels (keys) unchanged - sort, arithmetic, etc - is really powerful.

This answer is longer when minified, but it's faster in 2020.03.27:

    \t:100000 +/s>(#v)^<>,/v%/.5+!s           ⇒ 1494
    \t:100000 `freq@!s#>(s/!s*#v)!,/v%\.5+!s  ⇒ 691

Correction: I think the above can be a bit faster and shorter if we skip the dict, and just index into the keys. Compare:

     \t:100000 `freq@!s#>(s/!s*#v)!,/v%\.5+!s
    941
     \t:100000 `freq(s/!s*#v)s#>,/v%\.5+!s
    901

Always a pleasant surprise to find niche or mundane uses of array languages. I really appreciate the explication because it made it possible for me to follow along in J - there's vanishingly little material to patiently explain bits like the "grade-up grade-down to return rank" that permeates so much APL-style code.

I'm similarly pleased to have found a correspondence from K's ' (also present in Klong) to J, where it ends up being "0 in this instance.

    r=. v&%"0 (0.5+i. s)
    +/s>($r)$/:\:,/r

A nice demonstration of how the K REPL can be used as a calculator and exploratory tool. The concise syntax particularly shines in interactive cases.

> The concise syntax particularly shines in interactive cases

If you can tolerate the learning-curve though.

For comparison, I do appreciate that many (most?) Linux shell utilities and command-line programs in general have adopted standard conventions for arguments (-f for short, --full for verbose) which make it easier for people new to a program to take a cryptic command-line and look-up the full-versions of the abbreviated commands to see what's going on - PowerShell does the same thing with its strict aliasing of cmdlets. Unfortunately I can't see that K (or many other programming languages really) do the same thing, where a a short, cryptic program can be syntactically expanded to one using verbose syntax with no changes in program semantics (unless you count VB.NET vs C# equivalence, heh).

Is there any automated explainer tools for the K language for beginners?

> Is there any automated explainer tools for the K language for beginners?

I think q is a better starting out point than k. Most functions in q have readable names (each in q vs ' in k, for example). Also it comes with a richer library of functions.

Not long ago there was a post about using English language instead of the J symbology[0] but the end result isn't meaningfully easier to understand because of all the prerequisite knowledge of how evaluation works etc., once you've worked that out most of the "line noise" has already sunk in. I think that's a big sticking point against creating a second "inflatable" notation - though there is always Nial[1]

Not entirely an answer to your question, but J provides introspection/help in a pretty direct way via two distinct means, the first is ;: ("words") which will show you the parse of a J phrase (here, a pretty direct translation of the algorithm in the article):

    ;:'+/s>(s,#v)$/:\:,/v&%"0 (0.5+i.s)'
    ┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬──┬──┬─┬─┬─┬─┬─┬─┬─┬─┬───┬─┬──┬─┬─┐
    │+│/│s│>│(│s│,│#│v│)│$│/:│\:│,│/│v│&│%│"│0│(│0.5│+│i.│s│)│
    └─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴──┴──┴─┴─┴─┴─┴─┴─┴─┴─┴───┴─┴──┴─┴─┘

Which shows the tokens of the phrase, which can be helpful if you are unsure of where a symbol or diacritic is being used. Inside the J IDE you can get context sensitive help by pressing Ctrl-F1 on a symbol, if you were interested in /: for example, you are directly linked here[2].

I am unaware of a similar tool in K, which should not be taken to mean it doesn't or can't exist. One of the reasons I'm interested in J has been the tooling and documentation available.

[0]: https://wjmn.github.io/posts/j-can-look-like-apl/

[1]: https://tangentstorm.github.io/nial/intro.ndf.html

[2]: https://code.jsoftware.com/wiki/Vocabulary/slashco

> The concise syntax particularly shines in interactive cases.

I think this is a good point.

In an interactive environment: you can iteratively build the expression up, and you have the right chunks of context in working memory as you do it. You'd still need to learn what the different functions/operations are; but in a one-line REPL the use of symbols would allow you to fit more on a line than using more traditional identifiers.

That avoids many of the things I'd be concerned about for writing code like this if I had to come back and read or modify it months later.

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.

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.

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.

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.

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 suspect the Python or Haskell equivalent of

    _q+(s-+/_q)><>q-_q:s*v%+/v

would be longer, but it would also probably be more readable.

The only difference is a matter of alphabets. Is English more readable than Japanese because the words aren't as condensed?

Though I would miss the daily K post, but here it is!

K definitely meets my criteria for being a Write-Only Language. I remember a quote about APL (a precursor to K) being “indistinguishable from line noise”.

https://en.wikipedia.org/wiki/Write-only_language

Reply on news.ycombinator.com