kdb

> The same baseless accusations of “unreadable”, “write-only” and “impossible to learn” are leveled at all Iversonian languages, k included. I'd be really curious to know if they really are baseless. It's very very difficult to imagine that K developers can really read a mess like this as easily as one might read Go or whatever. https://github.com/KxSystems/kdb/blob/master/e/json.k Has anyone tested this? Take a K program and ask a K developer to explain it? Or maybe introduce a deliberate bug and see how long they take to fix it compared to other languages. You could normalise the results based on how long it takes them to write some other code. Free research project for any compsci researchers out there... (though good luck finding skilled K programmers).

A one-liner in k tends to be equivalent to a much larger program in another language. Here's a program in k. I'm not sure exactly what it does. I think it might be a json encoder/decoder: https://github.com/KxSystems/kdb/blob/master/e/json.k

No true Scotsman. I assume you haven't looked at the expansion of errno lately? edit: also https://github.com/KxSystems/kdb/blob/master/c/c/k.h

> And later array languages have mostly abandonned the crazy names in favour of actual words Sharing this without comments: https://github.com/KxSystems/kdb/blob/master/c/c/k.h

I'll just leave this here: https://github.com/KxSystems/kdb/blob/master/c/c/odbc.c

This is false, I've optimized horrendously large json parsing by simply rotating the data in a table form and using a binary serializer/deserializer (c.js provided by kdb: https://github.com/KxSystems/kdb/blob/master/c/c.js ). It's insanely faster to parse binary into js object without going through json at all than parsing string json, and we transformed a dumb application from slow death to "oh wow no need to optimize further, all perf problems are now fixed" simply by switching the serialization format (faster to download, faster to deserialize, faster to access). It even helps the backend to serialize faster than writing enormous ASCII strings just to talk to the browser memory structure. Dont forget these json format are just better xml and still made for humans. Machines can work well with structures closer to the memory layout, for

For inspiration, here’s the full solution set for the 2015 edition in around 100 loc of k. Yes, all problems. https://github.com/KxSystems/kdb/blob/master/ad.k

Doesn't seem that strange compared to K[1] or Q[2], which are used by Wall Street banks. K encourages you to use single-letter variables and bunch your code up as tight as possible into long lines. Here's an example: [3]. Interestingly, their Github repo has some K-inspired C[4], Java[5], C#[6], and Javascript[7]. [1] https://en.wikipedia.org/wiki/K_(programming_language) [2] https://en.wikipedia.org/wiki/Q_(programming_language_from_K... [3] https://github.com/KxSystems/kdb/blob/master/holiday.q [4] https://github.com/KxSystems/kdb/blob/master/c/c/odbc.c [5] https://github.com/KxSystems/kdb/blob/master/c/jdbc.java [6] https://github.com/KxSystems/kdb/blob/master/c/c.cs [7] https://github.com/KxSystems/kdb/blob/master/c/c.js

Reminds me of Arthur Whitney's k.h[1] Example: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; #define CD default 1 - https://github.com/KxSystems/kdb/blob/master/c/c/k.h

Surprised nobody talks about the kdb codding style: https://github.com/KxSystems/kdb/blob/master/c/c/k.h

Recently I came across some code that checks quite a few boxes in this guide. Check it out: https://github.com/KxSystems/kdb/blob/master/c/c/k.h https://github.com/KxSystems/kdb/blob/master/c/c/odbc.c

Welp, you were not kidding: https://github.com/KxSystems/kdb/blob/master/c/c/curl.c This code is basically obfuscated by hand. Absolutely unapproachable. Only the original author(s) can understand it. Judging by other comments, it seems to work well. So they seem to be good programmers producing working code. It's just not intelligible by other human beings, which is a pretty bad thing, but not the only factor in software quality/health. The Vim code base is at some parts straight batshit insane, but it's one of the most polished programs I've ever used. All that being said, I would find infuriating to work with such code. Nope!

The KDB code is terse to an unhealthy extreme. Check this gem: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 Or this wall of code: https://github.com/KxSystems/kdb/blob/master/c/c.cs

I was kind of happy to find some java code this time around - who says java needs to be verbose? https://github.com/KxSystems/kdb/blob/master/c/jdbc.java

I like it when kdb is mentioned because then I can post this link: https://github.com/KxSystems/kdb/blob/master/c/c/k.h#L96 It's one of my all-time favorites. A window into a certain type of mind.