Пусть тогда показывает что-то вроде tooltip’а «вы меняли код, ткните сюда и я запущу тесты» или запускает по таймауту.
Но делать это на каждое задумчивое добавление одного символа в исходник — однозначный перебор.

Я не вижу в слове «кибербионика» ни одного корня, связанного со словами, табуированными в светском общении.

Ну а как ещё научиться дварковать коллег по офису влендишным способом?

зависит от ситуации: есть задачи «пусть лучше вылетит, чем работает абы как», есть задачи «пусть хоть что-то сделает, а там посмотрим». Снесет пол базы — да, проблема, не найдет значение в 10 файлах из миллиона — может проблемой и не быть.

Система, в которой вылетает при любом некорректном действии, конвертируется в систему, которая не вылетает, одним простейшим обобщающим try-catch.

Система, которая скрывает внутри своих действий все проблемы, выдавая вместо исключений всякие undef/None/etc., конвертируется в систему, которая отвечает за свои действия и не делает некорректных действий, очень долго и муторно, а чаще всего — просто заменой языка на надёжный.

signaling NaN собсно для того и signaling чтобы выкидывать исключения. если уж у вас получилось его создать, то исключений от него вы ждать должны.

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

Дискриминация — неоправданное различие в правах и обязанностях человека по определённому признаку.
Если бы «не семейные пары» не могли снять квартиру вообще — это было бы дискриминацией.

Когда большинство хозяев вводят такие ограничения — получается это самое «вообще».

Если вы выступаете против этого права, то ВЫ и разводите дискриминацию.

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

В нравоучениях и советах не нуждаюсь. Спасибо за понимание.

Не за что. Вы не показали ничего такого, что следовало бы «понять».

Это условия орендодателя, а не дескрименация.

Дискриминация — это выставление условий, которые не обоснованы объективно, а являются желанием левой пятки поставщика услуги.

И подтяните грамматику, пожалуйста.

угу. только вот очень легко находится

Не в коде стиля пресловутого imap-uw :)

а вот то что в динамических языках просто быстрее написать реализацию и начать тестить — єто факт

это ортогональные понятия.

теже boundary errors компиляторы статически типизированных языков не отлавливают , и что ? часто валится ?

Да, бывает.

посмотрите на мир, где циклы проца дешевые, а «циклы» прогера дорогие...

И снова — не путайте два разных аспекта типизации.

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

Не должно быть «варнингов», если значение непустимо — надо не писать нечитанную ботву в лог, а порождать исключение.

perl -e ’use strict; use warnings FATAL => qw(all);

Само по себе то, что это надо явно включать, делает язык опасным.

Тем не менее, если вы явно: if(int("0.0″)) или не очень явно: if("0.0″ + 0) скажите что это не строка, а таки число,

Обе Ваших проверки чреваты боком.

Практически дословно: «Состояние в настоящем, которое является следствием действий в прошлом и выражено через эти действия».
Это определяет ИЕ перфект и его наследника — английский Present Perfect, и покрывает все известные свойства:
* выражение завершённости действия, в случае «предметного» действия;
* конструкции типа «I have lived here for 10 years» (которые в случае обычных определений описываются явно, а в нашем случае — являются очевидным следствием), и понимание, чем они отличаются от Present Continuous в той же роли;
* недопустимость сочетания с указанием момента времени — потому что описываемое состояние — в настоящем, а не прошлом;
* то, что если состояние чем-то «испорчено», то надо использовать уже Past Perfect;
* почему вспомогательный глагол — to have;
* прямую связь с causative form.

Сам курс напоминает размазанную школьную программу старших классов.

Свою специфику Вы и так освоите. А вот умение говорить — чтением мануалов не создаётся. Поэтому эти курсы обычно дополняют то, что получаешь сам от работы.

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

Я бы на месте работодателя был бы максимально заинтересован в полезности/эффективности таких курсов.

Ну так это и получается.

грамматики, которая у многих хромает, дается по минимуму и т.д.

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

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

вообще в вашем варианте, при use strict/warnings; вы увидите сообщения об ошибках когда пытаетесь использовать undef (который вытащен из хэша).

Использовать под что, простите? Это уже зависит от целевой операции. Может, где-то undef — нормальное значение (как оно часто и бывает). А просто сообщения об ошибке — это путь в никуда. Недопустимая операция просто не должна выполняться.

ну в том то и дело, что в рамках языка это поведение консистентно и понятно.

Что именно? Что 0.0 это false, а «0.0» это true, и отличить на уровне языка нельзя? Это не может быть консистентным и понятным в любом языке.

с чего бы вдруг. тот же пшп «претендует» только на веб

Вы действительно не знаете разницу между уровнем и ориентацией языка? ;)

несколько передергиваете, дыры не были связаны с тем что программисты использовали операторы сравнения со строками

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

почему же тогда программы на «типобезопасных» языках все также имеют глюки ?

Потому что не все глюки ловятся системой типов. Хотя наиболее опасные могут ею быть легко отловлены.

как по мне тут борьба с проблемой, которая затрагивает только школьников

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

например в си тоже строки напрямую нельзя сравнивать

Си это переносимый ассемблер, соответственно, его ограничения растут из его нацеленности на железо. А названная троица претендует на роль ЯВУ.

и ничего , все живы :)

Ой сказки-то не рассказывайте. Почитайте, какие дикие дыры находили в коде на Си в 90-х (все интернетовские сервисы того времени) и как медленно народ учился писать секьюрно.

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

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

Что мешает в php принудительно приводить типы?

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

но что военного в нужном месте использовать (int) или intval() или floatval() etc в зависимости от ситуации?

То, что где-то проконвертировали значение, а где-то — забыли. Вот ошибся программист после 7 часов упорной работы (а впереди ещё 3 часа). А затем начинается, что в типичной ситуации «оно» работает без ошибок, а в некоторых маргинальных — начинает нести фатальную чушь. И вы даже тестами этого не ловите, потому что обычный тест не позволяет проверить, в скаляре число или строка, представляющая это число. Напоминаю мой пример про префиксы телефонных номеров: это вылезло не сразу.

После приведения типов всё становится более-менее согласовано.

Мне нравится это «более-менее», оно как раз отражает ситуацию. Вот именно, когда более, а когда менее. Вы привели данные (ну, 99% из них — потому что 1% или забыт, или не приведён из-за изменения структуры базы). А дальше что? Как проверить, что операция в принципе корректна, потому что она однозначно применима именно с той функциональностью, которая задумана?

Я согласен, что при привычке работать с языками с жесткой типизацией от php может возникнуть butthurt, если не похуже.

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

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

а если не ознакомился, что намного чаще?

Включат древовидное представление.

пока не увидел ни одной

Помогает опыт чтения почты и хождения на форумы:)