JavaScript без циклов

Императивные алгоритмы лучше реализовывать императивно :)
Выполнение некоторой чистой функции несколько раз бессмысленно. Есть близкая абстракция к циклу for — развертка (unfold). Но опять же, это функция, и имеет возвращаемое значение.

JavaScript без циклов

Как-то так

Язык C# почти функционален

В Haskell проверка тоже будет в рантайме

Да нет же. Не знаю как в Rust, но если вы используете Maybe значит вы явно обрабатываете случай отсутствия значения.
Возможно вы имели ввиду вот такой вариант:

myFunction:: Maybe Int -> Int
myFunction (Just a) = a

Здесь мы явно отказываемся от кейса Nothing. Но при компиляции с -W компилятор нам об этом подскажет.
Вообще как мне кажется это очень плохая практика использовать Maybe в качестве входного параметра функции, она ведь является монадой и Haskell сам сможет построить в случае необходимости композицию из нескольких Maybe.
Т.е. в предыд. примере функция должна быть вроде этой:

myFunction::Int -> Int
myFunction a = a
-- ну или просто
myFunction = id

Язык C# почти функционален

Алгебраические типы данных — это альтернатива классам. Позволяют создавать новые типы путем композиции с использованием операции логического сложения (или) и умножения (и)

Примеры:

data Bool = True | False-- (логическое или). Работает примерно как enum
data User = Name Age -- (логическое и). Объединяет 2 типа Name и Age в 1. 

Аналоги в C#

enum Bool = True, False
class User {
    Name Name;
    Age Age;
}

Но вот чего нельзя сделать в C# — это комбинация этих операций:

data Maybe a = Nothing | Just a -- тип значение которого может отсутствовать.

В C# близко к этому null, но в отличие от ADT тут проверка будет не на этапе компиляции, а в рантайме.

Натягиваем ФП на ООП

Но CAS на весь корень это очень дорого (т.к. по сути успешно завершится модификация только из одного потока, а остальные будут впустую жечь электричество). Тут честный Lock на всё время операции экономнее.

В этом и суть CAS операций и не важно корень это или операции мутации по отдельности. В качестве бонуса мы получаем lock-free реализацию, которую получить на lock-ах по определению нельзя.

Как я писал приложение на Elm

Elm обладает развитой системой типов с автоматическим выводом, в ClojureScript такой возможности к сожалению нет (. Можете пояснить что вы подразумеваете под легким рефакторингом в Clojure? Он же вроде как динамически типизирован?
PS я не против Clojure, просто интересно )

Как я писал приложение на Elm

Честно говоря слабенькая статья получилось из разряда «Как я сходил в магазин». Ценность ее сомнительная, никаких технических деталей не увидел.
Про плюсы Elm в статье упоминалось, а вот минусы никак не были освещены.
Как по мне, самая большая проблема с Elm это даже не синтаксис, а интеграция с уже существующими библиотеками. Там как бы 2 пути: либо использовать порты (актуально для библиотек с сайд эффектами), либо переписывать на Elm (возможно есть еще какой-то путь). Было бы интересно если бы Вы как-то затронули эту темы.
А так, спасибо за популяризацию ФП :)

TDD все еще сравнивают с TLD — мнения экспертов

Теоремы тут не причем. Если прибегать к метафорам из математики, то тесты в TDD — это аксиомы, или инварианты (кому как удобно оперировать терминами).
Весь смысл TDD как раз таки и заключается в том, чтобы выделить набор утверждений для системы к-ым она должна удовлетворять, а затем уже писать саму систему.
Еще можно провести аналогию с use case. По-факту use case один в один ложится в тест и тест является с одной стороны формализацией требований к программе, а с другой возможностью подтвердить наличия этого свойства у системы (на самом деле только выявить случаи отсутствия этого свойства)

Наследование реализаций: закопайте стюардессу

Я не автор статьи и не эксперт, но это могло бы выглядеть примерно так

Наследование реализаций: закопайте стюардессу

Если кто не понял, то напишу это же проще. Не используйте «Шаблонный метод», а используйте «Стратегию». :)

Большой опрос по алгоритмам

Думаю для чистоты эксперимента можно было добавить пару фейковых алгоритмов )

Про волнения в головах

Как же не хватает в последнее время таких классных статей. Респект

Шорткаты в JavaScript

Приведение строки к числу

var foo = parseFloat('3133.7'),
    bar = parseInt('31337');

var foo = +'3133.7',
    bar = +'31337';

parseInt и + работают не одинаково. + более строгая операция, parseInt же позволяет парсить вот такие строки «123abc».
К слову сказать Вы не правильно используете parseInt. Правильно вызывать

parseInt(str, 10);

иначе без указания основания могут возникать неожиданности.
Попробуйте например parseInt('0x93')

Концепция «Родные Элементы»(Native Elements)

В двух предложениях тут не ответить. Лучше не поленитесь, изучите react.
Моя задача была показать как эта проблема решается, а не научить Реакту )
Вкратце метод render может содержать логику отображения и компоненты в идеале должны не иметь состояния.
Получать доступ к другим элементам из вне очень плохое архитектурное решение. Каждый компонент должен отвечать только за свои дочерние компоненты.
Histogram5 и StyledHistogram5 это два полноценных отдельных компонента. Касательно многословности, в последних версиях Реакта такого рода компоненты можно создавать используя лямбды

Концепция «Родные Элементы»(Native Elements)

var StyledHistogram5 = component({
      render() {
         return <Histogram5 columnWidth="100px" />;
      }
});

//App - корневой компонент. (Можно воспринимать как body в html)
var App = component({
    render() {
       return (<StyledHistogram5/><StyledHistogram5/><StyledHistogram5/><StyledHistogram5/><StyledHistogram5/>)
    }
});

Можете это воспринимать так:
component — создает «шаблон» внешний вид которого определяется функцией render.
для создания «элемента» мы просто объявляем компонент в виде html-элемента вот так:

 <myComponent>

.
Все аттрибуты могут быть доступны внутри render через this.props и предполагается что они используются в компоненте Histogram
По факту это просто повторное использование кода.
В ООП для этого часто прибегают к наследованию
В функциональном программировании — частичное применение

Концепция «Родные Элементы»(Native Elements)

что-то близкое к реакту

var Histogram5 = component({
      render() {
         return <Histogram columns="5" />;
      }
});

Концепция «Родные Элементы»(Native Elements)

Не нужно городить фреймворк для такой простой задачи.
Решение лежит на поверхности. В вашем примере нужно просто создать новый компонентв скажем ui-vboxhistogramm5Columns (не очень удачное название) который внутри использует ui-vboxhistogramm с нужными аттрибутами и использовать его :)
С технической стороны это примерно тоже что и выносить повторяющийся код в новый метод.

Конец эпохи динамических языков

Ну это спорно.
Вы эти изменения сможете инкапсулировать в созданных вами React компонентах нижнего уровня. Остальные же компоненты даже об этом не узнают.
А возьмем проект на чистом HTML. Изменения затронут весь код.

Lock-free алгоритмы и реализация стека

Читайте внимательнее
1) Очередь изначально поддерживает только 2 потока: 1 читатель и 1 писатель. Как сделать много писателей автор описал в п.4
2) Обеспечить наличие фейкового элемента в очереди думаю не очень сложно

Насчет технических деталей не знаю не реализовывал, но концепция выглядит довольно стройной.

Как обойтись почти без исключений, заменив их уведомлениями

Согласен, что для чистых validate бессмысленно его вызывать, если не использовать результат.
Но возможны validate и с побочными эффектами. Например когда нам нужно проверить не существует ли пользователя с таким логином и нам нужны запросы к БД.
Тогда как мне кажется ленивость может сыграть с нами злую шутку.