Прекрасный язык, задушенный корпорацией

Swift был прекрасным языком, но он далеко отошел от своего первоначального видения.

Очень далеко.

В этой статье мы рассмотрим различные виды управления современными языками программирования. Я объясню, в чем именно заключается уникальность диктаторской структуры Swift, и продемонстрирую вам, насколько плохи стали дела.

Но сначала проведем краткий экскурс по истории Swift.

Краткая история Swift

Swift был сайд-проектом Криса Латтнера (Chris Lattner), создателя LLVM и старшего директора по разработке инструментов для разработчиков в Apple. В начале 2010-х годов в свое свободное время он закладывал основы языка, который мы сегодня знаем и любим.

Высшее руководство Apple было до отказа набито рукопожатными с Джобсом выходцами из NeXT, построившими свою карьеру на Objective-C. Потребовалось очень много внутреннего политиканства, чтобы получить зеленый свет на Swift.

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

Каково было видение Латтнера?

Простые решения, которые компонуются (simple things that compose). Поэтапное раскрытие (progressive disclosure). Есть только один способ решить задачу (one way to do things).

В следующем, 2015 году, Латтнер добился немыслимого: убедил вторую по секретности компанию в мире открыть исходный код Swift.

Язык Swift с открытым исходным кодом развивался в течение многих лет. За ним стояли сразу три племени, успешно контролируя друг друга:

• Сам Лэттнер, который занимается реализацией своего видения и сдерживанием технического долга компании.

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

• Apple, гигант, который платит зарплату рабочей группе Swift, и который неуклонно стремится к прибыли.

В 2017 году Крис отчалил возиться с искусственным интеллектом. Приятели Тима Кука по MBA начали запускать в Swift свои щупальца, направляя его к следующему этапу его жизни.

«Swift превратился в гигантскую, сверхсложную кучу специальных случаев, специального синтаксиса, специальных решений...».

— Крис Латтнер, 2024

В 2024 году нашему взгляду предстает вышеупомянутый список из 217 ключевых слов. Они не являются ни простыми, ни хорошо сочетаемыми.

Без твердой руки Латтнера Swift оказался в неудобном положении между двумя враждующими кланами: сообществом разработчиков ПО с открытым исходным кодом™ и Apple Inc.

У обоих есть свои стимулы и свои недостатки, но вы можете догадаться, кто имеет большее влияние.

«Apple Inc. является руководителем проекта и выступает в роли арбитра. Руководитель проекта производит назначения на руководящие должности».

— Swift.org

Как управлять языком программирования

Каждый язык программирования кем-то разрабатывается и поддерживается. Это может быть один человек, отдел в компании или большое сообщество независимых разработчиков.

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

Давайте рассмотрим модели управления, используемые в самых популярных и успешных языках.

Python: Великодушный пожизненный диктатор

Python был создан Гвидо ван Россумом (Guido van Rossum) в 1990 году (и назван в честь Монти Пайтон). Гвидо был BDFL (великодушным пожизненным диктатором). Этот титул чертовски крут (и по сути является эвфемизмом для «ведущего сопровождающего»). В конце концов, жаркие споры о выражениях присваивания привели к тому, что Гвидо покинул свой пост в 2018 году.

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

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

— Гвидо ван Россум

Rust: Открытый исходный код, управляемый сообществом

Изначально Rust был личным проектом Грейдона Хоара (Graydon Hoare), который был принят компанией Mozilla, его работодателем, и в итоге стал поддерживаться силами Rust Foundation — некоммерческой организации, созданной AWS, Huawei, Google, Microsoft и Mozilla.

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

Хоть это все может выглядеть как какая-нибудь утопия, сообщество Rust, как и все опенсорсные сообщества, не лишено драматизма.

Каждое важное решение в Rust начинается с рабочего предложения (RFC – Request for Comments). К обсуждению предложения приглашаются все желающие, что в итоге должно привести к общему согласию или компромиссу. Хоть такие обсуждения иногда и получаются очень изнурительными, они являются секретным ингредиентом качества Rust.

— Rust Governance

Kotlin: Открытый исходный код, поддерживаемый корпорацией

Kotlin был создан JetBrains в 2011 году — компанией специализирующейся на IDE, которая надеялась таким образом продать больше копий IntelliJ и наладить перекрестные продажи других своих инструментов для разработчиков. В 2017 году Google объявила о поддержке Kotlin для Android.

Kotlin управляется Kotlin Foundation, созданным совместно Google и JetBrains. Совет директоров фонда назначает ведущего дизайнера языка, который, по сути, является высокопоставленным инженером JetBrains. Члены сообщества могут представить KEEP на рассмотрение сообществом, а разработчики могут тестировать экспериментальные API до их окончательной доработки.

«Дизайн языка высечен из камня, но этот камень достаточно мягок, что, приложив некоторые усилия, мы могли впоследствии изменить его форму».

— Kotlin Design Team

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

Стимулы

По сути, управление языком программирования — это согласование стимулов. Вокруг каждого языка программирования существуют 3 основные группы заинтересованных лиц:

• Конечные пользователи-разработчики, которые используют язык ежедневно.

• Сообщество, формирующие (и реализующее) рабочие предложения по изменению языка.

• Руководящая группа, за которой остается последнее слово.

Конечные пользователи-разработчики просто хотят работать с хорошим языком. Язык является их стимулом, и они голосуют своими клавиатурами. Эта когорта исчисляется миллионами, однако на самом деле они имеют наименьшее влияние из-за чрезвычайно высокой стоимости перехода на другой язык: большинство из них не захочет отказываться от своего многолетнего опыта.

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

• Résumé-driven-development подталкивает инженеров к участию в дискуссиях только для того, чтобы повысить свою личную востребованность. К тому же, тяжелая работа — это тяжелая работа.

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

Форумы, посвященные эволюции Swift, печально известны своими бесконечными страницами синтаксического байкшеддинга.

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

В некоторых случаях, как, например, в случае с Python или Rust, руководящая группа формируется из наиболее влиятельных членов сообщества, направляя их несовершенный набор стимулов в направлении чего‑то, напоминающего «то, что лучше для языка».

В других случаях, как, например, в случае с Kotlin, компании, создающие язык, преследуют свои цели: продажа IDE (JetBrains) и увеличение числа и производительности Android‑разработчиков (Google).

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

Swift: Пожизненный корпоративный диктатор

Apple и Swift представляют наихудшую возможную ситуацию.

Apple однозначно является диктатором Swift. Они платят зарплату большинству членов рабочей группы (core team) и имеют право произвольно назначать членов руководства проекта.

У Apple самый очевидный стимул из всех возможных: максимизация прибыли для акционеров.

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

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

Swift 5.1 — это канонический пример того, что Apple наплевать на сообщество. В нем появились непрозрачные типы результатов с some, неявные возвраты и обертки свойств. Она даже внедрила построители функций в компилятор без какого-либо эволюционного процесса!

В сочетании эти функции составляют синтаксическую основу SwiftUI, нового блестящего фреймворка пользовательского интерфейса будущего™. Но вместо того чтобы дать сообществу возможность высказаться, мы видим одностороннее одобрение (или отсутствие такового) этих функций, продиктованное какими‑то собственными внутренними дедлайнами Apple.

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

От себя лично добавлю, что манифест Swift Concurrency был написан еще в 2017 году. Однако, при распределении ресурсов команды Swift* гораздо более приоритетной задачей стало создание нового фреймворка пользовательского интерфейса в 2019 году, в результате чего Swift Concurrency был отложен на годы, до 2021 года.

*Ну хотя бы у меня есть Combine.

Наследие Латтнера

Давайте еще раз рассмотрим философию дизайна Криса Латтнера и сравним ее с современным Swift:

• Простые решения, которые компонуются. (Сложные решения, которые не компонуются)

• Поэтапное раскрытие. (У Свифта 217 ключевых слов)

• Есть только один способ решить задачу. (Построители результатов и макросы?!)

Несмотря на уход из Apple в 2017 году, Латтнер оставался в рабочей группе Swift до 2021 года. Объяснение его ухода было связано с пессимистичными перспективами развития Swift:

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

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

Многие факторы (в том числе амбициозные цели, четкие графики, длиннющие очереди багов, внутренние сотрудники, которые хотят просмотреть/разработать что-либо до того, как к этому получит доступ общественность, и давление на команду извне) выливаются в такое странное взаимодействие с сообществом.

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

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

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

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

Технологический долг и компилятор

Крис Латтнер неоднократно говорил в подкастах о том, что в компиляторе накопился технический долг. Это было неизбежно на ранних этапах, пока его крошечная команда умудрялась угождать миллионам разработчиков, переводя всю их среду разработки с Objective-C и с Swift 2 на 3.

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

Современный Swift — сверху донизу раб прихотей кабалы Apple MBA, которая ценит секретность и презирает вклад сообщества. Без влияния Латтнера или хотя бы неустанного стремления к изяществу, навязанному Джобсом, все сводится к тому, чтобы выпустить новейший проприетарный загребатель бабла.

Apple: Убийцы?

Apple не ведет себя со Swift неразумно, учитывая их структуру стимулов. Нам нужно трезво оценивать текущую ситуацию:

Трудно поспорить с тем, что SwiftUI все-таки чертовски хорош.

Из соображений бизнеса, к 2019 году необходимо было выпустить декларативный UI-фреймворк, чтобы конкурировать с быстрорастущими кроссплатформенными конкурентами React Native и Flutter.

Объединение платформ (iOS, macOS, watchOS, TVOS, а теперь и VisionOS) также было важной стратегической задачей, которая позволила укрепить экосистему для всего железа Apple.

Крейг Федериги (Craig Federighi) не идиот — усложнение языка было компромиссом, который они рассматривали. Как всегда, выгода для бизнеса превалирует над гиканьем луддитов, жалующихся на исключения в компиляторе при проверке типов.

Есть ли хоть какая-то надежда?

Apple и все опенсорсное сообщество не оставили без внимания резкий шаг Криса в сторону разрыва отношений с ним. Хотя это был не единственный фактор, он помог катализировать сдвиг в сторону менее диктаторской и более прозрачной модели управления.

Swift заимствует идеи из модели Rust — специализированные руководящие группы и рабочие группы, включающие членов не из Apple.

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

Акцент на использовании Swift за пределами закрытой экосистемы Apple дает проблеск надежды на то, что руководство Apple начнет видеть лес отличного языка программирования сквозь деревья проприетарных фреймворков. В настоящее время существует руководящая группа по платформам для внедрения Swift в Windows и Arduino.

Компания Apple пробует Swift на некоторых собственных внутренних системах, обрабатывая миллионы запросов в секунду. Хотя это не совсем альтруистично, инвестиции в рабочую группу Swift On The Server — это очень здорово.

Наконец, Apple работает над переписыванием Foundation в виде пакета Swift с открытым исходным кодом, который одинаково хорошо переносится на все платформы. Многие новые библиотеки, такие как AsyncAlgorithms, также поставляются в виде пакетов, а не привязаны к ОС, как стандартная библиотека.

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

Я очень надеюсь, что так и будет.

В завершение статьи напоминаем про открытый урок на тему машинного обучения в iOS, который пройдет 26 ноября. Что ждет на уроке: краткая теория ML, демонстрация обучение нейронки с помощью CreateML, возможности CoreML и Vision.

Если интересно, записывайтесь на странице курса "iOS Developer. Professional".