Вот этот момент мне показался самым... странным в интервью.
Мощность машин быстро растёт.

Кроме того, большинство массивных расчётов замечательно выносится в спецвычислители - ну хоть CUDA/OpenCL. Я не уверен насчёт именно видеокарт именно в вашем случае, но суперкомпьютер суперкомпьютеру рознь - может, тот же результат можно получить чем-то вроде Knight'а или спецядро на ПЛИС запилить?

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

Никто ж не требует суперкомпа (в традиционном понимании) для установки в РЛС с АФАР? А там числодробилки нужны приличной производительнсти, причём, в реальном времени и с (кое-где) ограничениями по массе, теплу и потреблению.
Или - другой пример - никто ж не удивляется суммарной мощности сети Биткойна? Там ASIC'и. МНОГО ASIC'ов, сколоченных в фермы... обычному компу (или суперкомпу) там уж лет десять как делать нечего.

Поэтому, если уже известен некий стержень вычислений, вокруг которого всё крутится/будет крутиться в обозримом будущем, почему именно "суперкомпутер"?

а сертифицировать переложенный с фортрана код кто будет?

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

Переписать на С (лучше - чистом, дабы снять все тулчейн-зависимости) таким образом, чтобы вынести вычислительно-ёмкие вещи в аппаратно-зависимые функции/методы/классы. И наслаждаться затем "вездеходностью" кода. Это помимо скорости.

Аппаратные ускорители - они же не только на станции полезны. Худо ли, если _точный_ код у расчётчика на столе будет в разы и на порядки быстрее бежать?

Да, современное железо уже подбирается к уровню, когда становится возможным использовать Монте-Карло для трёхмерной графики в реальном времени:
http://www.youtube.com/watch?v=BpT6MkCeP7Y

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

Ну, Монте-Карло или нет, вопрос десятый - там свои ограничения и источники ошибок есть. А вот с чем Татарина поддержу, так это с "достругиванием" кода.
У нас в SVC "сидит" чутка лучшее приближение, чем диффузионка (с некоторыми оговорками метод близок к прямому решению уравнения переноса). Когда стало нужным "допилить" для увеличения скорости счёта, был эффект и от перехода на C++ - примерно 2 порядка, и от применения современных методов решения разреженных систем большой размерности (2-3 раза). Правда, в онлайн мы его пока не утрамбовали, но пока и не занимались всерьёз распараллеливанием. А всего лишь возникла задача допилить до возможности использования отдельных расчётов в существующей системе на АЭС...
Правда, код БНы не считает - групп маловато.

Одно из направлений мысли - программно программируемые матрицы. С современными техпроцессами необходимую расчётную мощность можно поместить в "банальный смартфон". Другое дело, когда требуется большой объём ввода-вывода (не в плане исходных/конечных, а работа с большим объёмом данных), например брутфорс такими "ускорителями" не форсировать.

Понятия не имею, нужен ли там в расчётах Монте-Карло, ибо в нейтронных расчётах разбираюсь примерно как свинья в живописи.

О чём говорил - о том, что если алгоритм определён и у него выделены критичные к скорости операции (как прямое/обратное Фурье для ЦОС, к примеру или тригонометрия/квадратный корень для 3д-рендера), то скорость - это не есть проблема.
Ну или точно не есть проблема, которая решается именно и только установкой суперкомпов; суперкомпы или вообще процессоры общего назначения нужны как _универсальное_ вычислительное средство. Ведь суперкомпы дают рост производительности на порядки - три-пять порядков максимум. Того же роста в массивных вычислениях можно несоизмеримо дешевле получить аппаратным ускорением. А реакторные штуки - нейтроника или теплотехника выглядят именно как нечто поддающееся параллелизации.

Для таких спецалгоритмов есть всякие весёлые платки с дополнительными процессорами, с GPU, с ПЛИС.
Их немножко мучительно программировать, но результат в смысле скорость/количество железа или скорость/ватты отличается радикально. Но и выносятся туда после профилирования лишь критичные по скорости функции числодробления, то есть, не нужно же весь алгоритм под железо перепиливать. Только конкретные формулы/операции.

А если, как Вы говорите, ещё и компиляторы Фортрана такие убогие в отрасли используются, что переход на нормальную компиляцию С/С++ даёт выигрыш на два порядка, то о чём вообще речь?

Во-первых, интервью отличное.
Во-вторых, если кто-нибудь сходу вспомнил по коду 90Н команду (семейство 8086, asm) - то пусть напомнит. И, заодно, можно написать код для запрещения прерываний. В интернет грязными руками не лазить!

Тем временем, я сделаю вид, что ничего не помню.

Слишком просто — это универсальная операция над любыми данными.

Ещё в порядке оффтопа, 99 строк на C++, полностью реализующие Монте-Карло для трёхмерной графики:
http://www.kevinbeason.com/smallpt/

Процессор 8086 был знаменит тем, что у него не было отдельной команды NOP. В качестве неё использовалась команда XCHG AX, AX.

Ну, на ассемблере 8086 я довольно много программировал вплоть до 1995 года. Но коды не помню. Коды я помнил от 8080, довольно долго. Да и сейчас помню больше половины таблицы. А вот от 8086 коды уже не помнил, не было смысла - команды у него ну очень переменной длины и один и тот же байт мог значить совсем разные вещи, в зависимости от начального смещения. Больше того, есть такая программа, которая играет музыку на PC Speaker-е, у неё этот трюк используется - переход посредине команды, после чего исполняется совсем другая последовательность. А ещё у неё в тексте COPYRIGHT было написано одними большими буквами. Потому что это место тоже исполнялось.

Тех кто тянет С/С++ языки в критические области - пристрелить на дальнем подступе. И никак иначе! А лучше пристрелить вообще!
Только проверенные и только НАДЕЖНЫЕ языки высокого уровня! С и С++ не является языком высокого уровня - он застрял на серединке, в нем нет ГЛАВНОГО - в нем нет ЧИТАБЕЛЬНОСТИ КОДА! Все приплыли, и проект F-35 как бы на это намекает, много АДА с примесью С. Вот и до сих пор кувыркаются. Так что только Паскаль, Ада и Фортран. Ну еще можно ассемблер, где это нужно.

Насчет спец. процессора. Сколько было эйфории по поводу Java и что появится куча спец. процессоров поддерживающие Java на уровне железа. И хде они? Все крутиться на обычных серийных процессорах.

Неправда. Современный компьютер состоит из нескольких серийных процессоров и нескольких тысяч параллельных процессоров. Это радикально отличается от того, что было 20 лет назад.
Программа, требующая для выполнения только один универсальный процессор, использует возможности современного компьютера от силы на 10%.

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

Интересно еще узнать, что конкретно за машины используются на БАЭС для работы с ГЕФЕСТом.

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

Знаю исследовательскую группу по прогнозированию землетрясений которая долгое время пользовалась шестью обычными бытовыми двуядерными PC и малой серверной стойкой с восьмиядерным процессором. И это все выдавалось за вычислительные сверхмощности. И только недавно они перешли на использование нового сервера с 64 ядрами.
Другой пример, где знакомый работает в госконторе где объемное моделирование электродинамики материалов разных неделями заставляют делать на примитивных двуядерных ноутбуках. А по причине режимности работать на других машинах запрещено.

Да чего там говорить, у меня дома на своих трех компьютерах (один ноут и две специализированные PC) вычислительных мощностей больше, чем в исследовательском центре университета нашего, где работаю. Где компьютеры стоят еще лохматых 2009-2011 годов.

Если Вы не любите кошек, Вы просто не умеете их готовить.

...
С++ по читаемости зависит почти исключительно от программиста. Возможно всё.

Необоснованная критика, полагаю.


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

А какая тут связь? Ява-процессоры просто никому не нужны.

А там, где нужны быстрые спецвычисления - нужны спецпроцессоры. А где они нужны, там они и есть.

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

Несмотря на то, что растёт, требование станции (одна кампания за рабочую смену) еле-ели выполняется с Гефестом, то есть, с уравнением диффузии. Впритык. Так что пока недостаточно выросла.

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

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

И как это компутеры вообще работают? Ведь все операционки - Виндоус, Линукс и все остальные Юниксы, включая проприетарные - написаны, о ужас! на С++

Может дело не в языках, а в квалификации программистов?

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

Видел. И что дальше? Ни одной ОС написанной на Яве нет. Как и все крупные программы типа БД или САПР - написаны на С++. Вычислительные с плавающей точкой - в основном Фортран, целочисленные - С++.

По опыту 8 лет работы в суперкомп. отделе Интела не видел ни одной вычислительной программы, написанной на чем-либо, кроме Фортрана и С-С++ (иногда на смеси этих языков). А на контроллерах и ускорителях вообще даже Фортрана нет, сплошной С.

Я блин, даже нормального сишника не могу найти в свой отдел, в hh сплошной ширпотреб - ява, C# да веб-программисты.

И еще. Что мне толку,что эти Явы спасают от глупых ошибок, если люди на собеседованиях даже формат числа с плавающей точкой не знают? Вырастили блин, поколение пепси среди инженеров.

Уважаемые участники, не оффтопьте, пожалуйста. Вернусь из командировки, перенесу отдельно в новую тему. - Модератор

У меня был упор на то, что мощность "при желании растет". Без суперкомпьютеров.
НЯП, диффузия - это массивно-параллельные вычисления. Там при реальном желании/требовании скорости (реальном - это подкрепленном оплатой) можно очень многое придумать без покупки многопроцессорного монстра. Монте-Карло немного хуже в смысле аппаратного/спецвычислительного ускорения, но лишь немного.

Я видел, как подобные задачи решаются для 3д-рендеринга, там где коммерческие интересы реально упираются в скорость вычисления. Напихать в стойку побольше лезвий - это не всегда самое дешевое. Про майнинг криптовалют я вообще молчу. Там вычмоща отдельно взятой фермы бывает такая, что и рекордные суперкомпы отдохнут.
Если на АЭС есть _реальная_ потребность (то есть, практическая выгода, а не абстрактное "хорошо бы") от более сложных алгоритмов, то эти алгоритмы можно заставить бегать сильно быстрее на относительно дешевом железе.

Ни в коем случае не буду.
У автора - вообще мухи и котлеты в одном супе с гайковертом.
Если С++ - "низкоуровневый", то каким боком лучше столь же низкоуровневый, но более примитивный и убогий Паскаль? И каким боком в список желательных языков вообще попал ассемблер?

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

Квалификация - она само собой. Конечно, на С++ можно и нужно писать качественный код.
Просто на С++ (С, Паскале) ошибке легче иметь катастрофические для программы/системы последствия, чем такой же ошибке на Яве: прямой доступ к памяти, не-манагед код.

Конечно проще, кто спорит. На Яве, на бейсике. Как школьники. Только потом не надо ныть, что у нас кодов нет, и никто их писать не умеет.

Монте-Карло по сути своей очень хорошо параллелится. Трудно представить алгоритм, который параллелился бы лучше.

Господа программисты, а почему в тему никто ещё не вкинул слово "C++11"?

Согласен.

Кому любопытно - обновления последней оси от дяди Билла (Windows 10) - это поэма! Идет постоянное лихорадочное исправление косяков. На нормальных компьютерах это не так заметно,хотя временами напрягает, а вот на смартфонах - исправляют одно, косячат другое, у мну смарт Microsoft Lumia 650 - задолбался обновлять и перегружать...

Вот, можете сами поглядеть:

https://support.microsoft.com/ru-ru/help/22...story?ocid=1607

Монте-Карло содержит условные переходы, плохо влазит под SIMD и требует полноценного (с условным исполнением) процессора на каждую ветку вычислений, НЯП.

А зачем и почему именно 11?

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

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


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

Ну так и для других методов это справедливо в значительной степени.

А С++03 не отличался от С++ версии 1989-го?

Отличия стандарта 11-го года от 3-го - точно такая же эволюция, а не революция.
Просто со временем фич набирается немало.

Спасибо админу за его терпение, за наш флуд. Да эту тему нужно выделить в отдельную ветку.
А теперь отвечу по порядку:
1) С/С++ отнес к языкам среднего уровня - так как это и не язык низкого уровня (Асм), но и не язык высокого уровня - он не "читается" как обычный текст (именно это имел ввиду Вирт, когда давал обоснование языку высокого уровня - он должен восприниматься человеком как обычный текст (например, как читать литературу). С языки не читабельны, не воспринимаются человеком.
2) по статистике (не мной замечено, а буржуями! за бугром) - 70 % времени уходит на отладку и вылавливание логических ошибок (самые дорогие ошибки!). Поэтому читабельность и восприятие логики программы на первом месте при отладке. А восстанавливать логику программы читая с и h фалы и составляя в мозгу логику кодера - психушка обеспечена!!!
3) А еще приведите мне довод о великолепной стандартизации С/С++! Это миф!!! Блин, из-за этого я потерял целый месяц, ковыряясь в с++ исходнике одного драйвера для контроллера на Линуксе. Это было жесть!!!!!!!!!!!! Мне надо было из Паскаля (Lazarus), получить из динамической библиотеки данные. Агась, держи карман пошире. Все было написано так красиво, и (кстати, это работало, НО! только исключительно на си ). Использовались шаблоны и перегруженный вызов функции. Т.е. стандартные вещи. Угу. Так вот, все дело в том что перегруженные функции не работала как положена, вызывалась только первая в цепочке, а мне надо была вторая. При разборе в интернете нашел инфу что это сильно зависит от разработчика конкретной версии компилятора.
Короче, проблему то я решил, все заработало красиво и как положено. А самое прикольное в том, что процесс считывания, буферизации и сохранения данных был многопоточным, распараллеленым - и это все на Паскале. Так можно писать хорошие и нужные вещи и на Паскале, с меньшими затратами.
ЗЫ. Хотя мой любимый FPC использует компилятор с/с++ что и установленный в системе был.
Та что я сужу не по наслышке, я столкнулся с глубинами ада по самое нехочу. Потому с/с++ не хочу. Серьезно. Потому и не хотят идти в С/С++ кодеры - зачем напрягать извилины там, где не надо. Потому С/С++ нельзя близко допускать к критическим областям - пристреливать за горизонтом!!!!!!! Ибо выловить логические ошибки в таком коде практически нереально!!! Поэтому и взлетел проект Буран, а F-35 летает низэнько низэнько, как крокодилы над землей.

Это гостиничному интернету спасибо в далёких краях, точнее его "скорости"

Вернусь - выделю.

Тогда надо срочно переносить ваш паскаль код на КОБОЛ. Он ещё более близок к человеческому восприятию, чем паскаль

Ваш пост сводится к следующему: Вы любите Паскаль и не умеете читать сишный код. Ну и что с того? Почему Вы решили, что это распространяется на всех?

Меня вот Паскаль раздражал - своей бессмысленной и тупой многословностью и необходимостью вместо программирования постоянно бороться с убогостью языка, так я ж не делаю из личных предпочтений глобальных выводов. Нравится кому-то писать "begin" вместо простой открывающей скобки - да барабан в руки, флаг на шею (ну, как в Паскале принято )
На самом деле, если убрать в сторону мелкие неудобства и общую убогость Паскаля, с С они близнецы-братья, благо писаны в одно и то же время в одной и той же парадигме процедурного программирования. Ваше удивление и торжествующее доказательство того, что на Паскале, оказывается, если помучаться, тоже можно что-то путное написать - странно, ибо конечно можно!

Паскаль - вполне адекватный своему времени функциональный язык с достаточно развитыми средствами.
Си он проиграл из-за раздражающих нелогичностей и мелочей. Миллионы программистов могли выбирать, но при прочих равных, мелочи оказались решающи Си был просто удобнее.
Отвлекитесь на секунду от личных предпочтений и посмотрите глобально: абсолютное большинство софта Человечества (в том числе - почти весь системный, критичный к ошибкам, лежащий в основе нашей цивилизации) написано на С и его наследниках. Индустрия выбрала его как стандарт не просто так, и Паскаль остался маргинальным - тоже не без причин.
Да, проиграл. Из-за мелочей. Да, мелочи - это мелочи. Но проиграл. 40-50 лет назад.

Но С++ ставить на одну доску с С/Паскалем? Это, простите, дикость. Ибо это уже смена парадигмы - первый объектно-ориентированный язык, принятый индустрией. Это уже другой век софтовой индустрии.

И даже этот век - тоже уже ушёл; С++, как и С в своё время ушёл в свою нишу, которая постоянно сужается.
Преимущества для большинства проектов managed кода настолько велики (не говоря уж о гигантском рывке новых языков в синтаксисе, функционале и общей выразительности), что нужно иметь очень, очень веские основания, чтобы выбирать С++ для нового проекта.
Посмотрите С#, посмотрите, насколько много рутинной работы может брать на себя язык, насколько коротко и понятно можно записывать сложные вещи, которые в тех же С/Паскале требовали бы чуть ли не страницы сложно читаемого кода. И это я ещё стороной обхожу специализированные для своей области скрипты. А ведь накладные расходы даже на интерпретацию с общим ростом мощности сильно убавили в процентном отношении!
Сравнимы ли С/Паскаль в удобстве в обращении с матрицами с Матлабом? Или при работе с текстами с Ruby? Да там пропасть необозримой ширины!


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

Что тут можно сказать?

Оглянитесь вокруг.
Вокруг появилось много нового и полезного.
Я не призываю Вас выкинуть, наконец, эту палку-копалку (мало ли, и она в нужный момент сойдёт за инструмент), но блин! Оглянитесь вокруг, наконец!

Вы контроллеры программировали? На каком языке там пишут, знаете? А на суперкомпах? Список кодов из spec.org или top500 смотрели?

О чем вообще говорить, элементарной грамотности нет.

О, вот это мне знакомо! Дофига гениев, придумывающих "алгоритмы". Только вот кодеров нет. Инженеров то есть.

А так каждый дурак может рассуждать про монте-карло и simd.

Сейчас именно их я и программирую.

У кого?

Поздравляю. Нашу отечественную программистскую промышленность.

Надеюсь, теперь наши граждане смогут ловить покемонов и внутри ВВЭР

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

А конкретно в расчётах (тему обсуждения ещё помните, да? ) - закодить это даже не 1/10 часть работы.
Это всё равно что электронику - к умению паять свести.

Вы, я вижу, полагаете, что умение кодить и знание WinAPI/TCP/IP стека/HAL/ассемблера х86/что там ещё по месту нужно - некая врождённая магия, данная богами?
Да нет... просто специфичные знания, которые приобретаются по мере надобности.

Дурак, конечно, может о монте-карло и simd рассуждать. Только вот к чему это сказано?

Вы программируете покемонов?

Вы вообще чем занимаетесь? Что-то кроме С++ видели?

Сколько времени тратиться на написание кода? 17 %?! Это что такая офигенная трудоемкость? Так что это не аргумент. Не убедили. Никак. Я работал с С/С++ и с Паскалем. Да,я признаю, что мне нравится Паскаль тем, что он четкий язык и так как я пишу программы для работы себе (т.е. это не основная моя задача), то тратить много времени на отладку у меня нет. Специфика работы. Посему я выбираю более практичнее и менее затратное решение. Себестоимость разработки на С/С++ и Паскале РАЗНАЯ - на Паскале трудоемкость ниже. Просто программисты которые пишут на С/С++ - это просто бесконечная золотая жила на поддержке и обновлениях. Ибо писать качественный софт - это не выгодно!!! Это бизнес, ничего личного. К сожалению это мировой тренд не только в программировании, но и в технике (например одноразовые авто, электротехника, телефоны, смартфоны планшеты и т.д.). Вот поэтому в критических областях С/С++ нужно пристреливать на дальних подступах. Ибо нужен инструмент не позволяющий допускать делать ошибки на ровном месте. С подобные языки это не гарантируют и не обеспечивают.
По поводу стандарта - ха и много раз ха. Да нету этого стандарта на практике. В теории - да, на практике - как карта ляжет у разработчика. я уже это приводил выше. НЕТУ на практике. Особенно расскажите мне стандарт на М$ оффис, как его выполняет сама компания в своих продуктах ? Ответ - да никак.
Да и вообще есть мнение (не моё), что С/С++ надо пристрелить - ибо это язык для диверсантов. Крайне нехороший язык.
ЗЫ. Ну не скажу что Паскаль такой уж древний язык. Вы путаете классический Виртовский от того на чем пишут сегодня. Delphi/FPC - очень сильно ушли от него, много хорошего появилось в нем благодаря С/С++ (не без этого) - это и дополнительные операторы при работе с циклами (Break, Continue - не нужно Goto), это и перегруженные процедуры и функции, дженерики, работа с потоками. Чего ещё то нужно?

А чтобы больше не писать про все минусы языков С, дам ссылку - там все изложено предельно четко и ясно Критика C++ . Там достается и чистому С.

Нет, стоимость С++ проектов ниже.
В общем-то в истории индустрии известна только одна фирма, которая делала крупные, серьёзные проекты на Паскале: Борланд с их компиляторами и средой. Вроде, и они перешли на С++, НЯЗ.
Ну и глупости же говорите очевидные про специально написанный криво софт.


Ну, есть мнение, что нами правят рептилоиды с Нибиру, так что с того?
Тут вопрос что с чем сравнивать. Конечно, С/С++ - небезопасные языки. Но Вы же решили сравнивать с Паскалем, который в этом смысле либо там же, либо хуже.


Почему же "путаю"? Дельфи я сам в своё время пользовал для in-situ поделок и оболочек - для 90-х годов инструмент был потрясающий, пожалуй, на тот момент, почти не отставал (как язык) от альтернатив, а уж среда на тот момент была и вовсе исключительной.
Но в целом ветка Паскалей отстаёт в развитии на 10-30 лет, что в программировании - эпоха. Ну вот как тот самый элементарный break, который был в С с рождения.

Что нужно? Как обычно - десятки полезных вещей и избавление от сотни неудобств. Нормальная перегрузка операторов, нормальные делегаты, аттрибуты - мало ли что. Покажите мне, как выглядит в Паскале класс-итератор, а особенно - его использование? Ну вот то-то и оно.
И появляется мешанина кода, логика в которой просто теряется. И появляются ошибки. Ну, точнее, появлялись бы, если б на Паскале продолжали писать достаточно сложные проекты. Наследники Паскаля - та же Ада - страдают тем же самым (да, Ф-35 тут пример).

Код истребителей Сухого написан на С++.
Летают.

Кажется этот спор мне что-то напоминает:
softwarer> ...... Ваши выкладки построены на ложном сопоставлении "рабочего" из КБ/опытного производства и "рабочего" с конвейера (серийного производства). Разумеется, это даёт нелепые результаты. Примерно так же Вы могли бы судить, не видя разницы между деятельностью художника и маляра: кустарщина, мол, каменный век. Хреновый ты работник, Рембрандт, учись у Малевича - краскопульт взял и вперёд, в промышленное производство.

:_

Это на самом деле великолепное сравнение, потому что Рембранту по сути ВСЁ РАВНО, чем работать. Мастер может использовать для шедевра кусок камня, шмат глины или рисовать по бумаге древесным углем - качество работы определяется не инструментом. На стене туалета тоже можно чем угодно рисовать, там важен больше смысл, чем чёткость линий.

Точно так же те же расчёты можно писать на скрипте Матлаба, и они всё равно будут иметь огромную ценность как расчёты.
Или поделка для лаборатории, считывающая данные с АЦП-карты и что-то там пишущая в файл может быть написана на чём угодно, хоть на Паскале, в самом деле.

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