а) На хабре уже есть серия из кажется 6 статей Джоэля Спольски с описанием и команд, и воркфлоу и всего чего угодно.
б) Понятие «интуитивный интерфейс» очень относительно. Лично мне, как разработчику привыкшему общаться с компьютером путем отдачи команд на гибких формализованных языках, работать с консолью сильно проще, чем лезть за мышкой и нажимать на кнопки. А главное — продуктивнее. И выигрыш по времени ВНЕЗАПНО окупает изучение документации (не говоря о том, что это прокачивает мозги и помогает понять как на само деле работает продукт).
Это нормально, перестроиться после того как уже есть опыт императивного программирования очень сложно. Зато потом на стыке двух парадигм получается по-настоящему красивый код.
А вот люди которые никогда в жизни не программировали часто плохо понимают императивных подход, зато легко врубаются в функциональный. Он на самом деле более естественный. Только надо понять, что вы строите не цепочку шагов, а набор взаимосвязанных утверждений, описывающих задачу.
Поинтересуйтесь тем, что такое «шитый код» и почему он иногда может быть быстрее обычного. Это если не учитывать разворачивание функциональных конструкций в императивные.
Ну если начать обсуждать оптимизацию компилятором, то функциональные циклы часто используют хвостовую рекурсию, тоже разворачиваются на ура и тоже могут оказаться быстрее for.
Ну, и да — КЛАДР был стандартом не только для госучреждений, но и вообще самой стандартной БД адресов в стране и активно используется и в множестве enterprise-софта.
С учетом того, что цикл идиоматический, то да. А если не идиоматический, то, имхо, вероятность ошибиться с инициализатором или условием останова цикла больше.
А насчет stateless — его преимущества гораздо лучше видны не на таких коротеньких примерах, а на сложных преобразованиях последовательностей сложных структур данных.
б) Понятие «интуитивный интерфейс» очень относительно. Лично мне, как разработчику привыкшему общаться с компьютером путем отдачи команд на гибких формализованных языках, работать с консолью сильно проще, чем лезть за мышкой и нажимать на кнопки. А главное — продуктивнее. И выигрыш по времени ВНЕЗАПНО окупает изучение документации (не говоря о том, что это прокачивает мозги и помогает понять как на само деле работает продукт).
А вот люди которые никогда в жизни не программировали часто плохо понимают императивных подход, зато легко врубаются в функциональный. Он на самом деле более естественный. Только надо понять, что вы строите не цепочку шагов, а набор взаимосвязанных утверждений, описывающих задачу.
Но в базовой идеологии, да, много очень общего.
Вообще в моем примере как раз показано, что можно написать такой for который будет быстрее неленивой функциональной реализации и аналогичной ленивой.
И если бы в ruby был настоящий сишный for со счетчиком (а не итераторный foreach), то вариант с двумя счетчиками работал бы быстрее.
Что-нибудь типа:
for (var i = 0, j = 0; i < 100000000000 && j < 50; i++)
{
if (prime(i))
{
res[j] = i;
j++;
}
}
(псевдосишарп)
А насчет stateless — его преимущества гораздо лучше видны не на таких коротеньких примерах, а на сложных преобразованиях последовательностей сложных структур данных.
И есть даже такое (по сути ESB для интеграции ведомств в масштабе всей страны).