ReactOS поборется за государственные инвестиции.

я же говорю, без экстрима.

Видимо, вы так ничего и не поняли

Программист когда работает над кодом, пишет код примерно так как писалось до него, если чтобы имплементить фичу надо 100 строк, то чтобы сделать 10 фич, надо 1000 строк.

Ага, только разница в сложности между «фичами» может быть от нуля до бесконечности - и это не имеет никакого отношения к тому, как именно пишет код конкретный программист и как писалось до него. И я не говорю уже о привязке её реализации к какой-то фиксированной длине - это уже за гранью здравого смысла

сложная фича - много кода, простая - мало.

сложная фича - много кода, простая - мало.

А если кода поровну?

Значит примерно одинаковые фичи. Сложность ведь не только программная релизация. Вот как -то так все работает. http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx

Значит примерно одинаковые фичи.

Вы в адеквате или как?

Сложность ведь не только программная релизация.

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

Главная и основная причина программных ошибок - недостаток тестеров.

Главная и основная причина программных ошибок - недостаток тестеров.

Ага, а причина болезней - недостаток врачей и я чувствую, что это уже терминальная стадия. Понять то, что выявление ошибки предполагает её существование, судя по-всему, выше вашего понимания

Впрочем, мне это уже неинтересно

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

два варианта кода имеющих одну длину и решающих одну и ту же задачу практически идентичны.

два варианта кода имеющих одну длину и решающих одну и ту же задачу практически идентичны.

А если вы доведёте эту мысль до своего логического завершения, то с радостью откроете для себя закон тождества

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

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

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

Но речь даже не об этом - совершенно ненавязчиво с вопроса сравнения сложности реализации разных «фич» вы отползли на вопрос реализации одной «фичи» разными программистами. Если вы думали, что этот манёвр вам удастся, то вы заблуждаетесь - просто его несостоятельность не менее очевидна

Вот алгоритмы к фичам не имеют абсолютно никакого отношения. Я ждал когда вы про них упомянете. Если вы работали программистом, то знаете, что 99,9% кода - это не сортировки и не оптимизации, а просто логика работы программы и поддержание разных интерфейсов. Более сложная фича - та, в которой логика взаимодействий сложнее, значит для ее поддержания нужно больше кода, и в ней может быть больше багов.

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

sort(&begin,&end)

m3 = multiply(m1,m2)

Вот алгоритмы к фичам не имеют абсолютно никакого отношения. Я ждал когда вы про них упомянете. Если вы работали программистом, то знаете, что 99,9% кода - это не сортировки и не оптимизации, а просто логика работы программы и поддержание разных интерфейсов.

Логика работы программы - это и есть её алгоритм, и всё, что было сказано про варианты реализации сортировки и оптимизации, точно также относится как к программе в целом, так и к отдельным её частям («фичам», ну или что вы там под ними понимаете)

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

Это было бы справедливо, если бы единица кода несла бы в себе равное количество «взаимодействий» как меры сложности - однако это не так

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

Только эта одна строчка в каждом конкретном случае будет иметь разную «логику взаимодействий» - поэтому даже если допустить существование программ длиной в одну команду их сложность будет различной (для разных команд)

Вчера поставил посмотреть что за зверь, 5 минут работы и bsod)

РеактОС добьётся большего успеха нежели линукс. Касперский-ready же наверняка.

Нет, сложность у них будет одинаковой. И та и другая «программа» делает одно действие, и имеет ровно одно место для совершения ошибки (я сейчас игнорирую ввод и вывод данных).

Вариант реализации алгоритма взять из базы данных два числа, перемножить и положить обратно в базу данных - фактически один. Сортировка - математический алгоритм, математики 100 лет думали и придумали кучу разных вариантов на все случаи жизни. Алгоритмы «бизнес-логики» отличаются тем, что они с одной стороны простые (взять зарплату человека, умножить на 10, вывести как максимальную сумму кредита), а с другой стороны прописаны не на уровне программиста, а на уровне заказчика. Для прикладных программ алгоритмы прописывает фактически дизайнер, который определяет логику взаимодействия программы с пользователем.

Нет, сложность у них будет одинаковой. И та и другая «программа» делает одно действие, и имеет ровно одно место для совершения ошибки

Вы сами догадаетесь, что за абсурдный вывод следует из этого утверждения?

Для прикладных программ алгоритмы прописывает фактически дизайнер, который определяет логику взаимодействия программы с пользователем.

Вам напомнить с чего началась дискуссия?

Удобная программа имеет больше логики взаимодействия с пользователем, по этому она нуждается в лучшем тестировании, а если оно отсутствует, то получаются глюки

Это вы кому отвечали?

Это я возвращаюсь к началу: если креатор следать таким же функциональным и удобным как студию, то он развалится

Это я возвращаюсь к началу: если креатор следать таким же функциональным и удобным как студию, то он развалится

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

вообще, да, дизайнер. Беда gdb не в том, что он мало умеет, он умеет все. Беда в том что пользоваться им совершенно невозможно.