Из-за ленивости на хаскеле действительно эти трансдьсеры не нужны (если не нужно переиспользовать трансформации) и на js такое действительно можно написать только через генераторы, вы правы.
x |> f = f x
main =
[1..]
|> filter even
|> map (* 2)
|> take 3
|> print -- [4, 8, 12]
Увеличение уровня абстракции в данном случае помогает использовать трансдьюсеры со всеми сворачиваемыми типами (массивы, стримы в rxjs, множества, словари) независимо от того, реализовали ли они функции map/filter/take. Чисто теоретически, если бы трансдьюсеры бы встроили в js, то из всех библиотек типа rxjs/xstream все эти трансформации можно было бы выпилить, оставив только reduce, потому что универсальные трансдьюсеры будут работать однообразно везде.
Да, можно, в js тоже есть библиотеки с ленивыми коллекциями, а в clojure все трансформации по умолчанию ленивы (но при этом ленивые трансформации проигрывают по скорости трансдьюсерам.
Но работа с трансформациями как с объектом первого класса — фишка трансдьюсеров, которая позволяет
а) переиспользовать их
б) использовать одни и те же трансдьсеры для любых типов данных, которые поддерживают свертки (Foldable), скажем, стримы в rxjs (те же самые трансдьюсеры будут прекрасно работать и там), а значит из этих библиотек можно было бы спокойно выпилить все трансформации, если бы трансдьюсеры были бы нативными и общеиспользуемыми (маловероятное будущее, но в clojure стремятся к этому)
Как я уже сказал, писать все эти трансдьюсеры с нуля не придется. Почти во всех своих проектах я использую ramda (как аналог lodash, только функциональный), который уже имеет реализацию трансдьюсеров (пример в статье есть). Мало того, трансдьюсеры — паттерн намного проще, чем ленивые вычисления (в lodash). Да и и сама ramda намного проще и немагичнее, чем lodash. Так же трансдьюсеры позволяют переиспользовать код, потому что позволяют работать с трансформациями как с объектом первого класса, а потом применять их.
Еще важно то, что трансдьюсеры работают где угодно, где есть reduce, то есть эти трансьдеюсеры будут работать что с lodash, что с ramda, что со стримами (при условии конечно, что они не зависят от реализации reduce, как функция take). Из этого следует вывод, что всякие xstream/rxjs можно было упросить, убрав оттуда filter/map/прочее и оставив только reduce.
Матана в трансдьюсерах нет, в статью я хотел вложить смысл, что это очень простой паттерн, который позволяет добится большой эффективности.
Ну и для сравнения с циклами: читать цепочку трансформация (будь то просто Array#map, или трансдьюсеры) проще, чем циклы с внутренней логикой, так как это декларативно.
Под паттерном я тут понимаю не паттерн проектирования, а просто какой-то повторяющийся кусок кода/повторяющаяся сигнатура. В данном случае под middleware я понимаю что-то вроде обертки, которая принимает функцию и возвращает новую с такой же сигнатурой, но с дополнительной логикой.
Да, так и есть. Я довольно долго работал с ленивыми коллекциями и генераторами, в результате чего привык сначала делать все операции (зачастую над бесконечным списком), а после чего брать нужное количество результатов.
Шрифты с гигатурами для повышения читаемости кода (считать и спарсить один символ "≥" намного проще, чем два символа, особено в какой-нибудь строке с js-лямбдой), например — https://github.com/tonsky/FiraCode
Мне кажется, это ситуативно. Если главная страница — посадочная, которая не имеет никакого функционала и основная цель которого — чтобы юзер зарегался и начал пользоваться сервисом, то логотипа более чем достаточно и отдельная ссылка будет только мешать, заставляя входить в сервис каждый раз. Если же наше приложение — какой-нибудь дашборд, где главная страница — список наших проектов, то ссылка на главную ОБЯЗАТЕЛЬНО должна быть.
ruby медленный
Тут дело даже не в этом, а в том, что скорость руби почти не играет роли, когда ботлнек — доступ к базе данных.
Гугл таки уже запускает js, разве нет? Более того, писать изоморфные приложения (то есть первый рендеринг SPA на стороне клиента и кэшируется) уже стало нормой.
А есть подобный список, но для Elixir/Erlang? Мне очень нравится акторная модель Elixir, Phoenix в какой-то мере тоже нравится, но я не вижу смысла делать на нем обычные сайты, которые хранят данные и рендерят страницы, нужно что-то с фоновым процессом и вебсокетами.
Делал ранее агрегатор, который в фоне парсил торрент-трекеры и по вебсокетам отправлял новые раздачи на клиенты.
А зачем делать еще одно нативное приложение для разных платформ, которое нужно юзерам устанавливать, ради которого нужно нанимать несколько новых программистов ради мобильных платформ, если можно просто сделать РЕАЛЬНО кроссплатформу через веб, до которой будет проще добраться (запустить сайт значительно проще)?
P.S.: Электрон — зло, конечно, имхо, там все в принципе можно и в браузере запустить (и запускают, веб-версия скайпа есть и используется мной, если мне вдруг нужно в 2017 скайп запустить)
Из-за ленивости на хаскеле действительно эти трансдьсеры не нужны (если не нужно переиспользовать трансформации) и на js такое действительно можно написать только через генераторы, вы правы.
Несколько недель назад я такое тоже писал:
Увеличение уровня абстракции в данном случае помогает использовать трансдьюсеры со всеми сворачиваемыми типами (массивы, стримы в rxjs, множества, словари) независимо от того, реализовали ли они функции map/filter/take. Чисто теоретически, если бы трансдьюсеры бы встроили в js, то из всех библиотек типа rxjs/xstream все эти трансформации можно было бы выпилить, оставив только reduce, потому что универсальные трансдьюсеры будут работать однообразно везде.
Да, можно, в js тоже есть библиотеки с ленивыми коллекциями, а в clojure все трансформации по умолчанию ленивы (но при этом ленивые трансформации проигрывают по скорости трансдьюсерам.
Но работа с трансформациями как с объектом первого класса — фишка трансдьюсеров, которая позволяет
а) переиспользовать их
б) использовать одни и те же трансдьсеры для любых типов данных, которые поддерживают свертки (Foldable), скажем, стримы в rxjs (те же самые трансдьюсеры будут прекрасно работать и там), а значит из этих библиотек можно было бы спокойно выпилить все трансформации, если бы трансдьюсеры были бы нативными и общеиспользуемыми (маловероятное будущее, но в clojure стремятся к этому)
Как я уже сказал, писать все эти трансдьюсеры с нуля не придется. Почти во всех своих проектах я использую ramda (как аналог lodash, только функциональный), который уже имеет реализацию трансдьюсеров (пример в статье есть). Мало того, трансдьюсеры — паттерн намного проще, чем ленивые вычисления (в lodash). Да и и сама ramda намного проще и немагичнее, чем lodash. Так же трансдьюсеры позволяют переиспользовать код, потому что позволяют работать с трансформациями как с объектом первого класса, а потом применять их.
Еще важно то, что трансдьюсеры работают где угодно, где есть reduce, то есть эти трансьдеюсеры будут работать что с lodash, что с ramda, что со стримами (при условии конечно, что они не зависят от реализации reduce, как функция take). Из этого следует вывод, что всякие xstream/rxjs можно было упросить, убрав оттуда filter/map/прочее и оставив только reduce.
Матана в трансдьюсерах нет, в статью я хотел вложить смысл, что это очень простой паттерн, который позволяет добится большой эффективности.
Ну и для сравнения с циклами: читать цепочку трансформация (будь то просто Array#map, или трансдьюсеры) проще, чем циклы с внутренней логикой, так как это декларативно.
Нууу, это выглядит странно
Собственно, я переписывал это на хаскеле, но без нормальной реализации take.
Под паттерном я тут понимаю не паттерн проектирования, а просто какой-то повторяющийся кусок кода/повторяющаяся сигнатура. В данном случае под middleware я понимаю что-то вроде обертки, которая принимает функцию и возвращает новую с такой же сигнатурой, но с дополнительной логикой.
А вот можно по-подробнее? Если сделать сперва .slice(0, 2), то мы получим первые две игры независимо от того, выигранные они или нет.
Да, так и есть. Я довольно долго работал с ленивыми коллекциями и генераторами, в результате чего привык сначала делать все операции (зачастую над бесконечным списком), а после чего брать нужное количество результатов.
Добавил ссылки на описание с документации express.js, laravel, а так же на свое приблизительно объяснение.
Исправил, спасибо.
Шрифты с гигатурами для повышения читаемости кода (считать и спарсить один символ "≥" намного проще, чем два символа, особено в какой-нибудь строке с js-лямбдой), например — https://github.com/tonsky/FiraCode
Мне кажется, это ситуативно. Если главная страница — посадочная, которая не имеет никакого функционала и основная цель которого — чтобы юзер зарегался и начал пользоваться сервисом, то логотипа более чем достаточно и отдельная ссылка будет только мешать, заставляя входить в сервис каждый раз. Если же наше приложение — какой-нибудь дашборд, где главная страница — список наших проектов, то ссылка на главную ОБЯЗАТЕЛЬНО должна быть.
ruby медленный
Тут дело даже не в этом, а в том, что скорость руби почти не играет роли, когда ботлнек — доступ к базе данных.
Как вам такой сайт? https://www.humblespark.com
Slack
А есть подобный список, но для Elixir/Erlang? Мне очень нравится акторная модель Elixir, Phoenix в какой-то мере тоже нравится, но я не вижу смысла делать на нем обычные сайты, которые хранят данные и рендерят страницы, нужно что-то с фоновым процессом и вебсокетами.
Делал ранее агрегатор, который в фоне парсил торрент-трекеры и по вебсокетам отправлял новые раздачи на клиенты.
А зачем делать еще одно нативное приложение для разных платформ, которое нужно юзерам устанавливать, ради которого нужно нанимать несколько новых программистов ради мобильных платформ, если можно просто сделать РЕАЛЬНО кроссплатформу через веб, до которой будет проще добраться (запустить сайт значительно проще)?
P.S.: Электрон — зло, конечно, имхо, там все в принципе можно и в браузере запустить (и запускают, веб-версия скайпа есть и используется мной, если мне вдруг нужно в 2017 скайп запустить)
Ага, чтобы программисты видели кучу сложночитаемого и сложноподдержимоего кода. Слайдеры на CSS — не читаемый код.
Анимация — это стили, они должны быть сделаны на css. Я ведь написал это в своем комменте.