Программирование в таблицах — новая концепция записи условных (и не только) конструкций

    Не так давно, в процессе поиска в сети альтернативных подходов к программированию я наткнулся на очень интересное видео. Это 40-минутная презентация с интригующим названием «No Ifs, Ands, or Buts. Uncovering the Simplicity of Conditionals». Автор презентации Джонатан Эдвардс (Jonathan Edwards) рассказывает о новой концепции записи условных конструкций при помощи созданных им схематических таблиц (schematic tables).

    Эта тема должна быть интересна всем, кто хоть немного интересуется программированием. Если у вас нет в распоряжении лишних сорока минут или вы не можете посмотреть видео по какой-либо другой причине, предлагаю ознакомиться с моим кратким пересказом презентации Джонатана.

    Предисловие


    Автор оригинальной идеи на простых примерах показывает нам ключевые особенности схематических таблиц и сравнивает их с традиционной записью условных конструкций на языке C (на самом деле Java, но в примерах в основном используется его C-подножество). Кроме видео, на данную тему есть также статья, где концепция описана более формальным языком. Так как данный пересказ нацелен на то, чтобы вкратце поведать вам о самых интересных моментах презентации, я опустил некоторые математические подробности, которыми оперирует автор, и сосредоточился на примерах и сравнениях.

    Схематические таблицы


    Рассмотрим для начала структуру схематической таблицы на примере функции fib. Она принимает на вход один параметр n и возвращает число из последовательности Фибоначчи, порядковый номер которого равен значению n. Исходный код функции:
    int fib(int n) {
     assert(n >= 0);
     if (n == 0) return 0;
     if (n == 1) return 1;
     return fib(n - 1)
            + fib(n - 2)
    }


    * This source code was highlighted with Source Code Highlighter
    .
    Схематическая таблица данной функции имеет следующий вид:

    Рис. 1. Схематическая таблица функции fib

    В первом столбце записываются переменные. В этом примере у нас их только две — входной параметр in и возвращаемое значение out. Второй столбец содержит утверждения (Assert). Здесь он используется для проверки неотрицательности входного параметра. Во всех последующих столбцах записываются условия. Первый столбец после Assert считается истинным, когда in == 0, второй — когда n == 1, и третий — при n >= 2.

    Таким образом, столбцы отвечают за условия. Строки таблицы, в свою очередь, отвечают за действия. Они содержат функции, которые выполняются последовательно одна за другой, начиная сверху и двигаясь вниз. Давайте запишем последовательность действий, определенных в схематической таблице функции fib:
    1. Если in < 0, сообщить об ошибке (стандартное поведение при невыполнении условия в столбце Assert) и завершить выполнение.
    2. Если in == 0, вернуть 0.
    3. Если in == 1, вернуть 1.
    4. Если in >= 2, перейти к следующему пункту.
    5. Передать результат выражения in - 1 в качестве входного параметра в рекурсивный вызов fib.
    6. Передать результат выражения in - 2 во второй рекурсивный вызов функции.
    7. Вернуть результат сложения значений, полученных из обоих рекурсивных вызовов.
    Давайте теперь напишем юнит-тест, чтобы проверить корректность работы составленной функции. Сделать это очень просто — надо создать новую пустую функцию, в столбце Assert записать утверждение, которое должно выполняться, а в следующем за Assert столбце необходимо записать безусловный вызов проверяемой функции, передав ей на вход интересующие нас значения. Результат выполнения функции будет выведен в столбце «=». В нашем случае тест называется fib test.

    Рис. 2. Функция fib в процессе выполнения

    Как видно из рисунка, в качестве входного параметра функции было передано число 3, и она вернула нам 2. Запись в столбце Assert значит, что результатом функции не должна быть ошибка. Заметьте, что таблица справа — это та же самая схематическая таблица, которую мы создали для функции fib, только теперь в нее был добавлен еще один столбец с именем «=», в котором для каждой строки записан результат операции, выполняемой в данной строке. Кроме того, серым цветом залиты те столбцы, условия которых не выполнены. В данном случае выполняется условие последнего столбца (3 >= 2), и мы получаем результат сложения значений, полученных из двух рекурсивных вызовов функции fib.

    Возможность просмотра всех промежуточных значений является одной из замечательных особенностей схематических таблиц. Джонатан утверждает, что позаимствовал эту идею у электронных таблиц (spread sheets), в которых все значения вычисляются на лету. Если кликнуть на синюю стрелку, над которой находится курсор на рисунке выше, появится еще одна таблица, соответствующая рекурсивному вызову функции fib. Этот процесс можно продолжать и дальше. В каждой следующей таблице мы видим, какой столбец является истинным в текущем вызове, и значения операций, выполняемых в каждой строке таблицы.

    Рис. 3. Раскрытие рекурсивных вызовов функции

    Подобная возможность потенциально может сделать процесс отладки приятным занятием.

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

    Переключатели (switch-statements)


    Попробуем представить условие-переключатель при помощи схематической таблицы. Допустим, мы пишем игру, в которой присутствует метод для вычисления нанесенного урона. Назовем его damage. На основании типа атаки, ее неожиданности и уровня защиты атакуемого метод возвращает определенное значение урона.

    Исходный код метода:
    enum Attack {Magic, Melee};

    int damage(Attack attack, bool surprise, int defense) {
     int power;
     
     switch (attack) {
      case Magic:
       power = 5;
       break;
      
      case Melee:
       power = 4;
       break;
     }
     
     int effectiveness = power * (surprise ? 3 : 2);
     
     switch (attack) {
      case Magic:
       if (effectiveness >= defense)
        return effectiveness - defense;
       return 0;
      
      case Melee:
       return (effectiveness / defense) * 2;
     }
    }

    * This source code was highlighted with Source Code Highlighter
    .
    Соответствующая ему схематическая таблица:

    Рис. 4. Схематическая таблица метода damage

    Рассмотрим те элементы таблицы, которые нам еще не встречались. Во-первых, здесь присутствует несколько входящих параметров, каждый из которых принадлежит имеет определенный тип. Во-вторых, после столбца Assert появился новый столбец True. В нем содержатся безусловные действия, которые выполняются всегда. В-третьих, в первом столбце, кроме входных параметров и возвращаемого значения, появился еще один тип переменных — локальные переменные. Строго говоря, каждая строка без имени является анонимной локальной переменной (это наглядно продемонстрировано в таблицах юнит-теста, который был рассмотрен ранее). Но в некоторых случаях удобно дать строке некоторое имя, чтобы потом можно было использовать ее значение в последующих операциях и функциях.

    Итак, двигаясь сверху вниз и размышляя слева направо, мы приходим к такой последовательности действий:
    1. На основании типа атаки присвоить локальной переменной power значение 5 или 4.
    2. На основании признака неожиданности атаки, присвоить анонимной локальной переменной значение 3 или 2.
    3. Присвоить локальной переменной effectiveness результат произведения двух переменных, значения которых были определены в пунктах 1 и 2.
    4. Если attack == Magic, Вычесть из effectiveness значение переменной defense.
    5. Если attack == Magic & defense <= 0, вернуть значение 0.
    6. Если attack == Magic & defense >= 1, вернуть результат вычитания effectiveness - defense.
    7. Если attack == Melee, вернуть результат выражения effectiveness / defense * 2.
    Как видно из примера, операция в столбце True (пункт 3) выполняется всегда, когда до нее доходит очередь — она не зависит от выполнения того или иного условия. Все остальные операции выбираются из столбца, условие которого является истинным для текущего набора входных параметров.

    Горизонтальные линии отображают потоки данных между условиями, определенными в таблице. Таким образом, наличие горизонтальной линии всегда свидетельствует об использовании данных, посчитанных в одном условии (или безусловно) в вычислениях с другим условием.

    Визуальное сравнение исходного кода метода damage и соответствующей ему схематической таблицы при одном и том же размере шрифта:
    Рис. 5. Сравнение исходного кода метода damage с его схематической таблицей

    Слева сравнивается размер конструкции на экране при двух различных способах записи, а справа наглядно показано переплетение логики метода. Так как в текстовой записи логики программы присутствует только одно измерение, в нашем примере возникает «пробка» — зеленый участок посередине помещен между двумя условными блоками. Это немного затрудняет восприятие кода, если мы хотим, например, узнать результат выполнения при выполнении условия attack == Magic. В случае схематической таблицы, логика и действия расположены на двух различных осях, ортогональных друг другу. И здесь мы приходим к фундаментальному принципу концепции схематических таблиц — представление кода в двух измерениях, вместо одного.

    Рис. 6. Фундаментальный принцип концепции схематических таблиц

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

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

    Рис. 7. Простота и универсальность схематических таблиц

    Оказывается, что такие виды условных конструкций, как вложенные if-then-else условия, switch-выражения и даже полиморфизм (не рассмотренный здесь), — все они сводятся к единому виду при использовании схематических таблиц. На мой взгляд, это хороший знак. Здесь будет уместным привести высказывание Альберта Эйнштейна:
    Все должно быть простым, насколько это возможно, но не проще.

    В данной заметке я не рассматривал полиморфизм, так как он не вносит больших изменений в структуру таблицы. Пример того, как заменить перекрытие (overriding) метода на языке Java записью в виде схематической таблицы, начинается на видео презентации с 29-й минуты.

    Заключение


    Описанная концепция является одной из нескольких интересных возможностей, положенных в основу разрабатываемого Джонатаном языка программирования Coherence. Скриншоты в статье были сделаны с видео презентации. Автор разработал оболочку, которая предоставляет средства для интерактивной работы со схематическими таблицами, их редактирования и выполнения, а также написания юнит-тестов. Увидеть все это в действии можно на видео. Автор также выложил исходный код оболочки (написанный на С#) вместе с исполняемым файлом для ОС Windows. [скачать]

    Дополнительные материалы по теме, включая статью с формальным описанием концепции схематических таблиц, можно найти на сайте www.subtextual.org. У автора также есть блог. Хоть он и редко обновляется, там можно найти описание и других интересных идей, таких как, например, co-actions.

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

    Благодарю за внимание.

    UPD:
    В комментариях люди высказывают сомнения по поводу целесообразности применения схематических таблиц на практике. Попробую немного прояснить ситуацию.

    Данный метод записи логики программы ни в коем случае не позиционируется как завершенная разработка, для которой осталось только написать IDE с компилятором и пустить ее в массы. На данный момент это только концепция. На мой взгляд, она наталкивает на некоторые размышления о текущем положении дел в области программирования. Я решил, что хабрасообществу будет интересно узнать о ней, так как в последнее время из новый веяний в области мы можем наблюдать лишь появление новых языков, которые основываются на уже существующих парадигмах программирования, не смотря на то, что включают в себя механизмы для более простой организации параллельных вычислений.

    UPD2:
    Прошу прощения за дезинформацию. Исходники оболочки, написанный на C#, и исполняемый файл для ОС Windows можно скачать с сайта проекта, см. первый вопрос в разделе FAQ. Subtext — это ее старое название, сейчас проект носит имя Coherence.


    P. S. Если у вас есть замечания по стилю изложения или оформлению статьи, не стесняйтесь писать их в комментариях или мне лично. Я буду рад любой критике.
    Share post

    Similar posts

    Comments 54

      +4
      Интересно. Только вот кажется мне, что образ мышления для программирования подобным образом придется поменять. Условные переходы, циклы и прочее, более естественны для восприятия и понимания. Понятное дело что это только вариация на тему, но думаю стоит ввести дополнительные абстракции для данного случая, потому что сложные программы читать в таком виде будет крайне тяжело, если вообще возможно.
      Хотя в тоже время визуализация положительно скажется на совместных обсуждениях кода с коллегами и при парном программировании.
        +2
        > Условные переходы, циклы и прочее, более естественны для восприятия и понимания.
        Вы так говорите, потому что вы так учились программировать) А схематические таблицы — это и есть более высокий ровень абстракции.

        При записи на языке программирования, вам приходится думать по одному символу за раз:
        «i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».

        А при записи в схематической таблице вам нужно создать колонку, добавить в нее операцию * и перетащить мышкой соответствующие переменные на место аргументов этой операции.

        Джонатан пытается сказать нам, что история программирования еще не закончена и можно найти лучшие способы записи программной логики, чем набирание кода по одному символу (autocompletion не в счет). И я с ним согласен.
          +1
          С другой стороны, чтобы понять код, я читаю его в одной последовательности — сверху вниз слева направо. Пока я пытался понять, что же делает таблица, глаза бегали во все возможные стороны. А если она разрастется до, скажем, 20 условий и переменных, то придется крутить головой еще сильнее чтобы вспомнить, какая строка \ столбец за что отвечает.

          Концепция сетки чем-то напоминает мне мой первый инструмент программирования — The Games Factory. Так правда было слегка наоборот — по вертикали условия, а по горизонтали объекты, над которыми можно проводить действия. Вообще, достаточно интересный проект.
          Для нелюбителей платить деньги есть более молодой бесплатный аналог, созданный бывшими пользователями TGF — Scirra Construct.
            0
            > можно найти лучшие способы записи программной логики
            а можно и худшие
              –4
              Спасибо, кэп)
              +3
              > При записи на языке программирования, вам приходится думать по одному символу за раз:
              > «i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».

              Думать по одному символу за раз? Это как?

              У меня набором кода обычно руки занимаются, голова о наборе символов не думает.

              ИМХО, изучение слепой печати эффективнее любого «мышиного» интерфейса.

              Да, кривая обучения гораздо круче. Но это как с карандашом — десять лет учишься им пользоваться, потом всю жизнь используешь не замечая.
                +2
                >При записи на языке программирования, вам приходится думать по одному символу за раз

                При чтении человек воспринимает информацию целыми токенами, которые состоят, как минимум, из слов, а обычно — из целых фраз. По буквам текст воспринимает только ребёнок, начинающий учиться читать.
                  0
                  Забавно, когда минусуют за общеизвестные истины. Это за их очевидность (но тогда непонятен тезис того, на чей вопрос ответ), или кто-то не знает очевидных вещей?

                  Впрочем, даже если очевидные вещи кому-то неизвестны, то странно, как можно было пройти мимо заполнившего весь Интернет в своё время мегабояна про малую важность порядка букв в словах: «По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужю бкуву по отдльенотси, а все солво цликеом.»
              +2
              Перенесите топик в один из тематических блогов.

              Тогда топик попадет на главную и его увидит гораздо больше хабралюдей, чего статья, конечно же, достойна.
                –2
                Спасибо за подсказку. В разделе «программирование» подходящего блога не нашлось) Поместил в «Я рекомендую».
                +2
                Напоминает работу компилятора при анализе кода для оптимизации
                  +1
                  Ну что значит новое? Нам похожие таблички еще в школе на уроках информатики показывали))
                    –3
                    бредовая идея
                    это все нормально только на ваших академический примерах
                    так же как и хаскел в универе показывают. для рекурсии и т.п. муры
                    ну, и плюс запутанные у вас графики
                    код гораздо понятнее
                      +2
                      Наверняка таблицу можно строить автоматически. Ну или код — автоматически. Так что такие идеи только дополнят наш код.
                        +1
                        Haskell и прочие языки функционального программирования представляют не только академический интерес.
                        К примеру, масштабируемость многих сервисов небезызвестного Google достигается как раз использованием элементов функционального программирования.
                        0
                        Спасибо, это интересный подход. Наверняка тут откроются интересные возможности для реализации параллельности — ведь столбцы таблицы в некотором смысле независимы…
                          0
                          Перенесите в блог «Я сумасшедший»)
                            +2
                            Похоже, что автор в рамках проекта в очередной раз изобрёл сопоставление по образцу (pattern matching). Или в презентации предполагалось, что аудитория об этом ничего не знает.
                              +1
                              Непонятно, почему бы не оставить возможность задавать эту таблицу в коде (текстом), строчка кода — строка таблицы. В качестве альтернативы. Текст — уж очень он универсален.
                                0
                                Пока что предлагается использовать таблицу как основу для генерации кода. На видео первый пример (который я не привел в своей заметке) показывает, как порой можно ошибиться при записи условий, интуитивно кажущихся правильными. И как этого можно избежать при использовании таблиц.
                                +2
                                ну не знаю, стандартная запись кажется удобнее, может, потому что привычнее…
                                  0
                                  кажется, эти таблички и так строятся на каждому углу в разных IDE.
                                  в той же студии были такие таблички, только как способ анализа кода
                                    0
                                    Концепция более или менее ясна, хотя и спорна, но я не нашёл в статье, хотя может из-за своей невнимательности, ссылки на инструмент, которым можно было бы её опробовать. Если такой инструмент есть — укажите на него.
                                      0
                                      Для скачивания оболочка пока что не доступна. Это исследовательский проект автора.
                                        0
                                        Я ошибся. Здесь можно скачать исходник вместе с exe-файлом.
                                        0
                                        похоже на графический редактор для DSL
                                          0
                                          да, в общем, им и является.с DSL вообще беда — что ни придумаешь, все под них можно записать.
                                          +2
                                          какая-то помесь носорога с бегемотом — табличек с синтаксическим анализом. Самое главное, непонятно, что тут от собственно табличек? Наличие столбцов — оно, знаете-ли, не показатель. В целом, конечно, занимательно, но ИМХО совершенно нежизнеспособно. Абстрактное такое ощущение, что автор нашел на каком-то этапе такую форму записи, но пока не обкатал и не отбросил ее, как излишне громоздкую.
                                            +6
                                            >>Программирование в таблицах — новая концепция…

                                            Ждём программирования на дивах
                                              +1
                                              Получается что код будет очень сильно расти вширь, потому что любое ветвление/условие добавляет столбец. Я представил такую таблицу для функции WindowProc с ее последовательностью case. Тут не просто никаких wide-мониторов не хватит, а задолбаешься прокручивать код туда/обратно. И не очень понятно, как будет выглядеть IDE для такого кода и как в нем работать.

                                              Идея сама по себе интересная и сырая. На академических примерах, конечно, все красиво, но в более-менее большой программе, боюсь, будет кошмар.
                                                0
                                                А вертикальная последовательность case вас не беспокоит? В любом случае, устройство Windows-приложения не является образцовым примером проектирования. В реальных задачах можно было бы создать отдельную таблицу для каждого case-случая, и передавать им в качестве входных параметров текущее состояние WindowProc. А сгенерированный код, по желанию пользователя, может преобразовать таблицы в case-случаи.
                                                  +1
                                                  Если создавать отдельную таблицу для каждого случая, то мы получим такую же хрень, как во флеше, когда каждый обработчик в отдельном окошке. Во многих случаях удобно, когда программа вся вместе, а не разорвана по кускам. Та же самая хрень возникнет, если IDE будет показывать только текущий столбец на экране или как-то так.

                                                  Вертикальный case меня не очень беспокоит. А горизонтальный очень. Сейчас размер строк в программе регулярно приближается к 60 символам или переходит через них, если разместить 30 case-случаев по горизонтали, то получится около 2000 символов на строку. К тому же будет теряться очень много полезного места на отступы и выравнивание по столбцам. Это если размещать это в виде обычного текстового файла в таком виде, как это на экране. Если же использовать внутри файла какую-то разметку или какой-то двоичный формат (как тот же флэш), то мы приходим к той же проблеме. Опять-таки жесткая привязка к IDE- не есть хорошо. Программируя на C, я могу пользовать Kdeveloper, Visual Studio, Eclipse или просто тупо набирать программу в Far'е. Здесь такое невозможно.

                                                  С другой стороны, флэшеры мучаютсяработают и не жужжат -)

                                                  «Устройство Windows-приложения не является образцовым примером проектирования» как аргумент не принимается, мы живем в том мире, который есть, и WinAPI ради нового стиля программирования никто переделывать не будет.

                                                  Я не вижу особых преимуществ такой двумерной схемы. При переходе c Borland C++ на Delphi преимущества были налицо, а здесь они весьма спорные. Внешне это напоминает переход на другой язык программирования. Примерно как перейти с C++ на Fort или Lisp. К тому же дополнительно нагружаются мозги лишним измерением.

                                                  Кстати говоря, не уловил пассаж про «более высокий уровень абстракции». VCL, MFC, Qt- это абстракции по отношению к WinAPI. Таблицы- это иной способ записи программы. К «высоким уровням абстракции» это отношения не имеет.

                                                  Имхо- технология сырая. Если ее доведут до ума- будет очень интересно посмотреть.
                                                +1
                                                Я не понял как эта поделка позиционируется? Новая нотация для алгоритмов вместо старых блок-схем? Или язык программирования?
                                                  0
                                                  как концепция
                                                    0
                                                    концепция чего?
                                                      0
                                                      Концепция записи логики программы. Входит в состав языка Coherence — академической разработки товарища Джонатана Эдвардса.
                                                        0
                                                        В смысле, это альтернатива чему? Блок-схемам, текстам, языку программирования?
                                                          0
                                                          альтернатива процессу набора кода
                                                  +1
                                                  Язык программирования нужен, чтобы абстрагироваться от работы процессора, чтобы речью (английской обычно) объяснить процессору что делать.
                                                  Все эти схемы не похожи на то, как описывают издавна алгоритмы: «Варить до готовности» — варить() пока! готово?, «А коли дань платить не будете, войско наше на земли ваши вступит» — напасть если! дань_уплачена, определённый интеграл — с A до B с шагом dx…
                                                  Даже если научиться их читать и писать — всё равно в голове будут те же if, switch, while.
                                                    0
                                                    Действительно, наша логика ближе к графам, чем к таблицам.
                                                    0
                                                    Сначала верстали на таблицах, теперь программируют… Даешь теперь <div>'ное программирование!
                                                      +1
                                                      в любом случае, визуальное программирование какими-то блокс-хемами — это будущее, имхо. в том или ином виде…
                                                        +1
                                                        В качестве обучалки для детей — это настоящее. Иного применения думаю не существует, т.к. человеку проще писать на мета-языке, чем блок-схемы делать в специальной среде.
                                                        0
                                                        У кого-нить exe запустился? Падает с «ошибкой при инициализации» 0xc0000135, вин xp pro 2002 sp3.
                                                        Мне нравиться.
                                                          +1
                                                          Ошибка в первой строке сто тридцать шестого столбца.
                                                            0
                                                            действительно, нашел-исправил-запустил). В себе содержит demo1 и demo2, различаются иерархией классов.
                                                          0
                                                          Не привязываясь к конкретной нотации: иногда необходимо приподняться над привычным способом чего-то делать и посмотреть на это под другим углом.

                                                          Не далее как несколько дней назад, убил времени на написание достаточно запутанной логики. Потом сел, подумал, начертил таблицу, разметил условия и переходы, фактически нарисовал конечный автомат. После того как всё встало на свои места, перенести это в обычную нотацию обычного языка программирования — было делом исключительно тривиальным.

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

                                                            Как альтернативное представление кода для задач отладки и оптимизации — тоже не хватает наглядности. Для проектирования тоже не подходит…

                                                            Надеюсь, найдется достойная сфера применения.
                                                              +1
                                                              В заголовке фигурирует фраза «концепция записи условных (и не только) конструкций».
                                                              В материале освещены как раз только условные. Можно пример «не только условных»? А то С, С++, C#, Java, VB да и вообще все остальные распространенные языки оперируют не только условными конструкциями. И полиморфизм сравнивать с такой таблицей я бы не стал, ибо у него множество более полезных применений, чем то, в котором его может якобы заменить такая концепция.
                                                                0
                                                                «И не только» — это составление рабочих функций, их выполнение, отладка, составление юнит-тестов, механизм рекурсивных вызовов.
                                                                  0
                                                                  Табличное представление для if/case в данной концепции весьма удобно (мне кажется), если привыкнуть.
                                                                  А вот «составление рабочих функций, их выполнение, отладка, составление юнит-тестов, механизм рекурсивных вызовов» — можно пример чего-нибудь из этого списка?
                                                                  Просто такие таблицы не более чем визуальная оболочка. С тем же успехом можно писать на том же C# а для таких вот конструкций сделать визард или возможно даже Debuger Visualizer, упрощающие понимание кода с множеством if-ов и прочее.
                                                                  В общем, прикольно, интересно, но хз зачем…
                                                                    0
                                                                    «… можно пример чего-нибудь из этого списка?»
                                                                    Эти вещи я кратко описал в заметке. В частности, составление теста и выполнение функции можно посмотреть в примере с Фибоначчи. Рекурсивные вызовы там же. На видео автор показывает пример ошибки в юнит-тесте (временная отметка 17:20) и демонстрирует, как можно редактировать код функции прямо в процессе ее выполнения.

                                                                    С тем же успехом можно писать на том же C# а для таких вот конструкций сделать визард или возможно даже Debuger Visualizer, упрощающие понимание кода с множеством if-ов и прочее.
                                                                    А Джонатан хочет донести до нас мысль, что такие конструкции можно изначально записывать в таблицах, которые автоматом разрешат противоречивые случаи, а затем преобразовать результат в код и сэкономить таким образом время и затраченные усилия.
                                                                0
                                                                Это же академический проект. Вероятнее всего он хорошо подойдет для верификации программ, а не для разработки. Непонятно только что концептуально нового в этом программировании таблиц? На полке лежит книга Э.Хамби Программирование таблиц решений (Programs from decision tables) 1976, не далеко за 35 лет прогресс шагнул (
                                                                • UFO just landed and posted this here

                                                                  Only users with full accounts can post comments. Log in, please.