Мне вот интересно, почему в России/Украине почти ни один магазин не отправляет заказ без подтверждения по телефону. При этом в Европе (Западной Европе) ни один магазин не звонит подтверждать заказ. Это разница в менталитете или просто так исторически сложилось (изначально повелось)?
Между прочим Nashorn/Rhino не такие уж и "экзотические". Да, это не браузер — нету window, нету event loop. Но это полноценные JavaScript движки. Никто не мешает даже писать на ES6 и транспилить это дело babel-ом. И даже React там может работать.
Наверно потому же, почему и Java тестировали на сервлетах, хотя есть Grizzly/Netty. Типа это более популярно. Хотя если кто-то только смотрит на финальные каритинки, не читая текст, в надежде выбрать более "крутую" технологию для нового проекта, то может сложиться немного неадекватное предстваление. Ведь и на PHP, и на Java можно сделать оптимальнее. Даже касательно Node.js, если задача напряжная для CPU (как здесь — подсчёт контрольных сумм), то можно запустить несколько процессов и баллансировать между ними nginx-ом/haproxy/etc. Это позволит загрузить все ядра процессора. Так сравнивать некорректно. Но Go всё же рулит.
Если у вас IPC < 1.0, то я вас поздравляю, ваше приложение простаивает в ожидании данных от оперативной памяти.
А разве все инструкции выполняются за один такт? Разве не существует инструкций которые выполняются несколько таков и т.о. даже при отсутствии ожидания среднее количество инструкций на такт будет меньше 1?
Если бы только одну команду запомнить. А надо то ещё запоминать названия всех сервисов. Раньше можно было набрать cat /var/log/a-few-letters и нажать tab либо вообще поставить звёздочку, а теперь надо запускать systemctl, где искать полное название сервиса и копипастить его в параметры journalctl. Или всё же есть адекватный способ?
В Вашем примере на D только один массив непонятного размера и бизнес-логика (суммирование) не вынесено в отдельную функцию. Если же создать 4 массива с элементами разных размеров и не инлайнить функцию суммирования (а написать template, который будет понимать разные типы), то кода будет чуть больше… Но в целом Ваши негодования понятны — отсутствие в стандартной библиотеки функции reduce (есть сторонние реализации) и отсутствие generic-ов — на эту тему уже много написано, даже авторами языка.
Среднестатистическому — нет (хотя WebAssembly набирает обороты). А вот крутому — да. Чтоб он потом не писал очередной транспилер на ноде, заставляя тысячи других фронтэндеров покупать новые макбуки.
Вообще говоря, если смотреть на доминирующую архитектуру процессоров, то она нынче мультиядерная. А распараллеливаются, как раз, лучше "чистые" функции, которые используют только иммутабельные данные.
Ну вот, например, в Андроиде по умолчанию вплоть до 6-й версии был toolbox, где не было cp. В Гугл вот такие вот забавные ребята. Потому приходилось во всех сриптах для копирования использовался dd или cat перенаправлением ввода.
Так "bash scripting" — это название всего цикла. Это стандартная практика пихать в книги/циклы статей сопутствующий материал, только косвенно относящийся к тематике, просто указывая во введении что-то типа: "Если вы, в bash-скриптах, каким-то образом обрабатываете данные, вам не помешает знакомство с инструментами sed и gawk".
Если в статьях про баш-скрипты писать только про bash builtins и ничего более, то они будут очень скудными и далёкими от реальности. Например, cat, ls и find — тоже внешние программы.
cp — это не bash builtin (как :), это отдельная программа (обычно отсюда), которая ещё может и отсутствовать (например, на embedded-устройствах или на Android-телефонах). Лучше приучать себя к lightweight решениям.
Московские магазины часто звонят подтверждать заказ даже после 100% оплаты.
Мне вот интересно, почему в России/Украине почти ни один магазин не отправляет заказ без подтверждения по телефону. При этом в Европе (Западной Европе) ни один магазин не звонит подтверждать заказ. Это разница в менталитете или просто так исторически сложилось (изначально повелось)?
Между прочим Nashorn/Rhino не такие уж и "экзотические". Да, это не браузер — нету window, нету event loop. Но это полноценные JavaScript движки. Никто не мешает даже писать на ES6 и транспилить это дело babel-ом. И даже React там может работать.
Наверно потому же, почему и Java тестировали на сервлетах, хотя есть Grizzly/Netty. Типа это более популярно. Хотя если кто-то только смотрит на финальные каритинки, не читая текст, в надежде выбрать более "крутую" технологию для нового проекта, то может сложиться немного неадекватное предстваление. Ведь и на PHP, и на Java можно сделать оптимальнее. Даже касательно Node.js, если задача напряжная для CPU (как здесь — подсчёт контрольных сумм), то можно запустить несколько процессов и баллансировать между ними nginx-ом/haproxy/etc. Это позволит загрузить все ядра процессора. Так сравнивать некорректно. Но Go всё же рулит.
А разве все инструкции выполняются за один такт? Разве не существует инструкций которые выполняются несколько таков и т.о. даже при отсутствии ожидания среднее количество инструкций на такт будет меньше 1?
Там же метка "перевод" стоит. Instagram это с полгода назад у себя в блоге публиковал.
Если бы только одну команду запомнить. А надо то ещё запоминать названия всех сервисов. Раньше можно было набрать
cat /var/log/a-few-lettersи нажать tab либо вообще поставить звёздочку, а теперь надо запускатьsystemctl, где искать полное название сервиса и копипастить его в параметрыjournalctl. Или всё же есть адекватный способ?Дык статья "Как получить тестовое задание в день регистрации и не ждать сто лет" будет следующей из цикла.
Так это же костыль от бессилия сделать нормальную аутентификацию, причем используя средства совсем для этого не предназначенные. И об этом уже писали.
В Вашем примере на D только один массив непонятного размера и бизнес-логика (суммирование) не вынесено в отдельную функцию. Если же создать 4 массива с элементами разных размеров и не инлайнить функцию суммирования (а написать template, который будет понимать разные типы), то кода будет чуть больше… Но в целом Ваши негодования понятны — отсутствие в стандартной библиотеки функции reduce (есть сторонние реализации) и отсутствие generic-ов — на эту тему уже много написано, даже авторами языка.
Если реально всем, то в чём проблема автоматизировать отправку этих "инвайтов" в наш современный век?
А NFC-тэги курам внедрять не думали? Понимаю, что дороже, но всё же надёжнее — на кону же жизнь курицы!
Среднестатистическому — нет (хотя WebAssembly набирает обороты). А вот крутому — да. Чтоб он потом не писал очередной транспилер на ноде, заставляя тысячи других фронтэндеров покупать новые макбуки.
Вообще говоря, если смотреть на доминирующую архитектуру процессоров, то она нынче мультиядерная. А распараллеливаются, как раз, лучше "чистые" функции, которые используют только иммутабельные данные.
Ну вот, например, в Андроиде по умолчанию вплоть до 6-й версии был toolbox, где не было
cp. В Гугл вот такие вот забавные ребята. Потому приходилось во всех сриптах для копирования использовалсяddилиcatперенаправлением ввода.Так "bash scripting" — это название всего цикла. Это стандартная практика пихать в книги/циклы статей сопутствующий материал, только косвенно относящийся к тематике, просто указывая во введении что-то типа: "Если вы, в bash-скриптах, каким-то образом обрабатываете данные, вам не помешает знакомство с инструментами sed и gawk".
Если в статьях про баш-скрипты писать только про bash builtins и ничего более, то они будут очень скудными и далёкими от реальности. Например,
cat,lsиfind— тоже внешние программы.cp— это не bash builtin (как:), это отдельная программа (обычно отсюда), которая ещё может и отсутствовать (например, на embedded-устройствах или на Android-телефонах). Лучше приучать себя к lightweight решениям.