что зачем и почему

OOP или FP?

Императивное программирование.

Да, нет. Я как бы намекнул, что двоичная логика - это сильное упрощение для людей с квадратично-гнездовым мышлением, так как по-мимо двух состояний всегда есть МИНИМУМ еще промежуточное. И мышлление у нас визуальное… Мы в воображение все идеализируем. Ага вспоминаем задачи про пять яблок, а не про сложение абстрактных двух чисел. У нас из всех чувств только зрение хорошо развито, а остальные недоразвитые. Вспоминаем детские рисунуки. Что там видим? - Геометрические примитивы, те мы разбиваем все что видим на кружки, линии, многоугольники… Ага видеокарта такая. У вот у мозг по-большей части GPU, которое входе эволюции научилось что-то помимо полигонов обрабатывать… К чему я веду… Можешь назвать каких-то выдающихся не знаю физиков, математиков, писателей, которые родились слепыми и чего-то достигли… Вопрос риторический => мышление связано со зрением, с визуализацией слов, у тебя в голове существуют какие-то идеальные образы стула, стола, монитора и тп… И там еще мы научились и физику просчитывать каким-то надмозгом. Когда ты представляешь стул, то не представляешь как на нем будешь летать. И вот мы доходим до программирования… В общем программирование - это творчество, если у тебя есть способности к рисованию, к литературе… да просто развитое воображение… Расскажи лучше как функциональное программирование интеллект то разовьет? Ты если дураком родился, ты им и умрешь. И что точно, так это то, что люди с бинарной логикой в бошке - это идиоты такие же как придурки в комментариях на кажом сайте новостей.

Троичная логика, визуальное восприятие, развитие интеллекта — это все очень интересные вопросы, но при чем тут функциональное программирование? %) Где причинно-следственная связь?

Расскажи лучше как функциональное программирование интеллект то разовьет?

Да элементарно, Ватсон!
FP - это как получить похожий результат другим способом. Что даёт построение новых нейронных связей. Если тебе нужны исследования, то в свободном доступе можно найти альтернативу, проведённую на людях, знающих более одного языка (и проанализированы сами языки, Русский, Английскиий, Немецкий etc).

Когда ты представляешь стул, то не представляешь как на нем будешь летать.

Ну вот ТАК писать не надо. Образ напрямую связан с контекстом, голого стула у тебя в памяти нет. Когда тебе надо сесть, то ты не думаешь, а тянешься к стулу или просто задом на любую поверхность. Сознание включается на уровень мышления только тогда, когда сесть охота, а свободных стульев нет. Т.е. надо решать задачу.

Какая парадигма преобладает?

OOP. Какие бы условия про умных людей не ставились) И да, уже сказали, что OOP не исключает FP. Могу еще добавить, что если ты сделал замыкание, или там вызвал map в джаваскрипте, то это еще не FP.

Могу еще добавить, что если ты сделал замыкание, или там вызвал map в джаваскрипте, то это еще не FP.

а что тогда FP?

Ты, как ОП и расскажи)

Ну давай возьмем из википедии

In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.

Во-первых, есть композиция функций, во-вторых декларативность.

Не говоря уж о сути «map values to other values, rather than a sequence of imperative statements which update the running state of the program»

а где тута pattering match?

Pattern matching есть например в расте, который вроде как на бумаге мультипарадигменный, но на нем чото пишут в императивном стиле. С паттерн матчингом.

Ок, многие ЯП сейчас юзают (противным голосом) «илименты фе-пе». В императивном стиле.

а Lisp мультипарадигменный? А на нём пишут? А .Net?
А как быть с крестами или Smalltalk? Так messages или наследование?

паттерн матчинг это ж if вездесущий. не есть оно ФП.

Во всех современных языках двоичная логика… Она противоестественна, но проста в реализации. А дальше уж рассуждения идут что-то основанное на чем-то в корне неверном что-то развивает. Ну ты можешь заучить какие-то паттерны, которые позволяют решить ту или иную проблему, но количество нейронов в твоем мозге от этого не изменится. Я веду к тому, что «выше головы не прыгнешь», у тебя есть «талант» от рождения (бога) либо его нет. А что там переменные вдруг стали неизменны и надо перестраивать ранее заученные трюки под это ограничение. Как оно умнее тебя сделает?

Нейроны не отрастут, а связи между ними - легко, как от любого обучения новому. Решение «ненужных» задач это прокачка силы воли, вдобавок.

где-то связи отрастают, а где-то отваливаются и ты что-то забываешь. это рассуждения ни о чем все тупо своидится к размеру мозга, лобных долей, количеству нейронов в коре

Забываются мелочи, зато общий навык остаётся. Примерно как научившись играть на гитаре не забываешь, как кататься на велике.

Я забыл, например, как в блендере модельки лепить. С велосипедом пример неудачный, потому как до определенного возраста тебе сложно даже ходить не «подпрыгивая», а равно и держать равновесие

OOP или FP?

Да просто херачь код.

Всё время хреначу ;}

Консоль твоя с | и разными грепами седами и прочими xargs это чистый fp

Силён!

OOP или FP?

Зависит от языка программирования. FP удобнее для программиста, но значительно тяжелее для компилятора. И если писать на FP на языке, который его не поддерживает (например, Си++), будут адские тормоза.

То есть, если производительность некритична, то можно выбирать Haskell (если задача ложится на его систему типов) или какой-то из лиспов, например Racket (если нужна максимальная гибкость).

Если же производительность критична или надо писать для браузера, то только ООП.

Если же производительность критична или надо писать для браузера, то только ООП.

Странное утверждение. А почему Racket а не, допустим, CL?

Странное утверждение.

В С++ и JS ООП намного быстрее, чем ФП.

А почему Racket а не, допустим, CL?

Потому что CL намного более мультипарадигменный и это отражается на библиотеках. Там, где в Racket будут замыкания, в CL вместо них будут CLOS, макросы, динамические переменные и переопределение таблиц чтения. Один универсальный setf чего стоит (в Racket использование set! не приветствуется).

Я когда переходил с CL на Racket первые полгода пытался переизобрести «недостающие» библиотеки. Потом нашёл аналоги всего, что в CL активно используется, но к тому моменту понял, почему оно не нужно.

В С++ и JS ООП намного быстрее

Да ты …

А в шарпе, в шарпе быстрее? А то, понимаешь, сборщик мусора…

Потом нашёл аналоги всего, что в CL активно используется, но к тому моменту понял, почему оно не нужно.

А вот это интересный опыт. Ты бы статью, если есть время, закинул. Мне, да и большинству, было бы интересно.

А в шарпе, в шарпе быстрее? А то, понимаешь, сборщик мусора…

Дело не в сборщике мусора. А в том, будет ли разработчик компилятора заморачиваться, чтобы хвостовая рекурсия превращалась в цикл, набор фильтров и отображений на коллекции не копировал всю коллекцию на каждом шаге, композиция функций компилировалась, и прочие оптимизации, необходимые для функционального программирования.

Разработчики компиляторов C++, C#, JS предполагают, что программист будет писать в стиле ООП и именно его оптимизируют. Кстати, SBCL тоже.

А вот это интересный опыт. Ты бы статью, если есть время, закинул. Мне, да и большинству, было бы интересно.

Вот про подход к ФП: Почему в scheme не любят set! ?

Вот общий вывод: Анализ пользователей Common Lisp и Racket .

О, за ссылки и разъяснения спасибо. Steel bank что? Я не понял, что тоже?

О, за ссылки и разъяснения спасибо. Steel bank что? Я не понял, что тоже?

Тоже оптимизирует CLOS и defstruct, а не цепочки функциональных вызовов. Быструю программу приходится писать с setf. В Racket всегда есть функциональная альтернатива без потери скорости. Зато ООП в Racket имеет очень существенные накладные расходы (и используется только в графическом пользовательском интерфейсе).

Кстати, неплохая поддержка ФП, оказывается, есть в Rust:

https://github.com/brianwow/zero-cost-abstraction

https://habr.com/ru/articles/482318/

Хм. Я то думал, что с каждой версией компилятора это учитывают.

Rust поделил сообщество на разные лагеря. И они по ходу непримиримы. Счем это связано, не знаю!

Хм. Я то думал, что с каждой версией компилятора это учитывают.

SBCL? Так даже в ANSI CL явно было указано, что основным стилем написания программ является императивный. Вплоть до того, что хвостовая оптимизация там необязательна.

С другой стороны, оптимизация функциональных вызовов заметно усложняет отладку (стек вызовов частично «исчезает»). А у CL одна из основ — сверхмощный отладчик.

А у CL одна из основ — сверхмощный отладчик.

За это и любим.

За это и любим.

Вот именно. А если взять функциональные языки, то в Racket хвостовая оптимизация затирает стек. В результате пишешь

(define (f x) (+ (g x) (h x) (k x) 1))
(f 'bad)

получаешь ошибку car: contract violation. На стеке только f, + и car. Потому что в одной из g, h, k хвостовой операцией оказалась операция, у которой хвостовой операцией была car.

В Haskell ещё жёстче. Чистая ленивая функция просто хранит вычисления в данных.

y = f x
z = g y
print $ head z

Получаешь ошибку *** Exception: bad data со стеком print, head. Хотя сама ошибка bad data возвращена из f или g.

Поэтому в функциональных языках отладчик считается почти бесполезным, а вместо него контракты и модульные проверки (unit tests). В Haskell и Typed Racket ещё и типизация.