плюсую, в начале такой подход то что нужно, если переходить с ооп-языков
через некоторое время постепенно стаёт интуитивно понятно, как более общо функции выражать/переиспользовать в multiple dispatch-парадигме

по крайней мере мне не помогало то, что пытался читать про этот вопрос  - только когда какое-то количество кода написал, то стало яснее

Я как потомственный рабоче-крестьянин плохо разбираюсь в заумных рассуждениях, но с практической точки зрения вот это

"В объектно-ориентированном программировании (ООП) мир задачи описывается как совокупность объектов, обладающих некоторыми свойствами и вступающих во взаимодействие. За основу описания берутся не отношения, а сами объекты. Объект состоит из данных (внутренняя структура объекта) и методов (набор операций, применимых к данному объекту)"

ничем не отличается от того, что делается в Джулии. За основу берутся объекты, между которыми описывается взаимодействие. Объект в данном случае состоит только из данных (внутренняя структура объекта), а методы являются внешними по отношению к объекту (на самом деле эта разница достаточно эфемерна и по факту является синтаксической).

Ну, имеется в виду, что с точки зрения написания программы, нету практической разницы между x.foo() и foo(x), хотя в первом случае метод вроде бы как принадлежит объекту x, а во втором случае вроде бы нет.

Ммм...
Возможно только с точки зрения инкапсуляции и приватности есть разница (насколько я понимаю, в некоторых диалектах приватные методы нельзя вызывать вне описания класса).

Разница в том, что foo(x) не привязан часто к конкретному типу x а работает с большим набором типов, которые могут быть не связаны друг с другом никакими формальными отношениями 🙂 Возможно я сильно забиваю голову и на старте это не важно, но это действительно значимое отличие

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

Основная разница между OOP и multiple dispatch в том, что у методов нет выделенного объекта, это да. И это звучит достаточно разумно, если подумать - почему у функции с двумя аргументами, первый аргумент должен быть важнее второго?

Именно, тут главное выражение "набор операций, применимых к ДАННОМУ объекту (или классу)"

Строго говоря, foo(x) жёстко привязан к абстрактному типу Any, потомками которого являются все остальные. И в этом смысле, foo следует интерпретировать как метод общего предка в ООП

Мне кажется тут вопрос скорее подхода филосовского.
Например в классическом ООП какие-то объекты умеют считать свою (length) - что бы она не значила. И если ты хочешь внутри своего кода получить длинну объекта, то ты сначала должен формально убедиться что ты работешь только с объектами которые ее умеют отдавать (Т.е. явно указывают свое наследие от какого-то интерфейса) и ты не можешь сам научить существующий класс считать свою длину если у тебя нет доступа к его коду.
В джулии алгоритм подсчета длины живет отдельно от классов и объектов - это просто функция length. Если ты хочешь добавить возможность считать длину какого-то объекта, то ты просто дописываешь для этого объекта реализацию этого алгоритма

скорее подхода филосовского

да нет, как раз таки если Джулия позволяет писать как хочешь, надо сразу определится с этим

К Джулии этот афоризм наверное не очень применим, потому что она про 100 функций, которые работают с 10 структурами.

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

Вот я немного в прострации, обычно в учебниках пишут про основу языка - ООП, там или ФП, рассказывают как представлять задачу в коде, в виде типов или объектов или функций, в Джулии как то этот момент вообще пропускается, как будто кроме написания небольшой функции больше ничего и нет в языке

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

Найдите книжку, которую я скидывал. Там прям разбор паттернов и общих типа Банды Четырех и специфически джулевых при реализации на Джулии есть в довольно кратком и понятном виде

+ в закрепе данного телеграм канала есть достаточно много интересных вещей.