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

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

Это сообщение отредактировал(а) Zloxa - 3.10.2013, 13:25

Добавлю: как правило фунционал бага гораздо больше, чем фунционал ошибки.

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

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

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

Это сообщение отредактировал(а) Zloxa - 3.10.2013, 17:17

Ошибка - это когда глядя на код, понимаешь, что там кое-что сделано не так, как надо. Можно это ассоциировать с опиской в грамматике. Вот к примеру, нужно обратиться к первому элементу в динамическом массиве Arr. В коде стоит обращение Arr[1]. Ошибка в явном виде, т.к первый элемент имеет индекс 0. Еще одним ярким примером может служить не правильно использованные операторы. Вместо "не равно" стоит "равно". Вместо ">" стоит "<" и т.д.

Баг - это не верное поведение кода. Зачастую это проявляется только при определенных условиях. При определенных входных параметрах, результатах работы других частей программы и т.п. Т.е. на первый взгляд код может показаться правильным, но при определенных условиях он выдаст совершено не тот результат, который ожидается. Самым ярким примером бага является использование деления без проверки делителя на не равность нулю. Такой код будет работать и может случится так, что будет работать долгое время. Но как только он получит 0 в делителе, все рухнет. 

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

Вопрос задан неверно (с ошибкой), так как нельзя сравнивать качественно разные понятия - баг и ошибку.

Из моего опыта:

"ошибка" - признанный программистом факт несовершенства его навыков и/или знаний, при этом, неприменно, являющийся для всех объективной причиной некорректной работы его алгоритма.

Пример: программист неверно написал алгоритм подсчёта CRC суммы, так как не прочёл мануал.

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

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

по сути "баг и фича" это понятия, которыми оперирует не программист, а скорее архитектор системы или политическое понятие, которым оперирует высшее руководство компании.

Пример:  Майкросовт,  старается все свои баги превратить в фичи, путём финансового давления на конкурентов... Но вот со стороны пользователей фичи Майкросовта - откровенные баги.

Это сообщение отредактировал(а) CompWorm - 4.10.2013, 06:26

Вот где не соглашусь. Не могу даже предположить как divizion by zero может вдруг превратиться в фитчу. Или функция Sum, которая должна суммировать аргументы, получающая на входе 1 и 3 и возвращающая при этом 5. Какой нужно быть квалификации, что бы сказать, что это фитча?

Poseidon, в iPhone при наборе номера нельзя его редактировать, это баг или фича? 

Запрет делать что-то, ровно как и разрешение это делать - это всегда на усмотрение разработчика. Если Apple решили сделать так, то это фитча. А вот если бы ты набирал номер 123, а вызов шел на номер 321, то это баг. Правильно написал Zloxa:  В документации нет ни строчки о том, что пользователь должен иметь возможность редактировать номер - значит это фитча. Вот если бы там была описана эта возможность, то это было бы багой.
Но я не знаю не одной документации, где писалось бы "При вводе значения 0 программа должна аварийно закрываться".

Во, блин, сколько у нас настоящих программистов оказывается  

bug - это на буржуйском, а ошибка - на нашем 

Добавлено через 4 минуты и 57 секунд

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

Нет. Это лишь "not a bug".
Фичей это было бы если бы в документации было явно прописано, что пользователь не имеет возможности редактировать номер.


Однако если, скажем в ТЗ, есть упоминание о том, что значение не должно равняться нулю, но четко не прописано чем это должно быть обеспечено, это не баг.

Это сообщение отредактировал(а) Zloxa - 4.10.2013, 11:48

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

То, что компворм называл ошибкой, я склонен называть багом. Да, он появился в результате ошибочных действий программиста, возможно в результате ошибочной трактовки задания/документации или чего-то там еще. Можно сказать что "программист допустил ошибку при реализации алгоритма". Но неврено работащий алгоритм квалифицировать как "ошибку" - нельзя. Это либо баг либо нет.

Впрочем, про слово "ошибка" я уже высказывался.



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

Знакомый работает в IBA, у них есть понятие "дефект" 

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

Всегда ваш, К.О.

Это баг. И заключается он в том, что в ТЗ четко прописано что значение не должно ровняться нулю, а программа все-равно 0 пропускает. Значит где-то баг в фильтрации значений.

То что где-то есть баг - согласен.
Не согласен с тем, что краш по делению на ноль, в этих обстоятельствах - баг. Баг там, где появился этот ноль, который не должен был появиться. Это мог быть внеший по отношению к нам программный модуль. И полный и категоричный отказ промолачивать заведомые гoвноданные, в ряде случаев - намного лучше, чем аккуратное заметение под коврик ситуации, которой не должно возникать в принципе.

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

Это сообщение отредактировал(а) Zloxa - 4.10.2013, 16:33

Вообще-то в английском есть и "error" и "mistake" и уже IT-жаргонный "bug" и, возможно сюда и "failure" с "fault" впишется. Но вот то что слова "баг" в русском изначально не было - это верно  Но теперь-то уже есть, так что отклоняется! 

Пока читал, вспомнил про интересные эффекты в играх. Например, если в самом первом "Sonic The Hedgehog" на некоторых уровнях вставать на определенный пиксель на движущейся платформе, то наш ёжик проваливается под платформу, исчезает с глаз, а затем происходит что-то уж совсем странное: камера переезжает к концу уровня, причем даже соника не видно, он возникает только в конце. Чувствую что отхожу от темы, но вот что это? Есть ещё новомодное слово "глитч", но тут оно наверное не подходит. Тут явно баг. Даже непонятно, разработчики сделали это специально, или это какой-то не предусмотренный эффект? Кому интересно, можно посмотреть здесь (на 9:00 примерно такой же эффект): ссылка на момент с багом в прохождении Sonic на YouTube

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

Это сообщение отредактировал(а) ne_tru_e - 4.10.2013, 22:53

Зачем в богатый и прекрасный русский язык тянуть что-то из бедных языков?

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

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

я различаю ошибку (error) от оплошности (mistake):

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

и то и другое с т.з. пользователя может выглядеть похоже.
Где они расходятся?

1) в расценках решения:

• выявленная оплошность (обычно) дешева в починке, ее нередко замечают во время code review, или быстрого взгляда на код еще раз, эта сфера (теоритически) должна покрываться полноценным процессом разработки (т.е. контролем качества)
• выявленная ошибка нередко заставляет пересмотреть реализацию компонента или даже всю архитектуру. Tут yж никакой процесс не поможет, ошибкам легче пробираться в выпущенный продукт в полном "прокате", т.е. даже если есть команда QA, т.к. нередко им трудно отречься от общения с разрабами и "проникновения" веверным подходом к решению задачи.

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



Это сообщение отредактировал(а) bilbobagginz - 5.10.2013, 20:05

ne_tru_e, а Вы различаете дом и home, Землю от    
earth отличаете, мышь от mouse?

Добавлено через 6 минут и 7 секунд
вот как раз от кривого алгоритма неожиданный эффект и проистекает, ничего мистического в машинах нет, а на твои речи даже Билл хором с римским папой заорёт: "Ересь". И первый попавшийся иезуит им поддакнет и скажет, что тебе повезло, что живёшь среди цивилизованных людей, благодаря чему инквизитор с факелом по близости не околачивается.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 06:28

в контексте багофичи встаёт вопрос об оценке корректности любой работы любого алгоритма. Если ты пишешь модель электрометаллургического агрегата для целей САУ, то любая неадекватность модели есть баг, так как из-за него не правильным будет уже управление, в итоге в лучшем случае сварят дряную сталь, а потом сделанную из неё дверцу машины можно будет гнуть об локоть, а лист толщиной 20 мм будет коловоротом за 30 с дырявиться сверлом диаметром 40 мм, что не получается даже при замене листа кривостали доской из любой, сколь угодно мягкой породы дерева. Но если ты модель того же агрегата пишешь для игры, то можешь заявить, что в игре иная физика, по которой лапласиан потенциала в проводнике не равен нулю и объявить то же самое поведение алгоритма фичей. Если статья писана для любителей поиска очепяток и даже грубых ошибок, то слова "отака" - фича, а если для серьёзных читателей - ошибка.

Добавлено @ 06:56
В программировании в частности и в IT вообще возможны лишь две ошибки, не являющееся багами:
1. Ошибка в символе, или строке, предназначенной для вывода человеку (на дисплей, на принтер, на телетайп...): будучи ошибкой языка общения, а не программирования, такая ошибка не затрагивает алгоритм. Например, если пункт меню на экране будет назван не "Edit", а "Adit", или "Edeet", но в оконной процедуре идентифицирован правильно, то это ошибка с точки зрения английского языка, но не баг с точки зрения языка c++. Любая ошибка, являющаяся таковой с точки зрения языка программирования, есть баг и всякий баг есть ошибка.
2. Синтаксическая ошибка, на столько грубая, что компилятор её вообще не пропустит. До какого либо поведения алгоритма такая ошибка просто не дойдёт.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 07:00

В программировании вполне не редко случается, что суперпозциция ошибок не приводит к багам.    В то время, как исправление части этих ошибок как раз таки не устраняет, а приводит к проявлению багов.  

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

Добавлено @ 09:48
Например, если ты положишь PI=4, а во все формулы заложишь корректирующий коэффициент: l=3.1415926535897932384626433832795*PIr/2, s=3.1415926535897932384626433832795*PIr^2/4..., то такое значение PI ошибкой не будет, так как данные не обязаны соответствовать тому, что понимается под именованными константами в математике, а при таком PI 3.1415926535897932384626433832795*PI/4 равно обычному PI. 

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 09:49

Мне одному интересно, он это по памяти написал?   

Poseidon, не надо преувеличивать.

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

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 10:06

Нет. Требования формулируются для того, что хоть на что то влияет, а  - это константа-тёзка, если гарантированы правильные значения площади круга, длины окружности, площади сферы и объёма шара, то это не ошибка. А если ты декларируешь , но используешь не правильную формулу l=PI*r, то вот это и есть ошибка, при такой формуле правильное PI равно 6.283185307179586476925286766559. Если задача не число PI хранить в качестве справочного данного, а длину окружности вычислить, то в требования закладывается её правильное отношение к диаметру, а назовёшь ты PI это отношение, отношение длины окружности к радиусу, площади круга к диаметру, или что угодно ещё, значения не имеет. Главное гарантировать правильные результаты на выводе при любом вводе, в том числе, при обмене с другими программами, а как ты переиначишь внутри имена констант - твоё личное дело. Можешь вообще корнем квадратным назвать куб, а кубом корень квадратный, но и применять их наоборот и ошибкой это тоже не будет.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 10:14

Не важно для чего формулируются требвания. Если они сформулированы, им нужно соответствовать. 


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

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

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 10:41

Можно даже ввести понятие круглого метра с определением: круглый метр есть единица площади круга, равная площади круга, радиус которого равен метру, заложить коэффициент 3.1415926535897932384626433832795 в функцию возведения в степень при показателе, равном 2, а саму вторую степень назвать не квадратом, а кругом и положить s=PI*a^2 формулой площади квадрата ("эс равно пи а круг") и ещё предусмотреть перевод площади перед выводом на экран из круглых метров в общепринятые квадратные, тогда PI будет равно 0.31830988618379067153776752674503. Если от программы будут требоваться площади, а не степени, то это не ошибка.

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

Добавлено через 6 минут и 8 секунд
А откуда они в таком случае вообще знают о её существовании? Мне как то попадалась константа PI=1.5707963267948966192313216916398, и ничего. Я безглючно использовал её в тригонометрии с градусами вместо радианов.

Не важно откуда они узнали о ее существовании. Если не из документации/спецификации, это недокументированная особенность, которую можно использовать лишь на свой страх и риск. И если вдруг с выходом патча, окажется что значение этой константы изменилось, поставщику фреймворка/библиотеки/инструмента, предъявить будет нечего, на его баг трекере топик будет закрываться как not a bug.

не, число её интерпретаций не счетно.


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

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

ТарасАтавин, столько условностей, рекомендаций и ухищрений вместо простой рекомендации следования одной простой истине - не плоди гoвнокод, следуй спецификации, опирайся на документацию  

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 11:10

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

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 11:17

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

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 11:58

1. Чётная ошибка, то есть две взаимокомпенсирующие ошибки ошибкой не являются.
2. По возможности следует избегать даже таких пар, сокращая чётную ошибку, подобно тому, как школьники сокращают множители числителя и знаменателя дроби, так как хоть ошибкой она и не является, но повышает вероятность возникновения обычной нечётной ошибки при взаимодействии третьего места в программе с одной из половин чётной ошибки.
3. Если используешь сторонние файлы, всегда проверяй значения всех используемых констант и поведение всех используемых функций.
4. При использовании любых функций из сторонних динамических библитоек или таскай за собой гарантировано совместимые версии всех библиотечных файлов (если можно), или проверяй установленную версию. Если разрешено первое, то можно сочетать.
5. Если программный продукт в целом содержит даже одну не чётную ошибку, то виноват в ней не тот, кто написал гoвнoкод, а тот, кто писал часть программы, отдаваемую конечному пользователю.
6. Даже если приложение глючит из-за ошибки в библиотеке/SDK/компиляторе, то ошибка заключается в неучёте ошибки в библиотеке/SDK/компиляторе.
7. Тем не менее гoвнoкодь только для компенсации ошибок в сторонних гoвнoфайлах.

Добавлено через 3 минуты и 44 секунды
Не счётное количество причин ни как не может проявляться в конкретно-ограниченном проекте, использующем лишь некоторые сторонние константы функции, а не множество всех возможных констант и функций. А непосредственно используемые вещи проверить можно. Если ты прыгаешь на батуте, то зачем тебе стелить соломку у подножия восьмитысячника на соседнем континенте? Проверь батут, ты не народ потомственных альпинистов.

Добавлено через 10 минут и 17 секунд
Согласен, внутренние соглашения и документация на весь полуфабрикат - разные вещи и если сказано, что PI - это математическая пи, то этому можно и довериться. А я вот читал, что PI - это пи попалам. И что им предъявить на такую константу? Речь не о том, что надо проверять ещё и соответствие чужих спецификаций действительности. Речь о том, что не стоит доверять одним лишь именам, а подглядывание в спецификацию - один из способов той самой проверки, иногда даже единственно доступный.

Разработчик компилятора/библиотеки/IDE/SDK может быть виноват в ошибке только в том случае, если он не описал её, как фичу, допустив её именно у себя. К константам даже это не относится, по ним вина в ошибке только в случае прямой лжи в спецификации, а если константу вообще забыли описать в спецификации, то её документирует декларация. Кому не нравятся кривые константы - переопределяйте самостоятельно. А если вдруг автор языка написал, что на его языке сложение имеет приоритет над умножением, то потрудитесь исправить в исходнике прилады с помощью скобок, или путём вычисления произведений в виде именованных промежуточных результатов.

архисерьёзная ошибка так думать

 Да, но он ведь может компенсировать её другой архисерьёзной ошибкой 

Во-первых, странный наезд по поводу английского языка. Bug можно перевести как глюк, это наиболее подходящее слово, потому что уже есть перевод error - ошибка. И потом, если вспомнить историю, то появление термина "bug" возникло после того, как в шкафообразной ЭВМ нашли жучка, из-за которого она неправильно работала, кажется это был мотыль, хотя это слабо относится к теме, так же как слово глюк - сокращение от слова "галлюцинация". Про инквизицию и мистику: а я разве говорил что в программах есть нечто мистическое? Про неожиданный эффект я не зря написал. Вы в курсе, что когда выпускаешь программный продукт, и пользователи начинают им пользоваться, то практически сразу обнаруживается куча ошибок? И это не зависит от степени "крутости" и "пряморукости" разработчиков - всего предусмотреть нельзя. Тут Билли бы меня поддержал, а упомянутые не к месту Папа Римский и иезуиты ничего бы не поняли - зачем это им? И почему, кстати, бывший глава MS должен что-то там оценивать? Он для Вас последняя инстанция в вопросах разработки и программирования? Возьмите того же Sonic'a, которого я привел в пример, да многие современные и старые игры тоже, а уязвимости в программных продуктах, это не неожиданные эффекты? Только про кривые алгоритмы согласен.

bug (клоп, жучок) уже в 19 веке означал дефект механизма, возможно с подачи Эдисона

###. холивар

скопипастил с википедии   



Добавлено через 4 минуты и 17 секунд
А вы различаете багу, борбагу, гейзенбагу, мандельбагу и шрёдинбагу?!?!?!?   

Гурбангулы Бердымухаммедов.  

Ась?   

Я говорю, что мы тоже по иностранному магём.  

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

Вооот, а если бы научился произносить без запинки то, что я написал, то точно взяли бы  

Да уж, точно бы взяли   А потом догнали бы и еще раз взяли!