> Самые хитрые нюансы устройства типов данных и их расположения в памяти скрыты за пределами кода. С этим и следует бороться, повышая прозрачность кода от высокоуровнего вызова до каждого бита.
> Было бы прекрасно, если бы исходные коды (по факту логика) были бы как можно больше независимы от архитектуры железа.
Выглядит противоречиво. либо обеспечивается как можно большая абстракция от железа, либо видно каждый бит. Либо можно обеспечить оба этих требования ценой производительности, спрятав всё в виртуальную машину. Хотя нет, это отказ от первого
точно не 80%. Головной обтекатель — то ли 5, то ли 6 млн, стартовый стол+запуск ещё несколько процентов. А вторая ступень не можжет стоить 0, так что это точно не 80%
Я не программирую на JS, но многие пункты, особенно NaN, минимальное значение больше нуля, сравнение трёх чисел — это очевидные и логичные пункты и более того справедливые для многих языков, а не только JS.
А относительно остальных пунктов хочется заметить, что если язык спроектирован так, чтобы давать свободу выражения, и не писать «простыню» однозначно-очевидного кода для простых вещей, то на граничных случаях будут такие как будто «смешные» случаи.
Пост в целом хороший, потому что подборка граничных случаев большая, но это совсем не «что за чёрт, Javascript» из заголовка. Такое впечатление может быть только на человека, далёкого от программирования и высокоуровневых языков.
да и сам сервер, засунуть в него N дисков по 2 ТБ или те же N дисков по 8 ТБ — разница в 4 раза, а стоимость «оверхэда» в виде остального железа сильно больше 0$
а что за фича была? Я недавно столкнулся с такой проблемой, пока через TOR не вышел с нового устройства — не пускало ни через один из 3 клиентов, что я попробовал *может случайно совпадение и пустило просто по другой причине но совпало с TOR".
сличение адреса не обеспечивает безопасность, отсутствие https позволяет провести атаку MITM, хотя адрес совпадёт, казалось бы! И наличие только https — тоже не безопасность.
Только точные адрес ПЛЮС https дают какую-то гарантию. Одно из двух — это как ворота без забора (или наоборот).
Последнее, что я сделал — отказался от ccache. В моем случае, он давал задержку примерно в секунду. Да, если подходящий файл найден, это ускоряет сборку. Но такое не часто случается, когда ты пишешь новый код.
ccache больше подходит не для случая, если вы занимаетесь разработкой, а для случая, если это build-сервер, который собирает десятки-сотни-тысячи проектов регулярно и не все из них изменяются.
Или если у вас source-based дистрибутив linux, например gentoo.
А так системы сборки, умеющие «инкрементально» дают намного больше пользы
в штатном режиме полёта требуется минимум 4 двигателя для «простых» алгоритмов управления полётом + рабочие двигатели должны размещаться симметрично и тд. Кроме пути использовать 6-8 винтов/двигателей, чтобы не сразу коптер падал можно использовать более продвинутые алгоритмы.
Например, вот пост о лаборатории, в которой удалось добиться стабильного полета на 3 двигателях после отказа одного
в момент измерения возможно измерить либо круговую, либо линейную поляризацию.
И если измерить в обоих случаях круговую, то линейная примет случайное значение в обоих случаях, а не противоположное.
И наоборот, если измерить линейную, то круговая примет случайное значение в обоих случаях, а не противоположное, насколько я понял.
Именно по второму способу поляризации понятно, что состояние было суперпозиции, насколько я понимаю.
Это плохой статический анализатор, потому что так много ошибок и предупреждений не должно быть. В хорошем с ложными срабатываниями борятся всеми путями
> Было бы прекрасно, если бы исходные коды (по факту логика) были бы как можно больше независимы от архитектуры железа.
Выглядит противоречиво. либо обеспечивается как можно большая абстракция от железа, либо видно каждый бит. Либо можно обеспечить оба этих требования ценой производительности, спрятав всё в виртуальную машину. Хотя нет, это отказ от первого
Неправда. Он сменил свою фамилию на Дотком, это не псевдоним
x86_64, x86-64 — это AMD64, да
НО
ну и выше про C, Java написал mayorovp
А относительно остальных пунктов хочется заметить, что если язык спроектирован так, чтобы давать свободу выражения, и не писать «простыню» однозначно-очевидного кода для простых вещей, то на граничных случаях будут такие как будто «смешные» случаи.
Пост в целом хороший, потому что подборка граничных случаев большая, но это совсем не «что за чёрт, Javascript» из заголовка. Такое впечатление может быть только на человека, далёкого от программирования и высокоуровневых языков.
Первый раунд — это первый чемпионат? Или в этом чемпионате будет много раундов?
Только точные адрес ПЛЮС https дают какую-то гарантию. Одно из двух — это как ворота без забора (или наоборот).
ccache больше подходит не для случая, если вы занимаетесь разработкой, а для случая, если это build-сервер, который собирает десятки-сотни-тысячи проектов регулярно и не все из них изменяются.
Или если у вас source-based дистрибутив linux, например gentoo.
А так системы сборки, умеющие «инкрементально» дают намного больше пользы
Например, вот пост о лаборатории, в которой удалось добиться стабильного полета на 3 двигателях после отказа одного
И если измерить в обоих случаях круговую, то линейная примет случайное значение в обоих случаях, а не противоположное.
И наоборот, если измерить линейную, то круговая примет случайное значение в обоих случаях, а не противоположное, насколько я понял.
Именно по второму способу поляризации понятно, что состояние было суперпозиции, насколько я понимаю.
warlock13 хорошо написал здесь про круговую поляризацию и линейную