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

Мы как-то умудряемся риалтам писать, конечно не без поддержки со сторону C/C++, но логика вся в перле.

Ну вот именно для того, чтобы логика не разъехалась, лучше бы узнавать о том, что валидные данные случайно были испорчены, например, как можно раньше и получать при этом как можно более вменяемую ошибку, что при проверке в той sub'е, которая использует данные, куда проще, чем когда ошибка уже спуститься на 20 уровней вниз и вызовет произвольное perl'овое исключение

Конечно, все данные проверяются при входе. Размазывать проверки по всему стеку - гарантия тормозов.

> валидные данные случайно были испорчены

давай это, еще чексуммы строковых переменных пересчитывать - вдруг космическая радиация биты в ячейке изменила, а память без ECC ?

реалтайм можно писать на чем угодно.
хоть на шелел
это следует просто из определения реалтайма

rowhammer!

вопрос в том, для кого сервис, для людей или для черепах

ну и его нагрузочная способность тоже, чтоб не закупать 100500 серверов

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

Если приложение меняется каждый день - есть набор тестов без прохождения которого приложения даже на сэндбокс не выкатить

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

если такое поведение где-то вылезет где-то, то на него появится тест

Ага, только для того, чтобы понять, что же было причиной - нужно будет разное время потратить в зависимости от того, где произошло исключение - в том куске кода, который понимает, какие данные ему нужны и знает, почему реально пришедшие данные не соответствуют требованиям, или где-то в произвольном месте возникнет "а тут нельзя undef!!"

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

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

а что плохого в стэктрейсах?

они ни очем

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

вместо стектрейса должно быть внятное и адекватное сообщение в лог