Кто нибудь видел табличку или статью с сравнением ЯП из ООПс точки зрения реализации типов/классов? И в каких случаях брать неООП?

Question

[moybublik]

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

Comments

[Дмитрий]

Было бы интересно узнайть что писать собрались, от того и выбор будет.
Есть языки где классы есть, но не про ооп вообще

Answer 1

[Adamos]

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

ООП, например, вообще не применяется в программировании скриптов на Bash. И в PostScript ООП нет и не будет. И еще есть куча ниш, где оно просто не нужно. Но вам-то это правда нужно знать, если вы не сталкивались и не узнали именно поэтому?..

Answer 2

[mayton2019]

Непонятно что вы хотите увидеть в этой табличке? Кейсы в которых надо брать ООП или не-ООП?

Мы живем в эпоху мультикультурализма в разработке. Языки такие как C++/Scala в принципе - мультипарадигменные. Они являются одновременно ООП и ФП. И эта диффузия продолжается.
И другие языки тоже идут в этом направлении.

Есть хороший доклад Брагилевского где он просто напримере геометрических фигур (круг, квадрат)
показвывает что ФП и ООП - это просто две ортогональные технологии которые одинаково ведут
к успеху.

По реализациям. 99% зависит от платформы. Например языки C#/F# будут скорее всего использовать
платформу .Net и ее реализацию типов и классов. Языки Java/Kotlin/Scala - соотв будут опираться
на JVM-представление классов и ее типы. Erlang/Elixir - своя реализация типов в beam-машинке.
Нативные языки - кто во что гаразд.

Когда использовать не-объектные языки. Ну не знаю. Я-бы опять уточнил - когда вам не стоит
внедрять пользовательские типы/классы. Вот я щас пишу утилиту для копирования данных
с продуктового ftp на тестовый. Там нужно файлы выбирать по датам. Код на scala. Состоит
из 1 объекта Main и порядка 40 штук функций. Пользовательских типов нет. Вот мне как-то
так хватило и этого. Если писать notebooks под Databricks то там тоже идет такой себе
стиль программирования где нет явной декларации классов.

Вобщем самый лучший язык - это тот который вы знаете. И профессионал может решить любую
задачу в своём языке всегда. Поэтому я-бы не стал париться рисованием таких табличек.
Тем более что она очень спорная и бесполезная.