Здравствуйте, VladD2, Вы писали:

E>>Стиль, значит. А со стороны выглядит так, что твои статьи просто никто не рецензирует, включая и себя самого.

VD>Еще раз. Все что тебе кажется со стороны или спереди высказывай мне в личной переписке.

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

VD>А то может мне кажется что-то не хорошее про тебя. Представляешь как неприятно будет если я это все в форуме вывалю?

Валяй.

E>>Почему читатель должен тебе верить? Если лямбда-исчисление Черча есть -- дай ссылку, но просить поверить тебе не нужно.

VD>Можно было бы конечно все о наукообразить добавив список литературы в конце, но смысла в этом не вижу.

То, в чем ты не видишь смысла, является экономией времени читателя.

VD>Ну, так получилось, что об однонаправленном тексте сказано и выше, и ниже. Неужели — это так существенно?

Да. Цени время читателя.

VD>Что до моего времени, то уж извини не тебе о нем судить.

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

E>>Это только то, что сразу бросилось в глаза и запомнилось.

VD>Это все очень похоже на слабо обоснованные наезды. Ты ведь что сказал в своем первом пассаже?
VD>

VD>По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

VD>Что же за наезды ты продемонстрировал? Большая часть цитат вообще не имеет отношения к твоему высказыванию.

Хорошо, пойдет дальше. Про императивных программистов.

ПРЕДУПРЕЖДЕНИЕ

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

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

Это сильно упростит восприятие функционального кода на начальном этапе. Данное мысленное преобразование требуется потому, что императивный программист за долгие годы привык думать низкоуровневыми понятиями (паттернами кодирования) циклов и простейших операций. ФП же предлагает думать бее крупными операциями, такими как отображение, фильтрация и свертка/агрегация.

Откуда информация о том, о чем привык думать императивный программист?
Кстати, здесь еще одна опечатка -- "бее" вместо "более".

К сожалению, многие императивные программисты не привыкли думать об агрегации как о преобразовании, но это плохой стереотип, который нужно ломать в своем сознании.

Из той же оперы.

Теперь по поводу изложения от первого лица.

Например, фразы вида:

Отсутствие аналога FoldRight, конечно же, факт неприятный, но особой проблемой это не является, так как, во-первых, FoldRight требуется довольно редко, а во-вторых, его нетрудно написать самостоятельно:

Она использует Reverse из LINQ. Метод Reverse написан довольно хитро, что делает его весьма эффективным. Но об этом вы узнаете, когда дочитаете до описания этого метода. В принципе, можно было бы реализовать специализированную версию данного метода для IList<T>, но у меня есть большие подозрения, что от этого будет мало толку.

На мой взгляд, это не очень полезный вариант метода Aggregate, так как того же самого эффекта можно добиться последовательным вызовом обычного Aggregate() и Select() (о Select см. ниже). Возможно, такой вариант потребовался для реализации «LINQ to SQL», а возможно, просто кто-то перестарался.

Понятное дело, что «так» императивные программисты не пишут. Не делают они это по двум причинам.

Во-первых, из соображений производительности (хотя в 99% случаев она вряд ли пострадает). Ведь создается промежуточная последовательность (в данном случае динамический массив типа List<string>()), а это не оптимально!

Во-вторых, из-за способа мышления. Об этом говорилось раньше, но сейчас стоит сказать об этом еще раз, так как на примере это видно куда лучше.

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

VD>За наезды видимо были приняты высказывания о том, что мало кто реально освоил ФП (что является стопроцентной правдой).

Откуда такая статистика?

VD>Ну, и как после этого воспринимать такую критику?

Это ты у себя спроси. Мне как-то фиолетово, как ты ее будешь воспринимать. Если ты хочешь видеть у своих статей только положительные стороны, то ни я, ни кто-нибудь другой, не сможет указать тебе на их недостатки.