All streams
Search
Write a publication
Pull to refresh
152
0
Григорий @bfDeveloper

Программист на C++, D, Brainfuck

Send message
Тоже хотел про это написать и даже был готов возмущаться, как так можно было написать. А потом подумал, как сделать симуляцию устойчивую к этой проблеме. Не поднять точность, а принципиально избавить метод от подобных ошибок. Конкретно эту задачу решить несложно — задача двух тел решается аналитически. А как быть с тремя телами? Пока могу придумать только количественные решения, например, методы высоких порядков сходимости (Р-К 4).
Вы видимо находите смешным использование слов вроде «точка останова». А я вот так не считаю и часто употребляю. Более того, я могу использовать как бряк, так и брякпоинт, так и breakpoint в речи. Но не надо забывать, что у всех слов есть другие значения и оттенки. Всему своё место. Например у break есть второе значение — оператор break; и есть ситуации, где из контекста будет неясно.
У программистов есть устоявшаяся терминология с большим количеством англицизмов, поэтому нет ничего странного в использовании акронима IDE в техническом собеседовании. Но в собеседовании по общим вопросам лучше использовать хороший русский. А ещё лучше понять, на каком языке говорит кандидат и говорить на нём же.
Кстати да, очень жёсткий пример для публичного кода. Можно было ограничиться prinf(«FAIL»); Я вот сразу пошёл компилить и проверять. Хорошо хоть clang'ом скомпиленное не запускал. Из-под рута не сижу, но приятного мало и для юзера.
Ценой усложнения языка. Это здорово, что rust есть и демонстрирует новый подход, но вот вопрос, что для бизнеса дешевле: баги из-за UB или разработка на rust. Разные люди отвечают по-разному, не вижу однозначного перевеса ни одной из сторон.
У нас с коллегами зашёл спор про то, можно ли после этого писать на С++. Для тех, кто боится подобного рекомендую запустить с -Rpass=.*
Скрытый текст
~$ clang -O2 -Rpass=.* optUB.cc -o clangUB
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^
optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]
return Do();
^
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^


Там отлично видно:
optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]
Заставить сформировать отчёт по всем UB почти нереально, у gcc можно -Wagressive выставить на многие оптимизации, например. Некоторые случаи ловятся, но не все.
Многие хвалят D(dlang) для датамайнинга. Есть превосходная библиотека mir
Есть и другие (ebay tsv-utils). D на уровне по простоте, при этом однозначно лидер в соотношении простота/производительность.
Звук влияет на сон и сновидения. Даже самая безобидная аудиокнига может превратить обычный сон в кошмар. Я всего дважды засыпал с фоновыми звуками — оба раза ловил жесточайшие кошмары через 15 минут, а потом ещё долго не мог уснуть снова. Так что психологический фактор забыт зря.
Это может быть индивидулальной чертой, я привык спать в полной темноте и тишине, поэтому выключены все светодиоды на всех девайсах и даже зарядник достаю из розетки — слышно писк трансформатора. Многие могут вообще не слышать шум, а мне спать мешает.
А давайте по пунктам? Две мировых войны, воевали с половиной европы, вторая половина (как минимум Англия, Франция) в союзе с Россией. В крымской войне Россия — агрессор, сами начали. 1812 — опять Англия в союзниках, не откажись Алексндр от торговой блокады Англии, войны бы не было. Кроме того там не было союза всей Европы, там по факту одна Франция. Семилетняя война к России отношения почти не имеет, участвовали по дипломатическим соглашениям и союзам, Европа воевала внутри себя. Пётр Первый на шведов напал сам и с целью захвата земель. Аналогично русско-польские войны — можете называть это возвратом территорий, но Русь снова в агрессорах. Дальше в средние века не пойду, там вообще сложно говорить о государствах в современном понимании.
И ещё, если мы говорим о производительности, то что в коде делает рекурсия? Итеративный вариант точно будет быстрее, да ещё и от переполнения стека защищён. Тут конечно можно сделать через оптимизацию хвостовой рекурсии, но для этого надо код переписать. Так как есть, ни один компилятор не осилит. Да и не думаю, что хоть один движок js это вообще делает.
Извините, но пост ужасен. Во-первых, с такими темпами у нас будут статьи «2+2 на JavaScript». Во-вторых, выкладывать код не самого хорошего качества в обучающей статье — плохо.
Я молчу про однобуквенные переменные с комментом (это же канон плохого коментария, от которого надо избавляться). Но этот код не будет работать с пустым массивом — банально зациклится. Это одна из ошибок новичка, такое студенты на первом курсе пишут и больше такого не делают. Зачем такое публиковать?
Кроме того, 100 лет как принянто диапазоны делать открытыми справа, то есть не включать правую границу и не писать уродливое data.length -1. В случае пустого получаем -1, а что это за индекс?
Ну и в качестве придирки. Плохим тоном, хотя и без последствий в js, является вычисление среднего (a+b)/2. Давно придумали писать a + (b-a)/2, чтобы не иметь переполнений. Да, в js всё double и проблем не будет, но ведь потом так напишут на чём-нибудь ближе к железу.
Я не один с таким поведением был: https://habrahabr.ru/company/tm/blog/335642/#comment_10362148
Сейчас шрифты вернулись старые. Претензии к ним снимаются. Но плотность текста из-за интервалов и размера шрифта всё ещё актуальна.
Знаете, первый раз я хочу закрыть хабр и не возвращаться. Шрифты вообще невменяемые. Если сегодня утром они были просто мелкими, то сейчас они мелкие полужирные. Начертание цифр невменяемое, 1 вылазит за пределы, как в падонкаффском сленге. Я нЕ хОчУ ЧиТаТь ЭтИ зАбОрЧиКи. Интервалы — п#z$@ц, границ между блоками вообще не видно. Где комментарии, где пост, не понять.
Плотность информации упала в разы — читать по диагонали стало невозможно, а точнее не даёт прироста скорости. Похоже буду читать хабр не на сайте, а через агрегаторы, а если не получится, то ну нахер.
P.S. Пока писал жирность пофиксили, но всё так же плохо читается.
Без знаний вам даже в голову не придёт, что вам нужно умножать матрицы. Я видел код, где из двух матриц трансформации вытаскивались компоненты сдвига и скейла, чтобы просуммировать руками и создать из них матрицу. В то время как надо было просто перемножить исходные. Это проще, это быстрее писать, быстрее работает. Или поиск минимума через сортировку массива. Такое сплошь и рядом, но это же полный бред. С точки зрения абстракций всё хорошо, так как очень мало кто включает алгоритмическую сложность в свой интерфейс.

Абстракции это очень важно, но это два ортогональных навыка: абстракции программирования и математическая подготовка.
А я нигде и не писал про знание алгоритмов. Алгоритмические задачки они именно про мышление, а не знание. Чтобы написать бинарный поиск или какую-нибудь сортировку нужно именно мышление. А за одно и проверка опыта обработки краевых случаев, знания известных проблем (все возможные переполнения и выходы за границу). Такие алгоритмы выявляют массу проблем, которые будут встречаться в коде.
Видите ли в чём дело, обычно не перемножают. А того, кто этим занимается каждый день, нужно спрашивать более сложные вещи. Проблема часто не может быть решена на том уровне, на котором создана. То есть квалификация кандидата должна быть выше, чем уровень повседневных задач. Кроме того это индикатор общих и частных знаний — насколько глубоко человек погружается в ту или иную тему, на сколько интересуется смежными. Умножение матриц действительно считаю минимальным возможным знанием в геометрии и алгебре. Так же как и геометрический смысл и идею аффинных преобразований. Неспециалисту не надо влёт писать матрицу хитрой трансформации, но хотя бы представлять, как это работает.

С большинством проблема — оно создаёт стереотипы и ожидания. И такие вот статьи укрепляют стереотипы, что можно особо не учиться и пойти работать, обесценивают высшее образование и тд и тп. Может вместо выкидывания вопросов из собеседования лучше просто поднять общий уровень и научить решать эти задачи? Может так мы поднимем общее качество софта, которым пользуемся?
<holywar>

Ну вот опять 25. Почему все постоянно пишут, что алгоритмы никому не нужны. Если они не нужны вам, чтобы делать сайтики, то это не значит, что они не нужны никому. Я вот ни за что не возьму на работу человека, у которого есть высшее профильное образование, а он не знает, как оценить сложность алгоритма сортировки. Или высшее математическое без умения перемножить две матрицы на доске. Оба этих навыка мне нужны примерно раз в месяц, то есть постоянно. Отсутствие базовых навыков говорит о полном нежелании разбираться в том, как всё устроено.
Ну и логические задачки тоже могут быть полезны. Далеко не всем и не везде, но обычно в команде нужен хотя бы один круто соображающий человек для решения нестандартных проблем. Дебаг редко воспроизводящегося бага — очень сложная логическая задача, иногда нужны не инструменты и опыт, а просто мозги. Разумеется опыт первичен, а алгоритмы и логика вторичны, если вам нужен работник прямо сейчас. А вот для джунов всё наоборот — можно научить умного интересующегося человека, но раскачать логику «опытному» программисту на грани невозможного.
</holywar>
Это опера 12 тормозит? JS может быть, но рендер там самый быстрый. На слабых компах хром до сих пор может адски тормозить при обычном скроле, когда в фоне грузится десяток страниц. Это мой основной кейс гугления: открыть в фоне всю первую страницу выдачи и идти по вкладкам. Так вот опера не тормозила в этом случае никогда. Это ещё и единственный браузер, который начинал отображать текст страницы до полной загрузки — на медленном интернете это must have фича. И единственный браузер, который мог выравнивать страницу по ширине, что было следствием своего движка. А хром так не умеет.
Свой движок — свои фичи, а хромоклоны вообще все одинаковые.
Отредактировано
Вероятно нужны ещё скобочки, чтобы вызвать функцию на созданном объекте:
double z=Add{ .y=20, .x=10 }();

Перепутал оператор double с оператором (). Вот такое приведение кажется опасным. Ещё никогда операторы неявного приведения до добра не доводили.
Но выглядит очень круто, никогда не смотрел на именованные аргументы с этой стороны.
Непонятно, как они собрались ставить рапторы на Falcon 9. Он точно не будет дросселироваться до уровня минимальной тяги мерлина, слишком уж мощный. Как возвращать ступень? Или они поставят один маленький раптор специально для посадки?
Правила перегрузки со списками инициализации вообще безумные. То, что один элемент списка приводит к поиску других конструкторов, регулярно ломает код. Например:
struct InitMap {
  using Map = map<string, string>;
  InitMap(Map m) {}
};
InitMap m({{"k", "v"}});

Компилятору непонятно, то ли конструктор копирования звать, то ли конструктор от map. Добавляем «пустой» элемент:
InitMap m({{"k", "v"}, {});

И всё работает. Самая магия, что вариант
InitMap m({{string("k"), "v"}});

Работает, а приведение обоих элементов нет:
InitMap m({{string("k"), string("v")}});

Это всё объяснимо и после поллитра, а то и больше, даже понятно. Но лучше бы не усложняли инициализацию. Задача сделать универсальную инициализацию на все случаи жизни так и не решена. Куча мест, где в шаблонах нельзя бездумно написать {}, иногда ещё и две версии приходится делать.

Information

Rating
4,444-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity