Это не так, поскольку в случае любой проблемы с подсистемой, пойдут сначала к нему.
Нет, конечно. Пойдут к нему с проблемой в сишной части. С проблемой в растовской части пойдут к растовикам.
За возню с этим он получает свой ярлык мейнтейнера.
А как он может с этим возиться, если у него этих устройств нет?
За возню с Rust'ом он не получит дополнительно ничего, кроме головной боли.
Ergo после того, как человек стал мейнтейнером, у него нулевой стимул добавлять в том числе новые драйверы на сишке. Я правильно понимаю, что после того, как Кристоф стал мейнтейнером, в его подсистеме не было добавлено ничего нового? Лычку-то он уже получил, зачем стараться ещё?
Насколько я понимаю, в разработке Linux используется стиль красных директоров — «ты царь и бог в своём загончике, но если будут проблемы, то твоя голова летит, а не головы подчинённых».
И какие головы там куда летят? Где можно посмотреть на примеры этой ответственности?
Подавляющее большинство уязвимостей в ядре — memory corruption:
Поэтому да, C действительно жуткий и опасный, потому что в расте доброй части этих ошибок не было бы. И, как следствие, части других тоже не было бы, потому что ограниченный диапазон внимания программиста не распылялся бы на то, как бы сконкатенировать две строки без добавления remote shell'а, и у программиста было бы время и силы подумать о чём-то ещё.
В варианте SHITTY_CODEGEN он видать не смог раскрыть один из шаблонов поэтому нагенерил три варианта функций GoRec с тремя разными типами возврата ввиде лямбд, кторые он вынужден вызывать по отдельности, строки 25, 31, 37.
У меня есть чувство, что он сначала заинлайнил GoRec в лямбды, а потом всё сломалось, потому что так хвостовую рекурсию увидеть тяжелее, конечно.
Беглый взгляд показывает, что идет вызов GoRec(nfa.initState, 0), плюс унутре там парсится пустая строка, если я чего-то не проглядел. Попробуй в "std::string_view string" чем то проинициализировать.
Match передаётся снаружи, так что компилятор не знает, что будет в string и в nfa.
О Боже, во что превратили С++ за последние 20 лет :)
Лучший в мире инструмент для обеспечения job security.
Распознавать-то распознаёт, только иногда делает с этим адовую ерунду, когда там требуются какие-то дополнительные оптимизации: https://gcc.godbolt.org/z/bh6Gx5hxq
Мне лень по ассемблеру строить полный call graph, но у clang есть хотя бы один рекурсивный путь с call, а gcc делает что-то либо очень гениальное, либо очень тупое для -DSHITTY_CODEGEN-случая (и там тоже есть какие-то рекурсивные пути с call — gcc'шный кодген мне понимать сильно тяжелее, чем clangовский в этом случае).
При этом аналогичный SHITTY_CODEGENу (с паттерн-матчингом и вот этим всем) ФП-код компилируется в хвостовую рекурсию без всяких вызовов, как и ожидается.
Тесты уменьшают скорость, конечно, потому что тесты заставляют писать по пять экранов моков, прокладок и тестов на то, что без тестов делается за 10 строк. При этом от тестов никакой пользы, потому что они не ловят ошибки просто по определению: тесты тестируют положительный сценарий у разработчика в голове.
Я многие другие вещи писал (и писал о некоторых из них на хабре), от расстояния Левенштейна до разных регулярок. Вполне себе плюсовая производительность.
БПФ что на хаскеле, что на плюсах я буду писать не явными поэлементными циклами, а с использованием векторных примитивов.
Компилятору наверное проще оптимизировать цикл, чем рекурсию?
Компилятору проще оптимизировать то, смысл чего он «понимает». При этом даже loop-invariant code motion можно делать не всегда, потому что не факт, что цикл выполнится хотя бы один раз, и не факт, что у LICMнутого выражения нет сайд-эффектов.
А про рекурсию и свёртки есть конкретные математические теоремы, которые показывают, когда конкретно их можно объединять или делать другие преобразования, тогда как операции над циклами — это всегда эвристики.
Конечно, тут смешиваются различия между циклами/рекурсией и чистотой/эффектами, но циклы по своей природе требуют мутации, поэтому это смешение чуть более оправдано, чем может показаться.
Поразительная вертлявость (хотя первые четыре буквы лучше заменить на «омер»).
Во первых, я не жаловался.
Это неважно. Указывали на недостатки. Показывали как недостатки. Объясняли, почему сишников это не устраивает.
Конкретная формулировка здесь неважна, важно только то, что якобы неяВность определённой фичи раста является недостатком (поводом отказаться, етц) для людей с альтернативным складом ума, и потом говорите, что C++ без ещё более неяВной фичи для этих же людей — плохо, и с неяВной фичей он был бы лучше, и она бы не была недостатком (поводом отказаться, етц).
Шиза.
Определяющее слово здесь «может». Во вторых, я указал на недостаток, который может быть причиной отказа.
Не надо врать. Вы сказали, что эта возможностьявляется причиной отказа. Вы прямо написали, что возможность скрывать детали реализации неприемлема для сишников (а не «может быть неприемлема», например).
Я предложил конкретные условия. Когда это могло быть автоматически.
Угу, только эти конкретные условия недостаточно формализированы, нелокальны, и ведут к на самом деле большим прболемам в поддержке кодовых баз (за что вы так ратовали рядом).
Но тут ведь главное — предложить. Поучаствовать. Высказать. Насколько это осмысленно — совершенно неважно. Хоть код копипасти, хоть автомагией занимайся.
Опять же слово «могло» фигурирует.
Что это вообще значит в данном случае? Типа, может делать, а может и не делать, монетку кидает? Или это ваше предложение — это так, не предложение, а фантазии вслух, уровня «может, на Гаити съездить» — «может, автомувать, если перегрузка одна»?
Лучше бы вы последовали совету, подышали свежим воздухом. Научитесь сначала читать вы сами, прежде чем указывать другим. У вас фантазии в голове
Никаких фантазий. Просто вы патологически неспособны говорить технически точные и однозначные фразы (как это принято в технических обсуждениях), вместо этого растекаясь философской мыслию по древу, а когда вас ловят на этом, вы начинаете играть в слова.
При этом любых вопросов по существу вы избегаете как огня, и в лучшем случае просто переводите тему, а чаще — напрочь игнорируете эти вопросы. c++11 проблема потому что sfinae, но в c++03 с ним всё норм, но код неоднозначен, но в enable_if_t всё просто, но проблема, но надо тащить библиотеку.
А кто вешает-то? Прямо говорится, что человеку за байндинги отвечать не нужно, их будут мейнтейнить другие люди.
В чём ответственность?
Потому, что они ответственны за всю систему, а значит, ответственны за действия котов, которых пасут.
И если в биндингах для раста будут проблемы, то какие проблемы возникнут у конкретно Кристофа?
Ты как будто никогда не участвовал в исправлении ошибок после того, как утвердил ошибочный PR.
Ошибок в тех системах, за которые я не отвечал — нет. Даже если я высказывал своё ценное мнение в PR'е (чего от меня, кстати, тоже не требовали, и чего не требуют от Кристофа).
И да, даже в опенсорсе. Даже когда меня тегали на гитхабе, чтобы я отревьювил что-нибудь, отдалённо связанное с чем-то ещё, что я делал — ну посмотрел и посмотрел.
Тоже очень косвенная ответственность, но она есть. И старпёры-мейнтейнеры её очень хорошо чувствуют, на уровне гениальности.
Эта «косвенная ответственность» называется желанием быть царьком в своём загончике, опять же.
Я от этого избавился примерно на второй год корпоративной работы, а на третий — понял, что это глупое эго, не более. Нет моего кода, нет моего проекта, нет моей ответственности кроме той, которую я прямо и явно на себя взял. Не надо пытаться быть богом, не надо пытаться отвечать за всё. Более того, даже не надо пытаться понимать всё — разделение труда примерно для этого и существует.
Это понимание освобождает, рекомендую.
он на это давно согласился, за них он получил плюшки мейнтейнера
А в чём принципиальная разница? Пасти котов одинаково (не) надо и там, и там. Починить и проверить код он одинаково (не) может и там, и там. В чём разница?
он с ними уже давно научился эффективно работать, соответственно плюсы большие, а минусы стали много меньше
С кем — с ними? С драйверами устройств, которых у него нет? А в чём там вообще работа может заключаться?
уже выпущенные устройства не эволюционируют со временем, только уходят с рынка
APIшки ядра эволюционируют (stable API is nonsense же), и в работе устройств выявляются баги.
Я в хаскеле спокойно пишу условный mapM_/forM_, который, вообще говоря, реализован рекурсией-свёрткой, да ещё и абстрактно поверх любого тайпкласса Foldable. И ничего, получаю производительность на уровне C++. Функциональные компиляторы натасканы на рекурсию так же, как императивные — на циклы.
Чтобы не остаться с чем-то недоделанным перед релизом.
А чем это отличается от любой другой вещи, которую человек не может проверить или допилить сам, вроде драйверов под железки, которых у мейнтейнера нет?
Кроме того, не вижу проблем в том, чтобы необязательные для сборки вещи были недоделанными, учитывая, что поддержка раста всё ещё находится в экспериментальном режиме.
Достаточно очевидно, что после его смерти, это будут не его проблемы.
Но я-то не Кристоф, мне интересно и важно, что будет после его смерти!
Нормально, практически ничего.
Это уже другой вопрос по сравнению с «шансов, что множество непустое, практически нет». Теперь мы уже обсуждаем меру этого множества :]
Кристофу, как и Линусу, нравится не иметь ответственности перед драйверопейсателями, но чтобы их инструменты были стабильны.
Обвязки для раста не являются их инструментами. Они ими не пользуются, и они им не нужны.
паясничать перестаньте, лучше "полезно" проясните.
Да не, почему, я ж не спорю, ненужная на практике фигня. Точно так же, как и тесты — ненужная на практике фигня (с чем спорите уже вы).
чувак написал: "полезно" и выдал такую хрень, что без поллитры никто не разберёт, которая на экране не помещается!
Показал ради лулзов основания математики на расте, чем плохо? Это как судить об ООП по fizzbuzz enterprise edition (только, в отличие от ООП, математика интересна и полезна).
понятно почему вас на работу не нанимают.
Почему? Нанимают же. Я прям сразу говорю, что не пишу тесты, и мне сразу оффер дают на ×2 от верхней границы вилки.
и программировать чередование чисел, не важно натуральных, фибоначчи, факториалов или ещё чего, ни в энтерпрайзе не требуется ни в не энтерпрайзе.
При этом вы топите за тесты и ООП, хотя никто не видел никакого правильного ООП, и тесты нафиг не нужны ни энтерпрайзу, ни его пользователям. Плюс, все эти тесты тестируют 2+2 = 4, очень классно.
Тут уже недалеко до построения сигма-алгебры.
Нет, конечно. Пойдут к нему с проблемой в сишной части. С проблемой в растовской части пойдут к растовикам.
А как он может с этим возиться, если у него этих устройств нет?
Ergo после того, как человек стал мейнтейнером, у него нулевой стимул добавлять в том числе новые драйверы на сишке. Я правильно понимаю, что после того, как Кристоф стал мейнтейнером, в его подсистеме не было добавлено ничего нового? Лычку-то он уже получил, зачем стараться ещё?
И какие головы там куда летят? Где можно посмотреть на примеры этой ответственности?
Так что нет, ты понимаешь неправильно.
Подавляющее большинство уязвимостей в ядре — memory corruption:
Поэтому да, C действительно жуткий и опасный, потому что в расте доброй части этих ошибок не было бы. И, как следствие, части других тоже не было бы, потому что ограниченный диапазон внимания программиста не распылялся бы на то, как бы сконкатенировать две строки без добавления remote shell'а, и у программиста было бы время и силы подумать о чём-то ещё.
Так позовите же их, подтверждающих ваши слова, в тред, наконец!
Это монада
Listи ей подобные, что ли?У меня есть чувство, что он сначала заинлайнил
GoRecв лямбды, а потом всё сломалось, потому что так хвостовую рекурсию увидеть тяжелее, конечно.Matchпередаётся снаружи, так что компилятор не знает, что будет вstringи вnfa.Лучший в мире инструмент для обеспечения job security.
Которое не то что ноль, а отрицательное.
Распознавать-то распознаёт, только иногда делает с этим адовую ерунду, когда там требуются какие-то дополнительные оптимизации: https://gcc.godbolt.org/z/bh6Gx5hxq
Мне лень по ассемблеру строить полный call graph, но у clang есть хотя бы один рекурсивный путь с
call, а gcc делает что-то либо очень гениальное, либо очень тупое для-DSHITTY_CODEGEN-случая (и там тоже есть какие-то рекурсивные пути сcall— gcc'шный кодген мне понимать сильно тяжелее, чемclangовский в этом случае).При этом аналогичный
SHITTY_CODEGENу (с паттерн-матчингом и вот этим всем) ФП-код компилируется в хвостовую рекурсию без всяких вызовов, как и ожидается.Тесты уменьшают скорость, конечно, потому что тесты заставляют писать по пять экранов моков, прокладок и тестов на то, что без тестов делается за 10 строк. При этом от тестов никакой пользы, потому что они не ловят ошибки просто по определению: тесты тестируют положительный сценарий у разработчика в голове.
То же самое, что «в несколько раз меньше строк», да.
Я многие другие вещи писал (и писал о некоторых из них на хабре), от расстояния Левенштейна до разных регулярок. Вполне себе плюсовая производительность.
БПФ что на хаскеле, что на плюсах я буду писать не явными поэлементными циклами, а с использованием векторных примитивов.
Компилятору проще оптимизировать то, смысл чего он «понимает». При этом даже loop-invariant code motion можно делать не всегда, потому что не факт, что цикл выполнится хотя бы один раз, и не факт, что у LICMнутого выражения нет сайд-эффектов.
А про рекурсию и свёртки есть конкретные математические теоремы, которые показывают, когда конкретно их можно объединять или делать другие преобразования, тогда как операции над циклами — это всегда эвристики.
Конечно, тут смешиваются различия между циклами/рекурсией и чистотой/эффектами, но циклы по своей природе требуют мутации, поэтому это смешение чуть более оправдано, чем может показаться.
Нет, я просто хочу хоть как-то добиться от вас признания, что тесты не нужны, потому что менеджерам и клиентам на них пофиг.
Поразительная вертлявость (хотя первые четыре буквы лучше заменить на «омер»).
Это неважно. Указывали на недостатки. Показывали как недостатки. Объясняли, почему сишников это не устраивает.
Конкретная формулировка здесь неважна, важно только то, что якобы неяВность определённой фичи раста является недостатком (поводом отказаться, етц) для людей с альтернативным складом ума, и потом говорите, что C++ без ещё более неяВной фичи для этих же людей — плохо, и с неяВной фичей он был бы лучше, и она бы не была недостатком (поводом отказаться, етц).
Шиза.
Не надо врать. Вы сказали, что эта возможность является причиной отказа. Вы прямо написали, что возможность скрывать детали реализации неприемлема для сишников (а не «может быть неприемлема», например).
Угу, только эти конкретные условия недостаточно формализированы, нелокальны, и ведут к на самом деле большим прболемам в поддержке кодовых баз (за что вы так ратовали рядом).
Но тут ведь главное — предложить. Поучаствовать. Высказать. Насколько это осмысленно — совершенно неважно. Хоть код копипасти, хоть автомагией занимайся.
Что это вообще значит в данном случае? Типа, может делать, а может и не делать, монетку кидает? Или это ваше предложение — это так, не предложение, а фантазии вслух, уровня «может, на Гаити съездить» — «может, автомувать, если перегрузка одна»?
Никаких фантазий. Просто вы патологически неспособны говорить технически точные и однозначные фразы (как это принято в технических обсуждениях), вместо этого растекаясь философской мыслию по древу, а когда вас ловят на этом, вы начинаете играть в слова.
При этом любых вопросов по существу вы избегаете как огня, и в лучшем случае просто переводите тему, а чаще — напрочь игнорируете эти вопросы. c++11 проблема потому что sfinae, но в c++03 с ним всё норм, но код неоднозначен, но в enable_if_t всё просто, но проблема, но надо тащить библиотеку.
А кто вешает-то? Прямо говорится, что человеку за байндинги отвечать не нужно, их будут мейнтейнить другие люди.
В чём ответственность?
И если в биндингах для раста будут проблемы, то какие проблемы возникнут у конкретно Кристофа?
Ошибок в тех системах, за которые я не отвечал — нет. Даже если я высказывал своё ценное мнение в PR'е (чего от меня, кстати, тоже не требовали, и чего не требуют от Кристофа).
И да, даже в опенсорсе. Даже когда меня тегали на гитхабе, чтобы я отревьювил что-нибудь, отдалённо связанное с чем-то ещё, что я делал — ну посмотрел и посмотрел.
Эта «косвенная ответственность» называется желанием быть царьком в своём загончике, опять же.
Я от этого избавился примерно на второй год корпоративной работы, а на третий — понял, что это глупое эго, не более. Нет моего кода, нет моего проекта, нет моей ответственности кроме той, которую я прямо и явно на себя взял. Не надо пытаться быть богом, не надо пытаться отвечать за всё. Более того, даже не надо пытаться понимать всё — разделение труда примерно для этого и существует.
Это понимание освобождает, рекомендую.
А в чём принципиальная разница? Пасти котов одинаково (не) надо и там, и там. Починить и проверить код он одинаково (не) может и там, и там. В чём разница?
С кем — с ними? С драйверами устройств, которых у него нет? А в чём там вообще работа может заключаться?
APIшки ядра эволюционируют (stable API is nonsense же), и в работе устройств выявляются баги.
Я в хаскеле спокойно пишу условный
mapM_/forM_, который, вообще говоря, реализован рекурсией-свёрткой, да ещё и абстрактно поверх любого тайпкласса Foldable. И ничего, получаю производительность на уровне C++. Функциональные компиляторы натасканы на рекурсию так же, как императивные — на циклы.Я правильно понимаю, что в той подсистеме, которую он мейнтейнит, есть драйвера только для того, что есть лично у него?
Зачем вообще нести за неё ответственность, если ему прямо предлагалось, чтобы обвязки мейнтейнили сами растовики?
Тогда какая им разница на стабильность этих инструментов?
Ответственность на них никто не вешает, опять же.
А чем это отличается от любой другой вещи, которую человек не может проверить или допилить сам, вроде драйверов под железки, которых у мейнтейнера нет?
Кроме того, не вижу проблем в том, чтобы необязательные для сборки вещи были недоделанными, учитывая, что поддержка раста всё ещё находится в экспериментальном режиме.
Но я-то не Кристоф, мне интересно и важно, что будет после его смерти!
Это уже другой вопрос по сравнению с «шансов, что множество непустое, практически нет». Теперь мы уже обсуждаем меру этого множества :]
Обвязки для раста не являются их инструментами. Они ими не пользуются, и они им не нужны.
Да не, почему, я ж не спорю, ненужная на практике фигня. Точно так же, как и тесты — ненужная на практике фигня (с чем спорите уже вы).
Показал ради лулзов основания математики на расте, чем плохо? Это как судить об ООП по fizzbuzz enterprise edition (только, в отличие от ООП, математика интересна и полезна).
Почему? Нанимают же. Я прям сразу говорю, что не пишу тесты, и мне сразу оффер дают на ×2 от верхней границы вилки.
При этом вы топите за тесты и ООП, хотя никто не видел никакого правильного ООП, и тесты нафиг не нужны ни энтерпрайзу, ни его пользователям. Плюс, все эти тесты тестируют 2+2 = 4, очень классно.