[Goroshko 0]

Решается задача резать из дерева статуэтки, по одной в день...

...

С каких это пор ручное распределние ресурсов (в ассемблере, например) более затратный процесс чем любая операционная среда? Знаете сколько движений нужно сделать для организации очереди сообщений, самой примитивной?

...

Зато когда с задачей не справляется готовая закрытая система всегда есть возможность развести руками и свалить всю вину за _свои_ ошибки на разработчиков ОС.. ;) Собственно говоря, любая программа на 90% это обработчик "нештатных" ситуаций. Обработаете ли вы их сами или свалите на ОС с непредсказуемым результатом -- решайте сами.

По поводу всего выше сказанного хотелось бы заметить, то же в виде аналогии:

Если вам надо забить один гвоздь, вы в принципе можете сделать это и камнем, если ничего нет под рукой.

Если вам надо забить 10 гвоздей, без молотка будет очень трудно.

Если вам надо забить 100 гвоздей - понадобится и соответсвующее рабочее место.

Если надо забивать 1000 гвоздей в час - понадобится полноценное, удобное, рабочее место и качесвенный инструмент.

 

Все это непосресдвенно касается и написания программ в самом общем смысле, никакой специфики тут нет. Почему ОСРВ и softPLC так рьяно завоевывают западный рынок и так тяжело проходят на нашем? потому что у них выделяются совсем другое количество времени на разработку. Не могут они себе позволитиь тратить столько времени, сколько тратят у нас. Поэтому эффекктивность среды разарботки у них считается одним из важнейших параметров системы.

Когда вы используете НАСТОЯЩУЮ ОСРВ (т.е. прошедшую сертификации, с нормальной историей и success story, то вероятность, что ошибка будет связана с самой ОСРВ - примерно 1% и почти наверняка она уже документирована. Когда вы пишете свой код - вы каждый раз создаете новые ошибки :-)

 

Еще можно смотреть на этот вопрос по-другому. Любой код содержит ошибки и чем больше кода, тем выше вероятность ошибок. ПОлучается очень простая зависимость: чем больше "абстракций" и "уровней" не относящихся к решаемой задаче вы используете, тем больше рискуете сделать ошибок. Конечно, если в проекте 15 пар глаз и вагон времени на отладку, имеете право рисовать облака и кирпичи, но чаще всего ограничены не ресурсы вычислительные, а ресурсы людские.

Насчет объема кода - полностью согласен, но вот насчет уровней абстракции..... сильно сомневаюсь, в противном случае ничего кроме структурного программирования не было бы нужно... чем дальше ваш код от предметной области - тем он менее понятен, его труднее модифицировать, в нем дольше искать ошибки и в итоге он менее надежен.

 

Надеюсь, понятно излагаю? Предложение простое: примените процессор на 10 долл дороже, решите предметную задачус НУЛЯ и обойдетесь двумя программистами вместо 15 + покупка чужого кода, который решает разные задачи в общем виде.

Не верю (с) Станиславский.

Как два программиста могут с НУЛЯ решить задачу быстрее чем 15, работающих с готовым инструментарием?

Приведу пример из практики, когда пришлось написать дизассемблер для Intel 196NP и декомпилировать готовую библиотеку плавающей точки, чтобы исправить ошибки в вычислении функции квадратного корня и обработчике перполнений. Компилятор был куплен официально, но обращение в BSO Tasking так и осталось без внятного ответа, а сроки проекта поджимали... "вот тебе бабушка и Юрьев день!" :)

Согласен - бывают и такие проблемы, и это обратная сторона медали ибо как известно - "Серебряной пули нет" :-) Но и утверждать, что на ассемблере - лучше, сейчас по меньшей мере - ошибочно.

[Olej 0]

Хорошо сказал Goroshko Egor - настолько хорошо, что даже цитировать отдельные места не хочется... (жаль, что это не я сказал! ;)).

 

Добавить можно бы только то, что при самом поверхностном рассмотрении, желание "всё написать с нуля" - оно проще, за него проще отвечать, но происходит оно ... от страха (именно и только от страха) использования чужих механизмов. Если вас не устраивает (ошибается) в конечном итоге некоторая возможность из операционного окружения, sqrt(), например - то добавьте свою реализацию sqrt() к той же операционной среде (библиотекам etc.), даже не удаляя никаким образоим ту исходную реализацию, которая вас не устроила. Размер? а кого интересует на сегодня размер? вы хорошо представляете тот объём ненужного кода, который прикомпоновывается к вашей системе при использовании любых tools?

 

Насчет объема кода - полностью согласен, но вот насчет уровней абстракции..... сильно сомневаюсь, в противном случае ничего кроме структурного программирования не было бы нужно... чем дальше ваш код от предметной области - тем он менее понятен, его труднее модифицировать, в нем дольше искать ошибки и в итоге он менее надежен.

 

Да и в отношении объёма кода ... "слухи сильно преувеличены"© - простейшие функции вы да, можете реализовать "с нуля" в 10-100 строк кода, но ... использование сложнейших моделей поведения, типа "менеджер ресурсов", в операционной среде реализуются в 100-200 строк (только интерфейс), а нечто подобное по функциональности потребует "с руки" - многих тысяч строк кода (с пропорциональным числом привнесенных ошибок!).

 

Приведу пример из практики, когда пришлось написать дизассемблер для Intel 196NP и декомпилировать готовую библиотеку плавающей точки, чтобы исправить ошибки в вычислении функции квадратного корня и обработчике перполнений. Компилятор был куплен официально, но обращение в BSO Tasking так и осталось без внятного ответа, а сроки проекта поджимали... "вот тебе бабушка и Юрьев день!" :)

 

Я тоже до определённого времени грешил тем, что дизасемблировать нечто проще... ровно до тех пор, когда начинаешь понимать, что преодолев свой страх, всё делается на порядки производительнее.

 

Но, слава богу, остальные библиотеки с исходниками.

 

И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...

Поэтому панацея - не "открытость кода", а: а). соответствие его выверенным стандартам поведения a'la POSIX + б). массовостью (тысячи пользователей) и долгосрочностью (годы и десятки лет) его испытания и тестирования. Это есть и необходимое и достаточное условия!

[zltigo 1]

но происходит оно ... от страха (именно и только от страха) использования чужих механизмов.

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после

некоторого освоения и изобретения первого "лома".

[v_shamaev 0]

Хорошо сказал Goroshko Egor - настолько хорошо, что даже цитировать отдельные места не хочется... (жаль, что это не я сказал! ;)).

 

Но, слава богу, остальные библиотеки с исходниками.

 

И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...

Поэтому панацея - не "открытость кода", а: а). соответствие его выверенным стандартам поведения a'la POSIX + б). массовостью (тысячи пользователей) и долгосрочностью (годы и десятки лет) его испытания и тестирования. Это есть и необходимое и достаточное условия!

 

Панацея - не панацея, но реально сильно облегчает жизнь при отладке - собранная из исходников с отладочной информацией система не останавливает во время отладки на системном вызове, а позволяет просмотреть - что там происходит - и соответственно понять свои ошибки в понимании механизмов. Это реально повышает производительность - убедился на собственной шкуре. К тому же диагностика далеко не всегда бывает достаточно внятной, что бы разобратся - почему все вроде бы правильно написанное не работает.

[Andrew2000 0]

И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает,

Не только "не читает", а еще и исправлять приходиться. А что делать, если не работает.

 

Поэтому панацея - не "открытость кода", а: а). соответствие его выверенным стандартам поведения a'la POSIX + б). массовостью (тысячи пользователей) и долгосрочностью (годы и десятки лет) его испытания и тестирования. Это есть и необходимое и достаточное условия!

Целиком ЗА! Но где это все взять?

Где достать "годы и десятки лет) его испытания" для нового микроконтроллера?

Вот я становлюсь этим "его испытания и тестирования" - а для этого мне исходники нужны.

А у специализированных изделий "тысячи пользователей" не бывает.

 

О разных областях говорим.

[TMX 0]

Я тоже до определённого времени грешил тем, что дизасемблировать нечто проще... ровно до тех пор, когда начинаешь понимать, что преодолев свой страх, всё делается на порядки производительнее.

Фактически, речь пошла о надежности, которой кроме пресловутого доктора не занимается :).

Если переходить на эмоции - то Вы перекладываете ответственность на чужие плечи (разработчиков ОС или тысячи пользователей) и этим снимаете свои страхи :).

 

Мой опыт показывает, что все зависит от задачи: приходилось и дизасемблировать и находить баги в компиляторе и в процессоре и в средствах отладки. Я думаю, каждому знакомо элементарное планирование надежности: для игрушек, для бытовой техники или для систем управления промышленным оборудованием.

 

И ошибки могут исправляться по-разному: досконально изучаться и фиксироваться, просто обходиться заплаткой без разбирательства: все зависит от ситуации и цены вопроса. И эти способы не зависят от уровня абстракции.

 

Не хотелось бы, чтобы реальная оценка вопроса подменялась позицией "Я - смелый".

 

А в остальном, Вы правы, конечно.

Хочу еще добавить, что в процессе разработки разных уровней ПО, создаются программные отладочные средства для проверки корректности. Их использование значительно облегчает локализацию ошибок в дальнейшем.

[Goroshko 0]

Панацея - не панацея, но реально сильно облегчает жизнь при отладке - собранная из исходников с отладочной информацией система не останавливает во время отладки на системном вызове, а позволяет просмотреть - что там происходит - и соответственно понять свои ошибки в понимании механизмов. Это реально повышает производительность - убедился на собственной шкуре. К тому же диагностика далеко не всегда бывает достаточно внятной, что бы разобратся - почему все вроде бы правильно написанное не работает.

В принципе это правильно - имея доступ к отладочной информации того инструментария, с которым работаешь, намного проще анализировать его поведение и свои проблемы. Хотя в конечном счете все упирается в качество инструментария и в первую очередь качество его документированности. Именно это важно в первую очередь, ведь только сами исходники могут мало помочь - взять хотя бы тот же stl - отдельные его места практически не читаемы (хотя на это и есть объективные причины, точнее были на момент написания этой библиотеки). Даже тот же QNX местами имеет весьма загадочные конструкции в заголовочных файлах типа вложеных неименованных структур и unions. И очень помогает в этой ситуации именно документированность и хорошо описанное rationale (как и почему это должно работать).

Т.е. я хочу сказать, что открытость исходников к сожалению часто приводит к бедности документации, что делает систему более непонятной, чем закрытая система, но хорошо документированная.

[zetvictory 0]

Если вам надо забить один гвоздь, вы в принципе можете сделать это и камнем, если ничего нет под рукой.

Если вам надо забить 10 гвоздей, без молотка будет очень трудно.

Если вам надо забить 100 гвоздей - понадобится и соответсвующее рабочее место.

Если надо забивать 1000 гвоздей в час - понадобится полноценное, удобное, рабочее место и качесвенный инструмент.

 

В былые времена фабричное производство начиналось именно с изготовления инструмента. Не потому, что мастер совсем не мог найти молоток, просто молотки были настолько кривые и несовершенные... ;) Сегодня в программировании еще каменный век, хоть бы что там ни говорили!

 

Почему ОСРВ и softPLC так рьяно завоевывают западный рынок и так тяжело проходят на нашем? потому что у них выделяются совсем другое количество времени на разработку. Не могут они себе позволитиь тратить столько времени, сколько тратят у нас.

 

Вернее, столько ДЕНЕГ? Согласен, если у нас на качественную разработку потребительского изделия достаточно потратить в среднем 10-15 тыс. у.е. за пол года времени, то у них это зарплата одного инженера за три месяца примерно...

 

Когда вы используете НАСТОЯЩУЮ ОСРВ (т.е. прошедшую сертификации, с нормальной историей и success story, то вероятность, что ошибка будет связана с самой ОСРВ - примерно 1% и почти наверняка она уже документирована. Когда вы пишете свой код - вы каждый раз создаете новые ошибки :-)

 

Каждый раз когда приходилось сталкиваться с чем-то "настоящим" и "сертифицированным", создавалось впечатление, что это не я использую, а меня используют для исправления собственных глюков. В любом случае использовать чужой код менее эффективно, чем собственный. Нужно изучать приличный объем документации, другого пути нет.

 

Не верю (с) Станиславский.

Как два программиста могут с НУЛЯ решить задачу быстрее чем 15, работающих с готовым инструментарием?

 

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

 

Но и утверждать, что на ассемблере - лучше, сейчас по меньшей мере - ошибочно.

 

Лучше что? Утверждаю: ручной код на ассемблере наиболее быстрый и прозрачный, т.е. с точки зрения машины он лучше. Другой вопрос, нет времени все писать на ассемблере и тем более заниматься "складыванием байтов", когда поколения процессоров сменяются раз в год-полтора.

 

Хорошо сказал Goroshko Egor - настолько хорошо, что даже цитировать отдельные места не хочется... (жаль, что это не я сказал! ;)).

Добавить можно бы только то, что при самом поверхностном рассмотрении, желание "всё написать с нуля" - оно проще, за него проще отвечать, но происходит оно ... от страха (именно и только от страха) использования чужих механизмов.

 

Знаете, мне действительно страшно использовать компоненты, работу которых нельзя проверить. А вам не страшно будет садиться в самолет, например, если вы не уверены в его надежности? В самолете один двигатель, один бак, одна пара шасси... Хорошо еще если парашюты выдадют!

 

Бывают приложения в которых беспечность, как крайняя форма смелости не проходит.

 

Если вас не устраивает (ошибается) в конечном итоге некоторая возможность из операционного окружения, sqrt(), например - то добавьте свою реализацию sqrt() к той же операционной среде (библиотекам etc.), даже не удаляя никаким образоим ту исходную реализацию, которая вас не устроила. Размер? а кого интересует на сегодня размер? вы хорошо представляете тот объём ненужного кода, который прикомпоновывается к вашей системе при использовании любых tools?

 

Экий вы быстрый! :) Ошибка в простых операциях библиотеки плавающей точки тоже легко может быть заменена, по-вашему? Посмотрите код на выходе компилятора. Мало того, такие вещи никогда не документируют в готовых библиотеках. Особенно все становится очень забавным, когда у вас на такой "хилой" основе решается система дифур. Кстати, хороший компилятор не линкует ненужный код к приложению.

 

Да и в отношении объёма кода ... "слухи сильно преувеличены"© - простейшие функции вы да, можете реализовать "с нуля" в 10-100 строк кода, но ... использование сложнейших моделей поведения, типа "менеджер ресурсов", в операционной среде реализуются в 100-200 строк (только интерфейс), а нечто подобное по функциональности потребует "с руки" - многих тысяч строк кода (с пропорциональным числом привнесенных ошибок!).

 

:) Скажите пожалуйста, а все эти ОСы не люди написали? Да, объем текста нужен немалый. Для примера, драйвер файловой системы FLASH в ручном исполнении занимает 4540 строк, но в его работе после 550 тыс. часов наработки в различных условиях и изделиях нет сомнений. Как он работает в ЛЮБОЙ ситуации я знаю точно, могу отвечать материално за результаты, а вы готовы заплатить из своего кармана за сбои в работе черного ящика на базе готовой системы? Обычно производители софта стыдливо отгораживаются WARNINGами и "ограниченными лицензиями", когда разговор идет об ответственности.

 

Вы можете реализовать "с нуля" любые функции, любой сложности. Все остальное есть вопрос желания, времени, терпения и навыка. Более того, заглядывая в чужой код, за который заплачено денег, разве никогда не возникало разочарования типа "Ну кто так строит?" ©

 

Есть подозрение, что использование чужих "готовых библиотек", где надо и не надо частично происходит от страха перед невыполнимой задачей или нумения огранизовать и поддерживать крупный проект или от лени. Лень родилась раньше нас, эт ясно, а страхи проходят после первой попытки построить нечто крупнее 100 тыс. строк. Попробуйте! "Не пожалеете, если останетесь живы..." © М.Твен

 

И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...

Поэтому панацея - не "открытость кода", а: а). соответствие его выверенным стандартам поведения a'la POSIX + б). массовостью (тысячи пользователей) и долгосрочностью (годы и десятки лет) его испытания и тестирования. Это есть и необходимое и достаточное условия!

 

Каменный век в программировании продолжается! Ура! :)

 

но происходит оно ... от страха (именно и только от страха) использования чужих механизмов.

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после

некоторого освоения и изобретения первого "лома".

 

Чужие механизмы потому и "чужие"... Лучше бы вы сказали: "стандартных механизмов"! А постигать (читай: созерцать и размышлять) занятия по времени бесконечные. К сожалению пока заказчики не готовы платить только за созерцание.

Изменено 25 мая, 2006 пользователем Vlad-12

[zltigo 1]

Знаете, мне действительно страшно использовать компоненты, работу которых нельзя проверить. А вам не страшно будет садиться в самолет, например, если вы не уверены в его надежности?

Я Вас понял - самолетами Вы не летаете, поскольку их сделали не Вы и скорее всего перед посадкой

Вам не дали все "проверить" (постучать ногой по стойке шасси и понюхать керосин, а что Вы еще можете 'проверить'?). Понятно.

Но после этого Вы почему-то пишете:

И святая вера в наличие исходников здесь - не панацея...

Каменный век в программировании продолжается! Ура! :)

Как-то у Вас все наизнанку вывернуто - использование орудий труда c 'рынка' вместо собственноручного изготовления каменного топора называете 'каменным веком'.

[Goroshko 0]

В былые времена фабричное производство начиналось именно с изготовления инструмента. Не потому, что мастер совсем не мог найти молоток, просто молотки были настолько кривые и несовершенные... ;) Сегодня в программировании еще каменный век, хоть бы что там ни говорили!

Боюсь вы немного путаете - это называется не каменный век, а натуральное хозяйство. Боюсь история уже наглядно продемонстрировала всю неэффективность такого подхода. В области программирования, что бы вы не говорили :-) натуральное хозяйство осталось исключительно в самых консервативных областях. И дело не в надежности/ненадежности чужого кода, натуральное хозяйство сохраняется там, где это могут себе позволить разработчики. Когда время на разработку достаточно большое, что бы тратить его на создание велосипедов. Когда работа команды разработчиков оплачивается в часах, заказчик никогда невыделит средства на написание вещей, уже существующих.

 

Вернее, столько ДЕНЕГ? Согласен, если у нас на качественную разработку потребительского изделия достаточно потратить в среднем 10-15 тыс. у.е. за пол года времени, то у них это зарплата одного инженера за три месяца примерно...

Любопытная у вас логика. А вы не заметили, что из нее вытекает? Получается, что западные разработчики намного квалифицированнее наших? И могут сделать за три месяца тот же продукт, что наши за пол года? А?

Мне кажется что это не совсем верно, да и практический опыт показывает обратное. Просто у них время - это действительно деньги. И не могут они себе позволить тратить пол года там, где можно потратить всего три месяца. А мы пока что можем себе это позволить, не везде конечно. И именно по этому еще остаюстся у нас подобные дисскусии. Я собственно и занимаюсь тем, что руковожу разработкой СКАДА системы для европейской фирмы - системного интегратора. И требования по надежности этой системы - самые жесткие. Фирма занимается автоматизацией безопасностей автомобильных тунелей - а это уровень безопасности выше чем скажем в метрополитене. Ведь там основная проблема - пожары автомобилей и можете себе представить что творится в многокилометровом тунеле когда там загорается автомобиль.

 

Каждый раз когда приходилось сталкиваться с чем-то "настоящим" и "сертифицированным", создавалось впечатление, что это не я использую, а меня используют для исправления собственных глюков. В любом случае использовать чужой код менее эффективно, чем собственный. Нужно изучать приличный объем документации, другого пути нет.

А вы наверно можете написать вектор или карту, работающую эффективнее stl? Неужели кто-то выделит средства на такую работу?

 

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

Это не вопрос использования/неиспользования чужого кода - это вопрос организации управления разработкой. мы же обсуждаем совсем другой вопрос.

 

Утверждаю: ручной код на ассемблере наиболее быстрый и прозрачный, т.е. с точки зрения машины он лучше. Другой вопрос, нет времени все писать на ассемблере и тем более заниматься "складыванием байтов", когда поколения процессоров сменяются раз в год-полтора.

Прозрачный????? Что значит в вашем понимании прозрачный? Мало того что он совершенно не читаем и очень тяжел для понимания, т.е. время на посик ошибок в ассемблерном коде на порядки выше чем на любом более менее высокоуровневом языке, а значит он менее надежен, так и ще и в большинстве случаев, нанаписание ассемблерного кода, сравнимого по производительности с тем, который оптимизирует компилятор также требует очень больших временных затрат.

 

Маленький офтопик, с вашего позволения...

Анекдот:

приходит заяц к медведю и рассказывает:

Знаешь Миша, я когда вот тут себя почешу, мне так приятненько становится. А вот если я одну лапку за спину заброшу, а потом потянусь, и вот так голову наклоню и здесь себя почешу, такие мурашки приятные по шкурке...

А медведь ему и говрит - Знаешь заяц, а не дофига ли у тебя времени?

 

Вы можете реализовать "с нуля" любые функции, любой сложности. Все остальное есть вопрос желания, времени, терпения и навыка. Более того, заглядывая в чужой код, за который заплачено денег, разве никогда не возникало разочарования типа "Ну кто так строит?" ©

 

Есть подозрение, что использование чужих "готовых библиотек", где надо и не надо частично происходит от страха перед невыполнимой задачей или нумения огранизовать и поддерживать крупный проект или от лени. Лень родилась раньше нас, эт ясно, а страхи проходят после первой попытки построить нечто крупнее 100 тыс. строк. Попробуйте! "Не пожалеете, если останетесь живы..." © М.Твен

Знаете есть еще одна причина. Попробуйте написать нечто работающее оптимальнее и надежнее stl? Или Boost?

А может если вам нужен xml вы пишете свой парсер?

Или свою базу данных, когда надо хранить и обрабатывать большие данные?

Или пишете с нуля свои компиляторы?

Одно могу сказать - я вам завидую, у вас очень щедрые заказчики!

Изменено 27 мая, 2006 пользователем Goroshko Egor

[zetvictory 0]

Я Вас понял - самолетами Вы не летаете, поскольку их сделали не Вы и скорее всего перед посадкой

Вам не дали все "проверить" (постучать ногой по стойке шасси и понюхать керосин, а что Вы еще можете 'проверить'?). Понятно.

 

Минуточку! :) А вы всегда воздерживаетесь от поступков, когда страшно? По поводу самолетов существует система для поддержания их технического состояния, описания технологических процедур и сертификации компонентов. Чего стоит только запрет на вылеты всех машин определенной марки до выяснения причин аварии, повлекшей человеческие жертвы.

Не припоминаю, чтобы софтверные фирмы хотя бы оповещали ВСЕХ потребителей о существующей проблеме в софте. Не только на своем сайте вешали маленькую кнопочку "поддержка", а оповещали каждого?

 

Как-то у Вас все наизнанку вывернуто - использование орудий труда c 'рынка' вместо собственноручного изготовления каменного топора называете 'каменным веком'.

 

:) тут уж как у кого руки стоят! Мне, например, топор не нужен а инстумента всякого за 20 лет деятельности накопилось предостаточно, чтобы не покупать чужой. Может наоборот, продать кому-то?

 

Позволю себе венуть цитату целиком:

 

И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...

 

Проявления каменного века я вижу здесь: "внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок". Так происходит из-за того, что "генератор исправлений" был пЪян, сильно торопится, либо код написан криво и не годится для модификации?

 

Попробуйте отремонтировать "большой и сложный" автомобиль сегодня.

Большинство деталей и инструмента вы найдете стандартными и не станете вколачивать микроскопом саморезы, "внося 3 новых тонких ошибки", не так ли? В нормалной стране вам просто не дадут "вносить ошибки" даже в свой собственный автомобиль, для этого есть обученный специалист и ремонтная база. Конечно, если вы сами автомеханик -- "флаг в руки!", но тогда автомобиль не такой уж и сложный.. ;)

 

Возвращаясь к теме: в таких условиях нет причин использовать готовый код покупной ОСРВ, не поддающейся модификации или вообще без исходников в любых приложениях. Еще более интересно выглядит применение операционных надстроек... В принципе на их базе возможно построение стабильных систем при условии отлаженности отдельных частей, применении в родной предметной области и, возможно, наложении запрета на любые модификации.

 

Мне кажется, что большинство проблем любой грамотный разработчик или группа могут решать не прибегая к покупке готовой ОСРВ. Сделают это быстрее по отношению к освоению покупного кода, поиску и устранению в нем слабых мест (для конкретной предметной задачи). По крайней мере, пока не будет разработано единых стандартов построения, написания и документирования программ, системы имен и т.п. нет смысла тратить время. Возможно некоторой альтернативой является ПО с открытым кодом, которое по законам биологии должно бы путем эволюции дойти до наилучшего возможного уровня но за приличный промежуток времени.

[zetvictory 0]

В области программирования, что бы вы не говорили :-) натуральное хозяйство осталось исключительно в самых консервативных областях. И дело не в надежности/ненадежности чужого кода, натуральное хозяйство сохраняется там, где это могут себе позволить разработчики. Когда время на разработку достаточно большое, что бы тратить его на создание велосипедов. Когда работа команды разработчиков оплачивается в часах, заказчик никогда невыделит средства на написание вещей, уже существующих.

 

Ладно, можно сказать иначе. Почему заказчик вообще должен платить деньги тем, кто хочет за них купить весь инструмент материалы и выполнить работы? Разве не является нормальным когда у строителей уже есть инструмент, который они хорошо знают и могут эффективно применять? Не надо переписывать готовое -- пользуйтесь! Не хватает -- найдите готовое и освойте как свое или напишите. Но путь "найти и освоить" часто приходит в точку "написать свое", вот почему проще бывает написать свое сразу не тратя времени на поиски чужих ошибок. Именно поэтому разработка "с нуля" может быть более эффективной, особенно для небольших проектов.

 

Вернее, столько ДЕНЕГ? Согласен, если у нас на качественную разработку потребительского изделия достаточно потратить в среднем 10-15 тыс. у.е. за пол года времени, то у них это зарплата одного инженера за три месяца примерно...

Любопытная у вас логика. А вы не заметили, что из нее вытекает? Получается, что западные разработчики намного квалифицированнее наших? И могут сделать за три месяца тот же продукт, что наши за пол года? А?

 

Вероятно вы не поняли :) Разве я сказал, что один их разработчик за три месяца справится?

 

Мне кажется что это не совсем верно, да и практический опыт показывает обратное. Просто у них время - это действительно деньги. И не могут они себе позволить тратить пол года там, где можно потратить всего три месяца.

А мы пока что можем себе это позволить, не везде конечно. И именно по этому еще остаюстся у нас подобные дисскусии. Я собственно и занимаюсь тем, что руковожу разработкой СКАДА системы для европейской фирмы - системного интегратора. И требования по надежности этой системы - самые жесткие. Фирма занимается автоматизацией безопасностей автомобильных тунелей - а это уровень безопасности выше чем скажем в метрополитене. Ведь там основная проблема - пожары автомобилей и можете себе представить что творится в многокилометровом тунеле когда там загорается автомобиль.

 

Мы так скатимся до спора о курице и яйце. Они не могут себе позволить тратить пол года? А мы можем себе позволить потратить миллион за три месяца? Нет, что ж так? Ну не готовы наши бизнесы вкладывать такие суммы в разработку пока еще... Именно по этой причине вы работаете для "для европейской фирмы - системного интегратора", а мы работаем для местного рынка и на местные деньги, соответственно не применимы и западные подходы. К слову, одно из направлений: системы безопасности атомных станций.

 

А вы наверно можете написать вектор или карту, работающую эффективнее stl? Неужели кто-то выделит средства на такую работу?

 

Наверно да, а нужно? :) Гораздо интереснее решать новые задачи, которые еще никто не решает. А вот на них средства выделяются...

 

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

Это не вопрос использования/неиспользования чужого кода - это вопрос организации управления разработкой. мы же обсуждаем совсем другой вопрос.

 

Заказчику разве не наплевать на характер ваших проблемы, если работа стоит или на выходе не то, что он хотел? Где же системный подход к проектированию или на метод "из пушки по воробьям?"

 

Прозрачный????? Что значит в вашем понимании прозрачный? Мало того что он совершенно не читаем и очень тяжел для понимания, т.е. время на посик ошибок в ассемблерном коде на порядки выше чем на любом более менее высокоуровневом языке, а значит он менее надежен, так и ще и в большинстве случаев, нанаписание ассемблерного кода, сравнимого по производительности с тем, который оптимизирует компилятор также требует очень больших временных затрат.

 

Можно встречный вопрос, Вы давно писали программы на ассемблере? А приходилось ли писать крупный проект? Мне ваши слова напоминают схрахи студента-первокурсника на первой лекции по матанализу. Существуют достаточно эффективные подходы к программированию в т.ч. на ассемблере. Обычно не вызывает затруднений читать ассемблерный код системы 10-ти летней давности, даже не помня точного смысла отдельных команд смысл действий остается понятен и можно восстановить алгоритм не затрачивая каких-то суперусилий. По поводу вероятности ошибки -- все с точностью до наоборот! Не буду приводить конкретный примеров, скрытые ошибки, пропущенные компилятором "С" бывает сложнее найти чем было бы написание новой функции на ассемблере и ее отладка.

 

Вопрос не в том на каком языке написана ваша программа, вопрос в используемых подходах к проектированию вцелом!

 

А может если вам нужен xml вы пишете свой парсер?

Или свою базу данных, когда надо хранить и обрабатывать большие данные?

Или пишете с нуля свои компиляторы?

Одно могу сказать - я вам завидую, у вас очень щедрые заказчики!

 

Представляете! :) Однажды за пол дня написал простейший парсер XML статей в одном краткосрочном проекте на PHP и не жалею. Через полтора года при переносе сайта провайдером на PHP5 решил подправить код "оптимизировать"... В результате два дня бодался с провайдером, чтобы изменили настройки кодировок. Так в чем же дело? Клиенту (торговая фирма) есть дело до того, кем написан парсер? Сайт не работал(бы) два дня, это проблема!

 

Ну про базу данных и компиляторы не буду, а то точно не поверите... ;) Есть проекты, были разные решения и с каждым новым шагом легче дальше ходить. Чего и вам желаю!

 

 

В области программирования, что бы вы не говорили :-) натуральное хозяйство осталось исключительно в самых консервативных областях. И дело не в надежности/ненадежности чужого кода, натуральное хозяйство сохраняется там, где это могут себе позволить разработчики. Когда время на разработку достаточно большое, что бы тратить его на создание велосипедов. Когда работа команды разработчиков оплачивается в часах, заказчик никогда невыделит средства на написание вещей, уже существующих.

 

Ладно, можно сказать иначе. Почему заказчик вообще должен платить деньги тем, кто хочет за них купить весь инструмент материалы и выполнить работы? Разве не является нормальным когда у строителей уже есть инструмент, который они хорошо знают и могут эффективно применять? Не надо переписывать готовое -- пользуйтесь! Не хватает -- найдите готовое и освойте как свое или напишите. Но путь "найти и освоить" часто приходит в точку "написать свое", вот почему проще бывает написать свое сразу не тратя времени на поиски чужих ошибок. Именно поэтому разработка "с нуля" может быть более эффективной, особенно для небольших проектов.

 

Вернее, столько ДЕНЕГ? Согласен, если у нас на качественную разработку потребительского изделия достаточно потратить в среднем 10-15 тыс. у.е. за пол года времени, то у них это зарплата одного инженера за три месяца примерно...

Любопытная у вас логика. А вы не заметили, что из нее вытекает? Получается, что западные разработчики намного квалифицированнее наших? И могут сделать за три месяца тот же продукт, что наши за пол года? А?

 

Вероятно вы не поняли :) Разве я сказал, что один их разработчик за три месяца справится?

 

Мне кажется что это не совсем верно, да и практический опыт показывает обратное. Просто у них время - это действительно деньги. И не могут они себе позволить тратить пол года там, где можно потратить всего три месяца.

А мы пока что можем себе это позволить, не везде конечно. И именно по этому еще остаюстся у нас подобные дисскусии. Я собственно и занимаюсь тем, что руковожу разработкой СКАДА системы для европейской фирмы - системного интегратора. И требования по надежности этой системы - самые жесткие. Фирма занимается автоматизацией безопасностей автомобильных тунелей - а это уровень безопасности выше чем скажем в метрополитене. Ведь там основная проблема - пожары автомобилей и можете себе представить что творится в многокилометровом тунеле когда там загорается автомобиль.

 

Мы так скатимся до спора о курице и яйце. Они не могут себе позволить тратить пол года? А мы можем себе позволить потратить миллион за три месяца? Нет, что ж так? Ну не готовы наши бизнесы вкладывать такие суммы в разработку пока еще... Именно по этой причине вы работаете для "для европейской фирмы - системного интегратора", а мы работаем для местного рынка и на местные деньги, соответственно не применимы и западные подходы. К слову, одно из направлений: системы безопасности атомных станций.

 

А вы наверно можете написать вектор или карту, работающую эффективнее stl? Неужели кто-то выделит средства на такую работу?

 

Наверно да, а нужно? :) Гораздо интереснее решать новые задачи, которые еще никто не решает. А вот на них средства выделяются...

 

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

Это не вопрос использования/неиспользования чужого кода - это вопрос организации управления разработкой. мы же обсуждаем совсем другой вопрос.

 

Заказчику разве не наплевать на характер ваших проблемы, если работа стоит или на выходе не то, что он хотел? Где же системный подход к проектированию или наш метод "из пушки по воробьям?"

 

Прозрачный????? Что значит в вашем понимании прозрачный? Мало того что он совершенно не читаем и очень тяжел для понимания, т.е. время на посик ошибок в ассемблерном коде на порядки выше чем на любом более менее высокоуровневом языке, а значит он менее надежен, так и ще и в большинстве случаев, нанаписание ассемблерного кода, сравнимого по производительности с тем, который оптимизирует компилятор также требует очень больших временных затрат.

 

Можно встречный вопрос, Вы давно писали программы на ассемблере? А приходилось ли писать крупный проект? Мне ваши слова напоминают схрахи студента-первокурсника на первой лекции по матанализу. Существуют достаточно эффективные подходы к программированию в т.ч. на ассемблере. Обычно не вызывает затруднений читать ассемблерный код системы 10-ти летней давности, даже не помня точного смысла отдельных команд смысл действий остается понятен и можно восстановить алгоритм не затрачивая каких-то суперусилий. По поводу вероятности ошибки -- все с точностью до наоборот! Не буду приводить конкретных примеров, скрытые ошибки, пропущенные компилятором "С" бывает сложнее найти чем было бы написание новой функции на ассемблере и ее отладка.

 

Вопрос не в том на каком языке написана ваша программа, вопрос в используемых подходах к проектированию вцелом!

 

А может если вам нужен xml вы пишете свой парсер?

Или свою базу данных, когда надо хранить и обрабатывать большие данные?

Или пишете с нуля свои компиляторы?

Одно могу сказать - я вам завидую, у вас очень щедрые заказчики!

 

Представляете! :) Однажды за пол дня написал простейший парсер XML статей в одном краткосрочном проекте на PHP и не жалею. Через полтора года при переносе сайта провайдером на PHP5 решил подправить код "оптимизировать"... В результате два дня бодался с провайдером, чтобы изменили настройки кодировок. Так в чем же дело? Клиенту (торговая фирма) есть дело до того, кем написан парсер? Сайт не работал(бы) два дня, это проблема!

 

Ну про базу данных и компиляторы не буду, а то точно не поверите... ;) Есть проекты, были разные решения и с каждым новым шагом легче дальше передвигаться. Чего и вам желаю!

Изменено 27 мая, 2006 пользователем Vlad-12

[Goroshko 0]

Ладно, можно сказать иначе. Почему заказчик вообще должен платить деньги тем, кто хочет за них купить весь инструмент материалы и выполнить работы? Разве не является нормальным когда у строителей уже есть инструмент, который они хорошо знают и могут эффективно применять? Не надо переписывать готовое -- пользуйтесь! Не хватает -- найдите готовое и освойте как свое или напишите. Но путь "найти и освоить" часто приходит в точку "написать свое", вот почему проще бывает написать свое сразу не тратя времени на поиски чужих ошибок. Именно поэтому разработка "с нуля" может быть более эффективной, особенно для небольших проектов.

Вы меня не поняли. Я не говорил, что заказчик должен платить за инструмент. Заказчки платит за продукт. И выбирает исполнителя исходя из соотношения - качество/стоимость. А стоимость зачастую вплотную связана с временем разработки. А качесвенный инструментарий значительно сокращает время разработки и соответсвенно - стоимость. А где вы берете инструментарий - дело уже отдельное. Можно писать свой инструментарий, а можно купить готовый. Оба варианта - отнюдь не дешовые. В первом случае вы тратите деньги на разработку, во втором - на покупку. Практика показывает что самостоятельная разработка инструмента, по качеству соответсвующего покупному более затратна. Потому что сделать качественный, хорошо оттестированный и документриованный продукт (не программку, которой можете пользоваться не только вы лично), довольно дорого ( в смысле потраченного времени, которое, как известно - деньги :-) ). Лучшая аналогия, это когда строитель сам изгоавливает дрель, пилу, бетономешалку, цемент, кирпичи ну и т.д. :-) Это ведь немного отличается от изготовления раствора используя готовый цемент и готовую бетономешалку :-)

 

 

Вероятно вы не поняли :) Разве я сказал, что один их разработчик за три месяца справится?

И тем не менее - время разработки сопоставимых изделий здесь и там - зачастую разное. Их требования по времени разработки значительно превосходят наши во многих областях.

Ну не готовы наши бизнесы вкладывать такие суммы в разработку пока еще... Именно по этой причине вы работаете для "для европейской фирмы - системного интегратора", а мы работаем для местного рынка и на местные деньги, соответственно не применимы и западные подходы. К слову, одно из направлений: системы безопасности атомных станций.

Я ведь говорил не о суммах - при разнице вкладываемых сумм, колличество разработчиков для проектов одного типа вполне сопоставимы. Но требования по времени разработки отличается на порядок.

Наверно да, а нужно? :) Гораздо интереснее решать новые задачи, которые еще никто не решает. А вот на них средства выделяются...

Тогда это совсем о другом. Естественно для задач, которые не имеют готовых решений надо делать свои :-) Вы же вроде говорили о том, что предпочтительнее писать свое чем использовать чужое. Значит речь идет о ситуации, когда чужи решения уже есть - и пример вектора вполне оправдан. Но в его случае и вы сами спрашиваете - "а зачем?" Именно это вопрос возник и у меня по рочтении ваших постов. Мне тоже интерестнее решать новые задачи, не имеющие аналогов :-) .

 

Вопрос не в том на каком языке написана ваша программа, вопрос в используемых подходах к проектированию вцелом!

Удивительно, зачем же тогда люди придумывают новые языки, спорят о типизации, надежности, о безопастных конструкциях языка? Почему ищут подходы создания языков на который писать программы легче, быстрее и надежнее... Вы сравните временные затраты написания приложений на С# и на С++? Да это обычно задачи из разных областей, но опыт разработки показывает, что временные затраты на сопоставимые задачи у С# в разы меньше чем у С++.

 

Однако все вышесказанное никак не умаляте важности подходов к программированию... просто делает это проще :-)

[TMX 0]

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

Ну есть еще и поддержка.

Если вам придется по этому протоколу другие устройства подключать?

Искать того самого молчаливого программиста?

В принципе, неплохая гарантия занятости.

 

Насчет ассемблера - поддерживаю, все не так страшно.

[Goroshko 0]

Насчет ассемблера - поддерживаю, все не так страшно.

Хотел подчеркнуть, я не вижу абсолютно ничего страшного в ассемблере. Только я абсолютно уверен, что написание больших проектов на ассемблере - нонсенс. Это не только не надежно, но и не оптимально.

Но в конечном счете намного легче и проще написать критические места системы на С при этом учитывая логику обработки компилятором этих учасктов. В итоге конечный код будет зачастую даже лучше чем в ручную написанный на ассемблере и меньше гимороя при переходе на новый процессор.

По опыту разработок я для себя сделал вывод, что использование ассемблера должно иметь четкие оправдания и не в стиле - на ассемблере оптимальнее код, а нечто более весомое. И это не абстрактный страх (а что собственно страшного в ассемблере??? ), а требование к читаемости и модифицируемости кода, к его оптимальности.