Ну это просто одна из проблем, которую хорошо решают наследование+полиморфизм. Есть и другие, в том числе включающие наследование не только поведения, но и данных. Но в качестве контраргумента было достаточно одного примера.

Почитаю, спасибо, но речь же шла не о преимуществах Go перед другими языками. Речь о том, что, имея поддержку ООП в своем повседневном языке, человек ей не пользуется. По надуманным причинам.

А еще есть ощущение, что многие ставят знак равенства между «ООП вообще» и «моделированием доменной модели через ООП». Это совсем не одно и тоже. Как правило, построить доменную модель на объекта действительно очень сложно. И редко нужно.

Не нужно гнаться за «объективизацией», как за самоцелью. Применяйте, если это делает ваш код короче (и проще в поддержке). Большое приложение может состоять из независимых кусков — сервисов, каждый из которых предоставляет OOP-like интерфейс для внешнего мира, но не обязан быть объектно-ориентированным внутри. Также нет никаких требований объединять все классы приложения в единую мега-иерархию.

Я не автор, но отношусь к этому сугубо отрицательно. Говорят, множественное наследование сложно, потому что может возникнуть «deadly diamond of death», но эту проблему можно элементарно решить на уровне компилятора. Если в классе возникает проблема неоднозначности выбора метода, то нужно заставить разработчика явно реализовать этот метод. Вот и все, вроде.

А вы не смешивайте, вот и все.

Наследование — это самый мощный инструмент ООП. По-сути, без наследования (и связанного с ним полиморфизма) ООП особого смысла не имеет, ибо все остальное можно смоделировать, назвав процедуры удобным тебе образом.

Тут надо отойти в сторонку и сказать, зачем нужны ООП/ФП/etc. Основная цель любой методологии и любого нормального языка программирования — упростить решение задач. Определенных задач, разумеется, потому что универсального подхода пока никто не придумал. В программировании простота решения коррелирует с количеством кода, которое ты должен написать в прикладной программе. Пишешь меньше кода — тратишь меньше времени, упрощаешь поддержку продукта. Именно с этой точки зрения надо смотреть на языки программирования. Категории «труъ» и «не-труъ» интересны только как индикаторы достижения цели.

Так вот, для упрощения работы программиста в незапамятные времена были придуманы библиотеки процедур и вообще структурное программирование. Сейчас апологеты композиции (composition over inheritance) говорят, что вам достаточно скомбинировать библиотечные функции нужным образом чтобы получить требуемое сложное поведение. Это так, но таковая композиция сама по себе является сложной сущностью. Аналог такой сущности — стойка с сетевым оборудованием. Все компоненты в стойке стандартны, но конкретная конфигурация стойки — нет.

Что делать, если нам нужно переиспользовать такую композицию? В функциональном подходе можно сделать функцию, которая будет собирать составляющие ее функции нужным образом. Это отлично работает до тех пор, пока нам не потребуеся подменить одну фукцию из частей композиции на другую. Как это сделать без копирования всей композиции и замены одного имени на другой? Передавать этот подменяемый кусочек в параметрах? Неудобно, ибо в композиции может быть большое количество заменяемых частей, и нам придется предавать целую кучу параметров.

Класс в ООП — это по сути композиция функций, в которой можно подменять отдельные компоненты. Для этого там существует наследование и полиморфизм. Все просто.

Что характерно, например, в разработке веб-фронтенда такие хейтеры ООП спокойно используют HTML DOM и не жалуются, что это не кошерно. Возможно, даже не обращают внимание на факт соприкосновения с объектами.
Автор поднял правильную тему, и в правильном ключе. Спасибо.

Между приложениями и индексированием Гуглом очень мало общего. Речь шла о том, что многие приложения, которые сейчас традиционно реализуются нативными средствами, можно реализовать как PWA. Да, индексирование SPA поисковиками — сложная тема, но с индексированием нативных приложений дело обстоит еще хуже.

Занудам пристало быть грамотными.
ru.wikipedia.org/wiki/Клептократия

Значит необходим ИИ в телефоне, который будет работать твоим секретарем. Чтобы можно было спокойно расслабиться и быть уверенным, что в случае, если чинджер опять похитит твою сестру, телефон сообщит.

Нил Стивенсон обстоятельно писал свои книги задолго до того, как Энди Вейр взялся за клавиатуру. :) Легко могу рекомендовать любую его книгу.

Электрические грузовики, заправляются индукционным образом от дороги.

Нет ничего страшнее инициативного дурака.

Хотя стремление защитить свой образ жизни тоже нельзя списывать о счетов.

Интересующиеся могут посмотреть стоимость билетов на pathe.nl. Ровно так билеты и стоят. Ну и вообще, 12 евро — это такой привычный прайс на небольшие развлечения.

TypeScript уже включен в студию, начиная с 2013 Update 2.

А мне понравилась цепочка: акционеры решили увеличить прибыль на 20% — система сама сказала кому что делать. Че же они — лохи такие — не решили сразу на 1000% прибыль поднять? Это же волшебное решение основной проблемы бизнеса!

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

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

Вот и мне показалось, что это очевидный вывод. Срочно в номер — «Австралийские ученые доказали, что мы живем в Матрице». :)

Это в любом случае не будет пахнуть хуже, чем метод с пятью out-параметрами.