покажи мне, что ли, энкодер видео на хаскеле :) или стример того же видео / аудио на эрланге видел, на хаскеле - нет еще пусть даже он будет что-то стороннее из libav* подключать
Я думаю, написать можно и даже оптимизировать, но ничего хорошего с этого не выйдет. Оптимизированный под производительность хаскелевый код выглядит чудовищно. Интерор с сторонним тоже печален, впрочем.
Вот и основная разница. Плюсы - высокопроизводительный кроссплатформенный язык, синтаксис которого /местами/ ужасен, оброс всякими всякостями за годы. Все что он умеет можно писать и на чистых сях, но неудобно получается для больших проектов (или код выглядит как внутренности того же 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>" и "::" и представлять параметризованные типы данных (так называемая "большая лямбда" в функциональщине, "типы, зависящие от типов").
И в связи с этим приподнимается вопрос: как будет выглядет тот же хаскель лет через тридцать сверхинтенсивного индустриального использования где надо и не надо - и пары-тройки ревизий с учётом накопившегося опыта. ;)
Ну-ну, попробуй. Будет эмуляция С++ на монадах и хаскельном синтаксисе, в три раза многословнее Си, ибо скорее всего очень много низкоуровневых моментов придется прописывать явно.
Это неправда. Во-первых, для _кодогенерации_ не нужно глубогокого описания семантики. Во-вторых, описание некоторого подмножества сишечки не так и сложно. Я сам лично пробовал таким вот образом низкоуровневого программировать, и получалось куда прикольнее C++. Тогда я активно работал с C++ и ещё мог оценить... Получаются относительно нормальные макросы, взамен всяких там <>. И уже дальше, при желании, если задача большая и сложная, то моожет быть, и стоит моделировать глубже. Вот там уже и возникнут, вероятно, и пачки монадных и даже стрелочных трансформеров. Но и без этого, получается ничуть не хуже C++. Типаа, в C++ это всё так замечательно типизровано, что ли??... Это у меня было, приблизительно, в эпоху, когда только-только в GHC сделали инфиксную запись типов и вот уже включали в новый GHC. Помню потому, что помню, как радовался ;-)
Сгенерить код "шоб работало" сравнительно несложно. А вот видеокодек так писать, придется массу подробностей указывать - тут выравнивание, тут интринсик, тут столько битов в арифметике, тут столько, тут на стеке массивчик, тут еще что. Сокращения кода не ожидается, только синтаксис многословнее.
Если говорить про написание на чистом си, ну или подмножестве, которое эмулируем — да, даже близкого по объёму кода добиться сложно. А если говорить про C++, о чём и начали разговор, то все его возможные мета-хрени будут выглядеть куда проще. И дело вовсе не в выравнивании и битах в арифметике.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2012-06-17 03:59 pm (UTC)если кажется сложным - пиши на objective-c (бугага)
no subject
Date: 2012-06-17 05:22 pm (UTC)no subject
Date: 2012-06-17 06:06 pm (UTC)или стример того же видео / аудио
на эрланге видел, на хаскеле - нет еще
пусть даже он будет что-то стороннее из libav* подключать
no subject
Date: 2012-06-17 06:16 pm (UTC)no subject
Date: 2012-06-17 06:25 pm (UTC)no subject
Date: 2012-06-17 07:44 pm (UTC)Синтаксис -- почти всегда мелочь, на которую почему-то именно тупые кодеры обращают внимание.
no subject
Date: 2012-06-17 09:25 pm (UTC)я сам не могу быть объективен, так как на плюсах пишу уже лет 15 и давно глаз замылен
т.е. что-то типа
typedef boost::shared_ptr< Frame > FramePtr;
FramePtr frame = boost::make_shared< Frame >( data, width, height, pixelformat );
не вызывает проблем никаких, но для многих может быть непривычным
no subject
Date: 2012-06-17 10:58 pm (UTC)Конкретно тут -- разве что type inference могла бы пофиксить синтаксис, да и то, не сильно: убрать typedef и/или тип значения frame. Но в данном куске кода это всего лишь косметика, к такому придираться низко.
К отсутствию type inference придерусь, но это не синтаксис, а типизация (которую я бы назвал "семантика для компилятора", хотя слишком вольно звучит).
В остальном -- пример очень понятный с точки зрения синтаксиса, если знать, что такое "t1<t2>" и "::" и представлять параметризованные типы данных (так называемая "большая лямбда" в функциональщине, "типы, зависящие от типов").
no subject
Date: 2012-06-18 05:17 am (UTC)no subject
Date: 2012-06-17 06:52 pm (UTC)no subject
Date: 2012-06-17 07:10 pm (UTC)no subject
Date: 2012-06-17 07:36 pm (UTC)no subject
Date: 2012-06-17 07:52 pm (UTC)no subject
Date: 2012-06-17 08:06 pm (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2012-06-17 09:12 pm (UTC)no subject
Date: 2012-06-18 01:45 am (UTC)no subject
Date: 2012-06-18 05:08 am (UTC)no subject
Date: 2012-06-18 05:16 am (UTC)no subject
Date: 2012-06-18 06:11 am (UTC)no subject
Date: 2012-06-18 11:14 am (UTC)Во-первых, для _кодогенерации_ не нужно глубогокого описания семантики.
Во-вторых, описание некоторого подмножества сишечки не так и сложно.
Я сам лично пробовал таким вот образом низкоуровневого программировать, и получалось куда прикольнее C++. Тогда я активно работал с C++ и ещё мог оценить...
Получаются относительно нормальные макросы, взамен всяких там <>.
И уже дальше, при желании, если задача большая и сложная, то моожет быть, и стоит моделировать глубже. Вот там уже и возникнут, вероятно, и пачки монадных и даже стрелочных трансформеров. Но и без этого, получается ничуть не хуже C++.
Типаа, в C++ это всё так замечательно типизровано, что ли??...
Это у меня было, приблизительно, в эпоху, когда только-только в GHC сделали инфиксную запись типов и вот уже включали в новый GHC. Помню потому, что помню, как радовался ;-)
no subject
Date: 2012-06-18 03:10 pm (UTC)no subject
Date: 2012-06-18 03:49 pm (UTC)А если говорить про C++, о чём и начали разговор, то все его возможные мета-хрени будут выглядеть куда проще.
И дело вовсе не в выравнивании и битах в арифметике.
(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-06-18 03:14 pm (UTC)http://ffmpeg.org/doxygen/trunk/msvideo1_8c-source.html
Что тут сильно упростится при генерации его из хаскеля?
no subject
Date: 2012-06-19 02:25 am (UTC)http://wiki.multimedia.cx/index.php?title=Microsoft_Video_1
no subject
Date: 2012-06-18 08:29 am (UTC)