tag:blogger.com,1999:blog-7754674872362895099.post7878711936124033315..comments2023-05-03T16:18:51.793+03:00Comments on Очень серьезный блог: Complexity and orderAnonymoushttp://www.blogger.com/profile/10666299351005530153noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-7754674872362895099.post-45914360459914521712011-04-19T13:26:16.950+04:002011-04-19T13:26:16.950+04:00Часто вы использовали ленивые вычисления?Изрядно, ...<i>Часто вы использовали ленивые вычисления?</i><br>Изрядно, на С++ это обычно сводится к написанию своего итератора.<br><br><i>А часто ли вы видели в живом коде "Приспособленца"?</i><br>Может у меня просто задачи такие, но довольно часто. А использовать этот шаблон начал еще до того как узнал о его существовании :)<br><br><i>Те кто не подозревает о существовании ленивых вычислений, насколько для него код будет сложнее чем для вас?</i><br>Я думаю любой компетентный программист должен о их существовании знать. Дело даже не в том, знает или нет. Один и тот-же алгоритм, использующий ленивые вычисления, будет намного проще реализовать на языке - поддерживающем ленивость, чем на языке его не поддерживающем.<br><br>А вообще, пост немного о другом.Lazinhttp://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-4234702651249161732010-03-31T09:38:49.631+04:002010-03-31T09:38:49.631+04:002v_s, цикломатическая сложность разных реализаций ...2v_s, цикломатическая сложность разных реализаций одного алгоритма - всегда будет одинакова.<br />Нужно учитывать и то, что мы обычно не записываем программы в виде цепочки вычислений с кучей ветвлений, вместо этого, мы обычно руководствуемся принципом - "разделяй и властвуй", делим код на независимые части и компоненты, в результате чего, его становится проще понимать. А еще, в когда пишешь на языке с поддержкой ФП, не каждый control path задается явно, ведь ФП программа, это не последовательность statement-ов, а просто множество выражений, последовательность вычисления которых не задается программистом в явном виде.<br />Судя по моему опыту программиования на F#, кода получается намного меньше, и он намного проще для понимания :)Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-58157408645666505082010-03-29T13:40:58.929+04:002010-03-29T13:40:58.929+04:00http://insanegigolo.livejournal.com/58673.html#cut...http://insanegigolo.livejournal.com/58673.html#cutid1v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-25137888902122797542010-03-29T10:17:13.974+04:002010-03-29T10:17:13.974+04:00Ну вот странно, вы согласились что если алгоритм о...<i>Ну вот странно, вы согласились что если алгоритм одинаковый, значит и сложность его одинаковая.<br />Но при этом получается что на функциональном это легче реализовать.</i><br />Во первых, я имел ввиду не алгоритмическую сложность, а сложность системы в общем.<br />Если программа состоит из множества зависящих друг от друга частей, то чем больше таких зависимостей, тем сложнее система.<br />Тоже самое можно сказать о порядке выполнения операций. Чем больше в программе инвариантов вида - <b>"операция Б может быть выполнена только после операции А, но до операции С"</b>, тем сложнее система.<br />Языки программирования, поддерживающие ООП - позволяют уменьшить количество зависимостей между разными частями приоложения, поэтому, говорят, что они позволяют бороться со сложностью(не той, которая big-O).<br />ФП позволяет не определять явно порядок выполнения операций, уменьшая тем самым количество зависимостей другого рода, поэтому оно тоже позволяет бороться со сложностью.<br />Смысл поста сводится к тому, что противопоставлять ФП и ООП - дело не благодарное.<br /><br /><i>Можно живой пример на обоих языках, доказывающий вашу точку зрения?</i><br />Здесь можно посмотреть на реализацию алгоритма <a href="http://www.algolist.net/Algorithms/Sorting/Quicksort" rel="nofollow">quicksort</a>.<br />Реализация этого алгоритма на haskell выглядит так:<br />qsort [] = []<br />qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)<br />когда мне в последний раз понадобилось вспомнить как работает этот алгоритм, я просто вспомнил, как он выглядит на haskell - настолько здесь все декларативно и емко :)Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-60885069687404747302010-03-27T15:10:09.909+03:002010-03-27T15:10:09.909+03:00Этот комментарий был удален администратором блога.alsohttp://foodblogger.ru/noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-65960139466591358582010-03-26T23:27:37.440+03:002010-03-26T23:27:37.440+03:00Ну вот странно, вы согласились что если алгоритм о...Ну вот странно, вы согласились что если алгоритм одинаковый, значит и сложность его одинаковая.<br />Но при этом получается что на функциональном это легче реализовать.<br />Можно живой пример на обоих языках, доказывающий вашу точку зрения?v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-4281941201422789922010-03-26T09:45:36.574+03:002010-03-26T09:45:36.574+03:00Часто вы использовали ленивые вычисления?
Изрядно,...<i>Часто вы использовали ленивые вычисления?</i><br />Изрядно, на С++ это обычно сводится к написанию своего итератора.<br /><br /><i>А часто ли вы видели в живом коде "Приспособленца"?</i><br />Может у меня просто задачи такие, но довольно часто. А использовать этот шаблон начал еще до того как узнал о его существовании :)<br /><br /><i>Те кто не подозревает о существовании ленивых вычислений, насколько для него код будет сложнее чем для вас?</i><br />Я думаю любой компетентный программист должен о их существовании знать. Дело даже не в том, знает или нет. Один и тот-же алгоритм, использующий ленивые вычисления, будет намного проще реализовать на языке - поддерживающем ленивость, чем на языке его не поддерживающем.<br /><br />А вообще, пост немного о другом.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-57104468337115583512010-03-25T23:28:06.699+03:002010-03-25T23:28:06.699+03:00Часто вы использовали ленивые вычисления?
А часто ...Часто вы использовали ленивые вычисления?<br />А часто ли вы видели в живом коде "Приспособленца"?<br />Те кто не подозревает о существовании ленивых вычислений, насколько для него код будет сложнее чем для вас?v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-23458150335358607342010-03-25T20:59:11.542+03:002010-03-25T20:59:11.542+03:00Я не это хотел сказать, а то, что эти паттерны поя...Я не это хотел сказать, а то, что эти паттерны появились по причине отсутствия в С++/Java(не знаю какой язык использовали Гамма и компания) поддержки ленивых вычислений. Отсюда растут ноги у шаблона "приспособленец". О многих других можно сказать подобное.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-74172654750108921142010-03-25T18:27:34.498+03:002010-03-25T18:27:34.498+03:00Избавляясь от этого паттерна мы избавляемся от сло...Избавляясь от этого паттерна мы избавляемся от сложности?v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-88306491608970058112010-03-25T17:53:06.999+03:002010-03-25T17:53:06.999+03:00Я же написал - паттерны проектирования. Многие из ...Я же написал - паттерны проектирования. Многие из паттернов GoF просто не нужны, когда пишешь на функциональном ЯП, первое что пришло в голову - шаблоны flyweight, или command, ленивость и ФВП избавляют навсегда от их применения.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-35278234017432266272010-03-25T17:30:30.617+03:002010-03-25T17:30:30.617+03:00Паттерны не придуманы, паттерны найдены. Паттернов...Паттерны не придуманы, паттерны найдены. Паттернов много: рефакторинга, интеграции, проектирования. Какие вы имели в виду?<br />Декларативные языки далеко не к каждой задаче подходят.v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-2036272133507938992010-03-25T16:27:18.176+03:002010-03-25T16:27:18.176+03:002v_s: бывают очень сложные задачи, зачем по вашему...2v_s: бывают очень сложные задачи, зачем по вашему люди придумали всевозможные паттерны проектирования?<br />Писали-бы себе на Си, раз все так просто :)<br /><br />2legolegs: согласен, по большей части )Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-761052623885405312010-03-25T16:01:24.452+03:002010-03-25T16:01:24.452+03:00Этот комментарий был удален администратором блога.Анонимныйhttp://talkcompressors.ru/noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-74717956330858350712010-03-21T15:34:16.871+03:002010-03-21T15:34:16.871+03:00Будущее (отдалённое) - за декларативными языками. ...Будущее (отдалённое) - за декларативными языками. А ООП и функциональщина - всего лишь две дорожки одной развилки этого пути.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-72993449949874150902010-03-20T23:47:46.160+03:002010-03-20T23:47:46.160+03:00Какая может быть сложность внесения изменений, неу...Какая может быть сложность внесения изменений, неужели редактор не может справится?<br />Если человек не может представить концептуальную модель объекта проектирования, то ему ни одна парадигма не поможет.v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-24624294472182162982010-03-20T22:24:36.714+03:002010-03-20T22:24:36.714+03:00Я имел ввиду не алгоритмическую сложность, а сложн...Я имел ввиду не алгоритмическую сложность, а сложность в общем. Сложность понимания кода, сложность внесения изменений и тд.Anonymoushttps://www.blogger.com/profile/10666299351005530153noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-80302791192217925212010-03-20T18:41:02.777+03:002010-03-20T18:41:02.777+03:00ООП сам добавляет сложности. А функционально напис...ООП сам добавляет сложности. А функционально написанный код, от процедурного ничем по сложности не отличается, алгоритм то одинаково сложный.v shttps://www.blogger.com/profile/14522009638363727407noreply@blogger.com