stride — это способ генерации последовательности/массива, поэтому использовать его для замены счётчика итераций значит использовать его не по назначению. Я не уверен в отсутствии оптимизаций на этот случай на уровне компилятора, но, честно говоря, присутствие таких оптимизаций было бы нелогичным. Классический цикл for отсутствует во многих функциональных языках, но в любом из них генерация списка чисел для обхода считается моветоном.
А потом другим программистам наслаждаться поддержкой кода таких творцов.
Вы всерьёз считаете, что конструкции типа for i in 1000000.stride(to:1, by: -1)
читаемы и удобнее в поддержке, чем примитивный for-цикл?
Или что операторы инкремента/декремента могут стрелять по ногам?
Понятно, что авторы языка решают что оставлять, но аргументы на тему, что конеретно эти изменения хоть как-то способны улучшить качество кода, выглядят очень странно.
Ладно бы все, как один, написали: фиг с ним с for, будем хвостовую рекурсию использовать… но нет, все про этот жуткий вариант со stride, который ещё и память на абсолютно ненужную последовательность тратить будет.
Я вспоминаю 2007-й год. Из всего фронт-энда у нас был только PrototypeJS.
Справедливости ради, уже был выбор как минимум из PrototypeJS, MooTools, jQuery и YUI.
Хотя мне ещё тогда казалось, что это перебор. А сейчас этот буриданов выбор расплодился в геометрической прогрессии.
То, что в кортеж нельзя добавить новые элементы, не делает его структурой времени компиляции, а лишь неизменяемой структурой данных. Есть много языков, в которых ни один экземпляр любого типа нельзя изменить во время выполнения. Но это не повод называть тот же list структурой времени компиляции.
Допустим, у нас есть кортеж {x, y}, если его конкретное значение может быть всегда вычислено на этапе компиляции, то да, это структура времени компиляции. Но если какой-то внешний фактор, например пользовательский ввод, может повлиять на значение x или y, то это уже совсем не структура времени компиляции.
в то время как встроенный сервер php — совсем не производительное решение
Вы так пишете как-будто Webrick (встроенный сервер для Ruby) — производительное решение. Добавьте в Gemfile строку
gem 'thin'
и посмотрите ещё раз (после bundle install).
А по теме статьи, Вы по сути выбираете из медленных технологий. Рассмотрите Elixir+Phoenix и Golang+Gin, если производительность без кеша имеет значение для вас :-)
Вообще, слово взрыв там не очень уместно закрепилось, потому что рождает абсолютно левые ассоциации. Процесс расширения Вселенной больше похож на надувание шарика, где поверхность шарика — это и есть Вселенная. Что вокруг неё и что внутри неё неведомо, т.к. выйти за пределы Вселенной, будучи её частью, скорее всего нереально.
Вы помните, сколько нужно было написать кода, чтобы вывести стандартное окно, просто обрабатывающее стандартные кнопки и стандартное меню сворачивания, разворачивания и закрытия окна с помощью Win32 API?
Я помню, только, справедливости ради, этот код писали вручную разве что для развлечения уже 10 лет назад. В Visual C++ он генерировался автоматически в отдельных файлах, а в Delphi его даже видно не было. Ну и кстати ничего особо страшного в том коде не было, довольно простой, только многословный. Поэтому декларативный способ описания форм в итоге победил.
Тут вопрос скорее в том, что для человека важнее. Если главное «пройти интересный квест», то это тоже самообразование, но уже не по специальности. Хотя кто знает, что Вы под квестом подразумеваете… может специализация туда тоже входит…
А вот почему забыли про Elixir и Nim непонятно...
Вы всерьёз считаете, что конструкции типа
for i in 1000000.stride(to:1, by: -1)читаемы и удобнее в поддержке, чем примитивный for-цикл?
Или что операторы инкремента/декремента могут стрелять по ногам?
Понятно, что авторы языка решают что оставлять, но аргументы на тему, что конеретно эти изменения хоть как-то способны улучшить качество кода, выглядят очень странно.
Ладно бы все, как один, написали: фиг с ним с for, будем хвостовую рекурсию использовать… но нет, все про этот жуткий вариант со stride, который ещё и память на абсолютно ненужную последовательность тратить будет.
Хотя мне ещё тогда казалось, что это перебор. А сейчас этот буриданов выбор расплодился в геометрической прогрессии.
Допустим, у нас есть кортеж {x, y}, если его конкретное значение может быть всегда вычислено на этапе компиляции, то да, это структура времени компиляции. Но если какой-то внешний фактор, например пользовательский ввод, может повлиять на значение x или y, то это уже совсем не структура времени компиляции.
и посмотрите ещё раз (после bundle install).
А по теме статьи, Вы по сути выбираете из медленных технологий. Рассмотрите Elixir+Phoenix и Golang+Gin, если производительность без кеша имеет значение для вас :-)
Так это Вы суверенный дефолт описали. Он, кстати, не освобождает от долга, а переносит вопрос в международные суды.
tag .class {}— это стиль, который применится к любым элементам с классом «class», находящимся внутри элементов tagtag.class {}— это стиль, который применится к элементам tag с классом «class»