> И что? Человек придумал ассемблеры, чтобы не считать адреса меток вручную, и
> не совершать при этом ошибок.

Так для начала нужно задать вопрос, зачем человек придумал адреса и метки (привет Тьюрингу)? Зачем потом ему понадобился ассемблер, и зачем потом он создает Си, чтобы избавится от ассемблера. Зачем? В корень зреть нужно, ошибка именно там. (Слышал про то, что нужно изменить направление роста стека, чтобы избавится от переполнения его :) и тому подобной ереси)

> Человек придумал типизацию, чтобы описывать свою
> программерскую задумку точнее, позволяя компилятору лучше проверять соответствие кода
> задумке.

Не типизацию, а абстракцию. Последовательность из восьми битов он назвал абстрактно байтом, и тд. В ассемблере нет типов, как таковых, обсуждали это уже.

> И человек продолжает придумывать всё больше и больше вещей, которые
> позволяют описать больше деталей своей задумки, и ошибки вылезают чаще и
> чаще.

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

> Хочешь я тебе ссылок накидаю на то, какие ошибки позволяет
> отлавливать rust?

На каком языке написан ваш rust?

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

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

> И развитие языков программирования идёт в сторону автоматизации этого процесса. Даже если
> мы посмотрим на C, мы увидим, что он развивается в сторону
> автоматизации этого процесса.

вот тут я не понял какой именно процесс и его автоматизация? Автоматизация гроша не стоит если нет оптимального управления.

> Точнее развивался некоторое время, он уже застыл и
> дальше развиваться неспособен. C++ идёт дальше в этом направлении, но его
> развитие было сильно повреждено идеей "повторного использования кода", с которой программисты
> носились как с писаной торбой в 90-е и 00-е. То есть,
> в результате мы поняли фундаментальные ограничения идеи, что хорошо для нас,
> но C++'у от этого не легче.

так почему до сих пор из кирпичей складывают дома?

> Нет. Это теоретическое рассуждение, которое противоречит практике.

Почему же теоретическое? Вот когда ответите на выше заданный вопрос, на чем написан ваш rust, то поймете. И тут нет противоречия.

> Если бы оно было верно,
> то самые надёжными программами были бы те, что написаны на ассемблере.

"надежными" - расплывчатое понятие, уточните.

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

Смотреть как работают чужие руки, равносильно не иметь своих (ц). Возьмите в руки инструмент, и познайте для чего он создан.

> Код ядра специфичный
> для x86 (который гарантированно не будет выполняться на arm'ах, а значит
> ему не нужна кроссплатформенность C), написан почти весь целиком на C,
> на асме только то, что на C писать не удаётся.

А что такого можно написать на асме, которого нельзя написать на Си? Я уже задавал такой вопрос, повторю, "существует ли такой алгоритм, который можно написать ТОЛЬКО на javascript"?

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

Курица или яйцо? работает ведь, такая же ситуация ждет и ЯП.

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

Он и работает

>[оверквотинг удален]
> мне надо что-то подобное провернуть, я либо лезу в *scratch* emacs'а,
> либо достаю текстовый процессор, либо запускаю R, либо сажусь писать программу
> на C или Rust (R на мой взгляд бредовое убожество из
> 80-х, который хорош лишь тем, что к нему есть куча готовых
> скриптов). Казалось бы, программу писать дольше, чем взять два столбца чисел,
> посчитать в каждой строчке разницу, возвести её в квадрат, и сложить
> эти квадраты, зачем писать программу? Я не задумывался об этом, пока
> мне не пришлось работать рука об руку с людьми далёкими от
> программирования, которые настаивали на использовании калькулятора, и даже пытались считать
> со мной наперегонки, чтобы показать, что калькулятор лучше.

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

Если да, то в чем проблема, вы сразу выявите ошибку в программе, если результат не сходится.
Если нет, то и вычисления на калькуляторе не дадут гарантий безошибочности вычислений. И потратите ровно столько времени на выявления ошибок вычислений на калькуляторе, сколько на написание программы. Порой даже необходимо прибегнуть к листу бумаги с карандашом. Представьте вот, написали программу сложения положительных чисел, а в результате получилось отрицательное кхммм мат ожидание говорит об обратном, и вы полезете искать ошибку (и смех и грех, сумма натурального ряда равна -1/12 мда уж :))

по теме: Автоматическое доказательство
https://ru.wikipedia.org/wiki/%D0%90%D0%...

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

ну как зачем, сами выше писали, автоматизация.

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

хммм, тут небольшой спорный момент, теоретически, если я пишу алгоритм (давайте лучше функцию), на вход которой ДОЛЖНО поступать положительное число, то собственно спрашивается, зачем туда пихать отрицательное?

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

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

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

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

увы пока мы не создали код, который будет создавать код без участия человека :)

> Естественно. А чем вы ещё будете мерять?

тогда зачем мы четвертым измерением выбрали время? замените его на деньги :) время-деньги, а не пространство-времени.