Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Конечно, в стародавние времена Копернику было достаточно сместить точку отсчёта с Земли на Солнце — небесная механика выровнялась с земной, а наблюдаемые результаты совпали с теми, что давали эпициклы.
Все-таки модель Коперника показывала предсказательные результаты хуже, чем модель эпициклов. Так что ссылаться на нее, как на хрестоматийный пример, некорректно. Вот когда Кеплер ввел эллипсы, тогда модель стала точнее.
Забавно, что можно провести параллели с этой статьей. Даже верные идеи (думаю, автор считает свою таковой, иначе зачем об этом писать?) могут быть искажены деталями в принятой реализации.
Думаю, если у этой пары людей дошло дело до автоматизации их процесса, то связь у них давно налажена намного более удобным образом, который не зависит от наличия в прямой видимости всяких китайских железок к примотанными к ним скотчем динамиками.
Ну, судя по фото в статье, он как раз торчит, ничем не приметный, среди другой такой же рассыпухи и даже рядом с каким-то разъемом (да там вся плата по размеру с один сплошной разъем, не сильно больше USB A, насколько я вижу -- все еще подходит под "разломал USB" ;)?). Если там на самой плате не написано, что это микрофон, то и не заметить, мне кажется...
А какой же? На самом устройстве на корпусе, поди, не написано, что вот тут микрофон, и даже дырочки нет, наверное. Это конечно не сразу что-то плохое, но оно отлично описывается словом hidden.
Удивительно, почему было сразу не начать с проверки мест использования изменившихся констант? Если только бит передвинулся, очевидно же, что с этим как-то связано
На хабре не одобряют личностей, вылезших почесать свое ЧСВ. То, что вы сделали работу, 80% которой любая LLM сегодня сделает, еще ни о чем не говорит. Хотели отзывов -- умейте их принимать.
▸ матчи внутри одной функции вместо нескольких голов, компилируемых во внутренний матч
Еще один серьезнейший недостаток такой реализации, не позволяющий рассматривать его хоть сколь-либо серьезно -- невозможность добавить код до и после матча в ту же функцию. Не представляю, кому он был бы нужен в таком виде.
Никогда не думал, что кто-то не воспринимает анимационную картинку картинкой, тем более, что вставляются они одним и тем же способом и пока браузер ее не загрузит, он не знает, что там.
Это как-же после переворачивания бумажки параллелограммы превратились в прямоугольники? Нет, тут я (и не только я, думаю) видят стекание параллелограммов в прямоугольники, после чего нам заявляют "очевидно (sic!), площадь не поменялась". Наверное, у вас какая-то другая очевидность.
На следующей картинке (пардон, анимации) хотя бы степень сюрреализма менее очевидна, поскольку там параллелограммы просто сползают вниз, а потом деформируются.
Собственно, почему в документации предпочитают строчные комментарии вместо многострочных, думаю объясняется вот этим примечанием из ссылки про синтаксис комментариев, что я дал выше:
It is conventional for doc comments to contain Markdown, as expected by rustdoc. However, the comment syntax does not respect any internal Markdown. /** `glob = "*/*.rs";` */ terminates the comment at the first */, and the remaining code would cause a syntax error. This slightly limits the content of block doc comments compared to line doc comments.
но если я не могу штатными средствами добавить в документацию страничку текста — это позор.
И что по-вашему, "штатные средства"? Почему #![doc = include_str!("path/to/file.md")] вы не считаете таковым?
Как надо: да как угодно, но только, чтобы в текст комментария не вторгались управляющие символы, не имеющие к нему никакого отношения.
Ну пишите комментарии в виде/** ... */ (вместо ///) или /*! ... */ (вместо //!).
И чтобы блоки кода из документационных файлов, вставленных директивой #![doc = include_str!("path/to/file.md")], не пытались превратиться в доктесты и не ломали сборку (какие ещё доктесты в отвлеченных текстах, алё).
А если мне нужно, чтобы они в доктесты превращались? Удобная практика -- внедряете Readme.md проекта на github-е с примерами кода и они проверяются при сборке. Если вам не нужна проверка, то напишите ignore или no_run.
▸ матчи внутри одной функции вместо нескольких голов, компилируемых во внутренний матч
Ужас. Во-первых, внутреннее устройство торчит наружу. Во-вторых, куда цеплять документацию? В-третьих, разнесут по нескольким файлам (да даже просто в файле по куче мест) и ищи-свищи, где весь код. В-четвертых, теперь IDE вам весь код handle_event не свернет, чтобы глаза не мозолил, только отдельные ветки
▸ с какого-то хрена для макросов нужен отдельный крейт, такого гигантского WTF я со времен изучения настройки новелловской сети не помню.
Наоборот, хорошо, что язык нормально поделен на части. Нет нужды тащить и компилировать то, что вам нафиг не нужно. Ну и плюс развивать легче, когда оно на отдельные части побито.
Необорот, это очень хорошее решение. Вставлять произвольный код в форматную строку? И потом ломать глаза, выясняя, куда это там автор забекдорил непонятные вычисления? Если уж прям невмоготу, то можно так:
Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Ну-у-у, это и у математиков есть такая уязвимость. Наверное, поэтому им нобелевки не дают.</s>
Все-таки модель Коперника показывала предсказательные результаты хуже, чем модель эпициклов. Так что ссылаться на нее, как на хрестоматийный пример, некорректно. Вот когда Кеплер ввел эллипсы, тогда модель стала точнее.
Забавно, что можно провести параллели с этой статьей. Даже верные идеи (думаю, автор считает свою таковой, иначе зачем об этом писать?) могут быть искажены деталями в принятой реализации.
Ну так паники вместо встроенных неявных сегфолтов в C. А если при неправильном использовании все равно падать, то какие-то странные наезды получаются.
Думаю, если у этой пары людей дошло дело до автоматизации их процесса, то связь у них давно налажена намного более удобным образом, который не зависит от наличия в прямой видимости всяких китайских железок к примотанными к ним скотчем динамиками.
А если там половина строк -- это комментарии? Тоже плохо?
Ну, судя по фото в статье, он как раз торчит, ничем не приметный, среди другой такой же рассыпухи и даже рядом с каким-то разъемом (да там вся плата по размеру с один сплошной разъем, не сильно больше USB A, насколько я вижу -- все еще подходит под "разломал USB" ;)?). Если там на самой плате не написано, что это микрофон, то и не заметить, мне кажется...
А какой же? На самом устройстве на корпусе, поди, не написано, что вот тут микрофон, и даже дырочки нет, наверное. Это конечно не сразу что-то плохое, но оно отлично описывается словом hidden.
Но емкость дисков росла, чтобы это процентное отношение уменьшать, а не поддерживать постоянным...
А как они это померяли? Или просто от балды цифру в отчете написали, чтобы боялись?
Удивительно, почему было сразу не начать с проверки мест использования изменившихся констант? Если только бит передвинулся, очевидно же, что с этим как-то связано
Какой тег? Вы union (коим является MaybeUninit) с enum не путаете?
На хабре не одобряют личностей, вылезших почесать свое ЧСВ. То, что вы сделали работу, 80% которой любая LLM сегодня сделает, еще ни о чем не говорит. Хотели отзывов -- умейте их принимать.
Еще один серьезнейший недостаток такой реализации, не позволяющий рассматривать его хоть сколь-либо серьезно -- невозможность добавить код до и после матча в ту же функцию. Не представляю, кому он был бы нужен в таком виде.
Никогда не думал, что кто-то не воспринимает анимационную картинку картинкой, тем более, что вставляются они одним и тем же способом и пока браузер ее не загрузит, он не знает, что там.
Это как-же после переворачивания бумажки параллелограммы превратились в прямоугольники? Нет, тут я (и не только я, думаю) видят стекание параллелограммов в прямоугольники, после чего нам заявляют "очевидно (sic!), площадь не поменялась". Наверное, у вас какая-то другая очевидность.
На следующей картинке (пардон, анимации) хотя бы степень сюрреализма менее очевидна, поскольку там параллелограммы просто сползают вниз, а потом деформируются.
Собственно, почему в документации предпочитают строчные комментарии вместо многострочных, думаю объясняется вот этим примечанием из ссылки про синтаксис комментариев, что я дал выше:
И что по-вашему, "штатные средства"? Почему
#![doc = include_str!("path/to/file.md")]вы не считаете таковым?Ну пишите комментарии в виде
/** ... */(вместо///) или/*! ... */(вместо//!).А если мне нужно, чтобы они в доктесты превращались? Удобная практика -- внедряете Readme.md проекта на github-е с примерами кода и они проверяются при сборке. Если вам не нужна проверка, то напишите
ignoreилиno_run.Ужас. Во-первых, внутреннее устройство торчит наружу. Во-вторых, куда цеплять документацию? В-третьих, разнесут по нескольким файлам (да даже просто в файле по куче мест) и ищи-свищи, где весь код. В-четвертых, теперь IDE вам весь код
handle_eventне свернет, чтобы глаза не мозолил, только отдельные веткиНаоборот, хорошо, что язык нормально поделен на части. Нет нужды тащить и компилировать то, что вам нафиг не нужно. Ну и плюс развивать легче, когда оно на отдельные части побито.
Необорот, это очень хорошее решение. Вставлять произвольный код в форматную строку? И потом ломать глаза, выясняя, куда это там автор забекдорил непонятные вычисления? Если уж прям невмоготу, то можно так:
(поперхнулся) То есть вы здесь не видите очевидного?
Я к тому, что некорректно сравнивать 100000 с 300000 с мемориала. На мемориале все потери, а в репортаже только часть, непонятно какая.