Что не так с Лиспом?

Проблема в том, что у такой процедуры будет какая-нибудь абстрактная сигнатура, у которой будет абстрактная Monad m в ограничениях. И поди ж ты раскопай, что это на самом деле всегда что-нибудь про IO.

Нет, Monad m там не будет, это слишком слабое ограничение для того, чтобы влиять на глобальное состояние. Там будет какое-нибудь MonadIO m, или PrimMonad m, или вообще, не знаю, STM.

Вы вот видели код на Haskell, который это делает? Там сплошное IO да IO погоняет

Как раз на выходных вспомнил, что давно не писал код, который запускается, и поигрался с ручной реализацией DFT. За время масштаба часа-двух (из которых, наверное, полчаса тупил и думал, как мне соответствующий оператор после того, как я его отсепарировал, выразить не поэлементным умножением, а через трёхмерные тензоры — короче, это функция rowise в коде ниже) наваял реализацию с repa, а потом ради интереса с accelerate. Найдёте

center :: Acc (Matrix (Complex Float)) -> Acc (Matrix (Complex Float))
center = imap $ \(I2 x y) v -> ifThenElse (even $ x + y) v (negate v)

dotp :: (Shape sh, Num e) => Acc (Array (sh :. Int) e) -> Acc (Array (sh :. Int) e) -> Acc (Array sh e)
dotp a1 a2 = sum $ zipWith (*) a1 a2

rowise :: Num e => Int -> Acc (Matrix e) -> Acc (Matrix e) -> Acc (Matrix e)
rowise resultSize m1 m2 = dotp m1' m2'
  where
    m1' = replicate (constant $ Any :. All :. resultSize :. All) m1
    m2' = replicate (constant $ Any :. resultSize :. All :. All) m2

dft :: Image Pixel8 -> Image PixelRGB8
dft img@Image { .. } = generateImage (\x y -> uncurry3 PixelRGB8 $ rgbsRun `indexArray` (Z :. y :. x)) resultSize resultSize
  where
    resultSize = imageWidth
    dims = Z :. resultSize :. resultSize

    imgComplex = compute $ center $ use $ fromFunction dims $ \(_ :. y :. x) -> P.fromIntegral (pixelAt img x y) / 255 :+ 0

    exps = generate (constant dims) $ \(I2 x y) -> exp $ mult * fromIntegral (x * y)
    mult = constant $ -2 * pi * (0 :+ 1) / P.fromIntegral resultSize

    ps = compute $ rowise resultSize exps imgComplex
    fs = rowise resultSize exps ps

    maxR = the $ maximum $ flatten $ map magnitude fs
    logScalingC = 1 / log (1 + maxR)
    toInt v = round $ v * 255
    rgbs = flip map fs $ \c -> let phase' = 0.5 + phase c / (2 * pi)
                                   logMagn = logScalingC * log (1 + magnitude c)
                                   RGB_ r g b = toRGB $ hsl (phase' * 360) 1 logMagn
                                in T3 (toInt r) (toInt g) (toInt b)
    rgbsRun = run rgbs

хоть одно IO?

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

При этом вычисление одной матрицы с repa работает ровно столько же на одном ядре, сколько вот

int main()
{
        std::vector<float> a;
        a.resize(1024 * 1024 * 1024);
        std::vector<float> b;
        b.resize(1024 * 1024 * 1024);

        std::iota(a.begin(), a.end(), 10);
        std::iota(b.begin(), b.end(), 500);

        auto start = high_resolution_clock::now();

        double result = 0;
        for (int i = 0; i < a.size(); ++i)
                result += a[i] * b[i];

        auto end = high_resolution_clock::now();

        std::cout << result << std::endl;
        std::cout << duration_cast<milliseconds>(end - start).count() << std::endl;
}

плюсовый код: для картинки ширины N пикселей для вычисления, например, элемента матрицы ps (размером NxN) требуется сделать N умножений и N — 1 (считайте, N) сложений — то есть, 2N³ действий, как и в этом коде для N = 1024.

А, ну и специально для любителей гомоиконности: не сильно сложно сделать так, чтобы компиляция была не JIT, а AOT, и под CPU (или под видяху) код генерировался не во время выполнения, а во время компиляции самого хаскель-кода. Вопрос использования маленького кусочка template haskell.

прямые доступы в память и все прочие прелести такого программировать

Максимум — условный unsafeIndex, который без рантайм-проверки границ. А почему? А потому, что система типов слишком слабая (а не слишком сильная), завтипов нет, и доказательство того, что доступ корректный, не то что произвести нельзя, а выразить нельзя.

(можно на benchmarks game посмотреть)

Я бы не стал делать выводы ни о каком языке по benchmarks game, потому что они оптимизируют сильно другую функцию полезности. В реальности так никто не пишет код (вернее, писать такой код сильно неоптимально) что на хаскеле, что на плюсах, что на go.

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

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

Ну так и в случае кода на типах вы либо пишете что-то очень абстрактное, где вам плевать на конкретную монаду (mapM, foldM, whenM и так далее), либо вы пишете что-то менее абстрактное, но тогда у вас там будет не Monad m, а, не знаю, MonadError String m, и тогда у вас куда меньше вопросов о поведении конкретной монады.

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

А хрен знает. Код писать, как и с другими языками, наверное. Ну и чужой читать, да.

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

В Си++ та же самая проблема, на самом деле. Только не с sort, а с шаблонами.

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

Она отчасти смягчается тем, что в Си++ культура другая: там не пытаются все идеи упаковать в минимальные интерфейсы, наоборот всё многословно и интерфейсы богатые. И, вроде как, по структуре этих интерфейсов можно примерно прикинуть, о чём идёт речь и как оно работает.

Это вы блоги людей за последние лет 10 не читали, включая всяких там Саттеров или Титусов Винтерсов.

Зависимые типы, как средство доказательства корректности, — не технология, учитывая те объёмы кода, которые требуются в production для решения задач, а просто любопытная математическая концепция. А на примере какой-то доказанной FS для Linux видно, что подход «докажем для ключевых кусков корректность, а для остального не важно», не работает. Ну, доказали они корректность FS в своей системе аксиом, а потом оказалось, что эта система не отражает реальную работу Linux, и чего делать?

Давайте всё же не будем сравнивать доказательство корректности ФС с доказательством того, что ваша монада — на самом деле монада? Там-то доказательства смешные.

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

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

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

Зачем?

И потерять весь стейт и это без учета всяких Spring boot'ов и других фреймворков которые накладывают свои ограничения на этот процесс
В мире Java ближе всего к CL REPL подошел Clojure но и тот недотягивает