![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
все, казалось бы, хорошо в современном стане активистов от программирования. по одну сторону стоят различные Ruby, Python, PHP, по другую - Ocaml, Haskell, F#, теперь вот Ur/Web – казалось бы, чего можно еще желать?
и в чем, собственно, вопрос?
Но вся эта братия деликатно обходит стороной два (связанных, в общем-то) вопроса – взаимодействие с другими системами (существующими и будущими), а также эволюция и взаимодействие с прошлыми и будущими версиями себя. Их решению мешает то, что ВСЕ theorem prover`ы, contract verification тулзы, генераторы тестов и пр. предполагают, что тестируемая система замкнута. Что неверно – ведь таким образом полностью протестировать можно только ПО, которое работает исключительно с предметной областью, порожденной единожды зафиксированной формальной логикой – например, компилятор или систему решения уравнений.
Понятно, что всякие твиттеры с веселыми фермерами можно отправить на свалку истории, и никто о них толком не вспомнит впоследствии, а что делать, например, с управляющим ПО автомобилей, электростанций, поездов и прочих комплексов со сроком службы более 20-30 лет? за это время успеет несколько раз смениться железо, ОС, а в запущенных случаях – протоколы обмена информацией и форматы файлов.
у нас же не просто так образовывается куча кода, который уходит на выброс (к вопросу о bit rot, который поднимался ранее), она образуется именно из-за нерешенной проблемы совместимости в малом масштабе (языков, платформ и т.д.) и в большом масштабе (взаимодействие построенных на этой базе систем).
революционное (write-build-test-release-repeat) развитие софта во многом упрощает разработку каждой следующей версии, но оставляет нас со старыми данными, зоопарком плохо совместимых (т.к. не все апгрейдятся мгновенно, по разным причинам) систем, и риском остаться с носом для тех, кто доверил софту свои данные, в случае внезапного исчезновения вендора или угасания комьюнити (да, понятно, что опенсорс частично решает эту проблему. но какой процент не-софтописательских организаций способен самостоятельно написать, скажем, конвертор хотя бы ODF в HTML, SVG в что-нибудь еще, или перенос нетривиального обьема и структуры БД, скажем, с MySQL на постгрес, включая переписывание всего использующего эту БД софта, если такой вопрос вдруг встанет?)
совместимость с другими существующими платформами – та же проблема, только в профиль. задача слегка облегчается тем, что есть “живое” окружение, на котором можно протестировать работу системы и заложить его в требования изначально. в случае с софтом, созданным после разработки оригинальной системы, таких поблажек нет.
тонкость в том, что все современные высокопроизводительные компиляторы, что у императивных, что у функциональных языков являются частными случаями проекций Футамуры. ключевое здесь именно слово “проекция” – т.е. происходит отображение А → B, а не A ↔ B, которое приводит к потере информации о исходной системе, или, точнее, потери информации о модели, реализацией которой является система.
к этому вопросу пытаются подходить с разных сторон – динамические ЯП (Lisp, Python, IO) позволяют интроспекцию структур данных “напрямую”, JVM и CLR имеют Reflection, более-менее продвинутые модели обмена данными между системами, известные в народе как “веб-сервисы” в той или иной форме самодокументируемы, а web медленно, но уверенно завоевывает семантическая разметка (другой вопрос, что там она далеко не всем нужна, т.к. конечные авторы и потребители информации – люди, а не машины), и именно поэтому она вряд ли получит такую же популярность как, например, CSS :)
ну и где же выход?
в этом смысле мне кажется, что долгоживущее программное обеспечение будущего должно представлять из себя динамические самодокументируемые системы, которые (в сегодняшней терминологии) способны
а) быть изменяемы без привлечения сторонних инструментов (которые могут стать недоступны по тем или иным причинам)
б) после изменения спецификации (модели) самостоятельно выработать алгоритмы, сгенерировать новый исполняемый код, (а потом рассчитать и изготовить железо, хехе), соответствующим образом сконвертировать данные при изменении форматов, или же подобрать и сгенерировать функции-адаптеры, которые будут делать это по мере необходимости
в) поддерживать протоколы обмена спецификацией друг с другом, которые позволяли бы системе накапливать знания о окружающем мире, людях и других системах, вносить их в модель и (автоматически или полуавтоматически) стыковаться с ними, и соответствующим образом развивать\расширять свое внутреннее представление данных и осваивать новые протоколы взаимодействия (возможно, тоже сгенерированные автоматически под данный частный случай)
фух. введение получилось в 4 раза дольше, чем собственно мысль. зато, вроде, теперь понятно, “зачем всё это нужно”. продолжение следует… черт. пост, к которому нужно оглавление – не такой уж и хороший пост…
NOTE TO SELF: перевести на английский, а то что-то я совсем англ версию бложека забросил.
no subject
Date: 2010-03-08 10:59 am (UTC)угу, я подумаю... мне тут внезапно напомнили, что надо до среды отсабмитить 2 статьи на конференцию, одна-то почти готова, а во второй еще совершенно конь не валялся... так что я сейчас вот это выгрузил из головы в блог, сейчас можно его радостно забыть и переключить контекст на некоторое время...
>> в рамках текущих моделей computer science
увы, да. не хватает и языков, и баз знаний. там по посту рассеяны ссылки на Cyc, Grammatical Framework, еще стоит поглядеть на iso 15926. до general-puprose CAD-системы еще очень далеко.
>> неслабая матчасть, адекватно моделирующая когнитивные процессы.
Именно. Моделировать надо не столько и не сколько софт, сколько людей и системы, ради которых, собственно, пишется софт.
>> что делать с компиляцией данных?
в терминах esb и сервисов да, т.к. данные не аннотированы (что это за флоат? тонны? метры? рейтинг? рейтинг! а рейтинг чего и зачем?)
>> Ты, наверное, хотел сказать наоборот: "машины, а не люди"?'
нет, именно люди. а что, вы уже скармливаете новости из гугл ридера вашему домашнему роботу? тогда мы идем к вам :)
no subject
Date: 2010-03-08 11:11 am (UTC)Я имел ввиду несколько другое. Моделировать когнитивные процессы, по-моему, было бы полезно, чтобы научить компьютер познавать мир вокруг (пока что "только" тот, мир, которые работает на нашем метаязыке, а, потенциально, и всю объективную реальность). В примере с сервисами познание бы заключалось в том, что программа бы сама смогла отдискаверить все сервисы, определить семантическую нагрузку данных, с которыми те работают, сопоставить эти данные, выделить в них общее и различное, уметь находить и ресолвить в них противоречия. В результате этого, такая программа бы могла скармливать менее одаренным собратьям свои данные из ложечки-адаптера, которую бы она генерировала автоматически.
>>нет, именно люди. а что, вы уже скармливаете новости из гугл ридера вашему домашнему роботу? тогда мы идем к вам :)
Хм, всю жизнь думал, что семантический веб нужен для того, чтобы его могли анализировать и использовать программы. Люди, хоть плачут и колются, но умеют это делать, а вот программы в общем случае это не умеют. Ни быстро, ни медленно, ни с матом - вообще никак.
no subject
Date: 2010-03-08 11:19 am (UTC)Веб-для людей в конечном итоге. Семантический веб-для машин. Людей сейчас больше. И пишут они тоже обычно именно для людей (за исключением SEOшников). Поэтому семантически размеченного контента не так уж много.
no subject
Date: 2010-03-08 11:21 am (UTC)Походу мы одно и то же выражаем в разных словах. В принципе на форму пофигу, главное, что по содержанию друг друга поняли =)
no subject
Date: 2010-03-08 11:24 am (UTC)Линки я почитаю, как будет возможность.
В идеале, хотелось бы целостную модель, на которой бы можно было построить действительно познающую себя и окружающий мирок программу, а не очередную, пусть и очень продвинутую по меркам сегодняшнего дня, подпорку. Но это я уже забегаю вперед - может как раз в линках про такое и написано.
no subject
Date: 2010-03-08 11:28 am (UTC)