Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.

Здравствуйте, mrTwister, Вы писали:

T>Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.

Не совсем. "Функциональные ЯП" принципиально не имеют фич для программирования в ООП стиле. Их основная идея — убрать из языка, или максимально затруднить, возможность написания "грязного" кода. С другой стороны, почти все ООП языки — это сборная солянка самых разных подходов; как хочешь, так и пиши.

T>Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.
Очень хорошо прочищает мозги книжка Ивана Чукича "Функциональное программирование на С++".
Там все понятия ФП, начиная с чистых функций, прекрасно объясняются и реализуются на С++.

LVV>Очень хорошо прочищает мозги книжка Ивана Чукича "Функциональное программирование на С++".
LVV>Там все понятия ФП, начиная с чистых функций, прекрасно объясняются и реализуются на С++.

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

Здравствуйте, mrTwister, Вы писали:

T>парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.
Деление языков на функциональные, объектно-ориентированные, процедурные и т.п — не совсем корректно.
Правильнее различать функциональные, объектно-ориентированные, процедурные стили программирования. Которые более или менее успешно можно реализовать на многих языках.
Например, на объектно-ориентированных C# или Java многие пишут чисто процедурный код.
На том же C++ можно реализовать функциональное программирование, а на ассемблере — объектно-ориентированое.
К слову, объектно-ориентированное ядро Windows написано на не объектно-ориентированном C (без плюсов).
Другое дело, что очень удобно, когда язык поддерживает какой-то стиль программирования готовыми конструкциями.
Так, классы C# или C++ очень удобны для реализации объектов.
А F# или Lisp имеют более полную поддержку функций.

Здравствуйте, vmpire, Вы писали:

V>А F# или Lisp имеют более полную поддержку функций.

Common Lisp строго говоря не является ЯП какой-то одной парадигмы, переменные и списки там впервую очередь муттабельные. А значит сразу не ФП. У него всего по немножку.

F# имеет концепцию иммутабельности по умолчанию, поэтому ближе к ФП, но его дополнительно усиливает строгая типизация и типы множества и сумма.
Написание логики программы на F# сводится к описанию состояния системы и их обработке.
Ближе все к ФП из мне известных это clojure.

Здравствуйте, vmpire, Вы писали:

V>Деление языков на функциональные, объектно-ориентированные, процедурные и т.п — не совсем корректно.
V>Правильнее различать функциональные, объектно-ориентированные, процедурные стили программирования. Которые более или менее успешно можно реализовать на многих языках.

В теории да, но на практике нет. C# имеет точно такую же поддержку функций, как и в F# и там тоже всю логику можно в описывать только на функциях, все необходимое для этого там уже есть, удобство использования с точки зрения синтаксиса примерно такое же, только вот так практически никто не делает и не будет делать. А на F# пишут на функциях, хотя тоже можно и в процедурном и в объектно-ориентированном стиле писать, все фичи для этого есть. Разница только в том, что на F# стандартная библиотека написана на функциях, а в C# на классах и объектах и именно это определяет, как язык будут потом использовать и в каком стиле на нем писать.

Здравствуйте, scf, Вы писали:

scf>Не совсем. "Функциональные ЯП" принципиально не имеют фич для программирования в ООП стиле.

Scala и F# имеют, на них легко можно писать в ООП стиле. Вот только так никто не делает.

Здравствуйте, mrTwister, Вы писали:

scf>>Не совсем. "Функциональные ЯП" принципиально не имеют фич для программирования в ООП стиле.

T>Scala и F# имеют, на них легко можно писать в ООП стиле. Вот только так никто не делает.

Про шарп не скажу, но Scala — это гибридный язык, не функциональный.

Здравствуйте, scf, Вы писали:

scf>Про шарп не скажу, но Scala — это гибридный язык, не функциональный.

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

Здравствуйте, mrTwister, Вы писали:

T>Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.

Парадигма не может определяться библиотекой. Как раз нооборот, при необходимости библиотеки подтягиваются под парадигму, как это было в .NET с Enumerable и Queryable. Стиль скорее зависит от начальных целеполаганий, а в дальшейшем от наработанных традиций.

Здравствуйте, IT, Вы писали:

IT>Парадигма не может определяться библиотекой. Как раз нооборот, при необходимости библиотеки подтягиваются под парадигму, как это было в .NET с Enumerable и Queryable. Стиль скорее зависит от начальных целеполаганий, а в дальшейшем от наработанных традиций.

Стандартная библиотека может подтягиваться под разные парадигмы и в зависимости от того, к каким именно парадигмам она будет подтянута, наработаются те, или иные традиции.

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

САД>достаточно любой нормальной книги по функциональному языку, что бы иметь возможность применять этот подход на любом языке
Императивщиков примерно 98%...
Поэтому книга Чукича для них — самая нормальная.

Здравствуйте, mrTwister, Вы писали:

T>Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный

Интересно, а разработчики на C знают, что на функциональном языке программируют?

Здравствуйте, Basil2, Вы писали:

B>Здравствуйте, mrTwister, Вы писали:

T>>Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный

B>Интересно, а разработчики на C знают, что на функциональном языке программируют?

Разработчики С и так знают, что программируют на языке с парадигмой от стандартной библиотеки С. Хотя, какая там стандартная библиотека, ее фактически нет. В условиях почти отсутствующей стандартной библиотеки её функции выполняют другие стандартные API (например posix) и они задают общий тон программ на С

Здравствуйте, Basil2, Вы писали:

B>Здравствуйте, mrTwister, Вы писали:

T>>Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный

B>Интересно, а разработчики на C знают, что на функциональном языке программируют?

"На функциях" — это значит, что функции — объекты первого класса. В C без дополнительных средств генерации замыканий (типа libjit) такого не бывает в принципе, а с этими средствами — дорого (компилятор не умеет оптимизировать). Поэтому C — не функциональный язык.

Здравствуйте, mrTwister, Вы писали:

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

Немерле показал и доказал совершенно обратное. Его стандартная библиотка — .NET Framework. Тем не менее на нём замечательно пишется в функциональной парадигме. Более того, он продемонстрировал, что разные парадигмы могут и должны дополнять друг друга, а не инициировать дурацкие споры на тему у какой парадигмы чего длиннее.

Здравствуйте, IT, Вы писали:

IT>Немерле показал и доказал совершенно обратное.

У него слишком маленькая пользовательская база, чтобы что-то там доказывать. Кроме того, я сам наверняка не знаю, но очень подозреваю, что функцинальщина там разве что на уровне методов классов. То есть декомпозция строится не на workflow, как в ФП, а все еще объектно-ориентированная. То, что внутри методов классов используются лямбды с паттерн-матчингом и прочей функциональщиной делает код немного приятнее, но по большому счету ничего не меняет, программа как была объектно-ориентированной, так ей и осталась.

Здравствуйте, mrTwister, Вы писали:

T>У него слишком маленькая пользовательская база, чтобы что-то там доказывать.

Это не серьёзный аргумент. У 99% языков пользовательская база маленькая, особенно у подавляющего большинства фукнциональных. У того же хаскеля или лиспа на уровне погрешности, тем не менее это никак не умоляет их вклад в развитие ЯП.

T>Кроме того, я сам наверняка не знаю, но очень подозреваю, что функцинальщина там разве что на уровне методов классов.

Именно.

T>То есть декомпозция строится не на workflow, как в ФП, а все еще объектно-ориентированная.

Функциональная декомпозиция — это антипаттерн по типу CodeFirst. Работает исключительно на начальных этапах разработки или в микропроектах, потом неожиданно превращается в проблему. Впрочем, это общая беда функциональных языков — они великолепно применимы в несложных проектах. Ни одна фукнциональная среда не может похвастаться таким набором компонентов и лёгкостью их подключения и использования как, например, Java, JavaScript или C#/.NET. Кстати, два последних языка по сути являются мультипарадигменными, но декомпозиция и компонентность в них решается вовсе не средствами ФП.

T>То, что внутри методов классов используются лямбды с паттерн-матчингом и прочей функциональщиной делает код немного приятнее, но по большому счету ничего не меняет, программа как была объектно-ориентированной, так ей и осталась.

Я уже упоминал, что ФП и ООП могут и должны дополнять друг друга. И ООП языки постепенно впитывают в себя возможности функциональной парадигмы, что говорит об их практичности и адекватности. В свою очередь ФП языки продолжают загнивать в своих догмах и домыслах об их элитарности и избранности.

Здравствуйте, scf, Вы писали:

scf>Не совсем. "Функциональные ЯП" принципиально не имеют фич для программирования в ООП стиле. Их основная идея — убрать из языка, или максимально затруднить, возможность написания "грязного" кода. С другой стороны, почти все ООП языки — это сборная солянка самых разных подходов; как хочешь, так и пиши.

Твоя стройная теория разбивается о целый рад функциональных ЯП поддерживающих ООП:
1. OCaml.
2. F#.
3. Nemerle.
4. Scala.