November 28th, 2009

2021 год

Что нужно для счастья: онтология, лексика, нотация

Последние несколько дней я неоднократно натыкался в самых разных местах на рецепт счастья в описании мира. Успех в моделировании чрезвычайно прост, как 1-2-3:

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

Модели хранятся внутри компьютера как онтология, схема. Если вам не нужен доступ к моделям, этого достаточно.

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

Без онтологий очень тяжело. Поглядите на вопль комьюнити Business Rules и Complex Event Processing, как им тяжело жить без явной онтологии (особенно онтологии времени): http://intranet.cs.man.ac.uk/ruleML/presentations/keynote1.ppt

2. Лексика. Концепты по большому счету безымянны, а разные люди называют их по-разному в разных языках. Доступ к концептам дает лексика (vocabulary), терминология критична для понимания.

Если вам (а не вашему компьютеру) нужно как-то редактировать ваши модели (или программы -- все равно), то вам потребуется лексика. "Метки", "имена", "идентификаторы", "термины", "названия" -- это все лексика, терминология, словари.

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

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

Чтобы построить предметно-специфицированный язык (domain-specific language, DSL), вам потребуются:
-- онтология (метамодель, схема)
-- лексика (именно о ней заботятся при локализациях: кому удобно читать-писать по-русски, пусть используют русскую лексику. Кому удобно по-английски -- пусть переключаются на английский, это не должно ни на что влиять)
-- нотация (пусть она будет для этой предметной области привычна. Если вам нужно работать с музыкантами -- пусть это будут ноты на пяти линейках, а если у вас диджеи, то предложите им piano roll).

Проблема в том, что счастья нет:
-- ISO 15926 хорош как онтология, но в нем нет огромного числа важных концептов.
-- SBVR хорош для терминологии, но онтология в нем никудышная.
-- про нотации вообще сказать нечего, полная свобода делать свои собственные ошибки.

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

Но как только вам потребовалось описывать мир так, чтобы удовлетворить самых разных интересантов, и чтобы эти описания все были связаны между собой и поддерживалась их целостность, да еще и обеспечивалось коллективная работа над этим описанием, да еще объемы этих описаний велики (какая-нибудь нефтяная платформа с находящимся на ней небольшим нефтеперерабатывающим заводом, описанная с точностью, достаточной для ее изготовления), то у вас БОЛЬШИЕ ПРОБЛЕМЫ -- и с онтологией (должна быть одна, хотя в ней будет много-много метамоделей), и с лексиками (их уже будет много) и нотациями (их тоже немало -- десятки, если не сотни).

Нынешние линейки САПРов решают эту задачу "на коленке", все решения глубоко внутрифирменные. Языковые верстаки пытаются вывести решение этой задачи в обычную разработческую рутину.
2021 год

Wordpress.com -- первые впечатления

1. Там внутре очень кучеряво. Сначала даже показалось, что настроек побольше, чем в ЖЖ. Но это не так. Wordpress.com -- это публикации "в никуда", а не социальная сетка (чуть не опечатался: секта -- и недалеко бы ушел от истины). Поэтому настроек там с ЖЖ одинаково: в ЖЖ больше настроек, которые помогают бороться с френдами, а в wordpress.com больше настроек, помогающих бороться с постингами, их черновиками, их резюме и т.д.

2. Удивительно медленно. Я думал, что ЖЖ нетороплив. Нет, это wordpress.com нетороплив. Крайне нетороплив. Раздражительно нетороплив. И, похоже, даже его платные версии будут работать с той же неторопливостью (нигде не нашел, что оплата хоть что-нибудь ускоряет).

3. Не хватает чего-то типа semagic (по слухам, semagic тоже может постить в wordpress, но я как-то не нашел в нем возможности залогиниться и в ЖЖ и в wordpress и потом быстро переключаться между ними).

С огромным удивлением обнаружил, что я за последнюю пару дней написал ой-ой сколько по-английски (на http://ailev.wordpress.com уже 3 постинга, сделанные методом cut/paste из частной переписки. Один про системную инженерию и ее развитие, а два других про ISO 15926: как к нему приделать словарный уровень, и как к нему приделать language workbenches).

Тем самым, я теперь живу (по факту) в трех местах -- в ЖЖ, английском своем блоге и в Google Wave. А еще я иногда заглядываю в LinkedIn, ибо там в группах время от времени проскакивает что-то интересненькое.
2021 год

Программистские катакасты -- еще шаг от примата кода к примату процесса

Относительно новая мода -- катакасты (http://katas.softwarecraftsmanship.org/, все нужные ссылки с объяснениями -- http://katas.softwarecraftsmanship.org/?page_id=2).

Идея программистских ката проста и понятна, это идея обучения любому процессному навыку. Изучение НЛП начинается как раз с описания примера обучения вождению машины и подробно рассказывается про интериоризацию навыков. Музыкантам, танцорам, спортсменам этого тоже объяснять не нужно. Почему-то это нужно объяснять программистам (минут по десять каждое объяснение высококвалифицированными дядьками, и суть этого объяснения -- давайте брать в пример каратистов и музыкантов), и это объяснение почему-то программистов завораживает.

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

Я вначале даже не понимал, откуда столько восторгов. И только потом понял (хотя отнюдь не все из этого звучит в объяснениях самих программистов, это остается невысказанным):
а) это действительно радикальный сдвиг от обучения путем чтения чужих программ-результатов (наиболее распространенная парадигма обучения программированию: "хороший программист не тот, кто много кодирует, а тот, кто много читает чужой код") к обучению путем копирования процесса мастера. В ката учишься не "лучшим решениям", а учишься процессу их достижения. Учишься не дизайн-паттернам, а способам их вписывания в текст программы. Учишься процессу, а не структуре.
б) Тайминг важен. Читая книжку, невозможно понять ритм исходного действия. Ноты "Полета шмеля" не передают характера музыки, картинки характерных поз каратиста не передают скорости движений. В ката этот ритм очевиден. К тому же в книжке показать мультиоконное программирование невозможно, а видео решает проблему.
в) существеннейшая часть работы программиста перешла из кода в последовательность кодирования. TDD невозможно понять "по книжке": отсутствие ритма заставляет разбираться со многими похожими картинками (перескок между которыми дополнительно распыляет внимания) как с кинолентой, пытаясь восстановить движения по многочисленным похожим кадрикам. В результате TDD оказывается неосвоенным, и от него отказываются при легком дуновении дедлайнового ветерка. То же относится ко многим другим практикам: они сегодня относятся к процессу, а не к описанию результата. Процесс требует развертки во времени.

Современная форма программистских ката также требует перформанса, демонстрации другим людям. Так это же наш старый друг конструкционизм (http://en.wikipedia.org/wiki/Constructionist_learning) -- обучение заключается не столько в передаче знаний, сколько в создании каких-то значимых предметов и демонстрации их окружающим для получения обратной связи. В простейшей форме, это "набивание руки" на решении задач по уже освоенному материалу, переход осознанной компетентности в неосознанную, доведение мыслительного навыка до автоматизма -- но задачи эти нужно предъявлять, чтобы а) была цель, б) быть уверенным, что решил их правильно, в) получить обратную связь по улучшению.

Я вот думаю, какие могли бы быть ката в системной инженерии. И понимаю, что делать их нужно в САПР -- точно так же, как программистские ката делают в программных средах, а не с карандашом и бумагой. Учить нужно процессу, а не только результату. Недостаточно давать задачки типа "требования вот такие, найдите архитектурное решение". Нужно делать задачки в САПР, и затем добиваться ритма.

Но при программировании на DSL (а в САПР идет именно оно: программирование=моделирование на декларативных domain specific languages) почему-то нет тех практик, которые приняты при программировании на GPL (general programming languages). Но ведь суть та же! Значит, и приемы работы должны быть похожи, и приемы обучения.