Javarevisited

Knuth's Dancing Links is originally from 2001, and was first published to book form in Fasicle 6 (2019).

Dancing Links seems to have outstanding performance for a generic cover problem, even on modern cache heavy processors.

It seems like the static layout of the links benefits greatly from cache locality. Seriously, study the algorithm before hating on it.

EDIT: Knuth's original writing style may be "too mathematical" for some. Here's a dumbed down version: https://medium.com/javarevisited/building-a-sudoku-solver-in-java-with-dancing-links-180274b0b6c1

The original Knuth: https://arxiv.org/abs/cs/0011047

The 2001 code is suboptimal in a few ways compared to the more recent updates. Knuth discusses the updates in Fasicle 6, the cweb source code is: https://www-cs-faculty.stanford.edu/~knuth/programs/dlx1.w

-------------------

EDIT: But... I hate it when people tell me to read other papers without pointing out the issue. :-)

The specific issue is that in Dancing Links: 1 -> 2 -> 3 becomes 1->3, and then later becomes 1 -> 2 -> 3 again. This pattern of insert (and then un-insert at the same place) means that all linked-list operations will execute in L1 cache.

Furthermore, Knuth lays out the data such that 1, 2, and 3 are sequential in memory. So the entire process is incredibly cache-efficient and takes advantage of both temporal and spatial locality. (Because 1 usually inserts / removes 2, and because 1 and 2 are always next to each other in memory, you're never…

> You need to inherit to create anything that is a class

That's true of the Java compiler, for which the documentation is strewn around the intenet...but an example is here: https://medium.com/javarevisited/compiler-generated-classes-methods-and-fields-in-java-343dde2cce61

The Java syntax doe not require extending Object explicitly.eg This is a valid, useless, class:

public class App
{}

> I don’t like modern Java because there’s too much non-Java magic code

It seems like this is the common path for popular languages. They develop their own library-backed DSL's for the most common use cases, which are often little more than macros (@data @getter, @notnull, etc). I am biased by what I've seen in the last 30 years though.

Publications and spread. I have a larger following on Medium than I have in dev.to or hashnode. So I post there and usually provide a canonical link to the actual article in a more "decent" location.

The value is the publication such as https://medium.com/javarevisited/ which I usually use or https://medium.com/better-programming which is a bit more painful (for the submitter). But the benefit is that both have orders of magnitude more followers than I do. When an article goes up in a publication I get huge viewer numbers.

Monetization isn't available in my country so I never enabled it as an option. I'm not sure if I would turn it on to begin with as all my new content on medium isn't exclusive to the platform.

This guy literally wrote the same AI generated rage bait article format for every programming language he could think of yesterday.

https://medium.com/codeelevation/python-is-dying-and-nobody-wants-to-admit-it-4260f774117a

https://javascript.plainenglish.io/react-is-dying-and-nobody-wants-to-admit-it-8210c459abe0

https://javascript.plainenglish.io/php-dead-and-nobody-wants-to-admit-it-6337964534e3

https://medium.com/javarevisited/java-is-dying-and-nobody-wants-to-admit-it-461395cdb92f

https://javascript.plainenglish.io/javascript-is-dying-and-nobody-wants-to-admit-it-f3d8388d5f82