![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
программерско-маркетинговое (война ППИ | API war)
С удовольствием прочитал вот эту статью: 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
Он в деталях показывает путь ошибки, найденной клиентом через менеджеров и программеров в новый релиз.
(кстати, ППИ = прикладной программный интерфейс = API. Не знаю, пользуются ли этой аббревиатурой еще, вообще не завидую переводчикам программерских материалов)
Хотя статья обьясняет, почему и как Майкрософт проиграл одну весьма важную для него войну, она отнюдь не анти-майкрософт. Скорее она выражает взвешенную точку зрения программиста, который выбирает инструменты для программы, которой работать следующие 5-10 лет. Я не нашел места, где бы я был не согласен с автором. Плюс, отличное чувство юмора и много мест, где я ржал.
"Майкрософт часто делает ставки, которые проигрывает. Например WinFS, разрекламированная как способ улучшить поиск, сделав файловую систему реляционной базой данных, игнорирует факт, что настоящий способ улучшить поиск - это улучшить поиск. Не надо заставлять меня впечатыавть метадату для всех моих фйлов, чтобы я выучил и мог использовать язык запросов. Просто имейте совесть и поищите долбаный диск, быстро, по строке, которую я напечатал, используя текстовые индексы и технологии, которые уже в 1973 г. перестали быть новыми и интересными."
"В начале 90х многие из нас думали, что большая битва будет между процедурным и ОО-программированием, и мы думали что ОО резко улучшит продуктивность. Я тоже так думал. Многие люди все еще так думают. Оказалось, что мы не правы. ООП - очень удобный прикол, но это не то что было обещано. Настоящее значительное улучшение продуктивности исходит от языков, которые автоматически управляют памятью для вас." (VB, Java, C#, Lisp..)
Из статьи становится предельно ясно, почему Intenet Explorer уже несколько лет не развивается (и не будет), что происходит с C# и почему гораздо больше программ на C# для веба а компании не спешат переводить свои существующие программы на .НЕТ.
В конце статьи есть немного рекламы софта, который автор разрабатывал, и я уже совсем ржал на вот этом скриншоте:
http://www.fogcreek.com/FogBUGZ/40tour/06.html
Он в деталях показывает путь ошибки, найденной клиентом через менеджеров и программеров в новый релиз.
no subject
no subject
no subject
Вообще, в таком случае помогает (грустное) знание дебильного устройства двух вещей: хашмапа и хашкода строки.
Кто-нибудь бы научил Сан какой-нибудь алгебре там, расстоянию Хэмминга, что-нибудь в таком роде. Но они гордые, они думают, что лучше их никто ничего не знает.
Кстати, если 20 строк, и так уж критично, может быть, стоит попробовать trie (см Кнут, том 3).
А что за идея насчёт gc? От него, имхо, вообще лучше держаться подальше.
no subject
Из-за этого же не могу воспользоваться ХэшМеп напрямую - там десяток референсов хранится на внутренние transient структуры типа EntrySet, которые мне не нужны. Тут такое дело, что при 20 парах уже даже прямой перебор в массиве всего 80% проигрывает хэшмепу (миллион чтений из HM занимает секунду, а перебором из массива пар - 1.8 сек). А память экономится в 2 раза. У меня сейчас есть идея одна, если выгорит, напишу результаты.
no subject
no subject
no subject
:-P
и никто меня не переубедит насчет эффективности... согласен, в 85% случаев оно не критично, но в остальных 15% без С никуда. а в С++ многое лишнее... вернее не лишнее, но многие вещи замедляют сильно. Inheritance,Virtual functions и прочий OOP-related junk.
no subject
really?
Object Destruction: Inheritance does increase the object destruction overhead, as destructors for all the parent classes in the class hierarchy are invoked. There is the additional overhead of setting up vtable in the destructor. Virtual destructors also increase the overhead of object destruction.
Re: really?
Все равно включен объект или унаследован - конструктор и деструктор придется вызывать.
А overhead на создание vtable совершенно пренебрежимый на фоне создания объекта вообще.
Re: really?
Re: really?
:-)
я к тому что у меня всегда настольной книгой был Керниган и Ричи, а не Страуструп.
Естественно - это не лучше и не хуже. это просто как оно есть... :-)
Re: really?
Re: really?
no subject
no subject
no subject
no subject
no subject
Но, с другой стороны, верно: Знатоки Ядра тоже в почёте.
no subject
Не знаю, правда, что такое atdp.
no subject