Будущее программирования
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: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 01:02 pm (UTC)http://thedeemon.livejournal.com/33165.html?thread=371341#t371341
Вычислительных мощностей только-только начинает хватать, если пытаться без послаблений валидации работать.
>> воз, однако, если и сдвинулся, то совсем не в эту сторону
Его двигают, потому что требования к конечному продукту ужесточаются, регуляторы\экологи\конкуренты\аудиторы жмут с другой стороны, а списки закупок комплектующих на постройку подводной лодки, например (около 10..50 млн. отдельных SKU) нужно составлять за день-два, а не за несколько лет, например.
А вот инженерия софта действительно пока ползет в другую сторону.
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:48 pm (UTC)отсюда и оговорка на "как правило" - у нас это правило если и выполняется, то довольно специфичным образом
no subject
Date: 2011-04-20 01:51 pm (UTC)Скажем так, когда installed base менее 100 тысяч машин\пользователей - то можно считать что такой проблемы нету.
no subject
Date: 2011-04-20 08:03 pm (UTC)а что касается мильонов пользователей: ну вот зимой падал скайп на сутки. сколько денег они потеряли на этом падении? и сколько дополнительных денег им пришлось бы потратить на предотвращение этого падения?
no subject
Date: 2011-04-20 09:19 pm (UTC)no subject
Date: 2011-04-20 09:23 pm (UTC)no subject
Date: 2011-04-20 01:22 pm (UTC)no subject
Date: 2011-04-20 07:37 pm (UTC)В банковском софте баги в программе могут заткнуть отделом разбора жалоб.
no subject
Date: 2011-04-20 08:00 pm (UTC)no subject
Date: 2011-04-20 06:02 pm (UTC)no subject
Date: 2011-04-20 06:39 pm (UTC)а мечтать - оно, конечно, не вредно, кто бы спорил
no subject
Date: 2011-04-21 04:25 am (UTC)1. формализация требований
2. реализация их в коде
3. удостоверение в соответствии друг другу 1 и 2
Первый пункт останется, второй будет автоматизирован, третий отпадет за ненадобностью.
no subject
Date: 2011-04-21 05:07 am (UTC)или вы не для людей программы пишете?
no subject
Date: 2011-04-21 05:58 am (UTC)