Здравствуйте, FR, Вы писали:
FR>Тем, что разработка — empiric process, а не defined process. В случае empiric process точность соблюдения технологии и процесса не гарантирует результата в принципе, потому, что какие бы "типовые" работы не были. Потому, что все они сопряжены с решением проблем, способ решения которых повлияет на структуру результата, и результат определяется не соблюдением технологии, а человеческим вкладом и личными качествами исполнителей.
А с чего ты решил, что проектирование нового железа относится к defined process-ам?
Здравствуйте, Andrei F., Вы писали:
AF>А с чего ты решил, что проектирование нового железа относится к defined process-ам?
Оно не относится полностью к defined процессам, не зря тот же интел тратит миллиарды на R&D. Но у них легко разделяются собственно исследования (R) от разработки (D), а в программировании всегда получается жуткий клубок из этих R и D.
Тут даже для написания мелкой утилитки бывает приходится заниматся кучей исследований.
Здравствуйте, Andrei F., Вы писали:
E>>При общении людей должна быть некоторая степень доверия к словам друг друга.
AF>Только не тогда, когда это касается флейма на форуме.
E>>На вопрос о прогрессе в Windows я ответил. Ваша очередь.
AF>Задавай по порядку.
Приведите доказательства того, что ваша претензия "софт работает медленнее, потребляет больше оперативки, багов в нем всё больше, и даже время разработки растет" оправдана.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
E>>Да натыкался когда-то на статистику средств, затрачиваемых на разработку ПО в США. Там выходило, что расходы на внутреннее и заказное ПО было значительно выше, чем на разработку коробочного ПО. За деталями в гугл.
AF>Ссылку давай.
Наиболее весомым на рынке ПО является сегмент приложений (Applications), доля которого составляет около 48%. На втором месте сегмент системного и инфраструктурного ПО с долей чуть более 30%, оставшиеся 22% рынка принадлежат сегменту инструментального ПО. Получается, что сегмент приложений примерно в 2 раза больше сегмента инструментального ПО и в 1,6 раза больше сегмента системного и инфраструктурного ПО. Однако в странах со зрелым ИТ-рынком доля инструментального ПО выше, а доля приложений ниже — например в Южной Корее они оцениваются в 35 и 39% соответственно.
Если сюда добавить еще и тот факт что изрядный объем ПО (в том числе и коробочного) производится с использованием аутсорсинга (т.е. то, что для продавца коробка -- для производителя заказ)...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Наиболее весомым на рынке ПО является сегмент приложений (Applications), доля которого составляет около 48%. На втором месте сегмент системного и инфраструктурного ПО с долей чуть более 30%, оставшиеся 22% рынка принадлежат сегменту инструментального ПО. Получается, что сегмент приложений примерно в 2 раза больше сегмента инструментального ПО и в 1,6 раза больше сегмента системного и инфраструктурного ПО. Однако в странах со зрелым ИТ-рынком доля инструментального ПО выше, а доля приложений ниже — например в Южной Корее они оцениваются в 35 и 39% соответственно.
Интерсно каков процент у железнячников инструментальных железок
Здравствуйте, Andrei F., Вы писали:
AVK>>Таким образом получается, что это железячники доят с нас бабло, топая проторенной дорожкой которое десятилетие
AF>Не забывай о проектировании схем, разработке новых материалов и оборудования, и т.д.
А в проектировании все очень похоже на софтострой. Те же годами живущие архитектуры, те же проблемы совместимости со старыми железками, те же реализуемые покрытые мхом идеи середины прошлого века.
AVK>>а вот софт уже уперся в значительно более серьезные ограничения
AF>Это какие "более серьезные ограничения"?
Обыкновенные — порог сложности, отсутствие практически применимых алгоритмов, отсутствие новых идей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Делом в том, что детям свойственны страхи. Подавляющее большинство детей боится темноты, чуть менее подавляющее — высоты и т.п. С возрастом это у них проходит по причинам, которые я упомянул в исходном сообщении. И вот если вдруг не проходит, вот тогда-то они и становятся фобиями.
В детстве я как раз любил узнавать все новое. И детям вообще свойственно любопытство, любознательность. Если в детстве я запросто мог взять лягушка за задние лапы, давить тараканов руками и т. п., то теперь мне это будет не очень приятно.
Основная беда новых технологий состоит в том, что зачастую они появляются тогда, когда у каждого толкового специалиста уже есть свои собственные методы решения тех или иных проблем, которые решает эта новая технология. Причем эти методы опробованы на реальных проектах, на них набиты шишки, есть готовые шаблоны реализации. А вот на новой технологии, какова бы она ни была удачной, эти шишки еще предстоит набивать методом проб и ошибок. Плюс на первых порах есть некоторый недостаток информации.
Соответственно возникает ситуация: если ты все делаешь по старым образцам, то риски минимальны, ты знаешь что и как надо делать. Грубо говоря, если у тебя есть пила, доски и гвозди, то ты знаешь, что можешь за три часа сколотить скворечник. Если скворечник собирать из конструктора LEGO, то первый скворечник будет сделан (1) медленнее (2) будет менее удачным, потому что в некоторых частях вместо того, чтобы воспользоваться нужной деталью, ты что-то доделаешь при помощи знакомых молотка и гвоздей. И даже после освоения LEGO часто разница в скорости и качестве между старым методом и новым будет невелика.
Новые технологии в значительной степени облегчают жизнь тем, кто на них приходит без груза старых. Со временем специалисты в старых технологиях мигрируют на более современные.
Здравствуйте, AndrewVK, Вы писали:
AVK>А в проектировании все очень похоже на софтострой. Те же годами живущие архитектуры, те же проблемы совместимости со старыми железками, те же реализуемые покрытые мхом идеи середины прошлого века.
Да, проблемы те же. Но результат, как ни странно, куда приличнее.
AVK>отсутствие практически применимых алгоритмов, отсутствие новых идей.
Не похоже на правду.
А порог сложности — это всё зависит только от инструментов.
Здравствуйте, eao197, Вы писали:
E>Приведите доказательства того, что ваша претензия "софт работает медленнее, потребляет больше оперативки, багов в нем всё больше, и даже время разработки растет" оправдана.
Вот тут я положен на обе лопатки. Очень сложно доказать, что белое — это белое
E>
E>Наиболее весомым на рынке ПО является сегмент приложений (Applications), доля которого составляет около 48%. На втором месте сегмент системного и инфраструктурного ПО с долей чуть более 30%, оставшиеся 22% рынка принадлежат сегменту инструментального ПО. Получается, что сегмент приложений примерно в 2 раза больше сегмента инструментального ПО и в 1,6 раза больше сегмента системного и инфраструктурного ПО. Однако в странах со зрелым ИТ-рынком доля инструментального ПО выше, а доля приложений ниже — например в Южной Корее они оцениваются в 35 и 39% соответственно.
Эти данные — о назначении софта, а не его тиражности. То есть абсолютно ортогональны тому, что ты пытался доказать.
Здравствуйте, FR, Вы писали:
FR>Оно не относится полностью к defined процессам, не зря тот же интел тратит миллиарды на R&D.
R&D — это вообще всегда empiric процесс, а не defined. И от области (авиастроение, автомобилестроение, космонавтика, микроэлектоника, программирование) это никак не зависит. Defined процесс — это, например, серийное производство. Tиражирование ПО, в отличие от тиражирования реактивных самолетов, — тривиально. Но тема отличия R&D в первом и втором случае не раскрыта.
FR>Но у них легко разделяются собственно исследования (R) от разработки (D), а в программировании всегда получается жуткий клубок из этих R и D.
Разделение R и D вообще никакого отношения к обсуждаемой теме не имеют.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'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
Здравствуйте, Klapaucius, Вы писали:
K>R&D — это вообще всегда empiric процесс, а не defined. И от области (авиастроение, автомобилестроение, космонавтика, микроэлектоника, программирование) это никак не зависит. Defined процесс — это, например, серийное производство. Tиражирование ПО, в отличие от тиражирования реактивных самолетов, — тривиально. Но тема отличия R&D в первом и втором случае не раскрыта.
Есть еще такая вещь как применимость исследований к разработке. У них если некий вопрос исследован то примение к разработке уже вполне defined и сама разработка возможна по формальным спецификациям, у нас эти процессы почти не разделяемы, и исследования могут и всплывают на любом этапе процесса разработки.
FR>>Но у них легко разделяются собственно исследования (R) от разработки (D), а в программировании всегда получается жуткий клубок из этих R и D.
K>Разделение R и D вообще никакого отношения к обсуждаемой теме не имеют.
Здравствуйте, Andrei F., Вы писали:
AF>Да, проблемы те же. Но результат, как ни странно, куда приличнее.
Вот это меня и удивляет. Как вообще можно сравнивать, кроме как притягивать за уши аналогии?
AVK>>отсутствие практически применимых алгоритмов, отсутствие новых идей.
AF>Не похоже на правду.
А что, есть вещи, которые можно сделать с очевидным бенефитом, но которые никто не делает.
AF>А порог сложности — это всё зависит только от инструментов.
Не только.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
К>Т.е. анализ, проектирование и разработка это по сути основное содержание создания ПО, основным звеном в этом является человек, а он очень плохо поддаётся автоматизации (в отличие от технологических процессов, происходящих на фабриках).
Автоматизируется какая-либо деятельность. "Автоматизация человека", по этой причине, словосочетание бессмысленное. Если же говорить о деятельности человека, то практически все, что сейчас делается автоматически — когда-то делалось человеком, и это как бы говорит нам, что деятельность человека вполне автоматизируема. Это, в некоторой степени касается и умственной деятельности. Например, решение кубических уравнений до Кардано было процессом "эмпирическим" и даже "творческим". А теперь это defined процесс.
Естественно, успехи в области автоматизации мышления достаточно скромные, но мы можем рассмотреть повышение эффективности умственной деятельности человека. В этой области как раз есть впечатляющие успехи в физике. Хороший формализм и математический инструментарий в физике всегда помогал бороться с тем, что Брукс в своей, поминаемой обычно не к месту, статье про серебряную пулю называет сущностной сложностью.
Хорошие иллюстрации — формулировка Гамильтона для механики и Хэвисайда-Герца для электродинамики (и вообще вклад работ Гамильтона, Гиббса и Хэвисайда в развитие физики, векторный анализ, например).
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'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
Здравствуйте, FR, Вы писали:
FR>Есть еще такая вещь как применимость исследований к разработке. У них если некий вопрос исследован то примение к разработке уже вполне defined и сама разработка возможна по формальным спецификациям, у нас эти процессы почти не разделяемы, и исследования могут и всплывают на любом этапе процесса разработки.
1) Есть разница между "разработка по формальным спецификациям невозможна" и "разработка по формальным спецификациям не ведется".
2) Empiric + defined = empiric. Все равно R&D и там и там empiric.
K>>Разделение R и D вообще никакого отношения к обсуждаемой теме не имеют. FR>Имеют, в этом как раз самое большое отличие.
Ну, тогда не имеет отношение противопоставление empiric и defined.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'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
Здравствуйте, Klapaucius, Вы писали:
K>Автоматизируется какая-либо деятельность. "Автоматизация человека", по этой причине, словосочетание бессмысленное. Если же говорить о деятельности человека, то практически все, что сейчас делается автоматически — когда-то делалось человеком, и это как бы говорит нам, что деятельность человека вполне автоматизируема. Это, в некоторой степени касается и умственной деятельности. Например, решение кубических уравнений до Кардано было процессом "эмпирическим" и даже "творческим". А теперь это defined процесс.
Вон ТРИЗ вообще формализует такую творческую деятельность как техническое изобретательство, однако для прграммирования ТРИЗ ничего эффективного предложить не смог.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, FR, Вы писали:
FR>>Есть еще такая вещь как применимость исследований к разработке. У них если некий вопрос исследован то примение к разработке уже вполне defined и сама разработка возможна по формальным спецификациям, у нас эти процессы почти не разделяемы, и исследования могут и всплывают на любом этапе процесса разработки.
K>1) Есть разница между "разработка по формальным спецификациям невозможна" и "разработка по формальным спецификациям не ведется".
Угу, в совтостроении тоже возможно, и будет на порядок дороже чем сейчас. Рецепт простой пишем первую версию делаем на ее базе формальные спецификации и с нуля пишем вторую версию
K>2) Empiric + defined = empiric. Все равно R&D и там и там empiric.
Угу вопрос в соотношении и цене.
K>>>Разделение R и D вообще никакого отношения к обсуждаемой теме не имеют. FR>>Имеют, в этом как раз самое большое отличие.
K>Ну, тогда не имеет отношение противопоставление empiric и defined.
