Во-первых, не удивительно. Во-вторых, выяснилось, что не осознаете.
Что такое теплое и мягкое?
Это попытка сравнивать вещи из разных категорий. Например, когда сравнивают Java и emacs или C# и vim. Наверное, по каким-то критериям (типа размера дистрибутива или величины порога входа) их можно сравнивать, но его адекватность будет под большим сомнением.
Вы пытаетесь что-то сказать, но не можете
Аминь.
Не томите, здесь все свои.
Тут бы следовало подставить известную цитату из "Брата 1".
Сможете объяснить в чем неадекватность и какой контекст разговора. На всякий случай, для контекста "vcpkg install что-угодно".
Для людей, которые знакомы с vcpkg выражение "vcpkg install что-угодно" означает установку библиотек из репозитория vcpkg. Не более того. Вы же в своей статье писали про то, что вам для проекта нужен nlohman_json. Вот nlohman_json попадает в скоуп vcpkg, а bash -- нет.
Это то же самое, как пенять Nix-у, что через него нельзя под Windows установить Visual Studio.
В чем неадекватность?
Во-первых, в стравнении. Во-вторых, в нежелании читать и думать. Или в неспособность, тут пока рано делать выводы.
Как vcpkg решает проблему работы clang-format который мне нужен для ежедневной разработки на С++?
А он их и не решает. Он подтягивает библиотеки, которые нужны для компиляции и линковки вашего С++ного проекта. А clang-format таковой библиотекой не нуждается.
Лучше проверять, прежде чем писать. А то может случиться конфуз: На crates.io живет множество не-Rust проектов. Вы спрашивали про Qt? https://github.com/KDAB/cxx-qt/
Ну и где там нужный вам nlohman_json? Что ж вы, если вам нужно писать на C++ и вам так нравится cargo, не пользуетсь cargo для управления зависимостями?
То, что менеджерам зависимостей для других языков приходится таскать наработки из мира C и C++ не удивительно. Если на условном Rust-е все никак не могут написать свой Qt, то остается только паразитировать на уже готовом Qt и делать так, чтобы менеджер зависимостей мог этот Qt подтянуть к проекту на условном Rust-е (или Python-е).
А вот в мире С и С++ пока насрать на то, что делается на условном Rust-е, т.к. влияние этого пока что ничтожно.
nix и vcpkgs - это пакетные менеджеры. Мне как разработчику нужно от них одно: установка зависимостей проекта.
Вот как раз из-за того, что вы причисляете vcpkg в категорию "пакетного менеджера" (да еще наделяя термин "пакетный менеджер" смыслом из Unix-ного мира) и возникает проблема. vcpkg не является таковым в том смысле, который вам нужен.
И, что характерно, таковым он и не задумывался. По крайней мере, пока.
Кстати, называется vcpkg именно как vcpkg, а не vcpkgs. Так что вы и здесь демонстрируете незнание материала.
Давно уже не бывает "только C++".
Да что вы говорите... А мужики-то и не знают.
Опять вы ошиблись, написав "Непонятно осознаете ли вы, что сравниваете теплое с мягким." к моему "Я даже make и cmake не нашел в репозитории."
Я не ошибся.
Не знаете что vcpkg умеет приносить CMake?
Знаю. Под Windows, например, он может и Perl, и MSYS2 с bash-ем поставить. Но только для своих нужд, чтобы собрать из исходников библиотеку, которая вам потребовалась. Пользователю нет доступа к этим инструментам. Т.е. для пользователя он CMake "приносить" таки не умеет.
Кстати говоря, если работать с vcpkg в режиме манифеста и через CMake-овский TOOLCHAIN-файл, то никакие PATH вручную модифицировать не нужно.
Ну то есть просто увидели слово "vcpkg" и сразу приняли сторону.
Я не принимал сторону, а увидел, что в какой-то момент пошли:
a) неадекватные сравнения. Пример с vcpkg install bash неадекватен в контексте разговора про vcpkg. Он для таких вещей не предназначался; b) неадекватные требования к vcpkg: vcpkg решает проблемы только C++ (как cargo решает проблемы только Rust-а, а npm -- только JS). Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
И тут уж мне показалось, что в этих наших Интернетиках кто-то сильно не прав.
Простите, что вы говорите? Я в этой ветке обсуждения увидел сравнения только от автора статьи и сравнения эти, скажем так, весьма странные, мягко говоря. Эти сравнения и прокомментировал. И тут вы мне такой "начать вы решили с автора статьи"... Конечно, раз сравнения озвучивать начал автор статьи, то с кого же мне начинать?
vcpkg install что-угодно, господи. Хватит придумывать велосипеды из костылей.
Я здесь в упор не вижу утверждений, что vcpkg что-то может, а nix чего-то не может. Или наоборот.
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю. Мол, если нужны зависимости для C++ного проекта, то подтянуть их через vcpkg может быть удобнее, чем через nix. Но когда на такое замечание (пусть даже и крайне спорное) отвечают тем, что vcpkg не может установить bash в систему, то это выглядит очень и очень странно. Что, собственно, и вызвало мой комментарий.
Вы хотите продолжить в своем духе или узбагоитесь уже?
Возможно, я уже плохо вижу, но мне кажется, что автор комментария, на который я ответил, и автор статьи -- это один и тот же человек.
Кроме того, вся ветка обсуждения, в которой мы сейчас находимся, началась вовсе не со сравнения, а с того, что типа есть vcpkg и не нужно выдумывать костыли. И все, без сравнений. Сравнения начались как раз автором статьи.
То есть nix с vcpkgs можно сравнивать и это нормально
Я где-то такое говорил?
Повторю еще раз: nix и vcpkg -- это инструменты разных калибров, предназначенные для разных задач. Поэтому сранивать их (хоть nix с vcpkg, хоть vcpkg с nix) так себе идея. Отсюда и "теплое с мягким".
И когда автор статьи в комментарии говорит о том, что он не может сделать vcpkg install bash, то это свидетельствует о том, что он вообще не понимает что такое vcpkg, зачем он нужен и как используется. Посему такие сравнения с такими примерами выглядят как жалобы на неудобство закручивания гвоздей крестовой отверткой.
А я должен был знать все что Вы знаете чтобы знать что есть ООП и что есть не совсем ООП? По-моему это слишком. Перебор.
Заявления о "настоящести ООП" без наличия хоть сколько-нибудь существенной эрудиции в данном вопросе превращают вас в клоуна. В лучшем случае.
Это не прочиталось? Не понялось?
Это ерунда, а не попытка доказать то, что "ООП -- это теория". В области программирования достаточно много реально научных теорий, например, теория алгоритмов. Еще можно вспомнить про формальную верификацию. Которые к теореме Пифагора по своей доказательной силе гораздо ближе, чем ваши рассуждения.
Не надо себя распалять в воображении о числах.
Так это же вы заявляете о том, что x86 не может быть нормальным сервером. Только вот когда заходит речь о реально больших числах, например, о том, как Google обслуживает свой поиск или свой Gmail, так выясняется, что там x86-е в немерянных количествах. А не МФ от IBM.
Проблема в том, мил человек, что полноценно загрузить тысячи независимых х86-64 серверов гораздо сложнее чем один МФ.
Тысячи серверов загружают те, кто знает, умеет и имеет актуальную в этом необходимость. Например, Google, Amazon, Netflix, Microsoft, Yandex и т.д.
Кому это не нужно, берут то, что нужно под задачу.
Удивлюсь. Ибо: "Настоящим ООП языком был и остается только ST." -- это точная ваша цитата.
Просто я знаю хорошо SmallTalk и ничего про другие. Поэтому и ссылаюсь на него. Это плохо?
Да.
Что там у Вас в активе?
Из языков программирования? Из того, что использовалось для работы: C, C++, Java, D, Ruby. Из прочего, что выходило за рамки обычных HelloWorld-ов: Pascal, VB for Application, Eiffel, Python. Плюс еще полдюжины языков, на которых дальше HelloWorld-ов не пошло за ненадобностью или потому, что привкус не понравился: Modula-2, Ada, Scala, OCaml, Go, Rust, JavaScript, Erlang, Lua и всякая никому не известная экзотика, вроде Pike или Nice.
"Кроме того ни один язык заявляющий об ООП-ности, не сможет обогнать код с языка компилируемого в машинные команды."
Это заявление из категории "ничто не может двигаться быстрее света". Только вот свету и не нужно двигаться быстрее, он и так движется с максимальной скоростью. Нативные ОО-языки (вроде C++, Eiffel, D, Ada 95) и так компилируются непосредственно в нативный код. В отличии от динамических SmallTalk-ов с Ruby, в которых JIT может сработать, а может и нет.
Я ничего не знаю ни про один из перечисленных.
Но мнение о том, что "настоящий ООП только в SmallTalk" имеете. Поэтому чем дальше, тем большим клоуном выглядите.
Но здесь нет Java и .NET.
Вы просили те, что компилируются в нативный код. Java транслируется в байт-код и не обязательно этот байт-код будет JIT-ится. А .NET -- это и не язык программирования вообще, это платформа.
Вы этого не можете знать, поэтому Вы наговариваете
Так поделитесь: что такого производительного вы делали на SmallTalk и во сколько раз обгоняли на бенчмарках аналоги на нативных языках, типа C++.
Интересно почему?
Потому что из ваших слов за три киллометра несет отсутствием опыта сколько-нибудь серьзной разработки ПО.
Все что притягивается за уши не может быть эталоном
Это вы просто Eiffel-я не знаете. И Java. Чистые ОО-языки, между прочим. А в Eiffel еще крутая поддержка множественного наследования, которого в SmallTalk нет в принципе. Наверное, покруче, чем в C++.
Когда кругозор стремится к нулю, а опыта разработки на ОО языках и того меньше, то и SmallTalk эталоном покажется.
Уже пояснил.
Нет.
Не совместимы в том смысле что нет единого подхода к программированию.
"Единый подход" вдруг стал синонимом "компактного"? o_O Знаете, у меня уже цензурные слова заканчиваются, чтобы передавать степень моего опупевания от ваших "откровений".
Ок. Может. Та ERP система которую я сопровождал 25 лет будучи перенесена в облако стоит на отдельном серваке х86-64 с кучей коров (ударение на первое "о") и памяти.
Какие-нибудь количественные показатели у этой ERP есть? Ну там объем данных дохилиард терабайт, пропускная способность десятки миллионов RPS, поддержка одновременной работы трех миллиародов юзверей с пяти контенентов?
Горизонтальная масштабируемость это единственный метод на х86-64 чтобы ранить (от слова "run") сколько-нибудь объемную работу.
Именно. Для вертикального масштабирования есть ваши любимые МФ. Когда МФ обсераются на объемах, приходят десятки тысяч x86-х и все дела. Хотя, не удивлюсь, если в течении 5-10 лет эти самые десятки тысяч x86-х сменят сотни тысяч ARM-ов.
Что синтаксис там Паскале-подобный, а не вот это вот ifTrue и ifElse.
Нет никакой такой природы по которой код настоящих ООП языков не может быть достаточно быстрым.
Нет, поэтому C++ и Eiffel и не тормозят. А SmallTalk и Ruby динамичекие, у них тормоза в ДНК.
Много ли Вы знаете современных языков в ходу у программистов которые не имеют виртуальную машину для байт-кода?
Давайте подсчитаем: С, С++, Go, Rust, Swift + Objective-C, ObjectPascal, Ada. Можно для экзотики еще и Haskell с OCaml-ом добавить. Ну и Eiffel, раз уж экзотику в теме про ООП упомянули.
но читый ООП это далко не про производительность и соревнования по скорости.
Повторюсь: С++ и Eiffel прекрасно себя чувствуют в области производительности. А то, что вы со своим SmallTalk-ом никогда производительный код и не писали, так это не проблема ООП ни разу.
И как Вы могли видеть выше SmallTalk был признан как "чистый" т.е. правильный вариант имплементации ООП
Где я это мог видеть?
Кем он был "признан"? Что, где-то есть какой-то ISO или ANSI или ГОСТ стандарт на ООП, в котором приписано, что стандартной реализацией ООП является SmallTalk?
Вас не смущает, что ООП вообще и первый ОО-язык програмирования появились задолго до SmallTalk-80?
Надеюсь, вы не сольетесь в очередной раз и не разразитесь очередной порцией нелепостей, а ответите на поставленные вопросы.
Заодно, чтобы два раза не вставать: какими еще ОО-языками, кроме SmallTalk-а, вы пользовались?
В случае Смоллтолка не нащупали, его парадигма "вообще всё объекты и их методы, а общаемся мы сообщениями" (откуда же и название пошло) так же полезна при разработке, как поддержка 65535 мышей в ОС
Справедливости ради: в Ruby реализован тот самый ООП из SmallTalk, только в нормальном синтаксисе и исходники лежат в обычных файлах, а не в образах виртуальных машин, как это было в SmallTalk-овских средах.
Этот самый ООП с паре с синтаксисом Ruby дает удобные инструменты для реализации eDSL. Чем, собственно, Ruby и хорош (и за счет чего получился Ruby-On-Rails, а за счет RoR свою долю хайпа получил и Ruby).
Ценой же является медленное исполнение кода. Плюс, за счет динамики и возможности построения eDSL-ей под задачу, в большом объеме Ruby-нового кода сложнее разбираться, чем в коде на статически типизированных языках.
Так что я бы не сказал, что идеи SmallTalk-а умерли. Они трансформировались. Но с быстрым кодом, имхо, они не совместимы в принципе. Просто по своей природе. А автор статьи, как я понимаю, SmallTalk для формошлепства использовал, да еще и в режиме "в одно лицо, без коллег". В таких условиях ни скорость исполнения, ни ресурсоемкость, ни удобство коллективной работы в расчет можно и не брать.
Во-первых, вы же сами отказались от продолжения разговора.
Во-вторых, Хабр не тот ресурс где принято называть вещи своими именами. Самое мягкое, что я могу сделать -- это назвать глупость глупостью. Но и это, скорее всего, вызовет поток минусов в карму.
Опечатался: "А clang-format таковой библиотекой не
нуждаетсяявляется."Во-первых, не удивительно.
Во-вторых, выяснилось, что не осознаете.
Это попытка сравнивать вещи из разных категорий.
Например, когда сравнивают Java и emacs или C# и vim.
Наверное, по каким-то критериям (типа размера дистрибутива или величины порога входа) их можно сравнивать, но его адекватность будет под большим сомнением.
Аминь.
Тут бы следовало подставить известную цитату из "Брата 1".
Для людей, которые знакомы с vcpkg выражение "vcpkg install что-угодно" означает установку библиотек из репозитория vcpkg. Не более того. Вы же в своей статье писали про то, что вам для проекта нужен nlohman_json. Вот nlohman_json попадает в скоуп vcpkg, а bash -- нет.
Это то же самое, как пенять Nix-у, что через него нельзя под Windows установить Visual Studio.
Во-первых, в стравнении.
Во-вторых, в нежелании читать и думать. Или в неспособность, тут пока рано делать выводы.
А он их и не решает. Он подтягивает библиотеки, которые нужны для компиляции и линковки вашего С++ного проекта. А clang-format таковой библиотекой не нуждается.
Ну и где там нужный вам nlohman_json? Что ж вы, если вам нужно писать на C++ и вам так нравится cargo, не пользуетсь cargo для управления зависимостями?
То, что менеджерам зависимостей для других языков приходится таскать наработки из мира C и C++ не удивительно. Если на условном Rust-е все никак не могут написать свой Qt, то остается только паразитировать на уже готовом Qt и делать так, чтобы менеджер зависимостей мог этот Qt подтянуть к проекту на условном Rust-е (или Python-е).
А вот в мире С и С++ пока насрать на то, что делается на условном Rust-е, т.к. влияние этого пока что ничтожно.
Вот как раз из-за того, что вы причисляете vcpkg в категорию "пакетного менеджера" (да еще наделяя термин "пакетный менеджер" смыслом из Unix-ного мира) и возникает проблема. vcpkg не является таковым в том смысле, который вам нужен.
И, что характерно, таковым он и не задумывался. По крайней мере, пока.
Кстати, называется vcpkg именно как vcpkg, а не vcpkgs. Так что вы и здесь демонстрируете незнание материала.
Да что вы говорите... А мужики-то и не знают.
Я не ошибся.
Знаю. Под Windows, например, он может и Perl, и MSYS2 с bash-ем поставить. Но только для своих нужд, чтобы собрать из исходников библиотеку, которая вам потребовалась. Пользователю нет доступа к этим инструментам. Т.е. для пользователя он CMake "приносить" таки не умеет.
Кстати говоря, если работать с vcpkg в режиме манифеста и через CMake-овский TOOLCHAIN-файл, то никакие PATH вручную модифицировать не нужно.
Я не принимал сторону, а увидел, что в какой-то момент пошли:
a) неадекватные сравнения. Пример с
vcpkg install bashнеадекватен в контексте разговора про vcpkg. Он для таких вещей не предназначался;b) неадекватные требования к vcpkg: vcpkg решает проблемы только C++ (как cargo решает проблемы только Rust-а, а npm -- только JS). Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
И тут уж мне показалось, что в этих наших Интернетиках кто-то сильно не прав.
Простите, что вы говорите? Я в этой ветке обсуждения увидел сравнения только от автора статьи и сравнения эти, скажем так, весьма странные, мягко говоря. Эти сравнения и прокомментировал. И тут вы мне такой "начать вы решили с автора статьи"... Конечно, раз сравнения озвучивать начал автор статьи, то с кого же мне начинать?
Вот этот комментарий полностью:
Я здесь в упор не вижу утверждений, что vcpkg что-то может, а nix чего-то не может. Или наоборот.
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю. Мол, если нужны зависимости для C++ного проекта, то подтянуть их через vcpkg может быть удобнее, чем через nix. Но когда на такое замечание (пусть даже и крайне спорное) отвечают тем, что vcpkg не может установить bash в систему, то это выглядит очень и очень странно. Что, собственно, и вызвало мой комментарий.
Вы хотите продолжить в своем духе или узбагоитесь уже?
Возможно, я уже плохо вижу, но мне кажется, что автор комментария, на который я ответил, и автор статьи -- это один и тот же человек.
Кроме того, вся ветка обсуждения, в которой мы сейчас находимся, началась вовсе не со сравнения, а с того, что типа есть vcpkg и не нужно выдумывать костыли. И все, без сравнений. Сравнения начались как раз автором статьи.
Я где-то такое говорил?
Повторю еще раз: nix и vcpkg -- это инструменты разных калибров, предназначенные для разных задач. Поэтому сранивать их (хоть nix с vcpkg, хоть vcpkg с nix) так себе идея. Отсюда и "теплое с мягким".
И когда автор статьи в комментарии говорит о том, что он не может сделать
vcpkg install bash, то это свидетельствует о том, что он вообще не понимает что такое vcpkg, зачем он нужен и как используется. Посему такие сравнения с такими примерами выглядят как жалобы на неудобство закручивания гвоздей крестовой отверткой.В смысле того, что сравниваются инструменты, скажем так, разных калибров, предназначенные для разных задач.
Например, очень странная претензия в комментарии:
Интересно, а в cargo есть Boost или Qt, или тот же npm? Получится ли при разработке на Rust использовать JS, TS и Python без костылей?
Непонятно осознаете ли вы, что сравниваете теплое с мягким.
Заявления о "настоящести ООП" без наличия хоть сколько-нибудь существенной эрудиции в данном вопросе превращают вас в клоуна. В лучшем случае.
Это ерунда, а не попытка доказать то, что "ООП -- это теория". В области программирования достаточно много реально научных теорий, например, теория алгоритмов. Еще можно вспомнить про формальную верификацию. Которые к теореме Пифагора по своей доказательной силе гораздо ближе, чем ваши рассуждения.
Так это же вы заявляете о том, что x86 не может быть нормальным сервером. Только вот когда заходит речь о реально больших числах, например, о том, как Google обслуживает свой поиск или свой Gmail, так выясняется, что там x86-е в немерянных количествах. А не МФ от IBM.
Тысячи серверов загружают те, кто знает, умеет и имеет актуальную в этом необходимость. Например, Google, Amazon, Netflix, Microsoft, Yandex и т.д.
Кому это не нужно, берут то, что нужно под задачу.
Удивлюсь. Ибо: "Настоящим ООП языком был и остается только ST." -- это точная ваша цитата.
Да.
Из языков программирования? Из того, что использовалось для работы: C, C++, Java, D, Ruby. Из прочего, что выходило за рамки обычных HelloWorld-ов: Pascal, VB for Application, Eiffel, Python. Плюс еще полдюжины языков, на которых дальше HelloWorld-ов не пошло за ненадобностью или потому, что привкус не понравился: Modula-2, Ada, Scala, OCaml, Go, Rust, JavaScript, Erlang, Lua и всякая никому не известная экзотика, вроде Pike или Nice.
Это заявление из категории "ничто не может двигаться быстрее света". Только вот свету и не нужно двигаться быстрее, он и так движется с максимальной скоростью. Нативные ОО-языки (вроде C++, Eiffel, D, Ada 95) и так компилируются непосредственно в нативный код. В отличии от динамических SmallTalk-ов с Ruby, в которых JIT может сработать, а может и нет.
Но мнение о том, что "настоящий ООП только в SmallTalk" имеете. Поэтому чем дальше, тем большим клоуном выглядите.
Вы просили те, что компилируются в нативный код. Java транслируется в байт-код и не обязательно этот байт-код будет JIT-ится. А .NET -- это и не язык программирования вообще, это платформа.
Так поделитесь: что такого производительного вы делали на SmallTalk и во сколько раз обгоняли на бенчмарках аналоги на нативных языках, типа C++.
Потому что из ваших слов за три киллометра несет отсутствием опыта сколько-нибудь серьзной разработки ПО.
Это вы просто Eiffel-я не знаете. И Java. Чистые ОО-языки, между прочим.
А в Eiffel еще крутая поддержка множественного наследования, которого в SmallTalk нет в принципе. Наверное, покруче, чем в C++.
Когда кругозор стремится к нулю, а опыта разработки на ОО языках и того меньше, то и SmallTalk эталоном покажется.
Нет.
"Единый подход" вдруг стал синонимом "компактного"? o_O
Знаете, у меня уже цензурные слова заканчиваются, чтобы передавать степень моего опупевания от ваших "откровений".
Какие-нибудь количественные показатели у этой ERP есть? Ну там объем данных дохилиард терабайт, пропускная способность десятки миллионов RPS, поддержка одновременной работы трех миллиародов юзверей с пяти контенентов?
Именно. Для вертикального масштабирования есть ваши любимые МФ. Когда МФ обсераются на объемах, приходят десятки тысяч x86-х и все дела. Хотя, не удивлюсь, если в течении 5-10 лет эти самые десятки тысяч x86-х сменят сотни тысяч ARM-ов.
Цитаты из гугла -- это почти как надписи на заборе.
Это какое-то скаральное знание?
Я вот тоже знаю много страшных слов. Но не считаю что настоящий ООП только в SmallTalk. И? Кто меня опровергнет?
Оно и заметно.
Все чудесатее и чудесатее. Было сильное подозрение, что вы кроме SmallTalk-а ничего и не пробовали. Отсюда и такой пиетет.
А тут еще и выясняется, что вас и программистом то назвать можно с натяжкой.
Что синтаксис там Паскале-подобный, а не вот это вот ifTrue и ifElse.
Нет, поэтому C++ и Eiffel и не тормозят. А SmallTalk и Ruby динамичекие, у них тормоза в ДНК.
Давайте подсчитаем: С, С++, Go, Rust, Swift + Objective-C, ObjectPascal, Ada. Можно для экзотики еще и Haskell с OCaml-ом добавить. Ну и Eiffel, раз уж экзотику в теме про ООП упомянули.
Повторюсь: С++ и Eiffel прекрасно себя чувствуют в области производительности. А то, что вы со своим SmallTalk-ом никогда производительный код и не писали, так это не проблема ООП ни разу.
И почему я не удивлен?
Где я это мог видеть?
Кем он был "признан"? Что, где-то есть какой-то ISO или ANSI или ГОСТ стандарт на ООП, в котором приписано, что стандартной реализацией ООП является SmallTalk?
Вас не смущает, что ООП вообще и первый ОО-язык програмирования появились задолго до SmallTalk-80?
Надеюсь, вы не сольетесь в очередной раз и не разразитесь очередной порцией нелепостей, а ответите на поставленные вопросы.
Заодно, чтобы два раза не вставать: какими еще ОО-языками, кроме SmallTalk-а, вы пользовались?
Я даже могу подсказать почему.
Из-за ваших категоричных и бездоказательных утверждений из категории (простите, я своим текстом, лень точные цитаты выискивать):
настоящий ООП только в SmallTalk;
ООП -- это такая же теория, как и теорема Пифагора;
ООП и компактный нативный код не совместимы;
x86-64 сервак даже базу данных не потянет.
Справедливости ради: в Ruby реализован тот самый ООП из SmallTalk, только в нормальном синтаксисе и исходники лежат в обычных файлах, а не в образах виртуальных машин, как это было в SmallTalk-овских средах.
Этот самый ООП с паре с синтаксисом Ruby дает удобные инструменты для реализации eDSL. Чем, собственно, Ruby и хорош (и за счет чего получился Ruby-On-Rails, а за счет RoR свою долю хайпа получил и Ruby).
Ценой же является медленное исполнение кода. Плюс, за счет динамики и возможности построения eDSL-ей под задачу, в большом объеме Ruby-нового кода сложнее разбираться, чем в коде на статически типизированных языках.
Так что я бы не сказал, что идеи SmallTalk-а умерли. Они трансформировались. Но с быстрым кодом, имхо, они не совместимы в принципе. Просто по своей природе. А автор статьи, как я понимаю, SmallTalk для формошлепства использовал, да еще и в режиме "в одно лицо, без коллег". В таких условиях ни скорость исполнения, ни ресурсоемкость, ни удобство коллективной работы в расчет можно и не брать.
Теорема Пифагора имеет математически выверенное доказательство.
Можете предъявить что-то подобное для "ООП"?
Вы бы лучше объяснили читателям зачем вообще сравнивать ООП в разных языках?
Ну вот в ObjectPascal ООП реализовано одним способом.
А в SmallTalk другим.
И что?
Вы будете делать выбор между ObjectPascal и SmallTalk на основании различий в их ООП? Реально?
Во-первых, вы же сами отказались от продолжения разговора.
Во-вторых, Хабр не тот ресурс где принято называть вещи своими именами. Самое мягкое, что я могу сделать -- это назвать глупость глупостью. Но и это, скорее всего, вызовет поток минусов в карму.