Я читал о том, как неудачный стиль программирования на таких языках, как Erlang, заканчивается гораздо более короткими программами, чем защитный стиль, найденный на большинстве других языков. Это правильно для всех типов программ и для чего это необходимо?Почему неудачные программы быстрого стиля короче, чем программы защитного стиля?
Неудачные программы не обязательно короче программ защитного стиля: это зависит от реализации и мер, необходимых для обеспечения безопасного оборонительного кода.
В случае Erlang программы с быстрой задержкой обычно короче из-за декларативного стиля и того, как VM обязательно генерирует ошибки для вас. В качестве примера, в функции:
day(1) -> sunday;
day(2) -> monday;
day(3) -> tuesday;
day(4) -> wednesday;
day(5) -> thursday;
day(6) -> friday;
day(7) -> saturday;
Любое неожиданное значение, переданное в функции приведет к ошибке, которые могут быть перехвачены и обработаны другим процессом (т.е. .: супервизор). Такие ошибки также никогда не будут подвергать опасности систему в целом и не требуют добавления кода к самой функции - все это делается за пределами обычного пути выполнения по предопределенным поведением.
В динамическом языке, где fail-fast не является нормой, вам придется вручную проверять границы и выдавать исключение самостоятельно. Затем вы должны поймать исключение локально (на уровне верхнего уровня try ... catch), если вы не хотите, чтобы вся система опустилась. Код обработки ошибок обычно должен быть вставлен по всему пути выполнения.
В статическом языке, где отказоустойчивость не является нормой, то как долго ваш код будет сильно зависеть от вашей системы типов. Если язык позволяет определять типы, в которых конечные случаи заканчиваются проверкой для вас компилятором, вам обычно не нужно обрабатывать это внутри кода, за пределами недетерминированных событий (файлы не работают, неожиданный ввод пользователя и т. Д.). языках с такими системами типов, многие ошибки будут обнаружены до начала выполнения, и поэтому у вас не будет столько защитных случаев.
Если невозможно избежать ошибок, языки, поддерживающие отказоустойчивые идиомы (например, Erlang), позволят использовать более понятный код, чем языки, которые не являются (статическими или нет), главным образом потому, что код для особых случаев isn ' t с кодом для идеального пути выполнения.
Неудачный стиль программирования ориентирован на лучшую читаемость кода и отладку. Пользовательский опыт является вторичной целью: пользователь может испытывать странные сообщения об ошибках или сбои программ, но более высокое качество кода позволяет программистам легко найти ошибку и исправить проблему.
Оборонительный стиль программирования вместо этого фокусируется на валидации ввода от пользователя и от других частей кода. Код более подробный, потому что программист должен тщательно проверять ввод и изящно терпеть неудачу в случае ошибки. Это приводит к большему количеству кода (с точки зрения программистов) и более надежному приложению (с точки зрения пользователей).
Неправильно. Вы сбиваете с толку неустойчивый стиль без стиля обработки ошибок.Неудачный стиль по-прежнему позволяет вашей программе ловить ошибки и восстанавливать их, не беспокоя пользователя. – Deestan
Очевидно, что пользователь также использует преимущества менее багги программного обеспечения с отказоустойчивым стилем. Я бы сказал, что failfast - это ясность в правильном вводе и некорректном вводе, и на самом деле это необходимо. Ясность неизменно дает лучшее программирование. Ошибки на входе должны быть отмечены как таковые (вместо того, чтобы приложение ограничивалось неопределенной землей), но это не препятствует тому, чтобы приложение обрабатывало эту ошибку элегантно и интуитивно. Я думаю, вы создаете ложную дихотомию. – harms
Неверный ответ. В контексте Erlang, для которого был задан вопрос, более надежный подход заключается в том, чтобы избежать защитного программирования и просто позволить процессу оскорбления «сбой». В другом процессе будут предприняты соответствующие действия для восстановления. В Java, на котором у вас есть опыт, у вас нет выбора, кроме как защищаться, потому что это императивный язык с моделью параллелизма с общим состоянием. Поскольку Erlang - это функциональный язык с параллелизмом при передаче сообщений, а также потому, что существуют механизмы для обмена сообщениями между процессами, это совершенно нормально и предпочтительнее, чтобы быть быстрым. – dsmith
См. Разделы 4.3 и 4.4 от Joe Armstrong's thesis.
Ссылка не работает, но вот что работает: http://erlang.org/download/armstrong_thesis_2003.pdf –
Раздел 4.5 также имеет отношение, на мой взгляд. –
Я собираюсь сломать традицию и спросить, почему это было сделано wiki сообщества. :) –
Должен ли я изменить его, чтобы он не был вики-сообществом? Я никогда не уверен, какая вещь является вики-сообществом, а какая нет. – Zubair
Большая вещь об вики сообщества - это то, что люди могут редактировать любой ответ, чтобы исправить это, и нет никаких точек upvote, предоставленных пользователю, который отправил ответ, в то время как обычный режим дает очки, и только пользователи с минимальным количеством точек могут редактировать ответы. –