В последнюю неделю у меня из головы не выходит один вопрос...

Давайте подумаем, в чём состоит цель инженера-программиста? После некоторых рассуждений я пришёл к следующим формулировкам:

Цель: Создавать и развивать способность цифровых систем решать задачи пользователей

Единица измерения цели: решённая задача пользователя

Фокус: быстро, качественно и в полном объёме решать задачи пользователей через развитие цифровых систем

Но помогают ли нам в этом наши технологии? Мы создаём языки, а потом создаём для них Framework'и, потому что в языке не хватает функциональности. Мы спорим об архитектуре. Мы пишем тесты и выпрашиваем время на рефакторинг.

Вы заметили, что в этих утверждениях нигде нет фразы "решать задачи пользователей"?

Так вот тот вопрос, который не даёт мне покоя:

Возможно ли создать язык программирования, для которого не нужны Framework'и, в котором не нужно выбирать архитектуру, и в котором не нужно писать тесты или рефакторить код?

Для себя я определил архитектуру так:

Архитектура программной системы - это набор ограничений, которые формируют и направляют реализацию системы в сторону максимизации её ценности

• Это набор ограничений: архитектура задаёт рамки/правила по которым должна строиться система

• Архитектура формирует и направляет реализацию: у разработчиков должна быть свобода в реализации, но архитектура задаёт для них ограничения

• Архитектура максимизирует ценность: ограничения поставлены так, чтобы вписываясь в них система принесла больше ценности. Именно архитектура определяет: какими паттернами реализовывать бизнес-логику, как связываться со сторонними сервисами, из каких категорий будет состоять программный код

И я придумал для этого метафору. Представьте, что мы строим дом. Тогда:

Системный архитектор:
Нарисует чертежи всего дома (фасада, этажей). Задаст форму квартирам: сколько в квартире комнат, куда проведены трубы и электричество. Исходя из этого, сан-узел можно будет поставить только в одной комнате (куда проведены вода и канализация), а кухню только в другой (куда проведена вода и газ). Системный архитектор наложил на весь дом и на каждую квартиру верхне-уровневые ограничения: структурные (сколько в каждой квартире комнат, где сан-узел, где кухня, а где жилые комнаты) и поведенческие (это жилое помещение, а не склад или магазин). Но в какой комнате будет детская, а в какой рабочий кабинет - решать не ему.

Системный дизайнер:
Он как дизайнер интерьеров. Определяет назначение каждой комнаты, учитывая уже наложенные архитектурные ограничения. Где будет гостиная, где спальня, где рабочий кабинет и т.п. И расставляет мебель (структурные ограничения), руководствуясь назначением каждой комнаты (поведенческие ограничения). И всё это так, чтобы живущим в квартире людям было удобно.

Программист:
Это рабочий, который по чертежам дизайнера положит паркет, подключит фурнитуру и соберёт мебель.

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

• Системный архитектор - senior (опытный программист, способный спроектировать кластер контейнеров)

• Системный дизайнер - middle (программист, способный спроектировать один контейнер)

• Программист - junior (любой программист, способный работать внутри контейнера по готовым ограничениям)

Последние месяцы изучаю функциональное программирование. И я не понимаю, почему любой доклад по ФП начинается с того, что докладчик пол часа рассказывает, почему не стоит использовать ООП. И при этом приводит в пример структурный код!

Если в языке есть управляющие конструкции, по типу if/else, то это НЕ объектно-ориентированный язык. И не важно какие свойства ему приписываются в Wikipedia. В ООП работа с булевыми выражениями выглядит так:

result = request->validate(rules);
result
    ->ifTrue(useCase->execute())
    ->ifFalse(response->unprocessable())

Вот вам и посылка сообщений, и "Tell, don't ask".

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

Вы выстрелите себе в ногу, если попытаетесь смоделировать развёртку docker-контейнеров или взаимодействие между web-компонентами с помощью ФП. И вам будет так же трудно обработать данные запроса на сервере с помощью ООП. Все парадигмы имеют свои преимущества и недостатки, и используются как инструменты для разных задач.

Слушая доклады по ФП, лично я хотел бы слышать что-то типа: "Смотрите, мы сейчас будем заниматься обработкой данных. У ФП есть для этого отличные механизмы, и работают они вот так..."

Призываю всех улучшать своё понимание парадигм и использовать их по назначению. (b.t.w. нативный "Railway programming" в ФП - это круто)