ну вот я имею опыт с той же libpng, и считаю её уёбищем. я не знаю, какие задачи она должна решать — но задачи удобной работы с png она не решает вообще. как раз потому, что у неё в принципе такой цели не было, у неё была цель «реализовать стандарт». в итоге я или пинаю imlib2 (которая тоже не сахар, но намного удобней для простых целей), или вообще взял из гоззы minipng и глобально обработал напильником (потому что идиот; лучше бы с нуля написал).

с либжопег, по ходу, всё ещё хуже. но там вдобавок формат уёбищный, и dct, и мне лень как парзер пилить, так и dct, так что при необходимости возьму, наверное, её. или спизжу код из stb_image.

для fft мне хватало kissfft. ну, у меня не было задач, где скорость настолько критична. были бы — наверное, взял бы fftw.

это всё ещё к той тонкой границе между нежеланием запариваться неудобными библиотеками и маниакальным желанием всё написать с нуля самому. однако почти все эти библиотеки всё равно неудобны — именно за счёт их универсальности.

реально — супероптимизирование по скорости далеко не всегда важно. и библиотеки часто берут «на вырост», кстати. ту же sqlite: да камон, её часто тянут туда, где достаточно было бы наколенного балансированого дерева с простейшим mmap (если ни вообще тупо массива с линейным/двоичным поиском). а картинку часто можно imagemagic-ом конвертнуть в какую-нибудь pnm и читать результат из stdin. и ты пы.

(Reply to this) (Parent) (Thread)

> и библиотеки часто берут «на вырост», кстати. ту же sqlite: да камон, её часто тянут туда, где достаточно было бы наколенного балансированого дерева с простейшим mmap

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

(Reply to this) (Parent) (Thread)

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

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

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

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

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

а потом кто-то пытается решить конкретную задачу при помощи этого агрегата, и в итоге строит агрегат по использованию агрегата.

(Reply to this) (Parent)