Покровы сорваны!

[thedeemon]

Группа ученых под руководством Дэниела Лебреро из Лаборатории Торговых Программных Интерфейсов британской компании IG Markets Ltd провела статистическое исследование о связи числа баг-репортов и языков программирования на базе информации об открытых проектах на сайте "Центр деятельности мерзавцев" (GitHub.com, организация разрешена в России, за исключением некоторых периодов, когда она запрещена). Выяснилось, что наличие статической типизации и продвинутой системы типов не помогает в уменьшении ошибок, а порой даже вредит, в то время как меньше всего ошибок получается в программах на максимально простых языках.

Плотность багов у проектов с 10 звездами и более:


Теперь научно доказано, что theiced был прав: типы не нужны, а писать надо на Кложури. А также Эрланге и Го. Адептам сложных языков и развитых систем типов надлежит раскаяться, одуматься и перестать уже своими надуманными неработающими идеями отвлекать благородных донов, занятых TDD.

Comments

[nponeccop.livejournal.com]

Вот же ж обобщателей понабежало. Перечитайте пост - я всего лишь о своём проекте говорил. Что там у вас - мне не интересно.Сами разбирайтесь.

[yauheni akhotnikau (from livejournal.com)]

У меня нет желания общаться в стиле "сам дурак". Однако, если уж по вашему мнению, STL медленный (и map в частности), то что быстрее при прочих равных?

А если ваш проект такой уникальный и map там не к месту, то чтож вы на него map примеряли?

[nponeccop.livejournal.com]

С чего вы решили, что у меня есть решение, быстрее STL при прочих равных? Если б оно у кого-то было - оно бы было в стандарте.

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

STL безбожно тормозит в том смысле, что универсальное решение почти всегда обгоняется специализированным, причём по моему опыту, в случае STL это ускорение в разы. И роль STL в проекте сводится к некритичным участкам и этапу быстрого прототипирования. После чего STL быстро вырезается по совету профайлера. Это ответ на вопрос "чего ж примеряли".

Мой проект уникальный, как и Ваш. Если у вас в проекте боттлнек в лукапах std::map, и вы не можете придумать более быстрой специализированной альтернативы - бесплатно за вас вашу работу я делать не буду. Тем более что оптимизация - это комплексная задача, нужно видеть всю систему в целом и роль std::map в ней.

std::map это красно-чёрные деревья. Одних только самобалансирующихся деревьев есть штук 10 разных. AVL часто позиционируют как альтернативу. Помимо этого есть tries, hash tables, сортированные массивы (и деревья упакованные в массивы), вероятностные алгоритмы (Bloom filters и т п), автоматы, и можно творчески комбинировать подходы, создавая гибридные структуры. Например, делать отдельный индекс по первым (или последним) символам.

И помимо замены структуры на другую, есть чисто сишные трюки: укорачивание указателей, локальная сборка мусора (сокращает расходы на деаллокацию), хитрые схемы аллокации, хитрые склеивания чтобы вместо трёх аллокаций была одна, генерация специализированного кода в рантайме через LLVM и т.д.

[yauheni akhotnikau (from livejournal.com)]

> С чего вы решили, что у меня есть решение, быстрее STL при прочих равных?

Все понятно. В STL нет готовой структуры данных под вашу конкретную задачу, поэтому STL тормозит безбожно.

[nponeccop.livejournal.com]

С моей точки зрения вы пишете обычный, стереотипичный джуниорский бред.

В тред реквестируются комментаторы http://nponeccop.livejournal.com/490910.html - pappadeux, swizard и elizarov, чтобы разъяснить несчастному содержание предыдущих серий и показать, в каком именно смысле STL тормозит безбожно. Ну или опровергнуть - дескать, от задачи зависит, и STL не только медленный, но даже и шустрый очень, если правильно готовить.

[yauheni akhotnikau (from livejournal.com)]

Да я вообще программировать не умею, большинство LOR-овских аналитиков вам это с удовольствием подтвердят.

Ну и с моей джуниорской точки зрения вы ставите STL в вину то, что ради чего STL и создавалось: универсальное решение, которое трудно обогнать в общем случае. Что позволяет STL-ю решать, как минимум, две важнейшие задачи:

1. Быть единой системой типов для поставщиков различных компонентов. Грубо говоря, если одна команда пишет драйвер к СУБД, а вторая использует этот драйвер, то им нужно как-то между собой взаимодействовать: как-то строки должны передаваться, вектора строк, ассоциативные контейнеры и т.д. Наличие стандартизированных типов контейнеров сильно упрощает такое взаимодействие.

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

По-моему, опять же, джуниорскому разумению, ради этого STL создавался и стандартизировался. И говорить, что STL безбожно тормозит вне рамок этих условий... Ну, блин, странно это.

[andrei-dikun.livejournal.com]

>> Быть единой системой типов для поставщиков различных компонентов.

Вот-вот. А то ведь это была проблема для Си/Си++. В каждой библиотеке своя строка и прочие типы. Потом в свой программе пытаешься их приклеить и состыковать.