Комментарии 149
Если в 2025 году вы по-прежнему будете программировать на ПХП, могу только посочувствовать.
Если заменить php на coq, что случится?
Нам же обещали, что "оно всё само". Неужели так трудно найти решение для произвольно заданной массовой проблемы прямо в IDE?
(насчёт через зад — вся computer science через зад. Так же как и вторичноротые получаются выворачиванием ануса на место рта, так и современное программирование — это вывернутое "через зад". Но мы привыкли и считаем это ртом).
Сегодня мы боремся с техническим долгом (что бы это ни означало), с устаревшим кодом, который сложно поддерживать и дорого изменять, но, в то же время, он генерирует много денег.Самое емкое, на мой взгляд, описание настоящего и будущего PHP.
поддерживает нативно UTF-8?
А что значит "нативно"? Это, типа, выбирать utf8 буквы как элементы массива? Или что?
Ну так в пыхе это и так всё есть. И UTF-8 строки, и функции для работы с ними. В чём претензии?
Блин, да хоть UTF-32/UCS-4, разница какая? PHP позволяет работать с чем угодно и как угодно. Хоть нижний с верхним суррогаты в обратном порядке соединять.
Предлагаю всё же более точно их высказывать, а то выглядит как "слышал звон".
P.S. А что есть "валидная utf-8 строка"? Почему язык должен мне диктовать как соединять суррогаты? Привязывать обычную последовательность байт к спеке, которая раз в год обновляется — это попахивает недальновидностью и фатальным устареванием всего языка каждый год. Нужно проверить строку — "проверяй, пожалуйста, вот тебе пачка функций для проверок". Но на уровне ядра зашиваться на это — глупо, только проблем добавляет.
Таким образом, в 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++, которые являются системными языками с упором на производительность и контроль. Но видеть подобный подход в высокоуровневом интерпретируемом языке предназначенном для веб-разработки – это мрак.
Найти подстроку без учёта регистра? Кодировки недостаточно, нужна локаль.Unicode стандартизирует lower/upper/title case трансформации. Хоть я согласен что в большинстве случаев это не то что вам нужно.
Взять первые N символов? Локаль.Разве? Если мы говорим о UTF-8, то мне кажется что разделение на codepoints и графемы универсально и не зависит от локали.
В целом я согласен с вашим комментарием, но я думаю, что строку, ведущей себя как набор байт следует честно называть – bytearray например, а не строкой.
К примеру, в Rust любой String – это гарантированно валидная UTF-8 строка, и хоть на уровне построения этот тип является оберткой над динамическим массивом байт (Vec), его набор методов значительно отличается от массива. К примеру, нельзя индексироваться по элементам (s[3]), чтобы разработчикам не пришло в голову таким образом «взять третий символ», но зато можно итерироваться по символам.
Которые, насколько я знаю, зависят от языка в общем случае? А как?Предлагая универсальную локально-независимую систему, которая полезна как раз когда нужна консистентная нормализация, которая не будет зависеть от локали.
И да, это означает что подобная трансформация может идти в разрез с грамматикой языков. Но, если задуматься, стандарт юникод и не обязан строго следовать текущим правилам грамматики, потому что грамматические правила изменчивы, а однообразное отображение символов – нет.
… буква-как-бета иногда пишется как ss [...]. Но это одна буква. Или нет?С точки зрения написания (но не произношения) это даже не буква, а лигатура, как например "ff" или "æ". Изначально у нее не было даже своего места в алфавите, как и заглавного начертания. Таким образом, SS всегда были и остаются двумя раздельными буквами.
Дизайнеры юникода и шрифтов предусмотрительно потрудились и нарисовали заглавный вариант: ß — ẞ (Latin Capital Letter Sharp S). А с 2017 года совет по немецкому правописанию окончательно одобрил использование заглавного варианта, так что теперь оба варианта верны: SCHEISSE и SCHEIẞE. Выходит, что только последние два года ẞ можно считать полноценной буквой, а не сокращенным способом написания двух других букв.
Но отсутствие string прям в стандартной библиотеке лично меня не сильно печалит.Лично меня печалит что все повсеместно используют юникод, но никто не удосуживается полноценно следовать его правилам.
Хорошо если работа с текстом ограничивается последовательностью принял-сконкатенировал-передал, но если начинаются внутренние модификации, почти наверняка можно наделать ерунды.
так что теперь оба варианта верны: SCHEISSE и SCHEIẞE
Вообще-то нет. В современном немецком SS и ß строго разделяют, и на письме замена одного на другое считается грамматической ошибкой. На слух они хоть и похожи, но всё же по разному влияют на произношение предшествующего гласного, и в отдельных случаях даже имеют в итоге разное значение.
Найти подстроку в строке? Кодировка тут неважна, можно обращаться с байтиками.
Зависит от степени вашего перфекционизма. Смотрите, движок хрома умеет:
А руби из коробки (сам пример) — нет. Подозреваю, что вообще мало, кто умеет (хотя, вроде бы, очевидно ожидать, что "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 (всяческих благ его родителям, наделившим парня именем с акутом) сделал правильно. А именно, компилятор парсит спеку консорциума.
Мне за 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 тоже так умеет:
У вас в коде комбинированная тильда потерялась, но я верю, что может. Просто это, как и в руби, — костыль.
фреймворк — пожалуйста, а 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, и три структурированных — список, хэшмап, кортеж) — неистово мешает наворотить дел,
- и так далее.
Если одним словом: неправильный код выгляди некрасиво, и это видно даже совсем новичкам.
Кто кого куда меньше? В Барселоне живет 2 млн человек
То ли Гугл, то ли зрение подвело. 3,7 млн видел вроде на подсказках или как их там, не переходя на страницу.
через два месяца новички на эликсире должны догнать команду пхп и начать быстро обгонять
Это с каким-нибудь Хаскель бэкграундом или те же пехепешники с ООП-головного мозга?
Не, я вообще не уверен, что хаскель можно показывать людям до того, как они будут себя чувствовать свободно во всех парадигмах и минимум в пяти языках :)
Вообще, я вступаю на очень скользкий путь: я очень далек от того, чтобы давать какие-нибудь советы, или там гарантировать что-нибудь. Я лишь делюсь своим личным, сугубо интимным мнением и опытом.
Эликсир как раз очень плавно вводит в ФП, и то, как оно все устроено (акцент на отказоустойчивости, деревья супервизиров, let it crash, модель акторов, минимум типов данных, и т. п.) может либо прямо очень очаровать, либо нет. И если да — бэкграунд не так важен, даже хорошо, что люди сразу видят, как оно бывает в сто раз внятнее. Если же нет — повторюсь, насиловать не нужно. Когда человеку противен аромат дыни, его не заставить полюбить ее вкус принудительным вскармливанием.
как-то заруливают
Куда? Не, серьезно, ну нужны же метрики какие-то. А то я подозреваю, чем нарковывернутее код, тем больше он вам лично зарулит :)
За скалу не скажу, у меня очень поверхностный опыт (я только один проект на хадупе кхм консультировал и сам написал не более тысячи строк) — но все же у меня остался привкус переусложненности и попытки заколачивать многие шурупы микроскопами, просто потому что ФП. Не знаю, как осуществляется вход именно в скалу, но если из Java/.NET — то та же виртуальная машина все-таки очень сильно мешает чистой смене парадигмы. Лучше сравнивать c входом в OCaml или даже Scheme.
Могу сказать за себя: мне в хаскеле очень мешает то, что с одной стороны для тривиального односвязного списка мне придется возиться с монадами, а с другой — если не нравится, что все вычисления ленивые — то вот стриктнесс хак (!) для жадных. Ну и самых ужас — это то, что существует и приветствуется практика (я говорил уже) втащить миллиард разных функций и операторов в локальное пространство имен и всеми ими пользоваться. Для человека, который привык учиться, читая и разбирая чужой код — это нереальный шоу-стоппер.
type-driven development на примере хаскеля уже больно показывать
Его больно показывать на всем в сегодняшнем мире, потому что кроме настоящих энтузиастов, которых примерно промилле, — есть еще крепкие профессионалы, которым хочется все-таки полученные знания применить. Чистая наука — восторг, но прикладые аспекты тоже важны. И тот же Idris все-таки вынудит вас сказать: «это было круто, а теперь давайте портируем это на питон и запустим». Ну, утрирую слегка. Это было бы круто рассказывать в институтах, юнцам с горящими глазами, но не профи, запустившим и поддерживающим какой-нибудь SaaS на 1М юников.
мне в хаскеле очень мешает то, что с одной стороны для тривиального односвязного списка мне придется возиться с монадами
Минуточку, а зачем для списка учить понятие монады? concatMap и :[]/\x -> [x] соответствуют >>= и return/pure, но определены только на списках.
Может все конечно так красиво как вы и говорите, я даже подумал попробовать, но потом посмотрел, что язык чистый фп и понял, что не смогу)
Я не фанатик ООП и не противник ФП части первого и второго использую в своих проектах.
Например: стараюсь избегать for, foreach и использую map, reduce итд, но вызывать такие вещи лично мне удобнее $collection->map(callback), а не map($collection, callback);
Так же не представляю, что-бы я писал не $user->save(), а saveUser($user);
Возможно эликсир и быстрее в некоторых задачах, но то, что скорость разработки на нем выше чем на php я все же не поверю, думаю тут больше зависит от прослойки между монитором и креслом, а не от языка.
В каком-то комментарии вы писали, что у вас очень сильная команда «эликсирщиков» думаю это как раз та причина по которой ваша скорость разработки высока, вы сравниваете свою сильную команду с командой которая клепает лендосы на php.
Но на php тоже есть сильные команды, просто из-за большого количества php разработчиков — вы больше видите слабые.
Что написали на эликсире кроме вебсокетов для которых пхп как раз не предназначен?
Покажите мне на эликсире фреймворк уровня симфони или ларавель, где я могу с легкостью быстро и качественно разработать среднее приложение.
Или покажите мне на эликсире такую же простую cms как wordpress или drupal
Когда создадите/создадут в эликсире такую же мощную экосистему для веб разработки — тогда можем и поспорить, сейчас же, ничего лучше php для веба нет.
Да, на эликсир или С можно написать что-бы работало быстрее и возможно где-то правильнее, но пока вы будете это делать — проект на php уже будет продаваться и если этот проект писали не джуны — для конечного пользователя разницы не будет, все будет работать так же быстро и так же без багов как и было бы на других языках.
Да, на эликсир или С можно написать что-бы работало быстрее и возможно где-то правильнее, но пока вы будете это делать — проект на php уже будет продаваться и если этот проект писали не джуны [...]
Это ерунда миф (про эликсир, не про си, конечно).
Разработка на эликсире в сравнении с пхп на основе моего опыта примерно в пять раз быстрее, при одинаковом уровне разработчиков. И в два-три раза быстрее, чем на руби.
все будет работать так же быстро
Нет. Вот моя заметка, англ. про скорость (пример синтетический, но легитимный): лукап в хэшмапе из 1М элементов и возврат значения, полноценный HTTP-сервер. Скорость отклика менее сотни микросекунд. Не милли. Микро.
Ничего близко похожего на пхп не сделать.
И да, и нет.
Во-первых, далеко не все приложения вообще нуждаются в базе.
Во-вторых, в ORM на любом объектном языке вам придется руками бороться с N+1, а иммутабельный язык просто не даст построить такой запрос по определению.
В-третьих, если запрос сложный, его надо будет процессить, и эликсир из коробки разрешит это сделать параллельно, с почти нулевым оверхедом по коду.
Ну и так далее.
Вы не сможете написать код, который сначала создаст объект, а потом начнет наполнять его содержимым.
Зачем вы все время не к месту употребляете словосочетание «тьюринг-полный» (оно, кстати, пишется через дефис)?
При чем тут это? Да, при определенном рвении можно выстрелить себе в голову и из палки, но для этого вам придется написать свой ORM, который станет так делать целенаправленно.
Ну и мне неизвестен ни один иммутабельный язык, в котором существовали бы «конструкторы».
В том месте, где данные будут доставаться из базы, будет запрос. Ну, типа такого (это эликсир/экто)
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 сделала?
Не понял вопрос. Это исходный код на языке Elixir с использованием ORM Ecto.
не вижу отличий от других языков, где ORM ровно так же можно попросить вытянуть дочерние объекты
А можно не попросить, и последующий 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 за два года?
И там довольно сложно с точным определением периода «за 2 года», т.к. стандарты выходят намного быстрее, чем внедряется их поддержка в браузеры.
Я бы назвал: саму идеологию server side rendering, стрелочные функции, переход с promise на async/await, условное вычисление через точку (это когда свойства у объекта может и не быть, но если оно есть, то берем его), приход js на бекенд (nodejs).
Отдельно я бы еще отметил приход js в нишу не-вэб приложений: например тот же скайп и дискорд на electron. А также приход js в нишу мобильной разработки и там ему удалось добиться гораздо большей кроссплатформенности и переиспользованию кода, чем java.
Я бы сказал, что это TypeScript, Flow и Hegel в первую очередь.
А что можно из головы написать про JS за два года
Про js/ts/coffee и прочее можно сказать, что тот самый код, написанный 2 года назад, работает и сейчас.
2 года в разработке — это один миг. Далеко не каждый продукт доходит до продакшена за это время. Так что, париться по этому поводу из за новых свистелок-перделок в языке?
— одна версия
— один язык
— один stackoverflow
Кмк сила в разнообразии, а самый «частый» или «признанный» подход не означает лучший.
Вроде бы тут есть какие-то параллели с доказательной медициной, но слишком уж утопично.
ЗЫ. да будет холивар.
А уж Delphy так вообще был industry wide standard!
И что же Вас не устраивает с уровнем безопастности на данный момент?
Например то, что «уровень безопасноcти на данный момент» не является «максимально возможным уровнем безопасности». И если этот самый уровень можно ещё поднять, то в общем-то по хорошему стоит это сделать. То есть прямо вот кидаться переписывать весь софт заново может и не надо, но возможно стоит подумать об альтернативах для новых продуктов.
Заранее заявлю — Чернобыль тупо человеческая ошибка, а Фукусима — игнорирование рекомендаций МАГАТЭ
То еcть вы предлагаете подождать пока где-то что-то случиться именно из-за софта и только тогда начинать думать и об усилении безопасности в этом плане?
Думаю, что Вы огорчитесь, узнав что в реальности всё намного проще. Ну или мягко сказать будете в шоке)
На ТЭС, АЭС (по крайней мере знакомых мне) используют линукс из ряда постарее с кастрированным функционалом (к примеру на одной АЭС до сих пор стоит сборка на основе 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 лет назад, когда массово стали внедрятся компьютеры, казалось вот вот и всё будет автоматизированно, даже налоги будут считаться автоматически…
Но нет будущее не наступило, всё так же люди корпят над проводками и сведением балансов.
Песня про физический труд роботов и отдых человеков, далека по прежнему примерно как в ситуации с Ахиллесом и черепахой
Б`ольшую часть сообщества разработчиков составляют джуны. И они же чаще других отправляются на stackoverflow. А это уже x^2. Т.е. бОльшая часть решений в мире IT (с учетом опен-сорса, учебных и пет-проектов) принимают разработчики с минимальным понимаем того, что и зачем они делают.
P.S. я ни в коем случае не говорю, что опен-сорс, пет-проекты или джуны — это что-то плохое. Мое мнение лишь в том, что это не те понятия, на которые можно спокойно опереться.
~10 фреймворков PHP, которые сейчас есть, будут консолидированы.Их уже сейчас по сути только два осталось. Ларавел и Симфони. У остальных доля мизерная.
Тут недавно уже была статья про инструмент, который пытался предугадывать желания пользователя: Ученые переименовали 27 человеческих генов, потому что Excel их неправильно обрабатывал.
Вот примерно то же самое будет, если заменитель интеллекта начнет угадывать намерения разработчиков и вмешиваться. Недетерминированные угадывающие инструменты не должны влиять на результат. Максимум — выдавать предупреждения. Решения все равно должен принимать человек. Явное лучше неявного.
Автодополнение только предлагает варианты. Конечное решение принимает пользователь.
Как там было про 20% и 80%? :)
То есть да, в 80% случаев VS предлагает правильную подсказку или скажем resharper предлагает полезный рефакторинг. Но это те 80% где и без них всё просто решается. А проблемы обычно создают оставшиеся 20%. И вряд ли ИИ в этом плане что-то сильно изменит. Простые вещи он поможет решить, но их я и без него решу не напрягаясь…
— Джарвис, сбацай-ка мне Интернет-магазин на базе PHP, используя в базе только поля «группа\подгруппа\артикул\описание артикула\цена\цена_оптовая\moq\наличие\адрес доставки\world_id_заказчика».
— Размести на Уругвайском хостинге не дороже 33 рублей в месяц.
— Шрифты используй Comic Sanserif и что-то такое в красненьких тонах, с синенькими буквами.
— Да! И не забудь поддержку IE6 и Android 1.6.
Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.
Всё же надеюсь, что в будущем мы не будем более быстро набирать буковки, а пересядем уже в "машину".
не знаю как ваше, но мое программирование будет выглядеть так же, как и последние 20 лет:
terminal, vim, make, gcc, clang, etc.
скорей всего даже colorscheme в виме останется тот же. Стабильность!
«конструктор кода по шаблонам проектирования»
Особенно повеселил раздел про стаковерфлой.
Сверять свой код с ответом десятилетней давности — это прекрасная практика, я считаю :)
TL;DR В 2025 разработчики станут еще тупее, а IDE будет жрать не только всю память, но и весь канал.
У меня нет ярко выраженного мнения на этот счет.
Точнее есть, но оно вам не понравится: хорошему языку, который разработчику знаком, — автокомплит не нужен. Я полностью отказался от автокомплита в эликсире, эрланге и руби. Я быстрее печатаю, чем выбираю из списка. У меня раньше были еще сниппеты всякие, но тоже в прошлом — если прям так болит палец, что печатать не могу — открою соседний проект и скопипащщу оттуда.
На всяких джаве, питоне, R, — на которых пишу значительно реже, — автокомплит включен, и даже если бы я постоянно на них писал — упомнить все стопятьсот миллиардов библиотечных классов и методов я вряд ли бы смог. У хаскеля та же болезнь: чтобы не изобретать велосипедов, нужно в хугле проводить больше времени, чем в редакторе — и тут автокомплит, безусловно, помогает. Кстати, конкретно для хаскеля я бы натравливал AI не на гитхаб, а именно на хугл (подозреваю, что этот ваш найнинчнейл так и делает).
В общем, для новичка — безусловное добро. Для развесистых, перегруженных парадигмами и реализациями языков — тоже.
В остальных случаев — я думаю медленнее, чем набиваю код, поэтому батлнек в другом месте.
Вера в супер-пуперские AST-преобразования, конечно, серьёзная. Мы вот в Java уже больше 15 лет имеем Structural search & replace, который делает пользовательские AST-преобразования и весьма неплохо. Но я не представляю, чтобы миграция между несовместимыми фреймворками описывалась через него. Там всегда куча именно семантических краевых случаев, которые идеально не покроешь. Если вслепую массово применить к большой кодовой базе, посадишь пачку загадочных багов, которые потом запаришься отлаживать. Тем более в языке без статической типизации.
КМК, 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 в языках
Главное — аккуратнее смешивать, а то тайпчекинг неразрешимым станет
Это да…
Как там в коке с сетоидами хотя бы? Они вылезают в каждой второй задаче.
не знаю, я думаю надо chapuza спросить, то он вроде как спец по нему
Ладно, фиг с ним. Нафига в 2020-м году писать руками возвращаемый тип матча, я уж не говорю о 2025-м
Согласен полностью, пора в 2020 уходить от этого
надо chapuza спросить, то он вроде как спец по нему
Упаси святой восьмибитный процессор! Я название-то только в прошлом году выучил, до сих пор иногда через “ck” на конце пишу.
Как показало время, «не взлетел»…
А есть что о нем почитать? интересно
bourabai.ru/alg/clarion/index.htm
Пошёл учить пхп...
Как будет выглядеть программирование в 2025 году?