AVK>Это все создавалось в те времена, когда IDE современного уровня просто не существовало, а сделать продукт, хотя бы по некоторым параметрам сравнимым с чем нибудь типа VS6 еще можно. Это я не говорю о том, что в 1С все было настолько убого, что даже VCS прикрутить нельзя было. Но с тех пор в этой области очень очень много поменялось. Сейчас IDE без мощных средств анализа и автоматизированного изменения кода, поддержки VCS, расширяемости, современного редактора и прочих уже привычных вещей просто не нужна никому, кроме некоторых гиков, до сих пор пользующихся текстовыми редакторами для разработки. AVK>Но самое интересное что почти все серьезные IDE (ну, как минимум, Eclipse, IDEA и VS) имеют широчайшие возможности по расширяемости в том числе и в плане поддержки собственных языков и платформ, и даже специальные инструменты для создания таких вещей, см., к примеру, DSL Tools в VS, или то что сейчас под эгидой Nemerle делается, или тот же MPS. Бери да пользуйся (хотя и тут трудозатраты для серьезных средств явно не по плечу одному человеку).
Согласен IDE становятся открытые, но пока примеров полной интеграции я не видел.
Может скоро увидим, но я не буду первопроходцем
Здравствуйте, IT, Вы писали:
I>>Критерий успешности какой ?
IT>Общая сложность решения.
Чем выше сложность тем лучше или как ? Как сравнить сложность RX и TPL для одной и той же задачи ?
I>>Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
IT>Главный результат — опыт применения той или иной технологии, заключающийся главным образом в выявлении её недостатков и ограничений.
Лучше говорить про возможности и свойства. Потому что недостатки и ограничения привязаны к контексту и совсем не очевидно, как именно.
I>>Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче.
IT>Т.е. по-твоему любой опыт бесполезен? В принципе, если свой опыт совсем не анализировать, то я с тобой согласен. Но это не мой случай.
По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений.
I>>То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту.
IT>Я объясню, почему отрицательный опыт более ценный и почему он помогает в дальнейшем отсекать заведом неверные решения. Дело в том, что неправильное решение гораздо проще проанализировать и выявить причины неуспешности. Вдумчивый анализ даёт довольно точный и главное ограниченный список этих самых причин. А вот успешное решение ограниченного списка причин успешности не имеет, этот список бесконечен. Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Не совсем ясно, что ты с этим опытом будешь делать. Вот окажется что heapless решение это неудачный опыт, потому что все твои рассуждения привязаны к контексту. А потом сядешь за реалтайм и то же самое окажется именно тем, что надо.
А если отталкиваться от возможностей и свойств, все получается очень просто.
Здравствуйте, igor-booch, Вы писали:
I>>Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные. I>>Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
IB>Есть репутационные потери. Они тоже имеют денежный эквивалент. Посчитать его точно конечно нельзя, но можно экспертно оценить.
То есть, для экспертной оценки качества решения нужна еще какая то экспертная оценка ?
Теоретически твой подход может работать. ТОлько на практике всю необходимую информацию ты можешь получить через год, два а может и вообще никогда не получишь или получишь, но не ту.
Вот реальный пример, названия конторы и продукты изменены.
Команда берется за проект и за год выкатывает версию. Им сообщает что проект никому не нужен и увольняют, остаётся суппорт.
Вывод по твоей методологии — технические решения отстой.
Через полгода этот же проект взлетает сам собой и приносит бабло. Вывод — технические решения на высоте.
Еще через полгода проект сворачивают окончательно. Вывод — технические решения снова отстой.
Через год CEO говорит, что этот продукт был самым лучшим из того что делала контора.
Вывод — технические решения снова на высоте.
Финансовый директор говорит что проект не окупился, потому что суппорт сожрал весь профит. Вывод — технические решения отстой.
Еще через год этот же код продукта реюзается на 90%, ядро остаётся без изменения характеристик, возможностей и тд и новые продукт взлетает, приносит прибыль и окупает всю разработку обоих продуктов за все годы, при этом продолжает так же глючить как и первый вариант.
И вот у тебя два результата — по одному техническое решение отстой. По второму — ажно круть, хотя 90% код почему то из отстойного продукта
Чего реально видно на этом примере — у конторы корявый маркетинг. Никакой корреляции между прибылью и качеством технических решений просто нет и быть не может.
Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям.
Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы.
То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
Вопрос — как оценить качество технического решения ?
I>skipped I>Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям. I>Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы. I>То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
Требования по качеству это часть постановки задачи. Например
требования по производительности — капитальные затраты
по безопасности — капитальные затраты
по трудозатратам на масштабирование (рост функциональности или количества пользователей (данных)) — эксплуатационные расходы
по трудозатратам на исправление багов — эксплуатационные расходы
и т. д.
Если команда не выполнила требования по качеству за отведенный для задачи срок (превысили лимит затрат) это априори означает что она выбрали неудачный вариант
решения задачи.
Даже если команда выполнит требования по качеству, но за срок превышающий отведенный для задачи срок, то это также будет означать что команда выбрала неудачный вариант
решения задачи.
Если экплуатационные расходы превышают максимально допустимые расходы описанные в постановке задачи, то это тоже означает что команда выбрала неудачный вариант
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, qlat, Вы писали:
Q>>Согласен IDE становятся открытые, но пока примеров полной интеграции я не видел.
AVK>Что ты подразумеваешь под полной интеграцией? Во всех трех перечисленных IDE и основные поддерживаемые языки реализованы в виде расширений.
у меня нет примеров систем класса ERP, без своей среды разработки, где использовалась бы полностью среда типа VS. видел решения — биллинг. системы, произв. системы, WMS и т.д. — все это были самописки, которые продавались как коробки, но они были закрытые, в них разработчик клиента почти ничего писать не мог, как в 1С, Axapta, SAP.
Здравствуйте, qlat, Вы писали:
Q>может ты пример приведешь?
Первая ссылка в гугле — http://mybusinessnet.codeplex.com/. А вообще мне твоя логика не очень понятна — типа миллионы леммингов не могут ошибаться? Большинство современных ERP систем родились не сейчас, а тогда, когда качественных и открытых IDE еще не было, я об этом как раз и писал.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, qlat, Вы писали:
Q>>может ты пример приведешь?
AVK>Первая ссылка в гугле — http://mybusinessnet.codeplex.com/. А вообще мне твоя логика не очень понятна — типа миллионы леммингов не могут ошибаться? Большинство современных ERP систем родились не сейчас, а тогда, когда качественных и открытых IDE еще не было, я об этом как раз и писал.
Логика — использовать накопившийся опыт, для быстрого написания движка и перенос решения 1С 7 на данный движок. И не быть первопроходцем
Здравствуйте, Ikemefula, Вы писали:
I>Чем выше сложность тем лучше или как ?
Или как.
I>Как сравнить сложность RX и TPL для одной и той же задачи ?
Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это.
I>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений.
Я не понимаю что ты подразумеваешь под возможностями и своствами решений.
I>Не совсем ясно, что ты с этим опытом будешь делать.
Этот опыт я буду применять.
I>А если отталкиваться от возможностей и свойств, все получается очень просто.
Если ты мне внятно растолкуешь что ты под этим понимаешь, то может я с тобой и соглашусь.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Очень хорошая аналогия. Путей обхода бесконечное множество, но только один путь является наикратчайшим между пунктами А и Б. Знание этого пути является знанием "как надо". И мне не нужно знать где находятся все мины минного поля. Мне нужно знать только мины, которые встретятся на моем кратчайшем пути. Путь человека между пунктами А и Б, который не знает "как надо", будет длиннее кратчайшего. Соответственно ему придется обнаружить больше мин. Когда человек находится в пункте А и ему нужно попасть в пункт Б, сначала продумывает маршрут — это теория, знания "как надо". Потом на этом маршруте он встречает мины получает знания "как не надо" — это практика. А если человек отправится в путь не проложив маршрута, он изучит больше мин, но эти мину будут залегать на таких не оптимальных путях, которыми люди вооруженные знаниями "как надо" никогда не ходят.
Поэтому нельзя говорить:
IT>Я объясню, почему отрицательный опыт более ценный
Все знания имеют ценность, только эта ценность отличается качественно. Это все-равно что сказать, что автомобилисту важнее знать где находятся ямки и кочки на дорогах (актуально для российских дорог), чем знать сами дороги.
Q>>Пример 1С, Axapta, Sap AVK>Это все создавалось в те времена, когда IDE современного уровня просто не существовало
Это всё имеет свою нишу на рынке до сих пор и будет иметь. ERP логика (бухгалтерия, склад) стандартизована. Эти среды направлены на то чтобы максимально быстро и легко (с наименьшими затратами ресурсов) расширять и конфигурировать стандартную логику ERP. Именно расширять и конфигурировать, а не создавать новую. Сделать в этих средах что-то что выбивается из стандартной логики действительно труднее, чем в универсальных средах, типа Visual Studio. Программист ERP в первую очередь ценен знанием предметной области. Технически программирование в среде разработки ERP примитивно. Языки программирования ERP это что-то вроде DSL.
Итого ERP позволяют минимизировать расходы компании, если ей нужна только стандартная логика ERP, возможно сконфигурированная под её нужды. А то что позволяет минимизировать расходы, всегда найдет место на рынке.
Использование ERP это что-то вроде аутсорсинга
бухгалтерии, управления складом. Customer relationship menegment требует большей специализации под клиента, поэтому CRM системы развиты меньше. Хотя тоже есть у Microsoft.
Здравствуйте, igor-booch, Вы писали:
IB>ERP логика (бухгалтерия, склад) стандартизована.
Если бы. Во-первых не путай бухгалтерию и ERP. В бухгалтерии таки да, есть стандарты (которые периодически меняются, особенно в РФ), но и в рамках этих стандартов возможны определенные изменения в логике. Но ERP это сильно больше чем бухгалтерия. А склад нифига не стандартизован (стандартизованы, и то в определенных пределах, некоторые документы типа накладной), тебя обманули.
IB> Эти среды направлены на то чтобы максимально быстро и легко (с наименьшими затратами ресурсов) расширять и конфигурировать стандартную логику ERP. Именно расширять и конфигурировать, а не создавать новую.
Ты 1С то видел изнутри? Опять же, ты что думаешь, стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, igor-booch, Вы писали:
IB>Очень хорошая аналогия. Путей обхода бесконечное множество, но только один путь является наикратчайшим между пунктами А и Б.
Не надо из аналогий делать выводы, это, как минимум, логически некорректно. Критериев оптимальности решения несколько, и баланс приоритетов этих критериев зависит от конкретной ситуации и конкретного проекта. Где то важнее время, где то возможность реализации с большим количеством неопытных разработчиков, где то минимизация потраченного бабла, где то достижение высокого уровня качества и т.д. Но и это еще проблема. Другая проблема в том что не все критерии можно посчитать в нужный момент времени. Как, к примеру, оценить стоимость развития системы, когда у нас еще даже первый релиз не состоялся?
В отличие от этого, факапы видны вполне очевидным образом и почти вне зависимости от критериев оптимальности и баланса между ними.
Таким образом, сказать что вот такое решение всегда хорошо в любом проекте почти никогда не выходит, кроме совсем уж примитивных вещей, зато сказать что вот такой факап это жопа опять же в почти любом проекте обычно удается.
IT>>Я объясню, почему отрицательный опыт более ценный IB>Все знания имеют ценность, только эта ценность отличается качественно. Это все-равно что сказать, что автомобилисту важнее знать где находятся ямки и кочки на дорогах (актуально для российских дорог), чем знать сами дороги.
Предполагается обычно, что человек, который берется за архитектуру системы с ощутимой стоимостью разработки уже знает где дороги.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK>Во-первых не путай бухгалтерию и ERP. AVK>Но ERP это сильно больше чем бухгалтерия.
Бухгалтерия это часть ERP, причем центральная. Продуктом работы любого модуля (например закупки, продажи, склад) могут быть бухгалтерские проводки.
AVK>А склад нифига не стандартизован (стандартизованы, и то в определенных пределах, некоторые документы типа накладной), тебя обманули.
Модуль склад есть точно в Axapta, есть в 1С. По моим оценкам 50 — 60% среднего и малого бизнеса достаточно стандартной функциональности модуля Склад. 20 — 30% требуется расширение стандартной функциональности средствами разработки ERP. Только русские заказчики всегда стремятся прогнуть систему под себя, невзирая на риск её поломки, а иностранные заказчики учитывают риск поломки от чрезмерного вмешательства программистов в стандартную логику и предпочитают подстроить свои бизнес процессы под систему ERP.
AVK>Ты 1С то видел изнутри? Опять же, ты что думаешь,
Axapta видел изнутри, работал 1,5 года на ней программистом.
AVK>стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет?
Пишет Microsoft, на консалтинговые компании, которые занимаются внедрением Axapta она "падает с неба", если можно так выразиться. Консалтинговая фирма стандартную логику не пишет, он её больше конфигурирует и дополняет под нужды конечного заказчика.
Здравствуйте, igor-booch, Вы писали:
IB>Бухгалтерия это часть ERP
Да.
IB>причем центральная
Нет. Центральная часть, о чем недвусмысленно говорит название, это планирование ресурсов. А бухгалтерия это не планирование, это пост-фактум отчетность.
IB>Продуктом работы любого модуля (например закупки, продажи, склад) могут быть бухгалтерские проводки.
Уверен? Даже если взять типовые конфигурации 1С, то упомянутый тобой склад никаких бухгалтерских проводок не формирует, там свои собственные регистры. А серьезные ERP системы про сравнению с типовыми конфигурациями 1С, это примерно как авиалайнер рядом с велосипедом.
IB>Модуль склад есть точно в Axapta
И чего? Он много где есть.
IB>По моим оценкам 50 — 60% среднего и малого бизнеса достаточно стандартной функциональности модуля Склад.
Ах по твоим оценкам. Ну тогда сдаюсь.
IB>Только русские заказчики всегда стремятся прогнуть систему под себя
Это делают все, кто хочет быть конкурентоспособным. А вот кто вместо прогибания софта под бизнес, или просто подбора достаточно гибкого софта, наоборот бизнес под софт прогибает, те обычно печально заканчивают.
AVK>>стандартная логика какого нибудь отраслевого решения, она с неба падает или все таки кто то ее пишет? IB>Пишет Microsoft
И? Он при этом аксаптовым инструментарием не пользуется, пишет все в блокноте?
IB>на консалтинговые компании, которые занимаются внедрением Axapta она "падает с неба", если можно так выразиться
Кого в этом топике волнуют те, кто занимается внедрением? Средства разработки не для них создаются, а для тех кто делает прикладные решения. Если ты когда то там у какого то внедренца подпиливал стандартные конфигурации, это вовсе не означает что это единственная или даже основная аудитория средств разработки ERP платформ. В Парусе, к примеру, вообще таких людей, как у 1С, массовых допильщиков стандартных конфигураций, вообще нет. А конкретно в упомянутом тут Парус 10 на данный момент под релизную платформу собрать решение можно только на серверах Паруса. Бизнес у всех поставщиков ERP решений разный, не стоит под одну гребенку всех кто в этом секторе работает равнять.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, igor-booch, Вы писали:
I>>Для того, что бы внятно говорить про успех, надо забыть это слово применительно к техническим решениям. I>>Вместо этого лучше использовать вещи навроде востребованость и качество, а это уже две большие разницы. I>>То есть, нужно отделить маркетинг от технических решений. Маркетинг оценивать по прибыли. Технические решения — по качеству.
IB>Я говорил не о прибыли, а о затратах, причем <b>затратах </b>
Это не важно. Самое главное — у тебя оценка комплексная.
То есть, по популярности текста ты пытаешься оценить уровень владения языком автора текста
IB>Требования по качеству это часть постановки задачи. Например IB>требования по производительности — капитальные затраты IB>по безопасности — капитальные затраты IB>по трудозатратам на масштабирование (рост функциональности или количества пользователей (данных)) — эксплуатационные расходы IB>по трудозатратам на исправление багов — эксплуатационные расходы IB>и т. д.
IB>Если команда не выполнила требования по качеству за отведенный для задачи срок (превысили лимит затрат) это априори означает что она выбрали неудачный вариант
Ну как же — выполнила. Все в ажуре — вложились в сроки, получили бабло — код хороший и решения на высоте.
IB>Если экплуатационные расходы превышают максимально допустимые расходы описанные в постановке задачи, то это тоже означает что команда выбрала неудачный вариант
Здравствуйте, IT, Вы писали:
I>>Как сравнить сложность RX и TPL для одной и той же задачи ?
IT>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это.
А как же тогда общую сложность решения оценивать ?
I>>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений. IT>Я не понимаю что ты подразумеваешь под возможностями и своствами решений.
На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
I>>А если отталкиваться от возможностей и свойств, все получается очень просто. IT>Если ты мне внятно растолкуешь что ты под этим понимаешь, то может я с тобой и соглашусь.
Еще раз на примере GC. Если подходить по твоему, то для конкретного приложения можно получить вывод, что GC это удачное решение, ибо не надо следить за памятью и тд, а надо всего то заботиться о занулении ссылок.
В другом приложении внезапно окажется, что этого недостаточно, надо еще избавляться от старых объектов и пользовать иммутабельные объекты. В третьем — окажется, что наоборот, надо переходить на старые объекты. Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
Собтсвенно отсутствие реюзабельности демонстрирует другой пример — в конкретном приложении, скажем высоконагруженый сервер или какой реалтайм нужно использовать heapless-решения ну например для кеширования и очень аккуратно пользовать GC в остальных случаях.
При этом проблемы с реалтаймом вытекают из свойств .Net GC и требований к реалтайму. Если время отклика час-два, то это одно, а если 100мс то GC мягко говоря, может работать гораздо дольше и тут не надо пилить какой то проект, что бы анализировать удачность или неудачность применения GC.
Вобщем обсуждение удачных и неудачных решений имеет смысл только если ты сидишь носом в одной и той же области годами, контекст не меняется и людям во круг тебя всё и так понятно, даже объяснять не нужно.
Здравствуйте, Ikemefula, Вы писали:
IT>>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это. I>А как же тогда общую сложность решения оценивать ?
На больше / меньше.
I>>>По моему надо акцентироваться не на ярлыках, а на возможностях и свойствах решений. IT>>Я не понимаю что ты подразумеваешь под возможностями и своствами решений. I>На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
И какое это всё имеет отношение к правильности принятых решений. Вот например следующее имеет самое непосредственное отношение. На примере моего БЛТ можно сказать, что SqlBuilder в нём спроектирован неудачно, т.к. в одном месте намешалось AST для SQL, оптимизации этого AST и средства его конструирования. В результате получилась довольно негибкая архитектура, что в конце концов не лучшим образом повлияла на некоторые решения в дальнейшем. Т.е. имеет место быть самый настоящий отрицательный опыт с чётким пониманием того почему так делать не надо. А то, о чём ты говоришь — это есть функциональные и нефункцианальные требования, которые к обсуждаемой теме вообще не имеют никакого отношения.
I>Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Я не знаю метрик, которые можно было бы использовать для формальной оценки сложности. Если ты про это. I>>А как же тогда общую сложность решения оценивать ?
IT>На больше / меньше.
Значит у тебя есть какие то метрики, только ты стесняешься их показать
I>>На примере твоего БЛТ — возможности это просто фичи, большие и маленькие. А быстродействие, расход памяти и прочие вещи — это свойства.
IT>И какое это всё имеет отношение к правильности принятых решений. Вот например следующее имеет самое непосредственное отношение. На примере моего БЛТ можно сказать, что SqlBuilder в нём спроектирован неудачно, т.к. в одном месте намешалось AST для SQL, оптимизации этого AST и средства его конструирования. В результате получилась довольно негибкая архитектура, что в конце концов не лучшим образом повлияла на некоторые решения в дальнейшем. Т.е. имеет место быть самый настоящий отрицательный опыт с чётким пониманием того почему так делать не надо. А то, о чём ты говоришь — это есть функциональные и нефункцианальные требования, которые к обсуждаемой теме вообще не имеют никакого отношения.
То есть, "намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" ты почему то не можешь рассматриват как свойство BLT. Вопрос — почему ?
I>>Вроде как по мелочи, но оказывается, что удачный опыт какой то не совсем удачный, без конкретного контекста его вообще невозможно реюзать.
IT>Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике.
Насколько я понял, "неудачный опыт" судя по примеру БЛТ это просто некоторые ограничения == свойства в конкретном контексте. И вот как то странно искать решение руководствуясь одними лишь ограничениями
Здравствуйте, Ikemefula, Вы писали:
IT>>На больше / меньше. I>Значит у тебя есть какие то метрики, только ты стесняешься их показать
Я такой стеснительный.
I>То есть, "намешалось AST для SQL, оптимизации этого AST и средства его конструирования" и "негибкая архитектура" ты почему то не можешь рассматриват как свойство BLT. Вопрос — почему ?
Это не свойство, это — косяк. Ещё раз объясняю, свойства о которых ты говоришь — это функциональные и нефункциональные требования к задаче. Сложность, успешность и неуспешность решения к этому не имеют отношения, т.к. одно и тоже свойство может быть реализовано как хорошо, так и плохо, может требовать кучу ресурсов, а может расходовать их очень оптимально.
IT>>Именно это я и пытаюсь донести с самого моего первого сообщения в этом топике. I>Насколько я понял, "неудачный опыт" судя по примеру БЛТ это просто некоторые ограничения == свойства в конкретном контексте. И вот как то странно искать решение руководствуясь одними лишь ограничениями
По-моему, ты зациклился на своих свойсвах и пытаешь подменить одно понятие другим, чтобы объяснить для себя непонятное в более привычных терминах. Из этой подмены ничего не получается, но в результате ты сваливаешь свои проблемы на оригинальные утверждения.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
