Доказательное программирование
Внимание!
Содержание данной статьи никак не связано с докладом академика А.П. Ершова «Научные основы доказательного программирования» 1984 г.
Статья содержит утверждения, способные вызвать вспышки гнева и неконтролируемой агрессии. За последствия автор статьи ответственности не несет!
В тексте упоминаются следующие языки программирования: Java, Swift, Kotlin, Scala, Go, Haskell и др.
Эта статья — антитезис. Автор ставит вопросы, но не считает своим долгом на все из них дать ответы.
В момент своего появления в Европе доказательная медицина казалась скандальной, неприятной и отвергаемой почти всем медицинским сообществом идеей. Даже в США, которые сейчас являются оплотом доказательной медицины, долгое время не хотели ее принимать. Основная идея — докажи, что то, что ты собираешься сделать, реально поможет. Сейчас большинство назначений доктора делают исходя из приобретенных знаний и опыта. Но что если для определенных ситуаций можно создать такой протокол лечения, следуя которому с болезнью сможет справиться даже неспециалист, и будет доказано, что этот протокол работает? Можно ли покрыть такими протоколами все известные недуги? Все, конечно же, нет, но какие-то — определенно, да.
И вот тут невольно возникает вопрос: не обошла ли медицина другую, казалось бы, не менее прогрессивную индустрию разработки программного обеспечения? Ок, у врачей есть этика, primum non nocere («главное, не навреди»). Но разработчик не врач, и вроде как его это не касается… или касается? Всегда ли разработчик выбирает лучшее решение для своего клиента? Не преследует ли время от времени разработчик какие-то свои цели (освоить новую технологию, попробовать новую либу, язык программирования и т.п.), о чем клиенту лучше не знать? Испытывает ли разработчик угрызения совести в связи с этим? Или это норма рынка? Ведь индустрия не стоит на месте, и если разработчик проигнорирует новомодное решение, то рискует не попасть на набирающий ход поезд под названием «мейнстрим»?
А надо ли вообще искать лучшее, оптимальное решение? Спрос на рынке программ растет как на дрожжах. Все больше устройств, которым необходимо собственное ПО. Эти программы надо создать, и у клиентов, скажем честно, не всегда есть выбор. В некоторых отраслях счет компаний, обладающих реальной экспертизой, идет на единицы. В такой ситуации разработчик диктует свои условия. Но даже там, где существует реальная конкуренция, всегда ли решение выбранного подрядчика обладает лучшим соотношением «цена — качество»? Всегда ли разработчики сами могут это понять?
Давайте разбираться! На конкретных примерах.
«Чудесное» воскрешение Kotlin
Kotlin — отечественный продукт, созданный в недрах небезызвестной российской компании JetBrains. Зачем действительно был создан этот язык, знает, видимо, только часть сотрудников этой компании, но можно пофантазировать. Какой программист не хочет создать свой язык? Вопрос риторический. В JetBrains тоже нашлись энтузиасты. Но мы знаем, что в этой компании проходимцев нет, все товарищи исключительно умные и образованные. В свои ряды они абы кого не берут. Если они создали язык и сказали, что язык крутой, и это то, что вам нужно, значит так оно и есть! Ребятам можно верить… или нет?
Есть в JetBrains такой чувак (собирательный образ), который когда-то открыл для себя DSL. И в голову ему пришла «гениальная» идея, которая до этого, несомненно, не приходила в голову никому: не надо выбирать язык под задачу, вместо этого надо сделать язык для создания языков, и тогда разработчик сам будет создавать такой язык, который ему нужен для решения конкретной задачи! Бинго! Придумано — сказано, сказано — сделано. Сначала была статья, из которой уже было ясно, что перспектив у затеи немного, но это точно не было ясно чуваку из JetBrains. Если вы поняли, о каком продукте идет речь, то могли заметить: автор, задним числом все умные, а ты тогда это знал? Вы не поверите! На самом деле (философы, кстати, не любят эту фразу) это было бы понятно любому, кто читал анонс JetBrains и при этом имел достаточный опыт «полевой работы». Проблема кажется очевидной. Но не господам из знаменитой компании, которые уж точно знают, что программисту нужно, а что — нет.
Любой, кто пробовал создать свой язык, осознает, что дело это не такое простое, как может показаться на первый взгляд. И вроде бы все инструменты есть, и книги написаны. Но вот что надо учесть: под ваш язык нет инфраструктуры, нет комьюнити, нет ничего! Вы создаете его в пустоте. Вы не найдете на рынке специалистов, знающих ваш язык. Всех надо готовить, всех надо учить. Не всем это понравится — перспективы такого опыта с точки зрения рынка труда сомнительны.
Но чувак из JetBrains слишком умен, чтобы ошибаться. Он уж точно знает, что это взлетит. Создается команда разработчиков, и они начинают пилить очередной, но, конечно же, уникальный инструмент для создания языков программирования — MPS. Прошло 10 лет. Если вы посещали конференции с участием JetBrains, то могли обратить внимание на изобилие продуктов, которые компания продвигает. На любой вкус. Только MPS вы там не увидите, т.к. он стыдливо спрятан в стол. Нет, продукт существует и по сей день. И даже есть одна, кажется европейская, компания, которая до сих пор им пользуется. Большая, надо сказать, компания. Может поэтому продукт еще жив.
Но чувак из JetBrains не успокаивается — он делает выводы. К сожалению, не те, которые следовало бы. Гений решает впасть в другую крайность — не менее гениальную, чем первая. Теперь, говорит он, я сделаю один язык, но по-гениальному универсальный. Который заменит все остальные. Потому что новый язык будет лучшим и самым правильным. В нем будет все удобно, все продумано. Гении иначе не умеют. Другие языки создавались лузерами. Наш их всех победит! Создается команда идейных разработчиков, и они начинают пилить очередной, но, конечно же, уникальный язык программирования, и гений из JetBrains с оптимизмом смотрит в будущее.
Язык почти готов, публикуются анонсы. И… тишина. Вроде новый же язык! Почему за ним не выстроилась очередь?! Может дело в том, что примерно в это же время увесистую дверь комьюнити разработчиков с ноги открыла «всплывшая» невесть откуда Scala (о ней чуть позже), которая очаровала своими возможностями, и Kotlin растворился в сиянии новой игрушки программистов? Казалось, что новенький продукт JetBrains идет к катастрофе.
Но гений из JetBrains не может ошибаться! Он понимает, что Kotlin появился слишком рано, его время еще не пришло. В конце концов, когда разрабы наиграются со Scala, они оценят всю гениальность отечественного языка. У Kotlin еще все впереди! И он не ошибся. Помощь пришла откуда не ждали.
Изначально Kotlin эксплуатировал инфраструктуру Java, что позволило быстро вывести его на рынок. Java же известна не только как «банковский язык», на котором написано, пожалуй, большинство современных решений для этой отрасли, но и как основной язык разработки для самой популярной мобильной ОС. Главный ее конкурент — ОС от Apple — требовал от разработчиков использования мумии под названием Objective C. Изначальный выбор этого языка понятен, но гениев из Apple (а там такие тоже есть!) таки пристыдили достаточно, чтобы они выкатили комьюнити более современный язык. Swift выглядел очень модно! Особенно по сравнению с трупом, который приходилось использовать до этого. Google должна была ответить на вызов!
Так случилось, что Google к тому времени уже какое-то время сотрудничала с JetBrains, которая на базе замечательной (без шуток) Idea помогла запилить Anroid Studio — не менее замечательный (тоже без шуток) инструмент! И вот так оказалось, что у JetBrains есть подходящий язык. И выглядит он, что характерно, модно, как и Swift. Java-то уж 30 лет! Старье! А тут такой красавец! Нужно было действовать решительно. В итоге Kotlin получил титул основного языка разработки приложений для Android. Вот он — звездный час гения из JetBtains! Теперь-то разработчики от него никуда не денутся! Признание! Google переписывает все свои доки, дублируя примеры на отечественном языке программирования. Более того, примеры на Kotlin становятся основными. Разработчики IT-гиганта, попавшие под чары «нового» языка, начали строить планы по использованию встроенного в него конструктора DSL для… Постойте! Что? Конструктор DSL? Встроен? Как? Опять?
История эта обрывается на настоящем моменте. В итоге миллионы мобильных разработчиков получили новый язык, на который многие из них начали переходить по настоянию Google. Что же дает нам этот чудесный образец творчества лучших инженеров из Санкт-Петербурга? Да примерно ничего! Точнее, шанс уйти в минус. Получить дополнительные затраты на создание и, что важно, на поддержку своих продуктов. Сам язык, если присмотреться, несет в себе больше проблем, чем решений. Почему? Да потому-что сложность разработки не уменьшается от замены языка на другой язык того же типа. Сложность разработки, как правило, заключается в самой задаче, которую надо решить. И, чем сложнее задача, тем сложнее и дороже ее решение. То, что на одном языке код выглядит немного короче, чем на другом, мало что меняет. Послушайте доклады инженеров из JetBrains. На что они делают упор? На то, что код на Kotlin будет «намного» меньше, чем, скажем, на Java. Только вот они как-то не задумываются над простым вопросом:, а за чей счет банкет? За счет чего ушли те «лишние» строки кода Java? Не пропала ли из кода какая-нибудь полезная информация, которую раньше можно было бы просто прочесть, но теперь о ней надо догадываться по косвенным признакам? Не задумывались ли гении из JetBrains о том, что хитрый вывод типов, который проделывает созданный ими несомненно гениальный компилятор, нужно будет проделывать каждый раз и разработчикам, которые будут читать «пожатый» код, тратя на это лишнее время?
Опять вопросы… Но хочется задать еще больше. Можем ли мы сравнить описанную ситуацию с выпуском нового лекарства на фармацевтический рынок? Лекарство должно пройти сертификацию прежде, чем его допустят к продаже в развитых странах. С точки зрения доказательной медицины, препараты с недоказанной эффективностью — это мусор, который не имеет право называться лекарством. Другое дело, что большинство веществ никогда не проходило требуемую сейчас процедуру тестирования. Многие из них никогда это тестирование и не пройдут из-за его высокой стоимости. Но об этом все будут знать.
IT-рынок захлебывается в потоке новомодных языков, которые скоро перестанут друг от друга отличаться. Каждый новый язык по словам их создателей «уникален» и «современен». Приводится масса причин, почему разработчик должен выбрать именно этот язык. Но так ли обстоят дела, как то декларируется? Действительно ли новый язык, новая библиотека, новый фреймфорк, новая СУБД решат больше проблем, чем добавят? Будут ли они эффективней, чем ранее разработанные инструменты, которые уже используются и по которым уже есть какая-то экспертиза?
Пока отложим эти вопросы и двинемся дальше…
Свидетели Scala
Вы когда-нибудь общались с представителем «секты свидетелей» Scala? Он на вас будет смотреть свысока, даже если на 30 см ниже ростом. Потому что он познал. А вы — не познали. Он «так может», а вы и «ваш язык» — нет. За его запятой может прятаться вселенная, а за вашим «плюсиком» ну максимум — конкатинация строк. Какая банальность! Его код — это высокоинтеллектуальный ребус для таких же просветленных, как он сам. На самом деле это ребус даже для него самого, но он от этого лишь получает удовольствие. А вы со «своим языком» такого удовольствия лишены. Вы обречены писать банальности с использованием предопределенного набора банальных операторов. И символы, которые вы пишете, не имеют никакой дополнительной высокоинтеллектуальной нагрузки… Кажется, что разработчики Scala попытались запихать в язык все, что смогли вспомнить. И если что-то не запихивалось, раздвигали и запихивали. Трудно сказать, чего там нет. И, казалось бы, вот… Ну что еще нужно? Безграничные возможности для самовыражения!
Говорят, что «ажиотаж» вокруг Scala подутих в 2017–2018 гг. Как по мне, ажиотажа, собственно, никогда и не было. Был интерес, было любопытство. Короткий период. Год-два. Но да, некоторые смельчаки не заметили подвоха и погрузились в Scala по пояс. Возможно, в их вселенной какой-то ажиотаж и был. Но большинство поматросило модную штучку и оставило в покое. А те, кто влез, те — да… Те влипли по-полной. Но признаться в этом себе невероятно сложно. Сложно признавать подобные ошибки. Лучше сказать, что язык замечательный, это программисты плохие. Не доросли. Не доучились. Низкий IQ. Язык для избранных. На конференции свидетель Scala показывает слайд с парой строк, выглядящих как обычное арифметическое выражение. Но по хитрому прищуру докладчика все понимают, что здесь есть второе дно. И что эти две строки надо «читать». И дальше он с упоением рассказывает, как именно. Почему он так сделал? Потому что может! Потому что язык так может.
Согласно индексу TIOBE за март 2021, Scala и Kotlin находятся на соседних строчках. Считаю, замечательное соседство! Индустрия в безопасности, ее иммунная система справилась с недугом и миновала пропасть, по краю которой прошла. Да, есть потери. Scala поглотила слабых духом и оставила за собой шлейф из начатых проектов, от которых не просто будет избавиться. Но ничего. Поглощенным поможет реабилитация, а проекты рано или поздно умрут своей смертью. Все как обычно. Все имеет начало и конец.
А есть ли что-то подобное в фарме? Когда-то фенобарбитал можно было купить без рецепта, сейчас же во многих странах его вообще нет — запретили (основное действующее вещество «Корвалола»). Стволовые клетки колют как витамины, но уже многие знают, чем это может обернуться. В 30-е годы прошлого века Кюри толкали свою радиоактивную косметику «Tho-Radia» — в итоге она была признана «ядовитой». Детокс-терапия — клизма, диета, «очищение» — очень модно (не запрещено)!
Сейчас у общества есть защитный механизм — доказательная медицина. В каком-то смысле это заклинание позволяет уберечься от подобной «скверны». В конце концов, всегда можно выяснить, была ли доказана эффективность того или иного препарата. Если не получается, есть комьюнити врачей, которые помогут.
В индустрии разработки пока ничего такого нет. Нам выкатывают нечто, что выглядит соблазнительно, и в итоге, в лучшем случае с небольшими потерями, мы проходим сложный период, движемся дальше. Но так бывает не всегда. Мириады неоновых вывесок с рекламой самых новых технологий и решений обволакивают неподготовленный ум начинающего программиста и запускают свои щупальца в его новые проекты. Да и опытный программист может быть усыплен очаровательным пением коварных IT-сирен. Все ли из того, что вы задействовали в своем проекте, вам действительно нужно? Или это дань моде, когда страх «отстать» не оставляет вам выбора? Действительно ли ваш выбор продиктован личным опытом? Возможно ли иметь качественный личный опыт, например на рынке разработки мобильных приложений, когда Google меняет правила игры раз в несколько месяцев?
Ну вот, опять! Вопросы, вопросы…
Сверхновый GO
Вот уж где создатели языка определенно постарались. Go, по сравнению с Kotlin, это действительно большая работа. За простотой синтаксиса скрывается целая сеть сложных компромиссов. Несомненно, назвать этот язык чьим-то клоном никак нельзя. Современный, продуманный, легко читаемый. Последнее, при таком синтаксическом аскетизме, кажется невероятным достижением разработчиков. Чудо чудесное, не иначе!
Не слишком ли все хорошо? Что-то здесь не так, что-то мы упускаем, что-то ускользает от нашего взора. Вот! Кажется я вижу чьи-то торчащие уши! Взять тесты. Почему здесь так много комментариев? Как это? Они интерпретируются? Это что, значит, в комментах спрятан еще один язык? Дополнительный синтаксис, которого как бы нет? Но он как бы не подходит под утверждение «ничего лишнего», так что там ему и место — нечего портить стройный язык всякой второстепенной чепухой! На самом деле (опять эта нефилософская фразочка) тут нет вины разработчиков: причина такого решения в самой природе тестов и общей проблеме всех современных мейнстримовых языков. Но это тема отдельной статьи. Сейчас не об этом. Так что здесь я разработчиков не виню — они сделали все, как принято. Хотя осадочек таки есть… Эх!
Легенда гласит, что инженеры Google создавали язык для внутренних нужд и что он должен был быть достаточно простым и доступным даже слесарям из хозгруппы. Если это так, то многое становится понятным. Иначе сложно представить, что еще могло заставить разработчиков языка так поступить с одной из базовых концепций ООП. Когда я приношу домой новый телевизор, к нему прилагается пульт. Когда я сажусь на водительское место в авто, там уже есть органы управления. Я не ношу их с собой, как и не покупаю телевизор к уже имеющемуся у меня пульту. К новому телефону продается чехол, который выпускают специально под данный девайс, а не наоборот. Что же с инженерами Google не так? Почему они делают это с нами? Где чертов пульт?!
Если же отбросить сие недоразумение с интерфейсами, то в целом язык следует основным канонам и придраться тут не к чему. Но, раз уж мы затронули эту тему, пару слов про ООП-диссидентов. Сложно сказать, что движет этими несчастными. Возможно, это защитный механизм, позволяющий не сойти с ума, когда единственным рабочим языком программирования в арсенале является JavaScript? А может, это патологическая неспособность к абстрактному мышлению? Или отсутствие опыта работы над по-настоящему большими проектами? Чье-то тлетворное влияние? Или это скрытая сверхспособность помнить весь проект в деталях независимо от того, какого он размера, и никогда не допускать ошибок при взаимодействии между компонентами системы? Кто знает, кто знает… Больно уж много специалистов с этой сверхспособностью развелось…
Что же подсказывает нам доказательная медицина? Следует ли нам избавиться от традиционных методов лечения, когда врач изучает все, что касается человеческого организма (анатомию, физиологию, биохимию), и при этом знает лекарственные вещества, — оставить хирургов, а обычных терапевтов заменить кабинками «Instant Doctor», которые будут следовать доказанному протоколу лечения и использовать только средства с доказанной эффективностью? Насколько все можно упростить? Реальность такова, что доказательство эффективности различных химических веществ — мероприятие крайне недешевое и доступно только Большой Фарме. А те не будут тратить деньги на лекарства, на которых они не смогут сорвать куш. Так что большинство лекарств существующему стандарту эффективности не будут соответствовать никогда. Эффективность парацетамола не доказана, и никто не знает, почему он делает то, что делает. Но помогает же!
Разработчики Kotlin забыли (или никогда не знали), почему в Java нет перегрузки операторов. Создатели Scala вообще об этом не задумывались. А инженеры из Google по какой-то причине решили, что их интерпретация основ ООП поистине революционна. Это те самые случаи, когда новым выглядит хорошо забытое старое. Смущает то, что нет какого-либо серьезного анализа этих языков, наоборот — Интернет переполнен исключительно хвалебными отзывами. Т.е. ни о попытке как-то подтвердить эффективность навязываемого инструмента, ни и о банальной критике этих решений и речи нет. В чем причина?
Можно взглянуть на все с другой стороны. Не нравится, не ешь. Дай рынку насытиться! Изобилие — это хорошо! Есть конкуренция, есть выбор. И кажется, что все так, выбор есть, но… можем ли мы правильно выбрать? И всегда ли этот выбор действительно есть? Какова цена ошибки? Каким требованиям должен соответствовать язык программирования в вашем случае? Каким стандартам соответствует выбранный язык? Только тем, которые сформулировали сами создатели языка? Очень надежно! Или он просто вам понравился? Вы хотите его изучить, потому что коллеги о нем все время говорят, хвалят и все такое? А знает ли об этом ваш заказчик? Готов ли он оплачивать ваше обучение?
Вы выбрали новую СУБД, которая только появилась на рынке. Но исследовал ли кто-то ее надежность? Кто авторитетно может это исследование подтвердить? Вы? Ваш коллега? Он знает, как проводить такие исследования? Точно? Или исследование будет перенесено в продакшн и, конечно, оплачено ничего не подозревающим клиентом? Не стоит ли вспомнить здесь об этике? Ведь в данный момент для этого клиента вы олицетворяете все программистское сообщество, и если дискредитируете свою работу, то вы дискредитируете тем самым все сообщество, перекладывая стоимость своих ошибок на него, как это делают создатели разного рода новых инструментов и языков программирования. Без контроля, без сертификации, под честное слово.
Ну и напоследок…
Альтернативная медицина
Опять провал, опять ничего не выходит. Ошибки лезут из всех щелей. Паника. Что же делать? Как все исправить? Как сделать так, чтобы все работало с первого раза, а объем проблем перестал нарастать, словно снежный ком? Надо начать все сначала, время еще есть, но где гарантия, что результат будет другим?… Что это за сладкий шепот в левом ухе? Кажется, он что-то пытается сказать! Шепот: «Функциональный язык». Что? Шепот: «Выбери функциональный язык — забей на постылую императивщину, пора сменить парадигму». О чем это он? Ну-ка ну-ка, Интернет… Так-так-так. Ого! Какая интересная концепция! Шепот, где же ты был раньше? Наконец-то решение найдено, теперь все заработает с пол-оборота! Но что-то терзает душу молодого разработчика, что-то не дает покоя… что же опять не так?
Мы нашли вашу кучу, проектов на Haskell в ней не было.
«Если все так чудесно, — размышляет наш герой, — где те мириады проектов, написанных на функциональных языках программирования? Почему большинство программистов продолжают поедать мейнстримовый кактус? Возможно, от нас что-то скрывают? Тайный орден охраняет секреты эффективного программирования? Не просто, наверное, — думает он, — скрывать секреты, связанные с идеей, возраст которой сопоставим с возрастом самой отрасли. Или тут какой-то подвох? Может, все дело в системе образования, когда в учебном плане по информатике доминирует императивный подход?»
Может ли разработчик разобраться в этом вопросе, не погружаясь в него с головой и не расчищая авгиевы конюшни от «авторитетных» мнений «специалистов»? Что он обнаружит, попытавшись найти необходимый источник информации? Холивар, когда оппоненты до последнего готовы отстаивать свое мировоззрение, свой комфортный мирок, который они с таким трудом выстроили из скудной смеси парадигм и традиций и который готов рассыпаться на части от любой крамольной мысли? Сможет ли найти наш бедолага что-то, что укажет нужное именно ему направление? Какой-нибудь путеводитель, учебник. Или без наставника здесь не обойтись?
А верно ли вообще ставить вопрос таким образом? Действительно ли есть из чего выбирать? Возьмем функциональный Haskell, который позиционируется как язык общего назначения. Что бы это ни значило, тот же самый ярлык несут на себе такие монстры, как C++, Java, С#. Может ли Haskell составить им конкуренцию на этом поле? Вот реально? В теории — несомненно. Но на практике, как говорится, не тратьте свое время. Хотя такой язык, несомненно, достоин того, чтобы с ним познакомиться… в свободное от работы время. Что же с ним не так?
Придется совершить каминг-аут: я обожаю Prolog! Как и Haskell, он относится к семейству декларативных языков. Это когда вы не говорите машине, как именно нужно что-то сделать, не указываете последовательность действий, которые следует совершить, а устанавливаете некие границы и формулируете задачу, т.е. что нужно сделать, при этом на вопрос как пытается ответить уже сам компилятор. И это, казалось бы, хорошо. Но все меняется в тот момент, когда программа начинает делать что-то не то. Не то, что от нее ожидали. Возникает закономерное желание понять: почему она поступила именно так? И вот здесь выясняется, что любой императивный язык буквально «ткнет пальцем» в место в коде, где проявилась проблема и откуда ее можно локализовать. С декларативными языками иначе. Там нет привычного нам стека выполнения, который однозначно бы мапился на код. В случае с Prolog он может совершить миллион сопоставлений, прежде чем ошибка даст о себе знать. Это как если бы ваш стектрейс состоял из миллиона строк и в какой-то одной из этих строк что-то пошло не так, что-то не сошлось, какое-то правило не сработало.
Если учесть, что даже вооружившись самыми передовыми средствами отладки, найти проблему в императивном коде бывает ой как не просто, легко понять, почему в реальной жизни программисты предпочитают не связываться с языками, где отладка пусть и немного, но сложнее. Да, императивный код частенько «отрывается» от постановки задачи, когда приходится искать, где именно в коде реализована конкретная функция, гадать, почему разработчик выбрал именно такое решение и действительно ли оно корректно. Но, видимо, по соотношению всех плюсов и минусов императивные языки имеют серьезный гандикап.
Как же ориентироваться в этом океане технологий? Может, есть в нем тихие гавани, которые помогут найти решение? Взять HTML. Это не просто язык, это промышленный аппликационный стандарт. Т.е. речь не о стандарте, описывающем сам язык, а о стандарте для браузеров, которые обязаны его поддерживать. Ни анархии тебе, ни конкуренции. И кажется, что всех все устраивает. Его неизменный попутчик JavaScript при всей своей убогости тоже стандарт; лишь 10 лет назад разработчики браузеров договорились о том, чтобы заложить первый кирпич в фундамент куда более продуманной технологии WebAssembly. Чуть хуже дела обстоят в мобильной разработке. Тут таких стандартов, к сожалению, нет. Хотя попытки их внедрить таки имеют место быть. От унылой Cordova, до новенького Flutter. Но без поддержки всех участников рынка эти попытки обречены. Отрасль, скорее, идет в обратную сторону: Huawei выкатывает свою собственную ОС, и, учитывая размер рынка Китая, игнорировать ее, похоже, не получится.
Разработчики же прочих платформ в большинстве своем не накладывают никаких ограничений на используемые технологии (Apple не в счет), но и не делают попыток о чем-то договориться. Пожалуй, Microsoft достигла наибольших успехов с C#, рождение которого стало итогом войны с Sun Microsystems за право вносить изменения в стандарт Java. Microsoft добилась впечатляющих успехов в продвижении своего детища, но так и не смогла сдвинуть Java с ее пьедестала. Может, в будущем? Кто знает.
Способно ли развитие стандартизации изменить ситуацию? Или не стоит ничего менять, и так хорошо? Или не хорошо? Кажется, что спрос есть. Пример EJB, который канул в лету вместе с Sun, показывает, что на самом деле (вот опять) движение в эту сторону возможно и рынок готов его поддержать. Но неудача EJB могла быть неверно интерпретирована, что и привело к топтанию на месте. А может быть, у затеи изначально не было шансов? Как бы то ни было, при всем разнообразии решений то и дело вываливающихся на и без того переполненный рынок, кажется, что ситуация напоминает настоящий застой. Парадокс… или кризис? Или все ок, и думать тут особо не о чем? Как воспринимать все это изобилие? Как новые игрушки, с которыми интересно повозиться (за чей-то счет, естественно), или как пилюли, эффективность которых должна быть подтверждена? Как воспринимать эти «игрушки» в руках коллег (в широком смысле), результаты игр которых разгребать потом придется вам? Может быть, новая этика?
Вопросы, вопросы, вопросы…
Я все сказал
