K made a lot more sense to me after I realised it is three things: a library of functions, operators, and a set of types. The only way to access the function library is through the operators/type overloading. Different versions of K (or related languages) then choose different libraries of functions, or different operators. Code is essential a very dense encoding of function calls into a fixed library.
Similar to the library of functions, accessible through a collection of operators us the Q'Nial language. It doesn't always get the visibility it's cousins (J and K) enjoy
K is cool but really, really expensive. Kevin Lawler's Kona seems nice. Shakti (next K version) could be good but I can't figure out a damn thing about it.
And then there's J, which, man. Hard to learn, but cool.
There's now ngn/k[0] for a free implementation of K6. The author prefers K6 to Shakti, which is K9. And there are a number of other open-source K dialects and array languages as well[1]. For learning about K, the recently-created K wiki[2] is a great resource.
A number of orgs have perpetual site licenses, or so I've been told. It can solve many problems elegantly and with minimal code and development time. But it requires a core group of people who do almost nothing else.
It’s been a while now since I first met on theoretical level array languages. I like the symbolic representation of Dyalog and APL in spite of its input problem. Is there a language of those well sure for mobile development or llvm and web compilation?
Also missing some comprehensive guide on its philosophy and way of thought to solve problems? I remember there were some videos on YouTube solving the advent Of code and comparing to Haskell. These were awesome in order to get into the APLer mindset.
>A story, since in retrospect I think it's worth telling.
Some years ago I was at the SF Clojure meetup. Arthur Whitney's daughter worked at the sponsoring company, and he agreed to come tell us about K.
>In retrospect, I don't think we gave him the welcome he deserved. No one was rude or anything, but it seemed there was a disconnect: Arthur was keen to show off how fast K (and Kdb) was, over zillions and zillions of rows.
>But the thing that the Clojurists were all searching for (that got them into Clojure in the first place) was expressivity. Is Clojure fast? I don't know, generally the problems I face come down to avoiding balls of mud rather than performance bottlenecks. And I think that was true of most there.
>So Arthur got something of an underwhelming reception. I remember someone asking "Does K have the ability to self-modify, a la Lisp macros?" When Arthur said no, you could see most people in the room just sort of mentally shrug and move on.
>And this was too bad. Because recently I've been playing around with J (another APL descendant) and been very impressed by some expressivity/readability benefits. Some small things that have very big effects on the codebase you actually end up with.
>The first thing is the avoidance of abstraction. To use a Twitterism:
>Broke: Just write your code and don't divide it into functions, creating one long main method
>Woke: Divide your code up, naming parts that get reused
>Bespoke: If your code is made up of really really short things, it ends up being shorter than the names you would use, so you can just write the thing rather than your name for it. An analogy would be: there is no human-comprehensible way to communicate the idea of "picosecond" in less time than an actual picosecond.
>The other thing I didn't expect was the benefit of multiple dispatch being baked into e v e r y t h i n g. In Clojure I might write (map + a b) to add each index together; in J I could just write a+b.
>This is neat stuff! Best practices for keeping complexity down in APL's tend to be the opposite of what they are in other languages. Aaron Hsu gave a talk about this: https://www.youtube.com/watch?v=v7Mt0GYHU9A
>It's too bad! Arthur came to tell us about speed---there's a reason it's used on giant datasets in finance, where performance translates directly into cash---but I wish we'd had the presence of mind to ask more about experience of writing K.
>So, Arthur, if you're reading this: Sorry everyone seemed kinda bored in SF a few years ago when you kindly came to present. We missed out!
The licenses aren’t cheap but are worth it for the right problems. Definitely worth adding that the relatively few people skilled in k/q are very much in demand and paid accordingly.
It's written by a private company with no public docs and no public implementation. Hell, it's not even directly sold, since it's just used as the backend for Q.
I have heard of people getting into legal problems for making a Q clone but not for k3/k6 implementations, so I don't know where they draw the line there.
Consider mathematical notation. That digit 2 could mean “power of 2” if it’s small and upper right of an object; “index 2” if small and bottom right. “Multiply by 2” if regular sized and to the left - very confusing! Indeed, it is very confusing if you are not versed in the accepted syntax of math expressions.
But if you are used to it, there’s no confusion - it’s just a very concise and useful way to express various concepts.
The argument is that your entire program fits on one screen. It may be hard to read (without practice) but you can stare at the whole thing all at once. I don't know if I buy the argument but it's an interesting one.
You’re not wrong. While writing K you sit in the repl and work out each piece as you go and make sure it gives the result you expect and then build up.
[+] [-] quag|4 years ago|reply
[+] [-] enduku|4 years ago|reply
[+] [-] gaze|4 years ago|reply
And then there's J, which, man. Hard to learn, but cool.
[+] [-] mlochbaum|4 years ago|reply
[0] https://codeberg.org/ngn/k
[1] https://aplwiki.com/wiki/List_of_open-source_array_languages
[2] https://k.miraheze.org/wiki/Main_Page
[+] [-] huhtenberg|4 years ago|reply
Can't find any pricing info on their website. How expensive is "expensive"?
[+] [-] gbronner|4 years ago|reply
[+] [-] threatofrain|4 years ago|reply
[+] [-] nudpiedo|4 years ago|reply
Also missing some comprehensive guide on its philosophy and way of thought to solve problems? I remember there were some videos on YouTube solving the advent Of code and comparing to Haskell. These were awesome in order to get into the APLer mindset.
[+] [-] CraigJPerry|4 years ago|reply
https://mlochbaum.github.io/BQN/
[+] [-] rscho|4 years ago|reply
[+] [-] invalidOrTaken|4 years ago|reply
>A story, since in retrospect I think it's worth telling. Some years ago I was at the SF Clojure meetup. Arthur Whitney's daughter worked at the sponsoring company, and he agreed to come tell us about K.
>In retrospect, I don't think we gave him the welcome he deserved. No one was rude or anything, but it seemed there was a disconnect: Arthur was keen to show off how fast K (and Kdb) was, over zillions and zillions of rows.
>But the thing that the Clojurists were all searching for (that got them into Clojure in the first place) was expressivity. Is Clojure fast? I don't know, generally the problems I face come down to avoiding balls of mud rather than performance bottlenecks. And I think that was true of most there.
>So Arthur got something of an underwhelming reception. I remember someone asking "Does K have the ability to self-modify, a la Lisp macros?" When Arthur said no, you could see most people in the room just sort of mentally shrug and move on.
>And this was too bad. Because recently I've been playing around with J (another APL descendant) and been very impressed by some expressivity/readability benefits. Some small things that have very big effects on the codebase you actually end up with.
>The first thing is the avoidance of abstraction. To use a Twitterism:
>Broke: Just write your code and don't divide it into functions, creating one long main method
>Woke: Divide your code up, naming parts that get reused
>Bespoke: If your code is made up of really really short things, it ends up being shorter than the names you would use, so you can just write the thing rather than your name for it. An analogy would be: there is no human-comprehensible way to communicate the idea of "picosecond" in less time than an actual picosecond.
>The other thing I didn't expect was the benefit of multiple dispatch being baked into e v e r y t h i n g. In Clojure I might write (map + a b) to add each index together; in J I could just write a+b.
>This is neat stuff! Best practices for keeping complexity down in APL's tend to be the opposite of what they are in other languages. Aaron Hsu gave a talk about this: https://www.youtube.com/watch?v=v7Mt0GYHU9A
>It's too bad! Arthur came to tell us about speed---there's a reason it's used on giant datasets in finance, where performance translates directly into cash---but I wish we'd had the presence of mind to ask more about experience of writing K.
>So, Arthur, if you're reading this: Sorry everyone seemed kinda bored in SF a few years ago when you kindly came to present. We missed out!
[+] [-] imachine1980_|4 years ago|reply
[+] [-] rak1507|4 years ago|reply
ngn/k is foss and can be installed on linux https://codeberg.org/ngn/k
[+] [-] andylynch|4 years ago|reply
Download + licenses are at https://kx.com/developers/download-licenses/
The Q for Mortals book (free online) is a good place to start, as is https://code.kx.com/q/learn/tour/
The licenses aren’t cheap but are worth it for the right problems. Definitely worth adding that the relatively few people skilled in k/q are very much in demand and paid accordingly.
[+] [-] marcelnita|4 years ago|reply
[+] [-] dotnwat|4 years ago|reply
[+] [-] maximus-decimus|4 years ago|reply
I have heard of people getting into legal problems for making a Q clone but not for k3/k6 implementations, so I don't know where they draw the line there.
[+] [-] Jenk|4 years ago|reply
But that looks like a really error prone syntax.. error prone like writing Brainfuck I mean.
[+] [-] beagle3|4 years ago|reply
Consider mathematical notation. That digit 2 could mean “power of 2” if it’s small and upper right of an object; “index 2” if small and bottom right. “Multiply by 2” if regular sized and to the left - very confusing! Indeed, it is very confusing if you are not versed in the accepted syntax of math expressions.
But if you are used to it, there’s no confusion - it’s just a very concise and useful way to express various concepts.
K is similar.
[+] [-] gaze|4 years ago|reply
[+] [-] Nekorosu|4 years ago|reply
[+] [-] quag|4 years ago|reply
[+] [-] huyage|4 years ago|reply
[+] [-] AzzieElbab|4 years ago|reply