May 1st, 2007

2019

Новое поколение ЭВМ

Sun и IBM решели выпустить мейнфреймы для Web 3.0 -- http://www.iht.com/articles/2007/04/25/business/compute.php (для игровых и видеоразвлекательных приложений).

Мне больше всего нравится в этой статье комментарий о некотором оживлении на рынке компьютерных архитектур: когда сегодняшние микропроцессоры уперлись в развитие многих ядер на одном чипе, можно вернуться к вопросу о хардверных архитектурах -- и выпуск новых мейнфреймов как раз может означать такой поворот событий в сторону вариаций в хардверных архитектурах после многих годов однообразного застоя. Почему застоя (даже больше -- отстоя)? Я просто опять вспомнил, как Alan Kay ругал нынешнюю микропроцессорную архитектуру за то, что она по факту в 1000 раз менее эффективна, чем немного модифицированная в 1979 году архитектура аж 1961 года!!! (http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273&page=3) :
Just as an aside, to give you an interesting benchmark—on roughly the same system, roughly optimized the same way, a benchmark from 1979 at Xerox PARC runs only 50 times faster today. Moore’s law has given us somewhere between 40,000 and 60,000 times improvement in that time. So there’s approximately a factor of 1,000 in efficiency that has been lost by bad CPU architectures.
The myth that it doesn’t matter what your processor architecture is—that Moore’s law will take care of you—is totally false.
Вот статья про Burroughs-машины, те самые, архитектура которых в 1000 раз более эффективна, нежели нынешние -- http://en.wikipedia.org/wiki/B5000.

Я успел когда-то давно попрограммировать на довольно низком уровне. И у меня осталось полное ощущение, что на сегодняшних технологиях все можно делать работающим в 1000 раз быстрее, жрущим памяти в 100 раз меньше, и время разработки тоже меньшим в разы и разы. Михаил Донской говорил мне несколько дней назад, что переписал ("с нуля", не заглядывая в оригинальные коды) платформу 1С для наладонников -- и нормально там эта платформа работает, быстро.

Ничего, все еще наладится. И про Лисп-машину вспомнят. Только это будет не Лисп-машина, а COLA (combined object-labmda)-машина (см. http://www.viewpointsresearch.org/pdf/colas-whitepaper.pdf). Я подписан на рассылку этого проекта (FONC), там все вполне шевелится.
2019

Организация/администрирование -- разнородные заметки последних дней (к построению предмета)

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

Collapse )
2019

Формализм для административной/организационной/операционной онтологии

Мы должны определить сейчас систему/язык программирования/моделирования/фиксации знаний (компьютеров и людей), которые связаны с организацией/администрированием. Что нам нужно записывать на формальном языке? А модели/схемы/описания/архитектуры организаций, указанные в http://ailev.livejournal.com/480843.html -- прежде всего оргонтологию=метамодель="научный предмет организации", получив тем самым domain specific language, на котором мы затем сможем описывать модели/схемы конкретных организаций.

Когда мы пытаемся создать более-менее формальную систему описаний различных организаций, то мы должны сначала выбирать из этих подходов тот стиль/вид языков программирования/моделирования/онтологического описания мира, который будет удобен для того или иного потребного администраторам программирования/моделирования/онтологического описания мира -- и прежде всего создания organizational knowledge domain specific language = метамодели = нашего целевого языка описания организации. Назовем этот язык-метамодель-оргонтологию Орглан (слово пока никем не занятое). Конечно, нужно сразу постулировать возможность трансляции/перевода формальной записи на Орглане из одной языковой семьи в другую, если потребуется.

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

Дискуссия-2006 в "Электронной России" про выбор подхода к описанию организации свелась к выбору из подходов с семантически-сетемыми "классификаторами и проекциями" и "объектного-процессного" UML-описания (или "ГосМастер против Rational Rose", как это было тогда обозвано). Описания на "просто языке программирования" даже не рассматривались -- ибо инструментарий для рендеринга различных view на описание организаций нужно еще поискать, а системы программирования с разнообразными "браузерами" типа смоллтоковских на тот момент даже не всплывали в разговорах.

Это я пишу через год после постинга http://ailev.livejournal.com/388456.html, с тех пор многое прояснилось -- в том числе понимание того, что на чужой оргонтологии далеко не уедешь. И, конечно, я знаю про работы Непейводы по логической классификации стилей программирования и "адекватности стилей задаче" -- но мы тут про другое. Более того, я догадываюсь, какая кипучая деятельность идет в Domain-Specific Modeling (http://en.wikipedia.org/wiki/Domain-specific_modeling), или даже как склеиваются UML и OWL в рамках document centric engineering (см. пример кратенького описания к http://www.sysmlforum.com/docs/cfps/SoSyM-CfP-MBSE.htm -- обожаю извлекать всякие тренды и определения из call for papers и call for participation).

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

Есть следующие более-менее распространенные подходы к компьютеризированному описанию окружающего мира:
1. семантические сети и базы знаний, ключевое слово "онтология" -- OWL, CycL, ER-оргмоделлеры типа ОргМастер и многие другие. Сейчас всех напрочь победил OWL, но как раз перед появлением этого подхода появлялись работы типа http://www.cs.man.ac.uk/~ocorcho/documents/ekaw00_CorchoGomezPerez.pdf, которые заставляют более внимательно отнестись к разнообразию разных языков спецификации онтологий (и которые указывают на выразимость в онтологических языках концептов, n-арных отношений, функций, процедур, экземпляров, аксиом, продукционных правил, формальной семантики). А в последнее время ResearchCyc предлагает навороченные альтернативы для knowledge formation and dialog, чем и предполагается заниматься (http://www.cyc.com/cyc/cycrandd/areasofrandd_dir/kfd).
2. объект-ориентированный подход: ключевое слово "модель" -- UML с добавками, все про model-driven development (неожиданно от "моделей предприятия" идет перескок в "генерацию исполняемого кода"), всевозможные ARISы и другие средства реализации "процессного подхода" и "корпоративной архитектуры". Тут нужно еще добавить и IDEF0-IDEF3.
3. "просто язык программирования", даже если это объект-ориентированный язык (но не UML, а Smalltalk/Self или аналогичный) и система браузеров для различного рендеринга кодов. Аспектное и контекстное программирование -- это сюда же. Языки сверхвысокого уровня, а также сверхмощные (т.е. сверхкомпактные, но быстрые) исполняемые языки типа COLA (combined object-lambda) из проекта FONC.
4. сущностые схемы, организационные схемы и прочий инструментарий СМД-методологов (хотя тут вся "компьютерная поддержка" сводится к Visio и спецнабору stensils в лучшем случае).

Кроме выбора "общеметодологического языка" для фиксации Орглана, нужно выбрать для него конкретную реализацию языковой среды.

По-хорошему, так все эти варианты описания равноприменимы -- "конкретный синтаксис" тут неважен. Важным оказывается сама языковая среда (позволяет ли она в конечном итоге использовать эти описания для создания OrgLAN -- скаламбурим тут и скажем, что "организационная сеть" является программной реализацией Orglan как организационного языка).

После опроса самых разных людей выяснилось, что подход 3 (использование какого-то исполнимого выразительного языка и его расширений вкупе с рефлексивными трансформациями, написанными на нем же) нравится всем, хотя и самый ресурсоемкий. Зоопарк "стандартных специализированных языков" (типа OWL, UML, транформационные языки и т.д.) в одной системе почему-то никого не привлекает, хотя в этом случае и возможно использование стандартного инструментария. Все мои собеседники говорили, что если уж и стоит задача фундаментальной разработки в одной из областей (построения предмета организации/администрирования), так тут нужно честно брать такой же фундаментальный инструментарий -- т.е. решать онтологические задачи прямо в целевом языке. Будет и компактнее, и понятнее, и быстрее.

Но ключевым при этом становится тот системный архитектор и "языковед", который будет ответственным за архитектуру этой разработки и элегантность "схватывания" оргонтологии языковыми средствами.

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

Поэтому вопрос к уважаемым френдам: не знают ли они кого-то, кто был бы способен выполнить такой амбициозный проект? Ибо дело стремительно катится к стартапу, и нужно подбирать команду.