В современном мире технологии проникают во все сферы жизни, обретая статус не просто инструментов, а полноценной среды, в которой мы постоянно живем и работаем. Когда мы используем программы, языки программирования или системы, мы часто не замечаем, что находимся в некой «коробке» — ограниченном пространстве возможностей, диктующем правила взаимодействия с данными и программным обеспечением. Концепция «вы находитесь в коробке» описывает эту парадоксальную ситуацию, когда свобода действий кажется безграничной, но на самом деле ограничена внутренними рамками отдельных программных решений и связанных с ними экосистем. Одним из фундаментальных утверждений этой идеи является то, что программы по своей природе стремятся покрыть всё больше сфер: они «расползаются», чтобы уметь выполнять всевозможные задачи вплоть до чтения почты — метафора, ставшая известной благодаря закону Зевински, который гласит, что программы будут разрастаться, пока не смогут выполнять задачу чтения почты, а если не могут — их заменят теми, кто сможет. Это заставляет нас задуматься о природе роста программного обеспечения и о том, как подобный рост ведёт к сложностям, излишней универсальности и неизбежному застою.
Интуитивно кажется, что универсальные инструменты — это хорошо. Однако почти все современные программы и языки программирования одновременно «мыслят слишком мелко и слишком масштабно». Они обещают пользователю делать всё, но с оговоркой, что нужно отказаться от других инструментов и осесть на одном «универсальном локомотиве». На практике это создаёт зависимость — из-за высоких затрат на смену инструмента пользователь склонен оставаться с первым выбранным решением и пробовать использовать его для целей, на которые он изначально не предназначался. В результате инструменты разрастаются, накапливают сотни функций и постепенно перестают развиваться качественно, погружаясь в застой.
Можно сказать, что внутри программных экосистем воспроизводится экономический цикл бума и спада. Чтобы выйти из этой замкнутой коробки, существуют два ключевых подхода. Первый — сознательное ограничение роста инструментов, то есть запрет на то, чтобы программы становились слишком громоздкими и многофункциональными. Однако этот метод крайне непопулярен — никто не хочет искусственно сдерживать развитие и расширение возможностей любимых и востребованных инструментов. Второй путь — снижение затрат на переключение между инструментами.
Если способы интеграции и взаимодействия между различными программами будут проще, гибче и быстрее, не возникнет необходимости в едином универсальном решении. Вместо этого можно будет создавать системы из множества узкоспециализированных, но совместимых между собой компонентов, которые легко комбинируются под текущие задачи. Низкие издержки переключения помогут избежать ситуаций, когда пользователи «застревают» в выборке одного инструмента, пусть даже не идеально подходящего. Одним из самых простых способов снизить такие издержки является обратная совместимость. Если новые инструменты сохраняют или хотя бы близки к синтаксису и функционалу предыдущих, то обучаться и переходить становится гораздо легче.
Примером может служить ripgrep, который берёт почти весь синтаксис от традиционного GNU grep, или языки программирования, наследующие синтаксис скобок от C и его современников. Подобный подход снижает трение и способствует более свободному движению между инструментами. Стандартизация — ещё один мощный механизм для облегчения взаимодействия. Наличие общих протоколов и спецификаций, таких как сетевые стандарты или форматы языка (например, спецификация C), обеспечивает работу разнообразных компиляторов и программных инструментов с единой базой. Однако стандарты не всегда решают проблему в полной мере, потому что инструмент должен желать или быть вынужденным поддерживать совместимость.
Например, CUDA, проприетарный фреймворк для GPU, использует закрытый бинарный формат, что вынуждает разработчиков прибегать к сложному обратному проектированию для модификации. До появления более эффективных методов коммуникации между программами активно использовались так называемые Foreign Function Interfaces (FFI), позволяющие одной программе вызывать функции другой, построенной на другом языке. Несмотря на теоретическую привлекательность, FFI сопряжены с множеством проблем — начиная от необходимости базового соглашения на уровне C ABI, заканчивая сложностями с несовместимыми средами выполнения, разницей в типах и необходимостью написания множества обвязок для каждого языка. Сегодня интерес вызывают решения на основе WebAssembly и его компонентной модели, которые обещают упростить межязыковое взаимодействие. Композиция инструментов через межпроцессное взаимодействие (IPC) — традиционный и мощный способ совмещения разных программ в единую рабочую цепочку.
В Unix-подобных системах для этого используется оболочка (shell), которая позволяет выстраивать конвейеры (пайпы) из отдельных утилит. Наиболее ярким примером является одноразовое скриптование, когда через серию команд можно выполнить комплексный анализ, обработку и фильтрацию данных, не прибегая к серьёзному программированию. IPC открывает свободу взаимодействия между приложениями, написанными на разных языках, с разными ABI и интерфейсами. Однако при этом интерфейс взаимодействия обычно неструктурирован — это просто поток сырых байт без строгой схемы. Такое ограничение ведёт к проблемам: при работе с интерактивными программами или сложными форматами данных могут возникать затруднения.
Новые поколения оболочек, такие как PowerShell и Nushell, пытаются это исправить, введя поддержку структурированных данных и системы типов на уровне конвейера команд. PowerShell в частности предоставляет мощные средства для обработки объектов и типизированных данных, что является значительным шагом вперёд в сравнении с традиционным shell. Тем не менее, такая архитектура не решает все проблемы. Нет совместимости между разными shell-средами, отсутствует стандартный протокол для описания выходных данных программ, а также нет гарантий стабильности формата вывода между версиями. Попытки решить эти проблемы наталкиваются на ограничения внутри систем ввода-вывода: недоступность отдельных каналов связи для передачи схем, отсутствие стандартизованного механизма самоописания и взаимодействия.
Для передачи структурированных, самоописанных данных имеет смысл использовать удалённые вызовы процедур (RPC). RPC обеспечивает «in-band» коммуникацию — программы договариваются о формате данных и интерфейсах внутри самого потока взаимодействия. Высокая совместимость, возможность обеспечения обратной и прямой совместимости, совместное использование типов и API между языками делают данный подход привлекательным. Однако внедрение RPC требует серьёзных усилий: программу необходимо адаптировать к рамкам RPC-фреймворка, иногда модифицировать внутреннее представление данных ради производительности, что не всегда возможно без потерь. В конечном счёте все эти сложности связаны с тем, что программы являются, по сути, тюрьмами для данных и пользователей.
Ваши данные и действия физически находятся внутри ограниченного контейнера — «коробки» программного обеспечения, которая диктует рамки возможности взаимодействия. Вне рамок программы данные нельзя эффективно использовать без значительных усилий разработчика. Даже когда выходные данные отправляются наружу, они должны пройти через узкие дверные проёмы ввода-вывода, причем, если данные не соответствуют протоколам, они теряются или игнорируются. Некоторые языки пытаются расширить размер своей «коробки». Языки, работающие на JVM, такие как Java, Kotlin и Clojure, демонстрируют сравнительно лёгкую интеграцию между собой.
Однако JVM — тоже коробка, и взаимодействие с языками вне неё значительно затруднено. Другие, например Lisp и особенно Racket, снижают затраты на расширение самой коробки, позволяя создавать новые языки и инструменты внутри этой среды. Но при этом проникновение внешних программ в эту коробку остаётся проблемой. Инструменты с интересными и уникальными возможностями тоже по сути остаются в коробке. Smalltalk, Pluto.
jl или Rustc предоставляют замечательные функции внутри своих экосистем, но каждая такая функция — часть собственной ограниченной среды. Часто же проекты и экосистемы вовсе не пытаются уйти из коробки: они, напротив, создают искусственные замки, усиливая зависимость пользователей и удерживая их в рамках собственных технологий. Такая практическая форма vendor lock-in — скрытая зависимость от авторов программ — наблюдается повсеместно. Таким образом, каждый пользователь и разработчик находится в постоянном положении зависимости и ограничений, навязанных «коробкой» программ. Это вызывает глубокие вопросы о направленности развития программного обеспечения и необходимости переосмысления базовых архитектур и принципов взаимодействия.
В ближайших обсуждениях предстоит рассмотреть, какие концептуальные инновации и практические решения могут помочь нам «вырваться» из этой коробки, созданной технологиями, в сторону более свободных, открытых и гибких вычислительных систем, способных эволюционировать и менять форму вместе с потребностями пользователей.
