Будущее программирования
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-21 07:44 am (UTC)no subject
Date: 2011-04-20 12:05 pm (UTC)в идеальном мире - да
в реальном мире, где пожелания пользователей "добавить фитюлечку сюда и фенечку вон туда" разлагают любые спецификации до полной неформализуемости - сомнительно
no subject
Date: 2011-04-20 12:11 pm (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
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 05:45 pm (UTC)no subject
Date: 2011-04-20 12:28 pm (UTC)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:57 pm (UTC)Другой вопрос, что после "набивки" такой штуки данными о реальном мире выясняется, что вычислительные мощности нужны очень неслабые.
И метамодель мира тоже уже несколько раз переписывалась. А за нею - перенабивка, ибо задача отображения онтологий в *такой детализации* автоматизированно пока решается плохо.
Реально оно живет в автострое, судостроении, у нефтяников и атомщиков. Может еще у фармакологов каких-то, но ручаться могу только за людей, с которыми общался.
Рекомендую поговорить с Мэтью Вестом и Ианом Александром про это.
no subject
Date: 2011-04-20 06:06 pm (UTC)no subject
Date: 2011-04-20 06:09 pm (UTC)no subject
Date: 2011-04-20 08:44 pm (UTC)Количество движений после спецификации минимально.
Целая статья про разработку спецификации сортировки и её реализации.
Там Эпиграм, но всё же.
no subject
Date: 2011-04-20 12:49 pm (UTC)no subject
Date: 2011-04-20 12:57 pm (UTC)(no subject)
From:no subject
Date: 2011-04-20 01:03 pm (UTC)Мир меняется. Создавать/править эти "software atom's" под реалии мира и задачи надо будет как и прежде.
Ты описал правильные вещи, но это не более чем еще один уровень абстракции. А он как известно, не отменяет того что работает внутри.
no subject
Date: 2011-04-20 05:53 pm (UTC)(no subject)
From:no subject
Date: 2011-04-20 01:12 pm (UTC)Далее вопрос в онтологических dependent types и принципиальной описуемости семантики/прагматики данных.
Добавить машиночитаемое онтологическое описание, что T это не просто float64, но ещё и верхняя граница диапазона рабочих температур оборудования, выраженная в градусах цельсия - да, можно. И даже полезно для дальнейших выводов. Однако, точности подобных описаний и выводимости из них полезной информации есть предел.
Описание действий часто оказывается проще, понятнее и проверяемее, чем детальное описание требований к данным. Особенно если до-машинное описание на уровне предметной области также составляется специалистами-предметниками в терминах действий.
Подобная проблема сейчас привела к популярности NoSQL решений. Декларативный уровень - всегда обобщение чего-то уже известного. Иногда его достаточно, а иногда конкретная декларативная модель была хороша вчера (для показа денормализованных таблиц из нормализованных данных в базе) и совершенно непригодна для сегодняшних иерархий и графов.
no subject
Date: 2011-04-20 05:58 pm (UTC)Там уже сейчас цепочки автоматически строятся из N элементов, не из одного преобразования.
Про остальное согласен, что пока все сложно, неочевидно и непонятно. Когда действия проще спецификаций это знак того, что язык спецификаций слишком плохой и/или не задействован автоматический вывод типов/цепочек/доказательств.
no subject
Date: 2011-04-20 03:04 pm (UTC)Сам же я всё больше прихожу к выводу, что есть занятия неформализуемые, требующие интеллекта и творческих способностей. И имеющие большой спрос.
Врачи, адвокаты, учителя, программисты...
no subject
Date: 2011-04-20 05:51 pm (UTC)no subject
Date: 2011-04-20 07:08 pm (UTC)no subject
Date: 2011-04-21 05:24 am (UTC)no subject
Date: 2011-04-21 09:29 am (UTC)И, кстати, хороший вопрос будет ли достаточно формализованное описание требований проще чем влоб наваять то что нужно.
no subject
Date: 2011-04-21 09:45 am (UTC)no subject
Date: 2011-04-21 11:33 am (UTC)А что нужно читать, чтобы программировать в этом будущем? Какая портфель знаний нужен?
(я прочитал все комментарии)
no subject
Date: 2011-04-21 11:38 am (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2011-04-21 07:22 pm (UTC)Имея нормальную библиотеку алгоритмов на Java, лямбды в придачу, выводимые типы - уже достаточно что бы кода про склеивание кусков спецификации ("отсортированно по признаку и сгруппировано по такому") почти не было.
Такую спецификацию уже больше ничем не сократишь. А алгоритмы в таком коде уже все есть готовые в библиотеке (отсортировать, сгруппировать, выбрать максимум, ...).
Помимо траты мозга на пользовательскую логику есть ещё трата мозга на техническую хрень. Типа, написание той самой нормальной библиотеки. Но там тоже как-то непонятно, как автоматом выводить алгоритмы сортировки или автоматом распределить алгоритм на ноды кластера.
Сможет ли такой автовывод алгоритма придумать алгоритм Ахо-Корасик или суффиксное дерево просто исходя из спецификации "нужно быстро находить строки"?
no subject
Date: 2011-04-22 04:41 am (UTC)Сможет ли машина придумывать хитрые алгоритмы? Сейчас это выглядит невероятным, но теоретически это вполне возможно. Повторюсь, еще недавно человек занимался распределением регистров, адресов памяти и выбором инструкций, а сегодня машина это делает лучше. Еще сегодня иные программисты сами описывают тип каждой переменной, но в некоторых языках с этим уже успешно справляется компилятор.
(no subject)
From: