По этой логике в любом языке есть «элементы ООП», и выражение «пишу с использованием ООП» <...> перестаёт иметь какую-либо описательную силу
Странная какая-то у вас логика.
На любом языке можно писать с использованием кодов возврата для обработки ошибок (верное утверждение) -- значит в любом языке есть коды возврата (подмена понятий; коды возврата есть в программе, в языке максимум поддержка), и выражение "пишу с использованием кодов возврата" перестает иметь описательную силу (неверное утверждение).
То, что на любом языке при желании можно писать с использованием ООП, ничего не говорит о том, будет ли эта возможность использована в каждом отдельно взятом случае. Соответственно выражение "пишу с использованием ООП" имеет еще какую описательную силу.
Но суть на самом деле была в обратном. Автор в процессе критики ООП как подхода ссылается на языки без поддержки ООП. Подвох в том, что отсутствие поддержки ООП в языке еще не означает отсутствие использования ООП в написанной на нем программе.
утверждение «классического ООП там нет» (с которым вы изначально спорили)
Автора спросили, действительно ли он вообще без ООП пишет, вот прям вообще без объектов. На что он ответил что пишет на Go в котором классического ООП нет, а есть только типы, к которым можно присобачить методы.
Я попытался заметить, что минимальная терминологическая и синтаксическая разница ничего не меняет и по сути это обычный класс. Классы, инкапсуляция, полиморфизм -- Go определенно использует элементы ООП и автор скорее всего тоже, просто не осознает этого.
"Классическое ООП" я вообще не трогал, потому что никто не знает что это такое.
можете привести пример наиболее популярного, на ваш взгляд, типизированного языка, для которого верно утверждение «классического ООП там нет»
Что такое классическое ООП? Что значит его там нет?
На любом популярном типизированном языке при должном желании можно писать с применением ООП.
Потому что раньше по-другому не умели. Поэтому инкапсуляция, наследование и полиморфизм считались базой и чуть ли не серебряной пулей. Но по факту оказалось, что те же проблемы куда удобнее решать другими способами.
Мне кажется вы несколько путаете причину и следствие.
Сначала кучу времени большинство разработчиков методом проб и ошибок приходили к одним и тем же решениям (в частности, группировка данных и методов, сокрытие деталей реализации, полиморфизм и т. п.), а потом уже это заметили и назвали ООП, функциональное программирование, паттерны проектирования и т. п.
Так что все все умели и до, и после, и даже во время. То, что в некоторых проектах и даже областях развели хайп и перегнули палку с применением -- ну так это просто локальные перекосы.
начинаем писать обычный сишный код, но завёрнут он не в функции и типы, а в классы и методы <...> Я вижу набор функций, которые принимают аналог джавовского "интерфейса" в качестве первого аргумента.
Вы излишне концентируетесь на синтаксисе. Главное смысл написанного, а не как это записано.
Выходит, C - это язык с полноценной поддержкой ООП?
Нет, в С нет поддержки ООП на уровне языка. Но это не мешает писать на нем с использованием ООП.
Пример с pthread выше как раз и должен был проиллюстрировать что отсутствие поддержки со стороны языка не отменяет использования соответствующих концепций.
Инкапсуляция, наследование и полиморфизм в том или ином виде есть в большинстве современных языков. Но никто не пытается абсолютно все проблемы решать только этими инструментами.
Так на кой черт вы всю статью перед этим пытаетесь абсолютно все проблемы решать только этими инструментами?
Только это первый и последний раз, когда мы пользуемся ООП как инструментом для описания поведения объектов реального мира.
Потому что это просто иллюстративный пример. В дальнейшем мы пользуемся ООП как инструментом для описания объектов, с которыми работает программа.
Мне в голову просто приходит пример ядра линукса, который написан на чистом C
Я вам сейчас наверное весь шаблон сломаю:
typedef unsigned long int pthread_t;
int pthread_create(pthread_t* thread, ...);
int pthread_setschedparam(pthread_t thread, int policy, const sched_param* param);
int pthread_join(pthread_t thread, void** retval);
...
Объект, методы, инкапсуляция. На чистейшем С.
Потому что ООП это не конкретные ключевые слова языка программирования, а общий подход к структурированию кода. Примерно так же, как функциальный подход это не только функции.
Так с освещением по сути то же самое. Зачем гиперреалистичное освещение в играх с упором на сюжет, механику и т. п.? Просят ли его покупатели или это просто то, в чем сейчас соревнуются разработчики, используя это как основной предмет маркетинга своего продукта?
Ну и моя личная придирка. Когда предмет изображён очень реалистично, но даже минимально с окружением не взаимодействует и на действия игрока не реагирует, то возникает чувство диссонанса и халтуры. Диссонанс потому что вот вроде бы должно создаваться ощущение реалистичного виртуального мира, но на поверку он оказывается картонным и условным. Халтура потому что ощущение примерно как от комикса, где персонажей нарисовали от руки, а на задник бахнули простенько обработанную фотографию, не заморачиваясь с прорисовкой деталей вручную.
Вам от этого конечно же легче не будет, но проект на C/C++ пятилетней давности, который не может собраться свежим тулчейном, вероятнее всего настолько криво написан, что он и пять лет назад по-хорошему собираться не должен был бы.
Lua в свое время и появился как альтернатива Tcl (со слов автора языка):
Однако у Tcl был непривычный синтаксис, не было хорошей поддержки описания данных, и запускался он только на платформах Unix. Мы не рассматривали Лисп или Scheme из-за их недружелюбного синтаксиса. Python был ещё во младенческом возрасте.
Иронично, что изначально Lua задумывался как
Из-за того, что большинство пользователей не было профессиональными программистами, языку следовало избегать замысловатого синтаксиса и семантики.
Но сейчас, когда C-подобные языки и Python по сути стали стандартом де-факто, Lua получился замысловатым в сравнении.
Таблицы вместо массивов/списков, индексация с 1, глобальные по умолчанию переменные и т. п. -- у всего этого есть своя логика, но в сложившейся ситуации всегда приходится делать оговорки или пояснять почему это работает не так, как везде.
Как я уже пытался отметить в нескольких комментариях выше, поскольку тот же Python больше не во младенческом возрасте, может быть проще прикрутить его (аналогично легковесный встраиваемый вариант) и не морочить людям голову.
У duktape конкретно -- пока не очень хорошо, примерно как когда-то давно было у Lua. Довольно странно, BitInt не выглядит как что-то очень уж сложное. Надо будет поглядеть, может получится разобраться и сочинить MR. Другие встраиваемые реализации могут отличаться, я не в курсе.
а что у js с целыми 64 битными?)
Как вы быстро от сомнений в размерах бинарного кода перескочили на выискивание отдельных огрех =). Причем у Python видимо не нашли ничего? =)
Конечно у любого варианта, включая Lua, будут какие-то свои особенности. Вопрос в том сколько их будет и насколько они необычные (специфичные).
Принципы работы и даже особенности поведения настолько распространенных языков как Python или JS по сути уже стали стандартом де-факто. Вероятность что пользователь уже знаком с этими языками и их нюансами, или что эти знания пригодятся ему где-то еще довольно высока. При всех достоинствах Lua, его особенности как правило слишком специфичные.
эмм легковесный python и js? а можно в цифрах, вот последний lua на x64 вест 300кб
pocketpy это ~400 кб x86_64. Там весь интерпретатор это один .c объемом ~20k LOC.
Само собой это не весь дистрибутив Python -- это сам язык, его builtins и несколько полезных модулей типа sys, math, json и т. п.
И что по скорости вызова как python/js функций из C так и C функций из python/js?
Честно говоря, даже не задумывался о производительности вызовов фукций между скриптом и хостом, где там вообще можно накосячить?
Сам по себе pocketpy примерно в 1.5 раза медленее lua, но при этом чуточку быстрее cpython. То есть соврешенно обычная производительность, к которой все привыкли.
Лично мое мнение -- если производительности скрипта уровня базовых lua/cpython/duktape не хватает, то с высокой долей вероятности вы что-то делаете не так, пытаясь сделать слишком многое силами скрипта.
Да, могут быть такие единичные сценарии когда объективно нужна вся возможная производительность именно в скриптовой части, но в таких случаях тем более надо внимательно взвешивать все варианты.
Судя по ближайшим планам основных дистрибутивов, X11 удалят из репозиториев ещё до того, как доделают Wayland.
Странная какая-то у вас логика.
На любом языке можно писать с использованием кодов возврата для обработки ошибок (верное утверждение) -- значит в любом языке есть коды возврата (подмена понятий; коды возврата есть в программе, в языке максимум поддержка), и выражение "пишу с использованием кодов возврата" перестает иметь описательную силу (неверное утверждение).
То, что на любом языке при желании можно писать с использованием ООП, ничего не говорит о том, будет ли эта возможность использована в каждом отдельно взятом случае. Соответственно выражение "пишу с использованием ООП" имеет еще какую описательную силу.
Но суть на самом деле была в обратном. Автор в процессе критики ООП как подхода ссылается на языки без поддержки ООП. Подвох в том, что отсутствие поддержки ООП в языке еще не означает отсутствие использования ООП в написанной на нем программе.
Автора спросили, действительно ли он вообще без ООП пишет, вот прям вообще без объектов. На что он ответил что пишет на Go в котором классического ООП нет, а есть только типы, к которым можно присобачить методы.
Я попытался заметить, что минимальная терминологическая и синтаксическая разница ничего не меняет и по сути это обычный класс. Классы, инкапсуляция, полиморфизм -- Go определенно использует элементы ООП и автор скорее всего тоже, просто не осознает этого.
"Классическое ООП" я вообще не трогал, потому что никто не знает что это такое.
Что такое классическое ООП? Что значит его там нет?
На любом популярном типизированном языке при должном желании можно писать с применением ООП.
Ну так о том и речь. В самом языке (на уровне синтаксиса) классов и методов нет, но это не мешает написать код с использованием классов и методов.
Я не думаю, что наличие UCS что-то меняет, это по сути просто синтаксический сахар.
Суть в том, что между
Буквально нет никакой смысловой разницы.
Не совсем так, в C возможно использование классов и методов.
Отсутствие поддержки на уровне языка не исключает использование как минимум отдельных элементов ООП.
Мне кажется вы несколько путаете причину и следствие.
Сначала кучу времени большинство разработчиков методом проб и ошибок приходили к одним и тем же решениям (в частности, группировка данных и методов, сокрытие деталей реализации, полиморфизм и т. п.), а потом уже это заметили и назвали ООП, функциональное программирование, паттерны проектирования и т. п.
Так что все все умели и до, и после, и даже во время. То, что в некоторых проектах и даже областях развели хайп и перегнули палку с применением -- ну так это просто локальные перекосы.
Вы излишне концентируетесь на синтаксисе. Главное смысл написанного, а не как это записано.
Нет, в С нет поддержки ООП на уровне языка. Но это не мешает писать на нем с использованием ООП.
Пример с pthread выше как раз и должен был проиллюстрировать что отсутствие поддержки со стороны языка не отменяет использования соответствующих концепций.
Зря вы думаете, что есть какая-то фундаментальная разница как именно будет записан метод у класса на конкретном языке.
Как будто если поместить запись функции внутрь фигурных скобочек или за их пределами, то это сделает код более ООП или менее ООП.
GTK опирается на GObject. Там буквально все ООП, просто написано на С и поэтому не так удобно как в других языках.
Любой сколь-нибудь крупный проект на С рано или поздно приходит к использованию элементов ООП.
Так на кой черт вы всю статью перед этим пытаетесь абсолютно все проблемы решать только этими инструментами?
Потому что это просто иллюстративный пример. В дальнейшем мы пользуемся ООП как инструментом для описания объектов, с которыми работает программа.
Я вам сейчас наверное весь шаблон сломаю:
Объект, методы, инкапсуляция. На чистейшем С.
Потому что ООП это не конкретные ключевые слова языка программирования, а общий подход к структурированию кода. Примерно так же, как функциальный подход это не только функции.
C++20 ещё.
Учитывая что у бубунты LTS сильно длиннее (минимум до 2029, платно -- до 2034), им возможно все равно какую версию брать за основу.
Осталось интерфейс командной строки нормальный сделать, а не вот это вот все =___=.
Так с освещением по сути то же самое. Зачем гиперреалистичное освещение в играх с упором на сюжет, механику и т. п.? Просят ли его покупатели или это просто то, в чем сейчас соревнуются разработчики, используя это как основной предмет маркетинга своего продукта?
Ну и моя личная придирка. Когда предмет изображён очень реалистично, но даже минимально с окружением не взаимодействует и на действия игрока не реагирует, то возникает чувство диссонанса и халтуры. Диссонанс потому что вот вроде бы должно создаваться ощущение реалистичного виртуального мира, но на поверку он оказывается картонным и условным. Халтура потому что ощущение примерно как от комикса, где персонажей нарисовали от руки, а на задник бахнули простенько обработанную фотографию, не заморачиваясь с прорисовкой деталей вручную.
Вам от этого конечно же легче не будет, но проект на C/C++ пятилетней давности, который не может собраться свежим тулчейном, вероятнее всего настолько криво написан, что он и пять лет назад по-хорошему собираться не должен был бы.
Lua в свое время и появился как альтернатива Tcl (со слов автора языка):
Иронично, что изначально Lua задумывался как
Но сейчас, когда C-подобные языки и Python по сути стали стандартом де-факто, Lua получился замысловатым в сравнении.
Таблицы вместо массивов/списков, индексация с 1, глобальные по умолчанию переменные и т. п. -- у всего этого есть своя логика, но в сложившейся ситуации всегда приходится делать оговорки или пояснять почему это работает не так, как везде.
Как я уже пытался отметить в нескольких комментариях выше, поскольку тот же Python больше не во младенческом возрасте, может быть проще прикрутить его (аналогично легковесный встраиваемый вариант) и не морочить людям голову.
У Javascript в целом -- все нормально, BigInt поддерживается всеми "полноразмерными" реализациями: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
У duktape конкретно -- пока не очень хорошо, примерно как когда-то давно было у Lua. Довольно странно, BitInt не выглядит как что-то очень уж сложное. Надо будет поглядеть, может получится разобраться и сочинить MR. Другие встраиваемые реализации могут отличаться, я не в курсе.
Как вы быстро от сомнений в размерах бинарного кода перескочили на выискивание отдельных огрех =). Причем у Python видимо не нашли ничего? =)
Конечно у любого варианта, включая Lua, будут какие-то свои особенности. Вопрос в том сколько их будет и насколько они необычные (специфичные).
Принципы работы и даже особенности поведения настолько распространенных языков как Python или JS по сути уже стали стандартом де-факто. Вероятность что пользователь уже знаком с этими языками и их нюансами, или что эти знания пригодятся ему где-то еще довольно высока. При всех достоинствах Lua, его особенности как правило слишком специфичные.
Duktape (встраиваемый Javascript) еще меньше, 150-200 кб кода.
pocketpy это ~400 кб x86_64. Там весь интерпретатор это один .c объемом ~20k LOC.
Само собой это не весь дистрибутив Python -- это сам язык, его builtins и несколько полезных модулей типа sys, math, json и т. п.
Честно говоря, даже не задумывался о производительности вызовов фукций между скриптом и хостом, где там вообще можно накосячить?
Сам по себе pocketpy примерно в 1.5 раза медленее lua, но при этом чуточку быстрее cpython. То есть соврешенно обычная производительность, к которой все привыкли.
Лично мое мнение -- если производительности скрипта уровня базовых lua/cpython/duktape не хватает, то с высокой долей вероятности вы что-то делаете не так, пытаясь сделать слишком многое силами скрипта.
Да, могут быть такие единичные сценарии когда объективно нужна вся возможная производительность именно в скриптовой части, но в таких случаях тем более надо внимательно взвешивать все варианты.
Питон отлично встраивается в микропроцессорные системы: https://micropython.org/
Но возникает вопрос зачем уезжать именно в страну с левосторонним движением.