Pull to refresh

Comments 45

Соглашусь, первый вариант функции _do просто взрывает мозг
Да тут всё разносит мозг, к стати моманды это опечатка или есть такое слово?
В принципе «сломать» мозг это отчасти цель этой статьи, для повышения гибкости, так сказать.
А какой код кроме _do функции например сложный?
к примеру этот код
function take(int $n): Parser {
    return parser(function($s) use ($n) {
        return strlen($s) < $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ];
    });
}


тяжело воспринимается 2-ва return и тернарный оператор не к месту к стати…
Ничего сложно, довольно симпатичный код.
Выглядит довольно таки красиво.
Кому как многие привыкают читать код линейно с верху в низ без надобности возврата, к предыдущем участкам и чтением строки что бы понять что именно возвращается.
К примеру
      if(strlen($s) < $n) {
           return Parser::FAILED;
      } else {
           return array(
                  substr($s,0,$n),
                  substr($s,$n)
           );
      }


Согласитесь выглядит более читабельней чем

    return strlen($s) < $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ];


Ну и чем плох тернарный оператор, к примеру, всё просто, у вас новая вводная вам надо и при strlen($s) == $n вернуть Parser::FAILED
многие привыкшие к тенарным операторам сделают это так

    return strlen($s) < $n ? Parser::FAILED : strlen($s) == $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ] ;


Что приводит к тому что человек не сразу поймёт что возвращается, становиться не очевидным просто.
>Согласитесь выглядит более читабельней чем

Да вроде одинаково…

>многие привыкшие к тенарным операторам сделают это так

Уверен, что многие сделают примерно так: return strlen($s) <= $n? Parser::FAILED: [ substr($s, 0, $n), substr($s, $n) ];
UFO just landed and posted this here
пишу на скала, код в статье — сложна))), а говорят скала сложна.
автор, отличная статья, ждем продолжения?

Было бы неплохо увидеть финальный код.
И сравнить с парсером, написанным с использованием како-то другого подхода.


Лично мне код не показался очень простым и понятным. Но возможно, простота познается в сравнении, и на деле другие реализации были бы гораздо сложнее?


Кстати, по-моему, написанный парсер строковых литералов не обработает строку с двойной кавычкой внутри ("I \"am\" inside") :)

Финальный код приведен в конце, правда ссылку на репозиторий я похоже забыл, вот он.
Вот пример на js, правда на js и мой код выглядел бы на порядок проще, разница в тестируемости отдельных частей и декларативности.
В парсинге строк я действительно немного схалтурил :)

Всё, конечно круто, если не брать во внимание то, что вам уже и так сказали о читабельности и то, что 90% PHP-программистов пост-советского пространства и с ООП совладать не в силе… На стандартный вопрос отличий private и protected или абстрактного класса от интерфейса на собеседовании далеко не каждый отвечает, неговоря уже о таком рядом плывущем ките, как SOLID. В подавляющем большинстве случаев, кандидат даже не предпринимает попытки понять базовые паттерны проектирования и даже пресловутые синглтоны и абстрактные фабрики зазубриваются. А вы тут решили ФП вбросить, опасную игру затеяли. Но еще раз повторюсь, другим 10% полезно иногда смотреть на другие парадигмы, как минимум для общего развития. Лично я проникся ФП на фронтенде, но на бекенд пока руки не доходят, да и бизнес мне за такие шутки по рукам надает :D
Вы так говорите, как будто функциональщина лучше и сложнее ООП подхода. Посмотрите на пример, ад из колбеков замаскированный через бинд, сложный в поддержке и трудночитаемый. У функциональщины свои плюшки, но ради них жертвуют человекопонятным кодом.

Ну, а по поводу знаний ООП, мусора везде хватает, на то есть эйчары и собеседования, чтобы его фильтровать, в нормальные компании такие не попадают.
Нет, я говорю ни в коем случае не о сложности. ООП мейнстримней, материалы по нему намного доступней читателям, незнакомым с английским языком(хотя по моему убеждению ЛЮБОЙ разработчик должен владеть английским хотя бы на уровне чтения документации, но практика поиска сотрудника в мультиязыковую команду показала, что это далеко не так).
А что вы хотите от страны где 80% не имеют загранпаспорта и дальше крыма не выезжали, а дома пилят проекты на битриксе. Но это вымирающее меньшинство. В Беларуси или Украине таких проблем нет, практически везде чтение документации на английском и ооп — обязательные условия, т.к. проекты западные.

Я так понимаю, вы искали среди так называемых фрилансеров, но это отдельная группа, где за редким исключение ни то что программиста, но даже человека адекватного найти тяжело. У нас же сейчас обратная ситуация, слишком много начитанных специалистов, которые любят паттерны, ddd и всякие абстракции больше, чем результат.
Я искал любых людей, готовых к релокации в Бангкок на довольно хороших условиях, с оплатой перелетов\проживания и довольно конкурентной з\п, тем более для Бангкока. Кстати, про фрилансеров не совсем согласен. В русском фрилансе еще может быть(честно — не знаю), но на том же upWork, программисты с рейтами выше 15-20$\час как правило адекватные, конечно, с исключениями. Я сам фрилансер по большому счету, только еще иногда езжу к клиенту «на место» при необходимости, так что фрилансеров буду с пеной у рта отстаивать :D

Но это вымирающее меньшинство

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

У нас же сейчас обратная ситуация, слишком много начитанных специалистов, которые любят паттерны, ddd и всякие абстракции больше, чем результат

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

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

В ООП тоже всё легко тестировать если пользуешься DI и пользуешься фаулеровскими заветами вроде разделяй запрос и модификатор.
Вы в статье очень удачно использовали объекты, тем самым продемонстрировав, что ООП не отменяет функциональных подходов, а очень удачно дополняется ими.

На самом деле в этом примере ООП не используется, а класс используется только ради инфиксной нотации ($this->orElse($that) вместо orElse($this, $that)).
А у ООП достаточно недостатков, начиная от хрупкости базового класса. Это видно даже в количестве паттернов, большей части из которых в функциональной парадигме просто нет, за ненадобностью.

90% PHP-программистов пост-советского пространства и с ООП совладать не в силе…

В 90% ваш ООП не нужен.
Взяли за идею, мол ООП корова, которая спасет мир. Но это не так.
+100500.

Нужно задачу решать самым простым способом, а не городить огород.
Самым простым способ и думать о будущем, да и задачи бывают разные 'Hello world' и 'интернет магазин' это разные по объёму и методики решения задачи.
Самым простым, необходимым для решения задачи… :)
Может вы не будете за меня решать, что я решил, а что нет? А еще не будете решать за сообщество, которое почему-то внезапно в большинстве своем использует ООП — наверное не просто так, м? Ваши высказывания говорят о том, что и в ФП я знаю побольше вашего. Для всего есть свои области применения. ООП очень удобно там, где нужно общаться на одном языке с бизнесом, например. Для этого у нас есть DDD. А что для этого есть в ФП?

Не сказал бы, что DDD может быть использовано исключительно с ООП, наоборот, мне кажется описание действий, которые можно производить с данными более гибко, чем попытка определить какому объекту действие принадлежит.

У вас ошибка уже в том, что вы пытаетесь производить действия исключительно с данными. Мой менеджер ничего не знает и не должен знать о данных, с которыми я провожу эти действия. Ему гораздо понятней объекты реального мира: нефтяная труба, ящик помидоров или клиент банка, нежели (радиус, материал, длина конструкции, проводимость), (длина, ширина, вместимость), (номер паспорта, баланс,… x100 других параметров). Это если не брать во внимание, что в бизнесе не бывает чистых функций и выдача кредита физ. лицу принципиально отличается от выдачи кредита юр.лицу.
Обычно менеджеры оперируют не только объектами, но и процессами, а с этим у ООП значительно хуже, чем у ФП. А вообще ООП и ФП отлично дополняют друг друга именно в сфере моделирования бизнеса процессов. Да и многие ООП паттерны являются по сути переводом на ООП-нотацию сущностей, которые в ФП есть, как говорится, из коробки.

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

Это всё справдливо только если только мы говорим не о чистых ФП. А говоря ФП, во всяком случае я подразумеваю ЧИСТОЕ ФП. И самый высокий уровень абстракции, который мы там можем себе позволить — Функции высших порядков, что все еще очень далеко от ООП по уровню абстракции. Если не прав, буду рад увидеть пример. Я даже нагуглить не смог.

Возьмем для примера чистый функциональный язык Haskell, в нем делается так:


module Fruits (Tomato, grow, eat) where

data Tomato = Tomato String Int

grow weight = Tomato "Good one" weight
eat (Tomato name _) = name ++ " was good"

Извне модуля видно только имя типа Tomato и функции, внутренняя структура абстрагирована.
Полиморфизм тут тоже есть, если интересно, называется Type Classes.

А еще не будете решать за сообщество, которое почему-то внезапно в большинстве своем использует ООП — наверное не просто так, м?

Мне сложно общаться с людьми, которые меняют свое мнение на лету.
Ты уж определись, либо 90% не могут совладать с ООП, либо сообщество только ООП использует. А то, я тебя не понимаю.
И не надо ванговать, что и кто лучше знает, я тут своими знаниями не делился.
Ты уж определись, либо 90% не могут совладать с ООП, либо сообщество только ООП использует

Если у тебя не достаточно логических способностей понять, что сообщество программистов не ограничивается только российскими программистами и то, что люди часто используют то, чего не понимают(ООП — как пример) это твои проблемы. Это если не учитывать, что я ни разу не сказал, что сообщество использует ТОЛЬКО ООП. Что-то я не вижу от тебя ни одной публикации по ФП, так что собирай свой жир и иди троллить куда-нибудь в другое место.
Отвечу всё таки.
Ты делаешь утверждение, что 90% Похапэшников в СНГ, не могут совладать с ООП.

1. Какое сообщество программистов? Ты четко указал, что мы говорим о СНГ. И что в СНГ 90% похапэшников, не могут в ООП.
2. Выходя из пункта 1, ты не следишь, за тем что пишешь.
3. Довод, что я не пишу тут статьи, просто смешон.

Прошу не пиши мне больше, я общаюсь с адекватными людьми.
Спасибо.
Какое сообщество программистов? Ты четко указал, что мы говорим о СНГ. И что в СНГ 90% похапэшников, не могут в ООП.

А, то есть ты решил взять 2 разных комментария, написанных в 2х разных контекстах, 2м разным людям, вырвать их из контекста и обвинить меня в том, что я мол за своими словами не слежу. Позволю себе такой же «опус».
я общаюсь с адекватными людьми

Но это не так

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

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


$pair = _do(function() use (&$jValue,&$result) {
        $key = yield takeOf('\\w');
        yield literal(':');
        $value = yield $jValue;
        $result[$key] = $value;
        return true;
    });
    yield $pair->separatedBy(literal(','));

а как с автокомплитом метода separatedBy в IDE ?

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

Вот именно,
хороший код должен читаться без привычки

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

Просто yield — очень новая фича.
Ее почти никто не начал использовать. :)
Я бы добавил во вступлении, что инструменты ФП в PHP не просто есть, а есть с незапамятных времён и плох тот пехепешник, который не знает об array_(map|reduce|filter) и call_user_func
Sign up to leave a comment.

Articles