Just... no. What are you even trying to compare? UX of a language matters. Clarity, thinking paradigm, expressability etc. all matter and are affected by the visual size of code.
A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem. Flitting your eyeballs around a screen takes orders of magnitude less effort than scrolling around and navigating files. Cognitive load is important.
We really need to burn this vague "only semantics matter" scourge that's creeped into our programmer values these days. I'm sorry, but I care about things like incentives against over-engineering, ease of directly thinking in the problem domain, and simplicity of the encompassing ecosystem.
A terse one-line solution tells me there is virtually no room for over-engineering. Even without knowing K, I can see obvious constants side-by-side, telling me it's likely using a direct data representation of the problem in its code. Does K culture encourage code like that? Does programming in K bias you towards directness and simplicity? Then please, I want some of that special sauce on my team.
"A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem."
When I work on some more complex problem, I like to think about the problem, not spend energy decoding condensed text. Scrolling a bit more verbose but clear code, is faster for me.
Why not create a programming language, that uses all possible unicode codepoints to further decrease the number of characters used? That would be so much more readable!
The built-in functions and API to a system library spoil these metrics. As an example, consider HQ9+, which is pretty good at printing "Hello, world!" for instance.
I've been messing with Uiua (https://www.uiua.org/) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
I work with it daily in a bank, and I couldnt find a better way to express it. Many colleagues throwing their keyboard in despair at this stupid impossible to remember syntax.
There are a lot of things in various programming languages which are hard to remember, but k and array languages have such a small surface area, not being able to remember it while working with it daily amounts to learned helplessness.
(source: mostly amateur k programmer, also worked with it in a bank, find it vastly easier to read/write/remember than most mainstream languages)
Not that it's impossible to remember, bit it's definitely contrary to most traditional use of the symbols employed in it, though not without logic. My favorite is the functions from io package, called 0, 1, and 2 (yes, numbers) which handle interaction with stdin, stdout, and stderr respectively. In dyadic form they at least have a colon, but in monadic form they look like plain numbers: 1 "Hello world".
I suspect that to study k (and use kdb) efficiently, you need to actively forget what you knew about the syntax of other languages, and study k as a language from Mars that happens to map to ASCII characters somehow.
It is really easy to remember; it is so small that remembering is the least of the issue. The rest is just using it a lot; I find it readable and nice to work with. Unlike other some other languages we get shoved down your throats.
"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
— Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.
This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes.
For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against.
In a living environment the software lives too, and keeps changing and adapting.
> That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to.
I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.
you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare
> There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
You could also say that the average bank/company should have learned from previous mistakes doing exactly that for many decades. Select a language that is well tested, understood and supported. Set a limit on cleverness and instead focus on maintainability and simplicity.
The LoC count and similar metrics have the advantage of an easy calculation.
Ultimately though,they are a proxy to a more relevant but difficult to determine attributes such as
Given a reasonably proficient engineer, the amount of time it would take them to resolve a bug in code written by someone else or alternatively extend its functionality in some way.
From the linked page (and the one linked beyond that), it's a breadth-first search actually. Keep a list of possible puzzle states at all times, pick a blank cell (theoretically arbitrary, but in practice intelligently for performance), add copies of the state with each possibility for that state added.
> Why array languages seem to gravitate to symbol soup that makes regex blush I'll never know.
Because the HN crowd is amazed by the cool hacker vibes of the symbol-soup subset of array languages. The comments also reflect an (unfounded) elitist attitude.
Matlab, for example, is very commonly used array language in the wild and is definitely not a symbol soup. Bit more verbose but makes the array programming paradigm very approachable (and other paradigms are also supported).
The discussions around “line noise”-languages are always intersting.
Most programmers would agree the ‘/’ symbol is at least as clear as writing ‘divideBy’. The question is how often the symbols are used and if their frequency in code justifies learning them.
You don't really have to worry about keeping track of tons of functions, variables, structs, classes, etc., and trying to keep all the names straight in your head - all you need is to know the symbols, so it's in some ways easier than reading a complex function in more verbose languages where you might need to lookup stuff from several libraries just to understand what's going on. Also, that one line is ~100 characters, each of which probably covers ~0.5-1 lines in other languages, so you should expect to set aside a similar amount of time to reading and understanding it.
I suspect that if you're fluent in the language, understanding an expression written in it comes just as easily and quickly as reading a sentence in a book does to me.
i've only seen these style of languages commented after a contest is over on stack programming challenges. I have no idea how one would learn all this stuff from code in the wild (like i learned most of python, for example). then again, i don't go searching github for k, apl, or perl for that matter.
I'm sure each of those languages makes some guarantee about the sorts of errors that can be introduced - as opposed to C (let me pick on it) where the errors you know you can introduce, and the errors that are introduced aren't a large union. However i have a hard enough time typing english consistently, so the various "symbol-y" languages just glaze my eyes, unfortunately.
It almost "feels" like these languages are an overreaction to the chestnut "they must get paid by LoC".
But -- (and forgive me if I'm totally wrong) -- this isn't just "non-english" but "non-phonetic" which is a smaller set of written languages, and the underlying language is ... math.... so understanding the underlying grammer itself relies on having decades of math education to really make it jive.
If this code is just a final result of "learn math for 2-3 decades, and spend years learning this specific programming language" -- my statement stands. Interacting with this kinda binary blob as a programming language is impressive. I think I read somewhere that seymour cray's wife knew he was working too hard when he started balancing the checkbook in hex...
The underlying language isn't really very mathematical, at most there's a bit of linear algebra in the primitives but that's it. You certainly don't need any sort of formal maths education to learn APL. There are about 50 or so new symbols, which is not a big ask, with any sort of focus the majority of the syntax etc can be learned very quickly. The "bugs" in your original code stand out very clearly because things like "∘}" don't make sense, ∘ being "dyadic" (infix).
and it bears mention that a decent chunk of those symbols are things nearly everyone is familiar with from other languages (+, -, =, etc), symbols you've probably seen in math class or on your graphing calculators (÷, ×, ≠, ⌈, ←, etc), and symbols with very strong mnemonic associations once you've seen them explained (≢, ⍋, ⍳, ⌽, etc).
As a kdb+/Q programmer I would say it depends on the type of problem.
For example, when working with arrays of data it certainly is easier to think and write “avg a+b” to add two arrays together and then take the average.
In a non-array programming language you would probably first need to do some bounds checking, then a big for loop, a temporary variable to hold the sum and the count as you loop over the two arrays, etc.
Probably the difference between like 6ish lines of code in some language like C versus the 6 characters above in Q.
But every language has features that help you reason about certain types of problems better. Functional languages with algebraic data types and pattern matching (think OCaml or F#) are nicer than switch statements or big if-else-if statements. Languages with built-in syntactic sugar like async/await are better at dealing with concurrency, etc.
Which is why C# is the giant ever increasing bag of tricks that it is (unkind people might say bloat…) ;-) Personally, I’m all for this; let me express the problem in whatever way is most natural.
There are limits, of course, and it’s not without downsides. Still, if I have to code in something all day, I’d like that “something” be as expressive as possible.
Well no, not in a non-array programming language. In any language that has a semi-decent type/object system and some kind of functional programming support, `avg a+b` would just be `avg(a, b)`, which is not any easier or harder, with an array type defined somewhere. Once you make your basic array operations (Which they have to be made in q anyways, just in the stdlib), you can compose them just like you would in q, and get the same results. All of the bounds checking and for-loops is unnecessary, all you really need are a few HKTs that do fancy maps and reduces, which the most popular languages already have.
A very real example of this is Julia. Julia is not really an array-oriented programming language, it's a general language with a strong type system and decent functional programming facilities, with some syntactic sugar that makes it look like it's a bit array oriented. You could write any Q/k program in Julia with the same complexity and it would not be any more complex. For a decently complex program Julia will be faster, and in every case it will be easier to modify and read and not any harder to write.
I don't know what you mean by the q array operations being defined in the standard library. Yes there are things defined in .q, but they're normally thin wrappers over k which has array operations built in.
For some classes of problems that are easily vectorized, using an array-focused language can certainly make thinking about them and their solutions more efficient, since you can abstract over the data structure and iteration details.
As a quant, I used kdb+/q quite a bit for 5+ years for mid-frequency strategies, but as I moved towards higher frequency trading that required calculations on the order book that couldn't be easily or efficiently vectorized, then continuing to use array-focused languages would have only complicated reasoning about those problems.
I went to this tech talk on Dyalog (a modern APL-like language), and the speaker makes the argument that the notation allows certain idioms to be recognized more easily:
This particular snippet was in the context of compilers, but the rest of the talk has more on Dyalog and APL as a system of mathematical notation. The underlying theme is that optimizing mathematical expressions may be easier than optimizing general code.
one nice thing about the array language style is that it's possible to talk about variations on algorithms where the relevant code snippets, being a few characters, fits inline into the discussion; more traditional vertically-oriented languages that take handfuls or dozens of lines to say the same things need to intersperse code display blocks with expository prose
Hillel Wayne writes about it on his newsletter every once in a while. He's convinced me that he does in fact think through some problems better in array languages but I still can't really conceive of what that experience is like.
if it's something you're interested in trying i'd be happy to point you toward more resources, and i'm sure there are plenty of other arraylang tinkerers reading this thread who could help, too
Most people are put off by the symbols, that wasn't really the issue I had.
So I do love APL and arraylangs, and learning them was really helpful in a lot of other languages.
But they never became a daily driver for me not because of the symbols, which were honestly fine if you stick with it long enough, but after about 3-4 years of dabbling on and off I hit a wall with APL I just couldn't get past.
Most other languages I know there is a "generic-ish" approach to solving most problems, even if you have to cludge your way through suboptimally until you find "the trick" for that particular problem and then you can write something really elegant and efficient.
APL it felt like there was no cludge option -- you either knew the trick or you didn't. There was no "graceful degredation" strategy I could identify.
Now, is this actually the case? I can't tell if this is a case of "yeah, thats how it is, but if you learn enough tricks you develop an emergent problem solving intuition", or if its like, "no its tricks all the way down", or if its more like, "wait you didn't read the thing on THE strategy??".
Orrr maybe I just don't have the neurons for it, not sure. Not ruling it out.
So I fed this to Claude. First of all it was able to identify that it's K programming language.
Then I asked it to explain it and here's what it provided, kinda impressive though not sure if it's correct:
----
Certainly, I'll do my best to break down this K code. Keep in mind that K is a very terse language, so each symbol can represent a complex operation. I'll explain it step by step:
1. `!9 9`: This creates a 9x9 matrix (likely representing a Sudoku grid).
2. `p:!9 9`: Assigns this 9x9 matrix to variable `p`.
3. `-3!p`: Divides the grid into 3x3 boxes.
4. `3/:-3!p`: Reshapes the result, likely to group the 3x3 boxes.
5. `,`: Flattens the result.
6. `p,:,3/:-3!p`: Appends the flattened 3x3 groupings to `p`, creating constraints for rows, columns, and 3x3 boxes.
7. `p[;y]=p`: Compares each value in `p` with the value at position `y`.
8. `|/p[;y]=p`: Finds the maximum (essentially, checks if the value exists in the constraints).
9. `x|/p[;y]=p`: Multiplies the result with `x` (likely a mask of available positions).
10. `(!10)^...`: Creates a list of numbers 1-9 that are not in the result of step 9.
11. `@[x;y;]'...`: Applies the result to position `y` in `x`.
12. `{...}'`: This is an each-right apply, performing the operation for each element.
13. `,/...`: Flattens the result.
14. `x(...)/&~x`: This is a fixed-point iteration. It repeatedly applies the function until the result doesn't change, starting with the positions where `x` is 0.
In essence, this code appears to be a very concise Sudoku solver. It iteratively fills in values that don't conflict with the rules of Sudoku (no repeats in rows, columns, or 3x3 boxes) until the puzzle is solved or no more moves can be made.
This is an advanced piece of K code, showcasing the language's ability to express complex algorithms very concisely.
--------------
Interestingly ChatGPT 4o-mini identifies it as J programming language. Here's what it gave me:
The code you've provided is written in J, a high-level, array-oriented programming language. J is known for its concise syntax, where operators and functions are often combined into compact expressions.
Here's a breakdown of the code:
x: In J, x is a variable or a value that is being manipulated by the functions and operators.
,: The comma is used in J to concatenate items or to create a list of results.
/{...}: The / is the "each" operator in J, meaning the expression inside the braces {...} will be applied to each element of the array x.
@[x;y;]: This is an "indexing" function in J, accessing elements of x and y based on the indices.
*'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9'**: This part is a combination of multiple functions applied to the variables x and y. Specifically, ! generates random values, ^ is exponentiation, and *| performs a mathematical operation based on the result of x and y. The part with 3/:-3!p is more complex, but it's working with lists of values.
This code is likely intended for some specific computation in J, and the compact nature of J's syntax can make it difficult to decipher at first glance.
Gemini also identifies it as J and this is the output for comparison:
The programming language used in the code is *J* (pronounced "Jay"). It's a concise, array-oriented programming language known for its expressive syntax and powerful capabilities.
Here's a breakdown of the code:
*1. Verb Definition:*
* `x(,/{@[x;y;]'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9}')/&~x` defines a verb (a function in J terminology) and assigns it to the variable `x`.
*2. Verb Structure:*
* `x( ... )/&~x` is the basic structure of the verb.
`x( ... )` applies the verb defined within the parentheses to its argument, which will be `x` itself.
* `/&~x` is a hook, a control flow construct in J. It applies the verb defined within the parentheses to each element of `x` and then applies the verb `&~x` to the resulting array.
*3. Verb Body:*
* `,/{@[x;y;]'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9}` is the body of the verb.
Let's break it down further:
* `{@[x;y;]` creates a gerund (a verb-like noun) that takes two arguments, `x` and `y`.
* `'(!10)^x` generates an array of `x` elements, each raised to the power of `!10` (factorial of 10).
`/p[;y]=p` is a conjunction that appends the value of `p` to itself for each element in `y`.
* `,:,3/:-3!p:!9 9}` generates an array of 3 elements, each of which is the factorial of `-3` (which is undefined and results in an error) followed by the number 9.
*4. Overall Functionality:*
* The verb takes an array `x` as input.
* It applies the gerund to each element of `x`, creating an array of arrays.
* It then applies the conjunction to each of these arrays, appending the value of `p` (which is likely defined elsewhere in the code) to itself.
* Finally, it generates an array of 3 elements with errors and 9s.
* The hook `/&~x` applies the verb to each element of `x` and then applies a function that is likely defined elsewhere in the code (since `&~x` is not defined within this verb).
*Note:* Without more context about the definitions of `p` and other variables or functions used in the code, it's difficult to provide a more precise explanation of the verb's exact behavior. However, the breakdown above should give you a general understanding of the code's structure and logic.
I cannot comprehend the mindset of people who decide to spam (because that is what your comment is) any forum with a page of bullshit GPT slop. Do you think it's helpful or interesting?
Personally I believe it is interesting since it shows the current state of the art for the 3 LLMs.
I was surprised that Claude was able to identify the language and explain the code.
But, please feel free to downvote my comments. I guess the aggregate in the end will demonstrate whether it was a useful comment or spam + bullshit GPT slop.
Please don't litter HN with LLM spam, it adds nothing of value to the discussion. You even said it yourself, you have no idea if any of the word vomit is true or not.
Does anyone have any thoughts on what motivates people to play sudoku or write solvers for sudoku ? I have trouble finding motivation to solve artificial problems. That said I sink hundreds of hours into factorio.
For me personally, I have little motivation to do classical sudokus. They either have a not-so-elegant solve path (usually set by a computer) or are too difficult for me to solve.
Variant sudokus on the other hand are a lot of fun. They often have very elegant solve paths and there are many neat tricks you can discover and reason about.
I also mostly enjoy Sudoku variants, most of which I discovered via Geocaches, interestingly.
After solving a few I then implemented a solver with customizable constraints, if anyone's interested, should still be available here:
Like many puzzles, there’s a regular release of endorphins as you progress, and a lot of satisfaction in completing something. I enjoy puzzles just like reading a book or playing a game, it’s another world I can step into for a bit of an escape, but I like to think it’s decent mental exercise. Overall I vastly prefer cryptic crosswords where solving each clue genuinely brings a smile to my face, but that’s more of a commitment of time (and for me sometimes a guarantee of frustration). I also like doing puzzles in the newspaper because me and my kids can sit together and all contribute. Coffee, breakfast, sat in the sun with a newspaper and a good pencil[1], absolute bliss if you ask me.
As for solvers, it’s a very elegant, well-formed problem with a lot of different potential solutions, many of which involve useful general techniques. I used to dabble clumsily in chess engines and honestly it’s the only time I’ve ever ended up reading Knuth directly for various bit twiddling hacks, so it’s always educational.
idk man, you ask a good question. I think the idea has to do with the saddle you put on the invisible horse that is the game’s problem. Factorio has several complex saddles you must master to tame the beast. In factorio, you can get progressively better at using these saddles to tame even the most unwieldy scenario. Sudoku, at its heart, is not much different than factorio. However sudoku has one narrow problem with many different, increasingly nuanced ways of solving it. Factorio has many different “sudoku” style problems, but each problem needs to be handled differently, with each problem having increasing levels of sophistication. I think you might like factorio more because it’s just a bigger steak to chew on, and you’ve got the right appetite.
I don’t care much for sudoku but I do enjoy crosswords quite a lot, which feels like a somewhat arbitrary exercise. I enjoy the fact that I know a lot of words and it makes me feel clever. There’s probably something to that with most puzzle type challenges.
I teach C++ and I made my students code a Sudoku solver last year. It's a very convenient project to give them: self-contained, already familiar, no OS-specific weirdness, you get to use STL data structures, algorithms, very gentle I/Os...
All games are artificial problems, so your question actually is, what motivates people to engage in pastimes?
Sudoku, crosswords, Simon Tatham's puzzles etc. are an excellent way to pass the time while keep training the mind. Sports are their equivalent for the body.
Finally, writing solvers for a problem, be it real or artificial, for many is just another variety of puzzle to engage in.
I wasted too much time in my youth trying to min-max, and now I get bored as soon as I figure out, roughly, what the rules and mechanics look like for any game.
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
Solvers are useful for confirming that a puzzle you've recieved or generated is solvable. The meditative process can really go sideways when there is no solution for you to stumble upon.
Puzzles in commercial collections don't usually have that problem, but those from other sources sometimes do.
Solvers also make for a nice craft exercise, as here. Simple but not trivial, you can approach them in a lot of different ways and thereby work through different techniques or constraints you mean to explore.
I guess I'm the opposite. After doing a couple of sudoku many years ago my thought was "Hey, I could just automate this" and started thinking of algorithms.
I find that sodoku is not a math or even a logic puzzle, but rather an epistemology puzzle. Lots of how we know/how much we know, and if you get into speed with some failure tolerance through estimating probability it adds even more thought provoking rabbit holes.
Downvotes and upvotes work together to manage the visibility of posts that align with the community's tastes.
While I myself found an opportunity to reply to the GP and didn't down vote them, their comment only engaged with the article in a shallow way and only then, seemingly, to just dismiss the concept of solver altogether.
It wasn't a offensive comment, but it didn't really contribute to the site in the way many people digging into deep technical walkthroughs like this expect to see.
Some downvotes weren't guaranteed, but they're not surprising and they're probably helping new readers stay engaged with more topical and technical alternatives.
It's not the end of the world to get a few downvotes, and it's almost never personal. It certainly isn't here.
Aside: Downvotes on HN can be an expression of age related, self-righteous sniper pique; Opinions on what contributes to a conversation can be all over the place and are entirely subject to biases, which can be interesting (I guess). Doesn't really matter, and Hail Satan anyway. Also "Q for Mortals" is an interesting book.
Here is the line, it is written in K. K is a language created by the same person (Arthur Whitney) based on APL and Scheme.
Lines of code is a poor metric, because languages use lines differently.
A much better measure would be the number of nodes in a parse tree, of semantically meaningful non-terminals like "a constant" or "a function call".
An even better measure would also involve the depth and the branching factor of that tree.
Just... no. What are you even trying to compare? UX of a language matters. Clarity, thinking paradigm, expressability etc. all matter and are affected by the visual size of code.
A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem. Flitting your eyeballs around a screen takes orders of magnitude less effort than scrolling around and navigating files. Cognitive load is important.
We really need to burn this vague "only semantics matter" scourge that's creeped into our programmer values these days. I'm sorry, but I care about things like incentives against over-engineering, ease of directly thinking in the problem domain, and simplicity of the encompassing ecosystem.
A terse one-line solution tells me there is virtually no room for over-engineering. Even without knowing K, I can see obvious constants side-by-side, telling me it's likely using a direct data representation of the problem in its code. Does K culture encourage code like that? Does programming in K bias you towards directness and simplicity? Then please, I want some of that special sauce on my team.
</rant>
"A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem."
When I work on some more complex problem, I like to think about the problem, not spend energy decoding condensed text. Scrolling a bit more verbose but clear code, is faster for me.
Why not create a programming language, that uses all possible unicode codepoints to further decrease the number of characters used? That would be so much more readable!
The built-in functions and API to a system library spoil these metrics. As an example, consider HQ9+, which is pretty good at printing "Hello, world!" for instance.
https://cliffle.com/esoterica/hq9plus/
The preferred measure of information content is simply number of bits as used for instance in Algorithmic Information Theory [1].
[1] https://en.wikipedia.org/wiki/Algorithmic_information_theory
https://en.m.wikipedia.org/wiki/K_(programming_language)
“Expressive” = like two cats fought while standing on the keyboard
I've been messing with Uiua (https://www.uiua.org/) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
I work with it daily in a bank, and I couldnt find a better way to express it. Many colleagues throwing their keyboard in despair at this stupid impossible to remember syntax.
There are a lot of things in various programming languages which are hard to remember, but k and array languages have such a small surface area, not being able to remember it while working with it daily amounts to learned helplessness.
(source: mostly amateur k programmer, also worked with it in a bank, find it vastly easier to read/write/remember than most mainstream languages)
Not that it's impossible to remember, bit it's definitely contrary to most traditional use of the symbols employed in it, though not without logic. My favorite is the functions from io package, called 0, 1, and 2 (yes, numbers) which handle interaction with stdin, stdout, and stderr respectively. In dyadic form they at least have a colon, but in monadic form they look like plain numbers: 1 "Hello world".
I suspect that to study k (and use kdb) efficiently, you need to actively forget what you knew about the syntax of other languages, and study k as a language from Mars that happens to map to ASCII characters somehow.
It is really easy to remember; it is so small that remembering is the least of the issue. The rest is just using it a lot; I find it readable and nice to work with. Unlike other some other languages we get shoved down your throats.
Which is why banks love it. Because one has to be pretty smart to be able to wade through all that nutty, impossible to remember syntax.
Therefore, k is a smart choice, and people who use k in business applications must be really smart.
"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
— Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.
By becoming even more clever:
https://www.linusakesson.net/programming/kernighans-lever/in...
This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
It's a nice interpretation.
I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
Very unconvincing. If you become cleverer you can just write even more clever code and still not be able to debug it.
Great!
> how will you ever debug it?
By being so smart that your program has obviously zero bugs in it!
This view is too static.
That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes.
For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against.
In a living environment the software lives too, and keeps changing and adapting.
> That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time.
It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to.
I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.
you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare
> There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
You could also say that the average bank/company should have learned from previous mistakes doing exactly that for many decades. Select a language that is well tested, understood and supported. Set a limit on cleverness and instead focus on maintainability and simplicity.
But possibly not its maintainability.
The LoC count and similar metrics have the advantage of an easy calculation.
Ultimately though,they are a proxy to a more relevant but difficult to determine attributes such as
Given a reasonably proficient engineer, the amount of time it would take them to resolve a bug in code written by someone else or alternatively extend its functionality in some way.
It has strong perl vibes and it brings back ptsd :D. Maybe this overshortification of things is a personnel or intelligence indicator of some sorts.
Not knowing K, am I correct in assuming this is a backtracking brute force solver?
From the linked page (and the one linked beyond that), it's a breadth-first search actually. Keep a list of possible puzzle states at all times, pick a blank cell (theoretically arbitrary, but in practice intelligently for performance), add copies of the state with each possibility for that state added.
That sounds like 100+ lines in python or similar languages…
You should be able to do it in under 20 lines using the same matrix operations as the K code via numpy.
Numpy is indeed very apl. Just more horrible to me; not python-y and annoyingly verbose for the apl-er.
A few years back I made a modest attempt at writing a concise yet readable sudoku solver in Python - in about 29 lines: https://github.com/hrzn/sudoku/blob/master/sudoku.py
Could have been made shorter at the price of readability.
It probably isn't. At least, not for Python.
What baud is that? /s
mismatched, whatever it is, that's for sure. It's not quite line noise, so maybe it's just the wrong stop bit?
"one line in your custom language" is not one line at all lol
To be fair K is a real language that's used by more than just him.
Why array languages seem to gravitate to symbol soup that makes regex blush I'll never know.
Yeah I think MATLAB and Mathematica are waaay more used than K et al. They just don't look insane so people aren't posting them on HN as much.
> Why array languages seem to gravitate to symbol soup that makes regex blush I'll never know.
Because the HN crowd is amazed by the cool hacker vibes of the symbol-soup subset of array languages. The comments also reflect an (unfounded) elitist attitude.
Matlab, for example, is very commonly used array language in the wild and is definitely not a symbol soup. Bit more verbose but makes the array programming paradigm very approachable (and other paradigms are also supported).
Array language have been around far longer than any "HN crowd".
The discussions around “line noise”-languages are always intersting.
Most programmers would agree the ‘/’ symbol is at least as clear as writing ‘divideBy’. The question is how often the symbols are used and if their frequency in code justifies learning them.
I'll sometimes gauge code complexity by comparing the number of lines of code against the output of
IE "how much does it compress?"Looking at APL -- I'm reminded of what happens if I accidentally send the gzipped output to my tty...
I'm impressed that there's anyone who can follow along (can you find the bug?) to code like
p←{(↑⍵)∘{(⍺∨.=⍵)/⍳n×n∘}¨,⍵},(n*÷2){⍵,⍺⊥⌊⍵÷⍺}'⍳n n←⍴⍵
It really feels like compressed binary data where everyone's got a copy of the dictionary already...
Legitimately curious how APL programmers think about maintainability and readability. Is code just thoroughly commented or otherwise documented?
You don't really have to worry about keeping track of tons of functions, variables, structs, classes, etc., and trying to keep all the names straight in your head - all you need is to know the symbols, so it's in some ways easier than reading a complex function in more verbose languages where you might need to lookup stuff from several libraries just to understand what's going on. Also, that one line is ~100 characters, each of which probably covers ~0.5-1 lines in other languages, so you should expect to set aside a similar amount of time to reading and understanding it.
I suspect that if you're fluent in the language, understanding an expression written in it comes just as easily and quickly as reading a sentence in a book does to me.
That’s exactly what they say. Though most kdb I’ve see in business looks more like Python.
i've only seen these style of languages commented after a contest is over on stack programming challenges. I have no idea how one would learn all this stuff from code in the wild (like i learned most of python, for example). then again, i don't go searching github for k, apl, or perl for that matter.
I'm sure each of those languages makes some guarantee about the sorts of errors that can be introduced - as opposed to C (let me pick on it) where the errors you know you can introduce, and the errors that are introduced aren't a large union. However i have a hard enough time typing english consistently, so the various "symbol-y" languages just glaze my eyes, unfortunately.
It almost "feels" like these languages are an overreaction to the chestnut "they must get paid by LoC".
my impression is that the language is used more for scripts than for "code" in a true sense. A bit of "how much can you juggle in your mind" going on
I'm not sure why it would be any more impressive or surprising than the billions of people who read and write in non English alphabets
That's a really good point...
But -- (and forgive me if I'm totally wrong) -- this isn't just "non-english" but "non-phonetic" which is a smaller set of written languages, and the underlying language is ... math.... so understanding the underlying grammer itself relies on having decades of math education to really make it jive.
If this code is just a final result of "learn math for 2-3 decades, and spend years learning this specific programming language" -- my statement stands. Interacting with this kinda binary blob as a programming language is impressive. I think I read somewhere that seymour cray's wife knew he was working too hard when he started balancing the checkbook in hex...
The underlying language isn't really very mathematical, at most there's a bit of linear algebra in the primitives but that's it. You certainly don't need any sort of formal maths education to learn APL. There are about 50 or so new symbols, which is not a big ask, with any sort of focus the majority of the syntax etc can be learned very quickly. The "bugs" in your original code stand out very clearly because things like "∘}" don't make sense, ∘ being "dyadic" (infix).
and it bears mention that a decent chunk of those symbols are things nearly everyone is familiar with from other languages (+, -, =, etc), symbols you've probably seen in math class or on your graphing calculators (÷, ×, ≠, ⌈, ←, etc), and symbols with very strong mnemonic associations once you've seen them explained (≢, ⍋, ⍳, ⌽, etc).
I’ve often wondered about languages like APL/k, are the programmers actually able to think about problems more efficiently?
As a kdb+/Q programmer I would say it depends on the type of problem.
For example, when working with arrays of data it certainly is easier to think and write “avg a+b” to add two arrays together and then take the average.
In a non-array programming language you would probably first need to do some bounds checking, then a big for loop, a temporary variable to hold the sum and the count as you loop over the two arrays, etc.
Probably the difference between like 6ish lines of code in some language like C versus the 6 characters above in Q.
But every language has features that help you reason about certain types of problems better. Functional languages with algebraic data types and pattern matching (think OCaml or F#) are nicer than switch statements or big if-else-if statements. Languages with built-in syntactic sugar like async/await are better at dealing with concurrency, etc.
Which is why C# is the giant ever increasing bag of tricks that it is (unkind people might say bloat…) ;-) Personally, I’m all for this; let me express the problem in whatever way is most natural.
There are limits, of course, and it’s not without downsides. Still, if I have to code in something all day, I’d like that “something” be as expressive as possible.
Well no, not in a non-array programming language. In any language that has a semi-decent type/object system and some kind of functional programming support, `avg a+b` would just be `avg(a, b)`, which is not any easier or harder, with an array type defined somewhere. Once you make your basic array operations (Which they have to be made in q anyways, just in the stdlib), you can compose them just like you would in q, and get the same results. All of the bounds checking and for-loops is unnecessary, all you really need are a few HKTs that do fancy maps and reduces, which the most popular languages already have.
A very real example of this is Julia. Julia is not really an array-oriented programming language, it's a general language with a strong type system and decent functional programming facilities, with some syntactic sugar that makes it look like it's a bit array oriented. You could write any Q/k program in Julia with the same complexity and it would not be any more complex. For a decently complex program Julia will be faster, and in every case it will be easier to modify and read and not any harder to write.
Why would it be avg(a, b)?
What if I want to take the average difference of two arrays?
mean(a - b)
I don't know what you mean by the q array operations being defined in the standard library. Yes there are things defined in .q, but they're normally thin wrappers over k which has array operations built in.
For some classes of problems that are easily vectorized, using an array-focused language can certainly make thinking about them and their solutions more efficient, since you can abstract over the data structure and iteration details.
As a quant, I used kdb+/q quite a bit for 5+ years for mid-frequency strategies, but as I moved towards higher frequency trading that required calculations on the order book that couldn't be easily or efficiently vectorized, then continuing to use array-focused languages would have only complicated reasoning about those problems.
I went to this tech talk on Dyalog (a modern APL-like language), and the speaker makes the argument that the notation allows certain idioms to be recognized more easily:
https://youtu.be/PlM9BXfu7UY?si=ORtwI1qmfmzhJGZX&t=3598
This particular snippet was in the context of compilers, but the rest of the talk has more on Dyalog and APL as a system of mathematical notation. The underlying theme is that optimizing mathematical expressions may be easier than optimizing general code.
one nice thing about the array language style is that it's possible to talk about variations on algorithms where the relevant code snippets, being a few characters, fits inline into the discussion; more traditional vertically-oriented languages that take handfuls or dozens of lines to say the same things need to intersperse code display blocks with expository prose
Hillel Wayne writes about it on his newsletter every once in a while. He's convinced me that he does in fact think through some problems better in array languages but I still can't really conceive of what that experience is like.
there are several open-source K environments available, some which even run in the browser:
http://johnearnest.github.io/ok/index.html
if it's something you're interested in trying i'd be happy to point you toward more resources, and i'm sure there are plenty of other arraylang tinkerers reading this thread who could help, too
Most people are put off by the symbols, that wasn't really the issue I had.
So I do love APL and arraylangs, and learning them was really helpful in a lot of other languages.
But they never became a daily driver for me not because of the symbols, which were honestly fine if you stick with it long enough, but after about 3-4 years of dabbling on and off I hit a wall with APL I just couldn't get past.
Most other languages I know there is a "generic-ish" approach to solving most problems, even if you have to cludge your way through suboptimally until you find "the trick" for that particular problem and then you can write something really elegant and efficient.
APL it felt like there was no cludge option -- you either knew the trick or you didn't. There was no "graceful degredation" strategy I could identify.
Now, is this actually the case? I can't tell if this is a case of "yeah, thats how it is, but if you learn enough tricks you develop an emergent problem solving intuition", or if its like, "no its tricks all the way down", or if its more like, "wait you didn't read the thing on THE strategy??".
Orrr maybe I just don't have the neurons for it, not sure. Not ruling it out.
Every K program ought to end in QED, and then I remember that KQED is also a thing, and I wonder if their two worlds have ever overlapped.
(KQED is the Bay Area PBS partner. PBS is the US public television org.)
I put 2011 in the title above because https://web.archive.org/web/20110813135700/https://dfns.dyal... appears to have the main thing - is there a better year?
So I fed this to Claude. First of all it was able to identify that it's K programming language.
Then I asked it to explain it and here's what it provided, kinda impressive though not sure if it's correct:
----
Certainly, I'll do my best to break down this K code. Keep in mind that K is a very terse language, so each symbol can represent a complex operation. I'll explain it step by step:
```k x(,/{@[x;y;]'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9}')/&~x ```
Let's break it down:
1. `!9 9`: This creates a 9x9 matrix (likely representing a Sudoku grid).
2. `p:!9 9`: Assigns this 9x9 matrix to variable `p`.
3. `-3!p`: Divides the grid into 3x3 boxes.
4. `3/:-3!p`: Reshapes the result, likely to group the 3x3 boxes.
5. `,`: Flattens the result.
6. `p,:,3/:-3!p`: Appends the flattened 3x3 groupings to `p`, creating constraints for rows, columns, and 3x3 boxes.
7. `p[;y]=p`: Compares each value in `p` with the value at position `y`.
8. `|/p[;y]=p`: Finds the maximum (essentially, checks if the value exists in the constraints).
9. `x|/p[;y]=p`: Multiplies the result with `x` (likely a mask of available positions).
10. `(!10)^...`: Creates a list of numbers 1-9 that are not in the result of step 9.
11. `@[x;y;]'...`: Applies the result to position `y` in `x`.
12. `{...}'`: This is an each-right apply, performing the operation for each element.
13. `,/...`: Flattens the result.
14. `x(...)/&~x`: This is a fixed-point iteration. It repeatedly applies the function until the result doesn't change, starting with the positions where `x` is 0.
In essence, this code appears to be a very concise Sudoku solver. It iteratively fills in values that don't conflict with the rules of Sudoku (no repeats in rows, columns, or 3x3 boxes) until the puzzle is solved or no more moves can be made.
This is an advanced piece of K code, showcasing the language's ability to express complex algorithms very concisely.
--------------
Interestingly ChatGPT 4o-mini identifies it as J programming language. Here's what it gave me:
The code you've provided is written in J, a high-level, array-oriented programming language. J is known for its concise syntax, where operators and functions are often combined into compact expressions.
Here's a breakdown of the code:
This code is likely intended for some specific computation in J, and the compact nature of J's syntax can make it difficult to decipher at first glance.Gemini also identifies it as J and this is the output for comparison:
The programming language used in the code is *J* (pronounced "Jay"). It's a concise, array-oriented programming language known for its expressive syntax and powerful capabilities.
Here's a breakdown of the code:
*1. Verb Definition:* * `x(,/{@[x;y;]'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9}')/&~x` defines a verb (a function in J terminology) and assigns it to the variable `x`.
*2. Verb Structure:* * `x( ... )/&~x` is the basic structure of the verb. `x( ... )` applies the verb defined within the parentheses to its argument, which will be `x` itself. * `/&~x` is a hook, a control flow construct in J. It applies the verb defined within the parentheses to each element of `x` and then applies the verb `&~x` to the resulting array.
*3. Verb Body:* * `,/{@[x;y;]'(!10)^x|/p[;y]=p,:,3/:-3!p:!9 9}` is the body of the verb. Let's break it down further: * `{@[x;y;]` creates a gerund (a verb-like noun) that takes two arguments, `x` and `y`. * `'(!10)^x` generates an array of `x` elements, each raised to the power of `!10` (factorial of 10). `/p[;y]=p` is a conjunction that appends the value of `p` to itself for each element in `y`. * `,:,3/:-3!p:!9 9}` generates an array of 3 elements, each of which is the factorial of `-3` (which is undefined and results in an error) followed by the number 9.
*4. Overall Functionality:* * The verb takes an array `x` as input. * It applies the gerund to each element of `x`, creating an array of arrays. * It then applies the conjunction to each of these arrays, appending the value of `p` (which is likely defined elsewhere in the code) to itself. * Finally, it generates an array of 3 elements with errors and 9s. * The hook `/&~x` applies the verb to each element of `x` and then applies a function that is likely defined elsewhere in the code (since `&~x` is not defined within this verb).
*Note:* Without more context about the definitions of `p` and other variables or functions used in the code, it's difficult to provide a more precise explanation of the verb's exact behavior. However, the breakdown above should give you a general understanding of the code's structure and logic.
For completeness, I tested o1-preview and o1-mini. Both were able to identify the language, but only o1-preview realized it was a sudoku solver.
Please kindly delete your account, destroy your devices, and move to the woods far away from technology.
Sure. but please elaborate ..
I cannot comprehend the mindset of people who decide to spam (because that is what your comment is) any forum with a page of bullshit GPT slop. Do you think it's helpful or interesting?
Personally I believe it is interesting since it shows the current state of the art for the 3 LLMs.
I was surprised that Claude was able to identify the language and explain the code.
But, please feel free to downvote my comments. I guess the aggregate in the end will demonstrate whether it was a useful comment or spam + bullshit GPT slop.
It wasn't able to explain the code, it was wrong.
Perhaps you’ll be kind enough to post the explanation as a top level comment.
It’ll certainly help those of us who do not know K.
Please don't litter HN with LLM spam, it adds nothing of value to the discussion. You even said it yourself, you have no idea if any of the word vomit is true or not.
It's your comment that's adding nothing
It's very interesting that Claude can at least figure out it's a sudoku solver in K where chatgpt fails
There is a video about this.
https://www.youtube.com/watch?v=DmT80OseAGs
You can try the solution at https://tryapl.org/
Does anyone have any thoughts on what motivates people to play sudoku or write solvers for sudoku ? I have trouble finding motivation to solve artificial problems. That said I sink hundreds of hours into factorio.
For me personally, I have little motivation to do classical sudokus. They either have a not-so-elegant solve path (usually set by a computer) or are too difficult for me to solve.
Variant sudokus on the other hand are a lot of fun. They often have very elegant solve paths and there are many neat tricks you can discover and reason about.
Some fun ones, if you'd like to try:
- https://logic-masters.de/Raetselportal/Raetsel/zeigen.php?id...
- https://logic-masters.de/Raetselportal/Raetsel/zeigen.php?id...
- https://logic-masters.de/Raetselportal/Raetsel/zeigen.php?id...
I also mostly enjoy Sudoku variants, most of which I discovered via Geocaches, interestingly. After solving a few I then implemented a solver with customizable constraints, if anyone's interested, should still be available here:
https://www.sudoku-solver.ch/
Like many puzzles, there’s a regular release of endorphins as you progress, and a lot of satisfaction in completing something. I enjoy puzzles just like reading a book or playing a game, it’s another world I can step into for a bit of an escape, but I like to think it’s decent mental exercise. Overall I vastly prefer cryptic crosswords where solving each clue genuinely brings a smile to my face, but that’s more of a commitment of time (and for me sometimes a guarantee of frustration). I also like doing puzzles in the newspaper because me and my kids can sit together and all contribute. Coffee, breakfast, sat in the sun with a newspaper and a good pencil[1], absolute bliss if you ask me.
As for solvers, it’s a very elegant, well-formed problem with a lot of different potential solutions, many of which involve useful general techniques. I used to dabble clumsily in chess engines and honestly it’s the only time I’ve ever ended up reading Knuth directly for various bit twiddling hacks, so it’s always educational.
1: https://musgravepencil.com/products/600-news-wood-cased-roun...
idk man, you ask a good question. I think the idea has to do with the saddle you put on the invisible horse that is the game’s problem. Factorio has several complex saddles you must master to tame the beast. In factorio, you can get progressively better at using these saddles to tame even the most unwieldy scenario. Sudoku, at its heart, is not much different than factorio. However sudoku has one narrow problem with many different, increasingly nuanced ways of solving it. Factorio has many different “sudoku” style problems, but each problem needs to be handled differently, with each problem having increasing levels of sophistication. I think you might like factorio more because it’s just a bigger steak to chew on, and you’ve got the right appetite.
I don’t care much for sudoku but I do enjoy crosswords quite a lot, which feels like a somewhat arbitrary exercise. I enjoy the fact that I know a lot of words and it makes me feel clever. There’s probably something to that with most puzzle type challenges.
I teach C++ and I made my students code a Sudoku solver last year. It's a very convenient project to give them: self-contained, already familiar, no OS-specific weirdness, you get to use STL data structures, algorithms, very gentle I/Os...
All games are artificial problems, so your question actually is, what motivates people to engage in pastimes?
Sudoku, crosswords, Simon Tatham's puzzles etc. are an excellent way to pass the time while keep training the mind. Sports are their equivalent for the body.
Finally, writing solvers for a problem, be it real or artificial, for many is just another variety of puzzle to engage in.
I don't particularly enjoy sudoku but I like word puzzle games.
They're all artificial problems, but your brain likes a challenge and you get a dopamine hit when you solve it, I suppose.
I play sudoku almost exclusively on the plane. It's a good way to lose 5-15min.
I wasted too much time in my youth trying to min-max, and now I get bored as soon as I figure out, roughly, what the rules and mechanics look like for any game.
Normally I would concur, but I recently fell into a klondike solitaire binge and the only way out was to write a solver.
[flagged]
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
Solvers are useful for confirming that a puzzle you've recieved or generated is solvable. The meditative process can really go sideways when there is no solution for you to stumble upon.
Puzzles in commercial collections don't usually have that problem, but those from other sources sometimes do.
Solvers also make for a nice craft exercise, as here. Simple but not trivial, you can approach them in a lot of different ways and thereby work through different techniques or constraints you mean to explore.
I guess I'm the opposite. After doing a couple of sudoku many years ago my thought was "Hey, I could just automate this" and started thinking of algorithms.
Interesting position that was not expressed before. However please note that the same could be said about writing a solver.
Optimising a Sudoku solver can be seen as a different puzzle entirely and not as a mode of playing Sudoku.
Optimising solutions is the meditative exercise for me.
I enjoy running simulation after simulation after simulation, studying possible outcomes and optimising everything. Everyone is different :)
I find that sodoku is not a math or even a logic puzzle, but rather an epistemology puzzle. Lots of how we know/how much we know, and if you get into speed with some failure tolerance through estimating probability it adds even more thought provoking rabbit holes.
Meta: No need to DV a comment you don't like for no reason. Engage instead. Why not have a chat?
Wouldn't it be more productive/rewarding to instead engage with comments I do like?
Only you can say what's best for you.
If have to ask: What's rewarding about only having your viewpoint reinforced?
Where are you getting the viewpoints thing from?
Downvotes and upvotes work together to manage the visibility of posts that align with the community's tastes.
While I myself found an opportunity to reply to the GP and didn't down vote them, their comment only engaged with the article in a shallow way and only then, seemingly, to just dismiss the concept of solver altogether.
It wasn't a offensive comment, but it didn't really contribute to the site in the way many people digging into deep technical walkthroughs like this expect to see.
Some downvotes weren't guaranteed, but they're not surprising and they're probably helping new readers stay engaged with more topical and technical alternatives.
It's not the end of the world to get a few downvotes, and it's almost never personal. It certainly isn't here.
Aside: Downvotes on HN can be an expression of age related, self-righteous sniper pique; Opinions on what contributes to a conversation can be all over the place and are entirely subject to biases, which can be interesting (I guess). Doesn't really matter, and Hail Satan anyway. Also "Q for Mortals" is an interesting book.
People are saturated with anger and frustration after doom scrolling. They engage with their pitchforks.
A few anonymous downvotes are what qualifies as pitchforks these days?