Семантика в IT: почему нас бесят удобные программы

В центре всего стоит UX (User Experience).

Все говорят про UX.

UX – это святое.

UX – это цель.

UX – это путь.

Да и, в конце-то концов, UX – это то, за что мы платим (или не совсем) деньги и прощаем недостатки.

Но, если копнуть глубже, возникает вопрос: «А из чего, собственно, состоит UX?»
Ответы обычно примитивны: из интерфейса, удобства, скорости, привычности. Но, чувствуете, чего‑то не хватает? Есть системы с красивым интерфейсом, которые бесят. Есть и такие, «некрасивые», к которым возвращаешься снова и снова.

Небольшое лирическое отступление

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

1. Плохая: некоторая терминология может быть тебе непонятна.

2. Хорошая: будут моменты, которые я буду объяснять простым языком, чтобы поняла и непросветлённая аудитория. Большое спасибо, что уделили этому пункту свое драгоценное время.

Книга I: “Боже Мой, Боже Мой, для чего Ты Меня оставил?” *

Главное зло в мире информационных технологий (IT)

Тут могут начаться великие холивары (holy war(s)). Я предложу свою точку зрения, вокруг которой и будет крутиться основная идея статьи.

Итак, главное зло — дьявол в мелочах. А мелочь эта — грань между производством и продажей продукта. Я думаю, вы уже угадали этих «сатанистов».

МАРКЕТОЛОГИ

Да-да, эти, на первый взгляд, добродушные ребята. Они, может, сами по себе и отличные люди, но иногда творят такое, что стыдно всей индустрии. И я поясню свою точку зрения.

Теорема: хороший продукт не нуждается в маркетинге

В идеальном мире (который описывает философия BSD) всё просто:

1. Ты делаешь хороший продукт.

2. Люди им пользуются.

3. Они рассказывают другим.

4. Продукт становится популярным.

Это работает в закрытых экосистемах, где нет информационного шума:

• В маленьких городах лучший пекарь известен всем без рекламы.

• В университетской среде лучший профессор собирает аудиторию без плакатов.

• В Open Source лучший код привлекает разработчиков без маркетинга.

Но мы-то с вамиотлично понимаем, что эта теория, воспитанная на самом отборном гуманизме, работает не везде, часто вообще не работает. И вина этому — маркетинг. Лучше всего видно того, кто кричит.

Сценка в “Ведьмаке”

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

Так, описывая короткой сценой из Ведьмака, и работает маркетинг.

Отходя от метафор: что же не так?

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

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

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

Я не дурак, и так знаю

Я и не вешаю на вас, читатели, ярлыки. Многие из вас и так отлично понимают выше сказанные речи. Но тогда у меня ответный вопрос: почему же вы продолжаете использовать плохой продукт?

Не поймите меня неправильно. Я человек толерантный и мирный. За резкими словами скрывается простая идея «почему же мир полон плохих решений, которые набирают огромную популярность?». Ответ могу дать и я сам: инерция.

Инерция: что это, собственно, такое

Инерция – это свойство тел сохранять состояние покоя или движения, пока какая-нибудь внешняя сила не изменит этого состояния. Физика, 7 класс. В мире IT инерция проявляется везде: от чипа в вашем электрическом чайнике до компьютеров NASA. Особенно сильно инерция проявляется в пользовательском ПО.

Итак, попытаемся перевести физический термин в термин, понятый нашей индустрии.

Инерция в IT — это страшная сила

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

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

Из чего складывается инерция в IT:

1. Привычка (психологическая инерция). Человек — существо территориальное. Мы привыкаем к интерфейсу, к расположению кнопок, к поведению системы. Даже если система объективно плоха — переучиваться страшно. Мозг говорит: «Я знаю, как здесь закрыть окно, зачем мне лезть куда‑то ещё?»

2. Экосистема (техническая инерция). У тебя куплены программы, игры, плагины. Лежат документы в проприетарных форматах. Друзья и коллеги сидят в том же болоте. Выход из экосистемы грозит разрывом связей и потерей данных.

3. Страх неизвестности (когнитивная инерция). «А вдруг там будет хуже? А вдруг я не разберусь? А вдруг мои любимые программы не запустятся?» Этот страх парализует сильнее любых технических недостатков.

4. Социальное давление (стадная инерция). Быть как все — безопасно. Выбиваться — страшно и хлопотно.

5. Корпоративная политика (бюрократическая инерция). В компаниях это вообще цемент: “У нас всё настроено, есть регламенты, есть договоры с вендором. Менять? А кто будет переписывать документацию? А кто переучивать сотрудников? Начальник не поймёт”.

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

Как правило, главными противниками прогресса являются виды инерции, описанные в пунктах 2 и 5, а в личном использовании пользовательского ПО — все остальные (см. выше). Но не забываем: всё в нашем мире взаимосвязано. Спрос на продукт в пользовательском центре побуждает на создание новой экосистемы, что неизбежно ведет и к новой корпоративной политике. Это экономика и политика внимания.

Обобщение информации выше: причины популярности плохих продуктов

Инерция и маркетинг создают порочный неразрывный круг.

Как это работает:

Шаг 1. Маркетинг создает шум. Громкий зазывала привлекает внимание. Люди идут на крик (стадный инстинкт + ограниченность времени на выбор + иногда лень).

Шаг 2. Продукт покупают (или скачивают). Он может быть объективно плохим, но первая партия пользователей уже есть. Деньги получены, метрики горят.

Шаг 3. В продукте не видят изъянов. Изначально все «нормально», продуктом спокойно пользуются.

Шаг 4. Включается инерция. Люди уже потратили время на установку, настройку, привыкание. Даже если продукт глючит — переучиваться лень. «Потерплю, может, обновят».

Шаг 5. Экосистема разрастается. Выходить все сложнее: тут и настройки, и файлы, и знакомые, которые тоже там.

Шаг 6. Бюрократическая инерция. В компаниях это закрепляется: «У нас всё настроено, всех переучивать? Нет, будем мучиться дальше».

Шаг 7. Маркетинг получает новые бюджеты. «Продукт же покупают! Значит, он хорош! Давайте ещё громче кричать!»

Шаг 8. Круг замкнулся!

graph LR    M[Маркетинг] -->|шум| P[Покупка]    P --> I[Инерция]    I --> E[Экосистема]    E --> B[Бюрократия]    B -->|новые бюджеты| M

Плохой продукт живёт и процветает не потому, что он хорош, а потому что:

1. Маркетинг привлёк первых пользователей.

2. Инерция не дала им уйти.

3. Экосистема привязала их по рукам и ногам.

4. Бюрократия зацементировала это в корпорациях.

5. Маркетинг использует «успешные продажи» как доказательство качества.

О Люцифере…

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

Это монополия. А экономисты отлично знают, что только конкуренция рождает лучшие решения.

Однако, на счастье пользователю, все‑таки находится достойный противник «Люциферу». Вспоминаем ситуацию с GCC и Apple. Да‑да, часто именно корпорациям невыгодны монополии, тогда они начинают действовать. Еще один пример: политика Valve с Windows — Valve невыгодно, если Microsoft закроет свою экосистему. Так и родился SteamOS & Proton — а дальше начали подтягиваться и другие дистрибутивы, сами знаете.

Следствие

Хорошему продукту, чтобы прорваться, нужно быть не просто «хорошим», а прорывными. Настолько, чтобы:

• Перекричать маркетинговый шум (хотя у него нет на это бюджета).

• Преодолеть инерцию пользователей (а она огромна).

• Предложить миграцию из старой экосистемы (а это больно).

• Убедить бюрократов (а они боятся перемен).

Именно поэтому рынок ПО так часто напоминает кладбище хороших идей, которые не «выстрелили».

Книга II: «Рассудок не черпает свои законы из природы, а предписывает их ей» **

Возвращаясь к истокам

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

Итак, мы говорили про UX. Из чего же он все таки состоит?

Структура хорошего UI: официальная версия

Давайте узнаем привычным образом — Google в помощь. (Не будем пользоваться автоматическим поиском от Gemini — при всем моем уважении к AI, эту информацию я изучил сам).

Что мы получаем (без прелюдий):

1. Полезность и ценность (по сути, обязательная часть любого продукта)

2. Интуитивная навигация и структура (UI)

3. Удобство использования (размытое понятие)

4. Скорость работы (особенность реализации)

5. Адаптивность и доступность (особенность реализации)

6. UX‑тексты (без хорошей документации в этом мире тяжело)

7. Визуальная иерархия и эстетика (UI)

8. Персонализация (весьма размытое понятие)

Я подозреваю, что и вы понимаете, что чего‑то не хватает. Многое из выше приведенного списка сводится к UI и качеству реализации, некоторые понятия не имеют точного и равнозначного для всех определения. Поэтому, пока запишем данные, которые имеем:

UX = UI + Реализация + X

Где X — неизвестный элемент. Будем его искать.

Спору нет, если ищешь, то всегда что-нибудь найдешь, но совсем не обязательно то, что искал ***

Давайте попытаемся сформулировать этот X. Даю вам неограниченное время. Согласен, это очень тяжело. UI, реализация — что еще? Слово вертится на языке, но никак.

Давайте попробуем зайти с другой стороны — с реальных примеров. Возьму один из своего опыта: опыт работы с MacOS & CachyOS.

Для справки:

Кто не знает, CachyOS — дистрибутив Linux на базе Arch, заточенный на «выжимание» максимума из производительности твоего ПК (базируется, в основном, на процессоры x86-64-v3 & x86-64-v4, то есть на Desktop Edition, но на данный момент есть и Handled Edition). Пока многие пакеты в других дистрибутивах компилируются под флагом «‑O2», пакеты в CachyOS компилируются под «‑O3 ‑march=native». Часто используется и флаг «‑flto=thin». CachyOS базируется на особых патчах ядра Linux, сильно оптимизированных и заточенных под определенные задачи.

macOS — это операционная система для компьютеров Mac (MacBook, iMac, Mac mini, Mac Studio, Mac Pro), разработанная Apple. В отличие от большинства других ОС, она работает исключительно на фирменном «железе» Apple, что позволяет добиться идеальной оптимизации и бесшовной интеграции (так называемая «экосистема»). Базируется на сертифицированном ядре Darwin (XNU), которое ведёт свою родословную от BSD Unix (NextSTEP). Благодаря тесной связке с процессорами Apple Silicon (M1, M2, M3) и механизмам ROSETTA (для эмуляции ПО под Intel), macOS выжимает максимум из энергоэффективности и производительности в творческих задачах (видео, музыка, программирование). В то время как другие ОС тратят ресурсы на совместимость с «железом» от сотен вендоров, macOS заточена под отточенную работу конкретных чипов и жестов трекпада.

Сильно углубляться в детали не буду. Данной информации будет достаточно для примера ниже.

Для чистоты эксперимента…

Будем смотреть от лица СРЕДНЕГО ПРОДВИНУТОГО ПОЛЬЗОВАТЕЛЯ. Да, это весьма субъективный образ, соглашусь. Сформулируем для большей объективности ценности и умения нашего «подопытного».

Портрет “среднего продвинутого пользователя”

Кто он такой? Это не хардкорный линуксоид, собирающий ядро с флагами которых нет в природе. И не «пользователь‑чайник», для которого компьютер — это просто иконка «интернета».

Краткая таблица‑описание такого человека:

Сравнение: macOS vs CachyOS (фактологическая таблица)

Что мы видим из этой таблицы

У каждой системы — разные сильные стороны:

macOS даёт:

• Интеграцию с конкретным железом.

• Продуманный до мелочей интерфейс.

• Высокую энергоэффективность.

• Защиту пользователя от ошибок.

CachyOS даёт:

• Контроль над каждым аспектом системы.

• Выбор из множества реализаций (планировщики, файловые системы).

• Доступ к огромному количеству софта через один интерфейс.

• Полную прозрачность и возможность исправить что угодно.

graph TB    subgraph macOS        A1[Стабильность]        A2[Интеграция]        A3[Предсказуемость]    end    subgraph CachyOS        B1[Открытость]        B2[Контроль]        B3[Гибкость]    end

К чему пришли…

Я думаю, вам стало проще, мысли прояснились, но слово мы так и не вспомнили. Мы поняли одно — разные инструменты для разных целей. Однако и macOS, и CachyOS имеют большой спектр смежных областей, программирование как минимум. Почему же одни выбирают одно, другие — второе? Мы понимаем, что это решает тот самый X, но что это?

И я вам раскрою страшную тайну: люди не могут подумать о том, чему нет названия.

Книга III: “Если у вещи нет названия — её не существует” ****

О великой антиутопии

Я не фанат антиутопий, но это не отменяет того, что я могу подмечать в них гениальные мысли. И Джордж Оруэлл — настоящий гений, когда сформулировал мысль, трактовка которой и является названием «Книги III» моей статьи.

Справка:

В «1984» через упрощение языка (новояз) у людей отнимали возможность мыслить определённые мысли (да, тавтология, прошу простить). Нельзя назвать «свободу» — нельзя и подумать о ней.

Цитата из “1984”:

Сайм откусил еще от черного ломтя, наскоро прожевал и заговорил снова, — неужели вам непонятно, что задача новояза — сузить горизонты мысли? В конце концов мы сделаем мыслепреступление попросту невозможным — для него не останется слов. Каждое необходимое понятие будет выражаться одним-единственным словом, значение слова будет строго определено, а побочные значения упразднены и забыты.

(Мыслепреступление – термин из романа-антиутопии Джорджа Оруэлла «1984», означающий любое сомнение, инакомыслие или мысль, противоречащую идеологии правящей партии)

Возвращаясь к X:

Да-да-да, многие из вас догадались к чему я веду. Слова‑термина для X попросту нет (или оно есть, но настолько редко, что о нем знает меньшинство людей). И знаете, я решил, что пора с этим покончить:

Мы привыкли думать, что качество продукта измеряется скоростью, количеством фич или красотой интерфейса. Но почему тогда есть системы, которые при всех этих параметрах вызывают глубокое раздражение? А есть другие — с виду неказистые, но к ним тянет, как к старому другу. Потому что есть то, что лежит глубже фич и интерфейсов. Я решил дать этому имя и взять ответственность. Я называю X семантикой.

О семантике в проектировании продукта

Может, я был слишком резок, когда сказал, что имени тому нет. Оно есть, но проявляется в нашей индустрии исключительно в разработке ПО (и, со страхом замечаю, что этот термин начинают с каждым годом все меньше и меньше упоминать).

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

Смертельный пример: Граф социальных связей

Давайте представим, что мы пишем простую соц-сеть, где у пользователя есть друзья, и мы хотим, чтобы при удалении пользователя все ссылки на него тоже исчезали. Возьмём для этого 2 языка с совершенно разными семантиками: Rust и Java.

Версия на Java (классический подход с сборщиком мусора)

import java.util.ArrayList;
import java.util.List;
class User {    String name;    List<User> friends = new ArrayList<>();        User(String name) {        this.name = name;    }        void addFriend(User friend) {        friends.add(friend);        friend.friends.add(this); // Взаимная дружба    }
}
public class SocialNetwork {    public static void main(String[] args) {        User alice = new User("Alice");        User bob = new User("Bob");        User charlie = new User("Charlie");                alice.addFriend(bob);        alice.addFriend(charlie);        bob.addFriend(charlie);                // Алиса хочет удалиться из соцсети        alice = null; // Надеемся на сборщик мусора?                // Боб все еще дружит с Чарли        System.out.println(bob.friends.size()); // 2 (включая alice?)                // Сборщик мусора когда-нибудь приберется...        System.gc(); // "Пожалуйста, уберите мусор" (no гарантий)    }
}

Семантика Java:

1. Сборщик мусора (GC) — волшебная палочка, которая “когда-нибудь” найдет и удалит недостижимые объекты.

2. Циклические ссылки — не проблема для GC (он умный).

3. Null — допустимое значение для любой ссылки.

4. Время жизни объекта — не контролируется программистом явно.

Важно: В этом коде есть скрытая проблема — если мы обнулили alice, но на неё всё ещё ссылаются друзья (bob.friends содержит ссылку на Alice), то объект не будет удалён никогда! У нас утечка памяти, но GC не поможет — он видит, что объект достижим через Боба.

Пытаемся “переписать” на Rust (наивно)

Программист, мыслящий в Java-стиле, напишет что-то такое:

// ПЛОХОЙ КОД - НЕ СКОМПИЛИРУЕТСЯ!
struct User {    name: String,    friends: Vec<User>, // ОШИБКА: рекурсивный тип без указателя!
}
impl User {    fn new(name: &str) -> Self {        User {            name: name.to_string(),            friends: Vec::new(),        }    }        fn add_friend(&mut self, friend: User) { // ОШИБКА: берем владение!        self.friends.push(friend);    }
}
fn main() {    let alice = User::new("Alice");    let mut bob = User::new("Bob");        bob.add_friend(alice); // alice ПЕРЕЕЗЖАЕТ внутрь bob.friends    // println!("{}", alice.name); // ОШИБКА! alice больше не существует!        let charlie = User::new("Charlie");    bob.add_friend(charlie);
}

Компилятор Rust взорвется с кучей ошибок:

1. Ошибка 1: Vec<User> — невозможно, размер типа не известен на этапе компиляции (нужен указатель).

2. Ошибка 2: add_friend(self, friend: User) забирает владение friend, поэтому после добавления оригинала больше не существует.

3. Ошибка 3: Взаимная дружба (friend.friends.add(self)) невозможно, потому что у нас нет ссылки на self внутри friend.

Правильная Rust-версия (другая семантика)

В Rust нам придется переосмыслить архитектуру:

use std::cell::RefCell;
use std::rc::{Rc, Weak};
struct User {    name: String,    friends: RefCell<Vec<Weak<User>>>, // Слабые ссылки, чтобы избежать циклов
}
impl User {    fn new(name: &str) -> Rc<User> { // Возвращаем умный указатель        Rc::new(User {            name: name.to_string(),            friends: RefCell::new(Vec::new()),        })    }        fn add_friend(this: &Rc<User>, friend: &Rc<User>) {        // Добавляем слабую ссылку на друга        this.friends.borrow_mut().push(Rc::downgrade(friend));        // Добавляем слабую ссылку на себя в список друга        friend.friends.borrow_mut().push(Rc::downgrade(this));    }        fn friend_count(&self) -> usize {        // Считаем только "живых" друзей (слабая ссылка может указывать в никуда)        self.friends.borrow().iter()            .filter(|weak| weak.upgrade().is_some())            .count()    }
}
fn main() {    let alice = User::new("Alice");    let bob = User::new("Bob");    let charlie = User::new("Charlie");        User::add_friend(&alice, &bob);    User::add_friend(&alice, &charlie);    User::add_friend(&bob, &charlie);        println!("У Боба {} друзей", bob.friend_count()); // 2 (Alice и Charlie)        // Алиса удаляется...    drop(alice); // Явно уничтожаем объект        println!("У Боба {} друзей", bob.friend_count()); // 1 (только Charlie)
}

Ключевые семантические различия

1. Владение (Ownership)

• Java: Объектами владеет сборщик мусора. Вы просто имеете ссылки.

• Rust: У каждого объекта есть ровно один владелец. Присваивание = перемещение.

2. Циклические ссылки

• Java: Нормально, GC справится.

• Rust: Катастрофа! Циклы из Rc приведут к утечке памяти (никто не будет удален). Нужны Weak.

3. Время жизни

• Java: “Живи, пока на тебя кто-то ссылается”.

• Rust: “Живи ровно до закрывающей фигурной скобки, если не сказано иначе”.

4. Изменяемость

• Java: По умолчанию всё изменяемо.

• Rust: По умолчанию всё неизменяемо. Для изменения нужна изменяемая ссылка (или изменяемый указатель, но это не идиоматичный Rust).

5. Null

• Java: Базовый тип для всех ссылок (миллиардная ошибка).

• Rust: Нет null. Есть Option<T> — либо есть значение, либо нет.

Вывод из примера

Теперь, я уверен, многие точно понимают, почему фраза Боромира “нельзя просто так взять и переписать проект с одного языка программирования на другой” (это мы ещё не касались фреймворков (framework)!) верна как никогда.

Как семантика влияет на жизнь “обычного” пользователя

Некоторые скажут: “Ну, автор, молодец, пример показал, но я же не занимаюсь программированием, мне зачем это знать?” Почему этот пример важен для обычного человека? Потому что та же логика работает и на уровне ОС, на уровне любого софта. И ниже я, конечно, поясню.

Возвращение к истокам v2

Вернемся к формуле. Теперь можем записать её следующим образом:

UX = UI + Семантика + Реализация

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

Однако, и здесь мы не остановимся. Имя-то есть – семантика, но все до сих пор очень расплывчато. Разберем анатомию нашего X.

Анатомия семантики

Cемантика — не монолит, а сплав нескольких компонентов.

Семантика = Философия + Идеология + Архитектура + Парадигма + Эргономика

graph TD    A[Семантика] --> B[Философия]    A --> C[Идеология]    A --> D[Архитектура]    A --> E[Парадигма]    A --> F[Эргономика]

Пожалуйста, не путаем термины философия и идеология, парадигма и эргономика.

Книга IV: Тайна Мадридского Двора

Кто виноват?

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

Ответ, как ни странно, лежит в той же плоскости, что и вся наша статья.

1. Маркетинг не умеет продавать семантику

Вспомните нашу сценку с Ведьмаком. Маркетолог — тот самый зазывала в тумане. Что он может кричать?

• «У нашей системы красивый интерфейс!» — это продаётся.

• «У нашей системы молниеносная скорость!» — это продаётся.

• «У нашей системы искусственный интеллект!» — это продаётся (пока не разобрались).

• «У нашей системы правильная семантика!» — а это как? Это что, с чем едят?

Семантику нельзя показать на скриншоте. Её нельзя измерить в попугаях (мегагерцах, гигабайтах, FPS). Её можно только почувствовать после месяцев использования. А маркетинг работает на коротких дистанциях.

2. У семантики нет лобби

За красивым интерфейсом стоят дизайнеры. За скоростью — инженеры. За количеством фич — продакт-менеджеры. У всех есть свои голоса в компаниях, свои конференции, свои статьи на Хабре.

А кто стоит за семантику? Философы от программирования? Их не нанимают в production-команды.

Компаниям невыгодно, чтобы пользователи задумывались о семантике. Потому что семантика многих популярных продуктов — это «вы нам платите, а мы делаем с вами что хотим». Если пользователи начнут это осознавать — они могут задать неудобные вопросы.

3. Языковой барьер (в переносном смысле)

Мы ужеговорили про Оруэлла: если у вещи нет названия — её не существует. У семантики название есть, но оно «учёное». Оно пахнет университетской аудиторией, лингвистикой, семиотикой. Это не то слово, которое используют в подкастах для стартаперов.

В русскоязычном IT‑сообществе термин «семантика» прочно закрепился только в узкой области — «семантика программирования» (лингвисты в комментариях могут со мной не согласиться). В контексте пользовательского опыта его не используют. А значит, для 99% пользователей этой категории просто не существует.

4. Семантика — это про отношения, а не про свойства

Обратите внимание: в наших таблицах семантика всегда описывается через отношение:

• «система уважает пользователя»

• «система контролирует пользователя»

• «система относится к пользователю как к источнику дохода»

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

5. Семантика требует осознанности

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

Большинство людей не задают себе таких вопросов. Они просто пользуются тем, что поставили, и терпят. А когда терпеть становится невмоготу — идут к знакомому «компьютерщику» и просят переустановить Windows. Круг замыкается.

Так что же делать?

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

Я не питаю иллюзий, что после этой статьи все бросятся устанавливать Linux и анализировать семантику каждой программы. Но если хотя бы несколько человек в комментариях напишут: «Так вот почему меня бесил этот продукт, а я не мог объяснить!» — значит, статья написана не зря.

Потому что главное зло — не в маркетологах, не в инерции и даже не в монополиях. Главное зло — в отсутствии языка для описания того, что мы чувствуем.

А язык у нас теперь есть.

«Яхве, мир, который ты желал создать, действительно мог быть лишен страха. Однако в мире без страха смерти люди не могли бы столкнуться со страхом и искать надежду. Конечно, они могли бы продолжать идти вперед, просто живя, но это было бы совсем не похоже на то, чтобы идти вперед, побеждая свои собственные страхи. Вот почему мы даем акту движения вперед особое название. Мы называем его “мужеством”»

– Соскэ Айзен, тайтл “Bleach”

Пометки:

‘ *Отрывок из «Евангелие» по Марку

‘ ** Высказывание Эммануила Канта

‘ *** Джон Рональд Руэл Толкин «Хоббит, или Туда и обратно»

‘ **** Трактовка одной из идей антиутопии «1984» Дж. Орэлла, выдвинутая автором статьи