Здравствуйте, eao197, Вы писали:
E>Нет, главная особенность в том, что они не такие, как все остальные
в таком случае, уважаемый, ты тоже занимаешься рутиной и клепанием гор посредственного кода
потому что если твой велосипед не ездит быстрее остальных, то разработчик этого велосипеда — рутинщик и ламо недоученное. Во всяком случае, именно в этом меня пытаются убедить
абсолютно не понимаю, что ты хотел продемонстрировать этими прописными истинами
MS>Прошу заметить, что данный пример является лишь иллюстрацией. Понятно, что современными средствами это делается по-другому, типа remove_if или методами в классе строки. Но принцип от этого не изменяется. Есть бесчисленное множество других задач, которые не решаются стандартными методами. И вот алгоритмический анализ и сокращение сложности там, где это принципиально возможно — это очень сильное колдунство. Оно не может быть рутиной по определению, оно может лишь не являться необходимым. Но такие задачи, в которых алгоритмическая оптимизация является несущественной, не вызывают у меня ни малейшего интереса.
Можно упрощать существующие алгоритмы, можно — придумывать свои, для решения более сложных задач. Или ты и с этим не согласен?
Здравствуйте, c-smile, Вы писали:
CS>Развей мою печаль: про "кривые руки" это про что все-таки было?
пара идей, которые приходят в голову без особого углубления в проблему
Пройти по документу, сгруппировать все однотипные элементы (линки — в одну кучку, простой текст — в другую, и т.п.). Для каждой из этих групп извлекаем соответствующий стиль и применяем ко всем элементам, которые попали в группу. Вместо N * M получаем N + const * M, что уже намного лучше.
Правда, узлы, для которых переопределяется CSS, усложняют положение. Придется проводить такую обработку не для всего документа в целом, а для каждого из его узлов, имеющего свою под-CSS.
Альтернативный вариант — пройти по документу и построить глобальную плоскую CSS, заменив у элементов стили на новые. После чего обработать весь документ как одно целое.
Второй вариант должен быть затратнее по расходу памяти, но зато быстрее. Хотя это зависит от конкретных документов, без экспериментов точно сказать нельзя.
В любом случае, сложность O(N * M * D) — это реально только для самой примитивной лобовой реализации
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, c-smile, Вы писали:
CS>>Развей мою печаль: про "кривые руки" это про что все-таки было?
Д>пара идей, которые приходят в голову без особого углубления в проблему
[поскипано]
"без особого углубления в проблему" и тем более без знания CSS
последний(ие) запрограммировать невозможно вообще.
Здравствуйте, c-smile, Вы писали:
CS>[поскипано]
CS>"без особого углубления в проблему" и тем более без знания CSS CS>последний(ие) запрограммировать невозможно вообще.
давайте лучше отставим в сторону менторский тон и поищем в идеях фатальные недостатки, несовместимые с жизнью. Если таковые там есть.
Здравствуйте, Дарней, Вы писали:
E>>Можешь мне объяснить, что ты подразумевал под "изобретают что-то новое"?
Д>"типа и кисти с красками у него свои" Д>какие же они "свои", если они покупаются в ближайшей лавке, только чуть более дорогой?
Видимо, сказалось то, что я когда-то пытался научиться живописи. Так вот у художников никто сам вручную кисти не делает. Да и краски, в подавляющем большинстве, то же. Максимум -- это грунтовку свою, но там и рецептура примитивная -- вода, желатин и гуашь.
А вот разница при использовании дешовых "noname" кистей (неизвестно из какого зверя) и колонковых/беличьих (т.е. дорогих по определению) -- просто огромна. Особенно это заметно при использовании тонких круглых кистей, которые в дешовом варианта начинают разлазиться после трех-четырех сеансов.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А вот разница при использовании дешовых "noname" кистей (неизвестно из какого зверя) и колонковых/беличьих (т.е. дорогих по определению) -- просто огромна. Особенно это заметно при использовании тонких круглых кистей, которые в дешовом варианта начинают разлазиться после трех-четырех сеансов.
я никогда и не говорил, что дешевые инструменты лучше дорогих
только какое отношение это всё имеет к исходной теме, я понять не могу
Здравствуйте, Дарней, Вы писали:
E>>Нет, главная особенность в том, что они не такие, как все остальные
Д>в таком случае, уважаемый, ты тоже занимаешься рутиной и клепанием гор посредственного кода
Не простой вопрос, на самом деле. Вот возьмем один из моих самых любимых велосипедов -- объектное хранилище ObjESSty. Сама по себе ObjESSty -- это около пятидесяти тысяч строк посредственного C++ кода (как смог, так и написал). Но вот ее использование в некоторых задачах (а именно долговременное хранение сложных С++ объектов) позвляет писать гораздо меньше прикладного кода (по сравнению с теми же SQL БД).
Так что, я занимаюсь рутиной при кодировании ObjESSty, но избавляюсь от рутины при использовании ObjESSty.
Что же до скорости -- на моем ноутбуке ObjESSty показывает время ~0.002 секунды при создании и обновлении объекта (т.к. самые дорогостоящие операции при поддержке транзакций с помощью write ahead log). Оценить, насколько это быстро я не берусь, поскольку с SQL базами данных сравнивать не совсем корректно, а других объектных БД у меня в распоряжении нет.
Д>потому что если твой велосипед не ездит быстрее остальных, то разработчик этого велосипеда — рутинщик и ламо недоученное.
Проблема данного обсуждения в том, что под эффективностью здесь понимают сугубо скорость работы кода. Но почему-то забывают, что скорость написания кода так же имеет важное значение, для многих задач даже еще более важное. Вот мои велосипеды не позволяют быстро ездить (в смысле скорости работы кода), зато позволяют быстро запрягать (в смысле более быстрого кодирования).
Но и в том и в другом случае разница между рутинщиком и велосипедистом в том, что рутинщик:
a) не находит в себе сил и желания избавиться от части рутины изобретением велосипеда;
b) даже если у него возникает желание, то он не знает, какую именно часть работы нужно подвергнуть пересмотру, чтобы получить более эффективное решение.
Вот различие между мастерами и подмастерьями, имхо, лежит на уровне варианта b). Просто потому, что подмастерью еще не хватает ни опыта, ни чутья, чтобы определить точное место "бутылочного горлышка".
А вариант a) -- это уже на уровне психологии. Человек, который склонен сам браться за устранение узких мест, имхо, сможет и рутиной заниматься. Но, поскольку душа у него к этому не будет лежать, то и качество будет не самым высоким. А вот если бы ему предоставили возможность делать то, что хочется... Возьми к примеру какую-нибудь софтину для искуственной генерации ландшафтов (с помощью фракталов и других материй из высшей математики). Там ведь прорва работы -- и графический интерфейс (менюшки, тулбары, диалоги), и форматы графических файлов, и система помощи, и печатная документация и пр. и пр. Но вот все это будет иметь совершенно бледный вид, если сама генерация ландшафта будет в два раза медленнее (при том же качестве), что и у конкурентов.
Та же песня и с СУБД. Ядро СУБД, от которого зависит эффективность работы СУБД, может занимать процентов тридцать от всего объема кода (не считая сопутствующих административных утилит). Но при оценке СУБД качество работы ядра будет привлекать наибольшее количество внимания. (По крайней мере для встраиваемых СУБД, типа ObjESSty, BerkeleyDB или SQLite).
Так вот называть людей, программирующих "узкие места" (будь то генерация фракталов или система кэширования страниц) рутинщиками вряд ли возможно. Хотя бы в силу уникальности решаемых ими задач. Одним из следствий, является то, что со своими специализированными навыками эти узкие специалисты больше нигде не нужны (в отличии от тех, скажем, кто пишет пользовательский интерфейс для программы генерации ландшафтов или административных утилит СУБД).
Ну и что еще более важно -- для успешности проекта нужна нормальная команда, в которую входят и те и другие. Без внутренних войн и перетягивания одеяла на себя. Но это уже совсем другая история.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, c-smile, Вы писали:
CS>>[поскипано]
CS>>"без особого углубления в проблему" и тем более без знания CSS CS>>последний(ие) запрограммировать невозможно вообще.
Д>давайте лучше отставим в сторону менторский тон и поищем в идеях фатальные недостатки, несовместимые с жизнью. Если таковые там есть.
Давай. Только сначала придется разобраться что есть cascading, selector specificity.
Если пойти по ссылке то можно прочитать следующее:
WebCore (in upcoming Safari releases) has a really cool optimization that I came up with to avoid even having to compute the set of declarations that apply to an element. This optimization in practice results in not even having to match style for about 60% of the elements on your page.
The idea behind the optimization is to recognize when two elements in a page are going to have the same style through DOM (and other state) inspection and to simply share the front end style information between those two elements whenever possible.
There are a number of conditions that must be met in order for this sharing to be possible:
(1) The elements must be in the same mouse state (e.g., one can't be in :hover while the other isn't)
(2) Neither element should have an id
(3) The tag names should match
(4) The class attributes should match
(5) The set of mapped attributes must be identical
(6) The link states must match
(7) The focus states must match
(8) Neither element should be affected by attribute selectors, where affected is defined as having any selector match that uses an attribute selector in any position within the selector at all
(9) There must be no inline style attribute on the elements
(10) There must be no sibling selectors in use at all. WebCore simply throws a global switch when any sibling selector is encountered and disables style sharing for the entire document when they are present. This includes the + selector and selectors like :first-child and :last-child.
Примерно же такая оптимизация работает в Mozilla насколько мне известно.
У меня используется несколько иная схема — традиционный caching. Быстрее работает в моем случае.
Приведенный список 10 ситуаций (особенно последняя тема) сводят на нет возможные способы редуцирования O(N*M*D)
Например сайты семейства wikipedia в принципе не оптимизируемы из-за своей системы стилей.
Проблема усугубляется еще тем что мало найти список стилей в который попадает данный элемент,
нужно осуществить собственно последовательное наследование этих стилей для получения финального.
CSS level 3 это примерно 60-70 атрибутов у одного стиля.
Т.е. style resolving это серьезно.
Здравствуйте, eao197, Вы писали:
E>Не простой вопрос, на самом деле. Вот возьмем один из моих самых любимых велосипедов -- объектное хранилище ObjESSty. Сама по себе ObjESSty -- это около пятидесяти тысяч строк посредственного C++ кода (как смог, так и написал). Но вот ее использование в некоторых задачах (а именно долговременное хранение сложных С++ объектов) позвляет писать гораздо меньше прикладного кода (по сравнению с теми же SQL БД).
E>Так что, я занимаюсь рутиной при кодировании ObjESSty, но избавляюсь от рутины при использовании ObjESSty.
вообще-то, я то же самое говорил
E>Проблема данного обсуждения в том, что под эффективностью здесь понимают сугубо скорость работы кода. Но почему-то забывают, что скорость написания кода так же имеет важное значение, для многих задач даже еще более важное. Вот мои велосипеды не позволяют быстро ездить (в смысле скорости работы кода), зато позволяют быстро запрягать (в смысле более быстрого кодирования).
E>Ну и что еще более важно -- для успешности проекта нужна нормальная команда, в которую входят и те и другие. Без внутренних войн и перетягивания одеяла на себя. Но это уже совсем другая история.
проблема в том, что многие из тех самых "программистов узких мест" имеют обыкновение считать всех окружающих идиотами
собственно, реакция некоторых участников нашего флэйма прекрасно это демонстрирует
Господа, а не кажется ли вам, что вся эта дискуссия просто-напросто демонстрирует одно простой факт ?
Единого мира программирования попросту не существует. Эта область человеческой деятельности давно уже разбилась на ряд вполне отдельных областей, в которых действуют свои законы, и в разных областях эти законы бывают порой попросту противоположными. И то. что верно для приложений 3D графики — совсем не годится для разработки корпоративных сайтов...
Отсюда и непонимание друг друга. Все равно как если бы архитектор, создающий современные жилые дома, начал дискутировать с архитектором, чья специальность — церкви или соборы. Один про важность состыковки крупнопанельных блоков и промышленное их производство, другой ему в ответ — о том, как правильно купола делать из кирпичей.
Хотя и тот и другой — архитекторы.
_>Вы когда-нибудь занимались не шарашками расчитанными на месяц, типа получил бабки и свалил, _>а нормальным сопровождением своих же програм которое длится более n лет. _>Деньги нужно брать не за РЕШЕНИЕ, а за то что оно (ваше РЕШЕНИЕ) будет работать и приносить клиенту прибыль. _>n — 1,2,3 и.т.д
Согласен. Это больше вопрос отношения к делу. Мой подход подразумевает отношения с заказчиком как разработчик-заказчик, а не пиявка-жертва. При этом подходе архитектуру надо проектировать. Это работа. Но лучшая работа, чем лишний труд, основанный на бездумном загадывании на будущее.
РЕШЕНИЕ, в моём понимании — именно решение задачи, сформулированной заказчиком. Предполагается (с некоторыми допущениями ) что заказчик знает, что он делает, и вы не думаете за него на каждом шаге. И если Вы видите дополнительные проблемы (в нашем понимании — задачи ) которые встанут перед заказчиком, лучше сразу сообщать ему об этом, или закладываясь на эти задачи, хотя бы ставить заказчика в известность.
А не работать на вырост просто так, потому что вам так придумалось. Это тоже должно быть частью РЕШЕНИЯ.
Но это только моя позиция. Я её Вам не навязываю.
К примеру, некоторые здесь считают алгоритмирование — основной задачей программирования, а всё остальное фуфлом. У каждого свой подход, и, исходя из этого, своё место в жизни.
Здравствуйте, Дарней, Вы писали:
Д>Пройти по документу, сгруппировать все однотипные элементы (линки — в одну кучку, простой текст — в другую, и т.п.). Для каждой из этих групп извлекаем соответствующий стиль и применяем ко всем элементам, которые попали в группу.
Это подходит только для случаев, когда селекторов в CSS мало. А если их много? А это — суровая реальность соврменной верстки. Д> Вместо N * M получаем N + const * M, что уже намного лучше.
Д>Правда, узлы, для которых переопределяется CSS, усложняют положение. Придется проводить такую обработку не для всего документа в целом, а для каждого из его узлов, имеющего свою под-CSS. Д>Альтернативный вариант — пройти по документу и построить глобальную плоскую CSS, заменив у элементов стили на новые. После чего обработать весь документ как одно целое.
Идея хорошая, но сколько она будет стоить? В том-то вся и проблема, что для "планаризации" CSS нужно для каждого элемента выполнить сканирование списка правил и выбрать те, которые применимы. Вычисление применимости селектора в общем случае требует просмотра полного списка предков, а также подглядывания в соседей.
Когда список правил построен, его нужно отсортировать по важности и специфичности. А затем для каждого из запрошенных атрибутов вычислить его фактическое значение с учетом приоритета. Многие стили придется брать из предка; некоторые атрибуты для вычисления потребуют вычисления значения атрибута предка.
Я не специалист, но геморрой тут заметен невооруженным взглядом.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дарней, Вы писали:
Д>проблема в том, что многие из тех самых "программистов узких мест" имеют обыкновение считать всех окружающих идиотами
Есть еще и обратная проблема: многие из тех, кто в принципе не смог бы заниматься узкими местами, смотрит на специализированных специалистов свысока и снисходительно. Типа, мы-то всегда на волне, а вы в своих микрооптимизациях рельного мира-то и не видите.
Это все экстримизм, на который лучше не обращать внимания.
Хотя, иногда, после рюмки-другой 10-летней выдержки чайку "Белый Аист", хочется проронить скупую мужскую слезу, порвать рубаху со словами: "Да я!... Да сложный объект...! Да за две миллисекунды...! Да в режиме транзакционности!...".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>я никогда и не говорил, что дешевые инструменты лучше дорогих Д>только какое отношение это всё имеет к исходной теме, я понять не могу
Такое отношение, имхо, что сравнение между работой программистов и художников у Шахтера получилось более рельным (на мой сермяжный взгляд), чем у тебя. Ближе к действительности, так сказать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Это подходит только для случаев, когда селекторов в CSS мало. А если их много? А это — суровая реальность соврменной верстки.
можно закэшировать полученную плоскую CSS (если исходить из предположения, что CSS не будет меняться при каждой загрузке страницы )
хотя тут тоже свои заморочки, в особенности для встроенных CSS. теоретически их тоже можно кэшировать, но на практике геморрой будет стремительно разрастаться
S>Я не специалист, но геморрой тут заметен невооруженным взглядом.
геморрой конечно немаленький, но по моему впечатлению, его происхождение — в основном в сложности самой системы применения правил CSS. А от этого в любом случае никуда не деться
Здравствуйте, c-smile, Вы писали:
CS>Примерно же такая оптимизация работает в Mozilla насколько мне известно.
то есть примерно то же самое, что я предлагал
хотя дьявол, как всегда, в деталях
CS>У меня используется несколько иная схема — традиционный caching. Быстрее работает в моем случае.
CS>Приведенный список 10 ситуаций (особенно последняя тема) сводят на нет возможные способы редуцирования O(N*M*D) CS>Например сайты семейства wikipedia в принципе не оптимизируемы из-за своей системы стилей.
тем не менее, мне кажется, что случай когда каждый элемент на странице имеет отличающийся от других стиль — это исключение, а не правило
Здравствуйте, eao197, Вы писали:
E>Есть еще и обратная проблема: многие из тех, кто в принципе не смог бы заниматься узкими местами, смотрит на специализированных специалистов свысока и снисходительно.
не вижу для этого причин, за исключением фатальных ошибок в генетическом коде но таких особей к любому вида программирования подпускать нельзя
E>Хотя, иногда, после рюмки-другой 10-летней выдержки чайку "Белый Аист", хочется проронить скупую мужскую слезу, порвать рубаху со словами: "Да я!... Да сложный объект...! Да за две миллисекунды...! Да в режиме транзакционности!...".
) что заказчик знает, что он делает, и вы не думаете за него на каждом шаге. И если Вы видите дополнительные проблемы (в нашем понимании — задачи 
1.1.4 stable rev. 510
