В секретных чатах это делается на стороне клиента, так что шансов что что-то пойдёт не так гораздо меньше, даже если сообщение перехвачено. Алгоритмы открыты, те кто хочет могут проверить их надежность и стойкость.
Меня лично очень смущает тот факт что телегаму доступна вся история обычных сообщений, посему я никогда не скажу в обычном чате того чего бы не сказал в публичном месте. По сути, телеграм это несколько улучшенная аська, но не более того.
С другой стороны, супер-пупер-секурные мессенжеры (а-ля Signal) обладают существенным недостатком — невозможность одновременного использования нескольких устройств с синхронизацией всех сообщений между ними, в то время как потеря устройства обозначает потерю всей истории — вот это большая проблема.
Вы разницы все равно не заметите. Даже если таких фрагментов будет сотня.
Если фрагмент настолько прост — может быть. А если он сложнее и их десятки тысяч? Что-то я сомневаюсь что тот кто привык писать всё «в лоб» хоть на секунду задумается о разнице.
То что движок не умеет оптимизацию — это конечно проблема движка, но пока это так (а ситуация вряд ли изменится в обозримом будущем) — разработчик должен об этом думать. Если он об этом не думает, то получаются раздутые тормозные приложения.
«на порядок» — это «в 10 раз». Хотя в данном конкретном случае (я чисто из вредности проверил) разница получилась аж в 20(!) раз (последний хром).
Разумеется, если такой фрагмент выполняется один раз или очень редко, это не очень существенно, но речь о том что те кто думает что «так понятнее» делают это везде (и другим советуют), в итоге в более-менее сложном приложении (или при ощутимо большем числе элементов) это накапливается и можем легко получить вместо 0.05 секунды аж целую одну, а это уже существенная задержка.
На самом деле, даже если опустить вопрос эфективности, в данном случае больше удивляет сам ход мыслей разработчика — а именно создание массива для обработки простой последовательности чисел — вас это не смущает?
К тому же, как уже выше заметили, таки остался вопрос о том чем это реально лучше чем цикл по «понятности» — на мой взгляд, цикл как раз более понятен и логичен.
Решение такого типа реализовать можно (теоретически), но практически это будет очень дорого, энергоёмко и с сомнительной надежностью.
Сам факт наличия механики делает систему менее надежной, менее точной и более энергопотребляющей, но самый интересный вопрос — как приёмник отличит отражение от источника (который излучает во всех направлениях), особенно если в помещении есть хорошо отражающие поверхности (или фрагменты поверхностей)?
Даже если есть простое решение проблемы с отражениями (или комната не содержит отражающих поверхностей), то возникают ещё две проблемы:
— гарантировать обнаружение источника более чем одним приёмником, одновременно или в пределах небольшого временного интервала (поскольку они узконаправленные);
— гарантировать отсутствие препятствия на пути как минимум двух достаточно удалённых друг от друга приёмников в любой момент времени.
Первую можно решить быстрым вращением (лидары передают привет), а вот вторую — либо убиранием препятствий (что делает всю систему несколько менее практичной), либо использованием кучей приёмников, что, в свою очередь, приводит к чрезмерному усложению системы со всеми вытекающими (стоимость, надежность, энергопотребление). Впрочем, куча приёмников решит и проблему с отражениями (наверное), но это ещё больше усложнит систему.
Надеюсь, это сарказм? Этот фрагмент потребует минимум на порядок больше времени для выполнения, не говоря уже о необоснованных выделениях памяти и всеми последствиями этого.
Впрочем, если учесть что едва ли не 9 из 10 разработчиков пишут в таком стиле, неудивительно что всё требует жутко много памяти и работает очень медленно… зато удобно для глаз автора кода (наверное).
Чисто теоретически… пресс-хата может оказаться меньшим злом в сравнении с последствиями получения информации, и если прессуемый сам не в состоянии получить доступ (к примеру, физически уничтожена флешка с ключём), то это всё же может иметь смысл.
Гаджет, встроенный в ухо, «понимает», что у владельца — стрессовая ситуация, связанная с низким уровнем звука.
Не совсем понятно, как он «понимает» от чего конкретно стресс — это может быть как уровень звука, так и мысли о недавнем (или предстоящем) неприятном разговоре с кем-то, не говоря уже о том что стресс может быть как раз от слишком высокого уровня звука, который отвлекает от приготовления еды.
Я понимаю пользу явного указания namespace (в отдельных случаях), но, как я уже сказал выше — речь о случаях когда конфликты практически невозможны.
Похоже, некоторые разработчики просто считают using вредным, но вот читабельность кода от этого нисколько не улучшается, а если учесть темплейты и прочее, то конструкции разворачиваются просто невероятные, и это при том что гайдлайны проекта требуют всё вмещать в 80 колонок.
Ещё сильно «радует» явное использование префиксов namespace при использовании достаточно уникальных (и говорящих за себя) имен в C++ (и других языках с namespace) — типа std::string, std::printf и пр. на каждом шагу.
Очень интересно, какая религия не позволяет разрабочику указать «using namespace std» в файле, или даже в пределах scope где std так и пестрит.
Владельцы разныебывают, однако. Казалось бы, ну как так можно, но оказывается даже тот кто знает русское слово (и его правописание) почему-то неправильно пишет английское.
Рискну предположить что читателей хабра на порядки меньше чем русскоговорящих людей которые вообще не слышали слово «сепарировать» — оно довольно специфично и в быту практически не употребляется (я, к примеру, не могу вспомнить когда его слышал/видел последний раз, лет 20 точно уже прошло).
Но если вы погуглите site:ru "seperate", то тоже найдете немало случаев его неправильного употребления — и явно на русскоязычных ресурсах, и даже там где этого быть вроде как не должно.
Не совсем понял в чём могла бы заключаться моя неправота — то что это одна из самых распостраненных ошибок — это статистика.
Как его можно написать через «e» я сам не понимаю, но факт остается фактом — поищите в гугле site:uk "seperate" — почти 5 миллионов страниц, и даже если только четверть из них писали «настоящие» англичане — это всё равно очень много.
Странно что в список не попало слово separate, которое часто пишут как seperate, причём ошибочный вариант даже сам по себе включается в некоторые словари как «ошибочная форма от separate».
А почему нет? Вполне может быть что авторы ещё не представляют себе что там должно быть, как оно должно работать или вообще ещё не определились чего хотят, вот и эксперементируют, заодно собирая мнения и идеи.
Разница только в том что кто-то это делает публично, а кто-то «тайно» — в первом случае об отсутствии спецификации в начале разработки известно всем, а во втором об этом может никто и не узнать (поскольку её выложат вместе с языком) — хотя принципиальной разницы нет.
В конце концов, это ж не мостостроение, где опасно начинать строить пока нет проекта и расчётов, особенно с учётом того что нигде в продакшн это не используется.
Если это традиция, то где же компиляторы (или хотя бы интерпретаторы) Perl на Perl, PHP на PHP, Ruby на Ruby или Python на Python?
Чтобы отладить все нюансы есть достаточно реальных задач кроме собственно компилятора, в то время как написание компилятора не обязательно затронет все нюансы которые нужно отлаживать, но вот времени займёт просто уйму (особенно если язык сильно отличается от того на котором пишут первый компилятор).
Задачи, к тому же, необязательно должны быть такими сложными во время разработки языка — к примеру, для отладки рекурсии хватит чисел Фибоначчи, для отладки многопоточности или асинхронной обработки — web-client/server.
Но разумеется, если у разработчиков свободного времени вайлом — тогда да, почему бы и нет, собственно, пишут же эмулятор Z80 на bash…
Если кратко — почти все эти «способы» (кроме 2 и 4) это не более чем попытка натянуть сову на глобус, к тому же нет в этой области серебрянной пули и универсального рецепта для успеха.
Если кому-то кому интересно моё мнение по пунктам...
1. Если текст и так предполагает ответ, то просьба ответить будет явно лишней. Если получатель не в состоянии это понять, то ему вообще не стоит писать.
3. Ну да, приветствие и прощание с многострочной подписью конечно очень уместны в десятке сообщений которыми обмениваешься с одним человеком в течение одного дня. Как и цитирование всего что было написано до этого. Как и привычка говорить «привет» и «пока» при каждой встрече сотрудника в коридоре в течение одного дня — явное проявление чрезвычайного уважения.
5. Объем письма должен быть таким какой нужен для доведения сути. Впрочем, тут другая проблема — как показывает практика, в 90% случаев люди читают (или запоминают) либо первое, либо последнее предложение, тупо пропуская всё что между — хотя это бывает важно (и отправитель ожидает что его прочтут). Я помню переписку с одним клиентом, которому потребовалось много писем чтобы объяснить как решить проблему, хотя полное и пошаговое решение было описано в первом же письме — но он упорно его не читал потому что «письмо слишком длинное», пришлось все шаги разбить на предложения и отправить отдельными письмами.
6. Простой язык, как правило, уместен только с простыми людьми. Если мне напишут языком третьеклассника, я отправлю письмо в спам, потому что в 99% случаев это и будет спам. Остальной 1% остается для клиентов с языком на низком уровне, но обычно это легко отличимо от спама.
7. Эмоции это палка о трёх концах, тут всё зависит, но лучше их избегать — факты всегда лучше.
8. Жирный шрифт, италик — где уместно и без фанатизма — да. Разные цвета… это в 99% спам.
9. Время отправки вещь сомнительная. Например, в моём случае, письмо отправленное кем-то (от кого я не жду писем) между 6-7 утра с большой вероятностью окажется пропущенным — потому что в перид с 7 до 11 (в 11 я обычно начинаю читать почту) придёт ещё пара десятков, а если я начал читать её только в конце дня — то тем более. Лучший способ попасть вовремя — это написать в момент когда человек уже разгреб всю почту и проверяет снова — но этот момент угадать очень трудно, хотя можно с высокой вероятностью предположить что через час-два после начала рабочего дня человек уже разобрал всю почту.
—
set -eэто на самом деле эквивалентset -o errexit— опции
errunsetне существует в природе, естьnounsetи её эквивалентset -u.Меня лично очень смущает тот факт что телегаму доступна вся история обычных сообщений, посему я никогда не скажу в обычном чате того чего бы не сказал в публичном месте. По сути, телеграм это несколько улучшенная аська, но не более того.
С другой стороны, супер-пупер-секурные мессенжеры (а-ля Signal) обладают существенным недостатком — невозможность одновременного использования нескольких устройств с синхронизацией всех сообщений между ними, в то время как потеря устройства обозначает потерю всей истории — вот это большая проблема.
Прям таки «все»? Если это не секретный чат, то ничего особо безопасного там нет. Удобно — это да, в основном надежно, но явно не безопасно.
Если фрагмент настолько прост — может быть. А если он сложнее и их десятки тысяч? Что-то я сомневаюсь что тот кто привык писать всё «в лоб» хоть на секунду задумается о разнице.
То что движок не умеет оптимизацию — это конечно проблема движка, но пока это так (а ситуация вряд ли изменится в обозримом будущем) — разработчик должен об этом думать. Если он об этом не думает, то получаются раздутые тормозные приложения.
Разумеется, если такой фрагмент выполняется один раз или очень редко, это не очень существенно, но речь о том что те кто думает что «так понятнее» делают это везде (и другим советуют), в итоге в более-менее сложном приложении (или при ощутимо большем числе элементов) это накапливается и можем легко получить вместо 0.05 секунды аж целую одну, а это уже существенная задержка.
На самом деле, даже если опустить вопрос эфективности, в данном случае больше удивляет сам ход мыслей разработчика — а именно создание массива для обработки простой последовательности чисел — вас это не смущает?
К тому же, как уже выше заметили, таки остался вопрос о том чем это реально лучше чем цикл по «понятности» — на мой взгляд, цикл как раз более понятен и логичен.
Сам факт наличия механики делает систему менее надежной, менее точной и более энергопотребляющей, но самый интересный вопрос — как приёмник отличит отражение от источника (который излучает во всех направлениях), особенно если в помещении есть хорошо отражающие поверхности (или фрагменты поверхностей)?
Даже если есть простое решение проблемы с отражениями (или комната не содержит отражающих поверхностей), то возникают ещё две проблемы:
— гарантировать обнаружение источника более чем одним приёмником, одновременно или в пределах небольшого временного интервала (поскольку они узконаправленные);
— гарантировать отсутствие препятствия на пути как минимум двух достаточно удалённых друг от друга приёмников в любой момент времени.
Первую можно решить быстрым вращением (лидары передают привет), а вот вторую — либо убиранием препятствий (что делает всю систему несколько менее практичной), либо использованием кучей приёмников, что, в свою очередь, приводит к чрезмерному усложению системы со всеми вытекающими (стоимость, надежность, энергопотребление). Впрочем, куча приёмников решит и проблему с отражениями (наверное), но это ещё больше усложнит систему.
Впрочем, если учесть что едва ли не 9 из 10 разработчиков пишут в таком стиле, неудивительно что всё требует жутко много памяти и работает очень медленно… зато удобно для глаз автора кода (наверное).
Не совсем понятно, как он «понимает» от чего конкретно стресс — это может быть как уровень звука, так и мысли о недавнем (или предстоящем) неприятном разговоре с кем-то, не говоря уже о том что стресс может быть как раз от слишком высокого уровня звука, который отвлекает от приготовления еды.
Похоже, некоторые разработчики просто считают using вредным, но вот читабельность кода от этого нисколько не улучшается, а если учесть темплейты и прочее, то конструкции разворачиваются просто невероятные, и это при том что гайдлайны проекта требуют всё вмещать в 80 колонок.
Очень интересно, какая религия не позволяет разрабочику указать «using namespace std» в файле, или даже в пределах scope где std так и пестрит.
Но если вы погуглите
site:ru "seperate", то тоже найдете немало случаев его неправильного употребления — и явно на русскоязычных ресурсах, и даже там где этого быть вроде как не должно.Как его можно написать через «e» я сам не понимаю, но факт остается фактом — поищите в гугле
site:uk "seperate"— почти 5 миллионов страниц, и даже если только четверть из них писали «настоящие» англичане — это всё равно очень много.Разница только в том что кто-то это делает публично, а кто-то «тайно» — в первом случае об отсутствии спецификации в начале разработки известно всем, а во втором об этом может никто и не узнать (поскольку её выложат вместе с языком) — хотя принципиальной разницы нет.
В конце концов, это ж не мостостроение, где опасно начинать строить пока нет проекта и расчётов, особенно с учётом того что нигде в продакшн это не используется.
Чтобы отладить все нюансы есть достаточно реальных задач кроме собственно компилятора, в то время как написание компилятора не обязательно затронет все нюансы которые нужно отлаживать, но вот времени займёт просто уйму (особенно если язык сильно отличается от того на котором пишут первый компилятор).
Задачи, к тому же, необязательно должны быть такими сложными во время разработки языка — к примеру, для отладки рекурсии хватит чисел Фибоначчи, для отладки многопоточности или асинхронной обработки — web-client/server.
Но разумеется, если у разработчиков свободного времени вайлом — тогда да, почему бы и нет, собственно, пишут же эмулятор Z80 на bash…
3. Ну да, приветствие и прощание с многострочной подписью конечно очень уместны в десятке сообщений которыми обмениваешься с одним человеком в течение одного дня. Как и цитирование всего что было написано до этого. Как и привычка говорить «привет» и «пока» при каждой встрече сотрудника в коридоре в течение одного дня — явное проявление чрезвычайного уважения.
5. Объем письма должен быть таким какой нужен для доведения сути. Впрочем, тут другая проблема — как показывает практика, в 90% случаев люди читают (или запоминают) либо первое, либо последнее предложение, тупо пропуская всё что между — хотя это бывает важно (и отправитель ожидает что его прочтут). Я помню переписку с одним клиентом, которому потребовалось много писем чтобы объяснить как решить проблему, хотя полное и пошаговое решение было описано в первом же письме — но он упорно его не читал потому что «письмо слишком длинное», пришлось все шаги разбить на предложения и отправить отдельными письмами.
6. Простой язык, как правило, уместен только с простыми людьми. Если мне напишут языком третьеклассника, я отправлю письмо в спам, потому что в 99% случаев это и будет спам. Остальной 1% остается для клиентов с языком на низком уровне, но обычно это легко отличимо от спама.
7. Эмоции это палка о трёх концах, тут всё зависит, но лучше их избегать — факты всегда лучше.
8. Жирный шрифт, италик — где уместно и без фанатизма — да. Разные цвета… это в 99% спам.
9. Время отправки вещь сомнительная. Например, в моём случае, письмо отправленное кем-то (от кого я не жду писем) между 6-7 утра с большой вероятностью окажется пропущенным — потому что в перид с 7 до 11 (в 11 я обычно начинаю читать почту) придёт ещё пара десятков, а если я начал читать её только в конце дня — то тем более. Лучший способ попасть вовремя — это написать в момент когда человек уже разгреб всю почту и проверяет снова — но этот момент угадать очень трудно, хотя можно с высокой вероятностью предположить что через час-два после начала рабочего дня человек уже разобрал всю почту.