Здравствуйте, mike.b, Вы писали:
MB>1.1. Конечно, возможно, это отлично, что каждый может определить свои примитивы для control flow. Вроде монад, скобок, стрелки. Но оказывается (?) этих примитивов не хватает. Они не универсальны, и в большом проекте возникает куча собственных промежуточных абстракций, которые реализуют собственный control flow через манипулирование функциями. Можно сказать, что это отлично, что так и должно быть, ведь, это — true fp.
я, значица, бейсик-пограммер и мне тоже кое-что непонятна в С: хорошо, канешно, что можно определять свои функции, вроде факториала или сортировки. но оказывается стандартного набора доп. функций нет, и в каждом проекте приходится определять свои собственые функции. куда мир катится, а?
MB>Но такой подход приводит к куче мелких функций, состоящих сплошь из идентификаторов, смысл которых совершенно непонятен. И непонятно, от куда эти функции взялись, и где они будут использоваться. Для того, чтобы вникнуть в происходящее, нужно пройти весь граф вычислений от вершины до самого низа, где и запрятана вся функциональность. Непонятно, как можно менять эту структуру, добавлять функциональность в ней, оптимизировать, улучшать, не меняя эту структуру целиком, что сложно.
патом, при использовании этих доп. функций алгоритм программы полностью запутыфается, и понять его невозможно без изучения внутренностей каждой из них. в бейсике всё сделано реально круто — есть десяток стандартных примитивов и всё пишешь напрямую на них, и ничего больше изучать тебе никогда уже в жизни не понадобится. так ведь гораздо удобней, да и строках бесиковская программа выходит длиннее, а значит платят больше
MB>Хороший пример этого неудобства — книга Пейтона Джонса о разработке компилятора и виртуальной машины для функционального языка. Где для каждой мелкого с точки зрения функциональности дополнения приходится переписывать ВСЕ функции. Конечно, эти изменения внести можно быстро благодаря структуре языка. Но их нужно внести МНОГО.
вот например я изучаю С по книге о сжатии данных. не ссамый лучший конечно учебник, но главное там все примеры написаны на С. и что я вижу? что для реализации каждого алгоритма сжатия приходится писать свою функцию. не лучше было бы в самом начале разщработать одну универсальную и затем вызывать её с разными параметрами? тогда остаток книги можно было бы сократить, а сэкономленную бумагу пустить на протирку жоп
MB>И это черта не только примеров в этой книге. Я попробовал немножко похакать вокруг исходников Frag — приходится делать то же самое. Что я делаю не так?
я пробовал изучать C по другой книге, посящённой созданию 3d-шутеров, и тоже ни чаго не понял. что я делаю не так?
MB>1.2. Сначала в Haskell мы упорно уходим от side effects, уходим от переменных, а потом очень много кода пишем при помощи монад. Но монады — это не очень гибкий инструмент, потому что связывание функций возможно только единственным способом.
к тому же фнукции — негибкий инструмент потомушта для них предусмотрен всего один способ вызова. вот если бы f() ознаало одно, а f[] — другое, это было бы реальное преимущество перед бейсиком
MB>Конечно, можно иметь несколько bind'ов, но это вряд ли приведёт к улучшению понимания кода. Да и как может быть заранее известно, какой именно bind понадобится, и как они должны взаимодействовать. Поэтому, для организации dataflow:
вот ещё одна проблема с фукциями — как их можно писать, если заранее неизвестно какие понадобятся. ну просто ума не приложу!
MB>1.2.1. Нужно делать world-состояние большим, включая в него большое количество значений. Но это сводит на нет все утверждения об автоматическом распараллеливание.
и ещё у С недостаток — на моём денди не работает. а сосед говорил, что будет. ну не мог же мой сосед наврать!
>Вычисление в монаде строго последовательные. А монады сплошь и рядом. Непонятно в этом случае, а зачем уходить от переменных и от описания dataflow при помощи них? Да, они требуют более мощных алгоритмов автоматического распараллеливания, но эти алгоритмы дают и больше возможностей. А насчёт того, насколько это возможно, так посмотрите компиляторы Fortran и С от Intel и Sun.
а для бейсика емсть калькуятор МK-85, значит бейсик лучше!
MB>1.2.2. Можно попробовать разбить все вычисления на вычисления в небольших монадках, но это увеличивает количество аргументов у функций, заставляет придумывать функции для склейки значений. Снова усложнение. Зачем, если с переменными проще?
вот и я о том же. зачем вызывать функции, передавать им аргументы, если можно все вычисления написать самому. ну ведь проще так, чесслово!
MB>1.2.3. Стрелка спасает, но не очень эффективно: опять же требует много дополнительного кода для манипуляции над значениями.
а ещё говорят там есть классы — это уж вовсе недецкий изврат
MB>2. Возможно, всё хорошо, пока дело не доходит до вызова main. Вызов — же это действие — 'примени main к такому-то значению', а не описание применения. Что-то у меня в голове не сходится: мы долго бежим от того, чтобы использовать действия, и в итоге, оно оказывается чуть ли ни самой фажной частью системы. Зачем писать программы, которые никто не запускает? Как насчёт концептуальной целостности?
и ведь главное — всё равно на одних описаниях функций ты ничего не сделаешь, их ведь ещё вызывать надо. т.е. концептуальной чистсоты нету. а раз так, то можно значительно упростить язык, убрав из него функции. всё равно ведь он останется тьюринг-полным, пралльно я рассуждаю?
MB>В чём я не прав? Надеюсь, тут есть гуру, которые смогут открыть мне глаза.
на деревню дедушке Мазаю от пионерской организации. передать в сосбвтенные руки
