Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это абсолютно необходимо для программирования (не только на ассемблере) и оно обязательно входит в курс обучения в университете. Все кто заканчивал какое-то программирование этого проходили.
Реальный-то язык современного десктопного процессора, в который компилируется 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 нс можно получить неплохой такой феерверк.
Про кэш достаточно знать, что он есть, у него есть ассоциативность, и что через него синхронизируются разные ядра (поэтому держать два счётчика, дёргаемых двумя разными ядрами, в одном кешлайне не очень хорошая идея). Где здесь физический уровень вентилей?
Один сторонник знания физического уровня и RS-триггеров уже, впрочем, обзывал меня зубрилой потому, что я просто гулю таблички с латентностью разных уровней кэша, ассоциативностью, и так далее, для нужной мне железки, вместо того, чтобы ну вот просто понимать RS-триггеры и выводить эти параметры из первых принципов и электрической схемы процессора. Впрочем, продемонстрировать вывод той же латентности кэша какого-нибудь Skylake из первых принципов и его схемы он почему-то отказался.
Ну и заодно отвечая на ваш соседний комментарий
В эмбединге, где счет на наносекунды, - таки необходимо.
Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды, при написании кода для обычных x86_64, скажем, никакого смысла нет в знании физического уровня до вентилей.
Да, есть FPGA, но FPGA-шники не знают C++ так, как я, например, и не все задачи делаются на FPGA или требуют FPGA.
Дело до того, что разговор с них начался, наверное? Вон какой исходный тезис был (самую важную часть выделил жирным):
Это ключевой вопрос, потому что разговор о реалистичности тех или иных сценариев развития всегда неявно подразумевают их оправданность.
Проститутки ассоциируются с криминалом, не более. Говорят, в развитых странах с легализованной проституцией этой стигмы меньше.
Да и все мы занимаемся проституцией, продавая свои мозги, по большому счёту.
Лол, он сильно разный даже просто для разных поколений 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-фича (достаточно новый стандарт?) опасна:
Сможете сходу сказать, когда и чем?
В очередной раз отмечу, что вам уже полдюжины раз было показано, что это не так, и что [сильные] типы ловят и логические ошибки.
Про кэш достаточно знать, что он есть, у него есть ассоциативность, и что через него синхронизируются разные ядра (поэтому держать два счётчика, дёргаемых двумя разными ядрами, в одном кешлайне не очень хорошая идея). Где здесь физический уровень вентилей?
Один сторонник знания физического уровня и RS-триггеров уже, впрочем, обзывал меня зубрилой потому, что я просто гулю таблички с латентностью разных уровней кэша, ассоциативностью, и так далее, для нужной мне железки, вместо того, чтобы ну вот просто понимать RS-триггеры и выводить эти параметры из первых принципов и электрической схемы процессора. Впрочем, продемонстрировать вывод той же латентности кэша какого-нибудь Skylake из первых принципов и его схемы он почему-то отказался.
Ну и заодно отвечая на ваш соседний комментарий
Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды, при написании кода для обычных x86_64, скажем, никакого смысла нет в знании физического уровня до вентилей.
Да, есть FPGA, но FPGA-шники не знают C++ так, как я, например, и не все задачи делаются на FPGA или требуют FPGA.