Обсуждение

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

Читал Вас последний месяц по диагонали, не понимая, откуда вдруг взялся такой поток инструментариев при отсутствии явной задачи. Теперь все прояснилось - оказывается, Вы орглан проектируете (чтобы на нем спроектировать "электронное государство", если я правильно понял презентацию в "Электронной Росиии"). Теперь буду читать Вас гораздо внимательнее!

Я бы отдал на аутсорсинг какой-нибудь российской (или молдавской :) фирме, которая с индусами конкурирует. По кр.мере сроки и качество предсказуемые.

Явная задача есть -- но она отнюдь не сводится к созданию "электронного государства". Да, у нашей небольшой группы есть опыт работы с госуправлением в целом и пары лет работы в программе "Электронная Россия". Но задачу мы ставим другую: создать такой предмет организации/администрирования, который был бы применим как в условиях государственных органов, так и в частном секторе. Там возникает огромное число самых разных идеологических и технических проблем, мы их потихоньку решаем. В "Электронной России" такой задачи не ставилось, и не ставилось задачи создать онтологию администрирования -- там пришли к выводу, что можно использовать уже готовое уникальное сочетание оргонтологии и моделлера ГосМастер питерской фирмы БИГ. Если мы при этом решили разрабатывать свою оргонтологию "с нуля", а также разработать новое поколение софтового оргинструментария, то можно выбрать и совершенно другие средства. Все мои постинги последнего месяца -- результат постепенного прохода по планам нашего разбирательства с проблемами организации, опубликованным довольно уже давно, пару лет назад. Просто прямо сейчас идет интенсивная сборка сделанного. Отсюда и мои семинары про менеджмент 21 века, и уточнение постановки задачи для софта, и поиск людей, и многое другое.

Ну да, именно это я и написал. На расширяемом языке можно вполне написать любой DSL, и использовать его для моделирования. Скажем, если языком выбрать Smalltalk и некоторые его избранные расширения.

А кто этой фирме задачу будет ставить? И потом прислеживать за выполнением? ;) Нет, нам нужен человек, с которым можно содержательно поговорить об отражении в языке понятий предметной области. Собеседник, а не кодер.

под абстрактным языком я имел ввиду не-ньюмановский язык, более абстрактный язык, который, впрочем, может быть написан на смолтоке.

команду порекомендовать не могу, но могу попробовать предложить себя в качестве когнитолога или его помощника (правда, научных работ на эту тему нет)

Я бы предложил себя (есть и некоторый опыт и желание :-), при желании могу выслать резюме), но я 1) живу в Новосибирске, 2) у меня двое маленьких детей (старшему 2 года, младшей 1 месяц), а отсюда вытекают проблемы с мобильностью и более жёсткие требования к оплате.

Лучше, чем вы, задачу вряд ли кто-нибудь поставит, иначе будет лишь испорченный телефон. Все равно вам придется это все править... Уж лучше один день потратить на написание задания. Собеседник поговорить сможет, но вот чтобы прислеживать, мягко говоря, за наемными программистами, это нужны совсем другие навыки. Железные нервы и железная воля :)

Да понимаю я все про абстрактный синтаксис. Я ровно об этом и пишу: если в основу положить расширяемый язык, то на нем (в том числе, используя его расширения) легко выражать различные абстрактные синтаксисы. Смоллток вполне нормальный выбор для такого языка. Если бы разработчики FONC были чуть более продвинуты в своих заботах, я бы выбрал их. Вот уж где можно было бы развернуться! Ибо "и смоллток тоже там".

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

Встретимся? У меня в профайле есть мыло, можно обменяться телефонами.

Думаю, что важно очное присутствие в Москве (учитывая еще и разницу во времени с NSK, онлайн коллаборация тут не пройдет)-- если нет планов переезжать, то и резюме присылать не стоит. Если есть планы -- стоит. Оплата, конечно, зависит не от наличия семьи, а от потенциальной отдачи.

Ваше желание разрабатывать 'продвинутую' систему, основываясь на 'ущербных' подходах (OWL, UML, ..), наверняка не оправдает ожиданий. Даже если когда-нибудь у Вас будет работающий интерпретатор OrgLAN, станет проблема наполнение (создание) базы данных на нем, что при Вашем фундаментальном подходе будет делом более сложным. Предлагаю рассмотреть вариант использования ЕЯ и естественной семантики, как наиболее адекватной как для создания онтологии (подязыка в данном случае), так и дальнейшего способа общения с системой. Конечно, предвижу возражения, что язык многозначен, сложен и пр. Это так, однако же есть наработки, которые можно было бы использовать в качестве хорошего фундамента. Кроме этого, Ваш оптимизм в отношении Крокета может дорого обойтись, ибо Smalltalk, будь он трижды хорош (хотя я так вообще не думаю) ни по выразительности, ни по скорости не годится для данной задачи. Мнение о том, что он проигрывает в 1.5 С++ ничем не подтверждено. Разница в два порядка минимум. Уже не говоря о том, что в случае с крокетом очень сложно будет использовать что-то кроме Smalltalk. Дружба только с дядей Васей имеет свои минусы. Я уж не говорю о совершенно неадекватной современности графической части, причем всякие отмазки вроде 'у нас все есть, только в других ветках, а вообще мы ого-го' меня лично не успокоили бы. P.S. Анонимность по причине глюков с регистрацией.

специально искал сравнительный тест (реальных приложений) а не то баловство, с которыми играются заангажированные Smalltalk любители, вот напр. http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gst&lang2=gpp, только там все цифры по преимуществу нужно множить на 1.5-2, т к. там gcc, который примерно во столько уступает компилятору Intel C++, (т. е. в binary-trees не в 23 раза медленней а минимум в 30 на коммерческом компиляторе). И память он выедает не как, к примеру, Питон в 1.5 раза от С++, а в 7-10 раз больше, чем нужно.

1. Приведенный тест скорости идет для GNU Smalltalk (который 11 апреля 2007 года вышел в новом релизе с такими фразами, как "Startup time and quit time were improved widely (the time for running a simple "Hello, World" program is about one fifth of 2.3.x)". Явно это не лучший из некоммерческих компиляторов. 2. Некоторые важные операции для Сквик медленнее таковых же в VisualWorks примерно в 10 раз. Ну, для Сквика был разработан оптимизирующий пакет Exuperi, который поднимает скорость выполнения таких операций в те же 10 раз. 4. Скорость в 60-80% от скорости на C была получена в экспериментах с виртуальной виртуальной машиной -- и, насколько я знаю, эти исследования сейчас активно используются в проекте FONC combined object-lambda, одним из первых целевых языков для которого является как раз Smalltalk, и которые делается командой инициаторов проекта Сквик (это "следующая версия"). Виртуальная виртуальная машина для Pepsi/Cola/id уже живая для нескольких платформ, и даже поддерживает аспектное программирование. Увы, там пока самое-самое начало, и опираться на эту систему пока нельзя абсолютно. Просто иметь ввиду.

У нас совсем нет желания разрабатывать продвинутую систему, основываясь на OWL, UML и всех девяти стандартах model-driven approach и примерно таком же количестве стандартов (если не больше!) из Semantic Web. С этими бассейнами, кинозалами, зимними садами наш маленький самолетик не взлетит. Я удручен, что мой постинг можно прочесть как разворот в эту сторону. Выбор ЕЯ в качестве основного инструментария "на входе" подразумевает работу с такими системами, как CYC. Очень интересно, но остается тысяча и один вопрос про а) интерфейсы, б) коллаборативность, в) что еще нужно добавить к этому топору (похоже, что много-много кода на Java), чтобы получился съедобный суп. Если не CYC, то сразу же встают вопросы про то, что умеет система работы с языком, и как она будет развиваться. Выбор ЕЯ в качестве одного из выходных языков (один из костюмов для объекта -- говоря в терминах интерфейсной архитектуры Tweak) вполне возможен. Интересно также говорить об анализе "наговоренного на ЕЯ" в коммуникационной части системы (в переписке, тредах комментов, описаниях работ и т.д.) -- и потом добавления находок к имеющейся структурированной информации. Этим мы планируем заниматься, и как минимум один разговор у нас на эту тему уже состоялся. Это направление никак не противоречит тому, что мы собираемся сделать сейчас: разработать онтологию и зафиксировать ее в каком-то языке, позволив стандартными интерфейсными средствами делать различные view для инстансов объектов зафиксированных в онтологии классов. Отмазки про "другие ветки", конечно, серьезны. Но идеальных выборов не бывает. Выбирается Крокет за "автомагические" коллаборативность и p2p, наличие интерфейса Tweak, компактность кода, портируемость и близость к проекту FONC, идеологическую близость к нашим верхнеуровневым целям (промышленно-учебные системы). Дружба только с дядей Васей имеет и свои плюсы -- зоопарки весьма трудно сопровождать. Про вынужденную анонимность понял, но можно подписаться и прямо в тексте -- хотя бы чтобы не путались разные анонимы друг с другом :)

И, кстати, всегда будет возможность поучаствовать в проекте. Нам хотелось бы держать эту разработку как open source. Зарабатывать мы хотим на сервисах (прежде всего -- управленческом консалтинге), а не на коде.

>У нас совсем нет желания разрабатывать продвинутую систему, основываясь на OWL, UML.. Но как же? Ведь кроме этого никаких других 'средств' в Вашем посте упомянуто не было. Поэтому вполне можно было догадаться, что речь идет о чем-то подобном. >Я удручен, что мой постинг можно прочесть как разворот в эту сторону. Зря, много хотеть добиться отнюдь неплохо :-) Я ,конечно, в какой-то мере, приписал Вам и свои мысли, но что Вам нужно, я наверняка понял. И нужна Вам довольно развитая экспертная система, способная работать с разными источниками данных. С богатым интерфейсом по части работы как с внутренним представлением, так и возможностью визуализации результатов. Если и не сразу, то потом обязательно. Исходя из этого я и посоветовал более осмотрительно подходить к инструментарию. Потому как Крокет здесь никак не пройдет. Просто он из другой оперы,- конференц-система с 3D примочками. С посредственной реализацией и большим списком проблем. Коль скоро Ваша система будет ориентирована на тесную работу с документами, то выбор ЕЯ в качестве обязательного, если не сказать первичного компонента, необходим. Далее, чтобы система могла 'читать' документ, необходимо либо чтобы она напрямую работала с ЕЯ, либо посредник, который будет содержание переформулировать на OrgLAN. Разумеется, первый вариант более здравый. >Выбор ЕЯ в качестве основного инструментария "на входе" подразумевает работу с такими системами, как CYC. Совершенно справедливо. Но только отсутствие систем на базе Cyc, способных читать документы в какой-либо существенной предметной области говорит не в пользу Cyc. Я имел ввиду несколько другое: не имеет смысла изобретать новый формализм, идя по пути Cyc, OWL, UML и пр. творений компьютерной индустрии. Подход Cyc, OWL - давайте сделаем формализм, а потом его как-то сделаем полезным для практических задач - не работает. Хотя, конечно, под практической задачей я подразумеваю работу с ЕЯ. А вот идти от ЕЯ к формализму (семантической сети - реальной и адекватной онтологии) - это лучший путь по нескольким причинам: любой эксперт сможет проверить и расширить уже созданную модель, не зная спец. языка, эту модель сразу можно использовать для транслятора ЕЯ->семантическая сеть с последующим любым анализом на ней, также по полученному результату можно синтезировать совершенно осмысленные фразу на ЕЯ. Последнее, правда, нигде работающим не встречал. По поводу производительности интерпретируемых языков не хочу Вас разочаровывать, но сходную производительность они могут показывать только на очень специально подобранных тестах. Чудес не бывает, и когда вместо 2 ассемблерных команд интерпретатор выполняет 30, и третья часть из них - операции с регистрами адресации и чтения (не нужного для обычного кода) в кэш, ни о каком сравнимом быстродействии речи быть не может. Их заявления я бы отнес к научной фантастике, если только они не делают JIT-компиляцию, как в .Net. Но JIT-компилируемый код перестает быть динамическим. Извиняюсь за анонимность - Георгий Дерновой.