На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (16) « Первая ... 12 13 [14] 15 16  все  ( Перейти к последнему сообщению )  
> Функциональное програмирование , Что за зверь такой
    Цитата Исмаил Прокопенко @
    Flex FerrumПо крайней мере инженер отдаёт себе отчёт, что "при данной метОде решения задачи возможен фак ап".

    А программист просто "закрывает глаза" и врёт даже себе

    Добавлено
    Не говоря уже про коллег на форуме

    Ну да! Программист же - он тупой, к любой задаче с одним инструментом подходит, а потом возмущается, почему для программирования какого-нибудь S7-300 ему только FBD предлагают, а на С++17 - нельзя. Или почему при разработке числодробилки под айбиэмовский DeepBlue у него такой адовый шит в коде получается. Угу. Нет, чтобы докумекать, что в S7-300 - жёсткий реалтайм, а на машинке, где число процессоров измеряется тысячами, синхронизация потоков - очень дорогая штука. Ну идиот, одно слово. :D :D :D
      Цитата Исмаил Прокопенко @
      Инженер считает, что проект не сделан, если факап возможен хотя бы чисто теоретически, а программист, если вероятность факапа мала, считает, что он невозможен и считает, что свою задачу он выполнил
      Инженер считает, что число пи равно 3, а если нужно точно, то 3.14.
      А знающий программист знает, что там дальше ещё много много цифр.
      Инженерам обычно хватает приближённых эмпирических формул, и они сильно удивляются, когда подсунув эти грубые формулы программисту, получает в ответ сильно приближённое решение. Ведь формулы-то точные.
        Цитата Исмаил Прокопенко @
        "Самый очевидный плюс ленивых вычислений — если что-то не требуется, оно не будет вычислено."
        Это квантовая механика. Один в один. Мы в матрице.

        Добавлено
        Исмаил Прокопенко, тебе ещё не надело клоуном работать?
          Цитата Flex Ferrum @
          Программист же - он тупой

          Но согласитесь, что лавинообразный рост вычислительной нагрузки возможен, а Вы говорите, что нет. Хотя любому инженеру это очевидно.

          Достаточно написать 3 строчки
          C=f3(e,f,g)
          B=f1(C,D)
          А=B*C


          Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих.

          А если бы строчек было 10?
          А если каждая функция имеет по 5 параметров и внутри вызывает кучу других функций?

          Уже разрулить "завязки" (т.е. что с чем связано, а значит, что нужно считать "прям щас", а что можно отложить) уже нетривиальная задача, жрущая не малые ресурсы. А тут ещё лавина отложенных вычислений, которые все откладывались, откладывались и вот наконец пришло время их выполнять
            Цитата D_KEY @
            Фактически он и создается. Если тебя привлекает синтаксический сахар, то мне этот разговор будет не слишком интересен :)
            В какой-то степени да, синтаксический сахар. Но дык, например, синтаксис лямбд в С++ тоже не более, чем синтаксический сахар. Тебе они тоже не слишком интересны?
            Цитата D_KEY @
            Кстати, что будет, если в выражении указать объект, который будет уничтожен до реального вычисления?
            Я к тому, что из вызова не видно, что выражение будет вычислено лениво.
            Не понятно, как именно ты собрался его уничтожать. Что ты имеешь в виду? Уничтожение в другом потоке?
            Цитата D_KEY @
            И еще такой вопрос, в обобщенном коде как мне сделать perfect forwarding в случае ленивых параметров?
            Не знаю, мне даже думать на эту тему не хочется. Наверное также как и в случае неленивых параметров. Я ленивость вызова функций не считаю архиполезной штукой, использую редко и как правило в простых случаях. А Perfect Forwarding сам по себе отрыжка академического плюсового перфекционизма. Эта неуёмная жажда обобщить все на свете на практике только вредит.
            Цитата Исмаил Прокопенко @
            И опять всплывает разница между программистами и инженерами.
            Инженер считает, что проект не сделан, если факап возможен хотя бы чисто теоретически, а программист, если вероятность факапа мала, считает, что он невозможен и считает, что свою задачу он выполнил
            Поэтому мы видим вокруг тонны инженерного факапа. :D
              Цитата applegame @
              Цитата D_KEY @
              Фактически он и создается. Если тебя привлекает синтаксический сахар, то мне этот разговор будет не слишком интересен :)
              В какой-то степени да, синтаксический сахар. Но дык, например, синтаксис лямбд в С++ тоже не более, чем синтаксический сахар. Тебе они тоже не слишком интересны?

              Не слишком. Но код упрощают во многих случаях, да.

              Цитата
              Цитата D_KEY @
              Кстати, что будет, если в выражении указать объект, который будет уничтожен до реального вычисления?
              Я к тому, что из вызова не видно, что выражение будет вычислено лениво.
              Не понятно, как именно ты собрался его уничтожать. Что ты имеешь в виду? Уничтожение в другом потоке?

              Ну я же могу сохранить этот параметр, не потеряв ленивость? Вот сохранил я его, а объекты, которые используются в выражении давно уничтожены. Что произойдет?

              Цитата
              А Perfect Forwarding сам по себе отрыжка академического плюсового перфекционизма. Эта неуёмная жажда обобщить все на свете на практике только вредит.

              :D
                Цитата applegame @
                Поэтому мы видим вокруг тонны инженерного факапа.

                Потому что инженерный фак ап лежит на поверхности, поэтому и кажется что его много.
                Хотя на самом деле у программистов фак апа в разы больше, просто он глубоко зарыт

                Добавлено
                И потом, исправить косяк в железе - это тебе не пару строк в коде поправить. На это иногда ГОДЫ нужны и огромные ресурсы
                Сообщение отредактировано: Исмаил Прокопенко -
                  Цитата D_KEY @
                  Не слишком. Но код упрощают во многих случаях, да.
                  Здесь то же самое, код может упростить, но не является серебряной пулей. Просили пример где lazy полезно, я его привел. Хочешь синтаксическим сахаром, хочешь костылями.
                  Цитата Исмаил Прокопенко @
                  Достаточно написать 3 строчки
                  C=f3(e,f,g)
                  B=f1(C,D)
                  А=B*C

                  Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих.
                  И что? В третьей строчке фактически будет вычислены первая и вторая. Итоговое время выполнения не изменится вообще никак. Да и итоговый машинный код будет одинаковым.

                  Ты наверное никогда не пишешь
                  a = (b + c) * d + e / f;
                  это же ЛАВИННОСТЬ!!!
                  надо писать
                  bc = b + c;
                  bc = bc * d;
                  ef = e / f;
                  a = bc + ef;

                  Так-скаать "размазать" код по строчкам, для более плавного выполнения. :lool:
                  Сообщение отредактировано: applegame -
                    Цитата applegame @
                    И что? В третьей строчке фактически будет вычислены первая и вторая. Итоговое время выполнения не изменится вообще никак. Да и итоговый машинный код будет одинаковым.

                    Не верно.
                    Во первых если значения некоторых переменных вычислить заранее, то память под уже не нужные переменные можно освободить. А в случае лавины потребуется сразу вся память, так как придется "держать в уме" сразу все переменные.
                    А во вторых, как я понимаю, в случае "ленивых языков" компилятор вместо вставки уже вычисленного ранее значения вставляет некий "код пролога" (например вызов функции), который вычислит это значение. Т.е. некоторую ссылку на код, который формирует нужное значение.
                    Сообщение отредактировано: Исмаил Прокопенко -
                      "Лавины" действительно могут быть, я выше писал об этом. Возможно, это следствие кривых рук и неумения использовать haskell, но тем не менее.
                      Сообщение отредактировано: D_KEY -
                        Цитата D_KEY @
                        это следствие кривых рук и неумения использовать haskell

                        Так с прямыми руками и хаскелл с его ленивыми вычислениями не нужен. Так?

                        Хороший программист и так пишет программу так, чтобы она наиболее оптимально работала и использовала ресурсы.

                        А все эти "ленивые вычисления" и прочие костыли - это просто средства защиты от криворуких программистов.

                        Так?

                        Добавлено
                        Ведь не секрет, что 99% программистов имеют, мягко говоря, неудовлетворительную квалификацию и интеллект. Не случайно же у них так "туго идут" общеинженерные дисциплины.

                        Поэтому приходится изощраться и придумывать разные костыли, чтобы даже низкоквалифицированный программист мог хоть какую-то пользу приносить
                          Цитата Исмаил Прокопенко @
                          Достаточно написать 3 строчки
                          C=f3(e,f,g)
                          B=f1(C,D)
                          А=B*C


                          Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих.
                          Да и третья вычисляться не будет. Результат-то пока не нужен.
                          Реально эти выражения компилируются в дерево операций, как только значение понадобится, оно по этому дереву вычисляется. Ненужные более ветви сразу отсекаются. На практике ты получишь тот же код, что и в обычном императивном языке, разве что порядок вычислений может поменяться.
                          Цитата applegame @
                          Поэтому мы видим вокруг тонны инженерного факапа
                          Это не потому, что инженер допускает факап. Это потому, что он не считает его факапом.
                          Цитата Исмаил Прокопенко @
                          Во первых если значения некоторых переменных вычислить заранее, то память под уже не нужные переменные можно освободить. А в случае лавины потребуется сразу вся память, так как придется "держать в уме" сразу все переменные.
                          А зачем их держать в памяти? Как только все вычисления со значением закончатся, ненужное значение сразу можно чистить. Хранить приходится только именованные переменные, но в функциональных языках они используются нечасто. Вот в императивных языках с этим сложности, там переменных на порядок больше, а без отслеживания времени жизни приходится все переменные держать в активном состоянии.
                            Исмаил Прокопенко, у вас в посте очень мало конструктивных высказываний. Возможно даже совсем нет.

                            Добавлено
                            Цитата amk @
                            А зачем их держать в памяти? Как только все вычисления со значением закончатся, ненужное значение сразу можно чистить. Хранить приходится только именованные переменные, но в функциональных языках они используются нечасто.

                            Проблема в том, что даже ленивые списки часто действительно используются не по делу. Даже в примерах.
                            Там, где в "императоры языках" был бы обычный обход, в функциональщине часто видим списки, которые таки да, сохраняют результат вычислений и держат его в памяти по крайней мере до окончания обхода(хотя в некоторых случаях правильной хвостовой рекурсии предыдущие элементы списка можно будет освободить, но не уверен, что это делается).
                            Сообщение отредактировано: D_KEY -
                              Цитата D_KEY @
                              в функциональщине часто видим списки, которые таки да, сохраняют результат вычислений и держат его в памяти
                              Попытка сымитировать состояние (как бы переменные и цикл) при использовании парадигмы, где состояния в принципе быть не должно. Программист просто никак не может отойти от привычной императивщины.
                                Ой не пойму, об чём вообще спор. От перемены мест вычислений в программе сумма затребованных ими ресурсов не изменится. Это в идеале, в реальности на хранение списков нужны дополнительные ресурсы, но и на вычисления по месту нужны дополнительные ресурсы, и бывает, что больше одних, а бывает, что и других.
                                Другое дело, что некоторые алгоритмические фрагменты могут перекрывать друг друга, поэтому вычисления по факту требования их результата могут отменить некоторые предшествующие элементы списков, поэтому ленивость является главным образом оптимизацией в рант-тайм, выбрасывающая ранние вычисления, перекрытые последующими. Если архитектура языка ориентирована на отложенные вычисления, то списки априори дёшевы, и проблема лишь в том, чтобы эту архитектуру реализовать на практике. О чём тут ещё спорить-то?
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0542 ]   [ 16 queries used ]   [ Generated: 29.03.24, 13:09 GMT ]