Обновить
-1
1.6

Специалист по теории типов USB-кабелей

Отправить сообщение

А про квантмех, лежащий за транзисторами я, извини за грубость, точно побольше вашего знаю.

Вполне возможно, особенно если говорить про транзисторную часть, а не логическую, например.

Хотя, впрочем, все релевантные дисциплины в Физтехе я сдал на отл или хор (от теормеха с введением в лагранжев и гамильтонов формализм через сам квантмех до какой-то ерунды по моделированию в том числе квантовомеханических процессов, по которой у меня был хор из-за того, что я задиристый засранец). Но да, это не моя специализация (и я приматом был), и уж точно не в моей активной памяти.

Соответственно, объём знаний, достаточно цельно покрывающий работу компьютера, велик, но вполне проходим.

Но не нужен. Потому что пока ты учишься рассчитывать фононы в кристаллических решетках и плазмоны-поляритоны на их границе (ой, надо топологию изучить, кстати, опять математика попёрла), Вася изучает паттерны, методологии разработки, рассуждения о литкод-алгоритмах на интервью вслух, командную работу и софт-скиллы, и нанимается на работу вместо тебя. А ты идёшь со своим пхд по квантам и требованием 5-7 лет опыта работы с этим вот всем в калифорнийский медстартап за смешные 50-70к в год, пока двухлетний выпускник буткампа идёт фронтендером кнопочки перекрашивать за 100-150.

Поэтому смотри, что выходит: у тебя есть куча дисциплин, освоение которых требует нетривиальных усилий, которые не приносят практически никакой пользы лично тебе, и альтернативные издержки которых ощутимо высоки. На обывательско-человеческом языке это называется «неподъёмная задача».

Единственный автоформаттер, который меня действительно бесит — ormolou. clang-format же достаточно неплохо настраивается.

В любом случае

std::string foo(int * ptr, int*otherptr) {
  if (doStuff)
  {
    if(otherStuff) {
      doSomething();
    doThings(); }
    } else
    {
      doMoreThings();
      return
      "success";
  }
}

бесит больше, особенно когда строк не 10, а 100.

И нет, я не утрирую, весь код за авторством товарища был таким.

Он именно о поддержке кодовой базы писал.

Он писал взаимоисключающие параграфы «мне не нужны помощники, мне норм самому» и «я не хочу мейнтейнить растобайндинги, потому что это слишком сложно».

Это имеет смысл только в том случае, если он относится к коду как к своей территории, и не хочет пускать на эту территорию чужаков. А это — профнепригодность для мейнтейнера.

А в вашем проекте писали ли код на двух языках для одной библиотеки?

В моих — да. У меня даже были проекты (например, с кусками на 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 процедурного программирования, и она появилась даже до С (и поэтому в С эта революционная технология присутствует).

Дальше, по предыдущему вашему офигительному тейку:

И в этом есть рациональное зерно. Потому что если проблема будет только в драйвере, то его можно одного будет откатить или заблокировать без серьёзных проблем.

Это настолько вызывающе неверно, что, во-первых, смешно, а, во-вторых, вы точно занимаетесь программированием дальше хобби-проектов-однодневок?

  1. Если проблема в обвязках, то их точно так же можно откатить или «заблокировать» (что бы это ни значило) без серьёзных проблем для сишного кода. Централизованные обвязки здесь не делают хуже.

  2. Если проблема в обвязках, то драйвера на расте будут страдать независимо от того, что представлены эти обвязки одной копией рядом с исходной сишной реализацией, или методично скопированы в каждый раст-драйвер. Ну просто потому, что код один и тот же, блин. Копирование здесь не делает лучше.

  3. Исправление проблем в обвязках потребует исправлять их в каждой из копий, которые неизбежно (эмпирический закон эволюции копипасты) разойдутся в мелочах (и не очень), что потребует куда больше усилий. Копирование здесь делает строго и существенно хуже.

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

Утверждаю, что спектра от Харрис и Харрис до TAPL недостаточно, чтобы понимать все уровни ЭВМ, потому что Харрис и Харрис не объясняет квантмех, лежащий за транзисторами, которые в основе всех этих вентилей, а TAPL не объясняет логико-категориальные основания математики.

Без Ландафшица с одной стороны спектра и какого-нибудь «categorical logic and type theory» Якобса с другой нельзя быть хорошим программистом, ящетаю.

Интерпретирую ваш уклончивый ответ как «нет, не могу пояснить».

Ну что тут скажешь? Продолжайте необоснованно верить, что знание вентилей делает ваш код на ассемблере для обычных десктопных процессоров лучше.

Я отдалённо знаком с алгеброй (ну, той, которая Chapter 0 у Паоло Алюффи — собсна, проботал значимую часть упражнений в этой книге и понимаю

такие шутки целиком

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

Теперь расскажите, пожалуйста, за себя, и что вас заставляет думать, что проблемы в криптографии нет.

у всего есть, но далеко не всё доказывается, особенно когда алгоритм становится распределённым

Во-первых, доказывается.

Во-вторых, а что вы с распределёнными алгоритмами делаете в вашем мире? Тестируете, что ли?

требовалось

Если это требовалось, то программист дальше формализует эти требования, доказывая требуемые свойства этой функции. В данном случае у него это не получится.

логические утверждения != алгоритмы

Ограничения тоже ≠ алгоритмы. Логические утверждения — это свойства алгоритмов.

«Алгоритм Дейкстры находит кратчайший путь» — это утверждение про алгоритм (и его можно доказать, а не тестировать). «Веса должны быть неотрицательными» — это утверждение про входные данные алгоритма (и их тоже можно выразить в типах). «Алгоритм расчёта квадратного корня даёт ошибку не больше одного ULP» — это тоже утверждение, его тоже можно доказать (а не тестировать 2³² вариантов, как предлагали в соседней статье, или случайную выборку из 2⁶⁴).

Извините, я по памяти писал - точно не помню, коммутативность Вы предлагали верифицировать или ассоциативность - это не принципиально. Они оба не подходят.

Почему? Конкатенация строк ассоциативна.

требовалось сравнить две строки с учётом равно (>=)

Это отношение рефлексивно. Это можно выразить в типах.

но пользователь написал жёсткое сравнение:

Это — не рефлексивно. Доказать рефлексивность не получится.

В реальности именно с математикой сталкиваемся редко: чаще всякая фигня вроде "взять с полки пирожок, если он там есть, если нет - выбрать другую полку и взять с неё"

И у этого тоже есть требования и инварианты.

деление было примером к неожиданным ексепшенам

Вы там заодно функцию деления назвали add, а я показал, как типы это ловят (а тесты — нет).

Вы предложили ключевое слово которое сообщает компилятору "здесь нет ексепшенов".

Нет, я предложил не это.

ограничения в общем виде описываются алгоритмом, а не типом

И снова нет. Ограничения — это логические утверждения. Это не алгоритмы.

а условие (что Вы предлагали) a + b == b + a

Я предлагал проверять ассоциативность, а не коммутативность, если что.

далеко не всегда выполняется. Если a и b - строки, а язык у нас, например, Rust который конкатенирует оператором "плюс" - например.

Конкатенация строк не является сложением чисел (которое мы обсуждали), ломающие новости! А проблема-то в чём?

и не все, далеко не все, алгоритмы описываются простым декларативным выражением.

Например?

В инте 64 бита. Кажется, что мы передаём инт, а на деле передаём 64 аргумента.

Когда говорят о сотне аргументов, то подразумевают не сотню бит или сотню байт, а сотню сущностей, не связанных в одну в предметной области.

Данная ошибка в общем виде типами не решается:

Показывал, как решать ровно это (только там у вас деление было).

То есть реально в решении работали не типы, а сравнение программы с образцом

С каким образцом? В типах, как и всегда, выражаются ограничения и условия на поведение функции — ровно то, для чего они и предназначены.

HFT - это имеется в ввиду "High Frequency Trade"? Если оно - то там нету наносекунд, тама транспортный уровень все съест.

Транспортный уровень у всех одинаковый, там даже длину кабелей уравнивают от серверов участников до биржевого сервера. Выигрываете вы как раз за счёт наносекунд.

А вот на управлением мощными электромоторами - очень даже идет, ибо при промахе в 200 нс можно получить неплохой такой феерверк.

Ну так как знание вентилей-то помогает?

И >= вместо >, и + вместо /, и деление на ноль, и многое другое — всё это я вам писал в комментариях.

Я тут недавно узнал (и до сих пор обескуражен этим фактом), что простая C++20-фича (достаточно новый стандарт?) опасна:

template<auto V>
const auto& make_static()
{
  return V;
}

Сможете сходу сказать, когда и чем?

В очередной раз отмечу, что вам уже полдюжины раз было показано, что это не так, и что [сильные] типы ловят и логические ошибки.

Про кэш достаточно знать, что он есть, у него есть ассоциативность, и что через него синхронизируются разные ядра (поэтому держать два счётчика, дёргаемых двумя разными ядрами, в одном кешлайне не очень хорошая идея). Где здесь физический уровень вентилей?

Один сторонник знания физического уровня и RS-триггеров уже, впрочем, обзывал меня зубрилой потому, что я просто гулю таблички с латентностью разных уровней кэша, ассоциативностью, и так далее, для нужной мне железки, вместо того, чтобы ну вот просто понимать RS-триггеры и выводить эти параметры из первых принципов и электрической схемы процессора. Впрочем, продемонстрировать вывод той же латентности кэша какого-нибудь Skylake из первых принципов и его схемы он почему-то отказался.

Ну и заодно отвечая на ваш соседний комментарий

В эмбединге, где счет на наносекунды, - таки необходимо.

Насчёт эмбеддедов и эмбеддингов не знаю, а вот в HFT, где счёт точно идёт на наносекунды, при написании кода для обычных x86_64, скажем, никакого смысла нет в знании физического уровня до вентилей.

Да, есть FPGA, но FPGA-шники не знают C++ так, как я, например, и не все задачи делаются на FPGA или требуют FPGA.

Если программист хотя бы приблизительно осознает как его код будет выполняться на самом деле процессором, то он сможет сделать лучший выбор кода для данной задачи.

  1. Можете пояснить, как конкретно понимание физического уровня до вентилей помогает в написании прикладного кода?

  2. Знакомы ли вы с математической логикой, теорией типов, теорией категорий, и если нет, то почему? Не считаете ли вы, что они тоже улучшают качество кода?

По факту же в плюсах довольно много вещей, которые сделанны именно для того, чтобы можно было как раз сфокусироваться на

…игре в увлекательную викторину «а не UB ли я сейчас делаю?»

И когда базовые потребности уже полностью удовлетворены, человек начинает замечать несправедливость и на более высоком уровне - на уровне интеллектуальных благ, к примеру.

Вы говорите «замечать несправедливость», я говорю «придумывать несправедливость там, где её нет, чтобы на фоне борьбы с ней реализовать соответствующий уровень пирамиды потребностей в признании».

Поздравляю - вы предлагаете прийти к коммунистическому обществу, в котором репрессивный орган в виде государственного аппарата упразднён

Не совсем. Я анархо-капиталист.

а общество живёт и принимает решения коллективно, самостоятельно и открыто.

Не общество, а индивидуальные агенты. И никакого коллективного принятия решений, потому что оно размывает ответственность за негативные решения и награду за позитивные.

Возможности общества безграничны.

Почему?

При этом эволюция продолжается. Вы же не будете это отрицать?

Да, но не в ту сторону, которая обычно подразумевается под эволюцией в обывательском понимании, в котором результат очередных N итераций эволюции — более лучше по каким-то классически культурно положительным признакам вроде интеллекта, силы, и так далее.

Так появление и развитие монополий, а также их трансформация в супермонополию - это естественный и неизбежный процесс.

Как и смерть монополий, если им не помогать супермонополистом-государством, например. И это тоже хорошо, потому что смена компаний даёт эволюцию (в хорошем, классически культурно положительном смысле) товаров и услуг.

Извините, когда человек взял ипотеку на 20 лет - вы думаете, он будет куда-то часто переезжать?

Да, почему нет? Ипотека спокойно продаётся и перепокупается (по крайней мере, там, где я живу), и без какой-либо существенной потери в деньгах (кроме оплаты агентов, условно). Я сам купил дом, который был в ипотеке, и который владелица ипотеки мне спокойно продала и обменяла на ипотечный дом в другом месте с эквивалентным оставшимся долгом.

Если вы не хотите потерять в деньгах, конечно.

Если я не готов потерять условную тыщу баксов на переезде, значит, я просто оцениваю дискомфорт от ТСЖ в тысячу баксов.

Я опираюсь на питерский опыт.

В моём случае Техас.

А про низкую активность жильцов - я об этом и говорил. Индивидуализм является проигрышной стратегией.

Не уверен, что смог донести мысль. ТСЖ в том районе, где я живу, почему-то работает нормально даже при сверхнизком участии людей.

В уровне жизни, естественно.

Ну, проще не стало. Его как измерить?

Как-то не очень - для кого? :-)

Для стартапов и инноваций (о которых мы говорили изначально). Их в Норвегии де-факто нет.

Нет, Норвегия - чисто капиталистическая страна со всеми минусами

Смотря как определять капитализм/социализм. В Норвегии очень много форсированного перераспределения и уравниловки. Я не могу назвать её чисто капиталистической страной.

Обилие стартапов не является показателем высокого уровня жизни. Я бы даже сказал наоборот - самыми предприимчивыми являются более бедные страны.

Разговор начался не с уровня жизни, а с разработки продуктов:

А почему вам не нравится схема, в которой финансирование работы программиста (или коллектива программистов) обеспечивает суперкорпорация, которая заинтересована в конечном продукте?

поэтому я фокусируюсь на разработке этих самых продуктов, которые в текущей экономике проще всего учитывать через количество стартапов.

Повторю - любого человека в стране. Доходы и налоги.

Судя по статье, доходы — это просто зарплаты. От коррупции (взяток в обход зарплаты, с которых, естественно, не платятся налоги) это не помогает примерно никак.

В СССР до хрущёвских реформ.

демократия
в СССР

Ну ладно.

Вы не поняли. Изменяющиеся внешние условия приводят к изменению человека. НТП создаёт новые технологии, новые технологии создают новые производственные отношения, новые производственные отношения меняют принципы организации производства и распределения благ и, как следствие, психологию индивидуумов.

Не, я знаком с этим тезисом, и я понимаю, какую мысль он пытается передать, просто я с обоснованностью этой мысли не согласен.

Бытие, конечно, определяет сознание, но куда слабее, чем думают гегелианцы и марксисты. Фундаментальные аспекты психологии (желание при прочих равных экономить энергию aka лень, желание иметь статус в стае повыше, и так далее) никакое бытие в ближайшие N тысяч лет не изменит чисто по эволюционно-отборным причинам (и, я склонен считать, не изменит никогда, потому что это поведение будет выгодно всегда).

Тебе не кажется, что у тебя тут противоречие? Если дедушка Дарвин работает на уровне отбора групп (то есть коллективов людей), то уже хотя бы он делает групповое целеполагание, то есть целеполагание уровнем выше особи.

Нет, не кажется.

Связанные с понятием цели, целеполагания и прочих похожих терминов коннотации — это наличие субъекта, который эти цели может оформить и свободно-вольно выбирать, и наличие некоего глобального плана, частью которого эти цели являются.

У тебя есть возвышенность, холм какой-то, и ты на его вершину льёшь воду. Эта вода течет вниз, причём локально выбирая места пониже. Можно ли сказать, что у воды есть цель стечь вниз? Гравитация занимается целеполаганием?

Древние греки так, конечно, говорили, но это называлось то ли анимизмом, то ли антропоморфизмом, то ли ещё как-то похоже, и где-то в 16-м/17-м веке от этого стиля мышления в ходе естественнонаучной революции отошли.

Вообще, коммунисты и социалисты относятся к человечеству с инженерной точки зрения, то есть, везде видят системы-подсистемы-надсистемы. А та идеология, к которой принадлежишь ты, вот этой иерархии систем и взаимосвязи не хочет видеть.

Я эти системы тоже вижу. Просто коммунисты-социалисты считают, что ограничений для инженерии де-факто нет, а я считаю, что есть.

Коммунисты упорно пытаются строить вечный двигатель, а когда я говорю, что законы физики это не дают сделать, поэтому попытки несколько бесплодны и даже вредны, они начинают обвинять меня в невидении систем, в незнании инженерии, ну и на сдачу в отсутствии эмпатии и сострадания ко всем тем, кому халявная энергия поможет.

Информация

В рейтинге
1 604-й
Зарегистрирован
Активность