Комментарии 143

Если в 2025 году вы по-прежнему будете программировать на ПХП, могу только посочувствовать.

Зря вы так, PHP очень стремительно развивается последнее время, но даже не принимая это во внимание статья не теряет своей актуальности, PHP в ней можно заменить на любой другой язык по желанию :)
Вероятно для него и еще некоторых языков, к цифре в заголовке статьи надо будет добавить 12, чтобы получилось 2037, а там уже киберпанк и вот_это_вот_всё ;)

Взрыв мозга.


А потом кубы вместо сайтиков.


Хотя ИМХО coq как-то для инопланетян, dependent pattern matching там через зад, аннотации возвращаемых типов матча писать часто надо. Есть более годные языки.

Нам же обещали, что "оно всё само". Неужели так трудно найти решение для произвольно заданной массовой проблемы прямо в IDE?


(насчёт через зад — вся computer science через зад. Так же как и вторичноротые получаются выворачиванием ануса на место рта, так и современное программирование — это вывернутое "через зад". Но мы привыкли и считаем это ртом).

Это вы о том языке программирования, который создан специально для веб, и который до сих пор не поддерживает нативно UTF-8? Вылезайте уже из своего бункера. PHP может стремительно развиваться только на кладбище истории.

Сегодня мы боремся с техническим долгом (что бы это ни означало), с устаревшим кодом, который сложно поддерживать и дорого изменять, но, в то же время, он генерирует много денег.
Самое емкое, на мой взгляд, описание настоящего и будущего PHP.
поддерживает нативно UTF-8?

А что значит "нативно"? Это, типа, выбирать utf8 буквы как элементы массива? Или что?

Это типа иметь определенный на уровне языка или стандартной библиотеки тип «валидная UTF-8 строка» и набор методов или функций для работы с этим типом. То, как это реализовано в абсолютном большинстве современных языков программирования.

Ну так в пыхе это и так всё есть. И UTF-8 строки, и функции для работы с ними. В чём претензии?


Блин, да хоть UTF-32/UCS-4, разница какая? PHP позволяет работать с чем угодно и как угодно. Хоть нижний с верхним суррогаты в обратном порядке соединять.


Предлагаю всё же более точно их высказывать, а то выглядит как "слышал звон".


P.S. А что есть "валидная utf-8 строка"? Почему язык должен мне диктовать как соединять суррогаты? Привязывать обычную последовательность байт к спеке, которая раз в год обновляется — это попахивает недальновидностью и фатальным устареванием всего языка каждый год. Нужно проверить строку — "проверяй, пожалуйста, вот тебе пачка функций для проверок". Но на уровне ядра зашиваться на это — глупо, только проблем добавляет.

В php нет типа «валидная utf-8 строка». Есть тип string, который по сути является произвольным набором байт, и который не дает каких-либо гарантий о своих значениях, тем самым перекладывая всю головную боль по работе со сложными кодировками с языка на разработчика.

Таким образом, в php вообще нет типа «строка», который соответствовал бы современным представлениям о том, что такое строки. Вместо этого тип «string» является тем, что в современных языках называется «массив байт», и создан лишь потому, что в php вообще нет нормальных массивов, а работать как-то с потоками байт необходимо.

Чтобы дать возможность «работать с чем угодно и как угодно» php предоставляет зоопарк функций, принимающие одинаковые аргументы и делающие одно и тоже, но корректно работающие только при выполнении разных неявных предположений (кодировки аргументов и ожидаемая кодировка результата), о которых должен знать и заботиться разработчик.

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

Хорошо спроектированные языки программирования хороши тем, что дают разработчику определенные явные гарантии. Основная гарантия, которую дает php – существование гигабайт легаси кода, который все еще «приносит много денег», и который еще десятилетия кому-то прийдется поддерживать.

Таким образом, PHP – это Cobol нашего времени, полный странных и откровенно плохих архитектурных решений, которые никто не собирается исправлять, потому что поддержка легаси уже давно стала важнее развития языка.

Спасибо за детализацию. Так действительно лучше и понятнее претензия.


Я не буду оспаривать утверждания, более того, согласен со всеми пунктами вводной части. Но есть одно "но", которое я не услышал: В чём проблема-то?


Или вы считаете, что strlen('string'), который в PHP намного сложнее Buffer.byteLength('string', 'utf8'), который в "расово верных современных языках" (не будем тыкать пальцем)? Ну или mb_strlen('string') сложнее выучить, нежели 'string'.length?


В любом случае, если в PHP, цитата "зоопарк функций", то в ваших "правильных" языках, очевидно, этот зоопарк как минимум в два раза больше, и даже способы работы отличаются (одно метод примитива, а другое статический метод класса), т.к. отличия в PHP для работы со строками и байтами заключается лишь в префиксе mb_, в отличии примера в 3ем абзаце выше. Где для работы с байтами нужно учить ещё одну толпу всяких функций/методов.


На всякий случай ещё раз повторю вопрос: Вот я вижу, что подход PHP намного удобнее. Более того — он мало чем вообще отличается от любого низкоуровневого языка. В чём проблема этого подхода и где удобство в ваших "современных языках", кроме озвученных тезисов "они хорошо спроектированы" и "я так привык", которые, очевидно, не несут никакого смысла?

В чём проблема-то?
Проблема в том, что как я уже сказал, язык перекладывает головную боль на плечи разработчика. Чтобы корректно работать с каждым экземпляром типа string, необходимо помнить в какой кодировке оно было закодировано. Более того, некорректное использование string не только не запрещается, но и неявно поощряется тем, что в значительном количестве случаев (но не всех) возвращается ожидаемое разработчиком значение. Так, к примеру, strlen возвращает корректное количество символов в utf-8 строках, если в них использован только ASCII диапазон (коды 0-127).

Или вы считаете, что strlen('string'), который в PHP намного сложнее Buffer.byteLength('string', 'utf8'), который в «расово верных современных языках» (не будем тыкать пальцем)?
Вы так и не сформулировали вопрос. Функция strlen возвращает количество байт в строке, разве нет?

Ну или mb_strlen('string') сложнее выучить, нежели 'string'.length?
Проблема не в том, чтобы выучить, а самой необходимости что-то учить. PHP увеличивает когнитивную нагрузку на разработчика, требуя крайне аккуратно обращаться со строками, либо поощряет пребывать в благом неведении, штампуя быдлокод.

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

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

Вот я вижу, что подход PHP намного удобнее. Где удобство в ваших «современных языках»?
Удобнее в сравнении с чем? Интересует, какие языки вы использовали на практике, чтобы сравнить.

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

Если в 2020 сайт генерирует некорректную кодировку – в 95% случаев это заслуга PHP. Такое отношение к строкам может быть простительно C/C++, которые являются системными языками с упором на производительность и контроль. Но видеть подобный подход в высокоуровневом интерпретируемом языке предназначенном для веб-разработки – это мрак.
Чтобы корректно работать с каждым экземпляром типа string, необходимо помнить в какой кодировке оно было закодировано.

Зависит от того, что именно вам нужно. Найти подстроку в строке? Кодировка тут неважна, можно обращаться с байтиками.
Найти подстроку без учёта регистра? Кодировки недостаточно, нужна локаль.
Отсортировать с учётом вывода пользователю? Локаль.
Взять первые N символов? Локаль.


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

Найти подстроку без учёта регистра? Кодировки недостаточно, нужна локаль.
Unicode стандартизирует lower/upper/title case трансформации. Хоть я согласен что в большинстве случаев это не то что вам нужно.

Взять первые N символов? Локаль.
Разве? Если мы говорим о UTF-8, то мне кажется что разделение на codepoints и графемы универсально и не зависит от локали.

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

К примеру, в Rust любой String – это гарантированно валидная UTF-8 строка, и хоть на уровне построения этот тип является оберткой над динамическим массивом байт (Vec), его набор методов значительно отличается от массива. К примеру, нельзя индексироваться по элементам (s[3]), чтобы разработчикам не пришло в голову таким образом «взять третий символ», но зато можно итерироваться по символам.
Unicode стандартизирует lower/upper/title case трансформации.

Которые, насколько я знаю, зависят от языка в общем случае? А как?


Разве? Если мы говорим о UTF-8, то мне кажется что разделение на codepoints и графемы универсально и не зависит от локали.

Я когда-то изучал немецкий и отдалённо помню (ну, кроме du bist scheisse), что буква-как-бета иногда пишется как ss (кстати, единственная запомненная мной фраза выше — живой пример). Но это одна буква. Или нет? Или мне надо прекратить писать код и на самом деле позвать лингвиста или сесть и почитать маны?


Попытки закоса под умение в UTF-8 это всё скрывают.


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

Да. Но отсутствие string прям в стандартной библиотеке лично меня не сильно печалит.


Тем более, что bytearray не сильно хуже — например, если вам нужно (вдруг) считать расстояние Левенштейна между строками, дабы вывести первые N совпадений, то обработка строк как байт даёт результаты не сильно хуже, чем обработка строк как символов (или графем? или что тут вообще считать за расстояние?), но работает на порядок быстрее.

Которые, насколько я знаю, зависят от языка в общем случае? А как?
Предлагая универсальную локально-независимую систему, которая полезна как раз когда нужна консистентная нормализация, которая не будет зависеть от локали.

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

… буква-как-бета иногда пишется как ss [...]. Но это одна буква. Или нет?
С точки зрения написания (но не произношения) это даже не буква, а лигатура, как например "ff" или "æ". Изначально у нее не было даже своего места в алфавите, как и заглавного начертания. Таким образом, SS всегда были и остаются двумя раздельными буквами.

Дизайнеры юникода и шрифтов предусмотрительно потрудились и нарисовали заглавный вариант: ß — ẞ (Latin Capital Letter Sharp S). А с 2017 года совет по немецкому правописанию окончательно одобрил использование заглавного варианта, так что теперь оба варианта верны: SCHEISSE и SCHEIẞE. Выходит, что только последние два года ẞ можно считать полноценной буквой, а не сокращенным способом написания двух других букв.

Но отсутствие string прям в стандартной библиотеке лично меня не сильно печалит.
Лично меня печалит что все повсеместно используют юникод, но никто не удосуживается полноценно следовать его правилам.

Хорошо если работа с текстом ограничивается последовательностью принял-сконкатенировал-передал, но если начинаются внутренние модификации, почти наверняка можно наделать ерунды.
Найти подстроку в строке? Кодировка тут неважна, можно обращаться с байтиками.

Зависит от степени вашего перфекционизма. Смотрите, движок хрома умеет:


%w|mañana mañana|.map(&:length)


А руби из коробки (сам пример) — нет. Подозреваю, что вообще мало, кто умеет (хотя, вроде бы, очевидно ожидать, что "mañana" и "mañana" должны по поиску "mañ" находиться оба, нет? — я там где-то недалеко подробно объясняю, почему тут такой внезапный результат).


Взять первые N символов? Локаль.

Нет. И ucs, и utf кодировки дают однозначный ответ на вопрос о количестве символов, локаль тут ни при чем.


Которые, насколько я знаю, зависят от языка в общем случае? А как?

Как описано в спецификации консорциума.


у турков каких-нибудь всё ломается

А еще можно сделать правильно. Я в 2012 году писал проект на руби, там было много юникода — так вот я сел, подумал, и для начала распарсил спеку консорциума — ссылка просто пруф, код там наколеночный, но все же. Примерно в то же время автор эликсира José Valim — сделал ровно то же самое для языка (поэтому эликсир по-настоящему умеет тип «юникодная строка»). Насколько мне известно, кроме нас двоих эта бесхитростная идея (которая работает сейчас, и для всех будущих спецификаций юникода) пока никому в голову не приходила.


И ваш пример с эсцетом (ß) — тоже описан в спецификации. Как и строчная сигма на конце греческих слов, и строчная «и» без точки в турецком. Нужно просто применять всю спецификацию, а не то, что получилось имплементировать до релиза.

Так, к примеру, strlen возвращает корректное количество символов в utf-8 строках, если в них использован только ASCII диапазон (коды 0-127).

Извините, а что вы называете символом?

Вы не до конца понимаете суть проблемы, к сожалению. Так же, примерно, как американцы, изобретавшие кодировку ASCII-7. Вот смотрите, код на эликсире:


"Ελλάς"
|> String.upcase()
|> IO.inspect()
|> String.downcase(:greek)
|> String.capitalize()
|> IO.inspect()

#⇒ "ΕΛΛΆΣ"
#⇒ "Ελλάς"

Сигма в нижнем регистре пишется по-разному в середине и на конце слов.


А ведь еще есть комбинированная диакритика. Пример на руби.


%w|mañana mañana|.map(&:length)
#⇒ [6, 7]

Почему? А вот так: в первом слове это одна буква — наследие LATIN, во втором — обычная n и «комбинированная тильда».


В эликсире все, конечно, работает из коробки:


~w|mañana mañana|
|> Enum.map(&String.graphemes/1)
|> IO.inspect()
#⇒ [["m", "a", "ñ", "a", "n", "a"], ["m", "a", "ñ", "a", "n", "a"]]
|> Enum.map(&Enum.join/1)
#⇒ ["mañana", "mañana"]

Как там в PHP вот со всеми этими тонкостями? Длину-то посчитать можно и на коленке за пять минут хоть на ассемблере.

Сигма в нижнем регистре пишется по-разному в середине и на конце слов.

Очень крутой пример. Действительно воспроизводится некорректно. Но разве это не баг библиотеки icu, которая и занимается переводом в верхний/нижний регистр? Ну т.е. то что при работе, она не проверяет окончание? Выглядит как оно самое.


А ведь еще есть комбинированная диакритика. Пример на руби.

Да, PHP выдаёт тоже самое, только наоборот: 7 для первого слова и 6 для второго (Кажется это вы просто перепутали их местами). В любом случае умляут в первом слове и PHP выделяет его как отдельный символ. Т.е. поведение по умолчанию аналогично Ruby.


Допускаю, что есть какие-то хитрости с дополнительным указанием локали. Или какой-нибудь сантинайзер/нормалайзер. Просто т.к. мне не приходилось с подобным работать — вообще контраргументов никаких не имею)). Эликсир круто показывает себя в этом плане.

разве это не баг библиотеки icu

«На нашей машине все работает», да. Какая мне, в сущности, разница баг чего именно это? Есть язык программирования, есть грек, который при использовании этого языка программирования всего-то хочет строку в нижний регистр перевести.


Ну и да, разумеется, icu может, если ее научить.


перепутали их местами

Ага, пардон.


В любом случае умляут в первом слове

Это не умляут. Умляут — это фонетическое явление сингармонизма в германских языках, и знак, его обозначающий — не путать с диерезисом (тремой). В испанском это — тильда. </занудство>


PHP выделяет его как отдельный символ

Что, мягко говоря, неожиданно, правда? Кстати, в руби можно все исправить, если нормализовать строки руками:


%w|mañana mañana|.map do |s|
  s.unicode_normalize(:nfc).length
end
#⇒ [6, 6]

мне не приходилось с подобным работать

Диакритика используется примерно во всех языках, за редким исключением. Даже в английском встречается диерезис («naïve»). Мы же тут обсуждаем качество работы с произвольным юникодом, да? Ну вот представьте себе, что вы норвег, датчанин, или грек.


Эликсир круто показывает себя в этом плане.

Причем не только сейчас, а и в будущем, когда добавят очередной клингонский, он будет обработан корректно. Потому что вместо того, чтобы взять стороннюю библиотеку из прошлого века (хорошую, тут сказать нечего, но очень громоздкую и с кучей легаси) — автор эликсира José Valim (всяческих благ его родителям, наделившим парня именем с акутом) сделал правильно. А именно, компилятор парсит спеку консорциума.

Кстати, в руби можно все исправить, если нормализовать строки руками:

PHP тоже так умеет:


foreach (['manana', 'mañana'] as $word){
  echo mb_strlen(Normalizer::normalize($word));
}
#66
Я конечно все понимаю, но хейтить язык из-за такой мелочи?
Мне за 8 лет не приходилось с такой проблемой сталкиваться.
Если у вас проект завязан на подобные вещи — php вам не подходит и используйте «правильные языки»
Но для веба ничего лучше php пока не придумали и подтверждение этому — миллионы приложений бекенд которых написан на php.

Но для веба ничего лучше php пока не придумали и подтверждение этому — миллионы приложений бекенд которых написан на php.

Для финансов ничего лучше COBOL не придумали, и подтверждение этому — тысячи банковских систем, написанных на COBOL. /s

хейтить язык из-за такой мелочи?

Никто язык не хейтит. Я просто указал на то, что он непригоден для работы со строками в мультиязыковой среде. То есть — в частности — в вебе.


для веба ничего лучше php пока не придумали

Вы не в курсе ≠ ничего не придумали. Давно придумали. Даже тот же эликсир кроет php как бык овцу: https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections


миллионы приложений бекенд которых написан на php

Миллионы леммингов не могут ошибаться? Это так себе аргумент.

Даже тот же эликсир кроет php как бык овцу:

На совсем не типичных для PHP задачах…

На типичных тоже кроет :) И на скорости разработки кроет. И на отказоустойчивости тоже.


PHP тоже так умеет:

У вас в коде комбинированная тильда потерялась, но я верю, что может. Просто это, как и в руби, — костыль.


essome


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


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


Про «что написали» — еще раз для особо одаренных: миллионы леммингов могут ошибаться (ну и написали таки кое-что: дискорд там, пинтерест, файненшл таймс, тойота каршеринг, ченджорг), причем на ванильном компиляторе, без необходимости чуть не полностью его переписывать, как это случилось в FB.


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

Прежде всего он жив потому, что заказчики и работодатели платят за решения на нём.

Заказчики платят за продукт, а не за язык. Работодатели — платят за человекочасы, а не за язык.


Больше всего (по моему опыту) в 2020 платят за КОБОЛ. Чаще всего — за пхп, потому что найти сотого разработчика в команду из 99 — на пхп проще.


Продуктовые же компании, кроме совсем бедных и упоротых, — в сторону пхп уже лет десять не смотрят.


Если совсем упрощать, то: проще найти 50 инженеров, которые будут поддерживать вотцап на эрланге, чем 10К, которые все равно не смогут поддержать его аккуратно на пхп. Я вообще забывать начал, что такое защитное программирование — за меня все язык и среда исполнения делает, буквально.


А с появлением волшебного LiveView, когда для интерактивного взаимодействия со страницей вдруг оказался не нужен JS — все стало вообще абсолютно шоколадно.

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

Я сам всегда первый противник все переписывать.


Но в мире возникают новые продукты. И вот для них проще и дешевле взять что-то чуть более приспособленное к высокой конкурентности и отказоустойчивости.


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


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

Вот прямо сейчас отчуждаю. На PHP 7.4 Не важно же какой язык. :) Вот будет вакансий и резюме на Элексире в Киеве (раза в два меньше Барселоні, если верить вики) в количестве сравнимом хотя бы с Go — можно будет подумать, что-то неважное и простое отчудить и сравнить скорость разработки и требуемые серверные мощности.


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

раза в два меньше Барселоны, если верить вики

Кто кого куда меньше? В Барселоне живет 2 млн человек, из которых миллион — туристы, а еще миллион — работники сферы обслуживания туристов :)


требуемые серверные мощности

Заметно снижаются, об этом куча саксесс сториз в интернете.


Сколько процентов форы дать Элексиру?

Я лично переходил из руби, у которого чуть ближе синтаксис (но парадигма гораздо ближе к пхп). Через месяц я писал на эликсире с такой же скоростью, как на руби (а я хорошо на руби пишу, можно на SO убедиться). Но не это главное.


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


То есть если мерить не LOCами в час, а выхлопом — через два месяца новички на эликсире должны догнать команду пхп и начать быстро обгонять. По моим прогнозам.


Но тут главное — силком не тащить. Если человеку парадигма не понравится — он будет только упираться, и толку не выйдет. Зато если понравится — отдача будет очень заметна. Особенно в отказоустойчивости и понятности кода через год.

Плохого кода (труднотестируемого, невнятного, переусложненного, с лишними абстракциями, с недостающими абстракциями, просто «чёта он какой-то убогий») — стало в разы меньше

А как это язык влияет на говнокод?
как это язык влияет на говнокод?

Напрямую.


  • нельзя сделать одно и то же пятью разными способами,
  • нет говноциклов типа for, while и т. п. — fold или рекурсия,
  • условные операторы выглядят чужеродно и режут глаз, язык буквально заставляет от них отказаться полностью в пользу pattern-matching’а,
  • нельзя поменять переменную там, и удивиться здесь из-за иммутабельности и скоупинга,
  • не нужно возиться с межпроцессорными синхронизациями из-за иммутабельности и модели акторов,
  • не нужно возиться с обработкой ошибок из-за деревьев супервизоров (знаменитый принцип «let it crash»),
  • линтер не пустит дальше незадокументированный код,
  • уже двойная вложенность режет глаз и подталкивает переписать, что возможно всегда,
  • десять типов объектов (функция, шесть примитивных — атом, строка, число, pid, port, reference, и три структурированных — список, хэшмап, кортеж) — неистово мешает наворотить дел,
  • и так далее.

Если одним словом: неправильный код выгляди некрасиво, и это видно даже совсем новичкам.

нельзя сделать одно и то же пятью разными способами,

В смысле нельзя? Язык не тьюринг полный?
нет говноциклов типа for, while и т. п. — fold или рекурсия,

Явная рекурсия — это goto функционального программирования. foldl/foldr, scanl/scanr, unfold, и прочие схемы полущ.

Кто кого куда меньше? В Барселоне живет 2 млн человек

То ли Гугл, то ли зрение подвело. 3,7 млн видел вроде на подсказках или как их там, не переходя на страницу.


через два месяца новички на эликсире должны догнать команду пхп и начать быстро обгонять

Это с каким-нибудь Хаскель бэкграундом или те же пехепешники с ООП-головного мозга?

Не, я вообще не уверен, что хаскель можно показывать людям до того, как они будут себя чувствовать свободно во всех парадигмах и минимум в пяти языках :)


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


Эликсир как раз очень плавно вводит в ФП, и то, как оно все устроено (акцент на отказоустойчивости, деревья супервизиров, let it crash, модель акторов, минимум типов данных, и т. п.) может либо прямо очень очаровать, либо нет. И если да — бэкграунд не так важен, даже хорошо, что люди сразу видят, как оно бывает в сто раз внятнее. Если же нет — повторюсь, насиловать не нужно. Когда человеку противен аромат дыни, его не заставить полюбить ее вкус принудительным вскармливанием.

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


Вот type-driven development на примере хаскеля уже больно показывать.

как-то заруливают

Куда? Не, серьезно, ну нужны же метрики какие-то. А то я подозреваю, чем нарковывернутее код, тем больше он вам лично зарулит :)


За скалу не скажу, у меня очень поверхностный опыт (я только один проект на хадупе кхм консультировал и сам написал не более тысячи строк) — но все же у меня остался привкус переусложненности и попытки заколачивать многие шурупы микроскопами, просто потому что ФП. Не знаю, как осуществляется вход именно в скалу, но если из Java/.NET — то та же виртуальная машина все-таки очень сильно мешает чистой смене парадигмы. Лучше сравнивать c входом в OCaml или даже Scheme.


Могу сказать за себя: мне в хаскеле очень мешает то, что с одной стороны для тривиального односвязного списка мне придется возиться с монадами, а с другой — если не нравится, что все вычисления ленивые — то вот стриктнесс хак (!) для жадных. Ну и самых ужас — это то, что существует и приветствуется практика (я говорил уже) втащить миллиард разных функций и операторов в локальное пространство имен и всеми ими пользоваться. Для человека, который привык учиться, читая и разбирая чужой код — это нереальный шоу-стоппер.


type-driven development на примере хаскеля уже больно показывать

Его больно показывать на всем в сегодняшнем мире, потому что кроме настоящих энтузиастов, которых примерно промилле, — есть еще крепкие профессионалы, которым хочется все-таки полученные знания применить. Чистая наука — восторг, но прикладые аспекты тоже важны. И тот же Idris все-таки вынудит вас сказать: «это было круто, а теперь давайте портируем это на питон и запустим». Ну, утрирую слегка. Это было бы круто рассказывать в институтах, юнцам с горящими глазами, но не профи, запустившим и поддерживающим какой-нибудь SaaS на 1М юников.

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

Минуточку, а зачем для списка учить понятие монады? concatMap и :[]/\x -> [x] соответствуют >>= и return/pure, но определены только на списках.

определены только на списках

Вот именно это я и считаю раковой опухолью: восемьсот способов сделать тривиальныю вещь.


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

написать свою реализацию

Именно свою реализацию concatMap или реализацию интерфейса монады для списка?

Посмотрел язык и фреймворк.
Может все конечно так красиво как вы и говорите, я даже подумал попробовать, но потом посмотрел, что язык чистый фп и понял, что не смогу)
Я не фанатик ООП и не противник ФП части первого и второго использую в своих проектах.

Например: стараюсь избегать for, foreach и использую map, reduce итд, но вызывать такие вещи лично мне удобнее $collection->map(callback), а не map($collection, callback);

Так же не представляю, что-бы я писал не $user->save(), а saveUser($user);

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

В каком-то комментарии вы писали, что у вас очень сильная команда «эликсирщиков» думаю это как раз та причина по которой ваша скорость разработки высока, вы сравниваете свою сильную команду с командой которая клепает лендосы на php.
Но на php тоже есть сильные команды, просто из-за большого количества php разработчиков — вы больше видите слабые.
фейсбук, вк, хабр, баду?
Что написали на эликсире кроме вебсокетов для которых пхп как раз не предназначен?

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

Или покажите мне на эликсире такую же простую cms как wordpress или drupal

Когда создадите/создадут в эликсире такую же мощную экосистему для веб разработки — тогда можем и поспорить, сейчас же, ничего лучше php для веба нет.

Да, на эликсир или С можно написать что-бы работало быстрее и возможно где-то правильнее, но пока вы будете это делать — проект на php уже будет продаваться и если этот проект писали не джуны — для конечного пользователя разницы не будет, все будет работать так же быстро и так же без багов как и было бы на других языках.
То естъ кроме элексира и php других вариантов для веба не существует? :)
фейсбук, вк, хабр, баду?

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


У вк тоже какие-то свои костыли вроде были.


Или покажите мне на эликсире такую же простую cms как wordpress или drupal

У меня был сайт на друпале. На шестом. Мигрировать на восьмой я не осилил, в итоге оказалось проще (для моих задач, естественно) написать статический сайт на hakyll и сделать единоразовое преобразование из дампа друпальной БД в набор .md-документов.

Вот зачем вы рассказываете о том, в чем не разбираетесь?
HHVM Не язык и потребность в нем отпала после выхода php 7

HHVM Не язык и потребность в нем отпала после выхода php 7

А разве Facebook не начала переход на HHVM задолго до того, как вышел PHP 7?

Ну да. И чему это противоречит? У 5 версии были проблемы со скоростю на нагрузках уровня FB, они её решили сами. Потом вышла 7 версия, и нужна в ограниченном решении пропала.
Да, на эликсир или С можно написать что-бы работало быстрее и возможно где-то правильнее, но пока вы будете это делать — проект на php уже будет продаваться и если этот проект писали не джуны [...]

Это ерунда миф (про эликсир, не про си, конечно).


Разработка на эликсире в сравнении с пхп на основе моего опыта примерно в пять раз быстрее, при одинаковом уровне разработчиков. И в два-три раза быстрее, чем на руби.


все будет работать так же быстро

Нет. Вот моя заметка, англ. про скорость (пример синтетический, но легитимный): лукап в хэшмапе из 1М элементов и возврат значения, полноценный HTTP-сервер. Скорость отклика менее сотни микросекунд. Не милли. Микро.


Ничего близко похожего на пхп не сделать.

Скорость отклика менее сотни микросекунд. Не милли. Микро.

А потом мы идём в базу данных…

И да, и нет.


Во-первых, далеко не все приложения вообще нуждаются в базе.


Во-вторых, в ORM на любом объектном языке вам придется руками бороться с N+1, а иммутабельный язык просто не даст построить такой запрос по определению.


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


Ну и так далее.

N+1, а иммутабельный язык просто не даст построить такой запрос по определению.

Можно больше подробностей? Не понимаю как это вообще связано с иммутабельностью.

Вы не сможете написать код, который сначала создаст объект, а потом начнет наполнять его содержимым.

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

Зачем вы все время не к месту употребляете словосочетание «тьюринг-полный» (оно, кстати, пишется через дефис)?


При чем тут это? Да, при определенном рвении можно выстрелить себе в голову и из палки, но для этого вам придется написать свой ORM, который станет так делать целенаправленно.


Ну и мне неизвестен ни один иммутабельный язык, в котором существовали бы «конструкторы».

Зачем вы все время не к месту употребляете словосочетание «тьюринг-полный» (оно, кстати, пишется через дефис)?

Я так кажусь умнее.
но для этого вам придется написать свой ORM, который станет так делать целенаправленно.

То есть существующие ORM под иммутабельные языки сами вытягивают дочерние объекты? Или как это вообще работает? Давайте на простом примере статьи с комментариями, нужно вывести 10 последних статей и к ним 10 последних комментарием. Как это будет выглядеть на иммутабельном языке и как оно будет работать?

В том месте, где данные будут доставаться из базы, будет запрос. Ну, типа такого (это эликсир/экто)


from a in Article, as: :article,
join: c in assoc(a, :comments),
inner_lateral_join: top_ten in subquery(
  from Comment,
  where: [article_id: parent_as(:article).id],
  order_by: :popularity,
  limit: 10,
  select: [:id]
), on: top_ten.id == c.id,
limit: 10,
preload: [comments: c]

Напишете preload: в последней строчке — вытянет сразу. Нет — придется руками доставать, когда понадобится, отдельным запросом. Чуда не случится: если данных нет, их нет, и взяться им неоткуда.


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

В том месте, где данные будут доставаться из базы, будет запрос. Ну, типа такого (это эликсир/экто)

Этот запрос ORM сделала? Окей, вполне нормально. Правда не вижу отличий от других языков, где ORM ровно так же можно попросить вытянуть дочерние объекты.
Этот запрос ORM сделала?

Не понял вопрос. Это исходный код на языке Elixir с использованием ORM Ecto.


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

А можно не попросить, и последующий article.comments.first пойдет в базу исподтишка, приводя к N+1. Вы помните вообще, о чем мы тут разговариваем (помимо полноты разных языков по Тьюрингу)? Я отвечаю вот на такой ваш вопрос:


Не понимаю как это вообще связано с иммутабельностью.

Из-за иммутабельности (невозможности субсеквентного изменения объекта по месту) — по невнимательности учинить N+1 в иммутабельном языке не получится.

Не понял вопрос. Это исходный код на языке Elixir с использованием ORM Ecto.

Издалека очень похоже на ручное построение запроса к БД. Это я где угодно могу сделать.
А можно не попросить, и последующий article.comments.first пойдет в базу исподтишка, приводя к N+1.

Возможно.
Из-за иммутабельности (невозможности субсеквентного изменения объекта по месту) — по невнимательности учинить N+1 в иммутабельном языке не получится.

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

В эликсире (и ФП вообще) нет объектов. Написать функцию, которая станет ходить в базу и по одной доставать связанные сущности, возвращая структуру с дополнительным дитём — можно (язык тьюринг-полный, да), но это гораздо сложнее, чем достать сколько нужно, и оно будет прямо орать с экрана: эй, не нужно так делать.


В рельсах есть целый гем, который детектит N+1, в экто его нет, и никогда не будет, потому что написать код, который приведет к N+1 в прямом смысле непросто. Вот и все.


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

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

Ну вот и всё. Если это можно, то кто-нибудь обязательно так и сделает. Вопрос закрыт.

Вопрос был закрыт давным-давно, когда я написал «иммутабельный язык просто не даст построить такой запрос по определению», но вы попросили подробностей. И я потратил кучу времени, доброжелательно рассказывая, почему, и как, хотя вам было просто нужно написать «я прав, вопрос закрыт».


Да, вы правы, любой полный по Тьюрингу язык разрешит сделать все, что угодно. Вопрос в том, насколько часто вы сталкиваетесь с простреленными ногами. Я волею судеб консультирую некоторое количество проектов на эликсире, руби, питоне и похапе (так вышло, не знаю уж, как).


Так вот в похапе — ошибки связанные с инъекциями и небрежным экранированием — почти сошли на нет в последнее время. При этом и Eloquent, и Django, и Rails — пачками приносят N+1. В любом проекте, с которым приходят на аудит, — их есть. В любом.


А с Ecto это не так. Потому что люди ходят по пути наименьшего сопротивления.


«Кто-то обязательно напишет весь проект на глобальных переменных» — так себе аргумент в пользу того, что их использование — это нормально. Так же и тут.




Ну и это, люди, которые осознанно пришли в ФП и иммутабельность не из-за хайпа, а потому что им очевидны плюсы — обычно в среднем умнее и профессиональнее энтерпрайзников с ООП головного мозга. Поэтому шансов увидеть прямо говнокод — в среднем меньше.

А аргументы будут?
Или все тот же «пробовал php4 не понравилось»?

Что-то я скептически оцениваю подобные радужные прогнозы (про Best Verified Practice например) на такой короткий срок.

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

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

А как развился JavaScript за последние несколько лет? Вопрос не риторический. Я слежу за несколькими языками программирования, кроме PHP, например в Go завезли модули, круто оптимизировали под arm64, добавили поддержку RISC-V, много сделали в криптографических модулях и оборачивании ошибок. Это я написал из головы. А что можно из головы написать про JS за два года?

Наверно, лучше задать этот вопрос разработчикам на джаваскрипт. Я его касаюсь только изредка, поэтому скорее мой ответ относится к изменениям за последние лет 5.
И там довольно сложно с точным определением периода «за 2 года», т.к. стандарты выходят намного быстрее, чем внедряется их поддержка в браузеры.
Я бы назвал: саму идеологию server side rendering, стрелочные функции, переход с promise на async/await, условное вычисление через точку (это когда свойства у объекта может и не быть, но если оно есть, то берем его), приход js на бекенд (nodejs).
Отдельно я бы еще отметил приход js в нишу не-вэб приложений: например тот же скайп и дискорд на electron. А также приход js в нишу мобильной разработки и там ему удалось добиться гораздо большей кроссплатформенности и переиспользованию кода, чем java.
RXJS, имхо, неплохой шаг вперёд (хоть это и библиотека, а не часть языка).
А что можно из головы написать про JS за два года

Про js/ts/coffee и прочее можно сказать, что тот самый код, написанный 2 года назад, работает и сейчас.

2 года в разработке — это один миг. Далеко не каждый продукт доходит до продакшена за это время. Так что, париться по этому поводу из за новых свистелок-перделок в языке?
Какое-то безрадужное будушее:
— одна версия
— один язык
— один stackoverflow

Кмк сила в разнообразии, а самый «частый» или «признанный» подход не означает лучший.
Вроде бы тут есть какие-то параллели с доказательной медициной, но слишком уж утопично.
Скорее тут параллели с эволюцией, вроде бы все оптимально, и с далека очень даже ничего получилось, но копни глубже — куча костылей/подпорок и переиспользования кода. И появиться какая-то генетическая ИТ археология, чтобы понять как получился тот или иной код, и что будет если поменять один бит на другой :)
Извините, но на счёт самого частого — это загиб. Я не говорю о «модных» или «перспективных», а именно часто используемых. И кто может переплюнуть С и его семейство? Что кодеры будут делать без электричества? А ведь на АЭС, ТЭС и ГЭС используются плюсы, от Франции и до Ломоносова (это личное знание). Большинство производства — тоже плюсы; большинство ЯПов в предках имеют корни от С\С++ (ну да, кроме ассемблера и делфи)… Люди подзабыли Кобол — страдают америкосы, люди подзабудут С — будут страбать все.
ЗЫ. да будет холивар.
да бесспорно, C хорош в своей нише, но те же пользовательские интерфесы на нем не пишут (почти), хотя и для них в какой-то момент это было стандартным решением.
А уж Delphy так вообще был industry wide standard!
Delphi так вообще был industry wide standard!

Не был Delphi никогда стандартом за пределами регионов, где можно было купить пиратский диск с полной версией и миллионами VCL библиотек за полтинник.

Как сейчас помню: будучи студентом, пошел на ярмарку вакансий от вуза. И кроме доктора Веба и прочих — сидели такие тихие и степенные дядечки.
Подошел к ним, спросил что и как — через губу ответили — нам нужен человек со знанием Delphi!

Холивар? С радостью!


Я бы предпочёл, чтобы АЭС, ТЭС и ГЭС использовали что-то более безопасное. Кок там тот же вышеупомянутый. Или идрис (мы же обсуждаем 2025-й год?).

О, даже интересно. И что же Вас не устраивает с уровнем безопастности на данный момент? Или ещё лучше — слушаю предложения как повысить уровень безопастности. Обещаю доложить об идеях своему начальству и указать Вас как источник. Заранее заявлю — Чернобыль тупо человеческая ошибка, а Фукусима — игнорирование рекомендаций МАГАТЭ (сокращение огранизации немного иначе пишется, там буквы скачут как у девочки-эмо в переписке, прошу извинить за упрощение). Кстати с деятельностью упомянутой организации рекомендую ознакомится перед написанием предложений.
И что же Вас не устраивает с уровнем безопастности на данный момент?

Например то, что «уровень безопасноcти на данный момент» не является «максимально возможным уровнем безопасности». И если этот самый уровень можно ещё поднять, то в общем-то по хорошему стоит это сделать. То есть прямо вот кидаться переписывать весь софт заново может и не надо, но возможно стоит подумать об альтернативах для новых продуктов.

Заранее заявлю — Чернобыль тупо человеческая ошибка, а Фукусима — игнорирование рекомендаций МАГАТЭ

То еcть вы предлагаете подождать пока где-то что-то случиться именно из-за софта и только тогда начинать думать и об усилении безопасности в этом плане?
Я ничего не предлагаю в данном контексте. Вы заявили желание улучшения безопастности, но формулировка «использовали что-то более»… Слишком размыта. Я сделал вывод, что как минимум Вас что-то не устраивает, о чём и спросил.

Это был другой оппонент :)


Меня в плюсах не устраивает вот что:


  1. Невозможность формального доказательства (в смысле всяких коков или тех же идрисов) отсутствия нежелательных свойств и наличия желательных. Софт для АЭС я не писал, так что примеры оттуда я привести не могу, но вот из более близких мне компиляторов, например… Если вы пишете компилятор на плюсах, то вы про него вообще ничего сказать не можете. Если же вы пишете компилятор на условном идрисе, то вы можете формально доказать, например, что написанная вами только что оптимизация не ломает семантику программы. Или что композиция оптимизаций не ломает семантику. Из общих соображений аналогичные вещи должны существовать и для кода, управляющего АЭС-ГЭС-етц.
  2. Конкретно в случае плюсов ещё печалит легкость отстрела ног всякими UB. Я писал код с некоторыми требованиями к корректности, и это был ад. Учитывая, что это было HFT, где в худшем случае компания обанкротится, и люди пойдут по домам, ну в совсем крайнем случае кто-то сядет, тогда как у всяких -ЭС на кону человеческие жизни, страшно представить, как у них там всё жёстко.
Ну вот, такую схему обломали подменой)
Думаю, что Вы огорчитесь, узнав что в реальности всё намного проще. Ну или мягко сказать будете в шоке)
На ТЭС, АЭС (по крайней мере знакомых мне) используют линукс из ряда постарее с кастрированным функционалом (к примеру на одной АЭС до сих пор стоит сборка на основе RH 7.3 с ядром 2.4, а ещё года 3-4 назад на многих система была Fedora 8, сейчас 21). В основном в программах используют один, максимум 2 шаблона или обходятся вовсе без них. Тестирование? Ну-ну… Считается, что это обязаность программиста в основном. А остальное проходит испытания на выделенных компах, где имитация процессов на станции. Когда я после вуза пришёл работать, то (я не хвастаюсь) даже не знал что такое функции. Сейчас-то за столько лет я побольше понимаю, но и вместе с тем замечаю, что… Есть такой термин — стагнация, он хоть и не по теме программирования, но подходит. В этой сфере хорошо то, что работает, а о развитии речи не идёт. Ну не считать же развитием дополнительные фишки по желанию с объектов? С другой стороны это всё действительно работает и от программной части не стоит ждать аварии.
Все что описано в статье — это то как «менеджеры» галер хотят видеть процесс разработки.

Что делать с языками типа Кобол? На гитхабе кода совсем нету. Весь код закрытый.
Что будет с SQL? Нет же проектов полностью на чистом SQL.
Оптимизации (архитектурные, кода, запросов к базе) делаются тоже в контексте нагрузок проекта, а это ИИ вряд ли поймет(потому что не участвует в этих проектах).
Как будет этот ИИ бороться с недоработками/ошибками в стороннем софте? БД это самый хороший пример такого софта. Что ИИ будет анализировать changelog и учитывать эти нюансы?

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

С sql ИИ как минимум сможет «давать по рукам» за какие нибудь вложенные select-ы в реляционных базах, в общем стараться обезопасить от плохих практик / ошибок. Что-то наверняка будет автоматически оптимизироваться на уровнях слоев абстракций над БД, но опять же соглашусь с вами что в сложных случаях — надо будет действовать по старинке.

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

Таким образом — я считаю, что речь не идет о том, что разработчики станут не нужны, а лишь о том как в наиболее популярных кейсах максимально облегчить их работу. А высвободившееся время от работы над популярными/общими кейсами разработчики смогут направить как раз на специфичные оптимизации, фикс сложных кейсов совместимости со сторонним софтом и т.п.
Эх мечты менеджеров, упростить работу, что бы оно само всё делалось или джунами за копейки.
Поспешу огорчить, что чем проще писать становиться тем больше, быстрее и более сложные решения начинают писать конкуренты. И вот мы опять на том же уровне где были до этого.
Развитие это хорошо просто не надо питать иллюзий, что оно как-то поможет сократить расходы.
Перераспредилить != сократить же. Сократить — в абсолюте, да, не поможет, но оно вроде как и не требуется в отрыве от всего.
С sql ИИ как минимум сможет «давать по рукам» за какие нибудь вложенные select-ы в реляционных базах, в общем стараться обезопасить от плохих практик / ошибок.

Как раз не может :) Запросы оптимизируются только на реальных данных, без понимания природы данных непонятно будет ли эффективно использоваться индекс или нет, может данные разреженные. И как раз select в select это один из способа оптимизации запросов, вложенные select сужает область основного запроса.
Еще есть нюанс в том, что некоторые плохие «вчерашние» практики — сегодня стали хорошими, может быть и наоборот.

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

На практике ИИ втыкнет в код самый часто встречающийся костыль на stackoverflow. Да и как разработчик которые сам не решал проблемы сможет найти решение для редкой и специфической проблемы? Тут надо только постоянная практика.

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

Я тоже хочу облегчения работы, но только не с такой стороны и без таких менеджерские баблометрик. Плюс это все ИИ ломает систему роста разработчика, джун не набьет руку на простом коде — потому что ИИ-дополение кода будет работать, со сложной проблемой не разбереться потому что не понимает и не знает как, что-то новое придумать не может (ИИ метриками задавит), плохое тоже не может сделать (как учить/учиться на ошибках).
И это все приведет к жуткому расслоению, будут разрабы старой закалки лет под 80, и молодые которые «и-и-к и-и-к и в продакшн». В принципе все что и сейчас только на порядок хуже. Так как творчества уже не будет, будет станок где важен только результат. А понимает разработчик что делает код или не понимает уже никого не волнует.
Проблема любых оптимизаторов в том, что они упираются в алгоритмическую разрешимость. Да, во многих случаях оптимизировать код получится. Но сколь не совершенствуй алгоритмы, рефакторинг произвольного кода до оптимального вида в принципе невозможен.

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

Да но еще и по причине того, что код развиваться и меняется постоянно, не все разрабатывают TEX один раз и навсегда. И код всегда стремиться до оптимального вида в процессе рефакторинг, но никогда не достигает — так как меняются требования.

Над шаблонными задачами облегчит работу:
1. Нормальный каталог алгоритмов на всех языках и на SQL в том числе.
2. Нормальный поисковик по коду, где можно искать с кавычками и подчеркиванием, а не так как сейчас.
3. Дальнейшее развитие генераторов кода, разных, и для CRUD, и для GraphQL и по спецификациям OpenAPI. Разного рода Skaffold, Template и агрегаторов типа templatemonster. И это касается не только шаблонного кода, но и шаблонных сценариев для деплоя например.

Вы сильно оптимистично восприняли мой прогноз, хотя в целом верно. Я думаю что будет еще хуже. Сейчас наблюдаю за молодым поколением и как они решают поставленные задачи, все ровно так как и описано в статье. Гуглинг, копипастинг. Если им дать еще ИИ в помощники — то это будет просто жесть, и что-то типа того как сейчас обстоят дела в скульптуре. Вроде всего и много, но ничего уровня Микеланджело нету. И на все вопросы «Почему?», ответ один — «Утрачены древние секреты».
это то как «менеджеры» галер хотят видеть процесс разработки
Знаете в истории всё повторяется, примерно такие же процессы происходили в бух.учёте примерно 20 лет назад, когда массово стали внедрятся компьютеры, казалось вот вот и всё будет автоматизированно, даже налоги будут считаться автоматически…
Но нет будущее не наступило, всё так же люди корпят над проводками и сведением балансов.
Песня про физический труд роботов и отдых человеков, далека по прежнему примерно как в ситуации с Ахиллесом и черепахой
Но нет будущее не наступило, всё так же люди корпят над проводками и сведением балансов.

Но при этом всё-таки над сведением балансов сидит гораздо меньше людей чем раньше.
Статья про ожидания. Реальность: В 2025 году половина продакшена на питоне еще будет плеваться ворнингами про 2.7.
Загнал обе страницы (эту и оригинал) в архив интернета. Посмотрим через 5 лет, не забыть бы.
Главное чтобы архив интернета был доступен через 5 лет и в нём остались эти страницы. А то одна две строки в robots.txt, и веб архив как минимум ограничивает доступ ко всем архивным копиям сайта.
Автор очень зря считает, что решения принятые в большинстве случаев — верные.
Б`ольшую часть сообщества разработчиков составляют джуны. И они же чаще других отправляются на stackoverflow. А это уже x^2. Т.е. бОльшая часть решений в мире IT (с учетом опен-сорса, учебных и пет-проектов) принимают разработчики с минимальным понимаем того, что и зачем они делают.
P.S. я ни в коем случае не говорю, что опен-сорс, пет-проекты или джуны — это что-то плохое. Мое мнение лишь в том, что это не те понятия, на которые можно спокойно опереться.
~10 фреймворков PHP, которые сейчас есть, будут консолидированы.
Их уже сейчас по сути только два осталось. Ларавел и Симфони. У остальных доля мизерная.

Автор оригинальной статьи считает Wordpress за фреймворк. "Да, но нет", конечно, но доля WP в мировом интернете колоссальная, вся экосистема PHP живёт с оглядкой на этого слона в посудной лавке.

Тут недавно уже была статья про инструмент, который пытался предугадывать желания пользователя: Ученые переименовали 27 человеческих генов, потому что Excel их неправильно обрабатывал.
Вот примерно то же самое будет, если заменитель интеллекта начнет угадывать намерения разработчиков и вмешиваться. Недетерминированные угадывающие инструменты не должны влиять на результат. Максимум — выдавать предупреждения. Решения все равно должен принимать человек. Явное лучше неявного.

Ну вообще-то высокоинтеллектуальное автодополнение в VisualStudio достаточно удобное. После того как нажимаешь "." в 80% нужен один из первых двух предложенных вариантов.

Автодополнение только предлагает варианты. Конечное решение принимает пользователь.

Как там было про 20% и 80%? :)


То есть да, в 80% случаев VS предлагает правильную подсказку или скажем resharper предлагает полезный рефакторинг. Но это те 80% где и без них всё просто решается. А проблемы обычно создают оставшиеся 20%. И вряд ли ИИ в этом плане что-то сильно изменит. Простые вещи он поможет решить, но их я и без него решу не напрягаясь…

Время разработчика затрачиваемое на проверку сегенерированного будет прямо пропорционально его объему. Пока это строка-две, это удобно, пока это генератор кода под узкую ситуацию это достаточно предсказуемо, чтобы можно было не проверять. Но за «ИИ» который будет создавать код для широкого спектра задач путем интерполяции других кусков кода нужно будет все проверять. И чем больше сгенерированный кусок тем выше шанс на ошибку со стороны того же ИИ.
Вы сейчас про искусственный интеллект, или про джуниор программистов говорили? :)
А может лучше будет, если программирование станет чем-то вроде…
— Джарвис, сбацай-ка мне Интернет-магазин на базе PHP, используя в базе только поля «группа\подгруппа\артикул\описание артикула\цена\цена_оптовая\moq\наличие\адрес доставки\world_id_заказчика».
— Размести на Уругвайском хостинге не дороже 33 рублей в месяц.
— Шрифты используй Comic Sanserif и что-то такое в красненьких тонах, с синенькими буквами.
— Да! И не забудь поддержку IE6 и Android 1.6.

По-моему, достаточно высокоуровневое программирование, хотя все ньюансы чтобы учесть — надо шарить в технологиях чтобы просто их упомянуть в тексте...
А лучше сразу «Джарвис, заработай мне денег». Вот только зачем вы нужны будете Джарвису?
Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.

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

>Как будет выглядеть программирование в 2025 году?

не знаю как ваше, но мое программирование будет выглядеть так же, как и последние 20 лет:
terminal, vim, make, gcc, clang, etc.

скорей всего даже colorscheme в виме останется тот же. Стабильность!
Хочу статический анализатор кода, предлагающий для исходного кода какой-нибудь шаблон или ряд шаблонов. И чтоб при его применении автоматом все рефакторилось. На всех языках.
«конструктор кода по шаблонам проектирования»

Особенно повеселил раздел про стаковерфлой.
Сверять свой код с ответом десятилетней давности — это прекрасная практика, я считаю :)

TL;DR В 2025 разработчики станут еще тупее, а IDE будет жрать не только всю память, но и весь канал.

Ну, кстати, от умного автокомплита, убирающего рутину, я бы не отказался. TabNine, в принципе, уже неплох, и вполне себе позволяет даже в каком-нибудь хаскеле (на котором на порядок-другой меньше кода и данных для обучения) делать что-то такое:



Само вон догадывается, как надо код дописать и к какой локальной переменной обращаться (исключая кривой ', вставленный IDE).

У меня нет ярко выраженного мнения на этот счет.


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


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


В общем, для новичка — безусловное добро. Для развесистых, перегруженных парадигмами и реализациями языков — тоже.


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

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

Ну на хугл натравливать странно для кода, который вот я прямо сейчас пишу, его на хугле ещё нет.


Но тут куда прикольнее, что я вот только что написал antecedent' <- convertRefinement antecedent, и только начал писать conseq, как оно мне предложило абсолютно естественную и разумную consequent' <- convertRefinement consequent. Притом, что типы у antecedent и consequent одинаковые.


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

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

Вера в супер-пуперские AST-преобразования, конечно, серьёзная. Мы вот в Java уже больше 15 лет имеем Structural search & replace, который делает пользовательские AST-преобразования и весьма неплохо. Но я не представляю, чтобы миграция между несовместимыми фреймворками описывалась через него. Там всегда куча именно семантических краевых случаев, которые идеально не покроешь. Если вслепую массово применить к большой кодовой базе, посадишь пачку загадочных багов, которые потом запаришься отлаживать. Тем более в языке без статической типизации.

НЛО прилетело и опубликовало эту надпись здесь
Краткая суть статьи: Человек, который 18 лет занимается PHP думает что в 2025 будущее программирования будет заключаться в том, что разработчики будут иначе выбирать фреймворк для PHP, а все умные штуки будет вместо нас делать AI.
А что это за слово такое в английском языке, «практикс»? Я что-то пропустил, или имеются в виду «практисес»?
В 2025 будут преобладать «программисты мышкой» с фреймворком головного мозга, которые даже не смогут написать ни одного мало-мальски сложного запроса к базе данных.
КМК, IDE не должен быть умнее программиста — одно дело упрощать жизнь квалифицированному специалисту, и другое дело — делать работу за дурака (результат будет предсказуемым).
Ога, мы тоже в офисе шутили про то, что в будущем будут не программисты, а Операторы IDE

Ха… думается все будет по другому


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


  • Рефакторинг основанный на AST — а сейчас он как-то инчае о_О ?



А вот что будет, так это


1) Языки будут более точные и будут проходить в сторону упрощения синтаксиса, увеличения выразительности и возможностей


1-а) Обязательно появятся те же макросы, которые есть в Groovy/Scala в других языках
1-б) Будем программировать не только языки, но и AST, создавая свои языки
1-в) Будут языки которые будут смешивать этапы runtime и compile time, как при помощи макросов, так и для доказательности правильности языков
1-д) Системы типов будут усложняться (см TypeScript, coq)


2) ООП не умрет, даже не надеяться (а тот кто будет топить за смерь ООП, будет сам гореть в Аду — go learning logic), но он будет немного другой ООП — те же traits


3) Патерны программирования (из книг), станут безпозлны ибо из заменять Макросы и DSL, кончено по факту, сами Шаблоны программирования не уйдут, но цитировать эту глупость будут меньше


4) Языки станут по выразительности что-то между python и scala


5) C#, JS отомрут, первый будет переосмыслен силами MS и выпущен другой язык частично совместимый C#, так чтоб уменьшить накопившиеся "плохих генов" в грамматике языка.
JS — потому что, на это дело рано или поздно все забьют — ибо есть WASM


6) WASM станет новой виртуальной машиной, которая будет на ровне с JVM


7) TypeScript убъет JS, если не умрет от количества собственных плохих мутаций (кол в голову за синтаксис тэгов в TypeScript)


8) Рано или поздно PHP переедет на другую VM (например на WASM или JVM или PythonVM)


9) Будут в очередной раз возникать и умирать визуальные языки программирования — как способ развода… кроликов на деньги


10) Вангую, что в ближайшем будущем будет рост кол-ва языков, большинство умрут, и будет рост средств разработки языков, которые будут внедряться в текущие языки — см. GraalVM

1-д) Системы типов будут усложняться (см TypeScript, coq)

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


Языки станут по выразительности что-то между python и scala

То есть, выразительными, как позапрошлогодняя газета?


WASM станет новой виртуальной машиной

А Golang — квантовым компьютером!


PHP переедет на другую VM

А Цукерберг изобретет социальную сеть для сокурсников.


будет рост средств разработки языков, которые будут внедряться в текущие языки

В общем — будущее — за рекурсивным внедрением языков в самое себя.


Ура!

1д) Согласен с что рядом лучше их не ставить (TypeScript vs coq)


То есть, выразительными, как позапрошлогодняя газета?

относительно чего мерить? python не особо выразителен, а популярность растет, как правило всякое попсовое и полу живое лучше всего распространяется (см php — хоть его не люблю)


WASM по факту уже есть, и есть большой список языков которые в него компилируются.
Ту же мертвую лошадь JS с нарушенными типами использовать тяжко и тот же TypeScript, и прочее есть попытка уйти от JS, WASM — принятый стандарт и дальнейший шаг


Так что ирония Golang не совсем уместна


А Цукерберг изобретет социальную сеть для сокурсников.

Не отрицаю, может и очередную соц сеть запустит


В общем — будущее — за рекурсивным внедрением языков в самое себя.

Будущее за вечным — любовь, ненависть, деньги.


за рекурсивным внедрением языков в самое себя — это уже есть — см Eclipse Xtext, IDEA DSL, DSL сам по себе, GraalVM, macros в языках

Будут языки которые будут смешивать этапы runtime и compile time, как при помощи макросов, так и для доказательности правильности языков

Главное — аккуратнее смешивать, а то тайпчекинг неразрешимым станет.


Системы типов будут усложняться (см TypeScript, coq)

Как там в коке с сетоидами хотя бы? Они вылезают в каждой второй задаче.


Ладно, фиг с ним. Нафига в 2020-м году писать руками возвращаемый тип матча, я уж не говорю о 2025-м?

Главное — аккуратнее смешивать, а то тайпчекинг неразрешимым станет

Это да…


Как там в коке с сетоидами хотя бы? Они вылезают в каждой второй задаче.

не знаю, я думаю надо chapuza спросить, то он вроде как спец по нему


Ладно, фиг с ним. Нафига в 2020-м году писать руками возвращаемый тип матча, я уж не говорю о 2025-м

Согласен полностью, пора в 2020 уходить от этого

надо chapuza спросить, то он вроде как спец по нему

Упаси святой восьмибитный процессор! Я название-то только в прошлом году выучил, до сих пор иногда через “ck” на конце пишу.

Когда то был модный язык Кларион, в котором не надо было программировать чтобы писать программы.
Как показало время, «не взлетел»…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

17 декабря 2004 г.

Местоположение

Кипр

Сайт

fun.co

Численность

51–100 человек

Дата регистрации

28 августа 2013