Comments 25
Конечно, в бизнес-программировании доминирует функциональная модель. Сюрприз? Сюрприз, если вы рассматриваете только такие языки, как Java, C++, C# и Ruby. Если подумать, то всё это ООП – тонкая прослойка для доступа к базам данных и SQL, что на самом деле – функциональный язык.
Сильный сюрприз. Всегда считал SQL — декларативным языком, а не функциональным. Всегда считал, что в мире бизнес ПО как раз таки рулит ООП, а FP хороши для параллельных вычислений, или как сахар для «больших языков».
Сильный сюрприз. Всегда считал SQL — декларативным языком, а не функциональным. Всегда считал, что в мире бизнес ПО как раз таки рулит ООП, а FP хороши для параллельных вычислений, или как сахар для «больших языков».
+3
Декларативные языки включают в свое множество функциональные, если мне память не изменяет
+2
Декларативный язык по определению не может включать в себя функциональный язык. И в этом его преимущество
0
Тьюринг полный ЯП, по определению, может быть использован для описания любых программ.
Декларативный и императивный подходы — указывают на способ описания алгоритмов.
ООП, ФП и прочее — способ организации алгоритмов.
Не стоит это путать.
Декларативный и императивный подходы — указывают на способ описания алгоритмов.
ООП, ФП и прочее — способ организации алгоритмов.
Не стоит это путать.
+7
ООП — это уменьшение «сложности» предметной области через декомпозицию её на «независимые» части: внутренности объекта и внешнюю среду.
ФП — это уменьшение «сложности» предметной области через композицию (выделение) однотипных операций.
Выбирать эти инструменты надо исходя из этих особенностей, а не из частоты изменений. Если применять их к месту, то будет счастье, если путать — будут проблемы с изменениями.
Под «сложностью» в этом комментарии можно понимать количество возможных связей между сущностями.
ФП — это уменьшение «сложности» предметной области через композицию (выделение) однотипных операций.
Выбирать эти инструменты надо исходя из этих особенностей, а не из частоты изменений. Если применять их к месту, то будет счастье, если путать — будут проблемы с изменениями.
Под «сложностью» в этом комментарии можно понимать количество возможных связей между сущностями.
+6
ООП — это уменьшение «сложности» предметной области через декомпозицию её на «независимые» части: внутренности объекта и внешнюю среду.
А в чем разница с функцией? Разве не та же декомпозиция на внутренности функции (и интерфейс в виде параметров) и внешнюю среду (вызывающую).
0
А в чем разница с функцией? Разве не та же декомпозиция на внутренности функции (и интерфейс в виде параметров) и внешнюю среду (вызывающую).
Та же, но в Вашем примере функция — это не обязательно функция из ФП, а функция «вообще» — метод организации кода. Так же, как объединение нескольких значений в одну структуру — метод организации данных. Это более низкоуровневые абстракции. Функции есть и в ООП и в ФП и в любом другом *П.
0
По-моему, и в ФП и в ООП есть оба названных вами подхода: и инкапсуляция и абстракция. А разница между ними именно в отношении к существительным и глаголам. ФП считает, что любой глагол в теории можно применить к любому существительному и не привязывает их. Это, в теории, дает большую свободу и гибкость (можно добавлять новые существительные, а методы работы с ними уже есть), однако сильно усложняет структуру программ (проще каталогизировать существительные, чем глаголы).
Однако, с развитием инструментов и языков программирования эти подходы сближаются. IDE может показать нам все структуры, подходящие для данной функции и наоборот, а язык обеспечит приведение типов.
Однако, с развитием инструментов и языков программирования эти подходы сближаются. IDE может показать нам все структуры, подходящие для данной функции и наоборот, а язык обеспечит приведение типов.
+2
По-моему, и в ФП и в ООП есть оба названных вами подхода: и инкапсуляция и абстракция.
Конечно оба. Но инкапсулируют и абстрагируют они разное.
ФП считает, что любой глагол в теории можно применить к любому существительному
Оно так не считает. Оно оперирует функциями в математическом их понимании. Это не глаголы. Не стоит в рассуждениях привязываться к понятиям «существительное» и «глагол» и прочим из естественных языков. Хотя бы потому, что в разных естественных языках они обладают разными свойствами, а значит, разной семантикой.
Однако, с развитием инструментов и языков программирования эти подходы сближаются. IDE может показать нам все структуры, подходящие для данной функции и наоборот, а язык обеспечит приведение типов.
IDE не имеет никакого отношения к парадигмам программирования, тем более не может их сближать. Оно облегчает написание и чтение кода, не более того.
0
UFO just landed and posted this here
Тоже дочитал до этого места и подумал, что автор шутит
+3
Это да, но не продавит. Ибо слишком уж очевидно искусственное «зауживание» сферы применения бизнес-ПО.
Всякие CADы, LABы, скайпы, лингвалеo-ы, прогнозирование в медицине, и даже экономике, офисный софт, строительство и архитектура, эпюры, нагрузки и т.д. можно продолжать бесконечно. Все эти продукты либо не используют SQL вовсе, либо используют его вспомогательно, так же как, например, файловую систему. А краеугольными в них являются кодеки, модели, спецификации и т. д. Т.е. чисто программные решения. Кроме того, SQL глубоко вторичная вещь, к тому же легко заменяемая. Большие таблицы, map-reduce, бинарные или разреженные деревья, опять же те же файлы — способов хранения просто море. И серьезная программа далеко не просто «проводник» к этим данным.
Всякие CADы, LABы, скайпы, лингвалеo-ы, прогнозирование в медицине, и даже экономике, офисный софт, строительство и архитектура, эпюры, нагрузки и т.д. можно продолжать бесконечно. Все эти продукты либо не используют SQL вовсе, либо используют его вспомогательно, так же как, например, файловую систему. А краеугольными в них являются кодеки, модели, спецификации и т. д. Т.е. чисто программные решения. Кроме того, SQL глубоко вторичная вещь, к тому же легко заменяемая. Большие таблицы, map-reduce, бинарные или разреженные деревья, опять же те же файлы — способов хранения просто море. И серьезная программа далеко не просто «проводник» к этим данным.
+2
Ну и в конце-концов, SQL это информационно-логический мультипарадигмальный язык, а вовсе не функциональный. В лучшем случае, функциональной частью можно назвать Select'ы с их вложенностью, insert'ы, update'ы и т.п. сложно назвать функциональным языком.
0
select-ы я считаю чистыми функциями — нет побочных эффектов, допускается параллельное выполнение.
update/insert в принципе тоже не указывают жёсткий порядок выполнения, а фиксация данных в переменных есть и в функциональных языках.
Кроме того, популярные версионные базы данных предоставляют каждой транзакции срез данных на момент начала транзкации, т.е. каждая транзакция работает со своей версией данных, изменения в которой остальные увидят только после коммита. Мне приходит в голову аналогия со вставкой в дерево в чистой фунциональщине: строится изменённая копия в памяти, а в конце операции корень старого дерева заменяется на корень нового и только так все видят сделанные изменения.
Другое дело, если отойти от стандарта и прийти к реализациям (T-SQL, например), туда намешивают императивщину (переменные, блоки if, циклы, курсоры), что делает большинство реализаций мультипарадигменными.
update/insert в принципе тоже не указывают жёсткий порядок выполнения, а фиксация данных в переменных есть и в функциональных языках.
Кроме того, популярные версионные базы данных предоставляют каждой транзакции срез данных на момент начала транзкации, т.е. каждая транзакция работает со своей версией данных, изменения в которой остальные увидят только после коммита. Мне приходит в голову аналогия со вставкой в дерево в чистой фунциональщине: строится изменённая копия в памяти, а в конце операции корень старого дерева заменяется на корень нового и только так все видят сделанные изменения.
Другое дело, если отойти от стандарта и прийти к реализациям (T-SQL, например), туда намешивают императивщину (переменные, блоки if, циклы, курсоры), что делает большинство реализаций мультипарадигменными.
0
дальше написано;
>Отойдя назад, вы увидите, что база данных – это большая структура данных, а приложения – наборы операций с ними. В сердце любого бизнес-приложения лежит большая функциональная база данных.
в этом контексте так и получается всегда, есть база с данными и функциями, и любой язык как 'обертка' над этим, веб доступ, консольный и тд…
>Отойдя назад, вы увидите, что база данных – это большая структура данных, а приложения – наборы операций с ними. В сердце любого бизнес-приложения лежит большая функциональная база данных.
в этом контексте так и получается всегда, есть база с данными и функциями, и любой язык как 'обертка' над этим, веб доступ, консольный и тд…
0
ФП — об организации потока исполнения
ООП — об организации работы с данными.
Какой смысл сравнивать теплое с мягким?
ООП — об организации работы с данными.
Какой смысл сравнивать теплое с мягким?
+2
инкапсуляции программ на мелкие куски
Дальше не читал.
0
А я начинающий и мне было интересно…
Вообще для начинающих изучать программирование вообще кастратофически не хватает этаких «переводов» происходящего на человеко-понятный язык.
Например из 4 книг по php, которые я пытался начать читать, все 4 написаны программистами для программистов. То есть уже с первых страниц начинается нечто, которое способен понять человек, уже знающий программирование.
Ну и зачем такое счастье нужно?
Вообще для начинающих изучать программирование вообще кастратофически не хватает этаких «переводов» происходящего на человеко-понятный язык.
Например из 4 книг по php, которые я пытался начать читать, все 4 написаны программистами для программистов. То есть уже с первых страниц начинается нечто, которое способен понять человек, уже знающий программирование.
Ну и зачем такое счастье нужно?
0
Sign up to leave a comment.
Когда использовать ООП, а когда — ФП?