Сообщение Re[8]: Отличие функционального ЯП от объектно-ориентированог от 25.10.2020 17:58
Изменено 25.10.2020 18:05 mrTwister
Re[8]: Отличие функционального ЯП от объектно-ориентированог
Здравствуйте, VladD2, Вы писали:
T>>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП
VD>
Это называется процедурная декомпозиция. Они доступна везде.
Процедурная декомпозиция — это очень маленькое подмножество функциональной. Практически все стандартные ФП паттерны завязаны на ФВП, которых нет в процедурных языках.
VD>В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.
Как правило, явно классы в F# используются только для взаимодействия с другим .net кодом.
T>>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.
VD>Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.
Язык один и тот же — javascript (ну или typedcript, сути не меняет). И программист один и тот же с одними и теме же тараканами в голове. Даже задача одинаковая. Но в случае с реактом он будет писать в ФП стиле, а в случае с ангуляром в ООП.
VD>Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.
На реакте общепринят flux
VD>Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.
В энный раз повторяю — я про декомпозицию задачи, а не про написание методов. Программы на реакте декомпозируются с помощью архитектурного паттерна unidirectional data flow.
VD>Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.
Все так, а на реакте не используют изменяемое состояние во вью. Об этом и речь.
VD>1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
Я ничего не писал о проблемах в ООП, при чем тут это?
VD>2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
Я не писал, чт оФП — это панацея, при чем тут это?
VD>3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
Все так. А вот традиции и привычки задаются используемой стандартной библиотекой.
VD>4. Язык может стимулировать к использованию ФП представляя удобные средства.
Средства языка без поддержки стандартной библиотеки имеют малое влияние на традиции.
VD>5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.
Функциональная часть там очень крохотная, которая мало на что влияет, только на уровне методов.
T>>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП
VD>
Это называется процедурная декомпозиция. Они доступна везде. Процедурная декомпозиция — это очень маленькое подмножество функциональной. Практически все стандартные ФП паттерны завязаны на ФВП, которых нет в процедурных языках.
VD>В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.
Как правило, явно классы в F# используются только для взаимодействия с другим .net кодом.
T>>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.
VD>Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.
Язык один и тот же — javascript (ну или typedcript, сути не меняет). И программист один и тот же с одними и теме же тараканами в голове. Даже задача одинаковая. Но в случае с реактом он будет писать в ФП стиле, а в случае с ангуляром в ООП.
VD>Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.
На реакте общепринят flux
VD>Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.
В энный раз повторяю — я про декомпозицию задачи, а не про написание методов. Программы на реакте декомпозируются с помощью архитектурного паттерна unidirectional data flow.
VD>Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.
Все так, а на реакте не используют изменяемое состояние во вью. Об этом и речь.
VD>1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
Я ничего не писал о проблемах в ООП, при чем тут это?
VD>2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
Я не писал, чт оФП — это панацея, при чем тут это?
VD>3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
Все так. А вот традиции и привычки задаются используемой стандартной библиотекой.
VD>4. Язык может стимулировать к использованию ФП представляя удобные средства.
Средства языка без поддержки стандартной библиотеки имеют малое влияние на традиции.
VD>5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.
Функциональная часть там очень крохотная, которая мало на что влияет, только на уровне методов.
Re[8]: Отличие функционального ЯП от объектно-ориентированог
Здравствуйте, VladD2, Вы писали:
T>>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП
VD> Это называется процедурная декомпозиция. Они доступна везде.
Процедурная декомпозиция — это очень маленькое подмножество функциональной. Практически все стандартные ФП паттерны завязаны на ФВП, которых нет в процедурных языках.
VD>В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.
Как правило, явно классы в F# используются только для взаимодействия с другим .net кодом.
T>>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.
VD>Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.
Язык один и тот же — javascript (ну или typedcript, сути не меняет). И программист один и тот же с одними и теме же тараканами в голове. Даже задача одинаковая. Но в случае с реактом он будет писать в ФП стиле, а в случае с ангуляром в ООП.
VD>Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.
На реакте общепринят flux
VD>Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.
В энный раз повторяю — я про декомпозицию задачи, а не про написание методов. Программы на реакте декомпозируются с помощью архитектурного паттерна unidirectional data flow.
VD>Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.
Все так, а на реакте не используют изменяемое состояние во вью моделях. Об этом и речь.
VD>1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
Я ничего не писал о проблемах в ООП, при чем тут это?
VD>2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
Я не писал, чт оФП — это панацея, при чем тут это?
VD>3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
Все так. А вот традиции и привычки задаются используемой стандартной библиотекой.
VD>4. Язык может стимулировать к использованию ФП представляя удобные средства.
Средства языка без поддержки стандартной библиотеки имеют малое влияние на традиции.
VD>5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.
Функциональная часть там очень крохотная, которая мало на что влияет, только на уровне методов.
T>>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП
VD>
Это называется процедурная декомпозиция. Они доступна везде. Процедурная декомпозиция — это очень маленькое подмножество функциональной. Практически все стандартные ФП паттерны завязаны на ФВП, которых нет в процедурных языках.
VD>В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.
Как правило, явно классы в F# используются только для взаимодействия с другим .net кодом.
T>>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.
VD>Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.
Язык один и тот же — javascript (ну или typedcript, сути не меняет). И программист один и тот же с одними и теме же тараканами в голове. Даже задача одинаковая. Но в случае с реактом он будет писать в ФП стиле, а в случае с ангуляром в ООП.
VD>Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.
На реакте общепринят flux
VD>Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.
В энный раз повторяю — я про декомпозицию задачи, а не про написание методов. Программы на реакте декомпозируются с помощью архитектурного паттерна unidirectional data flow.
VD>Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.
Все так, а на реакте не используют изменяемое состояние во вью моделях. Об этом и речь.
VD>1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
Я ничего не писал о проблемах в ООП, при чем тут это?
VD>2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
Я не писал, чт оФП — это панацея, при чем тут это?
VD>3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
Все так. А вот традиции и привычки задаются используемой стандартной библиотекой.
VD>4. Язык может стимулировать к использованию ФП представляя удобные средства.
Средства языка без поддержки стандартной библиотеки имеют малое влияние на традиции.
VD>5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.
Функциональная часть там очень крохотная, которая мало на что влияет, только на уровне методов.