Я думаю, написать можно и даже оптимизировать, но ничего хорошего с этого не выйдет. Оптимизированный под производительность хаскелевый код выглядит чудовищно. Интерор с сторонним тоже печален, впрочем.
Вот и основная разница. Плюсы - высокопроизводительный кроссплатформенный язык, синтаксис которого /местами/ ужасен, оброс всякими всякостями за годы. Все что он умеет можно писать и на чистых сях, но неудобно получается для больших проектов (или код выглядит как внутренности того же ffmpeg). Альтернативы я ему пока не вижу. Тут проскакивали попытки впихнуть в него гэрбедж-коллектинг, но при наличии shared_ptr оно и не сильно нужно (оверхед в случае наличия множества мелких объектов убирается аллокаторами памяти, типа гуглового или jemalloc, что позволяет избавляться от излишней фрагментированности кучи при активной работе с памятью).
ну ебать. Разве у крестиков проблемы с синтаксисом? Проблемы как раз с семантикой. Синтаксис -- почти всегда мелочь, на которую почему-то именно тупые кодеры обращают внимание.
я сколько общался со страдальцами - все жаловались на синтаксис я сам не могу быть объективен, так как на плюсах пишу уже лет 15 и давно глаз замылен т.е. что-то типа typedef boost::shared_ptr< Frame > FramePtr; FramePtr frame = boost::make_shared< Frame >( data, width, height, pixelformat ); не вызывает проблем никаких, но для многих может быть непривычным
значит дебилы-страдальцы попадались. Это бывает. Конкретно тут -- разве что type inference могла бы пофиксить синтаксис, да и то, не сильно: убрать typedef и/или тип значения frame. Но в данном куске кода это всего лишь косметика, к такому придираться низко. К отсутствию type inference придерусь, но это не синтаксис, а типизация (которую я бы назвал "семантика для компилятора", хотя слишком вольно звучит). В остальном -- пример очень понятный с точки зрения синтаксиса, если знать, что такое "t1<t2>" и "::" и представлять параметризованные типы данных (так называемая "большая лямбда" в функциональщине, "типы, зависящие от типов").
И в связи с этим приподнимается вопрос: как будет выглядет тот же хаскель лет через тридцать сверхинтенсивного индустриального использования где надо и не надо - и пары-тройки ревизий с учётом накопившегося опыта. ;)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
Синтаксис -- почти всегда мелочь, на которую почему-то именно тупые кодеры обращают внимание.
no subject
я сам не могу быть объективен, так как на плюсах пишу уже лет 15 и давно глаз замылен
т.е. что-то типа
typedef boost::shared_ptr< Frame > FramePtr;
FramePtr frame = boost::make_shared< Frame >( data, width, height, pixelformat );
не вызывает проблем никаких, но для многих может быть непривычным
no subject
Конкретно тут -- разве что type inference могла бы пофиксить синтаксис, да и то, не сильно: убрать typedef и/или тип значения frame. Но в данном куске кода это всего лишь косметика, к такому придираться низко.
К отсутствию type inference придерусь, но это не синтаксис, а типизация (которую я бы назвал "семантика для компилятора", хотя слишком вольно звучит).
В остальном -- пример очень понятный с точки зрения синтаксиса, если знать, что такое "t1<t2>" и "::" и представлять параметризованные типы данных (так называемая "большая лямбда" в функциональщине, "типы, зависящие от типов").
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject