Как я пытался придумать новый подход к изучению алгоритмов через интерактивные визуализации

А прикольно было бы всего Кнута так разрисовать.

Если серьезно, то добавить бы контекста про представленные алгоритмы. Скажем, в вашей реализации коллизии разрешаются переносом в соседнюю незанятую ячейку, но об этом можно только догадаться по самому коду. Ведь это не единственный способ. Нашел неприметную кнопку "Теория".

Тоже пытаюсь придумать как визуализировать алгоритмы, но лучше анимации пока не видел и не придумал. Код вообще выглядит здесь неуместным. Поняв алгоритм можно написать его в коде любого нужного языка — у вас выбор языка планируется?

На мой взгляд, потеть должна машина, а человек учиться, не выворачивая мозги наизнанку.

Мне всегда казалось, что любое обучение это всегда тяжело. Как говорил препод по матану в университете: "Вы думаете мне дается легко то что я вам преподаю? Я на это потратил 30 лет жизни и не все они были прекрасны, но мне нравится это делать, нравится преодолевать собственное непонимание."

Они пытаются заставить нас думать как компьютер, а не наоборот — подчинить железо нашим потребностям. Чтобы понять, как работает код алгоритма, нужно представлять, как машина будет его выполнять. Я решил, что хочу уйти от этого подхода.

Любопытно, что функциональное программирование в целом пытается сделать то же самое, но другим путем: отказаться от конкретной реализации и идти по пути абстрактного математического языка (лямбда счисление, теория категорий, комбинаторика и т.д.).

Отладчик с возможностью шага назад это интересно.
Связь команд компьютера и естественного языка — полезно.
Вот только исходный посыл в статье абсолютно неверный

Чтобы понять как они работают, приходится изучать их код и представлять, как компьютер будет его выполнять. Это странно — почему мы должны учиться думать как компьютер, вместо того, чтобы заставить его помогать нам учиться?

Чтобы научиться программировать, человеку неизбежно придется понять логику его работы.
Мне пришлось сделать отдельные упражнения для того, чтобы ученик тренировался представлять выполнение программы. Без этого ученики стопорятся где-то в районе изучения циклов и не растут дальше.

Ну и я в целом не одобряю подход с "анимацией для объяснения". После их просмотра люди думают "ну вроде понятно". А если попросишь написать, то утонет в тысяче нюансов реализации. В коде важно не только то, что написано, но и то, что не написано.

Есть такой ресурс по визуализации алгоритмов https://visualgo.net/ru

Чем то напомнило проект который я писал, что-бы визуализировать решение Ханойской башни
https://github.com/anatoly314/HanoiTower

Если добавить div с определённой начальной позицией, и потом сразу же поменять координаты на конечные, то браузер склеит эти два изменения в одно. Div сразу окажется в конечной позиции без анимации. Чтобы такое не происходило, приходится вставлять задержку в два фрейма анимации с помощью window.requestAnimationFrame().

element.style.height = '0';
element.offsetHeight; // reflow
element.style.height = '100px';

Это позволяет избежать совсем сложного императивного кода с запутанным состоянием и ручными вычислениями. Получается тоже не просто, и в итоге анимациями заведует огромный класс на 1000 строк.

В ИТМО когда-то писали много визуализаторов для разных алгоритмов. Сейчас это всё осталось только в Wayback Machine, так что запустить их теперь вряд ли получится.

if swapped:                            
    break

if not swapped:
    break