>>что человеческий фактор надо исключать из программирования
> значить программы должны писать те же программы, предложением выше про утопию. А
> что в итоге мы имеем? Как и говорил ранее, человек придумал
> программы переводящие с одного языка в другой, но так и не
> придумал ничего подобного, когда программа сама пишет другую программу.И что? Человек придумал ассемблеры, чтобы не считать адреса меток вручную, и не совершать при этом ошибок. Человек придумал типизацию, чтобы описывать свою программерскую задумку точнее, позволяя компилятору лучше проверять соответствие кода задумке. И человек продолжает придумывать всё больше и больше вещей, которые позволяют описать больше деталей своей задумки, и ошибки вылезают чаще и чаще. Хочешь я тебе ссылок накидаю на то, какие ошибки позволяет отлавливать rust?
Вот например.
https://medium.com/@sgrif/no-the-problem-isnt-bad-coder...
Чувак любопытно описывает проблему, так что она выглядит проблемой с самого начала, но потом объясняет, почему когда код был написан, она не была проблемой. Код не был ошибочен, когда он был написан. Но когда изменились другие части программы, он стал ошибочным.
>>Но мне кажется, что непониманием этих фактов грешат больше апологеты C и C++, которые предлагают стратегию борьбы с ошибками, сводящуюся к тому, что надо нанимать квалифицированных программистов.
> Стандарты программирования и всякие секурные кодинг гайды, их тоже нужно проверять на
> уязвимости (проверка на непротиворечивость)
Кодинг-гайды не панацея. Нет ни одного кодинг-гайда, который бы объяснил, как править код так, чтобы гарантированно не привнести ошибку. Единственный способ, который как мне кажется может сработать -- это писать программу с нуля, каждый раз когда надо внести туда изменение. Не менять программу, а менять ТЗ, и заново проходить через все этапы начиная с проектирования программы. Но это абсолютно непрактичный способ, если только мы не найдём способ автоматизировать эти этапы.
И развитие языков программирования идёт в сторону автоматизации этого процесса. Даже если мы посмотрим на C, мы увидим, что он развивается в сторону автоматизации этого процесса. Точнее развивался некоторое время, он уже застыл и дальше развиваться неспособен. C++ идёт дальше в этом направлении, но его развитие было сильно повреждено идеей "повторного использования кода", с которой программисты носились как с писаной торбой в 90-е и 00-е. То есть, в результате мы поняли фундаментальные ограничения идеи, что хорошо для нас, но C++'у от этого не легче.
>>Это делается посредством выбора инструментов и организации процесса написания и приёмки кода.
> А сами инструменты какими средствами (инструментами) делать нужно? порочный круг, а вы
> как думаете?
Нет. Это теоретическое рассуждение, которое противоречит практике. Если бы оно было верно, то самые надёжными программами были бы те, что написаны на ассемблере. Но как мы видим, на практике ассемблер используют не для надёжности, а для экономии ресурсов, в первую очередь памяти. Код ядра специфичный для x86 (который гарантированно не будет выполняться на arm'ах, а значит ему не нужна кроссплатформенность C), написан почти весь целиком на C, на асме только то, что на C писать не удаётся.
Любопытно было бы ознакомиться с теоретической моделью, которая покажет, почему этот порочный круг не работает. А пока я не знаю такой теоретической модели, я отметаю этот порочный круг исходя из эмпирики. (что-то крутится в голове, связанное со сложностью по Колмогорову, но я не могу вспомнить)
Впрочем, я могу поделиться чисто практическим опытом, который наводит на мысль о том, как это работает. Точнее как этот порочный круг не работает. Мне периодически приходится обрабатывать данные, как правило это какая-нибудь табличка с кучей чисел. И я избегаю пользоваться калькулятором. Каждый раз когда мне надо что-то подобное провернуть, я либо лезу в *scratch* emacs'а, либо достаю текстовый процессор, либо запускаю R, либо сажусь писать программу на C или Rust (R на мой взгляд бредовое убожество из 80-х, который хорош лишь тем, что к нему есть куча готовых скриптов). Казалось бы, программу писать дольше, чем взять два столбца чисел, посчитать в каждой строчке разницу, возвести её в квадрат, и сложить эти квадраты, зачем писать программу? Я не задумывался об этом, пока мне не пришлось работать рука об руку с людьми далёкими от программирования, которые настаивали на использовании калькулятора, и даже пытались считать со мной наперегонки, чтобы показать, что калькулятор лучше.
Так зачем писать программу? Я понаблюдал за процессом, и я понял в чём дело. Дело даже не в том, что на калькуляторе надо выполнить больше действий и проще совершить ошибку -- не, это не всегда так, иногда отладка программы и обработка всех специальных случаев приводит к тому, что программу создавать дольше, чем просто посчитать. Но в любом случае я получаю воспроизводимый результат. Я получаю программу, в которой сведены воедино все специальные случаи, которые я нашёл. Эта программа позволяет рассуждать о том, как она работает и, например, убедиться в том, что специальные случаи какого-то типа я обрабатываю одинаково. Если у меня есть сомнения в том, как обрабатывать какой-то специальный случай, то иногда я могу выяснить это экспериментально, засовывая в программу специально подготовленные данные, состоящие исключительно из специальных случаев. Если я совершил ошибку подготавливая данные (те два столбца в табличке содержали косяки), то когда я найду ошибку, я могу исправить табличку и запустить программу заново, не выполняя все вычисления заново вручную.
Если я выполняю расчёты вручную, я никогда не могу быть уверен в том, что они выполнены верно, когда же я автоматизирую, то я могу со временем обрести уверенность в них. Достаточную уверенность для того, чтобы когда мне коллеги скажут, что у тебя какой-то косяк, потому что не сходится с их данными, я бы без малейшего сомнения (не только снаружи но и внутренне не испытывая сомнений) заявлял бы им, что у меня всё ок, косяк где-то у них. И мало того, что заявить, но на самом деле оказаться правым в итоге.
Так вот, мне кажется, что создание специализированных инструментов для полностью автоматизированного выполнения расчётов, имеют что-то общее с созданием сложных инструментов для создания кода.
>>что ошибки квалифицированного обходятся в большие суммы денег.
> опять всему мерило - бабло, хммммм
Естественно. А чем вы ещё будете мерять? Духовность -- увы -- это качественное мерило, которое не позволяет делать количественных оценок.
