Обсуждение

А Инвел входит в вашу Инкозе? :) Видел это слово на их презентации. :)

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

Интересно, сейчас посмотрю вводное видео. Пока два вопроса по языковой базе: 1) В чём именно заслуги Factor? Из ценного можно отметить dynamic scope и нативную стековость (что, впрочем, тоже простой point-free вариант dynamic scope). Но всё это (вплоть до специфичной для Factor'а культуры написания) уже легко реализуемо на Python, Lua, Ruby и многих других языках. Однако, не тащит за собой ограничения стековых. 2) Python-based отображение - кто им занимается?

Фактор -- это функциональный язык без лямбды, но это не единственное его достоинство. Он представляет весьма специфичный способ создания на его основе разных синтаксисов ("сам себе парсер"), это высокорефлексивный язык-для-разработки-языков. Он настолько языкоориентирован, что состоит из "слов" :) Ну, и там встроенная в язык IDE, как в Smalltalk. Мне point-free с явным обозначением того, где именно находится обрабатываемый объект (на стеке, конечно!) очень нравится. Это соответствует тому, как люди описывают свою деятельность. В кулинарных рецептах пишут "возьмите X, посолите, поперчите, пожарьте, отбейте, нарежьте" и нигде явно не пишут, с каким предметом работается: ежели уж взял предмет в руки, так все операции с ним и идут. Это соответствует гипотезе, что "все мыслительные операции мы делаем визуально с объектами-внутри-головы, беря их мысленными руками". Мне почему-то Factor представляется очень "психологичным" языком, хотя этот психологизм идет полностью контринтуитивно по отношению к людям, воспитанным в традициях C++. Но и BASIC когда-то полностью сбивал мушку программистам, и они не могли долго воспринять "красоты C++" -- почему же сам C++ не может сбивать мушку для восприятия красоты Factor? Тут нужно еще особо указать, что в Factor я отдельно рассматриваю его ядро и отдельно -- развивающие это ядро "стандартные словари" (аналог "библиотек"). C Python и теорией категорий работает algebraic_brain.

Спасибо. :) Многие классические API построены на этом принципе. Например, OpenGL. Для этого в языках без dynamic scope использовались глобальные состояния (а позднее состояния уровня треда). Но вместе с C++ и Java пришли другие принципы дизайна (разбивка и явное упоминание объектов) и мушка сбилась. Хотя каскадные сообщения в стареньком Smalltalk это в чистом виде ваш пример с рецептом. Сейчас ситуация снова меняется. Из особо вкусных "рецептов" (с открытием и закрытием контекстов) можно привести jQuery. А ведь это уже мэйнстрим, самая популярная JavaScript библиотека. Хорошая иллюстрация с примерами: http://github.com/raganwald/homoiconic/blob/master/2010/03/significant_whitespace.md

Вы еще http://haml-lang.com/ поглядите, там тоже шаг в ту сторону. Я от XML/HTML до сих пор в полном офигении, насколько это неуклюже... К счастью, не прошо и двадцати лет с момента языкового взрыва, закончившегося в годы победы сначала Паскаля, а затем Джавы. Сейчас опять начинают расцветать сто цветов, что меня чрезвычайно радует. Это тренд буквально последних трех-четырех лет, до этого все как-то очень гнило было, жизнь цвела только в маргинальных проектах...

Уже знаком. :) Такие решения теперь часто встраивают в веб-фреймворки на динамических языках, как embedded DSL. Раньше было в лиспах и Seaside на Smalltalk, а сейчас пошло в народ. Я пару лет назад делал такой DSL в Python, но так и не пригодилось, работа ушла в сторону визуализации W3C стандартов. Кстати, когда с этим работал - нашлись и ответы про причины нечитабельности XML/HTML. Håkon Wium Lie в докторской диссертации подробно описывает историю языков для структурирования и оформления текста. Там видно, что работы по W3C стандартам велись в очень антиязыковой среде, и CSS один из немногих случаев, когда доводы "я хочу использовать готовый парсер SGML" не перевесили. Сейчас проще с коммьюнити. Люди лучше понимают, что затраты на освоение нового языка близки к затратам на освоение нового API. И почти не заметны, по сравнению с усилиями на понимание новой предметной области.

Спасибо за ссылку, интересно. Когда-то давным-давно (где-то в 1983 году, плюс-минус год-два) на одной из Школ программирования, проводимых ВЦ РГУ в Лиманчике (до сих пор вспоминаю эти события с нежностью) рассматривался вопрос о том, что такое "язык сверхвысокого уровня". После трех дней дискуссий было выработано какое-то определение (что-то очень похожее на определение современного DSL), и один из присутствующих вдруг заявил, что знает такой язык: это RPG -- язык генератора отчетов (что-то типа отдельного языка для оператора FORMAT в Фортране, что казалось всем присутствующим ниже нижнего уровня языка). Присутствующие обалдели, и не смогли от этого оправиться: RPG и впрямь удовлетворял всем требованиям сверхвысокоуровневости. Поэтому я веду линию этих языков верстки от нескольких источников: -- операторы "формат" всяких языков -- спецязыки генераторов отчетов -- языки разметки текста (ведущие свою историю от сладкой парочки форматтеров nroff/troff и заканчивая технологией DITA) -- языки верстки типа того же CSS. Мне вот прямо сейчас нужно что-то выбрать для описания методов в соответствии с метамоделью ISO 24744 (на выходе должен быть высокорегулярный текст типа http://www.verdewek.com/openmetis/Download/OPENMetisWhitePaper.zip). Мне почему-то кажется, что это нужно делать в "языковой парадигме", а не парадигме "кликания табличек", как в EPF Composer, в котором генерируются подобные тексты "в виде вебсайтов" (видел я эти переструктурированные вебсайты: нечитабельный ужас!). То есть я бы писал какой-то размеченный (промаркапленный) текст, который после процессинга бы "правильно и красиво сверстался со всеми справочными индексами и проставленными гиперссылками, а содержимое было бы проверено не только на соответствие типов фрагментов текста, но и на соответствие метамодели типов DSL", а не "заполнял окошки для базы данных, чтобы потом сработал хитрый генератор отчетов для хитрой схемы данных". Хотя тут, конечно, возможны варианты, но я склоняюсь к чисто текстовому представлению от "графического с объектами, их портами и связями с заполнением табличек атрибутов для каждого объекта и связи". Конечно, текстовое представление вовсе не исключает (и наоборот, подразумевает) представление в виде внутренней структуры данных, соответствующей схеме данных/метамодели, но "верстка результата-текста" тут вполне нормальная парадигма. Как я понимаю, тут мы обсуждаем что-то очень близкое к помянутой в постинге Пиумартовской парадигме "цепочек смысла", где всякие преобразования делаются в метафоре цепочек парсинга-верстки.

Да, и все эти линии постоянно взаимодействуют, а в девяностые W3C снова изобретает велосипеды... :) Но в один язык/синтаксис такое не объединить, получаются как минимум два разных. Для больше-разметки, описания структур с небольшим включением текста - например, подход HAML/SASS. И для больше-текста, с внедряемой разметкой - подход TeX и wiki markup. Впрочем, к описываемой выше задаче готовой базы для решений я не встречал. В TeX слишком специфичный DSL, а построенные в метафоре текст+DSL вебовские template engines столь примитивны, что с нуля проще. У Пиумарты парсер используется как частный случай pattern matching, поэтому внутренние трансформации тоже выглядят как парсинг-вёрстка. Интересно получается. :) Ведь в такой метафоре можно представить любой фрагмент кода на Рефале.

Я ко всей этой механике еще хочу подоткнуть контроль типов из ISO 15926, то есть у меня не столько "разметка для верстки", сколько "разметка для типизации". Грубо говоря, мне нужно как-то записывать структуры данных для ISO 24744 -- и это чистое недоразумение, что в них текстовые атрибуты на естественном языке могут быть довольно обширны. Со временем кодирование будет детальным, и длинные тексты на естественном языке будут заменены подробными семантическими описаниями всех этих WorkUnits, DocumentKinds и т.д. В этот момент довольно интересно, как будет выглядеть "управление версткой" итогового представления. Сама задача представляется мне крайне интересной и неисследованной (а с другой стороны -- абсолютно типовой и по-разному решаемой в современном программировании эпохи данных-в-XML и вывода-в-HTML. Другое дело, что вебовские решения по традиции "более тупые" и много из них не вытащишь, я считаю это некоторой боковой эволюционной веткой, которая должна будет вымереть в серьезных проектах. Поэтому я и ориентируюсь в том числе на языки разных репорт генераторов, а не на веб-языки). У Пиумарты нужно смотреть не только его работы, но и работы его соседей. Они по итогам этого года будут пытаться сделать "Франкенштейна", как они говорят -- софт, интегрирующий их разные идеи. Коротенечко это описано в http://www.vpri.org/pdf/tr2009016_steps09.pdf -- написано это в октябре 2009г., но выложено в открытый доступ в мае 2010, буквально недавно. "Приложения как верстка программ" там в полной мере раскрывается.

Сначала получается полноценный DSL описания структур данных для ISO 24744. А затем его вторая markup форма - с возможностью смешивания обеих форм в пределах одного файла, а также лёгким переводом одной в другую при редактировании. DSL выдаёт некую структуру с графом связей, на этом вкусное заканчивается, и начинается типовой вывод. Так? Материалы VPRI я читал, даже подписан на рассылку FONC (несмотря на нелюбовь к рассылкам :)

На встрече позавчера в Питере мы в очередной раз поставили вопрос о языке, в котором мы будем говорить о мегамодели (совокупности метамоделей, моделей, языков и нотаций, которые используем). Увы, я так и не понял про "вторую маркап форму": непонятно, что такое "форма DSL" (другой DSL? Другая нотация того же DSL? Равен ли "язык" в DSL тому, что называется language в ISO 24744 или это всегда language+notation?). Постараюсь чуть подробнее: -- есть DSL Mapper, на котором написано картирование 24744->15926. После работы Mapper получается метамодель 24744 в виде OIM (классы определены, но не определены экземпляры) в формате OWL-как-в-4й-части на данный момент. Можно прочесть этот OWL-файл в память, после чего получится представление на ОПSL ("оперативная память specific language" -- представление семантической сетки для ISO 15926 в оперативной памяти). -- инженер описывает метод в DSL-24744, находясь в IDE (а пока нет IDE с проверками типов, подсказками и автозавершениями в соответствии с типами, то в любом текстовом редакторе). Этот DSL использует разметку для отнесения написанного кода к тем или иным классам метамодели ISO 24744. После проработки компилятора/интерпретатора этого DSL-24744 в памяти получается на ОПSL уже имеющаяся OIM-24744, дополненная семантической сеткой откомпилированного текста на DSL-24744 ("МойМетод" на ОПSL). -- Для OIM-24744 на DSL-верстки (который переводится в OIM-верстки) определяется вывод ("генерация отчета"): форматирование, шрифты и прочие вещи, связанные с презентацией в различных медиа. По идее, в памяти после компиляции остается OIM-верстки на ОПSL плюс собственно семантическая сеть верстки-для-ISO24744 (МояВерстка24744 на ОПSL). -- МойМетод подвергается МоейВерстке и дает на выходе красивый сверстанный текст со всеми шрифтами, отступами, блэкджеком и шлюхами. То есть в моей версии "разметка смыслов" и "разметка шрифтов" проходят не в одном тексте, а "разметка шрифтов" ассоциируется с "разметкой смыслов" (то есть "стили" приклеиваются к смыслам). Это все, конечно, нужно проверять и поэкспериментировать с разными вариантами.

Язык с двумя нотациями, которые желательно сделать как можно ближе. Первая - смыслы, вторая - разметка смыслов в тексте. Что в первом случае выглядит так     info("myId", relation1=some_other_id, textattribute1="Hello!" textattribute2="Bye!") во втором внедряется в текстовый поток так     ..текст до..     {     \info("myId", relation1=some_other_id)     \.textattribute1     Hello!     \.textattribute2     Bye!     }     ..текст после.. Общие принципы такие, но настоящий дизайн должен быть лучше.

Важное уточнение: правильно тут говорить не "смыслы" все-таки, а "значения" или вернее "типы значений"(хотя "значения" и пересекаются с программистскими "значениями" -- но тут берем лингвистические значения слов. Если мы языко-ориентированные, то у нас ведь "слова" с объективными "значениями" и отличающимися от них субъективными "смыслами". Тут, правда, нужно разводить философскую дискуссию на эту тему, особенно про "типы значений", но пока воздержимся). Про две нотации в одном языке (в одном лучше видна разметка/структура типов значений в тексте, во второй лучше виден текст) понятно. Но ваш пример пока непонятен по двум статьям: -- зачем нужна нотация, в которой лучше видна разметка типов значений, чем сам текст? Как часто она будет использоваться? Для каких целей (какие операции будет удобней выполнять)? -- почему у вас с первом случае нет объемлющего текста "до" и "после", а во втором случае есть? Куда текст делся? У нас есть хороший пример: итоговый текст Open/METIS (я давал ссылку) со структурой крайне близкой к определяемой ISO 24744 за мелкими исключениями. Как это бы выглядело для него? В моём понимании в этом итоговом тексте почти убрана разметка типов значений (кроме того, что названия типов значений ушли в заголовки типа "Processes", "Models" и т.д.), плюс отработана разметка вёрстки (шрифты, центрирование и нестинг заголовков и т.д.). Нам нужно просто -- восстановить, как этот текст выглядел бы до обработки -- понять, как можно было бы улучшить этот текст в выходном виде (дополнительная провязка гиперссылками? комментарии на полях? дополнительные справочники в приложениях?), если бы мы грамотно его разметили значениями/типами значений во входном виде.

Например, "WorkUnit is an abstract subclass of EndeavourElement, specialized into Task, Technique and Process" - типичный искусственный текст, достаточно пары фактов в описании классов для его генерации. И первая нотация хороша (более комфортна для записи и чтения) для тех частей описания, где уровень детализации позволяет обходиться без прямого текста. subclassOf(EndeavourElement) abstract() В то же время, одна нотация может вкладываться в другую, с произвольной глубиной (имплементация - вопрос удобных скобок :) Поэтому "текст до" и "текст после" могут быть выражены в любой нотации. Но если это прямой текст, то во второй нотации он представлен как есть, а в первой придётся заключать в кавычки (или скобки перехода во вторую нотацию). Как можно превратить эти "контуры языка" во что-то красивое я посмотрю детальнее по конкретным структурам и документам.

> У нас есть хороший пример: итоговый текст Open/METIS (я давал ссылку) > со структурой крайне близкой к определяемой ISO 24744 за мелкими > исключениями. Как это бы выглядело для него? > В моём понимании в этом итоговом тексте почти убрана разметка типов > значений (кроме того, что названия типов значений ушли в заголовки > типа "Processes", "Models" и т.д.), плюс отработана разметка вёрстки > (шрифты, центрирование и нестинг заголовков и т.д.). Нам нужно просто > -- восстановить, как этот текст выглядел бы до обработки > -- понять, как можно было бы улучшить этот текст в выходном виде > (дополнительная провязка гиперссылками? комментарии на полях? > дополнительные справочники в приложениях?), если бы мы грамотно его > разметили значениями/типами значений во входном виде. Вопросы: - когда Вы говорите о не желании заполнять поля таблиц то, как в текстовом языке планируется проверять полноту и целостность описания, то есть, будет ли потом результат скармливаться порождающим системам? Возможно, планируется запускать чекер который строит по тексту структуры и их уже проверяет на полноту и целостность, тогда мы получаем лишний шаг, который логичней сгрузить на интерфейс, не обязательно табличный, чтобы строить текст на DSL уже полный и целостный. Другая возможность Вам: не надо делать проверки, так как результат читается человеком и неполнота и возможные нарушение целостности ссылок не важны. - в тексте, приведенном к качестве примера, присутствуют иллюстрации, Вы в дальнейшем планируете и их порождать из структурированных описаний? Если да то как планируется решить вопрос порождения, текста, заготовок моделей из описаний на 15926 – языка фактов, но не действий (я имею ввиду статику информационной модели против динамики языков программирования). - что кроме текстовых описаний должно быть на выходе? Из обсуждений мегамоделей, я вынес понимание, что идея была в фиксации варианта мегамодели для проекта, и погружении в нее всего начиная от требований и заканчивая фиксацией прохождения развилок, трассировка целей и тп так, чтобы можно было извлекать из мегамодели ТЗ, спецификации, данные для динамических моделей, информацию для DSS и правила для проверки сборок, итп

1. Полнота и целостность описания проверяются в текстовом языке как обычно: работа с ним происходит в IDE, и "ошибки отмечаются на полях". Старый "компиляторный" вариант с ошибками в отдельной выдаче я не рассматриваю. Результат по определению скармливается какому-то компилятору (интерпретатору, ленивому оценщику и т.д. -- подставить по вкусу) и предусматривает генерацию. Это верно для всех языков. Тут, похоже, обсуждается смесь нескольких языков, поэтому что когда какой язык порождает/обрабатывает, остается пока непроясненным. По идее, сначала отрабатывает "проверка типов", а затем "генерация итогового текста". Но justy_tylor предлагает что-то другое, я никак не разберусь, что именно. 2. Да, я планирую порождать эти иллюстрации из структурированных описаний. ISO 15926 тут понимается как система типов. Конечно, я могу порождать сложные типы и потом рисовать их структуру (диаграмму классов, и даже значения для констант). Другое дело, что к типам добавляется язык. Пока это простой язык верстки. Другое дело, что для верстки текст лучше бы брать из атрибутов. То есть это описания типов и констант, погруженные в верстальный язык. 3. На выходе текущего этапа (создание композера методов) должен быть текст "учебника метода" для начала. Хотя обсуждаются "любые цепочки преобразований" в череде разных DSL, т.п. делается .15926 платформа, включающая language workbench для многочисленных специализированных для разных целей DSL как инструментальный механизм. Все остальное -- потом, когда утрясется какая-то архитектура и терминология подхода .15926 платформы. Поэтому другие (кроме композера) прикладные примеры пока не рассматриваются. Уже и сейчас очень сложно: например, нужно честно "временной/жизненный цикл" из 24744 погрузить в 4D-онтологию ISO 15926 для качественной "проверки типов"...