Stages of Denial

[TheAceOfHearts]

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.

[aaron-santos]

If you internalize this cursed knowledge, you will see how language[C]-evangelists cherry-pick which dimensions to measure the value/success of a programing language. Don't proceed. It will make you frustrated, cynical, and disillusioned with the state of PL discourse.

[DonHopkins]

Can I write one regular for loop to ten around one regular for loop, instead of ten regular for loops?

[danwills]

I know it's a joke but I don't really agree that this area is cursed! It just delves way deeper into syntactical terseness than many programmers will tolerate.. even compared to assembler it's quite a different beast.

I think still potentially very interesting if you're keen on expressing the most computation using the smallest number of characters though!

[agumonkey]

I developed this on a society scale. Every time I go to a place and people are using very wrong ways (from normale like using an old excel file as a collaborative dB or wilder like printing Excel sheets to write changes wih a pencil to edit the file later...) I go depressed.

[goto11]

I find it rather weird to compare K to C. In what circumstances would the choice be between K and C? A more reasonable comparison would be between say Python with numerical libraries and K.

[mqpasta]

Ah, true!

[anyfoo]

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))".

[endgame]

The lens library has a reasonably consistent visual language baked into it:

- Operators containing `%` apply a function to the target (mnemonic: % is "mod" in many languages).

- Operators containing `=` have a `MonadState` constraint and operate on the monadic state.

- Operators containing `~` operate directly on values.

- Operators starting with `<` pass through the new value.

- Operators starting with `<<` pass through the old value.

- Operators containing `@` operate on indexed optics (mnemonic: indices tell you where you are "at" in the structure you're traversing).

So an operator like `(<<<>=)` means "semigroup append something in the monadic state and return the old result". This is the power of a well-chosen symbol language, and I don't know how you'd do this ergonomically and compactly with only named operators.

[WillDaSilva]

As anyone who uses such a language could tell you, you get used to the symbols quite quickly, and commit their meaning into memory. For that reason I mostly view the heavy use of symbols in a programming language as a negative only insofar as it makes it intimidating to newcomers.

The only other thing can I find can be an issue with the heavy use of symbols in a language is that it can lead to a certain degree of inflexibility in the language. There are only so many symbols that can be used, and once they're all used up your options are either use normal variable names (and reduce the number of ideas that can be expressed concisely), or make symbols context dependent.

The designers of k went to some lengths to avoid the use of variable names, so some symbols are better than others in terms of clarity. Some mean the same thing everywhere, but others are heavily context dependent in an effort to reuse the limited amount of symbols they have at their disposal.

k is a great domain-specific language, but struggles at being a good general purpose language for a variety of reasons. I'd love to be able to use it for data processing inside of other languages. Let the other less expressive but more robust languages handle the control flow, library interactions, etc., and then run k code to work with data as vectors and tables. If only k supported n-dimensional arrays, then it'd be very interesting to see what it could do if integrated with something like Numpy, but I could spend all day wishing k was better than it is. I'm very happy with what it's able to do, and generally groan when I find myself having to use other less expressive data processing tools (which is practically everything).

[tablespoon]

> 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].

I think the "if you are deeply familiar with them" is important. Using non-standard symbols makes comprehension more binary: either you've memorized them and understand or you don't; there's no muddling through, relying on common concepts and terms to make up for incomplete memorization.

That probably also results in a much more binary user base: true-believers who dedicated a bunch of time to become proficient, and non-users who were unable or unwilling to, and not a whole lot in between.

[initplus]

The trouble in Haskell is that an operator like %%@~ is just an arbitrary name.

In languages like K or APL, the combination of symbols is the actual definition.

[chiph]

    {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.

[travisjungroth]

I think this hints at the main issue people have when reading more terse code: you need to read it slower. If you try to read K at the same speed as C, it’s going to fly by. I can feel this in my own Python code when I write in a more or less compact style. But on the more dense code, if I slow down, I can understand it faster and more clearly than the verbose code.

[rak1507]

Been doing k for a bit (under a year). A single glance is optimistic, but probably only took me a few seconds. Almost certainly faster than any equivalent code in any other language. It's even easier if you give it a nice name, like "fib".

[Aerroon]

How many years did you spend on mathematics? How comfortable are you with reading math notation?

I think the same problem applies. If you don't remember the specific of a symbol it becomes difficult to understand what the symbol might be without context.

[lvncelot]

Is it that much worse than, for instance:

  kvPairs.reduce((acc, [k,v]) => ({...acc, [k]: v}), {})

(Which obviously has nothing to do with the K-Snippet but is the first thing that came to my mind that's equally as symbol-heavy)

[still_grokking]

  fib = 0 fby ( 1 fby fib + next fib );

That's how this would look in a data-flow language.

"fby" means "flowed by". It constructs a stream.

So you can be quite terse without loosing the clarity just by using the right abstraction.

Example taken form:

https://en.wikipedia.org/wiki/Lucid_(programming_language)

[WillDaSilva]

The /0 1 gives it away practically immediately for me, but that might just be because I've seen/used that particular example so many times.

[tarxzvf]

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.

[nlitened]

How about this: K is an interpreted language, but your whole program's source code plus the interpreter plus the whole database engine fits inside your server's L1 cache, so K programs tend to be faster than their C equivalents (in addition to all the array operations being highly optimized).

And you don't get to waste time scrolling, your typical module's code fits on your single screen.

[scns]

Sorry to be pedantic, but even if you said english and chinese, the analogy would still be off IMHO.

[nine_k]

> 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.

[vintermann]

You certainly can do points-free programming in Haskell. It's the first place I ever heard of it.

Ironically, points-free programming in Haskell has a lot of '.' in it.

[WillDaSilva]

I love the idea of using k as a DSL (domain specific language) for working on time-series data. Something like it would also be great for working on n-dimensional arrays, but unfortunately k doesn't really support working with them in any elegant or efficient way.

Python and Numpy would benefit a lot from having something like k to express vector/matrix operations elegantly.

[turbinerneiter]

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.

[still_grokking]

But why not just write

  (0 to 99).sum

That's not much longer, and quite readable even for the uninitiated. (It's a Scala expression, so not made up).

[goto11]

> Imagine the second line being added in by your ide in a light gray.

So what would be the benefit compared to just writing `plus reduce range 100`?

[peterburkimsher]

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.

[raldi]

I guess the ending is supposed to be a joke, but because the piece never explains what | means, I couldn’t figure it out.

[galkk]

I guess it means "max" or something like that (comparison operation?), and |/ means "max of an array".

Author builds this up by showing how long is writing "max" function with other approaches (iteration, reduce).

Can be wrong though

[jitl]

    Math.max(...list)

[emptysea]

Got to be careful with the argument spread, since depending on the JS engine and how large the `list` is, you can end up with a RangeError

e.g.,

    Math.max(...Array(100_0000).fill(0))

results in:

    Uncaught RangeError: Maximum call stack size exceeded

[LAC-Tech]

Huh, I had no idea that function had variable arity. Thanks.

[arthurcolle]

Enum.max(...list) ;)

[LAC-Tech]

So are array languages polish notation?

    +/!100

feels like the opposite way you'd write it in some kind of RPN concatenative language

    100 ! [ + ] /

[CraigJPerry]

You read it strictly right to left, weird idea to me but it’s common in the array languages - j and APL do it this way too.

I believe the reasoning is something like Iverson (or maybe Whitney) didn’t like the complexity of PEMDAS in maths so decided on this rule.

[tzs]

In Polish notation all the operators are prefix operators.

In APL family languages there are infix operators and prefix operators.

Prefix operators take as their operand the result of everything to their right. Infix operators take as one operand everything to their right and take as their other operand the first thing on their left.

[Jtsummers]

Not quite. + isn’t the last thing done (which it would be in Polish notation). Instead it’s done during the / operation.

Polish notation would be lisp (or the notion most people have for lisp, special forms and macros break it up a bit).

[pdimitar]

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.

[kubb]

I love the bit about junior stanford educated Google employees :)

[kleene_op]

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.

[gHosts]

This is either the most important paper in Computer Science.... or a trivial side effect of representing function composition by string concatenation...

http://nsl.com/papers/rewritejoy.html

[compressedgas]

I have come to call:

        [A] a = A
        [A] b = [[A]]
    [A] [B] c = [A B]
        [A] d = [A] [A]
        [A] e =
    [A] [B] f = [B] [A]

This the minimal Joy.

  [[db]fbcabc[da]cfc]da

This program is one I most like.

Vg vf gur cnenqbkvpny pbzovangbe.

[nope96]

also posted previously as

Stages of denial in encountering K, March 9, 2020, 422 comments https://news.ycombinator.com/item?id=22504106

[dmor]

Wow, this is art

Wonder how many people did not skip to the end and then skim back

[Anunayj]

Wait... How did that happen.

[vanderZwan]

> 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;
    }

[marrowgari]

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/

[chronolitus]

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?

[eevilspock]

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

[gjulianm]

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.

[rak1507]

Where to start reading: https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.... maybe

If you ever feel like trying it again, and get stuck on something, https://chat.stackexchange.com/rooms/90748/the-k-tree is the place to ask :)

[z3t4]

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.

[still_grokking]

It's likely a mater of what you're used to.

I start to feel uncomfortable when I see an explicit loop.

But that's actually very weird as I write Scala a lot where you use "for" (instead of "do-notation") for monadic computations.

My brain starts smoking when someone uses a "for" as an regular loop! That causes usually a few seconds of complete confusion. :-D

[razetime]

It's all up to preference, really. It took me a while to get around my muscle memory from general imperative programming by the time I started using languages like K competently. Getting that motivation is definitely hard.

[goto11]

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.

[mr_vile]

the symbols compose in both directions and are aware of tacit parameters, so I don't really think your summary is even remotely correct

[BugsJustFindMe]

> 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)).

[jasonwatkinspdx]

Yeah, ever since running into this little snippet eons ago, I've found the symbols are better argument for APL style languages quite weak: http://nsl.com/papers/kisntlisp.htm

Since the arity of all the primitives are known there's less parens than lisp. That seems like the clear sweet spot to me.

And I think this is born out with K the product. One of the things they added with Q is a more text oriented syntax.

The big a-ha in APL style languages is shifting from thinking about loops and iterating over single elements to transforming tensor like objects. It's a powerful approach no matter what language and syntax you use.

[rak1507]

Yes, a direct translation. (Using the reduction)

[smoldesu]

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.

[wging]

K is not an esolang and was not designed for golf; it has real users. https://en.wikipedia.org/wiki/K_(programming_language)

Also, the primary goal is not always speed... runtime speed or speed of development. There are other things we trade off for all the time.

[the_af]

It should be noted that, according to Wikipedia, the K language isn't a toy language like Brainfuck but an actual language successfully used for a suite of financial software. It was developed for this purpose, not for code golf.

[TeMPOraL]

K language and APL family languages are serious business, though. And they get a head start on "extensibility" and other nice practical properties - notice how all those single-character operations are inherently and extremely composable.