Какой язык программирования стоит выучить первым? (ʇdıɹɔsɐʌɐɾ: ɯǝʚɯо ņıqнqvиʚɐdu)

Определенные диалекты Lisp получше JavaScript будут. Совершенно несправедливо записали вы его в один ряд с Brainfuck.

Готовим многопоточность с core.async

Только документацией к core.async, по факту различий нет, go-loop и while являются просто макросами к loop.

Делаем проект на Node.js с использованием Mongoose, Express, Cluster. Часть 1

Генераторы были сделаны для того, чтобы упростить написание итераторов.

Звучит как масло масляное, что дальше то делать с этими итераторами? Разработчики ES6 этим функционалом предоставили просто аппендикс для работы с ленивыми структурами данных, но в сам язык никакой удобной их поддержки не предоставили. Для декларативного описания обработки коллекций по прежнему проще использовать сторонние либы по типу "Stream.js". Сообщество просто покрутило эту штуку и пристроило куда могло, то что генераторы решают проблему callback hell красивее чем целый ряд изобретенных до этого костылей, сомнительно. В любом случае в Node.js 7.0.0 подвезли async/await и использованию генераторов для написания синхронного кода, нет никакого оправдания.

Делаем проект на Node.js с использованием Mongoose, Express, Cluster. Часть 1

Писать код в синхронном стиле хорошо с использованием async/await.
Генераторы я вообще не понимаю для кого и зачем сделаны. Их дизайн сделан настолько плохо,
что вернувшись к функции которую написал 15 минут назад, уже не понимаешь что она делает.
Это похоже на такой задел под ленивые вычисления, который не довели до конца.

Делаем проект на Node.js с использованием Mongoose, Express, Cluster. Часть 1

А можно просто:

$ npm install express-generator -g
$ express --view=jade myapp

Какое место занимает язык Scala в ИТ-индустрии

Раз уж пошли код сравнивать как можно без lisp в лице Clojure:

(defn task-3 []
  (let [v1 (future (task-1))
        v2 (future (task-2))]
    (future (+ @v1 @v2))))

Время — деньги, или аргументы за и против почасовой оплаты

Устанавливайте штрафные санкции на превышение количества ошибок.

Тема не раскрыта. Кто и как будет определять за какие ошибки будут санкции? Зачем работнику идти к работодателю который может вдруг насчитать штрафов на половину зп за скажем поехавшую верстку в IE6, по штрафу за каждый уехавший блок. А что если в компании есть отдел тестирования?

Небесный путь в PHP

Все ваши вопросы, можно смело адресовать и к ООП. Их решения напрямую зависит от квалификации разработчика закладывающих архитектуру на старте проекта, ФП или ООП тут имеют мало значения как таковые. Особенно с учетом того что почти все языки гибридные, могу ошибаться но только Haskell можно назвать чистым ФП языком, остальные функциональные языки могут работать с мутабельными состояниями, что позволяет там где нужно писать императивно, а уже большую часть функционально. Помимо того, ошибки проектирования с использованием ФП нормальная практика для только набирающей популярность методологии, паттерны проектирования ООП тоже не за один год придумались. Для ФП есть и еще будут свои паттерны.
Отвечая на тезис «ООП — лучшее, что придумало человечество», лично для меня определенно нет, по простой причине. ООП для меня это рутинный кактус который нужно есть, а ФП это тот код, при написании которого я могу отдохнуть.

Небесный путь в PHP

Я специально в своем комментарии в защиту ФП упомянул JS, это очень распространенный опыт, обжечься на нем и ругать ФП. Сам писал бэкенд на Node.js с лямбдами и думал что пишу ФП, это был очень неудачный опыт. Но этот опыт говорит только о том что в JS очень неудачная реализация для ФП и не более. Примеры больших ФП проектов вам привели, это намекает что парадигма жизнеспособна. Почему в целом и в Российском IT сегменте такие большие проекты сложно найти? Думаю ответ очевиден, для большого проекта нужно собрать в одну команду несколько специалистов со знанием ФП языка, что ввиду невысокой распространенности проблематично, так же немаловажный аспект — бизнес не будет вкладывать деньги в непроверенную годами технологию. Повод ли это хоронить ФП? Не думаю.

Небесный путь в PHP

В вашем комментарии сквозит намек на то что ФП менее удобен для больших проектов и масштабируемых систем. Непонятно откуда взялся этот стереотип, возможно из за JS к которому пока неуклюже пытаются придать функциональную парадигму некоторые фреймворки. Сами идеи ФП такие как неизменяемость состояний и чистые функции как раз и располагают к написанию более поддерживаемых больших и сложных систем. Как эти идеи представлены в конкретных языках, вопрос другой. Что касается вашего вопроса про массовый продукт реализованный исключительно с использованием ФП то как вам пример Riemann?

Небесный путь в PHP

Посмотрел ваш сайт, видео, исходники проекта. Количество вложенных сил и то что вы ведете проект минимум с 2013 года, бесспорно вызывает уважение. Однако меня не покидало чувство что вы с 2010 года живете в изолированном бункере где нашли книжку о PHP. На подобный проект в 2016 году кроме как с удивлением и непониманием смотреть не удается. Если вам не нравится "путь PHP" почему бы не посмотреть на другие языки? Если отойти от мейнстрима то выбор огромен, в том числе и с принципом проектирования приближенном к KISS.

Node.js 7.0.0 зарелизился. Встречайте async/await без babel

let user,spammers = [];
(function loop() {
    getUser().then((user) => {
        isSpammer(user).then((user) => {
            spammers.push(user);
            if (spammers.length <= 10 && user !== null)
                loop(); 
        });       
    });
}())

А зачем оно вам? async/await безусловно куда более лучшие инструменты чем promise.

Node.js 7.0.0 зарелизился. Встречайте async/await без babel

Это делается через рекурсию.

От Jquery UI до Ext.js: обзор javascript UI библиотек для SPA. Часть 1

есть же — https://github.com/angular-ui/bootstrap

От Jquery UI до Ext.js: обзор javascript UI библиотек для SPA. Часть 1

В защиту Jquery UI могу сказать что как то вдохнул вторую жизнь в древний проект на нём, с помощью backbonejs + Underscore.js. Получилось довольно неплохо.

Все рушится

Да, действительно nvm exec 6.8.1 npm install & nvm exec appname решают проблему. Это действительно круто, 2 года назад когда я столкнулся с проблемой подобное решение если и было то не гуглилось. Спасибо за наводку. А давайте представим что Yarn красиво интегрировал в себя nvm, и умеет читать из package.json аттрибут "nodejs-version":"6.8.1". И теперь когда мы делаем yarn install, yarn сам скачает нам нужную версию ноды и npm, а yarn run будет у нас алиасом для nvm exec 6.8.1 appname, для зависимых пакетов их локальный атрибут "nodejs-version" будет игнорироваться. И в итоге мы получаем 1. Более user friendly управление версией ноды для проекта 2. можно глобально обновлять ноду и не боятся что остальные сервисы перестанут работать. Вполне достойная как по мне фича, что бы сделать еще один менеджер пакетов (сарказм)

Все рушится

Мой опыт рефакторинга старого приложения под более свежую версию Nodejs был настолько неудачным, что у меня осталась психологическая травма. Возможно помните что ранняя версия express изначально хранила в себе большую часть модулей, а потом авторы решили вынести их по разным пакетам, и это была проблема только одного из множества пакетов изменивших API. Я отлично понимаю почему зафиксировать версию ноды для приложения проблематично при текущей архитектуре, но уверен что решение в рамках пакетного менеджера придумать возможно, пусть хоть он докер контейнеры разворачивает под капотом, хорошая практика оставить на усмотрение разработчика выбор — лишний оверхед или решать конфликты ручками.

Все рушится

А представьте себе такую жизненную ситуацию, у вас есть сервер на котором работает жирный такой сервис на Nodejs, и ему года 3, и все эти годы никто в него не заглядывает а его разработчик давно уволился, и тут вам нужно задеплоить туда еще один сервис, естественно написанный на куда более свежей ноде, и вот проблема этот древний сервис не запускается на новой версии Nodejs. И решений сейчас тут только два и оба та еще "радость", это ковырять старый сервис решая проблемы совместимости или ковырять что-либо из контейнеризации типа Docker.

Все рушится

Я как пользователь пакетного менеджера не должен себе ничего представлять. У меня тут рядом есть пакетный менеджер из другой оперы — leiningen, там можно указать версию интерпретатора, и могу сказать что это очень удобно. Почему бы мне не хотеть того же от npm или Yarn?

Все рушится

Нет у Yarn действительно важных фич, то чего действительно не хватает так это указания версии nodejs в package.json и соответственно работы приложения именно с этой версией вне зависимости от того что стоит непосредственно в окружении.