Информация об изменениях

Сообщение Re[4]: Отличие функционального ЯП от объектно-ориентированог от 25.10.2020 14:38

Изменено 25.10.2020 15:01 mrTwister

Re[4]: Отличие функционального ЯП от объектно-ориентированого
Здравствуйте, VladD2, Вы писали:

VD>Какой-то набор заблуждений. Поддержка функций — это процедурное программирование. Его поддерживают все языки включая ассемблер.


Естественно, имеются ввиду функции высшего порядка. Странно, что приходится пояснять эту очевидную мысль

VD>Поддержка же ФП в C# до сих пор недостаточна. Для полноценной поддержки нужен полноценный пттерн-матчинг, неизменяемые типы и алгебраические типы. Все это пока только в проектах новых стандартов.


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

VD>Та часть поддержки ФП, когда в C# есть на сегодня боле чем пригодна для использования функционального стиля. Скажем лямбды, замыкания, функции высшего порядка — это все сделано не плохо и во всю используетя.

Но декомпозция при этом преимущественно объектно-ориентированная, я про нее. То, как реализовали методы никакой роли не играет, сложность программы определяется высокоуровневой декомпозицией, а не тем, как методы классов написали.

VD>Еще раз. "на функциях" — это и есть процедурное программирование. А функциональное — это когда ты используешь преобразование данных.

Еще раз (тм). "На функциях" означает композицию функций с активным использованием функций высшего порядка. Преобразование данных, естественно, никуда не девается, но именно функциональная композиция является определяющим фактором.

VD>Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.

И?

VD>И в стандартной библиотеке есть тот же Линк, которые по сути является стандартным набором функций высшего порядка.

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

VD>Библиотеки F# отличаются не тем, что они "написаны на функциях", а тем, что они приспособлены для карринга и обработки списков. Если бы F# не возился с каррингом ему за глаза хватило бы Linq.

Карринг — это и есть функции высшего порядка, и вполне логично, что стандартная библиотека заточена на использование функций высшего порядка. Благодаря этому декомпозиция с использованием ФВП в F# значительно сильнее распространена, чем в C#, несмотря на то, что в C# тоже есть ФВП

VD>Будут в C# такие же возможности по поддержке ФП как в Nemerle и F#, на шарпе можно будет точно так же писать в функциональном стиле, а выбор стиля будет завесить от задачи или тараканов в голове разработчиков.

Какие бы фичи в C# ни добавили, стиль будет определяться стилем стандартной библиотеки. И да, повторюсь, я не про то, как именно написаны методы классов, я про декомпозицию задачи на подзадачи и композицию кода. Именно они определяют стиль, а не то, используются ли в методах if'ы, или паттерн-матчинг.
Re[4]: Отличие функционального ЯП от объектно-ориентированог
Здравствуйте, VladD2, Вы писали:

VD>Какой-то набор заблуждений. Поддержка функций — это процедурное программирование. Его поддерживают все языки включая ассемблер.


Естественно, имеются ввиду функции высшего порядка. Потому что именно функции высшего порядка позволяют делать функциональную композицию кода и соответствующую декомпозицию задачи. Странно, что приходится пояснять эту очевидную мысль

VD>Поддержка же ФП в C# до сих пор недостаточна. Для полноценной поддержки нужен полноценный пттерн-матчинг, неизменяемые типы и алгебраические типы. Все это пока только в проектах новых стандартов.


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

VD>Та часть поддержки ФП, когда в C# есть на сегодня боле чем пригодна для использования функционального стиля. Скажем лямбды, замыкания, функции высшего порядка — это все сделано не плохо и во всю используетя.

Но декомпозция при этом преимущественно объектно-ориентированная, я про нее. То, как реализовали методы никакой роли не играет, сложность программы определяется высокоуровневой декомпозицией, а не тем, как методы классов написали.

VD>Еще раз. "на функциях" — это и есть процедурное программирование. А функциональное — это когда ты используешь преобразование данных.

Еще раз (тм). "На функциях" означает композицию функций с активным использованием функций высшего порядка. Преобразование данных, естественно, никуда не девается, но именно функциональная композиция является определяющим фактором.

VD>Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.

И?

VD>И в стандартной библиотеке есть тот же Линк, которые по сути является стандартным набором функций высшего порядка.

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

VD>Библиотеки F# отличаются не тем, что они "написаны на функциях", а тем, что они приспособлены для карринга и обработки списков. Если бы F# не возился с каррингом ему за глаза хватило бы Linq.

Карринг — это и есть функции высшего порядка, и вполне логично, что стандартная библиотека заточена на использование функций высшего порядка. Благодаря этому декомпозиция с использованием ФВП в F# значительно сильнее распространена, чем в C#, несмотря на то, что в C# тоже есть ФВП

VD>Будут в C# такие же возможности по поддержке ФП как в Nemerle и F#, на шарпе можно будет точно так же писать в функциональном стиле, а выбор стиля будет завесить от задачи или тараканов в голове разработчиков.

Какие бы фичи в C# ни добавили, стиль будет определяться стилем стандартной библиотеки. И да, повторюсь, я не про то, как именно написаны методы классов, я про декомпозицию задачи на подзадачи и композицию кода. Именно они определяют стиль, а не то, используются ли в методах if'ы, или паттерн-матчинг.