программерско-маркетинговое (война ППИ | API war)

[exceed_er]

С удовольствием прочитал вот эту статью: http://www.joelonsoftware.com/articles/APIWar.html
(кстати, ППИ = прикладной программный интерфейс = API. Не знаю, пользуются ли этой аббревиатурой еще, вообще не завидую переводчикам программерских материалов)

Хотя статья обьясняет, почему и как Майкрософт проиграл одну весьма важную для него войну, она отнюдь не анти-майкрософт. Скорее она выражает взвешенную точку зрения программиста, который выбирает инструменты для программы, которой работать следующие 5-10 лет. Я не нашел места, где бы я был не согласен с автором. Плюс, отличное чувство юмора и много мест, где я ржал.

"Майкрософт часто делает ставки, которые проигрывает. Например WinFS, разрекламированная как способ улучшить поиск, сделав файловую систему реляционной базой данных, игнорирует факт, что настоящий способ улучшить поиск - это улучшить поиск. Не надо заставлять меня впечатыавть метадату для всех моих фйлов, чтобы я выучил и мог использовать язык запросов. Просто имейте совесть и поищите долбаный диск, быстро, по строке, которую я напечатал, используя текстовые индексы и технологии, которые уже в 1973 г. перестали быть новыми и интересными."

"В начале 90х многие из нас думали, что большая битва будет между процедурным и ОО-программированием, и мы думали что ОО резко улучшит продуктивность. Я тоже так думал. Многие люди все еще так думают. Оказалось, что мы не правы. ООП - очень удобный прикол, но это не то что было обещано. Настоящее значительное улучшение продуктивности исходит от языков, которые автоматически управляют памятью для вас." (VB, Java, C#, Lisp..)

Из статьи становится предельно ясно, почему Intenet Explorer уже несколько лет не развивается (и не будет), что происходит с C# и почему гораздо больше программ на C# для веба а компании не спешат переводить свои существующие программы на .НЕТ.

В конце статьи есть немного рекламы софта, который автор разрабатывал, и я уже совсем ржал на вот этом скриншоте:
http://www.fogcreek.com/FogBUGZ/40tour/06.html
Он в деталях показывает путь ошибки, найденной клиентом через менеджеров и программеров в новый релиз.

Comments

[exceeder.livejournal.com]

В словах этих, конечно же, есть истина. Однако довелось мне на днях оптимизировать достаточно критичную структуру данных. На Джаве. Надо было написать наиболее быстрый и оптимальный по памяти контейнер для пар строка-обьект, причем таких пар не больше 20 на контейнер. Как отправная точка брался HashMap. Так вот, в первой паре тестов быстрее оказывался тот контейнер, который тестировался первым по ходу программы :) Пришлось вспоминать, как устроены процессорные кэши и думать, как оно вообще где выполняется. Ну и также пришлось вспоминать воркшоп с разработчиками GC, чтобы написать более-менее репрезентабельный тест всего цикла использования контейнеров, включая GC. Но, пожалуй, на этом уровне уже можно остановиться. Ибо знание ассемблера уже никак не помогает ничего отоптимизировать - даже самые крепкие уже согласились, что оптимизирующие компиляторы справляются лучше.

[juan-gandhi.livejournal.com]

Пардон. Бенчмарк такого рода нужно сначала потренировать, этак 10 миллионов раз, на заданном участке кода, а потом уже начать мерять. Это же джава.

Вообще, в таком случае помогает (грустное) знание дебильного устройства двух вещей: хашмапа и хашкода строки.

Кто-нибудь бы научил Сан какой-нибудь алгебре там, расстоянию Хэмминга, что-нибудь в таком роде. Но они гордые, они думают, что лучше их никто ничего не знает.

Кстати, если 20 строк, и так уж критично, может быть, стоит попробовать trie (см Кнут, том 3).

А что за идея насчёт gc? От него, имхо, вообще лучше держаться подальше.

[exceeder.livejournal.com]

Не, trie не подойдут, я о них думал. Скорость хорошая, но память расходуется слишком сильно - одна буква и две ссылки на узел в дереве. Тут такое дело, что чем меньше расходовать памяти, тем больше влезет в кэш, а значит меньше I/O.
Из-за этого же не могу воспользоваться ХэшМеп напрямую - там десяток референсов хранится на внутренние transient структуры типа EntrySet, которые мне не нужны. Тут такое дело, что при 20 парах уже даже прямой перебор в массиве всего 80% проигрывает хэшмепу (миллион чтений из HM занимает секунду, а перебором из массива пар - 1.8 сек). А память экономится в 2 раза. У меня сейчас есть идея одна, если выгорит, напишу результаты.