tag:blogger.com,1999:blog-654279083390275842.post1768429303214010353..comments2024-03-19T12:22:43.654+03:00Comments on Размышлизмы eao197: [comp.prog.thoughts] Причины шума вокруг функционального программированияeao197http://www.blogger.com/profile/17283739752119445290noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-654279083390275842.post-67013376220415990772009-10-14T12:52:07.116+03:002009-10-14T12:52:07.116+03:002Konstantin:
Немного странно что вы основываетесь...2Konstantin:<br /><br /><i>Немного странно что вы основываетесь не на собственном опыте применения ФП, а на том что опоненты были не достаточно убедительны.</i><br /><br />Мой собственный опыт основан на изучении OCaml и Scala пару лет назад. В результате которого стало понятно, что на моих текущих задачах ни один из этих языков достойной заменой C++у не станет. Может я, конечно, не прозрел, но каких-то фундаментальных преимуществ ФП перед ООП я не увидел.<br /><br />Что до оппонентов, то вот пример. Очень много в разговорах об ФП говорится о хорошей поддержке распараллеливания. Но где она? Автоматического распаралленивания нет, в программе нужно самостоятельно выделять места и для параллельной обработки и использовать соответствующие структуры данных. Все то же самое получается и не в ФП подходах.<br /><br /><i>Не так давно вы восхищались VoidSafety в Эйфеле.</i><br /><br />Не, там я восхищался тем, как это дело удалось засунуть в язык, который изначально на это не расчитывался. И для которого есть солидная база пользователей и огромная база написанного кода.<br /><br /><i>Указатели на функции были и в Паскале, и в С.<br />С ФВП можно делать композицию, карринг и другие классные штуки. Сможете вы такое сделать с указателями?</i><br /><br />При наличии GC и обобщенного программирования в языке -- не вижу проблем. В том же D это возможно, хотя он и не ФП язык.<br /><br /><i>Вызывается тот или иной вариант foo в зависимости от типа переданного параметра.</i><br /><br />И если со временем нам нужно будет добавить Derived3, то нам придется перекомпилировать места обращения к foo.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-75919917229434444372009-10-14T12:33:28.544+03:002009-10-14T12:33:28.544+03:00Но действительно, от мифов о волшебных свойствах Ф...<i>Но действительно, от мифов о волшебных свойствах ФП уже подташнивает.</i><br /><br />Немного странно что вы основываетесь не на собственном опыте применения ФП, а на том что опоненты были не достаточно убедительны.<br /><br />Не так давно вы восхищались VoidSafety в Эйфеле. А алегбраические типы которые дают тоже самое и много другое - это для вас виртовский Паскаль. Как-то не логично не находите?<br /><br /><i>Наследование плохо на структурное программирование ложится. И полиморфизм (что видно по исходникам OpenSSL и gSOAP). Да и инкапсуляция тоже...</i><br /><br />Замечательно наследование ложится. Особенно наследование интефейсов. Всего-то надо в класс-структуру добавить указатели на функции. <br />Вся существующая инкапсуляция - всего лишь вариации на тему opaque pointer. <br /><br /><i>Указатели на функции были и в Паскале, и в С.</i><br />С ФВП можно делать композицию, карринг и другие классные штуки. Сможете вы такое сделать с указателями?<br /><br /><i>А пример можно увидеть?</i><br /><br />--<br />data Base = Derived1 | Derived2<br /><br />foo Derived1 = "Derived1"<br /><br />foo Derived2 = "Derived2"<br /><br />createSomeBase::() -> Base<br /><br />main = putStrLn (foo createSomeBase)<br />--<br />Вызывается тот или иной вариант foo в зависимости от типа переданного параметра.Konstantinhttps://www.blogger.com/profile/15149287212548252454noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-29938742477068040142009-10-14T12:21:14.405+03:002009-10-14T12:21:14.405+03:00*)Чтобы нельзя было промазать мимо массива индексо...<i>*)Чтобы нельзя было промазать мимо массива индексом ибо чтобы заткнуть компилер во всех путях исполнения должна быть гарантия.</i><br /><br />А разве это в общем случае решается? Разве что заведением типа индекса, как в Паскале:<br /><br />type MyArrayDim: 1..25;<br />float my_array[ MyArrayDim ];<br />for( MyArrayDim i = 1; ... ) {<br /> my_array[ i ] = ...;<br />}<br /><br />Но и здесь, я думаю, будут какие-то runtime-проверки при изменения значения i.<br /> <br /><i>*)Чтобы нельзя было плодить уродцев с вагонами постоянно меняющегося состояния. Чтобы Степановские регулярные функции были по дефолту и транзитивно проверялась регулярность через весть проект.</i><br /><br />Как раз D к этому ближе всяких C++/C#/Java/Scala подобрался. В D2 появились immutable-данные и pure-функции. И все это в привычной для C++ника упаковке.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-66180839567640701652009-10-14T11:40:02.442+03:002009-10-14T11:40:02.442+03:00ну ди тут никаким боком - все сайд эффекты на мест...ну ди тут никаким боком - все сайд эффекты на месте. Скорее это будет помесь RapidMind'овского детища с хаскелем. <br />*)Смысл в том чтобы ругалось на невозможность оптимизировать инплейс изменение массива изза наличия другой ссылки на него и тп. <br />*)Чтобы нельзя было промазать мимо массива индексом ибо чтобы заткнуть компилер во всех путях исполнения должна быть гарантия. <br />*)Чтобы нельзя было плодить уродцев с вагонами постоянно меняющегося состояния. Чтобы Степановские регулярные функции были по дефолту и транзитивно проверялась регулярность через весть проект. Чтобы нерегулярные нужно было писать специально и с трудом :). Убрать глобальные вообще. <br />Вот тогда на вопрос "вы еще кипятите ?" будет простой ответMiroslavhttps://www.blogger.com/profile/08682508835432008058noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-67143925071642149462009-10-14T11:18:06.235+03:002009-10-14T11:18:06.235+03:002Rubanets Myroslav:
Могу развернуть наверное.
С ...2Rubanets Myroslav:<br /><br /><i>Могу развернуть наверное.</i><br /><br />С удовольствием почитал бы. И, думаю, не только я.<br /><br /><i>ну и главное - за проверку и контроль сайд эффектов я готов отдать много чего.</i><br /><br />Эх, в очередной раз с грустью вспоминается долгострой под названием D...eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-76544319121060058842009-10-14T10:48:46.832+03:002009-10-14T10:48:46.832+03:00ну и главное - за проверку и контроль сайд эффекто...ну и главное - за проверку и контроль сайд эффектов я готов отдать много чего. Долой клятый дебаггер, и даже IDE впридачу. У меня полосами дебаг чужого багла идет - и сейчас черная. А когда начальство проснется насчет "many core utilization" то придет полная и беспросветная ...Miroslavhttps://www.blogger.com/profile/08682508835432008058noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-44200182506417980792009-10-14T10:43:16.923+03:002009-10-14T10:43:16.923+03:002Евгений Охотников:
eda - electronic design automa...2Евгений Охотников:<br />eda - electronic design automation. Софт для тех кто лепит микросхемы/чипы. Здесь по прежнему нужно контролировать размеры в битах основных типов данных. Я охотно верю что gc и прозрачные от машины типы рулят много где, но за лишние 8 байт в прямоугольнике ... То есть компилятор должен а)давать рулить памятью б)проверять чего нарулили. Нужны массивы (медицинский факт). И тп. <br />То есть почитав RWH я честно говоря особых проблем чтобы из H вырос язык пригодный для нас не вижу. Разве что авторы будут продолжать "avoid success at all cost" :) Могу развернуть наверное.Miroslavhttps://www.blogger.com/profile/08682508835432008058noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-41694643713441318162009-10-14T10:09:21.321+03:002009-10-14T10:09:21.321+03:002Rubanets Myroslav: не знаю, что такое EDA индустр...2Rubanets Myroslav: не знаю, что такое EDA индустрия, но могу предположить, что для массового использования ФП нужно максимально снизить порог вхождения. По сути -- интегрировать возможности ФП в мейнстримовые языки (что сейчас видно на примерах C# и D).<br /><br />Имхо, все это оставляет языки типа OCaml и Haskell для маргиналов. Особенно OCaml. Haskell, наверное, будет областью исследований в области языков программирования.<br /><br />Кстати, по поводу C#, Scala и D. Имхо, D в этом смысле самый интересный вариант, т.к. только в нем есть поддержка иммутабельности и константности для любых объектов. И даже C++ в этом смысле к ФП ближе, чем C# и Scala.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-10720860344416639362009-10-14T09:52:41.737+03:002009-10-14T09:52:41.737+03:00главный вопрос не "вы все еще кипятите?"...главный вопрос не "вы все еще кипятите?" а "как вы кипятите? вы же еще живы". Правда вопрос риторический.<br /><br />По фп есть желание цинично подискутировать :) правда я не спец - у меня только пожелания есть :) По принципу - что от него надо чтобы мы ( EDA индустрия ) его начали юзать ( кроме массовых расстрелов ессно )Miroslavhttps://www.blogger.com/profile/08682508835432008058noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-54395312975327908762009-10-14T08:54:14.078+03:002009-10-14T08:54:14.078+03:002Konstantine:
Зря вы так :)
Я предупреждал, что э...2Konstantine:<br /><i>Зря вы так :)</i><br /><br />Я предупреждал, что это передергивание ;) Но действительно, от мифов о волшебных свойствах ФП уже подташнивает.<br /><br /><i>С тем же успехом можно и ООП на структурное нятянуть:</i><br /><br />Нет, не с тем же. Наследование плохо на структурное программирование ложится. И полиморфизм (что видно по исходникам OpenSSL и gSOAP). Да и инкапсуляция тоже (хотя модули Modula-2 и пакеты Ada здесь сильно в тему).<br /><br /><i>Сами же видите что и ФВП в вашу систему не укладываются.</i><br /><br />Не особо. Указатели на функции были и в Паскале, и в С. И использовались похожим образом (C-шный qsort тому пример). Кроме того, ряд языков для структурного программирования (Паскаль, С, Ada) не имели сборки мусора. Поэтому ФВП там быть не могло по физическим, а не идеологическим причинам. Но в том же Oberon-е, AFAIK, локальные функции вполне себе используются как ФВП.<br /><br /><i>Да и паттерн-матчинг зачастую гораздо больше похож на виртуальный вызов, чем на switch.</i><br /><br />А пример можно увидеть?eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-61121328174578338012009-10-14T05:39:59.101+03:002009-10-14T05:39:59.101+03:00Зря вы так :)
С тем же успехом можно и ООП на стр...Зря вы так :)<br /><br />С тем же успехом можно и ООП на структурное нятянуть:<br />"Структуры-состояния передаются в процедуры-методы. А виртуальная диспетчеризация для выбора ветки обработки -- все это для меня чистой воды программирование в стиле Виртовского Паскаля."<br /><br />Сами же видите что и ФВП в вашу систему не укладываются. Да и паттерн-матчинг зачастую гораздо больше похож на виртуальный вызов, чем на switch.Konstantinhttps://www.blogger.com/profile/15149287212548252454noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-14473002195552004742009-10-13T21:43:26.259+03:002009-10-13T21:43:26.259+03:00Ура! Все толпой в ООП!
Было, было :)
Причем им отв...<i>Ура! Все толпой в ООП!</i><br />Было, было :)<br />Причем им отвечали:<br />Да тоже самое можно ж писать и в процедурном стиле :)<br /><br /><i>Выросло новое поколение программистов, которое начинало учиться сразу на ООП.</i><br />Должно было бы вырости :)<br />Но поражаюсь, как не зная что такое процедурный стиль умудряются на нем писать.<br /><br />Тогда еще, говорили - не-е-е, на С++ ООП не поймешь. Нужно углубиться в Smalltalk, вот тогда ты поймешь, что такое ООП, а не будешь лепить структуры с указателями на функции.<br /><br />Но как бы там ни было - ООП прижилось, потому что во многом в нем можно усмотреть продолжение процедурного стиля.<br /><br />А вот с ФП... не так :) Это <b>иное</b> программирование.<br /><br /><i>По моему наоборот ява интерфейсы с одним методом это жалкая пародия на замыкания</i> <br />Аха, в среде java программистов стало признаком хорошего тона мечтать о настоящих замыканиях, а не в виде вложенных анонимных классов.<br />Прикол что при обсуждении синтаксиса замыканий не пришли к единому мнению, а потому в Java 7 их так и не будет.<br /><br /><i>Как обойтись без ООП знают не многие.</i><br />Может это мне так много лет "везет", но из своего опыта - ООП знают немногие :) Поэтому скорей:<br />Без ООП обходятся и доныне - многие.Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-15168127846566544612009-10-13T21:31:45.358+03:002009-10-13T21:31:45.358+03:002Rustam: С демонстрацией теже проблемы что с ООП н...2Rustam: <i>С демонстрацией теже проблемы что с ООП на маленьких примерах ничего ни увидишь.</i><br /><br />Может быть.<br /><br /><i>По моему наоборот ява интерфейсы с одним методом это жалкая пародия на замыкания :)</i><br /><br />Мне кажется, что наши формулировки не противоречат друг другу :) На уровне реализации моя, имхо, точнее :))eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-78679580146566422332009-10-13T20:13:24.974+03:002009-10-13T20:13:24.974+03:00Я читал ту тему. Там был один хороший вопрос с про...<i>Я читал ту тему. Там был один хороший вопрос с просьбой демонстрации этой функциональной декомпозиции. Но ее не было, демонстрации-то. Игра в шашки точно так же решалась бы на какой-нибудь Modula-2 в 1980-м.</i><br /><br />С демонстрацией теже проблемы что с ООП на маленьких примерах ничего ни увидишь. Как пример вполне кстати подходит, например решение задачи К на rsdn http://www.rsdn.ru/forum/decl/2720396.flat.aspx#2720396 кстати из него видно что функциональная декомпозиция скорее ближе к ОО чем к структурной :)Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-23114993475141628042009-10-13T20:03:22.827+03:002009-10-13T20:03:22.827+03:00По моему это только схожесть, проектирование совер...По моему это только схожесть, проектирование совершенно разное, хотя допускаю что я уже успел позабыть структурное :)<br /><br />Хотя может решает мощность. Например в структурных языках, просто невозможно также легко манипулировать функциями как в ФЯ это и ФВП из которых строится все как из кирпичиков (кстати как и в ООП) и замыкания которые во многом локально заменяют объекты.<br /><br />По моему наоборот ява интерфейсы с одним методом это жалкая пародия на замыкания :)Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-24761794374063951572009-10-13T19:53:13.035+03:002009-10-13T19:53:13.035+03:00Почитав пару номеров журнала "Практика функци...Почитав пару номеров журнала "Практика функционального программирования" (http://fprog.ru/2009/), я понимаю, что в функциональных языках ничего сверхнового нет. Идеи есть интересные (борьба с изменяемым состоянием), но уж слишком это все заматематизировано (это отчетливо видно на примере статей Душкина). Лучше почитать книги по дискретной математике и уже упомянутую книгу Б. Мейера.Quakerhttps://www.blogger.com/profile/08892867659877597144noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-79735846247498844832009-10-13T19:35:15.641+03:002009-10-13T19:35:15.641+03:00Я читал ту тему. Там был один хороший вопрос с про...Я читал ту тему. Там был один хороший вопрос с просьбой демонстрации этой функциональной декомпозиции. Но ее не было, демонстрации-то. Игра в шашки точно так же решалась бы на какой-нибудь Modula-2 в 1980-м.<br /><br />Многие примеры из ФП наводят на мысль о том, что все эти ФВП и лямбда-функции используются не более чем синтаксический сахар для Java-интерфейсов с единственным методом.<br /><br />Все остальное -- а именно структуры и передача их в качестве параметров функциям + функции анализируют структуры (паттерн-матчинг с алгебраическими типами) для выбора ветки обработки -- все это для меня чистой воды программирование в стиле Виртовского Паскаля.<br /><br />Но для многих задач (те же вычисления или синтаксический анализ) это гораздо удобнее ООП.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-79716605094404608012009-10-13T19:06:23.248+03:002009-10-13T19:06:23.248+03:00Я уже с Владом поругался на тему что функциональщи...Я уже с Владом поругался на тему что функциональщина ничего нового не приносит в плане декомпозиции:)<br /><br />По моему это не так. Те же параметризованные модули из ML (правда это не только в функциональщине есть, например у ады тоже, но все равно это новье по сравнеие с "классическим" СП) и/или монады уже сильно меняют структуру кода. Да и ФВП тоже сильно смещает акценты, также и алгебраические типы.Rustamhttps://www.blogger.com/profile/17746482246614094380noreply@blogger.com