ngn/k, an AGPL K interpreter

by kick • 7 years ago

118 127 7 years ago

OskarS• 7 years ago

Is K [0] in some sort of competition with J [1] about who can write worst, most unreadable and unmaintainable C code possible?

[0] https://bitbucket.org/ngn/k/src/master/m.c

[1] https://github.com/jsoftware/jsource/blob/master/jsrc/v2.c

atemerev• 7 years ago

There are people who value brevity and minimal amount of code above everything else. Arthur Whitney, the author of K, doesn't even use scrolling — everything he reads or writes has to fit on a single page.

tgv2• 7 years ago

Brevity should not be an excuse for obscurity and illegibility. I get it that you assign a short name to central data structures, but all those two character identifiers...

kick13• 7 years ago

Snide remarks are dull, and HN's guidelines explicitly recommend against cheap humor. Every time K is posted to HN someone makes this exact style of comment in an attempt to be funny, but it's entirely unoriginal.

There's good reason as to why C written by APL programmers looks as it does, and shallowly dismissing it does a disservice to everyone.

msla7• 7 years ago

I still wonder if this is the form the author of the code uses to write the program.

warpech• 7 years ago

If you find it unbelievable that code like this is written by hand, read this short explanation about “a very unusual style of C” [1].

Fastai has a guide how to write Whitney-style code in Python [2].

Thre is a relevant thread in HN [3].

[1] https://github.com/kevinlawler/kona/wiki/Coding-Guidelines#t...

[2] https://docs.fast.ai/dev/style.html

[3] https://news.ycombinator.com/item?id=19481505

saagarjha14• 7 years ago

This isn't even unusual "I want to write K in C" style, it's specifically being annoying: https://bitbucket.org/ngn/k/src/master/m.c. I mean, for goodness' sake, it's pivoting the stack in x86_64 assembly to implement _start!

ngnk13• 7 years ago

any ideas for a more compact and efficient way to get argc and argv on both linux and freebsd without bringing in libc?

userbinator2• 7 years ago

For those who want to try understanding APL-styled C, I recommend starting off with this:

https://code.jsoftware.com/wiki/Essays/Incunabulum

I think a lot of the reason people have difficulty is that you need to read the macros first; jumping into the middle won't make any sense. The macros are very mnemonic and there's only 5 of them. For example, I found the DO macro to be particularly elegant because it expresses "repeat something n times", and one of the features of array languages which makes them terse and powerful is this implicit repetition.

mark_l_watson• 7 years ago

Thanks, especially for the fastai style link. I am currently finishing a book [1] that uses the Hy language (hylang) which is a Lisp wrapper on Python. I am going to revisit my code examples, informed by Jeremy’s ideas. Hy is really just a simple mapping of Python to Lisp (syntax very much like Clojure) so most of his style ideas carry over.

[1] https://leanpub.com/hy-lisp-python

msla7• 7 years ago

I wish they'd release the source of the obfuscator they used.

saagarjha14• 7 years ago

The code is unreadable, formatted in the style of an IOCCC entry–and this looks intentional. I wonder why.

smabie3• 7 years ago

It’s just a different style. After using kdb+/q for aoc2019, I quite like the no space one-line style. I find the code easier to read and remember. I think most people who have tried an APL derived language also agree.

It’s important that many/most cultural norms are not optimal, they are arbitrary. So don’t immediately discount something for looking weird.

saagarjha14• 7 years ago

I refuse to believe that the call to main here is a matter of style: https://bitbucket.org/ngn/k/src/master/m.c.

DagAgren• 7 years ago

You have a massive selection bias going on here - you're not going to use APL if you do not already tolerate this kind of code.

tgv2• 7 years ago

I think most people who have tried an APL derived language also agree.

That part I have some experience with, and I think that's not the case. I was taught APL (in a CS course) along with a hundred or so other students, and it was nearly universally disliked; IIRC, it only resonated with some of the EE people. The department's administration was even written in APL, and nobody wanted to touch it. After finishing my assignments, I've never wanted to look at it again. So I, for one, doubt the style is universally likable.

lifthrasiir2• 7 years ago

The Whitney style relies mostly on C macros, while IOCCC (and especially golfed) entries tend to exploit very forgiving operators. It is likely that you can actually understand the thing with only proper renaming. I can confidently say this because my IOCCC entry had won in the Best Short Program category ;-)

I'm still not sure that this terse style in C improves reading. I agree that lots of concise idioms present in APL family of languages do improve reading (once you picked them up), and I do like lots of short functions more than a number of long functions (another contrast to IOCCC, where you don't see many functions). But those languages are tailor made to maximize this aspect. You for example don't think much about loop invariants in APL and friends because they are mostly implicit, and in turn you get very good refactorability. Would it improve other non-array languages? I doubt.

saagarjha14• 7 years ago

The Whitney style relies mostly on C macros, while IOCCC (and especially golfed) entries tend to exploit very forgiving operators.

It did seem a little "off" to me, but I couldn't put my finger on it; thanks for describing what was wrong with it.

It is likely that you can actually understand the thing with only proper renaming.

Fair point, but I usually like to keep my use of renaming to understand code for the decompiler :)

kick13• 7 years ago

How is it unreadable? I've spent a fair amount of time digging my teeth into it, and I find it fantastic. It's terse, but far from unreadable.

saagarjha14• 7 years ago

I've spent a fair amount of time digging my teeth into it

I tend to label code that makes me do that "unreadable"; it's not that I literally can't read it (I routinely deal with worse) but it requires more effort than I consider reasonable for the medium it is presented in.

smcl3• 7 years ago

Usually it falls on the accuser to justify their accusation, however we are discussing if code like this is unreadable:

https://bitbucket.org/ngn/k/src/master/m.c

It is plain to any developer that this fits all definitions of "unreadable" and honestly I think in this case it falls on you to explain why you think it isn't.

bakul8• 7 years ago

I think this is what you really want to ask: “This style of programming is totally foreign to me. Clearly this is intentional — I am curious as to why you chose it. Can you explain?” :-)

Understanding why someone else makes a difference choice can be illuminating. Given that the author of the original k has written at least 5 or 6 versions of the language interpreter from scratch every time in this style, he must be doing something right. Right?

saagarjha14• 7 years ago

Given that the author of the original k has written at least 5 or 6 versions of the language interpreter from scratch every time in this style, he must be doing something right. Right?

Not necessarily, but others have pointed out reasons why one might write code this way.

geocar13• 7 years ago

The code is unreadable

False. I can read it just fine. Ergo, it is readable.

You cannot read it, and that is a different problem.

I wonder why

Because there are benefits you do not understand.

It is very strange to me that you assume someone who does something doesn't get anything out of it simply because you don't get anything out of it.

saagarjha14• 7 years ago

False. I can read it just fine. Ergo, it is readable.

https://news.ycombinator.com/item?id=22009831

It is very strange to me that you assume someone who does something doesn't get anything out of it simply because you don't get anything out of it.

I don't believe I assumed that?

emmanueloga_• 7 years ago

Author has a page [1] listing a few diff implementations of "K" [2]:

* A proprietary array processing language

* A variant of APL with elements of Scheme

* K serves as the foundation for kdb+, an in-memory, column-based database

* Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax.

1: https://ngn.bitbucket.io/k.html

2: https://en.wikipedia.org/wiki/K_(programming_language)

Edit: some examples of idiomatic code (I assume...)

* https://github.com/KxSystems/cookbook

* https://code.kx.com/phrases/

* https://github.com/KxSystems/javakdb

kick13• 7 years ago

More fun examples of k:

nsl.com

kparc.com

3xblah3• 7 years ago

"64-bit spyware"

Telemetry?

ngnk13• 7 years ago

i changed it to "telemetry". i'm not really sure what to call it. they are upfront about it in the clickwrap eula but the data is not anonymized (see section 1.5a - in k ".z.u" means username) and you are not allowed to obstruct connectivity. it's not quite spyware either, as it happens with your consent.

RodgerTheGreat4• 7 years ago

One subtle feature of oK is that it supports the creation of mutable closures. "f.d", where "f" is a function and "d" is some dictionary, will attach the dictionary to the function as if it were the global scope. You can then later use ".f" to extract that dictionary from a function to inspect it. This mechanism allows you to violate referential transparency (which is why Arthur doesn't like it), but you get a powerful mechanism for sandboxing code which can also permit writing code in an "OOP" style, if desired. Here's the feature in action:

      f:{a+::x}.[a:10]
    {[x]a::.`a+x}
      f 30
    40
      f 30
    70
      f 30
    100
      .f
    [a:100]

Naturally, if you have not explicitly re-bound the closure of a function, .f gives you access to that function's natural scope:

      a:99
    99
      b:"text"
    "text"
      .{}
    [prm:{[x]{[x]$[x;,/x ,''o'x ^/:x;,x]}@$[-8>@x;!x;x]};in:{[x;y]~^y?x};a:99;b:"text"]

Nifty, eh?

oK also supports unlimited lexical closure, which is a bit unusual among K interpreters; usually they either eschew closure entirely for simplicity or (as in k3) allow functions to close over a single scope.

chrispsn2• 7 years ago

ngn wrote:

i'm not trying to purposefully copy [Arthur's] style. i've always been trying to write shorter code - there are public traces of how that evolved in ngn/apl and in dyalog's ride. i acknowledge that after seeing some of arthur's code, including b, my mental threshold of what is considered acceptable dropped significantly. once you accept certain principles about the code, for instance that it's more important to be able to hold it at once in your head than to be able to explain it to the uninitiated, this style becomes more efficient and more pleasant

...

if you seek simplicity, this style is to a large extent discovered (as opposed to invented)

complicated things can be arranged in many ways. simple in few. that's why it always looks like entropy is increasing in the physical world :)

https://chat.stackexchange.com/transcript/message/52953241#5...

RodgerTheGreat4• 7 years ago

A fun and somewhat illuminating exercise in C is to simply try minimizing the number of semicolons in your programs. Pick any comfortable, well-defined task and spend a few hours refining an implementation.

Fewer semicolons means fewer statements. Apart from simplifying the structure of ones code overall, this also drives writing in a somewhat more functional style. You will find yourself taking advantage of the comma and ternary operators more, if you don't already. Macros are another tool for decreasing repetition. So is expressing programs in a "data-oriented" style, using lookup tables instead of explicit conditionals. If something is used only once, inlining it can reduce the number of distinct statements.

kick13• 7 years ago

'tlack:

It only took ten years for a non-toy one to come about! (Less if you count the one that got sued off the internet from the Morgan Stanley employee.)

https://news.ycombinator.com/item?id=944961

saagarjha14• 7 years ago

Somehow, I don't think they would appreciate this as much as you might have hoped: https://news.ycombinator.com/item?id=945093

kick13• 7 years ago

It was more a joke on "Ten years!" rather than assuming anything. I've already read that comment.

tlack• 7 years ago

For the record, I'm more open to this style now so I'd like permission to take a few steps back from that statement in 2009 (and probably most of my others that year!).

Coding in a terse style really does have some benefits. You can understand more program flow at one time and you can easily see larger patterns.

Another recent discussion https://news.ycombinator.com/item?id=21890259

beefhash• 7 years ago

And Google probably won't touch it anyway because AGPL.

3xblah3• 7 years ago

Download links:

https://bitbucket.org/ngn/k/downloads/k (Linux binary 64-bit)

https://bitbucket.org/ngn/k/get/master.tar.gz (Source code)

No Javascript required

ngnk13• 7 years ago

i'd encourage people to compile from source. the binary in "downloads" was compiled without the "-march=native" flag, in order to support older cpus, so it's a bit slower. also, i don't intend to update it regularly - i'll probably remove it in a couple of days.

EdSchouten• 7 years ago

You could argue that the license of the code, in this case AGPL, is irrelevant. I don’t think the source code is any easier to read than disassembled output.

beagle32• 7 years ago

You could say a similar thing about Japanese text if you don’t read Japanese - “copyright isn’t relevant, who would ever want to copy this gibberish?”.

As people in this and similar threads mention - it is easier to read; in fact, it is easier to read than even the preprocessed output, if you are familiar with the style and concepts.

gnulinux• 7 years ago

What a disappointing comment. This is like saying MIT/GPL/AGPL in programming languages most people don't understand is irrelevant, since most people wouldn't wanna read/copy/edit code anyway. By that logic, there is no value using open/free license in niche languages.

Even though you don't understand this language/style, doesn't mean a user may not want to refer to source code, or someone may want to contribute to the project.

ngnk13• 7 years ago

the agpl is not so much about making concise code pleasant for the masses, as it is about making its freedom viral

scottlocklin• 7 years ago

Yes, you need to understand a bit of APL to grok the style, but I don't know why it bothers people so much. I'm guessing because it involves people actually using the macro system for something interesting. Somehow lisp gets a pass.

Personally I think stuff like the DO macro (F/Fj in this code base https://bitbucket.org/ngn/k/src/master/k.h) should be used everywhere to the extent it is part of the C standard. If compilers were aware of it, there are significant optimizations which could be made. It's dirt simple and saves considerable typing and eliminates lots of potential for error.

msla7• 7 years ago

Somehow lisp gets a pass.

OK, which is more readable:

    (setf (car lst) "value")

Or:

    (rplaca lst "value")

I think the one which allows me to learn "setf's destination is the first parameter" and forget the rest is easier by far. setf is glorious macrology: It allows people to write arbitrarily complicated datatypes and have assignment just work, reliably.

But the problem with this code isn't the macros. It's the fact the author types like they're being charged by the character and taxed for whitespace. The macros are amazing to the extent they allow this sort of thing. Blaming them for it is wrong, but judging by the only standard that matters, readability, this is not a good coding style.

RodgerTheGreat4• 7 years ago

Your example neatly demonstrates that your definition of readability is based on familiarity. What does variable assignment have to do with the Contents of Address Register, anyway?

In the absence of familiarity, minimizing the number of moving parts and factoring out repeated patterns still has intrinsic value for aiding understanding.

jodrellblank2• 7 years ago

It's the fact the author types like they're being charged by the character and taxed for whitespace.

I dunno about you, but I have very little working memory in my head, just a few items, and only one focus of attention with a narrow field of view.

I can’t read that style of code, but opening a traditional codebase with part of the code here using lots of symbols to achieve a tiny amount of work and the next piece of work is four screens away, using a lot of symbols to achieve a small amount of work, it’s like declaring legalese as the most readable kind of English because it bloats so big it must be readable.

judging by the only standard that matters, readability, this is not a good coding style

What about composable idioms and conventions which let you do a lot of data transforms with a little attention and time?

What about a small amount of code to maintain and refactor? If this style saved you ten lines it might not help but where’s the cutoff that you’d start to be interested - if it saved you 50% of the work? 75%? 99.999999%?

If “big count per line of code is constant” this ought to be an exceptionally low bug style, right?

What about having less code to demonstrate correctness of?

What about having little code to throw away and rewrite if you don’t like it, leasing to a faster refactoring cycle time and a better expression of your intent after s set time? Or leading to readability simply being less important because the cost of rewriting 50 lines from scratch is so much lower than rewriting 10,000 lines from scratch?

Or if you’re writing documentation and there’s an order of magnitude less code to write about?

Or if you should write as many lines of test code as real code, and there’s an order of magnitude less code to test?

The whole style isn’t just “golf the character count”, but “collapse down the size of everything so one human attention covers a lot more of it, like zooming out to get a higher overview”.

Crossing down from several files to one file is a phase transition, crossing from one long file to one screen, is.

bakul8• 7 years ago

I use a slightly different DO macro. For example,

  DO(count(v)) v[i]=i;
  DO(3,4) a+=i*10+j;
  DO(3,4,5) a[i][k]+=b[i][j]*c[j][k];

Where i,j,k are first, second and third indices. So i in the last example takes values 0..2, for each i value j takes values 0..3 and for each j value k takes values 0..4.

geocar13• 7 years ago

Cool!

I've often thought about the best way to do this, and your suggestion is compelling. I'm going to try it out.

posterboy• 7 years ago

This must be the famous write once read never coding style I've heard so much about, a bit like my FINO list of bookmarks, where project like this one are always welcome

dang• 7 years ago

This is precisely explained by the quote elsewhere in the thread:

once you accept certain principles about the code, for instance that it's more important to be able to hold it at once in your head than to be able to explain it to the uninitiated, this style becomes more efficient and more pleasant

7thaccount5• 7 years ago

Any doc on how IO and other things work in this lang? The official K doc is pretty bad, so I can't exactly go there lol.

ngnk13• 7 years ago

    0:"path"                  /read  lines
    "path"0:("line1";"line2") /write lines
    1:"path"                  /read  bytes
    "path"1:"content"         /write bytes

7thaccount5• 7 years ago

Thanks ngnk, but what if I can't read the entire file into memory (Ex: 20 GB file)? Are there any streaming words?

chrispsn2• 7 years ago

Bizarre that this thread contains virtually no discussion of the technical merits of the end product (performance and size) - just the coding style.

kick13• 7 years ago

Right? I found it immensely disappointing.

svan99• 7 years ago

this is awesome. Congratulations!

ngn/k, an AGPL K interpreter

Related Stories