Здравствуйте, 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++.
Если нам не помогут, то мы тоже никого не пощадим.
