Устарел ли текст как форма представления программыСуществует мнение, что текст как способ представления программы устарел. Вот мнение Андрея Андреева, автора проекта «Странник»: «...можно (наконец !) уйти от текста при создании программ, заменив текстовый редактор структурным». В будущих языках программирования можно прийти к тому, что «программа — не текст, а набор конструкций». Конструкции эти, по его мнению, должны содаваться не с помощью текстового редактора, а с помощью специального структурного редактора. Программа должна создаваться не набором текста в текстовом редакторе, а заполнением форм структурного редактора. В результате этого полностью (или почти полностью) исчезнут ошибки периода компиляции; скорость компиляции возрастет в несколько раз. ...станет возможна online-компиляция программы (код оператора создается прямо в момент его ввода, а создание exe-файла будет просто компоновкой уже откомпилированых частей). Логика рассуждений понятна. Текст — это видимая сущность, из которой порождается суть программы, её семантика, невидимая часть. Можно напрямую создавать семантику программы, минуя «архаичный» текст. Исчезает надобность в каком-либо синтаксисе.Идея достаточно интересна. Похожие идеи были высказаны Евгению Зуеву: ...кроме низкоуровневого отображения программного модуля в виде дерева, должно быть и высокоуровневое представление программируемой модели как совокупности внешней среды и подсистем. Причем графически это может быть несколько разных типовых представлений, поддерживаемых системой программирования... на что он ответил статьёй "Древовидный" C++. Вот сжатый ответ Евгения:
Речь ... пойдет ... о том, как ... представить программу на ЯП в виде дерева (а на самом деле, конечно, графа)
и какие преимущества можно из такого представления получить.
Чем отличаются формат html от форматов pdf и doc? Да тем, что html-документ можно набрать в любом текстовом редакторе. А ведь можно было, уйдя от простого текста, разработать такой формат, который бы обеспечил бы и меньший объём документа, и скорость загрузки, и моментальность отображения. Но выбор сделан в пользу того, что мы сейчас имеем, и это не случайно. Так что прав Евгений Зуев: текст ещё долго будет служить программистам верой и правдой. Опубликовано: 2012.09.25, последняя правка: 2014.12.23 13:40
Отзывы✅ 2014/01/22 05:47, Сергей #0 Возможно, есть ещё одна вещь: кому-то может быть удобнее мышление образами, кому-то — словами. Вот и разделятся разработчики на сторонников изобразительного (или чертёжного) программирования и сторонников обычного, письменного программирования.✅ 2014/04/21 06:43, utkin #1 Скорее не устарел, однако хранение программ в других форматах заслуживает внимания. Действительно большинство языков программирования можно рассматривать в виде графов либо в виде деревьев (что является частным случаем графа). Деревья отлично структурируют программу и вполне соответствуют современным представлениям в программировании — блоки кода, классы, объекты и пр. Кроме того, уже частично готова инфраструктура, например XML позволяет хранить структурированные тексты программ без особых усилий.С программной точки зрения механизм также не вызывает затруднений — можно ввести в модель понятие блока, имеющего сходство с понятием узла в дереве. В зависимости от типа блок можно представлять как часть кода между программными скобками {} или begin-end, цикл, условие (там могут быть 2 блока), функция и пр. Оператор goto в таком случае становится чисто физически затруднительным. ✅ 2014/04/24 21:01, Автор сайта #2 Было бы интересно в результате компиляции получить и увидеть граф программы. На мой взгляд, текстовая форма хранения программы по-прежнему должна являться основной. Если же вводить/редактировать граф программы, то всё равно должна быть возможность преобразования в текстовый вид. Да и редактирование графа потребует соответствующих инструментов. Вещь, конечно, интересная, но не повлечёт ли это дополнительные сложности? Какие у Вас соображения?✅ 2014/06/17 04:22, utkin #3 Какие у Вас соображения? Фактически вторая Валентина собиралась (и следующая версия также планируется собираться в дерево). То есть при старте в один проход идет разбор структур в дерево. Это ни где не отображалось — тогда не было таких идей, просто так было удобно рассматривать процессы. Вычислительный процесс представлялся таким образом:Программа состоит из блоков (ООП не было, много сложностей и я ставил перед собой другие задачи). Каждый блок это узел дерева. Корневой узел — самый глобальный блок создается интерпретатором автоматически. То есть пустая программа это просто корень дерева. Узлы имеют ссылки на другие узлы (блоки программы) и на список строк (преобразованный текст программы). Блок это универсальная форма, которая может иметь несколько представлений: 1. Программные скобки — begin-end или {-} 2. Условия 3. Циклы 4. Методы (функции — много параметров / один результат). Все это описывалось одной структурой (просто заполнялись нужные для конкретного блока поля). Из блоков я не успел реализовать следующие возможности — загрузка методов из внешних модулей и подключение сторонних библиотек (DLL — тогда интерпретатор был жестко ориентирован на Windows) Таким образом, данные блоки могли бы быть: а) Представлены графически (при этом текстовое представление программы хранилось отдельно) и соответственно сохранены/распечатаны как картинка. б) Сохранено во внешних источниках (XML, JSON и т.д.) в) Прочитаны из внешних источников. На текущий момент это было не реализовано (но реализация была возможна). Сама идея блоков была рождена с той целью, чтобы можно было в будущем свободно копировать некоторые узлы из блока в блок (сходная идея — снипеты в Visual Studio). Насчет преобразований, то собрать текст из блока намного проще (потому что блок порожден автоматически, обработан и имеет мало ситуаций для обработки, чем текст введенный человеком), чем представить обычную программу в виде дерева. ✅ 2014/06/17 16:49, Автор сайта #4 функции — много параметров / один результат А каков тип этого результата — элементарный или же это может быть, к примеру, структурой или массивом?Как-нибудь надо будет поближе познакомиться в Вашими идеями :) ✅ 2014/06/19 10:10, utkin #5 Язык безтиповый, результат строка. Однако строка может рассматриваться с разных позиций. Были группы встроенных функций, рассматривающих строку как массив, стек и т.д. (требовалось указание разделителя, например, если брать разделителем пробле, то можно работать со словами, если слеш, то можно обрабатывать путь в файловой системе и т.д.) Плюс длинная арифметика (разряды представлялись символьно). Также были операции сохранения/чтения строки в/из файл(а) (без промежуточных операций типа, открыть/закрыть). Ввод/вывод был базовый (по типу JavaScript), крутые навороты планировались через DLL и как веб-интерфейс (по типу настроек модемов/роутеров).✅ 2014/06/19 18:06, Автор сайта #6 Понятно. И эта возвращаемая строка находится, конечно, в «куче», в динамической памяти. И Вы, конечно, считаете, что современная техника пережуёт любую программную неэффективность. В том числе и избыточное использование динамической памяти. А у Вас не было интереса к тому, чтобы строки размещать в стеке? Да-да, в аппаратном стеке, с использованием регистров ESP и EBP? Ведь такая модель использования памяти значительно эффективнее и надёжнее.операции сохранения/чтения строки в/из файл(а) без промежуточных операций типа, открыть/закрыть Вот это интересно. Открывать/закрывать всё равно придётся, только у Вас это делается неявно, спрятано за кадром. Наверное, перед всякой операцией чтения/записи делается неявное открытие, а по окончании — неявное закрытие?✅ 2014/06/20 10:32, utkin #7 Меня интересовала прежде всего проверка моих предположений и сама возможность реализации идей. Вопрос эффективности можно оставить на потом. Я принципиально не против стека. Есть возможность, значит можно запихать в стек, хорошо. Но на тот момент это было не главное.Вот это интересно. Открывать/закрывать всё равно придётся, только у Вас это делается неявно, спрятано за кадром. Наверное, перед всякой операцией чтения/записи делается неявное открытие, а по окончании — неявное закрытие? Естественно. Но идея была абстрагироваться от таких нюансов. Зачем это нужно программисту? Да, при сохранении в двоичном виде, постоянном чтении/записи (как например в базах данных) такая ситуация оправдана. Но здесь были другие принципы. Один из которых — более человеческое взаимодействие с компьютером. Все-таки, нравится/не нравится, но в паскале и си человек должен знать и уметь некоторые вещи, которые на самом деле не нужны для решения практических задач. Например, чтение из файла. Открытие файла в таком случае «лишняя» операция. Она нужна чтобы соблюсти ритуал операционной системы. Но для решения задачи в данной операции нет необходимости. Аналогично и различные типы чисел. Да, word эффективнее, чем byte. А Integer предпочтительней использовать, чем Boolean. Но опять-таки для подавляющего большинства прикладных (именно прикладных) задач, не связанных с самим программированием, эти данные вполне можно укладывать в Integer и напрочь забыть про остальные упомянутые. Страдает эффективность, согласен. Но язык не заточен на создание системных приложений. А в подавляющем большинстве остальных случаев эффективности Integer более чем достаточно.Ведь такая модель использования памяти значительно эффективнее и надёжнее. В плане эффективности, наверно, да. В плане надежности не понял, в чем она заключается?✅ 2015/11/03 15:20, me.lunin(аt)gmail.com #8 Только традиции полувековой и более давности, восходящей к ленте Тьюринга, только слабость технической базы университетов и попытка найти универсальный подход к любой проблеме и консерватизм — только это проблема. И дайте ссылку на проект.✅ 2015/11/03 15:00, Автор сайта #9 Если Вас интересует проект Уткина, то смотрите «энтузиасты-разработчики компиляторов и их проекты», язык Валентина.✅ 2016/07/20 16:18, Abah #10 Можно ли отказаться от текста при программировании? Ха-ха 3 раза!!!За полвека знакомства и практики программирования неоднократно размышлял на эту тему, пока не пришёл к окончательному выводу: текст — самое главное, что есть в программе. Когда исследуешь чужой код, прекрасно видишь "дерево", но без названий операций, за которыми подчас скрыты десятки и сотни команд, зачастую неясна суть действий. Неоднократно сталкивался с ситуацией, когда коллеги, пытаясь скрыть свои "ноу-хау" от своих конкурентов, просто называли (меняя слова в простом текстовом редакторе) функции абстрактными названиями типа f1, f2, f3..., а переменные брались как элементы массива. Интересно, что таким же образом работали (и работают) оборонные предприятия. Без толстенных альбомов (и хранящихся в 1-м отделе), расшифровывающих значения массивов и функций, понять набранную галиматью может только профи в данной конкретной области. И, даже если программа написана вполне понятно (с нормальными именами), новое поколение разработчиков, не напрягая извилины, просто выбрасывает сделанное предшественниками в "корзину". Бывают исключения. Но в этом случае текст программы должен обладать свойствами шедевра. Почти как "Война и мир" или что-то наподобие. Как сказал мне старший коллега: "Программы пишут не только для работы. Их, в основном, пишут для чтения". Программа должна описывать общую идею, концепцию своей работы, постепенно переходя к описанию более мелких элементов и частностей. Броуди в книге "Способ мышления Форт" отмечал, что последовательности слов, использованных программистом, должны полноценно рассказывать о сути выполняемых действий. А "дерево" нужно только для того, чтобы никто ни в чём не разобрался. ✅ 2018/05/25 01:12, Александр Коновалов aka Маздайщик #11 Хороший пример программирования без текста как линейной последовательности знаков — математические пакеты Mathcad и SMath Studio. В них при помощи графического интерфейса вводятся математические формулы и операторы языка программирования (if, for, while).Кладём на страницу while — у конструкции два незаполненных слота: условие и тело. Заполняем и всё работает. К слову, писать программы в них можно не только тыкая мышкой, на большинство конструкций есть горячие клавиши. Модель вычислений декларативная как в Excel. Меняем значение переменной в начале листа и вся страница пересчитывается. Несколько характерных примеров (из онлайн-версии SMath Studio): https://ru.smath.info/cloud/sheet/sSc6ByPoeY https://ru.smath.info/cloud/sheet/v5uguRZyxP https://ru.smath.info/cloud/sheet/LrzrXbGzGw https://ru.smath.info/cloud/sheet/XZ4aMbFZ8x https://ru.smath.info/cloud/sheet/3Zzs5Pkava https://ru.smath.info/cloud/sheet/KDvKK3HPUk В общем, такая технология уже давно существует. ✅ 2018/05/25 23:26, Автор сайта #12 Существует, сомнений нет. Сомнения в том, что нужно ли отказываться от текста? Владислав Джавадов в своём «Канторе» предполагает, что должны существовать взаимно обратимые преобразования из текста во внутреннее представление и наоборот, т. н. «отекстовка». Так что варианты есть.✅ 2018/05/27 16:30, Александр Коновалов aka Маздайщик #13 Документы Mathcad’а сохраняются в XML, так что в некотором смысле это тоже текст:-). Но, понятно, речь не об этом.В принципе, никто не мешает сделать для любого обычного текстового языка программирования среду разработки в духе Mathcad. Например, для Си горячей клавишей вводится оператор while вида while (•) {где знаками • я обозначил места для ввода текста (placeholder’ы). Среда не позволит, допустим, стереть букву i в слове while просто потому, что курсор в это место физически нельзя подставить (а можно только в placeholder). Но сохраняться файл будет в обычный текст на Си.✅ 2018/05/27 23:40, Автор сайта #14 Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос.✅ 2018/05/27 23:41, Александр Коновалов aka Маздайщик #15 git clone https://github.com/%USERNAME%/%PROJECTNAME%cd %PROJECTNAME% git add file.jpg git commit -m "Добавлена картинка" git push mspaint file.jpg git add file.jpg git commit -m "Обновлена картинка" git push Проблема хранения двоичных файлов — команда git diff (или её аналоги в GUI/web-мордах) не может, как правило, показать разницу. Хотя, например, git diff для PDF-ок с текстом или .doc/.docx файлов что-то показать пытается — как-то извлекает текст и показывает на нём отличия. Но как патч это уже использовать нельзя. ✅ 2018/11/18 15:18, Freeman #16 Текст будет служить правдой до тех пор, пока не появится адекватная абстракция двоичных интерфейсов. Например, из предлагаемой теории объектно-ориентированной ОС следует:
Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос. Вопрос будет прорабатываться в теме пакетного менеджера Кантора (http://forum.cantorsys.com/viewtopic.php?id=27) и на одноименной лекции.✅ 2019/08/29 09:07, рст256 #17 Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос. Просто сделать функции перевода из этого внутреннего представления в любой подходящий текстовый формат и обратно. Например в хмл.✅ 2021/03/26 16:56, Виталий Монастырский #18 Без текста мы всё равно никуда не уйдём до тех пор, пока ИИ не научится абсолютно корректно воспринимать человеческую речь. Да и после этого текст никуда не уйдёт — просто спрячется под очередной слой абстракции.Конечно же представление программ в текстовом виде очень плохо воспринимается человеком. Куда более эффективным является графическое представление в виде блок-схем. Но в блок-схемы то всё равно нужно вводить названия элементов, операции и так далее. Так что от текста на 100% не уйти, но вот представление программы нужно менять точно. В этом смысле я полностью согласен с мыслью о том, что для программиста программу лучше всего анализировать и разрабатывать в виде визуальных блок-схем, с заполнением отдельных полей необходимым текстом, а вот для компилятора или интерпретатора её всё равно необходимо представлять в виде текста. Отсюда напрашивается простое решение — создание визуального IDE на подобии "Дракона" (только улучшенной и причесанной версии, ясное дело) для непосредственной разработки, но под капотом которого будет транслятор полученной схемы в исходный код на чисто текстовом ЯП. ✅ 2021/03/27 12:47, Автор сайта #19 Блок-схемы и «Дракон» плохи тем, что у них рыхлое представление программы. Слишком неэкономно расходуется экранное пространство. Лучше, если IDE сама дорисует графику к введённому тексту. То есть не рисуем графический элемент if, а потом вставляем в него текст, а пишем текст, а IDE рисует нам соответствующую графику.Ещё минус блок-схем в том, что они соответствуют императивной парадигме, а с остальными у них похуже. И упор на алгоритмическую стороны оставляет без адекватной поддержки описание данных. ✅ 2021/03/27 21:31, Виталий Монастырский #20 Ну дак на то и руки, чтобы подровнять то, что криво. Я вот тоже там многим не доволен, но в базе концепция хороша. Да и для других парадигм программирования, кроме императивной, всегда можно что-нибудь придумать — не велика проблема. Дело то новое... не изученное... народ хочет разобраться. :)Главное суть подхода — визуальное программировние, при этом не имеется ввиду оконное аля-Дельфи, а именно схемное. Мы же тут с нуля все разрабатываем... так что как напишем текстовую версию языка, не будет проблем и графический вариант разработать. А вот то, о чем Вы говорите, лично мне вообще не понятно. Как говорила одна дам в том анекдоте, "я", говорит, "Ваш квадратный трехчлен даже представить себе не могу, не то, что разложить". :) Если что... https://www.youtube.com/watch?v=PrX2V_11p0A То есть мне вообще не понятно — что там будет подставляться и как рисоваться, пока Вы что-то будете вводить. Ваши статьи на эту тему я уже прочитал, но там как бы... все итак программистом вводится и в общем-то я это же самое имею в обычном текстовом редакторе — он мне рисует отступы и даже вводить ничего не нужно и никаких проблем. Лично я вообще вижу решение проблемы в разграничении мух и котлет... то есть — логики программы, от исполняемых наборов команд. В моем Cup-е это реализуется посредством введения именованных блоков кода и оператора их исполнения. Но даже в этом случае нужна система качественного визуального представления древа логики, которая человекопонятна. А просто выделение отдельных блоков серым цветом или вставка линий контроля за отступами... ну в общем пока я Вашу идею вообще не ухватил за хвост. ✅ 2021/04/01 12:15, Александр Коновалов aka Маздайщик #21 В моем Cup-е это реализуется посредством введения именованных блоков кода и оператора их исполнения. Именованный блок кода — это подпрограмма (процедура, функция, метод…), а оператор её исполнения — вызов подпрограммы (функции, процедуры, метода).✅ 2022/08/19 16:31, void #22 Моё скромное мнение: текст как формат представления программы — устарел. На самом деле, адекватное представление исходного кода программы — это не текст, а гипертекст. Но это не тот гипертекст, который вы знаете (делая джедайские пассы руками).Тезис №1: подход Literate Programming Дональда Кнута, его расширение в виде Literate DevOps (на основе Emacs org-mode babel, например). Был такой подход написания «понятных программ», начиная от документации в порядке «потока сознания» — то есть, в том, в котором удобно думать. А не в том, который своей структурой навязывает определённый язык программирования. Из инструментов, например noweb или funnelweb (или его форк на гитхабе fw-utf8). Здесь в WEB, то есть, Literate Programming: гипертекст это метатекст или паратекст, то есть, набор двух параллельных текстов: потока документации и потока кода (с цитированиями-трансклюзиями других блоков кода в текущем). Literate Devops (Emacs org-mode C-C внутри блоков кода, Jupyter Notebook, например и прочие playbook): по сути кибертекст, то есть: гипертекст, где часть текста «блок кода» может быть выполнена, а результат сразу подставлен в документ. В целом WEB — это метасистема, реализующая метасистемный переход над пространством текстов в пространство гипертекстов (паратекстов, метатекстов, кибертекстов). С методами weave (сборка документации, с индексами и ссылками) и tangle (сборка блоков кода в файлы с исходниками). В том же смысле, в каком обычные autotools, automake — это например, тоже метасистема времени конфигурации (из configure.in -> configure.am -> Makefile.in->Makefile.am->Makefile), на базе макроязыка M4, скриптов и какой-то магии. Здесь мы видим, что на примере Literate Programming: а) существует технология написания «понятных программ» — когда процесс программирования (и прочие, например, управление требованиями) — встроен в процесс документирования. б) программы в «блоках кода» по сути могут быть написаны на любом языке, собраны любым способом. Например, в Emacs org-mode #+BEGIN_SRC ... :var x=y ... #+END_SRC мы видим по сути метаданные, например, «метапеременные», которые могут быть переданы в блоки кода в сборку времени метасистемы. Например, можно написать несколько «параллельных текстов», на разных языках реализации. И реализовать «управление конфигурацией», которое будет выбирать тот или иной вариант реализации на том или ином языке программирования, передавая параметром конфигурацию в метапеременные «блоков кода». в) «блоки кода» в случае Literate DevOps можно частично проинтерпретировать, выполнив вручную (нажав C-c C-c внутри блока кода в Emacs org-mode babel). г) M-x org-mode-babel-tangle — это одна операция метасистемы, tangle в файловое текстовое представление, из гипертекста WEB single source в текстовые файлы с исходниками д) M-x org-mode-publish — это другая операция, weave — в промежуточный формат, например, tex и далее в целевой .pdf,.ps,.html как хорошо откомментированной документации, с индексами, глоссариями, перекрёстными ссылками из одних блоков кода на другие. Тезис №2: структурные редакторы (например, как формат представления документов: skribe, skribilo). Например, разметка skribe (частично её повторяет разметка texinfo, scribe в Racket Scheme, и т.п.). Skribillo — проект на основе Guile Scheme. Здесь мы видим, что разметка документа — это структурное представление (LISP-подобное, на основе S-выражений, с макросами. Но, например, в том же skribillo можно подключить любой reader/writer, например, XML или Markdown, теоретически, тот же DocBook, .docx или .odt тоже возможно). То есть, такой typesetter по сути и есть структурный редактор, на основе макросов поверх лисповых структурных S-выражений. Схема: DSSSL, например. Частично: typesetter SILE на основе Lua (там тоже относительно просто подключить свой xml-подобный формат, вдобавок к tex-подобной разметке). Тезис №2.1: программа — это не текст, а гипертекст (паратекст, кибертекст, метатекст). Не AST, а семантическое дерево. Например, компилятор Евгения Зуева С++ на основе семантического, а не синтаксического, как обычно, например в том же LLVM, представления. Или, компилятор Algol-60 с представлением на основе многоэтажных W-грамматик, грамматик Вейнгаардена. Как известно, они были довольно универсальным формализмом, не уступающим клеточным автоматам или машине Тьюринга (про что он и написал книжку с примерами). И в том числе, позволяли: а) задать семантику, а не только синтаксис. б) подключать многоязычные словари в) потенциально, реализовать синтаксические макросы в духе лисповых. Если говорить про LISP-ы, то, например, такие языки как Dylan, макросы в D-выражениях и его ранний прототип ещё с синтаксисом схемы Thomas. Тезис №3: язык CURL, от стартапа Тима Бернерса-Ли. После прочтения документации и примеров по этому языку складывается следующее предварительное ощущение, что же такое этот Curl. 1) Язык программирования вроде Scheme (Dylan, Thomas), Tcl/tk, REBOL, Red.Компилируемый в нативный код, с макросами схемы. ООП, С++-подобная модель, рефлексия и интроспекция. 2) Язык разметки вроде программируемой wiki, skribe, tex, html. 3) Язык, пригодный для реализации технологии "Literate Programming" 4) Программируемый интерактивный документ как формат данных — одновременно и исходник программы, и документ. 5) Гомоиконный, то есть, такие документы/программы обрабатывают и генерируют себя сами. По сути, как язык программирования — это Scheme с First-Class object, где object = type или environment. То есть, за счёт наследования environment можно сделать sandbox, ограничив ненужное. Каждый объект, модуль, документ — создаёт новое пространство имён. Пространства имён — структурированное представление. Текст программы взаимооднозначно отображается на объекты структурированного представления. Гомоиконная программа и есть сама по себе свой собственный структурный редактор. Объекты этого структурированного представления связаны — то есть, это по сути такой гипертекст. Клетки, связанные внутри Тезис №4: язык Unu, в Retro Forth последних версий на основе Ngaro/ Nga VM. Ретро форт — это функциональный постфорт. Исходники записываются в духе методологии Literate Programming, в разметке Unu наподобие Markdown. Это одновременно и документация, которую можно читать. И код, который можно исполнить. Тезис №5: Оберон, в реализациях BlackBox Component Pascal, Active Oberon в AOS. Здесь видим, что исходники тоже — только часть некоторого compound document, в который могут также быть внедрены вьюшки/виджеты, на самом этом Обероне как компонент написанные. То есть, очередные активные интерактивные документы, программируемая документация. То есть: гипертекст. ИТОГО: привёл достаточно убедительные, на мой взгляд, примеры того, что представление программ только лишь на основе текста == устарело. Да, текстовое представление ещё долго по инерции будет основным. Ту же кодировку Unicode относительно недавно стали поддерживать все основные языки программирования. Что же теперь мешает добавить туда полноценные интерактивные документы с программируемыми компонентами, гипертекст, языки разметки, макросы. Стуктурное или семантическое представление (в качестве основного). Только инерционность самих программистов и используемых ими инструментов (компиляторов, среды) — не более. На мой взгляд. Гипертекст изначальныйТеодор Холм Нельсон — изобретатель, гуманитарий, визионер — когда изобретал эти ваши гипертексты, он вовсе не имел в виду HTML:HTML и современный World Wide Web — это то, чего мы хотели избежать. К тому же, как оно написал в одноимённой статье «XML considered harmful». Причины и подробное обоснование, rationale — см. в этой статье.Почему же «структурированное представление» в формате жёстко навязанной синтаксической структуры, схемы, DTD в духе SGML,GML, XML, HTML следует считать вредным? Да потому, что интересует не синтаксис и WFF (Well Formed Form)-ность этих выражений как AST, а семантика, её корректность, связность, типизированность этих связей. Если прочитать «17 принципов Xanadu», описание протокола FeBe Udanax Gold protocol, рассуждения Теда Нельсона о «Xanalogical Structure, Needed Now More than Ever», ZigZag DataBase zzDB, ZigZag multidimentional hyperstructures, и в ту же тему, «XML considered harmful» — становится ясно, что же он имел в виду под гипертекстом изначальным. Это клетки. Клетки, связанные внутриВозьмём, например, представление Jupyter Notebook в формате JSON, или лучше того, Mathematica / Wolfram Alpha notebooks в виде тензоров — клеток, связанных внутри. Связанных типизированными гиперссылками. Обеспечивающих ссылочную прозрачность моделей данных.На этой первоначально, имманентно :) многомерной гиперструктуре (вроде zigZag DataBase или глобалей MUMPSа) — растут документы и программы, связи и отношения. Например, текст. Изначальный immutable-поток текста. Как функциональные структуры данных. К ним потом накладываются патчи, EDL, Edit Decision List. Ссылки — на оверлеи, блоки текста (в изначальном потоке, который никогда не меняется, просто одной из EDL является "создать новую версию"). Между этими ссылками на эти блоки, типизированными — различные типы ссылок, различные отношения. Отношение трансклюзии — то есть, цитирование содержимого ссылки (уникально структурно адресуемого, см. про purple numbers и адресацию на основе трансфинитных чисел, tumblers). То есть, при изменении текста включаемого документа по ссылке — цитата во включающем документе автоматически изменится. Ссылки на структурные адреса не должны ломаться при небольших изменениях документов. Далее, типизированные процедурные ссылки. Например, выполнить скрипт по ссылке и подставить сюда результат (скрипт на любом языке). Далее, обычные "ссылки перехода" на новый документ (или на какое-то конкретное место, конкретный блок внутри этого документа). Нетрудно заметить, что эти три типа ссылок в какой-то степени изоморфны LISP-овым UNQUOTE, QUOTE, SPLICE. А zzDB и его «гиперструктура» в какой-то мере напоминает conscell LISP-а. То есть, по сути такой гипертекст является средой исполнения лисп-подобных программ. Думается, что на основе того же Curl можно наиболее близко её воссоздать. Это будет среда исполнения гомоиконных программ и документов, literate programming структурный редактор. Сразу по построению. Чем отличаются формат html от форматов pdf и doc? Идеологией построения «составных документов». И кривизной реализации идеологии в силу недопонимания этой изначальной концепции, её идеологии:1) .doc как OLE compound document, на основе COM — а не, к сожалению, более разумных OpenDoc в OS/2 или .odc в BlackBox Component Pascal. По сути, это файловая система в миниатюре, в одном файле. Сложно сказать, то ли «файловые форки» в NTFS, HPFS файловых системах как дополнительные потоки данных» тому виной, то ли FAT32 вдохновлял создателей интерфейса IStorage. Отсюда проблемы, навеянные изначальной реализацией — проблемы с фрагментацией файла/восстанавливаемостью типа chkdsk, открытостью и документируемостью формата. Кто считает .doc достаточно документируемым — перечитайте спецификацию .docx на 15000 страниц, и сравните со спецификацией .odt раз в 10 меньше, или с каким-нибудь DocBook XML. 2) xml,xhtml,html продолжает sgml, gml. То есть, ENTITY, DTD, навязанную синтаксическую (а не семантическую, хотя частично есть DTD) структуру. Здесь рядом где-то должна прикладываться схема, иначе опять получим войну форматов наподобие HTML3.2двух вариантов несовместимых друг с другом. 3) pdf здесь выглядит наиболее любопытно, потому что это по сути — структурированный формат, структурированная база данных. Читаем описание формата PDF: а) есть словари, в которые собираются объекты (структурированное представление), б) индексы в словарях указывают на место в иммутабельном основном потоке, в) словари, индексы связаны ссылками друг на друга, г) контент по возможности бинарный, а не текстовый. скорее, гипертекстовый, д) если распаковать бинарный контент в текстовое представление — мы получим: д.1) команды отрисовки подмножества PostScript, д.2) скрипты на JavaScript для интерактивности и отрисовки форм, д.3) цифровые подписи, д.4) текстовое содержимое, д.5) шрифты, стили, формы. Если сравнить например это с форматом какого-нибудь исполняемого файла, например PE EXE или ELF или, например, AOS Active Oberon исполняемые модули, с метаданными, информацией о типах переменных модуля, то видна некоторая аналогия. Но если объектные или бинарные исполняемые файлы оптимизированы на разделение доступа на уровне mmap-инга отдельных страниц памяти, секций бинарника .text/.bss/.data/…, то здесь смысл этой базы данных, как формата PDF — не требовать для отрисовки страницы интерпретации содержимого всего файла, а только переходить по ссылке в словаре. Можно придумать некоторый универсальный формат представления документов/программ, на основе PDF. Например, хранить в ресурсах PDF файла не только исходники программ (как для встроенного JavaScript), Но и, например, slim binaries или какое-то подобное, откомпилированное бинарное представление. То есть PDF-формат — это по сути база данных структурированного представления. В котором можно хранить в том числе и бинарные данные (секции кода/данных/ресурсов). Получаем индексированное, связанное ссылками и — гипертекстовое структурированное представление. Представление операционных систем в виде Literate-Programming-гипертекстаПара ссылок про документ/программы для ядра и дистрибутива ОС:
Далее, что же мешает их полуавтоматизированно же проиграть и выполнить, как в каком-то Jupyter Notebook, playbook-е или том же CURL документ/программном представлении? В основном, ограничения браузера и формата. (наверное, что-то можно такое с бОльшей интерактивностью и запускаемостью изобразить поверх настроек к Емаксу) Здесь кстати, видна некоторая ригидность, ритуализированность самого процесса сборки. Команды сборки дистрибутива в LFS — это не дерево, это граф с циклическими (!) связями. Например, сначала собирается кросскомпилятор в своей новой конфигурации, triplet x86_64-lfs-gnu, не вполне полноценный. всё это делается из chroot в LiveCD любого другого линукса. Потом в ходе последующих стадий stages перегружаемся в эту новую, свежесобранную систему. И пересобираем ещё раз (или для верности, третий раз — и прогоняем тесты). Если считать, что это в LFS по сути описан-процесс управления конфигурацией,процесс управления сборкой и релизом дистрибутива, то сам этот процесс какой-то странный, с циклическими связями. То есть: вместо отдельных продуктов и компонент мы сначала получаем полуфабрикаты,некоторые из которых потом пересобираются по два раза: один раз в chroot, второй — перезагрузившись — в новой системе. Просто читая оглавление этой книжки, начинается икота. Во-первых, базовые компоненты циклически зависят друг от друга. Ядро от заголовков, glibc, gcc. gcc (и заодно g++) от glibc. и от тулчейна. Во-вторых, для «чистой» среды сборки зачем-то генерируется кросскомпилятор. Чтобы точно уж гарантировать разделение окружения хоста и собираемого гостя, цели. В общем, как-то неаккуратненько это всё. По сравнению с книго-ядром, документ-программой Ulix OS. Циклические связи. Да и сами компоненты какие-то жирные, например glibc состоит из 15 библиотек. Если ещё сюда ещё добавить какой-нибудь сильно связанный systemd — то вообще, занавес. В то же время, существуют «функционально чистые» среды сборки, обеспечивающие воспроизводимость сборок и более прозрачное управление конфигурацией. Такие как: NixOS, Guix, hermes.Nix из NixOS — функциональный пакетный менеджер/язык сборки наподобие Haskell. Рецепты сборки это монады или замыкания, продолжения (derivations) на функциональном языке. Соответственно, чистоту этого environment пытается обеспечить функциональщина. Environments собираются в цепочку nix-store, где работает сборка мусора. Guix из GuixSD — Nix переизобретён на языке Guile (диалект Scheme). G-strings, G-monads, через которые делается всё то же самое. Зато можно не учить Хаскель-подобное и пользоваться макросами лиспа для DSL. Hermes поверх языка Janet — более простой, чем Guix. Есть всего 2 команды: hermes build и hermes cp (в другой hermes по ssh).Дефолтный seed для сборки пытается повторить LFS: собирается чистое окружение с musl-кросскомпилятором, которым собирается всё остальное. DSL для описания ресурсов может использовать, да и вовсю использует макросы LISP-а. Например: defsrc для определения ресурсов, «конфигурационных единиц». И defgnu для дефолтных рецептов сборки типа configure/make/make install. Что такое программа — это текст или гипертекст? Текстовые представления ресурсов (URL пакета, SHA1 подпись, название пакета, файла, версия)? Или это всё-таки уже структурированные объекты? На мой взгляд, скорее второе. Соответственно, язык для описания управления конфигурацией, сборок, рецепты пакетного менеджера — это DSL/программа или гипертекст/кибертекст, то есть «интерактивный исполняемый документ»? На мой взгляд — и то, и другое одновременно. Изоморфно и гомоиконно. Пакетный менеджер — это структурный редактор эдакого гипертекста.< p class=citatа>Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос.Интересный ответ в том, что Git это сама по себе объектно-ориентированная база данных. Git разработан как набор высокоуровневых обёрток к низкоуровневым утилитам. На самом низком уровне, BLOB — это file object. они могут храниться сжатые, запакованные. Индексом здесь является SHA подпись от содержимого, То есть, это — Content-Addressable Memory, CAM. Tree object, commit object, fork — это ещё одни типы объектов. Подпись на спискок индексов file-object-ов. То есть, Git storage, репозиторий — это ООСУБД реализующая CAM с индексами других типов объектов, объектов-контейнеров в индексы хранимых блобов. У BLOB-а по идее, может быть несколько имён, метаданных. Потом, их по идее, тоже можно хранить в какой-то СУБД. Например, в глобалях MUMPS-а, хотя там много чего для этого надо переделывать. В проекте экзоядра MirageOS на Ocaml (где драйвер — это функтор, автомагическипостроенный из DSL-спецификации протокола), есть нечто похожее на Git — Irmin. Там говорится, что можно задать, запрограммировать свой алгоритм разрешения конфликтов для разных типов BLOB-ов. То есть, этот «структурный редактор» можно научить автомагически merge'ить по разным правилам для разных типов объектов хранилища. ✅ 2022/08/19 17:54, Автор сайта #23 void, ещё раз взываю к Вашей совести. Пишите свои отзывы по правилам русского языка. Если Вы не научитесь это делать, то Ваш язык не «взлетит», потому что Вы не сможете грамотно изложить людям свои мысли.Пожалуйста, скопируйте весь Ваш текст в Word, исправьте и пришлите его на почту, чтобы я заменил новым тестом старый. P.S. Потратил полтора часа, чтобы хоть как-то «причесать» комментарий void. ✅ 2022/08/23 13:25, Ильдар #24 Очень многа букафф, товаристч void! Срочно нужна тренировка лаконичности!Текст на каком-либо языке программирования — это своеобразный гипертекст. Существуют взаимосвязи между элементами программы. Например: не объявил переменную, класс или функцию — получи сообщение об ошибке. Значит, между ними существует какая-то взаимосвязь. Именно взаимосвязями ценен гипертекст. Говорить о том, что «гипертекст рулит, а языки программирования — отстой», будет неправильным. Попробуйте сами найти у языков программирования свойства гипертекста. «Грамотное» или «литературное» программирование «не взлетело», хотя известно давно. Значит, есть на то причины. Было бы замечательно найти исследование с условным названием «Недостатки технологий, которые не взлетели». А то преимущества «серебряных пуль» постоянно выпячиваются, а вот недостатки заметаются под ковёр. ✅ 2022/08/30 17:24, void #25 Текст на каком-либо языке программирования — это своеобразный гипертекст. Существуют взаимосвязи между элементами программы. Например: не объявил переменную, класс или функцию — получи сообщение об ошибке. Значит, между ними существует какая-то взаимосвязь. Именно взаимосвязями ценен гипертекст. Говорить о том, что «гипертекст рулит, а языки программирования — отстой», будет неправильным. Попробуйте сами найти у языков программирования свойства гипертекста. Вернёмся к формулировке понимания "обобщённой теории гипертекста". Операционная система — всего лишь очередная программа,ядро := запускалка программ (модулей ядра, то есть, драйверов; или серверных программ, демонов; или клиентских программ, то есть, процессов ядра ОС)Файл — неструктурированный, "одномерный" поток байтов. Его можно рассматривать как одномерный поток байт, байтовую строку. Или с тем же успехом, как многомерный поток байтовых строк. Обычный гипертекст, в бытовом понимании, то есть, например, "структурированный текст" вроде потомков SGML — это сериализованное в одномерный поток представление многомерной структуры данных, гиперструктуры. То есть, сериализованный в одномерность многомерный поток. Композиция моноидов есть моноид высшего порядка. Например, строка — моноид с порождающей структурой. Для чисел (0,+) или (1,*) порождает алгебру чисел. Для строк ('',_) где _ — конкатенация строк порождает алгебру строк.Если мы берём текст как поток слов, разделяемых пробелами, то можно придумать два порождающих моноида: ('',_) для букв внутри слова в слово и (" ",.) для слов внутри предложения в предложения.В модели отображения например LaTeX здесь текст представляется как поток vbox-ов, в которые вложены hbox-ы в которые вложены слова, разделённые клеем (переменного размера). Алгоритм typesetting из TeX-а разбивает слова так, чтобы минимизировать пустое пространство, дополняя выравнивание в клей, разбивая слова переносами. При этом несколько пробелов подряд "склеиваются" в один пробельный клей, есть и другой вид пробелов — неразрывный. Похожая синтаксическая структура присуща и HTML-подобной модели вёрстки. Если брать различные диалекты, то в HTML 4.0/5.0 DIV это vbox, а SPAN это hbox. Правда, выглядит это визуально хуже чем в TeX, потому что нет клея для выравнивания. Что же такое "гипертекст", следуя строго из изначального определения Теда Нельсона (а не его одномерной сериализованной SGML реализации)? Буквально, гипертекст — это текст высшего порядка, то есть, "текст текстов". Например, гиперчисла: гипервещественные, трансфинитные (кардинальные), гиперкомплексные. Это — числа "высшего порядка", многомерные (с немного другими порождающими моноидами). "Текст высшего порядка" — это не одномерный поток байтов, а многомерный. Например, возьмём простой текстовый редактор с синтаксической раскраской. Представление окна, буфера этого редактора — многомерный гипертекст. Мы можем адресовать не как нульмерный скаляр строка FILE := "Line1\nLine2\n\EOF", и даже не как одномерный массив строк TEXT[1]:="Line1",TEXT[2]:="Line2", а как двумерный поток букв TEXT[ROW,COLUMN]:=.... или как трёхмерный поток лексем TEXT[ROW,COLUMN,Z]:=... (поток лексем программы, сериализованного представления). Здесь Z-координата показывается цветом (тип лексемы: число,строка, структура, массив, ключевое слово, комментарий, вызов функции, вычисление выражения, операции и операторы).Теперь появляется понятие "гомоиконности", то есть однородности представления. В гомоиконном языке программирования код это данные, а данные это код. То есть код имеет ровно то же представление, что и данные. То есть программы, генерирующие код (метапрограммы, метаинтерпретаторы, метакомипляторы, макросы Лиспа, компилирующие слова Форта, Ребол-выражения) — писать ничуть не сложнее, чем программы, генерирующие данные. Метациклические реализации гомоиконных языков могут быть весьма компактны. Например, классический Лисп состоит из нескольких (15..20) строк, определяющих метациклически три базовые саморекурсивные функции: eval, apply, evlis. Лисп-1, например, Scheme — это Лисп с единственным пространством имён, где на уровне окружения environment, bindings привязки имён в значения есть по сути в (define x 123) и (define xfunc (lambda(y) (display "hello")) та самая гомоиконность: код это данные, а данные это код.Теперь приходим к понятию типов данных, конструирующих выражений, и first class objects. first class objects — это данные тех типов "первого порядка", которыми могут быть представлены все остальные конструирующие выражения. То есть, в этом смысле классический Паскаль — не функциональный язык (хотя есть процедурные типы), потому что компилятор не понимает композицию лямбд и не может вывести тип конструирующего выражения "функция высшего порядка" как композицию лямбд. Пролог — язык логического программирования, потому что термы, правила вывода термов, императивные предикаты, унифицированые переменные, факты базы знаний assert — это всё first class objects. Метациклический интерпретатор Пролога на Прологе ещё проще, чем Лиспа на Лиспе — потому что неявно WAM-машина, вычисляющая Пролог-выражения, подразумевает обход этой базы знаний, которая пополняет сама себя и метациклически вычисляет вывод новых правил. Язык, в котором first class objects — объекты в объектно-ориентированном программировании, — по-настоящему объектно-ориентированный. В этом смысле Visual Basic 5.0 или 1C v7.7 — объектный, но не объектно-ориентированный (а просто притворяется). Потому что нельзя вводить свои новые классы, новые типы объектов. Язык с метаклассами вроде Смолтока, Лиспа или прототипного ООП показывает, что метакласс, метаобъект (для прототипного) — это и есть замыкание типа, тот самый first-class object. Язык вроде Лиспа, например, Dylan, Goo (диалект Схемы), Curl — по-настоящему объектно-ориентированный, потому что там возможны functional objects. То есть, интерфейс метакласса, метаобъектный протокол — это, по сути, функтор, композиция функций высшего порядка, возвращающее объект, как моноид, объект как замыкание, окружений и привязок. Есть также языки, в которых модуль является first class object. Например, тот же Curl или ещё какой Lisp-3. Здесь, Lisp-1 (например, Scheme) — в единственном пространстве имён все переменные представлены значениями — просто некоторые значения функциональных типов (именованные лямбды). Гигиена макросов представляет через замыкание и syntax-object->datum отобразить локальные переменные макроса, что позволяет делать композицию таких макросов, как синтаксических объектов.После Lisp-1 были варианты Lisp-1.5 (например, MDL / Muddle, InterLisp, и т.п.), в которых макросы были реализованы через динамические Fexpr-ы, а не только лексические Sexpr-ы. В каком-то смысле, и PicoLisp можно считать Lisp-1.5. Для эффективной компиляции макросов отказались от Fexpr-ов в пользу compile-macro и прочих оптимизационных трюков, и пришли например к Lisp-2, например, CommonLisp. Здесь уже два пространства имён: в первом фукнции, во втором — переменные. "Двумерное" пространство имён позволяет написать (foo foo) и однозначно понимать контекст вычислений: что первое foo это функция, а второе — переменная. Просто проще компилировать. Подсистемы, например пакеты или defsystem в CommonLisp, реализованы, впрочем, не совсем модульно. По сути, это похоже на модули в каком-то Lua или Python, где модуль возвращает список переменных, функций, типов, зависимостей, включаемых/включённых модулей в виде простого списка (даже строк, а не символов). Более модульны, например, ISLISP с менее запутанной спецификацией языка и большей ориентацией в сторону "functional objects", либо некоторый условный Lisp-3. Lisp-3 — Лисп с тремя пространствами имён: функций, переменных, и окружений. Environment как first-class object. Например: схема kernel с vau-expressions. Метациклический компилятор kernel ещё проще, чем базового Лиспа, макросы реализованы модульно, модуль — единица first-class environment. Язык программирования/создания гипертекста Curl в этом смысле является диалектом Схемы с first-class environments и functional objects. Различные environments здесь являются рантайм-структурой, представляющей модуль: композиция их способна обеспечить контролируемый sandbox. Например, взяли и заменили символы функций чтения и записи файлов на пустышки. Затем подключили это пространство имён как основное для апплетов. Получили контролируемое окружение, где апплет физически не может читать или писать файлы — потому физически эти функции заменены на пустышки. Если и не пробрасывать функции в окружение вообще (а не заменять пустышками) — модуль, его использующий (т.е., небезопасный) — просто не скомпилируется. Когда в Curl подключается другой модуль, например как {require my-module.curl my-module}, то он подключается в отдельное environments, то есть, способами композиций этих first-class environments можно управлять (изолировать для sandbox-ов или расшарить для реализации ООП, например). ✅ 2022/08/30 17:29, void #26 Здесь мы приходим к фундаментальной разнице между операционной системой, запускающей приложения (например, смотрелку HTML), и операционной средой, запускающей апплеты (приложеньица, документы/программы/компоненты как functional objects). Например, смотрелка HTML с диалектами (вроде CSS, JavaScript) — это по сути навороченный интерпретатор, одномерных текстов (притворяющихся гипертекстами). Отсюда и все тормоза и повышенное потребление памяти. Запускалка апплетов — это компонентная среда, ориентированная на выполнение процессов и запуск компилированных объектов этой среды — компилированных объектов, составных документов, программных компонент. Которые выполняются в сконструированном окружении.Гипертекст становится многомерным, программно конструируемым как first-class objects, first class-environments, functional objects. Например, помимо одномерного представления как поток байт, одномерного массива строк или двумерного массива буфера окна текстового редактора, или трёхмерного расцвеченного массива — можно представить его и в виде четерёх, пяти- и более многомерного. Например: текст как поток символов, или привязок в окружении. В четвертом измерении сидят функциональные объекты (в третьем — контекст, окружение). При этом все эти представления, измерения — полностью равноправны. Потому что документ или текст программы представлен гомоиконным языком программирования: текст это код, код это данные, данные это текст, композиция текстов это функция высшего порядка над кодом/данными/текстом. То есть, многомерный гипертекст. Например, тот же Curl позволяет однородно представлять как текст документа, так и код, его обрабатывающий, так и динамические вычисленные значения (которые могут быть типа GraphicObject, то есть, иметь визуальное представление). При этом можно доопределять собственные теги, как макросы. Плюс, поддерживается ООП и рефлексивность. Далее логично развивать это в некоторую интерактивную операционную среду, работающую с языковыми моделями, например, моделями данных. Которые (как и сами данные, и исходники программ, их обрабатывающие) — могут храниться например в базе данных, а не в файлах, или доставаться по сети. То есть, этот многомерный гипертекст по сути работает с универсальными моделями (данных, программ, документов) — как first-class objects, first-class environments, functional objects. В тему "масштабируемой архитектуры программ". «Грамотное» или «литературное» программирование «не взлетело», хотя известно давно. Значит, есть на то причины. Было бы замечательно найти исследование с условным названием «Недостатки технологий, которые не взлетели». А то преимущества «серебряных пуль» постоянно выпячиваются, а вот недостатки заметаются под ковёр. По реализациям гипертекстовых сред авторинга я видел такое исследование примерно 1985 года выпуска, там сравнивалось примерно 15 таких гипертекстовых, гипермедийных, мультимедийных сред. Эти среды позволяли не только пассивно смотреть браузером-смотрелкою на сериализованное интерпретируемое представление и умиляться котикам, но и например активно работать с гипертекстом и гипермедией: изменять, публиковать, структурировать, расставлять ссылки и отношения, выводить новые зависимости. То есть, ещё тогда гипертекст понимался как способ организации своей операционной среды, своим собственным удобным именно вам способом, со своими структурами данных (гиперструктурами) и отношениями.Среды для усиления интеллекта (Augmented Intelligence), авторинга. Ранние хелпы примерно середины 90х годов — тоже подразумевали более интерактивную работу с гипертекстом. Уже потом самая примитивная реализация в виде сериализованного HTML и сопутствующих недоязычков вытеснила всё остальное (читайте «XML embedded markup considered harmful», ZigZag DataBase zzDB из проекта Xanadu, вот это вот всё). Из причин непопулярности в массах Literate Programming: Сам Дональд Кнут пишет, что прежде всего — нужно уметь писать, объяснять, подавать материал, структурировать изложение. А не только лишь сразу бросаться в бой и писать собственно код. Основная причина — в спешке, лени массовых программистов и массовой популярности технологии программирования под названием "IDE-friendly тяп-ляп и в продакшн". Просто программировать литературно, как и грамотно и понятно излагать и структурировать содержание — могут не только лишь все. Мало кто по настоящему умеет это делать. ✅ 2022/09/03 13:30, Ильдар #27 строка — моноид с порождающей структурой Хоть гипертекст, хоть супер-пупер-гипер-пипер-текст, — если, извините за выражение, пипл не схавает, имея, как правило, высшее образование, то это точно не взлетит. К примеру, всем понятно, что физика Эйнштейна и геометрия Лобачевского правильнее, чем физика Ньютона и геометрия Евклида. Но последними пользуются даже в рамках подавляющего большинства прикладных наук. В сопромате, геодезии, радиотехнике и т. д. В учебниках по сопромату Вы не найдёте Лобачевского и Эйнштейна. В Автокаде в 21 веке используется не геометрия 19 века (Лобачевского), а 3 века до нашей эры (Эвклида). Потому что «проще», не так «заумно», а погрешности в пределах ничтожного. читайте «XML embedded markup considered harmful» А зачем? Вы не сумели меня заинтересовать одним лишь названием. Если бы объяснили на двух пальцах интересно и доходчиво, то могли бы зажечь интерес. Который побудил бы погуглить. А так и без чтения я бы мог сходу назвать Вам как минимум пару существенных недостатков. Мне этого достаточно, чтобы интерес к гипертексту вообще и XML в частности был около плинтуса.environment как first-class object. Ну-ну. Приведите пример (в коде!), где бы функция возвращала своё окружение. Например, чтобы Ваша программа увидела в окружении простаивающее ядро процессора из загрузила бы его. Или перед выделением памяти узнала бы, а сколько вообще имеется свободной оперативки, да размеры крупных фрагментов памяти.видел такое исследование примерно 1985 года выпуска И что там было сказано о причинах, почему «не взлетело»?Эти среды позволяли не только пассивно смотреть браузером-смотрелкою на сериализованное интерпретируемое представление и умиляться котикам, но и например активно работать с гипертекстом и гипермедией: изменять, публиковать, структурировать, расставлять ссылки и отношения, выводить новые зависимости Ну и что? Кому-то это понадобилось?Сам Дональд Кнут пишет, что прежде всего — нужно уметь писать, объяснять, подавать материал, структурировать изложение. Ну и с каким успехом у Вас получается «уметь писать, объяснять, подавать материал, структурировать изложение»? Судя по написанному, Вы даже не приступали к этому. Пытаетесь что-то объяснять через моноиды. Через экзистенциальные типы не пробовали?Просто программировать литературно, как и грамотно и понятно излагать и структурировать содержание — могут не только лишь все. Мало кто по-настоящему умеет это делать. Цитирование Кличко не приближает лично Вас к умению «писать, объяснять». Учитывайте, что у многих людей полушария мозга развиты неравномерно. Есть пишущие гениальный код, но мычащие и не связывающие двух слов в речь. «Литературное» программирование не для них.✅ 2022/09/04 00:34, Автор сайта #28 Метациклический интерпретатор Пролога на Прологе ещё проще, чем Лиспа на Лиспе — потому что неявно WAM-машина вычисляющая Пролог-выражения подразумевает обход этой базы знаний, которая пополняет сама себя, и метациклически вычислят вывод новых правил. Погуглите, почему разрекламированное японское чудо — ЭВМ 5-го поколения — провалилось. Одна из причин — ставка на Пролог. Анализировать причины чужих неудач бывает поучительно. Но не для всех: всё равно кто-то продолжит говорить о величии идей, не написав конкурентоспособных программ.Рекламировать здесь, на этом сайте, хоть Лисп, хоть Пролог бесполезно. Философия грядущего языка предполагает эффективную реализацию, конкурентную по эффективности с Си. Вот если операционка, на которой Вы работаете, и браузер, в котором Вы пишите комментарии, будут написаны на Лиспе или Прологе, то это будет означать, что появились процессоры способные переварить эти неэффективные (с точки зрения процессора) языки. Вот тогда можно будет подумать о многомерном гипертексте. Но не раньше. Вот где есть место различным представлениям, в том числе во многомерных коллекциях, так это в промежуточном представлении. Хотя там не текст, а данные в двоичном виде. Но, в принципе, можно все символы с кодами от 0 до 255 считать принадлежащими некому алфавиту, тогда и промежуточное представление можно считать и текстом, и гипертекстом. Рекомендую Вам завести сайт или блог, так легче будет найти единомышленников. Заодно и заботы о «причёсывании» текста возьмёте на себя. ✅ 2022/09/04 15:53, Gudleifr #29 Погуглите, почему разрекламированное японское чудо — ЭВМ 5-го поколения — провалилось. Пролог здесь ни при чем. Совсем. Просто кибернетика была в конце 70-х запрещена. И у нас, и у них. Японцы попытались этот запрет обойти, но им объяснили, что это не нужно.✅ 2022/09/04 17:48, Автор сайта #30 кибернетика была в конце 70-х запрещена. И у нас, и у них. У нас:Факультет вычислительной математики и кибернетики МГУ, год основания — 1970 Источник — Википедия. Факультет, содержащий в своём названии «кибернетика», был открыт в 1970 г. и больше не закрывался, в том числе в конце 1970-х. Лидия Васильевна Городняя, оставлявшая комментарии на этом сайте, в конце 1960-х защищала дипломную работу, дипломным руководителем был академик Ершов. Это первое, что пришло в голову.У них: Компьютерные системы пятого поколения (FGCS) были 10-летней инициативой, начатой в 1982 году Министерством международной торговли и промышленности Японии (MITI) для создания компьютеров с использованием массовых параллельных вычислений и логического программирования Источник — английская Википедия. Как Вы видите, речь идёт не о конце 1970-х.Японцы попытались этот запрет обойти, но им объяснили, что это не нужно. Информация, похоже, почерпнута у сторонников теорий заговоров.Пролог здесь ни при чем. В программах на языке логического программирования Пролог данными программы являются некие факты. Решение задачи получают, перебирая факты. Линейное увеличение числа фактов ведёт к геометрическому росту просчитываемых комбинаций. Возникает комбинаторный взрыв, который «железо» не может преодолеть в разумные сроки. Комбинаторный взрыв можно преодолеть с помощью эвристики, отсекая ненужные комбинации. А эвристику тогда мог обеспечить только человек. Да и сейчас нейросети в своём интеллекте недалеко ушли от насекомых.✅ 2022/09/04 18:21, Gudleifr #31 Информация, похоже, почерпнута у сторонников теорий заговоров Погуглите "Чилийский эксперимент" или посмотрите библиографию Амосова...Линейное увеличение числа фактов ведёт к геометрическому росту просчитываемых комбинаций. Возникает комбинаторный взрыв, который «железо» не может преодолеть в разумные сроки Точно так же, как и процедурное программирование путем комбинирования фактов в структурах данных.Да и сейчас нейросети в своём интеллекте недалеко ушли от насекомых Скачайте же, наконец, с моего форума сборник "Автоматы" 56-го года.✅ 2022/09/05 12:48, MihalNik #32 В программах на языке логического программирования Пролог данными программы являются некие факты. Решение задачи получают, перебирая факты. Линейное увеличение числа фактов ведёт к геометрическому росту просчитываемых комбинаций. У Вас проблемы проблемы с терминологией. Ох уж эта желтая пресса полувековой давности! Программирование на Прологе вполне соответствуют императивному программированию с логикой обработки исключений. Но на списках работает медленно.Каждый факт — это что-то обобщенное между ветки условного оператора/ветвления или специализации шаблонной функции в С++. ✅ 2022/09/07 21:38, Автор сайта #33 Ох уж эта желтая пресса полувековой давности! Гм… В СССР, за исключением 3-4 последних лет, не было жёлтой прессы. 50 лет назад её точно не было. Не считать же жёлтой прессой журналы «Наука и жизнь», «Знание — сила» или «Квант».Программирование на Прологе вполне соответствуют императивному программированию Просто поставленные задачи (прикладной искусственный интеллект) не решались императивным программированием, ибо «не по зубам». Хотя бы в силу отсутствия тогда хороших средств распараллеливания. Комбинаторный взрыв легко увидеть на примере шахматной программы: если не отсекать заведомо «глупые» (или просто невысокого качества) ходы, то программа захлёбывалась в вычислениях. А ведь задачи, которые поставили перед собой японцы, были не менее сложными: распознавание речи и образов, обработка знаний и т. п.✅ 2022/09/08 12:16, Gudleifr #34 Просто поставленные задачи (прикладной искусственный интеллект) не решались императивным программированием То что Вы не знаете, что это были за задачи, и как они решались, не значит что они не решались.Хотя бы в силу отсутствия тогда хороших средств распараллеливания При чем тут императивное программирование?задачи, которые поставили перед собой японцы Японцы не ставили никаких задач. Они просто подытожили то, что успели придумать до отмены кибернетики.✅ 2022/09/08 15:42, Автор сайта #35 То что Вы не знаете, что это были за задачи, и как они решались, не значит что они не решались. Да нет, знаю что за задачи. Одной из задач была задача распознавания речи. Японская письменность, как известно, состоит из иероглифов, но их так много, что на клавиатуре не хватает клавиш. Они хотели диктовать текст компьютеру. Но программу с нужным качеством распознавания речи они в рамках того проекта сделать так и не смогли. Второй задачей было распознавание написанных от руки иероглифов. Она тоже провалена.При чем тут императивное программирование? При том, что императивное программирование — это программирование шаг за шагом, то есть последовательное. А параллельное — это одновременное.Японцы не ставили никаких задач. Они просто подытожили то, что успели придумать до отмены кибернетики. Цитирую Википедию:За десять лет на разработки было истрачено более 50 млрд ¥, и программа завершилась, не достигнув цели. То есть капиталисты могут потратить такие деньги безо всяких задач? Вы в это верите? А ведь пишут про цель — она всё-таки была?А кто отменил кибернетику? Масоны? Или авторы «Протоколов сионских мудрецов»? ✅ 2022/09/08 15:59, Gudleifr #36 Да нет, знаю что за задачи. Одной из задач была задача распознавания речи. Японская письменность И что? Есть пруфы о неприменимости для этих задач методов обычного программирования? Железо не тянуло.При том, что императивное программирование — это программирование шаг за шагом Это способ упорядочивания операторов, а не программирования.То есть капиталисты могут потратить такие деньги безо всяких задач? Поэтому и прикрыли.А кто отменил кибернетику? Обычные чиновники. Как показали тогдашние эксперименты, хорошая машина вполне заменяет среднего управленца.✅ 2022/09/08 22:10, Автор сайта #37 Железо не тянуло. Всё не тянуло. И железо, и ПО, и научная основа и того, и другого.Есть пруфы о неприменимости для этих задач методов обычного программирования? Всё в сети. Ищите да обрящете. Модель машинного зрения лучше ложится на параллельную основу. Подобно тому, как глаз видит картинку сразу целиком, а не по отдельным пикселям. Конечно, последовательное выполнение вполне себе моделирует параллельное, но ценой временных затрат.Это способ упорядочивания операторов, а не программирования Императивное программирование — это последовательное, в определённом порядке, шаг за шагом, выполнение операторов. Точка с запятой, которая является концом оператора в большинстве языков программирования, играет роль оператора «затем». Благодаря оператору «затем» соседние операторы выполняются в порядке их расположения. А вот в Хаскелле соседние операторы по умолчанию не выполняются в порядке их расположения. Чтобы принудить к этому, есть оператор «затем», который имеет сигнатуру «>>».Поэтому и прикрыли. Потратили тучу денег, а потом обнаружили, что нет задач? Не смешите. Без бизнес-плана (или чего-то похожего) денег не дали бы. То есть утром бизнес-план, вечером — деньги.Обычные чиновники. Так они не отменили кибернетику. Они лишь превратили финансирование конкретного проекта в связи с невыполнением поставленных задач и целей. Где тут отмена кибернетики? Так же попытки выращивания хлопка на Северном Кавказе или кукурузы в Заполярье не отменили сельское хозяйство в СССР.Дискуссия, заходит в тупик и очень далеко ушла от первоначальной темы «Устарел ли текст как форма представления программы». Логично её завершить, поскольку новых аргументов «за» и «против» по теме статьи давно нет. ✅ 2022/09/08 22:49, Gudleifr #38 Всё не тянуло. И железо, и ПО, и научная основа и того, и другого. Только железо.Всё в сети. Ищите да обрящете Т.е. нет.Модель машинного зрения лучше ложится на параллельную основу Как говаривал Минский, это "наивное" понимание.Подобно тому, как глаз видит картинку сразу целиком, а не по отдельным пикселям Опаньки!Императивное программирование — это последовательное, в определённом порядке, шаг за шагом, выполнение операторов Не выполнение, а написание. Что мешает к seq, if и do добавить par? (Ср. ОККАМ)Потратили тучу денег, а потом обнаружили, что нет задач? Да. Не нашлось спроса на вещи, которые были "признаны опасными и ненужными".Они лишь превратили финансирование Особенно в Чили.Логично её завершить, поскольку новых аргументов «за» и «против» по теме статьи давно нет Да. Просто запомните, что кибернетику прикрыли в 70-е. У меня на форуме вы можете уточнить, что когда и как было разработано.✅ 2022/09/08 23:37, MihalNik #39 В СССР, за исключением 3-4 последних лет, не было жёлтой прессы Пресса всегда и везде была со всеми вот этими великими "вот-вот прорывами" и "полными провалами". В реальности же результаты обычно намного прагматичнее: сроки и бюджеты сильно увеличиваются. По сути практические поставленные ими задачи уже решены: тексты голосом набирать можно, распознавать иероглифы вообще просто, автоматические переводчики худо-бедо работают.Также, заметим, по сути решены и задачи той "советской программы автоматизации экономики": электронные заказы, платежи и целые рынки. ✅ 2022/09/09 00:31, Gudleifr #40 Также, заметим, по сути решены и задачи той "советской программы автоматизации экономики": электронные заказы, платежи и целые рынки Мимо.✅ 2022/09/09 09:14, MihalNik #41 Мимо. Просто надо отделять математическую функциональность от политической интерпретации. В капиталистической системе аналог как раз сейчас мы уже имеем.✅ 2022/09/09 10:13, Gudleifr #42 математическую функиональность от политической интерпретации Опять мимо.✅ 2022/09/09 11:57, MihalNik #43 опять мимо Люблю эту песню: "..мимо этого дома идут поезда и жизнь проходит мимо..."новых аргументов «за» и «против» по теме статьи давно нет. Прошу прощения за оффтоп. Как форма текст, конечно же, с научной точки зрения во многом устарел, вот только реальные сроки и сферы сокращения его применения опираются на более прагматичные факторы. Поэтому внутренее представление программ в современных средах разработки как у JetBrains уже нетекстовое, а на выходе и для чтения и для хранения пока ещё текст. По сути текст сейчас тянет экосистема вокруг Git-а. Но для хранения он неэффективен. Вот если JetBrains предложат из коробки более экономичную (шуструю и компактную) нетекстовую альтернативу для хранения и контроля версий — она вполне может взлететь. Чтобы внедрить новый формат — нужен инструмент влияния.мол, синтаксис — гадость и излишество, давайте его выкинем и перейдем на древовидное представление программ (а заодно и обобщим все на свете Наоборот, древовидное представление — это путь к свободному выбору синтаксиса как выбор и настройка шрифта у текста.✅ 2022/09/09 12:39, Gudleifr #44 Тема выглядит так: Текста стало не хватать! Так давайте наложим на него дополнительные ограничения! Ведь, "гипер" и "деревья" — это упрощенный текст.✅ 2022/09/09 13:41, Автор сайта #45 Только железо. Википедия с Вами не согласна:ошибочный выбор языков типа Лисп и Пролог для создания базы знаний и манипулирования данными. Т.е. нет. Они есть. Но, в основном, в статьях и книгах доинтернетовской эпохи. Искать что-то специально для Вас не буду — я переживу, если Вы останетесь при своём мнении.Что ещё обращает на себя внимание — этот проект подавался с большой помпой, а вышел такой большой пшик, что даже не осталось заметных материальных следов. Не знаю ни одного примера ПО или «железа», которые родились в результате этого проекта и живы до сих пор. А всё потому, что задумывалось это, как революция. А вот от эволюции наследство осталось. До сих пор используется куча старинных библиотек для Фортрана. Или YACC-у уже полсотни лет и он до сих пор жив. Архитектура IBM/360 до сих пор развивается в наследниках. Просто запомните, что кибернетику прикрыли в 70-е. Опять теория заговоров. Не буду Вам мешать, ищите истину там.MihalNik По сути практические поставленные ими задачи уже решены Да, решены. Но современниками и современными технологиями. А тот японский проект не оставил видимого наследства. Ну может где-то в каких-то диссертациях. Но никто не скажет, что «Алиса» или «FineReader» имеют какого-то японского родителя.Прошу прощения за оффтоп. Как форма текст, конечно же, с научной точки зрения во многом устарел Это, как раз-таки, не оффтоп, а точно по теме :)Текст устарел, но он является привычным, универсальным и надёжным средством представления. Владислав Джавадов в своём проекте собирался хранить программу в неком промежуточном представлении. Но из него могла производится отекстовка исходника. И эти преобразования должны были стать взаимообратимыми. Вполне разумный компромисс между текстовым и нетекстовым представлением. ✅ 2022/09/09 14:10, Gudleifr #46 Википедия с Вами не согласна: ошибочный выбор языков типа Лисп и Пролог А при чем тут распознавание иероглифов?Они есть. Но, в основном, в статьях и книгах доинтернетовской эпохи Об этом я и говорю.не осталось заметных материальных следов А их и не могло остаться, т.к. он заключался только в повторении сделанного до него. Впрочем, известные 10- и 11-томники дают вполне приемлемое перечисление идей и методов, годных к применению и сейчас.YACC ... был революцией. Точнее, идея синтаксической компиляции.Не буду Вам мешать, ищите истину там Как может мне помешать Ваше незнание? (MACE WINDU: No. He will not be trained... He is too old. There is already too much anger in him).Да, решены И после этого Вы мне будете говорить о том, что ничего "не закрывали"? "Вы хотели в космос? Вот вам новый совочек и ведерко!"Текст устарел Устарел не текст, а "программисты", пытающиеся изобрести язык, способный описать то, что они сами не понимают.✅ 2022/09/09 19:34, MihalNik #47 Википедия с Вами не согласна: В те времена многие частные корпорации начали и продолжают по сей день успешно использовать логическое и функциональное программирование — Erlang, Visual Prolog. Ну даже при кривой реализации не может замедление всего в несколько раз принципиально так менять класс решаемых задач. Что ещё обращает на себя внимание — этот проект подавался с большой помпой, а вышел такой большой пшик. В Японии или в советской прессе? А то у нас тоже "с большой помпой" подаются всякие программы цифровых прорывов — по факту, как заметил Utkin, "я таких документов тоже могу выдавать по одной штуке в неделю".Очевидно что бюджет в полмиллиарда баксов просто ничтожен для железа под соответствующие задачи. Сегодня тратят на железо него десятки миллирдов в год. Вот Вы знаете, на что конкретно те деньги потратили японцы? Бюджеты такая штука: можно взять и напечтать 15 млн. штук книжек о Прологе по 1000 руб. каждая — вот уже полмиллиарда долларов, считайте и нет) ✅ 2022/09/12 23:45, Автор сайта #48 Замена Пролога ничего бы не дала. Ничтожно обвинять простой язык — это как если бы форму Бекуса-Наура или теорему Пифагора обвинили в каких-то экономических провалах. Но в данном случае это очень удобно — списать провал на черт знает что. Единственная проблема, которую мог создать этот язык — отсутствие качественной литературы. А могли бы японцы заменить Лисп и Пролог на Фортран? Он отлично работал на «железе» того времени. И литература была качественная. Просто этот инструмент сразу бы объявили неподходящим, неадекватным, не соответствующим сложности задач.А вот если Лисп с Прологом, то это не языки виноваты, а «железо» не тянет. Во-первых, любая система — это компромисс между возможностями железа и потребностями ПО. Эти языки никогда не отличались эффективной работой с «железом». В этом виноваты именно языки, а не «железо». Во-вторых, тройка языков Лисп, Пролог, Форт позиционировалась как инструменты для создания ИИ. Это создавало вокруг них ореол исключительности и ограждало от критики. И появление пятен на Солнце (провал компьютерного чуда в Японии) весьма удобно списать на «железо». даже при кривой реализации не может замедление всего в несколько раз принципиально так менять класс решаемых задач. Вот именно. Если «железо» не тянуло, а программы на Лиспе и Прологе были ого-го! — то где это чудо, которое распознаёт речь пусть не за секунды, а за месяц? Пусть медленно, но распознаёт. Да оно в принципе не решает задачу, сколько не дай ему ресурсов! Например, на современных эмуляторах «железа» тех дней. Значит, всё-таки есть пятна на Солнце.бюджет в полмиллиарда баксов просто ничтожен Инфляция, сэр. В те времена за эти деньги много чего давали, а теперь — только по морде. Тогда это было порядка 15-20% от расходов на программу «Аполлон».можно взять и напечатать 15 млн. штук книжек о Прологе В расчёте на каждого 6-7 японца?✅ 2022/09/13 00:03, Gudleifr #49 А могли бы японцы заменить Лисп и Пролог на Фортран? В 80-х годах?Во-вторых, тройка языков Лисп, Пролог, Форт позиционировалась как инструменты для создания ИИ Форт никогда и никем не позиционировался как язык ИИ.то где это чудо, которое распознаёт речь пусть не за секунды, а за месяц А при чем тут Лисп и Пролог? Вообще.можно взять и напечатать 15 млн. штук книжек о Прологе Специально посмотрел. В серии МО пара есть.Вы роете куда-то не туда. Проблема не-Си-подобных языков не в том, что они не годились для сложных задач, а в том, что задачи перестали ставиться. ✅ 2022/09/13 15:25, MihalNik #50 «железо» не тянет. У алгоритмов есть вычислительная сложность (которую Пролог и Лисп не меняют) и необходимый объем данных. Просто сравните эволюцию мощностей суперЭВМ и персоналок:https://ru.wikipedia.org/wiki/FLOPS к 1983-му суперЭВМ вышли на гигафлопсовые мощности. Только через 10 лет преодолели 100 Гфлопс: https://ru.wikipedia.org/wiki/Numerical_Wind_Tunnel Персоналки такие пошли где-то с 2011. А могли бы японцы заменить Лисп и Пролог на Фортран? Он отлично работал на «железе» того времени. И литература была качественная. Не могли. Потому что такие программы не имеют в принципе экономического смысла:где это чудо, которое распознаёт речь пусть не за секунды, а за месяц? Пусть медленно, но распознаёт. А для научного слишком дорого при нестабильности результов — по сути нужно было бы сотни-тысячи суперЭВМ тех времен, а не одна.Да оно в принципе не решает задачу, сколько не дай ему ресурсов! Вот именно, где эти программы на Лиспе и Прологе, на которые распилено полмиллиарда? Никто, очевидно их не написал. По той простой причине, что, во-первых, их не на чем было бы в принципе запускать, а во-вторых:В расчёте на каждого 6-7 японца? Ну а как Вы себе представляете "цифровой рывок"? 3,5 специалиста напишут 100500 программ?По сути нужно тоже, что делается и сейчас: обучать каждого студента программированию и дообучать готовых специалистов. А лучше со школьной скамьи. Вы сильно недооцениваете необходимые траты для написания соответствующего ПО. Поэтому даже переводчики на логических правилах были довольно кривые — и сегодня для обучениях нейросетей приходится тратить большие средства просто на подготовку данных. Тогда это было порядка 15-20% от расходов на программу «Аполлон». Сравнение странное. Сравните, например, с Минитель.✅ 2022/09/13 15:36, MihalNik #51 Проблема не-Си-подобных языков не в том, что они не годились для сложных задач, а в том, что задачи перестали ставиться. Кем и кому? Сегодня любому по сути доступны и мощности на 2-3 порядка больше, чем супеЭВМ тех времен и необходимые данные.✅ 2022/09/13 15:47, Gudleifr #52 Кем и кому [перестали ставится задачи ИИ]? Обществом — системным программистам.✅ 2022/09/13 15:56, MihalNik #53 системным программистам. А это прикладные задачи и сегодня на бытовом железе и даже тормозных ЯП решаемы, поэтому системные программисты тут уже не требуются, когда у каждого в кармане смартфон.✅ 2022/09/13 16:07, Gudleifr #54 у каждого в кармане смартфон Решаются всего три задачи:1) программа, написанная лет 40 назад, должна продолжать работать; 2) она должна стать дороже; 3) время показа рекламы должно быть увеличено. ✅ 2022/09/15 14:14, Бурановский дедушка #55 Prolog особенно привлек меня своей декларативностью — описываешь правила предметной области, а дальше все идет как бы само. ✅ 2022/09/15 14:44, Gudleifr #56 О причинах заката Этих "закатов" было, по крайней мере, три.В 30-х, когда оказалось, что электрически — на одних реле — машину не построишь, нужна электроника. В 60-х, когда оказалось, что мы должны отказаться от всезнания в управлении. В 70-х, когда поняли, что для дальнейшего прогресса надо менять общественное устройство. (Помните, у Лема Смех Тьюринга в Магеллановом Облаке?) Проблема логического программирования проста и незамысловата. Есть прямая цепочка рассуждений — получение новых фактов из старых (индукция). Есть обратная — проверка кандидатов в факты путем поиска фактов их подтверждающих (дедукция). В языках программирования первое реализуется структурами данных, где можно накапливать факты. Второе — механизмом функций, позволяющим свести сложные вычисления к набору простых. Программист может выбирать, что он считает заранее, а что только по надобности. Функциональные и логические языки заставляют нас сдвинуть "точку выбора" туда, куда удобно им, а не нам. Написать автору можно на электронную почту |
Продолжение цикла и выход из него