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.
Is there any summary of what's changed between K versions, or their lineage, for someone who's not "K-fluent" but a tiny bit familiar with array languages? What changed between K6, 7, and 9?
Since Kx is the proprietor of the main toolchain I assume such any such description would be more of an oral history rather than a technical document with a changelog, but I'm curious either way!
Hello, one of the maintainers of the wiki here. The major changes are generally divided into:
K2-K4
K5-K6
K7-K9
From my knowledge. Each group has the same general primitives and syntax, and major changes happen between those eras. Since K's design allows removal and addition of features, this is very hard to document. This, combined with Arthur Whitney's rocky relationship with documentation makes most sources of changes anecdotal. Most changes to primitives have been documented in the wiki's primitive pages. I'll have to summarize them in the history pages.
K4 has good docs, and K6 has a well-written manual on oK's repository. The rest are a fill-in-the-blanks game which have to be fished from archive pages and a lot of trial and error. K9, the latest one is still undergoing changes, but there are ongoing efforts to make tutorials in kparc/kcc and estradajke/k9-simples on github.
Theres also a version of K2, plus a PDF K2 reference manual and many example programs on nsl.com that are still available.
Back in 2002, I remember reading an article on kuro5hin where the author wrote: "I have heard rumors that there would be interest in opening up the language if there would be enough community response around it."
People commenting on today's web like to make fun of the idea that anything about computing was "better" in the past (and they like to crticise C too), but just look at how portable this code was designed to be. Moreover, it is as old as the web itself and it still compiles today.
What is the longevity of something written in Javascript.
"Arthur told me that he will open-source it, if there is sufficient interest. It is not very difficult to obtain the source from kx for your private use right now."
> What is the longevity of something written in Javascript.
I wrote some JavaScript in the late 90s which is still being used as part of a complex financial services value chain.
The idea that computing was better in the past is indeed silly, and completely ignores all the advances in understanding that have been made in the last many decades.
If your opinion is different, I can assure you that's due to ignorance.
It's hard to say how exactly to draw the line, but "array language" to an APLer usually means a language whose primary influence is APL. So these scientific languages that throw out most of the syntax are nearby but don't quite belong. From a practical standpoint the APL Wiki is centered on APL and exists to document the kind of niche material Wikipedia wouldn't cover, which is why there's nothing about these more mainstream languages currently.
I’d argue that array languages are far, far more limited than Python, to the point that the only thing you can reasonably do with them is processing array data (but they’re really good at it!)
Sounds like you're generalizing, based on... early APLs? NumPy? You could translate any BASIC code to, say, Dyalog APL easily without significant loss in fidelity. Different languages take different approaches but most modern ones (the ones that aren't just made to be calculators like Ivy) support either a generic functional or imperative style just fine.
K is inspired by Lisp, although you can't adapt that style directly because of the limited scoping rules: variables are either local or global, so a function can't see variables from containing functions. This means no closures, which K implementers consider a feature (I don't).
> This means no closures, which K implementers consider a feature (I don't).
having not touched K in about 15 years, when did this change? in k3:
K 3.2 2004-09-23 Copyright (C) 1993-2004 Kx Systems
LIN32 16CPU 15985MB ubuntu 0 EVAL
f:{a:x+1;{a+x}}
g:f 1
g
{a+x}
g 2
4
a
value error
a
^
parse error
This comes as a surprise to me! I thought none of Whitney's Ks had closures—although I did neglect to mention that kuc and oK add them. Digging around and asking on the K Matrix/Discord I found some posts that suggest that the K3 form is very limited. My read of these is that functions can refer to variables in the immediately surrounding scope (only one level up), and their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.
> their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.
That is definitely desirable! K (and kin) are fully referentially transparent and have value semantics. It would be bizarre and inconsistent to break referential transparency for closures.
No closures is one of the biggest pain points of k/q, it's incredibly limiting and frustrating. Besides that though, it's a wonderful language which allows you to solve problems very quickly with pretty good performance, assuming the problem is naturally vectorizable.
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 costs an arm and a leg. I think Kx systems fucked up in making the language proprietary and closed source and charging for licenses. The smarter long-term play would have been to charge for support/special features/etc ala julia computing or lightbeam.
They have a huge database product (kdb). The company that owns Kx is a billion dollar company.
It really isn't clear to me why they do what they do (not just with regards to the language). They have a large consulting business (q/kdb consultants can make £1k/day easily) so it doesn't make a difference. I believe some parts of q/kdb are open-source but some parts are not. And I think this really does hurt them because there isn't a big eco-system around their products (for example, they have had to hire people internally to build ML libraries for q).
It is very weird: they are at the eye of the storm for data analytics, their product is fast, they are growing modestly doing lots of business with banks and in other industries that need streaming analytics particularly...but they are still niche, and growing a lot slower than you would expect (part of this is that management insists on being profitable...people rip on SV companies for not making money...well, Kx are the other side of this...they are modestly profitable, but not really growing).
EDIT: I should add, if you see the stuff that is open...a lot of the code is a total shitshow.
Given the combined cost of K licenses in banks and other large companies, I'd say they are really far from having messed up. The main goal of the company is not to promote K the language.
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.
And the result of this trial-and-error programming process is, supposedly, a program that is protected from bugs because... it is short and you can see it on your screen all at once.
