Мы часто читаем о бэст практикс в программировании, о новых функциях фреймворков или о том, что нового в очередной версии PHP. Читаем, как поменять «то на это», почему какая-то техника хороша или плоха, или какой новый пакет вы можете использовать в своём проекте. Но всё это — рассуждения только о прошлом или настоящем.
Сейчас я заканчиваю чтение книги «The Inevitable», написанной основателем журнала Wired, речь в которой исключительно про будущее. Вдохновившись этой книгой, предлагаю посмотреть на будущее программирования.
Сегодня мы боремся с техническим долгом (что бы это ни означало), с устаревшим кодом, который сложно поддерживать и дорого изменять, но, в то же время, он генерирует много денег. На регулярной основе мы должны рефакторить код, следовать принципам DDD, писать тесты, обновлять в целях безопасности версию PHP, устанавливать свежие версии ПО на сервер и автоматизировать выкладку.
Так много текущей рутинной работы, что совершенно нет времени посмотреть на десятки других проектов, которые поддерживает наша компания… или, по крайней мере, хранит где-то на наших серверах. Нам стоило бы нанять эксперта, который поможет хотя бы немного улучшить каждый аспект. Не потому, что эти проекты плохие, а просто потому, что существует очень много технологий, которые мы можем использовать, и ещё больше кода, который мы должны просто поддерживать.
А как это всё будет происходить в будущем?
IDE будет использовать искусственный интеллект
В будущем набирать код станет проще. Наша IDE будет работать на основе искусственного интеллекта, который учится на анонимных данных других PHP-проектов и на всех проектах с открытым исходным кодом на Github и Gitlab.
Благодаря этому ИИ, когда мы начнём набирать «class HomepageC ...», IDE будет знать, что мы создаём контроллер домашней страницы, что мы используем Symfony, а также его версию из composer.json, и предложит автоматически дополнить оставшуюся часть кода модификаторами финализации и строгими типами, основываясь на знании используемой версии PHP, тоже из composer.json. Он сгенерирует шаблон для шаблонизатора, который мы используем, и будет имитировать содержимое, найденное в других шаблонах, которые уже есть в нашем проекте.
Благодаря огромному количеству анонимных данных и данных из публичных хранилищ кода, ИИ будет знать как лучше протестировать контроллер и будет использовать эти знания для создания оптимального теста контроллера.
Best Verified Practice
Когда мы говорим про «бэст практикс», то не имеем в виду то, что я или кто-то другой написал в посте или книге, основываясь исключительно на личном опыте. Эти мнения часто основаны на опыте, полученном всего лишь в нескольких проектах, и эмоционально окрашены.
В будущем понятие «бэст практикс» сменится на «верифайд практикс» и будет основано на реальных данных, связанных с двумя жёсткими показателями — техническим долгом и эффективностью написания кода. У технического долга будет финансовый эквивалент, который покажет, сколько будет стоить поддержка каждой строки кода в будущем. Вы свободно пишете статический код без типизированных классов? Строка может «стоить» $10. Вы пишете финальные классы со строгими типами и одним публичным методом? В таком случае, строка обойдётся в $2.
Эти цифры не будут случайными, а будут основаны на постоянном анализе колоссального объёма больших данных, анонимных для всех проектов, которые захотят использовать эту функцию. Код будет сравниваться с денежными затратами, которые были необходимы для поддержания и улучшения проектов. Благодаря этой обратной связи ИИ также будет знать, какая версия выгоднее для вашего конкретного проекта.
ИИ будет знать о контексте вашего проекта и сравнит данные соответствующим образом. У вас CLI проект? Он будет сравниваться с кодом других CLI проектов в этой предметной области. Вы делаете сайт? Он будет сравниваться с проектами других сайтов.
Эффективность написания кода будет определяться метрикой «ремонтопригодности» проекта. Она будет измеряться шкалой от 0 до 100 баллов, где 0 баллов означает, что понимание кода занимает много часов, а чтобы внести изменения могут потребоваться дни или даже недели. Код с оценкой 100 будет легко понять джуниор разработчику, и он или она сможет изменить код практически мгновенно.
IDE верифицированное автодополнение
IDE будет знать об этих показателях, а также будет следовать шаблонам, используемым в вашем коде. Когда вы начинаете писать кусок кода, чья эффективность равно 40-50 баллов, всплывёт автодополнение с предложением кода с тем же функционалом, но с эффективностью уже 80-90. Это похоже на ту работу, которую Rector или PHPStan выполняют сегодня.
Анализ производительности также будет выполняться наряду с анализом эффективности кодирования. Производительность будет автоматически измеряться при каждом изменении кода в фоновом режиме в контейнере Docker, а вы будете проинформированы о любых утечках памяти или росте времени исполнения. Этот анализ будет настолько точным, что пометит определённую строку или символы, вызвавшие утечку, и предложит исправление, которое вам останется только принять.
AST рефакторинг
Рефакторинг тоже будет более мощным, чем сегодня. Он будет основан на абстрактном синтаксическом дереве (ASТ). IDE предложит лучший вариант рефакторинга, который вы планируете сделать сейчас, на основе анонимных данных из всех открытых и закрытых проектов.
Вместо того, чтобы ссылаться на «бэст практикс», вы будете знать, что:
- решение А обойдётся вам в $3 за строку в рамках технического долга, и будет иметь рейтинг 95 баллов по эффективности и 45 баллов по производительности
- решение B обойдётся вам в $1 за строку в рамках технического долга, рейтинг эффективности составит 70 баллов, а производительности — 50 баллов
Вы строите стартап и хотите проверить свою идею? Тогда вы выберете вариант A. А если ваша компания является стабильной и она должна оставаться таковой в будущем? Тогда стоит перейти на более дешёвый в поддержке и производительности, но чуть более медленный в развитии вариант Б.
Вам не придётся спорить с коллегой или с вашим боссом, почему вы должны использовать то или иное решение. Вы сравниваете цифры, а затем решаете, основываясь на ваших приоритетах на данный момент.
Контекстная архитектура
Ваш код будет иметь контекстную архитектуру. ИИ будет знать, когда лучше переходить между контекстами, основываясь на данных из других проектов и окончательной стоимости миграции в них. Вы начинаете делать проект на WordPress? Это ок. Но что если ваш проект станет более популярным, и вам потребуется перейти на какой-то фреймворк PHP, который будет лучше удовлетворять ваши потребности? IDE предложит вам перейти на Laravel. Один клик и всё готово.
Три года спустя ваш проект разрастается, и у вас появится много задач по интеграции сторонних сервисов, которые уже встроены в инфраструктуру Symfony. IDE предложит вам мигрировать… нажимаете… и бум, вы на Symfony 9. Вы обнаружили, что на рынке недостаточно Symfony разработчиков, которые могли бы справиться с разработкой вашего проекта? Один щелчок и IDE переведёт проект на фреймворк, для которого достаточно разработчиков по разумной цене.
Версионированные ответы StackOverflow
IDE будет сканировать ваш код и анализировать ваши привычки кодирования. Обычно Вы пишете функцию за 15 минут, но сейчас это занимает уже почти 2 часа? В последующие годы IDE будет настолько хороша, что заметит даже небольшое снижение скорости написания кода за считанные секунды.
Затем IDE проверит ваш код, отсканирует ответы на StackOverflow, сопоставит ответы с версиями в вашем composer.lock, и предложит использовать конкретный фрагмент кода как наиболее подходящий.
Вы волнуетесь, что этот фрагмент кода просто скопирован случайным образом и сломает ваш проект? Рейтинг ответов больше не основан на голосовании пользователей, а теперь учитывает процент использования ответа в случае его успешного интегрирования в код проекта.
Протестированные фрагменты кода
Кроме того, фрагменты кода ежедневно тестируются самим StackOverflow, а также перед копированием в ваш проект. Именно с версией вашей локальной среды, так что вы можете быть уверены в том, что код будет работать. Люди сами уже не пишут версии этих ответов, как это было в прошлом. Код в ответе обновляется автоматически при каждом релизе технологии или фреймворка, которые он использует. Какой-то ответ дан для Symfony 5. А что будет, когда выйдет Symfony 6? Старый код в ответе обновится с помощью рецепта AST, который был выпущен вместе с Symfony 6. Таким образом, человек и IDE смогут легко с ним работать.
Финансирование Open-Source, основанное на активности
Будет создан новый проект, который свяжет коммерческие компании и контрибьюторов открытого исходного кода. Проект с открытым исходным кодом будет финансироваться компаниями, его использующими. Разработчики, которые вносят свой вклад, будут финансироваться посредством единой системы, основанной на поступающих потоках денег, без дополнительных комиссий на покрытие издержек.
Размер финансирования будет определяться с помощью метрик, таких как: влияние функции, объём работы, затраченное время, эффективность кода и т.д. Таким образом, код будет разрабатываться гораздо более последовательно, чем когда разрабатывался независимыми контрибьюторами в их свободное время. Разработчик в проекте с открытым исходным кодом, по сути, получит работу на full-time, финансируемую этим проектом.
Что эти компании получат в награду? Продвижение в конкретном сообществе, предрелизные выпуски новых версий и прямой доступ к экспертам-консультантам, создавшим проекты с открытым исходным кодом, которые они (эти компании) используют.
Консолидация фреймворков
~10 фреймворков PHP, которые сейчас есть, будут консолидированы. Сообщества вокруг фреймворков PHP научатся больше сотрудничать, вместо того, чтобы разрабатывать почти идентичные копии фреймворков с MVC-подходом.
Благодаря AST-миграциям можно будет переключаться на любой PHP-фреймворк. Это позволит сузить выбор до 3-4 фреймворков. Если миграция между фреймворками — это вопрос 1 клика в вашей IDE, то больше не будет конкуренции, основанной на утверждении, что «так исторически сложилось», и привычках, а только на качестве.
Сокращение количества фреймворков приведёт к их большей узконаправленности — один фреймворк будет преуспевать в API, другой в CLI, третий в сайтах с прекрасным UX.
Когда всё сообщество PHP сосредоточится на меньшем количестве фреймворков, это позволит нам инвестировать сэкономленные усилия в разработку новых технологий и функций.
Только 1 стабильная версия PHP
Благодаря автоматическим AST-миграциям, будет только две версии PHP — stable и dev. Поскольку обновление любого пакета или проекта станет очень быстрым и дешёвым, не будет никаких причин не обновляться до последней версии. Возможно, PHP-сообществу потребуется год или два, чтобы принять это и синхронизировать все проекты. Но когда это произойдёт, то уже через месяц после выпуска новой версии PHP вся экосистема с открытым исходным кодом будет использовать её как минимальную версию.
Полностью автоматические и мгновенные обновления кода
Код PHP не нужно будет обновлять вручную. У каждой версии PHP будет полный «рецепт» обновления на основе AST, который можно будет использовать для автоматического обновления кода на своём проекте. GitHub будет обрабатывать эти «рецепты», поэтому, когда выйдет новая версия PHP, GitHub начнёт автоматически отправлять pull-запрос в ваш репозиторий. Автоматические обновления будут не только для PHP, но и для любого фреймворка или пакета. Как Dependabot, который недавно был интегрирован в GitHub, но теперь с обновлением кода и решением всех проблем обратной совместимости.
GitHub upgrader
Если вы не хотите принимать все PR самостоятельно, вы можете зарегистрироваться в программе автоматических обновлений, чтобы GitHub справлялся с этим за вас. Также он как следует будет обновлять релизы и их SemVer.
Автоматизированные SemVer
Не будет никаких споров относительно того, является ли изменение прерыванием обратной совместимости или только патчем. ИИ будет анализировать код до и после, и на основе этого будет принимать решения. Он будет настолько умён, что сможет определять, насколько существенное влияние оказывает то или иное изменение. Если это не повлияет на какой-либо код в других проектах, он будет выпущен как патч.
PHP RFC на основе накопленного опыта
Такой же анализ прерывания обратной совместимости будет возможен для любого RFC в коде ядра PHP. Хотите предложить типизированные константы? ИИ подскажет вам, сколько проектов из топ-10 000 на Github будет сломано в процентах. Нечто подобное сейчас делается вручную в некоторых RFC.
Переосмысление «прерывания обратной совместимости»
ИИ также поможет вам генерировать «рецепты» миграции AST, поэтому мгновенное обновление может полностью справиться с прерыванием обратной совместимости. Это приведёт к изменению самого понятия. Прерывания обратной совместимости будет происходить только тогда, когда не может произойти автоматическое обновление, а для изменения кода требуется человек.
Попробовать RFC локально
Кроме того, любой может попробовать функцию из RFC локально сразу после создания PR в GitHub. Как? Github автоматически создаст временную версию со специальным тегом dev и отправит эту версию PHP в реестр пакетов. Вы создаёте RFC на добавления типизированных констант, отправляете его как PR на GitHub и через 1 минуту можете запустить sudo apt-get install php-dev-typed-constant, чтобы получить PHP с этим RFC на свой локальный компьютер.
Таким образом, программисты смогут попробовать эту функцию ещё до включения в основную ветку и даже до голосования по RFC. В таком случае даже голосование по новым функциям будет основано на реальных данных и опыте, а не на эмоциях, субъективных мнениях и аргументах.
Что ждёт нас в будущем?
В будущем наши возможности не будут ограничены нашей историей, прошлым выбором или быстро развивающимися технологиями, из-за которых наш код быстро устаревает. Всего за один клик все наши инструменты станут самыми современными на рынке на сегодняшний день.
Это позволит нам больше экспериментировать, проверять наши предположения и получать реальную обратную связь. Это приведёт к ещё более совершенной автоматизации процессов кодирования и изобретениям в языке, паттернах и архитектуре приложения, которые сегодня мы даже не можем себе представить.
«Лучший способ предсказать будущее — это создать его».
Счастливого создания!
kachkaev
Если в 2025 году вы по-прежнему будете программировать на ПХП, могу только посочувствовать.
OlegXxl Автор
Зря вы так, PHP очень стремительно развивается последнее время, но даже не принимая это во внимание статья не теряет своей актуальности, PHP в ней можно заменить на любой другой язык по желанию :)
amarao
Если заменить php на coq, что случится?
OlegXxl Автор
Вероятно для него и еще некоторых языков, к цифре в заголовке статьи надо будет добавить 12, чтобы получилось 2037, а там уже киберпанк и вот_это_вот_всё ;)
0xd34df00d
Взрыв мозга.
А потом кубы вместо сайтиков.
Хотя ИМХО coq как-то для инопланетян, dependent pattern matching там через зад, аннотации возвращаемых типов матча писать часто надо. Есть более годные языки.
amarao
Нам же обещали, что "оно всё само". Неужели так трудно найти решение для произвольно заданной массовой проблемы прямо в IDE?
(насчёт через зад — вся computer science через зад. Так же как и вторичноротые получаются выворачиванием ануса на место рта, так и современное программирование — это вывернутое "через зад". Но мы привыкли и считаем это ртом).
defuz
Это вы о том языке программирования, который создан специально для веб, и который до сих пор не поддерживает нативно UTF-8? Вылезайте уже из своего бункера. PHP может стремительно развиваться только на кладбище истории.
Самое емкое, на мой взгляд, описание настоящего и будущего PHP.SerafimArts
А что значит "нативно"? Это, типа, выбирать utf8 буквы как элементы массива? Или что?
defuz
Это типа иметь определенный на уровне языка или стандартной библиотеки тип «валидная UTF-8 строка» и набор методов или функций для работы с этим типом. То, как это реализовано в абсолютном большинстве современных языков программирования.
SerafimArts
Ну так в пыхе это и так всё есть. И UTF-8 строки, и функции для работы с ними. В чём претензии?
Блин, да хоть UTF-32/UCS-4, разница какая? PHP позволяет работать с чем угодно и как угодно. Хоть нижний с верхним суррогаты в обратном порядке соединять.
Предлагаю всё же более точно их высказывать, а то выглядит как "слышал звон".
defuz
В php нет типа «валидная utf-8 строка». Есть тип string, который по сути является произвольным набором байт, и который не дает каких-либо гарантий о своих значениях, тем самым перекладывая всю головную боль по работе со сложными кодировками с языка на разработчика.
Таким образом, в php вообще нет типа «строка», который соответствовал бы современным представлениям о том, что такое строки. Вместо этого тип «string» является тем, что в современных языках называется «массив байт», и создан лишь потому, что в php вообще нет нормальных массивов, а работать как-то с потоками байт необходимо.
Чтобы дать возможность «работать с чем угодно и как угодно» php предоставляет зоопарк функций, принимающие одинаковые аргументы и делающие одно и тоже, но корректно работающие только при выполнении разных неявных предположений (кодировки аргументов и ожидаемая кодировка результата), о которых должен знать и заботиться разработчик.
Я считаю такой подход примером плохого дизайна языка, и уж точно не считаю такой подход позволительным для языка, который ориентирован на веб-разработку.
Хорошо спроектированные языки программирования хороши тем, что дают разработчику определенные явные гарантии. Основная гарантия, которую дает php – существование гигабайт легаси кода, который все еще «приносит много денег», и который еще десятилетия кому-то прийдется поддерживать.
Таким образом, PHP – это Cobol нашего времени, полный странных и откровенно плохих архитектурных решений, которые никто не собирается исправлять, потому что поддержка легаси уже давно стала важнее развития языка.
SerafimArts
Спасибо за детализацию. Так действительно лучше и понятнее претензия.
Я не буду оспаривать утверждания, более того, согласен со всеми пунктами вводной части. Но есть одно "но", которое я не услышал: В чём проблема-то?
Или вы считаете, что
strlen('string'), который в PHP намного сложнееBuffer.byteLength('string', 'utf8'), который в "расово верных современных языках" (не будем тыкать пальцем)? Ну илиmb_strlen('string')сложнее выучить, нежели'string'.length?В любом случае, если в PHP, цитата "зоопарк функций", то в ваших "правильных" языках, очевидно, этот зоопарк как минимум в два раза больше, и даже способы работы отличаются (одно метод примитива, а другое статический метод класса), т.к. отличия в PHP для работы со строками и байтами заключается лишь в префиксе
mb_, в отличии примера в 3ем абзаце выше. Где для работы с байтами нужно учить ещё одну толпу всяких функций/методов.На всякий случай ещё раз повторю вопрос: Вот я вижу, что подход PHP намного удобнее. Более того — он мало чем вообще отличается от любого низкоуровневого языка. В чём проблема этого подхода и где удобство в ваших "современных языках", кроме озвученных тезисов "они хорошо спроектированы" и "я так привык", которые, очевидно, не несут никакого смысла?
defuz
Вы так и не сформулировали вопрос. Функция strlen возвращает количество байт в строке, разве нет?
Проблема не в том, чтобы выучить, а самой необходимости что-то учить. PHP увеличивает когнитивную нагрузку на разработчика, требуя крайне аккуратно обращаться со строками, либо поощряет пребывать в благом неведении, штампуя быдлокод.
Как раз в PHP зоопарк, потому что есть функции с одинаковым назначением и принимающим одинаковые типы, делающие одно и тоже, часто возвращающие одинаковый результат, и тем не менее реализованные по разному.
В «правильных» языках вы скорее всего увидите строгое разделение на понятие «массив байт» и понятие «строка» на уровне системы типов. Да, многие функции и методы могут быть продублированы, вот только ключевое отличие от PHP будет заключаться в том, что эти функции и методы будут применимы только к корректному типу, не позволяя их неверное использование.
Удобнее в сравнении с чем? Интересует, какие языки вы использовали на практике, чтобы сравнить.
Удобство в современных языках заключается в том, что если вы выполняете произвольные манипуляции со строками, на выходе вы получите валидную utf-8 строку. В PHP валидность строки никак не контролируется (потому что это накладные расходы, а PHP и так тормоз), так что обеспечение валидности возвращаемого значения (не говоря уже о его корректности) перекладывается на плечи разработчика.
Если в 2020 сайт генерирует некорректную кодировку – в 95% случаев это заслуга PHP. Такое отношение к строкам может быть простительно C/C++, которые являются системными языками с упором на производительность и контроль. Но видеть подобный подход в высокоуровневом интерпретируемом языке предназначенном для веб-разработки – это мрак.
0xd34df00d
Зависит от того, что именно вам нужно. Найти подстроку в строке? Кодировка тут неважна, можно обращаться с байтиками.
Найти подстроку без учёта регистра? Кодировки недостаточно, нужна локаль.
Отсортировать с учётом вывода пользователю? Локаль.
Взять первые N символов? Локаль.
Если строка не притворяется умеющей в уникод и всё это делающей, а ведёт себя как набор байт, то от неё нет соответствующих ожиданий, и (по опыту, по крайней мере) куда выше вероятность, что программист задумается, как правильно обрабатывать все эти случаи. А если программист не задумывается, то потом у него в его английской локали с латиницей всё работает, а у турков каких-нибудь всё ломается.
defuz
Разве? Если мы говорим о UTF-8, то мне кажется что разделение на codepoints и графемы универсально и не зависит от локали.
В целом я согласен с вашим комментарием, но я думаю, что строку, ведущей себя как набор байт следует честно называть – bytearray например, а не строкой.
К примеру, в Rust любой String – это гарантированно валидная UTF-8 строка, и хоть на уровне построения этот тип является оберткой над динамическим массивом байт (Vec), его набор методов значительно отличается от массива. К примеру, нельзя индексироваться по элементам (s[3]), чтобы разработчикам не пришло в голову таким образом «взять третий символ», но зато можно итерироваться по символам.
0xd34df00d
Которые, насколько я знаю, зависят от языка в общем случае? А как?
Я когда-то изучал немецкий и отдалённо помню (ну, кроме du bist scheisse), что буква-как-бета иногда пишется как ss (кстати, единственная запомненная мной фраза выше — живой пример). Но это одна буква. Или нет? Или мне надо прекратить писать код и на самом деле позвать лингвиста или сесть и почитать маны?
Попытки закоса под умение в UTF-8 это всё скрывают.
Да. Но отсутствие string прям в стандартной библиотеке лично меня не сильно печалит.
Тем более, что bytearray не сильно хуже — например, если вам нужно (вдруг) считать расстояние Левенштейна между строками, дабы вывести первые N совпадений, то обработка строк как байт даёт результаты не сильно хуже, чем обработка строк как символов (или графем? или что тут вообще считать за расстояние?), но работает на порядок быстрее.
defuz
И да, это означает что подобная трансформация может идти в разрез с грамматикой языков. Но, если задуматься, стандарт юникод и не обязан строго следовать текущим правилам грамматики, потому что грамматические правила изменчивы, а однообразное отображение символов – нет.
С точки зрения написания (но не произношения) это даже не буква, а лигатура, как например "?" или "?". Изначально у нее не было даже своего места в алфавите, как и заглавного начертания. Таким образом, SS всегда были и остаются двумя раздельными буквами.
Дизайнеры юникода и шрифтов предусмотрительно потрудились и нарисовали заглавный вариант: ? — ? (Latin Capital Letter Sharp S). А с 2017 года совет по немецкому правописанию окончательно одобрил использование заглавного варианта, так что теперь оба варианта верны: SCHEISSE и SCHEI?E. Выходит, что только последние два года ? можно считать полноценной буквой, а не сокращенным способом написания двух других букв.
Лично меня печалит что все повсеместно используют юникод, но никто не удосуживается полноценно следовать его правилам.
Хорошо если работа с текстом ограничивается последовательностью принял-сконкатенировал-передал, но если начинаются внутренние модификации, почти наверняка можно наделать ерунды.
chapuza
Зависит от степени вашего перфекционизма. Смотрите, движок хрома умеет:
А руби из коробки (сам пример) — нет. Подозреваю, что вообще мало, кто умеет (хотя, вроде бы, очевидно ожидать, что
"man?ana"и"manana"должны по поиску"man"находиться оба, нет? — я там где-то недалеко подробно объясняю, почему тут такой внезапный результат).Нет. И
ucs, иutfкодировки дают однозначный ответ на вопрос о количестве символов, локаль тут ни при чем.Как описано в спецификации консорциума.
А еще можно сделать правильно. Я в 2012 году писал проект на руби, там было много юникода — так вот я сел, подумал, и для начала распарсил спеку консорциума — ссылка просто пруф, код там наколеночный, но все же. Примерно в то же время автор эликсира Jose? Valim — сделал ровно то же самое для языка (поэтому эликсир по-настоящему умеет тип «юникодная строка»). Насколько мне известно, кроме нас двоих эта бесхитростная идея (которая работает сейчас, и для всех будущих спецификаций юникода) пока никому в голову не приходила.
И ваш пример с эсцетом (?) — тоже описан в спецификации. Как и строчная сигма на конце греческих слов, и строчная «и» без точки в турецком. Нужно просто применять всю спецификацию, а не то, что получилось имплементировать до релиза.
AnthonyMikh
Извините, а что вы называете символом?
chapuza
Вы не до конца понимаете суть проблемы, к сожалению. Так же, примерно, как американцы, изобретавшие кодировку ASCII-7. Вот смотрите, код на эликсире:
Сигма в нижнем регистре пишется по-разному в середине и на конце слов.
А ведь еще есть комбинированная диакритика. Пример на руби.
Почему? А вот так: в первом слове это одна буква — наследие LATIN, во втором — обычная
nи «комбинированная тильда».В эликсире все, конечно, работает из коробки:
Как там в PHP вот со всеми этими тонкостями? Длину-то посчитать можно и на коленке за пять минут хоть на ассемблере.
SerafimArts
Очень крутой пример. Действительно воспроизводится некорректно. Но разве это не баг библиотеки icu, которая и занимается переводом в верхний/нижний регистр? Ну т.е. то что при работе, она не проверяет окончание? Выглядит как оно самое.
Да, PHP выдаёт тоже самое, только наоборот: 7 для первого слова и 6 для второго (Кажется это вы просто перепутали их местами). В любом случае умляут в первом слове и PHP выделяет его как отдельный символ. Т.е. поведение по умолчанию аналогично Ruby.
Допускаю, что есть какие-то хитрости с дополнительным указанием локали. Или какой-нибудь сантинайзер/нормалайзер. Просто т.к. мне не приходилось с подобным работать — вообще контраргументов никаких не имею)). Эликсир круто показывает себя в этом плане.
chapuza
«На нашей машине все работает», да. Какая мне, в сущности, разница баг чего именно это? Есть язык программирования, есть грек, который при использовании этого языка программирования всего-то хочет строку в нижний регистр перевести.
Ну и да, разумеется,
icuможет, если ее научить.Ага, пардон.
Это не умляут. Умляут — это фонетическое явление сингармонизма в германских языках, и знак, его обозначающий — не путать с диерезисом (тремой). В испанском это — тильда. </занудство>
Что, мягко говоря, неожиданно, правда? Кстати, в руби можно все исправить, если нормализовать строки руками:
Диакритика используется примерно во всех языках, за редким исключением. Даже в английском встречается диерезис («nai?ve»). Мы же тут обсуждаем качество работы с произвольным юникодом, да? Ну вот представьте себе, что вы норвег, датчанин, или грек.
Причем не только сейчас, а и в будущем, когда добавят очередной клингонский, он будет обработан корректно. Потому что вместо того, чтобы взять стороннюю библиотеку из прошлого века (хорошую, тут сказать нечего, но очень громоздкую и с кучей легаси) — автор эликсира Jose? Valim (всяческих благ его родителям, наделившим парня именем с акутом) сделал правильно. А именно, компилятор парсит спеку консорциума.
VolCh
PHP тоже так умеет:
essome
Я конечно все понимаю, но хейтить язык из-за такой мелочи?
Мне за 8 лет не приходилось с такой проблемой сталкиваться.
Если у вас проект завязан на подобные вещи — php вам не подходит и используйте «правильные языки»
Но для веба ничего лучше php пока не придумали и подтверждение этому — миллионы приложений бекенд которых написан на php.
AnthonyMikh
Для финансов ничего лучше COBOL не придумали, и подтверждение этому — тысячи банковских систем, написанных на COBOL. /s
chapuza
Никто язык не хейтит. Я просто указал на то, что он непригоден для работы со строками в мультиязыковой среде. То есть — в частности — в вебе.
Вы не в курсе ? ничего не придумали. Давно придумали. Даже тот же эликсир кроет php как бык овцу: https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections
Миллионы леммингов не могут ошибаться? Это так себе аргумент.
VolCh
На совсем не типичных для PHP задачах…
chapuza
На типичных тоже кроет :) И на скорости разработки кроет. И на отказоустойчивости тоже.
У вас в коде комбинированная тильда потерялась, но я верю, что может. Просто это, как и в руби, — костыль.
essome
фреймворк — пожалуйста, а CMS просто не нужны никому, кроме галер, кропающих лендинги для парикмахерских. Но там — и существующих решений достаточно.
А еще я обожаю аргумент «вебсокеты, для которых язык программирования веба не предназначен» в 2020 году.
Про «что написали» — еще раз для особо одаренных: миллионы леммингов могут ошибаться (ну и написали таки кое-что: дискорд там, пинтерест, файненшл таймс, тойота каршеринг, ченджорг), причем на ванильном компиляторе, без необходимости чуть не полностью его переписывать, как это случилось в FB.
Я не агитирую же: нравится вам кактусы есть — ешьте в свое удовольствие. Просто не нужно говорить, что пхп жив почему-то еще, кроме огромной армии не желающих и не способных переучиться кодеров.
VolCh
Прежде всего он жив потому, что заказчики и работодатели платят за решения на нём.
chapuza
Заказчики платят за продукт, а не за язык. Работодатели — платят за человекочасы, а не за язык.
Больше всего (по моему опыту) в 2020 платят за КОБОЛ. Чаще всего — за пхп, потому что найти сотого разработчика в команду из 99 — на пхп проще.
Продуктовые же компании, кроме совсем бедных и упоротых, — в сторону пхп уже лет десять не смотрят.
Если совсем упрощать, то: проще найти 50 инженеров, которые будут поддерживать вотцап на эрланге, чем 10К, которые все равно не смогут поддержать его аккуратно на пхп. Я вообще забывать начал, что такое защитное программирование — за меня все язык и среда исполнения делает, буквально.
А с появлением волшебного LiveView, когда для интерактивного взаимодействия со страницей вдруг оказался не нужен JS — все стало вообще абсолютно шоколадно.
VolCh
Как заказчики, так и работодатели без особого восторга относятся к идеям "а давайте всё перепишем на новую технологию, в активном поиске работы по которой два человека на страну и хотят денег как два тимлида. Каждому. А нас всех увольняйте"
chapuza
Я сам всегда первый противник все переписывать.
Но в мире возникают новые продукты. И вот для них проще и дешевле взять что-то чуть более приспособленное к высокой конкурентности и отказоустойчивости.
И даже в случае старого продукта — вместо того, чтобы обмазывать новыми слоями глины монолит — можно начать отчуждать части в микросервисы, а там уже не так важно, какой язык.
Ну и уж если мы в Барселоне смогли собрать команду в офис из дюжины очень сильных разработчиков на эликсире — проблема кадров выглядит слегка надуманной (за пределами поселков городского типа).
VolCh
Вот прямо сейчас отчуждаю. На PHP 7.4 Не важно же какой язык. :) Вот будет вакансий и резюме на Элексире в Киеве (раза в два меньше Барселоні, если верить вики) в количестве сравнимом хотя бы с Go — можно будет подумать, что-то неважное и простое отчудить и сравнить скорость разработки и требуемые серверные мощности.
Правда не очень честное сравнение будет если напрямую сравнивать скорость разработки на ПХП людей, годами и даже десятилетиями на нём писавших и тех же людей, в первых раз Элексир увидевших. Сколько процентов форы дать Элексиру?
chapuza
Кто кого куда меньше? В Барселоне живет 2 млн человек, из которых миллион — туристы, а еще миллион — работники сферы обслуживания туристов :)
Заметно снижаются, об этом куча саксесс сториз в интернете.
Я лично переходил из руби, у которого чуть ближе синтаксис (но парадигма гораздо ближе к пхп). Через месяц я писал на эликсире с такой же скоростью, как на руби (а я хорошо на руби пишу, можно на SO убедиться). Но не это главное.
Плохого кода (труднотестируемого, невнятного, переусложненного, с лишними абстракциями, с недостающими абстракциями, просто «чёта он какой-то убогий») — стало в разы меньше, время на отладку сократилось очень значительно.
То есть если мерить не LOCами в час, а выхлопом — через два месяца новички на эликсире должны догнать команду пхп и начать быстро обгонять. По моим прогнозам.
Но тут главное — силком не тащить. Если человеку парадигма не понравится — он будет только упираться, и толку не выйдет. Зато если понравится — отдача будет очень заметна. Особенно в отказоустойчивости и понятности кода через год.
sumanai
А как это язык влияет на говнокод?
chapuza
Напрямую.
for,whileи т. п. —foldили рекурсия,Если одним словом: неправильный код выгляди некрасиво, и это видно даже совсем новичкам.
sumanai
В смысле нельзя? Язык не тьюринг полный?
0xd34df00d
Явная рекурсия — это goto функционального программирования. foldl/foldr, scanl/scanr, unfold, и прочие схемы полущ.
VolCh
То ли Гугл, то ли зрение подвело. 3,7 млн видел вроде на подсказках или как их там, не переходя на страницу.
Это с каким-нибудь Хаскель бэкграундом или те же пехепешники с ООП-головного мозга?
chapuza
Не, я вообще не уверен, что хаскель можно показывать людям до того, как они будут себя чувствовать свободно во всех парадигмах и минимум в пяти языках :)
Вообще, я вступаю на очень скользкий путь: я очень далек от того, чтобы давать какие-нибудь советы, или там гарантировать что-нибудь. Я лишь делюсь своим личным, сугубо интимным мнением и опытом.
Эликсир как раз очень плавно вводит в ФП, и то, как оно все устроено (акцент на отказоустойчивости, деревья супервизиров, let it crash, модель акторов, минимум типов данных, и т. п.) может либо прямо очень очаровать, либо нет. И если да — бэкграунд не так важен, даже хорошо, что люди сразу видят, как оно бывает в сто раз внятнее. Если же нет — повторюсь, насиловать не нужно. Когда человеку противен аромат дыни, его не заставить полюбить ее вкус принудительным вскармливанием.
0xd34df00d
Как раз, что касается ФП-парадигм, лучше имхо начинать с хаскеля. У меня достаточно большая выборка наблюдений людей, которые начинали с хаскеля или же со скалы какой-нибудь, и результат таки разный. Да, вторые быстрее пишут свою первую программу, но первые в долгосрочной перспективе как-то заруливают.
Вот type-driven development на примере хаскеля уже больно показывать.
chapuza
Куда? Не, серьезно, ну нужны же метрики какие-то. А то я подозреваю, чем нарковывернутее код, тем больше он вам лично зарулит :)
За скалу не скажу, у меня очень поверхностный опыт (я только один проект на хадупе кхм консультировал и сам написал не более тысячи строк) — но все же у меня остался привкус переусложненности и попытки заколачивать многие шурупы микроскопами, просто потому что ФП. Не знаю, как осуществляется вход именно в скалу, но если из Java/.NET — то та же виртуальная машина все-таки очень сильно мешает чистой смене парадигмы. Лучше сравнивать c входом в
OCamlили дажеScheme.Могу сказать за себя: мне в хаскеле очень мешает то, что с одной стороны для тривиального односвязного списка мне придется возиться с монадами, а с другой — если не нравится, что все вычисления ленивые — то вот стриктнесс хак (
!) для жадных. Ну и самых ужас — это то, что существует и приветствуется практика (я говорил уже) втащить миллиард разных функций и операторов в локальное пространство имен и всеми ими пользоваться. Для человека, который привык учиться, читая и разбирая чужой код — это нереальный шоу-стоппер.Его больно показывать на всем в сегодняшнем мире, потому что кроме настоящих энтузиастов, которых примерно промилле, — есть еще крепкие профессионалы, которым хочется все-таки полученные знания применить. Чистая наука — восторг, но прикладые аспекты тоже важны. И тот же Idris все-таки вынудит вас сказать: «это было круто, а теперь давайте портируем это на питон и запустим». Ну, утрирую слегка. Это было бы круто рассказывать в институтах, юнцам с горящими глазами, но не профи, запустившим и поддерживающим какой-нибудь SaaS на 1М юников.
AnthonyMikh
Минуточку, а зачем для списка учить понятие монады?
concatMapи:[]/\x -> [x]соответствуют>>=иreturn/pure, но определены только на списках.chapuza
Вот именно это я и считаю раковой опухолью: восемьсот способов сделать тривиальныю вещь.
Но дело не в этом, я имел в виду «чтобы написать свою реализацию», а не чтобы «использовать один из ста готовых способов».
AnthonyMikh
Именно свою реализацию
concatMapили реализацию интерфейса монады для списка?essome
Посмотрел язык и фреймворк.
Может все конечно так красиво как вы и говорите, я даже подумал попробовать, но потом посмотрел, что язык чистый фп и понял, что не смогу)
Я не фанатик ООП и не противник ФП части первого и второго использую в своих проектах.
Например: стараюсь избегать for, foreach и использую map, reduce итд, но вызывать такие вещи лично мне удобнее $collection->map(callback), а не map($collection, callback);
Так же не представляю, что-бы я писал не $user->save(), а saveUser($user);
Возможно эликсир и быстрее в некоторых задачах, но то, что скорость разработки на нем выше чем на php я все же не поверю, думаю тут больше зависит от прослойки между монитором и креслом, а не от языка.
В каком-то комментарии вы писали, что у вас очень сильная команда «эликсирщиков» думаю это как раз та причина по которой ваша скорость разработки высока, вы сравниваете свою сильную команду с командой которая клепает лендосы на php.
Но на php тоже есть сильные команды, просто из-за большого количества php разработчиков — вы больше видите слабые.
essome
фейсбук, вк, хабр, баду?
Что написали на эликсире кроме вебсокетов для которых пхп как раз не предназначен?
Покажите мне на эликсире фреймворк уровня симфони или ларавель, где я могу с легкостью быстро и качественно разработать среднее приложение.
Или покажите мне на эликсире такую же простую cms как wordpress или drupal
Когда создадите/создадут в эликсире такую же мощную экосистему для веб разработки — тогда можем и поспорить, сейчас же, ничего лучше php для веба нет.
Да, на эликсир или С можно написать что-бы работало быстрее и возможно где-то правильнее, но пока вы будете это делать — проект на php уже будет продаваться и если этот проект писали не джуны — для конечного пользователя разницы не будет, все будет работать так же быстро и так же без багов как и было бы на других языках.
Kanut
То естъ кроме элексира и php других вариантов для веба не существует? :)
0xd34df00d
Фейсбук не на пхп. Как только там стали появляться нагрузки, так начали пилить HHVM, прикручивать статическую типизацию, и так далее.
У вк тоже какие-то свои костыли вроде были.
У меня был сайт на друпале. На шестом. Мигрировать на восьмой я не осилил, в итоге оказалось проще (для моих задач, естественно) написать статический сайт на hakyll и сделать единоразовое преобразование из дампа друпальной БД в набор .md-документов.
essome
Вот зачем вы рассказываете о том, в чем не разбираетесь?
HHVM Не язык и потребность в нем отпала после выхода php 7
AnthonyMikh
А разве Facebook не начала переход на HHVM задолго до того, как вышел PHP 7?
sumanai
Ну да. И чему это противоречит? У 5 версии были проблемы со скоростю на нагрузках уровня FB, они её решили сами. Потом вышла 7 версия, и нужна в ограниченном решении пропала.
chapuza
Это
ерундамиф (про эликсир, не про си, конечно).Разработка на эликсире в сравнении с пхп на основе моего опыта примерно в пять раз быстрее, при одинаковом уровне разработчиков. И в два-три раза быстрее, чем на руби.
Нет. Вот моя заметка, англ. про скорость (пример синтетический, но легитимный): лукап в хэшмапе из 1М элементов и возврат значения, полноценный HTTP-сервер. Скорость отклика менее сотни микросекунд. Не милли. Микро.
Ничего близко похожего на пхп не сделать.
sumanai
А потом мы идём в базу данных…
chapuza
И да, и нет.
Во-первых, далеко не все приложения вообще нуждаются в базе.
Во-вторых, в ORM на любом объектном языке вам придется руками бороться с
N+1, а иммутабельный язык просто не даст построить такой запрос по определению.В-третьих, если запрос сложный, его надо будет процессить, и эликсир из коробки разрешит это сделать параллельно, с почти нулевым оверхедом по коду.
Ну и так далее.
sumanai
Можно больше подробностей? Не понимаю как это вообще связано с иммутабельностью.
hard_sign
Только COBOL, только хардкор!
essome
А аргументы будут?
Или все тот же «пробовал php4 не понравилось»?