Будущее программирования
Apr. 20th, 2011 06:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonВ будущем программирования не будет.
Знаете, 200 лет назад была такая профессия - фонарщик: надо было ходить по вечерам зажигать уличные фонари, а утром их тушить. И сайт ХэдъХантырь.ру пестрел объявлениями "Компании Люксофтъ требуются junior и senior фонарщики, умеющие обращаться с керосином и газом, наличие своей лестницы приветствуется, карьерный рост и соцпакет гарантируется". Фонарей становилось все больше, рынок рос, спрос на фонарщиков тоже. Но потом их работа была автоматизирована, фонарщиков не стало. Хотя это не значит, что ИТ-индустрия ("иллюминацонных технологий") пропала, она просто преобразилась, с тех пор выросши на порядки.
Как работает любая программа? У нее есть некий набор событий, которые она умеет воспринимать (действия пользователя, запросы от системы или других программ, в том числе по сети) и в ответ на эти события она что-то меняет в мире (что-то становится нарисовано на экране, что-то послано по сети в ответ, что-то записано на диске). Если у нас будет язык, на котором можно формально описать:
а) входные данные и состояние системы, причем не только их формат, но и свойства и взаимосвязи,
б) результат - желаемое состояние системы, и
в) нефункциональные требования (например, приоритет скорости над потреблением памяти или наоборот),
то все остальное компьютер сможет делать сам - найти оптимальный способ трансформации состояния из исходного в нужное, т.е. сам построить алгоритм, программу - то, что сегодня делают программисты. Для этого нужно лишь иметь набор примитивных функций, для которых так же подробно описаны их входы и выходы, и подобно тому, как сегодня работает вывод типов в ряде языков, сделать вывод свойств - оценку сложности и потребления памяти и других ресурсов. Фактически, задача построения алгоритма сведется к поиску оптимального пути в графе, где вершины - состояния, дуги - функции, а веса дуг - характеристики функций, вроде потребления определенных ресурсов. Сегодня задача поиска пути из Массачусетса в Аризону через сотни тысяч дорог, дорожек и населенных пунктов решается за долю секунды. В графе с намного более типизированными вершинами это можно делать еще быстрее.
Между прочим, рабочий прототип такой системы есть уже сегодня у каждого пользователя Windows - это движок DirectShow, используемый медиаплеерами и некоторыми другими приложениями. DirectShow оперирует графами, где потоки типизированных данных перемещаются между черными ящиками, преобразующими из из одного типа в другой. Например, мы хотим вывести на экран видео из некоего файла. Берем читалку файлов (фильтр File source) и видеоокошко (фильтр Video Renderer):
и просим движок DirectShow их соединить. Окошко не знакомо с форматами файлов и способами сжатия видео, оно умеет принимать на вход данные нескольких видов несжатых картинок. Читалка файлов тоже ничего не знает про форматы и сжатие, она просто читает файлы. Что делает движок DirectShow? У него есть база фильтров, про которые известно, какие форматы они умеют принимать на вход и выдавать на выход. Фактически, это функции. Например, декодер XviD есть функция из MPEG4 в Uncompressed_Video. Нередко выходной тип данных зависит от значений, полученных на входе, например AVI Splitter на входе имеет AVI файл, а на выходе в зависимости от содержимого файла может быть MPEG4, MJPEG, Huffyuv и еще сотни форматов. Зависимые типы, ага. И вот, пользуясь этой базой, а также при необходимости инстанцируя и "примеряя" некоторые фильтры, движок ищет последовательность фильтров, которая бы имела нужный вход и нужный выход, т.е. композицию функций нужного типа. По сути это задача поиска пути в графе, где типы данных - вершины, а фильтры-функции - дуги. Найдя путь, движок вставляет нужные фильтры и соединяет их в цепочку:
Фактически, компьютер только что придумал алгоритм: что делать, чтобы вывести видео из данного файла, какие операции над данными и в какой последовательности предпринимать. В данном случае искомая функция типа File -> Uncompressed_Video получается композицией функций FLV Splitter типа File -> Video_FLV1 и ffdshow decoder типа Video_FLV1 -> Uncompressed_Video. На картинке граф другого вида: в конкретных графах DirectShow наоборот вершины - фильтры, а дуги - данные, но это представление изоморфно вышеописанному.
Ту же схему можно применить и для построения произвольных программ, просто типы должны более детально описывать данные и состояния, а библиотека фильтров-функций должна быть достаточно хорошей. Скорее всего, примитивных функций нужно не так уж много, базового набора из Кнута/Кормена/Окасаки/whatever должно хватить для большинства задач. Понятно, что в большинстве случаев подходящих путей в таком графе будет очень много (proof irrelevance). В DirectShow в случае множественности возможных путей выбор происходит на основе приоритетов фильтров, заданных при их добавлении в базу. Это плохое решение, регулярно приводящее к проблемам. Но если для каждой функции будет автоматически выведена информация о ее характеристиках (сложность, требования к ресурсам, зависимости...), то можно будет задавать разные требования к программе и будут выбираться разные пути в графе.
Т.е. работа разработчика ПО сведется к составлению правильной спецификации. Нужно будет лишь правильно описать тип функции и требования к ее свойствам, составление же ее тела будет осуществляться автоматически, как сегодня автоматически зажигаются фонари.
Знаете, 200 лет назад была такая профессия - фонарщик: надо было ходить по вечерам зажигать уличные фонари, а утром их тушить. И сайт ХэдъХантырь.ру пестрел объявлениями "Компании Люксофтъ требуются junior и senior фонарщики, умеющие обращаться с керосином и газом, наличие своей лестницы приветствуется, карьерный рост и соцпакет гарантируется". Фонарей становилось все больше, рынок рос, спрос на фонарщиков тоже. Но потом их работа была автоматизирована, фонарщиков не стало. Хотя это не значит, что ИТ-индустрия ("иллюминацонных технологий") пропала, она просто преобразилась, с тех пор выросши на порядки.
Как работает любая программа? У нее есть некий набор событий, которые она умеет воспринимать (действия пользователя, запросы от системы или других программ, в том числе по сети) и в ответ на эти события она что-то меняет в мире (что-то становится нарисовано на экране, что-то послано по сети в ответ, что-то записано на диске). Если у нас будет язык, на котором можно формально описать:
а) входные данные и состояние системы, причем не только их формат, но и свойства и взаимосвязи,
б) результат - желаемое состояние системы, и
в) нефункциональные требования (например, приоритет скорости над потреблением памяти или наоборот),
то все остальное компьютер сможет делать сам - найти оптимальный способ трансформации состояния из исходного в нужное, т.е. сам построить алгоритм, программу - то, что сегодня делают программисты. Для этого нужно лишь иметь набор примитивных функций, для которых так же подробно описаны их входы и выходы, и подобно тому, как сегодня работает вывод типов в ряде языков, сделать вывод свойств - оценку сложности и потребления памяти и других ресурсов. Фактически, задача построения алгоритма сведется к поиску оптимального пути в графе, где вершины - состояния, дуги - функции, а веса дуг - характеристики функций, вроде потребления определенных ресурсов. Сегодня задача поиска пути из Массачусетса в Аризону через сотни тысяч дорог, дорожек и населенных пунктов решается за долю секунды. В графе с намного более типизированными вершинами это можно делать еще быстрее.
Между прочим, рабочий прототип такой системы есть уже сегодня у каждого пользователя Windows - это движок DirectShow, используемый медиаплеерами и некоторыми другими приложениями. DirectShow оперирует графами, где потоки типизированных данных перемещаются между черными ящиками, преобразующими из из одного типа в другой. Например, мы хотим вывести на экран видео из некоего файла. Берем читалку файлов (фильтр File source) и видеоокошко (фильтр Video Renderer):
и просим движок DirectShow их соединить. Окошко не знакомо с форматами файлов и способами сжатия видео, оно умеет принимать на вход данные нескольких видов несжатых картинок. Читалка файлов тоже ничего не знает про форматы и сжатие, она просто читает файлы. Что делает движок DirectShow? У него есть база фильтров, про которые известно, какие форматы они умеют принимать на вход и выдавать на выход. Фактически, это функции. Например, декодер XviD есть функция из MPEG4 в Uncompressed_Video. Нередко выходной тип данных зависит от значений, полученных на входе, например AVI Splitter на входе имеет AVI файл, а на выходе в зависимости от содержимого файла может быть MPEG4, MJPEG, Huffyuv и еще сотни форматов. Зависимые типы, ага. И вот, пользуясь этой базой, а также при необходимости инстанцируя и "примеряя" некоторые фильтры, движок ищет последовательность фильтров, которая бы имела нужный вход и нужный выход, т.е. композицию функций нужного типа. По сути это задача поиска пути в графе, где типы данных - вершины, а фильтры-функции - дуги. Найдя путь, движок вставляет нужные фильтры и соединяет их в цепочку:
Фактически, компьютер только что придумал алгоритм: что делать, чтобы вывести видео из данного файла, какие операции над данными и в какой последовательности предпринимать. В данном случае искомая функция типа File -> Uncompressed_Video получается композицией функций FLV Splitter типа File -> Video_FLV1 и ffdshow decoder типа Video_FLV1 -> Uncompressed_Video. На картинке граф другого вида: в конкретных графах DirectShow наоборот вершины - фильтры, а дуги - данные, но это представление изоморфно вышеописанному.
Ту же схему можно применить и для построения произвольных программ, просто типы должны более детально описывать данные и состояния, а библиотека фильтров-функций должна быть достаточно хорошей. Скорее всего, примитивных функций нужно не так уж много, базового набора из Кнута/Кормена/Окасаки/whatever должно хватить для большинства задач. Понятно, что в большинстве случаев подходящих путей в таком графе будет очень много (proof irrelevance). В DirectShow в случае множественности возможных путей выбор происходит на основе приоритетов фильтров, заданных при их добавлении в базу. Это плохое решение, регулярно приводящее к проблемам. Но если для каждой функции будет автоматически выведена информация о ее характеристиках (сложность, требования к ресурсам, зависимости...), то можно будет задавать разные требования к программе и будут выбираться разные пути в графе.
Т.е. работа разработчика ПО сведется к составлению правильной спецификации. Нужно будет лишь правильно описать тип функции и требования к ее свойствам, составление же ее тела будет осуществляться автоматически, как сегодня автоматически зажигаются фонари.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-04-20 12:00 pm (UTC)no subject
Date: 2011-04-20 12:05 pm (UTC)в идеальном мире - да
в реальном мире, где пожелания пользователей "добавить фитюлечку сюда и фенечку вон туда" разлагают любые спецификации до полной неформализуемости - сомнительно
no subject
Date: 2011-04-20 12:11 pm (UTC)no subject
Date: 2011-04-20 12:15 pm (UTC)он что-то похожее хотел.. о будушем...
no subject
Date: 2011-04-20 12:21 pm (UTC)http://video.yandex.ru/users/ya-events/view/126/
no subject
Date: 2011-04-20 12:22 pm (UTC)no subject
Date: 2011-04-20 12:28 pm (UTC)no subject
Date: 2011-04-20 12:29 pm (UTC)серьезно, идея "в будушем мы просто скажем компьютеру, что надо сделать" мне попадалась в книжках, которым лет больше, чем мне. воз, однако, если и сдвинулся, то совсем не в эту сторону
P.S. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
(C (http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html)) Alan J. Perlis
no subject
Date: 2011-04-20 12:44 pm (UTC)2. Этой идее лет 30, очередное обострение она получила в начале 90-х, т.н.языки спецификаций.
http://en.wikipedia.org/wiki/Specification_language
http://en.wikipedia.org/wiki/Specification_and_Design_Language
http://en.wikipedia.org/wiki/Category:Specification_languages
Но как обычно, русскоязычные не подозревают, что до них жили люди, даже ещё умнее их.
Во что упёрлись в прошлый раз?
Что мир, сцуко, реально сложный, и просто так его описать пупок развязывается.
Что точный язык для описаний, сцуко, реально сложный и люди не могут на нём писать.
Что перевод описания в алгоритм чаще всего неэффективен или неоднозначен, или непонятно как делать.
Что довольно трудно проверить, что перевод "what I mean, not what I say" -- то, что юзер хотел сказать.
Гораздо дешевле и проще выявить, что люди хотят от компьютеров (по областям), написать все покрывающие эти нужды готовые программы и говорить "поставьте xyz.rpm и не парьтесь". Этих xyz.rpm надо написать несколько меньше 6 млрд.
no subject
Date: 2011-04-20 12:49 pm (UTC)no subject
Date: 2011-04-20 12:51 pm (UTC)no subject
Date: 2011-04-20 12:57 pm (UTC)no subject
Date: 2011-04-20 12:57 pm (UTC)Другой вопрос, что после "набивки" такой штуки данными о реальном мире выясняется, что вычислительные мощности нужны очень неслабые.
И метамодель мира тоже уже несколько раз переписывалась. А за нею - перенабивка, ибо задача отображения онтологий в *такой детализации* автоматизированно пока решается плохо.
Реально оно живет в автострое, судостроении, у нефтяников и атомщиков. Может еще у фармакологов каких-то, но ручаться могу только за людей, с которыми общался.
Рекомендую поговорить с Мэтью Вестом и Ианом Александром про это.
no subject
Date: 2011-04-20 01:02 pm (UTC)http://thedeemon.livejournal.com/33165.html?thread=371341#t371341
Вычислительных мощностей только-только начинает хватать, если пытаться без послаблений валидации работать.
>> воз, однако, если и сдвинулся, то совсем не в эту сторону
Его двигают, потому что требования к конечному продукту ужесточаются, регуляторы\экологи\конкуренты\аудиторы жмут с другой стороны, а списки закупок комплектующих на постройку подводной лодки, например (около 10..50 млн. отдельных SKU) нужно составлять за день-два, а не за несколько лет, например.
А вот инженерия софта действительно пока ползет в другую сторону.
no subject
Date: 2011-04-20 01:03 pm (UTC)Мир меняется. Создавать/править эти "software atom's" под реалии мира и задачи надо будет как и прежде.
Ты описал правильные вещи, но это не более чем еще один уровень абстракции. А он как известно, не отменяет того что работает внутри.
no subject
Date: 2011-04-20 01:12 pm (UTC)Далее вопрос в онтологических dependent types и принципиальной описуемости семантики/прагматики данных.
Добавить машиночитаемое онтологическое описание, что T это не просто float64, но ещё и верхняя граница диапазона рабочих температур оборудования, выраженная в градусах цельсия - да, можно. И даже полезно для дальнейших выводов. Однако, точности подобных описаний и выводимости из них полезной информации есть предел.
Описание действий часто оказывается проще, понятнее и проверяемее, чем детальное описание требований к данным. Особенно если до-машинное описание на уровне предметной области также составляется специалистами-предметниками в терминах действий.
Подобная проблема сейчас привела к популярности NoSQL решений. Декларативный уровень - всегда обобщение чего-то уже известного. Иногда его достаточно, а иногда конкретная декларативная модель была хороша вчера (для показа денормализованных таблиц из нормализованных данных в базе) и совершенно непригодна для сегодняшних иерархий и графов.
no subject
Date: 2011-04-20 01:14 pm (UTC)no subject
Date: 2011-04-20 01:21 pm (UTC)Вы серьезно?
А какой софт вы пишете?
no subject
Date: 2011-04-20 01:22 pm (UTC)no subject
Date: 2011-04-20 01:48 pm (UTC)отсюда и оговорка на "как правило" - у нас это правило если и выполняется, то довольно специфичным образом
no subject
Date: 2011-04-20 01:51 pm (UTC)Скажем так, когда installed base менее 100 тысяч машин\пользователей - то можно считать что такой проблемы нету.
no subject
Date: 2011-04-20 02:08 pm (UTC)no subject
Date: 2011-04-20 03:04 pm (UTC)Сам же я всё больше прихожу к выводу, что есть занятия неформализуемые, требующие интеллекта и творческих способностей. И имеющие большой спрос.
Врачи, адвокаты, учителя, программисты...
no subject
Date: 2011-04-20 05:45 pm (UTC)no subject
Date: 2011-04-20 05:48 pm (UTC)