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

вон longan nano из riscv например довольно забавный по возможностям

и их там от 8 ног и до сотен - на любой вкус

Это, кстати, очень общая штука. Я с этими понятиями познакомился, когда про ОТО (общую теорию относительности) читал.

Возможность передавать функции туда-сюда очень хороши. Посмотрите на сигнатуры функций GSL, например - https://www.gnu.org/software/gsl/doc/html/integration.html

Вообще, из всего джентельменского набора только алгебраические типы данных и ленивость не очень применимы. А так:

1. Кортежи удобны.
2. GC - очень в тему, можно не заморачиваться с памятью.
3. Immutable data - без undo/redo особой пользы нет, но и не мешает.
4. Передача функций как значений туда-сюда - отлично!
5. Классы типов - нормально (вот Ocaml'овские +. /. и т.д. - это achtung).
6. Отсутствие неявных преобразований типов - ну не мешает, где-то даже помогая.
7. Ленивые вычисления, в общем, не нужны - в вычмат. алгоритмах обычно люди даже не пытаются вычислять то, что потом может не понадобится.

————————-
Проблема в том, что Хаскельные "паттерны проектирования", aka Monoid/Functor/Applicative/Monad вообще непонятно как применять в вычмате. Строго говоря, компьютерная арифметика обладает коммутативностью, но не ассоциативностью, то есть, это какой-то антимоноид.

Кроме того, желательны изменяемые массивы с хорошим контролем. Но вот те же Клиновцы даже срезов не сделали.

Под все эти описания можно подогнать любой современный язык.
А вот, что еще придется изучить физикам-ядерщикам и чему они не будут рады:
1. Понятие монад, функторов, линз, каррирования да и вообще хотябы немного погрузиться в лямбда исчисления
2. Научиться мыслить в функциональном и декларативном стиле, без циклов, без изменяемых переменных
3. Уметь переводить уйму алгоритмов написанных в императивном стиле в функциональный, желательно на лету (вот это самое сложное)
4. Научить или мотивировать своих коллег по цеху так же в это углубиться

Боюсь это слишком большая когнитивная нагрузка для человека, которому просто нужно быстро построить мат или физ модель / проверить гипотизу / обработать данные / обучить нейронную сеть. Еще не стоит забывать что у датасатанистов и физиков ядерщиков голова сильно забита кучей других вещей.

Чисто мое мнение - язык не должен быть как изощренное французкое блюдо, котым нужно трапезничать под Шато Марго 1920го года, разбираясь во всех его тонкостях приготовления и вкусовых нотах. ЯП просто должен хорошо выполнять свою функцию в той области для которой он проектировался или снискал популярность, и чем проще и быстрее им нучатся пользоваться тем лучше.

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

Да, даже фортран. Именно поэтому он живее всех живых.

1. Это не нужно - я не знаю, куда там моноид-то приткнуть - floating point арифметика строго говоря не ассоциативна. Разве что монады, которые везде, но это бессмысленная штука.

Частичное применение полезно, кстати. Так что с каррированием вы правы.

2. Так по-умолчанию физики-ядерщики не умеют в изменяемые переменные. То есть, Хаскель 98 проще, чем Цэ.

3. Проблема в том, что изначально алгоритмы пишутся в таком смешанно императивно-функциональном стиле, даже скорее функциональном. А императивность - это уже предварительная оптимизация под железо. Ну как мы пишем вычисление квадратного корня - псевдокод

let sqrt x eps = head $ dropWhile (\r -> |r^2 - x| > eps) | r
   where r_{n+1} = 0.5 (x/r_n + r_n)
                r_0 = 1

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

4. Дата-сциентисты изначально работают с векторными операциями - см R и содранная с него pandas.

5. Страшная история про язык Х - это из области тёмного фентези, что-то вроде Чёрного отряда. Если треть населения будет выкошена, насчёт компиляторов можно будет уже не переживать в ближайшие лет 100.

Это я вовремя проснулся

)))

Ну мне в фортране хочется использовать дженерики: код немного упрощается с т.з. понимания, но нельзя т.к. в основном проекте нельзя использовать Фортран новее Fortran 90 😞

Уже есть. Я доволен :)

1. Зачем?
2. Я и на фортране могу писать вполне в функциональном стиле. Мне от этого ни горячо, ни холодно, только код чуток переусложняется. Да и в императивном стиле функционалы поверх функционалов тоже программировать не проблема. (В моем случае вообще оказалось, что точность такой имплементации выше, чем если в лоб генерировать полный функционал).
3. Не проблема с линейными алгоритмами. Да даже с циклами, в общем-то, не так сложно будет, только есть ли ФЯП с нормальной поддержкой MPI и компиляцией в целевые архитектуры? Да и как быть с суперкомпьютерами из топ-10, где у каждого первого свой компилятор (доступны С/С++/Фортран)?
4. Спокойно юзаем R/Python. Брат жив

> ЯП просто должен хорошо выполнять свою функцию в той области для которой он проектировался или снискал популярность, и чем проще и быстрее им нучатся пользоваться тем лучше.

FORmula TRANslator
И не надо придумывать новые ЯП которые помогут физикам с ЧМами, чтобы писали код физики, а не программисты

4. Спокойно юзаем R/Python. Брат жив

так это же функциональные ЯП. Там в посте речь шла про чисто фп типа Haskell, Curry, Agda. Python-у кстати очень с большой натяжкой можно прибавить фп парадигму. Гвидо очень долго уговаривали затащить лямбды, в конце концов они там есть, но однострочные и без присваивания и вообще чисто для галочки там

Я, наверное, никогда не забуду текст по-английский, который был написан на фортране - ALL CAPS, сокращения и по предложению на строку. Жалко только нумерации не было.

Я, наверное, никогда не забуду англоязычный текст, написанный на фортране 77: ALL CAPS, сокращения + по предложению на строку. К сожалению, строки не нумерованы.

6-ти символьные сокращения!)

Да-Да-Да!!!

R как-то даже ортодоксально функциональный. Там нет синтаксического сахара для функций, всё через синтаксис \lambda:

f <- function(x) { return x + 1 }

Мне нравится. Да и больше из него используем векторизацию

Ну в 2003 точно можно длинные_имена вводить. Как минимум у меня есть функция, имя которой - 25 символов