Previous Entry Share Next Entry
2016-01

sustainable development (или как оставить индусов без работы)

все, казалось бы, хорошо в современном стане активистов от программирования. по одну сторону стоят различные 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: перевести на английский, а то что-то я совсем англ версию бложека забросил.


  • 1
ev_genus March 8th, 2010
Если взять пример с форматами, то можно было бы представить следующее.

Из спецификации формата X, правилами языка A, можно было бы сгенерировать конвертор в формат Y. Тогда системе достаточно просто знать спецификацию формата Y. Но если мощности форматов равны, то зачем придумывать новый?

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

Короче да, А → B. Но не забывай что A это не файл. А состояние вычислительной системы. Вообще всей на сколько у неё есть доступ и насколько есть доступ к ней. Возможно что в В просто нет места что б сделать A ↔ B. (Например гугл бы при каждом запросе копировал бы весь интернет) Я уже не говорю о случаях когда B не файл.

wizzard0 March 8th, 2010
>> если мощности форматов равны, то зачем придумывать новый?

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

Ну, например, есть у нас документы в формате Word 2003, но прошло 10 лет, и нам нужно выдать их в каком-нибудь другом формате, для того чтобы их обработала другая система.

Через несколько лет, например, придется обновить форматы файлов, которые используют Unix time (которое в 32 битах заканчивается в 2038 году).

А уже сейчас имеет смысл обновлять форматы, которые не поддерживают Unicode. Все три примера - изменение внешних условий. Если думать в терминах замкнутой системы - действительно, мощности форматов равны.

>> беда в том что генератор в формат X скорее всего описан в таких правилах которые не поддерживают описанное для Y.
Я не уверен, что правильно понимаю эту фразу

>> Возможно что в В просто нет места что б сделать A ↔ B

Да, понятно, что в общем случае преобразование действительно необратимо. Но простейший способ сделать его обратимым - хотя бы сохранить А. Так, как сейчас делают бутстрап компиляторов.

Кстати, компиляторов в этой системе будет много. Некоторые двусторонние, некоторые односторонние. Но с двусторонними проще...

ex_juan_gan March 8th, 2010
О как классно! Спасибо!

А ничего, что нынче люди уже руби с хаскелем мешают и получается неплохо?

wizzard0 March 8th, 2010
а) можно ссылку? :)

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

(no subject) (Anonymous) Expand
zoonior March 8th, 2010
A bidirectional programming language for ad-hoc, textual data.

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.


:)

wizzard0 March 8th, 2010
там ссылка битая, вот http://www.seas.upenn.edu/~harmony/

щас почитаю. забавно. линзы, отношения, schema-directed data, да :)

3d6 March 8th, 2010
Это один из путей.
Другой, в общем-то более привлекательный с точки зрения объема написанного кода и объема необходимого тестирования (система управления электростанцией, которая глючит - это явно не гут) - это подсаживание всего на виртуальные машины, которые занимаются реализацией совместимости с новой внешней средой. Конечно, это не панацея, и в случае совсем уж принципиальных изменений код переписывать придется, но выделить все подобные куски кода (типа чтения файлов, обращения к другим службам, и т.п.) в отдельные, почти не связанные с основным телом системы блоки - святая обязанность архитектора.
В более отдаленном будущем, таким взаимодействием с внешней средой должна будет заниматься универсальная интеллектуальная система, которая будет предоставлять необходимые данные для логической модели, и интерпретировать результаты ее работы. Для настройки же самой системы на внешнюю среду достаточно будет предоставить ей сравнительное описание ожидаемого и реального состояний среды, написанное на естественном языке с небольшими вставками спец. символов.

wizzard0 March 8th, 2010
>> виртуальные машины
http://en.wikipedia.org/wiki/Legacy_system#Improvements_on_legacy_software_systems

там еще где-то было про интерфейс через аппаратные KVM и подобные железки, но я уже посеял :)

>> таким взаимодействием с внешней средой должна будет заниматься универсальная интеллектуальная система, которая будет предоставлять необходимые данные для логической модели, и интерпретировать результаты ее работы. Для настройки же самой системы на внешнюю среду достаточно будет предоставить ей сравнительное описание ожидаемого и реального состояний среды, написанное на естественном языке с небольшими вставками спец. символов.

Собственно, да. Такой себе "метаинструмент". Я попытался это описать другими словами, но такое описание мне тоже нравится :)

kunaifusu March 8th, 2010
Проблема не инженерная а менеджерская - люди не хотят остаться без работы и переписывают код постоянно на новые модные технологии. Инженерно это не решается - им нужна работа и они ее придумают в обход любого самого умного само-развивающегося кода. А код на 20-30 лет и дольше пишут спокойно, IBM, например осаждает всех борцов с триграфами в С/С++, потому что у них работают системы написаные еще на EBCDICе.

metaclass March 8th, 2010
+1
Если остановить постоянные бессмысленные доработки и переделки софта - это очень быстро кончится вопросами со стороны владельцев бизнеса "а зачем вы вообще тут нужны, у нас и так все работает". Т.е. существование индустрии возможно только при софте, требующем постоянного наличия программистов и гуру-админов.

xeno_by March 8th, 2010
Спасибо! Отличный текст.

Я еще почитаю линки, а пока что было бы очень интересно, если ты сможешь набросить чуть больше информации по пунктам Б и В (а именно, на каком метаязыке писать модели, чтобы: 1) из них генерился код имплементации, 2) они могли быть понимаемы другими программами). Ессно, я не жду точного ответа - принимаются любые мысли в этом направлении.

Просто пока что не очень верится в то, что в рамках текущих моделей computer science можно научить программы понимать себя и другие программы в рамках 99.99% практических доменов. Конечно, сейчас популярны DSL и не зря, но это ведь не понимание программы, а просто костыль, расширяющий набор инструкций. Имхо, для общего случая необходима, прежде всего, неслабая матчасть, адекватно моделирующая когнитивные процессы.

Вот пример. Предположим есть в энтерпрайз-энвайронменте пачка веб-сервисов. У каждого есть WSDL, также у ESB можно спросить о том, какие сервисы сейчас есть онлайн. Это все здорово. Но, как только возникает задача, для которой надо из пачки сервисов скомпилировать данные и представить их пользователю, тут же нужно вмешательство программиста, который, собирает данные отовсюду, откуда надо, а потом из них генерит формочку на стопицот полей. Обе задачи скучные до невозможности - давайте автоматизировать.

Хотелось бы сказать: "вот тебе, железяка, запрос, а ты мне сама заинферь, откуда надо собирать данные, собери их, отфильтруй и покажи пользователю". Ладно, генерация GUI при наличии неприхотливого юзера более-менее решается - дайте только схему данных, а что делать с компиляцией данных? Насколько я могу себе представить, эта задача вообще не решается в терминах ESB и пачки сервисов.

P.S. другой вопрос, что там она далеко не всем нужна, т.к. конечные авторы и потребители информации – люди, а не машины. Ты, наверное, хотел сказать наоборот: "машины, а не люди"?

wizzard0 March 8th, 2010
>> чуть больше информации по пунктам Б и В

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

>> в рамках текущих моделей computer science
увы, да. не хватает и языков, и баз знаний. там по посту рассеяны ссылки на Cyc, Grammatical Framework, еще стоит поглядеть на iso 15926. до general-puprose CAD-системы еще очень далеко.

>> неслабая матчасть, адекватно моделирующая когнитивные процессы.
Именно. Моделировать надо не столько и не сколько софт, сколько людей и системы, ради которых, собственно, пишется софт.

>> что делать с компиляцией данных?
в терминах esb и сервисов да, т.к. данные не аннотированы (что это за флоат? тонны? метры? рейтинг? рейтинг! а рейтинг чего и зачем?)

>> Ты, наверное, хотел сказать наоборот: "машины, а не люди"?'
нет, именно люди. а что, вы уже скармливаете новости из гугл ридера вашему домашнему роботу? тогда мы идем к вам :)

109 March 8th, 2010
bit rot - это физический decay, а не моральный.

109 March 8th, 2010
тонкость в том, что все современные высокопроизводительные компиляторы, что у императивных, что у функциональных языков являются частными случаями проекций Футамуры. ключевое здесь именно слово “проекция” – т.е. происходит отображение А → B, а не A ↔ B, которое приводит к потере информации о исходной системе, или, точнее, потери информации о модели, реализацией которой является система.

эээ? потеря происходит гораздо раньше. например, на этапе system architecture -> detailed design (дизайн классов, интерфейсов и их взаимодействий). следующая потеря - на этапе собственно написания source кода. компилятор тут наименьшее зло.

wizzard0 March 8th, 2010
И с этим я тоже согласен.

Т.е. архитектура, дизайн и модель должны храниться вместе с программой, и в бинарниках тоже. Возможно, предоставляться на условиях "вы арендуете у нас программу\сервис, а после прекращения поддержки получаете ключи дешифровки вложенных моделей", дополнительным пакетом, аналогичным современным LTS (long term support), или покупаться сразу. С лицензионной точки зрения я не пробовал продумывать этот вопрос, но кажется, что всё решаемо.

metaclass March 8th, 2010
В общем, то, что ты хочешь - это некий гибрид сложных систем типизации и семантической разметки.
Чтобы система типов была достаточно мощной и для описания данных для машинной обработки и для понимания пользователем и для того, чтобы из нее осилить смысл этих данных.

metaclass March 8th, 2010
Вот к примеру, есть у нас реляционная база данных. В ней таблица, в таблице поле что-нибудь вроде "CAR_ROM_NUMBER" типа char(16). Если бы разработчикам было не влом и все базы данных бы поддерживали кастомные типы данных, то тип был был что-то вроде "ROMNUMBER,базовый тип char(16), описывает уникальный номер 1-wire устройства iButton, используемого для идентификации автомобилей". Если по хорошему, то последний комментарий нужно было бы писать не текстом, а какой-то семантической разметкой, чтобы потому это могли читать машины, а не только люди.

antonix March 8th, 2010
Модель то находится в голове.

Всегда есть некая модель, и есть некий механизм, по сути конечный автомат, выполняющий операции с моделью.

С точки зрения программ для электростанций и всего прочего, программа это не модель. Программа это конечный автомат. Компьютер это не конечный автомат, а «магическая хрень» обеспечивающая работу конечного автомата, то есть программы. То что эта «магическая хрень», по своей природе тоже является конечным автоматом, это уже другой вопрос, но это не проблема. А модель это сама электростанция со всеми её уникальностями.

Ценность труда программиста заключается в воссоздании этой модели у себя в голове. И написания на её основании некоего «конечного автомата» т.е. программы. Причем генерацию самого автомата, т.е. генерацию программы на основании модели наверное сравнительно легко автоматизировать. А вот сгенерировать модель – сложнее. Но в принципе возможно. Люди же это как-то делают.

Но сама по себе модель не сохраняется. Зачастую она существует только в голове программиста короткое время, когда он уже понял «как устроен мир» по части именно этой электростанции и написал программу работающий с «этим миром». То есть, модель это некая воображаемая загогулина в голове программиста, которая появляется на основании требований и спецификаций. Используется для написания программы. А затем безвозвратно теряется.

Да именно теряется. Я в этом уверен, потому что я ни разу не видел попыток людей сохранить именно то, что у них было в воображении, когда они писали программу. Документирование кода не предлагать, это всего лишь ещё одна спецификация кода а не модель. УМЛ диаграммы, уже лучше, но опять таки, это не то что крутится в воображении.

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

Что же касается самих программ для станций, автопилотов, и прочих программ, зря вы боитесь потерять содержащуюся в них «модель». Потому что эта модель уже давно потеряна. Собственно она была потеряна в момент написания этих программ. А окончательно она была потеряна когда авторы забыли что и как они себе думали пока их писали. То есть написание кода это уже необратимая операция, с точки зрения превращения модели в конечный автомат. Хотя в принципе, модель можно воспроизвести.

Да и ещё модель, именно ту которая была в голове у автора, можно воссоздать по книгам и учебникам которые он кроме всего писал, но скорее проще изобрести заново.

wizzard0 March 9th, 2010
http://wizzard0.livejournal.com/134487.html?thread=711511#t711511

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

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

что должно облегчить collaboration как внутри команды, так и вспоминание через полгода.

justy_tylor March 8th, 2010
Ur не теперь, пару лет назад он уже был. :)

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

Проблема скорее в самих используемых стандартах. Когда их делает W3C, то получается 100% ад-и-погибель. Но когда стандарта вообще нет - ещё хуже.

  • 1
?

Log in

No account? Create an account