Side note, but some people have such an evident talent for writing that it makes reading about _any_ topic a worthwhile experience. This author, Stefan Kruger, seems to be one of them.
I almost wish this link was to a blog rather than to a book about K, for which I only have a perennial curiosity.
Here's to hoping they consider writing said blog. I notice they have one but it only has 3 posts, all of which are about past Advent of Code puzzles.
I was wondering if anyone would find that unusual! It's long lasting but never rises to anything more than curiosity, so I wanted to juxtapose the two to convey the mixed feelings I have for it.
> Readability is a property of the reader, not the language.
Uiua[0]'s stack model is much more annoying to work with, but I really appreciate its embrace of unicode glyphs. Every other derivative of APL throws those out at the first opportunity, but when you have a lot of glyphs, you stop being so tempted to make different arities cause the same glyph to mean wildly different things, when the arity is not actually written down explicitly and depends on whether the next thing to the left is a parameter or another function. Once you can See The Matrix, this is the chief thing that still does make K and friends objectively unreadable in a way they don't have to be.
I appreciate the idea (and Uiua's examples indeed look beautiful, almost like visual programming) but I'd at least like some obvious way how to pronounce the code.
All of the symbols in Uiua have short english words as alternate names, and the online editor allows you to type them by alias.
K has "traditional names" for all the primitive operators which appear in reference cards and which are typically used when discussing code aloud with other K programmers. Q and Lil, which are both K descendants, outright replace some symbols with those named keywords. Named keywords can make the primitives superficially easier to remember, at the cost of making idiomatic patterns in the language less visually apparent.
Original quote is just mind-bogglingly stupid. If If I can't read any programming language, that's a defect on my part. If I can read pretty much any language except k and brainfuck, that's a sign k is particularly difficult to read.
To be frank, your quote is mind-bogglingly stupid. How easy do you think Java is to read to a native Greek speaker with no English language knowledge? Would the Java standard library be as easy for you to read if it were written in Greek? Would java still be an easy to read language if all the keywords and library were in Greek?
If your only definition of a good programming language is one written in your native language and a PL becomes bad if written in a different language, then your criteria is terrible/useless. And right now that's your criteria.
> "there is no single definitive k, but instead a sequence of slightly incompatible versions. If you decide to stick with k, you’ll see mentions of k4, k5 etc."
I don't know about the qualities of k itself, but I think the idea of having a common practice for experimental programming languages to be grouped under a single name like "E" with a number is quite attractive.
There are lots of students, hobbyists, researchers, professional devs and companies who are developing their own working programming language. There are a million of them, all with their own names. 99.9% of them are ignored, or criticized unfairly by others expecting fully fleshed out features.
I can imagine a GitHub repo where you can register a new language "En" (with n being a number) rather than it living in obscurity on a random website. Then others can jump in and experiment with the language and give it feedback, fork it, etc.
This isn't just for toy languages, but for big organizations like Google. Instead of naming a not-fully-baked C++ successor as "Carbon" and getting flak for it not being ready for real world code yet, they could simply call it "E321" and the status of the language would be self-explanatory.
Then if one of the E languages gains enough traction, it could "graduate" to its own named language.
I also like the cred that an "official" E language could get when a dev talks about it to others. Everyone would immediately know it was experimental and where to see the code.
What seems to be a pity about most array languages is that in theory, they would be ideal DSL languages for SIMD and MIMD code exploration, but as far as I understand from ArrayCast guests, most are still interpreters at heart focusing on plain CPU execution.
The big problem with using array languages for lower-level SIMD stuff is that that generally requires some amount of typedness, but tacking on types on an array language without ending up with having types be the majority of the syntax and code (or taking up a ton of mental capacity if utilizing very heavy type inference) would be rather non-trivial. And the operations you want for lower-level ops are quite different from the higher-level general-purpose ones too. (and, of course, some interpreters do make good use of SIMD and/or multithreading)
That said, some form of array language more suited for stuff like that is a somewhat common question; maybe one day someone will figure it out.
Vanessa McHale is doing some interesting work on a typed compilable array language, Apple[0].
While we have CUDA being polyglot, it is still pretty much C and C++, or shader languages, hence why I keep thinking why not an array language that is also a kind of shader language DSL.
Not exactly the approach your describing, but Futhark[0] offers an alternative to CPU execution, it compiles to CUDA or OpenCL to run on GPU (or multi-threaded CPU).
That one I am aware of, as language geek, I am always curious to GPU alternatives that aren't always the same old story only C and C++ get to party, which is actually an advantage of CUDA's polyglot approach.
I've only played around with k and APL in my spare time so I can't speak to real world problems. It is a ridiculously powerful query language, where in SQL you have only started writing `SELECT ...`, in k you are already done. But you need to have very good tacit knowledge of algorithms and the weird syntax to be productive, like oh I need to calculate an integral-image of this time-series, but that just a pre-scan over addition, boom and you are done. The theory of array programming with a focus in combinators is also an interesting perspective on functional programming. IMHO not something you should write full program in, but that hasn't stopped some from trying.
This was a helpful comment. After the article, the question that popped into my head was… so ok should I try and compare this to like BLAS or something like Jax?
But, this sort of language is more about writing and reading from the disk efficiently, right? I guess SIMD type optimizations would be less of a thing.
I feel like measuring things in characters is not meaningful, but only in tokens. Replacing "SELECT" with "SEL" would not improve SQL in the slightest.
It says a lot that the name of the file for is more informative about what the code does than the entirety of the file itself. "Readability is a property of the reader" indeed, but also the writer...
The problem solved by K is the long-term employment of people writing K. You can't be fired if you're the only one understanding more or less the codebase
Some snark in here, I'll try and give it a fair shake. Whitney's site mentions '300 spartans' as the rough number of people using k, although it's probably more than that.
Two reasons k folks like k: first, if you believe that programmer working memory, as in the number of chars or lines of code you personally can hold in your head is limited, then it might make sense to be as terse as possible -- this will significantly increase the range of things you can reason about.
Second, if such a language were to focus more on array and vector-level manipulation, then for certain sorts of math tasks, you might be pretty close to grad student nirvana -- programming looks like using a chalkboard to work out a strategy for some processing, and then straightforwardly translating this strategy without mucking around with all the 100s of lines of weird shit say python or java make you do to process something in bulk and in parallel.
On top of this, whitney is a mad genius, and his k interpreters tend to be SCREAMING fast, and, like a couple of hundred kilobytes compiled. Over time the language has built connections to large-scale data processing jobs (as in, you run a microsend-or-shorter-timeframe strategy based on realtime depth data from 500 different stocks, say), and it has benefitted from the path dependence you get there.
Anyway back to the top - it exists as both a rallying cry for and a great tool for a certain sort of engineer that wants to make millions of dollars and refer to him/herself as a "Spartan" of coders.
Absolutely not being sarcastic: one problem it solves is that it is very hard to read as a beginner, so it can be intimidating (although it becomes much easier to read a bit later). This, coupled with the general arrogance of k/q practitioners (again, not really saying this in a negative way) and that k, kdb, etc. deliberately doesn't give you guardrails makes people who write k/q seem a bit 'mythical' and make them feel very clever.
So I think k, q and kdb are fun to work with, but one of the major components of its success is that it allowed a community (in finance) to evolve that can earn 50-150% more than their peer groups who do the same work in Java or C++. 10 years ago a kx course cost $1500 per person per day.
To note that those are typical prices for enterprise level certifications, including some products that some Java or C++ devs might need to interact with, when working on those kind of environments.
A companion guide that I always recommend if interested in K is: Q for mortals, found here - https://code.kx.com/q4m3/
Note, from wikipedia: Q serves as the query language for kdb+, a disk based and in-memory, column-based database. Kdb+ is based on the language k, a terse variant of the language APL. Q is a thin wrapper around k, providing a more readable, English-like interface.
Coding Style The q gods have no need for explanatory error messages or comments since their q code is perfect and self-documenting. Even experienced mortals spend hours poring over cryptic q error messages such as the ones above. Moreover, many mortals eschew comments in misanthropic coding macho. Don’t.
I always thought it sounded super cool but it just doesn't exist in the problem spaces I work in. Like kdb+ was specifically designed to be run on bare metal without a full OS in the way of things going fast, and in quant environments where you're trying to shave off nanoseconds on the computations because your company's gone and invested in a dedicated fibre line to trading servers.
Readit News
I almost wish this link was to a blog rather than to a book about K, for which I only have a perennial curiosity.
Here's to hoping they consider writing said blog. I notice they have one but it only has 3 posts, all of which are about past Advent of Code puzzles.
Guessing you meant to say "peripheral curiosity" here? Perennial would mean you have a long-lasting and/or continued interest/curiosity.
Uiua[0]'s stack model is much more annoying to work with, but I really appreciate its embrace of unicode glyphs. Every other derivative of APL throws those out at the first opportunity, but when you have a lot of glyphs, you stop being so tempted to make different arities cause the same glyph to mean wildly different things, when the arity is not actually written down explicitly and depends on whether the next thing to the left is a parameter or another function. Once you can See The Matrix, this is the chief thing that still does make K and friends objectively unreadable in a way they don't have to be.
[0]: https://uiua.org
K has "traditional names" for all the primitive operators which appear in reference cards and which are typically used when discussing code aloud with other K programmers. Q and Lil, which are both K descendants, outright replace some symbols with those named keywords. Named keywords can make the primitives superficially easier to remember, at the cost of making idiomatic patterns in the language less visually apparent.
To be frank, your quote is mind-bogglingly stupid. How easy do you think Java is to read to a native Greek speaker with no English language knowledge? Would the Java standard library be as easy for you to read if it were written in Greek? Would java still be an easy to read language if all the keywords and library were in Greek?
If your only definition of a good programming language is one written in your native language and a PL becomes bad if written in a different language, then your criteria is terrible/useless. And right now that's your criteria.
I don't know about the qualities of k itself, but I think the idea of having a common practice for experimental programming languages to be grouped under a single name like "E" with a number is quite attractive.
There are lots of students, hobbyists, researchers, professional devs and companies who are developing their own working programming language. There are a million of them, all with their own names. 99.9% of them are ignored, or criticized unfairly by others expecting fully fleshed out features.
I can imagine a GitHub repo where you can register a new language "En" (with n being a number) rather than it living in obscurity on a random website. Then others can jump in and experiment with the language and give it feedback, fork it, etc.
This isn't just for toy languages, but for big organizations like Google. Instead of naming a not-fully-baked C++ successor as "Carbon" and getting flak for it not being ready for real world code yet, they could simply call it "E321" and the status of the language would be self-explanatory.
Then if one of the E languages gains enough traction, it could "graduate" to its own named language.
I also like the cred that an "official" E language could get when a dev talks about it to others. Everyone would immediately know it was experimental and where to see the code.
That said, some form of array language more suited for stuff like that is a somewhat common question; maybe one day someone will figure it out.
Vanessa McHale is doing some interesting work on a typed compilable array language, Apple[0].
[0]: https://github.com/vmchale/apple/?tab=readme-ov-file#apple-a...
While we have CUDA being polyglot, it is still pretty much C and C++, or shader languages, hence why I keep thinking why not an array language that is also a kind of shader language DSL.
[0] https://futhark-lang.org/
Thanks for the heads up nonetheless.
What problem is K trying to solve? What does a K program look like?
But, this sort of language is more about writing and reading from the disk efficiently, right? I guess SIMD type optimizations would be less of a thing.
Here's a program in k. I'm not sure exactly what it does. I think it might be a json encoder/decoder:
https://github.com/KxSystems/kdb/blob/master/e/json.k
>What does a K program look like?
You might want to check out https://news.ycombinator.com/item?id=40335921
beagle3 and geocar both have various comments you might want to search for.
With an Oracle-style DeWitt clause[1] prohibiting public benchmarks.
[1] https://mlochbaum.github.io/BQN/implementation/kclaims.html
Two reasons k folks like k: first, if you believe that programmer working memory, as in the number of chars or lines of code you personally can hold in your head is limited, then it might make sense to be as terse as possible -- this will significantly increase the range of things you can reason about.
Second, if such a language were to focus more on array and vector-level manipulation, then for certain sorts of math tasks, you might be pretty close to grad student nirvana -- programming looks like using a chalkboard to work out a strategy for some processing, and then straightforwardly translating this strategy without mucking around with all the 100s of lines of weird shit say python or java make you do to process something in bulk and in parallel.
On top of this, whitney is a mad genius, and his k interpreters tend to be SCREAMING fast, and, like a couple of hundred kilobytes compiled. Over time the language has built connections to large-scale data processing jobs (as in, you run a microsend-or-shorter-timeframe strategy based on realtime depth data from 500 different stocks, say), and it has benefitted from the path dependence you get there.
Anyway back to the top - it exists as both a rallying cry for and a great tool for a certain sort of engineer that wants to make millions of dollars and refer to him/herself as a "Spartan" of coders.
So I think k, q and kdb are fun to work with, but one of the major components of its success is that it allowed a community (in finance) to evolve that can earn 50-150% more than their peer groups who do the same work in Java or C++. 10 years ago a kx course cost $1500 per person per day.
Deleted Comment
I get the idea that one either already knows one needs an array programming language, or doesn't grok why anyone would need one
Note, from wikipedia: Q serves as the query language for kdb+, a disk based and in-memory, column-based database. Kdb+ is based on the language k, a terse variant of the language APL. Q is a thin wrapper around k, providing a more readable, English-like interface.
https://code.kx.com/phrases/wikipage/
https://code.kx.com/q/kb/programming-idioms/
https://code.kx.com/phrases/
It's primarily used for trading research and surveillance, not live trading. And I've never heard of anyone running it without an OS.
kOS is in development though current status is unknown.
(https://gist.github.com/chrispsn/da00835bb122c42f429a084df83...)
For those curious, what they're actually using is FPGAs and custom silicon.