23.02.1993 был создан Руби

Чем меня всегда поражали армиефилы, так это системой мышления «я — идиот, значит и остальные такие же идиоты и надо их лечить».

Именно то.

Я совсем не об этом говорил. "Описать систему" — это не то же, что и "решить задачу". Корректное решение задачи может быть каракулями на куске туалетной бумаги, которые даже сам автор через день не сможет понять. "Описание" — это то, что делает предмет понятным. И код на выразительном ЯП может таким описанием быть. Машинный код — вряд ли.

Так же, как и переход к ООП от классического процедурного программирования.

Ок. Всё можно реализовать классическим процедурным программированием, ООП нужно для упрощения поддержки и разработки. Согласен, хотя мне и хотелось увидеть пример необходимости ООП, вдруг я его просто не знаю.

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

24 февраля, переведи ruby-list:15977 или открой английскую версию FAQ

Я совсем не об этом говорил. «Описать систему» — это не то же, что и «решить задачу»

Вообще-то, изначально было утверждение в виде запроса: «Приведи пример того, что нельзя сделать в другой парадигме». Никаких «описаний» и прочих виляний в стороны.

Да, на процедурном подходе можно сделать всё, что и на объектом. Также, как и на машинных кодах можно сделать всё, что на ЯВУ. И?

Согласен, хотя мне и хотелось увидеть пример необходимости ООП, вдруг я его просто не знаю.

Вот, самое свежее с ЛОР'а: Работа с последовательностями в разных языках (комментарий)

При процедурном подходе это всё будет сильно более громоздко. И это ещё тупой пример, без демонстрации наследования. Как только появляется задача наследования — всё, в процедурном программировании начинается слив воды.

Вон, свой фреймворк 12 лет назад я именно процедурным закладывал. После того, как уткнулся в пределы процедурного подхода и перевёл понемногу на объектные рельсы, львиная доля кода сократилась в 5..10 раз. И скорость разработки стала в 10-20 раз выше :)

В то же время есть такой подход как метапрограммирование, который также упрощает поддержку и разработку.

Метапрограммирование и ООП ортогональны и нисколько не мешают друг другу. Метапрограммирование + ООП — это вообще термоядерная смесь :)

Но метапрограммирование без ООП обычно менее эффективно, чем ООП без метапрограммирования. Утверждаю это как многолетний Forth-программер :)

ООП, которое навязывает свой неестественный язык и само по себе является фабрикой проблем.

Можно озвучить проблемы, которые само по себе порождает ООП? А то я, вот, за последние 20+ лет только с обратным сталкиваюсь. Когда ООП позволяет разобраться с массой проблем, повышая скорость разработки, надёжность, лёгкость поддержки и расширения.

«Приведи пример того, что нельзя сделать в другой парадигме». Никаких «описаний» и прочих виляний в стороны.

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

Вот, самое свежее с ЛОР'а

Ну и где там преимущества ООП? " ->" вместо передачи одного параметра в функцию?

Как только появляется задача наследования — всё, в процедурном программировании начинается слив воды.

А так ли уж оно нужно? Для описания алгоритмов полезнее параметрический полиморфизм.

Но метапрограммирование без ООП обычно менее эффективно, чем ООП без метапрограммирования

Благодаря какому же волшебству, мне всё интересно?

Можно озвучить проблемы, которые само по себе порождает ООП?

Я выше называл уже две. 1) Неестественность понятия "объект" для задач программирования, где естественными являются понятия алгоритма и структуры данных. Нужно подгонять всё, что движется, под понятие объекта. 2) Скрытие побочных эффектов. Вызов метода — бросание камушка в чёрный ящик. Чистая функция, что бы она ни делала — простое отображение.

Ну и где там преимущества ООП? " ->" вместо передачи одного параметра в функцию?

А теперь представь, что параметр может быть разного типа. Ну, например, draw() для квадрата, окружности и полигона.

Будешь в функции делать switch по типу?

Благодаря какому же волшебству, мне всё интересно?

Благодаря наследованию и инкапсуляции, конечно же.

Неестественность понятия «объект» для задач программирования

Это пока набор слов, а не аргумент. Я не вижу тут неестественности. В чём неестественность объекта «сообщение форума»?

Нужно подгонять всё, что движется, под понятие объекта.

Зачем? Можно пример, когда под понятие объекта приходится подгонять?

Скрытие побочных эффектов

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

И, как раз, полная инкапсуляция и помогает хорошо от побочных эффектов. Если метод работает только со своими данными — это сильно ограничивает его возможности напортачить, как в случае процедурного программирования, когда параметр функции тащит с собой глобальные сущности.

Будешь в функции делать switch по типу?

Зачем, есть же ad hoc полиморфизм.

Что будет, если в наш switch для «окружности», «квадрата» и «полигона» прибудет сущность «эллипс»?

ООП вроде тоже не умеет материализовать несуществующие реализации. Но это к побочным эффектам не относится.

И, как раз, полная инкапсуляция и помогает хорошо от побочных эффектов.

/0

В чём неестественность объекта «сообщение форума»?

В том, что его не существует. Ни на одном из этапов работы MVC-приложения, коим является форум, такой объект нигде не встречается. Есть вполне реальные строчка в базе, буферная структура данных в виде экземпляра модели, в которую текст и информация о сообщении грузятся из этой строчки, ещё как минимум одна буферная структура данных при выводе контроллером в шаблон и, наконец, контейнер типа <article class="msg">, в котором мы и наблюдаем выведенное сообщение. Всё это реализуемо и без ООП.

Зачем, есть же ad hoc полиморфизм.

Полиморфизм без ООП? Извращение же. Да ещё и не 100% заменяющее. По сути в итоге получится то же самое ООП, только кривое и самопальное.

ООП вроде тоже не умеет материализовать несуществующие реализации

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

А так ли уж оно нужно? Для описания алгоритмов полезнее параметрический полиморфизм.

Те же яйца, вид сбоку.

Неестественность понятия «объект» для задач программирования, где естественными являются понятия алгоритма и структуры данных.

Ты еще скажи, что-нибудь типа «неестественность понятия объект для мозга человека, где естественными являются понятия алгоритма и структуры данных». ЯП - они для того, чтобы 99% времени на них было удобно выражать свои мысли. И только на 1% для того, чтобы их исполняла машина. И вот человеку как раз понятие объекта очень даже удобно.

Да ещё и не 100% заменяющее.

Всё ок. Не нужно заменять ненужно.

По сути в итоге получится то же самое ООП

ООП не получается, поскольку тайпклассы никакого отношения к объектам не имеют.

только кривое и самопальное.

Эк вы сходу.

Если в ООП нужно расширить имеющуюся систему, мы просто пишем новый объект.

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

Те же яйца, вид сбоку.

Щито?

И вот человеку как раз понятие объекта очень даже удобно.

Для чего удобно?

Щито?

http://ru.wikipedia.org/wiki/Полиморфизм_(программирование)#.D0.92_.D0.BE.D0....

Для чего удобно?

Для того, чтобы думать.

И вот человеку как раз понятие объекта очень даже удобно.

ну да, именно поэтому паскаль все осваивают в школе на раз, а объекты и прочий полиморфизм со скрипом осваивают в универах

http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

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

объекты для того, чтобы думать.

// Шутка про Чапаева и картошку.

ну да, именно поэтому паскаль все осваивают в школе на раз, а объекты и прочий полиморфизм со скрипом осваивают в универах

Паскаль? Все? В школе? Простите, вы либо не по-русски говорите, либо на другом глобусе живёте.

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

Если ты отличаешь compile-time и run-time связывание, медицина тут бессильна.

Не распарсил.

Слова пропускаю. «Если _не_ отличаешь»

ну, я не беру в расчет школы для умственно отсталых

А что, параметрический полиморфизм в рантайме не может работать? Может. Не понял суть претензии.

Испытал влияние: Perl, Smalltalk, Eiffel, Ada, Lisp[1], Python, Dylan, CLU (англ.), C++

А Мацумото часто пишет что это еще и shell\sh\bash.

И чем это будет отличаться от «виртуальные методы позволяют с кучей boilerplate кода и оверхеда»? Та же множественная динамическая диспетчерезация, вид сбоку.

От первого, по крайней мере, удаётся избавиться в любом случае. В статическом случае ещё и от второго. С виртуальными методами это не пройдёт.

Ну здрасти. Если компилятор может точно определить ран-тайм тип объекта, он заменяет вызовы через vtable на прямые.

Если компилятор может точно определить ран-тайм тип объекта

Компилятор про рантайм ничего знать не может. Если имелось в виду "если тип известен в compile-time": ну так в этом случае не может быть и полиморфизма.

Компилятор про рантайм ничего знать не может.

Если видит вызов конструктора, то может.

Почему я занимаюсь объяснением очевидных вещей, а?

Если видит вызов конструктора, то может.

Ок. У нас есть такая имитация параметрического полиморфизма:

int foo(IParameter* a);

Как компилятор здесь может убрать вызов через vtable? Создать специализированную версию этой функции, если "виден конструктор"? А если foo в другой единице трансляции? Это неслабая такая глобальная оптимизация, что-то мне не верится, что компиляторы в неё могут. Пригодился бы пруфлинк.

А при чем тут параметрический, если я про полиморфизм в реализации ООП?

Кто-то говорил:

Те же яйца, вид сбоку.

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

А то, что в паре простейших синтетических примеров компилятор может убрать виртуальный вызов, это, знаете ли, к полиморфизму отношения не имеет, да и никому не интересно: руками эта "оптимизация" выполняется с тем же успехом.

Так вы мне расскажите, через какое место вы будете обеспечивать «полиморфизм на шаблонах» в рантайме.

Все эти рассуждения про сферических коней очень интересны ровно до тех пор, пока мы не упираемся в банальный key_press(widget). И тут внезапно «куча boilerplate кода и оверхеда» оказывается совсем не boilerplate.

Так вы мне расскажите, через какое место вы будете обеспечивать «полиморфизм на шаблонах» в рантайме.

Я не говорил "полиморфизм на шаблонах", я говорил "параметрический полиморфизм", а шаблоны привёл как пример. Не шаблонами едиными.

ну чо, завести еще один топик _на_сегодня_ по той же теме? ;)

современные естественные языки (и соответствующий стиль мышления людей) - лучше всего ложатся на ООП. Этого недостаточно? ООП-подобный язык можно так извратить, что он станет похожим на обычный английский, например. И если это типа «бред, программисту не обязательно думать как быдлу», то, например, Кнут тоже думал о программировании на естественном языке.

В том, что его не существует. Ни на одном из этапов работы MVC-приложения, коим является форум, такой объект нигде не встречается.

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

современные естественные языки

Булочка.съесть vs. съесть булочку.

и соответствующий стиль мышления людей

Я и говорю, что думать об алгоритмах и структурах данных как о картофелинах заманчиво, но всё равно это излишнее усложнение.

помойму современный человек не умеет думать об алгоритмах как о first-class. Например, заходя в магазин, социально-приемлемо различать типы яблок («красенькое», «зелененькое»). А вот типы действий («дойти от А до Б маршрутом Х», «дойти от А до Б маршрутом Y») — это уже нечто сверхъестественное. Когда я пытаюсь объяснить, что маршрут 1 - это что-то типа маршрута 2, только с вот такими аспектами, «нормальные люди» обычно смотрят на меня как на идиота, поэтому я так стараюсь не делать. Алгоритмов нет в Реальном Мире. Их нельзя пощупать, потрогать. Соответственно, user-friendly язык должен подразумевать, что пользователь не может думать алгоритмами, и думает алгоритмами вместо него (иногда спрашивая подсказки).

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

все выше имхо

Так же устроены все паттерны, которые «думают» вместо программиста.

Мне-то казалось, что паттерны только для архитектуры используются, а не для алгоритмов. Как далеко прогресс ушёл.

Но даже чтобы использовать готовые алгоритмы ООП не обязателен. Всякие BLAS'ы и иже с ними ещё на процедурном фортране были.

я был qa в проекте, предназначенном для того, чтобы высокопараллельные приложения можно было кодить мышкой в Эклипсе без участия мозга -) Накидываешь в графический редактор «серверов», «алгоритмов», «источников», «приемников», итп, соединяешь все это стрелочками, нажимаешь кнопку «запустить», а оно дальше как-то пытается реализовать то, что ты там понарисовал

Параллельные в смысле parallelism, а не concurrency? И что за параллелизм: SMP, distributed?

И что вышло? Я знаком с парой разработчиков cluster openmp (нечто похожее, только программируют там не мышкой а прагмами), у них весьма неэффективно получилось по сравнению с тёплой ручной работой.

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

работало оно. не очень хорошо, но работало. что потом с ним стало - не знаю.

а у тебя - нельзя.

Можно, но зачем?

Соответственно, user-friendly язык должен подразумевать, что пользователь не может думать алгоритмами

Пользователь ≠ программист. А какой же он нафиг программист, если не может думать алгоритмами?

user-friendly язык

Вообще нонсенс.

там новость про 2.0 есть, например