Василий Банников

Когда юзер находится в вашем веб приложении, он создает определенные действия. Действия связаны с состоянием. А redux это набор утилит для глобального хранения состояния(state) в приложении.
Таким образом, вы создаете какие-то объекты и они меняются в зависимости от состояния. Пользователь это видит как некие различные реакции на его действия.

поделитесь источником, как быстро настроить для VS Code

ОК, гугл: eslint vscode
Не благодари )) Ну реально нет смысла копипастить.
А вот то, что при компиляции нет ошибок, это плохо и надо настроить сборщик.

лишь ошибки типизации которые не мешают компиляции

Если проект компилируется - то все типы сошлись. Если проект компилируется, а ошибка все таки есть - значит типы криво описаны.

Как проверять все файлы проекта на правильность типизации?

Скомпилировать проект.

Но, если допустим, изменить какой-нибудь тип (интерфейс), а файл, который на него ссылается и использует будет закрыт, то ошибку никакую не выдаст.

И это хорошо. Если TypeScript LSP будет перепроверять весь проект на каждый чих, а не только открытые файлы, то писать что-то сложнее todo листа будет невозможно...

Знаю, существуют ESLint, TSLint.

Они тоже для статического анализа, но для немного другого. В VSCode они так же чекают только открытые файлы, из тех же соображений производительности.
TSLint устарел. ESLint ставьте отсюда: https://marketplace.visualstudio.com/items?itemNam...

или просто совпадение, или рассчет на то что люди будут ошибаться и писать ему.

поддержка молчит ибо сказать ей нечего, кроме как вежливо послать.

В тот момент когда он сам изъявил данное желание

Стейт менеджер нужен для консистентного управления состоянием приложения, внезапно.
Если вы не пользуетесь менеджером состояния в реакт-приложении, то либо используете контекст (вот хорошее объяснение, почему на проде так делать не нужно), либо пишете заведомо неподдерживаемое приложение. Ну или ваше приложение — это игра в крестики-нолики с двумя полями в стейте корневого компонента.

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

Всегда, когда это возможно, нужно использовать неизменяемые коллекции, и неизменяемые переменные/проперти(val, а не var). Это нужно для того, чтобы сделать интерфейсы и код чище. Хорошо видно, где могут изменяться те или иные данные, а где - не могут, именно для этого иерархия коллекций в котлине разделена на две части. В джаве этого нет, и приходилось делать проверки в рантайме(см Collections.unmodifiableList, например).

Что значит "гуляет"? Где они находятся постоянно?
Правильная постановка много значит, между набором не должно быть поиска клавиши.
Насколько я понимаю такое возможно только если пальцы находятся на базовой позиции постоянно.
У меня по крайней мере так.
Попал указательными на метки, и они постоянно слегка касаются фываоолдж.
Для повышения скорости - упражнения на ритм и постоянная практика.
Для повышения точности - упражнения на ритм на малой скорости.
По поводу скорости - как показывает практика 200-250 это вполне нормальная скорость и в большинстве задач быстрее не надо.
Если вы конечно стенографистом не собрались работать - им да, чем больше тем лучше.
Лично для меня в слепой печати важна не скорость, а тот факт, что печать не отвлекает, и идет в фоновом режиме. Обычная скорость порядка 250. Если набиваю что-то большое, разгоняюсь до 300, быстрее уже ошибки массово.

You-Dont-Need-jQuery

Нельзя просто так взять и перенести вычисления на GPU - для этого (на 2021 год) программа должна разрабатываться отдельно, с учетом возможностей и структуры этого самого GPU.

Главный плюс GPU - высокая степень параллельности на независимых данных. GPU может одновременно делать тысячи математических операций, при условии, что результат каждой из них не зависит от результата других - что часто встречается при обработке изображений - отсюда высокая скорость вычислений.

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

Отсюда следует, что выиграть, считая на GPU, можно только тогда, когда данные независимы, хорошо умещаются в память видеокарты и успевают перекачиваться.

Надо не b[i] на null проверять, его там никогда не будет, а проверять длину массива b.
Ну и по-хорошему int.Parse для каждого числа использовать только один раз, а не на каждую проверку.

После сплита создаёте лист потом делаете цикл от 0 до длины полученного массива, внутри цикла проверяете значение на валидность если валидно то в лист добавляете его если нет то 0 после цикла вызываете метод ToArray() на листе.