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

maccuB = [1,2,3,4,5,6,7,8,2**33]
maccuB.select{ |elem| (elem&1).zero? }

Данная программа из maccuBa вытаскивает только четные элементы. Четность проверяется при помощи следующего кода: (elem&1).zero?. Идет побитовое умножение на 1 и проверка результата на равенство нулю. Казалось бы все верно. Я тоже так думал... до недавнего времени.

Все зависит от содержимого массива. Дело в том, что в Руби (как и в Перле с Питоном) есть несколько типов целых чисел: Bignum и Fixnum. Fixnum -- это аналог всем знакомого int, а Bignum -- это все числа, которые в int не поместились. То есть целые числа делятся на большие и маленькие. И загвоздка в том, что большие не имеют побитовых операций, т.к. имею совсем другую структуру хранения числа.

Теперь ситуация -- в результате математических преобразований мы получили число, которое превышает допустимые 30 разрядов (японцы посчитали, что 32 -- число не круглое) и получили большое целое число. Во время проверки на четность вылезет ошибка, так как с побитовыми операциями у больших чисел проблемы. Проблема решается просто:

maccuB = [1,2,3,4,5,6,7,8,2**33]
maccuB.select{ |elem| (elem%2).zero? }

Заменой побитовой операции умножения на операцию получения остатка от деления.

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