6 Кб, 298x169Почему функциональное программирование провалилось?
>>460219 (OP)
потому что программирование нужно для программистов, а не для вговнемоченых фантазеров
потому что программирование нужно для программистов, а не для вговнемоченых фантазеров
>>460275
пофиксил, а будь воля пограммистов то битрикс бы на хаскеле был с 1.5 фичей
>потому что программирование нужно для кабанчиков, а не для вговнемоченых пограммистов
пофиксил, а будь воля пограммистов то битрикс бы на хаскеле был с 1.5 фичей
>>460219 (OP)
неосиляторы
неосиляторы
В пизду эту лишнюю когнитивную нагрузку, когда надо копать от забора до заката
Потому что для функцианального программирования на лиспе и хачкеле надо быть умным знать математику и иметь трёхзначный IQ. Для императивного процедурного программирования веб-сайтов на python и js надо быть гуманитарием c IQ 80 и не капать слюной на клавиатуру, следовательно, такие кадры дешевле и их проще заменить баристами с улицы. Какой же из двух подходов будут лоббировать корпораты, интересно?
>>461478
Какую математику нужно знать для ФП? Я слышал, что в Хаскеле используется теория категорий. Но потом оказалось, что категорий, в математическом смысле, там нет.
Какую математику нужно знать для ФП? Я слышал, что в Хаскеле используется теория категорий. Но потом оказалось, что категорий, в математическом смысле, там нет.
>>460219 (OP)
Потому что стек не резиновый.
Потому что стек не резиновый.
>>461478
Смешно сказал. В js гораздо больше функциональщины чем в любой си-подобной калосрани.
Смешно сказал. В js гораздо больше функциональщины чем в любой си-подобной калосрани.
>>460219 (OP)
А Scala потеряла свою популярность? На нее джависты пересаживались.
А Scala потеряла свою популярность? На нее джависты пересаживались.
>>461594
Ну, она как-бы нахуй не нужна. По факту, что скэйла, что другие языки уровня кложи или окамла с эрлангом - у всех у них одна и та же проблема, а именно убогий тулинг, отсутствие стандартов и проверенная годами библиотека фреймворков, либ и прочего мидлвейра. Эрланг и Кложа гремели в середине нулевых как и Скэйла. Был Валкин со своим Эхо где НикиТонский и прочие писали на кложе и эрланге. Потом был бум скэйлы и на нее на хайпе переходили крутить бигдату через спарк или упарываться в котов и зио. У той же скэйлы до сих пор проблемы с IDE, которая краснит код и выжирает любые ресурсы. В JB целая команда в 10 человек уже больше 10 лет пилит плагин, но он бесконечно далек по уровню качества и набору фич если сравнивать с поддержкой котла или жабы.
Эрланг очень ситуативный и местечковый язык программирования, который в основном юзают как клей между модулями на сишке в телекоме. Есть элексир, который работает поверх BEAM и типа эрланг с синтаксисом руби.
Кложа лисп где не завезли норм IDE и библиотек. Вау эффекта не наблюдается.
Окамл за пределами Джейнстрит и еще парочки хфт фирм нигде не юзается.
Хаскел чисто исследовательский язык и писать на нем какой-нибудь энтерпрайз больно. Либо нужно как Зефиров со штангой приседать.
Ну, она как-бы нахуй не нужна. По факту, что скэйла, что другие языки уровня кложи или окамла с эрлангом - у всех у них одна и та же проблема, а именно убогий тулинг, отсутствие стандартов и проверенная годами библиотека фреймворков, либ и прочего мидлвейра. Эрланг и Кложа гремели в середине нулевых как и Скэйла. Был Валкин со своим Эхо где НикиТонский и прочие писали на кложе и эрланге. Потом был бум скэйлы и на нее на хайпе переходили крутить бигдату через спарк или упарываться в котов и зио. У той же скэйлы до сих пор проблемы с IDE, которая краснит код и выжирает любые ресурсы. В JB целая команда в 10 человек уже больше 10 лет пилит плагин, но он бесконечно далек по уровню качества и набору фич если сравнивать с поддержкой котла или жабы.
Эрланг очень ситуативный и местечковый язык программирования, который в основном юзают как клей между модулями на сишке в телекоме. Есть элексир, который работает поверх BEAM и типа эрланг с синтаксисом руби.
Кложа лисп где не завезли норм IDE и библиотек. Вау эффекта не наблюдается.
Окамл за пределами Джейнстрит и еще парочки хфт фирм нигде не юзается.
Хаскел чисто исследовательский язык и писать на нем какой-нибудь энтерпрайз больно. Либо нужно как Зефиров со штангой приседать.
>>460219 (OP)
Потому оно очень далеко от того как работают компуктеры. Процессор не функциональный, процессор императивный, соответственно всё нужно писать в императивном стиле - только тогда ты получаешь адекватно работающую программу.
Как будут функциональные процессоры - так все переедут на функциональные языки.
>>461478
Ничего там сложного нет, если разобраться и надрочиться. Такое же программирование как и любое другое.
Потому оно очень далеко от того как работают компуктеры. Процессор не функциональный, процессор императивный, соответственно всё нужно писать в императивном стиле - только тогда ты получаешь адекватно работающую программу.
Как будут функциональные процессоры - так все переедут на функциональные языки.
>>461478
Ничего там сложного нет, если разобраться и надрочиться. Такое же программирование как и любое другое.
А помните, как функциональные обиженки в 2018 году засирали борду и чаты в телеграме своими высерами-фантазиями про то, как ФП скоро всех победит? И где они все сейчас? Хуесосы, вы на месте?
265 Кб, 768x1024>>460219 (OP)
А оно не провалилось никуда. Им не пользуются просто. А не пользуются им потому что рыночек хочет девевого говна для узколобых долбоебов. Именно поэтому никто на сегодняшний день не получает белый ip, не полнимает собственную почту на своём сервере, и не выкупает домен у регистратора. На сегодняшний день все покупают хостинг у конторы, которая всю работу делает за них, предоставляя удобную панельку plesk с кнопками для управления. Гордый потребитель глубоко не копает и думает что он, стало быть сам создал свой почтовый сервер, хотя сервер был настроен до него компанией-хосттнгом, а он даже почтовые службы не нюхал. Вот такой вот мир. Продажа ненужной хуйни узколобым гоям - это основа так сказать. Кабанчик не хочет знать про искусство программирования и тонкости алгоритмов. Кабанчик хочет чтобы кнопка нажималась, а на каком говне эта кнопка работает он в душе не ебет. Поэтому на рыночке закрепляются типовые решения и готовые алгоритмы. Вот ООП это парадигма которая просто предоставляет один шаблонный подход, для решения большинства задач, вот все и дрочатся с ООП.
>>461536
Глупость. Стек - это особенность компмлятора. К языку это не имеет никакого отношения. Можно написать функциональный язык программирования который вообще бы не использовал стековый фрейм.
Существует ЯП заточенные под рекурсию, в которых на уровне компилятора заведомо придкман обход ситуаций переполнения стека, путём удаления ненужного говна в процессе забивания онного фреймами.
А оно не провалилось никуда. Им не пользуются просто. А не пользуются им потому что рыночек хочет девевого говна для узколобых долбоебов. Именно поэтому никто на сегодняшний день не получает белый ip, не полнимает собственную почту на своём сервере, и не выкупает домен у регистратора. На сегодняшний день все покупают хостинг у конторы, которая всю работу делает за них, предоставляя удобную панельку plesk с кнопками для управления. Гордый потребитель глубоко не копает и думает что он, стало быть сам создал свой почтовый сервер, хотя сервер был настроен до него компанией-хосттнгом, а он даже почтовые службы не нюхал. Вот такой вот мир. Продажа ненужной хуйни узколобым гоям - это основа так сказать. Кабанчик не хочет знать про искусство программирования и тонкости алгоритмов. Кабанчик хочет чтобы кнопка нажималась, а на каком говне эта кнопка работает он в душе не ебет. Поэтому на рыночке закрепляются типовые решения и готовые алгоритмы. Вот ООП это парадигма которая просто предоставляет один шаблонный подход, для решения большинства задач, вот все и дрочатся с ООП.
>>461536
Глупость. Стек - это особенность компмлятора. К языку это не имеет никакого отношения. Можно написать функциональный язык программирования который вообще бы не использовал стековый фрейм.
Существует ЯП заточенные под рекурсию, в которых на уровне компилятора заведомо придкман обход ситуаций переполнения стека, путём удаления ненужного говна в процессе забивания онного фреймами.
>>462014
Не понял. Ты хочешь читать программу с диска, когда стек переполняется?
> вообще бы не использовал стековый фрейм.
> путём удаления ненужного говна в процессе забивания онного фреймами.
Не понял. Ты хочешь читать программу с диска, когда стек переполняется?
>>462014
Просто была пропихнута как универсальная таблетка в нужный момент, не более.
>Вот ООП это парадигма которая...
Просто была пропихнута как универсальная таблетка в нужный момент, не более.
>>462232
ООП с паттернами и аджайлом - очень полезная идея для бизнеса, позволяет кабан кабанычу заменить ЧСВшного ботана на толпу дешевых макак-индусов и периодически выгонять их на мороз по мере выгорания.
А от функционального программирования какая ему польза? Оно наоборот повышает порог входа и потому является вредным. Комунячья зараза.
ООП с паттернами и аджайлом - очень полезная идея для бизнеса, позволяет кабан кабанычу заменить ЧСВшного ботана на толпу дешевых макак-индусов и периодически выгонять их на мороз по мере выгорания.
А от функционального программирования какая ему польза? Оно наоборот повышает порог входа и потому является вредным. Комунячья зараза.
>>461594
Scala была популярна только из-за ML фреймворка Spark. Сейчас все перешли на петухон.
Scala была популярна только из-за ML фреймворка Spark. Сейчас все перешли на петухон.
>>461588
В js совершенно пизданутая функциональщина, которая порождает адский спагетти-говнокод. Возьми исходники любого фреймворка, ты там ни за что не разберёшься что когда и где происходит из-за адского жонглирования функциями и полного отсутствия статических типов. Это яркий пример того, как делать не надо.
По теме: она не провалилась. Её элементы вошли во все основные ЯП на достаточном уровне.
В js совершенно пизданутая функциональщина, которая порождает адский спагетти-говнокод. Возьми исходники любого фреймворка, ты там ни за что не разберёшься что когда и где происходит из-за адского жонглирования функциями и полного отсутствия статических типов. Это яркий пример того, как делать не надо.
По теме: она не провалилась. Её элементы вошли во все основные ЯП на достаточном уровне.
>>462532
Этот прав. Работал на проекте где лид фронтенд команды угорал по хаскелю и искал только кандидатов, которые шарили в фп. С трудом нанял одного чела за год. На следующий год кабан почуял неладное и выгнал долбаеба на мороз. В течении полугода был нанят новый лид и команда из 7 человек и проект выпустили в срок
Этот прав. Работал на проекте где лид фронтенд команды угорал по хаскелю и искал только кандидатов, которые шарили в фп. С трудом нанял одного чела за год. На следующий год кабан почуял неладное и выгнал долбаеба на мороз. В течении полугода был нанят новый лид и команда из 7 человек и проект выпустили в срок
>>462532
Ага, особенно когда надо разобраться в иерархии на пять десятков уровней наследования, потому что макаки не слышали про композицию, и кабаныч начинает терять деньги за простой.
>Оно наоборот повышает порог входа
Ага, особенно когда надо разобраться в иерархии на пять десятков уровней наследования, потому что макаки не слышали про композицию, и кабаныч начинает терять деньги за простой.
>>462688
https://spark.apache.org/mllib/
Заткни свое гнойное ебло, обосранный скуфиндуй. Нахуй ты лезешь, если не шаришь, гандон?
https://spark.apache.org/mllib/
Заткни свое гнойное ебло, обосранный скуфиндуй. Нахуй ты лезешь, если не шаришь, гандон?
>>461594
Да. От скалы сейчас везде стараются избавиться в пользу java/kotlin или сразу пересаживаются на императивный golang.
Почему избавляются? Да потому что оно нахуй не нужно в проде. Функциональщина это юзлесс хуйня для крудописания. Тех же стримов в джаве достаточно чтобы покрыть все кейсы. Или циклы писать (как в Go) во многих случаях будет даже лучшим и более понятным решением.
При этом у скалы очень большие проблемы
- с тулингом (нет нормальной поддержки IDE)
- с обратной совместимостью. При переходе с Scala2 на Scala3 сломали обратную совместимость
И как бы нахуй на таком писать? Это же залупа, вот и все.
>А Scala потеряла свою популярность
Да. От скалы сейчас везде стараются избавиться в пользу java/kotlin или сразу пересаживаются на императивный golang.
Почему избавляются? Да потому что оно нахуй не нужно в проде. Функциональщина это юзлесс хуйня для крудописания. Тех же стримов в джаве достаточно чтобы покрыть все кейсы. Или циклы писать (как в Go) во многих случаях будет даже лучшим и более понятным решением.
При этом у скалы очень большие проблемы
- с тулингом (нет нормальной поддержки IDE)
- с обратной совместимостью. При переходе с Scala2 на Scala3 сломали обратную совместимость
И как бы нахуй на таком писать? Это же залупа, вот и все.
>>462765
Я как раз таки прекрасно знаю, для чего используют спарк. Из первых рук. А вот ты по фразе "со спарка переходят на питон" обосрался и показал нулевое знание в теме. Ещё и мл приплёл.
Ещё раз, не позорься.
Я как раз таки прекрасно знаю, для чего используют спарк. Из первых рук. А вот ты по фразе "со спарка переходят на питон" обосрался и показал нулевое знание в теме. Ещё и мл приплёл.
Ещё раз, не позорься.
>>462774
Тоже проигрываю с дебила.
Тоже проигрываю с дебила.
>>460219 (OP)
Почему провалилось? Фишки оттуда стырили мейнстрим языки.
Почему провалилось? Фишки оттуда стырили мейнстрим языки.
>>460219 (OP)
Оно не провалилось, оно живет в той в нише, для которой предназначено - матан (ДС/МЛ) и всякая ETL хуйня. Именно туда ложится парадигма ФП, в рамках которой у тебя данные в программе перетекают из выхода одной функции на вход другой, не мутируя сторонние вещи и ничего никуда не сохраняя. Собственно, в 50-60-х кодинг и был ПО СУТИ (не по форме) своей чисто функциональным.
А в рамках разработки программ, которыми пользуются реальные люди, быстро выяснилось, что у тебя есть всегда есть какие-то сайдэффекты, надо че-то промежуточно где-то сохранить (сторы с объектами появляются), че-то надо отрисовать на экран (сайдэффект), че-то сохраненное надо изменить в зависимости от пользовательского ввода и т.д. И для этого фп уже подходит не очень, точнее не подходит совсем.
Просто до плюсов народ не понимал, что данные и методы для работы с ними удобнее хранить в одном месте, а когда поняли, тут-то фп в рамках коммерческих программ окончательно и загнулось.
>Почему функциональное программирование провалилось?
Оно не провалилось, оно живет в той в нише, для которой предназначено - матан (ДС/МЛ) и всякая ETL хуйня. Именно туда ложится парадигма ФП, в рамках которой у тебя данные в программе перетекают из выхода одной функции на вход другой, не мутируя сторонние вещи и ничего никуда не сохраняя. Собственно, в 50-60-х кодинг и был ПО СУТИ (не по форме) своей чисто функциональным.
А в рамках разработки программ, которыми пользуются реальные люди, быстро выяснилось, что у тебя есть всегда есть какие-то сайдэффекты, надо че-то промежуточно где-то сохранить (сторы с объектами появляются), че-то надо отрисовать на экран (сайдэффект), че-то сохраненное надо изменить в зависимости от пользовательского ввода и т.д. И для этого фп уже подходит не очень, точнее не подходит совсем.
Просто до плюсов народ не понимал, что данные и методы для работы с ними удобнее хранить в одном месте, а когда поняли, тут-то фп в рамках коммерческих программ окончательно и загнулось.
>>463121
Нет, это неудобно. С этим проблем больше возникает чем плюсов.
> данные и методы для работы с ними удобнее хранить в одном месте
Нет, это неудобно. С этим проблем больше возникает чем плюсов.
>>463121
А потом как вдруг понял, теперь мы все и ебёмся с разделением состояния и логики.
>народ не понимал, что данные и методы для работы с ними удобнее хранить в одном месте
А потом как вдруг понял, теперь мы все и ебёмся с разделением состояния и логики.
>>463179
Если бы это было неудобно, такие языки как C++, Java, C#, Python, Ruby просто не появились бы. А такие PHP не двигались бы в сторону Java.
>>463237
Ожидаю предложений, как ты собираешься реализовать в рамках строгого ФП элементарный UI.
>Нет, это неудобно. С этим проблем больше возникает чем плюсов.
Если бы это было неудобно, такие языки как C++, Java, C#, Python, Ruby просто не появились бы. А такие PHP не двигались бы в сторону Java.
>>463237
>А потом как вдруг понял, теперь мы все и ебёмся с разделением состояния и логики.
Ожидаю предложений, как ты собираешься реализовать в рамках строгого ФП элементарный UI.
>>463253
Появление языков не означает удобство парадигмы, особенно с течением времени и изменением решаемых задач.
>такие языки как C++, Java, C#, Python, Ruby просто не появились бы
Появление языков не означает удобство парадигмы, особенно с течением времени и изменением решаемых задач.
>>460219 (OP)
Потому что ФП требует хорошей способности в абстрагирование. А дальше все утыкается в прокачанность и обученность кадров в построение абстракций. Обычно с этим скиллом все хорошо у математиков, либо просто у технарей со склонностью к математике, поэтому тот же хаскель, к примеру, очень хорошо прижился в научной тусовке.
В среднем же по больнице этот скилл у вкатунишек развит плохо, к сожалению. Поэтому бизнес делает ставку на гуманитариев, вооруженных паттернами-хуятернами, магическими аннотахами и прочим KISS-DRY-мистицизмом, а функциональные фишки внедряются медленно, ситуативно, но неизбежно.
Потому что ФП требует хорошей способности в абстрагирование. А дальше все утыкается в прокачанность и обученность кадров в построение абстракций. Обычно с этим скиллом все хорошо у математиков, либо просто у технарей со склонностью к математике, поэтому тот же хаскель, к примеру, очень хорошо прижился в научной тусовке.
В среднем же по больнице этот скилл у вкатунишек развит плохо, к сожалению. Поэтому бизнес делает ставку на гуманитариев, вооруженных паттернами-хуятернами, магическими аннотахами и прочим KISS-DRY-мистицизмом, а функциональные фишки внедряются медленно, ситуативно, но неизбежно.
>>461698
Так это то как раз достоинство ФП и прочих декларативных подходов. Если бы это было проблемой, мы бы все до сих пор на ассемблерах писали. Вместо этого мейнстримные языки программирования становятся все более и более высокоуровневыми. А все потому, что ни один нормальный человек (профдеформированных кодеров за норму не берем) на самом деле не мыслит императивно, в терминах инструкций проца над мутабельной памятью. Все нормальные люди мыслят декларативно, и буквально ни для кого эта низкоуровневая байтодрочь не представляет ценности на самом деле.
>Потому оно очень далеко от того как работают компуктеры.
Так это то как раз достоинство ФП и прочих декларативных подходов. Если бы это было проблемой, мы бы все до сих пор на ассемблерах писали. Вместо этого мейнстримные языки программирования становятся все более и более высокоуровневыми. А все потому, что ни один нормальный человек (профдеформированных кодеров за норму не берем) на самом деле не мыслит императивно, в терминах инструкций проца над мутабельной памятью. Все нормальные люди мыслят декларативно, и буквально ни для кого эта низкоуровневая байтодрочь не представляет ценности на самом деле.
>>463865
Где? Любая статья или иная научная работа по математике последние лет 8 если содержит программу, то она(программа) или на python, или на c++(обычно в таких случаях используются буквально древние библиотеки, написанные 20+ лет назад, писали которые чуть ли не атланты математической мысли).
Где? Любая статья или иная научная работа по математике последние лет 8 если содержит программу, то она(программа) или на python, или на c++(обычно в таких случаях используются буквально древние библиотеки, написанные 20+ лет назад, писали которые чуть ли не атланты математической мысли).
Покажите хотя бы один серьезный проект на haskell.
Функциональное программирование в целом штука весьма специфичная. И беда ФП не столько в мозгах преобладающей массы разработчиков, сколько в том, что алгоритм предполагает задание последовательности шагов, а ФП - это про задание правил преобразования выражений и последующую формулировку выражения, которую потом соответствующая система(будь то интерпретатор или железо) решает по заданным правилам.
Вот, есть те же формулы в excel. Чем не ФП? То же задание переменных(в ячейках) и правил вычисления(когда в ячейке пишут "=формула чего-то там". И все, кто работает более-менее серьезно с excel, таким занимаются.
ФП хорош как теоретическое изыскание и как штука для очень редких случаев, но все то же процедурное/ООП будет лучше.
Функциональное программирование в целом штука весьма специфичная. И беда ФП не столько в мозгах преобладающей массы разработчиков, сколько в том, что алгоритм предполагает задание последовательности шагов, а ФП - это про задание правил преобразования выражений и последующую формулировку выражения, которую потом соответствующая система(будь то интерпретатор или железо) решает по заданным правилам.
Вот, есть те же формулы в excel. Чем не ФП? То же задание переменных(в ячейках) и правил вычисления(когда в ячейке пишут "=формула чего-то там". И все, кто работает более-менее серьезно с excel, таким занимаются.
ФП хорош как теоретическое изыскание и как штука для очень редких случаев, но все то же процедурное/ООП будет лучше.
Мне кажется говорить что ФП провалилось это как если бы пуристы ООП говорили что оно провалилось потому что везде кроме Smalltalk есть лишь перенятые практики парадигмы но не она в чистом виде. Для рядового разраба вроде меня если есть анонимки и замыкания то это уже достаточно ФП, если есть классы то это уже достаточно ООП
>>463888
Блин, вот интересный ты анон. Приводишь в пример максимально успешный эксель как пример декларативного решения вычислительных задач, но тем не менее делаешь вывод, что императиващина - лучше, лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
Ну да, щас. А параллельные алгоритмы для тебя - шутка чтоли?
С параллелизмом от этой твоей последовательности вообще остались рожки да ножки в лице гарантий мемори моделей. А на уровнях ниже там одни приколы с публикациями, перестановками и кэшами. Давно уже императивность натянута совой на глобус. В ФП кстати параллелизм на порядки проще и интуитивней для понимания.
Блин, вот интересный ты анон. Приводишь в пример максимально успешный эксель как пример декларативного решения вычислительных задач, но тем не менее делаешь вывод, что императиващина - лучше, лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
>алгоритм предполагает задание последовательности шагов
Ну да, щас. А параллельные алгоритмы для тебя - шутка чтоли?
С параллелизмом от этой твоей последовательности вообще остались рожки да ножки в лице гарантий мемори моделей. А на уровнях ниже там одни приколы с публикациями, перестановками и кэшами. Давно уже императивность натянута совой на глобус. В ФП кстати параллелизм на порядки проще и интуитивней для понимания.
>>463893
На самом деле ты прав. Нет вообще никакого смысла холиварить за ООП vs ФП - по факту все давным давно уже кодят на смешанной парадигме.
На самом деле ты прав. Нет вообще никакого смысла холиварить за ООП vs ФП - по факту все давным давно уже кодят на смешанной парадигме.
>>462583
Проеб этого лида был лишь в том, что он сам не владел теми принципами, по которым угорал, в должной мере. Иначе бы он в одну харю закрыл проект в срок (видал такие контрпримеры воочию).
Проеб этого лида был лишь в том, что он сам не владел теми принципами, по которым угорал, в должной мере. Иначе бы он в одну харю закрыл проект в срок (видал такие контрпримеры воочию).
>>462532
Meh. Кабаны обычно в вопросах поддержки кода сами за деревьями леса не видят. Дюже потешно до поры до времени наблюдять за руиной целых отделов разработки, когда те утопают в техдолге, а кабаны пытаются эти проблемы решать чисто кабаньими методами: то раздувают штат, то наоборот сократят нахуй, а воз и ныне там...
Жаль, что в итоге из-за этого негативного опыта им оказывается проще просто не связываться никогда больше с in-house разработкой, и они в большинстве своем просто отдают ее на аутсорц унылым заебанным рабам. Мы проебали все полимеры.
Meh. Кабаны обычно в вопросах поддержки кода сами за деревьями леса не видят. Дюже потешно до поры до времени наблюдять за руиной целых отделов разработки, когда те утопают в техдолге, а кабаны пытаются эти проблемы решать чисто кабаньими методами: то раздувают штат, то наоборот сократят нахуй, а воз и ныне там...
Жаль, что в итоге из-за этого негативного опыта им оказывается проще просто не связываться никогда больше с in-house разработкой, и они в большинстве своем просто отдают ее на аутсорц унылым заебанным рабам. Мы проебали все полимеры.
>>463901
Такого вывода мною сделано не было
Это тоже задание последовательности действий. Другое дело, что эти действия происходят параллельно другим действиям.
Нне спорю.
>лучше, лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
Такого вывода мною сделано не было
> А параллельные алгоритмы для тебя - шутка чтоли?
Это тоже задание последовательности действий. Другое дело, что эти действия происходят параллельно другим действиям.
>В ФП кстати параллелизм на порядки проще и интуитивней для понимания
Нне спорю.
>>463901
Ранее мною было написано, что такого утверждения мною не делалось.
Мною была лишь написана просьба показать пример серьезно проекта на haskell.
>лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
Ранее мною было написано, что такого утверждения мною не делалось.
Мною была лишь написана просьба показать пример серьезно проекта на haskell.
>>463956
Ты мягко говоря преувеличиваешь, утвердждая что это - то же самое. Все таки параллелизм и многоядерные процы серьезно перекроили разработку и проектирование в свое время.
Кроме того, задание последовательности между двумя кусками ленивых вычислений было в том же хаскеле из коробки буквально все время его существования в лице монады IO, в то время как в джаве и позже в плюсах пришлось городить нетривиальные в изучении мемори модели, чтобы привычная коболистам тех времен императивщина поверх глобального состояния не множила на ноль оптимизации. Что характерно, моделями памяти все не ограничилось, и мейнстримные языки обрастают абстракциями разной степени кривизны и по сей день, при этом все как одна заимствованы из ФП.
Так что еще хз кто из этих двоих был более специфичен на тот момент.
>Это тоже задание последовательности действий.
Ты мягко говоря преувеличиваешь, утвердждая что это - то же самое. Все таки параллелизм и многоядерные процы серьезно перекроили разработку и проектирование в свое время.
Кроме того, задание последовательности между двумя кусками ленивых вычислений было в том же хаскеле из коробки буквально все время его существования в лице монады IO, в то время как в джаве и позже в плюсах пришлось городить нетривиальные в изучении мемори модели, чтобы привычная коболистам тех времен императивщина поверх глобального состояния не множила на ноль оптимизации. Что характерно, моделями памяти все не ограничилось, и мейнстримные языки обрастают абстракциями разной степени кривизны и по сей день, при этом все как одна заимствованы из ФП.
Так что еще хз кто из этих двоих был более специфичен на тот момент.
>>463969
В любом случае параллелищм не противоречит изначальному утверждению о последовательности действий.
Хоть многоядерность, хоть многопточность, хоть многозадачность... - все это упирается в наличие последовательности действий.
В любом случае параллелищм не противоречит изначальному утверждению о последовательности действий.
Хоть многоядерность, хоть многопточность, хоть многозадачность... - все это упирается в наличие последовательности действий.
>>463969
А это тут каким боком? Про ленивые вычисления и слова не было.
Поверх чего там работает функциональный язык? Поверх интерпретатора или железа. Но и то, и другое подразумевают последовательность действий. И, по сути, как ранее было мною написано ранее, все ФП просто приводится к обработке выражения/строки по заданным правилам(те самые функции и прочее).
>Кроме того, задание последовательности между двумя кусками ленивых вычислений
А это тут каким боком? Про ленивые вычисления и слова не было.
>в то время как в джаве и позже в плюсах пришлось городить нетривиальные
Поверх чего там работает функциональный язык? Поверх интерпретатора или железа. Но и то, и другое подразумевают последовательность действий. И, по сути, как ранее было мною написано ранее, все ФП просто приводится к обработке выражения/строки по заданным правилам(те самые функции и прочее).
Провал ФП - знаковое событие, недвусмысленно намекающее на будущее (а теперь уже и настоящее) IT индустрии.
Программистишки сами виноваты, что оказались терпилами и еще в 90-х прогнулись под ООП, паттерны, аджайл и недоязыки вроде петухона.
Нерды вроде Линуса Торвальдса или Джона Кармака кабан кабанычам больше не нужны.
Программистишки сами виноваты, что оказались терпилами и еще в 90-х прогнулись под ООП, паттерны, аджайл и недоязыки вроде петухона.
Нерды вроде Линуса Торвальдса или Джона Кармака кабан кабанычам больше не нужны.
>>463983
>>463986
И хули толку то, что все упирается в последовательность? Ты давно уже даже на мейнстримных языках эту последовательность на самом деле не пишешь и не видишь - после многопоточки что компиляторы, что виртуальные машины обросли таким слоем оптимизаций, что императивный код который ты пишешь на условной джаве или питоне, с реальными машинными инструкциями и их порядком на железе не будет коррелировать от слова никак. Если тебе и оптимизаций мало, прибавь к этой картине фреймворки.
Буквально никому не всралась твоя последовательность уже сегодня. В гробу ее все видели и похоронили 30 раз за тысячью слоев абстракций...
И какой смысл тогда продолжать натягивать эту сову на глобус? ФП от современной императивки отличается лишь тем, что оно по высокоуровневости разработки просто зашло еще дальше, со всеми вытекающими и подводными. Вот и вся разница.
Я просто отметил, что в функциональной парадигме никогда не было проблемы запилить цепочку последовательности там, где она уместна (а где не уместна, не пилить ее). Отрицальщики часто любят приписывать функциональной парадигме какие то рандомные фейковые грехи, типа что с ней хуево там, где стейт и сайдэффекты, мол, или что на функциональных языках, типа, последовательные алгоритмы тяжело лабать... Хуета все это, вранье от незнания. Все там всю дорогу было.
>>463986
И хули толку то, что все упирается в последовательность? Ты давно уже даже на мейнстримных языках эту последовательность на самом деле не пишешь и не видишь - после многопоточки что компиляторы, что виртуальные машины обросли таким слоем оптимизаций, что императивный код который ты пишешь на условной джаве или питоне, с реальными машинными инструкциями и их порядком на железе не будет коррелировать от слова никак. Если тебе и оптимизаций мало, прибавь к этой картине фреймворки.
Буквально никому не всралась твоя последовательность уже сегодня. В гробу ее все видели и похоронили 30 раз за тысячью слоев абстракций...
И какой смысл тогда продолжать натягивать эту сову на глобус? ФП от современной императивки отличается лишь тем, что оно по высокоуровневости разработки просто зашло еще дальше, со всеми вытекающими и подводными. Вот и вся разница.
>А это тут каким боком? Про ленивые вычисления и слова не было.
Я просто отметил, что в функциональной парадигме никогда не было проблемы запилить цепочку последовательности там, где она уместна (а где не уместна, не пилить ее). Отрицальщики часто любят приписывать функциональной парадигме какие то рандомные фейковые грехи, типа что с ней хуево там, где стейт и сайдэффекты, мол, или что на функциональных языках, типа, последовательные алгоритмы тяжело лабать... Хуета все это, вранье от незнания. Все там всю дорогу было.
>>464188
Наврядли. Функциональную парадигму языковые модели пережевали бы еще жосче, скорее всего.
Вообще, я бы поверил в перспективы вайбкодинга на условном хаскелле гораздо охотней, чем в высеры кое как типизированных скриптосеров.
Наврядли. Функциональную парадигму языковые модели пережевали бы еще жосче, скорее всего.
Вообще, я бы поверил в перспективы вайбкодинга на условном хаскелле гораздо охотней, чем в высеры кое как типизированных скриптосеров.
>>464197
Чатгопота идеально заменяет программистишек там, где от них требуется копипаста со StackOverflow и тупое обезьянничанье по паттернам (вся эта зубрежка на собесах про "уровни изоляций транзакций" и "типы бинов в Spring") без понимания как это работает. А началось все с "инкапсуляции" в ООП - я тупой дебил, не знаю, что там в черном ящике, но умею дергать нужные методы.
Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область. Программист был и тимлидом, и аналитиком, и кодером одновременно. Заменить такого мог бы только сильный ИИ, которого в обозримом будущем не предвидится. Там, где можно было генерить какие-то простые скрипты на Лиспе, это уже делалось.
Чатгопота идеально заменяет программистишек там, где от них требуется копипаста со StackOverflow и тупое обезьянничанье по паттернам (вся эта зубрежка на собесах про "уровни изоляций транзакций" и "типы бинов в Spring") без понимания как это работает. А началось все с "инкапсуляции" в ООП - я тупой дебил, не знаю, что там в черном ящике, но умею дергать нужные методы.
Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область. Программист был и тимлидом, и аналитиком, и кодером одновременно. Заменить такого мог бы только сильный ИИ, которого в обозримом будущем не предвидится. Там, где можно было генерить какие-то простые скрипты на Лиспе, это уже делалось.
>>464213
Ой, да полно тебе бухтеть на ровном месте. ФПшка по высокоуровневости абстракции еще фору ООПшке даст так то.
Кто ему нынче даст эту подготовку, камон? Системы массового образования большинства "цивилизованных" стран давным давно заруинены в пользу подготовки рабов для корпоратов, а корпоратам в свою очередь нахуй не всрались кадры, которые ты хуй заменишь. Каждое новое поколение тупее предыдущих. И из всей этой шкурной кодлы гондонов на капиталах, готовящей прямо сейчас всех нас в лучшем случае к скотскому BLM-LGBT существованию без цели, в худшем - к тотальному пиздорезу и утилизации буквально ради замены на ничтожеств без достоинства, вооруженных нейронками, которые при всей их тупости уже умнее этих ничтожеств, ты предьявляешь предьявы морально забитым под шконку промытым кодеркам?
Ты хоть с какого года сам то кодишь, чтобы такие громкие предьявы кидать?
>А началось все с "инкапсуляции" в ООП - я тупой дебил, не знаю, что там в черном ящике, но умею дергать нужные методы.
Ой, да полно тебе бухтеть на ровном месте. ФПшка по высокоуровневости абстракции еще фору ООПшке даст так то.
>Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область
Кто ему нынче даст эту подготовку, камон? Системы массового образования большинства "цивилизованных" стран давным давно заруинены в пользу подготовки рабов для корпоратов, а корпоратам в свою очередь нахуй не всрались кадры, которые ты хуй заменишь. Каждое новое поколение тупее предыдущих. И из всей этой шкурной кодлы гондонов на капиталах, готовящей прямо сейчас всех нас в лучшем случае к скотскому BLM-LGBT существованию без цели, в худшем - к тотальному пиздорезу и утилизации буквально ради замены на ничтожеств без достоинства, вооруженных нейронками, которые при всей их тупости уже умнее этих ничтожеств, ты предьявляешь предьявы морально забитым под шконку промытым кодеркам?
Ты хоть с какого года сам то кодишь, чтобы такие громкие предьявы кидать?
>>464195
И поэтому ты продолжаешь доказывать обратное.
Вижу и пишу:
A a(аргументы для конструктора);
a.имяМетода();
Про какую-либо разницу речи вообще не шло. Ты просто наращиваешь объем текста. Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле), но ты умудрился заглянуть во все места, кроме тех, куда заглянуть надо.
В целом я тебя понял. Дальше отвечать не буду.
>Буквально никому не всралась твоя последовательность уже сегодня
И поэтому ты продолжаешь доказывать обратное.
>давно уже даже на мейнстримных языках эту последовательность на самом деле не пишешь и не видишь
Вижу и пишу:
A a(аргументы для конструктора);
a.имяМетода();
>ФП от современной императивки отличается лишь тем, что оно по высокоуровневости разработки просто зашло еще дальше, со всеми вытекающими и подводными.
Про какую-либо разницу речи вообще не шло. Ты просто наращиваешь объем текста. Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле), но ты умудрился заглянуть во все места, кроме тех, куда заглянуть надо.
В целом я тебя понял. Дальше отвечать не буду.
>>464213
Возможно, такое было лет 30+ назад, но сейчас все намного проще стало. Да и надо ли веб-программисту знать про алгоритмы сжатия, про циклические многочлены или про теоремы из теории графов?
>Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область.
Возможно, такое было лет 30+ назад, но сейчас все намного проще стало. Да и надо ли веб-программисту знать про алгоритмы сжатия, про циклические многочлены или про теоремы из теории графов?
>>464217
Тема очень обширная и фундаментальная. В прикладной области сей анон ближе всего подошел к сути – корпорастам до пизды, на чём писать, если писать на этом могут одноклеточные макаки. Ни сложные императивные, ни сложные функциональные, ни тем более сраное ООП в виде smalltalk им не нужно. Им нужно хуяк-хуяк – и в продакшен.
Я заявляю, что западная экономика обеспечила уверенное отставание айти где-то лет на 20. Вот сейчас всё айти работает на алгоритмах-инструментах начала нулевых.
Кроме нейросетей, нейросети перепутали карты. Они всё равно говно, но в отсталой западной академической среде их не должно было возникнуть, коммерсы бы просто продолжали впаривать друг другу прокисшее говно.
Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина? Пока вы спорите о сортах говна – рандомные челы, имён которых здесь даже никто не знает, создают что-то вообше не похожее на старое.
Хотя, наверное, decoder-only transformer ближе к рекурентной функции.
Мимо анон со стэком из delphi, js, python, c/c++, haskell.
>Системы массового образования большинства "цивилизованных" стран давным давно заруинены в пользу подготовки рабов для корпоратов
Тема очень обширная и фундаментальная. В прикладной области сей анон ближе всего подошел к сути – корпорастам до пизды, на чём писать, если писать на этом могут одноклеточные макаки. Ни сложные императивные, ни сложные функциональные, ни тем более сраное ООП в виде smalltalk им не нужно. Им нужно хуяк-хуяк – и в продакшен.
Я заявляю, что западная экономика обеспечила уверенное отставание айти где-то лет на 20. Вот сейчас всё айти работает на алгоритмах-инструментах начала нулевых.
Кроме нейросетей, нейросети перепутали карты. Они всё равно говно, но в отсталой западной академической среде их не должно было возникнуть, коммерсы бы просто продолжали впаривать друг другу прокисшее говно.
Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина? Пока вы спорите о сортах говна – рандомные челы, имён которых здесь даже никто не знает, создают что-то вообше не похожее на старое.
Хотя, наверное, decoder-only transformer ближе к рекурентной функции.
Мимо анон со стэком из delphi, js, python, c/c++, haskell.
писал пару раз на хаскеле, мл, окамле, лиспе, они разные, но когда на них пишешь какой-то другой уровень абстракции ощущается почему-то, мб от недостатка опыта в программировании в целом, но совсем не те мысли, что при использовании ц,цпп даже раста и атс2. ещё там можно было можно очень быстро и удобно писать многие вещи с минимум кода. терминологию не помню, вроде комбинаторы, хайер кайндед полиморфизм, лифтинг.
поэтому мне показалось, что код на фп языках проще изменять и переиспользовать. конечно, во многих языках есть фичи из фп, но не на том уровне, что в самом фп.
ооп реальное вроде джавы и сишарпа не юзал не было нужды. даже не знаю какие у них юзкейсы, сишарп наверное что-то с виндой и юнити, а джава для майнкрафта? на фп юзкейсы нашлись, на них оказалось удобно писать парсеры, только поэтому их и стал копать.
поэтому мне показалось, что код на фп языках проще изменять и переиспользовать. конечно, во многих языках есть фичи из фп, но не на том уровне, что в самом фп.
ооп реальное вроде джавы и сишарпа не юзал не было нужды. даже не знаю какие у них юзкейсы, сишарп наверное что-то с виндой и юнити, а джава для майнкрафта? на фп юзкейсы нашлись, на них оказалось удобно писать парсеры, только поэтому их и стал копать.
>>460219 (OP)
Потому что ФП это программирование ради программирования. Эстетическая дрочка математиков, у которых мир построен на функциях. А пк устроен по другому, программирование нужно для создания продукта. Продукт ключевая цель, а не код. Ну и сам процессор устроен под процедурное программирование (кстати неопытные думают, что процедурное программирование есть ФП, мол там же функции только. Но ФП это совсем другое, там даже состояний нет, что уже звучит как абсурд для реального мира).
Потому что ФП это программирование ради программирования. Эстетическая дрочка математиков, у которых мир построен на функциях. А пк устроен по другому, программирование нужно для создания продукта. Продукт ключевая цель, а не код. Ну и сам процессор устроен под процедурное программирование (кстати неопытные думают, что процедурное программирование есть ФП, мол там же функции только. Но ФП это совсем другое, там даже состояний нет, что уже звучит как абсурд для реального мира).
>>464231
Это буквально ни то, ни другое. Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд и легализованная коллективная некомпетентность. Считать это недоразумение развитием методов разработки ПО попросту нелепо. Скорее уж это погибель. Как айтишки, так и здравого смысла вообще.
>Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина?
Это буквально ни то, ни другое. Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд и легализованная коллективная некомпетентность. Считать это недоразумение развитием методов разработки ПО попросту нелепо. Скорее уж это погибель. Как айтишки, так и здравого смысла вообще.
>>464345
Выше уже обсудили это. Нихуяшеньки это не причина, и вот вообще ни разу не проблема.
Чушь. Работа с состоянием в ФП - вообще не проблема, все инструменты для этого в парадигме имеются. Обычно про ФП без состояний говорят новички, которые прочитали первые несколько глав какого нибудь "learn you a haskell for greater good", преисполнились чистотой, промылись и идут евангелизировать в команды: как грится, когда в руке молоток - все кажется гвоздем. Так и сложился стереотип. А тема ФП тем временем гораждо глубже.
>Ну и сам процессор устроен под процедурное программирование
Выше уже обсудили это. Нихуяшеньки это не причина, и вот вообще ни разу не проблема.
>Но ФП это совсем другое, там даже состояний нет
Чушь. Работа с состоянием в ФП - вообще не проблема, все инструменты для этого в парадигме имеются. Обычно про ФП без состояний говорят новички, которые прочитали первые несколько глав какого нибудь "learn you a haskell for greater good", преисполнились чистотой, промылись и идут евангелизировать в команды: как грится, когда в руке молоток - все кажется гвоздем. Так и сложился стереотип. А тема ФП тем временем гораждо глубже.
>>464345
Ой, этот холивар, кстати, еще старее тебя самого будет.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>Эстетическая дрочка математиков, у которых мир построен на функциях
Ой, этот холивар, кстати, еще старее тебя самого будет.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>>464223
Это буквально самый ничтожный из твоих тезисов. Литералли "сперва добейся". Нахуя это комментировать, я не особо понимаю.
Ты всю дорогу начиная отсюда >>463888 почему то гнешь линию, что это проблема парадигмы в том, что проектов на ней мало. Типа - весьма специфичная она. Что на самом деле полная чушь. На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты, и школа ФП-разработки так и не популяризовалась. Вот и все. Императивщиков и функциональщиков учат слишком по разному. А коболистам прошлого (императивщикам по своей сути) оказалось просто западло переучиваться с нуля - ООП стал их выбором лишь потому, что на ООП оказалось проще переложить привычное им процедурное программирование. В итоге так и повелось, что от аланкеевского ООП остались рожки да ножки, а классы в современном ООП по факту выродились тупо в сборники процедур (сервисы) либо кортежи данных (стурктуры). Прав тот анон выше (>>464231), что отметил про отсталость айтишки. Только я бы оценил это отставание не в 20 лет, а лет в 40.
>Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле)
Это буквально самый ничтожный из твоих тезисов. Литералли "сперва добейся". Нахуя это комментировать, я не особо понимаю.
Ты всю дорогу начиная отсюда >>463888 почему то гнешь линию, что это проблема парадигмы в том, что проектов на ней мало. Типа - весьма специфичная она. Что на самом деле полная чушь. На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты, и школа ФП-разработки так и не популяризовалась. Вот и все. Императивщиков и функциональщиков учат слишком по разному. А коболистам прошлого (императивщикам по своей сути) оказалось просто западло переучиваться с нуля - ООП стал их выбором лишь потому, что на ООП оказалось проще переложить привычное им процедурное программирование. В итоге так и повелось, что от аланкеевского ООП остались рожки да ножки, а классы в современном ООП по факту выродились тупо в сборники процедур (сервисы) либо кортежи данных (стурктуры). Прав тот анон выше (>>464231), что отметил про отсталость айтишки. Только я бы оценил это отставание не в 20 лет, а лет в 40.
>>464213
да, гладкие многообразия, векторные расслоения и пучки очень нужны программистам.
Программистам даже калькулюс и 80% линейной алгебры не нужно вообще. Какая серьезная мат подготовка?
>требовалась серьезная математическая подготовка
да, гладкие многообразия, векторные расслоения и пучки очень нужны программистам.
Программистам даже калькулюс и 80% линейной алгебры не нужно вообще. Какая серьезная мат подготовка?
>>464653
Он не придумал ООП, если что. ООП ещё в Симуле было, до Смолтолка. И не в том виде, в котором фантазировал первый.
>В итоге так и повелось, что от аланкеевского ООП
Он не придумал ООП, если что. ООП ещё в Симуле было, до Смолтолка. И не в том виде, в котором фантазировал первый.
>>464226
Надо, когда он начнёт писать свои костыли. А он ведь начнёт...
>надо ли веб-программисту знать про алгоритмы сжатия, про циклические многочлены или про теоремы из теории графов?
Надо, когда он начнёт писать свои костыли. А он ведь начнёт...
>>464552
ТЫ ЧО, ПЕТУХ?!?!?! АЙТИ ФСЁ, ПРОГРАММУНЫ НЕ НУЖНЫ, ВИДЕЛ СОКРАЩЕНИЯ????? ЩА АИШКА КОДУНОВ ЗАМЕНИТ, БУДУ НА ВАЙБКОДИНГЕ ГТА6 ПИСАТЬ, МИРОМ УПРАВЛЯТЬ!!!111ЁЁЁЁЁ
>Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд
ТЫ ЧО, ПЕТУХ?!?!?! АЙТИ ФСЁ, ПРОГРАММУНЫ НЕ НУЖНЫ, ВИДЕЛ СОКРАЩЕНИЯ????? ЩА АИШКА КОДУНОВ ЗАМЕНИТ, БУДУ НА ВАЙБКОДИНГЕ ГТА6 ПИСАТЬ, МИРОМ УПРАВЛЯТЬ!!!111ЁЁЁЁЁ
>>464943
Большинство современных веб-пронраммистов будут тупо до последнего просить нейроку сделать нужное. А потом таких просто выкинут.
Большинство современных веб-пронраммистов будут тупо до последнего просить нейроку сделать нужное. А потом таких просто выкинут.
518 Кб, 720x720>>464653
Ага, карты легли так, что ФП безумно далёк от оборудования и требуется проебать кэш процессора будто его никто и не изобретал.
Не получилось, карты легли неправильно, просто не повезло. Разве у этого могут быть реальные причины?
> На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты,
Ага, карты легли так, что ФП безумно далёк от оборудования и требуется проебать кэш процессора будто его никто и не изобретал.
Не получилось, карты легли неправильно, просто не повезло. Разве у этого могут быть реальные причины?
>>465610
Ой, да кто бы говорил... Лицемер. Про кэш он вспомнил, смотрите на него...
Ты об этом кэше так же ни разу не вспоминаешь, кодя на каком нибудь питоне или джаве, и миссишь его при каждой оказии. И ничего - не сдох.
Ой, да кто бы говорил... Лицемер. Про кэш он вспомнил, смотрите на него...
Ты об этом кэше так же ни разу не вспоминаешь, кодя на каком нибудь питоне или джаве, и миссишь его при каждой оказии. И ничего - не сдох.
>>465707
И в жабе, и в питоне есть куча библиотек для работы с плотными массивами. Можно даже в строки захуячить данные и делать итерацию по строкам и это будет работать с кэшем. В ФП работать адекватно с кэшем принципиально невозможно, парадигма такая.
Пока не будет создан процессор который данные и код хранит в одной и той же ячейке как в мозге человека - ФП бесполезно. Но чет я не уверен что это будет эффективнее современной архитектуры с кэшем - расстояние между ALU и кэшем меньше чем в маняфантастичном ФП-процессоре.
> А ВОТ У ВАС!11
И в жабе, и в питоне есть куча библиотек для работы с плотными массивами. Можно даже в строки захуячить данные и делать итерацию по строкам и это будет работать с кэшем. В ФП работать адекватно с кэшем принципиально невозможно, парадигма такая.
Пока не будет создан процессор который данные и код хранит в одной и той же ячейке как в мозге человека - ФП бесполезно. Но чет я не уверен что это будет эффективнее современной архитектуры с кэшем - расстояние между ALU и кэшем меньше чем в маняфантастичном ФП-процессоре.
>>465835
Ты скозал?
Потешный ты лицемеришко конечно. Как же ты любишь говорить за других инженеров - что им проще, и что им невозможно.
Нет вообще никакой проблемы сгенерить императивную цепочку вычислений по декларативному коду, мань. Всю дорогу все так делали. Если ты так предвзят в отношении ФПшки, что не способен это осознать, можешь рассмотреть феномен SQL, который сам по своей сути максимально декларативный, и по которому СУБДшки вполне себе успешно строят императивные планы выполнения. Твои современные уютные языки программирования в этом плане - такая же высокоуровневая надстройка, так же далекая от реального железа с его особенностями и кешами. Разницы - буквально никакой.
>В ФП работать адекватно с кэшем принципиально невозможно, парадигма такая.
Ты скозал?
Потешный ты лицемеришко конечно. Как же ты любишь говорить за других инженеров - что им проще, и что им невозможно.
>Пока не будет создан процессор который данные и код хранит в одной и той же ячейке
Нет вообще никакой проблемы сгенерить императивную цепочку вычислений по декларативному коду, мань. Всю дорогу все так делали. Если ты так предвзят в отношении ФПшки, что не способен это осознать, можешь рассмотреть феномен SQL, который сам по своей сути максимально декларативный, и по которому СУБДшки вполне себе успешно строят императивные планы выполнения. Твои современные уютные языки программирования в этом плане - такая же высокоуровневая надстройка, так же далекая от реального железа с его особенностями и кешами. Разницы - буквально никакой.
>>465862
Да, я. Оспаривай.
Какие инженеры, отсталый? Что ты несешь? Парадигма запрещает сайдэффекты, а работа через с внешним массивом данных это один здоровенный, глобальный, сайдэффект.
Можешь на что угодно раскладывать, но работать с кэшем команд и с кэшем данных ты не сможешь, а значит идёшь нахуй.
Кал для дегенератов-менеджеров, был придумал таким, был создан таким, получилось ущербное говно от которого все избавляются.
Если ты тупоголовый кретин который не осилил базу работы компуктеров и хранения данных - безусловно.
> Ты скозал?
Да, я. Оспаривай.
> Потешный ты лицемеришко конечно. Как же ты любишь говорить за других инженеров - что им проще, и что им невозможно.
Какие инженеры, отсталый? Что ты несешь? Парадигма запрещает сайдэффекты, а работа через с внешним массивом данных это один здоровенный, глобальный, сайдэффект.
> Нет вообще никакой проблемы сгенерить императивную цепочку вычислений по декларативному коду, мань.
Можешь на что угодно раскладывать, но работать с кэшем команд и с кэшем данных ты не сможешь, а значит идёшь нахуй.
> SQL
Кал для дегенератов-менеджеров, был придумал таким, был создан таким, получилось ущербное говно от которого все избавляются.
> Разницы - буквально никакой.
Если ты тупоголовый кретин который не осилил базу работы компуктеров и хранения данных - безусловно.
>>465917
Такие, лицемеришко. Сам, небось, на джаве максимум круды писал, а пиздишь так, будто JVM-кишки мейнтейнишь, аки Леха Шипилев.
Так ты квадратногнездовой, хули, у тебя в башке парадигма приколочена к рантайму, блять. Если тебе парадигма запрещает сайд эффекты, это вообще ни разу не означает, что их не может быть в принципе. Ты тупо не шаришь о чем говоришь.
Ясно, лол. Нахуй было спорить с неадекватом-джуном в отрицалове...
>Какие инженеры
Такие, лицемеришко. Сам, небось, на джаве максимум круды писал, а пиздишь так, будто JVM-кишки мейнтейнишь, аки Леха Шипилев.
>Парадигма запрещает сайдэффекты, а работа через с внешним массивом данных это один здоровенный, глобальный, сайдэффект.
Так ты квадратногнездовой, хули, у тебя в башке парадигма приколочена к рантайму, блять. Если тебе парадигма запрещает сайд эффекты, это вообще ни разу не означает, что их не может быть в принципе. Ты тупо не шаришь о чем говоришь.
>SQL
>Кал
Ясно, лол. Нахуй было спорить с неадекватом-джуном в отрицалове...
>>464552
Я правильно понимаю, что для тебя женщина — это пизда на ножках? Почему ты автоматически относишься к вещам в духе "как им пользоваться", а не "как он устроен"? Ты меня огорчаешь.
>>464653
Сорян, не соглашусь. Хаскель спроектирован так, чтобы на нём было невыносимо тяжело делать полезные продукты. Я вижу охуительную ценность в идее, в том числе FRP, которое нынче там массово популяризовано в пародии на Elm под названием React.js. Но реализация в виде ЯП Haskell — это пиздец полный, этим невозможно пользоваться.
Лисп был №2 языком в индустрии совсем недавно. Можно строить теорию, что "просто лисп был не очень , а вот хаскель...", но правда в том, что индустрия уже отказалась от лиспохаскелей и не собирается к ним возвращаться ни в какое ближайшее время.
>>Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина?
>Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд и легализованная коллективная некомпетентность
Я правильно понимаю, что для тебя женщина — это пизда на ножках? Почему ты автоматически относишься к вещам в духе "как им пользоваться", а не "как он устроен"? Ты меня огорчаешь.
>>464653
>>Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле)
>Это буквально самый ничтожный из твоих тезисов. Литералли "сперва добейся". Нахуя это комментировать, я не особо понимаю.
Сорян, не соглашусь. Хаскель спроектирован так, чтобы на нём было невыносимо тяжело делать полезные продукты. Я вижу охуительную ценность в идее, в том числе FRP, которое нынче там массово популяризовано в пародии на Elm под названием React.js. Но реализация в виде ЯП Haskell — это пиздец полный, этим невозможно пользоваться.
>На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты, и школа ФП-разработки так и не популяризовалась.
Лисп был №2 языком в индустрии совсем недавно. Можно строить теорию, что "просто лисп был не очень , а вот хаскель...", но правда в том, что индустрия уже отказалась от лиспохаскелей и не собирается к ним возвращаться ни в какое ближайшее время.
>>465930
Интересная фантазия. Ты так фантазируешь потому что ты на фп лапшу пишешь?
Рантайм не может волшебным образом понять в каком месте глобал нужно создавать и можно разложить весь ФП в один кусок кода, а в каком нет.
Впрочем, можно создать такой рантайм, например ECS, который на какому-то уровне абстракций будет ФП. Но в таком случае ФП будет костылём который добавляет больше кода, лишняя мозгоебля.
Т.е. ты хочешь послать нахуй ФП и хуячить глобалы? О ну да, это и есть то самое функциональное программирование. Как я сразу не понял.
Что ещё ты про меня придумаешь, калоедище?
>>465986
В реальность давно выходил из манямирка? Тут это, KV больше 80% рынка заняли, слышал?
Как там тебе в 2010 году живётся? Тоже хочу, ебанёшь мне машину времени?
>Такие, лицемеришко. Сам, небось, на джаве максимум круды писал, а пиздишь так, будто JVM-кишки мейнтейнишь, аки Леха Шипилев.
Интересная фантазия. Ты так фантазируешь потому что ты на фп лапшу пишешь?
> Так ты квадратногнездовой, хули, у тебя в башке парадигма приколочена к рантайму, блять.
Рантайм не может волшебным образом понять в каком месте глобал нужно создавать и можно разложить весь ФП в один кусок кода, а в каком нет.
Впрочем, можно создать такой рантайм, например ECS, который на какому-то уровне абстракций будет ФП. Но в таком случае ФП будет костылём который добавляет больше кода, лишняя мозгоебля.
> Если тебе парадигма запрещает сайд эффекты, это вообще ни разу не означает, что их не может быть в принципе. Ты тупо не шаришь о чем говоришь.
Т.е. ты хочешь послать нахуй ФП и хуячить глобалы? О ну да, это и есть то самое функциональное программирование. Как я сразу не понял.
> Ясно, лол. Нахуй было спорить с неадекватом-джуном в отрицалове...
Что ещё ты про меня придумаешь, калоедище?
>>465986
В реальность давно выходил из манямирка? Тут это, KV больше 80% рынка заняли, слышал?
Как там тебе в 2010 году живётся? Тоже хочу, ебанёшь мне машину времени?
>>466090
Я вот живу в ней. И везде для обработки данных добавляют (верней, уже давно добавлен) как раз SQL почему-то.
Странно, ты уверен, что это не ты застрял в 2010? В реальности все уже давно поняли, что отказ от SQL был ошибкой и быстро переобулись назад. А у тебя тут KV, NoSQL и прочее до сих пор в почёте...
>В реальность давно выходил из манямирка?
Я вот живу в ней. И везде для обработки данных добавляют (верней, уже давно добавлен) как раз SQL почему-то.
>KV больше 80% рынка заняли
Странно, ты уверен, что это не ты застрял в 2010? В реальности все уже давно поняли, что отказ от SQL был ошибкой и быстро переобулись назад. А у тебя тут KV, NoSQL и прочее до сих пор в почёте...
>>466098
Ох уж этот маркетинг скульлахты, из каждого утюжка рассказывают что KV были ошибкой
>>466105
Да, я и говорил про БД. Может 80% это слишком, но вот утверждение что более 70% это NoSQL по факту там внутри всегда kv, так что пусть будут kv это правда
> В реальности все уже давно поняли, что отказ от SQL был ошибкой
Ох уж этот маркетинг скульлахты, из каждого утюжка рассказывают что KV были ошибкой
>>466105
Да, я и говорил про БД. Может 80% это слишком, но вот утверждение что более 70% это NoSQL по факту там внутри всегда kv, так что пусть будут kv это правда
>>466153
Ошибкой был не "KV", а попытка заменить им всё подряд. Большую часть данных сейчас (да и всегда) хранили не в KV в любом случае. Так что нет никаких "70%".
Ошибкой был не "KV", а попытка заменить им всё подряд. Большую часть данных сейчас (да и всегда) хранили не в KV в любом случае. Так что нет никаких "70%".
>>466082
Мы можем просто остаться при своих мнениях. Я так то не спорю, что кодить на хаскеле невыносимо, но все же считаю, что это все же из-за того, что под него надо переучиваться чуть ли не с нуля нахуй - он беспрецедентно строгий и не прощающий костылей (лиспы в этом плане не такие душные, да), и его инструментарий на фоне мейнстрима - откровенно куцый. А уж если у тебя еще и есть мейнстримный опыт за плечами, надо прям неебически переступить через себя чтобы смочь сделать на нем хоть что то и относиться к парадигме непредвзято. Поэтому этого и не случилось.
Как я выше и сказал - так легли карты.
>Но реализация в виде ЯП Haskell — это пиздец полный, этим невозможно пользоваться.
Мы можем просто остаться при своих мнениях. Я так то не спорю, что кодить на хаскеле невыносимо, но все же считаю, что это все же из-за того, что под него надо переучиваться чуть ли не с нуля нахуй - он беспрецедентно строгий и не прощающий костылей (лиспы в этом плане не такие душные, да), и его инструментарий на фоне мейнстрима - откровенно куцый. А уж если у тебя еще и есть мейнстримный опыт за плечами, надо прям неебически переступить через себя чтобы смочь сделать на нем хоть что то и относиться к парадигме непредвзято. Поэтому этого и не случилось.
Как я выше и сказал - так легли карты.
>>466163
На Rust мне не нужно переучиваться "чуть ли с нуля нахуй", но я его так же не люблю за бессмысленную сложность кодописания. Просто за невозможность композиции чистых и грязных алгоритмов уже разрабов хаскеля нужно было расстрелять нахуй — они вместо этого придумали монаду Reader, которая просто сделала весь этот пиздец ещё более сложным.
>но все же считаю, что это все же из-за того, что под него надо переучиваться чуть ли не с нуля нахуй - он беспрецедентно строгий и не прощающий костылей
На Rust мне не нужно переучиваться "чуть ли с нуля нахуй", но я его так же не люблю за бессмысленную сложность кодописания. Просто за невозможность композиции чистых и грязных алгоритмов уже разрабов хаскеля нужно было расстрелять нахуй — они вместо этого придумали монаду Reader, которая просто сделала весь этот пиздец ещё более сложным.
>>466188
Rust это те же яйца, только в профиль. Rust задирает планку своим борроучекером, который тоже беспрецедентен по своей сути, и тоже строг и требователен.
Понимаю эту фрустрацию. Поэтому на практике миксованные подходы вида "functional core, imperative shell" вполне себе прижились. Цимес впрочем в том, что imperative shell все более и более утончается.
Rust это те же яйца, только в профиль. Rust задирает планку своим борроучекером, который тоже беспрецедентен по своей сути, и тоже строг и требователен.
>Просто за невозможность композиции чистых и грязных алгоритмов уже разрабов хаскеля нужно было расстрелять нахуй
Понимаю эту фрустрацию. Поэтому на практике миксованные подходы вида "functional core, imperative shell" вполне себе прижились. Цимес впрочем в том, что imperative shell все более и более утончается.
>>466159
Да-да, скульлахта, всё это ошибка и вообще никто не пользуется. Держи в курсе.
>>466192
Скорее наоборот. В ядре дикая императивщина с чистыми функциями которую понимают только избранные, а внешние интерфейсы это какой-то микс из говна, палок и фп-кала, чтобы кодомакаки могли что угодно из какого угодно кала собрать, а фп для корпоблядей, чтобы тестировали любой кал до посинения.
Да-да, скульлахта, всё это ошибка и вообще никто не пользуется. Держи в курсе.
>>466192
> Поэтому на практике миксованные подходы вида "functional core, imperative shell"
Скорее наоборот. В ядре дикая императивщина с чистыми функциями которую понимают только избранные, а внешние интерфейсы это какой-то микс из говна, палок и фп-кала, чтобы кодомакаки могли что угодно из какого угодно кала собрать, а фп для корпоблядей, чтобы тестировали любой кал до посинения.
>>466212
Вот че ты влез опять, затычка в бочке? Ты же в упор не высекаешь, о каком core и shell выше идет речь, как выше в упор не высекал отличия парадигмы от рантайма - а все лезешь и на говно исходишь. Иди уже, проветрись, малой - тут дискуссия не твоего уровня. Друг другу мы все сказали уже.
>В ядре-хуядре...
Вот че ты влез опять, затычка в бочке? Ты же в упор не высекаешь, о каком core и shell выше идет речь, как выше в упор не высекал отличия парадигмы от рантайма - а все лезешь и на говно исходишь. Иди уже, проветрись, малой - тут дискуссия не твоего уровня. Друг другу мы все сказали уже.
>>466225
Так расскажешь мне про свой магический рантайм, который волшебным образом будет разбирать всё правильно? Примеры покажешь?
>>466246
>>466259
>>466263
Как же ФП-петушки стремятся доказать свою нужность и важность. Даже жаль вас немного, опущи от мира программирования которых оставили на задворках истории.
Так расскажешь мне про свой магический рантайм, который волшебным образом будет разбирать всё правильно? Примеры покажешь?
>>466246
>>466259
>>466263
Как же ФП-петушки стремятся доказать свою нужность и важность. Даже жаль вас немного, опущи от мира программирования которых оставили на задворках истории.
>>466272
>Нiiiiiiiiт! Это ни я прилюдно сру себе в портки, это мне функциональщики сайд эффектов подбросили! Уииииии!
Потому что не решило ни одной проблемы программирования. На функциональном ЯП можно точно так же писать говнокод и иметь точно такие же проблемы с производительностью и утечками памяти, как и на любом другом
>>466295
Ой да полно те. В айтишке есть миллион вещей, которые не решают буквально ни одной проблемы, но тем не менее прижились и пользуются популярностью.
Вон одни ORMы только чего стОят.
Ой да полно те. В айтишке есть миллион вещей, которые не решают буквально ни одной проблемы, но тем не менее прижились и пользуются популярностью.
Вон одни ORMы только чего стОят.
>>466307
Я? Нихуя. Мне вообще на тебя похуй начиная с этого >>465930 момента. Я с лиспоаноном общался, пока ты не вклинился с какой то шизоидной пастой, над которой полтреда покекало. Казалось бы - ну похуй тебе на ФП: выйди из треда, не позорься - имей блять самоуважение.
Нет, снова и снова императивный селюк прилюдно срет себе в шаровары. Нахуя?
Я? Нихуя. Мне вообще на тебя похуй начиная с этого >>465930 момента. Я с лиспоаноном общался, пока ты не вклинился с какой то шизоидной пастой, над которой полтреда покекало. Казалось бы - ну похуй тебе на ФП: выйди из треда, не позорься - имей блять самоуважение.
Нет, снова и снова императивный селюк прилюдно срет себе в шаровары. Нахуя?
>>466312
Сколько оправданий, лол. Это у тебя рефлекс выработался от бесконечных унижений, фп-чушка?
Сколько оправданий, лол. Это у тебя рефлекс выработался от бесконечных унижений, фп-чушка?
>>466302
Перейдя при этом на обсуждение СУБД... Ты сам-то свои сообщения читаешь?
>указав на ненужность SQL
Перейдя при этом на обсуждение СУБД... Ты сам-то свои сообщения читаешь?
>>466323
Бля, вангую это NodeJS-селюк с синдромом утенка на монге. Зато сколько гонору то было - "кеши процессорные"...
Бля, вангую это NodeJS-селюк с синдромом утенка на монге. Зато сколько гонору то было - "кеши процессорные"...
>>466326
Прочитай свои сообщения. Тебе писали про язык, ты сразу же перескочил на тип используемой СУБД, чтобы попытаться оправдать "ненужность" языка. Ты ошибки в логике здесь совсем не видишь?
>Что ты несешь?
Прочитай свои сообщения. Тебе писали про язык, ты сразу же перескочил на тип используемой СУБД, чтобы попытаться оправдать "ненужность" языка. Ты ошибки в логике здесь совсем не видишь?
>>466328
Опущенный опять пустился в фантазии о своём враге. Что ещё остаётся, не по делу возражать, на такое нужно мозги.
Опущенный опять пустился в фантазии о своём враге. Что ещё остаётся, не по делу возражать, на такое нужно мозги.
>>466330
Скажи честно, ты в состоянии воспринимать реальность? Не испытываешь с этим проблем?
Скажи честно, ты в состоянии воспринимать реальность? Не испытываешь с этим проблем?
>>466333
Не испытываю.
Не испытываю.
>>464600
Забавно что профессионально кодить с начал с 2006 года. И тогда был дикий холивар в пхп как кодить - ООП или по старинке процедурно. Забавно что второй вариант с массивами и функциями был куда гибче, а сторонники ООП были настолько глупыми что не могли объяснить реальные плюсы ООП, кроме завуалированного понравившегося вызова через.точку()
В общем, сложилось впечатления что основатели ЯП чето понимали за программирование, а модные молодежные подрожатели джава хотели ООП (в динамичном языке, лол). И в итоге пхп пошел не туда и заслуженно умер.
Другой забавный случай, что в те года питонщики, коих было 1,5 штуки, надсмехались над пхп, хотя у них на то время было еще хуже, ибо пхп 5 был уже как жаба
Забавно что профессионально кодить с начал с 2006 года. И тогда был дикий холивар в пхп как кодить - ООП или по старинке процедурно. Забавно что второй вариант с массивами и функциями был куда гибче, а сторонники ООП были настолько глупыми что не могли объяснить реальные плюсы ООП, кроме завуалированного понравившегося вызова через.точку()
В общем, сложилось впечатления что основатели ЯП чето понимали за программирование, а модные молодежные подрожатели джава хотели ООП (в динамичном языке, лол). И в итоге пхп пошел не туда и заслуженно умер.
Другой забавный случай, что в те года питонщики, коих было 1,5 штуки, надсмехались над пхп, хотя у них на то время было еще хуже, ибо пхп 5 был уже как жаба
>>464569
Кто будет читать высер малолетних вкатунцов на каникулах, которые нахватались с ютуба?
Именно так, в неразбавленной ФП по сути нет пошагового выполнения. Поэтому абстрагирование первых языков происходило именно в такой парадигме (перфокарты, машинный, ассемблер, си и подобные). То есть, само железо навязывало такое развитие и неожиданно человеку такое удобнее.
Понимаешь, истинная задача ФП это возможность самоутвердиться программисту на своем типа скилле. Поэтому если ты начинаешь тянуть "разбавленное ФП" которое уже адаптировано под железку, умеет какие-то абстракции под состояние, это уже не тру ФП и вообще для детей.
Проблема ФП что оно не создано практичнее решать задачу, оно создано чтобы макака могла подрочить на себя.
>Выше уже обсудили это
Кто будет читать высер малолетних вкатунцов на каникулах, которые нахватались с ютуба?
>Нихуяшеньки это не причина, и вот вообще ни разу не проблема.
Именно так, в неразбавленной ФП по сути нет пошагового выполнения. Поэтому абстрагирование первых языков происходило именно в такой парадигме (перфокарты, машинный, ассемблер, си и подобные). То есть, само железо навязывало такое развитие и неожиданно человеку такое удобнее.
>Обычно про ФП без состояний говорят новички
Понимаешь, истинная задача ФП это возможность самоутвердиться программисту на своем типа скилле. Поэтому если ты начинаешь тянуть "разбавленное ФП" которое уже адаптировано под железку, умеет какие-то абстракции под состояние, это уже не тру ФП и вообще для детей.
Проблема ФП что оно не создано практичнее решать задачу, оно создано чтобы макака могла подрочить на себя.
>>463265
А что оно означает? Как у тебя за последние 20 лет изменились задачи?
>Появление языков не означает удобство парадигмы, особенно с течением времени и изменением решаемых задач.
А что оно означает? Как у тебя за последние 20 лет изменились задачи?
>>464188
Так это ж литералли челики, вся карьера которых - это императивная низкоуровневая дрисня. Особенно забавно, что именно их ты привел в пример, ведь найти сколь-нибудь известного успещного ФПшника не получилось, лол.
>Нерды вроде Линуса Торвальдса или Джона Кармака
Так это ж литералли челики, вся карьера которых - это императивная низкоуровневая дрисня. Особенно забавно, что именно их ты привел в пример, ведь найти сколь-нибудь известного успещного ФПшника не получилось, лол.
>>463253
Как мы ловно переобулись с
до
Как мы ловно переобулись с
>данные и методы для работы с ними удобнее хранить в одном месте
до
>в рамках строгого ФП
>>466896
Так и есть. Только все таки не функциями, а процедурами.
Вообще, хз, какие там сторонники ООП были. Как кодили все на процедурах, так и кодят по сей день. Только вместо классического процедурного модуля сейчас - классы-сервисы, а вместо сишных инклюдов - инжекции DI-контейнеров. Вот буквально никакой разницы по итогу. Только больше оверхеда и больше бройлерпрейта.
Не они первые. Джаваны подражали страуструповой клике, которая уже тогда была мейнстримом в полный рост.
>Забавно что второй вариант с массивами и функциями был куда гибче
Так и есть. Только все таки не функциями, а процедурами.
Вообще, хз, какие там сторонники ООП были. Как кодили все на процедурах, так и кодят по сей день. Только вместо классического процедурного модуля сейчас - классы-сервисы, а вместо сишных инклюдов - инжекции DI-контейнеров. Вот буквально никакой разницы по итогу. Только больше оверхеда и больше бройлерпрейта.
> а модные молодежные подрожатели джава
Не они первые. Джаваны подражали страуструповой клике, которая уже тогда была мейнстримом в полный рост.
>>467005
Означает попытки заткнуть проблемы прошлых инструментов, сохраняя при этом похожесть на них. Удобство здесь стоит не на первом и даже не на втором месте.
Мы ушли от разработки ПО, данные которого меняются редко (десктоп, форумы) в сторону ПО, которое работает или с очень часто обновляемыми данными, или с данными в реальном времени. Отсюда появились всякие MapReduce (забавно, что название как раз из ФП взято) и прочие фреймворки для работы с данными, у которых основные принципы ФПшные.
>А что оно означает?
Означает попытки заткнуть проблемы прошлых инструментов, сохраняя при этом похожесть на них. Удобство здесь стоит не на первом и даже не на втором месте.
>Как у тебя за последние 20 лет изменились задачи?
Мы ушли от разработки ПО, данные которого меняются редко (десктоп, форумы) в сторону ПО, которое работает или с очень часто обновляемыми данными, или с данными в реальном времени. Отсюда появились всякие MapReduce (забавно, что название как раз из ФП взято) и прочие фреймворки для работы с данными, у которых основные принципы ФПшные.
>>467273
Раньше в пхп еще код писали в 1-2 человека и реальный выигрыш в виде инкапсуляции внутренней изменчивости (модульности) и контракты (интерфейсы) не ощущались (да и из-за отсутствие статики ООП было как пятое колесо).
В целом, ООП оказалось не серебряной пулей, но хорошо когда есть возможность на нем писать (но только в статично типизированном языке, а не этот цирк бреда). Поэтому холивар можно закрыть в пользу мультипарадигменных языков. В дотнете вообще есть F# и С# в последнем вообще сделали возможность как скрипты запускать.
https://dev.to/levu74/tutorial-running-your-c-code-without-a-project-file-49nk
Раньше в пхп еще код писали в 1-2 человека и реальный выигрыш в виде инкапсуляции внутренней изменчивости (модульности) и контракты (интерфейсы) не ощущались (да и из-за отсутствие статики ООП было как пятое колесо).
В целом, ООП оказалось не серебряной пулей, но хорошо когда есть возможность на нем писать (но только в статично типизированном языке, а не этот цирк бреда). Поэтому холивар можно закрыть в пользу мультипарадигменных языков. В дотнете вообще есть F# и С# в последнем вообще сделали возможность как скрипты запускать.
https://dev.to/levu74/tutorial-running-your-c-code-without-a-project-file-49nk
>>460219 (OP)
Потому что оно обещало всё упростить, а на деле усложнило. Попробуй напиши на ФП операционку, заебёшься потом оптимизировать. Или обучить вкатуна сразу на ФП, никакого быстрого старта не получится, будешь джва года объяснять монады, а в императивщине вкатун уже первые приложки доделает.
Потому что оно обещало всё упростить, а на деле усложнило. Попробуй напиши на ФП операционку, заебёшься потом оптимизировать. Или обучить вкатуна сразу на ФП, никакого быстрого старта не получится, будешь джва года объяснять монады, а в императивщине вкатун уже первые приложки доделает.
>>484808
Можно подумать, сейчас дофига операционок написано на питоне или джаве. С последней помнится были начинания, еще у Sun. Чето не взлетело.
Это в какой то мере справедливо. Под ФП надо нехило так перекраивать систему массового образования. Современная хуета на образовании готовит скорее тупых рабов, нежели качественных амбициозных специалистов, причем не только в этой стране.
> Попробуй напиши на ФП операционку, заебёшься потом оптимизировать
Можно подумать, сейчас дофига операционок написано на питоне или джаве. С последней помнится были начинания, еще у Sun. Чето не взлетело.
>Или обучить вкатуна сразу на ФП, никакого быстрого старта не получится
Это в какой то мере справедливо. Под ФП надо нехило так перекраивать систему массового образования. Современная хуета на образовании готовит скорее тупых рабов, нежели качественных амбициозных специалистов, причем не только в этой стране.
>>460219 (OP)
Почему провалилось? Оно используется там где уместно
Почему провалилось? Оно используется там где уместно
>>484856
У тебя логические ошибки. Нельзя просто так инвертировать импликацию. ФП -> заебёшь оптимизировать ещё не значит что НЕ ФП -> обязательно получится.
Тебя же как-то подготовила такого исключительного.
У тебя логические ошибки. Нельзя просто так инвертировать импликацию. ФП -> заебёшь оптимизировать ещё не значит что НЕ ФП -> обязательно получится.
> Современная хуета на образовании готовит скорее тупых рабов
Тебя же как-то подготовила такого исключительного.
45 Кб, 592x451провалилось от стыда под землю, глядя на ООП высеры
>>463941
Кабаны все прекрасно понимают.
Незаменимый специалист - главная угроза для бизнеса, хуже любых налогов и рейдерских захватов.
От таких надо в первую очередь избавляться.
Поэтому ООП и скриптовые языки в топе, сейчас код на них вообще могут писать нейросети.
А любители монадок едят мамкин борщ.
Кабаны все прекрасно понимают.
Незаменимый специалист - главная угроза для бизнеса, хуже любых налогов и рейдерских захватов.
От таких надо в первую очередь избавляться.
Поэтому ООП и скриптовые языки в топе, сейчас код на них вообще могут писать нейросети.
А любители монадок едят мамкин борщ.
>>467007
https://ru.wikipedia.org/wiki/Грэм,_Пол
>ведь найти сколь-нибудь известного успещного ФПшника не получилось, лол
https://ru.wikipedia.org/wiki/Грэм,_Пол
>>490886
Да, да... Видел я своими глазами как они все понимают.
Если че, это рилстори, в которой я живу.
Все правильно. Это как раз пример решения проблем в разработке кабаньим способом.
А разгадка проста: 95% программистов в 2025м - тупые и беспринципные гондоны. Отрицательный отбор в айтишке в конечном итоге сыграл свою роль, и кабаны с определенного момента (~2000е-2010е, а может быть и раньше) просто стремятся отлучить разработчика от кода любой ценой, выбить из рук вредных гондонов главное оружие их "незаменимости". Программист, пишуший код, давным давно уже считается персоной нон грата, и презрительно зовется велосипедостроителем. В современной разработке приветствуются лишь квадратногнездовые лоукодеры, а нейросетки - просто новый виток этой истории, ни больше ни меньше. И что характерно, кабанов действительно не в чем упрекнуть: такая их стратегия - вполне обоснованный ответ на тотальную безответственность и разрабов за свою работу.
Только вот программный код по своей сути - детерминирован и беспристрастен. Код не наебешь. Хуевый код неизбежно порождает хуевые решения, и никакие нейросетки с лоукодом этого не изменят. Кабаны с хуевым кодом ничего сделать не могут, разработчики - не хотят, в итоге весь банкет оплачивает потребитель, для которого дырявость софта давно уже - новая норма, а приватность данных - оксюморон. Так и живем.
Да, да... Видел я своими глазами как они все понимают.
>Дюже потешно до поры до времени наблюдять за руиной целых отделов разработки, когда те утопают в техдолге, а кабаны пытаются эти проблемы решать чисто кабаньими методами: то раздувают штат, то наоборот сократят нахуй, а воз и ныне там...
Если че, это рилстори, в которой я живу.
>Незаменимый специалист - главная угроза для бизнеса, хуже любых налогов и рейдерских захватов.
Все правильно. Это как раз пример решения проблем в разработке кабаньим способом.
А разгадка проста: 95% программистов в 2025м - тупые и беспринципные гондоны. Отрицательный отбор в айтишке в конечном итоге сыграл свою роль, и кабаны с определенного момента (~2000е-2010е, а может быть и раньше) просто стремятся отлучить разработчика от кода любой ценой, выбить из рук вредных гондонов главное оружие их "незаменимости". Программист, пишуший код, давным давно уже считается персоной нон грата, и презрительно зовется велосипедостроителем. В современной разработке приветствуются лишь квадратногнездовые лоукодеры, а нейросетки - просто новый виток этой истории, ни больше ни меньше. И что характерно, кабанов действительно не в чем упрекнуть: такая их стратегия - вполне обоснованный ответ на тотальную безответственность и разрабов за свою работу.
Только вот программный код по своей сути - детерминирован и беспристрастен. Код не наебешь. Хуевый код неизбежно порождает хуевые решения, и никакие нейросетки с лоукодом этого не изменят. Кабаны с хуевым кодом ничего сделать не могут, разработчики - не хотят, в итоге весь банкет оплачивает потребитель, для которого дырявость софта давно уже - новая норма, а приватность данных - оксюморон. Так и живем.
Потому что я не знаю что такое функтор и пучок. Простите я вас подвёл. Этого всего можно было избежать
>>490949
Если у тебя есть мало-мальский современный опыт разработки за плечами, скорее всего ты уже знаешь, что такое функтор. Просто тебе оно известно под другим именем.
>Потому что я не знаю что такое функтор
Если у тебя есть мало-мальский современный опыт разработки за плечами, скорее всего ты уже знаешь, что такое функтор. Просто тебе оно известно под другим именем.
>>460219 (OP)
Потому что я не могу на этом говне байтоёбить и писать очень быстрые императивные программы.
Потому что я не могу на этом говне байтоёбить и писать очень быстрые императивные программы.
132 Кб, 1114x720>>490971
В эпоху GPU и векторных операций байтобоить надо в array programming, а не в эти ваши сдвиги регистра.
В эпоху GPU и векторных операций байтобоить надо в array programming, а не в эти ваши сдвиги регистра.
>>460219 (OP)
ну оно не провалилось, а в качестве метода оптимизации кода влилось во все мейнстримовые языки
в чем основная сложность функциональщины - в том что оно не соответствует типовому способу мышления человека. человек мыслит объектами. ООП прекрасно ложится на платоново-аристотелевскую модель мира, на которой выстроена вся научная модель и метод. любой язык, у которого в базе нет понятия объекта/структуры/актора со своими свойствами обречен быть в лучшем случае нишевым инструментом.
даже в комонлисп пришлось запилить полноценное ООП чтобы хоть-что то вменяемое на нем можно было писать. на чистой функциональщине построить модель любой предметной области очень сложно и пиздец как неестественно для мозга, в отличие от любого языка ООП, где это на порядки проще делается.
> Почему функциональное программирование провалилось?
ну оно не провалилось, а в качестве метода оптимизации кода влилось во все мейнстримовые языки
в чем основная сложность функциональщины - в том что оно не соответствует типовому способу мышления человека. человек мыслит объектами. ООП прекрасно ложится на платоново-аристотелевскую модель мира, на которой выстроена вся научная модель и метод. любой язык, у которого в базе нет понятия объекта/структуры/актора со своими свойствами обречен быть в лучшем случае нишевым инструментом.
даже в комонлисп пришлось запилить полноценное ООП чтобы хоть-что то вменяемое на нем можно было писать. на чистой функциональщине построить модель любой предметной области очень сложно и пиздец как неестественно для мозга, в отличие от любого языка ООП, где это на порядки проще делается.
>>492046
абстракция это и есть объект, а точнее класс (эйдос в терминологии платона)
абстракция это и есть объект, а точнее класс (эйдос в терминологии платона)
>>492063
а функция - это процесс, преобразование. человек не мыслит процессами. для человека дерево - это хуйня со стволом, ветками и листьями, а не процесс превращения органических веществ из одних в другие с использованием фотосинтеза
а функция - это процесс, преобразование. человек не мыслит процессами. для человека дерево - это хуйня со стволом, ветками и листьями, а не процесс превращения органических веществ из одних в другие с использованием фотосинтеза
>>492103
ылитарий дохуя?
вот именно, для тебя функция - в первую очередь предмет (объект), то что существует, то что есть само по себе, и может что-то делать, имеет какие-то характеристики. а в чисто функциональной парадигме никаких объектов нет, есть только процесс изменения потока данных, определяемый ациклическим графом возможных состояний, где вершины - чистые функции и неизменяемые данные, а ребра вызовы этих функций (процесс передачи значений).
пока надо всякие матаны эмулировать это еще более-менее прокатывает, но как только предметная область меняется с математических выражений на что-нибудь другое, то начинается вырвиглазный пиздец.
функциональщина хороша там, где предметная область - явный матан. например потоковая обработка сигналов, преобразование каких-нибудь данных и т.д. мап-редьюс-туда-сюда и вывод на консоль. но там где нужно работать с перзистентными и иерархическими сущностями (а это 99,9% всех задач), она сосет из-за неоправданной сложности и негибкости.
единственный промышленный функциональный язык на котором действительно что-то пишут помимо хеловорлдов - common lisp. Но если ты откроешь исходник любой большой программы на cli то там чистой функциональщины от силы треть, остальное обычное ООП (правда с вырвиглазной семантикой). и что самое интересное если писать в духе всех последних оракловых гайдов то процент функциональщины в проектах на жаве будет такой же.
рыночек порешал.
так что лёрн хаскель фор грейт гуд (но в свободное от реального программирования время)
>Только если ты сельский дебил
ылитарий дохуя?
> Функция тоже абстракция
вот именно, для тебя функция - в первую очередь предмет (объект), то что существует, то что есть само по себе, и может что-то делать, имеет какие-то характеристики. а в чисто функциональной парадигме никаких объектов нет, есть только процесс изменения потока данных, определяемый ациклическим графом возможных состояний, где вершины - чистые функции и неизменяемые данные, а ребра вызовы этих функций (процесс передачи значений).
пока надо всякие матаны эмулировать это еще более-менее прокатывает, но как только предметная область меняется с математических выражений на что-нибудь другое, то начинается вырвиглазный пиздец.
функциональщина хороша там, где предметная область - явный матан. например потоковая обработка сигналов, преобразование каких-нибудь данных и т.д. мап-редьюс-туда-сюда и вывод на консоль. но там где нужно работать с перзистентными и иерархическими сущностями (а это 99,9% всех задач), она сосет из-за неоправданной сложности и негибкости.
единственный промышленный функциональный язык на котором действительно что-то пишут помимо хеловорлдов - common lisp. Но если ты откроешь исходник любой большой программы на cli то там чистой функциональщины от силы треть, остальное обычное ООП (правда с вырвиглазной семантикой). и что самое интересное если писать в духе всех последних оракловых гайдов то процент функциональщины в проектах на жаве будет такой же.
рыночек порешал.
так что лёрн хаскель фор грейт гуд (но в свободное от реального программирования время)
>>492275
Да, пишу императивно и процедурно.
Абстракция это не объект, ООП-дебил
Твой отсталый мозг засранный ООП-калом, пытается рационализровать почему ты пожрал ООП-говна, но это лишь жалкие попытки исказить реальность. Объекты это лишь говно в твоей бошке, а ООП это говноконцепция высранная менеджерами и дегенератами.
> ылитарий дохуя?
Да, пишу императивно и процедурно.
> вот именно, для тебя функция - в первую очередь предмет (объект), то что существует
Абстракция это не объект, ООП-дебил
Твой отсталый мозг засранный ООП-калом, пытается рационализровать почему ты пожрал ООП-говна, но это лишь жалкие попытки исказить реальность. Объекты это лишь говно в твоей бошке, а ООП это говноконцепция высранная менеджерами и дегенератами.
>>492360
А кроме говноговнохуйпидор обоснования будут? Так в школке в третьем классе базарят
А кроме говноговнохуйпидор обоснования будут? Так в школке в третьем классе базарят
>>460219 (OP)
Рыночек порешал красноглазых борщехлебов. Бизнесу нужны поддерживаемые продукты, которые можно легко и быстро написать людьми, которые взаимозаменямы. Аналогия с производством лучше чтобы любой токарь за час понял чего и куда в этом проекте, сделал грубую обработку, а дальше станок с ЧПУ довел деталь до сотых мм, чем иметь в цеху Петровича с золотыми руками, после увольнения которого или когда его намотает на вал с похмелья всё пойдет по пизде
Рыночек порешал красноглазых борщехлебов. Бизнесу нужны поддерживаемые продукты, которые можно легко и быстро написать людьми, которые взаимозаменямы. Аналогия с производством лучше чтобы любой токарь за час понял чего и куда в этом проекте, сделал грубую обработку, а дальше станок с ЧПУ довел деталь до сотых мм, чем иметь в цеху Петровича с золотыми руками, после увольнения которого или когда его намотает на вал с похмелья всё пойдет по пизде
>>490886
Двачаю это и есть основная проблема, а то в треде красноглазые пишут про смену системы образования, неосиляторов, другие способы мышления и прочую хуйню, забывая про того кто оплачивает этот банкет
Двачаю это и есть основная проблема, а то в треде красноглазые пишут про смену системы образования, неосиляторов, другие способы мышления и прочую хуйню, забывая про того кто оплачивает этот банкет
>>494253
Как это связано с непопулярностью ФП? ФП код же легче поддерживать, чем ООП с гетерами и сетерами?
>Бизнесу нужны поддерживаемые продукты, которые можно легко и быстро написать людьми, которые взаимозаменямы
Как это связано с непопулярностью ФП? ФП код же легче поддерживать, чем ООП с гетерами и сетерами?
>>492063
>>492068
И объект, и функция - абстракции.
ФП просто по уровню абстракций ушло гораздо дальше ООП. В ООП абстрагирование обычно останавливается где то на интерфейсах и обобщенке (дженериках).
Слыхал мнение, что каждый человек имеет свой индивидуальный предел, до которого он может абстрагировать штуки вокруг него, и это чуть ли не генетическая хуета, проявляющаяся еще на школьной скамье. Научно это нихуя не подтверждено, но любой школьный препод по математике скорее всего подтвердит это наблюдение.
Пятый класс, уравнения. Кто то из пиздюков с первой попытки понимает, что такое "икс" (а это, считай, самая первая реальная математическая абстракция, которую пиздюк встречает в шкиле), а кому то приходится прикладывать неебические ментальные усилия чтобы вкатиться и понять. Первые обычно идут впоследствии в когорту технарей, вторые - в гуманитарии (без негатива к гуманитариям).
И что характерно, уравнениями все не заканчивается. Кто то откисает в средних классах на всяких приколах типа пределов и тригонометрии. Кто то откисает на старших, встретившись с первыми производными и интегралами. Кто то откисает в универе на реальном матане - иногда откисает фатально и с отчислением, если специальность предполагает прям много матана в программе.
В программировании через жопу немного, но примерно так же. Обычно все чуваки с более-менее технарским уклоном с легкостью и со старта понимают концепты структурного программирования - ифы, циклы (гуманитарию кстати их хуй обьяснишь обычно - проверено неоднократно); процедурное программирование - процедуры, локальные переменные, возврат значения, стеки вызовов - тоже даются относительно легко; ООП уже дается хуевей - у вкатунов на этом уровне уже начинаются вопросики и непонятки - но со скрепом заходит. Обобщенка дается совсем хуево - не всякий вкатун способен адекватно объяснить, что это такое за PECS, а из тех кто может - не всякий готов их применять в реальной практике. Все нижеперечисленное - все более и более высокие уровни абстракции.
Ну а ФП - это совсем высокоуровневый набор абстракций. Его попросту не каждому дано понять - типы классов там какие то, функторы, шмонады... Даже привычная императивка абстрагирована нахуй, што!
Так же как не каждому дано вкатиться в совсем уж лютые разделы матана. Каждый имеет свой предел.
Функциональщиков мало, равно как мало и охуенных математиков. И те и другие стоят дорого, поэтому прикладной рыночек расположен не в их пользу. Поэтому ФП не мейнстрим и врядли им станет.
>>492068
И объект, и функция - абстракции.
ФП просто по уровню абстракций ушло гораздо дальше ООП. В ООП абстрагирование обычно останавливается где то на интерфейсах и обобщенке (дженериках).
Слыхал мнение, что каждый человек имеет свой индивидуальный предел, до которого он может абстрагировать штуки вокруг него, и это чуть ли не генетическая хуета, проявляющаяся еще на школьной скамье. Научно это нихуя не подтверждено, но любой школьный препод по математике скорее всего подтвердит это наблюдение.
Пятый класс, уравнения. Кто то из пиздюков с первой попытки понимает, что такое "икс" (а это, считай, самая первая реальная математическая абстракция, которую пиздюк встречает в шкиле), а кому то приходится прикладывать неебические ментальные усилия чтобы вкатиться и понять. Первые обычно идут впоследствии в когорту технарей, вторые - в гуманитарии (без негатива к гуманитариям).
И что характерно, уравнениями все не заканчивается. Кто то откисает в средних классах на всяких приколах типа пределов и тригонометрии. Кто то откисает на старших, встретившись с первыми производными и интегралами. Кто то откисает в универе на реальном матане - иногда откисает фатально и с отчислением, если специальность предполагает прям много матана в программе.
В программировании через жопу немного, но примерно так же. Обычно все чуваки с более-менее технарским уклоном с легкостью и со старта понимают концепты структурного программирования - ифы, циклы (гуманитарию кстати их хуй обьяснишь обычно - проверено неоднократно); процедурное программирование - процедуры, локальные переменные, возврат значения, стеки вызовов - тоже даются относительно легко; ООП уже дается хуевей - у вкатунов на этом уровне уже начинаются вопросики и непонятки - но со скрепом заходит. Обобщенка дается совсем хуево - не всякий вкатун способен адекватно объяснить, что это такое за PECS, а из тех кто может - не всякий готов их применять в реальной практике. Все нижеперечисленное - все более и более высокие уровни абстракции.
Ну а ФП - это совсем высокоуровневый набор абстракций. Его попросту не каждому дано понять - типы классов там какие то, функторы, шмонады... Даже привычная императивка абстрагирована нахуй, што!
Так же как не каждому дано вкатиться в совсем уж лютые разделы матана. Каждый имеет свой предел.
Функциональщиков мало, равно как мало и охуенных математиков. И те и другие стоят дорого, поэтому прикладной рыночек расположен не в их пользу. Поэтому ФП не мейнстрим и врядли им станет.
>>492063
>>492068
И объект, и функция - абстракции.
ФП просто по уровню абстракций ушло гораздо дальше ООП. В ООП абстрагирование обычно останавливается где то на интерфейсах и обобщенке (дженериках).
Слыхал мнение, что каждый человек имеет свой индивидуальный предел, до которого он может абстрагировать штуки вокруг него, и это чуть ли не генетическая хуета, проявляющаяся еще на школьной скамье. Научно это нихуя не подтверждено, но любой школьный препод по математике скорее всего подтвердит это наблюдение.
Пятый класс, уравнения. Кто то из пиздюков с первой попытки понимает, что такое "икс" (а это, считай, самая первая реальная математическая абстракция, которую пиздюк встречает в шкиле), а кому то приходится прикладывать неебические ментальные усилия чтобы вкатиться и понять. Первые обычно идут впоследствии в когорту технарей, вторые - в гуманитарии (без негатива к гуманитариям).
И что характерно, уравнениями все не заканчивается. Кто то откисает в средних классах на всяких приколах типа пределов и тригонометрии. Кто то откисает на старших, встретившись с первыми производными и интегралами. Кто то откисает в универе на реальном матане - иногда откисает фатально и с отчислением, если специальность предполагает прям много матана в программе.
В программировании через жопу немного, но примерно так же. Обычно все чуваки с более-менее технарским уклоном с легкостью и со старта понимают концепты структурного программирования - ифы, циклы (гуманитарию кстати их хуй обьяснишь обычно - проверено неоднократно); процедурное программирование - процедуры, локальные переменные, возврат значения, стеки вызовов - тоже даются относительно легко; ООП уже дается хуевей - у вкатунов на этом уровне уже начинаются вопросики и непонятки - но со скрепом заходит. Обобщенка дается совсем хуево - не всякий вкатун способен адекватно объяснить, что это такое за PECS, а из тех кто может - не всякий готов их применять в реальной практике. Все нижеперечисленное - все более и более высокие уровни абстракции.
Ну а ФП - это совсем высокоуровневый набор абстракций. Его попросту не каждому дано понять - типы классов там какие то, функторы, шмонады... Даже привычная императивка абстрагирована нахуй, што!
Так же как не каждому дано вкатиться в совсем уж лютые разделы матана. Каждый имеет свой предел.
Функциональщиков мало, равно как мало и охуенных математиков. И те и другие стоят дорого, поэтому прикладной рыночек расположен не в их пользу. Поэтому ФП не мейнстрим и врядли им станет.
>>492068
И объект, и функция - абстракции.
ФП просто по уровню абстракций ушло гораздо дальше ООП. В ООП абстрагирование обычно останавливается где то на интерфейсах и обобщенке (дженериках).
Слыхал мнение, что каждый человек имеет свой индивидуальный предел, до которого он может абстрагировать штуки вокруг него, и это чуть ли не генетическая хуета, проявляющаяся еще на школьной скамье. Научно это нихуя не подтверждено, но любой школьный препод по математике скорее всего подтвердит это наблюдение.
Пятый класс, уравнения. Кто то из пиздюков с первой попытки понимает, что такое "икс" (а это, считай, самая первая реальная математическая абстракция, которую пиздюк встречает в шкиле), а кому то приходится прикладывать неебические ментальные усилия чтобы вкатиться и понять. Первые обычно идут впоследствии в когорту технарей, вторые - в гуманитарии (без негатива к гуманитариям).
И что характерно, уравнениями все не заканчивается. Кто то откисает в средних классах на всяких приколах типа пределов и тригонометрии. Кто то откисает на старших, встретившись с первыми производными и интегралами. Кто то откисает в универе на реальном матане - иногда откисает фатально и с отчислением, если специальность предполагает прям много матана в программе.
В программировании через жопу немного, но примерно так же. Обычно все чуваки с более-менее технарским уклоном с легкостью и со старта понимают концепты структурного программирования - ифы, циклы (гуманитарию кстати их хуй обьяснишь обычно - проверено неоднократно); процедурное программирование - процедуры, локальные переменные, возврат значения, стеки вызовов - тоже даются относительно легко; ООП уже дается хуевей - у вкатунов на этом уровне уже начинаются вопросики и непонятки - но со скрепом заходит. Обобщенка дается совсем хуево - не всякий вкатун способен адекватно объяснить, что это такое за PECS, а из тех кто может - не всякий готов их применять в реальной практике. Все нижеперечисленное - все более и более высокие уровни абстракции.
Ну а ФП - это совсем высокоуровневый набор абстракций. Его попросту не каждому дано понять - типы классов там какие то, функторы, шмонады... Даже привычная императивка абстрагирована нахуй, што!
Так же как не каждому дано вкатиться в совсем уж лютые разделы матана. Каждый имеет свой предел.
Функциональщиков мало, равно как мало и охуенных математиков. И те и другие стоят дорого, поэтому прикладной рыночек расположен не в их пользу. Поэтому ФП не мейнстрим и врядли им станет.
>>494207
Ты просто цепанулся к постановке вопроса, и отвечаешь с точки зрения устройства нейросетей. Вопрос был не об этом.
>В чистом виде ФП.
Ты просто цепанулся к постановке вопроса, и отвечаешь с точки зрения устройства нейросетей. Вопрос был не об этом.
>>492275
Не бывает такой предметной области как "матан". Да и "работа с персистентными иерархиями" - не предметная область. Предметная область - это бабло тебе на карту кинуть/списать. Игорю тебе отрендерить. Таксисту кинуть адрес, где валяется твое бухое после попойки тело, чтоб он тебя до дома отвез... вот это вот все.
Да и даже если брать вот эти твои так называемые "иерархические сущности"... ты скорее всего преувеличиваешь, говоря что тебе прям сложна-сложна работать с ними без ООП. Как по мне, так весь реальный менеджмент этих сущностей и без ФП давным давно уже происходит под управлением великого множества баз данных, а крудовая обвязка вокруг них, которая обычно и составляет эти 99.9% решаемых задач, о которых ты говоришь, давным давно и так пишется stateless: выгребаем дтошку из репозитория, протаскиваем через stateless-сервисы, сериализуем респонзом на рестах, и наоборот. Замени ты эту цепочку на мап-редьюс-стрим - не поменяется ничего.
Или может быть ты имел ввиду ОРМы, лол?
Мимо
>функциональщина хороша там, где предметная область - явный матан. например потоковая обработка сигналов, преобразование каких-нибудь данных и т.д. мап-редьюс-туда-сюда и вывод на консоль. но там где нужно работать с перзистентными и иерархическими сущностями (а это 99,9% всех задач), она сосет из-за неоправданной сложности и негибкости.
Не бывает такой предметной области как "матан". Да и "работа с персистентными иерархиями" - не предметная область. Предметная область - это бабло тебе на карту кинуть/списать. Игорю тебе отрендерить. Таксисту кинуть адрес, где валяется твое бухое после попойки тело, чтоб он тебя до дома отвез... вот это вот все.
Да и даже если брать вот эти твои так называемые "иерархические сущности"... ты скорее всего преувеличиваешь, говоря что тебе прям сложна-сложна работать с ними без ООП. Как по мне, так весь реальный менеджмент этих сущностей и без ФП давным давно уже происходит под управлением великого множества баз данных, а крудовая обвязка вокруг них, которая обычно и составляет эти 99.9% решаемых задач, о которых ты говоришь, давным давно и так пишется stateless: выгребаем дтошку из репозитория, протаскиваем через stateless-сервисы, сериализуем респонзом на рестах, и наоборот. Замени ты эту цепочку на мап-редьюс-стрим - не поменяется ничего.
Или может быть ты имел ввиду ОРМы, лол?
Мимо
>>494760
Почему? Чистые функции легче понять, их легче тестировать, между ними видна чёткая связь, все дела.
Почему? Чистые функции легче понять, их легче тестировать, между ними видна чёткая связь, все дела.
>>494823
Я думаю, это из-за инерции. Раньше нанимали ООП-шников, теперь тоже продолжают их нанимать просто потому что "все так делоют, и ты делой". То есть поддержка кода тут уже не при чём?
Я думаю, это из-за инерции. Раньше нанимали ООП-шников, теперь тоже продолжают их нанимать просто потому что "все так делоют, и ты делой". То есть поддержка кода тут уже не при чём?
>>494887
Инерции в найме. Раньше было популярно ООП, все думали, что это путь вперёд, вышла джава, которую очень активно пропихивали, потом сишарп ещё родили и его начали пропихивать. И только в конце нулевых-начале десятых начали понемногу вкорячивать ФП подход в ООП-языки и проекты. Но мыслить продолжать ООП-шно, потому что до этого 40 лет так мыслили, отсюда и инерция.
Инерции в найме. Раньше было популярно ООП, все думали, что это путь вперёд, вышла джава, которую очень активно пропихивали, потом сишарп ещё родили и его начали пропихивать. И только в конце нулевых-начале десятых начали понемногу вкорячивать ФП подход в ООП-языки и проекты. Но мыслить продолжать ООП-шно, потому что до этого 40 лет так мыслили, отсюда и инерция.
>>494887
Современное ООП это эрзац. Оригинальные новаторские идеи ООП популяризовались еще даже хуже, чем идеи из функциональной парадигмы, а в мейнстриме в ходу старое доброе процедурное программирование, просто на классах. Современное "ООП" популярно лишь потому, что у коболистов прошлого получилось на классы переложить принципы процедурного программирования. Эта инертность мышления гораздо старше 40 лет на самом деле.
>ООП моложе функциональщины лет на 40
Современное ООП это эрзац. Оригинальные новаторские идеи ООП популяризовались еще даже хуже, чем идеи из функциональной парадигмы, а в мейнстриме в ходу старое доброе процедурное программирование, просто на классах. Современное "ООП" популярно лишь потому, что у коболистов прошлого получилось на классы переложить принципы процедурного программирования. Эта инертность мышления гораздо старше 40 лет на самом деле.
>>494253
Помнится, букинг долго сидел на перле и вообще не парился по этому поводу. Набирали людей вообще без знания перла — "на месте разберешься, главное чтобы человек был хороший".
Я по питону конкретно высрал простыню ( >>3497420 → ) с пояснением, каким вообще образом такой пиздец случился.
Нет, у кабанов нет прямой выгоды от того, что проект пишется на питоне, а не на эрланге. Крови этот питон попьет ещё много, но зато "никого не увольняют за выбор питона" — это раз. Два: 95% кадровиков совершенно некомпетентны, а какие-то из них поставлены на должность просто для того, чтобы сосать начальнику по выходным на даче. Даже при очень большом желании они не могут найти что-то, кроме рандомных выпускников с улицы, которые будут копипастить код с stackoverflow.
Как у таких ебланов появились деньги — это ещё одна забавная тема. Да, совсем недавно мешками деньги разбрасывали, просто за то, что ты продемонстрируешь желание сделать перспективный проект. А вы думали, что только в СНГ умеют бюджеты пилить? Рассиянские распилы меркнут по сравнению с сотней млрд долларов, которые каждый год пилятся в кремневой долине.
Elixir сейчас вообще довольно активно мелькает то там, тот тут. Нельзя сказать, что это дохуя мейнстримовый инструмент так-то.
Айтишная сфера в странах второго-третьего мира — это отдельный цирк. С одной стороны, они делают "как у серьёзных компаний". С другой стороны, у них нет и сотой доли бюджета "серьёзной компании", потому "делать так же" чота нихуя не получается. Потому часто бизнес делается по принципу "кого нашли на улице — того и впрягаем". Нашли достаточно кодеров на JS — будем писать модуль ядра под линукс на JS. Что значит нельзя? Никого это не ебёт — бегом взял и начал писать. Если завтра на улицах будет хаскелистов как грязи, то, внезапно, будут писать на хаскеле. Такая вот хуйня.
>Рыночек порешал красноглазых борщехлебов. Бизнесу нужны поддерживаемые продукты, которые можно легко и быстро написать людьми, которые взаимозаменямы.
Помнится, букинг долго сидел на перле и вообще не парился по этому поводу. Набирали людей вообще без знания перла — "на месте разберешься, главное чтобы человек был хороший".
Я по питону конкретно высрал простыню ( >>3497420 → ) с пояснением, каким вообще образом такой пиздец случился.
Нет, у кабанов нет прямой выгоды от того, что проект пишется на питоне, а не на эрланге. Крови этот питон попьет ещё много, но зато "никого не увольняют за выбор питона" — это раз. Два: 95% кадровиков совершенно некомпетентны, а какие-то из них поставлены на должность просто для того, чтобы сосать начальнику по выходным на даче. Даже при очень большом желании они не могут найти что-то, кроме рандомных выпускников с улицы, которые будут копипастить код с stackoverflow.
Как у таких ебланов появились деньги — это ещё одна забавная тема. Да, совсем недавно мешками деньги разбрасывали, просто за то, что ты продемонстрируешь желание сделать перспективный проект. А вы думали, что только в СНГ умеют бюджеты пилить? Рассиянские распилы меркнут по сравнению с сотней млрд долларов, которые каждый год пилятся в кремневой долине.
Elixir сейчас вообще довольно активно мелькает то там, тот тут. Нельзя сказать, что это дохуя мейнстримовый инструмент так-то.
Айтишная сфера в странах второго-третьего мира — это отдельный цирк. С одной стороны, они делают "как у серьёзных компаний". С другой стороны, у них нет и сотой доли бюджета "серьёзной компании", потому "делать так же" чота нихуя не получается. Потому часто бизнес делается по принципу "кого нашли на улице — того и впрягаем". Нашли достаточно кодеров на JS — будем писать модуль ядра под линукс на JS. Что значит нельзя? Никого это не ебёт — бегом взял и начал писать. Если завтра на улицах будет хаскелистов как грязи, то, внезапно, будут писать на хаскеле. Такая вот хуйня.
>>494723
Знаешь кого ещё меньше у нас тут? Гей шлюх. Круче чем математики, и востребованнее. не каждому дано.
С хуя ли какая-то бессмысленно и бестолково переусложнённая параща должна быть ценной? Ты знаешь хотя бы одного, ХОТЯ БЫ ОДНОГО БЛЯТЬ математика, который за свою жизнь высрал хотя бы что-то полезное, кроме алгоритма криптографии без документации по поводу того, как им теперь пользоваться? Я не знаю таких. Может быть потому, что не нужны ни гей шлюхи. ни математики, ни какие-то другие фрики.
>Обобщенка дается совсем хуево - не всякий вкатун способен адекватно объяснить, что это такое за PECS, а из тех кто может - не всякий готов их применять в реальной практике. Все нижеперечисленное - все более и более высокие уровни абстракции.
>Функциональщиков мало, равно как мало и охуенных математиков. И те и другие стоят дорого, поэтому прикладной рыночек расположен не в их пользу. Поэтому ФП не мейнстрим и врядли им станет.
Знаешь кого ещё меньше у нас тут? Гей шлюх. Круче чем математики, и востребованнее. не каждому дано.
С хуя ли какая-то бессмысленно и бестолково переусложнённая параща должна быть ценной? Ты знаешь хотя бы одного, ХОТЯ БЫ ОДНОГО БЛЯТЬ математика, который за свою жизнь высрал хотя бы что-то полезное, кроме алгоритма криптографии без документации по поводу того, как им теперь пользоваться? Я не знаю таких. Может быть потому, что не нужны ни гей шлюхи. ни математики, ни какие-то другие фрики.
>>494818
Потому что чистые функции НИЧЕГО НЕ ДЕЛАЮТ. Потому они чистые. Смысл работы любой программы — это побочные эффекты, которые "грязные" по поределению.
>Чистые функции легче понять, их легче тестировать, между ними видна чёткая связь, все дела.
Потому что чистые функции НИЧЕГО НЕ ДЕЛАЮТ. Потому они чистые. Смысл работы любой программы — это побочные эффекты, которые "грязные" по поределению.
>>495089
Большинство айтишных трендов задаются западными компаниями, в которых руководству в большинстве своём до пизды, что там хуже и лучше, какие идей или парадигмы — ты давай нам презентацию хуйни, через неделю инвесторам показывать, они бюджет на следующий год планируют. Приходит Страуструп, и грит "вот, в три раза меньше багов в софте будет, это называется ООП. Собачка — животное, кошечка — животное, я — животное. Это наследование. Понятно? Тогда дайте денег" — и эту хуйню купили. Быстрое, простое, понятное, и НЕПРАВИЛЬНОЕ решение. Но, ещё раз, твоя правильность-неправильность никого не ебёт, твоё ООП само по себе, без PowerPoint презентаций, даром никому не нужно. А PowerPoint презентации на ООП программировать одно удовольствие. Они ещё UML придумали. чтобы вообще хорошо презентации проектировались, реализовывались, и выпускались в продакшен.
Если отойти на секундочку обратно в техническую сторону, то современное понимание "ООП" — это вообще не ООП, это класс-ориентированное программирование, лапша из взаимных наследований реализации, которая заткнёт за пояс даже классические программы на коболе с goto. В процедурное программирование оно скатывается лишь усилиями отдельных самоучек, которым забыли пояснить, что от чего нужно наследовать, и потому они просто пишут код минимальными затратами усилий, "чтобы быстрее заработало и не ебало мозги", им приколы с графиками и презентациями нахуй не нужны. На самом деле Керниган и Ритчи — это классика подхода "хуяк-хуяк и в продакшен", люди, которые ничего не понимали в Computer Science, а просто тяп-ляп заебашили минимально рабочий инструмент. Когда у меня готовый инструмент есть, а у тебя нету, то я выиграл — такая логика американской экономики. Если кто не в курсе — язык Си выиграл у Algol 68, которые делался комитетом, и Дейкстра с Виртом громко хлопнув дверьё съебали из этого комитета. Вирт сделал Algol W, который нам всем хорошо известен под другим именем, но по итогу весь рыночек языка похерила пара-тройка корпораций, поглощенных по итогу одним Borland.
Да и вообще, я не понимаю этого разговора про "ООП", "ФП", "процедурное программирование" — все мейнстримные ЯП давно мультипарадигменные, а на Smalltalk пишет три калеки во всём мире.
>Оригинальные новаторские идеи ООП популяризовались еще даже хуже, чем идеи из функциональной парадигмы, а в мейнстриме в ходу старое доброе процедурное программирование, просто на классах. Современное "ООП" популярно лишь потому, что у коболистов прошлого получилось на классы переложить принципы процедурного программирования.
Большинство айтишных трендов задаются западными компаниями, в которых руководству в большинстве своём до пизды, что там хуже и лучше, какие идей или парадигмы — ты давай нам презентацию хуйни, через неделю инвесторам показывать, они бюджет на следующий год планируют. Приходит Страуструп, и грит "вот, в три раза меньше багов в софте будет, это называется ООП. Собачка — животное, кошечка — животное, я — животное. Это наследование. Понятно? Тогда дайте денег" — и эту хуйню купили. Быстрое, простое, понятное, и НЕПРАВИЛЬНОЕ решение. Но, ещё раз, твоя правильность-неправильность никого не ебёт, твоё ООП само по себе, без PowerPoint презентаций, даром никому не нужно. А PowerPoint презентации на ООП программировать одно удовольствие. Они ещё UML придумали. чтобы вообще хорошо презентации проектировались, реализовывались, и выпускались в продакшен.
Если отойти на секундочку обратно в техническую сторону, то современное понимание "ООП" — это вообще не ООП, это класс-ориентированное программирование, лапша из взаимных наследований реализации, которая заткнёт за пояс даже классические программы на коболе с goto. В процедурное программирование оно скатывается лишь усилиями отдельных самоучек, которым забыли пояснить, что от чего нужно наследовать, и потому они просто пишут код минимальными затратами усилий, "чтобы быстрее заработало и не ебало мозги", им приколы с графиками и презентациями нахуй не нужны. На самом деле Керниган и Ритчи — это классика подхода "хуяк-хуяк и в продакшен", люди, которые ничего не понимали в Computer Science, а просто тяп-ляп заебашили минимально рабочий инструмент. Когда у меня готовый инструмент есть, а у тебя нету, то я выиграл — такая логика американской экономики. Если кто не в курсе — язык Си выиграл у Algol 68, которые делался комитетом, и Дейкстра с Виртом громко хлопнув дверьё съебали из этого комитета. Вирт сделал Algol W, который нам всем хорошо известен под другим именем, но по итогу весь рыночек языка похерила пара-тройка корпораций, поглощенных по итогу одним Borland.
Да и вообще, я не понимаю этого разговора про "ООП", "ФП", "процедурное программирование" — все мейнстримные ЯП давно мультипарадигменные, а на Smalltalk пишет три калеки во всём мире.
>>495089
Большинство айтишных трендов задаются западными компаниями, в которых руководству в большинстве своём до пизды, что там хуже и лучше, какие идей или парадигмы — ты давай нам презентацию хуйни, через неделю инвесторам показывать, они бюджет на следующий год планируют. Приходит Страуструп, и грит "вот, в три раза меньше багов в софте будет, это называется ООП. Собачка — животное, кошечка — животное, я — животное. Это наследование. Понятно? Тогда дайте денег" — и эту хуйню купили. Быстрое, простое, понятное, и НЕПРАВИЛЬНОЕ решение. Но, ещё раз, твоя правильность-неправильность никого не ебёт, твоё ООП само по себе, без PowerPoint презентаций, даром никому не нужно. А PowerPoint презентации на ООП программировать одно удовольствие. Они ещё UML придумали. чтобы вообще хорошо презентации проектировались, реализовывались, и выпускались в продакшен.
Если отойти на секундочку обратно в техническую сторону, то современное понимание "ООП" — это вообще не ООП, это класс-ориентированное программирование, лапша из взаимных наследований реализации, которая заткнёт за пояс даже классические программы на коболе с goto. В процедурное программирование оно скатывается лишь усилиями отдельных самоучек, которым забыли пояснить, что от чего нужно наследовать, и потому они просто пишут код минимальными затратами усилий, "чтобы быстрее заработало и не ебало мозги", им приколы с графиками и презентациями нахуй не нужны. На самом деле Керниган и Ритчи — это классика подхода "хуяк-хуяк и в продакшен", люди, которые ничего не понимали в Computer Science, а просто тяп-ляп заебашили минимально рабочий инструмент. Когда у меня готовый инструмент есть, а у тебя нету, то я выиграл — такая логика американской экономики. Если кто не в курсе — язык Си выиграл у Algol 68, которые делался комитетом, и Дейкстра с Виртом громко хлопнув дверьё съебали из этого комитета. Вирт сделал Algol W, который нам всем хорошо известен под другим именем, но по итогу весь рыночек языка похерила пара-тройка корпораций, поглощенных по итогу одним Borland.
Да и вообще, я не понимаю этого разговора про "ООП", "ФП", "процедурное программирование" — все мейнстримные ЯП давно мультипарадигменные, а на Smalltalk пишет три калеки во всём мире.
>Оригинальные новаторские идеи ООП популяризовались еще даже хуже, чем идеи из функциональной парадигмы, а в мейнстриме в ходу старое доброе процедурное программирование, просто на классах. Современное "ООП" популярно лишь потому, что у коболистов прошлого получилось на классы переложить принципы процедурного программирования.
Большинство айтишных трендов задаются западными компаниями, в которых руководству в большинстве своём до пизды, что там хуже и лучше, какие идей или парадигмы — ты давай нам презентацию хуйни, через неделю инвесторам показывать, они бюджет на следующий год планируют. Приходит Страуструп, и грит "вот, в три раза меньше багов в софте будет, это называется ООП. Собачка — животное, кошечка — животное, я — животное. Это наследование. Понятно? Тогда дайте денег" — и эту хуйню купили. Быстрое, простое, понятное, и НЕПРАВИЛЬНОЕ решение. Но, ещё раз, твоя правильность-неправильность никого не ебёт, твоё ООП само по себе, без PowerPoint презентаций, даром никому не нужно. А PowerPoint презентации на ООП программировать одно удовольствие. Они ещё UML придумали. чтобы вообще хорошо презентации проектировались, реализовывались, и выпускались в продакшен.
Если отойти на секундочку обратно в техническую сторону, то современное понимание "ООП" — это вообще не ООП, это класс-ориентированное программирование, лапша из взаимных наследований реализации, которая заткнёт за пояс даже классические программы на коболе с goto. В процедурное программирование оно скатывается лишь усилиями отдельных самоучек, которым забыли пояснить, что от чего нужно наследовать, и потому они просто пишут код минимальными затратами усилий, "чтобы быстрее заработало и не ебало мозги", им приколы с графиками и презентациями нахуй не нужны. На самом деле Керниган и Ритчи — это классика подхода "хуяк-хуяк и в продакшен", люди, которые ничего не понимали в Computer Science, а просто тяп-ляп заебашили минимально рабочий инструмент. Когда у меня готовый инструмент есть, а у тебя нету, то я выиграл — такая логика американской экономики. Если кто не в курсе — язык Си выиграл у Algol 68, которые делался комитетом, и Дейкстра с Виртом громко хлопнув дверьё съебали из этого комитета. Вирт сделал Algol W, который нам всем хорошо известен под другим именем, но по итогу весь рыночек языка похерила пара-тройка корпораций, поглощенных по итогу одним Borland.
Да и вообще, я не понимаю этого разговора про "ООП", "ФП", "процедурное программирование" — все мейнстримные ЯП давно мультипарадигменные, а на Smalltalk пишет три калеки во всём мире.
>>497567
Это очевидно не так. Большая часть работы как раз делается в чистых функциях. Если у тебя наоборот, больше всего побочных эффектов, то ты либо делаешь что-то не так (неправильно разбил код на функции), либо ты рассматриваешь очень маленький скоуп, где у тебя только одна-две функции с побочными эффектами.
Даже если у тебя программа, которая жсоны перекладывает из одного места в другое, то и в этом случае большая часть функций будет чистой, а с побочными будет буквально две.
>Потому что чистые функции НИЧЕГО НЕ ДЕЛАЮТ
Это очевидно не так. Большая часть работы как раз делается в чистых функциях. Если у тебя наоборот, больше всего побочных эффектов, то ты либо делаешь что-то не так (неправильно разбил код на функции), либо ты рассматриваешь очень маленький скоуп, где у тебя только одна-две функции с побочными эффектами.
Даже если у тебя программа, которая жсоны перекладывает из одного места в другое, то и в этом случае большая часть функций будет чистой, а с побочными будет буквально две.
>>497567
В современных приложухах все побочные эффекты уходят на выход: в аутпут, в бд, в очередь, в коллектор логов, в трейсы, в метрики. Даже в ООП. Хранить состояние внутри приложухи - боль и отчаяние.
>побочные эффекты, которые "грязные" по поределению
В современных приложухах все побочные эффекты уходят на выход: в аутпут, в бд, в очередь, в коллектор логов, в трейсы, в метрики. Даже в ООП. Хранить состояние внутри приложухи - боль и отчаяние.
>>497602
Давай я тебе поясню на пальцах так: никого не волнует, сколько чашек кофе ты выпил и сколько совещаний провёл для того, чтобы написать строчку кода. Идея ясна? У тебя чистая функция отправит JSON по сети и добавит запись в постгрю? Ну давай возьмем самые жесткие вычислительные хуёвины — например, какую-то криптографию. Но даже протокол Signal не требует каких-то сверхъестественных вычислений на каждой итерации, и большая часть реализации таки должна обрабатывать "скучные" вещи, вроде отправки оп сети и отображение пользовательского интерфейса — которые почти не требуют вычислений, но зато требуют вымазаться с ног до головы в грязи.
>Большая часть работы как раз делается в чистых функциях
Давай я тебе поясню на пальцах так: никого не волнует, сколько чашек кофе ты выпил и сколько совещаний провёл для того, чтобы написать строчку кода. Идея ясна? У тебя чистая функция отправит JSON по сети и добавит запись в постгрю? Ну давай возьмем самые жесткие вычислительные хуёвины — например, какую-то криптографию. Но даже протокол Signal не требует каких-то сверхъестественных вычислений на каждой итерации, и большая часть реализации таки должна обрабатывать "скучные" вещи, вроде отправки оп сети и отображение пользовательского интерфейса — которые почти не требуют вычислений, но зато требуют вымазаться с ног до головы в грязи.
>>497606
У вас терминальная стадия микросервисов, вам нужен курс регулярных внутривенных вливаний YAML.
От того, что ты размазал десять функций по десяти микросервисам, суть кода не поменялась. Его стало больше, но он не делает больше.
>В современных приложухах все побочные эффекты уходят на выход: в аутпут, в бд, в очередь, в коллектор логов, в трейсы, в метрики. Даже в ООП. Хранить состояние внутри приложухи - боль и отчаяние.
У вас терминальная стадия микросервисов, вам нужен курс регулярных внутривенных вливаний YAML.
От того, что ты размазал десять функций по десяти микросервисам, суть кода не поменялась. Его стало больше, но он не делает больше.
>>497610
Но он ведёт себя предсказуемо. Все болячки как на ладони. Собственно в этом прикол микросервисов, а не в том что можно 50 индусов нанять и забить на менеджмент.
>Его стало больше, но он не делает больше.
Но он ведёт себя предсказуемо. Все болячки как на ладони. Собственно в этом прикол микросервисов, а не в том что можно 50 индусов нанять и забить на менеджмент.
>>497607
Нет, но не из-за побочных эффектов как ты думаешь, а из-за того, что это не одна функция, а несколько.
>У тебя чистая функция отправит JSON по сети и добавит запись в постгрю?
Нет, но не из-за побочных эффектов как ты думаешь, а из-за того, что это не одна функция, а несколько.
>>497616
Какие болячки на ладони? Десять сервисов быстрее отлаживать, чем десять функций в одном? Вынюхивать логи и собирать мозаику вызовыво между ними? Чо там у нас по миграции данных? Или у вас уже никто даже не знает до конца, что где хранится и зачем?
Как правило, типовая современная микросервисная лапша — это хуй знает что, состоящее из хуй знает чего, и ни один человек в компании не знает, как оно работает, не может его оттестировать и отладить end-to-end, и основной способ исправления багов — это поставить свечку в храме, чтобы прод пизданулся не на твоём сервисе, а ты потом пришел и сказал "а у меня все тесты проходят, это не в моём сервисе проблемы... да и вообще, это девопс опять что-то накосячил".
И получить систему, которая работает день через два. Откуда, просто откуда вы эту хуйню берёте? Все практические попытки такую хуйню повторить проваливались с треском. И спотифай, который бегал по конференциям и продвигал культуру отсутствия менеджмента, как новую религию, насосался по итогу хуёв в первую очередь, получив через раз работающий вебсайт, отвал стриминга при покупке подписки, и бан пользователей потому что... да никто даже не знает, куда этот аккаунт делся, просто в него нельзя залогиниться, и поддержка сама не знает, что с этим делать. Это мой случай, я эту хуйню не по каким-то рассказам в интернете говорю — рассказы в интернете просто подтверждают, что не я один этого говна поел.
На всякий случай я здесь уточню, что макросервисная архитектуру, как у яндекса или гугла — это не микросервисы. Потому что некоторые люди слышат отовсюду "микросервисы, мироксервисы", и начинают всё подряд наызвать микросервисами, мол "а мы чо, самые рыжые, что ли? У нас тоже микросервисы".
>Но он ведёт себя предсказуемо. Все болячки как на ладони. Собственно в этом прикол микросервисов, а не в том что можно 50 индусов нанять и забить на менеджмент.
Какие болячки на ладони? Десять сервисов быстрее отлаживать, чем десять функций в одном? Вынюхивать логи и собирать мозаику вызовыво между ними? Чо там у нас по миграции данных? Или у вас уже никто даже не знает до конца, что где хранится и зачем?
Как правило, типовая современная микросервисная лапша — это хуй знает что, состоящее из хуй знает чего, и ни один человек в компании не знает, как оно работает, не может его оттестировать и отладить end-to-end, и основной способ исправления багов — это поставить свечку в храме, чтобы прод пизданулся не на твоём сервисе, а ты потом пришел и сказал "а у меня все тесты проходят, это не в моём сервисе проблемы... да и вообще, это девопс опять что-то накосячил".
>Собственно в этом прикол микросервисов, а не в том что можно 50 индусов нанять и забить на менеджмент.
И получить систему, которая работает день через два. Откуда, просто откуда вы эту хуйню берёте? Все практические попытки такую хуйню повторить проваливались с треском. И спотифай, который бегал по конференциям и продвигал культуру отсутствия менеджмента, как новую религию, насосался по итогу хуёв в первую очередь, получив через раз работающий вебсайт, отвал стриминга при покупке подписки, и бан пользователей потому что... да никто даже не знает, куда этот аккаунт делся, просто в него нельзя залогиниться, и поддержка сама не знает, что с этим делать. Это мой случай, я эту хуйню не по каким-то рассказам в интернете говорю — рассказы в интернете просто подтверждают, что не я один этого говна поел.
На всякий случай я здесь уточню, что макросервисная архитектуру, как у яндекса или гугла — это не микросервисы. Потому что некоторые люди слышат отовсюду "микросервисы, мироксервисы", и начинают всё подряд наызвать микросервисами, мол "а мы чо, самые рыжые, что ли? У нас тоже микросервисы".
>>461536
Функциональному языку вообще стек не нужен. Можно помещать AST в RAM, а затем менять ветки на другие ветки согласно некоторым правилам.
К примеру небольшой пример:
fn(True) = "Hello "
fn(False) = "world"
fn(x) = x
main = fn(True) ++ fn(False) ++ fn("!") ~> File "/dev/stdout"
Данная программа помещается в RAM, а затем компилятор думает, так стоит начать вычисления... он ищет определение main и начинает менять применять к ней правила перезаписи.
Так будет выглядеть изменения в RAM (поэтапно):
1: main = fn(True) ++ fn(False) ++ fn("!") ~> File /dev/stdout
2: main = "Hello " ++ "world" ++ "!" ~> File /dev/stdout
3: main = "Hello world!" ~> File /dev/stdout
Дальше выражение не редуцируется, компилятор начинает применнять эффект I/O (конструктор `~>`) записывая строку в stdout.
Стек тут вообще не нужен, всё можно делать в RAM напрямую, всё зависит от реализации.
Функциональному языку вообще стек не нужен. Можно помещать AST в RAM, а затем менять ветки на другие ветки согласно некоторым правилам.
К примеру небольшой пример:
fn(True) = "Hello "
fn(False) = "world"
fn(x) = x
main = fn(True) ++ fn(False) ++ fn("!") ~> File "/dev/stdout"
Данная программа помещается в RAM, а затем компилятор думает, так стоит начать вычисления... он ищет определение main и начинает менять применять к ней правила перезаписи.
Так будет выглядеть изменения в RAM (поэтапно):
1: main = fn(True) ++ fn(False) ++ fn("!") ~> File /dev/stdout
2: main = "Hello " ++ "world" ++ "!" ~> File /dev/stdout
3: main = "Hello world!" ~> File /dev/stdout
Дальше выражение не редуцируется, компилятор начинает применнять эффект I/O (конструктор `~>`) записывая строку в stdout.
Стек тут вообще не нужен, всё можно делать в RAM напрямую, всё зависит от реализации.
>>497620
Чем принципиально одна чистая функция отличается от комбинации чистых функций? Или ты о чём? Ты развёрнуто формулировать свою мысль можешь?
Я привёл очень простой пример — я тебе что, буду рассказывать про детали реализации проекта да. допустим, на 200 тыс строк? Вот у меня на последнем проекте хуева гора кода занималась тупо обработкой соединений. Потому что если ты получаешь JSON в node.js, то нода и JS-библиотеки дохуя невидимых побочных эффектов делают, а именно: принять соединение, сделать TLS хендшейк, расшифровать блок данных, ещё один блок. ещё один, и так пока не придёт весь JSON — и только теперь ты можешь делать свои чистые алгоритмы, которые на самом деле выполняют 5-10% всей обработки. А если ты делаешь обработку сложнее, то внезапно возникает необходимость как-то фиксировать промежуточные этапы обработки — это опять грязь. И так далее.
>Нет, но не из-за побочных эффектов как ты думаешь, а из-за того, что это не одна функция, а несколько.
Чем принципиально одна чистая функция отличается от комбинации чистых функций? Или ты о чём? Ты развёрнуто формулировать свою мысль можешь?
>Даже если у тебя программа, которая жсоны перекладывает из одного места в другое, то и в этом случае большая часть функций будет чистой, а с побочными будет буквально две.
Я привёл очень простой пример — я тебе что, буду рассказывать про детали реализации проекта да. допустим, на 200 тыс строк? Вот у меня на последнем проекте хуева гора кода занималась тупо обработкой соединений. Потому что если ты получаешь JSON в node.js, то нода и JS-библиотеки дохуя невидимых побочных эффектов делают, а именно: принять соединение, сделать TLS хендшейк, расшифровать блок данных, ещё один блок. ещё один, и так пока не придёт весь JSON — и только теперь ты можешь делать свои чистые алгоритмы, которые на самом деле выполняют 5-10% всей обработки. А если ты делаешь обработку сложнее, то внезапно возникает необходимость как-то фиксировать промежуточные этапы обработки — это опять грязь. И так далее.
Итт спец олимпиада для неосиляторов?
Берем патриарха ООП Эванса, и видим что он советует использовать чистые функции почаще и вообще брать пример с математиков, так как это упрощает понимание и тестирование кода. Чек.
Берем какой-нибудь фп-язык, типа коммон лиспа, и видим в CLOS, ну потому что удобно моделировать сложные системы как взаимодействующие друг с другом объекты. Чек.
Берём двух двачеров-долбоящеров. Один не осилил ФП, поэтому думает что ООП панацея. Второй не понял ООП, поэтому молится на ФП.
Берем патриарха ООП Эванса, и видим что он советует использовать чистые функции почаще и вообще брать пример с математиков, так как это упрощает понимание и тестирование кода. Чек.
Берем какой-нибудь фп-язык, типа коммон лиспа, и видим в CLOS, ну потому что удобно моделировать сложные системы как взаимодействующие друг с другом объекты. Чек.
Берём двух двачеров-долбоящеров. Один не осилил ФП, поэтому думает что ООП панацея. Второй не понял ООП, поэтому молится на ФП.
>>497623
Давайте я вас рассужу: вы оба дураки и неправы. У функциональщины нет проблем со стэком — у неё есть проблемы с запредельным числом грязного мусора, который нужно создавать и, самое главное, убирать для того, чтобы "чистые" функции могли работать не выжирая гигабайты памяти на выполнение "Hello world". Само выполнение чистой функции — это грязный побочный эффект, да. Она чистая только пока она не выполняется — такие дела.
>Функциональному языку вообще стек не нужен. Можно помещать AST в RAM, а затем менять ветки на другие ветки согласно некоторым правилам.
>Данная программа помещается в RAM, а затем компилятор думает, так стоит начать вычисления... он ищет определение main и начинает менять применять к ней правила перезаписи.
Давайте я вас рассужу: вы оба дураки и неправы. У функциональщины нет проблем со стэком — у неё есть проблемы с запредельным числом грязного мусора, который нужно создавать и, самое главное, убирать для того, чтобы "чистые" функции могли работать не выжирая гигабайты памяти на выполнение "Hello world". Само выполнение чистой функции — это грязный побочный эффект, да. Она чистая только пока она не выполняется — такие дела.
>>497625
Я предполагаю, что тебе уже известны принципы, которые мы тут обсуждаем, поэтому не вижу смысла писать длинные пассажи.
Я о том, что ты пишешь, будто у тебя одна функция, которая и читает жсон, и обрабатывает его, и шлёт его в БД. Но в реальности-то это не так (надеюсь, по крайней мере, что у тебя не так).
Непосредственно побочные эффекты у тебя даже в этом случае будут только в паре функций, которые эти побочные эффекты и выполняют. Остальное реализуется чистыми функциями.
Чистые функции вообще никак не мешают сохранять куда-то промежуточные этапы (если речь не про ОЗУ).
>Ты развёрнуто формулировать свою мысль можешь?
Я предполагаю, что тебе уже известны принципы, которые мы тут обсуждаем, поэтому не вижу смысла писать длинные пассажи.
>Чем принципиально одна чистая функция отличается от комбинации чистых функций? Или ты о чём?
Я о том, что ты пишешь, будто у тебя одна функция, которая и читает жсон, и обрабатывает его, и шлёт его в БД. Но в реальности-то это не так (надеюсь, по крайней мере, что у тебя не так).
>Вот у меня на последнем проекте хуева гора кода занималась тупо обработкой соединений
Непосредственно побочные эффекты у тебя даже в этом случае будут только в паре функций, которые эти побочные эффекты и выполняют. Остальное реализуется чистыми функциями.
>А если ты делаешь обработку сложнее, то внезапно возникает необходимость как-то фиксировать промежуточные этапы обработки — это опять грязь
Чистые функции вообще никак не мешают сохранять куда-то промежуточные этапы (если речь не про ОЗУ).
18 Кб, 643x471>>497627
Если ты помещаешь программу в RAM, и просто начнешь переписывать, то никаких "скрытых" данных от разраба не будет. Многие языки скрывают от разработчика свой внутряк: стек вызовов, аппарат привязки переменных в окружении, самоу окружение. Это неправильный подход, на самом деле. Программист должен видеть точно, как его программа работает НА САМОМ ДЕЛЕ, и должен иметь возможность написать альтернативную реализацию.
Если ты помещаешь программу в RAM, и просто начнешь переписывать, то никаких "скрытых" данных от разраба не будет. Многие языки скрывают от разработчика свой внутряк: стек вызовов, аппарат привязки переменных в окружении, самоу окружение. Это неправильный подход, на самом деле. Программист должен видеть точно, как его программа работает НА САМОМ ДЕЛЕ, и должен иметь возможность написать альтернативную реализацию.
>>497634
Пиздец, а ты вообще когда-то что-то больше курсача делал? Какого хуя мы мыслим архитектурами уровня Hello world? Так-то и Си умеет Hello world делать без единого изменения переменной — и чо, у нас Си стал дохуя чистым функциональным языком от этого? Когда ты начинаешь делать что-то большее, чем вычисляемые во время компиляции выражения, то появляется необходимость в памяти, в огромном количестве стэк-фреймов, или блоков замыканий, если мы говорим про тот же Haskell — это всё говно нужно где-то хранить, выделять и очищать, и всё это сплошная грязь.
Берёшь рантайм хаскеля и модифицируешь до опизденения — заодно наешься такого количества говна, что в следующий раз у тебя поубиваться прыть, и ты хотя бы не будешь нести хуйню плана "чистые функции — это прекрасно, но их портит незначительное количество грязного кода под капотом, который можно было бы легко убрать".
>Если ты помещаешь программу в RAM, и просто начнешь переписывать, то никаких "скрытых" данных от разраба не будет. Многие языки скрывают от разработчика свой внутряк: стек вызовов, аппарат привязки переменных в окружении, самоу окружение. Это неправильный подход, на самом деле. Программист должен видеть точно, как его программа работает НА САМОМ ДЕЛЕ, и должен иметь возможность написать альтернативную реализацию.
Пиздец, а ты вообще когда-то что-то больше курсача делал? Какого хуя мы мыслим архитектурами уровня Hello world? Так-то и Си умеет Hello world делать без единого изменения переменной — и чо, у нас Си стал дохуя чистым функциональным языком от этого? Когда ты начинаешь делать что-то большее, чем вычисляемые во время компиляции выражения, то появляется необходимость в памяти, в огромном количестве стэк-фреймов, или блоков замыканий, если мы говорим про тот же Haskell — это всё говно нужно где-то хранить, выделять и очищать, и всё это сплошная грязь.
Берёшь рантайм хаскеля и модифицируешь до опизденения — заодно наешься такого количества говна, что в следующий раз у тебя поубиваться прыть, и ты хотя бы не будешь нести хуйню плана "чистые функции — это прекрасно, но их портит незначительное количество грязного кода под капотом, который можно было бы легко убрать".
>>497632
Я нихуя не понимаю, про какие "чистые функции" ты пишешь мне. На всякий случай ещё раз подчеркиваю.
Отпарсенный JSON ты где хранить будешь? Или ты его будешь побайтово по каждому запросу ключа заново парсить? И так далее, у любой сложной логики есть промежуточные состояния, и ФП здесь не исключение.
А доступ к RAM — это у нас не монада State, IO, ST, Reader/Writer? Это ли не грязь? Да, какие-то из них пишут грязь явно, через сишные прокладки, какие-то пишут грязь неявно, через замыкания языка — но замыкания являются такими же побочными эффектами, просто заувалированными.
>Непосредственно побочные эффекты у тебя даже в этом случае будут только в паре функций, которые эти побочные эффекты и выполняют. Остальное реализуется чистыми функциями.
Я нихуя не понимаю, про какие "чистые функции" ты пишешь мне. На всякий случай ещё раз подчеркиваю.
Отпарсенный JSON ты где хранить будешь? Или ты его будешь побайтово по каждому запросу ключа заново парсить? И так далее, у любой сложной логики есть промежуточные состояния, и ФП здесь не исключение.
>Чистые функции вообще никак не мешают сохранять куда-то промежуточные этапы (если речь не про ОЗУ).
А доступ к RAM — это у нас не монада State, IO, ST, Reader/Writer? Это ли не грязь? Да, какие-то из них пишут грязь явно, через сишные прокладки, какие-то пишут грязь неявно, через замыкания языка — но замыкания являются такими же побочными эффектами, просто заувалированными.
>>497637
А нахуя мне писать тебе полное определение лямбда исчесления, арифметики Пеано в правилах=терминах перезаписи? Я просто показываю концепцию, как оно вообще работает.
Все эти вычисления в рантайме происходят, а не во время компиляции.
Я тебе пикрил показал. Всё это может быть явно видно во время трассировки программы, а не скрыто. То есть замыкания - никакая не магия, и разраб может почитать stdlib чтобы узнать, какие правила в языке отвечают за привязку переменных. И может написать альтернативную реализацию, к примеру вели себя как в Prolog, а не как Haskell. И никаких стекфреймов тут нет, только AST, которое меняется с течением выполнения программы.
Яркий пример такого подхода — Lisp. В личпе лямбды это не минимальная частица языка, а всего лишь удобный макрос.
> Какого хуя мы мыслим архитектурами уровня Hello world?
А нахуя мне писать тебе полное определение лямбда исчесления, арифметики Пеано в правилах=терминах перезаписи? Я просто показываю концепцию, как оно вообще работает.
>Когда ты начинаешь делать что-то большее, чем вычисляемые во время компиляции выражения,
Все эти вычисления в рантайме происходят, а не во время компиляции.
> появляется необходимость в памяти, в огромном количестве стэк-фреймов, или блоков замыканий
Я тебе пикрил показал. Всё это может быть явно видно во время трассировки программы, а не скрыто. То есть замыкания - никакая не магия, и разраб может почитать stdlib чтобы узнать, какие правила в языке отвечают за привязку переменных. И может написать альтернативную реализацию, к примеру вели себя как в Prolog, а не как Haskell. И никаких стекфреймов тут нет, только AST, которое меняется с течением выполнения программы.
Яркий пример такого подхода — Lisp. В личпе лямбды это не минимальная частица языка, а всего лишь удобный макрос.
>>497641
Я эту хуйню поручу нейросетке:
«Input: array of 1 million machine integers (e.g., 32-bit or 64-bit)
Allowed operations:
• No mutation (so no in-place sort)
• No storing of intermediate lists or arrays
• Only pure functions applied on data
• No memoization or caching
• Output is "printed" (instantly and for free), so no serialization cost
Functional model, but not Church-style — actual numbers, just no memory
For 1 million integers:
O(n² log n) ≈ 1e12 * ~20 ≈ 2e13 basic steps
Let’s say each step (comparison + functional recomposition) takes around 500 CPU cycles (very optimistic).
On a 3 GHz CPU:
Steps/sec = 3e9 / 500 = 6e6
Total time = 2e13 / 6e6 ≈ 3.3e6 seconds ≈ ~38 days
⏳ Verdict
Estimated runtime: around 30–40 days on a modern CPU, assuming no storage/memoization of any intermediate results and purely recomputing everything through pure functions.»
Теперь на русском: шиз, которому я отвечаю, предлагает крошечный массив на миллион чисел сортировать месяц, но зато православными чистыми вычислениями. Что и требовалось доказать.
Для справки: qsort выполняет ту же задачу за 20 миллисекунд.
В лиспе замыкания являются объектами в памяти, похожими на хаскелевые, но со своими особенностями. То есть, они хранят контекст, ссылаются на окружающий контекст, это не просто пустая хуйня с бесплатным состоянием, которая при этом может сохранять и вспоминать данные из ниоткуда.
Если ты доведешь всё до абсурда в некоем воображаемом ЯП и будешь хранить промежуточные переменные в виде AST, то это никак сути не поменяет,поменяется лишь форма этих переменных.
>А нахуя мне писать тебе полное определение лямбда исчесления, арифметики Пеано в правилах=терминах перезаписи? Я просто показываю концепцию, как оно вообще работает.
Я эту хуйню поручу нейросетке:
«Input: array of 1 million machine integers (e.g., 32-bit or 64-bit)
Allowed operations:
• No mutation (so no in-place sort)
• No storing of intermediate lists or arrays
• Only pure functions applied on data
• No memoization or caching
• Output is "printed" (instantly and for free), so no serialization cost
Functional model, but not Church-style — actual numbers, just no memory
For 1 million integers:
O(n² log n) ≈ 1e12 * ~20 ≈ 2e13 basic steps
Let’s say each step (comparison + functional recomposition) takes around 500 CPU cycles (very optimistic).
On a 3 GHz CPU:
Steps/sec = 3e9 / 500 = 6e6
Total time = 2e13 / 6e6 ≈ 3.3e6 seconds ≈ ~38 days
⏳ Verdict
Estimated runtime: around 30–40 days on a modern CPU, assuming no storage/memoization of any intermediate results and purely recomputing everything through pure functions.»
Теперь на русском: шиз, которому я отвечаю, предлагает крошечный массив на миллион чисел сортировать месяц, но зато православными чистыми вычислениями. Что и требовалось доказать.
Для справки: qsort выполняет ту же задачу за 20 миллисекунд.
>Яркий пример такого подхода — Lisp. В личпе лямбды это не минимальная частица языка, а всего лишь удобный макрос.
В лиспе замыкания являются объектами в памяти, похожими на хаскелевые, но со своими особенностями. То есть, они хранят контекст, ссылаются на окружающий контекст, это не просто пустая хуйня с бесплатным состоянием, которая при этом может сохранять и вспоминать данные из ниоткуда.
Если ты доведешь всё до абсурда в некоем воображаемом ЯП и будешь хранить промежуточные переменные в виде AST, то это никак сути не поменяет,поменяется лишь форма этих переменных.
>>497641
Я эту хуйню поручу нейросетке:
«Input: array of 1 million machine integers (e.g., 32-bit or 64-bit)
Allowed operations:
• No mutation (so no in-place sort)
• No storing of intermediate lists or arrays
• Only pure functions applied on data
• No memoization or caching
• Output is "printed" (instantly and for free), so no serialization cost
Functional model, but not Church-style — actual numbers, just no memory
For 1 million integers:
O(n² log n) ≈ 1e12 * ~20 ≈ 2e13 basic steps
Let’s say each step (comparison + functional recomposition) takes around 500 CPU cycles (very optimistic).
On a 3 GHz CPU:
Steps/sec = 3e9 / 500 = 6e6
Total time = 2e13 / 6e6 ≈ 3.3e6 seconds ≈ ~38 days
⏳ Verdict
Estimated runtime: around 30–40 days on a modern CPU, assuming no storage/memoization of any intermediate results and purely recomputing everything through pure functions.»
Теперь на русском: шиз, которому я отвечаю, предлагает крошечный массив на миллион чисел сортировать месяц, но зато православными чистыми вычислениями. Что и требовалось доказать.
Для справки: qsort выполняет ту же задачу за 20 миллисекунд.
В лиспе замыкания являются объектами в памяти, похожими на хаскелевые, но со своими особенностями. То есть, они хранят контекст, ссылаются на окружающий контекст, это не просто пустая хуйня с бесплатным состоянием, которая при этом может сохранять и вспоминать данные из ниоткуда.
Если ты доведешь всё до абсурда в некоем воображаемом ЯП и будешь хранить промежуточные переменные в виде AST, то это никак сути не поменяет,поменяется лишь форма этих переменных.
>А нахуя мне писать тебе полное определение лямбда исчесления, арифметики Пеано в правилах=терминах перезаписи? Я просто показываю концепцию, как оно вообще работает.
Я эту хуйню поручу нейросетке:
«Input: array of 1 million machine integers (e.g., 32-bit or 64-bit)
Allowed operations:
• No mutation (so no in-place sort)
• No storing of intermediate lists or arrays
• Only pure functions applied on data
• No memoization or caching
• Output is "printed" (instantly and for free), so no serialization cost
Functional model, but not Church-style — actual numbers, just no memory
For 1 million integers:
O(n² log n) ≈ 1e12 * ~20 ≈ 2e13 basic steps
Let’s say each step (comparison + functional recomposition) takes around 500 CPU cycles (very optimistic).
On a 3 GHz CPU:
Steps/sec = 3e9 / 500 = 6e6
Total time = 2e13 / 6e6 ≈ 3.3e6 seconds ≈ ~38 days
⏳ Verdict
Estimated runtime: around 30–40 days on a modern CPU, assuming no storage/memoization of any intermediate results and purely recomputing everything through pure functions.»
Теперь на русском: шиз, которому я отвечаю, предлагает крошечный массив на миллион чисел сортировать месяц, но зато православными чистыми вычислениями. Что и требовалось доказать.
Для справки: qsort выполняет ту же задачу за 20 миллисекунд.
>Яркий пример такого подхода — Lisp. В личпе лямбды это не минимальная частица языка, а всего лишь удобный макрос.
В лиспе замыкания являются объектами в памяти, похожими на хаскелевые, но со своими особенностями. То есть, они хранят контекст, ссылаются на окружающий контекст, это не просто пустая хуйня с бесплатным состоянием, которая при этом может сохранять и вспоминать данные из ниоткуда.
Если ты доведешь всё до абсурда в некоем воображаемом ЯП и будешь хранить промежуточные переменные в виде AST, то это никак сути не поменяет,поменяется лишь форма этих переменных.
>>497638
Хорошо, пускай будет грязь.
Хорошо, пускай будет грязь.
>>497649
Блять, что за бред ты несешь нахуй?
Вообще-то qsort это чистая функция, долбоеб. Она выполняется чистыми вычислениями, и определена рекурсивно. Нахуй ты вообще её сюда приплел? Я тебе про A, ты про Б.
Я говорю, языку программирования вообще стек вызовов необязателен. Есть конкатенативные языки, такие как Fort, Joy, Factor тоже нет стека вызовов. Это вообще необязательная хуйня.
Хранятся не переменные, хранится сама программа, которая редуцируется каждый шаг вычислений.
Возьми доску, напиши не ней математическое выражение, и начинай переписывать подвыражения на их значения (результаты). Именно так вообще, ну, происходят вычисления, именно так вещи считаются. Редукция — основа математики. В компьютере можно сделать тоже самое, только вместо доски у нас - RAM.
https://en.wikipedia.org/wiki/Reduction_(mathematics)
https://en.wikipedia.org/wiki/Rewriting
https://esolangs.org/wiki/Thue
Блять, что за бред ты несешь нахуй?
> qsort
Вообще-то qsort это чистая функция, долбоеб. Она выполняется чистыми вычислениями, и определена рекурсивно. Нахуй ты вообще её сюда приплел? Я тебе про A, ты про Б.
Я говорю, языку программирования вообще стек вызовов необязателен. Есть конкатенативные языки, такие как Fort, Joy, Factor тоже нет стека вызовов. Это вообще необязательная хуйня.
> и будешь хранить промежуточные переменные в виде AST
Хранятся не переменные, хранится сама программа, которая редуцируется каждый шаг вычислений.
Возьми доску, напиши не ней математическое выражение, и начинай переписывать подвыражения на их значения (результаты). Именно так вообще, ну, происходят вычисления, именно так вещи считаются. Редукция — основа математики. В компьютере можно сделать тоже самое, только вместо доски у нас - RAM.
https://en.wikipedia.org/wiki/Reduction_(mathematics)
https://en.wikipedia.org/wiki/Rewriting
https://esolangs.org/wiki/Thue
>>497670
Я пропустил важный момент, который очевиден любому, кто разбирается в практическом программировании, но так и быть — это qsort из libc, соответственно, сишная реализация. Не так много других стандартных функций с именем qsort могут отсортировать миллион целых чисел за 20 миллисекунд.
Стэк не обязателен. Но жор памяти обязателен для хуёвых языков, написанных ради математической идеи, а не практической применимости.
Да похую, каким именем ты назвал свою переменную — это та же самая переменная.
И чем это отличается от ЛЮБОГО языка программирования? Более того, выполнение (не сам программный код) любой программы на любом языке программирования представляет собой применение функции "центральный процессор" к предыдущему состоянию для получения следующего состоянию. Хуйня, которой ты занимаешься — это просто жонглирование терминами, без изменения практической сути.
>> qsort
>Вообще-то qsort это чистая функция, долбоеб. Она выполняется чистыми вычислениями, и определена рекурсивно. Нахуй ты вообще её сюда приплел? Я тебе про A, ты про Б.
Я пропустил важный момент, который очевиден любому, кто разбирается в практическом программировании, но так и быть — это qsort из libc, соответственно, сишная реализация. Не так много других стандартных функций с именем qsort могут отсортировать миллион целых чисел за 20 миллисекунд.
>Я говорю, языку программирования вообще стек вызовов необязателен. Есть конкатенативные языки, такие как Fort, Joy, Factor тоже нет стека вызовов. Это вообще необязательная хуйня.
Стэк не обязателен. Но жор памяти обязателен для хуёвых языков, написанных ради математической идеи, а не практической применимости.
>Хранятся не переменные, хранится сама программа, которая редуцируется каждый шаг вычислений.
Да похую, каким именем ты назвал свою переменную — это та же самая переменная.
>Возьми доску, напиши не ней математическое выражение, и начинай переписывать подвыражения на их значения (результаты). Именно так вообще, ну, происходят вычисления, именно так вещи считаются. Редукция — основа математики. В компьютере можно сделать тоже самое, только вместо доски у нас - RAM.
И чем это отличается от ЛЮБОГО языка программирования? Более того, выполнение (не сам программный код) любой программы на любом языке программирования представляет собой применение функции "центральный процессор" к предыдущему состоянию для получения следующего состоянию. Хуйня, которой ты занимаешься — это просто жонглирование терминами, без изменения практической сути.
19 Кб, 740x193>>497679
А еще qsort реализован в Haskell. Ты же понимаешь, что скорость вычислений и занимаемые ВООБЩЕ не зависит от парадигмы?
Примерно... всем? Имплементации JS не работают с помощью паттерн-метчинга и переписывания AST.
>это qsort из libc
А еще qsort реализован в Haskell. Ты же понимаешь, что скорость вычислений и занимаемые ВООБЩЕ не зависит от парадигмы?
> И чем это отличается от ЛЮБОГО языка программирования?
Примерно... всем? Имплементации JS не работают с помощью паттерн-метчинга и переписывания AST.
>>497690
"А ещё троллейбус можно сделать из буханки хлеба" — нет, получится совсем не то же. "Qsort на хаскеле" каким он гуглится не присутствует нигде в хаскелевых библиотеках — и именно потому, что это "троллейбус из хлеба", практической ценности сия функция не имеет. Хотя, я встречал доскональное повторение сигной реализации на unboxed массивах, но с таким же успехом можно было и на C-- всё это написать.
Я назову любую хуйню "AST" и буду её переписывать JS. Как докажешь, что это "не та AST, не православная, еретическая"? Паттерн матчинг?... Многоловнее будет на JS, но всё равно можно сделать.
>А еще qsort реализован в Haskell. Ты же понимаешь, что скорость вычислений и занимаемые ВООБЩЕ не зависит от парадигмы?
"А ещё троллейбус можно сделать из буханки хлеба" — нет, получится совсем не то же. "Qsort на хаскеле" каким он гуглится не присутствует нигде в хаскелевых библиотеках — и именно потому, что это "троллейбус из хлеба", практической ценности сия функция не имеет. Хотя, я встречал доскональное повторение сигной реализации на unboxed массивах, но с таким же успехом можно было и на C-- всё это написать.
>Имплементации JS не работают с помощью паттерн-метчинга и переписывания AST.
Я назову любую хуйню "AST" и буду её переписывать JS. Как докажешь, что это "не та AST, не православная, еретическая"? Паттерн матчинг?... Многоловнее будет на JS, но всё равно можно сделать.
>>497826
Ты дурак? V8 (JIT-компилятор жиэса) вообще не так работает, можешь глянуть в исходники почитать. Ты голову включи и начни читать посты внимательно. Нет там переписывания термов.
Именно что блядь тоже. Алгоритм есть алгоритм, и его сложность не языком программирования определяется. Язык может накладывать только дополнительную нагрузку (GC, Dynamic Typing).
И то на Haskell работать будет быстрее сишной версии в ряде случаев, так как есть мемоизация.
> Я назову любую хуйню "AST" и буду её переписывать JS.
Ты дурак? V8 (JIT-компилятор жиэса) вообще не так работает, можешь глянуть в исходники почитать. Ты голову включи и начни читать посты внимательно. Нет там переписывания термов.
> нет, получится совсем не то же
Именно что блядь тоже. Алгоритм есть алгоритм, и его сложность не языком программирования определяется. Язык может накладывать только дополнительную нагрузку (GC, Dynamic Typing).
И то на Haskell работать будет быстрее сишной версии в ряде случаев, так как есть мемоизация.
>>497919
Я пропустил, старые версии AST у тебя святой дух будет очищать из памяти?
Ты сёдня решил без таблеток? Реализация qsort на хаскеле из гугла не имеет отношения к алгоритму quick sort, она же "сортировка Хоара" — это просто другой алгоритм. Читаешь описание сортировки Хоара, смотришь на код qsort под хаскель из гугла. У Хоара банально элементы перенесённые элементы на верхних уровнях оказываются в обратном порядке, а твой filter-sort генерирует массивы с сохранённым порядоком. Так что я хуй его знает, может быть ты сейчас жирафу отвечаешь — я ж не знаю, как тебя там сейчас плющит.
Пошли истории про "хаскель работает быстрее Си". Сорян, я уже ленту новостей посмотрел за сегодня, больше безумной хуйни я не вынесу.
>> Я назову любую хуйню "AST" и буду её переписывать JS.
>Ты дурак? V8 (JIT-компилятор жиэса) вообще не так работает, можешь глянуть в исходники почитать. Ты голову включи и начни читать посты внимательно. Нет там переписывания термов.
Я пропустил, старые версии AST у тебя святой дух будет очищать из памяти?
>Именно что блядь тоже. Алгоритм есть алгоритм, и его сложность не языком программирования определяется.
Ты сёдня решил без таблеток? Реализация qsort на хаскеле из гугла не имеет отношения к алгоритму quick sort, она же "сортировка Хоара" — это просто другой алгоритм. Читаешь описание сортировки Хоара, смотришь на код qsort под хаскель из гугла. У Хоара банально элементы перенесённые элементы на верхних уровнях оказываются в обратном порядке, а твой filter-sort генерирует массивы с сохранённым порядоком. Так что я хуй его знает, может быть ты сейчас жирафу отвечаешь — я ж не знаю, как тебя там сейчас плющит.
>И то на Haskell работать будет быстрее сишной версии в ряде случаев, так как есть мемоизация.
Пошли истории про "хаскель работает быстрее Си". Сорян, я уже ленту новостей посмотрел за сегодня, больше безумной хуйни я не вынесу.
>>460219 (OP)
Потому что удобно совмещать 2 парадигмы, а не ограничиваться только одной.
Если ты не заметил, языки без фп тоже умирают постепенно. Плюс все фп языки довольно древние, и неудобные.
Но вот почему в древности люди выбрали именно джэву, а не условный ерланг - хз. Наверное маркетинг зарешал. Вот ты бы выбрал язык от гугла, или от сельхоз банка?
Потому что удобно совмещать 2 парадигмы, а не ограничиваться только одной.
Если ты не заметил, языки без фп тоже умирают постепенно. Плюс все фп языки довольно древние, и неудобные.
Но вот почему в древности люди выбрали именно джэву, а не условный ерланг - хз. Наверное маркетинг зарешал. Вот ты бы выбрал язык от гугла, или от сельхоз банка?
>>497568
Сколько бы ни было противно в десятый раз перетирать очередную душную и унылую лыжу про рыночек, который порешал и поэтому прав, с выводом я соглашусь. Я тоже не особо вижу смысла подымать парадигмы на знамена.
>Да и вообще, я не понимаю этого разговора про "ООП", "ФП", "процедурное программирование" — все мейнстримные ЯП давно мультипарадигменные
Сколько бы ни было противно в десятый раз перетирать очередную душную и унылую лыжу про рыночек, который порешал и поэтому прав, с выводом я соглашусь. Я тоже не особо вижу смысла подымать парадигмы на знамена.
>>497991
>>497919
Вы мне напоминаете дидов, которые в айтишку вкатились где то в 90х, а потом году в 2010м на собесах рассказывали, как весело и задорно они соревновались с сишными компиляторами, вооружившись ассемблером. Мол "код на ассемблерах - быстрее". Те из них, кто сохранил адекватность на тот момент, честно признали что битву эту проебали в итоге.
Сравнивать вот так вот в лоб подходы на разных уровнях абстракции - это какой то специальный вид олимпиады блять.
>>497919
>>И то на Haskell работать будет быстрее сишной версии
>Пошли истории про "хаскель работает быстрее Си"
Вы мне напоминаете дидов, которые в айтишку вкатились где то в 90х, а потом году в 2010м на собесах рассказывали, как весело и задорно они соревновались с сишными компиляторами, вооружившись ассемблером. Мол "код на ассемблерах - быстрее". Те из них, кто сохранил адекватность на тот момент, честно признали что битву эту проебали в итоге.
Сравнивать вот так вот в лоб подходы на разных уровнях абстракции - это какой то специальный вид олимпиады блять.
>>460219 (OP)
Куда провалилось?
Куда провалилось?
>>498967
При чём тут асм вообще? Я тебе про Си говорю. Если тебе больше нравится — возьми C++ или Rust. Хаскель — это ЯП со сборщиком мусора и boxed типами по умолчанию, просто одно это уже даёт накладные расходы.
И тут даже скорее дело не в том, что Си оптимизирован под процессоры, а скорее процессоры оптимизированы под Си. Если взять те же TPU для нейросеток, то ими управляют на питоне, и получается норм, потому что 99.99% работы выполняет TPU, а питон просто запускает задачу.
>Вы мне напоминаете дидов, которые в айтишку вкатились где то в 90х, а потом году в 2010м на собесах рассказывали, как весело и задорно они соревновались с сишными компиляторами, вооружившись ассемблером.
При чём тут асм вообще? Я тебе про Си говорю. Если тебе больше нравится — возьми C++ или Rust. Хаскель — это ЯП со сборщиком мусора и boxed типами по умолчанию, просто одно это уже даёт накладные расходы.
И тут даже скорее дело не в том, что Си оптимизирован под процессоры, а скорее процессоры оптимизированы под Си. Если взять те же TPU для нейросеток, то ими управляют на питоне, и получается норм, потому что 99.99% работы выполняет TPU, а питон просто запускает задачу.
>>499911
Не мне, я мимокрок.
Джава - это тоже ЯП со сборщиком мусора и боксингом. Означает ли это что ООП сосет по производительности у процедурки на каком нибудь фортране? Очевидно, нет, потому что есть плюсы как прецедент ООП без боксинга и без GC. Так с чего бы прецедент Хаскеля должен определять преимущество ООП над ФП в производительности?
GC вообще никакого отношения к парадигме не имеет - это всего лишь деталь реализации. Да и давным давно уже программный код по высоте абстракций ушел настолько, что не имеет вообще ничего общего с кодом машинным. Даже тот же си весьма высокоуровневый - за счет оптимизаций компилятора то что пишется в коде совсем не равно тому, что по итогу будет выполняться. ФП в этом плане не меняет абсолютно ни-че-го. Это просто следующий уровень абстракции. Все что по сути он меняет - это привычки нытиков на разработке, которым "ниудобно", и они начинают пускаться в маняфантазии и выдумывать мнимые проблемы парадигмы, типа производительности.
>Я тебе про Си говорю
Не мне, я мимокрок.
>Хаскель — это ЯП со сборщиком мусора и boxed типами по умолчанию, просто одно это уже даёт накладные расходы.
Джава - это тоже ЯП со сборщиком мусора и боксингом. Означает ли это что ООП сосет по производительности у процедурки на каком нибудь фортране? Очевидно, нет, потому что есть плюсы как прецедент ООП без боксинга и без GC. Так с чего бы прецедент Хаскеля должен определять преимущество ООП над ФП в производительности?
GC вообще никакого отношения к парадигме не имеет - это всего лишь деталь реализации. Да и давным давно уже программный код по высоте абстракций ушел настолько, что не имеет вообще ничего общего с кодом машинным. Даже тот же си весьма высокоуровневый - за счет оптимизаций компилятора то что пишется в коде совсем не равно тому, что по итогу будет выполняться. ФП в этом плане не меняет абсолютно ни-че-го. Это просто следующий уровень абстракции. Все что по сути он меняет - это привычки нытиков на разработке, которым "ниудобно", и они начинают пускаться в маняфантазии и выдумывать мнимые проблемы парадигмы, типа производительности.