ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Конечно, в каждом случае надо смотреть отдельно. Я просто высказываю мысли вслух.

Если бы я использовал FirstElementIndex только внутри List, скорее я бы назвал его просто «first».

Здесь есть некоторая порция неоднозначности, потому что непонятно, индекс ли это, итератор ли, или сам элемент. Более того, непонятно даже, переменная ли это или формальный параметр. А уж в Delphi, на котором мне выпало сейчас писать, и вовсе может быть property объекта.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

С появление intellisense я перестал думать о длинне имен и стараюсь писать читаемый код

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

Условно говоря,

lItem := lItem + some_func() + other_func();

лучше, чем

lSomeListItemWithNiceJavaStyleName := 
lSomeListItemWithNiceJavaStyleName +
SomeFunctionGivingResultWithNicejavaStyleName() +
OtherFunctionGivingResultWithNicejavaStyleName();

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

NullObject — лишняя сущность.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

А это смотря где. Да, я не говорю, о том как можно писать — за это надо руки отрывать — а о том, как физически возможно. Если метод статический по сути, а не по объявлению (да и если по объявлению), можно сcast'ить null в объект и вызвать этот метод.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Я не хочу тут говорить вам, что можно придумать более информативные имена для «a» и «b», тк не знаю контекста.

Это условные обозначения, мне было лень придумать примеры.
Допустим, это было бы что-то типа

TConList = class //TConnectionList
или 
lFIdx: integer; //lFirstElementIndex;

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Наверное зависит от человека.

Разумеется!
Просто без этого напоминает старый анекдот: «С утра заехал, купил колодки, потом смотался на другой конец города, купил сцепление, потом заехал на мойку, потом в сервис, поменял колодки и сцепление, потом на техосмотр. Фффух, как бы я это успел, если бы не было машины». Здесь аналогично — если мы говорим, о том, что null это evil, потому что мы не можем с в стиле stream писать, то встает вопрос — а надо ли оно изначально.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

По Go — это все же несколько иное. Я бы сказал, это синхронный vs асинхронный метод обработки ошибки. Не совсем точное определение — да, там все синхронное, но принцип частично похож — разнесение операции и контроля ошибки в разные места. То же самое «бросить исключение вместо кода ошибки» — отсюда же.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Ну вот есть мнение, что огромное количество кода падает от того, что программист забыл проверку на null в цепочке.

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

Которая вообще-то нужна только потому, что с null всё упадёт.

Да нет — это, например, просто символ ошибки операции. Вовсе не только потому что иначе упадет. Это может быть

someting = foo.bar();
if(something==null){
  doThis();
  doThat();
  reportSomething();
  return;
}

это может быть

data = foo.bar();
if(data==null){
  data = new Data;
}

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

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

По-моему, читать «математическую» нотацию вида

bean = repository.getBean();
data = bean.getData();
outcome = data.getName();
return outcome;

легче, чем цепочку, и проверки никак не мешают — это обычный шаблон, который воспринимается совсем буднично, потому что код написан так же, как исполняется машиной, и читая его, ты следуешь ее логике: «получили — ошибка? выходим. Нет, смотрим дальше».

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Статических методов у объекта не бывает, они у класса :)

Вроде я про статический метод объекта и не писал.

когда нужно просто написать цепочку вызовов и вернуть Null Object, если хотя бы один зафейлился.

null ничем концептуально не отличается — так же на каждой стадии при получении null мы можем прокидывать null наверх. Разница в написании в строку, но по мне, это сомнительное преимущество.

Вы в дискуссиях про Go участвовали? Помните там обработка ошибок как устроена?

Совсем немного.
Смотря где, постоянно вижу конструкции вида
err, res = function_name();

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Я стараюсь без дебага обходиться

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

Опять же условный брейкпойнт поставить в джаве несложно.

Условный — да, а можно ли в Java поставить BP на возврат объекта-пустышки из .getBean() в строке:
return repository.getBean().getData().getName();
Или все же потребуется
data = repository.getBean().getData();
return data.getName();

? И можете ли вы ловить именно объект-пустышку, а не null?

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Если метод не статический.

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

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

По-моему, код становится писать легче, а не читать. Красивая концепция — все в строку.
Еще вопрос: в стиле return repository.getBean().getData().getName();
вам нужно поставить breakpoint на вызов getName. Далеко не каждая среда разработки позволит отловить этот конкретный вызов. Уж не говоря о том, что с null мы можем поставиь точку останова именно на момент fail'а операции с целью просмотра каких-либо данных.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Это чисто syntax sugar разница, не более. NULL возвращается в качестве ссылки/указателя и ничем не хуже, чем указатель на существующий валидный объект или указатель на объект-пустышку.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

А так можно обойтись без проверок.

Зачем две лишние проверки возврата пустоты, если изначально ясно, что операция не удалась? Если следовать стилю автора (в части мячиков, собак, NULL и звонков с вопросом), то это примерно как вместо «дорогая, я забыл купить продукты» протянуть пустой пакет, сказать «свари из этого суп», получить в ответ пустую кастрюлю. Вместо того, чтобы отложить ее, съесть из нее пустоту-воздух ложкой, а потом отметить про себя, что калорий-то не поступило. Ну, да, результат одинаковый, процесс — нет, втч по затратам. Зачем?

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Это только синтаксически. Никто не мешает взять Foo(null).Bar();

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

с отсутствием ленивости

Ничего — у меня лично отсутствует отсутствие ленивости.

Elixir: Как выглядит ООП в функциональном языке?

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

Необязательно. Допустим, у нас есть рамочная конвенция поведения, на которую мы расчитываем (одинаковый ответ на одинаковые воздействия).

Для этого cloneFrom должен быть системным методом, недоступным для переопределения. Так?

Допустим, базовый объект, самого нижнего уровня в системе, имеет cloneFrom изначально. Или он работает, например, через сериализацию по public properties.

Elixir: Как выглядит ООП в функциональном языке?

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

Поведение у них по определению одинаково — это объекты одного типа. Я о конечных данных, если что, а не каких-нибудь active record'ах.

В этот момент то, что будет внутри, придется передать как примитив (и по значению). То есть мы все равно нарушили идею о том, что все есть ссылка

Не совсем. если мы делаем что-то типа objectA.cloneFrom(objectB), где объекты имеют доступ к внутреннему состоянию при клонировании, это будет внутренняя кухня, нас это не интересует — с точки зрения интерфейса у нас объект инициализировался объектом.

ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет

Более, чем самодостаточно: NULL это не 0, это невалидный объект(или структура ака запись). Это уже встроенный в язык NotExistingObject.