программерско-маркетинговое (война ППИ | 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

[level42.livejournal.com]

Настоящее значительное улучшение продуктивности исходит от языков, которые автоматически управляют памятью для вас." (VB, Java, C#, Lisp..)

угу... в ущерб эффективности... :-)

[exceeder.livejournal.com]

Ну по крайней мере в Лиспе - точно нет ;-) Там инкрементальный способ управления памятью, ибо значения переменных никогда не изменяются.

Собственно, и в других языках это не проблема. Программисты не оптимизируют внешний цикл программы, а занимаются внутренним. Для внутренних же циклов всегда можно придумать эффективный алгоритм, который или вообще не будет создавать-удалять обьектов, или в конце концов можно написать его на С++ (пока такой необходимости не встречал). Все равно для целого проекта это будет эффективнее, чем писать всё на С++ или Дельфи. Ну и по той же причине, к примеру, я не вижу появления драйверов на С# или Джаве :) Есть вещи, которые традиционно останутся С и С++, к примеру, трехмерные двжики в играх. Так же, как до сих пор никуда не исчез Кобол.

Зато писать сложный UI на чистом MFC сейчас - замедлить в 10-15 раз выпуск конечной версии продукта.

[level42.livejournal.com]

насчет сложного UI - согласен на 100% - я бы писал на VB6 или неважно на чем, using Windows Forms... (про SWING заикаться не буду ;-)
но статья 2004 года, а сейчас народ все-таки потихоньку переползает на .NET (не только для WEBa)....
но мне все-таки не по себе, когда я не могу контролировать память напрямую... :-[

[exceeder.livejournal.com]

насчет SWING согласен полностью :) 5я Джава сейчас первый раз за время существования может упростить его до уровня Delphi-VB за счет аннотаций и т.д., однако почти никому это не надо - в UI на Джаве почти никто не станет сейчас инвестировать. Разве что IDE.

На .NET народ переползает, да, однако ни темпы, ни обьемы не сравнить с паровозом эры распространения win32 со скоростью вируса. ИМХО, мы переходим во времена, когда скилс по интеграции и адаптации разномастных продуктов друг к другу будут на вес золота. То есть лучше знать всё и никогда не употреблять "это лучше переделать с 0" :) Хотя опять же, COM в копилке, как самая сложная и заковыристая технология, добавит больше всего к зарплате.

[level42.livejournal.com]

да уж... COM - это воистину слово из 3 букв...:-)

[ex-zadoff59.livejournal.com]

3 года назад (4?) суппортил чиста жаба свинг
трейдинг систему на чикагской бирже.
в четвертом жаба былдере был такой вполне себе ГУИ рисовалка..

сто лет назад в Вижуал С++ тоже была отличная ГУИ рисовалка.
не хуже чем в Вижуал Васике.

дык. жаба ТОРМОЗИЛА. и ЖРАЛА ПАМЯТЬ.
контора начала переписывать куски на с++

[exceeder.livejournal.com]

скажу даже хуже - есть такая фирма Corel. Одно время они были крупным лидером, пока не начали писать UI на Джаве. Теперь у них фактически остался только Сorel Draw. Не на ту лошадь поставили.

С другой стороны, тот же JBuilder или там IDEA или Eclipse отлично выживают с UI на джаве. Просто SWING - очень сложный API. Его нельзя "скликать", а то что генерит JBuilder можно сразу выкинуть в мусорник. У меня есть несколько весьма успешных и сложных UI в копилке (для трансформаций СУБД с графическими инструментами), однако в коде много нестандартных изощрений (извращений?). Короче, сделать можно все, просто... ну долго рассказывать, но у Джавы полно архитектурных проблем - в стандартных APIs. Взять те же EJBs. Ко всему нужно подходить с умом.

[exceeder.livejournal.com]

кстати, а не приходилось заставить как-нибудть быстро работать что-то, бестолково построенное на DCOM c COM и смеси VB с С++, особенно когда там MFC с приравами в виде STL и ADO? Так вот, из личного опыта, оно ТОРМОЗИТ и ЖРЕТ ПАМЯТЬ :)
Собственно, this is what progamms do. They brake and feed on memory :D А винить надо кривые руки, менеджмент и "непредбачуваний збiг обставин".

[ltwood.livejournal.com]

Это хорошо. Еще лет 5-10 разработки программ с такой философией и придется абсолютно все переписывать с нуля. Вот тогда и потребуются люди, знающие, сколько битов в байте...

[exceeder.livejournal.com]

Разверните, плз, мысль. Хотелось бы узнать поподробнее.

[ltwood.livejournal.com]

Да, я не очень четко выразился. Относительно самой интеграции я ничего (почти) не имею против. А написал я в ответ на фразу 'лучше [...] никогда не употреблять "это лучше переделать с 0"'. Дело в том, что и так сейчас в использовании находится масса софта, который стоило бы переписать с нуля и не позволяют это сделать только экономические соображения. Интеграция приведет в частности и к тому, что проблемы в таких программах будут распространяться на весь использующий их софт. Всеобщая интеграция хороша для равномерно качественных компонентов, а в случае софта "приемлемого качество" приводит к взаимному проникновению багов. Весь этот хаос когда-то должен достигнуть критической точки, после которой таки придется многое переписывать с нуля...

[juan-gandhi.livejournal.com]

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

[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 раза. У меня сейчас есть идея одна, если выгорит, напишу результаты.

[level42.livejournal.com]

I know... :-( именно поэтому смотрю в сторону embedded или чего-нить подобного... вот Symbian OS, к примеру... ;-)

[exceeder.livejournal.com]

А еще есть такое огромное поле деятельности, как адаптация виртуальных машин - под процессоры мобильников, под те же embedded системы. Грамотные системщики в этом направлении тоже ценятся и всегда будут.

[level42.livejournal.com]

yup... :) но тем не менее, я слышал неоднократно что с тех пор как для blackberry стали все писать на Java, медленнее они стали значительно...
:-P
и никто меня не переубедит насчет эффективности... согласен, в 85% случаев оно не критично, но в остальных 15% без С никуда. а в С++ многое лишнее... вернее не лишнее, но многие вещи замедляют сильно. Inheritance,Virtual functions и прочий OOP-related junk.

[msh.livejournal.com]

Inheritance вообще ничего не замедляет, ибо это просто концепция, а virtual functions в современном ABI замедляет на одно обращение к памяти.

really?

[level42.livejournal.com]

Object Construction: Inheritance does increase the object construction overhead, as constructors for all the parent classes in the class hierarchy are invoked. There is the additional overhead of setting up vtable in the constructor.


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?

[msh.livejournal.com]

Really, really

Все равно включен объект или унаследован - конструктор и деструктор придется вызывать.

А overhead на создание vtable совершенно пренебрежимый на фоне создания объекта вообще.

Re: really?

[level42.livejournal.com]

угу... вот и вопрос тогда - зачем они вообще нужны - объекты?...

Re: really?

[msh.livejournal.com]

Это чрезмерно философский вопрос. Объекты - это одна из методик проектирования и программирования, сама по себе не good и не evil

:-)

[level42.livejournal.com]

согласен.
я к тому что у меня всегда настольной книгой был Керниган и Ричи, а не Страуструп.
Естественно - это не лучше и не хуже. это просто как оно есть... :-)

Re: really?

[juan-gandhi.livejournal.com]

В критичных кусках, имхо, ничего не надо ни создавать, ни разрушать. Пользоваться имеющимися. Имхо.

Re: really?

[exceeder.livejournal.com]

Абсолютно правильно. Для этого и были придуманы object pools.

[msh.livejournal.com]

Это ерунда. ВОТ, например, рядом со мной есть вакансия для человека, который знает про битики, байтики, заголовки блоков и телефонные протоколы 1968-го года. А для джавы - все в бангалоре. Пусть там выживают.

[level42.livejournal.com]

а "рядом со мной" - это где? :-)

[msh.livejournal.com]

В городке North York. А что?

[level42.livejournal.com]

not much... it happened so that I'm looking for a job right now... :-)

[juan-gandhi.livejournal.com]

Кроме вашей холодной торонтовщины и жаркого бангалора, есть ещё такие благословенные края, как силиконовая. Здесь вряд ли кто интересуется, как правильно имплементировать atdp.

Но, с другой стороны, верно: Знатоки Ядра тоже в почёте.

[msh.livejournal.com]

Такой работы в Торонто как раз мало, а гораздо больше в Оттаве. А уж в SFBA просто таки ужасно больше чем и там и там.

Не знаю, правда, что такое atdp.

[level42.livejournal.com]

одна проблема - в Оттаве делать ну совершенно нечего... город-призрак.

[ex-zadoff59.livejournal.com]

кобол не исчез только благодаря профсоюзам

[exceeder.livejournal.com]

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

[ex-zadoff59.livejournal.com]

кто говорил про "профсоюзы программистов"??

я говорил про профсоюзы мелких шестереок-технишенов. из банков, телефонных компаний, ТВ,
ремонтно строительных и пр..

лично мы натыкаемся на угрозы забастовок и откровенный саботаж. в NY, NJ и прочий бостон.

[cousin-it.livejournal.com]

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

Huh?

Ну и по той же причине, к примеру, я не вижу появления драйверов на С# или Джаве

A driver is something you run in kernel mode, no? So I need a JVM in the kernel? No thanks :-)

[exceeder.livejournal.com]

Посыпаю голову пеплом. Лисп пользуется "полноприводным" garbage collector'ом с конца 50х. Я думал, что, будучи строго функциональным (до введения присвоения в Common Lisp) он мог обойтись счетчиком ссылок на каждом обьекте. Оказалось, что не все так просто.

А про драйвера как раз никто и не спорит.

[belloff.livejournal.com]

Далеко не всегда. Показано, что в memory-rich системах garbage collection - это более эффективно, чем управление памятью вручную. Главным образом за счет того, что сборка мусора происходит большими кусками изредка, а не по чуть-чуть и часто и за счет того, что GC делает дефрагментацию кучи.

yes and no...

[level42.livejournal.com]

но тут уже зависит от эффективности самого GC.

[ex-zadoff59.livejournal.com]

оляля
жаба и выжуал бейсик "улучшают продуктивность"..

"настоящее улучшение" это когда приходицца закупать суперпупер серверы,
потому что Все Тормозит Со Страшной Силой?

[exceeder.livejournal.com]

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

Я могу доказать, что любой одно-экранный алгоритм на С++ может быть грамотно переписан на Джаве (или C#) без потери скорости, а часто и с ускорением - ибо иногда JIT может лучше отоптимизировать код, чем компилятор C++ - ему известно runtime environment.

[ex-zadoff59.livejournal.com]

одноэкранный алгоритм - это пусь штуденты на лабораторках играюцца.

[juan-gandhi.livejournal.com]

Роскошное ля-ля. Но это, щит, когда автор вдруг приплетает различные версии RSS и Atom - блин, как донести до широкой публики, что мой RSS класс читает все форматы; и надо ещё подумать, не сделать ли его способным переводить рсс в атом и обратно...

[exceeder.livejournal.com]

Так его мысль же была вроде не в этом. Такие классы как твой - как раз исправляют проблемы в нашем мире и всячески помогают людям от головной боли. В его же статье говорится, что решением было создание нового формата(!) для RSS, чтобы обьединить другие. Вот, к примеру, создали PNG чтобы обьединить GIF, BMP и всякие pixmapы. Идея хорошая, и даже формат классный, но привел он просто к появлению ещё одного формата. Ни BMP ни GIFы никуда не делись.
Твой подход - конструктивный. Создать обьединяющий API. Создание формата - обычно подход деструктивный. Он повышает энтропию в этом мире :)

[belloff.livejournal.com]

Между нами, девочками - в одной из передач DotNetRocks имел место присутсвовать некий гость из Майкрософт, который прохаживался по этой статье Джоэла в том смысле, что в Майкрософте просто нет тех самых двух лагерей - "MSDN Magazine" vs "Raymond Chen", на которые ссылается Джоэл. Он доверительно сообщил, что MSDN Magazine вообще не принадлежит Майкрософт, а пресловутый Рэймонд Чен не пользуется никаким особенным авторитетом и не имеет своей группы соратников.

[exceeder.livejournal.com]

Любопытно. I am dwelling on this article for the past couple of hours, and it doesn't look so perfekt to me anymore. Хотя она безусловно чем-то импонирует. Иван прав - "роскошное ля-ля" как раз в точку.