Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 16
Это база, ловить NPE на проде)
Тут ещё наверное вторая сторона медали присутствует. Крайняя ограниченность вычислительных ресурсов в 1965 году... Для реализации небезопасного "null" сколько байт кода в самом компиляторе надо? А для реализации "Option<T>" со всеми условиями?
“Как Rust обманывает процессор: тайная жизнь niche-оптимизации, drop flags и MIR” https://habr.com/ru/articles/1031398/
Ну и в целом чтобы придумать как именно это решать даже с небольшими ресурсами надо десяток лет пожить с этой ошибкой в проде. Щас-то с послезнанием хорошо говорить “это было ошибкой”.
В Java компилятор молчал, и ты узнавал о проблеме в проде. В Rust компилятор не даёт собрать программу, пока ты явно не ответишь на вопрос «а если тут пусто?». Дырку в стене вернули обратно в чертёж — и заварили на этапе компиляции.
Явно типизированный концепт Maybe лучше, чем автоматическое наложение этого концепта на вообще всё. Но он встречается настолько часто, что "для удобства" сделали unwrap и expect, которые втыкают в каждое второе место. В результате джависты смотрят на NPE в проде, а растисты - на креши всего продукта в проде.
Вместо работы с проблемой сказали "у нас ее нет, подпишите вот здесь что осознаете риск и берете ответственность" и как-бы вынесли за пределы безопасной безопасности языка.
А когда проблему игнорируют, то получается еще хуже.
Я бы сказал что NPE хуже unwrap() в том смысле, что unwrap сразу виден и его, например, поиском по коду можно найти. А вот с местами, где разименовывается указатель всё не так просто, места где может возникнуть NPE не так очевидны
Самое интересное началось как раз после того доклада 2009 года. Языки, которые проектировали уже с оглядкой на признание Хоара, эту дырку начали заделывать — каждый по-своему, но в одну сторону: отсутствие значения должно быть видно в типе, и компилятор должен заставить тебя его обработать.
В Haskell это Maybe. В Rust — Option<T>, и raw-null там просто нет как класса
Ну позвольте, это всё как минимум в Standard ML'е или даже в Hope появилось, к моменту этого доклада этому типу в том или ином виде минимум лет 20-30
Это примерно как вопрос почему Страуструп не реализовал ООП как надо было по Аллану Кею.
Потому что "правильный" способ работал слишком медленно.
Во-первых, не понимаю чего тут плюсуют. Статья сделана при помощи ИИ, но не в этом суть.
Во-вторых. ИЗВИНИЛСЯ??? За то, что создал null???
Ну не создал бы он, создал бы кто-нибудь другой. Потому что как без null? Разве кто-то хочет, чтоб ссылки вели куда-нибудь не туда, лишь бы не были null?
Ну не создал бы он, создал бы кто-нибудь другой.
Я абсолютно согласен с тем, что кто-нибудь в каком-нибудь языке высокого уровня обязательно сделал бы nil - это слишком напрашивающееся решение, это просто индикатор указателя, которому не присвоено значение; естественная альтернатива этому - случайное значение (что ещё хуже), а вовсе не современные абстрактны средства систем типов. nil ведь как раз и был придуман как дешёвый способ отличить неинициализированный указать от инициализированного.
Если бы Хоар в языке Algol-W сделал бы умную обработку ситуации с неинициализированными указателями, то, естественно, языков с корректной обработкой (с умной системой типов) было бы больше - потому что многие языки позаимствовали многие идеи из Алгола; а имеющих эту проблему - меньше. Но, думаю, вряд ли очень уж сильно. В Алголе были различные навороты, от которых при проектировании других языков отказались ради простоты и производительности, и от этого наворота отказались бы в пользу обычного null.
Да и похожая идея, по большому счёту, придумана независимо в Си - null-terminated string, пожалуй.
Разве кто-то хочет, чтоб ссылки вели куда-нибудь не туда, лишь бы не были null?
Речь не об этом, речь о языковых конструкциях, вынуждающих программиста использовании указателей ("разыменовании указателя") обрабатывать ситуацию, когда указатель не инициализирован, а не продолжать использовать его, как будто он инициализирован. Введение nil позволило программисту проверять, инициализирован ли указатель, но не заставило его это делать.
Хоар в тот момент проектировал систему типов для ALGOL W — по сути, первую серьёзную, всеобъемлющую систему типов для ссылок в объектно-ориентированном языке
ALGOL W - не объектно-ориентированный язык. Но если вы знаете о неизвестных работах Хоара в этой области, то это хорошая тема для следующей статьи
А в C# точнее в ADO.NET еще есть DBNull
А вот в современном C#/.NET есть типы string? и string. первый может указывать на null, второй - нет. дыра, наконец, закрыта?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Я не смог устоять»: как один человек в 1965-м добавил null, и оставил индустрии счёт на миллиард долларов