Ну чего там с языками программирования и технологиями?

Писать то что пока не написано.

Расписал выше.
И ты тут не один такой.

 

Ну не надо настолько все буквально то воспринимать. Конечно в любом более менее поддерживаемом языке, в том числе и в си современный компилятор даст warning.
А вот в рантайме если у тебя например ф-я "вычисли куб", такая лажа вполне может проскочить. И если у тебя отключены проверки переполнения -то так же программа облажается. А если нет - то работать будет медленнее и памяти забирать больше. Так что "либо трусы, либо крестик". Либо программа работает быстро как сишная/фортрановская числодробилка, либо проверяет переполнения и не лажает.
Третий вариант - математика написана изначально грамотно и не может переполниться, но это крайне мало нынче может, за пределами спецов по микроконтроллерам или DSP. Грамотно писать счет что в целой точке что в плавающей могут дай бог если процент от тех кто пишет (на массовых языках).

Мы с тобой явно в разных индустиях работали )
Пара примеров навскидку из личного опыта.
Цифровая обработка сигнала, где без оптимизации просто компьютер не успевает "прожевать" звук в реальном времени.
И сетевые фильтры в ядре, криво/недостаточно оптимизированный фильтр легко сделает тебе из гигабитного соединения десятимегабитное.

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

Не факт. Много где либо логические операции, либо сначала считают с большим разрядом а потом отсекают старшие биты. Посмотри сорсы того же црц16 или мд5.

 

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

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

 

А мужики то и не знают!
https://opensource.apple.com/source/xnu/xnu-792/bsd/crypto/md5.c.auto.html
мд5 это сильно легкое, соглашусь. можешь взять любой другой кэш на выбор. Я так подозреваю, что в Беркли народ все таки писал грамотно.

 

Я потерял нить о чем и зачем мы спорим.

 

напомните плз, как и что настроить, чтобы форум не маячил ошметками заигноренных?

 

Под дос всех. Кому не нравится турбопас с пристегнутой турбовижн - будет писать на q-basice.

 

Фортран!

 

Да, время безкомпромисных холиваров в прошлом...

 

У меня в подписи.

 

Объясните мне, откуда ноги растут про скорость Фортрана? Просто с чего он может быть быстрее обычного С, или С++. Тот человек, что нам матмодель Ми-8 делал, написал ее на Фортране. Но по его словам, выбор был вызван привычкой и наличием библиотек работы с матрицами. При этом результирующий код был под х87 процессор. При расчете во float это в принципе должно было уступать всем новым векторным инструкциям.

 

Мне пофиг в каком коде ковыряться и нихера толком не понимать

В том смысле, что я не программер - для меня все является китайской грамотой

зы в базе у меня msx-basic и тамошний же (msx) диалект паскаля. Это было 35 лет назад, если что. Так что - "программист", это точно не про меня.

 

Все КТС/КТВ начиная наверное с конца 70-х писались на Фортране. Как и матмодели АБСУ. Но вот что сейчас традицию продолжают, я, честно говоря, не ожидал.

 

AFAIK нет там каких-то прям высоких скоростей работы. Скорей там языковые конструкции для вычислений и для работы с числами интересные.

 

Так он же компилируемый. Причём его можно линковать с файлами на других языках. Как объектные файлы, так и dll/so.

 

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

 

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

 

Да, перепутал, виноват. Естественно процедурный.
rust кстати действительно интересен. Пытаюсь изучать по маленьку. Грамотная работа с памятью и потокобезопасность очень сильные вещи в русте в отличии от C/C++.

 

Старый фортран язык сильно ограниченный. Адресов/адресной арифметики в нем не было, соответсвенно не могла существовать часто проявляющаяся с адресной арифметикой проблема, известная как "aliasing": https://en.wikipedia.org/wiki/Aliasing_(computing)

На заре развития компиляторов позволяло сделать фортрану более качественней оптимизатор меньшими усилиями. С развитием Си, и появлением спецификатора "restrict" появилась возможность при грамотном программисте эту проблему избежать. Написать код не медленнее фортрана на Си можно, но требует грамотного специалиста, понимающего как работают проц и память.