PPL (Practical Programming Language)

Как же мне не нравится этот пистонячий способ выделения блоков только табуляцией.

Дали мне недавно статью почитать о пользе null и как его правильно готовить

И сразу ясно, чего стоит сабж. Приятно, когда авторы сходу признаются в своих извращениях. Не нужно время тратить.

Там не только табуляция.

Какие извращения? На сколько я понял в Kotlin реализованы похожие принципы.

У него optional на уровне языка?

The fundamental principle for achieving null-safety in PPL is this:

    PPL makes a distinction between nullable and non-nullable types.

    By default all values are non-nullable. Non-nullable values cannot be null at runtime and therefore
    can't lead to a null pointer error.

    Values that are allowed to be null at runtime must explicitly be declared as nullable in the source
    code. The compiler requires that nullable values must be checked for null before an operation can be
    executed on them. Thus null pointer errors can't occur at runtime.

    There are specific instructions and operators to support writing compact and readable null-safe
    code.

Тоже самое или очень похожее, но с другим синтаксисом, есть и в Kotlin
https://kotlinlang.org/docs/reference/null-safety.html

И в swift, и в rust (но явно).

На сколько я понял в Kotlin реализованы похожие принципы.

Ну и зря. Зачем городить особые случаи вокруг null, если человеческий Option решает всё то же самое по общей схеме проверки типов? Это и есть извращение, городить особые случаи там, где можно того же результата добиться композицией базовых принципов. Эдакая избыточная аксиоматика, где аксиомы просто вводятся от балды вместо того, чтобы доказать теорему на основании уже существующих. Такое ещё можно оправдать удобством использования, но удобство в данном случае не возрастает ни на йоту.

И в swift, и в rust (но явно).

Про Swift я не знаю, но в Rust как раз человеческие опции, разве нет?

В rust Option - часть std, а не языка, как у остальных.

Optional а не Option? Optional жрёт ресурсы на своё создание и удаление.

В rust Option - часть std, а не языка, как у остальных.

Да, я это и назвал «человеческим Option».

Optional а не Option?

Название в конкретном языке не важно. В Haskell это вообще Maybe. Речь об общем подходе к дизайну языков.

Optional жрёт ресурсы на своё создание и удаление.

В области применения JVM-based языков это несущественно, т. к. если внутри не примитив, то без аллокации памяти всё равно не обойтись. А там, где существенно, есть Rust. И в нём опции не жрут ничего сверх того, что сожрали бы nullable указатели. Зато типобезопасность обеспечивают.

Не важно что внутри. Создание и удаление любой обвязки требует ресурсов.

4 года пишу на Scala за деньги (а для себя ещё больше), и что-то ни разу не приходилось оптимизировать опции.

Знатоки JVM - можете мне сказать, почему все эти изобретатели модно-молодёжных языков поверх JVM так носятся с этим null-safety как с писаной торбой какой-то ?

Null-pointer exception'ы - это, что, такая большая проблема в чистом Java, что в каждом новомодном языке нужно обязательно её решать ?

Null-pointer exception'ы - это, что, такая большая проблема в чистом Java, что в каждом новомодном языке нужно обязательно её решать ?

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

Имхо проблема с нуллами — просто в невнимательности и их нужно просто нормально обрабатывать.

У Optional есть один минус.

Почему у нас возникает проблема null? Потому что мы забываем проверку на null или ошибочно предполагаем non-nullability.

Используя Option ничего не мешает написать optionVariable.get() на Option, который содержит null. Если использовать pattern matching, так, конечно, не выйдет, но потенциал для ошибки, особенно у джуниоров, остается.

С Nullable-типами, условно, у нас есть принудительный pattern matching по null-у везде.

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!".

Плюс нельзя заставить разработчиков везде использовать Option — будут забывать. А ведь есть ещё и библиотеки, где у авторов особое мнение.

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

Можно возразить — есть Code Review. Но это не умаляет плюса.

Code Review, как и QA, — процесс стохастический. При этом деградирующий с ростом мест, где потенциально могут быть проблемы, — ревьюер устает, да и глаз замыливается.

Type Level Nullability (ещё более по сравнению с Option) уменьшает количество ошибок, за которыми надо следить, повышая качества продукта.

Сам по себе он, конечно, не Killer Feature, особенно, если есть Option, но вполне себе практичная и приятная вещь, которая реально крутая и легкая в освоении (кстати, легче и компактней того же Option).

Имхо проблема с нуллами — просто в невнимательности и их нужно просто нормально обрабатывать.

Дык, и я про тоже. В публичном API - так или иначе обязательна проверка входных параметров, в том числе и на null. И null safety здесь задачу практически никак не облегчает. А во внутренних кишках своего кода - ты уже и сам знаешь где null а где не null, и лишняя потеря производительности и новый язык тут не нужны.

А во внутренних кишках своего кода - ты уже и сам знаешь где null а где не null, и лишняя потеря производительности и новый язык тут не нужны.

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

Null Safety решает именно эти проблемы.

Как и статическая типизация, например.

И когда Null Safety интегрирована в систему типов, отсутствует runtime cost.

Знатоки JVM - можете мне сказать, почему все эти изобретатели модно-молодёжных языков поверх JVM так носятся с этим null-safety как с писаной торбой какой-то ?

Null Pointer Exception упоминается разными авторами как самая часто встречающаяся ошибка в мире Java. Например, https://en.m.wikibooks.org/wiki/Java_Programming/Preventing_NullPointerException Моя практика говорит о том, что это действительно частая, лёгкая к исправлению и оттого особенно противная ошибка.

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

NPE — аналог утечек памяти и SEGFAULT из мира C/C++ (ну ок — утечки сильно жёстче из-за сложности локализации). Теоретически — вопрос только внимательности. Практически — не зря же даже хардкорные плюсовцы не требуют супервнимательности от сверхлюдей, а делают всякие auto_ptr или вообще Rust-ы. ;)

Прошу обратить внимание на то, что PPL отличается не только null-safety. У него есть и другие отличительные особенности. Каковы ваши мнения о них?

Например там:
1. реализованы Generics без type erasure.
2. отсутствуют примитивные типы и массивы
3. отсутствует автоматическое преобразование типов, хотя "", 0 и null приравнены к false
4. корневой тип (аналог Object в Java) не имеет никаких функций кроме to_string, тоесть невозможно забыть реализовать equals, hashcode, clone и в итоге получить неправильную реализацию из Object.
5. нет тихого арифметического переполнения (постоянно проверяется флаг переполнения CPU?)
6. нет необходимости в гетерах и сетерах, кроме случаев нестандартной реализации
7. нет необходимости в блоке деклараций import/using в начале кода (а что вместо этого?)
8. ключевое слово debug для установки точки останова и запуска UI встроеного дебагера
9. тройные апострофы, внутри которых не обрабатываются эскейп последовательности
10. тройные двойные кавычки, внутри которых есть плейсхолдеры

const name = "Einstein"
const quote = "Try not to become a man of success, but rather try to become a man of value."

const message = """{{name.to_upper_case}} said:
{{quote}}"""

Category		Operators
Arithmetic		+, -, *, /
Append			&
Boolean			and, or, xor, not
Comparison		>, >=, <, <=
Value equality		=v, #v
Reference equality	=r, #r
Feature access		., .null?, .error?
if expression		if {expression} then {expression} else {expression} end if
Null alternative	if_null:
Error alternative	if_error:

У Optional есть один минус.

Ровно тот же минус есть и в подходе с обеспечением null safety через создание особых случаев. Ведь:

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!"

Уродливость оператора — это категория, приходящая с опытом. Для гипотетического джуниора это ничем не отличается от вызова get опционального значения. И точно так же требует поправки на code review.

Плюс нельзя заставить разработчиков везде использовать Option — будут забывать.

Если в языке нет null, то не будут. Опять же воспользуюсь случаем и сошлюсь на Rust. Там это очень грамотно реализовано.

У Optional есть один минус.

Ровно тот же минус есть и в подходе с обеспечением null safety через создание особых случаев. Ведь:

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!"

Уродливость оператора — это категория, приходящая с опытом. Для гипотетического джуниора это ничем не отличается от вызова get опционального значения. И точно так же требует поправки на code review.

Для начала про Rust — там, по сути, мы тоже имеем _почти_ Type Level Null Safety, нужно постараться, чтобы вставить null, он не является в явном виде частью языка. Не совсем идеально, но тоже очень хорошо с учетом необходимости сохранения null для FFI.

Вообще же, например, в Scala, я упоминал еще, что можно не просто написать Option.get(), можно просто не вернуть Option, а вернуть сырой объект (или null) из метода. :)

И в итоге — либо все оборачивать в Option, даже если не nullable, либо где-то не оборачивать и тогда каждый раз при использовании думать — там действительно not nullable или просто обернуть забыли? Или не обернули специально, а потом отрефакторили кусочек метода и не заметили, что теперь он может вернуть null?

А так — null *уже* сам по себе является особым случаем — объект может быть двойственного типа и иметь кардинально разное поведение.

Дальше нужно «или крестик снять, или —».

Если мы добавляем Option, давайте реально полностью убирать null — ну хотя бы как в Rust (все же совместимость нужно сохранять), только, лучше, еще более жестко. Вон, как в C# Unsafe делали в свое время — и в блок специальный выделить участок кода нужно, и флаг компилятора вставить — десять раз подумаешь, нужен ли этот геморрой.

Если мы оставляем null как особый случай — давайте не Option ставить, а Nullable Types. Option в таком случае хуже — дает меньше гарантий.

Если в языке нет null, то не будут. Опять же воспользуюсь случаем и сошлюсь на Rust. Там это очень грамотно реализовано.

Про rust — согласен. Но в большинстве остальных языков есть одновременно и Option, и null — это плохо.

можно просто не вернуть Option, а вернуть сырой объект (или null) из метода. :)

Увы. Родовые травмы Java. К сожалению, тут только дисциплина. Это можно со спокойной совестью записать в недостатки Scala. С другой стороны, соблюдать эту дисциплину не так сложно. null ниоткуда не вернётся, если его где-то явно не написать. И если есть желание его где-то написать, то это уже однозначный сигнал использовать Option. Могу сослаться на свой опыт. NPE в Scala-коде встречается очень редко. Но да, я бы предпочёл, чтобы null вообще не было. Ибо:

Если мы добавляем Option, давайте реально полностью убирать null

Exactly my point.

null ниоткуда не вернётся, если его где-то явно не написать

Можно и неявно. Значение ссылочного поля класса по умолчанию null.

Да, действительно. В рамках предлагаемого подхода такого тоже быть не должно.