Есть статьи, взвешенно-нейтрально разбирающие два подхода (в общем контексте программирования на Хаскеле, чаще всего), и есть более однобокие «вводные» статьи. Приведу ссылки, а ниже изложу своё поверхностное мнение (по воспоминаниям по просмотру статей, я темой интересовался).
Научные статьи, рассматривающие алгебраические эффекты и альтернативные подходы (монадные трансформеры) в рамаках Хаскеля: Monad Transformers and Modular Algebraic Effects (What Binds Them Together), Freer Monads, More Extensible Effects. Я такие статьи, скорее, просматриваю - с Хаскелем шапочно знаком, но не программирую на нём.
Моё поверхностное мнение: мне бы на Koka было бы удобнее программировать, чем разбираться с монадными трансформерами на Хаскеле. Koka - компактный язык, чётко иллистрирующий идею как "чисто" программировать в функциональном стиле с эффектами ("чисто" в том смысле, что нотация эффектов явная, и при этом не особо навязчивая). В плюс к этому - такое программирование хорошо укладывается у меня в голове (я "вижу", что будет происходить в машинном коде при выполнении - и при желании могу разобраться в сгенерированном компилятором Koka коде на стандартном C, реализуещем нужную семантику благодаря фиче C longjump, насколько я понимаю). Ну и -- при желании я этот код на C мог бы встроить в свою программу (на C++); не уверен, что получилось бы легко с встраиванием кода на Хаскеле.
С Rust сравнивать, наверно, можно, но осторожно - размах не тот (Rust - промышленный язык, Koka - скорее, демонстрационный, ну, как сравнивать Rust и Idris).
Плюс поставить прав не хватает, поэтому поддержу словами.
«Пытливый ум» это хорошо примерно как сытый конь в сферическом вакууме: взрослые люди любят говорить на презентациях «МЫ делаем Мир лучше», однако только одарёные дополнительными хромосомами не понимают что это лож. Современный Мир это лож.
Всем мы (ну минимум 98% из нас) каждый день ходим на работу не ради крутых алгоритмов и классных приложений, а ради ДЕНЕГ, чтобы не сдохнуть от холода/голода/дерессии и т.д.
И нет ничего хуже, чем ковыряться в чужом поносе коде, пытаясь понять «чойта оно не делает то что в документации обещано»… Система общественного образования натаскивает нашего брата на самопожертвования, и материальные (своё время), и моральные (подстраиваться под обстоятельства: учителя в школе, препода в вузе, тимлида на работе, разрабов фреймворка, который тимлид однажды, прокалив собственный пукан, раскурил и теперь, идя на поводу у психологической защиты, иконизирует как «отличный инструмент, который НАДО уметь использовать и использовать»)… это грязное рабство, интеллектуальное рабство: мы считаем себя «достойными» именно этого, а не чего-то другого… мы привыкаем что если во рту нет привкуса д*рьма пота и крови, то значит мы плохо себя реализуем, занимаемся «ненастоящей» работой… и слепо верим что однажды, наконец-то, доберёмся до вершины это гранитной горы мастерства аутофелляции использования «крутого» инструмента и заживём лучше всех. Мысль о том что есть жизнь и без страданий, прямо здесь и сейчас, надо только шаг в торону сделать — нас не посещает, на неё табу.
А всё почему? Потому что деньги у тупых недалёких людей, которые платят за «здесь и сейчас, да так же как у всех», а не за элегантные и эффективные решения (в том числе будущих) задач.
Психологи говорят, что если работа вас угнетает — надо с неё уходить. А куда? Проблема-то не в отдельно взятых людях, а сложившимся обществе — обществе, которое выросло в гонке за звёздами, плевать что там под ногами/позади/вокруг — азарт он таков, отключает критическое мышление. Каждый хочешь жить быть владельцем IBM/Apple/MS. Каждый живёт только ради себя, никого не волнуют остальные… и колесо сансары (в философском смысле, а не религиозном) в его узкую точку зрения просто не помещается.
Сорян за лирику — накипело, но суть, надеюсь, сможете уловить.
Добра всем.
Я тимлид и, в отличие от предыдущего оратора, верю в тимбилдинг. К сожалению, моя компания не оплачивает такие штуки, поэтому приходится изобретать самому. У меня психологическое образование, так что мне, вероятно, немного легче.
Я считаю, что хорошая команда складывается, когда с одной стороны, все разбираются в некой широкой доменной области, а с другой ещё и в какой-то своей узкой. Соответстенно в час нужды все всем могут помочь и все знают к кому можно обратиться за помощью. Я, как тимлид, снимаю компетенции со всех и могу помочь кому угодно — и стараюсь делать это по мере необходимости. Удивительно н алюдей действует ощущение того, что их коллега может помочь решить почти любую проблему. Они становятся открытыми, с радотью изучают новое и помогают друг другу.
Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.
Рядом с такими непонятными и неформальными вещами, как ни странно отлично уживаются кодревью, мёрджреквесты (только сейчас к ним пришли, к сожалению, надо было раньше) и другие штуки, которые помогают нам следить за качеством кода друг друга. Надо сказать, что холивары тоже случаются — их помогает решить либо демократия, либо диктатура — к счастью, тимлид может выбирать любую модель в зависимости от ситуации. Диктатура может быть актуальна в том случае, если тимлид больше знает об итоговых целях чем команда — так тоже бывает. Очень часто разработчиков не особенно интересуют глобальные цели, а больше интересуют локальные задачи. Это нормально и к ним надо относиться с пониманием — не все обладают имперскими амбициями.
Да, понимание — это тоже отличная штука, которая помогает создать команду. В атмосфере понимания кодревью проходят гладко, ошибки правятся быстрее и зачастую лучше. Все понимают, что замечание — это не желание придраться, а желание добиться лучшей цели.
Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл :)
Ещё важная лично для меня вещь — это эмпатия, то есть способность хорошо воспринимать эмоции окружающих. Может кто-то считает это выдумкой, а кто-то считает, что эмоциям на работе не место, но я в эти концепции не верю. Я считаю, что понимание эмоций команды ведёт к тому, что никто никого не доведёт до такой вспышки эмоций, каковая помешает ему работать. С эмоциями надо уметь работать, да.
P.S. Не бейте больно, это просто мой, причём не очень большой, опыт. Ваш может быть частично или совсем другим.
gulp-copy не нужен, потому что gulp умеет выполнять задачи без трансформации, как
gulp.src('./source/js/**/*.*', {base: './source'})
.pipe(gulp.dest('./dist')) //скопирует папку js из source в dist
.pipe(gulp.dest('./deploy')); //можно использовать несколько раз
Your plugin should not do something that can be done easily with an existing node module
Wrapping every possible thing just for the sake of wrapping it will pollute the ecosystem with low quality plugins that don't make sense within the gulp paradigm.
Плагин не должен делать то, что легко делается существующим node модулем
Оборачивание всего подряд ради обертки загрязняет екосистему плагинами низкого качества, что противоречит парадигме gulp
Так что да, не нужны
gulp-requirejs — простая обертка
gulp-browserify — не поддерживается, вместо этого сам дает ссылку на рецепты, где способ запуска browserify для gulp
Есть статьи, взвешенно-нейтрально разбирающие два подхода (в общем контексте программирования на Хаскеле, чаще всего), и есть более однобокие «вводные» статьи. Приведу ссылки, а ниже изложу своё поверхностное мнение (по воспоминаниям по просмотру статей, я темой интересовался).
«Алгебраические эффекты» человеческим языком - перевод на Хабре вводной статьи прикладного программиста, который ближе к концу поясняет, что с Хаскелем он не знаком и потому научные статьи ему непонятны, он рассматривает тему с практическими примерами на JavaScript (ссылка на оригинал статьи для удобства). Более недавняя статья другого программиста с примерами на OCaml: Friendship ended with Monads: Testing out Algebraic effects in OCaml for Animations.
Научные статьи, рассматривающие алгебраические эффекты и альтернативные подходы (монадные трансформеры) в рамаках Хаскеля: Monad Transformers and Modular Algebraic Effects (What Binds Them Together), Freer Monads, More Extensible Effects. Я такие статьи, скорее, просматриваю - с Хаскелем шапочно знаком, но не программирую на нём.
Уместна ссылка на давнюю статью автора Koka: Algebraic effects for Functional Programming.
Моё поверхностное мнение: мне бы на Koka было бы удобнее программировать, чем разбираться с монадными трансформерами на Хаскеле. Koka - компактный язык, чётко иллистрирующий идею как "чисто" программировать в функциональном стиле с эффектами ("чисто" в том смысле, что нотация эффектов явная, и при этом не особо навязчивая). В плюс к этому - такое программирование хорошо укладывается у меня в голове (я "вижу", что будет происходить в машинном коде при выполнении - и при желании могу разобраться в сгенерированном компилятором Koka коде на стандартном C, реализуещем нужную семантику благодаря фиче C longjump, насколько я понимаю). Ну и -- при желании я этот код на C мог бы встроить в свою программу (на C++); не уверен, что получилось бы легко с встраиванием кода на Хаскеле.
С Rust сравнивать, наверно, можно, но осторожно - размах не тот (Rust - промышленный язык, Koka - скорее, демонстрационный, ну, как сравнивать Rust и Idris).
«Пытливый ум» это хорошо примерно как сытый конь в сферическом вакууме: взрослые люди любят говорить на презентациях «МЫ делаем Мир лучше», однако только одарёные дополнительными хромосомами не понимают что это лож. Современный Мир это лож.
Всем мы (ну минимум 98% из нас) каждый день ходим на работу не ради крутых алгоритмов и классных приложений, а ради ДЕНЕГ, чтобы не сдохнуть от холода/голода/дерессии и т.д.
И нет ничего хуже, чем ковыряться в чужом
поносекоде, пытаясь понять «чойта оно не делает то что в документации обещано»… Система общественного образования натаскивает нашего брата на самопожертвования, и материальные (своё время), и моральные (подстраиваться под обстоятельства: учителя в школе, препода в вузе, тимлида на работе, разрабов фреймворка, который тимлид однажды, прокалив собственный пукан, раскурил и теперь, идя на поводу у психологической защиты, иконизирует как «отличный инструмент, который НАДО уметь использовать и использовать»)… это грязное рабство, интеллектуальное рабство: мы считаем себя «достойными» именно этого, а не чего-то другого… мы привыкаем что если во рту нет привкусад*рьмапота и крови, то значит мы плохо себя реализуем, занимаемся «ненастоящей» работой… и слепо верим что однажды, наконец-то, доберёмся до вершины это гранитной горы мастерствааутофелляциииспользования «крутого» инструмента и заживём лучше всех. Мысль о том что есть жизнь и без страданий, прямо здесь и сейчас, надо только шаг в торону сделать — нас не посещает, на неё табу.А всё почему? Потому что деньги у тупых недалёких людей, которые платят за «здесь и сейчас, да так же как у всех», а не за элегантные и эффективные решения (в том числе будущих) задач.
Психологи говорят, что если работа вас угнетает — надо с неё уходить. А куда? Проблема-то не в отдельно взятых людях, а сложившимся обществе — обществе, которое выросло в гонке за звёздами, плевать что там под ногами/позади/вокруг — азарт он таков, отключает критическое мышление. Каждый хочешь жить быть владельцем IBM/Apple/MS. Каждый живёт только ради себя, никого не волнуют остальные… и колесо сансары (в философском смысле, а не религиозном) в его узкую точку зрения просто не помещается.
Сорян за лирику — накипело, но суть, надеюсь, сможете уловить.
Добра всем.
Я считаю, что хорошая команда складывается, когда с одной стороны, все разбираются в некой широкой доменной области, а с другой ещё и в какой-то своей узкой. Соответстенно в час нужды все всем могут помочь и все знают к кому можно обратиться за помощью. Я, как тимлид, снимаю компетенции со всех и могу помочь кому угодно — и стараюсь делать это по мере необходимости. Удивительно н алюдей действует ощущение того, что их коллега может помочь решить почти любую проблему. Они становятся открытыми, с радотью изучают новое и помогают друг другу.
Итак, основа крепкой команды, с моей точки зрения — это доверие и взаимопомощь.
Рядом с такими непонятными и неформальными вещами, как ни странно отлично уживаются кодревью, мёрджреквесты (только сейчас к ним пришли, к сожалению, надо было раньше) и другие штуки, которые помогают нам следить за качеством кода друг друга. Надо сказать, что холивары тоже случаются — их помогает решить либо демократия, либо диктатура — к счастью, тимлид может выбирать любую модель в зависимости от ситуации. Диктатура может быть актуальна в том случае, если тимлид больше знает об итоговых целях чем команда — так тоже бывает. Очень часто разработчиков не особенно интересуют глобальные цели, а больше интересуют локальные задачи. Это нормально и к ним надо относиться с пониманием — не все обладают имперскими амбициями.
Да, понимание — это тоже отличная штука, которая помогает создать команду. В атмосфере понимания кодревью проходят гладко, ошибки правятся быстрее и зачастую лучше. Все понимают, что замечание — это не желание придраться, а желание добиться лучшей цели.
Насчёт традиций: очень классно если получается их создать. К сожалению, как-то так получилось, что в моей нынешней команды нет ничего, что объединяло бы всех членов команды (или мне пока не удалось этого нащупать) — пива не пью я, а в настольные игры не играет дизайнер, не всех интересует DevOps, ну и так далее. Завидую тем, кто общую тему таки нашёл :)
Ещё важная лично для меня вещь — это эмпатия, то есть способность хорошо воспринимать эмоции окружающих. Может кто-то считает это выдумкой, а кто-то считает, что эмоциям на работе не место, но я в эти концепции не верю. Я считаю, что понимание эмоций команды ведёт к тому, что никто никого не доведёт до такой вспышки эмоций, каковая помешает ему работать. С эмоциями надо уметь работать, да.
P.S. Не бейте больно, это просто мой, причём не очень большой, опыт. Ваш может быть частично или совсем другим.
По поводу requirejs и browserify, вот что говорится в руководстве для написания плагинов
Так что да, не нужны
gulp-requirejs — простая обертка
gulp-browserify — не поддерживается, вместо этого сам дает ссылку на рецепты, где способ запуска browserify для gulp