За этим можно обратиться к C# и их async/await. Замечательная модель, но она не легла хорошо на язык и библиотеки. За пределами туториалов все очень криво и косо и конца этому нет и не видно.
А можно примеры? Ну кроме стандартной проблемы вызова асинхронного кода из синхронного. А то как-то ни разу в моей практике реальных проблем не было.
Для меня этот продукт известен как "фольга для плиты" или "пластины для защиты плиты". Суть в том, что вы фольгой накрываете плиту. А когда фольга засралась, то выкидываете её и накрываете плиту новой
Дело в том, что вы не можете просто так трактовать систему с неопределенным поведением компонентов как идеальную детерминированную систему. Но в практическом смысле для всех разумных задач вы можете трактовать некоторые системы как почти идеально детерминированные системы.
Математикам различие важно, физикам — по барабану.
Замечание: есть ряд случаев, когда можно трактовать систему со стохастическими компонентами как полную идеально детерминированную. Например, стохастический компонент может быть не связан с другими компонентами и не будет влиять на общее поведение системы (является ли это системой — зависит от вашего словаря). Или можно доказать, что стохастический эффект аннулируется (например, у вас есть набор логических вентилей, которые выдают константу вне зависимости от входа). Но, как правило, это никому не интересно.
И если вы мне скажете, что не кайфуете от чувства собственного превосходства, то вы врете. Говорите мне про добрые цели, обучение новичков и благородство — я-то знаю, что вы просто от себя тащитесь в глубине души.
Необоснованная экстраполяция до добра не доведет. Проблема заключается в том, что не все такие как ты. Когда я делаю код-ревью, то я не кайфую от чувства собственного превосходства. Я отлыниваю, я не хочу делать код-ревью. Я не хочу читать код, я не хочу писать замечания. Мне приходится это делать — вместо того, чтобы взять и просто поправить код. Я бы с радостью работал в одно рыло вечно, да вот только не получится.
просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.
Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.
В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
Каррирование нужно для лучшей поддержки pipeline-оператора |>
1) имя «n» — полохое. Лучше либо никакое, либо нормальное
2) уже на пятерке строк pipeline у вас начнет рябить в глазах
В C# аналогичный синтаксический сахар — это static extension методы.
Самое интересное: если сходить и посмотреть сам доклад, то станет ясно, что слайд имел как минимум развлекательную направленность. А еще можно увидеть, что слайд показан не весь: в конце показывается текст «Seriously, FP patterns are different». Человек просто хотел сказать, что нельзя переносить опыт из ООП в ФП.
Однако несколько людей в том вопросе начала отвечать нейтрально с точки зрения дружелюбия. Не стоит судить сообщество по отдельным товарищам.
Впрочем, сам вопрос "как применять ФП" ужасно большой, сравним с "как применять ООП" или "как программировать". На него трудно дать ответ в комментарии. Это притягивает тех, кто ответ на собирается давать.
Кстати, вы даже базовой терминологии не знаете. «чистый» — это не значит, что там ТОЛЬКО ФП, а это значит вот это: en.wikipedia.org/wiki/Purely_functional_programming
Ну сходил бы и почитал твою же статью. «Чистое» ФП — это подмножество ФП. «Чистому» ФП противопоставляется «нечистое» ФП.
Как только всё это сталкивается с реальность — там начинаются манёвры, и вы их уже демонстрировали.
такое, такое, такое, такое и такое.
Вы просто пользуетесь тем, что словари далеки от идеала. Вы используете максимальное кастрированное определение ФП, которое банит даже хаскелль. Или тролль, или просто хейтер.
Я вас не об этом спрашивал, я спрашивал о конкретных, полезных и применимых примерах использования подобной магии
Ок, есть к примеру, clojure.core.async, который использует внутри себя макросы для превращения кода в стейт-машину.
Наверное потому, что организация api в реакте использует свойства/парадигму жс?
Но нет, api в реакте использует только подмножество JS, а не все в JS. Кроме того, никто не запрещает эмулировать ФП на не-ФП языках.
Пошли манёвры, ну предоставьте пример использования api, который бы не противоречил базовым принципам ФП. Это ведь так просто.
У меня создается ощущение, что вы ненавидите ФП. Если ФП само по себе не самостоятельно, то почему Haskell считается чисто функциональным языком, но на нем можно писать программы?
В лиспах магия — макросы. Позволяет расширять поведение языка на лету.
Я даже зашел сюда: en.wikipedia.org/wiki/Functional_programming и проверил свои познания ФП — действительно, всё в ЖС и в ректе противоречит всем базовым концепциям. Объекты на уровне языка, переменные, состояния, отсутствие чистоты, прозрачность ссылок, отсутствие хоть какой-то системы типов, циклы
Зачем мешать жс и реакт, мы ведь только о реакте говорим? Это явное передергивание.
С чем? Где же эта изоляция, если само api по умолчанию не является ФП?
Юзер компоненты можно писать трогая только определенную часть АПИ.
Пфф… Вы так говорите, будто ФП и лисп в частности запрещают сайд-эффекты и магию. Особенно угарно упоминание лиспа, который позволяет творить супер-магию, которая бедному js и не снилась.
Система без сайд-эффектов непригодна к использованию. Суть ФП в изоляции сайд-эффектов.
Реакт прекрасно с этим справляется. Сам реакт изобилует всякой херней, но это не важно, потому что реакт позволяет писать юзеркод в функциональном стиле.
Подход хуков ближе к ФП, потому что в юзеркоде не требует классов, а требует только функции.
А это такой тоже интересный момент. Мне кажется, что если в своих JS задачах вы достигли уровня, когда следует воспользоваться какой-либо библиотекой уровня React (т.е. задачи уже довольно серьёзные), то...
Увы, популярная практика «фуллстеков» приводит к тому, что человек знает только одну часть профессии нормально, но с другой части его спрашивают как будто он знает её нормально.
Но, видимо, это актуально. Актуально учить некий абстрактный React забив даже на JS.
Это верстальщики и свитчеры, не обращайте внимания.
Ой, я наконец-то внимательно прочитал доку. Раньше я думал, что хуки нельзя использовать внутри компонентов которые внутри цикла. А вот оно как на самом деле:
Don’t call Hooks inside loops, conditions, or nested functions. Instead, always use Hooks at the top level of your React function
Для меня этот продукт известен как "фольга для плиты" или "пластины для защиты плиты". Суть в том, что вы фольгой накрываете плиту. А когда фольга засралась, то выкидываете её и накрываете плиту новой
Дело в том, что вы не можете просто так трактовать систему с неопределенным поведением компонентов как идеальную детерминированную систему. Но в практическом смысле для всех разумных задач вы можете трактовать некоторые системы как почти идеально детерминированные системы.
Математикам различие важно, физикам — по барабану.
Замечание: есть ряд случаев, когда можно трактовать систему со стохастическими компонентами как полную идеально детерминированную. Например, стохастический компонент может быть не связан с другими компонентами и не будет влиять на общее поведение системы (является ли это системой — зависит от вашего словаря). Или можно доказать, что стохастический эффект аннулируется (например, у вас есть набор логических вентилей, которые выдают константу вне зависимости от входа). Но, как правило, это никому не интересно.
Твой мотив быть говном — он только твой.
Конкретно по триггерам: blog.kloud.com.au/2018/01/30/cosmos-db-server-side-programming-with-typescript-part-4-triggers
Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.
В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
1) имя «n» — полохое. Лучше либо никакое, либо нормальное
2) уже на пятерке строк pipeline у вас начнет рябить в глазах
В C# аналогичный синтаксический сахар — это static extension методы.
Я прошу прощения, но F# в силу своих истоков является мультипарадигменным. Т.е вы можете в рамках F# комбинировать традиционные и новые подходы.
Однако несколько людей в том вопросе начала отвечать нейтрально с точки зрения дружелюбия. Не стоит судить сообщество по отдельным товарищам.
Впрочем, сам вопрос "как применять ФП" ужасно большой, сравним с "как применять ООП" или "как программировать". На него трудно дать ответ в комментарии. Это притягивает тех, кто ответ на собирается давать.
Вы просто пользуетесь тем, что словари далеки от идеала. Вы используете максимальное кастрированное определение ФП, которое банит даже хаскелль. Или тролль, или просто хейтер.
Ок, есть к примеру, clojure.core.async, который использует внутри себя макросы для превращения кода в стейт-машину.
Но нет, api в реакте использует только подмножество JS, а не все в JS. Кроме того, никто не запрещает эмулировать ФП на не-ФП языках.
Держи: const Hi = () => <span>Hi</span>
В лиспах магия — макросы. Позволяет расширять поведение языка на лету.
Зачем мешать жс и реакт, мы ведь только о реакте говорим? Это явное передергивание.
Юзер компоненты можно писать трогая только определенную часть АПИ.
Система без сайд-эффектов непригодна к использованию. Суть ФП в изоляции сайд-эффектов.
Реакт прекрасно с этим справляется. Сам реакт изобилует всякой херней, но это не важно, потому что реакт позволяет писать юзеркод в функциональном стиле.
Подход хуков ближе к ФП, потому что в юзеркоде не требует классов, а требует только функции.
Это верстальщики и свитчеры, не обращайте внимания.
Это решается линтером.
Мне кажется, что человек говорит о том, что стрелочные функции можно было бы сделать получше и нужда в классах бы сильно уменьшилась.