![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wizzardвсе, казалось бы, хорошо в современном стане активистов от программирования. по одну сторону стоят различные 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: перевести на английский, а то что-то я совсем англ версию бложека забросил.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-03-08 03:58 am (UTC)Из спецификации формата X, правилами языка A, можно было бы сгенерировать конвертор в формат Y. Тогда системе достаточно просто знать спецификацию формата Y. Но если мощности форматов равны, то зачем придумывать новый?
Тогда получается что придумать конвертор нельзя, а нужно придумывать другой генератор. Но беда в том что генератор в формат X скорее всего описан в таких правилах которые не поддерживают описанное для Y.
Короче да, А → B. Но не забывай что A это не файл. А состояние вычислительной системы. Вообще всей на сколько у неё есть доступ и насколько есть доступ к ней. Возможно что в В просто нет места что б сделать A ↔ B. (Например гугл бы при каждом запросе копировал бы весь интернет) Я уже не говорю о случаях когда B не файл.
no subject
Date: 2010-03-08 04:14 am (UTC)Например, 3д модель можно представить полигонами, вокселями, набором проекций, а еще его всё можно упаковать в октарное дерево, сжать, и провести еще много разных в общем-то обратимых трансформаций.
Ну, например, есть у нас документы в формате Word 2003, но прошло 10 лет, и нам нужно выдать их в каком-нибудь другом формате, для того чтобы их обработала другая система.
Через несколько лет, например, придется обновить форматы файлов, которые используют Unix time (которое в 32 битах заканчивается в 2038 году).
А уже сейчас имеет смысл обновлять форматы, которые не поддерживают Unicode. Все три примера - изменение внешних условий. Если думать в терминах замкнутой системы - действительно, мощности форматов равны.
>> беда в том что генератор в формат X скорее всего описан в таких правилах которые не поддерживают описанное для Y.
Я не уверен, что правильно понимаю эту фразу
>> Возможно что в В просто нет места что б сделать A ↔ B
Да, понятно, что в общем случае преобразование действительно необратимо. Но простейший способ сделать его обратимым - хотя бы сохранить А. Так, как сейчас делают бутстрап компиляторов.
Кстати, компиляторов в этой системе будет много. Некоторые двусторонние, некоторые односторонние. Но с двусторонними проще...
no subject
Date: 2010-03-08 04:18 am (UTC)Есть данные, с которыми работает система, и есть типы этих данных. Типы копировать стоит, данные - нет.
no subject
Date: 2010-03-08 04:13 am (UTC)А ничего, что нынче люди уже руби с хаскелем мешают и получается неплохо?
no subject
Date: 2010-03-08 04:17 am (UTC)б) в принципе, на любом тьюринг-полном языке можно создать систему, которая помнит про модель, про правила языка и может его трансформировать при желании в нечто другое. даже если отталкиваться чисто от статически компилируемых систем - ничто не мешает отдельно сохранить метаинформацию, из которой можно потом воссоздать следующую версию. Но, гм, что-то я таких систем в массовом использовании не встречал, и это меня настораживает.
no subject
Date: 2010-03-08 04:35 am (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2010-03-08 07:03 am (UTC)Boomerang grew out of the Harmony generic data synchronizer. All of our current efforts are focused on Boomerang and on lenses for string data; older work on lenses for trees, relations, and generic schema-directed data synchronization is archived here.
:)
no subject
Date: 2010-03-08 10:09 am (UTC)щас почитаю. забавно. линзы, отношения, schema-directed data, да :)
no subject
Date: 2010-03-08 07:29 am (UTC)Другой, в общем-то более привлекательный с точки зрения объема написанного кода и объема необходимого тестирования (система управления электростанцией, которая глючит - это явно не гут) - это подсаживание всего на виртуальные машины, которые занимаются реализацией совместимости с новой внешней средой. Конечно, это не панацея, и в случае совсем уж принципиальных изменений код переписывать придется, но выделить все подобные куски кода (типа чтения файлов, обращения к другим службам, и т.п.) в отдельные, почти не связанные с основным телом системы блоки - святая обязанность архитектора.
В более отдаленном будущем, таким взаимодействием с внешней средой должна будет заниматься универсальная интеллектуальная система, которая будет предоставлять необходимые данные для логической модели, и интерпретировать результаты ее работы. Для настройки же самой системы на внешнюю среду достаточно будет предоставить ей сравнительное описание ожидаемого и реального состояний среды, написанное на естественном языке с небольшими вставками спец. символов.
no subject
Date: 2010-03-08 10:39 am (UTC)http://en.wikipedia.org/wiki/Legacy_system#Improvements_on_legacy_software_systems
там еще где-то было про интерфейс через аппаратные KVM и подобные железки, но я уже посеял :)
>> таким взаимодействием с внешней средой должна будет заниматься универсальная интеллектуальная система, которая будет предоставлять необходимые данные для логической модели, и интерпретировать результаты ее работы. Для настройки же самой системы на внешнюю среду достаточно будет предоставить ей сравнительное описание ожидаемого и реального состояний среды, написанное на естественном языке с небольшими вставками спец. символов.
Собственно, да. Такой себе "метаинструмент". Я попытался это описать другими словами, но такое описание мне тоже нравится :)
no subject
Date: 2010-03-08 07:49 am (UTC)no subject
Date: 2010-03-08 09:04 am (UTC)Если остановить постоянные бессмысленные доработки и переделки софта - это очень быстро кончится вопросами со стороны владельцев бизнеса "а зачем вы вообще тут нужны, у нас и так все работает". Т.е. существование индустрии возможно только при софте, требующем постоянного наличия программистов и гуру-админов.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-08 09:48 am (UTC)Я еще почитаю линки, а пока что было бы очень интересно, если ты сможешь набросить чуть больше информации по пунктам Б и В (а именно, на каком метаязыке писать модели, чтобы: 1) из них генерился код имплементации, 2) они могли быть понимаемы другими программами). Ессно, я не жду точного ответа - принимаются любые мысли в этом направлении.
Просто пока что не очень верится в то, что в рамках текущих моделей computer science можно научить программы понимать себя и другие программы в рамках 99.99% практических доменов. Конечно, сейчас популярны DSL и не зря, но это ведь не понимание программы, а просто костыль, расширяющий набор инструкций. Имхо, для общего случая необходима, прежде всего, неслабая матчасть, адекватно моделирующая когнитивные процессы.
Вот пример. Предположим есть в энтерпрайз-энвайронменте пачка веб-сервисов. У каждого есть WSDL, также у ESB можно спросить о том, какие сервисы сейчас есть онлайн. Это все здорово. Но, как только возникает задача, для которой надо из пачки сервисов скомпилировать данные и представить их пользователю, тут же нужно вмешательство программиста, который, собирает данные отовсюду, откуда надо, а потом из них генерит формочку на стопицот полей. Обе задачи скучные до невозможности - давайте автоматизировать.
Хотелось бы сказать: "вот тебе, железяка, запрос, а ты мне сама заинферь, откуда надо собирать данные, собери их, отфильтруй и покажи пользователю". Ладно, генерация GUI при наличии неприхотливого юзера более-менее решается - дайте только схему данных, а что делать с компиляцией данных? Насколько я могу себе представить, эта задача вообще не решается в терминах ESB и пачки сервисов.
P.S. другой вопрос, что там она далеко не всем нужна, т.к. конечные авторы и потребители информации – люди, а не машины. Ты, наверное, хотел сказать наоборот: "машины, а не люди"?
no subject
Date: 2010-03-08 10:59 am (UTC)угу, я подумаю... мне тут внезапно напомнили, что надо до среды отсабмитить 2 статьи на конференцию, одна-то почти готова, а во второй еще совершенно конь не валялся... так что я сейчас вот это выгрузил из головы в блог, сейчас можно его радостно забыть и переключить контекст на некоторое время...
>> в рамках текущих моделей computer science
увы, да. не хватает и языков, и баз знаний. там по посту рассеяны ссылки на Cyc, Grammatical Framework, еще стоит поглядеть на iso 15926. до general-puprose CAD-системы еще очень далеко.
>> неслабая матчасть, адекватно моделирующая когнитивные процессы.
Именно. Моделировать надо не столько и не сколько софт, сколько людей и системы, ради которых, собственно, пишется софт.
>> что делать с компиляцией данных?
в терминах esb и сервисов да, т.к. данные не аннотированы (что это за флоат? тонны? метры? рейтинг? рейтинг! а рейтинг чего и зачем?)
>> Ты, наверное, хотел сказать наоборот: "машины, а не люди"?'
нет, именно люди. а что, вы уже скармливаете новости из гугл ридера вашему домашнему роботу? тогда мы идем к вам :)
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-08 11:47 am (UTC)Но дело в том, что в силу клинического идиотизма современных систем, инструментов и программистов, такая задача, решаемая в концептуальном виде за пару дней, сопровождается месяцем сношений в стиле "напишем вручную перенос данных из старой системы на Clarion в новую на Oracle, потому что ни метапрограммирования, ни кодогенераторов у нас под руками нет, и даже если бы и были - то ни один человек из нашего же саппорта и младших програмеров этого не поймет никогда".
Т.е. задача простая и творческая - написать функцию преобразования одного типизированного множества данных в другое. Но чтобы потом придуманную функцию адаптировать к реальным системам - начинается ручная дрочка, занимающая 99% времени.
no subject
Date: 2010-03-08 09:50 am (UTC)no subject
Date: 2010-03-08 09:57 am (UTC)эээ? потеря происходит гораздо раньше. например, на этапе system architecture -> detailed design (дизайн классов, интерфейсов и их взаимодействий). следующая потеря - на этапе собственно написания source кода. компилятор тут наименьшее зло.
no subject
Date: 2010-03-08 10:42 am (UTC)Т.е. архитектура, дизайн и модель должны храниться вместе с программой, и в бинарниках тоже. Возможно, предоставляться на условиях "вы арендуете у нас программу\сервис, а после прекращения поддержки получаете ключи дешифровки вложенных моделей", дополнительным пакетом, аналогичным современным LTS (long term support), или покупаться сразу. С лицензионной точки зрения я не пробовал продумывать этот вопрос, но кажется, что всё решаемо.
no subject
Date: 2010-03-08 11:02 am (UTC)а еще оно писалось в духе "ой черт черт, сейчас всё позабываю" :D
(no subject)
From:no subject
Date: 2010-03-08 11:49 am (UTC)Чтобы система типов была достаточно мощной и для описания данных для машинной обработки и для понимания пользователем и для того, чтобы из нее осилить смысл этих данных.
no subject
Date: 2010-03-08 11:53 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-08 12:00 pm (UTC)no subject
Date: 2010-03-08 03:35 pm (UTC)Всегда есть некая модель, и есть некий механизм, по сути конечный автомат, выполняющий операции с моделью.
С точки зрения программ для электростанций и всего прочего, программа это не модель. Программа это конечный автомат. Компьютер это не конечный автомат, а «магическая хрень» обеспечивающая работу конечного автомата, то есть программы. То что эта «магическая хрень», по своей природе тоже является конечным автоматом, это уже другой вопрос, но это не проблема. А модель это сама электростанция со всеми её уникальностями.
Ценность труда программиста заключается в воссоздании этой модели у себя в голове. И написания на её основании некоего «конечного автомата» т.е. программы. Причем генерацию самого автомата, т.е. генерацию программы на основании модели наверное сравнительно легко автоматизировать. А вот сгенерировать модель – сложнее. Но в принципе возможно. Люди же это как-то делают.
Но сама по себе модель не сохраняется. Зачастую она существует только в голове программиста короткое время, когда он уже понял «как устроен мир» по части именно этой электростанции и написал программу работающий с «этим миром». То есть, модель это некая воображаемая загогулина в голове программиста, которая появляется на основании требований и спецификаций. Используется для написания программы. А затем безвозвратно теряется.
Да именно теряется. Я в этом уверен, потому что я ни разу не видел попыток людей сохранить именно то, что у них было в воображении, когда они писали программу. Документирование кода не предлагать, это всего лишь ещё одна спецификация кода а не модель. УМЛ диаграммы, уже лучше, но опять таки, это не то что крутится в воображении.
Принимая это во внимание, разговоры о совместимости языков программирования, форматов данных и прочего, это по сути разговоры о формате в котором записан конечный автомат. И здесь, как уже было сказано, любой Тьюринг-полный язык вполне достаточный с технической точки зрения, а отличается только синтаксисом. То есть конвертируйте на здоровье как угодно и куда угодно.
Что же касается самих программ для станций, автопилотов, и прочих программ, зря вы боитесь потерять содержащуюся в них «модель». Потому что эта модель уже давно потеряна. Собственно она была потеряна в момент написания этих программ. А окончательно она была потеряна когда авторы забыли что и как они себе думали пока их писали. То есть написание кода это уже необратимая операция, с точки зрения превращения модели в конечный автомат. Хотя в принципе, модель можно воспроизвести.
Да и ещё модель, именно ту которая была в голове у автора, можно воссоздать по книгам и учебникам которые он кроме всего писал, но скорее проще изобрести заново.
no subject
Date: 2010-03-09 08:55 am (UTC)>> я ни разу не видел попыток людей сохранить именно то, что у них было в воображении, когда они писали программу
да, вот именно это я и понимаю под "самодокументируемой системой"
то есть, хочется выгрузить модель из головы автора
что должно облегчить collaboration как внутри команды, так и вспоминание через полгода.
no subject
Date: 2010-03-08 05:17 pm (UTC)Декларация новой версии формата данных одновременно с правилами автоматической (или полуавтоматической) трансляции из старых версий - штука несложная. Трансляция алгоритмов с одного языка на другой - в принципе тоже, только человеко-месяцев на транслятор поболее будет.
Проблема скорее в самих используемых стандартах. Когда их делает W3C, то получается 100% ад-и-погибель. Но когда стандарта вообще нет - ещё хуже.