Live data from Hacker News

K: War on Raze

gist.github.com

11–20 of 23 posts

Re: K: War on Raze

#11
post #8

Hm, just wrote up an explanation[0] of BQN's high-rank searching, which is the same concept used in J and APL and turns into rank-sensitive search in K. The issue it addresses is that in array programming you'd like to search for each of an array of elements all at once, but this is hard to distinguish from just searching for the array itself. So you look at the entries of the array you're searching to see what rank…

This is my first encounter with K, and it looks absolutely bonkers. The amount of logic you can express in a few characters is mind boggling. However, it makes my brain hurt. Is this a paradigm that becomes intuitive once you learn it, or is it like Ruby in the sense that it’s so flexible that every developer uses their own custom DSL and onboarding is like solving an infinite series of brain teasers?

It's unfamiliar, but highly learnable. The problem solving style can then be applied elsewhere to great effect.

If anything, K is the opposite of a language where everyone disappears into DSLs- you can write expressive code without wrapping it in custom abstractions. An anti-lisp, if you will. It's not uncommon for K programmers playing with a puzzle to independently arrive at character-for-character identical solutions.

Re: K: War on Raze

#13
post #8

Earlier quoted context omitted.

This is my first encounter with K, and it looks absolutely bonkers. The amount of logic you can express in a few characters is mind boggling. However, it makes my brain hurt. Is this a paradigm that becomes intuitive once you learn it, or is it like Ruby in the sense that it’s so flexible that every developer uses their own custom DSL and onboarding is like solving an infinite series of brain teasers?

It's unfamiliar, but highly learnable. The problem solving style can then be applied elsewhere to great effect. If anything, K is the opposite of a language where everyone disappears into DSLs- you can write expressive code without wrapping it in custom abstractions. An anti-lisp, if you will. It's not uncommon for K programmers playing with a puzzle to independently arrive at character-for-character identical soluti…

That's great to hear. I am always interested in learning new languages that are vastly different to mainstream languages to see if there are any hidden gems that I can incorporate into my day job.

Re: K: War on Raze

#14
post #13

Earlier quoted context omitted.

It's unfamiliar, but highly learnable. The problem solving style can then be applied elsewhere to great effect. If anything, K is the opposite of a language where everyone disappears into DSLs- you can write expressive code without wrapping it in custom abstractions. An anti-lisp, if you will. It's not uncommon for K programmers playing with a puzzle to independently arrive at character-for-character identical soluti…

That's great to hear. I am always interested in learning new languages that are vastly different to mainstream languages to see if there are any hidden gems that I can incorporate into my day job.

The only real disadvantage is finding yourself annoyed by obvious absences in the standard libraries of every non-APL-family language you come across.

"ugh why can't this sort() just give me a grade instead?"

"why does this provide reduce(), but no scan?"

"this would be so much cleaner if I had transpose, or even just laminate..."

Re: K: War on Raze

#15
post #7

Love seeing the random k/q code mentions here. All too often I feel as though I'm coding in a black box. This shines a little light letting me know others are out there too. Nice work.

What industry do you work in? Is it a common stack there?

Main industry for kdb+/q is finance, specifically sell-side or very large buy-side firms.

I wouldn't call it "common", but it's pretty well known.

kdb+/q devs certainly have good job security, heh.

Re: K: War on Raze

#16
post #8

Hm, just wrote up an explanation[0] of BQN's high-rank searching, which is the same concept used in J and APL and turns into rank-sensitive search in K. The issue it addresses is that in array programming you'd like to search for each of an array of elements all at once, but this is hard to distinguish from just searching for the array itself. So you look at the entries of the array you're searching to see what rank…

This is my first encounter with K, and it looks absolutely bonkers. The amount of logic you can express in a few characters is mind boggling. However, it makes my brain hurt. Is this a paradigm that becomes intuitive once you learn it, or is it like Ruby in the sense that it’s so flexible that every developer uses their own custom DSL and onboarding is like solving an infinite series of brain teasers?

Once you look at the verbs as symbols for algorithms, it will make much more sense. Most languages make you create algorithms. k code is the composition of algorithms.

Re: K: War on Raze

#17

Love seeing the random k/q code mentions here. All too often I feel as though I'm coding in a black box. This shines a little light letting me know others are out there too. Nice work.

check out the Arraycast podcast

Re: K: War on Raze

#18
post #8

Earlier quoted context omitted.

This is my first encounter with K, and it looks absolutely bonkers. The amount of logic you can express in a few characters is mind boggling. However, it makes my brain hurt. Is this a paradigm that becomes intuitive once you learn it, or is it like Ruby in the sense that it’s so flexible that every developer uses their own custom DSL and onboarding is like solving an infinite series of brain teasers?

It becomes intuitive. APL primitives are particular instantiations of clean high-level concepts. While a C programmer would think "I'll make a sparse encoding of this boolean array" a K programmer would just write Where. Having a rigorous definition for a pattern like this is a nice guide for the intuition, but it's possible to get in a situation where what you want to do and what the language provides don't line up.…

The high level description sounds a bit like Clojure...? Both sound very tied to the datastructures and built in algorithms provided. As long as your problem maps well to the built in tool it's very terse (in a very good way!). I find this makes coding much more productive. Most languages avoid committing that way

Would be curious to hear from someone's that's used both

Re: K: War on Raze

#19
post #18

Earlier quoted context omitted.

It becomes intuitive. APL primitives are particular instantiations of clean high-level concepts. While a C programmer would think "I'll make a sparse encoding of this boolean array" a K programmer would just write Where. Having a rigorous definition for a pattern like this is a nice guide for the intuition, but it's possible to get in a situation where what you want to do and what the language provides don't line up.…

The high level description sounds a bit like Clojure...? Both sound very tied to the datastructures and built in algorithms provided. As long as your problem maps well to the built in tool it's very terse (in a very good way!). I find this makes coding much more productive. Most languages avoid committing that way Would be curious to hear from someone's that's used both

Yeah, I've not used lisps much myself but it's definitely similar. See https://kparc.com/lisp.txt.

The quote by Alan Perlis, 'It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.' is also relevant to both lisp dialects and array languages.

Re: K: War on Raze

#20
post #19
post #18

Earlier quoted context omitted.

The high level description sounds a bit like Clojure...? Both sound very tied to the datastructures and built in algorithms provided. As long as your problem maps well to the built in tool it's very terse (in a very good way!). I find this makes coding much more productive. Most languages avoid committing that way Would be curious to hear from someone's that's used both

Yeah, I've not used lisps much myself but it's definitely similar. See https://kparc.com/lisp.txt . The quote by Alan Perlis, 'It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.' is also relevant to both lisp dialects and array languages.

Oh, of course. Lisp is maybe a more natural analogue.

I guess Clojure takes things a step further. It goes from "everything is a list" to something slightly broader with Vectors/Maps/Sets/etc. - all through language primitives. (the algorithmic layer is cleverly done through the sequence abstraction)

Coming from C++, in effect having your STL containers/algos baked into the language is a breath of fresh air :)

Post reply on HN