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

Предметы, субъекты, объекты

Начнём со схемы [1], хорошо известной в узких кругах (рис. 1).

В центре находится Человек [2], который является Субъектом деятельности. Слева от него Природа, которая является Предметом деятельности. Справа — Идея, которая является Объектом деятельности. Разница между Предметом и Объектом заключается в том, что первый можно лишь “ощущать”, а последний — лишь “мыслить”.

Перерисуем схему для упрощения дальнейшей модификации (рис. 2).

Задумка состоит в том, чтобы переложить озвученную схему на отдельно взятого человека (рис. 3).

Человек-с-большой-буквы состоит из отдельно взятых людей (или сознаний), каждому из которых своим уникальным образом даны его предметы, субъекты и объекты. По аналогии с тем, как предметы можно лишь “ощущать”, а объекты — лишь “мыслить”, с субъектами можно лишь “со-общаться”.

Трансляции, трансакции, трансформации

Теперь проложим мостик к содержанию предыдущего поста, в котором были даны наброски понятий трансляции, трансакции и трансформации (рис. 4).

Трансляции выполняются с предметами. Трансакции выполняются с субъектами. Трансформации выполняются с объектами. Причем любая трансформация влечёт за собой одну или несколько трансакций, которые, в свою очередь, влекут за собой одну или несколько трансляций.

Протоколы, узлы, объекты

Осталось в полученные схемы подставить понятия мира информационных технологий (рис. 5 и рис. 6).

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

Таким образом программирование суть моделирование трансляций, трансакций и трансформаций с протоколами, узлами и объектами соответственно.

[1]: Сергей Чернышёв. Черные лебеди роста. Семинар 2. http://chernyshev.ru/publications
[2]: Термины с заглавной буквы указывают на совокупность чего-либо в целом.

Процедуры, функции, типы, структуры, акторы, объекты, классы — это лишь малая часть понятий, которые так или иначе относятся к программированию. Через призму данных понятий обычно формируются представления о нём. Значит нам также потребуются понятия¹, которые позволят взглянуть на программирование иначе.

Трансляция

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

Трансакция

Трансакция суть двустороннее действие. Один отправляет, другой принимает. Один продаёт, другой покупает. Совершить одностороннюю трансакцию по определению невозможно. В качестве модели трансакции может выступать описание интерфейса в некотором языке программирования или, например, положение, регламентирующие поведение сторон в гражданском акте.

Трансформация

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

Программирование

Программа есть совокупность трансляций, трансакций и трансформаций.

Программирование суть моделирование трансляций, трансакций и трансформаций.

[1]: Пока только интуитивные представления о понятиях или, можно сказать, наброски понятий, которые навеяны работами Франка Фенинга (например, этой или этой), Александра Болдачёва (например, этой) и Андрея Смирнова (например, этой).

… In essence there are three “camps” in these discussions: the “Petri net camp”, the “Pi calculus” (or process algebra) camp, and the “Practitioners camp” (also known as the “No formalism camp”). This was the reason for starting the “Petri nets and Pi calculus for business processes” working group in June 2004. Two years later the debate is still ongoing and it seems unrealistic that consensus on a single language will be reached…

— W.M.P. van der Aalst et al. (2007). Business Process Management: Where Business Processes and Web Services Meet.

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

Объектно-ориентированное программирование

В мире ООП поведение представляется интерфейсами:

Выглядит довольно просто!

Алгебры процессов

В мире исчисления процессов поведение представляется сессионными типами:

Выглядит чуть сложнее. Из примечательного — очень “читабельная” рекурсивность определения.

Сети Петри

В мире сетей Петри поведение представляется т.н. открытыми сетями Петри²:

Основное отличие в графичности представления. Из примечательного — явные места, в которых находится процесс до/после взаимодействия с внешним миром. Именно в эти точки должен “подключиться” процесс, реализующий данное поведение:

Можно пойти ещё дальше и наполнить диаграмму смыслом, дав элементам подходящие имена:

1. В качестве подопытного поведения возьмём сессионный тип очереди, приведённый в одной из лекций (видео с привязкой ко времени) курса “Сессионно-типизированное конкурентное программирование”.
2. Открытые сети Петри (видео).

Инструментальный эффект

Появление нового инструмента порождает новую профессию.

Как это происходит?

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

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

Наивно полагать, что такие профессии гораздо проще освоить. Культурно оформляясь, новая профессия вбирает в себя смежные компетенции. В итоге объём компетенций остаётся примерно тем же, т.к. ограничивается лишь временем, которое человек может потратить на обучение.

Картинка “Software Engineer Evolution” пунктирно иллюстрирует этапы развития инструментов и соответствующих им профессий в сфере разработки софта.

Профессия разработчика стала по настоящему массовой благодаря появлению высокоуровневых языков программирования² (ВЯП). Следующий качественный скачок был связан с появлением инструментов web-разработки. Затем появились инструменты, облегчающие внедрение и эксплуатацию.

Каждый новый инструмент исключал целый пласт компетенций, которые больше не нужно было осваивать годами. Например, с появлением ВЯП отпала необходимость в изучении деталей устройства вычислительных машин, программирования/тестирования в машинных кодах и т.п. Примечательно, что адепты старых инструментов традиционно относятся к новым довольно скептически. Но, несмотря на это, новые инструменты из раза в раз обгоняли по массовости своих предшественников.

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

Что инструмент грядущий нам готовит

Прообразом нового поколения инструментов backend-разработки можно считать всевозможные BPMN-движки, инструменты кодогенерации на основе UML, сервера приложений, хранилища с поддержкой хранимых процедур. Ключевая идея — позволить разработчику думать исключительно о бизнес-логике и не думать обо всех остальных 100500 вещах, с которыми приходится сталкиваться при backend-разработке.

Современной реинкарнацией озвученных идей являются инструменты под собирательным названием Function as a Service (FaaS). FaaS — новое поколение domdev-инструментов, которые породят новую профессию под условным названием Domain Development Engineer (более коротко DomDev Engineer или просто DomDev).

Почему снова код, а не BPMN, визуальное программирование и т.п.?

До сих пор в основе каждого из инструментов лежал код. Почему в этот раз должно быть иначе? Миллионы строк доказывают способность кода бороться со сложностью. Код расширяется и поддерживается на протяжении десятилетий. А что насчет миллионов строк BPMN, которые расширяются и поддерживаются десятилетиями? Каждый новый инструмент приближает разработчиков к бизнесу. Ещё раз повторюсь — не условные аналитики обретают мощь разработчиков, а разработчики в очередной раз (sic!) глубже погружаются в бизнес. В обратную сторону, к сожалению, не работает. Ставить на codeless-инструменты очень рискованно, т.к. тупо не было ещё прецедентов. Рано или поздно они не выдерживают столкновения с естественной сложностью человеческой деятельности.

Набор юного домдева

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

Что он умеет?

Он разбирается в сложившейся предметной области и способен её расширять, выявляя новые абстракции и воплощая их в коде. Он способен писать, отлаживать, тестировать, объяснять, внедрять и поддерживать свой код. Способен читать и локализовывать ошибки в чужом коде.

Его не волнует оптимальность алгоритмов и структур данных. Ему не нужно думать о парсинге данных, кодировке данных, протоколах обмена данными, многопоточности, конкуренции, обработке технических ошибок, масштабировании, деградации, переповторах и т.д. и т.п.

Кто может им стать?

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

Какие у него инструменты?

DomDev Engine — движок для исполнения domdev-кода. По сути аналог виртуальной машины³.

DomDev Kit — набор готовых абстракций и операций над ними в рамках определённой предметной области. С возможностью безопасного расширения существующих абстракций и их композиции для создания новых в случае необходимости.

DomDev IDE — интегрированная среда разработки с автоматическими подсказками, рефакторингом и прочими плюшками.

Development eXperience — ключевой фактор для каждого из озвученных инструментов.

Заключение

На наших глазах формируется⁴ следующее поколение инструментов backend-разработки. Как следствие возникает новая массовая профессия — DomDev Engineer. Представители данной профессии будут ещё более ценными (во всех смыслах), т.к. будут гораздо ближе к бизнесу. В свою очередь, бизнес, инвестирующий в domdev-инструменты и людей, с высокой вероятностью получит стратегическое преимущество как минимум на ближайшее десятилетие.

[1]: Производительность используется как синоним полезности.

[2]: The History of FORTRAN https://www.obliquity.com/computer/fortran/history.html

[3]: По мнению ведущего разработчика Uber Cadence:

Cadence allows to write workflows as code. Think of it as a virtual machine for OO code that makes that code fully fault tolerant to process failures. As it is code it can be used to implement any business logic.

[4]: Amazon, Google, Microsoft и IBM давно занимаются этим. Экосистема Kubernetes семимильными шагами движется в этом направлении. Стремительно набирают популярность OSS-движки, например, Uber Cadence. Рискну предположить, что активно разрабатываются in-house решения. Информация об этом частенько просачивается. Например, осенью 2018 был доклад от Alibaba Group. Личный опыт автора, как разработчика in-house domdev-движка, также свидетельствует об этом.

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

Почему по рынку¹? Во-первых, зарплата в привязке к наносимой пользе — это более продвинутый подход к зарплатообразованию, который заслуживает отдельной статьи. Во-вторых, зарплата выше или ниже рынка, на мой взгляд, закладывает определённые риски, которые рано или поздно выливаются в затраты на поиск и/или подготовку новых работников.

Предлагаемый подход позволяет получить оценку рыночной зарплаты и далее мониторить её на постоянной основе. Область применения — технические позиции с высоким спросом на рынке, т.к обязательное условие — наличие вакансий с указанием вилки.

Позиция

Для простоты будем считать, что текущая позиция работника складывается из трёх составляющих:

1. Роли, которые работник способен исполнять с надлежащим качеством.
2. Уровень, определяющий сложность задач, которые работник способен решать самостоятельно (в той или иной роли).
3. Ключевые компетенции, которыми владеет работник.

Роли
- Аналитик
- Архитектор
- Разработчик
- Тестировщик
- Автоматизатор/DevOps
- Внедренец
- Саппортёр

Уровни
- Ведущий/Lead
- Старший/Senior
- Middle
- Младший/Junior

Ключевые компетенции
- Владение определённой предметной областью (телеком, банковское дело, всевозможные стандарты и т.д.)
- Владение определённой практикой (UX, frontend, backend и т.д.)
- Владение определённым инструментом (Java, Python, JS, Docker, Ansible и т.д.)

Алгоритм

1. Определяем самую дорогую позицию, в которой чувствуем себя уверенно.
2. Делаем выборку на HH
3. Подсчитываем.
4. Подписываемся.
5. Мониторим.

Опции для выборки
- Ключевые слова = (<роль> OR<alias>) AND (<уровень> OR <alias>) AND (<компетенция> OR <alias>)
- Чекбокс “В названии вакансии” = True
- Регион = <Домашний>
- Чекбокс “Скрыть вакансии без указания зарплаты” = True
- Тип занятости = Полная занятость
- График работы = Полный день
- Сортировка = По убыванию зарплат

Все остальное можно оставить по умолчанию.

Подсчёт

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

Подписка

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

Пример

Допустим вы “Lead Java Developer”, которому удаётся также совмещать ещё одну или несколько ролей. Работаете территориально в Санкт-Петербурге.

Выборка
- Ключевые слова = (разработчик OR программист OR developer OR engineer) AND (ведущий OR lead) AND java
- Регион = Санкт-Петербург

Подсчет

Предлагаю читателю потренироваться самостоятельно 😉

Полезные ссылки

• Software Engineer Title Ladder
• Software Engineering Job Titles Explained

[1]: Под “рынком” понимается некоторый диапазон/вилка, а не одно единственное число (будь то среднее, медиана или любой другой процентиль).

Перед вами очередная попытка осмыслить статью Харпера The Holy Trinity.

Ключевая идея статьи в том, что логика, языки и категории суть ипостаси вычисления. В рамках каждой из ипостасей существует фундаментальная концепция (fundamental concept). В логике — логическое следствие (entailment). В языках — суждение о типизации (typing judgment). В категориях — отображение¹ (mapping).

И, вроде бы, всё хорошо, но что-то смущает… В первой части статьи утверждается, что высказывание соответствует типу и структуре, а доказательство — программе и отображению. Но во второй части логическое следствие сопоставляется с суждением о типизации и… отображением! Таким образом с одной стороны может показаться, что отображение соответствует логическому следствию и суждению о типизации, а с другой — доказательству и программе. Попытаемся объяснить идею Харпера в терминах понятных обычному программному инженеру.

Суждение

Назовём форму, описывающую фундаментальную концепцию, суждением (judgment). Всё, что слева от символа турникета (turnstile) называется контекстом (context). Контекст — это всё, что есть у агента (опыт, знания, ресурсы, способности и т.д. и т.п.). Таким образом любое суждение всегда фиксируется в контексте некоторого агента.

Логика

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

Языки

В языках фундаментальной концепцией является суждение о типизации, которое фиксирует выразимость² (expressibility) некоторого типа (type). Тут уже нотация гораздо богаче и позволяет увидеть всё в полном объёме. В оригинальной статье нет понятия аналогичного выразимости, но оно необходимо для полноценного соответствия между ипостасями.

Категории

В категориях фундаментальной концепцией является суждение об отображении, которое фиксирует отобразимость³ (mappability) некоторой структуры (structure). В оригинальной статье нет понятий аналогичных суждению об отображении и отобразимости, но они необходимы для полноценного соответствия между ипостасями.

Соответствия

Таким образом ипостаси соотносятся⁴ следующим образом:

UPD1:

1. Более чётко сформулирована проблема исходной статьи.
2. Доказуемость заменена на осуществимость.

TODO:

1. Добавить про вычислимость.

[1]: Далее в статье вводится понятие суждения об отображении.

[2]: Считаем, что выразимость и программируемость — синонимы. То же самое относится к выражениям и программам.

[3]: Считаем, что отображение и морфизм — синонимы. Понятие отобразимости чуть лучше передает следующий смысл:

A central theme in category theory is the study of structures and structure-preserving maps. A map f : X → Y is a kind of observation of object X via a specified relationship it has with another object, Y. For example, think of X as the subject of an experiment and Y as a meter connected to X, which allows us to extract certain features of X by looking at the reaction of Y.

Brendan Fong, David I Spivak https://arxiv.org/abs/1803.05316

[4]: Подробнее о соотношении https://ncatlab.org/nlab/show/computational+trinitarianism

Совершает все подвиги до того, как в них явится нужда.

Делает то, что нужно, а не то, что говорят.

Создаёт новое, в точности копируя старое.

Подвергает сомнению, ни секунды не сомневаясь.

Снимает все ярлыки до того, как их повесят.

Отрицает авторитеты, строго следуя их заветам.

Движется в верном направлении, ошибаясь на каждом шагу.

Неуязвим, т.к. сам же смебётся¹ над собой.

Убежден, что дело важнее разговоров, а разговоры — основа любого дела.

Впереди всех, опережая лишь самого медленного из них.

Качественно улучшает исчезающе малыми шагами, абсолютно ничего не меняя.

Настоящий Йорег суть Инженер!

[1] Если исправить опечатку, то некоторые смыслы будут утеряны. Настоящий Йорег никогда не ломает обратную совместимость!

Отрывок из дорожной карты одного из самых амбициозных технологических проектов современности! А именно его завершающий этап:

The rift between the web and the OS is finally healed. The OS and local programs and WebApps merge. They are not just indistinguishable, they are the same thing. “Installing” becomes pinning applications to the local computer. “Saving” things locally is also just pinning. The browser and the OS are no longer distinguishable. The entire OS data itself is modelled on top of IPLD, and the internal FileSystem is IPFS (or something on top, like unixfs). The OS and programs can manipulate IPLD data structures natively. The entire state of the OS itself can be represented and stored as IPLD. The OS can be frozen or snapshotted, and then resumed. A computer boots from the same OS hash, drastically reducing attack surface.

Если взглянуть чуть шире (хотя куда уж ещё), то могло бы получиться примерно следующее…

Всепланетная система деятельности

Похуизм, наебалово и кабала практически побеждены. Жизнь и работа сливаются воедино. Они не просто неразличимы, они суть одно и то же. Люди просто живут в рамках пространства совместной деятельности. Любой человек в любой момент времени может начать новую деятельность или подключиться к уже существующей. При этом никто ничего не теряет! Новая деятельность гладко вытесняет устаревшую, т.к. это в интересах всех и каждого. Результаты деятельности вменяются всем сопричастным пропорционально вложенным усилиям. Политика, образование, здравоохранение и прочая “социалка” не исключение. Человечество начинает поступательно снимать свои издержки и оживает!

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

Опциональные типы (Optional, Maybe, etc…) отбраковываются аргументом про их обратную несовместимость при, казалось бы, безобидном ослаблении требований на входе или усилении гарантий на выходе.

Произведения (Classes, Records, etc…) объявляются местоориентированными (place-oriented) типами. После такого любой уважающий себя разработчик сто раз подумает, прежде чем начать их использовать.

Вместо столь милого сердцу произведения Рич (как обычно) предлагает использовать отображение (map). По его словам отображения более просты и фундаментальны, чем произведения. Для них, например, не требуется привлекать понятия места и функции.

Далее Рич вводит понятия схемы (schema) и выборки (select). Схема описывает потенциальную форму данных. Схема есть некий шаблон, которому данные могут соответствовать частично или полностью. В рамках самой схемы уровень соответствия никак не регламентируется. Выборка, в свою очередь, позволяет задать степень соответствия данных схеме в рамках того или иного контекста. У разных операций для одной и той же схемы обязательными или опциональными могут быть абсолютно разные “поля”.

Существует ли хоть один язык программирования, система типов которого позволяла бы накладывать ограничения на типы в зависимости от контекста их использования?

Идеальный мир

Во многих языках программирования существует мир чистых (pure) функций и мир операций с побочными эффектами (side effects).

Например, изменение некоторого мутабельного состояния считается побочным эффектом. Такие операции часто называют update-in-place, и они всегда имеют сигнатуру, которая вообще ни о чем не говорит. Например unit -> unit, IO() -> IO() или даже void -> void.

Ну очевидно же, что операций с побочными эффектами должно быть как можно меньше, а чистых функций — как можно больше.

Мир побочных эффектов

Но! В каждый язык (в т.ч. функциональные) встроена как минимум одна update-in-place операция. И это подстановка (substitution) значений на место переменных.

При каждом вызове (application) инстанцируется тело функции, и затем аргументы подставляются на место переменных.

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

Ничего не напоминает?

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

Существуют и другие примеры функционального update-in-place:

1. Внедрение зависимостей в иммутабельные объекты
2. Конструирование иммутабельных структур данных
3. Вставка новых элементов в структуры данных

Многоразовая подстановка

Операции с побочными эффектами подозрительно походят на операции подстановки. Разница лишь в том, что подстановка — одноразовая операция. После её выполнения информация о местах “стирается”, и выполнить подстановку повторно уже нельзя.

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