И, кстати, кроме схематичных таблиц у автора есть и другие неплохие решения (всё насайте):

- сначала он публикуетманифест, где выражает своё недовольство состоянием дел в области инженерии ПО. Часть взглядов такие же, как и у Седова ("машина теорий"). В частности, в т.ч. он вполне адекватно критикует распространенные решения для визуального программирования, утверждая, что отображение исходного кода (фактически, не видоизмененного) просто в двумерной плоскости явно недостаточно для получения существенно (!) нового качественного уровня в методологии разработки ПО;

- Example Centric Programming:док- первый шаг, где делается попытка организовать программирование через примеры. Без наглядных примеров тяжело формировать абстракции, выявлять закономерности, находить аналогии и т.д. Цель: организовать процесс разработки так, чтобы формирование исходного кода, отладка, тестирование, рефакторинг, REPL были сразу в одном флаконе - это одновременный процесс. В любой момент можно запустить расчёт вычислений (пример), зафиксировать результаты (в т.ч. внести в историю, их сравнивать, и т.д.), фиксировать возникающие ошибки/проблемы, указывать неопределенные вычисления (незавершенный исходный код) и система запросит значения для них, т.е. мы постепенно выстраиваем код, через поиск правильного решения, с непрерывными экспериментами. Одним словом, обобщены принципы продвинутой лисп-машины;

- Synthetic Trees:демо,док- некий семантический редактор. Цель: максимальная простота и "example centric programming". Данные и вычисления задаются в виде деревьев, внешний вид поближе к привычному текстовому представлению (автор осторожно акцентирует внимание на том, что реальная практика на сегодня такова: масштабы ПО, созданного с помощью текстовых языков и любых иных альтернатив - не соизмеримы), причём вычисления отражаются так, чтобы показать, что происходит в стэке. Основное редактирование программы выполняется через мышь (копирование или драг с дропом), есть понятие ссылок и связывания (что даёт возможность осуществлять переименование объектов с минимум затрат), и др. (лично для меня, деревья - не лучший вариант, плюс не всё гладко с эргономикой);

- Schematic Tables - представленные здесь схематические таблицы. Видимо, дальнейшее развитие "adaptive conditionals" из мыслей для схематического редактора, как попытка объединить деревья вычислений с таблицами решений, плюс и "example ..." не забыто;

- Coherence:демо,док- свой взгляд на реактивное программирование для упрощения алгоритмизации интерактивных и реагирующих систем, как дальнейшее обдумывание "action"-ов из семантического редактора. Реакции на изменения состояний задаются декларативно, система автоматически выстраивает согласованные действия для наката изменений, причём зависимости разруливаются во время runtime, с поддержкой транзакций и откатов изменений при неуспехе. НапоминаетAnimotron;

- Type as subtext:демо- использование идеи "example..." для системы типизации для языка а-ля сегодняшний мэйнстрим. Вместо явного декларирования имён типов используются только значения по умолчанию, плюс принцип прототипной типизации (полиморфизм и указание ограничений);

- Synchronously Updateable Views - пока только указано, что ведутся эксперименты с новой семантикой изменения состояний. Видимо, дальнейшее развитие идей Coherence. В этой области есть неплохо отработанные техники, например,Identity and Stateв clojure. М.б. увидим что-то новое, причём именно для "synchronously".

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

- "example driven development" (по аналогии с "test driven development"). Ещё в качестве примера можно глянуть на проектLight Table, где закладываются схожие принципы (кроме организации рабочего места по мотивамCode Bubbles), правда пока не так широко, кроме мгновенных "REPL-ов" нужен и их анализ (хотя если разработка на базе clojure, как в прототипе, то ограничений нет для реализации чего угодно под себя);

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