Давайте Вы сперва попробуете растолковать в чём тут профит.
Профит функционального стиля - это отдельная тема. Сейчас речь о том, что на большинстве популярных ООП языках нельзя или сложно (многословно, громоздко) писать в функциональном стиле.
Так вот, Ф-языки не имеют ПОЛНОЙ поддержки ООП.
Нет, Вы утверждали и продолжаете утверждать, что ФП - это сектанты, которые отвергают всё "чуждое", включая ООП.
потому что ООП не запрещает мутабельность, а Ф-языки её отвергают.
То, что из семи приведённых языков в шести мутабельность поддерживается, Вас не смущает?
Рекурсия неестественна для человеческого мышления. На уроках информатики приходится объяснять, что это такое.
Чтобы понять рекурсивное определение, например, факториала, не обязательно знать, что такое рекурсия.
цикл - повторяющееся действие
Нет. Цикл - это один из способов организовать повторяющиеся действия.
рекурсия - незавершённое объяснение, формулировка, ссылающаяся на саму себя.
Поэтому для использования рекурсии не обязательно знать, что это такое. Как необязательно знать, что такое падеж, чтобы разговаривать на русском языке.
большинство действий, вещей итп с которыми сталкивается человек
Мы говорим не об абстрактных действиях, а об именовании. И обычно мы называем предмет, а не место, где он расположен.
Функциональный подход: это карандаш.
Императивный подход: это то, что лежит в пенале (сегодня карандаш, завтра ручка).
Кроме того, современные дети с первого класса начинают учить математику. А в математике "переменная" используется в функциональном смысле.
ну хорошо. смотрим в фичи хацкеля.
Ещё раз с самого начала.
Вы чуть ли не в каждом сообщении называете ФП сектантством. Обосновываете тем, что в функциональных языках, якобы, нет императивных фич. В отличии от ПП языков, в которых полно ФП фич. И тут внезапно (для Вас) выясняется, что в ФП языках ПП фич больше, чем ФП фич в ПП. Поэтому все Ваши рассуждения на эту тему (то есть, половину того, что Вы написали) можно выкидывать на свалку.
Любой язык должен включать в себя числа, строки и способы комбинирования из них более сложных структур.
Этого недостаточно для эффективного (трудозатраты) написания больших приложений. Для борьбы со сложностью в императивных языках обычно используются классы (или прототипы). Для борьбы со сложностью в функциональных языках обычно используются АТД. Прочитайте про систему типов в функциональных языках.
Для того, чтобы писать в современном императивном стиле, нужны классы/прототипы и наследование. Для того, чтобы писать в современном функциональном стиле, нужны АТД, сопоставление с образцом и обобщённые функции.
я вот не знаю занахрена мне в обычном языке АДТ
Для того, чтобы использовать современный функциональный стиль. Конечно, если Вы хотите его использовать.
Понимаете, в чём наше отличие? Я хочу язык в который натащить всего-всего. Вот прямо всех доступных технологий.
А Вы хотите, напротив, выбросить то, что считаете "грязным", "нечистым".
Ну сколько можно. Мы ведь уже выяснили, что в популярных функциональных языках императивных фич больше, чем в функциональных фич в императивных языках.
Вы не тащите к себе АТД и даже не понимаете, как их можно использовать. А я прекрасно понимаю, как можно использовать ООП.
на любом императивном языке (даже на bash) можно писать в Ф-стиле.
Неверно. Попробуйте написать на не функциональном языке
data Foo = Bar | Baz Int
showFoo Bar = "Bar"
showFoo (Baz x) = show x
вообще не вижу взаимосвязи ООП и ФП.
Взаимосвязь между фактом поддержки ООП функциональными языками и Вашим утверждением, что они не поддерживают ООП (и большим количеством выводов, которые Вы делаете из этого, очевидно неверного, Вашего утверждения) .
множество языков включает в себя всяческую поддержку математики,
Математика тут не причём. В основе ООП языков - классы/прототипы. В основе ФП языков - АТД. Упрощая можно сказать, что есть ООП способ строить приложения и есть ФП способ строить приложения.
не является аргументом в сравнении ФП vs ПП.
Опять Вы отвечаете невпопад. АТД являются признаком, по которому можно отличить функциональные языки от не функциональных.
потому что там есть необходимые для этого инструменты, а в функциональном языке нет.
Обоснуйте.
максимально быстрый автомат можно создать ТОЛЬКО на
Только на ассемблере под конкретный процессор.
не обязана.
Вот Вы сами подтвердили, что Ваше предыдущее утверждение (автоматы только на гото) неверно.
Когда Вам удобно, у Вас и промис - монада и async - она же.
Мы говорим не о "моей парадигме", а о том, какие императивные фичи есть в функциональных языках. Почти во всех из них циклы есть, хоть они и не нужны. Это опровергает Ваше утверждение про отсутствие императивных фич в функциональных языках.
Циклы используются не ради циклов, а для описания итеративных процессов. Но для этого не обязательно использовать циклы.
циклы - естественны для человеческого мышления.
Циклы неестественны для человеческого мышления. На уроках информатики школьникам приходится объяснять, что это такое. И не все сразу понимают.
Рекурсия естественна для человеческого мышления.На уроках математики школьники понимают рекурсивные определения, даже не зная определения рекурсии.
иммутабельность как раз неестественна: в блокнотах пишут, файлы редактирую
Причём здесь блокноты и файлы? Переменная - это имя, обозначение. Естественно, дать имя/обозначение один раз и дальше его использовать. Так обычно делают - и в жизни, и на уроках математики.
когда он будет отствавать, бизнес бросит его в помойку
Не занимайтесь демагогией. Мы говорим про конкретный количественный показатель. Его можно непосредственно измерить/посчитать, а не гадать на кофейной гуще. Составьте два списка и сравните.
и те сравнения, что Вы предлагаете, противоречат простой статистике.
Статистика подтверждает моё утверждение. Для сравнения количества фич нужно использовать статистику по количеству фич, а не какую-то другую.
Вы говорите "нужна АДТ!". зачем она нужна?
Я говорю: чтобы создавать приложения в функциональном стиле, нужны АТД. Что тут непонятного?
Почему Вы решили, что не является? Сами придумали? Очень странно, что почти ничего не зная о ФП, Вы берётесь рассуждать об этом, оспаривая мнение специалистов.
Rust является функциональным языком. Вам уже в другом посте объяснили, почему.
не вижу в этом ну вообще ничего
Вы примерно 100500 раз повторили, что ФП - это сектанты, которые не терпят ничего императивного. Может быть, теперь, узнав, что большинство ФП языков поддерживают ООП, Вы перестанете повторять эту чушь.
но я пока не вкурил, что Вы имеете в виду под АДТ.
Алгебраические типы данных. Вместе сопоставлением с образцом АТД является характерной чертой функциональных языков.
Рассуждать о ФП, не зная про АТД, это как рассуждать про ООП, не зная про наследование.
заметьте, я постоянно поясняю свою позицию
Каким образом Ваш текст про дождь и пустыню поясняет Ваше утверждение, что функциональные языки не подходят для автоматов?
вы только прыгаете в "не верно".
Не вижу смысла приводить новые контраргументы, пока Вы на старые не отреагировали.
стейтмашина на goto предполагает
Стейтмашина не обязана реализовываться на goto. "goto" - это никому не интересные детали реализации.
только оно нифига не будет столько же эффективно.
Источник информации? Опять рассуждаете про монады, ни разу не попробовав их в деле.
Вы утверждаете, что в процедурных языках много фич из функциональных, а в функциональных - мало фич из процедурных. Я Вам предлагаю сравнить количество фич в этих списках, чтобы Вы убедились, что Вы не правы.
по сравнению с ASM F# конечно будет рулить и бибикать.
а по сравнению с процедурным языком будет отставать.
Не передёргивайте. Я Вам предлагаю сравнивать не с ASM, а с одним из самых популярных процедурных языков. Чтобы Вы убедились, наконец, что отставать будет процедурный язык.
а с учётом того, что в процедурных языках можно использовать функциональные подходы, а наоборот - нет
во первых, вы путаете фичи. одинаковые английские слова - разные фичи
Я не путаю. Это Вы выдвигаете, мягко говоря, очень странные утверждения о том, что такое async в функциональных языках.
во вторых, перевираете контекст. Я никогда не говорил, что монады пришли в хацкел из С++ :)
Это Вы перевираете контекст. Речь шла об async
И в любом случае, "появилось раньше в языке А" - это не эмоциональный аргумент в любом контексте.
то есть функциональщики боятся "испачкаться" в процедурном стиле
Похоже, Вы совсем ничего не знаете о функциональных языках.
Вот список самых популярных на текущий момент: Kotlin, Swift, Rust, F#, Julia, Scala, Haskell. Пять из семи поддерживают ООП. Шестой (Rust) поддерживает процедурный стиль. Всего один чистый функциональный язык - Haskell.
А если мы возьмём список популярных процедурных (по факту - ООП) языков, то почти ни один из них не поддерживает АТД. То есть, они не позволяют составлять программу в функциональном стиле (только отдельные функции).
Вы аргументы приводили эмоциональные: правильнее/красивее/раньше придумано/академически/итп
В моём сообщении нет эмоциональных аргументов. И в предыдущих сообщениях тоже нет аргументов "правильнее/красивее/академически". А "раньше придумано" - это не эмоциональный аргумент. Очевидно, что если фича появилась в языке А раньше, чем в языке Б, то она не могла попасть в язык А из языка Б.
А Ваши аргументы эмоциональные - "секстанский", "никому не нужный", "натягивать сову на глобус" и т.п.
в большинстве алгоритмов с вложенными циклами рекурсию реализовать теоретически можно, но придётся натягивать аки сову на глобус.
Нет алгоритмов "со вложенными циклами". Есть алгоритмы, которые Вы будете реализовывать с помощью вложенных циклов. Но их так же просто реализовать и без циклов.
Если Вы сомневаетесь, то приведите пример.
функциональные языки для стейтмашин вообще не подходят, поскольку проигрывают начисто по накладным расходам!
Эффективность зависит не от языка, а от компилятора.
Ваше утверждение "вообще не подходят" - бездоказательно. Видимо, Вы просто не умеете писать на функциональных языках.
Не тупо. Сначала я приводил аргументы, но Вы большую часть из них игнорируете (снова и снова повторяете свои недоказанные аргументы, игнорируя контраргументы).
Например, в том сообщении по порядку:
крайне редкий вычислительный алгоритм описывается рекурсией
Это неверно. Очевидно, что любой алгоритм, кроме О(1), можно описать рекурсией. Более того, обычно самый простой способ решить задачу - свести её к той же задаче меньшего размера. Проще всего это сделать с помощью рекурсии.
Предел не является изменяемой переменной. Окрестность (x -> к чему-то) не является изменяемой переменной. И "для всех x" в определении предела не означает, что x изменяется, а означает некое множество.
И так далее все Ваши утверждения. Причём, многие из них Вы повторяете уже не первый раз.
а средний функциональный язык концентрируется только на подмножестве A, считая подмножество B "грязным"
Я Вам уже писал, что это неверно. Сравните, например, C# и F#.
считая подмножество B "грязным", "неверным". Сектантство именно в этом - в отрицании иного опыта.
Это Вы про Ваши слова, что алгебраические типы данных ненужные?
Именно поэтому сектанты во все дыры пихают этого ненужного Фибоначчи.
Теперь понятно, почему Вы пихаете Фибоначчи почти в каждый свой пост.
Ваш пост полностью состоит из бездоказательных (и неверных) утверждений, искажённого цитирования и тому подобного. Не вижу смысла в подробных комментариях.
еще раз: async/await в прцедурных и функциональных языках имеют различное предназначение
async/await и в функциональных, и в императивных языках - это удобный синтаксис. То есть, это не новый способ выполнить асинхронный вызов, а новый способ описать в коде асинхронный вызов.
и вообще широчайшим образом стал юзать паттерн мутабельных переменных на стеке
То же самое можно сказать про "+" (плюс). Согласно Вашей логике, из того, что в императивных языках складываются изменяемые переменные, плюс в императивных языках это совсем не то, что плюс в функциональных.
Люди мыслят алгоритмами, а не преобразованиями.
Вот именно. А в императивных языках им приходится мыслить циклами и прочими несущественным для задачи деталями реализации.
Практически любой вычислительный алгоритм проще написать через рекурсивный процесс. А чтобы перевести его в итеративный процесс (хоть через рекурсию, хоть через цикл), приходится подумать.
Людям удобно использовать переменную, которая мутабельна, а не та, которая вычисляется лишь однажды.
Людям удобно использовать неизменяемую переменную. Как в математике ("пусть y = x + 1").
где-то под капотом работают те самые монады.
Нет никаких монад под капотом. Монады - это типы данных с определённым свойствами (для которых соблюдаются монадические законы). Ближайшая (хоть и кривая) аналогия в объектно-ориентированных языках - это интерфейс или трейт (конкретный - IMonad).
Монадной нотацией называют специальный синтаксис для монад (синтаксический сахар). Например, в F# этот синтаксис задаётся через "выражения вычисления", а в Haskell - через реализацию класса типов.
а async в функциональном языке - лишь расширенный вариант понятия "отложенное действие"
async/await и в функциональных, и в императивных языках - это удобный синтаксис (частный случай монданой нотациии).
.Кстати, генераторы списков основаны на том, что список является монадой.
Вывод неверен. Например, отсутствие прямого доступа к памяти не является минусом языка.
Есть случаи, когда удобнее A, есть случаи, когда удобнее B.
Это требует доказательства.
эталонное "не нужно" кстати.
Вы просто не умеете ими пользоваться.
В языках с динамической типизацией двойное "не нужно" получается.
Динамическая типизация - тоже типизация. И каждое значение имеет конкретный тип. И пользовательские типы данных в них активно используются.
как видим, языки сектантов вполне можно смело отбрасывать, ибо нормальные языки включают те же возможности, что и языки сектантов.
Если "языками сектантов" Вы называете пхп и пёрл, то да.
Что касается большинства функциональных языков, то они по возможностям превосходят соответствующие объектно-ориентированные языки. Сравните, например, Scala и Java или F# и C#.
поскольку необходимо крайне редко, то и библиотек таких мало
То есть, Вы считаете, что возможность написать функцию в одну строку, которую написали в 11 строк, нужна крайне редко.
можно написать свою библиотеку.
Системная библиотека отличается от самописной тем, что её знают все. То есть, её не придётся писать заново на новом месте работы и ждать, пока коллеги привыкнут к ней.
функциональные языки не имеют к внедрению async/await никакого (прописью: никакого) отношения.
Назовите язык и версию, в которой впервые появился async/await. Не промисы какие-нибудь, а именно async/await.
отсутствие возможности переписав только околосетевую подсистему задействовать AS IS огромное количество легаси
Несовместимость некой фичи с легаси кодом в каких-то конкретных языках не делает фичу плохой.
То, что с появлением async/await в каких-то языках этот способ стал самым популярным для асинхронных вычислений, указывает на то, что этот способ лучше предыдущих в этих языках.
так вышло, что async/await - ХУДШИЙ паттерн, пришедший в общеупотребительные языки.
Сначала Вы рассказывается, что на смену (якобы) "функциональному" аду колбеков пришёл замечательный (якобы) "процедурный" хороший async/await
Затем, несмотря на предоставленные факты, пытаетесь (голословно) убедить всех, что async/await появился раньше в процедурных языках. А когда не получилось, async/await внезапно становится у Вас худшим паттерном.
Я так понимаю, что с Вашей стороны идёт спор ради спора, и Вы сами не верите в то, что говорите.
У Вас "русские" - это национальность или нация?
Видимо даже до википедии не добрались.
Профит функционального стиля - это отдельная тема. Сейчас речь о том, что на большинстве популярных ООП языках нельзя или сложно (многословно, громоздко) писать в функциональном стиле.
Нет, Вы утверждали и продолжаете утверждать, что ФП - это сектанты, которые отвергают всё "чуждое", включая ООП.
То, что из семи приведённых языков в шести мутабельность поддерживается, Вас не смущает?
В отличии от жизни, в программе ребёнок может быть одновременно накормлен и не накормлен (в разных ветках перебора).
В императивных языках приходится мучить ребёнка, чтобы он изрыгнул съеденное и оказался в предыдущем состоянии.
Зачем классы в ООП языках знаете? АДТ в функциональных языках для того же.
Только в Ваших фантазиях.
Обоснуйте, что без мутабельности и goto нельзя написать эффективный автомат.
Мутабельность можно смоделировать на любом языке.
Чтобы понять рекурсивное определение, например, факториала, не обязательно знать, что такое рекурсия.
Нет. Цикл - это один из способов организовать повторяющиеся действия.
Поэтому для использования рекурсии не обязательно знать, что это такое. Как необязательно знать, что такое падеж, чтобы разговаривать на русском языке.
Мы говорим не об абстрактных действиях, а об именовании. И обычно мы называем предмет, а не место, где он расположен.
Функциональный подход: это карандаш.
Императивный подход: это то, что лежит в пенале (сегодня карандаш, завтра ручка).
Кроме того, современные дети с первого класса начинают учить математику. А в математике "переменная" используется в функциональном смысле.
Ещё раз с самого начала.
Вы чуть ли не в каждом сообщении называете ФП сектантством. Обосновываете тем, что в функциональных языках, якобы, нет императивных фич. В отличии от ПП языков, в которых полно ФП фич. И тут внезапно (для Вас) выясняется, что в ФП языках ПП фич больше, чем ФП фич в ПП. Поэтому все Ваши рассуждения на эту тему (то есть, половину того, что Вы написали) можно выкидывать на свалку.
Этого недостаточно для эффективного (трудозатраты) написания больших приложений. Для борьбы со сложностью в императивных языках обычно используются классы (или прототипы). Для борьбы со сложностью в функциональных языках обычно используются АТД. Прочитайте про систему типов в функциональных языках.
Для того, чтобы писать в современном императивном стиле, нужны классы/прототипы и наследование. Для того, чтобы писать в современном функциональном стиле, нужны АТД, сопоставление с образцом и обобщённые функции.
Для того, чтобы использовать современный функциональный стиль. Конечно, если Вы хотите его использовать.
Ну сколько можно. Мы ведь уже выяснили, что в популярных функциональных языках императивных фич больше, чем в функциональных фич в императивных языках.
Вы не тащите к себе АТД и даже не понимаете, как их можно использовать. А я прекрасно понимаю, как можно использовать ООП.
Спросите у гугла. Или у того, кто изучил Rust
Неверно. Попробуйте написать на не функциональном языке
Взаимосвязь между фактом поддержки ООП функциональными языками и Вашим утверждением, что они не поддерживают ООП (и большим количеством выводов, которые Вы делаете из этого, очевидно неверного, Вашего утверждения) .
Математика тут не причём. В основе ООП языков - классы/прототипы. В основе ФП языков - АТД. Упрощая можно сказать, что есть ООП способ строить приложения и есть ФП способ строить приложения.
Опять Вы отвечаете невпопад. АТД являются признаком, по которому можно отличить функциональные языки от не функциональных.
Обоснуйте.
Только на ассемблере под конкретный процессор.
Вот Вы сами подтвердили, что Ваше предыдущее утверждение (автоматы только на гото) неверно.
Вы не поняли то, что я написал.
Мы говорим не о "моей парадигме", а о том, какие императивные фичи есть в функциональных языках. Почти во всех из них циклы есть, хоть они и не нужны. Это опровергает Ваше утверждение про отсутствие императивных фич в функциональных языках.
Циклы используются не ради циклов, а для описания итеративных процессов. Но для этого не обязательно использовать циклы.
Циклы неестественны для человеческого мышления. На уроках информатики школьникам приходится объяснять, что это такое. И не все сразу понимают.
Рекурсия естественна для человеческого мышления.На уроках математики школьники понимают рекурсивные определения, даже не зная определения рекурсии.
Причём здесь блокноты и файлы? Переменная - это имя, обозначение. Естественно, дать имя/обозначение один раз и дальше его использовать. Так обычно делают - и в жизни, и на уроках математики.
Не занимайтесь демагогией. Мы говорим про конкретный количественный показатель. Его можно непосредственно измерить/посчитать, а не гадать на кофейной гуще. Составьте два списка и сравните.
Статистика подтверждает моё утверждение. Для сравнения количества фич нужно использовать статистику по количеству фич, а не какую-то другую.
Я говорю: чтобы создавать приложения в функциональном стиле, нужны АТД. Что тут непонятного?
Не путайте тёплое с мягким.
Почему Вы решили, что не является? Сами придумали? Очень странно, что почти ничего не зная о ФП, Вы берётесь рассуждать об этом, оспаривая мнение специалистов.
Rust является функциональным языком. Вам уже в другом посте объяснили, почему.
Вы примерно 100500 раз повторили, что ФП - это сектанты, которые не терпят ничего императивного. Может быть, теперь, узнав, что большинство ФП языков поддерживают ООП, Вы перестанете повторять эту чушь.
Алгебраические типы данных. Вместе сопоставлением с образцом АТД является характерной чертой функциональных языков.
Рассуждать о ФП, не зная про АТД, это как рассуждать про ООП, не зная про наследование.
Каким образом Ваш текст про дождь и пустыню поясняет Ваше утверждение, что функциональные языки не подходят для автоматов?
Не вижу смысла приводить новые контраргументы, пока Вы на старые не отреагировали.
Стейтмашина не обязана реализовываться на goto. "goto" - это никому не интересные детали реализации.
Источник информации? Опять рассуждаете про монады, ни разу не попробовав их в деле.
Вы утверждаете, что в процедурных языках много фич из функциональных, а в функциональных - мало фич из процедурных. Я Вам предлагаю сравнить количество фич в этих списках, чтобы Вы убедились, что Вы не правы.
Не передёргивайте. Я Вам предлагаю сравнивать не с ASM, а с одним из самых популярных процедурных языков. Чтобы Вы убедились, наконец, что отставать будет процедурный язык.
Откуда Вы взяли такую информацию?
Я не путаю. Это Вы выдвигаете, мягко говоря, очень странные утверждения о том, что такое async в функциональных языках.
Это Вы перевираете контекст. Речь шла об async
И в любом случае, "появилось раньше в языке А" - это не эмоциональный аргумент в любом контексте.
Похоже, Вы совсем ничего не знаете о функциональных языках.
Вот список самых популярных на текущий момент: Kotlin, Swift, Rust, F#, Julia, Scala, Haskell. Пять из семи поддерживают ООП. Шестой (Rust) поддерживает процедурный стиль. Всего один чистый функциональный язык - Haskell.
А если мы возьмём список популярных процедурных (по факту - ООП) языков, то почти ни один из них не поддерживает АТД. То есть, они не позволяют составлять программу в функциональном стиле (только отдельные функции).
Вы неверно интерпретируете этот закон.
Назовите источник этой информации. Вы сами это придумали?
Не извращение. Монада State входит в базовые библиотеки.
Не обманывайте. Я предлагаю Вам сравнить список фич C#, которых нет в F#, со списком фич в F#, которых нет в C#.
Картинка - вообще оффтоп.
В моём сообщении нет эмоциональных аргументов. И в предыдущих сообщениях тоже нет аргументов "правильнее/красивее/академически". А "раньше придумано" - это не эмоциональный аргумент. Очевидно, что если фича появилась в языке А раньше, чем в языке Б, то она не могла попасть в язык А из языка Б.
А Ваши аргументы эмоциональные - "секстанский", "никому не нужный", "натягивать сову на глобус" и т.п.
Нет алгоритмов "со вложенными циклами". Есть алгоритмы, которые Вы будете реализовывать с помощью вложенных циклов. Но их так же просто реализовать и без циклов.
Если Вы сомневаетесь, то приведите пример.
Эффективность зависит не от языка, а от компилятора.
Ваше утверждение "вообще не подходят" - бездоказательно. Видимо, Вы просто не умеете писать на функциональных языках.
Не тупо. Сначала я приводил аргументы, но Вы большую часть из них игнорируете (снова и снова повторяете свои недоказанные аргументы, игнорируя контраргументы).
Например, в том сообщении по порядку:
Это неверно. Очевидно, что любой алгоритм, кроме О(1), можно описать рекурсией. Более того, обычно самый простой способ решить задачу - свести её к той же задаче меньшего размера. Проще всего это сделать с помощью рекурсии.
Искажённое цитирование - подмена переменных элементами.
Предел не является изменяемой переменной. Окрестность (x -> к чему-то) не является изменяемой переменной. И "для всех x" в определении предела не означает, что x изменяется, а означает некое множество.
И так далее все Ваши утверждения. Причём, многие из них Вы повторяете уже не первый раз.
Я Вам уже писал, что это неверно. Сравните, например, C# и F#.
Это Вы про Ваши слова, что алгебраические типы данных ненужные?
Теперь понятно, почему Вы пихаете Фибоначчи почти в каждый свой пост.
Ваш пост полностью состоит из бездоказательных (и неверных) утверждений, искажённого цитирования и тому подобного. Не вижу смысла в подробных комментариях.
async/await и в функциональных, и в императивных языках - это удобный синтаксис. То есть, это не новый способ выполнить асинхронный вызов, а новый способ описать в коде асинхронный вызов.
То же самое можно сказать про "+" (плюс). Согласно Вашей логике, из того, что в императивных языках складываются изменяемые переменные, плюс в императивных языках это совсем не то, что плюс в функциональных.
Вот именно. А в императивных языках им приходится мыслить циклами и прочими несущественным для задачи деталями реализации.
Практически любой вычислительный алгоритм проще написать через рекурсивный процесс. А чтобы перевести его в итеративный процесс (хоть через рекурсию, хоть через цикл), приходится подумать.
Людям удобно использовать неизменяемую переменную. Как в математике ("пусть y = x + 1").
Нет никаких монад под капотом. Монады - это типы данных с определённым свойствами (для которых соблюдаются монадические законы). Ближайшая (хоть и кривая) аналогия в объектно-ориентированных языках - это интерфейс или трейт (конкретный - IMonad).
Монадной нотацией называют специальный синтаксис для монад (синтаксический сахар). Например, в F# этот синтаксис задаётся через "выражения вычисления", а в Haskell - через реализацию класса типов.
async/await и в функциональных, и в императивных языках - это удобный синтаксис (частный случай монданой нотациии).
.Кстати, генераторы списков основаны на том, что список является монадой.
это альтернативная запись для:
Вы специально игнорируете просьбу назвать версию, чтобы скрыть дату появления?
В JS промисы появились в 2012. В Python async/await появился в 2015.
Для того же самого - асинхронных вычислений.
Тогда промисы - просто объект для хранения колбеков. А монады - просто способ вызвать две функции по очереди. :)
Ваши фантазии про ФП довольно однообразны.
Неверно. Более того, я не припоминаю ни одного промышленного безтипового языка, кроме Forth.
Впрочем, все Ваши суждения о функциональных языках указывают на Ваше незнание предмета.
Вывод неверен. Например, отсутствие прямого доступа к памяти не является минусом языка.
Это требует доказательства.
Вы просто не умеете ими пользоваться.
Динамическая типизация - тоже типизация. И каждое значение имеет конкретный тип. И пользовательские типы данных в них активно используются.
Если "языками сектантов" Вы называете пхп и пёрл, то да.
Что касается большинства функциональных языков, то они по возможностям превосходят соответствующие объектно-ориентированные языки. Сравните, например, Scala и Java или F# и C#.
То есть, Вы считаете, что возможность написать функцию в одну строку, которую написали в 11 строк, нужна крайне редко.
Системная библиотека отличается от самописной тем, что её знают все. То есть, её не придётся писать заново на новом месте работы и ждать, пока коллеги привыкнут к ней.
Назовите язык и версию, в которой впервые появился async/await. Не промисы какие-нибудь, а именно async/await.
Несовместимость некой фичи с легаси кодом в каких-то конкретных языках не делает фичу плохой.
То, что с появлением async/await в каких-то языках этот способ стал самым популярным для асинхронных вычислений, указывает на то, что этот способ лучше предыдущих в этих языках.
Сначала Вы рассказывается, что на смену (якобы) "функциональному" аду колбеков пришёл замечательный (якобы) "процедурный" хороший async/await
Затем, несмотря на предоставленные факты, пытаетесь (голословно) убедить всех, что async/await появился раньше в процедурных языках. А когда не получилось, async/await внезапно становится у Вас худшим паттерном.
Я так понимаю, что с Вашей стороны идёт спор ради спора, и Вы сами не верите в то, что говорите.