Некоторое время назад меня пригласили выступить на вебинаре перед молодыми программистами. Я собирался назвать свой рассказ «IT в точке бифуркации: верхи не могут, а низы тоже не могут», но после того, как по названию прошлись маркетологи, оно превратилось в «Назад в будущее информационных технологий» (что совсем бредово). Я узнал об этом замечательном названии незадолго до выступления и сумел обрезать его до нейтрального «Будущее информационных технологий», попутно выкинув почти все о бифуркации.
Выступление прошло и осталась видеозапись, на которой показана презентация и слышен мой голос. Сначала я хотел выставить в блог эту видеозапись. Но выступление было скомкано из-за технических сбоев, так что без изрядного редактирования не обойтись, а выставлять презентацию без поясняющего голоса нет смысла, так как в презентации только опорные точки.
В итоге, я решил еще перевести выступление в текст, тем более, что мысли в выступлении были, на мой взгляд, любопытными и полезными.
Вот что в итоге получилось:
Точка бифуркации: критическое состояние системы, при котором система становится неустойчивой относительно флуктуаций и возникает неопределённость: станет ли состояние системы хаотическим или она перейдёт на новый, более дифференцированный и высокий уровень упорядоченности. (Википедия)
Что у нас в ИТ в настоящем?
ИТ в критическом состоянии, так как:
- IT-вооруженность быстро растет: рост количества «вычислительных» устройств, их производительности и производительности сетей. Несколько устройств на каждого человека. Потенциально можем много.
- Медленное развитие программирование. Ничего принципиально нового за последние 20 лет. Фактически можем очень мало, долго и дорого. Плохо свистим и медленно летаем.
Есть два возможных варианта объяснения медленного развития программирования:
- Мы приближаемся к совершенству (ха-ха-ха)
- Мы идем не туда или идем галсами
Забавная и очень субъективная иллюстрация медленного развития: недавно я почти подряд перечитал «Описание языка Ярмо: Машино-независимое ядро» (В. И. Гололобов, Б. Г. Чеблаков, Г. Д. Чинин, 1980) и описание Go (GoLang, после 2009), и оба этих текста (разделенные 40 годами) дали примерно одинаковые поводы для раздумий по поводу Вир-2. С точки зрения количества идей эти языки эквивалентны!
Если мы поставим задачу улучшить скорость/качество разработки программ, то можем ли мы говорить сразу «за все» программирование? Думаю, что не можем, так как программирование оно очень разное. Попробуем выделить сегменты, чтобы потом искать разные способы улучшения для разных сегментов. Разделение на сегменты достаточно условное, и скорее всего не полное, но достаточное для моего дальнейшего рассуждения.
Сегменты программирования:
- Рыночное. Что важно: time to market, инновации, конкурентные преимущества
- Производственное. Что важно: надежность, предсказуемость, производительность
- Государственное: Что важно: безопасность (защищенность), отсутствие закладок, надежность, производительность
- Бытовое (об том ниже)
Можно выделить еще 5-й сегмент: обучающее, олимпиадное, детское программирование, но мне пока хватит четырех.
Замечу, что рыночное программирование находится в фокусе внимания, но существует только потому, что опирается на инфраструктуру – гаджеты, интернет, магистрали, компиляторы, SDK, …
Если построить иерархию уровней, то в основе лежит:
- Государственное (инфраструктура)
- Над ним – производственное (невозможно без государственного)
- Над ним – рыночное (невозможно без производственного)
- Над ним – бытовое (невозможно без рыночного)
В этой заметке я буду говорить только о бытовом программировании. Как я его понимаю?
- У каждого человека есть устройства (смартфон, планшет, ноутбук, десктоп, умный дом, …), который он использует для решения своих задач
- Каждый пользователь уже немного программирует, хотя может быть и не догадывается об этом (хотя бы настраивает свои устройства)
Бытовое программирование – это программирование человеком своих устройств для решения своих бытовых задач.
Бытовое программирование — это не программирование в привычном виде (не синтезирующее программирование в классификации А.П. Ершова). Это, скорее, сборка некого «супер-приложения» из сервисов и компонентов разных производителей, работающих на разных устройствах.
Для бытового программирование важны: легкость, наглядность, унифицированный способ работы с разными устройствами, отсутствие необходимости в длительном обучении и чтении руководств.
Рассмотрим бытовое программирование на примере. Но сначала одно замечание по поводу уровня IT-вооруженности: смартфоны, планшеты, ноутбуки, десктопы – это очевидная часть. Но кроме этого, в IT-вооруженность входят (на примере моей семьи):
- Два облачных сервера
- Яндекс.Диски
- Dropbox
- Яндекс почта для доменов
- И так далее
Вот эти не столь очевидные части тоже нельзя упускать из виду.
Теперь напрямую к бытовому программированию. Рассмотрим User story:
Ребенок идет домой из школы. Хочу:
- Получить сигнал, когда он вышел из школы
- Получить тревожный сигнал, если он вышел не вовремя
- Посмотреть маршрут движения на карте – онлайн или позже
- Получить сигнал, что он дошел до дома
Очевидное условие: у ребенка должно быть устройство с GSM/GPS (часы, браслет или телефон)
Что мне, как бытовому программисту нужно для решения этой задачи:
- Расписание уроков (доступное по сети)
- Гео-локатор в устройстве (доступный по сети)
- Карта с возможностью изображать маршрутом на моем устройстве (смартфон, планшет)
- Сервис для сохранения маршрута (облако)
- Сервис, связывающий все компоненты – некий «диспетчер»
Для решения задачи мне надо написать скрипты и расставить триггеры для запуска этих скриптов. Скрипты и триггеры в совокупности и составляют «супер-приложение», решающее задачу. Набросаю часть решения:
- Диспетчер отслеживает время завершения урока и подает сигнал тревоги, если через 10 минут после завершения урока ребенок не вышел из школы
- Устройство ребенка посылает сообщение диспетчеру при пересечении границы школы
- Получив сигнал от устройства (о пересечении границы), диспетчер проверяет время по расписанию уроков – подает сигнал тревоги (на мое устройство), если не вовремя, или сигнал выхода, если вовремя
- Диспетчер подключает поток координат к карте на моем устройстве для показа маршрута
- Диспетчер сохраняет маршрут в облаке
- …
Очевидна похожесть супер-приложения на программу на Scratch. Программа на Scratch также есть совокупность скриптов, срабатывающих по триггерам, например, триггер начала работы, триггер касания объектов на экране и т.д. Разница в том, что супер-приложение является распределенным.
Для того, чтобы бытовой программист (родитель) мог собирать супер-приложение ему нужно:
- Иметь возможность доступа к всем нужным сервисам или компонентам (и знать интерфейс)
- Среда разработки: визуальная (a la Scratch) или скриптовая или любая другая
- Возможность задать триггеры: подключить скрипты к событиям (от календаря, от устройства, от часов, …)
Почему я говорю о супер-приложении, а не об обычном рыночном (монолитном) приложении? Тем более, если говорить о конкретном сценарии, часы с примерно таким функционалом есть на рынке.
Вот некоторые причины:
- У каждого человека свои хотелки, в быту особенно
- В монолитном приложение невозможно предусмотреть все варианты и все возможные настройки: «а древо жизни пышно зеленеет».
- Для примера, как только ребенок вышел из школы, надо включить мультиварку, чтобы подогреть обед. И так далее…
Итого: я считаю, что единственный реальный способ добиться эффективности бытового программирование – это сборка приложения.
Приведу еще несколько примеров (бытовых хотелок), которые трудно или невозможно реализовать, так как сейчас нас окружают монолитные приложения:
- Яндекс-навигатор, работающий на карте Гугле (а вдруг кому-то больше нравится карта Гугла)
- Объединение личного и рабочего календаря с расписанием уроков и календарем жены – хочу видеть все сразу.
- Единый кабинет для оплаты сотовых операторов, интернета и сервисов. И пусть они конкурируют за меня.
- Там же (в кабинете), чтобы не меня забрасывали рекламой, а я сообщал о том, что именно мне сейчас надо. Пусть рекламируют то, что мне надо и когда надо. А за ненужную рекламу мне платят.
Предположим, мы решились двигаться в сторону бытового программирования? На что из уже существующего мы можем опереться для того, чтобы сделать возможным бытовое программирование. Перечислю то, что я вижу сразу:
- Unix way 2.0
- Software USB
- Конструкторы и модульные конструкции
Теперь подробнее.
1. Unix way 2.0
В сильно урезанном виде исходный Unix way это:
- Пишите программы, каждая из которых делает что-то одно и делает это хорошо.
- Пишите программы, которые бы работали вместе.
- Пишите программы, которые поддерживают текстовые потоки, поскольку это универсальный интерфейс
Это то, что нужно, только надо немного осовременить формулировки:
- Пишите компоненты (сервисы), каждая из которых делает что-то одно и делает это хорошо
- Пишите компоненты (сервисы), которые бы работали вместе (которые можно соединить)
- Пишите компоненты (сервисы), экспортирующие свой интерфейс
2. Software USB
Из описания USB на wiki:
Разработчики спецификации USB уделили внимание вопросу автоматического определения функциональности USB устройств, чтобы избавить пользователя от рутинных действий при подключении USB устройств.
Примерно то же самое нам и надо, только для всех компонент и сервисов, задействованных в бытовой программе:
Нам нужна возможность получить определение функциональности программных компонент и сервисов. Компонента должна экспортировать свой интерфейс в среду разработки бытового программирования.
Это может показаться сложным, но эта задача проще, чем та, которая решена в USB, так как использовать определения будет человек (бытовой программист), а не другое устройство. Достаточно стандартизовать запрос к компоненте и формат, в котором выдается интерфейс компоненты.
3. Конструкторы и модульные конструкции
Все больше конструкторов используются в мире:
- Конструктор бронетехники «Армата», модульные корабли
- Scratch и другие визуальные языки программирования
- Arduino, детские электронные конструкторы и конструкторы роботов
- Лего (с которого начинается сознательная деятельность ребенка)
- Конструкторы сайтов/лендингов/прототипов приложений
- …
И это, на мой взгляд, не спроста, причем, программирование явно отстает от общего тренда.
Подведем итоги. Если вдруг кто-то упадет с дуба решит сделать возможным бытовое программирование, ему нужно сделать:
- Единую информационная среду (эко-систему), объединяющую различные эко-системы (веб, С++, Java, ….)
- которая состоит из компонентов и сервисов,
- экспортирующих свой интерфейс
- Стандарт на компоненты/сервисы и их интерфейс
- Среду бытовой разработки
- И всеобщее обучение в духе: «Программирование – вторая грамотность» (А.П. Ершов, 1981 г.)
Замечу, что если движение в сторону бытового программирования развернется, то это повлияет на все сегменты программирования.
И в завершение анекдот в тему. Разговор в фото студии:
- Напечатайте мне фотографии с этой флешки
- 9 на 13 ?
- 117, а к чему вы это спросили?
Постоянная ссылка