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

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

зависит от ситуации: есть задачи «пусть лучше вылетит, чем работает абы как», есть задачи «пусть хоть что-то сделает, а там посмотрим». Снесет пол базы — да, проблема, не найдет значение в 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, если не похуже.

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

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

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

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

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

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

Если мы в нем не можем этого чего-нибудь найти: то на это требуется как минимум явная реакция именно для этого хранилища.

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

Самый яркий пример такого подхода — в эрланговском «Let it crash». Но и вообще рекомендации для языков с системой исключений именно такие — проверяйте явно только то, что надо явно проверять по спецификации или если защиты по недопустимой ситуации или значению просто нет (как в перле).

А ещё есть вопрос тестирования — на котором особенно явно, что поиск багов резко облегчается, если видим исключение, но не если проблема замолчена (тогда без пошагового отладчика фиг чего найдёшь).

Ловить проблемы все же лучше поближе к месту их возникновения: так можно и пользователю что-то более разумное показать, и самому быстрее найти.

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

Разгадка проще: в документации явно указано что является false.

В документации может быть задокументировано что угодно (например, что 0 и 3.1415926 являются False, а остальные значения — True). Вопрос в том, насколько такое поведение консистентно в общих рамках языка и средства. Понимание любой непустой строки как истинной, как в Python, консистентно с логикой языка, в котором неявная конверсия строки в число недопустима. Язык, в котором числа и строки смешаны до такой степени, что их нельзя отличить никакими средствами самого языка, но при этом 0.0 есть false, а «0.0» есть true — неконсистентен и поэтому ущербен. И сколько бы его авторы ни документировали этот подход — правильнее он от этого не станет.

я еще раз повторюсь — вы приписали перлу и пшп то, чего нет

Я «приписал» им неявную конверсию между числами и строками. Она, очевидно, есть.

а по поводу конверсии — лично мне (после си) такой подход нравиться , код чистый от явных преобразований и лучше читается

Он в разы хуже читается, потому что непонятно, что ожидать от каждой операции.

«неожиданные эффекты» возникают обычно от быдлокода, так быдлокодера строгая типизация не остановит

Она позволит тому, кто будет читать код, увидеть эту конверсию и оценить её необходимость и эффекты в этом конкретном месте. И не позволит замаскировать такие конверсии.

В языках, где этот вопрос решён адекватно (например, в Go), даже конверсия между равномощными int и int32 запрещена, потому что первый — тип конкретной платформы, а второй — межплатформенный переносимый.