Здравствуйте, savaDAN, Вы писали:
DAN>опытный и талантлиовый разработчик напишет большую и сложную систему на любом языке, однако, тот же С#\Java ему поможет следующим (по сравнению с С): DAN>1. классы — легче проектировать
В чем легче? Почему легче? именно опытному разработчику... DAN>2. управление памятью — меньше багов
Т.е. лики памяти опытного разработчика будут заботливо подчищены GC... Гм. не такой уж и опытный этот разработчик раз у него прога ликает. DAN>3. большая стандартная библиотека — меньше кода писать.
Т.е. надо писать на шарпах/жабе потому что там библиотека стандартная больше? Гм. нет ведь библиотеки на все случаи жизни... Где то больше, где то меньше... К примеру я игру разрабатываю. 3D шутер с навороченной графикой. Чем мне в этом поможет стандартная библиотека?
читал?
DAN>>2. управление памятью — меньше багов CC>Т.е. лики памяти опытного разработчика будут заботливо подчищены GC...
Про типобезопсность слышал?
CC> Гм. не такой уж и опытный этот разработчик раз у него прога ликает.
Это не такой он опытный елси верит, что у него нет ликов.
DAN>>3. большая стандартная библиотека — меньше кода писать. CC>Т.е. надо писать на шарпах/жабе потому что там библиотека стандартная больше? Гм. нет ведь библиотеки на все случаи жизни... Где то больше, где то меньше... К примеру я игру разрабатываю. 3D шутер с навороченной графикой. Чем мне в этом поможет стандартная библиотека?
Дык в любой программе есть куча объвязочного кода. Та же работа с ХМЛ. Тот же ГУИ. Но конечно для игр скорее будет интересна не библиотека, а компонентная модель и динамичность дотнета. Он может заменить и скрипты, и плагины и много чего еще. Прибавив сюда генерацию кода в рантайме и получаем тучу приемуществ.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nickolay Ch, Вы писали:
CS>>Извиняюсь но как минимум код должен разрабатываться с применением инженерной совести. CS>>А специфика задачи...
NC>Ну вот опять совесть полезла. Что такое совестьЮ тогда давайте пофлеймим, только уж лучше в Священных войнах. NC>Писать надо так, как целесообразней, сиречь, так, что быстрее привелет нас к результатую. Целесообразность целиком зависит от задачи.
"как целесообразней" это как раз и есть часть этой самой совести.
Целесообразность включает в себя решения от глобальных проблем оптимального выбора инструмента/технологии
до целесообразности того или иного подхода на уровне конкретной функции.
Собственно весь этот топик и есть один большой разговор про целесообразность.
Идея состоит в том что как правило решение современной вычислительной задачи
(программы) не сильно зависит от того на чем — есть ли там managed framework или там unmanaged stdlib.
И то и то имеет тонны всяко разных классов и методов в конце концов. (Последнее кстати примерно на порядок больше всякого
имеет чем framework).
Постулирую: качество получаемой системы зависит от того знает ли менеджмент о том что какую
бы технологию они волевым порядком ни взяли а разработка все равно займет 9 месяцев
Выбор технологии дело сугубо техническое. При любом раскладе — уровень требования к исполнителям — одинаковый и не зависит
от того на чем писать.
Т.е. все эти трескучие лозунги это "желудок у котенка меньше наперстка". Следовать им нецелесообразно.
(чего-то то меня пробило на глобальные умозаключения, извиняюсь)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
DAN>>>1. классы — легче проектировать CC>>В чем легче? Почему легче? именно опытному разработчику... VD>Вот это
читал?
читал. вот только в чем заключается это самое "легче" — там не написано.
Есть там кста одна хорошая фраза: "этот язык определяет способ их программистского мышления."
так вот, вы мыслите на уровне абстракций а я на уровне того, как именно оно будет выполняться.
Потому как работаю я с платформозависимым кодом. И большинство его должно выполняться быстро и ресурсы освобождать немедленно как только они перестали быть нужны. В любом языке с GC мне надо будет теребить этот самый GC ручками чтобы он не ковырял в носу а сразу убивал мусор.
Кстати о сборщике — глядя на янус я склоняюсь к мнению что не такая уж и умная это штука. База у меня всего то 137 метров а янус при работе умудряется отжирать 87 мб working set и 669 virtual... и при этом откровенно подтормаживать при переходе от ветки к ветке...
DAN>>>2. управление памятью — меньше багов CC>>Т.е. лики памяти опытного разработчика будут заботливо подчищены GC... VD>Про типобезопсность слышал?
слышал. для меня она выглядит как очень строгая проверка на этапе компиляции... И покуда кажется больше мешающей чем полезной.
Кстати никак не получается найти развернутое определение, что же именно включается в этот термин. Не поможете ссылкой?
CC>> Гм. не такой уж и опытный этот разработчик раз у него прога ликает. VD>Это не такой он опытный елси верит, что у него нет ликов.
Верить что лики есть и писать без ликов — все же разные вещи. Разумеется в "любой программе есть ошибки" (с) не помню.
Но у профи ИМХО таких ляпов как лик быть не должно.
VD>Та же работа с ХМЛ.
парсер пишется за короткое время на С++ и имеет нужную функциональность и большую скорость и удобство нежели вызов стандатной библы. VD>Тот же ГУИ.
уууу... посмотрите на ку4... Что из его ГУИ следует делать на библах .нета? VD>Но конечно для игр скорее будет интересна не библиотека, а компонентная модель и динамичность дотнета.
Как геймдевелопер могу сказать — что то пока никаких удобств не видно...
Влад уже ответил, но не будем прятаться за спины титанов , кину и свои 5 копеек...
DAN>>1. классы — легче проектировать CC>В чем легче? Почему легче? именно опытному разработчику...
1. Классы это более высокий уровень абстракции. Чем более высоким уровнем абстракции вы манипулируете, тем больший кусок вы можете удержать и обработать в памяти (в голове). Собсно чем больше проект, тем это более важно.
Опытный разработчик имеет теже самые функциональные ограничения что и неопытный: в голове одновременно не более 7 предметов.
2. Классы это не только ценный мех, но и всякие другие приятные рюшки (хором): инкапсуляция и полиморфизм. Что позволяет писать систему более устойчивую к багам, что в свою очередь немало сокращает время разработки в целом.
DAN>>2. управление памятью — меньше багов CC>Т.е. лики памяти опытного разработчика будут заботливо подчищены GC... Гм. не такой уж и опытный этот разработчик раз у него прога ликает.
Не об этом речь. Баги делают все и опытные и неопытные. Просто у опытных меньше ляповых багов, и они их быстрее находят.
А речь вот о чем: в больших приложениях управление памятью геморрой еще тот — всякие там смартпоинтеры, которые толком не поддерживаются компилером, следовательно опять же больше ошибок которые крайне геморойно дебагировать и фиксить.
С другой стороны смею вас заверить, память отлично течет и системах с GC (особенно этим грешит VB6), но багов из за этого на порядок меньше, и искать и исправлять их тоже значительно проще.
DAN>>3. большая стандартная библиотека — меньше кода писать. CC>Т.е. надо писать на шарпах/жабе потому что там библиотека стандартная больше? Гм. нет ведь библиотеки на все случаи жизни... Где то больше, где то меньше... К примеру я игру разрабатываю. 3D шутер с навороченной графикой. Чем мне в этом поможет стандартная библиотека?
Как минимум автоматическая поддержка wide strings, коллекции, ввод\вывод, работа с временем/датами и пр. пр. пр.
Здравствуйте, savaDAN, Вы писали:
DAN>А речь вот о чем: в больших приложениях управление памятью геморрой еще тот — всякие там смартпоинтеры, которые толком не поддерживаются компилером, следовательно опять же больше ошибок которые крайне геморойно дебагировать и фиксить.
А можно вот об выделенном поподробнее?
И что ты считаешь большим приложением (больше 100 тысяч строк, 200, 500,...)?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, c-smile, Вы писали:
CS>Проблема в том что среди десяти threads появляется одна в которой CS>выполняется этот вот кусок. И все. Всем привет. CS>GC начинает останавливать все потоки. Когда они *все* остановились CS>тогда чистится мусор. Затем вся эта бодяга весело перезапускается. CS>Тут же выпадая в следующий осадок. Потому как тот IP на котором CS>работает приведенный фрагмент сидит на жирной трубе.
A>>Зачем? Для этого у GC есть поколения.
CS>Есть поколения и что? Не надо останавливать потоки? CS>Такого чуда имхо еще нет. В Java есть но в специфических продуктах.
afair, в 1.5 есть конкурентные сборщики не только для "молодого" поколения (который "parallel"), но и для tenured (сборщик "concurent"). Он останавливает потоки не на всё время сборки мусора.
Можно попробовать молодое поколение побольше сделать. Вы какие крутилки у ВМ крутили?
DAN>>А речь вот о чем: в больших приложениях управление памятью геморрой еще тот — всякие там смартпоинтеры, которые толком не поддерживаются компилером, следовательно опять же больше ошибок которые крайне геморойно дебагировать и фиксить.
E>А можно вот об выделенном поподробнее?
что именно подробней? E>И что ты считаешь большим приложением (больше 100 тысяч строк, 200, 500,...)?
500+.
Хотя под "большим" я имел ввиду скорее сложное, а сложность ессно не только от размера зависит.
Здравствуйте, savaDAN, Вы писали:
DAN>>>А речь вот о чем: в больших приложениях управление памятью геморрой еще тот — всякие там смартпоинтеры, которые толком не поддерживаются компилером, следовательно опять же больше ошибок которые крайне геморойно дебагировать и фиксить.
E>>А можно вот об выделенном поподробнее? DAN>что именно подробней?
Какие-такие смартпоинтеры, которые толком не поддерживаются компилятором.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, CreatorCray, Вы писали:
CC>Есть там кста одна хорошая фраза: "этот язык определяет способ их программистского мышления." так вот, вы мыслите на уровне абстракций а я на уровне того, как именно оно будет выполняться.
Видил я код игр... (некоторое время назат я работал в этой сфере) печальное зрелище. А самое противное что это все можно было написать гораздо чище и правильнее при то без потери эффективности.
А все по тому что господа оптимизаторы оптимизируют все подряд и за деревьями леса не видят. CC>Потому как работаю я с платформозависимым кодом. И большинство его должно выполняться быстро и ресурсы освобождать немедленно как только они перестали быть нужны. В любом языке с GC мне надо будет теребить этот самый GC ручками чтобы он не ковырял в носу а сразу убивал мусор.
Сразу это когда? CC>Кстати о сборщике — глядя на янус я склоняюсь к мнению что не такая уж и умная это штука. База у меня всего то 137 метров а янус при работе умудряется отжирать 87 мб working set и 669 virtual... и при этом откровенно подтормаживать при переходе от ветки к ветке...
Сколько можно повторять: В янусе тормозить Jet. Самый что не наесть анменеджет код.
VD>>Но конечно для игр скорее будет интересна не библиотека, а компонентная модель и динамичность дотнета. CC>Как геймдевелопер могу сказать — что то пока никаких удобств не видно...
Просто по тому что ты не знаешь .НЕТ.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
E>Какие-такие смартпоинтеры, которые толком не поддерживаются компилятором.
Ну например о которых Джэф Элджер в С++ библиотека программиста пишут.
ИМХО, сказать что эти сущности полностью поддерживаются компилятором (в том смысле что не позволят программисту допустить ошибку с управлением памятью) — нельзя.
Я уж не говорю о всяких вещах типа "кто создает память?", "кто удаляет память?", что _вообще_ не поддерживается компилером, только соглашениями и архитектурой. опять лишний источник ошибок для программиста и лишняя работа тестерам.
savaDAN wrote:
> E>Какие-такие смартпоинтеры, которые толком не поддерживаются > компилятором. > Ну например о которых Джэф Элджер в С++ библиотека программиста пишут. > ИМХО, сказать что эти сущности полностью поддерживаются компилятором > (в том смысле что не позволят программисту допустить ошибку с > управлением памятью) — нельзя.
А как эти понятия относятся? Или все что поддерживает компилятор
магически становится безопасным?
> Я уж не говорю о всяких вещах типа "кто создает память?", "кто удаляет > память?", что _вообще_ не поддерживается
С вопросами типа "кто создает память" нужно куда-нибудь в SU.CPP.CHAINIK
идти, чтоб хотя бы терминологию выучить.
> компилером, только соглашениями и архитектурой. опять лишний источник > ошибок для программиста и лишняя работа тестерам.
Здравствуйте, savaDAN, Вы писали:
DAN>Я уж не говорю о всяких вещах типа "кто создает память?", "кто удаляет память?", что _вообще_ не поддерживается компилером, только соглашениями и архитектурой. опять лишний источник ошибок для программиста и лишняя работа тестерам.
C>А как эти понятия относятся? Или все что поддерживает компилятор C>магически становится безопасным?
There is no silver bullet, но чем больше помогает компилер тем лучше. Или вы и с этим несогласны?
ИМХО так мы скатимся до спора о том, что не стоит обращать внимания на warning-и компилера раз от него помощи никакой...
C>С вопросами типа "кто создает память" нужно куда-нибудь в SU.CPP.CHAINIK C>идти, чтоб хотя бы терминологию выучить.
Ну-ну, так может быть вы мне расскажите как эта проблема решается в приложении состоящего из солянки разных сторонних библиотек, часть которых придерживается стратегии "дай мне буфер, я верну тебе результат в нем", часть "я тебе сама верну буфер, ты главное его не забудь удалить", а часть вообще имеет свое подобие GC и хочет чтобы с памятью работали исключительно через него? чего-то я такого в SU.CPP.CHAINIK не встречал.
А теперь еще добавьте к этому необходимость таскать подобные буфера через несколько либ внутренних...
С другой стороны смею вас заверить, память отлично течет и системах с GC (особенно этим грешит VB6), но багов из за этого на порядок меньше, и искать и исправлять их тоже значительно проще.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, CreatorCray, Вы писали:
DAN>>>>1. классы — легче проектировать CC>>>В чем легче? Почему легче? именно опытному разработчику... VD>>Вот это
читал? CC>читал. вот только в чем заключается это самое "легче" — там не написано.
Правильно. Там написано почемы ты этого не поймешь пока не познакомился и не перейдешь "на ты" со средством которое хочешь сравнить.
CC>Есть там кста одна хорошая фраза: "этот язык определяет способ их программистского мышления." CC>так вот, вы мыслите на уровне абстракций а я на уровне того, как именно оно будет выполняться.
Изумительное замечание.
CC>Потому как работаю я с платформозависимым кодом. И большинство его должно выполняться быстро и ресурсы освобождать немедленно как только они перестали быть нужны.
А вот тут ты ошибашся. Мы, ну, те что мыслят абстракциями, можем работать с разными задачами. И в зависимости от задачи будетм определять приоритеты.
CC>В любом языке с GC мне надо будет теребить этот самый GC ручками чтобы он не ковырял в носу а сразу убивал мусор.
Это очердное заблуждение. Связано оно как раз с тем, что ты не полностью понимашь как работает ЖЦ в современных рантаймах.
CC>Кстати о сборщике — глядя на янус я склоняюсь к мнению что не такая уж и умная это штука.
Господи, откуда же берется эта толпа оценщиков?
Ты проводил измерения? Ты выянял, что не так в Янусе?
Так что же ты судишь о том в чем не имешь ни малейшего представления?
Короче, или воспользуйся поиском, или давай спорить на любую сумму начиная от $1000, о том что в Янусе ЖЦ не имеет никакого отношения к торомазам. Тогда я найду в себе силы еще раз описать все что я повторял уже 100 раз.
CC> База у меня всего то 137 метров а янус при работе умудряется отжирать 87 мб working set и 669 virtual... и при этом откровенно подтормаживать при переходе от ветки к ветке...
Докагадайся с трех раз что происходит при переходе от ветке. В качестве намека... погляди что при этом изменяется.
VD>>Про типобезопсность слышал? CC>слышал. для меня она выглядит как очень строгая проверка на этапе компиляции... И покуда кажется больше мешающей чем полезной.
Могу только посочувствовать.
CC>Кстати никак не получается найти развернутое определение, что же именно включается в этот термин. Не поможете ссылкой?
У профи, по-моему, должно быть понимание, что в не типобезопасных языках избавиться от утечек памяти и вообще от проблем с ее интерпретацией можно только путем нехилого тестирования. И то полной гарантии не будет. И это при том, что вопрос о том что нужно стараться делать контроль за ресурсами автоматически даже не обсуждается.
VD>>Та же работа с ХМЛ. CC>парсер пишется за короткое время на С++ и имеет нужную функциональность и большую скорость и удобство нежели вызов стандатной библы.
Языком. Попробуй на досуге написать хотя бы интерпретатор XPath. А ведь ХМЛ — это куда более сложная технология.
VD>>Тот же ГУИ. CC>уууу... посмотрите на ку4... Что из его ГУИ следует делать на библах .нета?
Потому такой и ибогий. Две менюшки и командная строка.
А ты вот погляди на ГУИ у ArenaWars. Игра явно не того калибра, что Ку4, а ГУИ на порядки лучше.
VD>>Но конечно для игр скорее будет интересна не библиотека, а компонентная модель и динамичность дотнета. CC>Как геймдевелопер могу сказать — что то пока никаких удобств не видно...
А ты что-то уже пробовал разрабатывать?
Да, и пока ты не начнешь думать о тех самых абстракциях, дотнет тебе вообще интересен не будет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А можно вот об выделенном поподробнее?
Смартпоинтеры — это дополнительные усилия. Забыть его использовать, или использовать неверно тоже можно. А это все забивает голову. И там где программист свободный от ручного управления памятью (РУП) может тратить все свою умственную энергию на решение основной задачи программист с ручным управлением помятью (ПРУП) часть своих мозгов отводит на фоновую борьбу с этой сложностю.
Конечно ПРУП говорит окружающим (да и думает так сам), что он не затрачивает на РУП усилий. Но на самом деле он постоянно забивает РУП-ом свою голову и на основную задачу сил остается меньше.
А таких кусков далеко не один. Есть еще указатели, множество заменителей массивов, заменителей делегатов, эмуляции паттернов и т.п. В итоге на решение основной задаче ПРУП начинает отводить уже совсем незначительный объем своей гловы.
Однако ПРУП думает, что это просто задача у него очень сложная. Причем это за одно начинает развивать в нем комплекс крутого программера. "Глядите какую сложную задачу я смог решить!" А на самом деле задача то не такая уж и сложная.
Скрипты и управляемые среды снимают эти проблемы. Многие ПРУП замечают результат, но объясняют его какиме-то волшебными силами, а не банальным снятием с себя необходимости тратить время на совервшенно не нужную работу.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Во-первых, я спрашивал про смарт-поинтеры, которые прохо поддерживаются компиляторами. Поскольку в реальной жизни я таких смартпоинтеров не видел.
Во-вторых, я наблюдал, как освободившиеся от необходимости контроля памяти программисты успешно забывали освобождать другие ресурсы. В частности, конекшены к БД. Поиском чего полностью занимали свое освободившееся время. Просто за счет того, что вместе с контролем за памятью у них отобрали идиому RAII.
В-третьих, в языках, где нет явных указателей, а есть только ссылки, есть очень тонкие баги, связанные с копированием ссылки вместо клонирования объекта. На поиски которых так же уходит освободившееся после контроля памяти время.
Да и про то, что не нужные ссылки необходимо занулять, так же часто забывают.
Так что, имхо, сменили шило на мыло
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали:
WH>Сразу это когда?
Как только в нем пропадает необходимость.
WH>Сколько можно повторять: В янусе тормозить Jet. Самый что не наесть анменеджет код.
И память тоже он жрет?
Здравствуйте, savaDAN, Вы писали:
DAN>Влад уже ответил, но не будем прятаться за спины титанов , кину и свои 5 копеек...
DAN>>>1. классы — легче проектировать CC>>В чем легче? Почему легче? именно опытному разработчику... DAN>1. Классы это более высокий уровень абстракции. Чем более высоким уровнем абстракции вы манипулируете, тем больший кусок вы можете удержать и обработать в памяти (в голове). Собсно чем больше проект, тем это более важно. DAN>2. Классы это не только ценный мех, но и всякие другие приятные рюшки (хором): инкапсуляция и полиморфизм. Что позволяет писать систему более устойчивую к багам, что в свою очередь немало сокращает время разработки в целом.
Брр.. А разве классы только с .нет появились? Дык это я тогда уже оказывается лет 6 (за деньги) на дотнете пишу
И наш теперешний движок тоже на дотнете написан? там жеж классов — море
DAN>>>3. большая стандартная библиотека — меньше кода писать. CC>>Т.е. надо писать на шарпах/жабе потому что там библиотека стандартная больше? Гм. нет ведь библиотеки на все случаи жизни... Где то больше, где то меньше... К примеру я игру разрабатываю. 3D шутер с навороченной графикой. Чем мне в этом поможет стандартная библиотека? DAN>Как минимум автоматическая поддержка wide strings, коллекции, ввод\вывод, работа с временем/датами и пр. пр. пр.
std::wstring, контейнеры STL, СВОЙ ввод\вывод (кроссплатформенность надо), время-дата в понимании "день-месяц-год-час-минута" большой роли не играет. в отличие от hires таймеров и проч.
