Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Даже больше, оба ваших перевода неверны.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Как собственно все неравнодушные адепты Rust'а в пабликах, как только переписка всплыла в новостях.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Единственная верная суть в этом, что поддержка большой кодовой базы - это не биндинги написать.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Не даром сам Торвальдс дал комментарий.
Ух! Сам Яжефинн Торвальдс!
Суть которого сводится к тому, что это не Rust плохой, а программисты на Rust плохие. Плохие для ядра linux. Им нужно меняться. Это был для них по сути совет. Как мальчик, которого бросают в воду, чтобы он научился плавать, не может изменить физику воды.
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Это как раз показывает ваше непонимание. В ядре linux никто не будет ждать, что за дело возьмётся энтузиаст своего языка. Сломалось? Нужно чинить сразу.
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
А лучше вообще не ломать. Отсюда эта неприязнь нововведений. Которая оправдана.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Ядро linux - критическое ПО.
Для этого есть LTS-релизы.
Вы думаете только один Кристоф работает над DMA? Он там далеко не один.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
А что они скрывают? Реализация остаётся реализацией внутри своего же отдельного блока кода, и даже единицы трансляции.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Если трейт это ещё более менее определённая штука, то макрос может быть вообще чем угодно.
Что, в ядре линукса и сишные макросы уже запретили?
Если было изменение в обвязке, то просто так откатить ей не просто, так как все драйвера будут задеты изменениями, в отличии от изменений отдельного драйвера.
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
Реальный-то язык современного десктопного процессора, в который компилируется x86-64, закрыт и, видимо, сильно разный для AMD/Intel.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.
Вполне возможно, особенно если говорить про транзисторную часть, а не логическую, например.
Хотя, впрочем, все релевантные дисциплины в Физтехе я сдал на отл или хор (от теормеха с введением в лагранжев и гамильтонов формализм через сам квантмех до какой-то ерунды по моделированию в том числе квантовомеханических процессов, по которой у меня был хор из-за того, что я задиристый засранец). Но да, это не моя специализация (и я приматом был), и уж точно не в моей активной памяти.
Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим.
Но не нужен. Потому что пока ты учишься рассчитывать фононы в кристаллических решетках и плазмоны-поляритоны на их границе (ой, надо топологию изучить, кстати, опять математика попёрла), Вася изучает паттерны, методологии разработки, рассуждения о литкод-алгоритмах на интервью вслух, командную работу и софт-скиллы, и нанимается на работу вместо тебя. А ты идёшь со своим пхд по квантам и требованием 5-7 лет опыта работы с этим вот всем в калифорнийский медстартап за смешные 50-70к в год, пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
Поэтому смотри, что выходит: у тебя есть куча дисциплин, освоение которых требует нетривиальных усилий, которые не приносят практически никакой пользы лично тебе, и альтернативные издержки которых ощутимо высоки. На обывательско-человеческом языке это называется «неподъёмная задача».
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
Это имеет смысл только в том случае, если он относится к коду как к своей территории, и не хочет пускать на эту территорию чужаков. А это — профнепригодность для мейнтейнера.
А в вашем проекте писали ли код на двух языках для одной библиотеки?
В моих — да. У меня даже были проекты (например, с кусками на C++ и на питоне), и я не знал один из этих языков и не хотел его знать, и при этом всё нормально работало, потому что поддержка соответствующих частей была на энтузиастах этого языка.
Были и проекты на двух языках в одной либе, которые я поддерживал один, и тоже норм было.
И вы один, кто весь этот код поддерживает.
С чего бы? Ему предлагают помощь, он отказывается.
Я вижу, что вы не понимаете всю особенность той проблемы о которой пытался рассказать Кристоф.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
У программистов на C (или других структурных языков) другой склад ума, так как код для них должен быть линеен.
Что программисты на C (те, которые не осилили другие языки) не могут рассуждать о коде, давно известно, ведь the first letter in "CVE" stands for the C Programming Language. Даже две строки сконкатенировать без того, чтобы remote shell дать, получается не всегда. Совсем не всегда.
Особый склад ума. Единственный ваш тезис, с которым я согласен.
Rust, из-за наличия trait'ов и макросов может скрывать реализации алгоритмов, что для программистов на C не приемлемо.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
Более того, даже простой вызов sort или там, не знаю, list_add_rcu ровно это и делает: скрывает реализации соответствующих алгоритмов. Это основа и вообще raison d'etre процедурного программирования, и она появилась даже до С (и поэтому в С эта революционная технология присутствует).
Дальше, по предыдущему вашему офигительному тейку:
И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.
Это настолько вызывающе неверно, что, во-первых, смешно, а, во-вторых, вы точно занимаетесь программированием дальше хобби-проектов-однодневок?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Если проблема в обвязках, то драйвера на расте будут страдать независимо от того, что представлены эти обвязки одной копией рядом с исходной сишной реализацией, или методично скопированы в каждый раст-драйвер. Ну просто потому, что код один и тот же, блин. Копирование здесь не делает лучше.
Исправление проблем в обвязках потребует исправлять их в каждой из копий, которые неизбежно (эмпирический закон эволюции копипасты) разойдутся в мелочах (и не очень), что потребует куда больше усилий. Копирование здесь делает строго и существенно хуже.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр «ну я же предложил что-то, чё эти несогласные бухтят, вечно недовольны». Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу. Только он предложил мне мне самому написать по-быстрому форматтер кода для плюсов (у которых неразрешимая по Тьюрингу грамматика для начала, напомню), так как ни clang-format, ни один из кучи других форматтеров его не устраивали, и «у нас была очень специфичная база со специальными потребностями». Менеджмент схавал, а больше и не надо.
Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ, потому что Харрис и Харрис не объясняет квантмех, лежащий за транзисторами, которые в основе всех этих вентилей, а TAPL не объясняет логико-категориальные основания математики.
Без Ландафшица с одной стороны спектра и какого-нибудь «categorical logic and type theory» Якобса с другой нельзя быть хорошим программистом, ящетаю.
Я отдалённо знаком с алгеброй (ну, той, которая Chapter 0 у Паоло Алюффи — собсна, проботал значимую часть упражнений в этой книге и понимаю
такие шутки целиком
без открытия справочников) и некоторыми другими ветвями математики, используемыми в криптографии, вроде эллиптической всякой ерунды или решёток. Кроме того, я, хотелось бы думать, неплохо знаком с кое-какими ещё более абстрактными и глубокими ветвями математики (теоркат всякий, типы там, логика). При этом я полностью согласен с предыдущим оратором, и сам бы тоже не полез бы в написание своей крипты без существенной и многомесячной подготовки.
Теперь расскажите, пожалуйста, за себя, и что вас заставляет думать, что проблемы в криптографии нет.
Если это требовалось, то программист дальше формализует эти требования, доказывая требуемые свойства этой функции. В данном случае у него это не получится.
логические утверждения != алгоритмы
Ограничения тоже ≠ алгоритмы. Логические утверждения — это свойства алгоритмов.
«Алгоритм Дейкстры находит кратчайший путь» — это утверждение про алгоритм (и его можно доказать, а не тестировать). «Веса должны быть неотрицательными» — это утверждение про входные данные алгоритма (и их тоже можно выразить в типах). «Алгоритм расчёта квадратного корня даёт ошибку не больше одного ULP» — это тоже утверждение, его тоже можно доказать (а не тестировать 2³² вариантов, как предлагали в соседней статье, или случайную выборку из 2⁶⁴).
Извините, я по памяти писал - точно не помню, коммутативность Вы предлагали верифицировать или ассоциативность - это не принципиально. Они оба не подходят.
Почему? Конкатенация строк ассоциативна.
требовалось сравнить две строки с учётом равно (>=)
Это отношение рефлексивно. Это можно выразить в типах.
но пользователь написал жёсткое сравнение:
Это — не рефлексивно. Доказать рефлексивность не получится.
В реальности именно с математикой сталкиваемся редко: чаще всякая фигня вроде "взять с полки пирожок, если он там есть, если нет - выбрать другую полку и взять с неё"
HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.
Транспортный уровень у всех одинаковый, там даже длину кабелей уравнивают от серверов участников до биржевого сервера. Выигрываете вы как раз за счёт наносекунд.
А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.
Потому что если бы было норм самому, то не было бы «слишком сложно». А если слишком сложно, то помощники не помешают.
Я прямо чувствую себя неудобно, объясняя базовые логические выводы.
Я взял переводы по ссылке товарища выше. Конечно, понятное дело, переводы верны, когда надо опровергнуть исходную статью, и переводы неверны, когда из них следуют неприятные для вас вещи.
Я не знаю раст, не хочу его знать, и в мои планы не входит его изучение. Попробуйте адхом ещё раз.
Ага. А ещё поддержка большой кодовой базы — это не драйвер написать. И не бинарный блоб для amd влить. И что это говорит о всех тех людях, которые этим занимаются?
Ух! Сам Яжефинн Торвальдс!
Дискурс уровня базара (не в смысле того, что противопоставляется Собору Рэймондом, о котором я говорил выше, а в смыле базарных бабок).
Вы снова врёте: ждать не нужно, потому что люди вполне себе готовы взять на себя обязательства по мейнтейнерству.
Да, в ядре линукса же ничего никогда не вводят (даже когда уже что-то работает, см. фолианты, скажем), не ломают, и так далее.
Для этого есть LTS-релизы.
Конечно. Царёк в загончике тоже не один. Но царёк опирается на безапелляционный авторитет у прочих членов загончика, который в linux kernel пока ещё хотя бы на словах следует меритократическим принципам.
Нет, конечно. Если бы это было так, то у вас все функции были бы в одной единице трансляции, в одном большом таком .c-файле, а это, очевидно, не так.
Вы точно понимаете, о чём пишете, или просто какие-то умно звучащие слова накидываете?
Что, в ядре линукса и сишные макросы уже запретили?
Казалось бы, сишник с его #include должен понимать, что нет никакой разницы вообще с точки зрения влияния изменений между #include "foo.h" и копированием содержимого foo.h на место инклюда. У меня таки начинают закрадываться некоторые подозрения.
Лол.
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это ключевой вопрос, потому что разговор о реалистичности тех или иных сценариев развития всегда неявно подразумевают их оправданность.
Проститутки ассоциируются с криминалом, не более. Говорят, в развитых странах с легализованной проституцией этой стигмы меньше.
Да и все мы занимаемся проституцией, продавая свои мозги, по большому счёту.
Лол, он сильно разный даже просто для разных поколений Intel. Мой любимый пример — разное поведение по зависимостям между 128- и 256-битными версиями simd-регистров в зависимости от конкретного поколения микроархитектуры интелов (где-то vzeroupper надо делать, чтобы OOO нормально работало, где-то — нет).
И это естественным образом прокачивается при работе обычным программистом ровно в том объёме, который обычным программистам и нужен.
Работа мечты!
Вполне возможно, особенно если говорить про транзисторную часть, а не логическую, например.
Хотя, впрочем, все релевантные дисциплины в Физтехе я сдал на отл или хор (от теормеха с введением в лагранжев и гамильтонов формализм через сам квантмех до какой-то ерунды по моделированию в том числе квантовомеханических процессов, по которой у меня был хор из-за того, что я задиристый засранец). Но да, это не моя специализация (и я приматом был), и уж точно не в моей активной памяти.
Но не нужен. Потому что пока ты учишься рассчитывать фононы в кристаллических решетках и плазмоны-поляритоны на их границе (ой, надо топологию изучить, кстати, опять математика попёрла), Вася изучает паттерны, методологии разработки, рассуждения о литкод-алгоритмах на интервью вслух, командную работу и софт-скиллы, и нанимается на работу вместо тебя. А ты идёшь со своим пхд по квантам и требованием 5-7 лет опыта работы с этим вот всем в калифорнийский медстартап за смешные 50-70к в год, пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.
Поэтому смотри, что выходит: у тебя есть куча дисциплин, освоение которых требует нетривиальных усилий, которые не приносят практически никакой пользы лично тебе, и альтернативные издержки которых ощутимо высоки. На обывательско-человеческом языке это называется «неподъёмная задача».
Единственный автоформаттер, который меня действительно бесит — ormolou. clang-format же достаточно неплохо настраивается.
В любом случае
бесит больше, особенно когда строк не 10, а 100.
И нет, я не утрирую, весь код за авторством товарища был таким.
Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».
Это имеет смысл только в том случае, если он относится к коду как к своей территории, и не хочет пускать на эту территорию чужаков. А это — профнепригодность для мейнтейнера.
В моих — да. У меня даже были проекты (например, с кусками на C++ и на питоне), и я не знал один из этих языков и не хотел его знать, и при этом всё нормально работало, потому что поддержка соответствующих частей была на энтузиастах этого языка.
Были и проекты на двух языках в одной либе, которые я поддерживал один, и тоже норм было.
С чего бы? Ему предлагают помощь, он отказывается.
Я как раз прекрасно понимаю эту проблему. Кристоф хочет продолжать быть королём в своём уютном загончике, а тут опасно близко подходят люди, могущие показать, что король-то голый.
Что программисты на C (те, которые не осилили другие языки) не могут рассуждать о коде, давно известно, ведь the first letter in "CVE" stands for the C Programming Language. Даже две строки сконкатенировать без того, чтобы remote shell дать, получается не всегда. Совсем не всегда.
Особый склад ума. Единственный ваш тезис, с которым я согласен.
Знаете, как в ядре разные штуки сделаны в окрестности тех же ФС или драйверов? Там структурки с указателями на функции лежат, и эти структурки ровно этим занимаются: скрывают реализации алгоритмов. Или я что-то пропустил, и разные кристофы и анимерабы их уже выпилили?
Более того, даже простой вызов
sortили там, не знаю,list_add_rcuровно это и делает: скрывает реализации соответствующих алгоритмов. Это основа и вообще raison d'etre процедурного программирования, и она появилась даже до С (и поэтому в С эта революционная технология присутствует).Дальше, по предыдущему вашему офигительному тейку:
Это настолько вызывающе неверно, что, во-первых, смешно, а, во-вторых, вы точно занимаетесь программированием дальше хобби-проектов-однодневок?
Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.
Если проблема в обвязках, то драйвера на расте будут страдать независимо от того, что представлены эти обвязки одной копией рядом с исходной сишной реализацией, или методично скопированы в каждый раст-драйвер. Ну просто потому, что код один и тот же, блин. Копирование здесь не делает лучше.
Исправление проблем в обвязках потребует исправлять их в каждой из копий, которые неизбежно (эмпирический закон эволюции копипасты) разойдутся в мелочах (и не очень), что потребует куда больше усилий. Копирование здесь делает строго и существенно хуже.
Предлагать копипастить, особенно с таким обоснованием, как у Кристофа — это чисто политический манёвр «ну я же предложил что-то, чё эти несогласные бухтят, вечно недовольны». Абсолютно так же вёл себя один мой коллега на одной работе, например, выступавший против автоформаттеров кода (и консистентного форматирования кодовой базы вообще), мол, они ограничивают его свободу. Только он предложил мне мне самому написать по-быстрому форматтер кода для плюсов (у которых неразрешимая по Тьюрингу грамматика для начала, напомню), так как ни clang-format, ни один из кучи других форматтеров его не устраивали, и «у нас была очень специфичная база со специальными потребностями». Менеджмент схавал, а больше и не надо.
Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ, потому что Харрис и Харрис не объясняет квантмех, лежащий за транзисторами, которые в основе всех этих вентилей, а TAPL не объясняет логико-категориальные основания математики.
Без Ландафшица с одной стороны спектра и какого-нибудь «categorical logic and type theory» Якобса с другой нельзя быть хорошим программистом, ящетаю.
Интерпретирую ваш уклончивый ответ как «нет, не могу пояснить».
Ну что тут скажешь? Продолжайте необоснованно верить, что знание вентилей делает ваш код на ассемблере для обычных десктопных процессоров лучше.
Я отдалённо знаком с алгеброй (ну, той, которая Chapter 0 у Паоло Алюффи — собсна, проботал значимую часть упражнений в этой книге и понимаю
такие шутки целиком
без открытия справочников) и некоторыми другими ветвями математики, используемыми в криптографии, вроде эллиптической всякой ерунды или решёток. Кроме того, я, хотелось бы думать, неплохо знаком с кое-какими ещё более абстрактными и глубокими ветвями математики (теоркат всякий, типы там, логика). При этом я полностью согласен с предыдущим оратором, и сам бы тоже не полез бы в написание своей крипты без существенной и многомесячной подготовки.
Теперь расскажите, пожалуйста, за себя, и что вас заставляет думать, что проблемы в криптографии нет.
Во-первых, доказывается.
Во-вторых, а что вы с распределёнными алгоритмами делаете в вашем мире? Тестируете, что ли?
Если это требовалось, то программист дальше формализует эти требования, доказывая требуемые свойства этой функции. В данном случае у него это не получится.
Ограничения тоже ≠ алгоритмы. Логические утверждения — это свойства алгоритмов.
«Алгоритм Дейкстры находит кратчайший путь» — это утверждение про алгоритм (и его можно доказать, а не тестировать). «Веса должны быть неотрицательными» — это утверждение про входные данные алгоритма (и их тоже можно выразить в типах). «Алгоритм расчёта квадратного корня даёт ошибку не больше одного ULP» — это тоже утверждение, его тоже можно доказать (а не тестировать 2³² вариантов, как предлагали в соседней статье, или случайную выборку из 2⁶⁴).
Почему? Конкатенация строк ассоциативна.
Это отношение рефлексивно. Это можно выразить в типах.
Это — не рефлексивно. Доказать рефлексивность не получится.
И у этого тоже есть требования и инварианты.
Вы там заодно функцию деления назвали
add, а я показал, как типы это ловят (а тесты — нет).Нет, я предложил не это.
И снова нет. Ограничения — это логические утверждения. Это не алгоритмы.
Я предлагал проверять ассоциативность, а не коммутативность, если что.
Конкатенация строк не является сложением чисел (которое мы обсуждали), ломающие новости! А проблема-то в чём?
Например?
В инте 64 бита. Кажется, что мы передаём инт, а на деле передаём 64 аргумента.
Когда говорят о сотне аргументов, то подразумевают не сотню бит или сотню байт, а сотню сущностей, не связанных в одну в предметной области.
Показывал, как решать ровно это (только там у вас деление было).
С каким образцом? В типах, как и всегда, выражаются ограничения и условия на поведение функции — ровно то, для чего они и предназначены.
Транспортный уровень у всех одинаковый, там даже длину кабелей уравнивают от серверов участников до биржевого сервера. Выигрываете вы как раз за счёт наносекунд.
Ну так как знание вентилей-то помогает?
И
>=вместо>, и+вместо/, и деление на ноль, и многое другое — всё это я вам писал в комментариях.Я тут недавно узнал (и до сих пор обескуражен этим фактом), что простая C++20-фича (достаточно новый стандарт?) опасна:
Сможете сходу сказать, когда и чем?
В очередной раз отмечу, что вам уже полдюжины раз было показано, что это не так, и что [сильные] типы ловят и логические ошибки.