Ну, эсцет `ß` допускает 2 варианта записи в верхнем регистре `ẞ` и `SS`. Если один из них срабатывает, то имхо норм. Хоть тут и возникает некоторая необратимость в преобразованиях регистра, но для немецкого это в норме вещей. Тем более, что эсцет выходил из широкого употребления ещё в начале нулевых.
А вот о чём, кстати, пост? По-моему он исключительно о том, почему Альберту Степанцеву нравится PHP. Причём с весьма слабыми доводами и натяжками.
На вопрос из заголовка ответа нет, нет даже доказательств, что PHP является "одним из самых востребованных". То, что в интернете есть куча home pages, которые когда-то были написаны на PHP, а так же миллионы развёрнутых CMS - это имхо не аргумент. Это только показывает, что когда-то он был востребованным.
Для начала бы определиться со скоупом. Востребованный для чего?
Чтобы вести свой блог? Когда-то да, Wordpress в 2 клика в админке хостера и погнали. Сейчас очевидно нет. Соцсети давно уже заняли эту нишу, и поднимать свой личный блог в 2025 году на Wordpress - это шиза.
Чтобы сделать сайт-визитку для компании? Когда-то да, заказали в веб-студии за 20 т.р., они подняли CMS, скин натянули и погнали наполнять. Сейчас очевидно нет. Для компании важнее хорошо оформить карточки в 2Gis и Яндексе, и вести профиль в соц.сетях.
Чтобы сделать свой интернет-магазин? Спорно, конкурентов у PHP тут хватало и 15 лет назад, но допустим. Заказали у веб-студии за 100-150 т.р. разработку и ok. Сейчас очевидно нет. Маркетплейсы полностью вытеснили мелкие интернет-магазины.
Вообще формат CMS потерял популярность, уступив место SaaS решениям. И считать, что 100 тыс доменов привязанных к Tilda == 100 тыс проектов на PHP - это тупо. Это 1 проект, сколько бы там доменов ни было.
А приводить в пример ВКонтакте, который выбрал PHP 20 лет назад и чтобы не загнуться от последствий такого выбора, был вынужден написать свой компилятор - такое себе. Имхо, выглядит как аргумент, почему выбрать PHP было для них ошибкой.
Переход от PHP 4 к PHP 5 принес полноценное ООП, сделав язык удобным для коллективной работы. Версия 5.4 подарила неймспейсы и пакетный менеджер — PHP стал платформой для больших команд. PHP 7 произвел революцию в производительности благодаря работе Дмитрия Стогова из Core team.
Тут для полноты картины не хватает рассказа о достижениях PHP 6, который собственно и породил разговоры о том, что PHP своё отыграл, т.к. они так и не осилили поддержку Unicode добавить.
Ну и неизбывная особенность PHP - это процедурная стандартная библиотека с несогласованными функциями. Напр. str_split, но strpos (почему не str_pos?), зато у обеих строка идёт первым аргументом. Вроде логично, смотрим str_replace и внезапно основная строка - третий аргумент. О том, чтобы сделать это всё методами объекта String и речи не идёт. Так что никаким полноценным ООП в PHP не пахнет до сих пор.
А так, конечно, PHP не убиваем, столько сайтов на Wordpress, Joomla и Drupal, что если только их сложить уже больше 80% всех сайтов в мире получится.
P.S. Лично я перестал писать на PHP в 2009-м и ни разу не пожалел, в мире есть гораздо более приятные ЯП (и да, тут речь уж точно не про Go), так что не стоит зашориваться на чём-то одном.
Соглашусь. Все эти ассистенты больше похожи на интерфейс к поиску, который и запрос поймёт получше гугла и результаты сразу агрегирует в читаемый вид. Попробуйте PHind. На мой вкус, он для этих юзкейсов даже получше ChatGPT.
Ну да, имхо, новость должна быть либо про что-то широко известное, либо новость и должна презентовать что-то новое. А тут минорная версия какого-то нового языка и получилось непонятно, чем именно 0.30.2 стала такой примечательной, что удостоилась новости.
не является pure dataflow, это все control-flow с элементами dataflow
Погодите. Я правильно понимаю ситуацию? Вот я говорю, что есть Elixir c GenStage и Flow, которые позволяют реализовывать любую dataflow задачу стабильно, со всеми нужными примочками, обвязками и интроспекцией.
А вы говорите, что этого недостаточно, только потому что он не принуждает вас насильно писать в dataflow-подходе абсолютно всё, включая расчёт чисел Фибоначчи и вывод в консоль? Мне кажется, тут идея идёт уже в ущерб практичности и универсальности.
То, что вы описываете, в целом то и похоже на акторную модель. Акторы так же, как у вас компоненты, запускаются и ждут сообщений. Вы можете запустить определенные акторы, которые должны ожидать сообщений постоянно, а можете при получении потока данных динамически запустить много акторов, которые чисто обработают эти данные и завершатся.
Вопрос только в описании графа перетекания данных между акторами. В целом, можно это сделать в декларативном виде.
И я согласен, что это удобный подход для проектирования системы на верхнем уровне. Под неудобством я имел в виду, что внутренняя реализация акторов как раз является более простым кодом и там уже на каждый чих типа вывести "Hello world" в консоль продолжать думать потоками данных - это уже оверхед.
Концепция интересная: каждая следующая команда имеет на входе результат предыдущей , поэтому вместо обычной записи c(b(a())) можем иметь более наглядную а -> b -> c
Так это обычный pipe-оператор, который является одной из основных синтаксических конструкций в таких языках как Elixir и F#
На том же Elixir есть Flow - библиотека для потоковой обработки. Вот например, как посчитать частоту употребления слов в текстовом документе:
path_to_file
# потоковое чтение из файла
|> File.stream!()
# использовать IO-поток в качестве продьюсера для Flow
|> Flow.from_enumerable()
# разбить каждую строку по пробельным символам
|> Flow.flat_map(fn(line) -> String.split(line, ~r/\s+/) end)
# распараллелить дальнейшую обработку на несколько потоков
|> Flow.partition()
# отфильтровать то, что не является словами
|> Flow.filter(fn(word) -> Regex.match?(~r/^[\w-]+$/iu, word) end)
# выполнить свёртку с подсчётом слов
|> Flow.reduce(fn -> %{} end, fn(word, acc) ->
Map.update(acc, word, 1, fn(count) -> count + 1 end)
end)
# преобразовать в список - реальные вычисления инициируются тут
|> Enum.to_list()
# отсортировать результат по убыванию частотности слов
|> Enum.sort(fn({_w1, count1}, {_w2, count2}) -> count1 >= count2 end)
А как эту же задачу решить на Neva?
P.S. Другое дело, что несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно. Поэтому глупо весь язык под это затачивать.
Ну, эсцет `ß` допускает 2 варианта записи в верхнем регистре `ẞ` и `SS`. Если один из них срабатывает, то имхо норм. Хоть тут и возникает некоторая необратимость в преобразованиях регистра, но для немецкого это в норме вещей. Тем более, что эсцет выходил из широкого употребления ещё в начале нулевых.
Отчего же, например, в Elixir эти примеры спокойно работают, причём без воркэраундов, без перевода в массивы и т.п.
А функции на Си кто писал? Пушкин что-ли)
Если вы имели в виду, что это функции из С-stdlib, то нет. Там только такие: https://ru.wikipedia.org/wiki/String.h
А эти хоть и на Си, но написаны разработчиками PHP.
Не осилили было в контексте того, что полноценной поддержки Unicode так и нет до сих пор. Проверьте на примерах из этой статьи
Да, в целом, есть языки в которых есть bitstring и просто string. Если нормально всё реализовать, то это даже удобно)
Например, успешное прохождение всех проверок из этой статьи: https://mortoray.com/the-string-type-is-broken/
А вот о чём, кстати, пост? По-моему он исключительно о том, почему Альберту Степанцеву нравится PHP. Причём с весьма слабыми доводами и натяжками.
На вопрос из заголовка ответа нет, нет даже доказательств, что PHP является "одним из самых востребованных". То, что в интернете есть куча home pages, которые когда-то были написаны на PHP, а так же миллионы развёрнутых CMS - это имхо не аргумент. Это только показывает, что когда-то он был востребованным.
Для начала бы определиться со скоупом. Востребованный для чего?
Чтобы вести свой блог? Когда-то да, Wordpress в 2 клика в админке хостера и погнали. Сейчас очевидно нет. Соцсети давно уже заняли эту нишу, и поднимать свой личный блог в 2025 году на Wordpress - это шиза.
Чтобы сделать сайт-визитку для компании? Когда-то да, заказали в веб-студии за 20 т.р., они подняли CMS, скин натянули и погнали наполнять. Сейчас очевидно нет. Для компании важнее хорошо оформить карточки в 2Gis и Яндексе, и вести профиль в соц.сетях.
Чтобы сделать свой интернет-магазин? Спорно, конкурентов у PHP тут хватало и 15 лет назад, но допустим. Заказали у веб-студии за 100-150 т.р. разработку и ok. Сейчас очевидно нет. Маркетплейсы полностью вытеснили мелкие интернет-магазины.
Вообще формат CMS потерял популярность, уступив место SaaS решениям. И считать, что 100 тыс доменов привязанных к Tilda == 100 тыс проектов на PHP - это тупо. Это 1 проект, сколько бы там доменов ни было.
А приводить в пример ВКонтакте, который выбрал PHP 20 лет назад и чтобы не загнуться от последствий такого выбора, был вынужден написать свой компилятор - такое себе. Имхо, выглядит как аргумент, почему выбрать PHP было для них ошибкой.
Это всё конечно хорошо. Но для практического применения лучше изучить Elixir, во всяком случае если вас backend-разработка интересует.
https://www.erlang-solutions.com/blog/why-elixir-is-the-programming-language-you-should-learn-in-2024/
Тут для полноты картины не хватает рассказа о достижениях PHP 6, который собственно и породил разговоры о том, что PHP своё отыграл, т.к. они так и не осилили поддержку Unicode добавить.
Ну и неизбывная особенность PHP - это процедурная стандартная библиотека с несогласованными функциями. Напр. str_split, но strpos (почему не str_pos?), зато у обеих строка идёт первым аргументом. Вроде логично, смотрим str_replace и внезапно основная строка - третий аргумент. О том, чтобы сделать это всё методами объекта String и речи не идёт. Так что никаким полноценным ООП в PHP не пахнет до сих пор.
А так, конечно, PHP не убиваем, столько сайтов на Wordpress, Joomla и Drupal, что если только их сложить уже больше 80% всех сайтов в мире получится.
P.S. Лично я перестал писать на PHP в 2009-м и ни разу не пожалел, в мире есть гораздо более приятные ЯП (и да, тут речь уж точно не про Go), так что не стоит зашориваться на чём-то одном.
Соглашусь. Все эти ассистенты больше похожи на интерфейс к поиску, который и запрос поймёт получше гугла и результаты сразу агрегирует в читаемый вид. Попробуйте PHind. На мой вкус, он для этих юзкейсов даже получше ChatGPT.
Так они ещё и язык специальный придумали, где можно побольше избыточного бойлерплейта генерировать, Golang называется xD
Теперь понятно зачем он такой невыразительный. Чтоб красивые проценты по достижениям нейросетей рисовать.
Надо было вопрос точнее формулировать: Почему её не можно трогать? xD
Вы тут используете риторический приём "ложная дихотомия"
У вас просто нет фокуса на новую деятельность. Поэтому вы вместо продуктивных действий праздно жалуетесь на жизнь в комментариях.
Юзкейсы Симулинка понятны. Но мне показалось, что в случае Neva речь о том, чтобы всё в таком стиле писать.
Ну да, имхо, новость должна быть либо про что-то широко известное, либо новость и должна презентовать что-то новое. А тут минорная версия какого-то нового языка и получилось непонятно, чем именно 0.30.2 стала такой примечательной, что удостоилась новости.
Погодите. Я правильно понимаю ситуацию? Вот я говорю, что есть Elixir c GenStage и Flow, которые позволяют реализовывать любую dataflow задачу стабильно, со всеми нужными примочками, обвязками и интроспекцией.
А вы говорите, что этого недостаточно, только потому что он не принуждает вас насильно писать в dataflow-подходе абсолютно всё, включая расчёт чисел Фибоначчи и вывод в консоль? Мне кажется, тут идея идёт уже в ущерб практичности и универсальности.
Если мы хотим последовательно, то будут последовательно, хотим параллельно - будут параллельно.
Я уже выше приводил пример с Flow. Но можно и ещё проще, например, хотите в 10 параллельных потоков события обработать, вот пожалуйста:
Другими словами, когда надо - распараллеливаете, когда надо - схлопываете снова в 1 поток.
Подробнее о базовых элементах: Task, Stream
И о самом потоковом подходе: GenStage и Flow
То, что вы описываете, в целом то и похоже на акторную модель. Акторы так же, как у вас компоненты, запускаются и ждут сообщений. Вы можете запустить определенные акторы, которые должны ожидать сообщений постоянно, а можете при получении потока данных динамически запустить много акторов, которые чисто обработают эти данные и завершатся.
Вопрос только в описании графа перетекания данных между акторами. В целом, можно это сделать в декларативном виде.
И я согласен, что это удобный подход для проектирования системы на верхнем уровне. Под неудобством я имел в виду, что внутренняя реализация акторов как раз является более простым кодом и там уже на каждый чих типа вывести "Hello world" в консоль продолжать думать потоками данных - это уже оверхед.
Что вы под этим подразумеваете? Pipe-operator?
Так это обычный pipe-оператор, который является одной из основных синтаксических конструкций в таких языках как Elixir и F#
На том же Elixir есть Flow - библиотека для потоковой обработки. Вот например, как посчитать частоту употребления слов в текстовом документе:
А как эту же задачу решить на Neva?
P.S. Другое дело, что несмотря на удобство pipe-оператора писать 100% кода только в этом стиле - это неудобно. Поэтому глупо весь язык под это затачивать.
Да, можно вместо th расслаблено произносить d и носители вас прекрасно поймут.