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