потому что программирование нужно для программистов, а не для вговнемоченых фантазеров
>потому что программирование нужно для кабанчиков, а не для вговнемоченых пограммистов
пофиксил, а будь воля пограммистов то битрикс бы на хаскеле был с 1.5 фичей
неосиляторы
Какую математику нужно знать для ФП? Я слышал, что в Хаскеле используется теория категорий. Но потом оказалось, что категорий, в математическом смысле, там нет.
Потому что стек не резиновый.
Смешно сказал. В js гораздо больше функциональщины чем в любой си-подобной калосрани.
А Scala потеряла свою популярность? На нее джависты пересаживались.
Ну, она как-бы нахуй не нужна. По факту, что скэйла, что другие языки уровня кложи или окамла с эрлангом - у всех у них одна и та же проблема, а именно убогий тулинг, отсутствие стандартов и проверенная годами библиотека фреймворков, либ и прочего мидлвейра. Эрланг и Кложа гремели в середине нулевых как и Скэйла. Был Валкин со своим Эхо где НикиТонский и прочие писали на кложе и эрланге. Потом был бум скэйлы и на нее на хайпе переходили крутить бигдату через спарк или упарываться в котов и зио. У той же скэйлы до сих пор проблемы с IDE, которая краснит код и выжирает любые ресурсы. В JB целая команда в 10 человек уже больше 10 лет пилит плагин, но он бесконечно далек по уровню качества и набору фич если сравнивать с поддержкой котла или жабы.
Эрланг очень ситуативный и местечковый язык программирования, который в основном юзают как клей между модулями на сишке в телекоме. Есть элексир, который работает поверх BEAM и типа эрланг с синтаксисом руби.
Кложа лисп где не завезли норм IDE и библиотек. Вау эффекта не наблюдается.
Окамл за пределами Джейнстрит и еще парочки хфт фирм нигде не юзается.
Хаскел чисто исследовательский язык и писать на нем какой-нибудь энтерпрайз больно. Либо нужно как Зефиров со штангой приседать.
>js гораздо больше функциональщины
Какой функциональщины гораздо больше?
Потому оно очень далеко от того как работают компуктеры. Процессор не функциональный, процессор императивный, соответственно всё нужно писать в императивном стиле - только тогда ты получаешь адекватно работающую программу.
Как будут функциональные процессоры - так все переедут на функциональные языки.
>>3461478
Ничего там сложного нет, если разобраться и надрочиться. Такое же программирование как и любое другое.
А оно не провалилось никуда. Им не пользуются просто. А не пользуются им потому что рыночек хочет девевого говна для узколобых долбоебов. Именно поэтому никто на сегодняшний день не получает белый ip, не полнимает собственную почту на своём сервере, и не выкупает домен у регистратора. На сегодняшний день все покупают хостинг у конторы, которая всю работу делает за них, предоставляя удобную панельку plesk с кнопками для управления. Гордый потребитель глубоко не копает и думает что он, стало быть сам создал свой почтовый сервер, хотя сервер был настроен до него компанией-хосттнгом, а он даже почтовые службы не нюхал. Вот такой вот мир. Продажа ненужной хуйни узколобым гоям - это основа так сказать. Кабанчик не хочет знать про искусство программирования и тонкости алгоритмов. Кабанчик хочет чтобы кнопка нажималась, а на каком говне эта кнопка работает он в душе не ебет. Поэтому на рыночке закрепляются типовые решения и готовые алгоритмы. Вот ООП это парадигма которая просто предоставляет один шаблонный подход, для решения большинства задач, вот все и дрочатся с ООП.
>>3461536
Глупость. Стек - это особенность компмлятора. К языку это не имеет никакого отношения. Можно написать функциональный язык программирования который вообще бы не использовал стековый фрейм.
Существует ЯП заточенные под рекурсию, в которых на уровне компилятора заведомо придкман обход ситуаций переполнения стека, путём удаления ненужного говна в процессе забивания онного фреймами.
> вообще бы не использовал стековый фрейм.
> путём удаления ненужного говна в процессе забивания онного фреймами.
Не понял. Ты хочешь читать программу с диска, когда стек переполняется?
>Вот ООП это парадигма которая...
Просто была пропихнута как универсальная таблетка в нужный момент, не более.
ООП с паттернами и аджайлом - очень полезная идея для бизнеса, позволяет кабан кабанычу заменить ЧСВшного ботана на толпу дешевых макак-индусов и периодически выгонять их на мороз по мере выгорания.
А от функционального программирования какая ему польза? Оно наоборот повышает порог входа и потому является вредным. Комунячья зараза.
Scala была популярна только из-за ML фреймворка Spark. Сейчас все перешли на петухон.
В js совершенно пизданутая функциональщина, которая порождает адский спагетти-говнокод. Возьми исходники любого фреймворка, ты там ни за что не разберёшься что когда и где происходит из-за адского жонглирования функциями и полного отсутствия статических типов. Это яркий пример того, как делать не надо.
По теме: она не провалилась. Её элементы вошли во все основные ЯП на достаточном уровне.
Этот прав. Работал на проекте где лид фронтенд команды угорал по хаскелю и искал только кандидатов, которые шарили в фп. С трудом нанял одного чела за год. На следующий год кабан почуял неладное и выгнал долбаеба на мороз. В течении полугода был нанят новый лид и команда из 7 человек и проект выпустили в срок
>Оно наоборот повышает порог входа
Ага, особенно когда надо разобраться в иерархии на пять десятков уровней наследования, потому что макаки не слышали про композицию, и кабаныч начинает терять деньги за простой.
https://spark.apache.org/mllib/
Заткни свое гнойное ебло, обосранный скуфиндуй. Нахуй ты лезешь, если не шаришь, гандон?
>А Scala потеряла свою популярность
Да. От скалы сейчас везде стараются избавиться в пользу java/kotlin или сразу пересаживаются на императивный golang.
Почему избавляются? Да потому что оно нахуй не нужно в проде. Функциональщина это юзлесс хуйня для крудописания. Тех же стримов в джаве достаточно чтобы покрыть все кейсы. Или циклы писать (как в Go) во многих случаях будет даже лучшим и более понятным решением.
При этом у скалы очень большие проблемы
- с тулингом (нет нормальной поддержки IDE)
- с обратной совместимостью. При переходе с Scala2 на Scala3 сломали обратную совместимость
И как бы нахуй на таком писать? Это же залупа, вот и все.
Я как раз таки прекрасно знаю, для чего используют спарк. Из первых рук. А вот ты по фразе "со спарка переходят на питон" обосрался и показал нулевое знание в теме. Ещё и мл приплёл.
Ещё раз, не позорься.
Почему провалилось? Фишки оттуда стырили мейнстрим языки.
>Почему функциональное программирование провалилось?
Оно не провалилось, оно живет в той в нише, для которой предназначено - матан (ДС/МЛ) и всякая ETL хуйня. Именно туда ложится парадигма ФП, в рамках которой у тебя данные в программе перетекают из выхода одной функции на вход другой, не мутируя сторонние вещи и ничего никуда не сохраняя. Собственно, в 50-60-х кодинг и был ПО СУТИ (не по форме) своей чисто функциональным.
А в рамках разработки программ, которыми пользуются реальные люди, быстро выяснилось, что у тебя есть всегда есть какие-то сайдэффекты, надо че-то промежуточно где-то сохранить (сторы с объектами появляются), че-то надо отрисовать на экран (сайдэффект), че-то сохраненное надо изменить в зависимости от пользовательского ввода и т.д. И для этого фп уже подходит не очень, точнее не подходит совсем.
Просто до плюсов народ не понимал, что данные и методы для работы с ними удобнее хранить в одном месте, а когда поняли, тут-то фп в рамках коммерческих программ окончательно и загнулось.
> данные и методы для работы с ними удобнее хранить в одном месте
Нет, это неудобно. С этим проблем больше возникает чем плюсов.
>народ не понимал, что данные и методы для работы с ними удобнее хранить в одном месте
А потом как вдруг понял, теперь мы все и ебёмся с разделением состояния и логики.
>Нет, это неудобно. С этим проблем больше возникает чем плюсов.
Если бы это было неудобно, такие языки как C++, Java, C#, Python, Ruby просто не появились бы. А такие PHP не двигались бы в сторону Java.
>>3463237
>А потом как вдруг понял, теперь мы все и ебёмся с разделением состояния и логики.
Ожидаю предложений, как ты собираешься реализовать в рамках строгого ФП элементарный UI.
>такие языки как C++, Java, C#, Python, Ruby просто не появились бы
Появление языков не означает удобство парадигмы, особенно с течением времени и изменением решаемых задач.
Потому что ФП требует хорошей способности в абстрагирование. А дальше все утыкается в прокачанность и обученность кадров в построение абстракций. Обычно с этим скиллом все хорошо у математиков, либо просто у технарей со склонностью к математике, поэтому тот же хаскель, к примеру, очень хорошо прижился в научной тусовке.
В среднем же по больнице этот скилл у вкатунишек развит плохо, к сожалению. Поэтому бизнес делает ставку на гуманитариев, вооруженных паттернами-хуятернами, магическими аннотахами и прочим KISS-DRY-мистицизмом, а функциональные фишки внедряются медленно, ситуативно, но неизбежно.
>Потому оно очень далеко от того как работают компуктеры.
Так это то как раз достоинство ФП и прочих декларативных подходов. Если бы это было проблемой, мы бы все до сих пор на ассемблерах писали. Вместо этого мейнстримные языки программирования становятся все более и более высокоуровневыми. А все потому, что ни один нормальный человек (профдеформированных кодеров за норму не берем) на самом деле не мыслит императивно, в терминах инструкций проца над мутабельной памятью. Все нормальные люди мыслят декларативно, и буквально ни для кого эта низкоуровневая байтодрочь не представляет ценности на самом деле.
Где? Любая статья или иная научная работа по математике последние лет 8 если содержит программу, то она(программа) или на python, или на c++(обычно в таких случаях используются буквально древние библиотеки, написанные 20+ лет назад, писали которые чуть ли не атланты математической мысли).
Функциональное программирование в целом штука весьма специфичная. И беда ФП не столько в мозгах преобладающей массы разработчиков, сколько в том, что алгоритм предполагает задание последовательности шагов, а ФП - это про задание правил преобразования выражений и последующую формулировку выражения, которую потом соответствующая система(будь то интерпретатор или железо) решает по заданным правилам.
Вот, есть те же формулы в excel. Чем не ФП? То же задание переменных(в ячейках) и правил вычисления(когда в ячейке пишут "=формула чего-то там". И все, кто работает более-менее серьезно с excel, таким занимаются.
ФП хорош как теоретическое изыскание и как штука для очень редких случаев, но все то же процедурное/ООП будет лучше.
Блин, вот интересный ты анон. Приводишь в пример максимально успешный эксель как пример декларативного решения вычислительных задач, но тем не менее делаешь вывод, что императиващина - лучше, лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
>алгоритм предполагает задание последовательности шагов
Ну да, щас. А параллельные алгоритмы для тебя - шутка чтоли?
С параллелизмом от этой твоей последовательности вообще остались рожки да ножки в лице гарантий мемори моделей. А на уровнях ниже там одни приколы с публикациями, перестановками и кэшами. Давно уже императивность натянута совой на глобус. В ФП кстати параллелизм на порядки проще и интуитивней для понимания.
На самом деле ты прав. Нет вообще никакого смысла холиварить за ООП vs ФП - по факту все давным давно уже кодят на смешанной парадигме.
Проеб этого лида был лишь в том, что он сам не владел теми принципами, по которым угорал, в должной мере. Иначе бы он в одну харю закрыл проект в срок (видал такие контрпримеры воочию).
Meh. Кабаны обычно в вопросах поддержки кода сами за деревьями леса не видят. Дюже потешно до поры до времени наблюдять за руиной целых отделов разработки, когда те утопают в техдолге, а кабаны пытаются эти проблемы решать чисто кабаньими методами: то раздувают штат, то наоборот сократят нахуй, а воз и ныне там...
Жаль, что в итоге из-за этого негативного опыта им оказывается проще просто не связываться никогда больше с in-house разработкой, и они в большинстве своем просто отдают ее на аутсорц унылым заебанным рабам. Мы проебали все полимеры.
>лучше, лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
Такого вывода мною сделано не было
> А параллельные алгоритмы для тебя - шутка чтоли?
Это тоже задание последовательности действий. Другое дело, что эти действия происходят параллельно другим действиям.
>В ФП кстати параллелизм на порядки проще и интуитивней для понимания
Нне спорю.
>лишь на основании того, что никто тебе примера серьезного проекта на хаскеле не приведет.
Ранее мною было написано, что такого утверждения мною не делалось.
Мною была лишь написана просьба показать пример серьезно проекта на haskell.
>Это тоже задание последовательности действий.
Ты мягко говоря преувеличиваешь, утвердждая что это - то же самое. Все таки параллелизм и многоядерные процы серьезно перекроили разработку и проектирование в свое время.
Кроме того, задание последовательности между двумя кусками ленивых вычислений было в том же хаскеле из коробки буквально все время его существования в лице монады IO, в то время как в джаве и позже в плюсах пришлось городить нетривиальные в изучении мемори модели, чтобы привычная коболистам тех времен императивщина поверх глобального состояния не множила на ноль оптимизации. Что характерно, моделями памяти все не ограничилось, и мейнстримные языки обрастают абстракциями разной степени кривизны и по сей день, при этом все как одна заимствованы из ФП.
Так что еще хз кто из этих двоих был более специфичен на тот момент.
В любом случае параллелищм не противоречит изначальному утверждению о последовательности действий.
Хоть многоядерность, хоть многопточность, хоть многозадачность... - все это упирается в наличие последовательности действий.
>Кроме того, задание последовательности между двумя кусками ленивых вычислений
А это тут каким боком? Про ленивые вычисления и слова не было.
>в то время как в джаве и позже в плюсах пришлось городить нетривиальные
Поверх чего там работает функциональный язык? Поверх интерпретатора или железа. Но и то, и другое подразумевают последовательность действий. И, по сути, как ранее было мною написано ранее, все ФП просто приводится к обработке выражения/строки по заданным правилам(те самые функции и прочее).
Программистишки сами виноваты, что оказались терпилами и еще в 90-х прогнулись под ООП, паттерны, аджайл и недоязыки вроде петухона.
Нерды вроде Линуса Торвальдса или Джона Кармака кабан кабанычам больше не нужны.
>>3463986
И хули толку то, что все упирается в последовательность? Ты давно уже даже на мейнстримных языках эту последовательность на самом деле не пишешь и не видишь - после многопоточки что компиляторы, что виртуальные машины обросли таким слоем оптимизаций, что императивный код который ты пишешь на условной джаве или питоне, с реальными машинными инструкциями и их порядком на железе не будет коррелировать от слова никак. Если тебе и оптимизаций мало, прибавь к этой картине фреймворки.
Буквально никому не всралась твоя последовательность уже сегодня. В гробу ее все видели и похоронили 30 раз за тысячью слоев абстракций...
И какой смысл тогда продолжать натягивать эту сову на глобус? ФП от современной императивки отличается лишь тем, что оно по высокоуровневости разработки просто зашло еще дальше, со всеми вытекающими и подводными. Вот и вся разница.
>А это тут каким боком? Про ленивые вычисления и слова не было.
Я просто отметил, что в функциональной парадигме никогда не было проблемы запилить цепочку последовательности там, где она уместна (а где не уместна, не пилить ее). Отрицальщики часто любят приписывать функциональной парадигме какие то рандомные фейковые грехи, типа что с ней хуево там, где стейт и сайдэффекты, мол, или что на функциональных языках, типа, последовательные алгоритмы тяжело лабать... Хуета все это, вранье от незнания. Все там всю дорогу было.
Наврядли. Функциональную парадигму языковые модели пережевали бы еще жосче, скорее всего.
Вообще, я бы поверил в перспективы вайбкодинга на условном хаскелле гораздо охотней, чем в высеры кое как типизированных скриптосеров.
Чатгопота идеально заменяет программистишек там, где от них требуется копипаста со StackOverflow и тупое обезьянничанье по паттернам (вся эта зубрежка на собесах про "уровни изоляций транзакций" и "типы бинов в Spring") без понимания как это работает. А началось все с "инкапсуляции" в ООП - я тупой дебил, не знаю, что там в черном ящике, но умею дергать нужные методы.
Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область. Программист был и тимлидом, и аналитиком, и кодером одновременно. Заменить такого мог бы только сильный ИИ, которого в обозримом будущем не предвидится. Там, где можно было генерить какие-то простые скрипты на Лиспе, это уже делалось.
>А началось все с "инкапсуляции" в ООП - я тупой дебил, не знаю, что там в черном ящике, но умею дергать нужные методы.
Ой, да полно тебе бухтеть на ровном месте. ФПшка по высокоуровневости абстракции еще фору ООПшке даст так то.
>Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область
Кто ему нынче даст эту подготовку, камон? Системы массового образования большинства "цивилизованных" стран давным давно заруинены в пользу подготовки рабов для корпоратов, а корпоратам в свою очередь нахуй не всрались кадры, которые ты хуй заменишь. Каждое новое поколение тупее предыдущих. И из всей этой шкурной кодлы гондонов на капиталах, готовящей прямо сейчас всех нас в лучшем случае к скотскому BLM-LGBT существованию без цели, в худшем - к тотальному пиздорезу и утилизации буквально ради замены на ничтожеств без достоинства, вооруженных нейронками, которые при всей их тупости уже умнее этих ничтожеств, ты предьявляешь предьявы морально забитым под шконку промытым кодеркам?
Ты хоть с какого года сам то кодишь, чтобы такие громкие предьявы кидать?
>Буквально никому не всралась твоя последовательность уже сегодня
И поэтому ты продолжаешь доказывать обратное.
>давно уже даже на мейнстримных языках эту последовательность на самом деле не пишешь и не видишь
Вижу и пишу:
A a(аргументы для конструктора);
a.имяМетода();
>ФП от современной императивки отличается лишь тем, что оно по высокоуровневости разработки просто зашло еще дальше, со всеми вытекающими и подводными.
Про какую-либо разницу речи вообще не шло. Ты просто наращиваешь объем текста. Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле), но ты умудрился заглянуть во все места, кроме тех, куда заглянуть надо.
В целом я тебя понял. Дальше отвечать не буду.
>Раньше от программиста требовалась серьезная математическая подготовка, знание алгоритмической базы и умение вникнуть в предметную область.
Возможно, такое было лет 30+ назад, но сейчас все намного проще стало. Да и надо ли веб-программисту знать про алгоритмы сжатия, про циклические многочлены или про теоремы из теории графов?
>Системы массового образования большинства "цивилизованных" стран давным давно заруинены в пользу подготовки рабов для корпоратов
Тема очень обширная и фундаментальная. В прикладной области сей анон ближе всего подошел к сути – корпорастам до пизды, на чём писать, если писать на этом могут одноклеточные макаки. Ни сложные императивные, ни сложные функциональные, ни тем более сраное ООП в виде smalltalk им не нужно. Им нужно хуяк-хуяк – и в продакшен.
Я заявляю, что западная экономика обеспечила уверенное отставание айти где-то лет на 20. Вот сейчас всё айти работает на алгоритмах-инструментах начала нулевых.
Кроме нейросетей, нейросети перепутали карты. Они всё равно говно, но в отсталой западной академической среде их не должно было возникнуть, коммерсы бы просто продолжали впаривать друг другу прокисшее говно.
Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина? Пока вы спорите о сортах говна – рандомные челы, имён которых здесь даже никто не знает, создают что-то вообше не похожее на старое.
Хотя, наверное, decoder-only transformer ближе к рекурентной функции.
Мимо анон со стэком из delphi, js, python, c/c++, haskell.
поэтому мне показалось, что код на фп языках проще изменять и переиспользовать. конечно, во многих языках есть фичи из фп, но не на том уровне, что в самом фп.
ооп реальное вроде джавы и сишарпа не юзал не было нужды. даже не знаю какие у них юзкейсы, сишарп наверное что-то с виндой и юнити, а джава для майнкрафта? на фп юзкейсы нашлись, на них оказалось удобно писать парсеры, только поэтому их и стал копать.
Потому что ФП это программирование ради программирования. Эстетическая дрочка математиков, у которых мир построен на функциях. А пк устроен по другому, программирование нужно для создания продукта. Продукт ключевая цель, а не код. Ну и сам процессор устроен под процедурное программирование (кстати неопытные думают, что процедурное программирование есть ФП, мол там же функции только. Но ФП это совсем другое, там даже состояний нет, что уже звучит как абсурд для реального мира).
>Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина?
Это буквально ни то, ни другое. Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд и легализованная коллективная некомпетентность. Считать это недоразумение развитием методов разработки ПО попросту нелепо. Скорее уж это погибель. Как айтишки, так и здравого смысла вообще.
>Ну и сам процессор устроен под процедурное программирование
Выше уже обсудили это. Нихуяшеньки это не причина, и вот вообще ни разу не проблема.
>Но ФП это совсем другое, там даже состояний нет
Чушь. Работа с состоянием в ФП - вообще не проблема, все инструменты для этого в парадигме имеются. Обычно про ФП без состояний говорят новички, которые прочитали первые несколько глав какого нибудь "learn you a haskell for greater good", преисполнились чистотой, промылись и идут евангелизировать в команды: как грится, когда в руке молоток - все кажется гвоздем. Так и сложился стереотип. А тема ФП тем временем гораждо глубже.
>Покажите хотя бы один серьезный проект на haskell
Очевидный pandoc.
>Эстетическая дрочка математиков, у которых мир построен на функциях
Ой, этот холивар, кстати, еще старее тебя самого будет.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле)
Это буквально самый ничтожный из твоих тезисов. Литералли "сперва добейся". Нахуя это комментировать, я не особо понимаю.
Ты всю дорогу начиная отсюда >>3463888 почему то гнешь линию, что это проблема парадигмы в том, что проектов на ней мало. Типа - весьма специфичная она. Что на самом деле полная чушь. На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты, и школа ФП-разработки так и не популяризовалась. Вот и все. Императивщиков и функциональщиков учат слишком по разному. А коболистам прошлого (императивщикам по своей сути) оказалось просто западло переучиваться с нуля - ООП стал их выбором лишь потому, что на ООП оказалось проще переложить привычное им процедурное программирование. В итоге так и повелось, что от аланкеевского ООП остались рожки да ножки, а классы в современном ООП по факту выродились тупо в сборники процедур (сервисы) либо кортежи данных (стурктуры). Прав тот анон выше (>>3464231), что отметил про отсталость айтишки. Только я бы оценил это отставание не в 20 лет, а лет в 40.
>требовалась серьезная математическая подготовка
да, гладкие многообразия, векторные расслоения и пучки очень нужны программистам.
Программистам даже калькулюс и 80% линейной алгебры не нужно вообще. Какая серьезная мат подготовка?