I'm torn. Not about the conciseness of the language overall, but about using symbols vs. names. I do see how the symbols make things more concise, less clutter, and can even make it easier to grasp a piece of code if you are deeply familiar with them[1].
On the other hand, there might be a limit. I do know how it is to use the Haskell lens package only occasionally, and then having to lookup again what the operators read out loud as "percent-percent-at-squiggly" and "hat-dot-dot" stand for (withIndex and toListOf respectively).
But arguably, the ones that are long and seldom used need looking up anyway, and their name is not that much more useful maybe?
[1] Also compare "2+2*8" with "sum 2 to the product of 2 and 8", or even just "sum(2,prod(2,8))".
{x#x{x,+/-2#x}/0 1}
I'm sure if you used K for a year or so, that would be obvious and understandable at a single glance. But all I can think of is that I used to see that in my terminal session right after my modem got disconnected.Just replace K and JavaScript with German and English to see the vacuity of this argument. Either of several possible representations can become native to one’s thinking. The question is which is a better aid in reaching some non-arbitrary goal. The only merit of K presented and emphasized here was the supposed brevity of its programs. Personally I’ve found the habitable zone somewhere that allows for more air between ideas.
> Does giving a K idiom a name make it clearer, or does it obscure what is actually happening?
There's a balancing act around that. It's called "abstraction".
At some point, you cannot afford to know what's actually happening. If you try, the entire problem won't fit in your head. So you cut the thing you're working with to a name and an interface, and forget what's "actually happening". You do that right in the K code, because you e.g. cut your understanding of `/` to "fold the array with the preceding operation", and totally don't think about the way it's implemented in the machine code.
This, of course, does have a cost; the simplest case is inefficiency, worse are circuitous ways to arrive to logically the same result, when a much simpler way exists.
I'd argue that `/` or `+` are very much names, of the same nature as `fold` or `add`, just expressed shorter. So if you prefer point-free style, you can likely do a very similar thing in, say, Haskell (and some people do).
I'd hazard to say that APL and J are DSLs for array / matrix numeric code. They allow to express certain things in a very succinct way. What APL traditionally had, mmm, less than ideal experience was I/O, because the language is not optimized for the branchy logic required to handle it robustly. K is a next step that allows to escape into "normal-looking" language with long names, explicit argument passing, etc when you feel like it.
Also, I love this idea: «APL has flourished, as a DSL embedded in a language with excellent I/O. It's just got weird syntax and is called Numpy.» (https://news.ycombinator.com/item?id=17176147) The ideas behind APL / J / K are more interesting than the syntax, and haven't been lost.
I recently started using rust-analyzer with vscode.
One common sight is this:
thing
.stuff()
.other()
.whatevs()
Each of the calls returns a different type. Rust-analyzer displays the return type of each call to the right of it.I imagine something similar could reconcile the benefits of terseness with readability and discoverabilty.
The blog post already has the prototype:
+ / ! 100
plus reduce range 100
Imagine the second line being added in by your ide in a light gray.
The uncanny rapport I feel by reading "lazy Tuesday afternoon, visiting The Orange Website, self-consciously averting your eyes from the C compiler output in a nearby terminal" builds enough trust that I'm willing to pay attention to what John Earnest (IJ or RtG) has to say about this. He's a great writer.
Naming things is hard. It's one of the 2 most difficult problems in CS, along with cache invalidation and off-by-one errors. Of course, in this context I mean "CS" as "Computer Science", not "CouchSurfing".
For the K programming language, meanings are specifically defined. In the article:
"The word “ordinal” can mean anything, but the composition << has exactly one meaning."
That's fine for the K compiler, but not for Google Search, or grep. I use "<<" to mean a bit shift to the left, presumably because I was taught C in university.
Unique names are more useful for addressing (e.g. IPV6) but common names are more memorable (e.g. a URL. Translators (e.g. DNS) can't be perfect when there's a one-to-many or many-to-one correlation, but they try their best.
K does well to enforce structure, but in the process, makes it very hard for the programmer to find examples and other documentation. I guess that's why the language hasn't become as popular as other languages, whose syntax is sufficiently familiar to be legible and memorable but unique enough to be searchable.
I guess the ending is supposed to be a joke, but because the piece never explains what | means, I couldn’t figure it out.
Math.max(...list)
So are array languages polish notation?
+/!100
feels like the opposite way you'd write it in some kind of RPN concatenative language 100 ! [ + ] /
Programming language syntax is very much like the human languages themselves: it (re-)shapes your thinking.
I want to learn things that shape my thinking in a way that makes me more efficient, and in a way that makes it easier to express ideas.
If your language isn't giving me that then it's bye bye.
I get the appeal but squinting your eyes at a string of single-character symbols is taking it too far. The whole thing has to be somewhat ergonomic as well.
I love the bit about junior stanford educated Google employees :)
In my opinion, the conceal feature in Vim provides the best of both world to the name vs symbol problem.
When you want to review your code, you just go into normal mode, concealing all lengthy but frequent names into appealing symbols. When you want to write code, you switch to editing mode and all symbols on the editing line turn back into names
I use this feature mostly with python code. One liners making proficient use of lambdas, maps, reduces, and other functional treats are satisfyingly condensed, reducing the amount of attention required to parse each line.
No need for custom keyboards. People don't have to parse arbitrary symbols to understand what I wrote because the underlying code remains vanilla.
A drawback is that the apparent conciseness tricks me into writing very big one-liners difficult to parse when all terms are expanded.
This is either the most important paper in Computer Science.... or a trivial side effect of representing function composition by string concatenation...
also posted previously as
Stages of denial in encountering K, March 9, 2020, 422 comments https://news.ycombinator.com/item?id=22504106
Wow, this is art
Wonder how many people did not skip to the end and then skim back
> list.reduce((x,y)=>Math.max(x,y))
Honestly, while I like the clarity, I would still dislike it in JavaScript for performance reasons, because in JavaScript reduce is not optimized at all. And yes, I do work on a code-base where that difference is significant.
Also, that loop can still be cleaned up a bit in modern JS:
let max = list[0];
for (const v of list) {
if (v > max) max = v;
}
A slightly more verbose (less abstract) version of k would be q. Kx (proprietary owners of k/q) have a nice reference page if you're interested in learning more about the language, e.g., where it's used and how it's used... https://code.kx.com/q/ref/
Maybe the issue is that the symbols we readily accept are the ones we grew up with when learning Mathematics, + - * / ^ % = ..
If 'reduce' and 'map' had widely used symbols, which were taught in school / university as part of the standard curriculum, how different would coding look today?
Hint: K is the name of the central character in Franz Kafka's The Castle, as well as that of The Trial.
> "The term "Kafkaesque" is used to describe concepts and situations reminiscent of Kafka's work, particularly Der Process (The Trial) and Die Verwandlung (The Metamorphosis). Examples include instances in which bureaucracies overpower people, often in a surreal, nightmarish milieu that evokes feelings of senselessness, disorientation, and helplessness. Characters in a Kafkaesque setting often lack a clear course of action to escape a labyrinthine situation. Kafkaesque elements often appear in existential works, but the term has transcended the literary realm to apply to real-life occurrences and situations that are incomprehensibly complex, bizarre, or illogical."
~ https://en.wikipedia.org/wiki/Franz_Kafka#%22Kafkaesque%22
I remember a discussion on HN on this language like a year ago or so. In the end what I got was some extremely weird snippets for very specific little quizzes that someone claimed were faster than with other languages, the argument that "it's shorter" and "but I can work with it".
So yeah, if you like it, I get it, go enjoy it. But this smugness of "it's actually better and I'm better for knowing it", it irks me. One of the most important aspects of programming languages is that they need to be used, and K is the single hardest language that I've tried to understand, even with documentation on the other screen and reading just short snippets. A language that people will ignore because they don't even know where to start reading is not that good of a language.
I already have problems reading arrow/inline functions... for example where a method is called with a function that returns a function... if there is one more (async) call in there my brain starts smoking.
So it is a language with single-character symbols for the most common array operations like map, filter etc.
I think the article tries to make it sound more mysterious and groundbreaking than it really is.
> a more direct translation into another language might look like: range(100).reduce(plus, 0)
That's...uhh...one way to do it. But it's a lot shittier to read than sum(range(100)).
One important thing to remember about esolangs like this is that theory != implementation. Just because Brainfuck "theoretically" exists as a language doesn't automatically solve issues like memory management or extensibility. Sure, maybe it is more ergonomic to write some functions in K. But, as with most code-golfing languages, the goal isn't to build a better language, it's to build a faster one.
Maybe K can run those programs faster than Lisp/C/$FAV_LANG, but it's ultimately up to a much smarter programmer to implement that bit.
This is a category of cursed knowledge which causes psychic damage to the reader.
When you go down certain rabbit holes you develop a fascination with obscure forms of programming and start to realize it has some powerful benefits of which you can never take advantage because it isn't widely adopted.
To free yourself from this curse write ten regular for-loops in C and say a prayer to K&R while tighly holding your copy of The C Programming Language.