Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

github.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#71

Post by lkuty »

gsinclair wrote: post #63
alfiedotwtf wrote: post #54

Earlier quoted context omitted.

Awesome comment. In your opinion, what would be a language that comes closer to K’s functionality but at the same time be understandable to mere mortals?

I recommend checking out uiua.org for fun. The docs are well written and the concepts, while foreign to most, are ultimately accessible and interesting. k and uiua are in different branches of the APL family.

I recommend checking BQN at https://mlochbaum.github.io/BQN/ and the YouTube channel code_report by Conor Hoekstra (and also "Composition Intuition by Conor Hoekstra | Lambda Days 2023"). It is well documented.

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#72

Post by icsa »

userbinator wrote: post #62
vessenes wrote: post #18

I have a longstanding fascination with K and other "modern" APL derivatives. There are a few intersecting truisms about coding that I believe: one is that people's working memory varies: some have an immense amount, some less. Humans definitely process spatially better than in time series (e.g. comparing side by side rather than turning over a page.) This implies you should prefer succinct code and languages because…

One analogy I like to tell people who are overcome with shock and horror at APL-family languages is to compare it to someone used to Latin-family human languages looking at something like Chinese for the first time --- it's likewise totally "unreadable" at first glance, but then you realise that over a billion people can read and write that language fluently every day, many of which may also struggle with a Latin-fam…

Another analogy

Would you rather write/read:

DIVIDE X BY 5 GIVING Y

or

y=x/5; / this would be considered "noisy" by C programmers, relative to COBOL

The first is COBOL (designed to make code easier for "normal" people to read. The second is C/Java/Python/Javascript (which looks more like the math that we learn in grade school).

k/APL/J simple moves further in the direction of the algebraic notation you already know. The difference is more operations/algorithms.

When you read the one-character symbols in K as algorithms versus characters, it makes much more sense. In addition, you can read "faster" in k than in other languages, relative to the functionality being expressed.

When I review C/Java/C++, I print out the source code and write the equivalent k code in the margin. The compression ration is typically 10-20X. Doing so speeds up my work significantly when I go back over the reviewed code.

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#74

Post by mst »

sudosysgen wrote: post #56
eismcc wrote: post #22

Earlier quoted context omitted.

Arthur Whitney is showing how to build an array language using C in array language form. AW is known for kdb+ which is often used in finance due to its extreme performance properties and ability for quants to quickly explore ideas. Personally, to get a better handle on how array languages worked, I implemented KlongPy which is a python implementation of Klong, which descends from K (which AW wrote). You have to play…

FWIW, kdb+ is not that extremely performant - there's a lot of things that could be faster, and a lot of limitations that mean that you often would be better of not using a DB at all (or to use another DB and just pull everything you might need into memory). There is/was a tradeoff in that many things that would make it faster would require more code, and a cool thing about q/kdb+ is that it takes so little code you…

> a cool thing about q/kdb+ is that it takes so little code you don't have I$ issues

I'm not sure what an I$ issue is - any chance of a bit more explanation?

(also I'd love to hear about the tradeoff part in more detail but that's a bigger ask)

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#75

Post by omaranto »

RodgerTheGreat wrote: post #65
userbinator wrote: post #62

Earlier quoted context omitted.

One analogy I like to tell people who are overcome with shock and horror at APL-family languages is to compare it to someone used to Latin-family human languages looking at something like Chinese for the first time --- it's likewise totally "unreadable" at first glance, but then you realise that over a billion people can read and write that language fluently every day, many of which may also struggle with a Latin-fam…

As a moderately experienced K programmer, I find K easy enough to "scan". Common idioms immediately stand out as recognizable "words" that are suggestive of what a routine does before you fully parse it: @& (filtering) @ (sorting) @\: (folding) ,/ (flattening) +\ (a running total) etc. It's also easy to notice, e.g. in K3, a reserved name like "_f" and immediately know you're looking at a recursive procedure.

In what sense is @\: folding? Doesn't it take a list of functions on the left and a thing on the right, and returns the list of values obtained by applying each function to the thing?

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#76

Post by graemep »

skruger wrote: post #73

For people discovering k for the first time, I wrote https://xpqz.github.io/kbook as a gentle intro.

I am interested, but one thing I have still not quite understood is where to use this family of languages.

As far as I can tell they are best for data analysis but not for heavy numerical computation because most or all of them lack GPU support. is that right or have I got it wrong?

Are there any other use cases?

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#77

Post by scrawl »

graemep wrote: post #76
skruger wrote: post #73

For people discovering k for the first time, I wrote https://xpqz.github.io/kbook as a gentle intro.

I am interested, but one thing I have still not quite understood is where to use this family of languages. As far as I can tell they are best for data analysis but not for heavy numerical computation because most or all of them lack GPU support. is that right or have I got it wrong? Are there any other use cases?

q/kdb+ is used in finance (banking + funds) for heavy numerical computation every day. high-volume realtime data straight from markets, and petabyte/trillion-row historical DBs. it runs on CPU but computation easily parallelizes over cores/clusters.

regarding use cases, see https://kx.com/resources/use-cases/

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#78

Post by durumu »

mst wrote: post #74
sudosysgen wrote: post #56

Earlier quoted context omitted.

FWIW, kdb+ is not that extremely performant - there's a lot of things that could be faster, and a lot of limitations that mean that you often would be better of not using a DB at all (or to use another DB and just pull everything you might need into memory). There is/was a tradeoff in that many things that would make it faster would require more code, and a cool thing about q/kdb+ is that it takes so little code you…

> a cool thing about q/kdb+ is that it takes so little code you don't have I$ issues I'm not sure what an I$ issue is - any chance of a bit more explanation? (also I'd love to hear about the tradeoff part in more detail but that's a bigger ask)

I$ is short for instruction cache ($ -> "cash" -> cache). Since kdb has so little code, more of it fits into the instruction cache at once.

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#79

Post by scrawl »

mst wrote: post #74
sudosysgen wrote: post #56

Earlier quoted context omitted.

FWIW, kdb+ is not that extremely performant - there's a lot of things that could be faster, and a lot of limitations that mean that you often would be better of not using a DB at all (or to use another DB and just pull everything you might need into memory). There is/was a tradeoff in that many things that would make it faster would require more code, and a cool thing about q/kdb+ is that it takes so little code you…

> a cool thing about q/kdb+ is that it takes so little code you don't have I$ issues I'm not sure what an I$ issue is - any chance of a bit more explanation? (also I'd love to hear about the tradeoff part in more detail but that's a bigger ask)

they mean CPU instruction cache

Re: K/simple: a tiny K interpreter for educational purposes by Arthur Whitney

#80

Post by p0w3n3d »

p0w3n3d wrote: post #19

I believe that all one letter names for a language are already taken... Even Ć

I've just learned that Ć is no longer a viable name (thankfully). Now it's Fusion Programming Language (or fut?) https://github.com/fusionlanguage/fut
Post reply on HN