Это рассматривались два разных варианта получения энергии. В первом использовалось тепло недр Земли (геотермальные электростанции). Я объяснил, что это приведёт к охлаждению недр.

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

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

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

Это безграмотные глупцы, а не программисты. В самой ОС все критические места написаны именно на ассемблере. Что попроще - на классическом варианте Си, который есть макроассемлер, а всё остальное можно писать на чём угодно.

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

Первых роботов создают бедные. Дальше роботы будут сами размножаться и совершенствоваться.

Мне макроассемблер MASM32 так понравился, что я пишу на нём программы целиком, а не только критические места.

Вы хвастаетесь своей зарплатой перед своим котом? Быть выше или ниже можно только среди равных (не моя мысль, где-то попадалась).


Это писательские домыслы. Это нам внушила научная фантастика прошлого века, но это не соответствует действительности. Мы видим заводы-автоматы по сборке автомобилей, роботизированные конвейеры производства компьютеров и т.д. и т.п., и думаем - вот оно "Позабыты хлопоты, остановлен бег, Вкалывают роботы, а не человек!". Но это не так. Это лишь небольшой этап, а если проследить всю цепочку создания проектов, оборудования, измерительной техники, добычу ископаемых для получения необходимых материалов и всё прочее, то роботов можно и не заметить.
Думаю, в ближайшие века засилье роботов нам не грозит. Другое дело, что они займут место людей в точных и массовых производствах.
Когда-нибудь в далёком будущем, возможно, что-то подобное и произойдёт. Например, глупых людей будут использовать для подноса песка для автоматизированного производства транзисторов для умных роботов. Но довольно трудно представить себе что должно произойти в обществе, чтобы такое случилось. Уж скорее люди одичают и уйдут в леса.

Уже есть программы автоматического проектирования. На входе техническое задание - на выходе готовый проект, скомпилированный в машинных кодах для станков. Причём нет возможности вывести или редактировать какие-то промежуточные схемы, чертежи. Я сам работал с подобной программой и мне хотелось посмотреть, как она решила проблему, но разбираться в машинных кодах не было особого желания. Если такая программа содержит ошибку, то проект уже не исправить вручную.

Уже разработан 3D принтер, печатающий свои основные детали. Остаётся только добавить стандартные болты, гайки и другую мелочёвку и можно размножать принтер.

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

Такое возможно только для типовых задач.

TybeDour, попробуйте создать проект в отличной САПР например автокад. Ну хотя бы кривошипно-шатунный механизм. Но без использования уже готовых шаблонов! И оцените объем работы, который создан автоматически, с объемом, который вы затратили на придумывание, рисование, сопряжение деталей, расчеты на прочность и т.д.
Это заблуждение, что САПРы что-то создают. Это системы, которые хранят и облегчают использование уже созданного где-то и кем-то, но сами они ничего не создают.

Говно ваш автокад и в гробу его видал.

А чем пользуетесь?

Я без проблем подключал к своим программам такие драйверы, как DirectX, OpenGl. Но они мне не понравились и я написал свой драйвер для 3D графики.
В таких случаях я подключаю к своей программе внешние модули, например ffmpeg. Он содержит все мыслимые кодеки, и сам выбирает подходящий. Если я заранее знаю, какой нужен кодек, то встраиваю его в свой код, когда есть исходники на ассемблере. Если нет, переделываю на ассемблер с других языков или разрабатываю кодек сам или подключаю внешнюю DLL библиотеку.
Сейчас я пытаюсь написать собственный драйвер для USB устройств, который будет работать в обход стандартного протокола USB, напрямую обращаясь к регистрам и буферам внешнего устройства. Я иногда делаю разработки на заказ всевозможной автоматики, управляемой от компьютера. И мне надоело переписывать драйвера, когда заказчик обновляет ОС.
Это верно. Мне приходится встраивать в программу автоматическое распознавание конфигурации железа и заготавливать несколько вариантов алгоритмов.

Автокадом

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

А я знаю человека, который прямо млеет от автокада) Он так лихо навладыкался по конкретной тематике, что моментом всё делает)

В форумах часто можно видеть, как неделями дружно ищут какую нибудь ошибку в программе на языке высокого уровня (далее ЯВУ). Я тоже на этом обжигался. Потому, что программа на ЯВУ исполняет много скрытого кода и трудно выследить ошибку. Ошибки есть и в самих компиляторах и в ОС Windows. На ассемблере я всегда знаю, что делает процессор и быстро нахожу ошибки. Встроенными библиотеками Windows избегаю пользоваться, пишу свои. В общем, долго перечислять, чем мне нравится ассемблер. Но возвращаться к ЯВУ нет никакого желания.

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