потому что программирование нужно для программистов, а не для вговнемоченых фантазеров
>потому что программирование нужно для кабанчиков, а не для вговнемоченых пограммистов
пофиксил, а будь воля пограммистов то битрикс бы на хаскеле был с 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% линейной алгебры не нужно вообще. Какая серьезная мат подготовка?
>В итоге так и повелось, что от аланкеевского ООП
Он не придумал ООП, если что. ООП ещё в Симуле было, до Смолтолка. И не в том виде, в котором фантазировал первый.
>надо ли веб-программисту знать про алгоритмы сжатия, про циклические многочлены или про теоремы из теории графов?
Надо, когда он начнёт писать свои костыли. А он ведь начнёт...
>Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд
ТЫ ЧО, ПЕТУХ?!?!?! АЙТИ ФСЁ, ПРОГРАММУНЫ НЕ НУЖНЫ, ВИДЕЛ СОКРАЩЕНИЯ????? ЩА АИШКА КОДУНОВ ЗАМЕНИТ, БУДУ НА ВАЙБКОДИНГЕ ГТА6 ПИСАТЬ, МИРОМ УПРАВЛЯТЬ!!!111ЁЁЁЁЁ
Большинство современных веб-пронраммистов будут тупо до последнего просить нейроку сделать нужное. А потом таких просто выкинут.
> На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты,
Ага, карты легли так, что ФП безумно далёк от оборудования и требуется проебать кэш процессора будто его никто и не изобретал.
Не получилось, карты легли неправильно, просто не повезло. Разве у этого могут быть реальные причины?
Ой, да кто бы говорил... Лицемер. Про кэш он вспомнил, смотрите на него...
Ты об этом кэше так же ни разу не вспоминаешь, кодя на каком нибудь питоне или джаве, и миссишь его при каждой оказии. И ничего - не сдох.
> А ВОТ У ВАС!11
И в жабе, и в питоне есть куча библиотек для работы с плотными массивами. Можно даже в строки захуячить данные и делать итерацию по строкам и это будет работать с кэшем. В ФП работать адекватно с кэшем принципиально невозможно, парадигма такая.
Пока не будет создан процессор который данные и код хранит в одной и той же ячейке как в мозге человека - ФП бесполезно. Но чет я не уверен что это будет эффективнее современной архитектуры с кэшем - расстояние между ALU и кэшем меньше чем в маняфантастичном ФП-процессоре.
>В ФП работать адекватно с кэшем принципиально невозможно, парадигма такая.
Ты скозал?
Потешный ты лицемеришко конечно. Как же ты любишь говорить за других инженеров - что им проще, и что им невозможно.
>Пока не будет создан процессор который данные и код хранит в одной и той же ячейке
Нет вообще никакой проблемы сгенерить императивную цепочку вычислений по декларативному коду, мань. Всю дорогу все так делали. Если ты так предвзят в отношении ФПшки, что не способен это осознать, можешь рассмотреть феномен SQL, который сам по своей сути максимально декларативный, и по которому СУБДшки вполне себе успешно строят императивные планы выполнения. Твои современные уютные языки программирования в этом плане - такая же высокоуровневая надстройка, так же далекая от реального железа с его особенностями и кешами. Разницы - буквально никакой.
> Ты скозал?
Да, я. Оспаривай.
> Потешный ты лицемеришко конечно. Как же ты любишь говорить за других инженеров - что им проще, и что им невозможно.
Какие инженеры, отсталый? Что ты несешь? Парадигма запрещает сайдэффекты, а работа через с внешним массивом данных это один здоровенный, глобальный, сайдэффект.
> Нет вообще никакой проблемы сгенерить императивную цепочку вычислений по декларативному коду, мань.
Можешь на что угодно раскладывать, но работать с кэшем команд и с кэшем данных ты не сможешь, а значит идёшь нахуй.
> SQL
Кал для дегенератов-менеджеров, был придумал таким, был создан таким, получилось ущербное говно от которого все избавляются.
> Разницы - буквально никакой.
Если ты тупоголовый кретин который не осилил базу работы компуктеров и хранения данных - безусловно.
>Какие инженеры
Такие, лицемеришко. Сам, небось, на джаве максимум круды писал, а пиздишь так, будто JVM-кишки мейнтейнишь, аки Леха Шипилев.
>Парадигма запрещает сайдэффекты, а работа через с внешним массивом данных это один здоровенный, глобальный, сайдэффект.
Так ты квадратногнездовой, хули, у тебя в башке парадигма приколочена к рантайму, блять. Если тебе парадигма запрещает сайд эффекты, это вообще ни разу не означает, что их не может быть в принципе. Ты тупо не шаришь о чем говоришь.
>SQL
>Кал
Ясно, лол. Нахуй было спорить с неадекватом-джуном в отрицалове...
>SQL
>от которого все избавляются
Чё-то ты не очень разбираешься, пирожок...
>>Напомните мне, нейросети – это ФП, ООП, процедурщина, императивщина?
>Вайбкодинг вообще не парадигма разработки - это тупо концентрированный абсурд и легализованная коллективная некомпетентность
Я правильно понимаю, что для тебя женщина — это пизда на ножках? Почему ты автоматически относишься к вещам в духе "как им пользоваться", а не "как он устроен"? Ты меня огорчаешь.
>>3464653
>>Изначально речь шла про вопрос наличия хотя бы одного серьезного проекта на ФП(хаскеле)
>Это буквально самый ничтожный из твоих тезисов. Литералли "сперва добейся". Нахуя это комментировать, я не особо понимаю.
Сорян, не соглашусь. Хаскель спроектирован так, чтобы на нём было невыносимо тяжело делать полезные продукты. Я вижу охуительную ценность в идее, в том числе FRP, которое нынче там массово популяризовано в пародии на Elm под названием React.js. Но реализация в виде ЯП Haskell — это пиздец полный, этим невозможно пользоваться.
>На самом деле ФП не получила должного уровня развития лишь потому, что так легли карты, и школа ФП-разработки так и не популяризовалась.
Лисп был №2 языком в индустрии совсем недавно. Можно строить теорию, что "просто лисп был не очень , а вот хаскель...", но правда в том, что индустрия уже отказалась от лиспохаскелей и не собирается к ним возвращаться ни в какое ближайшее время.
>Такие, лицемеришко. Сам, небось, на джаве максимум круды писал, а пиздишь так, будто JVM-кишки мейнтейнишь, аки Леха Шипилев.
Интересная фантазия. Ты так фантазируешь потому что ты на фп лапшу пишешь?
> Так ты квадратногнездовой, хули, у тебя в башке парадигма приколочена к рантайму, блять.
Рантайм не может волшебным образом понять в каком месте глобал нужно создавать и можно разложить весь ФП в один кусок кода, а в каком нет.
Впрочем, можно создать такой рантайм, например ECS, который на какому-то уровне абстракций будет ФП. Но в таком случае ФП будет костылём который добавляет больше кода, лишняя мозгоебля.
> Если тебе парадигма запрещает сайд эффекты, это вообще ни разу не означает, что их не может быть в принципе. Ты тупо не шаришь о чем говоришь.
Т.е. ты хочешь послать нахуй ФП и хуячить глобалы? О ну да, это и есть то самое функциональное программирование. Как я сразу не понял.
> Ясно, лол. Нахуй было спорить с неадекватом-джуном в отрицалове...
Что ещё ты про меня придумаешь, калоедище?
>>3465986
В реальность давно выходил из манямирка? Тут это, KV больше 80% рынка заняли, слышал?
Как там тебе в 2010 году живётся? Тоже хочу, ебанёшь мне машину времени?
>В реальность давно выходил из манямирка?
Я вот живу в ней. И везде для обработки данных добавляют (верней, уже давно добавлен) как раз SQL почему-то.
>KV больше 80% рынка заняли
Странно, ты уверен, что это не ты застрял в 2010? В реальности все уже давно поняли, что отказ от SQL был ошибкой и быстро переобулись назад. А у тебя тут KV, NoSQL и прочее до сих пор в почёте...
>KV больше 80% рынка заняли
Какие конкретно? Кафки и редисы с мемкешами — это не БД.
> В реальности все уже давно поняли, что отказ от SQL был ошибкой
Ох уж этот маркетинг скульлахты, из каждого утюжка рассказывают что KV были ошибкой
>>3466105
Да, я и говорил про БД. Может 80% это слишком, но вот утверждение что более 70% это NoSQL по факту там внутри всегда kv, так что пусть будут kv это правда
Ошибкой был не "KV", а попытка заменить им всё подряд. Большую часть данных сейчас (да и всегда) хранили не в KV в любом случае. Так что нет никаких "70%".
>Но реализация в виде ЯП Haskell — это пиздец полный, этим невозможно пользоваться.
Мы можем просто остаться при своих мнениях. Я так то не спорю, что кодить на хаскеле невыносимо, но все же считаю, что это все же из-за того, что под него надо переучиваться чуть ли не с нуля нахуй - он беспрецедентно строгий и не прощающий костылей (лиспы в этом плане не такие душные, да), и его инструментарий на фоне мейнстрима - откровенно куцый. А уж если у тебя еще и есть мейнстримный опыт за плечами, надо прям неебически переступить через себя чтобы смочь сделать на нем хоть что то и относиться к парадигме непредвзято. Поэтому этого и не случилось.
Как я выше и сказал - так легли карты.
>но все же считаю, что это все же из-за того, что под него надо переучиваться чуть ли не с нуля нахуй - он беспрецедентно строгий и не прощающий костылей
На Rust мне не нужно переучиваться "чуть ли с нуля нахуй", но я его так же не люблю за бессмысленную сложность кодописания. Просто за невозможность композиции чистых и грязных алгоритмов уже разрабов хаскеля нужно было расстрелять нахуй — они вместо этого придумали монаду Reader, которая просто сделала весь этот пиздец ещё более сложным.
Rust это те же яйца, только в профиль. Rust задирает планку своим борроучекером, который тоже беспрецедентен по своей сути, и тоже строг и требователен.
>Просто за невозможность композиции чистых и грязных алгоритмов уже разрабов хаскеля нужно было расстрелять нахуй
Понимаю эту фрустрацию. Поэтому на практике миксованные подходы вида "functional core, imperative shell" вполне себе прижились. Цимес впрочем в том, что imperative shell все более и более утончается.
Да-да, скульлахта, всё это ошибка и вообще никто не пользуется. Держи в курсе.
>>3466192
> Поэтому на практике миксованные подходы вида "functional core, imperative shell"
Скорее наоборот. В ядре дикая императивщина с чистыми функциями которую понимают только избранные, а внешние интерфейсы это какой-то микс из говна, палок и фп-кала, чтобы кодомакаки могли что угодно из какого угодно кала собрать, а фп для корпоблядей, чтобы тестировали любой кал до посинения.
>В ядре-хуядре...
Вот че ты влез опять, затычка в бочке? Ты же в упор не высекаешь, о каком core и shell выше идет речь, как выше в упор не высекал отличия парадигмы от рантайма - а все лезешь и на говно исходишь. Иди уже, проветрись, малой - тут дискуссия не твоего уровня. Друг другу мы все сказали уже.
>дикая императивщина с чистыми функциями
Вы только посмотрите на него.
Так расскажешь мне про свой магический рантайм, который волшебным образом будет разбирать всё правильно? Примеры покажешь?
>>3466246
>>3466259
>>3466263
Как же ФП-петушки стремятся доказать свою нужность и важность. Даже жаль вас немного, опущи от мира программирования которых оставили на задворках истории.
Зачем ты приплёл используемые СУБД к ФП, а теперь даёшь заднюю?
>Нiiiiiiiiт! Это ни я прилюдно сру себе в портки, это мне функциональщики сайд эффектов подбросили! Уииииии!
Ой да полно те. В айтишке есть миллион вещей, которые не решают буквально ни одной проблемы, но тем не менее прижились и пользуются популярностью.
Вон одни ORMы только чего стОят.
Ты даун? Про SQL завизжал ФП-даун, а я его сразу же осадил, указав на ненужность SQL.
>>3466288
Почему я, как императивный гигачад, должен переживать о сайдэффектах?
Понятия не имею. Одному тебе известно, зачем ты так унижаешься.
Зачем ты проецируешь свои бесконечные унижения на меня, фп-чушка?
Я? Нихуя. Мне вообще на тебя похуй начиная с этого >>3465930 момента. Я с лиспоаноном общался, пока ты не вклинился с какой то шизоидной пастой, над которой полтреда покекало. Казалось бы - ну похуй тебе на ФП: выйди из треда, не позорься - имей блять самоуважение.
Нет, снова и снова императивный селюк прилюдно срет себе в шаровары. Нахуя?
Сколько оправданий, лол. Это у тебя рефлекс выработался от бесконечных унижений, фп-чушка?
>>3466317
>довн понял, что жидко обосрался, и пытается толсто троллить, лишь ещё больше размазывая говно по обосранной жопе
В голосину с этого дебича.
>указав на ненужность SQL
Перейдя при этом на обсуждение СУБД... Ты сам-то свои сообщения читаешь?
>>3466320
Клоунада фп-чушек продолжается. Больно вас попустили всем тредом, что вы перешли на визги и плач, да?
>>3466323
Что ты несешь? Впрочем, не отвечай, мне поебать на бред в бошке очередного обиженного жизнью любителя хлебать борщи.
Бля, вангую это NodeJS-селюк с синдромом утенка на монге. Зато сколько гонору то было - "кеши процессорные"...
>Что ты несешь?
Прочитай свои сообщения. Тебе писали про язык, ты сразу же перескочил на тип используемой СУБД, чтобы попытаться оправдать "ненужность" языка. Ты ошибки в логике здесь совсем не видишь?
Опущенный опять пустился в фантазии о своём враге. Что ещё остаётся, не по делу возражать, на такое нужно мозги.
Скажи честно, ты в состоянии воспринимать реальность? Не испытываешь с этим проблем?
Забавно что профессионально кодить с начал с 2006 года. И тогда был дикий холивар в пхп как кодить - ООП или по старинке процедурно. Забавно что второй вариант с массивами и функциями был куда гибче, а сторонники ООП были настолько глупыми что не могли объяснить реальные плюсы ООП, кроме завуалированного понравившегося вызова через.точку()
В общем, сложилось впечатления что основатели ЯП чето понимали за программирование, а модные молодежные подрожатели джава хотели ООП (в динамичном языке, лол). И в итоге пхп пошел не туда и заслуженно умер.
Другой забавный случай, что в те года питонщики, коих было 1,5 штуки, надсмехались над пхп, хотя у них на то время было еще хуже, ибо пхп 5 был уже как жаба
>Выше уже обсудили это
Кто будет читать высер малолетних вкатунцов на каникулах, которые нахватались с ютуба?
>Нихуяшеньки это не причина, и вот вообще ни разу не проблема.
Именно так, в неразбавленной ФП по сути нет пошагового выполнения. Поэтому абстрагирование первых языков происходило именно в такой парадигме (перфокарты, машинный, ассемблер, си и подобные). То есть, само железо навязывало такое развитие и неожиданно человеку такое удобнее.
>Обычно про ФП без состояний говорят новички
Понимаешь, истинная задача ФП это возможность самоутвердиться программисту на своем типа скилле. Поэтому если ты начинаешь тянуть "разбавленное ФП" которое уже адаптировано под железку, умеет какие-то абстракции под состояние, это уже не тру ФП и вообще для детей.
Проблема ФП что оно не создано практичнее решать задачу, оно создано чтобы макака могла подрочить на себя.
>Появление языков не означает удобство парадигмы, особенно с течением времени и изменением решаемых задач.
А что оно означает? Как у тебя за последние 20 лет изменились задачи?
>Нерды вроде Линуса Торвальдса или Джона Кармака
Так это ж литералли челики, вся карьера которых - это императивная низкоуровневая дрисня. Особенно забавно, что именно их ты привел в пример, ведь найти сколь-нибудь известного успещного ФПшника не получилось, лол.
Как мы ловно переобулись с
>данные и методы для работы с ними удобнее хранить в одном месте
до
>в рамках строгого ФП
>Забавно что второй вариант с массивами и функциями был куда гибче
Так и есть. Только все таки не функциями, а процедурами.
Вообще, хз, какие там сторонники ООП были. Как кодили все на процедурах, так и кодят по сей день. Только вместо классического процедурного модуля сейчас - классы-сервисы, а вместо сишных инклюдов - инжекции DI-контейнеров. Вот буквально никакой разницы по итогу. Только больше оверхеда и больше бройлерпрейта.
> а модные молодежные подрожатели джава
Не они первые. Джаваны подражали страуструповой клике, которая уже тогда была мейнстримом в полный рост.
>А что оно означает?
Означает попытки заткнуть проблемы прошлых инструментов, сохраняя при этом похожесть на них. Удобство здесь стоит не на первом и даже не на втором месте.
>Как у тебя за последние 20 лет изменились задачи?
Мы ушли от разработки ПО, данные которого меняются редко (десктоп, форумы) в сторону ПО, которое работает или с очень часто обновляемыми данными, или с данными в реальном времени. Отсюда появились всякие MapReduce (забавно, что название как раз из ФП взято) и прочие фреймворки для работы с данными, у которых основные принципы ФПшные.
Раньше в пхп еще код писали в 1-2 человека и реальный выигрыш в виде инкапсуляции внутренней изменчивости (модульности) и контракты (интерфейсы) не ощущались (да и из-за отсутствие статики ООП было как пятое колесо).
В целом, ООП оказалось не серебряной пулей, но хорошо когда есть возможность на нем писать (но только в статично типизированном языке, а не этот цирк бреда). Поэтому холивар можно закрыть в пользу мультипарадигменных языков. В дотнете вообще есть F# и С# в последнем вообще сделали возможность как скрипты запускать.
https://dev.to/levu74/tutorial-running-your-c-code-without-a-project-file-49nk