Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
по ней и сужу
Мы уже победили, просто это еще не так заметно...
