Я тут в очередной раз с адептами .Net схватился. Вообще говоря, занятные они люди. Уверовали в очередную панацею, и теперь все, тчо хоть какую-то критику этой панацеи представляет собой — вызывает реакцию, похожую на реакцию мусульман на карикатуры на пророка Мухаммеда
Сколько я этих панацей на своем веку видел, и где они сейчас...
Вчера задумался на эту тему, и вдруг неожиданно даже для себя пришел к выводу, меня поразившему. Вот он.
Если что-то при рождении своем дружно рассматривалось как новое слово, как полный переворот в ИТ — судьба этого была плачевна. А вот то, что при рождении все дружно ругали — побеждало.
Иными словами, законный принц — наследник престола его никогда не получал. Престол доставался гадкому утенку, выросшему в нищете и на задворках.
Вот примеры принцев
1. Алгол-60. Единственный термин из ИТ, которое я слышал, до того, как начал заниматься программированием (в 20 лет) — алгол. У меня книга до сих пор лежит где-то с названием "Универсальный язык программирования Алгол-60" И даже какой-то научно-фантастический роман припоминаю, где две внеземные цивилизации друго с другом на алголе объясняются . А уж в том. что он презренный Фортран заменит, никто и не сомневался.
Помер.
2. Алгол-68. Тоже все бурно хвалили в конце 60-х. Новое слово в программировании.
Помер.
3. ПЛ/1. Язык, предназначенный на замену Фортрана и Кобола одновременно.
Они оба до сих пор живы, о ПЛ/1 практически не слыхать.
4. Ада. Новое слово. Международный конкурс. В СССР немедленно выпускают несколько книг (а в то время книги издавать не спешили). Заменит все языки. Впитала в себя лучшие свойства всех предыдущих языков.
Скорее мертва чем жива.
5. Пролог. Основа японского проекта ЭВМ 5 поколения. Шуму до потолка. "Вызов Японии миру".
Где этот вызов и где пролог ?
6. Ява (да простят меня ее сторонники, я вовсе не хочу их задеть.) Опять то же, язык, который должен вытеснить и Паскаль, и С++.
Жив вполне. Но не вытеснил.
7. OS/2. Законный наследник MS-DOS. Признанный наследник престола в конце 80-х.
Померла.
А вот гадкие утята.
1. Паскаль. Язык созданный Виртом, в общем-то не для реального использования, а скорее как демонстрация того, каким должен быть язык. Около 10 лет (могу ошибиться, но примерно так) находится на задворках программистского мира. У меня лежит дома десятка полтора книг по Фортрану того времени и одна жалкая брошюра по Паскалю. Никто его всерьез не воспринимает.
В середине 80-х вспыхивает фейерверком и не погас до сих пор.
2. С. Синтаксический урод. Скажи кто-нибудь при его рождении, что именно он свергнет царство Фортрана — дружно посмеялись бы. Предмет шуток и издевательств (помните знаменитую "авторы языка С и Unix признались, что разыграли мир". Более того язык, специально заточенный под одну машину — PDP/11.
Дальнейшая судьба хорошо известна, чтобы о ней писать.
3. Windows. Какая-то странная графическая оболочка для MS-DOS. Прозябает 5 лет , о ней никто толком ничего не знает и никто всерьез не интересуется. О том, что она может составить конкуренцию хоть в чем-то OS/2 , и речи быть не может
Вспыхивает в 1990 году и ярко горит до сих пор.
Должен, конечно, привести и те примеры, которые в мою схему не укладываются.
Главный — конечно, сам IBM PC. При рождении ему прочили блестящее будущее, так оно и оказалось.
C++. Тоже при рождении ему предрекали, что он заменит С, так и вышло. Но тут вопрос спорный, в некотором смысле С++ — это просто новая версия С (я понимаю все неточность и даже неверность этого утверждения в строгом смысле этого слова), но по большому счету это так. Кстати, при рождении С++ иногда называли "С с классами".
Интересно, это действительно закономерность или я просто сгруппировал известные мне примеры искусственно ? Кто может привести еще примеры pro/contra ? Только просьба — говорить о вещах обще-ИТ значимости, а не об узкоспециализированных, там может быть иначе. И вторая просьба — не упоминать те случаи, когда предыдущей аналогичной технологии попросту не было. CD-ROM, к примеру.
Если это действительно закономерность, то философский вопрос — в чем причина ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если что-то при рождении своем дружно рассматривалось как новое слово, как полный переворот в ИТ — судьба этого была плачевна. А вот то, что при рождении все дружно ругали — побеждало.
Мне кажется, распространённость не противоположна расхваливанию, а просто ортогонально. Получает распространение то, что в первую очередь "работает", и уже во вторую — "удобно". Хотя подход этт может и сильно отличаться от того, как считается делать "правильным".
Иными словами, если ребята взяли и на C написали новую ОС, кросплатформенную, ставшую потом достаточно популярной — популярность самого языка возрастёт. А если на Аде ничего такого интересного написано не было — то и не стала она популярной.
PD>1. Паскаль.... В середине 80-х вспыхивает фейерверком и не погас до сих пор.
Хм, а где это он "не погас"? Да, на территории пост-СССР он ещё как-то тлеет, из-за наличия халявного дельфи. Но не более того.
PD>Должен, конечно, привести и те примеры, которые в мою схему не укладываются. PD>Главный — конечно, сам IBM PC. При рождении ему прочили блестящее будущее, так оно и оказалось.
Прочили? По-моему, IBM сам не верил в успех своего детища.
PD>Если это действительно закономерность, то философский вопрос — в чем причина ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я тут в очередной раз с адептами .Net схватился. Вообще говоря, занятные они люди. Уверовали в очередную панацею, и теперь все, тчо хоть какую-то критику этой панацеи представляет собой — вызывает реакцию, похожую на реакцию мусульман на карикатуры на пророка Мухаммеда
PD>Сколько я этих панацей на своем веку видел, и где они сейчас...
Ты одного понять не можешь. Никто не старается придумать панацею.
Стараются придумать решение, которое будет достаточно хорошо в большинстве случаев. Чувствуешь разницу?
Если для твоего конкретного случая общее решение не годится и у тебя есть объективные факты, которые это подтверждают — то сделай свое. Никто же не запрещает.
PD>Вчера задумался на эту тему, и вдруг неожиданно даже для себя пришел к выводу, меня поразившему. Вот он.
PD>Если что-то при рождении своем дружно рассматривалось как новое слово, как полный переворот в ИТ — судьба этого была плачевна. А вот то, что при рождении все дружно ругали — побеждало.
PD>Иными словами, законный принц — наследник престола его никогда не получал. Престол доставался гадкому утенку, выросшему в нищете и на задворках.
Ну дык .NET и так ругают все кому не лень . А то, что M$ его хвалит — так ему и положено, как автору "гадкого утенка".
Вот видишь — ты сам предсказал дот-нету блестящую судьбу
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вчера задумался на эту тему, и вдруг неожиданно даже для себя пришел к выводу, меня поразившему. Вот он. PD>Если что-то при рождении своем дружно рассматривалось как новое слово, как полный переворот в ИТ — судьба этого была плачевна. А вот то, что при рождении все дружно ругали — побеждало.
PD>Вот примеры принцев
PD>1. Алгол-60. Единственный термин из ИТ, которое я слышал, до того, как начал заниматься программированием (в 20 лет) — алгол. У меня книга до сих пор лежит где-то с названием "Универсальный язык программирования Алгол-60" И даже какой-то научно-фантастический роман припоминаю, где две внеземные цивилизации друго с другом на алголе объясняются . А уж в том. что он презренный Фортран заменит, никто и не сомневался. PD>Помер.
С другой стороны от послужил родоначальником целой линейки языков. Pascal и C больше алголоподобные, сем фортраноподобные... Могу ошибаться, но мне кажется, что структурное программирование (и прездение к goto) это наследие алгола. Когда мне попалась книга: алгоритмы на языке Algol, линейная алгебра, то при знании паскаля никаких проблем с чтением не кода не возникло. Алгол был жив достаточно продолжительное время, а потом на смену ему пришли новые средства. Алгол был первой ласточкой
PD>4. Ада. Новое слово. Международный конкурс. В СССР немедленно выпускают несколько книг (а в то время книги издавать не спешили). Заменит все языки. Впитала в себя лучшие свойства всех предыдущих языков. PD>Скорее мертва чем жива.
Generic-и в Ada входновили Страуструпа на введение шаблонов в С++. На Ada оказало клияние то, что этот проект финансировался военными ведомствами США. Сейчас потребность в Ada программистах высокая, но большая часть проектов идут под грифом "секретно" и туда даже американцев с улицы не берут. Что Ada мертва я бы не говорил, например этот проект. А сейчас лично у меня наметился всплеск активности: все чаще и чаще встречаются программисты, имеющие опыт работы с Ada.
PD>5. Пролог. Основа японского проекта ЭВМ 5 поколения. Шуму до потолка. "Вызов Японии миру". PD>Где этот вызов и где пролог ?
Вчера перечитывал Братко
PD>6. Ява (да простят меня ее сторонники, я вовсе не хочу их задеть.) Опять то же, язык, который должен вытеснить и Паскаль, и С++. PD>Жив вполне. Но не вытеснил.
Вытеснять что либ вообще не гуманно... Либо само умрет, либо нет.
PD>А вот гадкие утята.
PD>1. Паскаль. Язык созданный Виртом, в общем-то не для реального использования, а скорее как демонстрация того, каким должен быть язык. Около 10 лет (могу ошибиться, но примерно так) находится на задворках программистского мира. У меня лежит дома десятка полтора книг по Фортрану того времени и одна жалкая брошюра по Паскалю. Никто его всерьез не воспринимает. PD>В середине 80-х вспыхивает фейерверком и не погас до сих пор.
Хм... Д. Кнут в 1979 для системы литературного программирвоания (TANGLE+WEAVE) на которой будет позже реазизован TeX выбирает паскаль. В силу того, что компилятор паскаля есть почти на каждой ЭВМ. Pascal создавался для обучения и использовался в процессе обучения.
PD>3. Windows. Какая-то странная графическая оболочка для MS-DOS. Прозябает 5 лет , о ней никто толком ничего не знает и никто всерьез не интересуется. О том, что она может составить конкуренцию хоть в чем-то OS/2 , и речи быть не может PD>Вспыхивает в 1990 году и ярко горит до сих пор.
Тут было просто хорошее финансовое вливание
PD>Если это действительно закономерность, то философский вопрос — в чем причина ?
Ну... как я понимаю, есть несколько богатых буратино, которые вкладывают деньги. И их решения очень влияют на развитие IT. Плюс много зависит от того, как карта ляжет... Да и ругают не все, а то, что выходит на некий уровень популярности. И чем больше ругают, тем больше фанатики того или иного средства пытаются его улучшить. Диалектика.
Здравствуйте, Дарней, Вы писали:
PD>>Иными словами, законный принц — наследник престола его никогда не получал. Престол доставался гадкому утенку, выросшему в нищете и на задворках.
Д>Ну дык .NET и так ругают все кому не лень . А то, что M$ его хвалит — так ему и положено, как автору "гадкого утенка". Д>Вот видишь — ты сам предсказал дот-нету блестящую судьбу
Да бога ради. Может, так и будет. Меня тенденция больше сама по себе интересует.
Здравствуйте, Mystic, Вы писали:
M>С другой стороны от послужил родоначальником целой линейки языков. Pascal и C больше алголоподобные, сем фортраноподобные...
Pascal — безусловно. а С — не очень. Но ввобще верно.
>Могу ошибаться, но мне кажется, что структурное программирование (и прездение к goto) это наследие алгола. Когда мне попалась книга: алгоритмы на языке Algol, линейная алгебра
. Любимая книга моей молодости.
M>Generic-и в Ada входновили Страуструпа на введение шаблонов в С++. На Ada оказало клияние то, что этот проект финансировался военными ведомствами США. Сейчас потребность в Ada программистах высокая, но большая часть проектов идут под грифом "секретно" и туда даже американцев с улицы не берут. Что Ada мертва я бы не говорил, например этот проект. А сейчас лично у меня наметился всплеск активности: все чаще и чаще встречаются программисты, имеющие опыт работы с Ada.
ИМХО ты все же смешиваешь судьбу изделия как такового и его влияние на все остальное. Я только о первом говорил.
PD>>5. Пролог. Основа японского проекта ЭВМ 5 поколения. Шуму до потолка. "Вызов Японии миру". PD>>Где этот вызов и где пролог ? M>Вчера перечитывал Братко
M>Хм... Д. Кнут в 1979 для системы литературного программирвоания (TANGLE+WEAVE) на которой будет позже реазизован TeX выбирает паскаль. В силу того, что компилятор паскаля есть почти на каждой ЭВМ. Pascal создавался для обучения и использовался в процессе обучения.
Да. В университетах (не наших) он и тогда был популярен. В промышленности — пркатически не использовался.
PD>>3. Windows. Какая-то странная графическая оболочка для MS-DOS. Прозябает 5 лет , о ней никто толком ничего не знает и никто всерьез не интересуется. О том, что она может составить конкуренцию хоть в чем-то OS/2 , и речи быть не может PD>>Вспыхивает в 1990 году и ярко горит до сих пор.
M>Тут было просто хорошее финансовое вливание
Ну что в лоб, что по лбу. Причины разные бывают, а результат один. Кстати, неужели IBM мало денег вложила в OS/2 ?
PD>>Если это действительно закономерность, то философский вопрос — в чем причина ?
M>Ну... как я понимаю, есть несколько богатых буратино, которые вкладывают деньги.
"C" вместе с Unix не проходят. Делались чуть ли не на энтузиазме.
Думаю обобщить случаи не получится.
Не стал бы я сравнивать Algol 68
с амбициозным японским проектом компьютеров 5-го поколения.
Algol 68 кстати, критиковали.
Да и в успех японцев тоже верили только законченные оптимисты.
Но в целом может быть не ругают только то, что никому не интересно.
В этом случае слышны только положительные слова создателей.
То что интересно и чем реально пользуются, всегда будут и ругать и хвалить...
PD>6. Ява (да простят меня ее сторонники, я вовсе не хочу их задеть.) Опять то же, язык, который должен вытеснить и Паскаль, и С++. PD>Жив вполне. Но не вытеснил.
В отношении Жабы можно сказать вот что. Во-первых она провалилась в том виде, в котором ее изначально пытались внеднять — аплеты, софт на клиентских машинах, устройствах (про J2ME не будем сейчас). А всплыла наоборот на больших машинах в виде апп-сервером. Опять же, кто мог это предположить в 95-м? То есть смерть в первоначальном виде и реинкарнация в том, где ее никто не ждал.
PD>Интересно, это действительно закономерность или я просто сгруппировал известные мне примеры искусственно ? Кто может привести еще примеры pro/contra ? Только просьба — говорить о вещах обще-ИТ значимости, а не об узкоспециализированных, там может быть иначе. И вторая просьба — не упоминать те случаи, когда предыдущей аналогичной технологии попросту не было. CD-ROM, к примеру.
PD>Если это действительно закономерность, то философский вопрос — в чем причина ?
А причина в том, что один человек (одна группа людей) не могут оценить весь мир, всю сложность, которая поджидает новую технологию (язык) в жизни. Слишком сложная система. И в итоге, наверное, практически непредсказуемая. Тут и готовность разработчиков, и коммеческий сектор и техника и нужность пользователям и отсутствие альтернатив (которые, как правило, оказываются уже есть!!!). В итоге выживает то, вокруг чего сразу при рождении формируется какое-то сообщество, которое будет развивать потихоньку данную технологию в нужную ЖИЗНИ сторону. Сейчас та же Жаба развивается благодаря тому, что есть www.jcp.org, что есть обсуждение, есть развитие через целое сообщество.
Д>Ну дык .NET и так ругают все кому не лень . А то, что M$ его хвалит — так ему и положено, как автору "гадкого утенка". Д>Вот видишь — ты сам предсказал дот-нету блестящую судьбу
6 лет как предсказывают судьбу. Когда же??? Когда же появится софт на нем? Либо у нас на клиентских машинах, либо на серверах? Я пока только вижу (невооруженным взглядом конечно), то что его применяют на небольших веб-проектах. Те, кто только на Макрософт-технологиях давно сидит. Вот и все.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Ну... как я понимаю, есть несколько богатых буратино, которые вкладывают деньги.
PD>"C" вместе с Unix не проходят. Делались чуть ли не на энтузиазме.
Вот вот. Тут мой знакомый сказал фразу "делали не для денег, а что работало". Видать софтостроение чем-то похож на биатлон. Смешали несмешиваемое. Или надо зарабатывать (делать на один раз) или надо делать что-то чтобы работало, но это долго и на таком не заработать денег. Я конечно утрирую.
PD>Если что-то при рождении своем дружно рассматривалось как новое слово, как полный переворот в ИТ — судьба этого была плачевна. А вот то, что при рождении все дружно ругали — побеждало.
Ну это не показатель. Таких аналогий можно дофига привести (вспомнить хотя бы нашумевший текстик про то, что если создатель с бородой — то язык удачный, если без бороды — нет).
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Главный — конечно, сам IBM PC. При рождении ему прочили блестящее будущее, так оно и оказалось.
Не совсем. На самом деле для IBM PC не был серьёзым проектом. Его делали "до кучи" -- типа другие делают PC, ну и нам нужно что-то такое сбацать.
PD>C++. Тоже при рождении ему предрекали, что он заменит С, так и вышло. Но тут вопрос спорный, в некотором смысле С++ — это просто новая версия С (я понимаю все неточность и даже неверность этого утверждения в строгом смысле этого слова), но по большому счету это так. Кстати, при рождении С++ иногда называли "С с классами".
Стоит вспомниь, что C# и Java тоже принадлежат генеалогическому дереву C. Мне кажется, что это одна из основ успехов этих языков.
PD>Интересно, это действительно закономерность или я просто сгруппировал известные мне примеры искусственно ? Кто может привести еще примеры pro/contra ? Только просьба — говорить о вещах обще-ИТ значимости, а не об узкоспециализированных, там может быть иначе. И вторая просьба — не упоминать те случаи, когда предыдущей аналогичной технологии попросту не было. CD-ROM, к примеру.
Fortran. Когда фон Нейману показали проект, он сказал в ответ что-то нецензурное -- типа, мы здесь программисты, а не машинистки.
PD>Если это действительно закономерность, то философский вопрос — в чем причина ?
По моему, во многих случаях причина просматривается чётко -- firmware или committeeware против authorware.
Комитет Сальериевичей сливает одному Моцарту вчистую.
Здравствуйте, denis_krg, Вы писали:
_>6 лет как предсказывают судьбу. Когда же??? Когда же появится софт на нем? Либо у нас на клиентских машинах, либо на серверах? Я пока только вижу (невооруженным взглядом конечно), то что его применяют на небольших веб-проектах. Те, кто только на Макрософт-технологиях давно сидит. Вот и все.
Ну во первых, не 6 лет а 4 года.
Во вторых, никто не станет просто так бросаться и использовать новые платформы для давно существующих десктопных продуктов. Инерция мышления слишком велика. Во многих из крупных контор даже STL не используют, чего уж там говорить о новом языке
У меня из .NET софта сейчас имеется VS, Together, Reflector, тулкит для видеокарты. Тот же самый янус, наконец
Ну а что касается веб-проектов, то здесь ты вообще очень крупно ошибаешься.
Здравствуйте, Шахтер, Вы писали:
Ш>Не совсем. На самом деле для IBM PC не был серьёзым проектом. Его делали "до кучи" -- типа другие делают PC, ну и нам нужно что-то такое сбацать.
Насколько я помню, было иначе. IBM при появлении персоналок их просто проигнорировала. Дескать, что нам мелочами заниматься. Кончилось это тем, что коммивояжеры Apple начали продавать их персоналку сотрудникам IBM в штаб-квартире IBM Тогда IBM и решила срочно (за полгода) свою выпустить.
По крайней мере, такая легенда существует.
PD>>C++. Тоже при рождении ему предрекали, что он заменит С, так и вышло. Но тут вопрос спорный, в некотором смысле С++ — это просто новая версия С (я понимаю все неточность и даже неверность этого утверждения в строгом смысле этого слова), но по большому счету это так. Кстати, при рождении С++ иногда называли "С с классами".
Ш>Стоит вспомниь, что C# и Java тоже принадлежат генеалогическому дереву C. Мне кажется, что это одна из основ успехов этих языков.
Интересная мысль.
PD>>Интересно, это действительно закономерность или я просто сгруппировал известные мне примеры искусственно ? Кто может привести еще примеры pro/contra ? Только просьба — говорить о вещах обще-ИТ значимости, а не об узкоспециализированных, там может быть иначе. И вторая просьба — не упоминать те случаи, когда предыдущей аналогичной технологии попросту не было. CD-ROM, к примеру.
Ш>Fortran. Когда фон Нейману показали проект, он сказал в ответ что-то нецензурное -- типа, мы здесь программисты, а не машинистки.
PD>>Если это действительно закономерность, то философский вопрос — в чем причина ?
Ш>По моему, во многих случаях причина просматривается чётко -- firmware или committeeware против authorware. Ш>Комитет Сальериевичей сливает одному Моцарту вчистую.
Вот как навалимся всем миром,
Нам одиночки не нужны!
И станем все одним Шекспиром
Не зря у нас усе равны.
M>>С другой стороны от послужил родоначальником целой линейки языков. Pascal и C больше алголоподобные, сем фортраноподобные...
PD>Pascal — безусловно. а С — не очень. Но ввобще верно.
У нас в универе книжка по Схеме есть. Там во вступлении идет табличка — разделение языков. Паскаль и С уверенно помещены в ветку "Algol Family" ((ну и соответственно их последователи — Модулы, Явы, С++ и С#)
Здравствуйте, Mamut, Вы писали:
M>У нас в универе книжка по Схеме есть. Там во вступлении идет табличка — разделение языков. Паскаль и С уверенно помещены в ветку "Algol Family" ((ну и соответственно их последователи — Модулы, Явы, С++ и С#)
M>Все остальное — в Lisp Family
Эт. они упрощают сильно. Забыли про Fortran, ISWIM, ML, APL и др.
Причина проста. Люди не умеют сознательно создавать что-то новое и полезное. Миллиарды вкладываются в пустышки. Прогресс обеспечивается "гадкими утятами", которые, по большей части, случайно или как раз благодаря отсутствию этих миллиардов и посасыванию в желудке находят эффективные решения.
Идея такого сравнения конечно интересна, но чем большая популярность у языка/технологии, тем больше его/ее ругают.
На данный момент в IT не стоит упускать из виду маркетинговую составляющую (которая, конечно, рекламирует не что попало, а панацею от всех бед). Если раньше заказчик зачастую был более информирован положением дел, то теперь лишь знает слова бэйсик и дотнет, которые красиво мигали в банерах, про которые он как-то читал в газете или слышал от знакомого. Так и становиться технология популярной, что непременно вызывает увеличение объема ругани в ее адрес.
Здравствуйте, ie, Вы писали:
PA>>http://www.levenez.com/lang/history.html ie>А что это интересно из Ruby в C#2.0 попало?
Аналогично, .
Надо Влада с eao197 спросить.
Пальцем в небо: анонимные методы? Уж точно не generic'и.
Здравствуйте, Programmierer AG, Вы писали:
PA>Пальцем в небо: анонимные методы? Уж точно не generic'и.
Анонимные методы вряд ли, т.к. похожие на них code block в Ruby были заимствованны из Smalltalk. Да и синтаксически сильно отличаются.
Мое предположение -- ключевое слово yield и partial types (т.к. в Ruby все типы по определению открыты для дальнейшего расширения в других местах программы).
Вот только не знаю, были ли такие штуки в C# изначально, или же добавились к C# 2.0.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
PA>>Пальцем в небо: анонимные методы? Уж точно не generic'и.
E>Мое предположение -- ключевое слово yield и partial types (т.к. в Ruby все типы по определению открыты для дальнейшего расширения в других местах программы).
О! Оба пункта появились в C# 2.0.
Здравствуйте, Шахтер, Вы писали:
Ш>По моему, во многих случаях причина просматривается чётко -- firmware или committeeware против authorware.
Ш>Комитет Сальериевичей сливает одному Моцарту вчистую.
+1
Причем, это подтверждается еще и тем, что когда C++ стал переходить из authorware в committeeware, то его состояние стало постепенно...
Но и в самом authorware так же есть свои закономерности, которые логикой не объяснить
Но по крайней мере становится понятно, почему Lisp до сих пор многим нравится -- у него не было другого выбора
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mamut, Вы писали:
M>У нас в универе книжка по Схеме есть. Там во вступлении идет табличка — разделение языков. Паскаль и С уверенно помещены в ветку "Algol Family" ((ну и соответственно их последователи — Модулы, Явы, С++ и С#)
M>Все остальное — в Lisp Family
Шутку оценил, но если серьезнее, то они смешали понятие "языки т.н. арифметического типа" с понятием "алголоподобные языки".
Здравствуйте, eao197, Вы писали:
E>Но и в самом authorware так же есть свои закономерности, которые логикой не объяснить
E>Причем, это подтверждается еще и тем, что когда C++ стал переходить из authorware в committeeware, то его состояние стало постепенно...
Секрет в другом:
Здравствуйте, Programmierer AG, Вы писали:
E>>Причем, это подтверждается еще и тем, что когда C++ стал переходить из authorware в committeeware, то его состояние стало постепенно... PA>Секрет в другом:
Здравствуйте, Programmierer AG, Вы писали:
PA>Секрет в другом: PA>
Ну вот, все и стало на свои места. Закономерность на самом деле странная, но работает.
Меня другое пугает -- я вот так же велосипеды изобретать люблю. Но при этом не только без усов и бороды, но еще и лысый... Пора с изобретательством завязывать, все равно толку не выйдет...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Причем, это подтверждается еще и тем, что когда C++ стал переходить из authorware в committeeware, то его состояние стало постепенно...
Да, есть такое. Мне кажется, если что и убьёт C++, то это комитет по стандартизации.
По счастью, пока там сидит Страуструп и бьёт особо ретивых по рукам указкой.
Здравствуйте, Programmierer AG, Вы писали:
PA>Здравствуйте, Programmierer AG, Вы писали:
E>>>Причем, это подтверждается еще и тем, что когда C++ стал переходить из authorware в committeeware, то его состояние стало постепенно... PA>>Секрет в другом:
PA>Последняя надежда C++ — Саттер: PA>
Нет, это не надежда. Усы -- к дурной славе (я думаю C++/CLI).
PA>>Последняя надежда C++ — Саттер: E>На самом деле -- это не надежда, а приговор.
Ну, хотя бы популярность сохранит, а дурная слава — черт с ней . А о C++/CLI Шахтер верно подметил. Страшный трактор. Это же надо было додуматься — усложнить C++ в 2 раза.
Здравствуйте, eao197, Вы писали:
E>Меня другое пугает -- я вот так же велосипеды изобретать люблю. Но при этом не только без усов и бороды, но еще и лысый... Пора с изобретательством завязывать, все равно толку не выйдет...
Лысый — это хорошо, посмотри внимательно. И вывод неправильный — надо бороду срочно отпускать, а не изобретательство бросать .
Здравствуйте, Programmierer AG, Вы писали:
PA>Лысый — это хорошо, посмотри внимательно. И вывод неправильный — надо бороду срочно отпускать, а не изобретательство бросать .
Да, это мысль! Только хлопотное это дело (пару раз пытался), да и жене не нравится.
Ладно, постараемся стать исключением из правила
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Со всем бредом желания спорить нет, отмечу только Моцарта и Сальери.
При жизни последний был знаменитым, богатым и успешным. Оставил в музыке большой след — в первую очередь в виде плеяды блистательных учеников — Бетховен, Лист и Шуберт (может ты о них слышал краем уха? Хотя бы об одном из них?). Сына Моцарта учил мызыке, кстати, тоже он.
Здравствуйте, eao197, Вы писали:
E>Мое предположение -- ключевое слово yield и partial types (т.к. в Ruby все типы по определению открыты для дальнейшего расширения в других местах программы).
Programming-language buffs will be pleased to know that the keyword yield was chosen to echo the yield function in Liskov's language CLU, a language that is over 20 years old and yet contains features that still haven't been widely exploited by the CLU-less
E>Вот только не знаю, были ли такие штуки в C# изначально, или же добавились к C# 2.0.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>yield: ANS>
ANS>Programming-language buffs will be pleased to know that the keyword yield was chosen to echo the yield function in Liskov's language CLU, a language that is over 20 years old and yet contains features that still haven't been widely exploited by the CLU-less
Я помнил, что когда читал доку по Ruby, то про yield говорилось, что он был откуда-то взят. Но раз на схеме была нарисована стрелочка от Ruby к C#, а не от CLU, то...
И на той схеме от CLU показан только один наследник -- Ruby.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я тут в очередной раз с адептами .Net схватился.
Это ты зря.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это ты зря.
Ну а что же еще делать, когда они сотворили себе кумира и всякие попытки поставить под сомнение хоть один догмат встречают в штыки :- И добро бы я именно бога отрицал, а то ведь скажешь — "ну не верю я , что он превратил вино в воду, химию все же я знаю, не получится" — и все, анафема троекратная.
А впрочем, может ты и прав. На фанатиков логикой действовать — не получается.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а что же еще делать, когда они сотворили себе кумира и всякие попытки поставить под сомнение хоть один догмат встречают в штыки :- И добро бы я именно бога отрицал, а то ведь скажешь — "ну не верю я , что он превратил вино в воду, химию все же я знаю, не получится" — и все, анафема троекратная.
PD>А впрочем, может ты и прав. На фанатиков логикой действовать — не получается.
Демагогия detected. Зачем называть оппонентов фанатиками?
На самом деле, ты сам не хочешь понять одной простой вещи. Твой подход к повсеместной борьбе за производительность — это точка зрения, которой уже добрых лет тридцать будет. И еще в те времена она доказала свою практическую несостоятельность. А ты здесь преподносишь замшелые предрассудки, как новейшее откровение
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а что же еще делать, когда они сотворили себе кумира и всякие попытки поставить под сомнение хоть один догмат встречают в штыки
/Шепотом/ Ты только в сторону Nemerle ничего не говори... Эта трава еще ядренее C# будет...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>На самом деле, ты сам не хочешь понять одной простой вещи. Твой подход к повсеместной борьбе за производительность — это точка зрения, которой уже добрых лет тридцать будет. И еще в те времена она доказала свою практическую несостоятельность. А ты здесь преподносишь замшелые предрассудки, как новейшее откровение
What is the difference between very good programmers and excellent programmers? I think it’s only one single thing that makes the difference between excellent programmers and the others, and that’s the ability to “tie the knot”. But let me explain first…
…When you are able to abstract your problem as far as possible, you are a very good programmer; but if you are able to abstract your problem in a way it is most efficient for the machine, you have become an excellent programmer.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>…When you are able to abstract your problem as far as possible, you are a very good programmer; but if you are able to abstract your problem in a way it is most efficient for the machine, you have become an excellent programmer. E>[/q]
чтобы научиться наиболее эффективно абстрагироваться, нужно сначала научиться просто абстрагироваться. А вот с этим у товарища как раз серьезные проблемы.
Здравствуйте, Дарней, Вы писали:
Д>На самом деле, ты сам не хочешь понять одной простой вещи. Твой подход к повсеместной борьбе за производительность — это точка зрения, которой уже добрых лет тридцать будет. И еще в те времена она доказала свою практическую несостоятельность. А ты здесь преподносишь замшелые предрассудки, как новейшее откровение
Ложь. Это очень наивная трактовка. На самом деле доказала свою несостоятельность несвоевременная борьба за производительность и преждевременое разрушение дизайна в угоду оной. Всегда побеждал и побеждает принцип оценки системы как целого. В рамки такого подхода и вписывается знаменитое "premature optimization is root of evil". Ключевое слово здесь — premature, а не optimization. Последнее же совершенно свободно заменяется любым другим, например:
— "premature management is root of evil";
— "premature object orientation is root of evil";
— "premature debugging is root of evil";
— "premature payment is root of evil";
— "premature smoking and relaxing are roots of evil";
— "premature flaming is root of evil";
— "premature RSDN-ing is root of evil" (О! Я застолблю себе авторство?!).
Продолжить?
А вот теперь подумай: откуда возьмётся понимание этого принципа, если воспитывать народ в духе: "ресурс больше не ресурс"? Только не забудь ещё, что ограниченность ресурсов это вообще фундаментальная причина любого системостроения.
Ну? Гонг! Думаем!!!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А впрочем, может ты и прав. На фанатиков логикой действовать — не получается.
А это невозможно по определению. М-м-м... "чудный новый мир" — вокруг этой игрушки знаешь, сколько людей бошки сложили и ещё сложат?! Так что, контраргументация бесполезна by design. Ну хочется людям верить, что ресурсы компьютера больше не ресурсы — да пусть верят на здоровье. Ну хочется верить, что сила слова зависит от синтаксического сахара — да в добрый путь.
Меня одно успокаивает: похоже, что сама Microsoft голову терять не склонна, так что, всё не так уж и плохо. А что галдят те или иные адепты, да какая разница?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ложь. Это очень наивная трактовка. На самом деле доказала свою несостоятельность несвоевременная борьба за производительность и преждевременое разрушение дизайна в угоду оной.
А я о чем говорил?
<Далнейшее поскипано по причине полнейшей тривиальности>
Определённо верблюдов создал бог. Потому что верблюд — создание совершенное. Вот просто факты, смотрите сами:
Верблюд способен выносить диапазон температур от -20 до +50.
Верблюд способен 2 недели обходиться без воды и 2 дня без пищи.
Верблюд в условиях пустыни передвигается быстрее лошади: 80 — 90 км/в день.
Однако беговые верблюды развивают скорость до 40 км/ч.
Устройство ступни верблюда позволяет ему не тонуть в песке (она примерно как дно у бутылки).
Хотя тяга верблюда небольшая 50 — 60кг, но вес груза может быть в пределах от 200 до 500 килограммов (зависит от особи).
Верблюд может есть растения, которые не способно есть ни одно животное (напр. репейник, терний, верблюжья колючка).
Верблюдица по-арабски "нака". Нака — самый прекрасный комплимент для женщины. Часто употребляется в восточной поэзии.
Верблюжье молоко вообще очень полезно, и кроме того является средством повышения потенции у мужчин
Скафандры космонавтов утепляют верблюжьей шерстью.
Рекордная стоимость верблюда — 3.2 млн долларов.
Здравствуйте, Геннадий Васильев, Вы писали:
Я вообще не понимаю, что происходит. Уже не в первый раз наблюдается примерно следующая картина:
1. Некий участник форумов задает вроде невинный вопрос "а что это вот такое ...", или "а как сделать ...".
2. Затем он выдает какую-нибудь тезу типа "ну и отстой!"
3. В дискуссии о причинах такого мнения он всячески избегает давать прямые ответы на вопросы. Вместо этого он утверждает, что производительность — рулит.
4. На просьбы подкрепить свои бредни примерами приводятся а) очевидно некорректные либо б) откровенно неэффективные примеры. При этом подразумевается, что охаиваемая технология отстой потому, что не позволяет эти примеры реализовать.
5. От обсуждения этих примеров герой отказывается под разными предлогами — типа "там на самом деле были еще и другие требования", или "то, что вы такого не встречали, не значит, что этого не существует вообще, а стало быть, это — наиболее частый случай" и прочими маркетинговыми ходами
6. Будучи загнанным в угол, герой переходит к критике оппонентов: "вам главное — не истина, а меня опустить", "как вы можете воспитывать людей в духе 'ресурс больше не ресурс'" и прочему флейму.
Независимо от темы, данная картина повторяется с завидным постоянством.
Уважаемые участники дискуссий! Нет никакой связи между п.1. и п.6. Это извилистая тропа пеара, не более того.
Я не против оптимизаций. Я — за оптимизации! Обеими руками! Но почему-то самые ярые поклонники оптимизации приводят в качестве примеров как раз наиболее убогие способы "оптимизации". Потому, что при оптимизации, как и при разработке вообще, не стоит слепо следовать догмам. Думать надо всегда, творчески думать!
Вот про строки была дискуссия. Очень смешно. Оказалось, что известный эксперт и преподаватель WinAPI не знал, что в 90% в виндах строки все-таки оборудованы длиной. Поскольку он был воспитан на микроконтроллерах, где всю работу со строками надо было делать вручную, он и не искал этой информации. А трата четырех байт на длину, которая, быть может, и не понадобится, он до сих пор считает преступлением. Ок, нормально.
Теперь оказывается, что в мире ежедневно происходят страшные злоупотребления сериализацией. И все из-за того, что мировое зло борется за неэффективное использование ресурсов!
Особенно забавно, что в качестве примеров "неприменимости сериализации" приводятся либо высосанные из пальца задачи, либо задачи, которые решаются при помощи сериализации вполне эффективно. Более того, использование именно сериализации (как концепции упаковки данных во write-only поток) позволяет улучшить эффективность по сравнению с якобы эффективными решениями.
Да, я понимаю, в формате форумной мессаги трудно дать полное представление об огромном проекте. Я смотрю на задачу через "замочную скважину", и запросто могу не увидеть вполне весомых причин требовать произвольного позиционирования при переводе данных в хранимое представление. Ок, я не против. Я сам первым побегу использовать fseek если это будет неизбежно для достижения поставленной задачи. Но само то, что автору этого алгоритма нужно несколько попыток, чтобы все-таки найти источник этого требования, указывает на проблему и ее причину — выбор именно такого алгоритма не был обусловлен никакой настоящей причиной. Он просто был выбран за то, что автор счел его подходящим. Производительность вполне устроила, а архитектурная стройность, весь этот loose coupling и high cogesion в ТЗ не числились.
В итоге мы имеем противоборство между тупоконечниками и остроконечниками. Одни (и я в том числе) считают, что хорошая архитектура — the must, а производительность всегда можно дотюнить при необходимости. Другой лагерь почему-то считает нас транжирами, а эффективность — главным критерием софта. А уж какая там архитектура — дело второе.
Мы считаем, что хороша та программа, которая потребляет минимум концепций, а они — что та, которая потребляет минимум ресурсов.
Много лет рулили "эффективники", поскольку имеющихся ресурсов было крайне мало, и каждое улучшение эффективности давало офигенное преимущество для потребителя.
Теперь наступает перелом в "нашу" пользу, поскольку abstraction penalty неуклонно падает, ресурсов все больше, и самым дорогим ресурсом становится личное время разработчика. Можно представить себе этакую картину маслом: "архитектурщики" сгоняют "эффективников" в резервации, где те занимаются народными промыслами навроде плетения супербыстрых алгоритмов, запихиванием всего подряд в двенадцать регистров и прочими чудесами, медленно спиваясь от отсутствия настоящей работы.
Меня бы мучила совесть, не будь я уверен в том, что такого не произойдет. Никто не отменит эффективность, поскольку ресурсы кремния все-таки исчерпаемы. Вот только пути ее достижения изменятся, оставив за бортом не понявших этого (как меткие индейские стрелки вытеснили опытных лучников). Опять же, спрос на прикладные программы сейчас не удовлетворен и на 10% — посмотрите вокруг, уровень автоматизации просто никакой по сравнению с текущим уровнем достижений аппаратуры. Это означает, что даже самые нацеленные на эффективность методики не смогут жить без "архитектурных изысков", позволяющих распараллелить работу между многими разработчиками. То есть повторная используемость, тот самый loose coupling и high cohesion будут по прежнему рулить.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Выступления Дворкина выглядят не таким уж и "маркетингом", если не забывать, что програмист должен уметь оперировать разными абстракциями одновременно. В том числе — и близкими к железу понятиями. Иначе он никогда не поймёт, почему иногда loose coupling может навредить, несмотря на то, что, вроде бы, всё должно быть хорошо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я бы еще добавил, что средства разработки тоже очень сильно прогрессируют. На данный момент крайне редко встречаются специалисты, которые реально смогут написать ассемблерный код, работающий быстрее чем сгенеренный хорошим компилятором С++. Работать быстрее не в каком-то особом слуаче, а работать быстрее для любых входных данных и на большинстве целевых процессоров. (Хотя верит в свою способность сделать это чуть ли не каждый второй ). Причина сложности этой задачи вполне понятна — современный процессор слишком сложное устройство, существующее к тому же во многих разных вариантах. На быстродействие оказывает влияние не только сравнительная скорость работы команд, как в "старые добрые времена", но и наличие специализированных наборов команд, размер кэша, длина конвейера, качество работы модуля предсказания ветвлений, а так же всякие магические эффекты, наподобие replay (принципы работы которого, к тому же, старательно замалчивались). Все детали работы процессора просто не помещаются в голове одного человека, если он не сверх-гуру по архитектуре процессора. Но таких людей можно на пальцах пересчитать.
Но компиляторы — это еще цветочки. Уже сейчас наблюдается тенденция к применению кросс-модульного статического анализа для оптимизации, и дальше доля таких технологий будет расти. Благодаря этому автоматическая оптимизация сможет устранять многие виды abstraction penalty, которые не по зубам теперешним компиляторам.
Чтобы переплюнуть результаты применения таких технологий, нужно будет иметь очень мощный практический и теоретический багаж, и 99,9% программистов это будет просто не под силу. Да и просто не нужно.
Именно такой прогресс инструментов позволяет "ленивым программистам" (С) переложить как можную большую часть своей рутинной работы на автоматические инструменты. И это правильно, потому что правильный программист должен быть ленивым и умным. Ленивым — чтобы делать свою работу как можно проще. А умным — чтобы понимать, когда усложнить работу все-таки придется И нет ничего страшнее в нашей профессии, чем старательный невежда.
Здравствуйте, Дарней, Вы писали про оптимизирующие средства разработки,
Только я вот ну очень сомневаюсь, что найдётся оптимизирующий транслятор, который сможет изменить O(N^2) на O(log(N)). Или, скажем, сможет отключать проверки уровня доступа, которые присутствуют при открытии файлов.
А то, что abstraction penalty уменьшится — так это же очень хорошо! Теперь у нас пузырьковая сортировка вдвое быстрее вызываться будет! Кр-р-расота!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Только я вот ну очень сомневаюсь, что найдётся оптимизирующий транслятор, который сможет изменить O(N^2) на O(log(N)).
ну объясни мне, какое это имеет отношение к работе с указателями и ручному распределению памяти, которые (и только которые) наши гордые борцы за эффективность понимают под "оптимизацией"?
Здравствуйте, Дарней, Вы писали:
ГВ>>Только я вот ну очень сомневаюсь, что найдётся оптимизирующий транслятор, который сможет изменить O(N^2) на O(log(N)).
Д>ну объясни мне, какое это имеет отношение к работе с указателями и ручному распределению памяти, которые (и только которые) наши гордые борцы за эффективность понимают под "оптимизацией"?
Конкретное противопоставление O(N^2) и O(log(N)) — никакого. Но в свою очередь, ручное распределение памяти имеет к оптимизации наипрямейшее отношение.
И кстати, твоё утверждение про "...которые (и только которые)..." в корне не верно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Но в свою очередь, ручное распределение памяти имеет к оптимизации наипрямейшее отношение.
а что, оно поможет поменять сложность алгоритма с O(N^2) на O(log(N))?
ГВ>И кстати, твоё утверждение про "...которые (и только которые)..." в корне не верно.
Здравствуйте, Sinclair, Вы писали:
S>Много лет рулили "эффективники", поскольку имеющихся ресурсов было крайне мало, и каждое улучшение эффективности давало офигенное преимущество для потребителя. S>Теперь наступает перелом в "нашу" пользу,
Да, ничего не изменилось. Эффетивность такой же регулируемый компоент системы. Ни одна мая программа не тормозила на рассчетном обхеме информации ни 15 лет назад, ни сейчас. Просто раньше железо было просто никакое и решения создаваемые на его базе были очень примитивными.
Те кто понимал толк в архитектуре и тогда задумывались над ней. Причем со временем все больше, так как получали больший опыт. Но есть люди не способные следить за болшим количеством факторов одновременно. Вот они и выбрали в те времена простое решение — отбросить забуоту об архитектуре делая упор на эффективности.
Так как задачи тогда были очень простыми (в сделствии ограничений железа), то их неверная политика просто не была видна. Но со временем железо вырасло. Выросла и сложность задачь. Это привело к тому, что значимость архитекутры прилоежния резко возрасла. Но привычки не так просто сломать. У многих они превратились в образ мышления.
Так что кое в чем ты не прав. Обсудение этого вопроса как ни крути будет переодически переходить в обсуждение личностий. По сему наверно нужно просто прекратить это обсуждение. Сказано уже не мало. Каждый прочевший его сделает такие выводы какие сможет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
ГВ>>Но в свою очередь, ручное распределение памяти имеет к оптимизации наипрямейшее отношение.
Д>а что, оно поможет поменять сложность алгоритма с O(N^2) на O(log(N))?
Глупость detected: Почему ты думаешь, что тезис "ручное распределение памяти имеет к оптимизации наипрямейшее отношение" логически связан с "нет такого оптимизирующего транслятора, который преобразовал бы O(N^2) на O(log(N))"? Или упрощу: почему бузина в огороде связана с моральным обликом дядьки в Киеве? Только потому, что очень хочется приплести "ручное управление памятью" любой ценой и наехать на всех вокруг, чья точка зрения отличается от расхожей?
ГВ>>И кстати, твоё утверждение про "...которые (и только которые)..." в корне не верно.
Д>ок. пусть будет "прежде всего которые"
Перепишем утверждение:
ГВ>Только я вот ну очень сомневаюсь, что найдётся оптимизирующий транслятор, который сможет изменить O(N^2) на O(log(N)).
ну объясни мне, какое это имеет отношение к работе с указателями и ручному распределению памяти, прежде всего которые наши гордые борцы за эффективность понимают под "оптимизацией"?
А теперь я спрошу у тебя доказательство твоего утверждения. С чего ты взял, что "борцы за оптимизацию" прежде всего апеллируют к необходимости ручной работы с памятью?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Анонимные методы вряд ли, т.к. похожие на них code block в Ruby были заимствованны из Smalltalk. Да и синтаксически сильно отличаются.
Анонимные методы это практически наверняка ответ МС на анонимные классы Java, даже название похоже.
E>Мое предположение -- ключевое слово yield и partial types (т.к. в Ruby все типы по определению открыты для дальнейшего расширения в других местах программы).
Вот кстати истоки yield штука очень интересная. Корни ее определить я затрюдняюсь. Ни в одном из мейнстрим языков такого не было. Могу лишь предположить, что самый известный язык с yield все же не Руби, а Питон.
Что же касается partial types, то это никакие не открытые типы, это банальная возможность разместить один класс в нескольких файлах и ничего сверх того. Синтаксическое расширение это скорее extension methods в С# 3.0
E>Вот только не знаю, были ли такие штуки в C# изначально, или же добавились к C# 2.0.
Обе добавлены в 2.0.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Выступления Дворкина выглядят не таким уж и "маркетингом", если не забывать, что програмист должен уметь оперировать разными абстракциями одновременно. В том числе — и близкими к железу понятиями. Иначе он никогда не поймёт, почему иногда loose coupling может навредить, несмотря на то, что, вроде бы, всё должно быть хорошо.
Насчет loose coupling и пр. — верное замечание. Действительно, неоднократно подмечено, что подобный подход зачастую приносит кучу бенефитов. Но у нас у программистов как блин у верующих — любые хорошие концепции походя превращают в догмы, которые, разумеется, перестают хорошо работать, ибо их начинают ставить во главу угла, вместо реальных требований и приличиствующих месту абстракций.
Несмотря на то, что с выступлением Синклера я по большей части абсолютно согласен, я бы не рекомендовал подобные посты на прочтение "неподготовленным умам", ибо мы рискуем потерять еще несколько потенциальных спецов. Поставят тупо впереди телеги loose coupling, и прощай надежность и пр. весьма ценные факторы, без которых результат их труда будет иметь стоимость, стремящуюся к 0-лю...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Sinclair, Вы писали:
Д>Я бы еще добавил, что средства разработки тоже очень сильно прогрессируют. На данный момент крайне редко встречаются специалисты, которые реально смогут написать ассемблерный код, работающий быстрее чем сгенеренный хорошим компилятором С++.
Я уже неоднократно слышал эту чушь. Давайте я хоть раз озвучу ее правильно: на данный момент разработчики не имеют навыков писать оптимальный ассемблерный код, и поэтому когда пыжаться, зачастую проигрывают современным компиляторам С++ по эффективности кода. Разумеется, речь идет о задачах, на которых ассемблер уместен.
Так вот, матерый ассемблерщик дрючит все эти С++ и в хвост и в гриву. До сих пор. Достаточно посмотреть на выход компилятора — если бы это писал человек, я бы его уволил.
Д>И нет ничего страшнее в нашей профессии, чем старательный невежда.
Да нет, они не страшны, они отмирают сами по причине потери работы. Страшны догматики. Вот уж кто способен запудрить мозги, перевести кучи бабла и забыть выдать работающий результат...
Здравствуйте, Дарней, Вы писали:
ГВ>>Только я вот ну очень сомневаюсь, что найдётся оптимизирующий транслятор, который сможет изменить O(N^2) на O(log(N)).
Д>ну объясни мне, какое это имеет отношение к работе с указателями и ручному распределению памяти, которые (и только которые) наши гордые борцы за эффективность понимают под "оптимизацией"?
а ты напиши быструю сортировку "по месту", т.е. без дополнительного динамического выделения памяти на каждом шаге... тогда узнаешь, почему порой модифицированная пузырьковая работает не хуже.
Здравствуйте, Дарней, Вы писали:
ГВ>>Но в свою очередь, ручное распределение памяти имеет к оптимизации наипрямейшее отношение.
Д>а что, оно поможет поменять сложность алгоритма с O(N^2) на O(log(N))?
Эти нотации надо уметь оччень аккуратно читать и еще более быть аккуратным при применении к реальным N. На небольших N (до сотен и тысяч) это шаманство способно ввести в заблуждение неопытного читателя.
Видел тут не так давно показывали быструю сортировку на Хаскеле? Сложность алгоритма такая же как в классике, а реально работает медленнее пузырьковой. Сам догадаешься почему или подсказать?
Здравствуйте, vdimas, Вы писали:
V>Несмотря на то, что с выступлением Синклера я по большей части абсолютно согласен, я бы не рекомендовал подобные посты на прочтение "неподготовленным умам"
А "выступления Дворкина" рекомендовал бы?
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
V>Несмотря на то, что с выступлением Синклера я по большей части абсолютно согласен, я бы не рекомендовал подобные посты на прочтение "неподготовленным умам", ибо мы рискуем потерять еще несколько потенциальных спецов.
Вот-вот. Как раз деятели вроде Синклера, Вольфхунда или Влада почему-то часто забывают о том, что у них уже есть за плечами серьёзный опыт того же C++, а у тех, кто их выступления читает оного может и не быть.
Собственно, это-то и страшно в некоем стратегическом смысле — двусмысленные обоснования многих утверждений авторитетных деятелей. Вернее так: обоснования выглядят достаточно очевидными для говорящего, но совершенно непонятны внешнему наблюдателю, если тот не может адекватно представить контекст. Тем не менее, наблюдатель может повестись на авторитет и... получим в итоге неприятную картину. Рассосётся, конечно, со временем, куда деваться, но что-то уж больно хочется, чтобы это время было покороче — меньше шишек набьём.
Так что, к сожалению, с такой фигнёй придётся воевать и дальше...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Анонимные методы это практически наверняка ответ МС на анонимные классы Java, даже название похоже.
Не смешно. Явы еще на свете небыло когда в функциональных языках были аналоги анонимных методов. А название просто само напрашивалось. "Методы без имени".
AVK>Вот кстати истоки yield штука очень интересная. Корни ее определить я затрюдняюсь. Ни в одном из мейнстрим языков такого не было. Могу лишь предположить, что самый известный язык с yield все же не Руби, а Питон.
Я, кстати, ни одного такого языка не припомню. Где еще определение класса можно разбить на несколько файлов? Причем, заметь, не реализацию, а именно определение.
AVK> Синтаксическое расширение это скорее extension methods в С# 3.0
Вообще-то введение любой синтаксической конструкции является синтаксическим расширением. Это как бы смысл словосочетания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Эти нотации надо уметь оччень аккуратно читать и еще более быть аккуратным при применении к реальным N. На небольших N (до сотен и тысяч) это шаманство способно ввести в заблуждение неопытного читателя.
а кто здесь неопытный читатель?
V>Видел тут не так давно показывали быструю сортировку на Хаскеле? Сложность алгоритма такая же как в классике, а реально работает медленнее пузырьковой.
Это не имеет никакого отношения к обсуждаемой теме.
Здравствуйте, vdimas, Вы писали:
V>а ты напиши быструю сортировку "по месту", т.е. без дополнительного динамического выделения памяти на каждом шаге... тогда узнаешь, почему порой модифицированная пузырьковая работает не хуже.
Выбрать подходящий для данного случая алгоритм — это тоже одна из важных задач архитектора. Но это опять-таки не имеет никакого отношения к обсуждаемой теме. Re[5]: Вопрос вполне философский
Здравствуйте, vdimas, Вы писали:
V>Поставят тупо впереди телеги loose coupling, и прощай надежность и пр. весьма ценные факторы, без которых результат их труда будет иметь стоимость, стремящуюся к 0-лю...
А почему это loose coupling должен вдруг негативно влиять на надежность? Ты ничего не перепутал?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Глупость detected: Почему ты думаешь, что тезис "ручное распределение памяти имеет к оптимизации наипрямейшее отношение" логически связан с "нет такого оптимизирующего транслятора, который преобразовал бы O(N^2) на O(log(N))"?
Потому что я имел неосторожность ожидать от тебя логической связности твоих рассуждений. Теперь я понял, что это было глупостью с моей стороны
ГВ>А теперь я спрошу у тебя доказательство твоего утверждения. С чего ты взял, что "борцы за оптимизацию" прежде всего апеллируют к необходимости ручной работы с памятью?
Из того, что они пишут на форуме. Я так предполагаю, ты ведь сначала ознакомился с имеющимися материалами, прежде чем лезть в спор?
Здравствуйте, vdimas, Вы писали:
V>Так вот, матерый ассемблерщик дрючит все эти С++ и в хвост и в гриву. До сих пор. Достаточно посмотреть на выход компилятора — если бы это писал человек, я бы его уволил.
Такие "матерые ассемблерщики" давно уже сидят на разработке компиляторов и еще в некоторых специфических областях. Работают себе спокойно, и не флеймят на форумах, потому что знаю себе цену. А те, кто собираются дрючить С++ в хвост и гриву — это просто недоучки, которые не представляют себе реальной сложности задачи. Здесь на форуме таких уже много было, но ничего конкретного еще ни один не смог выдать.
V>Да нет, они не страшны, они отмирают сами по причине потери работы.
Кто ж их уволит, если они старательные? В любой конторе таких людей полно. Сидят себе, кропают килограммами код, в котором потом сам черт ногу сломит. А догматики попадаются очень редко. Мне только один встречался, так его через месяц и выпнули, потому что никакого реального результата он выдать не смог (С)
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Глупость detected: Почему ты думаешь, что тезис "ручное распределение памяти имеет к оптимизации наипрямейшее отношение" логически связан с "нет такого оптимизирующего транслятора, который преобразовал бы O(N^2) на O(log(N))"?
Д>Потому что я имел неосторожность ожидать от тебя логической связности твоих рассуждений. Теперь я понял, что это было глупостью с моей стороны
Нет, глупостью с твоей стороны на самом деле было то, что ты решил, что я обязан видеть в сообщениях других то и только то, что ожидаешь ты и ещё несколько авторов ФП.
На самом деле мой пост спровоцирован по большей части дискуссией Дворкина и Ко в теме "Каков глубокий смысл сериализации?". Там не было особого нажима на необходимость ручной работы с памятью. А вот рассуждения о необходимости своевременного анализа алгоритмов — были. Ну и как же мне было после столь яркой дискуссии, да ещё в теме, начатой Дворкиным, да ещё в которой раздаётся очередной демагогический вопль про сверхразумные средства разработки не вспомнить о сути указанной дискуссии?
Естественно, я понимаю, что я должен был стушеваться и замолчать. Священную корову ручного управления памятью, вокруг которой построено такое количество .Net-демагогии на самом деле лучше не трогать! Это же разве можно, лишить вас столь любимого аргумента? "Это же не можно!" (c)
ГВ>>А теперь я спрошу у тебя доказательство твоего утверждения. С чего ты взял, что "борцы за оптимизацию" прежде всего апеллируют к необходимости ручной работы с памятью?
Д>Из того, что они пишут на форуме. Я так предполагаю, ты ведь сначала ознакомился с имеющимися материалами, прежде чем лезть в спор?
Где конкретно? Ещё раз повторюсь — у меня такого впечатления не сложилось, следовательно, я ничего искать не обязан. Желаешь доказать своё утверждение — ссылки в студию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
V>>Эти нотации надо уметь оччень аккуратно читать и еще более быть аккуратным при применении к реальным N. На небольших N (до сотен и тысяч) это шаманство способно ввести в заблуждение неопытного читателя.
Д>а кто здесь неопытный читатель?
Например, ими могут оказаться студенты того же Павла Дворкина.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно, это-то и страшно в некоем стратегическом смысле — двусмысленные обоснования многих утверждений авторитетных деятелей. Вернее так: обоснования выглядят достаточно очевидными для говорящего, но совершенно непонятны внешнему наблюдателю, если тот не может адекватно представить контекст. Тем не менее, наблюдатель может повестись на авторитет и... получим в итоге неприятную картину. Рассосётся, конечно, со временем, куда деваться, но что-то уж больно хочется, чтобы это время было покороче — меньше шишек набьём.
Я лично этого не боюсь. Именно потому, что это форум, а не энциклопедия. Высказал мнение — неправильно поняли — подкорректировал.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Собственно, это-то и страшно в некоем стратегическом смысле — двусмысленные обоснования многих утверждений авторитетных деятелей. [...] S>Я лично этого не боюсь. Именно потому, что это форум, а не энциклопедия. Высказал мнение — неправильно поняли — подкорректировал.
Ну вот я как раз коррекцию и имею ввиду.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Нет, глупостью с твоей стороны на самом деле было то, что ты решил, что я обязан видеть в сообщениях других то и только то, что ожидаешь ты и ещё несколько авторов ФП.
Эк хитро завернул, шайтан Программы ты в том же стиле пишешь?
ГВ>На самом деле мой пост спровоцирован по большей части дискуссией Дворкина и Ко в теме "Каков глубокий смысл сериализации?". Там не было особого нажима на необходимость ручной работы с памятью. А вот рассуждения о необходимости своевременного анализа алгоритмов — были.
Эту тему я почти не читал. Мне по уши хватило хватило предыдущих флеймов, которые затевал Дворкин. Человек, который искренне верит, что строки в базе данных хранятся без длины — никогда не расскажет что-то интересное для меня.
Что касается своевременного анализа алгоритмов — это вещь конечно нужная, никто и не спорит. Главное только, поределиться, что такое "своевременный анализ". Если проект, к примеру, состоит в решении алгоритмически сложной задачи — с него и нужно начинать. Другой вопрос, что в индустрии такие задачи встречаются достаточно редко. А для обычной задачи выбор алгоритов — далеко не самая приоритетная задача.
ГВ>да ещё в которой раздаётся очередной демагогический вопль про сверхразумные средства разработки не вспомнить о сути указанной дискуссии?
это не демагогия, это факт. Ты разве не замечаешь изменений?
ГВ>Естественно, я понимаю, что я должен был стушеваться и замолчать. Священную корову ручного управления памятью, вокруг которой построено такое количество .Net-демагогии на самом деле лучше не трогать! Это же разве можно, лишить вас столь любимого аргумента? "Это же не можно!" (c)
ГВ>Где конкретно? Ещё раз повторюсь — у меня такого впечатления не сложилось, следовательно, я ничего искать не обязан. Желаешь доказать своё утверждение — ссылки в студию.
Почитай любой из предыдущих флеймов, которые он затеял.
Дарней,
Д>Мне искренне жаль этих несчастных. Боюсь, что большинству из них уже ничто не поможет.
Можете быть уверенными, "шаманство" с чиселкой N никого в ступор не поставит. На самом деле, указанное выше "шаманство" есть прямое следствие свойств полиномов и экспоненциальных функций.
Опять же, наряду с курсами по программированию также читаются курсы по теории сложности, где на первой же лекции демонстрируется, что при малых n (которые могут оказаться большими по отношению к практическим потребностям) более сложные (например, экспоненциальные) алгоритмы могут существенно выигрывать у менее сложных (например, полиномиальных). Часто упоминают про симплекс метод, который на практике работает хорошо, а теоретически имеет экспоненциальную сложность.
Так что относительно перспектив этих "несчастных" я бы так не горячился.
Здравствуйте, VladD2, Вы писали:
AVK>>Анонимные методы это практически наверняка ответ МС на анонимные классы Java, даже название похоже.
VD>Не смешно. Явы еще на свете небыло когда в функциональных языках были аналоги анонимных методов.
Ну и что? Когда делали C# 2.0 уже была. Речь то не о том, кто первый это придумал.
VD> А название просто само напрашивалось. "Методы без имени".
Inline methods, code block, expression blocks, lambda etc. Названий можно придумать море.
AVK>>Что же касается partial types, то это никакие не открытые типы, это банальная возможность разместить один класс в нескольких файлах и ничего сверх того.
VD>Я, кстати, ни одного такого языка не припомню. Где еще определение класса можно разбить на несколько файлов? Причем, заметь, не реализацию, а именно определение.
Википедия знает только C# 2.0. Как мне кажется, что то подобное было в Smalltalk, то там как таковых файлов исходников не было.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Можете быть уверенными, "шаманство" с чиселкой N никого в ступор не поставит. На самом деле, указанное выше "шаманство" есть прямое следствие свойств полиномов и экспоненциальных функций.
LCR>Опять же, наряду с курсами по программированию также читаются курсы по теории сложности, где на первой же лекции демонстрируется, что при малых n (которые могут оказаться большими по отношению к практическим потребностям) более сложные (например, экспоненциальные) алгоритмы могут существенно выигрывать у менее сложных (например, полиномиальных). Часто упоминают про симплекс метод, который на практике работает хорошо, а теоретически имеет экспоненциальную сложность.
LCR>Так что относительно перспектив этих "несчастных" я бы так не горячился.
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Так что относительно перспектив этих "несчастных" я бы так не горячился.
Хз. Пока что видно нежелание вести поиск оптимальных алгоритмов: вместо этого защищаются уже принятые решения, и для них сочиняются оправдания. Ну вот как в последнем случае, на протяжении нескольких постов подразумевался тезис "fseek необходим в данной задаче для уменьшения объема хранимых данных", несмотря на то, что
— был предложен алгоритм с теми же требованиями к объему и памяти, но без fseek (так что вопрос необходимости должен был отпасть сразу же)
— было предложено поискать пути дальнейшей оптимизации объема при помощи алгоритмов потоковой компрессии
Увы, оба аргумента были проигнорированы. Я искренне надеюсь, что в реальной жизни ученики все же будут думать головой, и подбирать алгоритм под условия, а не придумывать оправдания для алгоритма.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair,
LCR>>Так что относительно перспектив этих "несчастных" я бы так не горячился. S>Я искренне надеюсь, что в реальной жизни ученики все же будут думать головой, и подбирать алгоритм под условия, а не придумывать оправдания для алгоритма.
Собственно я уже не первый раз сталкиваюсь с (совершенно некорректной) интерполяцией вашего взаимного непонимания (по довольно специфичным вопросам) на качество обучения. Я бы не хотел, чтобы здесь все думали, будто курс программирования представляет собой копирование фактов из сознания учителя в сознания учеников с принудительным оверрайтом прежнего содержимого.
В реальной жизни ученики думают головой, продолжают учиться, и многие шагнули дальше своего учителя, но до сих пор благодарны ему (учителю). Так и должно быть, я считаю.
Здравствуйте, AndrewVK, Вы писали:
V>>Несмотря на то, что с выступлением Синклера я по большей части абсолютно согласен, я бы не рекомендовал подобные посты на прочтение "неподготовленным умам"
AVK>А "выступления Дворкина" рекомендовал бы?
Он же преподаватель. Для первых 2-х лет изучения программирования — очень даже. Ведь никто не говорит о том, что эффективность нынче не нужна как никто не говорит о том, что исчезли ограничения из реальных систем. Мы ведь всего-навсего обсуждаем вопрос необходимости гонки за эффективностью в каждом конкретном случае и умения выявлять ограничения (то бишь не искать их там, где их нет).
Я ведь почему порой не согласен с противниками Дворкина:
— читая их посты, создается впечатления некоего "разрыва" м/у традиционной программисткой наукой и "новыми веяниями" (типа — забудьте все, чему вас учили в институте), хотя никакого разрыва реально нет.
— реально речь должна вестись о соотвествии распределения усилий реальным функциональным и нефункциональным требованиям, делать какие-либо утверждения в отрыве от конкретных требований априори негамотно (неграмотно, разумеется, в "обе стороны")
— почему-то с удивительным упорством озвучивается тот факт, что повышение эффективности системы обязательно сказывается на ее архитектуре, хотя это очень часто не так. Более того, если кто-то является любителем коллекционировать интересные алгоритмы, то он мог заметить зачастую прямо противоположное. Одним словом, я бы подносил эту мысль под несколько другим углом, а именно: "если конкретная оптимизация ломает абстракции системы, то такая оптимизация должна иметь под собой весьма сильное обоснование", ключевое слово здесь — "если", а правильный ответ содержится в слове "обоснование", которое в нашем случае может быть только одно — внешнее по отношению к задаче требование (оно же ограничение в традиционных терминах).
— вообще, пропаганда применения одних подходов ВМЕСТО других обречена на выпады "против":
1. подходы зачастую отлично используются совместно;
2. баланс м/у подходами наиболее точно определяется реальными требованиями и ограничениями, а не текущей модой.
К тому же, у меня есть четкое убеждение, что человек, который умеет находить хорошие эффективные пути всяко более полезен, чем тот который не умеет. Если же речь идет о фанатизме, то я согласен, хотя я категорически против голословных обвинений в фанатизме. К тому же, реально просматривая "оптимизированные куски кода" реальных неудачных "оптимизаций" с большой вероятностью можно обнаружить отсутствие повышения эффективности. Это те самые случаи, когда кто-то пытается оправдать собственную несостоятельность целями повышения чего-то там. Мы здесь обсуждаем именно эти истории? Если нет, то для нашего обсуждения были взяты заведомо ложные посылы. В принципе, для того, чтобы продолжать подобные обсуждения необходимо причислить Дворкина именно к упомянутому случаю, независимо от реальной степени его причастности к подобным моментам, или же обсуждение можно сворачивать прямо сейчас.
Далее.
Например, со слов Влада неоднократно выходило, что если человек привык работать над эффективностью, то это потерянный для общества человек. Типа, если ты умеешь оптимизировать, то ты и есть фанат. Прямо от такую связку не озвучивает, но его посты настойчиво приводят к такой мысли. А мне вот кажется совсем обратное. Если человек умеет находить эффективные решения, то он их находит не только в алгоритмах, но и в архитектуре и даже в организации своего труда. И связано это не с только с обсуждаемой эффективностью как целью, сколько с уровнем способностей конкретного индивидуума к мышлению. Да именно, к банальному уровней способностей. Поэтому, если тут кто-то кого-то обвиняет в фанатизме или склонности к догмам, то можно не ходить вокруг да около, не плести 10-ти килобайтные ответы, а напрямую обсуждать тупость оппонента. Пусть не совсем корректно, зато более "честно".
Здравствуйте, Дарней, Вы писали:
V>>а ты напиши быструю сортировку "по месту", т.е. без дополнительного динамического выделения памяти на каждом шаге... тогда узнаешь, почему порой модифицированная пузырьковая работает не хуже.
Д>Выбрать подходящий для данного случая алгоритм — это тоже одна из важных задач архитектора. Но это опять-таки не имеет никакого отношения к обсуждаемой теме. Д>Re[5]: Вопрос вполне философский
Блин, я отвечал вообще-то на вопрос о том, почему ИНОГДА ручное управление памятью может быть оправданным... Похоже, манера отвечать не читая становится заразной на RSDN...
Здравствуйте, Дарней, Вы писали:
V>>Так вот, матерый ассемблерщик дрючит все эти С++ и в хвост и в гриву. До сих пор. Достаточно посмотреть на выход компилятора — если бы это писал человек, я бы его уволил.
Д>Такие "матерые ассемблерщики" давно уже сидят на разработке компиляторов и еще в некоторых специфических областях. Работают себе спокойно, и не флеймят на форумах, потому что знаю себе цену. А те, кто собираются дрючить С++ в хвост и гриву — это просто недоучки, которые не представляют себе реальной сложности задачи. Здесь на форуме таких уже много было, но ничего конкретного еще ни один не смог выдать.
Я думаю, что ты не знаешь, о чем говоришь, скорее всего ты не вращался в этих кругах, а сейчас просто излагаешь свое некое видение. Лучше попытайся воспринять что тебе говорят люди, реально потратившие на все это много лет. Кстати, на С++ я проработал лет 8 весьма плотно. К тому же было сделано замечание: "Разумеется, речь идет о задачах, на которых ассемблер уместен.". Очевидно, ты его не понял. Мне вообще кажется, что тебе не стоит отвечать на мои посты, ибо ты не хочешь (или не можешь) читать оппонента... Сегодня ты в ударе в общем.
V>>Да нет, они не страшны, они отмирают сами по причине потери работы.
Д>Кто ж их уволит, если они старательные? В любой конторе таких людей полно. Сидят себе, кропают килограммами код, в котором потом сам черт ногу сломит.
Это возможно только там, где в техническом руководстве сидят не спецы. Я обязательно просматриваю как сам код, так и более "крупный план" того, что пишет моя команда. В общем, я опять склонен думать, что ты не имеешь понятия о том, что говоришь...
Д>А догматики попадаются очень редко. Мне только один встречался, так его через месяц и выпнули, потому что никакого реального результата он выдать не смог (С)
Я наблюдал другое. Пудрить мозги "умными речами" на больших проектах можно почти год. Выдавать промежуточные результаты и т.д. И реально написать почти не пригодную к эксплуатации систему. Как раз довелось для одной очень известной тебе крупной западной фирмы перепроектировать их неудачную предыдущую разработку.
Здравствуйте, vdimas, Вы писали:
V>Он же преподаватель.
И что?
V> Для первых 2-х лет изучения программирования — очень даже.
А по мне так с точностью до наоборот. В начале важнее акценты расставить, а не чему то конкретному научить.
V>К тому же, у меня есть четкое убеждение, что человек, который умеет находить хорошие эффективные пути всяко более полезен, чем тот который не умеет.
Крайне спорно. Опять же — я не уверен что поиск эффективных решений на низком уровне такое сложное умение.
V>К тому же, реально просматривая "оптимизированные куски кода" реальных неудачных "оптимизаций" с большой вероятностью можно обнаружить отсутствие повышения эффективности. Это те самые случаи, когда кто-то пытается оправдать собственную несостоятельность целями повышения чего-то там.
Так об этом Синклер как раз и писал.
V>Например, со слов Влада неоднократно выходило, что если человек привык работать над эффективностью, то это потерянный для общества человек. Типа, если ты умеешь оптимизировать, то ты и есть фанат.
Ссылочку можно?
V> Прямо от такую связку не озвучивает, но его посты настойчиво приводят к такой мысли.
Такими аргументами можно кого угодно в чем угодно обвинить. Если тебе что то кажется, то намного лучше прямо спросить, а не делать из своих предположений далеко идущие выводы.
V> А мне вот кажется совсем обратное. Если человек умеет находить эффективные решения, то он их находит не только в алгоритмах, но и в архитектуре и даже в организации своего труда. И связано это не с только с обсуждаемой эффективностью как целью, сколько с уровнем способностей конкретного индивидуума к мышлению.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Собственно я уже не первый раз сталкиваюсь с (совершенно некорректной) интерполяцией вашего взаимного непонимания (по довольно специфичным вопросам) на качество обучения. Я бы не хотел, чтобы здесь все думали, будто курс программирования представляет собой копирование фактов из сознания учителя в сознания учеников с принудительным оверрайтом прежнего содержимого.
Я не понимаю, что именно из сказанного мной наводит на такое восприятие моего мнения. Я считаю, что все же лучше, чтобы ученики умнели благодаря обучнию, а не вопреки. Меня совершенно не беспокоит, узнают ли ученики о том, какие из методов получения строки в WinAPI оборудованы длиной, а какие нет. Фактов много, приемов — мало. Факты можно легко получить, открыв RTFM, приемы нужно долго усваивать.
Именно в этом и кроется корень противоречия: каждая сторона боится влияния противника на подрастающее поколение. Дворкин боится, что мы научим молодеж думать о ресурсах свысока.
Я боюсь, что он научит молодежь брать первое подвернувшееся решение, и обязательно обосновывать его выбор задним числом. Сам Павел предпочитает для обоснования эффективность, но это непринципиально — сам подход совершенно не завязан на конкретный набор аргументов. Точно так же фанатик от архитектурщины будет вводить лишние уровни абстракции и подбирать аргументы из области супергибкости и адаптируемости под неизвестно что. А на все замечания относительно откровенного оверхеда отвечать в духе "да в этом проекте в жизни не потребуется больше 10 транзакций в день" и "вот вам лишь бы последнее слово за собой оставить".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Я бы не хотел, чтобы здесь все думали, будто курс программирования представляет собой копирование фактов из сознания учителя в сознания учеников с принудительным оверрайтом прежнего содержимого.
LCR>В реальной жизни ученики думают головой, продолжают учиться, и многие шагнули дальше своего учителя, но до сих пор благодарны ему (учителю). Так и должно быть, я считаю.
Для тех, у кого самостоятельное мышление не очень развито, хороший учитель очень важен. В том числе и для того, чтобы развивать самостоятельность.
А если ученик хорошо умеет думать своей головой, то учитель ему вообще не очень нужен, и в особенности — плохой учитель.
Здравствуйте, vdimas, Вы писали:
Д>>А почему это loose coupling должен вдруг негативно влиять на надежность? Ты ничего не перепутал?
V>нет, не перепутал.
а не расскажешь мне, непосвященному, каким образом увеличение числа зависимостей между модулями должно помочь увеличить надежность?
Здравствуйте, vdimas, Вы писали:
V>Я думаю, что ты не знаешь, о чем говоришь, скорее всего ты не вращался в этих кругах, а сейчас просто излагаешь свое некое видение. Лучше попытайся воспринять что тебе говорят люди, реально потратившие на все это много лет. Кстати, на С++ я проработал лет 8 весьма плотно. К тому же было сделано замечание: "Разумеется, речь идет о задачах, на которых ассемблер уместен.". Очевидно, ты его не понял. Мне вообще кажется, что тебе не стоит отвечать на мои посты, ибо ты не хочешь (или не можешь) читать оппонента... Сегодня ты в ударе в общем.
Давай не будем устраивать здесь очередной раунд пенисометрии?
V>>>Да нет, они не страшны, они отмирают сами по причине потери работы.
Д>>Кто ж их уволит, если они старательные? В любой конторе таких людей полно. Сидят себе, кропают килограммами код, в котором потом сам черт ногу сломит.
вот ведь как интересно
V>Это возможно только там, где в техническом руководстве сидят не спецы. Я обязательно просматриваю как сам код, так и более "крупный план" того, что пишет моя команда. В общем, я опять склонен думать, что ты не имеешь понятия о том, что говоришь...
случай А
V>Я наблюдал другое. Пудрить мозги "умными речами" на больших проектах можно почти год. Выдавать промежуточные результаты и т.д. И реально написать почти не пригодную к эксплуатации систему.
случай Б
а в чем разница между случаем А и случаем Б? В том, что в случае А ты лично пресекаешь все возможные проблемы, а в случае Б тебя нет?
V>>Я думаю, что ты не знаешь, о чем говоришь, скорее всего ты не вращался в этих кругах, а сейчас просто излагаешь свое некое видение. Лучше попытайся воспринять что тебе говорят люди, реально потратившие на все это много лет. Кстати, на С++ я проработал лет 8 весьма плотно. К тому же было сделано замечание: "Разумеется, речь идет о задачах, на которых ассемблер уместен.". Очевидно, ты его не понял. Мне вообще кажется, что тебе не стоит отвечать на мои посты, ибо ты не хочешь (или не можешь) читать оппонента... Сегодня ты в ударе в общем.
Д>Давай не будем устраивать здесь очередной раунд пенисометрии?
Не раздавай впредь ярлыков насчет недоучек, ok? То свое заявление насчет ассемблера я сделал после примерно 3-х летнего участия/чтения rsdn и не хуже тебя знаю, какие мнения на этот счет здесь ходят. Тем не менее счел возможным озвучить. Сможешь опровергнуть меня более быстрым своим кодом на "высокооптимизируемом" С++ — welcome. Не сможешь — держишь свои соображения насчет "неучей" при себе. (Кста, если обратил внимание, я тусуюсь ближе к лагерю сторонников С++ в местных баталиях)
V>>>>Да нет, они не страшны, они отмирают сами по причине потери работы.
Д>>>Кто ж их уволит, если они старательные? В любой конторе таких людей полно. Сидят себе, кропают килограммами код, в котором потом сам черт ногу сломит.
Д>вот ведь как интересно
V>>Это возможно только там, где в техническом руководстве сидят не спецы. Я обязательно просматриваю как сам код, так и более "крупный план" того, что пишет моя команда. В общем, я опять склонен думать, что ты не имеешь понятия о том, что говоришь...
Д>случай А
V>>Я наблюдал другое. Пудрить мозги "умными речами" на больших проектах можно почти год. Выдавать промежуточные результаты и т.д. И реально написать почти не пригодную к эксплуатации систему.
Д>случай Б
Д>а в чем разница между случаем А и случаем Б? В том, что в случае А ты лично пресекаешь все возможные проблемы, а в случае Б тебя нет?
Разница в том, что в случае Б в тим-лидерах и более старших руководителях ходили люди, гораздо менее ориентирующиеся в своей специальности, чем рядовые программисты. Такое действиетльно наблюдалось часто.. довольно давно... Сейчас мне такой сценарий кажется маловероятным. Ответ на эти твои длинные копи-пейсты содержался в самом начале, см. выделенное.
Д>а не расскажешь мне, непосвященному, каким образом увеличение числа зависимостей между модулями должно помочь увеличить надежность?
Во-первых, для нашей отрасли не между модулями а между абстракциями, а во-вторых, первый бросающийся в глаза агрумент — типизированность vs нетипизированность. Или оная статическая vs динамическая. Есть и другие аргументы. Погугли насчет того как пишутся критичные к надежности приложния и что там насчет сильной связи.
В общем, как всегда с ног на голову. Loose coupling — это не самоцель, а лишь один из параметров к оптимизации в наших многомерных задачах. В конкретных случаях, ессно, параметрам раздают конкретные коэффициенты. Ну а далее включаем стандартные механизмы многофакторных оптимизаций с весовыми коеф. и получаем результаты согласно весовых коеф. Все это относится не только к loose coupling, а вообще к любым критериям/параметрам. И именно поэтому не существует "серебрянной пули". В общем, спец должен не только обладать некими знаниями для успешной деятельности, но и уметь их прикладывать по месту.
Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?
V>> Для первых 2-х лет изучения программирования — очень даже.
AVK>А по мне так с точностью до наоборот. В начале важнее акценты расставить, а не чему то конкретному научить.
Как можно расставлять акценты у неизвестного? Сначала нужно обрисовать саму "проблему", и только потом можно показать действие твоих акцентов. Всему свое время. Разработке сложных систем учат примерно с 3-го курса. К тому времени студенты уже способны понимать о чем речь. Для первокурсников же все, о чем мы здесь говорим будет китайской грамотой.
V>>К тому же, у меня есть четкое убеждение, что человек, который умеет находить хорошие эффективные пути всяко более полезен, чем тот который не умеет.
AVK>Крайне спорно. Опять же — я не уверен что поиск эффективных решений на низком уровне такое сложное умение.
Я непонял к чему именно относилось "крайне спорно". И при чем здесь низкий уровень. Существуют просто решения, а существуют эффективные решения. Если человек умеет находить эффективные решения — это означает что он вообще способен эти решения находить (вывод основан на правиле включения множеств, и отношений множество/подмножество )
V>>К тому же, реально просматривая "оптимизированные куски кода" реальных неудачных "оптимизаций" с большой вероятностью можно обнаружить отсутствие повышения эффективности. Это те самые случаи, когда кто-то пытается оправдать собственную несостоятельность целями повышения чего-то там.
AVK>Так об этом Синклер как раз и писал.
Знаешь, эти моменты очень тонки на мой взгляд. Давайте прежде чем причислять оппонента к конкретной группе, тем более к группе отрицательных персонажей, посмотрим на реальные куски кода или решения. Хотя бы из уважения к корректности спора.
V>>Например, со слов Влада неоднократно выходило, что если человек привык работать над эффективностью, то это потерянный для общества человек. Типа, если ты умеешь оптимизировать, то ты и есть фанат.
AVK>Ссылочку можно?
Вот тот большой флейм насчет оптимизации в одной из его первых программ.
V>> Прямо от такую связку не озвучивает, но его посты настойчиво приводят к такой мысли.
V>> А мне вот кажется совсем обратное. Если человек умеет находить эффективные решения, то он их находит не только в алгоритмах, но и в архитектуре и даже в организации своего труда. И связано это не с только с обсуждаемой эффективностью как целью, сколько с уровнем способностей конкретного индивидуума к мышлению.
AVK>Вот только Дворкин говорит о другом.
Очень жаль кстати. Мне бы импонировал оратор, который сумел бы грамотно освящать эти вопросы и ставить на место всех тех, для кого ничто не ресурс сейчас. Свое мнение я уже озвучил — это тупой подход со стороны требований/ограничений. По сути, у меня нет предпочтений и увлеченности, поэтому на оратора не гожусь.
Здравствуйте, Дарней, Вы писали:
V>>Похоже, манера отвечать не читая становится заразной на RSDN...
Д>Ты абсолютно прав. Д>Расскажи мне, какое вообще отношение имеет твое сообщение к теме моего сообщения?
Конкретно в той подветке, на которую я ответил речь шла об O-нотациях, алгоритмах и уместности ручного управления памятью.
Здравствуйте, vdimas, Вы писали:
V>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?
м... а что понимается под расчетом характеристик системы?
Здравствуйте, Дарней, Вы писали:
ГВ>>Нет, глупостью с твоей стороны на самом деле было то, что ты решил, что я обязан видеть в сообщениях других то и только то, что ожидаешь ты и ещё несколько авторов ФП.
Д>Эк хитро завернул, шайтан Программы ты в том же стиле пишешь?
По существу моего замечания, как я понимаю, тебе возразить нечего? O'K, так и отметим.
ГВ>>На самом деле мой пост спровоцирован по большей части дискуссией Дворкина и Ко в теме "Каков глубокий смысл сериализации?". Там не было особого нажима на необходимость ручной работы с памятью. А вот рассуждения о необходимости своевременного анализа алгоритмов — были.
Д>Эту тему я почти не читал. Мне по уши хватило хватило предыдущих флеймов, которые затевал Дворкин. Человек, который искренне верит, что строки в базе данных хранятся без длины — никогда не расскажет что-то интересное для меня.
Фу ты, ну ты, пальцы гнуты!
Хочешь вернуться к той дискуссии? Ну так посмотрим...
Поймите меня правильно. Это вовсе не значит, что мы оптимизировали
все и вся. Код, который работает 0.1 сек и занимает 100 байт, никто
не оптимизировал. И то, что оптимизировать нужно самые внутренние
циклы, мы прекрасно знали. Не об этом речь. А о том, что при написании
программ была определенная культура(Выделено мной. — ГВ.), требовавшая памятью не сорить
без надобности, первый попавшийся алгоритм не применять, а искать хороший,
ну и т.д.
Далее были традиционные бла-бла-бла, но вот что интересно.
, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:
— Наших бьют!
— Да нет, не бьют...
— Ну так послать туда наших!
Обращает на себя внимание тот факт, что за 26 минут до этого, Дворкин написал
А он у меня не метод был. Он просто функция был, потому что (сейчас я тебя испугаю) весь проект не на С++, а на С делался. Приины мне неизвестны, но повлиять я не мог ...
После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.
И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.
Д>Что касается своевременного анализа алгоритмов — это вещь конечно нужная, никто и не спорит. Главное только, поределиться, что такое "своевременный анализ". Если проект, к примеру, состоит в решении алгоритмически сложной задачи — с него и нужно начинать. Другой вопрос, что в индустрии такие задачи встречаются достаточно редко. А для обычной задачи выбор алгоритов — далеко не самая приоритетная задача.
Ну, ни ты ни я надо всей индустрией свечку не держали. Да даже если и предположить, что в индустрии чаще встречаются задачи, не требующие анализ свойств алгоритмов, это не отменяет необходимости такого анализа в тех случаях, когда это необходимо (это я специально повторяюсь, чтобы не возникало разночтений). А из априорной неизвестности такой необходимости следует, что анализировать в том или ином виде таки нужно всегда (это я снова специально повторился).
Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?
ГВ>>да ещё в которой раздаётся очередной демагогический вопль про сверхразумные средства разработки не вспомнить о сути указанной дискуссии? Д>это не демагогия, это факт. Ты разве не замечаешь изменений?
Нет, не замечаю таких изменений, которые бы подходили под определение разумности. Помощь в навигации — да. Но тенденции к сверхразумности пока не замечаю. Кроссмодульная оптимизация здесь ни при чём — ей как идее сто лет в обед.
ГВ>>Где конкретно? Ещё раз повторюсь — у меня такого впечатления не сложилось, следовательно, я ничего искать не обязан. Желаешь доказать своё утверждение — ссылки в студию. Д>Почитай любой из предыдущих флеймов, которые он затеял.
Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях. Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят.
Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
ГВ>>Например, ими могут оказаться студенты того же Павла Дворкина. Д>Мне искренне жаль этих несчастных. Боюсь, что большинству из них уже ничто не поможет.
Ха-ха-ха!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
V>> А мне вот кажется совсем обратное. Если человек умеет находить эффективные решения, то он их находит не только в алгоритмах, но и в архитектуре и даже в организации своего труда. И связано это не с только с обсуждаемой эффективностью как целью, сколько с уровнем способностей конкретного индивидуума к мышлению.
AVK>Вот только Дворкин говорит о другом.
А о том, что при написании программ была определенная культура, требовавшая памятью не сорить
без надобности, первый попавшийся алгоритм не применять, а искать хороший,
ну и т.д.
И чуть ниже в том же постинге:
Если кто-то думает, что моей целью было 200 байт сэкономить — ничего Вы
из моих рассуждений не поняли. Моей целью было научить его грамотно писать
программы, делать как следует, а не так, как получится. Не реализовать первую
пришедшую в голову идею, а подумать, нельзя ли здесь лучше сделать! Потому что
если я сейчас это пропущу — он и дальше будет так же делать, тройные циклы
писать там, где двойных хватит и лишние массивы без надобности заводить.
Мне, честно говоря, трудно представить более однозначное заякоривание основной мысли постинга.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Sinclair,
LCR>>Собственно я уже не первый раз сталкиваюсь с (совершенно некорректной) интерполяцией вашего взаимного непонимания (по довольно специфичным вопросам) на качество обучения. S>Я не понимаю, что именно из сказанного мной наводит на такое восприятие моего мнения.
Вашего — это собирательный образ.
Ты сериализация
Это разумеется не все случаи, просто я не владею в совершенстве возможностями поиска на сайте.
S>Я считаю, что все же лучше, чтобы ученики умнели благодаря обучнию, а не вопреки. Фактов много, приемов — мало.
Бесконечно рекурсивное ДА! Хочешь расскажу, как заставить человека думать?
Нужно 2 взаимно противоречивых утверждения и обосновать их. Всё.
Такое одновременное существование A и ~A вызывает мысль "что-то тут не так" и стимулирует поиск ответа. Результатом мыслительного процесса является некоторое общее утверждение, для которого A и ~A являются просто частными случаями. Я назову это утверждение утверждением второго порядка. Далее мы обосновываем 2 противоречивых утверждения второго порядка и человек находит (или не находит) утверждение третьего порядка. И так далее. То, что получается в результате этого процесса — это некоторые общие утверждения, которые можно назвать принципами (вещи типа "везде нужен баланс" и т.п.).
S>Именно в этом и кроется корень противоречия: каждая сторона боится влияния противника на подрастающее поколение. Дворкин боится, что мы научим молодеж думать о ресурсах свысока. S>Я боюсь, что он научит молодежь брать первое подвернувшееся решение, и обязательно обосновывать его выбор задним числом.
Плиз. Форумные разговоры вообще ничему не учат, это лишь источник информации. Человек учится _сам_ на основе информации, подчерпнутой из форумов, опыта, книжек и ещё из многих разных источников. Так что вы заблуждаетесь оба.
Кстати, а что тебя смущает в обосновании решения после выбора решения? Обычный творческий поиск: сначала предлагается решение, потом ищутся преимущество-недостатки при существующих условиях. Если не проканало, то предлагается новое. Что не хорошо?
Дарней,
Д>А если ученик хорошо умеет думать своей головой, то учитель ему вообще не очень нужен, и в особенности — плохой учитель.
"...если умеет думать головой..." Ха-ха-ха. Нет такого человека, который сам бы вывел всю теорию сложности, или функциональный анализ, или топологию. Вот Ньютон говорил: "я стоял на плечах гигантов".
Чтобы вырваться из клетки невежества нужен проводник.
Здравствуйте, vdimas, Вы писали:
V>Как можно расставлять акценты у неизвестного?
Почему неизвестного? Надо просто отделить мух от котлет, проблемы реализации от проблем архитектурных. И про первые рассказывать далеко не сразу.
AVK>>Крайне спорно. Опять же — я не уверен что поиск эффективных решений на низком уровне такое сложное умение.
V>Я непонял к чему именно относилось "крайне спорно".
К товему высказыванию.
V> И при чем здесь низкий уровень.
При том, что от уровня зависят те самые акценты.
AVK>>Так об этом Синклер как раз и писал.
V>Знаешь, эти моменты очень тонки на мой взгляд. Давайте прежде чем причислять оппонента к конкретной группе, тем более к группе отрицательных персонажей, посмотрим на реальные куски кода или решения. Хотя бы из уважения к корректности спора.
Пока что здесь не я кого то куда то причисляет, а кое кто другой огульно обзывает других фанатами. Так что с этим не ко мне.
V>>>Например, со слов Влада неоднократно выходило, что если человек привык работать над эффективностью, то это потерянный для общества человек. Типа, если ты умеешь оптимизировать, то ты и есть фанат.
AVK>>Ссылочку можно?
V>Вот тот большой флейм насчет оптимизации в одной из его первых программ.
Это не ссылка. Ты, пожалуйста, конкретн7ую цитату приведи.
AVK>>Вот только Дворкин говорит о другом.
V>Очень жаль кстати.
+1
V> Мне бы импонировал оратор, который сумел бы грамотно освящать эти вопросы и ставить на место всех тех, для кого ничто не ресурс сейчас.
А тебе не кажется, что ты с ветряными мельницами борешься?
Здравствуйте, Anton Batenev, Вы писали:
V>>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?
AB>м... а что понимается под расчетом характеристик системы?
Ну... большинство из нас пишут классические СМО. Там полно есть чего расчитывать
Здравствуйте, AndrewVK, Вы писали:
VD>>Я, кстати, ни одного такого языка не припомню. Где еще определение класса можно разбить на несколько файлов? Причем, заметь, не реализацию, а именно определение.
AVK>Википедия знает только C# 2.0. Как мне кажется, что то подобное было в Smalltalk, то там как таковых файлов исходников не было.
Такая возможность в ST связана с тем, что там класс — объект который постоянно существует /в образе/. И его можно менять как угодно в любой момент. Добавить, убрать переменные. Добавить, удалить, изменить методы. Соответсвенно некий пакет может добавить/переписать методы уже существующих классов. Но это не partial type в том смысле, что в C# — тип, определение которого размазано по классам. В ST это просто один из "побочных эфектов" выбранной модели.
, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:
Ой как загнул... меня ламером безмозглым назвал, а контекст сообщения забыл... да и дальнейшее обсуждения пропустил...
А ведь там говорилось не столько о скорости сколько о надежности решения.
(С)Pavel Dvorkin
А ведь это одна из самых распространенных уязвимостей в современном софте.
Кстати на счет форматирования есть такой замечательный язык Nemerle так вот при с помощью его макросов можно статическим анализом привести форматирование к конкатенации.
ГВ>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.
Ты в самом начале сделал не верную посылку о том что все тут фанатеют от .NET и всеми правдами и не правдами пытаются его защитить. И на основании этой ложной посылки сделал огромное колличество далеко идущих выводов. Ай как не хорошо.
А ведь разговор то не про .NET и не про С++ и даже не про С. Разговор о том что Дворкин выберает очень сомнительные как с точки зрения надежности так и с точки зрения производительности решения руководствуясь старыми привычками.
ГВ>И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".
А это называется демагогия и переход на личности.
ГВ>Что же до одиозного высказывания
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.
Те вся борьба с длинной строк строилась на архитектурной ошибке создателей С и всех тех кто эту ошибку тупо повторял?
Кстати
WH>По сравнению с копированием строк особенно если строки длинные это ничтожные затраты времени.
Нет, не ничтожные. На входе у тебя буфер из байтов или ushort. Строка, в сыром виде пришедшая, из файла, к примеру,. И длину ее найти можно только просмотрев символы в поисках некоего признака конца (0xD из файла). Это не копирование, но все же массовая операция. И делать ее у тебя кто-то будет, не ты сам, так кто-то из библиотеки. А вот я указатель на эту строку в memory-mapped файле возьму и дальше мое дело — искать ее длину или нет. Надо — найду. не надо — подожду пока что, может, и не понадобится.
При том что Павел признался что формировал этот фаил сам... Вот прикол то... Сам сформировал и сам жалуется что длинну не положил...
ГВ>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?
Тут опять неверная посылка и соответсвенно не верные выводы. Об алгоритмах думают но в большинстве задач не в первую очередь.
Например я некоторое время назад делал очень хитрую объектную систему... так вот движок этой системы получился килобайт на 150 исходников. И я его переписывал 3 раза прежде чем сумел уложится во все архитектурные требования которые как и положено при разработки таких систем очень сильно уточнялись по ходу дела. И если бы я во время разработки думал о производительности я бы его переписал не три раза, а раз 10 причем каждая итерация былабы намного длиннее. Так вот тот вариант который подходил под архитектурные требования тормозил жудко. Короче я его разогнал за пару часов на пару порядков ибо у меня получилась правильная архитектура и я просто вставил в нужных местах кеш. Причем там есть еще места которые можно пооптимизировать но вот только это никому не нужно ибо разогнаное решение и так с запасом укладывается в требования по производительности. Кстати не смотря на то что там очень активно используются строки оптимизировать их я и не думал. У меня даже мыслей таких небыло хотя со строкими там работа идет мягко говоря не самыми оптимальными методами. А если вдруг эту систему понадебится разогнать (что врядли) то оптимизация строк будет на самом последнем месте.
Вобщем как уже не однократно говорилось "Сделать правильную программу быстрой легко, а сделать быструю программу правильной не возможно." вот по этому я пишу правильные программы и только в случае если не хватает производительности я делаю их быстрыми причем я по возможности выбираю те оптимизации которые не портят архитектуру.
ГВ>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях. Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят.
Ему пытаются объяснить что он не там производителность ищет... при этом его методы понижают надежность.
ГВ>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).
Ну вот я еще и говорить разучился... Эх Гена, Гена... на пятый пункт ведь нарываешься.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ой как загнул... меня ламером безмозглым назвал, а контекст сообщения забыл... да и дальнейшее обсуждения пропустил... WH>А ведь там говорилось не столько о скорости сколько о надежности решения. WH>
WH>(С)Pavel Dvorkin WH>А ведь это одна из самых распространенных уязвимостей в современном софте. WH>Кстати на счет форматирования есть такой замечательный язык Nemerle так вот при с помощью его макросов можно статическим анализом привести форматирование к конкатенации.
Вот как раз то, что не всегда уязвимость есть уязвимость Дворкин тщетно пытался объяснить своим оппонентам. Я отлично понимаю, что приведённый фрагмент кода — одна из распространённейших уязвимостей. Только всё зависит от задачи. И если Дворкин утверждает, что на 200% уверен в том, что суммарная длина szFisrtName + szLastName не превысит буфера, то, почему-то, я ему верю. Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения.
ГВ>>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась. WH>Ты в самом начале сделал не верную посылку о том что все тут фанатеют от .NET и всеми правдами и не правдами пытаются его защитить. И на основании этой ложной посылки сделал огромное колличество далеко идущих выводов. Ай как не хорошо.
Я про всех никаких посылок сделать не мог. Ибо сам являюсь частью этих самых "всех" и от .Net ну совсем не фанатею. А вот то, что .Net был приплетён к той самой дискуссии не совсем по месту — уверен до сих пор.
Просто получилось что-то: "а вот если бы на рыбе росла шерсть, то в ней завелись бы блохи и сейчас про блох я вам и расскажу".
WH>А ведь разговор то не про .NET и не про С++ и даже не про С. Разговор о том что Дворкин выберает очень сомнительные как с точки зрения надежности так и с точки зрения производительности решения руководствуясь старыми привычками.
Как совершенно справедливо утверждает Дворкин, истина всегда конкретна (у нас же не метафизичисеский форум, верно?). И в рамках конкретных, озвученных им условий его решение нельзя признать неадекватным. Тогда как контрпримеры — более чем не к месту.
ГВ>>Что же до одиозного высказывания
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером. WH>Те вся борьба с длинной строк строилась на архитектурной ошибке создателей С и всех тех кто эту ошибку тупо повторял?
Погоди. Причём тут "борьба" с длиной строк? Да, Дворкин на самом деле упоминал перерасход памяти на длину в случае коротких строковых значений. Только причём тут архитектурная ошибка создателей C — совсем не понимаю.
Про архитектурную ошибку крутое, надо сказать, определение, особенно, если учесть, что ASCIIZ-формат долеко не так глуп, как тебе кажется. Дело в том, что таким образом мы избавляемся от необходимости синхронизировать информацию о длине в поле длины с фактической длиной строки. То есть, сама строка становится защищённой от ошибок рассинхронизации данных. А это немало. Так что, я бы поостерёгся таких заявлений.
WH>Кстати WH>
WH>>По сравнению с копированием строк особенно если строки длинные это ничтожные затраты времени.
WH>Нет, не ничтожные. На входе у тебя буфер из байтов или ushort. Строка, в сыром виде пришедшая, из файла, к примеру,. И длину ее найти можно только просмотрев символы в поисках некоего признака конца (0xD из файла). Это не копирование, но все же массовая операция. И делать ее у тебя кто-то будет, не ты сам, так кто-то из библиотеки. А вот я указатель на эту строку в memory-mapped файле возьму и дальше мое дело — искать ее длину или нет. Надо — найду. не надо — подожду пока что, может, и не понадобится.
WH>При том что Павел признался что формировал этот фаил сам... Вот прикол то... Сам сформировал и сам жалуется что длинну не положил...
А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием. Я надеюсь, ты не об этом
PD>Какая разница, откуда? Другая часть программы в буфер засылает.
?
ГВ>>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить? WH>Тут опять неверная посылка и соответсвенно не верные выводы. Об алгоритмах думают но в большинстве задач не в первую очередь.
Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
WH>Например я некоторое время назад делал очень хитрую объектную систему... [...]
А вот я... а вот он... а вот есть у нас оружие! Нет, дружище. Мы так с тобой ни до чего не договоримся. Хотя, для меня лично, ситуация, описанная тобой, более чем узнаваема. Но на основании одной только виртуальной аналогии утверждать ничего не буду. Да, бесспорно, написано изящно, не без возвышенного штиля, но о чём конкретно идёт речь понять нельзя.
Понимаешь... То, что ты сейчас написал похоже на разговоры о том, как "Мы с Серёгой выпили Пепси и...". Здесь нужна конкретика. Вдруг я до архитектуры дорвусь? Т.е., вдруг объяснение будет: "Мы ж менты!"
WH>Вобщем как уже не однократно говорилось "Сделать правильную программу быстрой легко, а сделать быструю программу правильной не возможно." вот по этому я пишу правильные программы и только в случае если не хватает производительности я делаю их быстрыми причем я по возможности выбираю те оптимизации которые не портят архитектуру.
Очень хорошо. Более того, я даже отлично понимаю, о чём конкретно ты говоришь, произнося сии лозунги. Ещё более того, я отлично понимаю, какое влияние на тебя предварительно оказал C++ и свойственные ему подходы к проектированию. Я только в одном не уверен. В том, что это поймёт тот, кто не имеет за плечами опыт работы с C++. Не сочти за переход на личности, будь добр.
ГВ>>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях. Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят. WH>Ему пытаются объяснить что он не там производителность ищет... при этом его методы понижают надежность.
Ну здесь я у тебя повторно попрошу урлчик на утверждение о генерации файла. Поскольку остальные приведённые им примеры сомнений в смысле быстродействия не вызывают. В смысле надёжности — тоже, при учёте контекста.
ГВ>>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе). WH>Ну вот я еще и говорить разучился... Эх Гена, Гена... на пятый пункт ведь нарываешься.
Нет, Андрей. Ну как ты мог обо мне такое подумать? Это ж корова (священная!) мычит, а не ты.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения.
Следует читать: ...подобного решения
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Увы, нет времени сейчас на участие в дискуссии. Выдалось немного времени — прочитал эту ветку. Много интересного о себе узнал
Но вот одно место все же отмечу.
S>4. На просьбы подкрепить свои бредни
Вообще такой род дискутирования говорит только о том, что автор не имеет более убедительных аргументов. К сожалению, мои оппоненты это прекрасно демонстрируют
Свой я аккуратно просмотрел. Во всех случаях это цитирование.
Так что, господа, научитесь для начала уважать чужое мнение и не называть его бредом (ах ,употребляю . Тем более, судя по отзывам и оценкам моего изначального постинга
Нашел немного времени, чтобы ответить. Не на все отвечу.
Д>чтобы научиться наиболее эффективно абстрагироваться, нужно сначала научиться просто абстрагироваться. А вот с этим у товарища как раз серьезные проблемы.
А собственно, почему ? Из чего следует, что они есть ? Я призываю думать и о реализации — мне говорят — у Вас проблемы с абстрагированием. Если я про абстрагирование вообще почти не говорю, потому что это для меня просто промежуточный этап, то из этого следует, что я вообще это делать не умею ?
Здравствуйте, Sinclair, Вы писали:
S>Вот про строки была дискуссия. Очень смешно. Оказалось, что известный эксперт и преподаватель WinAPI не знал, что в 90% в виндах строки все-таки оборудованы длиной.
А, теперь уже только 90%. Явный прогресс. Раньше утверждалось, нечто иное
>В 21 веке пора привыкать к тому, что строка в 99.9999% обладает длиной.
Windows, разумеется, живет в 21 веке. Вообще в этом веке только 0.0001% строк не имеет длины. А в Windows их аж 10%. М-да... Что же это за ОС такая, в которой количество устраевших конструкций в 10/0.0001 = 10000 (десять тысяч) раз превышает среднее по отрасли.
>Поскольку он был воспитан на микроконтроллерах, где всю работу со строками надо было делать вручную
Можно узнать — откуда эта информация ? Дело в том, что с микроконтроллерами я, насколько себя помню, никогда в жизни дела не имел. Нет такого в моей биографии. Это, конечно, печально, но вот нет...
Так что сообщите пожалуйста, кто обо мне такую дезинформацию дает.
А не сможете сообщить — придется вспомнить Булгакова
"Так что же этот человек сказал ?"
"А он попросту соврал. Поздравляю Вас, гражданин, соврамши"
Или же ты микроконтроллеры с микропроцессорами перепутал ? Уверяю тебя — это не совсем одно и то же.
(цитирую по памяти)
S>В итоге мы имеем противоборство между тупоконечниками и остроконечниками. Одни (и я в том числе) считают, что хорошая архитектура — the must, а производительность всегда можно дотюнить при необходимости. Другой лагерь почему-то считает нас транжирами, а эффективность — главным критерием софта. А уж какая там архитектура — дело второе.
Опять передергивание.
Прошу показать мне место, где я бы утверждал, что "какая там архитектура — дело второе". Ссылку в студию!
S>Мы считаем, что хороша та программа, которая потребляет минимум концепций, а они — что та, которая потребляет минимум ресурсов.
Опять передергивание. Хороша та программа которая потребляет минимум ресурсов, да, но при чем здесь минимум концепций ? Почему это потребление минимума ресурсов обязательно связано с транжириванием концепций ?
S>Много лет рулили "эффективники", поскольку имеющихся ресурсов было крайне мало, и каждое улучшение эффективности давало офигенное преимущество для потребителя. S>Теперь наступает перелом в "нашу" пользу
Не спеши!
>То есть повторная используемость, тот самый loose coupling и high cohesion будут по прежнему рулить.
Я как раз сейчас вынужден заниматься этим самым повторным использованием. Как-нибудь опишу свои впечатления
Здравствуйте, vdimas, Вы писали:
V>- читая их посты, создается впечатления некоего "разрыва" м/у традиционной программисткой наукой и "новыми веяниями" (типа — забудьте все, чему вас учили в институте), хотя никакого разрыва реально нет.
У меня впечатление что он если не есть уже, то начинает появляться.
V>- реально речь должна вестись о соотвествии распределения усилий реальным функциональным и нефункциональным требованиям, делать какие-либо утверждения в отрыве от конкретных требований априори негамотно (неграмотно, разумеется, в "обе стороны")
V>- почему-то с удивительным упорством озвучивается тот факт, что повышение эффективности системы обязательно сказывается на ее архитектуре, хотя это очень часто не так.
+1. Но не сомневайся, меня еще не раз в этом обвинят, хотя я такого нигде не утверждал.
>Более того, если кто-то является любителем коллекционировать интересные алгоритмы, то он мог заметить зачастую прямо противоположное. Одним словом, я бы подносил эту мысль под несколько другим углом, а именно: "если конкретная оптимизация ломает абстракции системы, то такая оптимизация должна иметь под собой весьма сильное обоснование"
Здравствуйте, WolfHound, Вы как бы это помягче сказать...
WH>>По сравнению с копированием строк особенно если строки длинные это ничтожные затраты времени.
WH>Нет, не ничтожные. На входе у тебя буфер из байтов или ushort. Строка, в сыром виде пришедшая, из файла, к примеру,. И длину ее найти можно только просмотрев символы в поисках некоего признака конца (0xD из файла). Это не копирование, но все же массовая операция. И делать ее у тебя кто-то будет, не ты сам, так кто-то из библиотеки. А вот я указатель на эту строку в memory-mapped файле возьму и дальше мое дело — искать ее длину или нет. Надо — найду. не надо — подожду пока что, может, и не понадобится. WH>[/q] WH>При том что Павел признался что формировал этот фаил сам... Вот прикол то... Сам сформировал и сам жалуется что длинну не положил...
А не сообщит ли уважаемый сэр, откуда следует, что именно этот файл я сам сформировал ? Я ведь ясно написал
PD>А вот я указатель на эту строку в memory-mapped файле возьму
в этом примере. Откуда здесь файл — неизвестно, может, просто текстовый, в этом случае, конечно, нуля в конце нет, но идея та же — строка с терминатором без дллины.
WH>Например я некоторое время назад делал очень хитрую объектную систему... так вот движок этой системы получился килобайт на 150 исходников. И я его переписывал 3 раза прежде чем сумел уложится во все архитектурные требования которые как и положено при разработки таких систем очень сильно уточнялись по ходу дела. И если бы я во время разработки думал о производительности я бы его переписал не три раза, а раз 10 причем каждая итерация былабы намного длиннее. Так вот тот вариант который подходил под архитектурные требования тормозил жудко. Короче я его разогнал за пару часов на пару порядков ибо у меня получилась правильная архитектура и я просто вставил в нужных местах кеш.
Хм, интересно. Правильная архитектура сама по себе, а кэш сам по себе. Он в эту архитектуру вообще не входит, так что ли ? И при проектировании программы ты никак не подозревал об его существовании, а потом начал думать, как бы это улучшить, и ввел кэш ? Что-то здесь не так. И , кажется, я даже понимаю что.
Архитектура правильная — это замечательно. Никто и не предлагает неправильную реализовать. Так что это опустим как тривиальность. А вот что касается эффективности — у тебя подсознательно сработал прежний личный опыт или даже не опыт, а полученная ранее откуда-то информация. И она тебе подсказала, что реальное быстродействие здесь может быть резко повышено за счет кеширования. Грубо (очень грубо) говоря, при кешировании все то, что тормозит, будет вызываться в 10 раз реже, и хотя работать будет само по себе не быстрее, но это будет незаметно. Ты это все время в уме держал, поэтому все и получилось хорошо.
А теперь представь себе на минуту, что ты о кешировании никогда не слышал и даже не знаешь, что это слово означает. И вот ты сделал свой движок, тормозит он жутко, как сам пишешь, а про кэш ты не знаешь. Или хуже — неприменим здесь кэш. Или не дал результата. И других методов условно говоря внешней оптимизации нет (под внешней я понимаю то, что не относится к архитектуре по твоему же определению)
Здравствуйте, Sinclair, Вы писали:
S>Хз. Пока что видно нежелание вести поиск оптимальных алгоритмов: вместо этого защищаются уже принятые решения, и для них сочиняются оправдания. Ну вот как в последнем случае, на протяжении нескольких постов подразумевался тезис "fseek необходим в данной задаче для уменьшения объема хранимых данных",
Это уже слишком все же. Речь изначально шла о том, как вывести некие данные в некоем формате. Этот формат был задан мной для демонстрации того, где лучше использовать последовательный вывод, а где нет. Сам формат просто предложен для демонстрации (запись разреженной матрицы в определенном формате) Теперь оказывается, что fseek нужен не для того, чтобы выводит в файл наилучшим по моему мнению методом именно для этого формата, а вообще для того, чтобы уменьшить объем хранимых данных!!!
Честно говоря, у меня никакого желания дискутировать нет с теми, кто себе это позволяет. Когда на такие передергивания идут — спорить бессмысленно. Это уже не спор для нахождения истины, а просто желание во что бы то ни было доказать свою правоту. Не гнушаясь при этом ничем.
Pavel Dvorkin,
PD> [про бред и прочее плохое самочувствие]
Я думаю, ребята не хотят никого обидеть. Просто таким образом они решают проблему передачи информации.
Это такой метод компрессии данных!
Вместо того, чтобы чётко и обстоятельно формулировать, в чём же собственно не прав оппонент, можно просто одним взмахом пальчиков над клавиатурой — хрысь! — и фсё.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Я думаю, ребята не хотят никого обидеть. Просто таким образом они решают проблему передачи информации.
Информации ?
LCR>Это такой метод компрессии данных!
Коды с искажениями
LCR>Вместо того, чтобы чётко и обстоятельно формулировать, в чём же собственно не прав оппонент, можно просто одним взмахом пальчиков над клавиатурой — хрысь! — и фсё.
Да не надо их в этом случае оправдывать. В конце концов речь идет все же о нахождении истины, а не о том, чтобы доказать свою правоту. А когда используются аргументы типа "В Африке муха цеце переносит сонную болезнь" — "А пингвины в Антарктиде высиживают птенцов" — то создается ощущение смертельной скуки... Потому что если ответишь что пингвины в сонной болезни все же не повинны, то в следующий раз тебе скажут, что Эверест — самая высокая вершина в мире
PD>Windows, разумеется, живет в 21 веке. Вообще в этом веке только 0.0001% строк не имеет длины. А в Windows их аж 10%. М-да... Что же это за ОС такая, в которой количество устраевших конструкций в 10/0.0001 = 10000 (десять тысяч) раз превышает среднее по отрасли.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот как раз то, что не всегда уязвимость есть уязвимость Дворкин тщетно пытался объяснить своим оппонентам. Я отлично понимаю, что приведённый фрагмент кода — одна из распространённейших уязвимостей. Только всё зависит от задачи. И если Дворкин утверждает, что на 200% уверен в том, что суммарная длина szFisrtName + szLastName не превысит буфера, то, почему-то, я ему верю. Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения.
Нет. Уязвимость это всегда уязвимость. Даже есть это и не будет уязвимостью пока код править только Павел но когда код начнет править кто-то еще...
ГВ>Я про всех никаких посылок сделать не мог. Ибо сам являюсь частью этих самых "всех" и от .Net ну совсем не фанатею. А вот то, что .Net был приплетён к той самой дискуссии не совсем по месту — уверен до сих пор.
Ладно сведем понятие все до Я, Влад и Антон.
ГВ>Как совершенно справедливо утверждает Дворкин, истина всегда конкретна (у нас же не метафизичисеский форум, верно?).
Дело в том что этот форум именно что метафизический... ГВ>И в рамках конкретных, озвученных им условий его решение нельзя признать неадекватным. Тогда как контрпримеры — более чем не к месту.
Контрпримеры чего? Того что операции над строками с длинной будут по крайней мере не медленней чем операции над строками с терминатором в конце?
ГВ>Погоди. Причём тут "борьба" с длиной строк? Да, Дворкин на самом деле упоминал перерасход памяти на длину в случае коротких строковых значений. Только причём тут архитектурная ошибка создателей C — совсем не понимаю.
ГВ>Про архитектурную ошибку крутое, надо сказать, определение, особенно, если учесть, что ASCIIZ-формат долеко не так глуп, как тебе кажется. Дело в том, что таким образом мы избавляемся от необходимости синхронизировать информацию о длине в поле длины с фактической длиной строки. То есть, сама строка становится защищённой от ошибок рассинхронизации данных. А это немало. Так что, я бы поостерёгся таких заявлений.
А вот с этого места по подробней пожалуйста. Чем установка терминатора в конце надежней установки длинны в начале? Не понимаю.
ГВ>А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием. Я надеюсь, ты не об этом
:
Меня сегодня чегото поиск не взлюбил А просматривать сотни сообщений...
ГВ>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
Нам джидаям...
ГВ>Очень хорошо. Более того, я даже отлично понимаю, о чём конкретно ты говоришь, произнося сии лозунги. Ещё более того, я отлично понимаю, какое влияние на тебя предварительно оказал C++ и свойственные ему подходы к проектированию. Я только в одном не уверен. В том, что это поймёт тот, кто не имеет за плечами опыт работы с C++. Не сочти за переход на личности, будь добр.
Вот только я сам довольно долго избавлялся от полюсовых замашек... мой плюсовый опыт в основном лежит в категории как делать не надо. В этом смысле плюсовый опыт несомненно ценен. Но плюсовые методы я не использую.
ГВ>Нет, Андрей. Ну как ты мог обо мне такое подумать? Это ж корова (священная!) мычит, а не ты.
В следующий раз не стоит выражатся двусмысленно. Я не люблю читать меж строк.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не сообщит ли уважаемый сэр, откуда следует, что именно этот файл я сам сформировал ? Я ведь ясно написал PD>>А вот я указатель на эту строку в memory-mapped файле возьму PD>в этом примере. Откуда здесь файл — неизвестно, может, просто текстовый, в этом случае, конечно, нуля в конце нет, но идея та же — строка с терминатором без дллины.
Может я не так понял но мне почемуто мерещится что при расказе о той программе где тебе позарез нужно было уложится в 100 мсек ты говорил про то что генерировал какойто фаил?
Ссылку найти что-то не получается.
PD>Хм, интересно. Правильная архитектура сама по себе, а кэш сам по себе.
Правильно. PD>Он в эту архитектуру вообще не входит, так что ли ?
Да. PD>И при проектировании программы ты никак не подозревал об его существовании, а потом начал думать, как бы это улучшить, и ввел кэш ?
Именно. PD>Что-то здесь не так. И , кажется, я даже понимаю что.
Не так тут то что такой стиль работы противоречит твоим привычкам.
PD>Архитектура правильная — это замечательно. Никто и не предлагает неправильную реализовать. Так что это опустим как тривиальность.
Правильность архитектуры понятие растяжимое. Очень растяжимое и у разных людей оно очень разное... PD>А вот что касается эффективности — у тебя подсознательно сработал прежний личный опыт или даже не опыт, а полученная ранее откуда-то информация. И она тебе подсказала, что реальное быстродействие здесь может быть резко повышено за счет кеширования. Грубо (очень грубо) говоря, при кешировании все то, что тормозит, будет вызываться в 10 раз реже, и хотя работать будет само по себе не быстрее, но это будет незаметно. Ты это все время в уме держал, поэтому все и получилось хорошо.
В уме я это точно не держал. Ну может быть гдето очень глубоко в темном углу подсознания.
Мне было мягко говоря не до производительности. Нужно было создась гибкую и стройную систему на основе кучи разрозненных и противоречивых требований. Некоторые требования пришлось убрать, другие добавить, третии изменить... все это дело нужно было согласовать... Причем как всегда система была нужна вчера.
PD>А теперь представь себе на минуту, что ты о кешировании никогда не слышал и даже не знаешь, что это слово означает.
Те представить что я не профпригоден? PD>И вот ты сделал свой движок, тормозит он жутко, как сам пишешь, а про кэш ты не знаешь. Или хуже — неприменим здесь кэш. Или не дал результата. И других методов условно говоря внешней оптимизации нет (под внешней я понимаю то, что не относится к архитектуре по твоему же определению)
Я бы назвал это внутренними оптимизациями. Тк они выполняются внутри одного слоя не влияя на интерфейс этого слоя.
В моем случае был код типа такого(в реальной системе сущностей было на много больше):
Причем все объекты были imutable и могли сравниватся на равенство не только по ссылкам но и по состоянию.
Причем данная архитектура была выбрана не по тому что тут открывается огромный простор для оптимизациий начиная от банального кеширования до генерации кода во время работы программы, а по тому что такая архитектура очень устойчива ко всяким недразумениям. И очень легка в поддержке и изменении.
PD> Что делать будешь ?
В четвертый раз все перепишу с учетом производительности. Всеравно это будет быстрее чем постоянно о ней думать.
Хотя последний раз я такими вещами занимался когда писал бинарный diff для бэкапа базы RSDN.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это уже слишком все же. Речь изначально шла о том, как вывести некие данные в некоем формате. Этот формат был задан мной для демонстрации того, где лучше использовать последовательный вывод, а где нет. Сам формат просто предложен для демонстрации (запись разреженной матрицы в определенном формате) Теперь оказывается, что fseek нужен не для того, чтобы выводит в файл наилучшим по моему мнению методом именно для этого формата, а вообще для того, чтобы уменьшить объем хранимых данных!!!
Есть задача и есть решение этой задачи.
Если стоит задача сохранить и востановить разряженую матрицу то использования fseek не оправданно и это тебе показали.
Также небыло продемонстрированно ни одного случая когда при необходимости сохранить и востановить состояние объекта нужен был бы произвольный доступ.
Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается.
Также произвольный доступ нужен при выполнении запросов. Это я про матрицу со средними значениями. Ибо мы востанавливаем объект не в том состоянии в котором он был до сохранения.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Во-первых, для нашей отрасли не между модулями а между абстракциями, а во-вторых, первый бросающийся в глаза агрумент — типизированность vs нетипизированность. Или оная статическая vs динамическая. Есть и другие аргументы. Погугли насчет того как пишутся критичные к надежности приложния и что там насчет сильной связи.
ослабление связей тоже достигается разными средствами. Использование более слабых видов типизации — только один из них. Уменьшение количества связей, а не их качества — это надежности не повредит, а даже совсем наоборот.
V>В общем, как всегда с ног на голову. Loose coupling — это не самоцель, а лишь один из параметров к оптимизации в наших многомерных задачах. В конкретных случаях, ессно, параметрам раздают конкретные коэффициенты. Ну а далее включаем стандартные механизмы многофакторных оптимизаций с весовыми коеф. и получаем результаты согласно весовых коеф. Все это относится не только к loose coupling, а вообще к любым критериям/параметрам. И именно поэтому не существует "серебрянной пули". В общем, спец должен не только обладать некими знаниями для успешной деятельности, но и уметь их прикладывать по месту.
V>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?
не использовал и не слышал ни от кого, что он серьезно это использует То есть слышать то конечно слышал и даже немного видел, но все те проекты можно смело отнести к разряду псевдонаучной синекуры.
ГВ>>>Нет, глупостью с твоей стороны на самом деле было то, что ты решил, что я обязан видеть в сообщениях других то и только то, что ожидаешь ты и ещё несколько авторов ФП.
ГВ>По существу моего замечания, как я понимаю, тебе возразить нечего? O'K, так и отметим.
по сушеству, говоришь?
Ну во первых — если ты думаешь, что хитроумная словесная эквилибристика — это круто и сразу показывает всем твой неимоверный IQ, то лучше тебе перестать так думать. У нас здесь все-таки не состязания адвокатов.
Во вторых — я не "ожидаю" чего-то услышать ни от кого. Выслушать интересные и оригинальные мысли я готов от любого. Некоторые пишут что-то интересное часто, некоторые — не очень, а некоторые — никогда.
ГВ>Вот здесь
, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:
то, что более сложная операция еще и работает быстрее — это по твоему естественно?
ГВ>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.
рассуждения про .NET он сам начал. Видимо, своё самое первое сообщение ему и надо было похе*ить по факту, а еще лучше перед его совершением?
ГВ>И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".
доказал? что именно доказал и каким образом?
ГВ>Что же до одиозного высказывания
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.
"здесь так принято" и "по историческим причинам" — это стандартные отмазки для решений, принятых по невежеству или недомыслию.
если интерфейс урезает информацию, а быстродействие критично для задачи — значит, надо искать другой интерфейс, вот и всё. Сейчас, к счастью, не 90е годы, выбор имеется.
Даже если выбрать не из чего, длину строки все равно достаточно вычислить один раз — сразу после извлечения инфы. Дальнейшие операции над данными, (если операций будет больше чем одна ), однозначно окупят эту небольшую затрату.
вместо этого наш герой выбирает заведомо неэффективный путь решения задачи и начинает усердно его оптимизировать, положив большой болт на все принципы качественного кодирования — при наличии более быстрого и "чистого" решения
ГВ>Ну, ни ты ни я надо всей индустрией свечку не держали.
я работал в разнообразных областях, и представление о распространенности тех или иных задач имею достаточно хорошее
ГВ>Да даже если и предположить, что в индустрии чаще встречаются задачи, не требующие анализ свойств алгоритмов, это не отменяет необходимости такого анализа в тех случаях, когда это необходимо (это я специально повторяюсь, чтобы не возникало разночтений). А из априорной неизвестности такой необходимости следует, что анализировать в том или ином виде таки нужно всегда (это я снова специально повторился).
ГВ>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?
есть определенная отличная от нуля вероятность, что под кустом, возле которого ты собрался разводить костер, сидит смертельно опасная ядовитая змея. Нужно ли перед разведением костра обшаривать палкой все окрестные кусты? Всё еще уверен, что нужно? А если известно, что дело происходит в Сибири, где самая опасная змея — это всего лишь гадюка, зато на каждом кусте пачками сидят опасные клещи?
ГВ>Нет, не замечаю таких изменений, которые бы подходили под определение разумности. Помощь в навигации — да. Но тенденции к сверхразумности пока не замечаю. Кроссмодульная оптимизация здесь ни при чём — ей как идее сто лет в обед.
никто и не говорит про разумность. Всего лишь автоматизация рутинных операций по оптимизации.
Идея то старая, но достойные практически применимые реализации появились совсем недавно. Как это обычно и бывает.
ГВ>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях.
"не самых благоприятных"?
благоприятнее условия даже придумать сложно
ГВ> Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят.
ГВ>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).
эта священная корова по крайней мере подтвердила свою жизнеспособность в существующих на данный момент условиях. В отличие от.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>"...если умеет думать головой..." Ха-ха-ха. Нет такого человека, который сам бы вывел всю теорию сложности, или функциональный анализ, или топологию. Вот Ньютон говорил: "я стоял на плечах гигантов".
LCR>Чтобы вырваться из клетки невежества нужен проводник.
для этого нужны карты. А проводник нахрен не нужен, если это Сусанин.
Здравствуйте, vdimas, Вы писали:
V>Не раздавай впредь ярлыков насчет недоучек, ok? То свое заявление насчет ассемблера я сделал после примерно 3-х летнего участия/чтения rsdn и не хуже тебя знаю, какие мнения на этот счет здесь ходят. Тем не менее счел возможным озвучить. Сможешь опровергнуть меня более быстрым своим кодом на "высокооптимизируемом" С++ — welcome. Не сможешь — держишь свои соображения насчет "неучей" при себе. (Кста, если обратил внимание, я тусуюсь ближе к лагерю сторонников С++ в местных баталиях)
интересно, почему вдруг сопоставление "С++ vs ручное кодирование" првератилось в "мой код против твой код"? Вероятно, чтобы потом доказать, что мой код ни на что не годится? Ну так я и не позиционирую себя как программиста на ассемблере. Я на нем уже лет десять не писал, если тебе это так интересно.
Я всего лишь сказал, что код современного компилятора мало кто способен превзойти по скорости. Ты можешь это сделать? Прекрасно, очень хорошо для тебя. Желательно подтвердить это фактами, конечно. Но если не можешь, я попробую поверить на слово
V>Разница в том, что в случае Б в тим-лидерах и более старших руководителях ходили люди, гораздо менее ориентирующиеся в своей специальности, чем рядовые программисты. Такое действиетльно наблюдалось часто.. довольно давно... Сейчас мне такой сценарий кажется маловероятным. Ответ на эти твои длинные копи-пейсты содержался в самом начале, см. выделенное.
если руководители не разбираются в предмете, то нет никакой разницы, идиоты их подчиненные или нет. Они все равно не смогут заметить разницы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А собственно, почему ? Из чего следует, что они есть ? Я призываю думать и о реализации — мне говорят — у Вас проблемы с абстрагированием. Если я про абстрагирование вообще почти не говорю, потому что это для меня просто промежуточный этап, то из этого следует, что я вообще это делать не умею ?
PD>Мягко выражаясь, странная логика.
странноватая логика — это начинать описывать свои рассуждения с конца. В особенности, когда тебя спрашивают про начало и ты не можешь внятно про него рассказать.
Никакого внятного объяснения, почему для ускорения скорости работы со строками ты выбрал ASCIIZ-строки, я так и не добился.
Здравствуйте, Дарней, Вы писали:
Д>Ну во первых — если ты думаешь, что хитроумная словесная эквилибристика — это круто и сразу показывает всем твой неимоверный IQ, то лучше тебе перестать так думать. У нас здесь все-таки не состязания адвокатов.
Овладевайте предметом, что я могу ещё сказать? Можно проще — не бросайте слов на ветер. Они ведь, как воробей...
Д>Во вторых — я не "ожидаю" чего-то услышать ни от кого.
Да, согласен, возможно, что я сделал неправильное предположение относительно твоих ожиданий. Но это был единственный способ охарактеризовать мотивацию возникшего противостояния. Возможно, что я и здесь ошибаюсь.
Д>Выслушать интересные и оригинальные мысли я готов от любого. Некоторые пишут что-то интересное часто, некоторые — не очень, а некоторые — никогда.
, 19.10.2005 некто Wolfhound представли публике совершенно некорректный и неуместный тест, где сравнивал конкатенацию и форматирование. Естественно, придя к "обескураживающему" выводу: C# быстрее C++. Зачем он это сделал — вопрос спорный, но я подозреваю, что искать рациональные обоснования здесь попросту бессмысленно:
Д>то, что более сложная операция еще и работает быстрее — это по твоему естественно?
ветку дискуссии. Читать с 24-го по 33-е сообщение. Дальше уже "разводка" началась: Дворкин привёл заведомо искусственный пример и к этому примеру прицепились.
Повторяю исходный пример вместе с условиями: на входе N 'const char*' без дополнительной информации. Выполнить конкатенацию за минимальное время. Общая длина всех N строк никогда (то есть, вообще, то есть — совсем никогда, даже на Марсе) не превысит 500 байт. Наводящий вопрос 1: куда будем std::string совать (не забывая о том, что std::string по умолчанию работает с malloc/free)? Наводящий вопрос 2: что такое фрагментация памяти? Наводящий вопрос 3: а что, если заказчик запретит использовать C++ не говоря уже о .Net?
ГВ>>После этого все рассуждения о .Net должны были быть пох..ены по факту. Кстати, и о C++ — тоже. Но нет! .Net-аплогеты уже сели на любимого конька и понеслась.
Д>рассуждения про .NET он сам начал. Видимо, своё самое первое сообщение ему и надо было похе*ить по факту, а еще лучше перед его совершением?
А он его и не о том писал, о чём нектороые подумали. Я понимаю, что ПД совершил нецензурное действие — упомянул .Net не в благоговейном смысле.
ГВ>>И хотя Дворкину вполне удалось доказать свои слова по части оценок производительности, но борцам за свободу .Net видать, глаза застило, потому в ход пошла тяжёлая флеймогонная артиллерия. То есть, в дальнейшем контраругемнтация строилась на совершенно шикарном принципе: реализация на C неправильна по определению. Это называется "кино и немцы!".
Д>доказал? что именно доказал и каким образом?
Он доказал, что безопасные подходы напрочь "сливают" по быстродействию перед потенциально опасным, но обдумано применённым. Прости, но твой пример с strcat совершенно не подходит, поскольку strcat попросту не передаёт нужной информации пользователю, а именно — указатель на конец результирующей строки. Без этой маленькой детали поточные операции конкатенации налетают на оверхед, связанный либо с обновлением поля длины, либо с необходимостью вычисления длины строки заново.
ГВ>>Что же до одиозного высказывания
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.
Д>"здесь так принято" и "по историческим причинам" — это стандартные отмазки для решений, принятых по невежеству или недомыслию.
В огороде бузина, в Киеве пальцем в небо тычут. Да, верно. "исторические причины" часто становятся отмазками. Ровно до тех пор, пока не столкнёшься со следствиями этих исторических причин без возможности на них повлиять. Дальше можно возопить к небесам и предать интерфейс анафеме. Говорят, помогает медитация на тотем.
Извини моё ёрничество, но оснований к твоему утверждению об отмазках я в той одиозной дискуссии не заметил. Если желаешь — докажи обратное. С удовольствие соглашусь с тобой, если оказался неправ.
Д>если интерфейс урезает информацию, а быстродействие критично для задачи — значит, надо искать другой интерфейс, вот и всё. Сейчас, к счастью, не 90е годы, выбор имеется.
Я уже напоминал цитату, не буду повторяться. Не было возможности использовать C++. Да он и не нужен при обсуждаемых операциях.
Д>Даже если выбрать не из чего, длину строки все равно достаточно вычислить один раз — сразу после извлечения инфы. Дальнейшие операции над данными, (если операций будет больше чем одна ), однозначно окупят эту небольшую затрату.
А вот фокус как раз в том, что судя по всему операция ОДНА, так что остальные рассуждения отбрасываются по факту их неприменимости.
Д>вместо этого наш герой выбирает заведомо неэффективный путь решения задачи и начинает усердно его оптимизировать, положив большой болт на все принципы качественного кодирования — при наличии более быстрого и "чистого" решения
К счастью, этой задачей занимался не кодер, нахватавшийся "правильных" принципов, а вменяемый программист. С чем я ПД вкупе с его заказчиками и поздравляю.
ГВ>>Ну, ни ты ни я надо всей индустрией свечку не держали. Д>я работал в разнообразных областях, и представление о распространенности тех или иных задач имею достаточно хорошее
Сие наблюдение не имеет доказательного значения, поскольку неизвестны а) условия, б) твоё влияние на контекст. Так что, делать выводы относительно всей индустрии, пока не соберёшь справки ото всех — бессмысленно.
ГВ>>Иными словами, не анализировать алгоритмику в том или ином виде это примерно как идти по лесу с завязанными глазами. Бесспорно, что вероятнее всего, что некоторое время шишку себе не набьёшь... Ну что, на ближайшем пикнике будем сугубо с завязанными глазами ходить?
Д>есть определенная отличная от нуля вероятность, что под кустом, возле которого ты собрался разводить костер, сидит смертельно опасная ядовитая змея. Нужно ли перед разведением костра обшаривать палкой все окрестные кусты? Всё еще уверен, что нужно?
Ты исходишь об априорном знании о ядовитости змей и вероятности их появления. Так что, пример не в кассу.
Вообще, я считаю, что в такие места лучше не ходить, а поляну под пикник, буде приспичило, подготавливать огнемётом.
Д>А если известно, что дело происходит в Сибири, где самая опасная змея — это всего лишь гадюка, зато на каждом кусте пачками сидят опасные клещи?
Тогда причём тут змея? Нужно думать о противоэнцефалитной прививке, не правда ли?
Одним словом, в своих примерах ты забываешь о том, что некоторое знание о контексте у тебя уже есть. Я же приводил свой пример для иллюстрации некоторого "предельного" состояния — отказ от анализа вообще. Однако, пример правомерен, поскольку такой тезис (об отсутсвтвии необходимости предварительного анализа алгоритмов) неоднократного приводился оппонентами Дворкина. Дескать, сначала абстракция — потом разбираемся.
ГВ>>Нет, не замечаю таких изменений, которые бы подходили под определение разумности. Помощь в навигации — да. Но тенденции к сверхразумности пока не замечаю. Кроссмодульная оптимизация здесь ни при чём — ей как идее сто лет в обед.
Д>никто и не говорит про разумность. Д>Всего лишь автоматизация рутинных операций по оптимизации. Д>Идея то старая, но достойные практически применимые реализации появились совсем недавно. Как это обычно и бывает.
Верно подмечено. Потому-то это и не означает эпохального прорыва. Задачи кроссмодульной оптимизации в случае того же самого C++ давным-давно решаются посредством шаблонов и совершенно классической оптимизации на уровне одного модуля. Актуальной КМО стала при активном использовании языков типа Java, где нет явного inline. Тогда как Java... Впрочем, это уже тема для другого флейма.
ГВ>>Почитал, как видишь. И ничего предосудительного в позиции и высказываниях ПД не обнаружил. Он говорит о культуре и излагает решение некоторой конкретной задачи в конкретных, не самых благоприятных с точки зрения современных технологий условиях.
Д>"не самых благоприятных"? Д>благоприятнее условия даже придумать сложно
Ух ты!!!? То есть, явное требование применять только C — это просто таки благоприятнейшие условия для .Net?
ГВ>> Ему в ответ начинают гнать местами откровенную пургу с одной лишь, как представляется, конечной целью: доказать священость священной коровы по имени Делайпоследуматьбудем, и что новые технологии рулят. ГВ>>Кстати, тот самый упомянутый мною тест, опубликованный Wolfhound как раз мычание той самой Делайпоследуматьбудем (три раза "ку" при упоминании всуе).
Д>эта священная корова по крайней мере подтвердила свою жизнеспособность в существующих на данный момент условиях. В отличие от.
А ты знаешь, кого вообще больше? Цитату напомнить? Она касалась, казалось бы, умнейших людей планеты... Так что, на основании жизнеспособности того или иного бзика далекоидущие выводы делать не стоит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
V>>Во-первых, для нашей отрасли не между модулями а между абстракциями, а во-вторых, первый бросающийся в глаза агрумент — типизированность vs нетипизированность. Или оная статическая vs динамическая. Есть и другие аргументы. Погугли насчет того как пишутся критичные к надежности приложния и что там насчет сильной связи.
Д>ослабление связей тоже достигается разными средствами. Использование более слабых видов типизации — только один из них.
Чудовищно опасный способ, кстати. Как с позиций производительности, так и с позиций надёжности.
Д>Уменьшение количества связей, а не их качества — это надежности не повредит, а даже совсем наоборот.
Что есть "качество связи"?
V>>Кстати, вопрос на засыпку. Кто когда в последний раз что-либо расчитвал из характеристик своих систем и расчитывал ли вообще хоть раз?
Д>не использовал и не слышал ни от кого, что он серьезно это использует То есть слышать то конечно слышал и даже немного видел, но все те проекты можно смело отнести к разряду псевдонаучной синекуры.
Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
ГВ>>Вот как раз то, что не всегда уязвимость есть уязвимость Дворкин тщетно пытался объяснить своим оппонентам. Я отлично понимаю, что приведённый фрагмент кода — одна из распространённейших уязвимостей. Только всё зависит от задачи. И если Дворкин утверждает, что на 200% уверен в том, что суммарная длина szFisrtName + szLastName не превысит буфера, то, почему-то, я ему верю. Кстати, его утверждение об уверенности на 200% никак не может отрицать необходимости оценки задачи для выбора подобного утверждения. WH>Нет. Уязвимость это всегда уязвимость.
А давай не будем путать понятия (1) потенциально опасный код и (2) уязвимость программы? (1) может и не означать (2), а вот обратное, как правило, верно.
WH>Даже есть это и не будет уязвимостью пока код править только Павел но когда код начнет править кто-то еще...
Ну, если к тому времени условия поменяются так, что будет снято ключевое требование к быстродействию, а вместо него появится требование устойчивости к изменениям внешних данных, то тогда такая программа с большой вероятностью будет переписана полностью... На данный же момент ситауция, как я понимаю, такая, что вероятность модификации небольшая, а ламеров к модификации не подпустят.
ГВ>>Я про всех никаких посылок сделать не мог. Ибо сам являюсь частью этих самых "всех" и от .Net ну совсем не фанатею. А вот то, что .Net был приплетён к той самой дискуссии не совсем по месту — уверен до сих пор. WH>Ладно сведем понятие все до Я, Влад и Антон.
O'K
ГВ>>Как совершенно справедливо утверждает Дворкин, истина всегда конкретна (у нас же не метафизичисеский форум, верно?). WH>Дело в том что этот форум именно что метафизический...
Ага. Значит, применять некие некорректные но "конкретные" аргументы для опровержения некоей "метафизической" истины — это правильно? Мда. Дзен-буддисты нервно медитируют в сторонке.
ГВ>>И в рамках конкретных, озвученных им условий его решение нельзя признать неадекватным. Тогда как контрпримеры — более чем не к месту. WH>Контрпримеры чего? Того что операции над строками с длинной будут по крайней мере не медленней чем операции над строками с терминатором в конце?
Да не откуда там было взять длины-то. Ты c const char* никогда не работал, что-ли?
ГВ>>...ASCIIZ-формат долеко не так глуп, как тебе кажется. Дело в том, что таким образом мы избавляемся от необходимости синхронизировать информацию о длине в поле длины с фактической длиной строки. То есть, сама строка становится защищённой от ошибок рассинхронизации данных. [...] WH>А вот с этого места по подробней пожалуйста. Чем установка терминатора в конце надежней установки длинны в начале? Не понимаю.
Тем, что не требует модификаций дополнительного отвлечённого от содержания строки поля. Строка получается "самодокументированной". Достаточно плюхнуть '\0' в нужном месте и получаем строку. Конкатенация тоже выполняется просто: найти в строке-назначении 0 и скопировать, начиная с этого адреса, указанную строку. Потом поставить 0 по адресу следующего за последним символа. И здесь не требуется, например, отслеживать смещение от начала строки, так что, такая операци применима, например, при поточной передаче данных.
Второй вариант выглядит более сложным и более подверженным ошибкам... ИМХО, разумеется.
Кроме того, нет необходимости выбирать и фиксировать размер поля длины. Каким оно должно быть? 1 байт (паскаль)? 2 (часто хватает)? 4 (почти предел)? 8 (хватит надолго)? 16 (навсегда?)? Байт длины длины + означенное им значение (на случай споров)? Всех этих заморочек удаётся избежать, когда символьный поток просто разрезается терминаторами. Поскольку меньше заморочек — меньше и приколов. Автоматы обработки строк можно строить не опасаясь переполнения счётчика позиции, к примеру. А это тоже предотвращает ряд проблем в некоторых случаях.
Но я, разумеется, не собираюсь агитировать за повсеместный переход на const char*...
ГВ>>А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием. Я надеюсь, ты не об этом
: WH>Меня сегодня чегото поиск не взлюбил А просматривать сотни сообщений...
Я подожду. Да и Дворкин, похоже, заинтересовался.
ГВ>>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами. WH>Нам джидаям...
...завсегда везде ништяк? Так чего тогда спорите?
ГВ>>Очень хорошо. Более того, я даже отлично понимаю, о чём конкретно ты говоришь, произнося сии лозунги. Ещё более того, я отлично понимаю, какое влияние на тебя предварительно оказал C++ и свойственные ему подходы к проектированию. Я только в одном не уверен. В том, что это поймёт тот, кто не имеет за плечами опыт работы с C++. Не сочти за переход на личности, будь добр. WH>Вот только я сам довольно долго избавлялся от полюсовых замашек... мой плюсовый опыт в основном лежит в категории как делать не надо. В этом смысле плюсовый опыт несомненно ценен. Но плюсовые методы я не использую.
Я не говорил о прямом переносе методов. Я говорил о влиянии C++. В чём конкретно оно выражается в твоём случае — трудно сказать. Ну хоть в отборе неправильных методов. Тоже результат опыта.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что есть "качество связи"?
это как раз использование разной степени слабости типизации
ГВ>Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй?
Здравствуйте, Дарней, Вы писали:
ГВ>>Что есть "качество связи"? Д>это как раз использование разной степени слабости типизации
То есть, связь с использованием слабой типизации — низкокачественная, а связь с использованием сильной типизации — высококачественная?
ГВ>>Ну вот видишь, а делаешь выводы космического масштаба обо всей индустрии. Ну как тебе не ай-яй-яй? Д>а у нас вся индустрия такая по ней и сужу
Странная у вас индустрия...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
LCR>>Чтобы вырваться из клетки невежества нужен проводник. Д>для этого нужны карты. А проводник нахрен не нужен, если это Сусанин.
Да добро бы карты, а то, пачка Беломора предлагается...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Sinclair>>Поскольку он был воспитан на микроконтроллерах, где всю работу со строками надо было делать вручную
PD>Можно узнать — откуда эта информация ? Дело в том, что с микроконтроллерами я, насколько себя помню, никогда в жизни дела не имел. Нет такого в моей биографии. Это, конечно, печально, но вот нет... PD>Так что сообщите пожалуйста, кто обо мне такую дезинформацию дает.
Вот так и создаются мифы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>То есть, связь с использованием слабой типизации — низкокачественная, а связь с использованием сильной типизации — высококачественная?
нет, они просто разные
ГВ>Странная у вас индустрия...
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Овладевайте предметом, что я могу ещё сказать? Можно проще — не бросайте слов на ветер. Они ведь, как воробей...
не понял. каким предметом? искусством софистики, что ли?
ГВ>Повторяю исходный пример вместе с условиями: на входе N 'const char*' без дополнительной информации. Выполнить конкатенацию за минимальное время. Общая длина всех N строк никогда (то есть, вообще, то есть — совсем никогда, даже на Марсе) не превысит 500 байт.
конкатенация и прочие операции над полученными строками там выполняются далеко не один раз.
ГВ>Наводящий вопрос 2: что такое фрагментация памяти?
наводящий вопрос — что такое кэширование буферов и TLS?
ГВ>Наводящий вопрос 3: а что, если заказчик запретит использовать C++ не говоря уже о .Net?
а если он вообще запретит использовать строки с длиной?
ГВ>А он его и не о том писал, о чём нектороые подумали. Я понимаю, что ПД совершил нецензурное действие — упомянул .Net не в благоговейном смысле.
Пд совершил нецензурное действие — взялся ругать то, в чем не разбирается.
ГВ>Он доказал, что безопасные подходы напрочь "сливают" по быстродействию перед потенциально опасным, но обдумано применённым. Прости, но твой пример с strcat совершенно не подходит, поскольку strcat попросту не передаёт нужной информации пользователю, а именно — указатель на конец результирующей строки. Без этой маленькой детали поточные операции конкатенации налетают на оверхед, связанный либо с обновлением поля длины, либо с необходимостью вычисления длины строки заново.
это актуально только в том случае, если строки часто передаются в/из внешний asciiz-based код, а расходы на собственно обработку данных невелики. ПД сам сказал, что основной затык по скорости был при обработке строк внутри программы.
ГВ>В огороде бузина, в Киеве пальцем в небо тычут. Да, верно. "исторические причины" часто становятся отмазками. Ровно до тех пор, пока не столкнёшься со следствиями этих исторических причин без возможности на них повлиять. Дальше можно возопить к небесам и предать интерфейс анафеме. Говорят, помогает медитация на тотем.
у нас сейчас не 90е годы, и такое встречается редко
ГВ>Извини моё ёрничество, но оснований к твоему утверждению об отмазках я в той одиозной дискуссии не заметил. Если желаешь — докажи обратное. С удовольствие соглашусь с тобой, если оказался неправ.
я имел несчастье следить за этой дискуссией долгое время, и у меня сложилось именно такое впечатление. ПД сначала решил, как сделать — а потом придумал, почему надо делать именно так. Ничем другим его невнятные объяснения я объяснить не могу.
ГВ>А вот фокус как раз в том, что судя по всему операция ОДНА, так что остальные рассуждения отбрасываются по факту их неприменимости.
это уже твои домыслы. ПД сам заявлял противоположное.
ГВ>Ты исходишь об априорном знании о ядовитости змей и вероятности их появления. Так что, пример не в кассу.
ну а как же. Когда ты собираешься делать проект, у тебя же должна быть хотя бы общая информация о возможных проблемах?
ГВ>Вообще, я считаю, что в такие места лучше не ходить, а поляну под пикник, буде приспичило, подготавливать огнемётом.
тогда тебе в армию наверно надо. там тоже любят радикальные решения
ГВ>Тогда причём тут змея? Нужно думать о противоэнцефалитной прививке, не правда ли?
при том, что из возможных рисков надо выбирать самые значимые. Алгоритмические сложности могут входить в их число, а могут и не входить. Равно как и необходимость написания низкоуровневого кода.
ГВ>Одним словом, в своих примерах ты забываешь о том, что некоторое знание о контексте у тебя уже есть. Я же приводил свой пример для иллюстрации некоторого "предельного" состояния — отказ от анализа вообще. Однако, пример правомерен, поскольку такой тезис (об отсутсвтвии необходимости предварительного анализа алгоритмов) неоднократного приводился оппонентами Дворкина. Дескать, сначала абстракция — потом разбираемся.
А кто предлагает отказываться от анализа вообще? Такой тезис приводил только сам Дворкин — "оптимизируй везде, где можно"
ГВ>Верно подмечено. Потому-то это и не означает эпохального прорыва. Задачи кроссмодульной оптимизации в случае того же самого C++ давным-давно решаются посредством шаблонов и совершенно классической оптимизации на уровне одного модуля. Актуальной КМО стала при активном использовании языков типа Java, где нет явного inline. Тогда как Java... Впрочем, это уже тема для другого флейма.
А эпохального прорыва и не будет. Есть только эволюция, и игнорировать ее результаты просто глупо.
ГВ>Ух ты!!!? То есть, явное требование применять только C — это просто таки благоприятнейшие условия для .Net?
ух ты! почему то я не заметил во флейме тезиса ".NET это фигня, потому что мне запретили его использовать в проекте"
ГВ>А ты знаешь, кого вообще больше? Цитату напомнить? Она касалась, казалось бы, умнейших людей планеты... Так что, на основании жизнеспособности того или иного бзика далекоидущие выводы делать не стоит.
При чем здесь люди и их интеллект?
больше тех технологий, которые лучше умеют выживать. Если Дворкин лучше всех знает, как писать программы, почему его программы никто не использует? Только не надо начинать разговоры про маркетинг — его возможности очень сильно преувеличивают.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кроме того, нет необходимости выбирать и фиксировать размер поля длины. Каким оно должно быть? 1 байт (паскаль)? 2 (часто хватает)? 4 (почти предел)? 8 (хватит надолго)? 16 (навсегда?)? Байт длины длины + означенное им значение (на случай споров)?
Просто так к слову. Есть еще один простой и удобный способ передачи длины строки (да и вообще размерностей). В первом байте размерности задействованы младшие 7 бит под длину. Старший бит выставлен в 0, если младшие биты полностью определяют длину. И в 1, если следом идет байт продолжения размерности. В следующем байте похожая картина -- младшие 7 бит -- это показатели длины (они объединяются с младшими 7-мью битами первого байта). А старший бит является показателем наличия продожения размерности.
Жалко, что я про этот способ раньше не знал Завел у себя 4-х байтовые указатели размерности, а оказалось, что в 99% случаев строки короче 255 символов. Поэтому на каждую короткую строку приходится нулевых байта в указателе размерности. Что при большом количестве маленьких строк выливается в существенный overhead.
А в ASN1 еще какие-то схемы для плавающих размерностей используются. Но это уже совсем другая история...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>Есть задача и есть решение этой задачи. WH>Если стоит задача сохранить и востановить разряженую матрицу то использования fseek не оправданно и это тебе показали.
Точнее, убедили себя в том, что это так. Мне их аргументы убедительными не показались, и от того, что ты повторишь, они убедительнее не станут.
WH>Также небыло продемонстрированно ни одного случая когда при необходимости сохранить и востановить состояние объекта нужен был бы произвольный доступ.
Ну-ну.
WH>Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается.
Например, PE-формат. Придуман очень недпльновидными людьми. Соблюсти его кровь из носу любой линкер обязан
Если несколько часов свободных найдется, уверен, найду еще много. Просто надо структуры файлов сидеть и смотреть
Здравствуйте, Дарней, Вы писали:
ГВ>>Овладевайте предметом, что я могу ещё сказать? Можно проще — не бросайте слов на ветер. Они ведь, как воробей... Д>не понял. каким предметом? искусством софистики, что ли?
Не... я про внятное выражение своих мыслей. Софистика — это уже намного дальше.
ГВ>>Повторяю исходный пример вместе с условиями: на входе N 'const char*' без дополнительной информации. Выполнить конкатенацию за минимальное время. Общая длина всех N строк никогда (то есть, вообще, то есть — совсем никогда, даже на Марсе) не превысит 500 байт. Д>конкатенация и прочие операции над полученными строками там выполняются далеко не один раз.
Мммм... ответ не по теме.
ГВ>>Наводящий вопрос 2: что такое фрагментация памяти? Д>наводящий вопрос — что такое кэширование буферов и TLS?
Ответ не по теме
ГВ>>Наводящий вопрос 3: а что, если заказчик запретит использовать C++ не говоря уже о .Net? Д>а если он вообще запретит использовать строки с длиной?
Слушай, в третий раз напоминаю, что ПД должен был использовтаь только C. Короче, ответ тоже не по теме.
Мдя...
ГВ>>А он его и не о том писал, о чём нектороые подумали. Я понимаю, что ПД совершил нецензурное действие — упомянул .Net не в благоговейном смысле. Д>Пд совершил нецензурное действие — взялся ругать то, в чем не разбирается.
А на основании чего? Подсказка: в заглавном постинге всё было сказано.
ГВ>>Он доказал, что безопасные подходы напрочь "сливают" по быстродействию перед потенциально опасным, но обдумано применённым. Прости, но твой пример с strcat совершенно не подходит, поскольку strcat попросту не передаёт нужной информации пользователю, а именно — указатель на конец результирующей строки. Без этой маленькой детали поточные операции конкатенации налетают на оверхед, связанный либо с обновлением поля длины, либо с необходимостью вычисления длины строки заново. Д>это актуально только в том случае, если строки часто передаются в/из внешний asciiz-based код, а расходы на собственно обработку данных невелики. ПД сам сказал, что основной затык по скорости был при обработке строк внутри программы.
Мммм... ПД кроме строк там ещё много чего упоминал, если не ошибаюсь. Кроме того, тот факт, что его обязали писать на C вполне может свидетельствовать о том, что какая-то часть программы уже была написана. Похоже, что по каким-то причинам её не захотели переписывать. Так что, рановато винить Дворкина в неуместном использовании ASCIIZ. Я же тебе говорю, что рассуждать о глупости "исторических причин" можно ровно до тех пор, пока не столнёшься с их последствиями. например, с интерфейсами, работающими исключительно с ASCIIZ.
ГВ>>В огороде бузина, в Киеве пальцем в небо тычут. Да, верно. "исторические причины" часто становятся отмазками. Ровно до тех пор, пока не столкнёшься со следствиями этих исторических причин без возможности на них повлиять. Дальше можно возопить к небесам и предать интерфейс анафеме. Говорят, помогает медитация на тотем. Д>у нас сейчас не 90е годы, и такое встречается редко
Ну, как видишь, встретилось таки.
ГВ>>Извини моё ёрничество, но оснований к твоему утверждению об отмазках я в той одиозной дискуссии не заметил. Если желаешь — докажи обратное. С удовольствие соглашусь с тобой, если оказался неправ. Д>я имел несчастье следить за этой дискуссией долгое время, и у меня сложилось именно такое впечатление. ПД сначала решил, как сделать — а потом придумал, почему надо делать именно так. Ничем другим его невнятные объяснения я объяснить не могу.
О! Наконец-то. Так вот, дело в том, что однозначные выводы о мотивах, если они не построены на совершенно чёткой и недвусмысленной основе (что в твоём случае не наблюдается, ибо "впечатление", это не основа для утверждения о мотивах) как раз и свидетельствуют о том, что "выводящий" пытается сделать некий, заранее ожидаемый им вывод. Иными словами — подтасовывает факты в свою пользу. Да ещё и с активным использованием приёма "домысел".
ГВ>>А вот фокус как раз в том, что судя по всему операция ОДНА, так что остальные рассуждения отбрасываются по факту их неприменимости. Д>это уже твои домыслы. ПД сам заявлял противоположное.
Кто же спорит, что длина одной строки должна вычисляться один раз! Но надо все же конкатенировать 10000000 раз не одну и ту же, а разные строки. Нет у меня такой зщадачи — одни и те же строки 10000000 раз конкатенировать!
Из этого, на мой взгляд, следует, что над одним и тем же набором строк операция таки проводится одна. И вовсе не следует, что свежеполученная в результате конкатенации строка непременно должна сопровождаться полем длины. Как раз наоброт, ПД упоминал, что оверхед на поля длин был у него не уместен.
ГВ>>Ты исходишь об априорном знании о ядовитости змей и вероятности их появления. Так что, пример не в кассу. Д>ну а как же. Когда ты собираешься делать проект, у тебя же должна быть хотя бы общая информация о возможных проблемах?
Правильно. Только сам факт получения такой информации опровергает тезис о ненужности анализа алгоритмов. Это не софистика. Это просто сопоставление утверждений.
ГВ>>Тогда причём тут змея? Нужно думать о противоэнцефалитной прививке, не правда ли? Д>при том, что из возможных рисков надо выбирать самые значимые. Алгоритмические сложности могут входить в их число, а могут и не входить. Равно как и необходимость написания низкоуровневого кода.
Откуда ты сможешь узнать о том, входят алгоритмические сложности (любого порядка) в число рисков проекта или нет, если ты не проведёшь анализ алгоритмики используемых компонентов? То есть, хот примитивный, хоть поверхностный, хоть ещё какаой, но анализ необходим?
ГВ>>Одним словом, в своих примерах ты забываешь о том, что некоторое знание о контексте у тебя уже есть. Я же приводил свой пример для иллюстрации некоторого "предельного" состояния — отказ от анализа вообще. Однако, пример правомерен, поскольку такой тезис (об отсутсвтвии необходимости предварительного анализа алгоритмов) неоднократного приводился оппонентами Дворкина. Дескать, сначала абстракция — потом разбираемся. Д>А кто предлагает отказываться от анализа вообще? Такой тезис приводил только сам Дворкин — "оптимизируй везде, где можно"
На самом деле, Дворкин говорил об умении писать эффективные программы без этого современного идиотского акцентирования на оптимизации, как на отдельном действии. Понимаешь, когда есть культура эффективного программирования, тогда вопрос об "оптимизируй" встаёт вообще нечасто. Понимаешь?
ГВ>>Верно подмечено. Потому-то это и не означает эпохального прорыва. Задачи кроссмодульной оптимизации в случае того же самого C++ давным-давно решаются посредством шаблонов и совершенно классической оптимизации на уровне одного модуля. Актуальной КМО стала при активном использовании языков типа Java, где нет явного inline. Тогда как Java... Впрочем, это уже тема для другого флейма. Д>А эпохального прорыва и не будет. Есть только эволюция, и игнорировать ее результаты просто глупо.
Ну да, определённая эволюция, конечно, есть. Так я этого и не отрицал.
ГВ>>Ух ты!!!? То есть, явное требование применять только C — это просто таки благоприятнейшие условия для .Net? Д>ух ты! почему то я не заметил во флейме тезиса ".NET это фигня, потому что мне запретили его использовать в проекте"
Мда. Это не тебе надо софистике учиться. Это я у тебя должен уроки брать. Извини, но я не понял, что ты хотел сказать. Я имел ввиду, что в проект, где поставлено требование писать на C трудно воткнуть .Net. В частных случаях это, конечно, может быть не так. А ты что имел ввиду?
ГВ>>А ты знаешь, кого вообще больше? Цитату напомнить? Она касалась, казалось бы, умнейших людей планеты... Так что, на основании жизнеспособности того или иного бзика далекоидущие выводы делать не стоит. Д>При чем здесь люди и их интеллект? Д>больше тех технологий, которые лучше умеют выживать.
Мда. технологии, надо думать, сами живут? Ить, игуаны эдакие.
Д>Если Дворкин лучше всех знает, как писать программы, почему его программы никто не использует? Только не надо начинать разговоры про маркетинг — его возможности очень сильно преувеличивают.
Почему же никто не использует? Он ведь сам говорил о 1000 машин, на которых его программа работает?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Точнее, убедили себя в том, что это так. Мне их аргументы убедительными не показались, и от того, что ты повторишь, они убедительнее не станут.
Что именно не убедительно? То что терминаторы справятся с задачей не хуже чем ручками заданный размер?
Кстати а как ты со своим fseek реализуешь схему типа
Object -> Serializer -> GzipStream -> EncryptStream -> NetStream -> Net -> NetStream -> DecryptStream -> GzipStream -> Deserializer -> Object
Самое смешное то что в Object могут быть гигабайты информации но вот эта цепочка этого даже не почувствует ибо она есть O(1) памяти.
Те твое стремление использовать произвольный доступ везде где он якобы может дать прирост производительности негативно сказывается на архитектуре ибо не возможно проделать то что на потоках делается на раз см выше.
Причем в место NetStream -> Net -> NetStream может быть файл. Те мы без без лишних телодвижений можем сделать сжатый и зашифрованный файл. Либо мы можем загнать BLOB в базу данных. Либо...
Это и есть один из примеров того как ты ради мнимой эффективности ломаешь архитектуру.
WH>>Также небыло продемонстрированно ни одного случая когда при необходимости сохранить и востановить состояние объекта нужен был бы произвольный доступ. PD>Ну-ну.
А разве был?
WH>>Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается. PD>Например, PE-формат. Придуман очень недпльновидными людьми. Соблюсти его кровь из носу любой линкер обязан
Я не силен в PE-формате но если мне не изменяет скалероз то он такой по тому что нужно было на старых машинах обеспечить подгрузку кода кусками.
Сейчас это не актуально но этот формат все еще используют по историческим причинам ибо особого смысла менять его пока нет.
PD>Если несколько часов свободных найдется, уверен, найду еще много. Просто надо структуры файлов сидеть и смотреть
Можешь не искать это например все базы данных. Но они опять таки решают не только и не столько задачу сохранить/загрузить. По этим базам делаются запросы. Плюс вставка/удаление/изменение...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А давай не будем путать понятия (1) потенциально опасный код и (2) уязвимость программы? (1) может и не означать (2), а вот обратное, как правило, верно.
Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
ГВ>Ну, если к тому времени условия поменяются так, что будет снято ключевое требование к быстродействию, а вместо него появится требование устойчивости к изменениям внешних данных, то тогда такая программа с большой вероятностью будет переписана полностью... На данный же момент ситауция, как я понимаю, такая, что вероятность модификации небольшая, а ламеров к модификации не подпустят.
И не надо ламеров подпускать. Дастаточно того что человек просто по невнимательности эделает косяк. Как ты думаешь зачем программы обильно посыпают asseret'ами?
ГВ>Да не откуда там было взять длины-то. Ты c const char* никогда не работал, что-ли?
Длинну всегда посчитать можно.
ГВ>Тем, что не требует модификаций дополнительного отвлечённого от содержания строки поля. Строка получается "самодокументированной". Достаточно плюхнуть '\0' в нужном месте и получаем строку.
И чем это лучше длинны в начале строки? ГВ>Конкатенация тоже выполняется просто: найти в строке-назначении 0 и скопировать, начиная с этого адреса, указанную строку.
А если так "найти в строке из 1000000 символов 0"? ГВ>Потом поставить 0 по адресу следующего за последним символа. И здесь не требуется, например, отслеживать смещение от начала строки,
А в чем проблема то? Где это модет повредить? ГВ>так что, такая операци применима, например, при поточной передаче данных.
А вот это вобще к делу не относится. Причем тут поток?
ГВ>Второй вариант выглядит более сложным и более подверженным ошибкам... ИМХО, разумеется.
Вот только второй вариант будет выглядить так
ГВ>Кроме того, нет необходимости выбирать и фиксировать размер поля длины.
Это пожалуй единственное преймущество. Вот только стоит ли оно всех тех недостатков? ГВ>Каким оно должно быть? 1 байт (паскаль)? 2 (часто хватает)? 4 (почти предел)? 8 (хватит надолго)? 16 (навсегда?)? Байт длины длины + означенное им значение (на случай споров)? Всех этих заморочек удаётся избежать, когда символьный поток просто разрезается терминаторами. Поскольку меньше заморочек — меньше и приколов.
Все просто... достаточно int'а. ГВ>Автоматы обработки строк можно строить не опасаясь переполнения счётчика позиции, к примеру. А это тоже предотвращает ряд проблем в некоторых случаях.
Автоматы работают с потоком, а не со строкой. А превратить строку какого угодно формата в поток проблем не составляет.
ГВ>...завсегда везде ништяк? Так чего тогда спорите?
По тому что вы утверждаете что нам хреново и вобще лоб до крови разбит...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается. PD>>Например, PE-формат. Придуман очень недпльновидными людьми. Соблюсти его кровь из носу любой линкер обязан WH>Я не силен в PE-формате но если мне не изменяет скалероз то он такой по тому что нужно было на старых машинах обеспечить подгрузку кода кусками. WH>Сейчас это не актуально но этот формат все еще используют по историческим причинам ибо особого смысла менять его пока нет.
Ну ты и насмешил ))) Потрясающе просто! Фантастическое невежество!!!!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не... я про внятное выражение своих мыслей. Софистика — это уже намного дальше.
внятное выражение своих мыслей не включает в себя построение перегруженных предложений. Тебя обманули и научили чему-то совсем другому, а не внятному выражению сових мыслей.
ГВ>Мммм... ответ не по теме.
с какой это радости?
ГВ>Ответ не по теме
правда?
ГВ>Слушай, в третий раз напоминаю, что ПД должен был использовтаь только C. Короче, ответ тоже не по теме.
ГВ>Мдя...
как интересно. ты объявляешь не относящимся к теме все, что не укладывается в твою стройную теорию?
ГВ>А на основании чего? Подсказка: в заглавном постинге всё было сказано.
ничего там не было сказано. Сплошная демагогия.
ГВ>Мммм... ПД кроме строк там ещё много чего упоминал, если не ошибаюсь. Кроме того, тот факт, что его обязали писать на C вполне может свидетельствовать о том, что какая-то часть программы уже была написана. Похоже, что по каким-то причинам её не захотели переписывать. Так что, рановато винить Дворкина в неуместном использовании ASCIIZ. Я же тебе говорю, что рассуждать о глупости "исторических причин" можно ровно до тех пор, пока не столнёшься с их последствиями. например, с интерфейсами, работающими исключительно с ASCIIZ.
и опять пошли твои домыслы, чтобы оправдать сделанные заранее умопостроения. Где там было такое написано, можешь показать?
ГВ>Ну, как видишь, встретилось таки.
ага. такое часто встречается, когда разработчик застрял в 90ом году, когда на дворе уже год 2006
ГВ>О! Наконец-то. Так вот, дело в том, что однозначные выводы о мотивах, если они не построены на совершенно чёткой и недвусмысленной основе (что в твоём случае не наблюдается, ибо "впечатление", это не основа для утверждения о мотивах) как раз и свидетельствуют о том, что "выводящий" пытается сделать некий, заранее ожидаемый им вывод. Иными словами — подтасовывает факты в свою пользу. Да ещё и с активным использованием приёма "домысел".
И на основании чего я, по твоему, сделал этот "ожидаемый вывод"?
Пока что я вижу, что ты сам сделал "ожидаемый вывод" насчет "ожидаемого вывода" у меня и теперь пытаешься подогнать под это факты.
ГВ>Кто же спорит, что длина одной строки должна вычисляться один раз! Но надо все же конкатенировать 10000000 раз не одну и ту же, а разные строки. Нет у меня такой зщадачи — одни и те же строки 10000000 раз конкатенировать! ГВ>[/q]
А вот здесь ПД опять путается в показаниях. То у него сложнейшие операции над строками, то вдруг тысячи одинаковых конкатенаций над разными строками
ГВ>Правильно. Только сам факт получения такой информации опровергает тезис о ненужности анализа алгоритмов. Это не софистика. Это просто сопоставление утверждений.
не нужно носиться по лесу полгода с ружьем, чтобы сделать выводы о наличии или отсутствии в данном лесу волков. Достаточно посмотреть в энциклопедию или спросить специалиста — в этом обычно и заключается "исследование".
ГВ>Откуда ты сможешь узнать о том, входят алгоритмические сложности (любого порядка) в число рисков проекта или нет, если ты не проведёшь анализ алгоритмики используемых компонентов? То есть, хот примитивный, хоть поверхностный, хоть ещё какаой, но анализ необходим?
ага. см выше
ГВ>На самом деле, Дворкин говорил об умении писать эффективные программы без этого современного идиотского акцентирования на оптимизации, как на отдельном действии. Понимаешь, когда есть культура эффективного программирования, тогда вопрос об "оптимизируй" встаёт вообще нечасто. Понимаешь?
понимаю, но не согласен. Этой точке зрения сто лет в обед, и она себя давно уже дискредитировала.
ГВ>Ну да, определённая эволюция, конечно, есть. Так я этого и не отрицал.
ну хоть это ты наконец сказал.
Д>>ух ты! почему то я не заметил во флейме тезиса ".NET это фигня, потому что мне запретили его использовать в проекте"
ГВ>Мда. Это не тебе надо софистике учиться. Это я у тебя должен уроки брать. Извини, но я не понял, что ты хотел сказать. Я имел ввиду, что в проект, где поставлено требование писать на C трудно воткнуть .Net. В частных случаях это, конечно, может быть не так. А ты что имел ввиду?
А к чему ПД вообще заговорил о .NET? написал прогу, в которой его нельзя было использовать, и пришел к выводу о его ущербности? Ой, держите меня трое
ГВ>Мда. технологии, надо думать, сами живут? Ить, игуаны эдакие.
именно так. Люди придумывают идеи, а дальше они живут уже самостоятельно. Или не живут.
ГВ>Почему же никто не использует? Он ведь сам говорил о 1000 машин, на которых его программа работает?
я так и не услышал ни мнения пользователей программы, ни программистов, которые поддерживают его код.
Здравствуйте, denis_krg, Вы писали:
_>Ну ты и насмешил ))) Потрясающе просто! Фантастическое невежество!!!!
Все знать не возможно. Почитал про PE признаю был не прав.
Однако у меня к тебе есть вопрос: Сохранит ли PE актуальность с приходом таких ОС как Singularity?
Что-то мне подсказывает что там будут использованы поточные форматы бинарников.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Однако у меня к тебе есть вопрос: Сохранит ли PE актуальность с приходом таких ОС как Singularity? WH>Что-то мне подсказывает что там будут использованы поточные форматы бинарников.
Боюсь, это будет актуально только для самых юных участников форума. Остальные уже перестанут программировать к тому времени.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
ГВ>>А давай не будем путать понятия (1) потенциально опасный код и (2) уязвимость программы? (1) может и не означать (2), а вот обратное, как правило, верно. WH>Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
Твоё утверждение, в сущности, никак моему не противоречит, поскольку ты говоришь всего лишь о "подавляющем большинстве", а не однозначной зависимости. Я не спорю, что в некоторых (назови их "частыми", или, даже "подавляюще частыми", суть не изменится) случаях, потенциально опасный код приводит к уязвимостям. И также есть некоторые случаи (их тоже кто-то может назвать "частыми" и "подавляюще частыми"), когда эта уязвимость не появляется.
Так что, будем считать, что договорились.
ГВ>>Ну, если к тому времени условия поменяются так, что будет снято ключевое требование к быстродействию, а вместо него появится требование устойчивости к изменениям внешних данных, то тогда такая программа с большой вероятностью будет переписана полностью... На данный же момент ситауция, как я понимаю, такая, что вероятность модификации небольшая, а ламеров к модификации не подпустят. WH>И не надо ламеров подпускать. Дастаточно того что человек просто по невнимательности эделает косяк. Как ты думаешь зачем программы обильно посыпают asseret'ами?
По невнимательности человек может сделать совершенно произвольный косяк. Так что, возражение не в кассу.
ГВ>>Да не откуда там было взять длины-то. Ты c const char* никогда не работал, что-ли? WH>Длинну всегда посчитать можно.
Зачем, если ПД несколько раз говорил, что оверхед, связанный с вычислением длины ему мешал?
<обсуждение ASCIIZ>
ГВ>>Тем, что не требует модификаций дополнительного отвлечённого от содержания строки поля. Строка получается "самодокументированной". Достаточно плюхнуть '\0' в нужном месте и получаем строку. WH>И чем это лучше длинны в начале строки?
Ну, как минимум тем, что не пришлось менять некое значение. Условное преимущество, конечно. Ну а потом, имея строку длины Z мы можем ещё реинтерпретировать её как Z разных строк, если считать от начала строки.
ГВ>>Конкатенация тоже выполняется просто: найти в строке-назначении 0 и скопировать, начиная с этого адреса, указанную строку. WH>А если так "найти в строке из 1000000 символов 0"?
Согласен, что с оверхедом.
ГВ>>Потом поставить 0 по адресу следующего за последним символа. И здесь не требуется, например, отслеживать смещение от начала строки, WH>А в чем проблема то? Где это модет повредить?
Ну как... Дополнительно либо counter либо указатель на начало болтается. Что-то суммировать надо (длину одной строки и другой), писать куда-то совсем не туда, куда указатели направлены. Гимор, да и только.
ГВ>>так что, такая операци применима, например, при поточной передаче данных. WH>А вот это вобще к делу не относится. Причем тут поток?
К примеру, маленький буфер, через который прокачивается строка, длина котрой определяется во время "прокачки". И куда здесь поле длины толкать, когда начало строки уже уехало?
ГВ>>Второй вариант выглядит более сложным и более подверженным ошибкам... ИМХО, разумеется. WH>Вот только второй вариант будет выглядить так WH>
А что такое string_length() ?
ГВ>>Кроме того, нет необходимости выбирать и фиксировать размер поля длины. WH>Это пожалуй единственное преймущество. Вот только стоит ли оно всех тех недостатков?
Ну, сие вопрос риторический. На данный момент мы имеем поддержку строковых операций на уровне команд x86.
ГВ>>Каким оно должно быть? 1 байт (паскаль)? 2 (часто хватает)? 4 (почти предел)? 8 (хватит надолго)? 16 (навсегда?)? Байт длины длины + означенное им значение (на случай споров)? Всех этих заморочек удаётся избежать, когда символьный поток просто разрезается терминаторами. Поскольку меньше заморочек — меньше и приколов. WH>Все просто... достаточно int'а.
Уверен? На совсем-совсем-совсем? И даже на тот случай, когда у тебя вся (вся!) память — 1 Мб, а строки длиной 10 символов в среднем и их много-много штук?
ГВ>>Автоматы обработки строк можно строить не опасаясь переполнения счётчика позиции, к примеру. А это тоже предотвращает ряд проблем в некоторых случаях. WH>Автоматы работают с потоком, а не со строкой. А превратить строку какого угодно формата в поток проблем не составляет.
А так и превращать ничего не надо.
Ладно, чтобы не разводить флейм, предлагаю дискуссию об особеностях формата ASCIIZ закрыть. У него есть свои плюсы и минусы, как и у всякой вещи. Я свои соображения изложил, можешь с ними соглашаться, можешь — не соглашаться. Факт налицо, на данный момент софт и хард активно поддерживает операции с ASCIIZ и в том или ином виде от него почти никуда не денешься.
</обсуждение ASCIIZ>
ГВ>>...завсегда везде ништяк? Так чего тогда спорите? WH>По тому что вы утверждаете что нам хреново и вобще лоб до крови разбит...
Цитату в студию! Или, хотя бы, обоснования! У меня, вот основания для точь-в-точь такого же утверждения, но в противоположную сторону, более чем есть:
WH>Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
Это у "нас" должна быть куча неприятностей при таких делах-то!
Да, кстати, всё ещё жду:
WH>>>>При том что Павел признался что формировал этот фаил сам... Вот прикол то... Сам сформировал и сам жалуется что длинну не положил...
ГВ>>>А вот тут я настоятельно попрошу у тебя урлчик на сообщение с признанием.
ГВ>>>... повторно попрошу урлчик на утверждение о генерации файла.
WH>>Меня сегодня чегото поиск не взлюбил А просматривать сотни сообщений...
ГВ>Я подожду. Да и Дворкин, похоже, заинтересовался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Было бы неплохо, если бы ты сохранил исходные вопросы и контекст.
ГВ>>Мммм... ответ не по теме. Д>с какой это радости?
Потому что ты пытаешься изменить начальные условия задачи.
ГВ>>Ответ не по теме Д>правда?
Да, это не имеет отношения к вопросу об учёте malloc/free
ГВ>>Слушай, в третий раз напоминаю, что ПД должен был использовтаь только C. Короче, ответ тоже не по теме. ГВ>>Мдя... Д>как интересно. ты объявляешь не относящимся к теме все, что не укладывается в твою стройную теорию?
Какая же это, к чертям, теория? Сам ПД и сказал, что нужно было писать на C. Проект до него начали, он там не с начала участвовал...
ГВ>>А на основании чего? Подсказка: в заглавном постинге всё было сказано. Д>ничего там не было сказано. Сплошная демагогия.
Докажи. Ну хоть на примере некоторых высказываний из первоначального постинга ПД
.
ГВ>>Мммм... ПД кроме строк там ещё много чего упоминал, если не ошибаюсь. Кроме того, тот факт, что его обязали писать на C вполне может свидетельствовать о том, что какая-то часть программы уже была написана. Похоже, что по каким-то причинам её не захотели переписывать. Так что, рановато винить Дворкина в неуместном использовании ASCIIZ. Я же тебе говорю, что рассуждать о глупости "исторических причин" можно ровно до тех пор, пока не столнёшься с их последствиями. например, с интерфейсами, работающими исключительно с ASCIIZ. Д>и опять пошли твои домыслы, чтобы оправдать сделанные заранее умопостроения. Где там было такое написано, можешь показать? Здесь:
S>Такой метод обязан быть private. Он должен быть обложен всеми мыслимыми ассертами, и документация обязана содержать четкое упоминание о том, как его можно вызывать.
ПД>А он у меня не метод был. Он просто функция был, потому что (сейчас я тебя испугаю) весь проект не на С++, а на С делался. Приины мне неизвестны, но повлиять я не мог, потому что вошел в проект отнюдь не в его начали.
И была эта функция не то что private , а super private. Потому как описана она была у меня static, а в этот файл изменения имел право вносить только я . Из других частей проекта ее вызвать нельзя было никаким способом.
Естественно, здесь не написано, что внутренние интерфейсы были исключительно ASCIIZ-based. Но и отрицать этого тоже нельзя. А поскольку Дворкину всё-таки пришлось использовать ASCIIZ, получаем, что так таки, с какими-то последствиями "истории" он столкнулся не имея возможности их изменить.
ГВ>>Ну, как видишь, встретилось таки. Д>ага. такое часто встречается, когда разработчик застрял в 90ом году, когда на дворе уже год 2006
Однако, деваться разработчику оказалось некуда.
ГВ>>О! Наконец-то. Так вот, дело в том, что однозначные выводы о мотивах, если они не построены на совершенно чёткой и недвусмысленной основе (что в твоём случае не наблюдается, ибо "впечатление", это не основа для утверждения о мотивах) как раз и свидетельствуют о том, что "выводящий" пытается сделать некий, заранее ожидаемый им вывод. Иными словами — подтасовывает факты в свою пользу. Да ещё и с активным использованием приёма "домысел". Д>И на основании чего я, по твоему, сделал этот "ожидаемый вывод"?
Домыслов, батенька. Только на сновании домыслов о том, что современные технологии a priori круче "старых" по всем без исключения статьям. А вот что послужило спусковым крбчком для самих домыслов? Ну, пока этот вопрос остаётся без однозначного ответа.
Д>Пока что я вижу, что ты сам сделал "ожидаемый вывод" насчет "ожидаемого вывода" у меня и теперь пытаешься подогнать под это факты.
Странно, если ты домысливаешь что-то, то почему сделать сие очевидное наблюдение, суть подогнать твои рассуждения под некий ожидаемый вывод?
ГВ>>Кто же спорит, что длина одной строки должна вычисляться один раз! Но надо все же конкатенировать 10000000 раз не одну и ту же, а разные строки. Нет у меня такой зщадачи — одни и те же строки 10000000 раз конкатенировать!
Д>А вот здесь ПД опять путается в показаниях. То у него сложнейшие операции над строками, то вдруг тысячи одинаковых конкатенаций над разными строками
Ну так, сложность она и есть совокупность массы простых вещей. Что здесь неправильно? Или нужно непременно, ну... скажем... считать кубический корень из логарифма суммы дисперсии и среднеквадратичного отклонения символов в строке?
И чем тебя удивитело то, что над набором данных проводится серия совершенно одинаковых операций? Это всегда называлось обработкой данных. Или расчётом производных значений. В чём путаница?
ГВ>>Правильно. Только сам факт получения такой информации опровергает тезис о ненужности анализа алгоритмов. Это не софистика. Это просто сопоставление утверждений. Д>не нужно носиться по лесу полгода с ружьем, чтобы сделать выводы о наличии или отсутствии в данном лесу волков. Достаточно посмотреть в энциклопедию или спросить специалиста — в этом обычно и заключается "исследование".
Какая разница, в чём именно оно заключается? Вопрос ставится для начала так: нужно делать такое исследование или нет?
ГВ>>Откуда ты сможешь узнать о том, входят алгоритмические сложности (любого порядка) в число рисков проекта или нет, если ты не проведёшь анализ алгоритмики используемых компонентов? То есть, хот примитивный, хоть поверхностный, хоть ещё какаой, но анализ необходим? Д>ага. см выше
Ну и славно. Значит, по этому пункту всё-таки договорились.
ГВ>>На самом деле, Дворкин говорил об умении писать эффективные программы без этого современного идиотского акцентирования на оптимизации, как на отдельном действии. Понимаешь, когда есть культура эффективного программирования, тогда вопрос об "оптимизируй" встаёт вообще нечасто. Понимаешь? Д>понимаю, но не согласен. Этой точке зрения сто лет в обед, и она себя давно уже дискредитировала.
Пример вашего спора с Дворкиным сие опровергает.
ГВ>>Ну да, определённая эволюция, конечно, есть. Так я этого и не отрицал. Д>ну хоть это ты наконец сказал.
Да.
Д>>>ух ты! почему то я не заметил во флейме тезиса ".NET это фигня, потому что мне запретили его использовать в проекте" ГВ>>Мда. Это не тебе надо софистике учиться. Это я у тебя должен уроки брать. Извини, но я не понял, что ты хотел сказать. Я имел ввиду, что в проект, где поставлено требование писать на C трудно воткнуть .Net. В частных случаях это, конечно, может быть не так. А ты что имел ввиду? Д>А к чему ПД вообще заговорил о .NET? написал прогу, в которой его нельзя было использовать, и пришел к выводу о его ущербности? Ой, держите меня трое
Цитату в студию. Об "общей ущербности .Net". Только не надо мне кивать в сторону всей дискуссии в целом. Докажи, короче. ИМХО, тезис об "ущербности .Net" не более, чем ваша выдумка.
ГВ>>Мда. технологии, надо думать, сами живут? Ить, игуаны эдакие. Д>именно так. Люди придумывают идеи, а дальше они живут уже самостоятельно. Или не живут.
И правда, метафизический спор получается. Ну ладно. Давай, ты поведаешь мне о своей встрече с какой-нибудь идеей. Мне вот, обычно приходится сталкиваться только с воплощением чьих-то идей. Или, на худой конец — с описанием. А вот так, чтобы прямо с самостоятельно живущей идеей — этого не было. Может, пропустил чего?
ГВ>>Почему же никто не использует? Он ведь сам говорил о 1000 машин, на которых его программа работает? Д>я так и не услышал ни мнения пользователей программы, ни программистов, которые поддерживают его код.
Ух ты! А может, тебе ещё и финансовый отчёт о деятельности предприятия-заказчика принести? Так ведь, и ему не поверишь, поди! Cкажешь — неправильно посчитан.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Боюсь, это будет актуально только для самых юных участников форума. Остальные уже перестанут программировать к тому времени.
1)ИМХО это наступит гораздо раньше.
2)Формат бинарников будет какатся только разработчиков ОС ибо разработчики компиляторов будут использовать встроеное в ОС API (что-то типа System.Reflection.Emit) для формирования бинарников. И даже авторы декомпиляторов не станут возится с бинарным форматом, а используют API ОС.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Твоё утверждение, в сущности, никак моему не противоречит, поскольку ты говоришь всего лишь о "подавляющем большинстве", а не однозначной зависимости. Я не спорю, что в некоторых (назови их "частыми", или, даже "подавляюще частыми", суть не изменится) случаях, потенциально опасный код приводит к уязвимостям. И также есть некоторые случаи (их тоже кто-то может назвать "частыми" и "подавляюще частыми"), когда эта уязвимость не появляется.
Потенциально опасный код не ставший уязвимостью это то самое исключения из правила. Так что потенциально опасный код писать нельзя.
ГВ>По невнимательности человек может сделать совершенно произвольный косяк. Так что, возражение не в кассу.
Еще как в кассу. Если человек сделал косяк и программа при первом же запуске об этом ему сказало то это одно. А вот если программа начала падать через месяц после совершенно безобидных правок это совсем другое.
ГВ>Зачем, если ПД несколько раз говорил, что оверхед, связанный с вычислением длины ему мешал?
Павел много чего говорил вот только в большинстве случаев можно было сделать иначе не потеряв при этом ничего кроме потенциальных неприятностей.
WH>>А если так "найти в строке из 1000000 символов 0"? ГВ>Согласен, что с оверхедом.
А если еще новый буфер под результат выделить надо...
ГВ>Ну как... Дополнительно либо counter либо указатель на начало болтается. Что-то суммировать надо (длину одной строки и другой), писать куда-то совсем не туда, куда указатели направлены. Гимор, да и только.
Для этого пишутся несколько инлайн функций и никакого гемороя.
ГВ>К примеру, маленький буфер, через который прокачивается строка, длина котрой определяется во время "прокачки". И куда здесь поле длины толкать, когда начало строки уже уехало?
Не понял. Зачем это надо. Какую задачу ты решаешь?
ГВ>А что такое string_length() ?
чтото типа
int string_length(const char* str)
{
return ((int*)str)[-1];
}
ГВ>Ну, сие вопрос риторический. На данный момент мы имеем поддержку строковых операций на уровне команд x86.
А это еще одна "гениальная" мысль когото из разработчиков железа... Чтоб ты знал... эти операции ни один современный компилятор не использует ибо от них нет ничего кроме тормозов на современных процессорах...
ГВ>Уверен? На совсем-совсем-совсем? И даже на тот случай, когда у тебя вся (вся!) память — 1 Мб, а строки длиной 10 символов в среднем и их много-много штук?
Все очень сильно зависит от задачи. Если мне нужно будет впихнуть невпихуемое то я еще и не такие фокусы использовать начну. Вот только таких задач исчезающе малое колличество.
ГВ>А так и превращать ничего не надо.
Это не есть серьезное преймущество.
ГВ>>>...завсегда везде ништяк? Так чего тогда спорите? WH>>По тому что вы утверждаете что нам хреново и вобще лоб до крови разбит... ГВ>Цитату в студию! Или, хотя бы, обоснования!
Да ни вопрос.
WH>Тут опять неверная посылка и соответсвенно не верные выводы. Об алгоритмах думают но в большинстве задач не в первую очередь.
Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
(С)Геннадий Васильев
ГВ>У меня, вот основания для точь-в-точь такого же утверждения, но в противоположную сторону, более чем есть: ГВ>
WH>>Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
ГВ>Это у "нас" должна быть куча неприятностей при таких делах-то!
Дык они что называется на лицо... Постоянно в программах находять дырки с переполнением буфера...
ГВ>Да, кстати, всё ещё жду:
Я мог не так понять Павла так что пусть он ответит на это
Здравствуйте, eao197, Вы писали:
E>Жалко, что я про этот способ раньше не знал Завел у себя 4-х байтовые указатели размерности, а оказалось, что в 99% случаев строки короче 255 символов. Поэтому на каждую короткую строку приходится нулевых байта в указателе размерности. Что при большом количестве маленьких строк выливается в существенный overhead.
Э... Не знаю откуда и почему, у меня где-то на задворках сознания лежит информация о том, что скорость работы с 32-х битовыми числами будет быстрее, нежели, скажем, с 8 или 16 битовыми на 32-х разрядных процессорах. Может кто-нибудь более внятно, нежели я, прокомментировать это?
Здравствуйте, WolfHound, Вы писали:
E>>Боюсь, это будет актуально только для самых юных участников форума. Остальные уже перестанут программировать к тому времени. WH>1)ИМХО это наступит гораздо раньше.
Ах, этот дивный новый мир! Завтра уже наступило!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Anton Batenev, Вы писали:
E>>Жалко, что я про этот способ раньше не знал Завел у себя 4-х байтовые указатели размерности, а оказалось, что в 99% случаев строки короче 255 символов. Поэтому на каждую короткую строку приходится нулевых байта в указателе размерности. Что при большом количестве маленьких строк выливается в существенный overhead.
AB>Э... Не знаю откуда и почему, у меня где-то на задворках сознания лежит информация о том, что скорость работы с 32-х битовыми числами будет быстрее, нежели, скажем, с 8 или 16 битовыми на 32-х разрядных процессорах. Может кто-нибудь более внятно, нежели я, прокомментировать это?
Имелся в виду оверхед по размеру. На каждую короткую строку приходилось три нулевых байта. Всегда.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Так что потенциально опасный код писать нельзя.
Не везде. Всё зависит от условий.
ГВ>>По невнимательности человек может сделать совершенно произвольный косяк. Так что, возражение не в кассу. WH>Еще как в кассу. Если человек сделал косяк и программа при первом же запуске об этом ему сказало то это одно. А вот если программа начала падать через месяц после совершенно безобидных правок это совсем другое.
Страшилок можно придумать много. Я, вон, про хождение в лесу, ты — стандартную из серии программистских.
ГВ>>Зачем, если ПД несколько раз говорил, что оверхед, связанный с вычислением длины ему мешал? WH>Павел много чего говорил вот только в большинстве случаев можно было сделать иначе не потеряв при этом ничего кроме потенциальных неприятностей.
В его условиях? Ты уверен?
ГВ>>Ну как... Дополнительно либо counter либо указатель на начало болтается. Что-то суммировать надо (длину одной строки и другой), писать куда-то совсем не туда, куда указатели направлены. Гимор, да и только. WH>Для этого пишутся несколько инлайн функций и никакого гемороя.
Откуда в языке C инлайн-функции? Токмо дефайны.
ГВ>>К примеру, маленький буфер, через который прокачивается строка, длина котрой определяется во время "прокачки". И куда здесь поле длины толкать, когда начало строки уже уехало? WH>Не понял. Зачем это надо. Какую задачу ты решаешь?
Например, отправляю строку по сети обычным send(). На начало отправки длина строки неизвестна.
ГВ>>А что такое string_length() ? WH>чтото типа WH>
ГВ>>Ну, сие вопрос риторический. На данный момент мы имеем поддержку строковых операций на уровне команд x86. WH>А это еще одна "гениальная" мысль когото из разработчиков железа... Чтоб ты знал... эти операции ни один современный компилятор не использует ибо от них нет ничего кроме тормозов на современных процессорах...
Но факта наличия это не отменяет. Выводы из этого можно делать любые.
ГВ>>Уверен? На совсем-совсем-совсем? И даже на тот случай, когда у тебя вся (вся!) память — 1 Мб, а строки длиной 10 символов в среднем и их много-много штук? WH>Все очень сильно зависит от задачи. Если мне нужно будет впихнуть невпихуемое то я еще и не такие фокусы использовать начну. Вот только таких задач исчезающе малое колличество.
Значит, авторам ASCIIZ количество таких задач не казалось исчезающе малым.
ГВ>>А так и превращать ничего не надо. WH>Это не есть серьезное преймущество.
А я так и не думаю.
ГВ>>>>...завсегда везде ништяк? Так чего тогда спорите? WH>>>По тому что вы утверждаете что нам хреново и вобще лоб до крови разбит... ГВ>>Цитату в студию! Или, хотя бы, обоснования! WH>Да ни вопрос. WH>
WH>>Тут опять неверная посылка и соответсвенно не верные выводы. Об алгоритмах думают но в большинстве задач не в первую очередь.
WH>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами.
WH>(С)Геннадий Васильев
Это утверждение следует из ваших же посылок о том, что анализировать алгоритмы не нужно. Однако, поскольку лоб не разбит, то значит, всё-таки анализируете? Значит, можно поздравить с "соврамши"?
ГВ>>У меня, вот основания для точь-в-точь такого же утверждения, но в противоположную сторону, более чем есть: ГВ>>
WH>>>Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
ГВ>>Это у "нас" должна быть куча неприятностей при таких делах-то! WH>Дык они что называется на лицо... Постоянно в программах находять дырки с переполнением буфера...
Да, это верно. Но я и не пытаюсь защищать повсеместное использование небезопасного кода. Да и ПД — тоже.
ГВ>>Да, кстати, всё ещё жду: WH>Я мог не так понять Павла так что пусть он ответит на это
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>Может я не так понял но мне почемуто мерещится что при расказе о той программе где тебе позарез нужно было уложится в 100 мсек ты говорил про то что генерировал какойто фаил?
Именно не так. В одном месте я говорил про 100 мсек, а в другом — про mmf. Я, кроме этого, еще много о чем в разных местах говорил, если все смешать в окрошку, то можно будет доказать без труда, что я развязал первую мировую войну .
WH>Ссылку найти что-то не получается.
Поищи.
PD>>Архитектура правильная — это замечательно. Никто и не предлагает неправильную реализовать. Так что это опустим как тривиальность. WH>Правильность архитектуры понятие растяжимое. Очень растяжимое и у разных людей оно очень разное...
Ну здравствуйте. Ты говоришь — правильная. Я с тобой соглашаюсь, при том, что я ее и в глаза не видел. Оказывается, и с этим соглашаться тоже не всегда надо — могут высказать недовольство.
PD>>А вот что касается эффективности — у тебя подсознательно сработал прежний личный опыт или даже не опыт, а полученная ранее откуда-то информация. И она тебе подсказала, что реальное быстродействие здесь может быть резко повышено за счет кеширования. Грубо (очень грубо) говоря, при кешировании все то, что тормозит, будет вызываться в 10 раз реже, и хотя работать будет само по себе не быстрее, но это будет незаметно. Ты это все время в уме держал, поэтому все и получилось хорошо. WH>В уме я это точно не держал. Ну может быть гдето очень глубоко в темном углу подсознания.
Вот именно. Работаешь ты не первый год, опыт есть. Представь себе, что тебе пришлось бы нечто вроде FAR писать. Ну и что, ты не используешь (пусть подсознательно) свой прежний опыт ? Ты же знаешь , как ФС работает (да пусть как юзер даже) , чего от нее можно ждать...
WH>Мне было мягко говоря не до производительности. Нужно было создась гибкую и стройную систему на основе кучи разрозненных и противоречивых требований. Некоторые требования пришлось убрать, другие добавить, третии изменить... все это дело нужно было согласовать... Причем как всегда система была нужна вчера.
PD>>А теперь представь себе на минуту, что ты о кешировании никогда не слышал и даже не знаешь, что это слово означает. WH>Те представить что я не профпригоден?
Господи, зачем же так! Я просто пример привел. Если обидел — извини.
Именно потому, что ты профессионально пригоден, ты и решился писать не самым эффективным способом, подсознательно понимая, что резервы есть. Ну а если их нет ? Или подсознание тебя обманет ? Или это не ты, а кто-то другой, и опыт у небольшой. Провалится он в этой ситуации как пить даст.
PD>> Что делать будешь ? WH>В четвертый раз все перепишу с учетом производительности. Всеравно это будет быстрее чем постоянно о ней думать.
Ну дай бог тебе успеха. Вообще-то, если времени много, то можно и так, не спорю.
Но вот на один вопрос ответь. По сути и ты, и AndrewYK, если отбросить шелуху, предлагаете классический подход "сверху вниз". В проектировании его использование общепринято. Но почему все же не сочетать его с элементами "снизу вверх" ? Ну спроектировали что-то на верхнем уровне абстракций, выделили подсистему работы с файлами, определили ее интерфейс, почему не сделать тест и не попробовать, что в модельной ситуации будет (пример с прокси-сервером, который Андрей привел). И с сетью тоже. Я решительно не понимаю, что в этом плохого. Зачем ждать до того момента, когда то ли будет работать с нужными характеристиками, то ли нет, вместо того, чтобы просто узнать — а такое вообще возможно ? Ведь времени на этот тест — 2 дня, подумаешь, проблема — создать тест, кот орый будет имитировать создание/удаление/дозапись файлов с той же интенсивностью, что ожидается в реальной работе ? Вмест того, чтобы в четвертый раз переписывать...
Не понимаю. Все это похоже на классическое — давайте ввяжемся в драку, а там видно будет. ИМХО все же стоит оценить последствия до, а не после.
WH>Хотя последний раз я такими вещами занимался когда писал бинарный diff для бэкапа базы RSDN.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Геннадий Васильев, Вы писали:
WH>Вот только практика показывает что потенциально опасный код в подавляющем большинстве случаев рано или позно превращается в уязвимсость.
Как , честно говоря, надоело эти байки слушать...
Уязвимость — где ? В Интернет — сайте, в результате чего дело может кончиться взломом сервера со всеми вытекающим ? Это одно. А , скажите на милость, какая такая уязвимость может быть в программе для квантовой химии, которая близко к интернету не лежала, ни с какими БД не работает ( в крайнем случае из какого-нибудь Акцесса входные данные берет и в xls записывает или еще куда ? Рухнуть она — может. Чертыхнутся и перезапустят. И если это раз в месяц происходит, то и не вспомнят больше об этом. У Вас что, никакие программы на вашем компьютере не падали ? Вы этим падениям счет ведете. что ли ? Если у Вас winrar при архивации упадет, скажите на милость, какая такая здесь уязвимость образуется ?
Что же касается проекта, в котором я участвовал, то никакие ламеры никогда к нему доступа иметь не будут. И интернета на той машине, где он работает, нет просто вообще — он там не нужен. И переделывать если его будут все же, то проверят не раз, и не два, а на полном наборе тестов, которых там (специально посмотрел сейчас) 119495. 5 часов примерно прогон их занимает. А если рухнет — ничего страшного, автоматом перезапустится и продолжит свою работу.
Так что нечего принципы web-индустрии в общие догматы возводить!
Здравствуйте, Геннадий Васильев, Вы писали:
E>>>Боюсь, это будет актуально только для самых юных участников форума. Остальные уже перестанут программировать к тому времени. WH>>1)ИМХО это наступит гораздо раньше. ГВ>Ах, этот дивный новый мир! Завтра уже наступило!
А ведь оно действительно уже наступило... .NET и Java медленно но верно теснят неуправляемые языки.
Правда это пока полумеры ибо эти среды работают по вер неуправляемых ОС.
Но я думаю что рано или позно ОС будут управляемые но бодут иметь VM для запуска легаси приложений.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
E>>>>Боюсь, это будет актуально только для самых юных участников форума. Остальные уже перестанут программировать к тому времени. WH>>>1)ИМХО это наступит гораздо раньше. ГВ>>Ах, этот дивный новый мир! Завтра уже наступило! WH>А ведь оно действительно уже наступило... .NET и Java медленно но верно теснят неуправляемые языки. WH>Правда это пока полумеры ибо эти среды работают по вер неуправляемых ОС. WH>Но я думаю что рано или позно ОС будут управляемые но бодут иметь VM для запуска легаси приложений.
Кхм. Ухожу, ухожу, ухожу. Да, кстати, там, по соседству, Дворкин ответил.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот именно. Работаешь ты не первый год, опыт есть. Представь себе, что тебе пришлось бы нечто вроде FAR писать. Ну и что, ты не используешь (пусть подсознательно) свой прежний опыт ? Ты же знаешь , как ФС работает (да пусть как юзер даже) , чего от нее можно ждать...
Я понятие не имею о том как ФС работает. Все что я о ней знаю это то что файлы можно создавать/удалять/изменять/скопировать/переименовать и получить список файлов по некоторой маске.
На это мои знания о файловых системах вобщемто заканчиваются.
PD>Господи, зачем же так! Я просто пример привел. Если обидел — извини.
Не не обидил. Просто не знание алгоритмов это по определению проф не пригоднось.
PD>Именно потому, что ты профессионально пригоден, ты и решился писать не самым эффективным способом, подсознательно понимая, что резервы есть. Ну а если их нет ? Или подсознание тебя обманет ? Или это не ты, а кто-то другой, и опыт у небольшой. Провалится он в этой ситуации как пить даст.
Да не думал я о производительности. Дело в том что постановка задачи была что типа: Хотим то не знаем что но чтобы было круто, гибко и раширяемо... и вобще у нас тут толпа индусов простаивает им нужно бизнес код пидалить, а системы (вернее одной из ее частей) то и нету.
WH>>В четвертый раз все перепишу с учетом производительности. Всеравно это будет быстрее чем постоянно о ней думать. PD>Ну дай бог тебе успеха. Вообще-то, если времени много, то можно и так, не спорю.
В том то и дело что времини то какраз не много.
PD>Но вот на один вопрос ответь. По сути и ты, и AndrewYK, если отбросить шелуху, предлагаете классический подход "сверху вниз".
Угу. PD>В проектировании его использование общепринято. Но почему все же не сочетать его с элементами "снизу вверх" ?
А зачем? PD>Ну спроектировали что-то на верхнем уровне абстракций, выделили подсистему работы с файлами, определили ее интерфейс, почему не сделать тест и не попробовать, что в модельной ситуации будет (пример с прокси-сервером, который Андрей привел). И с сетью тоже. Я решительно не понимаю, что в этом плохого. Зачем ждать до того момента, когда то ли будет работать с нужными характеристиками, то ли нет, вместо того, чтобы просто узнать — а такое вообще возможно ? Ведь времени на этот тест — 2 дня, подумаешь, проблема — создать тест, кот орый будет имитировать создание/удаление/дозапись файлов с той же интенсивностью, что ожидается в реальной работе ?
А зачем если за это время можно просто реализовать этот интерфейс и посмотреть как он будет работать в реальной системе?
Болие того такое решение даст возможность другим отлаживать свои части системы используя хоть и тормозной но работающий модуль. PD>Вмест того, чтобы в четвертый раз переписывать...
Я переписывал мение 1% кода от всей программы(не считая бизнеслогики)...
PD>Не понимаю. Все это похоже на классическое — давайте ввяжемся в драку, а там видно будет. ИМХО все же стоит оценить последствия до, а не после.
При работе на С++ я действительно предпочитал оценивать последствия до. Но при работе на C# можно себе позволить оценить последствия после и эта оценка гораздо точнее чем оценка до ибо просто не возможно оценить как поведет себя окружение. А можно это благодоря тому что модифицировать программу на C# намного проще и быстрее. И возни с отладкой гораздо меньше.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но вот на один вопрос ответь. По сути и ты, и AndrewYK, если отбросить шелуху, предлагаете классический подход "сверху вниз".
Нет. Сверху вниз это когда проектируется верхний уровень, потом детализируют нижний. Я же предлагал скорее из центра в стороны, когда проектируем минимум функционала минимально просто (все уровни до самого низа), а потом наращиваем мышцу, попутно рефакторя устаревший код.
PD>почему не сделать тест и не попробовать, что в модельной ситуации будет (пример с прокси-сервером, который Андрей привел).
Потому что само приложение намного лучше любого теста.
PD> И с сетью тоже. Я решительно не понимаю, что в этом плохого. Зачем ждать до того момента, когда то ли будет работать с нужными характеристиками, то ли нет, вместо того, чтобы просто узнать — а такое вообще возможно ?
Потому что всего заранее не предусмотришь.
PD>Ведь времени на этот тест — 2 дня, подумаешь, проблема — создать тест, кот орый будет имитировать создание/удаление/дозапись файлов с той же интенсивностью, что ожидается в реальной работе ? Вмест того, чтобы в четвертый раз переписывать...
А ы уверен, что переписывание будет сложнее написания отдельного теста, а потом переноса его в приложение? А ты уверен, что тест на 100% будет соответствовать ситуации с реальным приложением?
Здравствуйте, WolfHound, Вы писали:
WH>Однако у меня к тебе есть вопрос: Сохранит ли PE актуальность с приходом таких ОС как Singularity? WH>Что-то мне подсказывает что там будут использованы поточные форматы бинарников.
Отвечаю вопросом на вопрос. Уж извини. Какие еще экспериментальные ОС ты знаешь? Почему задаю этот вопрос сейчас объясню:
1. Сингулярити еще никто не видел
2. Таких экспериментов ставится десятки, если не сотни, это нормальный процесс.
3. Некоторые идет ОС-осстроители (те, которые пишут ОС, на которых люди работают) перенимают от ОС-осизобретателей. А это не одни и те же люди. Более того, друг друга жутко критикуют и вообще в некотором смысле антогонисты.
P.S. Я не хочу заводить флейм о Сингулярити, но то, что это не более чем еще одна новая идея, которой к тому же в жизни никто не видел (кроме узкого круга экспериментаторов в Майкрософте), это факт. Поэтому приводить даже название этой ОСи в качестве аргумента — более чем некорректно (на настоящий момент!!!)
Здравствуйте, WolfHound, Вы писали:
WH>Я понятие не имею о том как ФС работает. Все что я о ней знаю это то что файлы можно создавать/удалять/изменять/скопировать/переименовать и получить список файлов по некоторой маске. WH>На это мои знания о файловых системах вобщемто заканчиваются.
Милый и уважаемый W...Hound. Программирование — инженерная специальность. А инженерная специальность подразумевает твердое знание ОСНОВ. В нашем случае — знание основ работы современных ОС, знание основ работы файловых систем, механизмов кэширование и т.д. Знание основ распределения памяти (куча) основные грабли разных подходов. Знание основ работы виртуальных машин типа Жабы и ДОТ.нету и знание их недостатков. Принципиальных. Иначе — ты просто кодер. Вася Пупкин так сказать. Отчеты там делать простые, формочки клепать и т.д. То есть чем раньше да Делфи занимался, тем и сейчас, только на ДОТ.нете.
про PE-формат и твоих заяв про Сингулярити. Однако тенденция. И ты еще споришь с безусловно грамотными людьми вроде Павла. Я тебе серьезно говорю, ты изучай подход людей к решению проблем, это классический подход эффективных и успешных разработчиков. Он ничего нового не предлагает, он просто пытается тебе азбуку прочитать.
Далее, просто смешно читать твои посты про "удачную архтитектуру". Детский сад. Ща объясню.
Понимаешь, удачных архитектур не бывает. И обычно непосредственные разработчики это прекрасно знают. И больше всех обычно недовольны и хотят ее еще улучшить. То есть больше всего критикуют архитектуру непосредственные разработчики. Это даже не факт, так оно и есть на самом деле. Поверь. Нет идеальных решений. Конечно если ты не прочитал впервые книжку вроде "Банда четырех" или что-то еще. Тогда некоторые начинают просто на них молиться. Надеюсь, что не так.
У меня тоже есть свои архитектурные решения. И знаешь, я не буду их хвалить. Наоборот, переписываю по частям. Сервер приложения свой фактически. Почему и как — не спрашивай, но задача серьезная. 3 года как занимаюсь, экономический эффект серьезный у нас от этого. Но. Недостатков — валом. Даже больше. Другие есть хвалят. Я — ни за что.
WH>При работе на С++ я действительно предпочитал оценивать последствия до. Но при работе на C# можно себе позволить оценить последствия после и эта оценка гораздо точнее чем оценка до ибо просто не возможно оценить как поведет себя окружение. А можно это благодоря тому что модифицировать программу на C# намного проще и быстрее. И возни с отладкой гораздо меньше.
Фигня. Ни жаба, ни С# не дают такого эффекта. Эффект дают МЕТОДИКИ. Т.е. тест-драйвен-девелопмент, продумывание на бумажке как у eao197. Ну и просто опыт. А на чем писать — не так важно. Хотя, если конечно это в чем-то сопоставимые языки (я про императивные vs декларативные vs функциональные).
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот именно. Работаешь ты не первый год, опыт есть. Представь себе, что тебе пришлось бы нечто вроде FAR писать. Ну и что, ты не используешь (пусть подсознательно) свой прежний опыт ? Ты же знаешь , как ФС работает (да пусть как юзер даже) , чего от нее можно ждать... WH>Я понятие не имею о том как ФС работает. Все что я о ней знаю это то что файлы можно создавать/удалять/изменять/скопировать/переименовать и получить список файлов по некоторой маске. WH>На это мои знания о файловых системах вобщемто заканчиваются.
Вообще-то зря. Это не в укор тебе и не предложение начать изучать исходники ntfs.sys . Но почитать тех же Соломона — Руссиновича не мешает.
У меня сегодня лекция по спецкурсу. Буду им рассказывать про селекторы, дескрипторы, страничный механизм. Чтобы програмировать на высоком уровне — это даром не надо. Даже про 4Г пространство знать необязательно (пока не припрет . А тем не менее на лекции эти ходят, хотя все спецкурсы у нас выбирают студенты, им нужно лишь требуемое количество набрать, а какие именно — они сами решают. И отменять этот спецкурс я не буду.
А раньше я вел такой же спецкурс по BIOS-MS-DOS. int13h, int 21h, int2fh, Partition Table, BPB, FAT, ... Тоже не то, с чем им в реальной работе приходилось сталкиваться потом. И тоже ходили.
PD>>Господи, зачем же так! Я просто пример привел. Если обидел — извини. WH>Не не обидил. Просто не знание алгоритмов это по определению проф не пригоднось.
PD>>Именно потому, что ты профессионально пригоден, ты и решился писать не самым эффективным способом, подсознательно понимая, что резервы есть. Ну а если их нет ? Или подсознание тебя обманет ? Или это не ты, а кто-то другой, и опыт у небольшой. Провалится он в этой ситуации как пить даст. WH>Да не думал я о производительности. Дело в том что постановка задачи была что типа: Хотим то не знаем что но чтобы было круто, гибко и раширяемо... и вобще у нас тут толпа индусов простаивает им нужно бизнес код пидалить, а системы (вернее одной из ее частей) то и нету.
WH>>>В четвертый раз все перепишу с учетом производительности. Всеравно это будет быстрее чем постоянно о ней думать. PD>>Ну дай бог тебе успеха. Вообще-то, если времени много, то можно и так, не спорю. WH>В том то и дело что времини то какраз не много.
Так тем более.
WH>А зачем если за это время можно просто реализовать этот интерфейс и посмотреть как он будет работать в реальной системе?
Если за это же время — тогда да. Но ведь мне доказывали (не говорю ты), что надо сначала прототип сделать, и если выяснится, что он очень медленный, только тогда и улучшать. Что-то мне сдается, что прототип прокси-сервера за 2 дня не сделать... Впрочем, не знаю, я их не писал.
WH>При работе на С++ я действительно предпочитал оценивать последствия до. Но при работе на C# можно себе позволить оценить последствия после и эта оценка гораздо точнее чем оценка до ибо просто не возможно оценить как поведет себя окружение.
(все выделено мной — PD)
Вот это заявление мне кажется очень важным. В сущности, здесь и определяется основная причина моего подспудного недоверия к этой управляемой среде.
На С++ (Pascal, Fortran, Assembler) мы пишем на языке, а делаем машинные коды. Да, конечно, оптимизатор может быть неблестящим. Да, есть много такого, что нам остается неподвластно совсем или частично (WinAPI, FS, ...). Да, есть многопоточность.
Но в своем коде — я хозяин.. Что напишу — то и будет выполняться. Не может в моем коде вдруг неизвестно откуда вылезти новый высокоприоритетный поток и отнять время. Не может там быть захвачено больше адресного пространства и коммитировано памяти, чем я захватил и коммитировал. И т.д.
А вот в управляемой среде — может. Может, GC проснется именно в тот момент, когда для меня лучше всего, чтобы он спал и видел третий сон. Или, наоборот, я молю , чтобы он проснулся и память почистил, а он спит сном праведника. И т.д.
Фактически мы потеряли полный контроль над свои кодом. Эта ситуация не нова — она давно существует в средах программирования, где нет прямой компиляции на машинные коды. В интерпретаторах, проще говоря. В той же FoxPro, к примеру. Там тоже кто-то мусор убирает, потому как иначе нельзя. А когда он это делает — бог его знает.
Вот это мне и не нравится. Ты пишешь — невозможно оценить, как поведет себя окружение.
Поскольку на C# и C++ окружение абсолютно одно и то же, за исключением .Net исполняющей среды, то из этого ясно следует — невозможно оценить поведение именно этой управляемой среды.Не слишком ли это большая плата за удобства этой среды ?
Поверь мне (и ты, и другие) — я вовсе не имею целью эту среду охаять. Кстати, я уже на С# свой первый проект соорудил и деньги за него получил. Удобно писать, не спорю. Я другое хочу понять — что именно мы отдаем за эти удобства ?
Не слишком ли это большая плата за удобства этой среды ,
Здравствуйте, WolfHound, Вы писали:
WH>Потенциально опасный код не ставший уязвимостью это то самое исключения из правила. Так что потенциально опасный код писать нельзя.
Глупость. Если так, то надо абсолютно все в коде проверять. Любой другой код потенциально опасный. Я те серьезно говорю. Поэтому часто код интерфейсный часто стараются покрыть проверками на граничные условия, а дальше, вглубь — пишут как можно эффективней. Еще раз, я не об assert'ах. Их же в релизе нет. Да их везде не поставишь.
WH>>>А если так "найти в строке из 1000000 символов 0"? ГВ>>Согласен, что с оверхедом. WH>А если еще новый буфер под результат выделить надо...
У тебя "а если" слишком много. Читай условие задачи. Оно четкое. Если бы у бабушки... то бабушка была бы дедушкой. Знаешь такую фразу? )))
WH>>Тут опять неверная посылка и соответсвенно не верные выводы. Об алгоритмах думают но в большинстве задач не в первую очередь. WH>Ещё раз. Если необходимость анализа алгоритма неизвестна, то анализировать (по умолчанию) нужно всегда. Если, конечно, мы не хотим уподобиться ходящим по лесу с завязанными глазами. WH>[/q] WH>(С)Геннадий Васильев
Еще раз объясняю — программирование есть инженерная специальность. И чтобы не рухнуло при запуске, чтобы нагрузки тянуло — надо основные узкие места продумывать при проектировании, считать, оценивать. Иначе будет полная фигня. Архитектуру по ходу потом уже не изменишь.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет. Сверху вниз это когда проектируется верхний уровень, потом детализируют нижний. Я же предлагал скорее из центра в стороны, когда проектируем минимум функционала минимально просто (все уровни до самого низа), а потом наращиваем мышцу, попутно рефакторя устаревший код.
Ну пусть так.
PD>>почему не сделать тест и не попробовать, что в модельной ситуации будет (пример с прокси-сервером, который Андрей привел).
AVK>Потому что само приложение намного лучше любого теста.
Не согласен. Тест делается за день от силы, приложение — за месяцы порой.
PD>> И с сетью тоже. Я решительно не понимаю, что в этом плохого. Зачем ждать до того момента, когда то ли будет работать с нужными характеристиками, то ли нет, вместо того, чтобы просто узнать — а такое вообще возможно ?
AVK>Потому что всего заранее не предусмотришь.
+1
PD>>Ведь времени на этот тест — 2 дня, подумаешь, проблема — создать тест, кот орый будет имитировать создание/удаление/дозапись файлов с той же интенсивностью, что ожидается в реальной работе ? Вмест того, чтобы в четвертый раз переписывать...
AVK>А ы уверен, что переписывание будет сложнее написания отдельного теста, а потом переноса его в приложение? А ты уверен, что тест на 100% будет соответствовать ситуации с реальным приложением?
Нет, конечно. Хорош бы я был, если бы заявил, что standalone test будет на 100% соответствовать ситуации с реальным приложением ! Но уж если он не удовлетворяет требованиям — извольте это выкинуть сразу. В реальной жизни лучше не будет, может быть только хуже. Если простенький тест, создающий/читающий файлы в твоем прокси, не справляется с нагрузкой — пиши пропало, эта подсистема работать с требуемыми характеристиками не будет.
А написать такой тест — мне лично работы максимум на 3 часа. И тебе, думаю, тоже. И через 3 часа ты будешь знать, можно ли здесь использовать FAT или NTFS или надо писать свою псевдо-FS.
А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.
Здравствуйте, WolfHound, Вы писали:
WH>>>Хотя если есть какойто очень странный формат придуманный не очень дальновидными людьми и этот формат нужно соблюсти то выбора конечно не остается. PD>>Например, PE-формат. Придуман очень недпльновидными людьми. Соблюсти его кровь из носу любой линкер обязан WH>Я не силен в PE-формате но если мне не изменяет скалероз то он такой по тому что нужно было на старых машинах обеспечить подгрузку кода кусками. WH>Сейчас это не актуально но этот формат все еще используют по историческим причинам ибо особого смысла менять его пока нет.
Ну и ну! Ты хоть что-то про виртуальную память слышал и про то, как она реализована ? И ,кстати, как подгрузка страниц происходит ?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, denis_krg, Вы писали:
WH>Однако у меня к тебе есть вопрос: Сохранит ли PE актуальность с приходом таких ОС как Singularity?
Можно, я отвечу ?
PE — нет. Так же, как умер NE, умрет и PE. Будет что-то иное.
WH>Что-то мне подсказывает что там будут использованы поточные форматы бинарников.
Это будет только если появится поточная форма виртуальной памяти
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Точнее, убедили себя в том, что это так. Мне их аргументы убедительными не показались, и от того, что ты повторишь, они убедительнее не станут. WH>Что именно не убедительно? То что терминаторы справятся с задачей не хуже чем ручками заданный размер? WH>Кстати а как ты со своим fseek реализуешь схему типа WH>Object -> Serializer -> GzipStream -> EncryptStream -> NetStream -> Net -> NetStream -> DecryptStream -> GzipStream -> Deserializer -> Object WH>Самое смешное то что в Object могут быть гигабайты информации но вот эта цепочка этого даже не почувствует ибо она есть O(1) памяти.
С помощью fseek еще много чего нельзя делать. И не надо его совать туда, где он ни при чем — в сетевые потоки.
Кстати, ответь на такой вопрос. А зачем Вам тогда BinaryWriter/Reader ? У него ведь (о ужас!) Seek метод есть. Исключить его, и все дела!
Если ты под "слабой" типизацией подразумеваешь необходимость хотя бы раз приводить вниз по иерархии, то это аналогично отсутствию всякой типизации. Для сохранения строгости типизированности (в случае если уж передизайнить не получилось и приведения вниз имеются) обычно добавляют типизированные методы-касты типа (ToDerived1(), ToDerived2()), которыми снабжают некоего предка и всю его гомоморфную иерархию. Вот эти вот методы, обуспечивающие надежность, повышают внутреннюю связанность иерархии, доводя ее до абсолюта. Ибо система не сможет столь же безопасно работать с типами, которые не были заведомо "вшиты" в систему подобного строгого кастинга.
Д>а у нас вся индустрия такая по ней и сужу
Не принимай все на веру. Нужно отдавать себе отчет, в чем заключается "слабость" связи. Самый лучший способ ее достижения — это использование "хорошо известных" протоколов и интерфейсов, которые "уже и так есть". Базовые сущности фреймворков типа Java/.Net богаты на протоколы и интерфейсы. Хорошо так же если удасться обойтись небольшим числом своих "фреймворковых" абстракций, и вообще замечательно, если фреймворк работает равноценно как с теми сущностями, которые разрабатывались вместе с ним, так и с произвольными другими, удовлетворяющими основным протоколам и интерфейсам фреймворка.
Самый худший способ достижения слабой связанности — это обезличенные приемчики типа object GetSomeObject(object key), и очень специальная обработка в очень интересных ситуациях. Примерно так Microsoft работает с унаследованным COM, и вообще там у них явная каша (что не мудрено, ибо типизированностью там и не пахнет... COM-объекты можно приводить к всевозможным интерфейсам, даже к тем, которые не были задекларированы в списке базовых... В общем, из-за особенностей унаследованной технологии там как образец того, как писать не надо)
------
Еще заметь, что метод object IServiceProvider::GetService(Type serviceType), который служит для организации неимоверно слабой связи, все же мог бы быть типизированным во втором фреймворке, ибо он заведомо возвращает тип-потомок serviceType, который тебе не надо приводить вниз далее чем тип аргумента. Поэтому метод мог бы выглядеть так: ServiceT IServiceProvider::GetService<ServiceT>(). Жаль, что во втором фреймворке этот интерфейс не довели до ума.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А тем не менее на лекции эти ходят, хотя все спецкурсы у нас выбирают студенты, им нужно лишь требуемое количество набрать, а какие именно — они сами решают.
Совершенно нормальное явление. Это, по большему счету, нафиг не нужно, но интересно — потому и ходят. У нас вот тоже был похожий разговор с Владом. Нужно ли рядовому разработчику знать стоимость виртуального вызова по сравнению с прямым и вызовом делегата? Ну и соответственно, рассказывать об этом на семинаре... Нафиг не надо, но интересно.
В принципе через это проходят все. Сначала увлекаются выигрыванием пары тактов процессора при сложении, к этой же категории относится написание игрушек, придумывание своего криптоалгоритма, ect... Поднимите руку кто этого не делал?
Но с появлением опыта и возрастанием задач с которыми приходится сталкиваться, приходит осознание того, что выбор правильного алгоритма даст выигрыш на порядки больше, чем вылизывание неправильного, и для того чтобы все работало хорошо — достаточно выбрать правильный алгоритм, а тратить время на его оптимальную реализацию в конкретной ситуации смысла уже не имеет. Потом понятие "алгоритм" растягивается до понятия "архитектура", а "правильный" начинает включать в себя не только скорость и объем используемых ресурсов, но и стоимость разработки, удобство модификации, ect... Но этот путь до конца проходят не все.
PD>Если за это же время — тогда да. Но ведь мне доказывали (не говорю ты), что надо сначала прототип сделать, и если выяснится, что он очень медленный, только тогда и улучшать. Что-то мне сдается, что прототип прокси-сервера за 2 дня не сделать... Впрочем, не знаю, я их не писал.
А какая разница за сколько, если это уже работающий прототип? Этот код писать придется в любом случае. Важно что его оптимизация займет меньше времени, чем написание тестового проекта, на каждое потенциальное узкое место.
WH>>При работе на С++ я действительно предпочитал оценивать последствия до. Но при работе на C# можно себе позволить оценить последствия после и эта оценка гораздо точнее чем оценка до ибо просто не возможно оценить как поведет себя окружение. PD>(все выделено мной — PD)
PD>Вот это заявление мне кажется очень важным. В сущности, здесь и определяется основная причина моего подспудного недоверия к этой управляемой среде.
... PD> Что напишу — то и будет выполняться. Не может в моем коде вдруг неизвестно откуда вылезти новый высокоприоритетный поток и отнять время. Не может там быть захвачено больше адресного пространства и коммитировано памяти, чем я захватил и коммитировал. И т.д. PD>А вот в управляемой среде — может. Может, GC проснется именно в тот момент, когда для меня лучше всего, чтобы он спал и видел третий сон. Или, наоборот, я молю , чтобы он проснулся и память почистил, а он спит сном праведника. И т.д.
Это паранойя.. Серьезно.
На самом деле WH писал совсем про другое. Эта ситуация возможна в любом ЯП, под окружением понималась вовсе не .Net среда. Поинт в том, что изменить код и поменять алгоритм/архитектуру на правильную, в C# значительно проще, чем в C++, поэтому в C++ приходится принимать решения "до", в управляемых средах можно себе позволить сделать это "после". Игра с прототипом дает гораздо более предсказуемый результат чем игра с абстрактным тестом, и легкость модификации кода позволяет независить от конкретной реализации в момент проектирования.
PD>Не слишком ли это большая плата за удобства этой среды ,
Не слишком.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>почему не сделать тест и не попробовать, что в модельной ситуации будет (пример с прокси-сервером, который Андрей привел).
AVK>>Потому что само приложение намного лучше любого теста.
PD>Не согласен. Тест делается за день от силы, приложение — за месяцы порой.
Это если все и сразу. А если как я предлагал, то само приложение на первом этапе не сильно от теста по объему отличается.
PD>А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.
Так в приложении это функционал в конце концов нужен. Или ты предлагаешь делать одну и ту же работу 2 раза?
Здравствуйте, Merle, Вы писали:
M>Но с появлением опыта и возрастанием задач с которыми приходится сталкиваться, приходит осознание того, что выбор правильного алгоритма даст выигрыш на порядки больше, чем вылизывание неправильного, и для того чтобы все работало хорошо — достаточно выбрать правильный алгоритм, а тратить время на его оптимальную реализацию в конкретной ситуации смысла уже не имеет. Потом понятие "алгоритм" растягивается до понятия "архитектура", а "правильный" начинает включать в себя не только скорость и объем используемых ресурсов, но и стоимость разработки, удобство модификации, ect... Но этот путь до конца проходят не все.
И слава богу. Кто-то занимается драйверами. Кто-то системами кэширования в файловых системах. Кто-то построением оптимальных планов выполнения запросов в СУБД. Кто-то реализацией криптоалгоритмов в смарткартах. И с удовольствием используют знания о стоимости различных операций, полученных в начале карьеры/обучения.
Не все же считают, что полезное современное приложение -- это Web-приложение в паре с РСУБД и повсеместным использованием XML.
M>Поинт в том, что изменить код и поменять алгоритм/архитектуру на правильную, в C# значительно проще, чем в C++, поэтому в C++ приходится принимать решения "до", в управляемых средах можно себе позволить сделать это "после".
Извини, но звучит это не слишком правдоподобно. Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня. Изменить код в C#/Java по сравнению с C++ действительно проще за счет современных IDE и особенностей самих языков (у которых нет стольких неоднозначностей, как в C++). Но вот поменять алгоритм... Мне в свое время довелось в процессе обучения столкнуться с необходимостью смены алгоритма
. И каждый алгоритм сразу же накладывал свои органичения на всю систему в целом. Например, решение СЛАУ методом Халецкого требовало больше памяти из-за чего размерности СЛАУ приходилось ограничивать. А метод итераций для получения приемлимой точности увеличивал время расчета на несколько порядков. Так что сменить алгоритм -- это может означать серьезный пересмотр требований к задачи и условий ее выполнения. И язык, на котором решение делается, может иметь совсем мизерное значение по сравнению с остальными факторами. А уж если про смену архитектуры говорить... Ну например, много ли будет значить язык, если какой-нибудь statefull компонент потребуется переделать в stateless?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, denis_krg, Вы писали:
_>Понимаешь, удачных архитектур не бывает. И обычно непосредственные разработчики это прекрасно знают. И больше всех обычно недовольны и хотят ее еще улучшить. То есть больше всего критикуют архитектуру непосредственные разработчики. Это даже не факт, так оно и есть на самом деле. Поверь. Нет идеальных решений.
+1
Более того, имхо, архитектурные решения, которые нравятся сейчас, сразу после реализации, через какое-то время начинают казаться не такими удачными. А со временем, если проект развивается и сопровождается, требуют изменения чтобы не приходилось затем возюкаться с морально устаревшими решениями.
И объясняется это, имхо, двумя объективными факторами:
1) во время разработки у разработчиков проявляется "замыливание взгляда", т.е. нет свежего и трезвого взгляда на выполняемую работу. Я думаю, многие сталкивались с ошибками, которые никак не обраруживались в конце рабочего дня, но становились совершенно очевидными в начале следующего. С проектированием такая же история;
2) во время разработки могут быть не полностью известны все условия, в которых системе придется работать. И, что так же не редкость, эти условия имеют тенденцию изменяться со временем.
Вот и получается, что то, что казалось красивым, стройным и удачным вначале, перестает быть таковым через полгода-год.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
const char *str = "some very long string";
transmit(str);
transmit(str+5);
Не в упрёк, разумеется. Просто для демонстрации.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
PD>>А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.
AVK>Так в приложении это функционал в конце концов нужен. Или ты предлагаешь делать одну и ту же работу 2 раза?
Одним из результатов такого теста вполне может стать готовый функциональный модуль приложения. Потом он просто встраивается в приложение. У меня, например, так часто бывает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Одним из результатов такого теста вполне может стать готовый функциональный модуль приложения. Потом он просто встраивается в приложение. У меня, например, так часто бывает.
Это ты Дворкину скажи:
А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Это уже слишком все же. Речь изначально шла о том, как вывести некие данные в некоем формате. Этот формат был задан мной для демонстрации того, где лучше использовать последовательный вывод, а где нет. Сам формат просто предложен для демонстрации (запись разреженной матрицы в определенном формате) Теперь оказывается, что fseek нужен не для того, чтобы выводит в файл наилучшим по моему мнению методом именно для этого формата, а вообще для того, чтобы уменьшить объем хранимых данных!!!
Внимательно читаем переписку. Примерно здесь
PD>Нет, это именно те, кто столь любят сериализацию, злоупотребляют ею, плодя при этом файлы длины в N раз больше чем надо и захватывая ОП там, где это совсем не надо.
S>А какое отношение длина файла имеет к сериализации? Ты что, думаешь что fseek волшебным образом ее сократит? Разве что если ты две матрицы поверх друг друга запишешь
Самое непосредственное. При этом будут записаны ненулевые элемениы только. В один проход. И размер волшебным образом сократится — расчеты я сегодня утром приводил, то ли в письме к тебе, скорее к VladD2, посмотри сам.
Это было бы понятно, если бы ты не знал другого способа сократить объем. Однако еще за два дня до этого постинга я написал тебе, как сериализовать разреженную матрицу без fseek. И ты к этому моменту на тот постинг уже ответил, т.е. текст читал. Просто предпочел проигнорировать. Как и вопрос про применение компрессии. Действительно — зачем об этом спорить? Лучше пойти в другую ветку и снова начать рассказывать про какие-то "файлы длины в N раз больше чем надо".
PD>Честно говоря, у меня никакого желания дискутировать нет с теми, кто себе это позволяет. Когда на такие передергивания идут — спорить бессмысленно. Это уже не спор для нахождения истины, а просто желание во что бы то ни было доказать свою правоту. Не гнушаясь при этом ничем.
Ну вот опять. Павел, да, я такой негодяй. Для доказательства своей правоты я не гнушаюсь перечитыванием переписки и называнием вранья враньем, а непонимания — непониманием. Зато я читаю аргументы, и меня можно убедить. Естественно, не при помощи стенаний и заведомо некорректных утверждений.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
я понял, что ты имеешь в виду. Но вопросы системы типов — это еще не все. Существуют еще такие проблемы, как количество и качество зависимостей между модулями, наличие неявных связей в виде "соглашений о логике" и так далее — это всё намного хуже. "Качество зависимостей" — это наличие циркулярных зависимостей, например. Относительно небольшое количество таких связей резко увеличивает свзяность всей системы в целом. Например, во втором фреймворке модули System и System.Configuration стали циркулярно зависимы. Нахрена — непонятно
Здравствуйте, denis_krg, Вы писали:
_>Глупость. Если так, то надо абсолютно все в коде проверять. Любой другой код потенциально опасный. Я те серьезно говорю. Поэтому часто код интерфейсный часто стараются покрыть проверками на граничные условия, а дальше, вглубь — пишут как можно эффективней. Еще раз, я не об assert'ах. Их же в релизе нет. Да их везде не поставишь.
Именно что проверять надо все и везде. По крайней мере строгую защиту памяти (такую как в управляемых средах) отключать нельзя вобще.
Иначе мы имеем то что имеем... нестабильно рабетающий софт и куча вирусов.
_>У тебя "а если" слишком много. Читай условие задачи. Оно четкое. Если бы у бабушки... то бабушка была бы дедушкой. Знаешь такую фразу? )))
Можно подумать у моих опанентов их меньше...
_>Еще раз объясняю — программирование есть инженерная специальность. И чтобы не рухнуло при запуске, чтобы нагрузки тянуло — надо основные узкие места продумывать при проектировании, считать, оценивать. Иначе будет полная фигня. Архитектуру по ходу потом уже не изменишь.
Правда чтоли? А я менял... теперь буду знать что это сделать невозможно...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
про PE-формат
Ну никода я не занимался ни разработкой линкеров, ни разработкой загрузчиков... но если ты думаешь что для меня будет проблоемой изучить PE формат или написатль приложение которое экономит каждый такт то поверь мне ты жестоко заблуждаешься.
Понимаешь для меня всякие там PE, файловые системы и тп это детали реализации абстракций с которыми я работаю. И мне чесно говоря начхать на то как они устроены если у меня не стоит задача работать на этом уровне абстракции.
Просто если следовать твоей логике то при разработке той подсистемы я должен был изучить: Формат сборок .NET, формат PE файлов, знать устройство файловой системы в плоть до того как винт читает информацию,... и еще много другой фигни. Хотя мне было достаточно частично изучить System.Reflection, System.Xml и иметь поток без произвольного доступа. _>и твоих заяв про Сингулярити.
А именно? Только аргументированно пожалуйста. _>Однако тенденция. И ты еще споришь с безусловно грамотными людьми вроде Павла. Я тебе серьезно говорю, ты изучай подход людей к решению проблем, это классический подход эффективных и успешных разработчиков. Он ничего нового не предлагает, он просто пытается тебе азбуку прочитать.
Я этот подход не хуже Павла знаю. Просто для меня это пройденный этап.
_>Далее, просто смешно читать твои посты про "удачную архтитектуру". Детский сад. Ща объясню.
Ню-ню. _>Понимаешь, удачных архитектур не бывает.
Идеальных не бывает это да. А вот достаточно хорошие те удачные вполне. _>И обычно непосредственные разработчики это прекрасно знают. И больше всех обычно недовольны и хотят ее еще улучшить. То есть больше всего критикуют архитектуру непосредственные разработчики. Это даже не факт, так оно и есть на самом деле. Поверь. Нет идеальных решений. Конечно если ты не прочитал впервые книжку вроде "Банда четырех" или что-то еще. Тогда некоторые начинают просто на них молиться. Надеюсь, что не так.
Если ты думаешь что я хоть одну свою программу считаю идеальной то ты заблуждаешься. Другое дело что если я считаю что программа достаточно хлороша для тех задач которые она решает я не потрачу на нее больше ни секунды времени.
_>У меня тоже есть свои архитектурные решения. И знаешь, я не буду их хвалить. Наоборот, переписываю по частям. Сервер приложения свой фактически. Почему и как — не спрашивай, но задача серьезная. 3 года как занимаюсь, экономический эффект серьезный у нас от этого. Но. Недостатков — валом. Даже больше. Другие есть хвалят. Я — ни за что.
Я вот тоже пишу серверы приложений и тоже прекрасно знаю все недостатки. Другое дело что недостаток недостатку рознь.
Если недостаток серьезный (мешает жить) то приоретет его исправления очень высокий ибо чем дольше он будет оставатся тем сложнее его будет исправить.
Но если недостаток похоронен под кучей абстракций в редко изменяемом коде то и черт с ним. Без него работы хватает.
_>Фигня. Ни жаба, ни С# не дают такого эффекта.
Как вы не любите кошек? Да вы просто не умеете их готовить.
Можешь посмотреть мои сообщения двухлетней давности... я там тоже самое говорил. _>Эффект дают МЕТОДИКИ.
Вот именно. Дела в том что кроме самих языков и сред выполнения есть еще и средства разработки так вот такие мега рулезы как ReSharper и IDEA очень сильно влияют на процесс разработки. _>Т.е. тест-драйвен-девелопмент, продумывание на бумажке как у eao197. Ну и просто опыт. А на чем писать — не так важно. Хотя, если конечно это в чем-то сопоставимые языки (я про императивные vs декларативные vs функциональные).
C++ и x86 assembler это императивные языки. Вот только для того чтобы писать на них нужно затричивать очень разное колличество усилий.
С жабой и шарпом по сравнению с С++ тоже самое. Если при работе на С++ мне приходилось отвлекатся на всякие там UB то при работе на C# я об этом не думаю даже подсознательно. Болие того с помощью тогоже ReSharper'а я могу очень быстро менять архитектуру. Да и подходы к самой архитектуре совершенно другие нежели в С++.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>И слава богу. Кто-то занимается драйверами. Кто-то системами кэширования в файловых системах. Кто-то построением оптимальных планов выполнения запросов в СУБД. Кто-то реализацией криптоалгоритмов в смарткартах. И с удовольствием используют знания о стоимости различных операций, полученных в начале карьеры/обучения.
E>Не все же считают, что полезное современное приложение -- это Web-приложение в паре с РСУБД и повсеместным использованием XML.
Да причем тут это? Иван говорил об уневерсальных принципах, а ты опять начал разводить демагогию про ВЕБ приложения.
E>Извини, но звучит это не слишком правдоподобно.
Извени но если ты не работал в таком стиле. Именно раблотал те делал большое и сложное приложение то ты просто не можешь адекватно оценить этот стиль работы. Нельзя говорить о вкусе устриц если ты их не ел. E>Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня.
Гм?... Я вижу только три причины менять код
1)Исправить баг
2)Изменить алгоритм
3)Изменить архитектуру. E>Изменить код в C#/Java по сравнению с C++ действительно проще за счет современных IDE и особенностей самих языков (у которых нет стольких неоднозначностей, как в C++). E>Но вот поменять алгоритм... Мне в свое время довелось в процессе обучения столкнуться с необходимостью смены алгоритма
. И каждый алгоритм сразу же накладывал свои органичения на всю систему в целом. Например, решение СЛАУ методом Халецкого требовало больше памяти из-за чего размерности СЛАУ приходилось ограничивать. А метод итераций для получения приемлимой точности увеличивал время расчета на несколько порядков. Так что сменить алгоритм -- это может означать серьезный пересмотр требований к задачи и условий ее выполнения. И язык, на котором решение делается, может иметь совсем мизерное значение по сравнению с остальными факторами.
А я бы сделал обобщенный интерфейс и реализовал оба мотода. И дал пользователю (или автопилоту) выберать какой алгоритм решения использовать.
К томуже эта твоя задача скорее исключение из правил. E>А уж если про смену архитектуры говорить... Ну например, много ли будет значить язык, если какой-нибудь statefull компонент потребуется переделать в stateless?
Много. Ибо придется менять много кода. И тот язык где это сделать легче однозначно в болие выигрошной позиции.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то зря. Это не в укор тебе и не предложение начать изучать исходники ntfs.sys . Но почитать тех же Соломона — Руссиновича не мешает.
И на том спасибо. Вот например denis_krg считает что это фатальный недостаток и я не могу называтся программистом... PD>У меня сегодня лекция по спецкурсу. Буду им рассказывать про селекторы, дескрипторы, страничный механизм. Чтобы програмировать на высоком уровне — это даром не надо. Даже про 4Г пространство знать необязательно (пока не припрет . А тем не менее на лекции эти ходят, хотя все спецкурсы у нас выбирают студенты, им нужно лишь требуемое количество набрать, а какие именно — они сами решают. И отменять этот спецкурс я не буду. PD>А раньше я вел такой же спецкурс по BIOS-MS-DOS. int13h, int 21h, int2fh, Partition Table, BPB, FAT, ... Тоже не то, с чем им в реальной работе приходилось сталкиваться потом. И тоже ходили.
Как очень хорошо в соседнем
сообщении сказал Иван: Им это интересно вот и ходят.
PD>Если за это же время — тогда да. Но ведь мне доказывали (не говорю ты), что надо сначала прототип сделать, и если выяснится, что он очень медленный, только тогда и улучшать. Что-то мне сдается, что прототип прокси-сервера за 2 дня не сделать... Впрочем, не знаю, я их не писал.
Я тоже не писал прокси серверы. Но это вобщем не суть важно. Важно то что прокси сервер начинают писать сразу без выделеной стадии прототипирования. Дело в том что первый вариант прокси который хоть както заживет и будет прототипом. Причем этот прототип появится очень быстро ибо внимаение на всякие молочи типа производительности на этом этапе не заостряется.
Далие когда прототип зашевилился сразуже начинают вырисовыватся архитектурные косяки. Первым делом исправляеются именно эти косяки при помощи современных IDE код править очень легко так что это процесс идет очень бысто и качественно ибо программисты не боятся менять код. О производительности (если конечно она не настолько низкая что невозможно отлаживатся) всеще никто не думает.
И только после того как не осталось видимых косяков в архитектуре начинают думать о производительносяти и делают это так: Берут в руки профайлер... И так как у нас правильная архитектура (а важнейшее всойство правильной архитектуры это возможность менять как реализации конкретных слоев не затрагиваю соседнии так и частичное изменение самой архитектуры без гемороя) просто начинают переписывать куски системы.
PD>Вот это заявление мне кажется очень важным. В сущности, здесь и определяется основная причина моего подспудного недоверия к этой управляемой среде.
Окружение это в первую очередь базы данных, сеть, ФС итп PD>На С++ (Pascal, Fortran, Assembler) мы пишем на языке, а делаем машинные коды. Да, конечно, оптимизатор может быть неблестящим. Да, есть много такого, что нам остается неподвластно совсем или частично (WinAPI, FS, ...). Да, есть многопоточность.
Ну в .NET еще и библиотека добавляется. Но чем это отличается от техже библиотек которые подключяются к темже С++ и фортрану. PD>Но в своем коде — я хозяин.. Что напишу — то и будет выполняться. Не может в моем коде вдруг неизвестно откуда вылезти новый высокоприоритетный поток и отнять время. Не может там быть захвачено больше адресного пространства и коммитировано памяти, чем я захватил и коммитировал. И т.д. PD>А вот в управляемой среде — может. Может, GC проснется именно в тот момент, когда для меня лучше всего, чтобы он спал и видел третий сон.
А какая разница? Ты что пишешь приложение реального времени? Вот только под виндой это сделать всеравно не получится.
Кстати существуют мусорщики реального времени... PD>Или, наоборот, я молю , чтобы он проснулся и память почистил, а он спит сном праведника. И т.д.
GC.Collect();... PD>Фактически мы потеряли полный контроль над свои кодом.
А он у тебя был? Винда в любой мемент может забрать себе все процессорное время или всю память отдать соседнему приложению.
Да и компилятор тоже делает то что хочет. PD>Эта ситуация не нова — она давно существует в средах программирования, где нет прямой компиляции на машинные коды. В интерпретаторах, проще говоря. В той же FoxPro, к примеру. Там тоже кто-то мусор убирает, потому как иначе нельзя. А когда он это делает — бог его знает. PD>Вот это мне и не нравится. Ты пишешь — невозможно оценить, как поведет себя окружение.
Реально ГЦ в .НЕТ не смотря на то что не извесно когда он запустится он весьма предсказуем. Если знать как он работает можно настроить алгоритмы так что он будет работать без напрягов.
PD>Поскольку на C# и C++ окружение абсолютно одно и то же, за исключением .Net исполняющей среды, то из этого ясно следует — невозможно оценить поведение именно этой управляемой среды.Не слишком ли это большая плата за удобства этой среды ?
Вот именно то окружение и используемые библиотеки совершенно не предсказуемы.
PD>Поверь мне (и ты, и другие) — я вовсе не имею целью эту среду охаять. Кстати, я уже на С# свой первый проект соорудил и деньги за него получил. Удобно писать, не спорю. Я другое хочу понять — что именно мы отдаем за эти удобства ? PD>Не слишком ли это большая плата за удобства этой среды ,
Реально мы платим незначительной потерей производительности и некоторым перерасходом памяти. Но со временем разница стирается.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>Что-то мне подсказывает что там будут использованы поточные форматы бинарников. PD>Это будет только если появится поточная форма виртуальной памяти
В таких ОС существуют два типа бинарников.
1)Что-то типа сборки из .NET. Как ты понимаешь ни какого отношения ни к виртуальной ни к какой бы то нибыло еще памяти эти бинарника вобщемто не имеют.
2)Скомпилиные под конкретную машину.(их к сати может и не быть это лишь оптимизация) Эти бинарники содержат код и данные. Также эти бинарники могут ссылатся на другие для того чтобы не дублировать код. Ссылки этих бинарников образуют ацикличный направленный граф. При загрузки такого бинарника сначала грузятся все те бинарники от которых он зависит. Тк при разных запусках бинарники могут быть загруженны по разным адресам нам при загрузке нужно будет скоррекитировать кучу ссылок внутри бинарника. Для этого нам нужно будет либо сделать здоровую таблицу с метаинформацией где и что подкрутить в бинарнике. Либо цинично сериализовать этот и бинарник и просто идти по потоку и при встречи ссылки генерировать нужный код. Что-то типа докомпиляции при загрузке. В принципе оба решения довольно близки по характеристикам но мне почемуто кажется что с сериалзацией проблем будет меньше.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>Object -> Serializer -> GzipStream -> EncryptStream -> NetStream -> Net -> NetStream -> DecryptStream -> GzipStream -> Deserializer -> Object WH>>Самое смешное то что в Object могут быть гигабайты информации но вот эта цепочка этого даже не почувствует ибо она есть O(1) памяти. PD>С помощью fseek еще много чего нельзя делать. И не надо его совать туда, где он ни при чем — в сетевые потоки.
А сетевые потоки, компрессия и шифровине появились через пол года после того как была реализована сохранение и загрузка из файла...
PD>Кстати, ответь на такой вопрос. А зачем Вам тогда BinaryWriter/Reader ? У него ведь (о ужас!) Seek метод есть. Исключить его, и все дела!
Для тех случаев когда нужно сделать что-то еще кроме сохранения/загрузки данных. Например в томже бинарном diff'е я Seek использовал очень активно ибо этого требовала задача.
А сохранение/загрузка матрици не требует Seek. А если она его не требует то зачем платить больше? А плата это не только память и производительность но еще и архитектура. Как ты передаш матрицу по сети если ты использовал Seek? А вот я сделаю это вобще не напрягаясь. Мое решение прекрасно себя чувствует в условиях сильного изменения требованей к системе, а вот твое... Это я и называю правильной архитектурой.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Да причем тут это? Иван говорил об уневерсальных принципах, а ты опять начал разводить демагогию про ВЕБ приложения.
Универсальных принципах, говоришь... Ну покажи мне универсальный приницп вот здесь:
Совершенно нормальное явление. Это, по большему счету, нафиг не нужно, но интересно — потому и ходят. У нас вот тоже был похожий разговор с Владом. Нужно ли рядовому разработчику знать стоимость виртуального вызова по сравнению с прямым и вызовом делегата? Ну и соответственно, рассказывать об этом на семинаре... Нафиг не надо, но интересно.
...
Но с появлением опыта и возрастанием задач с которыми приходится сталкиваться, приходит осознание того, что выбор правильного алгоритма даст выигрыш на порядки больше, чем вылизывание неправильного, и для того чтобы все работало хорошо — достаточно выбрать правильный алгоритм, а тратить время на его оптимальную реализацию в конкретной ситуации смысла уже не имеет. Потом понятие "алгоритм" растягивается до понятия "архитектура", а "правильный" начинает включать в себя не только скорость и объем используемых ресурсов, но и стоимость разработки, удобство модификации, ect... Но этот путь до конца проходят не все.
Имхо, здесь есть изложение собственного опыта и, возможно, наблюдение за окружающими.
Возьмем пример. Нужно реализовать алгоритм TripleDES для какой-нибудь специфической платформы (смарткарты или специализированного компьютера). Скорость и ресурсоемкость результирующего кода здесь будут играть даже большую роль, чем удобство модификации и, может быть, стоимость разработки. Менять алгоритм здесь нельзя. А вот чтобы работало хорошо -- нужно как раз потратить время на его оптимальную реализацию.
Так что не во всех областях эти принципы актуальны.
WH>Гм?... Я вижу только три причины менять код WH>1)Исправить баг WH>2)Изменить алгоритм WH>3)Изменить архитектуру.
0) Улучшить качество кода (рефакторинг).
Ты сейчас говоришь о следствиях. Т.е. решили изменить архитектуру, пришлость править код. Я же говорил о другом. Исправление бага -- это один уровень (возможно самый низкий). Эти исправления могут не затрагивать ни выбранных алгоритмов, ни выбранной архитектуры. Смена алгоритма уже более высокий уровень, но на архитектуре не скажется. И т.д. Так вот, чем выше уровень вносимых изменений, тем меньше влияние языка реализации (имхо).
WH>А я бы сделал обобщенный интерфейс и реализовал оба мотода. И дал пользователю (или автопилоту) выберать какой алгоритм решения использовать.
А так и было. Т.е. за интерфейсом скрывались все реализации и основная программа не знала, какой метод используется. А вместо автопилота был я сам, т.к. нужно было выбрать метод, дающий решение с заданой точностью на имеющихся ресурсах.
WH>К томуже эта твоя задача скорее исключение из правил.
Из каких правил?
Имхо, здесь собрались люди, представляющие совсем разные области программирования (только вот плотность распределения по областям разная). И в каждой области свои правила действуют.
Вот что мне не нравится, так это то, что представители мейнстримовых направлений (в том числе упомянутых мной web-разработок) распространяют свои правила на все остальные области программирования. Считая при этом, что их взгяд на эффективность является более правильным. И мне нравится, что хотя бы Павел Дворкин упорно привлекает внимание к тому, что это далеко не всегда так.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>И слава богу.
Хм.. Специально не стал писать ни "к счастью", ни "к сожалению" в этой фразе, хотя рука тянулась..
E> И с удовольствием используют знания о стоимости различных операций, полученных в начале карьеры/обучения.
Верно. Но есть такой нюанс, тот кто прошел этот путь до конца, а потом сознательно начал заниматься именно вылизыванием нужных кусочков в нужных задачах до тактов, просто потому что именно это ему интересно, никогда не будет добиваться максимальной производительности или оптимальности по ресурсам там, где этого делать не надо. А вот по поводу того, кто застрял где-то посередине у меня есть серьезные сомнения...
E>Извини, но звучит это не слишком правдоподобно. Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня. Изменить код в C#/Java по сравнению с C++ действительно проще за счет современных IDE и особенностей самих языков (у которых нет стольких неоднозначностей, как в C++).
Уровня конечно разного, но любое изменение архитектуры все равно выливается в изменение кода, а менять код в новых языках, как ты сам сказал, проще, следовательно...
E> Например, решение СЛАУ методом Халецкого требовало больше памяти из-за чего размерности СЛАУ приходилось ограничивать. А метод итераций для получения приемлимой точности увеличивал время расчета на несколько порядков. Так что сменить алгоритм -- это может означать серьезный пересмотр требований к задачи и условий ее выполнения.
Ну как бы никто не говорит, что думать не надо. Stateless/stateful, как правило ясно еще на этапе знакомства с ТЗ, благо характеристики и особенности этих конструкций известны. А в остальном новые языки позволяют набросать прототип раньше, не думая о конкретной реализации, подгоняя ее по мере разработки, так как трудоемкость изменения существенно ниже.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, vdimas, Вы писали:
Д>я понял, что ты имеешь в виду. Но вопросы системы типов — это еще не все. Существуют еще такие проблемы, как количество и качество зависимостей между модулями, наличие неявных связей в виде "соглашений о логике" и так далее — это всё намного хуже.
Ты не можешь написать большого приложения без каких-либо "соглашений о логике". Насчет этого я прошелся по "хорошо известным интерфейсам и протоколам". Т.е., я не считаю увеличением зависимостей наличие зависимости от того, что уже "и так есть". Потому что тебе не надо беспокоиться о таких зависимостях ни во время разработки, ни во время поддержки/рефакторинга.
Например, ты используешь дотнет и TCP-каналы. TCP канал — это очень сложное "соглашение о логике". Но ты не будешь описывать и реализовывать это "соглашение о логике" в своей системе, т.к. канал реализован операционкой и есть конкретный ропер в .Net. Ты просто даешь ссылку в доке на "хорошо известную сущность".
Ведь откуда вообще взялся обсуждаемый критерий? Из опыта разработки и поддержки больших систем и из банального стремления к упрощению этих процессов путем уменьшения кол-ва пунктов технической документации (грубо). Так что, до тех пор пока даже очень сложные технические зависимости не приводят к усложнению ТВОЕГО процесса разработки или поддержки, все ok.
Д>"Качество зависимостей" — это наличие циркулярных зависимостей, например. Относительно небольшое количество таких связей резко увеличивает свзяность всей системы в целом. Например, во втором фреймворке модули System и System.Configuration стали циркулярно зависимы. Нахрена — непонятно
Не знаю насчет "всей системы". Если ты разработчик этих двух сборок, то да, увеличивают сильно. А если ты пользователь (а ты именно пользолватель), то для тебя ничего практически не поменялось (изменения не существенны).
Здравствуйте, Merle, Вы писали:
M>Верно. Но есть такой нюанс, тот кто прошел этот путь до конца, а потом сознательно начал заниматься именно вылизыванием нужных кусочков в нужных задачах до тактов, просто потому что именно это ему интересно, никогда не будет добиваться максимальной производительности или оптимальности по ресурсам там, где этого делать не надо. А вот по поводу того, кто застрял где-то посередине у меня есть серьезные сомнения...
А почему ты думаешь, что застрял? Может он еще в дороге?
M>Уровня конечно разного, но любое изменение архитектуры все равно выливается в изменение кода, а менять код в новых языках, как ты сам сказал, проще, следовательно...
При серьезных изменениях в архитектуре, имхо, речь будет идти не столько об изменении, сколько о переписывании заново...
M>Ну как бы никто не говорит, что думать не надо. Stateless/stateful, как правило ясно еще на этапе знакомства с ТЗ, благо характеристики и особенности этих конструкций известны. А в остальном новые языки позволяют набросать прототип раньше, не думая о конкретной реализации, подгоняя ее по мере разработки, так как трудоемкость изменения существенно ниже.
Смотря в каких областях. Не везде есть выбор из нескольких языков.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Одним из результатов такого теста вполне может стать готовый функциональный модуль приложения. Потом он просто встраивается в приложение. У меня, например, так часто бывает.
AVK>Это ты Дворкину скажи: AVK>
А насчет переноса его в приложение — я это и не предлагаю вовсе. Зачем ? Это же тест.
Мда. Здесь я немного загнул. Дворкин и в самом деле говорил о другом подходе к построению тестов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
E>>Хотя бы потому, что "изменить код" и "поменять алгорит/архитектуру" это понятия совершенно разного уровня. WH>Гм?... Я вижу только три причины менять код WH>1)Исправить баг WH>2)Изменить алгоритм WH>3)Изменить архитектуру.
А "добавить фичу" — это уже не причина изменения кода?
WH>К томуже эта твоя задача скорее исключение из правил.
А какие задачи не являются "исключением из правил"? Огласите весь список, пожалуйста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
В общем, я в спор пока не вмешивался, т.к.:
1) согласен с обоими сторонами сразу (все предложенные варианты хороши при их прикладывании по месту)
2) из-за п.1. когда-то написал свою библиотеку строк из 7-ми (!!!) совместимых м/у собой представлений (совместимых по операциям). Два из них были основаны на std::string (char/wchar_t), один на COM BSTR, еще два на стандартной ASCIIZ(char/wchar_t) и еще два на структуре типа этой:
А то, что ты там предложил, малость не согласуется с твоими высказываниями насчет потенциально-опасных программ, уязвимостей и прочих случайных косяков программиста.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не везде. Всё зависит от условий.
Да везде. Везде.
WH>>Павел много чего говорил вот только в большинстве случаев можно было сделать иначе не потеряв при этом ничего кроме потенциальных неприятностей. ГВ>В его условиях? Ты уверен?
Процентов на 90. Надо нужно смотреть задачу.
ГВ>Откуда в языке C инлайн-функции? Токмо дефайны.
Ну это ты оптимизаторам скажи.
WH>>Не понял. Зачем это надо. Какую задачу ты решаешь? ГВ>Например, отправляю строку по сети обычным send(). На начало отправки длина строки неизвестна.
Это как не извесна? У тебя же строка с длинной?
ГВ>Но факта наличия это не отменяет. Выводы из этого можно делать любые.
Вывод один: Какойто оптимизатор недоделанный придумал мега комманды которые будут очень быстро работать со строками... Вот только он не подумал о том что железо меняется и меняется быстро.
Так что теперь эти комманды как и большая часть x86ого камня никому не нужный баласт.
Кстати я нашел еще одну проблему ASCIIZ строк. Их можно копировать только посимвольно. Те на паралельных архитектурах будут прблемы с производительностью по сравнению со строками с длинной.
ГВ>Значит, авторам ASCIIZ количество таких задач не казалось исчезающе малым.
Я думаю они просто не особо долго думали над этим вопросом.
ГВ>>>А так и превращать ничего не надо. WH>>Это не есть серьезное преймущество. ГВ>А я так и не думаю.
А я думаю. Ибо если я делаю поточный алгоритм то у него на входе будет абстракция поток, а не строка. Это нужно для того чтобы в любой момент можно было сменить источних данных. Например на файл или сокет или на что нибудь еще.
ГВ>Это утверждение следует из ваших же посылок о том, что анализировать алгоритмы не нужно. Однако, поскольку лоб не разбит, то значит, всё-таки анализируете? Значит, можно поздравить с "соврамши"?
Никто не говорил что анализировать вобще не нужно. Анализировать не нужно в самом начале когда еще ничего нет ибо это крайне мало эффективно, а вот когда уже есть прототип который хоть както дышит все проблемы вылазят как на ладоне. И вот тут то и начинается анализ. Не раньше. Ибо проблемы вылазят в таких местах о которых никто даже не подозревал те эти проблемы прото не возможно обнаружить при проектировании на бумажке.
К томуже всякие алхимические катализаторы типа ReSharper'а очень сильно ускоряют проверащение не поймешь чего в программный продукт.
Вобщем для того чтобы понять нужно поработать в такм стиле.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>А то, что ты там предложил, малость не согласуется с твоими высказываниями насчет потенциально-опасных программ, уязвимостей и прочих случайных косяков программиста.
Млин. Это всего лишь пример того как в принципе эта функция может выглядить.
Реально все это будет совсем по другому. Со всеми проверками и прочими статическими защитами.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, vdimas, Вы писали:
V>>А то, что ты там предложил, малость не согласуется с твоими высказываниями насчет потенциально-опасных программ, уязвимостей и прочих случайных косяков программиста. WH>Млин. Это всего лишь пример того как в принципе эта функция может выглядить. WH>Реально все это будет совсем по другому. Со всеми проверками и прочими статическими защитами.
Вообще, проблема в том, что в стандартной библиотеке слишком слабая реализация строки с т.з. архитектуры. Они могли бы представить более гибкий механизм, например выделить отдельную стратегию ХРАНЕНИЯ содержимого строки. То, что сейчас там выделен отдельно всего-лишь аллокатор — не сильно спасает. Например, я написал аллокатор типа такого:
В общем, весьма прикольно для стековых строк + защита от всяческих переполнений.
Затем, когда я использую этот аллокатор в векторе, все просто чудесно. Я так же чудесно могу использовать этот аллокатор и со строками... но не получаю приличного выигрыша на малых строках для которых это все и предназначено. Ибо многие реализации STL имеют локальный буфер 16 или 32 байта, в которых хранят короткие значения, а нафига мне этот дополнительный локальный буффер, если этот буффер уже содержится в моем аллокаторе?
В общем, к такому сложному вопросу как строки в STL подошли немного в "лоб", в результате чего мы видим то, что видим. А именно — тонны всяких кастомных реализаций С++ строк.
Т.е. то, что высокоуровневую строку в С++ не "вшили" — это просто замечательно, но то, что не дали достаточно гибкую реализацию (то бишь конструктор) своих собственных реализаций — это недочет. А учитывая важность класса — практически фатальный
Многие ругают С++ за его работу со строками, и есть за что. Не за использование со стандартным аллокатором, разумеется (это первый аргумент только что изучившего STL новичка), а за отсутствие четких представлений о сценариях использования на момент разработки.
Здравствуйте, vdimas, Вы писали:
V>Вообще, проблема в том, что в стандартной библиотеке слишком слабая реализация строки с т.з. архитектуры. Они могли бы представить более гибкий механизм, например выделить отдельную стратегию ХРАНЕНИЯ содержимого строки. То, что сейчас там выделен отдельно всего-лишь аллокатор — не сильно спасает. Например, я написал аллокатор типа такого:
А когда я начинаю думать о строках то почемуто всевремя прихожу к выводу что для подавляющего я бы даже сказал практически абсолютного большинства случаев ничего лучше чем immutable строки + StringBuilder не придумать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ты не можешь написать большого приложения без каких-либо "соглашений о логике". Насчет этого я прошелся по "хорошо известным интерфейсам и протоколам". Т.е., я не считаю увеличением зависимостей наличие зависимости от того, что уже "и так есть". Потому что тебе не надо беспокоиться о таких зависимостях ни во время разработки, ни во время поддержки/рефакторинга.
V>Например, ты используешь дотнет и TCP-каналы. TCP канал — это очень сложное "соглашение о логике". Но ты не будешь описывать и реализовывать это "соглашение о логике" в своей системе, т.к. канал реализован операционкой и есть конкретный ропер в .Net. Ты просто даешь ссылку в доке на "хорошо известную сущность".
V>Ведь откуда вообще взялся обсуждаемый критерий? Из опыта разработки и поддержки больших систем и из банального стремления к упрощению этих процессов путем уменьшения кол-ва пунктов технической документации (грубо). Так что, до тех пор пока даже очень сложные технические зависимости не приводят к усложнению ТВОЕГО процесса разработки или поддержки, все ok.
Я говорил всё-таки не об этом. Не так уж важно, насколько сложен линк между двумя модулями. Он может быть пусть даже очень сложен, но если он хорошо инкапсулирован, то его применение не добавляет никаких проблем, как ты сам отметил. Намного важнее, насколько много этих линков. Если каждый модуль в явном виде использует половину всех модулей проекта — это плохо. Если модуль использует результаты работы других модулей неявно — это еще хуже.
V>Не знаю насчет "всей системы". Если ты разработчик этих двух сборок, то да, увеличивают сильно. А если ты пользователь (а ты именно пользолватель), то для тебя ничего практически не поменялось (изменения не существенны).
Поскольку мы рассуждаем об архитектуре, то меня интересует этот вопрос именно с точки зрения разработчика
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, vdimas, Вы писали:
V>>Вообще, проблема в том, что в стандартной библиотеке слишком слабая реализация строки с т.з. архитектуры. Они могли бы представить более гибкий механизм, например выделить отдельную стратегию ХРАНЕНИЯ содержимого строки. То, что сейчас там выделен отдельно всего-лишь аллокатор — не сильно спасает. Например, я написал аллокатор типа такого: WH>А когда я начинаю думать о строках то почемуто всевремя прихожу к выводу что для подавляющего я бы даже сказал практически абсолютного большинства случаев ничего лучше чем immutable строки + StringBuilder не придумать.
Да, иммутейбл строки — рулезз, снимает туеву хучу проблем с синхронизацией. Одно плохо — для получения всех бенефитов нужна система со сборкой мусора, а иначе передача по копии порой обходится дешевле, чем блокирующие изменения счетчика ссылок на immutable shared string.
А со стринг-билдером понятно, std::string — его прямой аналог (или даже вкупе с sstream как форматтером).
Здравствуйте, WolfHound, Вы писали:
WH>Именно что проверять надо все и везде. По крайней мере строгую защиту памяти (такую как в управляемых средах) отключать нельзя вобще. WH>Иначе мы имеем то что имеем... нестабильно рабетающий софт и куча вирусов.
А что ты будешь делать с производительностью? И потом, если проверять все и везде, то читабельность кода сильно ухудшится, и, как следствие, будет тяжело его поддерживать. А это обычно негативно отражается опять же на устойчивости софта. Может получиться, что с чем боролись, на то и напоролись.
_>>У тебя "а если" слишком много. Читай условие задачи. Оно четкое. Если бы у бабушки... то бабушка была бы дедушкой. Знаешь такую фразу? ))) WH>Можно подумать у моих опанентов их меньше...
На мой взгляд немножко меньше
_>>Еще раз объясняю — программирование есть инженерная специальность. И чтобы не рухнуло при запуске, чтобы нагрузки тянуло — надо основные узкие места продумывать при проектировании, считать, оценивать. Иначе будет полная фигня. Архитектуру по ходу потом уже не изменишь. WH>Правда чтоли? А я менял... теперь буду знать что это сделать невозможно...
А если проект достаточно большой (несколько человеко-лет) и уже работает, то как быть? Архитектуру легко менять (в смысле — без последствий), когда система еще не в продакшине.
про PE-формат WH>Ну никода я не занимался ни разработкой линкеров, ни разработкой загрузчиков... но если ты думаешь что для меня будет проблоемой изучить PE формат или написатль приложение которое экономит каждый такт то поверь мне ты жестоко заблуждаешься.
Я тоже не занимался. Мало кто этим занимается. Но иметь представление — как это работает — необходимо. Для эффективной работы. Насчет каждого такта — ты преувеличиваешь. Но иметь представление — какие конструкции тяжелы по производительности, а какие нет и в какой ситуации тоже необходимо.
_>>и твоих заяв про Сингулярити. WH>А именно? Только аргументированно пожалуйста.
Вот я и говорю — системы нет, а разговор про нее есть. Что-то тут не так.
_>>Однако тенденция. И ты еще споришь с безусловно грамотными людьми вроде Павла. Я тебе серьезно говорю, ты изучай подход людей к решению проблем, это классический подход эффективных и успешных разработчиков. Он ничего нового не предлагает, он просто пытается тебе азбуку прочитать. WH>Я этот подход не хуже Павла знаю. Просто для меня это пройденный этап.
Блин, обычно это тот подход, к которому приходят )))) И все, там и остаются. Пишут очень эффективно и надолго. В смысле код и решения в общем остаются востребованными долго. Годы как минимум. А ты от него уже оказывается ушел. Куда, если не секрет?
_>>Фигня. Ни жаба, ни С# не дают такого эффекта. WH>Как вы не любите кошек? Да вы просто не умеете их готовить. WH>Можешь посмотреть мои сообщения двухлетней давности... я там тоже самое говорил.
Не, пишу сам на жабе. Мне нравится. Но. При всех ее достоинствах я прекрасно осознаю все недостатки. И принципиальные ограничения. Опять же — не забалдел я от нее по дурному. И это хорошо.
_>>Эффект дают МЕТОДИКИ. WH>Вот именно. Дела в том что кроме самих языков и сред выполнения есть еще и средства разработки так вот такие мега рулезы как ReSharper и IDEA очень сильно влияют на процесс разработки.
Не так сильно, как ты думаешь. Хотя опять же — дело личное.
WH>С жабой и шарпом по сравнению с С++ тоже самое. Если при работе на С++ мне приходилось отвлекатся на всякие там UB то при работе на C# я об этом не думаю даже подсознательно. Болие того с помощью тогоже ReSharper'а я могу очень быстро менять архитектуру. Да и подходы к самой архитектуре совершенно другие нежели в С++.
А если подумать, не писать сразу, а чуть-чуть порисовать? Может меньше менять придется? Ты послушай, о чем eao197 говорит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А , скажите на милость, какая такая уязвимость может быть в программе для квантовой химии, которая близко к интернету не лежала, ни с какими БД не работает ( в крайнем случае из какого-нибудь Акцесса входные данные берет и в xls записывает или еще куда ? Рухнуть она — может. Чертыхнутся и перезапустят. И если это раз в месяц происходит, то и не вспомнят больше об этом. У Вас что, никакие программы на вашем компьютере не падали ? Вы этим падениям счет ведете. что ли ? Если у Вас winrar при архивации упадет, скажите на милость, какая такая здесь уязвимость образуется ? PD>Что же касается проекта, в котором я участвовал, то никакие ламеры никогда к нему доступа иметь не будут. <...> И переделывать если его будут все же, то проверят не раз, и не два, а на полном наборе тестов, которых там (специально посмотрел сейчас) 119495. 5 часов примерно прогон их занимает. А если рухнет — ничего страшного, автоматом перезапустится и продолжит свою работу.
PD>Так что нечего принципы web-индустрии в общие догматы возводить!
Сдается мне, что принципы web-индустрии имеют значения для несколько большего числа людей, чем принципы индустрии разработки софта для квантовой химии, которые Вы так настойчиво проталкиваете в догматы. Я, конечно, не пишу софт для квантовой химии, а вовсе даже для гидродинамического моделирования, однако некоторое сходство предметной области есть, согласны? Особенно по сравнению с программированием для web. Так что у меня есть некоторые сомнения насчет утверждений о том, что такие приложения могут падать и это никого сильно не огорчит (на самом деле, когда многочасовой рассчет завершается аварийно, то возникает желание забить гвоздь в голову разработчика, пусть даже промежуточные результаты и сохранены заблаговременно). На самом деле, по моему, не так уж важно насколько быстр код, если он НЕ РАБОТАЕТ. Каким образом меня должно утешать то, что есть много других программ, которые падают — я не понимаю. Может с годами понимание придет? Также вынужден обратить внимание на то, что сотня тысяч тестов (да хоть миллион) В ПРИНЦИПЕ не может гарантировать ОТСУТСТВИЕ ошибок, а в лучшем случае только обнаружит некоторые из них.
Также мне кажется сомнительным утверждение о том, что подобное ПО разрабатывается раз и на 10 лет, после чего его точно не будут менять. Возможно, квантовая химия это какая-то особая область знаний, о ней я судить не буду, но в разаработке софта для гидродинамического моделирования есть поддержка легаси кода и огромное количество связанного с этим внеполового секса, особенно когда имеешь дело с продуктом творчества программиста, пишущего на любом языке как на фортране, но это, конечно, уже совсем другая история. Просто наболело.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, denis_krg, Вы писали:
_>А что ты будешь делать с производительностью?
Я както не жалуюсь. Хотя тоже иногда биты из байтов повыжимать люблю. _>И потом, если проверять все и везде, то читабельность кода сильно ухудшится, и, как следствие, будет тяжело его поддерживать.
Это смотря кто проверяет. Если проверяет программист при разработке на С++ то это действительно так. А если проверяет рантайм при разработке на .NET то этих проверок в коде нет вобще. Их все рантайм делает. К томуже в случае с рантаймом они очень не плохо оптимизируются. Причем даже современный JIT показывает очень не плохие результат, а ведь он использует далеко не все теоритически возможные методы оптимизации. В прочем МС раблотает над устранением этого недостатка. _>А это обычно негативно отражается опять же на устойчивости софта. Может получиться, что с чем боролись, на то и напоролись.
Это если на С++... А если на шарпе или жабе то нет.
_>А если проект достаточно большой (несколько человеко-лет) и уже работает, то как быть? Архитектуру легко менять (в смысле — без последствий), когда система еще не в продакшине.
Ну если проект уже вышел в продакшен то тогда действительно труба.
Вот торлько я мел в виду способ разработки описанный тут
. При такм способе архитектуру править действительно очень легко ибо программа еще незамутнена всякими оптимизациями. К томуже правильные программисты делают архитектуру так что можно менять ее части (а это значительно проще) не затрагивая все приложения.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, denis_krg, Вы писали:
_>Я тоже не занимался. Мало кто этим занимается. Но иметь представление — как это работает — необходимо. Для эффективной работы.
Зачем? Что я теряю от не знания формата PE? _>Насчет каждого такта — ты преувеличиваешь. Но иметь представление — какие конструкции тяжелы по производительности, а какие нет и в какой ситуации тоже необходимо.
Ну это у меня вобще на безсознательном уровне работает.
_>Вот я и говорю — системы нет, а разговор про нее есть. Что-то тут не так.
Разговоры не столько а самой сингулярити сколько о принципах на которых она построена. И эти принципы мне очень нравятся. Единственное их решение которое у меня вызывает сомнения это невозможность загрузки нового кода в уже запущенный процесс.
_>Блин, обычно это тот подход, к которому приходят )))) И все, там и остаются. Пишут очень эффективно и надолго. В смысле код и решения в общем остаются востребованными долго. Годы как минимум.
У меня есть такие программы. Крутятся 7х24 на нфтяных заводах и есть не прося. _>А ты от него уже оказывается ушел. Куда, если не секрет?
Как выразился Влад к взрывному программированию. Впрочем я тут
об это уже писал.
_>Не, пишу сам на жабе. Мне нравится. Но. При всех ее достоинствах я прекрасно осознаю все недостатки. И принципиальные ограничения. Опять же — не забалдел я от нее по дурному. И это хорошо.
Если ты думаешь что я не осознаю недостатки шарпа то ты опять таки заблуждаешься. Просто во совокупности свойст среда созданный вокруг этого языка очень хорошо подходит для подавляющего числа задач.
_>Не так сильно, как ты думаешь. Хотя опять же — дело личное.
Ну я какбы до этого на С++ пописал и не мало... так что могу сравнивать. Правда если на шарпе писать также как на С++ то действительно современные IDE дают не много.
_>А если подумать, не писать сразу, а чуть-чуть порисовать? Может меньше менять придется? Ты послушай, о чем eao197 говорит.
Зачем думать на бумаге если можно подумать в коде? Причем лично мне с бумагой работать очень не удобно. Мне гораздо удобней набить код в редакторе используя всякие фишки тогоже ReSharper'а от автокмплита и хотфиксов до различных рефакторингов.
Короче к тому времени как eao197 закончит рисовать на бумажке у меня уже будет работающий прототип. А как уже говорилось косяки в живом коде видны гораздо лучше чем на бумаге.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Короче к тому времени как eao197 закончит рисовать на бумажке у меня уже будет работающий прототип.
Не хочу зарекаться, но думаю, что данное утверждение никогда не будет проверено на практике.
WH>А как уже говорилось косяки в живом коде видны гораздо лучше чем на бумаге.
Проблема с прототипами в том, что косяки в коде прототипа могут не иметь никакого отношения к результирующей системе.
К тому же откуда ты знаешь, что видно в проекте на бумаге?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Проблема с прототипами в том, что косяки в коде прототипа могут не иметь никакого отношения к результирующей системе.
Я думаю мы говорим о несколько разных прототипах.
E>К тому же откуда ты знаешь, что видно в проекте на бумаге?
Сам так работал.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Так в приложении это функционал в конце концов нужен. Или ты предлагаешь делать одну и ту же работу 2 раза?
Ну и что ? К примеру твоя же задача с прокси. Вопрос — выдержит ли FAT/NTFS такие нагрузки в плане нужной производительности, какое будет время для чтения/записи, если в минуту создается/изменяется/удаляется N,M,K файлов и их размеры такие-то с таким-то разбросом. Программа по таймеру делает все это, и я не верю , что на ее написание ты больше 3 часов потратишь. Потому что здесь 50 строчек максимум. Да еще на С#
Через 3 часа ты будешь все знать. После этого код теста выбрасывается на помойку (лучше, конечно, сохранить, пригодится
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Так в приложении это функционал в конце концов нужен. Или ты предлагаешь делать одну и ту же работу 2 раза?
PD>Ну и что ?
PD> К примеру твоя же задача с прокси. Вопрос — выдержит ли FAT/NTFS такие нагрузки в плане нужной производительности, какое будет время для чтения/записи, если в минуту создается/изменяется/удаляется N,M,K файлов и их размеры такие-то с таким-то разбросом.
Видишь ли — в реальном приложении таких вопросов не один и не два, а сотни. Что, писать сотни тестов? А еще, помимо чисто технических моментов, как в описываемом случае, есть вопросы типа "а будет ли удобно?", "насколько легко пользователям будет освоить?", "какой процент случаев использования покроет упрощенный фунционал, а какой процент придется закрывать функционалом сложным?" и т.п. Тоже будем тесты писать?
PD> Программа по таймеру делает все это, и я не верю , что на ее написание ты больше 3 часов потратишь.
3 часа на тест это микропрограмма на неделю работы. Говорить о каких то методологиях на таких проектах особо смысла нет, разницы большой не получишь.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и что ? К примеру твоя же задача с прокси. Вопрос — выдержит ли FAT/NTFS такие нагрузки в плане нужной производительности, какое будет время для чтения/записи, если в минуту создается/изменяется/удаляется N,M,K файлов и их размеры такие-то с таким-то разбросом. Программа по таймеру делает все это, и я не верю , что на ее написание ты больше 3 часов потратишь. Потому что здесь 50 строчек максимум. Да еще на С# PD>Через 3 часа ты будешь все знать. После этого код теста выбрасывается на помойку (лучше, конечно, сохранить, пригодится
Еще раз. За эти 3 часа будет реализован интерфейс этой подисистемы и работа пойдет дальше. И только в случае если это место окажется узким оно будет оптимизировано.
Ибо в процессе работы над остальными частями системы могут быть изменены требования к подсистеме кеширования. И чем проще будет эта подсистема тем быстрее и легче ее править.
И только когда архитектура болие или мение устаканится можно будет начать оптимизировать. Иначе с очень большой вероятностью оптимизированный код пойдет в мусор ибо требования изменились и оптимизировать надо совсем по другому.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Возьмем пример. Нужно реализовать алгоритм TripleDES для какой-нибудь специфической платформы (смарткарты или специализированного компьютера).
Хороший пример. Здесь еще любят приводить в качестве примера софт для АЭС и софт систем управления МБР.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Хороший пример. Здесь еще любят приводить в качестве примера софт для АЭС и софт систем управления МБР.
Ты суслика видишь? Нет? И я нет. А ведь он есть.
((c) к/ф ДМБ)
То, что на RSDN не слышно и не видно людей, которые разрабатывают софт для АЭС или для военных, совсем не означает, что таких людей нет. Я бы даже сказал, что их отсутствие на RSDN скорее проблема RSDN, чем достоинство.
Между тем, такие задачи действительно есть. И условия в них ну очень специфические.
И, конечно же, проще от таких задач отмахнуться (конечно, их же не видно), чем принять во внимание, что мейнстрим -- далеко не единственная стоящая вещь в программировании.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>То, что на RSDN не слышно и не видно людей, которые разрабатывают софт для АЭС или для военных, совсем не означает, что таких людей нет. Я бы даже сказал, что их отсутствие на RSDN скорее проблема RSDN, чем достоинство.
Если бы они тут были и ярко светились, то это была бы уже проблема КГБ.
E>Между тем, такие задачи действительно есть. И условия в них ну очень специфические.
Какова доля, по твоему, в их задачах тех же гуёв и баз данных? Или операторы АЭС никогда не пользуются мониторами, а все данные хранятся в тетрадках?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Между тем, такие задачи действительно есть. И условия в них ну очень специфические.
Наверное есть. И что?
E>И, конечно же, проще от таких задач отмахнуться (конечно, их же не видно), чем принять во внимание, что мейнстрим -- далеко не единственная стоящая вещь в программировании.
И что? Ты посмотри на корень топика — там ведь претендуют на принципы, а не на частные случаи.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Наверное есть. И что? AVK>И что? Ты посмотри на корень топика — там ведь претендуют на принципы, а не на частные случаи.
А то, что на фоне этих частных случаев я не могу считать слова Merle
Здравствуйте, IT, Вы писали:
IT>Если бы они тут были и ярко светились, то это была бы уже проблема КГБ.
E>>Между тем, такие задачи действительно есть. И условия в них ну очень специфические.
IT>Какова доля, по твоему, в их задачах тех же гуёв и баз данных? Или операторы АЭС никогда не пользуются мониторами, а все данные хранятся в тетрадках?
Думаю, что в очень многих случаях второстепенная. И знаю примеры, когда прикручивание АРМ-ов операторов и АРМ-ов мониторинга работоспособности основных аппаратно-вычислительных узлов выполнялись командами гораздо менее опытных разработчиков, чем софт для самих этих аппаратно-вычислительных узлов. Как всегда, по остаточному принципу...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Он и не претендует на универсальность, он расказывает о тенденциях.
Т.е., ты считаешь, что:
Но с появлением опыта и возрастанием задач с которыми приходится сталкиваться, приходит осознание того, что выбор правильного алгоритма даст выигрыш на порядки больше, чем вылизывание неправильного, и для того чтобы все работало хорошо — достаточно выбрать правильный алгоритм, а тратить время на его оптимальную реализацию в конкретной ситуации смысла уже не имеет. Потом понятие "алгоритм" растягивается до понятия "архитектура", а "правильный" начинает включать в себя не только скорость и объем используемых ресурсов, но и стоимость разработки, удобство модификации, ect...
это современная тенденция, которая происходит сейчас с современными разработчиками уже получившими образование и ставшими инженерами-программистами? Т.е., такой сдвиг сознания происходит с людьми уже в процессе реальной работы?
Если так, то это грусно. Поскольку мне казалось, что подобные вещи должны происходить еще в процессе обучения. И, желательно, не на старших курсах.
Но все равно не понятно, почему в расчет не принимаются задачи, где даже ведущие разработчики не имеют возможности влиять даже на выбор алгоритмов. Не говоря уже про архитектуру. Ну вот положено по стандарту безопасности использовать TripleDES или ГОСТ -- все, отставить разговорчики. Решение принимаешь не ты, как исполнитель, и даже не руководитель проекта -- решения подобного рода принимаются задолго до того и совсем другими людьми.
Еще круче, когда делается софт для большого аппаратно-программного комплекса. Вычислительные алгоритмы выбираются отдельными КБ. С учетом разных факторов. В том числе и с учетом мощности аппаратуры, на которой расчеты будут выполняться. И затем сменить основные алгоритмы уже нет возможности, поскольку менять придется очень многое, может быть даже переделывать специализированную аппаратуру и/или интерфейсы к ней. Да и критерии "правильности" здесь весьма четкие -- правильность расчетов, попадание в отведенное для расчетов время, потребление только отведенных под задачу ресурсов.
А такие критерии, как "стоимость разработки" и "удобство модификации" вообще к правильности могут не иметь никакого отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если так, то это грусно. Поскольку мне казалось, что подобные вещи должны происходить еще в процессе обучения. И, желательно, не на старших курсах.
Учить некому. Большие зарплаты в IT сыграли злую шутку — разрыв между зарплатой практикующего специалиста и учителя ВУЗа просто чудовищный. Результат предсказать несложно.
E>Но все равно не понятно, почему в расчет не принимаются задачи, где даже ведущие разработчики не имеют возможности влиять даже на выбор алгоритмов.
Потому что высшее образование — явление массовое и преподавать вещи, которые понядобяться долям процента выпускников, слишком расточительно.
E> Не говоря уже про архитектуру. Ну вот положено по стандарту безопасности использовать TripleDES или ГОСТ -- все, отставить разговорчики.
...
E>Еще круче, когда делается софт для большого аппаратно-программного комплекса. Вычислительные алгоритмы выбираются отдельными КБ.
Тебе не кажется, что ты путаешь архитектуру и алгоритмы?
E>А такие критерии, как "стоимость разработки" и "удобство модификации" вообще к правильности могут не иметь никакого отношения.
Это вряд ли. У нас все таки рынок, а не плановая экономика.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
про PE-формат и твоих заяв про Сингулярити. Однако тенденция.
Ты уверен, что действительно имешь права на надменность?
_> И ты еще споришь с безусловно грамотными людьми вроде Павла.
Да, он спорит с людьми вроде Пвла и тебя. Можно было бы поговорить о безусловности вашей грамотности, но это уже переход на личности.
Ты уже перешел на обсуждение личности Вольфхаунда и я тебя предупреждаю, что следующая попытка приведет тебя в баню.
_> Я тебе серьезно говорю, ты изучай подход людей к решению проблем, это классический подход эффективных и успешных разработчиков.
Можно привести подтверждение успешности данных разработчиков?
_> Он ничего нового не предлагает, он просто пытается тебе азбуку прочитать.
У Дворкина есть место где он может обучать азбуке тех кому она нужна. Вольфхаунд явно не из этого числа.
И вообще, ты бы сбросил маску умудренного опытом гуру наставляющего детишек.
Ты тут в лучшем случае равный среди равных. И твоя надменность и пафос выглядят очень просто непорядочно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>То, что на RSDN не слышно и не видно людей, которые разрабатывают софт для АЭС или для военных, совсем не означает, что таких людей нет. Я бы даже сказал, что их отсутствие на RSDN скорее проблема RSDN, чем достоинство.
Здравствуйте, VladD2, Вы писали:
VD>Я не о надежности. Я о таком трогательном интересе к нему.
Видимо интерес обусловлен именно требованиями надежности, крайне высокими для ПО. А вообще не факт, тут трудно судить, кому что и почему нравиться.
Вообще, каждый программист, видимо, имеет какие то дорогие его сердцу области, и вовсе необязательно чтоб он в них работал
Мне вот дороги и интересны области авионики и бортового ПО ВВС, хотя я сам в них и не работал. А кому то дороги сердцу АЭС.
VD>Кстати лучше всего можно долбанать на С/С++. VD>Нас Бенладен не слышит
Может, бахнем?! — предложил я Казакову и кивнул на заветную кнопку размером со спелый помидор.
— Обязательно бахнем и не раз, весь мир в труху, но потом!
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>В реальной жизни ученики думают головой, продолжают учиться, и многие шагнули дальше своего учителя, но до сих пор благодарны ему (учителю). Так и должно быть, я считаю.
Вот только на это и надежда.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>Я не силен в PE-формате но если мне не изменяет скалероз то он такой по тому что нужно было на старых машинах обеспечить подгрузку кода кусками. WH>>Сейчас это не актуально но этот формат все еще используют по историческим причинам ибо особого смысла менять его пока нет.
PD>Ну и ну! Ты хоть что-то про виртуальную память слышал и про то, как она реализована ? И ,кстати, как подгрузка страниц происходит ?
А ты в курсе что такое ремапинг?
ЗЫ
Надеюсь вопрос реторический.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Учить некому. Большие зарплаты в IT сыграли злую шутку — разрыв между зарплатой практикующего специалиста и учителя ВУЗа просто чудовищный. Результат предсказать несложно.
+1
E>>Еще круче, когда делается софт для большого аппаратно-программного комплекса. Вычислительные алгоритмы выбираются отдельными КБ.
AVK>Тебе не кажется, что ты путаешь архитектуру и алгоритмы?
Вообще-то это я к тому, что Merle сказал о повышении производительности путем замены алгоритма. Иногда либо нет такого алгоритма, либо нужно использовать тот, который каким-то стандартом предписан.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Можно узнать откуда такая забота о ПО которое работает всего в пятистах местах?
Хотя бы из-за того, что одно из таких мест, Чернобыльская АЭС, находится слишком близко ко мне.
А вообще мне кажется, что во многих областях, где требуется создание высоконадежного ПО (медицина, энергетика, транспорт, связь, авиция, космонавтика, военные направления) накапливается большой и уникальный в своем роде опыт. Только он не выставляется напоказ (в отличии от) и ознакомиться с ним не так просто.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Я не о надежности. Я о таком трогательном интересе к нему. VD>Кстати лучше всего можно долбанать на С/С++.
Может нужно кого-нибудь вразумить, пока не поздно? А то мужики-то и не знают?
JPL (Jet Propulsion Lab, NASA): Mars rover autonomous driving system (incl. scene analysis and route planning). C++ on Mars! Also lots of supporting software "on the ground" (i.e. Earth).
MAN B&W Diesel A/S: Purveyers of engines for large and very large ships (such as container ships and tankers).
* Electronic controlled fuel injection and exhaust valve control system for very large (up to more than 100.000 break horse power) two stroke diesel engines. Hard real-time system running on medium size embedded system. Absolutely critical 24/7 operation with distributed, redundant error recovery. Written entirely in high performance, high level C++, except for a few hundred lines of assembler code.
* Several large support systems for engines and crew running on desktop machines, written entirely in C++.
* Several internal business critical applications, for engine design calculations and design information storage.
Здравствуйте, eao197, Вы писали:
E>Вообще-то это я к тому, что Merle сказал о повышении производительности путем замены алгоритма. Иногда либо нет такого алгоритма, либо нужно использовать тот, который каким-то стандартом предписан.
Ну что ж, не все в мире идеально. Но к идеалу стремиться стоит.
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
Здравствуйте, klapaucius, Вы писали:
K>Здравствуйте, Pavel Dvorkin, Вы писали:
K>Сдается мне, что принципы web-индустрии имеют значения для несколько большего числа людей, чем принципы индустрии разработки софта для квантовой химии, которые Вы так настойчиво проталкиваете в догматы. Я, конечно, не пишу софт для квантовой химии, а вовсе даже для гидродинамического моделирования, однако некоторое сходство предметной области есть, согласны?
Да.
>Особенно по сравнению с программированием для web. Так что у меня есть некоторые сомнения насчет утверждений о том, что такие приложения могут падать и это никого сильно не огорчит (на самом деле, когда многочасовой рассчет завершается аварийно, то возникает желание забить гвоздь в голову разработчика, пусть даже промежуточные результаты и сохранены заблаговременно).
У меня тоже, если он не предусмотрел контрольные точки с рестартом с них...
>На самом деле, по моему, не так уж важно насколько быстр код, если он НЕ РАБОТАЕТ. Каким образом меня должно утешать то, что есть много других программ, которые падают — я не понимаю. Может с годами понимание придет? Также вынужден обратить внимание на то, что сотня тысяч тестов (да хоть миллион) В ПРИНЦИПЕ не может гарантировать ОТСУТСТВИЕ ошибок, а в лучшем случае только обнаружит некоторые из них.
Не надо банальные истины преподносить. Никакие тесты не могут гарантировать отсутствие ошибок, об этом все давно знают. Я вовсе не об этом говорил.
K>Также мне кажется сомнительным утверждение о том, что подобное ПО разрабатывается раз и на 10 лет, после чего его точно не будут менять. Возможно, квантовая химия это какая-то особая область знаний, о ней я судить не буду, но в разаработке софта для гидродинамического моделирования есть поддержка легаси кода и огромное количество связанного с этим внеполового секса, особенно когда имеешь дело с продуктом творчества программиста, пишущего на любом языке как на фортране, но это, конечно, уже совсем другая история. Просто наболело.
Здравствуйте, WolfHound, Вы писали:
PD>>Кстати, ответь на такой вопрос. А зачем Вам тогда BinaryWriter/Reader ? У него ведь (о ужас!) Seek метод есть. Исключить его, и все дела! WH>Для тех случаев когда нужно сделать что-то еще кроме сохранения/загрузки данных. Например в томже бинарном diff'е я Seek использовал очень активно ибо этого требовала задача. WH>А сохранение/загрузка матрици не требует Seek. А если она его не требует то зачем платить больше? А плата это не только память и производительность но еще и архитектура. Как ты передаш матрицу по сети если ты использовал Seek?
Никак. За полной ненадобностью в той задаче, о которой я говорил. К примеру, winrar решительно не умеет записывать архивы прямо-таки в сеть. И PhotoShop картинки в сеть не отправляет. И наш любимый VS бинарники пишет только в файл, а вовсе не в сеть.
>А вот я сделаю это вобще не напрягаясь.
Ну и на здоровье. А у меня этого задача не требует.
>Мое решение прекрасно себя чувствует в условиях сильного изменения требованей к системе, а вот твое... Это я и называю правильной архитектурой.
Все это слова, увы. А если потребуется эту матрицу в виде двумерной таблицы на экран выводить ? Тут ни мой fseek, ни твоя сериализация не подойдут, а придется все равно что-то иное писать с помощью то ли GDI+, то ли WriteLine...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>
S>А какое отношение длина файла имеет к сериализации? Ты что, думаешь что fseek волшебным образом ее сократит? Разве что если ты две матрицы поверх друг друга запишешь
S>Самое непосредственное. При этом будут записаны ненулевые элемениы только. В один проход. И размер волшебным образом сократится — расчеты я сегодня утром приводил, то ли в письме к тебе, скорее к VladD2, посмотри сам.
S>Это было бы понятно, если бы ты не знал другого способа сократить объем. Однако еще за два дня до этого постинга я написал тебе, как сериализовать разреженную матрицу без fseek. И ты к этому моменту на тот постинг уже ответил, т.е. текст читал. Просто предпочел проигнорировать. Как и вопрос про применение компрессии.
Именно. Потому что компрессия к делу отношения не имеет. Речь шла о выводе в определенном формате и оптимальнои решении для этого формата. Насчет пингвинов в Антарктиде и горы Эверест я больше дискутировать не буду — так как ты умеешь хорошо уводить дискуссию в сторону. За пределами этого формата и размера его данных я обсуждать ничего не намерен.
PD>>Честно говоря, у меня никакого желания дискутировать нет с теми, кто себе это позволяет. Когда на такие передергивания идут — спорить бессмысленно. Это уже не спор для нахождения истины, а просто желание во что бы то ни было доказать свою правоту. Не гнушаясь при этом ничем. S>Ну вот опять. Павел, да, я такой негодяй. Для доказательства своей правоты я не гнушаюсь перечитыванием переписки и называнием вранья враньем, а непонимания — непониманием.
Равно как и передергиванием, попытками уводить дискуссию в сторону и т.д., о чем я уже писал.
>Зато я читаю аргументы, и меня можно убедить.
Честно говоря, верится с трудом
>Естественно, не при помощи стенаний и заведомо некорректных утверждений.
ИМХО любыми способами это вряд ли получится . Так что вряд ли я буду с тобой еще спорить — скука смертельная
Здравствуйте, VladD2, Вы писали:
PD>>слишком уж много народу с этим бредом (опять употребил) согласно. Либо они все бредят, либо ...
VD>Вот тут нельзя не согласиться. Слишком много!
И все они бредят. Не форум прямо таки, а просто сумасшедший дом. И только несколько человек в нем не бредят и все эти бредни упорно разоблачают. Хвала им и слава за это !
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Никак. За полной ненадобностью в той задаче, о которой я говорил.
Задача о которой ты говорил требовала сделать структуру данный по которой потом выполнялись запросы.
А я говорю про сохранение/загрузку разряженой матрици. Именно эту задачу ты предложил расмотреть в начале. Без каких либо извращений с запросами, а когда тебе показали что fseek не только не нужен но еще и вредит ты начал менять задачу с сохранение/загрузи на запросы. PD>К примеру, winrar решительно не умеет записывать архивы прямо-таки в сеть.
А GZipStream если его вывод направить в NetworkStream может. PD>И PhotoShop каринки в сеть не отправляет. PD>И наш любимый VS бинарники пишет только в файл, а вовсе не в сеть.
Им приходится работать с вполне конкретными форматами многие из которых не расчитаны на сеть.
И что это доказывает кроме того что есть задачи которые принципиально не укладываются в сериализацию? Причем с этим никто не спорил.
Тебе пытаются объяснить что алгоритм не должен требовать от интерфейса сущностей с которыми он работает больше чем ему необходимо. Для сохранения матрици не нужно произвольного доступа. Это все прекрасно реализуется при помощи потока. Следовательно нужно использовать поток. Иначе связаность системы повысится на ровном месте, а это ни когда ни к чему хорошему не приводило.
PD>Ну и на здоровье. А у меня этого задача не требует.
Сейчас не требует, а через год потребует... причем тебя на том проекте уже на будет... вот люди которые будут это переписывать, а потом еще писать конверторы из твоего формата в последовательный очень много теплых слов о тебе скажут.
PD>Все это слова, увы. А если потребуется эту матрицу в виде двумерной таблицы на экран выводить ? Тут ни мой fseek, ни твоя сериализация не подойдут, а придется все равно что-то иное писать с помощью то ли GDI+, то ли WriteLine...
Опять подмена задачи? Причем подмена из серии: тебе говорят что котлованы для фундамента удобно копать экскаватором, а ты спрашиваешь как при помощи этого экскаватора стекла в окно всавлять.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Уязвимость — где ? В Интернет — сайте, в результате чего дело может кончиться взломом сервера со всеми вытекающим ? Это одно. А , скажите на милость, какая такая уязвимость может быть в программе для квантовой химии, которая близко к интернету не лежала, ни с какими БД не работает ( в крайнем случае из какого-нибудь Акцесса входные данные берет и в xls записывает или еще куда ? Рухнуть она — может. Чертыхнутся и перезапустят. И если это раз в месяц происходит, то и не вспомнят больше об этом. У Вас что, никакие программы на вашем компьютере не падали ? Вы этим падениям счет ведете. что ли ? Если у Вас winrar при архивации упадет, скажите на милость, какая такая здесь уязвимость образуется ? PD>Что же касается проекта, в котором я участвовал, то никакие ламеры никогда к нему доступа иметь не будут. И интернета на той машине, где он работает, нет просто вообще — он там не нужен. И переделывать если его будут все же, то проверят не раз, и не два, а на полном наборе тестов, которых там (специально посмотрел сейчас) 119495. 5 часов примерно прогон их занимает. А если рухнет — ничего страшного, автоматом перезапустится и продолжит свою работу.
PD>Так что нечего принципы web-индустрии в общие догматы возводить!
Уязвимости бывают не только в веб-сайтах. Они бывают в IE, RPC, медиа-плейерах, офисах — любых программах, которые имеют доступ к интернету или локальной сети, или могут работать с файлами, скачанными из интернета или локальной сети. И таких программ — ты наверно удивишься — очень много. На два-три порядка больше, чем программ для численных расчетов.
Поэтому давай ты не будешь учить нас жить, основываясь на своем уникально интересном опыте разведения серо-полосатых слонов в условиях среднего нечерноземья? И тогда никто не будет мучить тебя своими "байками".
Здравствуйте, Pavel Dvorkin, Вы писали: S>>Это было бы понятно, если бы ты не знал другого способа сократить объем. Однако еще за два дня до этого постинга я написал тебе, как сериализовать разреженную матрицу без fseek. И ты к этому моменту на тот постинг уже ответил, т.е. текст читал. Просто предпочел проигнорировать. Как и вопрос про применение компрессии.
PD>Именно. Потому что компрессия к делу отношения не имеет. Речь шла о выводе в определенном формате и оптимальнои решении для этого формата.
Павел, тут налицо какое-то недопонимание. Я даже не знаю, как к нему подступиться. Ну вот ты пишешь, что тебя интересовал совершенно конкретный формат. Павел, это все равно, как спросить "как мне поделить на три без деления". Хотя нет, делить без деления все-таки можно. Короче говоря, ты все время путаешь задачу и ее решение.
Если задача сформулирована как "выбрать максимально компактное представление разреженной матрицы, не требующее более чем О(1) дополнительной памяти и O(N) времени для чтения/записи", то fseek сосет. Он не просто ненужен, он вреден.
Если задача сформулирована как "реализовать алгоритм с записью длины записанных данных в начале", то сериализация по определению не подходит. Мне это казалось настолько очевидным, что даже спорить собственно не с чем. То есть ты взял исходные условия, в которых было сказано "последовательно записывать нельзя", и пытаешься нам доказать, что это порочит саму идею сериализации. С этим никто не спорит. Мы спорим с выбором формата. Когда тебя спрашивают "а нафига такой формат" — ты отвечаешь "чтобы объем сэкономить". Тебе говорят "так можно сэкономить не меньше, а даже больше", и ты вдруг заявляешь, что формат менять уже нельзя. Ты все-таки реши, формат откуда взялся — злой начальник тебе спустил его директивно, или ты сам его выбрал. Если сам — то по прежнему непонятно, зачем ты его выбрал таким.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И все они бредят. Не форум прямо таки, а просто сумасшедший дом. И только несколько человек в нем не бредят и все эти бредни упорно разоблачают. Хвала им и слава за это !
Может не бредят, а зублуждаются. И почти уверен, что искренне. Но радости от этого никакой (с).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Зачем думать на бумаге если можно подумать в коде? Причем лично мне с бумагой работать очень не удобно. Мне гораздо удобней набить код в редакторе используя всякие фишки тогоже ReSharper'а от автокмплита и хотфиксов до различных рефакторингов. WH>Короче к тому времени как eao197 закончит рисовать на бумажке у меня уже будет работающий прототип. А как уже говорилось косяки в живом коде видны гораздо лучше чем на бумаге.
на самом деле, проектирование на бумаге тоже имеет некоторый смысл. Я сам этим иногда пользуюсь — так проще систематизировать свои мысли. Другой вопрос, что необходимость в этом возникает только для очень сложных и неясных для меня задач, и проектирование на бумаге я делаю только для самого верхнего уровня архитектуры. Только описание общих идей и концепций — никаких описаний классов, максимум — описание основных компонентов системы.
Здравствуйте, eao197, Вы писали:
E>А вообще мне кажется, что во многих областях, где требуется создание высоконадежного ПО (медицина, энергетика, транспорт, связь, авиция, космонавтика, военные направления) накапливается большой и уникальный в своем роде опыт. Только он не выставляется напоказ (в отличии от) и ознакомиться с ним не так просто.
тут недавно обсуждали падение Ариан 5. Мы мало что знаем об использованном процессе разработки, но некоторые выводы можно сделать и по косвенным данным. И выводы эти неутешительны:
1. Интегральное тестирование системы (с помощью генератора полетных данных) не проводилось, или проводилось спустя рукава.
2. Важнейшая информация (ограничение на характеристики аппарата, на котором может использоваться софт) не была задокументирована должным образом.
И это — тот самый высоконадежный софт, о котором все говорят с таким придыханием?
Может быть, информация и правда не афишируется. Может быть, просто для того, чтобы не сняли голову с ответственных за разработку?
Здравствуйте, Дарней, Вы писали:
Д>тут недавно обсуждали падение Ариан 5. Мы мало что знаем об использованном процессе разработки, но некоторые выводы можно сделать и по косвенным данным. И выводы эти неутешительны: Д>1. Интегральное тестирование системы (с помощью генератора полетных данных) не проводилось, или проводилось спустя рукава. Д>2. Важнейшая информация (ограничение на характеристики аппарата, на котором может использоваться софт) не была задокументирована должным образом. Д>И это — тот самый высоконадежный софт, о котором все говорят с таким придыханием? Д>Может быть, информация и правда не афишируется. Может быть, просто для того, чтобы не сняли голову с ответственных за разработку?
Да тут еще недавно обсуждали N самых дорогих багов (включая и приводившие к человеческим жертвам). И еще где-то мелькали ссылки на воспоминания о разработке совецких систем для космических кораблей (когда непосредственно в ЦУП-е во время стыковки кораблей обнаружились баги в ПО бортового компьютера из-за того, что кто-то в исходниках поменял какие-то константы).
Только ведь смотря с чем сравнивать. Если сравнить с количеством багов, вылавливаемых в ядрах Linux-а или количество упдейтов, закачиваемых моей виндой с Live Updates, то мне представляется, что софт для спутников или мониторинга газовых трубопроводов действительно отличается надежностью в лучшую сторону. И даже если сравнивать финансовые потери от гибели Ариан 5 и от последствий вируса "I Love You", то может оказаться, что Ариан 5 -- это копейки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Только ведь смотря с чем сравнивать. Если сравнить с количеством багов, вылавливаемых в ядрах Linux-а или количество упдейтов, закачиваемых моей виндой с Live Updates, то мне представляется, что софт для спутников или мониторинга газовых трубопроводов действительно отличается надежностью в лучшую сторону.
А если добавить в уравнение объем функционала Линукса с одной стороны и бортового софта — с другой?
Здравствуйте, Дарней, Вы писали:
Д>А если добавить в уравнение объем функционала Линукса с одной стороны и бортового софта — с другой?
А мы какое уравние рассматриваем?
Можно оправдывать глючность софта его сложностью и сроками выхода на рынок. Можно, но уже не хочется. Слишком много вокруг глючного софта (включая и мой собственный)
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не надо банальные истины преподносить. Никакие тесты не могут гарантировать отсутствие ошибок, об этом все давно знают. Я вовсе не об этом говорил.
Я до того, как прочел ваши слова
И переделывать если его будут все же, то проверят не раз, и не два, а на полном наборе тестов, которых там (специально посмотрел сейчас) 119495. 5 часов примерно прогон их занимает.
тоже думал, что об этом все и давно знают. И о чем же Вы говорили? Я понял так, что Вы полагаете возможным использовать потенциально опасный код для максимизации скорости, а корректность этого опасного кода проверять тестами. Я что-то неправильно понял? Сначала Вы уповаете на тесты, а потом соглашаетесь, что гарантию правильной работы они не дают? Означает ли это то, что Вы согласны с тем, что использовать безопасный код, естественно, с некоторой потерей скорости правильнее, чем опасный? Или считаете, что для вычислительных задач скорость вычисления важнее (ха ха) правильности результата?
Это уже анекдот какой-то. "Я решаю СЛАУ почти мгновенно! Правда, такая фигня получается..."
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Никак. За полной ненадобностью в той задаче, о которой я говорил. WH>Задача о которой ты говорил требовала сделать структуру данный по которой потом выполнялись запросы.
Мы о чем говорим ? О моем рабочем коде ? Тогда да. Или о сериализации матрицы ? Тогда нет — это Sinclair придумал, что там есть запросы. Я их там не вижу.
WH>А я говорю про сохранение/загрузку разряженой матрици. Именно эту задачу ты предложил расмотреть в начале. Без каких либо извращений с запросами, а когда тебе показали что fseek не только не нужен но еще и вредит ты начал менять задачу с сохранение/загрузи на запросы. PD>>К примеру, winrar решительно не умеет записывать архивы прямо-таки в сеть. WH>А GZipStream если его вывод направить в NetworkStream может.
А на экран графический он может ? Почему ты все время хочешь какого-то расширения там, где это вовсе не требуется.
PD>>И PhotoShop каринки в сеть не отправляет. PD>>И наш любимый VS бинарники пишет только в файл, а вовсе не в сеть. WH>Им приходится работать с вполне конкретными форматами многие из которых не расчитаны на сеть. WH>И что это доказывает кроме того что есть задачи которые принципиально не укладываются в сериализацию? Причем с этим никто не спорил.
А их, ИМХО, очень много. И им совсем незачем рассчитывать на сеть. Я с трудом представляю себе линкер, который отправляет EXE прямо в сеть (на сетевой диск — конечно). И VS не посылает .cs в сеть. И вообще работа с сетью — только небольшая часть мира. Во многих случаях этого просто не надо.
А доказывает это одно — не надо придумывать себе проблемы там, где их нет. И не надо левой рукой дергать за правое ухо. Т.е. применять эту сериализацию там, где нет по смыслу задачи строго последовательного вывода (в сеть ту же, к примеру)
WH>Тебе пытаются объяснить что алгоритм не должен требовать от интерфейса сущностей с которыми он работает больше чем ему необходимо. Для сохранения матрици не нужно произвольного доступа. Это все прекрасно реализуется при помощи потока. Следовательно нужно использовать поток. Иначе связаность системы повысится на ровном месте, а это ни когда ни к чему хорошему не приводило.
Какая там к богу связность, есди я напишу одну-единственную функцию, которая выводит матрицу в файл!
PD>>Ну и на здоровье. А у меня этого задача не требует. WH>Сейчас не требует, а через год потребует... причем тебя на том проекте уже на будет... вот люди которые будут это переписывать, а потом еще писать конверторы из твоего формата в последовательный очень много теплых слов о тебе скажут.
Ну так мы далеко пойдем. Вот пишут сейчас в MS следующую версию VS. Они что, должны думать о том, что в 2020 году будут методы исполнения программ в Интернете непосредственно да еще с распараллеливанием, и исходя из этого, проектировать возможность
многокомпьютерной обработки с пока что несуществующими протоколами ?
PD>>Все это слова, увы. А если потребуется эту матрицу в виде двумерной таблицы на экран выводить ? Тут ни мой fseek, ни твоя сериализация не подойдут, а придется все равно что-то иное писать с помощью то ли GDI+, то ли WriteLine... WH>Опять подмена задачи? Причем подмена из серии: тебе говорят что котлованы для фундамента удобно копать экскаватором, а ты спрашиваешь как при помощи этого экскаватора стекла в окно всавлять.
Ничего подобного. Ты говоришь — необходимо предусмотреть расширяемость на то, о чем пока что речи нет по условиям задачи. У меня пока что речи о выводе в сеть нет, я, по твоим словам, должен об этом думать и позаботиться о том, что если она появится, чтобы легко было модифицировать. Я не исказил твои слова ? Вроде нет. Ну вот отвечаю — а почему ты не думаешь о том, что эту матрицу придется, может быть (и с гораздо большей, между прочим, вероятностью) как-то выводить отнюдь не в сеть, а на экран. Ну вот и выкини свою сериализацию и пиши так, чтобы можно было в случае чего легко это переделать для вывода и на экран. А я посмотрю
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мы о чем говорим ? О моем рабочем коде ? Тогда да. Или о сериализации матрицы ? Тогда нет — это Sinclair придумал, что там есть запросы. Я их там не вижу.
Правильно нету. Но они там появились когда ты подменил задачу с просто сохранить/востановить, на сохранить со средним арифметическим и востановить только те строки у которых среднее больше какогото числа.
Выделеное это запрос.
PD>А на экран графический он может ?
Может. Если написать какойнибудь ScreenStream который какимто одному ему ведомым способом будет визуализировать бинарный поток. Хотя смысла в этом нет никакого. Разве что для отладки того что генерирует сериализатор. PD>Почему ты все время хочешь какого-то расширения там, где это вовсе не требуется.
Я хочу чтобы решения не требовали больше чем необходимо. Твои решения требуют больше чем необходимо. Они не эффективны с точки зрения архитектуры программы.
А самое смешное в том что тебе показали как сделать не мение эффективное с точки зрения производительности решение без потерь с точки зрения архитектуры.
PD>А их, ИМХО, очень много.
Вот только сохранение/загрузка в их число не входят. По крайней мере небыло еще ни одного контр примера. PD>И им совсем незачем рассчитывать на сеть. Я с трудом представляю себе линкер, который отправляет EXE прямо в сеть (на сетевой диск — конечно). И VS не посылает .cs в сеть. И вообще работа с сетью — только небольшая часть мира. Во многих случаях этого просто не надо.
Да причем тут линкер? Он решает совсем другие задачи.
PD>А доказывает это одно — не надо придумывать себе проблемы там, где их нет. И не надо левой рукой дергать за правое ухо. Т.е. применять эту сериализацию там, где нет по смыслу задачи строго последовательного вывода (в сеть ту же, к примеру)
Может быть ты работаешь в узкой нише где однажды полученое ТЗ никогда не меняется?.. вот только в реальном мире все совсем не так. Сегодня не нужно пересылать матрици по сети, а завтра появилась необходимость сделать кластер. Что будешь по новой писать сохранение/загрузку матриц для того чтобы пересылать их между машинами?
PD>Какая там к богу связность, есди я напишу одну-единственную функцию, которая выводит матрицу в файл!
Вот ты и намертво привязал сохранение/загрузку матрици к файлу. Все приехали. Одна матрица — один файл. Причем матрица там будет лежать открытым текстом. Ни сжать, ни зашифровать..., а если это понадобится что делать будешь? Правильно второй раз переписывать сохранение матрици.
PD>Ничего подобного. Ты говоришь — необходимо предусмотреть расширяемость на то, о чем пока что речи нет по условиям задачи. У меня пока что речи о выводе в сеть нет, я, по твоим словам, должен об этом думать и позаботиться о том, что если она появится, чтобы легко было модифицировать. Я не исказил твои слова ? Вроде нет.
Я не это говорю. Я говорю что нельзя использовать толстые интерфейсы там где можно использовать тонкие. Произвольнй доступ vs последовательный это один из случаев толстый интерфейс vs тонкий.
А плохо это тем что уменьшает расширяемость системы.
PD>Ну вот отвечаю — а почему ты не думаешь о том, что эту матрицу придется, может быть (и с гораздо большей, между прочим, вероятностью) как-то выводить отнюдь не в сеть, а на экран. Ну вот и выкини свою сериализацию и пиши так, чтобы можно было в случае чего легко это переделать для вывода и на экран. А я посмотрю
Вот ты опять подменяешь задачу для того чтобы выкрутиться. Что я буду считывать с экрана? Экран штука write-only. А мы говорим о сохранении/загрузки. Ты еще потребуй чтобы код сохранения в DOOM'е ботов гонял... это требование вполне вписывается в твою логику на счет экрана.
Ты сейчас занимаешься тем что пытаешься довести мои слова до абсурда тем самы доказав свою правоту. Это называется демагогия.
Ну сказал фигню на счет того что матрицу нельзя эффективно сериализовать. Ну признай что не прав. Все мы люди. Все мы иногда ошибаемся.
Я тебя прекрасно понимаю ты привик писать максимально эффективно. Я сам несколько лет назад такой фигней страдал.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кому как. Если считать, что они "зублуждаются" — то нет. А вдруг они правы ?
Понимаешь в чем дело? Есть вопросы спорные. Но есть и довольно очевидные. Например, твоя неправота в вопросах абстракции для меня настолько очевидна, что любые мои попытки усомниться только угрепляют уверенность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
WH>Правильно нету. Но они там появились когда ты подменил задачу с просто сохранить/востановить, на сохранить со средним арифметическим и востановить только те строки у которых среднее больше какогото числа. WH>Выделеное это запрос.
Ну и на здоровье. Задачу я, верно, слегка подмеил. Хочешь считать это запросом — бога ради. Это ИМХО не столь существенно, термины меня мало интересуют. Суть же остается — в таком виде это проще читать, а сохранять — никаких проблем нет.
PD>>А на экран графический он может ? WH>Может. Если написать какойнибудь ScreenStream который какимто одному ему ведомым способом будет визуализировать бинарный поток
Слушай,а зачем все это надо, объясни бога ради. Я понимаю, когда в сетевых приложениях пытаются все вывести в поток. Но ведь это частный случай, не более. Экран по определению не есть устройство последовательного доступа, файл — тоже, можно и еще что-то придумать. Зачем насиловать задачу, пытаясь приспособить поток там, где он совсем не нужен.
В конце концов поток — просто структура данных "последовательность", а сериализация есть преобразование данных в эту структуру. Есть еще десятки других структур — списки, деревья, графы и т.д. Можно придумать алгоритм "деревизации" — преобразования неких данных в форму дерева. Где-то это имеет смысл, но не везде же.
Что же вы за эту сериализацию так уцепились ? Только потому, что в сетевых приложениях это единственно возможный способ передачи ? Но мир ИТ не исчерпывается сетевыми приложениями.
. Хотя смысла в этом нет никакого. Разве что для отладки того что генерирует сериализатор. PD>>Почему ты все время хочешь какого-то расширения там, где это вовсе не требуется. WH>Я хочу чтобы решения не требовали больше чем необходимо. Твои решения требуют больше чем необходимо. Они не эффективны с точки зрения архитектуры программы.
Они именно эффективны. Потому что не пытаются сериализовать на устройство прямого доступа (файл) и не насилуют ради этого алгоритм. А всякая попытка изменить алгоритм так, чтобы он соответствовал неким заранее определенным принципам, а не своей внутренней логике, приводи именно к неэффективности.
WH>А самое смешное в том что тебе показали как сделать не мение эффективное с точки зрения производительности решение без потерь с точки зрения архитектуры.
Да ничего мне не показали. Я же четко условия выставил. Могу повторить
Вывести матрицу в указанном формате (число троек — тройки) при условии, что
1. Один проход, не более
2. Дополнительная память — O(1). Хоть явно, хоть неявно.
Никто этого решения не предложил, его просто нет. Все, что предлагали — либо 2 прохода, либо дополнительная память. А при таких решениях и обсуждать нечего, совершенно ясно, как сделать.
Если я не прав — пожалуйста, ссылку на решение с соблюдением этих двух условий. Может, я что-то пропустил...
Но обсуждать преимущества и недостатки решений, нарушающих хоть одно из этих условий, я не буду. Это дано и не обсуждается.
PD>>А их, ИМХО, очень много. WH>Вот только сохранение/загрузка в их число не входят. По крайней мере небыло еще ни одного контр примера.
Хм, интересно. А загрузка/сохранение в/из БД тоже есть сериализация ? А если не в БД, а в мой собственный файл, то как ?
PD>>И им совсем незачем рассчитывать на сеть. Я с трудом представляю себе линкер, который отправляет EXE прямо в сеть (на сетевой диск — конечно). И VS не посылает .cs в сеть. И вообще работа с сетью — только небольшая часть мира. Во многих случаях этого просто не надо. WH>Да причем тут линкер? Он решает совсем другие задачи.
При том, что он создает файл некоторой структуры. Так сказать, сохраняет в определенном формате. И Paint, создающий BMP, тоже сохраняет в определенном формате, и там тоже поток не проходит, так как заголовок содержит длину файла, а она выяснится после сохранения вследствие RLE. И, уверен, еще много других форматов есть. Те же TTF, думаю, хотя нет времени посмотреть. Другие графические форматы. И т.д. Потому что разумные люди задачу не насилуют и формат строят не из соображений "легко вывести последовательно", а из соображений "удобно работать".
WH>Может быть ты работаешь в узкой нише где однажды полученое ТЗ никогда не меняется?.. вот только в реальном мире все совсем не так. Сегодня не нужно пересылать матрици по сети, а завтра появилась необходимость сделать кластер. Что будешь по новой писать сохранение/загрузку матриц для того чтобы пересылать их между машинами?
Ох, не стоит эту тему поднимать. Боюсь что завтра от тебя потребуют не кластер сделать, а заменить матрицу на Б-дерево, чтобы соответствовать новым ТЗ . Я как раз такой работой сейчас и занимаюсь — есть БД, в ней документы хранятся, а теперь вдруг потребовалось хранить различные версии этих документов. И все переделывать приходится. Ну не могли авторы этого предположить и заложить в архитектуру. Не требовалось им это.
Так что в какую сторону переделка пойдет — большоц вопрос. И что понадоится менять — тоже. И как — тоже.
PD>>Какая там к богу связность, есди я напишу одну-единственную функцию, которая выводит матрицу в файл! WH>Вот ты и намертво привязал сохранение/загрузку матрици к файлу. Все приехали. Одна матрица — один файл. Причем матрица там будет лежать открытым текстом. Ни сжать, ни зашифровать..., а если это понадобится что делать будешь?
Не надо мне проблемы придумывать там, где их нет, еще раз повторяю. Не хватает мне только шифрования данных квантовой химии и сжатия текстовых файлов , которые пользователь может вручную редактировать, для чего, собственно, этот вывод в указанном формате и делается.
>Правильно второй раз переписывать сохранение матрици.
Если это мне даже и понадоится (в данной задаче — 100% исключено) — за полчаса перепишу.
WH>Вот ты опять подменяешь задачу для того чтобы выкрутиться. Что я буду считывать с экрана? Экран штука write-only.
Ну это ты, мягко выражаясь, сильно неправ. С экрана дисплея, точно, не считывают, а из видеопамяти — за милую душу.А она и содержит то, что ототбражает экран. Ты хоть с основными понятиями DirectX знаком ?
WH>Ты сейчас занимаешься тем что пытаешься довести мои слова до абсурда тем самы доказав свою правоту. Это называется демагогия.
WH>Ну сказал фигню на счет того что матрицу нельзя эффективно сериализовать. Ну признай что не прав. Все мы люди. Все мы иногда ошибаемся.
Да не сказал я никакой фигни. См. мои условия и код в студию.
Здравствуйте, Sinclair, Вы писали:
S>Павел, тут налицо какое-то недопонимание. Я даже не знаю, как к нему подступиться. Ну вот ты пишешь, что тебя интересовал совершенно конкретный формат. Павел, это все равно, как спросить "как мне поделить на три без деления". Хотя нет, делить без деления все-таки можно. Короче говоря, ты все время путаешь задачу и ее решение.
Skipped как очережная попытка увести обсуждение в сторону. Если я требую определенный формат — значит он и именно он нужен. Почему — не обсуждается. Так надо.
S>Если задача сформулирована как "выбрать максимально компактное представление разреженной матрицы, не требующее более чем О(1) дополнительной памяти и O(N) времени для чтения/записи",
Так она не формулируется. Формулируется именно "в определенном формате". Формат был описан с самого начала. Обсуждать все другие форматы и алгоритмы я не намерен.
S>Если задача сформулирована как "реализовать алгоритм с записью длины записанных данных в начале", то сериализация по определению не подходит.
Вот это и есть ответ.
>Мне это казалось настолько очевидным, что даже спорить собственно не с чем. То есть ты взял исходные условия, в которых было сказано "последовательно записывать нельзя", и пытаешься нам доказать, что это порочит саму идею сериализации.
Я хотел лишь показать, что ее здесь не надо впихивать насильно и ломать ради нее формат данных.
>С этим никто не спорит. Мы спорим с выбором формата.
А это меня не интересует. Спорьте с кем угодно, но не со мной. Это "дано".
> Когда тебя спрашивают "а нафига такой формат" — ты отвечаешь "чтобы объем сэкономить".
Сожалею, что ввязался в эту часть дискуссии. На твои вопросы "зачем" лучше вообще не отвечать. В противном случае ты обязательно уведешь вопрос в сторону, начнешь предлагать архивацию и т.д.
>Тебе говорят "так можно сэкономить не меньше, а даже больше", и ты вдруг заявляешь, что формат менять уже нельзя.
Именно, Нельзя.
>Ты все-таки реши, формат откуда взялся — злой начальник тебе спустил его директивно, или ты сам его выбрал. Если сам — то по прежнему непонятно, зачем ты его выбрал таким.
Взял я его таким потому, что мне такой нужен. И все. И правильно ли я его выбрал в этой задаче — не обсуждается.
И вообще впредь, если доведется с тобой что-то обсуждать, я буду решительно отводить все попытки уводить дискуссию в сторону от поставленной задачи. То, что дано в условии — это дано, и посему не обсуждается. Прими к сведению.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кому как. Если считать, что они "зублуждаются" — то нет. А вдруг они правы ?
VD>Понимаешь в чем дело? Есть вопросы спорные. Но есть и довольно очевидные. Например, твоя неправота в вопросах абстракции для меня настолько очевидна, что любые мои попытки усомниться только угрепляют уверенность.
(Выделено мной- PD).
Во-первых, я так и не получил внятного объяснения, в чем именно я неправ, говоря об абстракциях. Потому что я о них просто почти ничего не говорил вообще. Может, я неправ именно в том. что не говорил ? Так я много о чем не говорил...
Ну а главное -ь в выделенном мной. Для тебя. А для других это и не очевидно, и даже вполне очевидно противоположное.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во-первых, я так и не получил внятного объяснения, в чем именно я неправ, говоря об абстракциях.
Ты их получил. И от разных людей. Но то ли не можешь, то ли не хочешь понять. Биться о стену чтобы тебе что-то доказать у меня просто нет сил и желания.
PD>Ну а главное -ь в выделенном мной. Для тебя. А для других это и не очевидно, и даже вполне очевидно противоположное.
Да нет проблем. Считай себя правым. Еще раз повторяю я разбиваться о стену не намерен. Я высказал свое мнение. Твое право прислушаться или делать все как делал.
Только когда будель молодых учить дай им думать своей головой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и на здоровье. Задачу я, верно, слегка подмеил.
Следовательно все дальнейшие рассуждения идут в лес. PD>Хочешь считать это запросом — бога ради. Это ИМХО не столь существенно, термины меня мало интересуют. Суть же остается — в таком виде это проще читать, а сохранять — никаких проблем нет.
Раз нужны запросы, а запросов обычно бывает много то эти записи нужно не просто сохранить, а еще и упорядочить по среднему значению и сделать индекс ибо чтение с диска операция очень медленная и поднимать 100метровый файл из-за пары строк это маразм. Так что твой вариант побыстрому все сохранить за один проход не подходит для этой задачи.
WH>>Может. Если написать какойнибудь ScreenStream который какимто одному ему ведомым способом будет визуализировать бинарный поток PD>Слушай,а зачем все это надо, объясни бога ради.
А может ты не будешь заниматься художественной резьбой по цитированию?
WH>>. Хотя смысла в этом нет никакого. Разве что для отладки того что генерирует сериализатор.
PD>Они именно эффективны. Потому что не пытаются сериализовать на устройство прямого доступа (файл) и не насилуют ради этого алгоритм. А всякая попытка изменить алгоритм так, чтобы он соответствовал неким заранее определенным принципам, а не своей внутренней логике, приводи именно к неэффективности.
Ты зациклился на алгоритме. А я говорю об архитектуре программы. Твои завязки на то что всегда будут сохранять в файл приводят к повышению связанности программы.
После того как ты это сделал ты уже не можешь направить вывод на последовательное устройство. Не можешь воспользоваться алгоритмом поточной компрессии...
Причем самое печальное в том что такие закладки на конкретные алгоритмы и полное забивание на архитектуру крайне негативно сказываются при поддержке программы. В плодь до того что порой такие программы приходится переписфывать полностью.
PD>Да ничего мне не показали. Я же четко условия выставил. Могу повторить
И так какая задача у нас стоит? Сохранить/загрузить матрицу или сохранить/загрузить использую строго заданный формат файла?
Если у нас первый случай то тебе показали как можно сериализовать матрицу за один проход и O(1) памяти причем без увеличения размера результата и какие преймущества нам дает сериализация.
Если у нас стоит следующая задача:
PD>Вывести матрицу в указанном формате (число троек — тройки) при условии, что
PD>1. Один проход, не более
PD>2. Дополнительная память — O(1). Хоть явно, хоть неявно.
PD>Никто этого решения не предложил, его просто нет. Все, что предлагали — либо 2 прохода, либо дополнительная память. А при таких решениях и обсуждать нечего, совершенно ясно, как сделать.
То очевидно что она неразрешима при использовании сериализации. Те если нужно прогнутся под конкретный формат (который я считаю крайне не удачным) и выдержать требования по памяти (требование одного прохода лишнее... сам догадаешься почему?) то я буду использовать произвольный доступ. Однако если в моей власти будет изменить этот формат то я это сделаю для того чтобы уменьшить связаность программы.
PD>Хм, интересно. А загрузка/сохранение в/из БД тоже есть сериализация ?
В какую БД? БД бывают очень разными. К томуже что касается реляционной БД то у меня есть чувство что сложные объекты типа разряженной матрицы лучше всего хранить в блобе... который предварительно можно сжать... PD>А если не в БД, а в мой собственный файл, то как ?
В какой файл? Что за формат у этого файла? Ах да... жестко фиксированный с непонятно какой целью.
PD>При том, что он создает файл некоторой структуры. Так сказать, сохраняет в определенном формате. И Paint, создающий BMP, тоже сохраняет в определенном формате, и там тоже поток не проходит, так как заголовок содержит длину файла, а она выяснится после сохранения вследствие RLE.
Если бы там использовалось чтонибудь поумнее RLE то длинну потока записывать былобы не нужно. PD>И, уверен, еще много других форматов есть. Те же TTF, думаю, хотя нет времени посмотреть. Другие графические форматы. И т.д. Потому что разумные люди задачу не насилуют и формат строят не из соображений "легко вывести последовательно", а из соображений "удобно работать".
Нормальные люди для того чтобы было удобно работать наворачивают на картинками абстракции. И работают уже с какимнибудь IImage. Далие реализуют ImagePNG, ImageBMP... И им начхать что за файл лежит на диске или прилетел по сети.
PD>Ох, не стоит эту тему поднимать. Боюсь что завтра от тебя потребуют не кластер сделать, а заменить матрицу на Б-дерево, чтобы соответствовать новым ТЗ .
Это всеравно что если заказчик по середине проекта скажет: Не хочу систему учета. Напишите мне DOOM. PD>Я как раз такой работой сейчас и занимаюсь — есть БД, в ней документы хранятся, а теперь вдруг потребовалось хранить различные версии этих документов. И все переделывать приходится. Ну не могли авторы этого предположить и заложить в архитектуру. Не требовалось им это.
А можно по подробней описать что система делала и как это должно измениться после переделки? И что нужно переделать?
Мне что-то подсказывает что авторы этой системы сделали что-то не так с архитектурой. В нормальной системе всеголишь нужно добавить в таблицу с документами версию документа и немного расширить интерфейс DAL(data access layer). На этом переделки собственно и закончились. Дальше идет написание нового функционала который использует расширеные возможности DAL.
В большинстве проектов подобные изменения в ТЗ происходят постоянно. И если система расчитана на непредсказуемое изменение требований (в приделах предметной области те из MathCad'а DOOM никто делать не будет) то такие изменения не должны занимать много времени. И именно по этому я и считаю что архитектура должна быть максимально гибкой вобще и не использовать произвольный доступ там где хватает последовательного в частности.
PD>Не надо мне проблемы придумывать там, где их нет, еще раз повторяю. Не хватает мне только шифрования данных квантовой химии и сжатия текстовых файлов , которые пользователь может вручную редактировать, для чего, собственно, этот вывод в указанном формате и делается.
Ага... те у нас появилось требование чтобы эти файлы мог править человек? Блин как ты лихо подменяешь задачи... То у нас кондовый бинарный формат... а то вдруг файлы должен править пользователь... Тебя не поймешь...
PD>Если это мне даже и понадоится (в данной задаче — 100% исключено) — за полчаса перепишу.
За пол часа? С тестированием? С конвертером? Не верю.
А если у тебя в программе сотня различных классов? И на каждый по пол часа, а это время еще доказать надо...
А если у нас что-то болие сложное чем сохранение/загрузка? Ведь сохранение/загрузка в какоето хранилище это абстракции очень низкого уровня... обычно она спрятана глубоко в нутри DAL... А вот если ты интерфейс DAL сделаешь шире чем необходимо (ну там из соображений "эффективности" завяжешся на реляционную БД или еще хуже на конкретную БД) то при попытке сменить хранилище придет толстая полярная лисица и заставит переписать пол проекта.
PD>Ну это ты, мягко выражаясь, сильно неправ. С экрана дисплея, точно, не считывают, а из видеопамяти — за милую душу.А она и содержит то, что ототбражает экран. Ты хоть с основными понятиями DirectX знаком ?
DirectX я не хуже тебя знаю. И прекрасно знаю что из видео памяти можно читать. Болие того сам читал... правдо дело было еще под досом и делалось это чисто ради прикола(в текстовом режиме по таймеру последовательно заменял друг на друга -\!/ и получалось какбы вращение, еще игрался с эффектом пламени). Вот только чтение из видио памяти с логической точки зрения бред. Оно может быть оправдано только ради каких либо хаков... например под досом когда памяти было очень мало приходилось делать некоторые граффически эффекты прямо в видио памяти.
Кстати на современных видюхах чтение из видио памяти нааамнооого медленней чем запись в видио память. Ибо шина заточена на передачу данных из системной памяти в видио память, а обратный канал сделали намного уже по тому что из видио памяти нормальные люди ничего не читают. Ну разве что иногда скриншоты делают. Или еще реже используют GPU не по прямому назначению, а для того чтобы шейдерами дробить числа не связанные на прямую с обработкой графики.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Дворкина о том, что строки мне на клиент [...] попадает как последовательность ASCIIZ (sic! не "хранятся в базе данных"!) без длины, так по этому поводу уважаемые оппоненты, вероятно, забыли, что не все интерфейсы к базам данных возвращают длину строкового поля. Мне, во всяком случае встречалось такое в 90-е. И кстати строки в C-интерфейсах вообще не особо принято было сопровождать полем длины. Чему Win API и служит примером.
Хм.. Как-то пропустил это место. Спасибо за защиту , но защитить я и сам себя сумею.
Во-первых, я не утверждал ничего насчет того, как там внутри БД. Цитирую из одиозного
PD>Внутри себя этот SELECT на сервере я не знаю что делает, но мне на клиент в итоге строка попадает как последовательность ASCIIZ.
Так что речь идет только о том, в каком виде мне ее возвращают.
MYSQL_ROW row;
unsigned int num_fields;
unsigned int i;
num_fields = mysql_num_fields(result);
while ((row = mysql_fetch_row(result)))
{
unsigned long *lengths;
lengths = mysql_fetch_lengths(result);
for(i = 0; i < num_fields; i++)
{
printf("[%.*s] ", (int) lengths[i], row[i] ? row[i] : "NULL");
}
printf("\n");
}
MYSQL_ROW is an array of null-terminated strings. (However, you cannot treat these as null-terminated strings if field values
may contain binary data, because such values may contain null bytes internally.) You can use the row data in any function
expecting a null-terminated string.
Итак, данные запроса возвращают в формате ASCIIZ строк, но и длину тоже , выходит, возвращают. М-да...
Но вот передо мной лежит книга П.Дюбуа 2001 года издания. И в ней на стр. 728 черным по белому сказано
Функция mysql_fetch_lengths впервые появилась в MySQL версии 3.20.5
Резюмирую. Данные возвращают в ASCIIZ. Но с некоторых пор добавлена функция, которая еще и длину возвращает. Спасибо, конечно, и правильно, что добавили ее, но и только. А суть осталась преждней — ASCIIZ.
Да и не могло быть иначе. Нет другого формата, который являлся бы универсальным. Эту ASCIIZ можно потом и Perl скормить, и PHP и , конечно, С++.
Ну а потом, конечно, когда все это попадет в зубы ODBC/OLE DB/ADO(ADO.NET) и т.д., там не только длину приделают, но при необходимости в синий цвет покрасят
Pavel Dvorkin,
PD>Да и не могло быть иначе. Нет другого формата, который являлся бы универсальным. Эту ASCIIZ можно потом и Perl скормить, и PHP и , конечно, С++.
А Unicode в asciiz?
Однако я склоняюсь к мысли, что лучше универсальная строка с необходимыми конвертерами в (из..) различные форматы (в т.ч. и asciiz). Лучше в том смысле, что ценой небольшого оверхеда (создание объекта вместо создания указателя) мы получаем возможность прозрачно работать со строками.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну и на здоровье. Задачу я, верно, слегка подмеил. WH>Следовательно все дальнейшие рассуждения идут в лес.
Не совсем. Просто некоторая модификация
PD>>Хочешь считать это запросом — бога ради. Это ИМХО не столь существенно, термины меня мало интересуют. Суть же остается — в таком виде это проще читать, а сохранять — никаких проблем нет. WH>Раз нужны запросы, а запросов обычно бывает много то эти записи нужно не просто сохранить, а еще и упорядочить по среднему значению и сделать индекс ибо чтение с диска операция очень медленная и поднимать 100метровый файл из-за пары строк это маразм. Так что твой вариант побыстрому все сохранить за один проход не подходит для этой задачи.
Побойся бога, какие там 100 метровые файлы, где я об этом писал. Посмотри внимательно , о чем шла речь — о среднем некоторого количества чисел в строке . Чтобы 100 метровый файл сделать, там сотни тысяч выборок должны быть, о чем ты.
WH>>>Может. Если написать какойнибудь ScreenStream который какимто одному ему ведомым способом будет визуализировать бинарный поток PD>>Слушай,а зачем все это надо, объясни бога ради. WH>А может ты не будешь заниматься художественной резьбой по цитированию?
??? ничего не понял.
PD>>Они именно эффективны. Потому что не пытаются сериализовать на устройство прямого доступа (файл) и не насилуют ради этого алгоритм. А всякая попытка изменить алгоритм так, чтобы он соответствовал неким заранее определенным принципам, а не своей внутренней логике, приводи именно к неэффективности. WH>Ты зациклился на алгоритме.
Именно
>А я говорю об архитектуре программы. Твои завязки на то что всегда будут сохранять в файл приводят к повышению связанности программы.
Нет. Еще раз — в очень многих случаях никакого вывода куда бы то ни было, кроме файла, по условию задачи нет и быть не может. Ты просто переносишь принципы web-программирования на все остальное ПО. Ну не будет Photoshop выводить рабочие файлы в сеть. Не будет, и все!
WH>После того как ты это сделал ты уже не можешь направить вывод на последовательное устройство. Не можешь воспользоваться алгоритмом поточной компрессии...
И не требуется это, пойми же! Ну не надо, и все .
WH>Причем самое печальное в том что такие закладки на конкретные алгоритмы и полное забивание на архитектуру крайне негативно сказываются при поддержке программы. В плодь до того что порой такие программы приходится переписфывать полностью.
Переписывать, если уж на то пошло, придется лист — вывод во внешнюю память. С чего ради все остальное-то придется переписывать. А это, вообще-то, мелочь, откровенно говоря.
PD>>Да ничего мне не показали. Я же четко условия выставил. Могу повторить WH>И так какая задача у нас стоит? Сохранить/загрузить матрицу или сохранить/загрузить использую строго заданный формат файла?
Второе. При указанных условиях.
WH>Если у нас стоит следующая задача: WH>
PD>Вывести матрицу в указанном формате (число троек — тройки) при условии, что
PD>>1. Один проход, не более
PD>>2. Дополнительная память — O(1). Хоть явно, хоть неявно.
PD>>Никто этого решения не предложил, его просто нет. Все, что предлагали — либо 2 прохода, либо дополнительная память. А при таких решениях и обсуждать нечего, совершенно ясно, как сделать.
WH>То очевидно что она неразрешима при использовании сериализации. Те если нужно прогнутся под конкретный формат (который я считаю крайне не удачным)
Насчет крайне — не надо, его единственный "недостаток" — не годится для сериализации. А вообще подобных форматов очень много, я уже об этом писал. Просто люди, разрабатывавшие PE-формат, отлично понимали, что в сеть его никто выводить не будет за полной ненадобностью А сделать его "сериализуемым" — будет потом сложнее загружать. А на этом формате вся Windows стоит. И не нужны тут лишние проблемы никому.
>и выдержать требования по памяти (требование одного прохода лишнее... сам догадаешься почему?)
Нет, не лишнее. Незачем делать в 2 прохода то, что можно в один делать.
>то я буду использовать произвольный доступ. Однако если в моей власти будет изменить этот формат то я это сделаю для того чтобы уменьшить связаность программы.
А вот с этим соглашусь. Если тебе хочется изменить формат, и у тебя есть к этому серьезные основания (а не расуждения о связанности или о том, что в 2025 году вдруг понадобится это в сеть выводить), то бога ради. Но жертвовать эффективностью сейчас ради возможных (а будут ли еще?) преимуществ потом — ИМХО не есть хорошее дело.
PD>>Хм, интересно. А загрузка/сохранение в/из БД тоже есть сериализация ? WH>В какую БД? БД бывают очень разными. К томуже что касается реляционной БД то у меня есть чувство что сложные объекты типа разряженной матрицы лучше всего хранить в блобе... который предварительно можно сжать...
Ну ладно. Есть так есть, это твои дела. Может, ты прав — правда, это отказ от БД фактически и переход на (псевдо)файл. Но вот вывод обычного класса, содержащего строки и целые, в таблицу БД , где int и varchar, не есть сериализация, а прямой доступ в чистом виде, хоть и не нами писанный.
PD>>А если не в БД, а в мой собственный файл, то как ? WH>В какой файл? Что за формат у этого файла? Ах да... жестко фиксированный с непонятно какой целью.
Не надо ерничать. Цель вполне определенная, хоть и не в этом дело. Пойми наконец, что формат файла определяетися порой далеко не тем, насколько удобно в него сериализовать, а совсем другими факторами.
Ну а если уж хочешь цель — пожалуйста. Я решил, к примеру, MS SQL конкуренцию составить и свою БД написать . Будем туда сериализовать или не станем ?
А если ближе к реальности, то и у меня некиий формат может быть, может, и попроще, чем .mdf, но не то, чтобы уж очень простой.
WH>Если бы там использовалось чтонибудь поумнее RLE то длинну потока записывать былобы не нужно.
Да не в нем же дело. Уверен, еще не один десяток таких форматов найдется. Было бы время — нашел бы.
WH>Нормальные люди для того чтобы было удобно работать наворачивают на картинками абстракции. И работают уже с какимнибудь IImage. Далие реализуют ImagePNG, ImageBMP... И им начхать что за файл лежит на диске или прилетел по сети.
Ты это авторам PhotoShop скажи, они тебя поблагодарят, когда он в 5 раз медленнее работать станет с GDI+ и его реализацией этих абстракций
PD>>Ох, не стоит эту тему поднимать. Боюсь что завтра от тебя потребуют не кластер сделать, а заменить матрицу на Б-дерево, чтобы соответствовать новым ТЗ . WH>Это всеравно что если заказчик по середине проекта скажет: Не хочу систему учета. Напишите мне DOOM.
Да бывает ведь...
PD>>Я как раз такой работой сейчас и занимаюсь — есть БД, в ней документы хранятся, а теперь вдруг потребовалось хранить различные версии этих документов. И все переделывать приходится. Ну не могли авторы этого предположить и заложить в архитектуру. Не требовалось им это. WH>А можно по подробней описать что система делала и как это должно измениться после переделки? И что нужно переделать?
В двух словах — есть БД, в ней в text полях документы хранятся. Все нормально работает. А теперь надо хранить прежние их версии, а это не предусмотрено. Вот и мучаюсь, переделывая всю структуру БД.
WH>Мне что-то подсказывает что авторы этой системы сделали что-то не так с архитектурой. В нормальной системе всеголишь нужно добавить в таблицу с документами версию документа и немного расширить интерфейс DAL(data access layer). На этом переделки собственно и закончились. Дальше идет написание нового функционала который использует расширеные возможности DAL.
Не думаю, что напутали. Не все там так просто.
WH>В большинстве проектов подобные изменения в ТЗ происходят постоянно. И если система расчитана на непредсказуемое изменение требований (в приделах предметной области те из MathCad'а DOOM никто делать не будет) то такие изменения не должны занимать много времени. И именно по этому я и считаю что архитектура должна быть максимально гибкой вобще и не использовать произвольный доступ там где хватает последовательного в частности.
Я как-нибуд ь на эту тему выскажусь
PD>>Не надо мне проблемы придумывать там, где их нет, еще раз повторяю. Не хватает мне только шифрования данных квантовой химии и сжатия текстовых файлов , которые пользователь может вручную редактировать, для чего, собственно, этот вывод в указанном формате и делается. WH>Ага... те у нас появилось требование чтобы эти файлы мог править человек? Блин как ты лихо подменяешь задачи... То у нас кондовый бинарный формат... а то вдруг файлы должен править пользователь... Тебя не поймешь...
Ну-ну. Ладно, принимаю, действительно, имел это в уме только, зря не написал сразу. Но не в этом дело — если и не в текстовом редакторе править (человек), а в ином — это мало что меняет.
PD>>Если это мне даже и понадоится (в данной задаче — 100% исключено) — за полчаса перепишу. WH>За пол часа? С тестированием? С конвертером? Не верю.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем. Просто некоторая модификация
Смешали теплое с мягким и сравнили с красным... Круто...
WH>>Ты зациклился на алгоритме. PD>Именно
И зря.
PD>Нет.
Чего нет? Связанность не повысил? PD>Еще раз — в очень многих случаях никакого вывода куда бы то ни было, кроме файла, по условию задачи нет и быть не может.
Вот только круг этих задач ограничен словами: Создать файл определенного формата. PD>Ты просто переносишь принципы web-программирования на все остальное ПО.
Я Веб программированием никогда не занимался. И не собираюсь. PD>Ну не будет Photoshop выводить рабочие файлы в сеть. Не будет, и все!
См выше.
WH>>Причем самое печальное в том что такие закладки на конкретные алгоритмы и полное забивание на архитектуру крайне негативно сказываются при поддержке программы. В плодь до того что порой такие программы приходится переписфывать полностью. PD>Переписывать, если уж на то пошло, придется лист — вывод во внешнюю память. С чего ради все остальное-то придется переписывать. А это, вообще-то, мелочь, откровенно говоря.
В данном случае я говорю не о сериализации, а вобще. Тут заложился, там заложился... ты же предлагаешь на алгоритмах зацикливаться... И получил из программы лапшу.
>>то я буду использовать произвольный доступ. Однако если в моей власти будет изменить этот формат то я это сделаю для того чтобы уменьшить связаность программы. PD>А вот с этим соглашусь. Если тебе хочется изменить формат, и у тебя есть к этому серьезные основания (а не расуждения о связанности или о том, что в 2025 году вдруг понадобится это в сеть выводить), то бога ради.
А это и есть серьезнае основания. Повишение связанности системы ради мнимой производительности это большая ошибка... Ибо "Premature optimization is the root of all evil". Я не против оптимизаций. Я против преждевременных оптимизаций. PD>Но жертвовать эффективностью сейчас ради возможных (а будут ли еще?) преимуществ потом — ИМХО не есть хорошее дело.
Кто жертвует? КТО!? Тебе показали как матрицу сериализовать без нескольких проходов и с использованием O(1) памяти и без увеличения файла на диске(болие того благодоря поточной компрессии...).
К тому же даже если бы тут и была жертва, а ее нет... то с очень большой вероятностью эту жертву и под микроскопом не увидить.
PD>Ну ладно. Есть так есть, это твои дела. Может, ты прав — правда, это отказ от БД фактически и переход на (псевдо)файл. Но вот вывод обычного класса, содержащего строки и целые, в таблицу БД , где int и varchar, не есть сериализация, а прямой доступ в чистом виде, хоть и не нами писанный.
Еще раз повторюсь: Сериализация это абстракция очень низкого уровня.
В пользовательском коде у меня будет что-то типа
А уж куда и как это дело будет сохранятся мне начхать.
PD>Ну а если уж хочешь цель — пожалуйста. Я решил, к примеру, MS SQL конкуренцию составить и свою БД написать . Будем туда сериализовать или не станем ? PD>А если ближе к реальности, то и у меня некиий формат может быть, может, и попроще, чем .mdf, но не то, чтобы уж очень простой.
Млин. С тобой вобще разговаривать не возможно. Ты постоянно задачи подменяешь.
PD>Ты это авторам PhotoShop скажи, они тебя поблагодарят, когда он в 5 раз медленнее работать станет с GDI+ и его реализацией этих абстракций
Я исходников фотошопа не видел но что-то мне подсказывает что именно так они и сделали. Иначе фотошоп бы умер не успев родиться.
PD>В двух словах — есть БД, в ней в text полях документы хранятся. Все нормально работает. А теперь надо хранить прежние их версии, а это не предусмотрено. Вот и мучаюсь, переделывая всю структуру БД.
Я конечно не вижу всю систему но почему нельзя в таблицу с документами просто добавить колонку с номером версии документа и включить эту колонку в первичный ключ?
PD>Не думаю, что напутали. Не все там так просто.
Если судить по той информации что дал ты то там все очень просто.
Если наш DAL это IDocumentStorage то я не стал бы даже менять IDocumentStorage. Я бы добавил в DocumentKey номер версии. Причем если версию не указать явно то он будет доставать последнюю версию чтобы не поломать уже работающий код.
Что мешает поступить в твоем случае также? Случайно не SQL разбросанный по всей программе?
PD>Ну-ну. Ладно, принимаю, действительно, имел это в уме только, зря не написал сразу. Но не в этом дело — если и не в текстовом редакторе править (человек), а в ином — это мало что меняет.
Задача сохранить/загрузить и задача сохранить/загрузить так чтобы сохраненный формат мог править человек это очень разные задачи.
PD>А конвертор для чего ? Old format supported
Ах да... я просто забл что ты только сохранялку переписываешь, а объектную модель не трогаешь. Просто в моей практике если уж приходится менять сохранялку то только при изменении объектной модели... А там поддержка старого формата это просто вешалка... проще конвертер написать. Можно конечно конвертировать нелету при загрузке но это создает свои провлемы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Не буду больше по пунктам отвечать, так как все это бесконечно, попробую резюмировать.
Твой подход — четкий сверху вниз.
Мой — сочетание сверху вниз и снизу вверх.
Преимущества твоего — большая логичность и (возможно) расширяемость.
Недостаток( ИМХО) — меньшая эффективность за счет более общих решений.
Преимущетсва моего — ближе к реальной машине, учет конкретных особенностей возможной реализации тех или иных абстракций.
Недостаток (по твоему ИМХО) — труднее будет модифицировать в случае чего.
Если я правильно сформулировал, то предлагаю зафиксировать разногласие и закончить дискуссию.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
1.1.4 stable rev. 510
То есть слышать то конечно слышал и даже немного видел, но все те проекты можно смело отнести к разряду псевдонаучной синекуры.
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
