Здравствуйте, Wolverrum, Вы писали:

W>SV:
W>

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

SV.>>...и это невероятно печально.
W>Это невероятно нормально, потому что:
W>ООП — это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

Это невероятно печально потому, что нет ничего жальче инвалидов, которые в припадке гордыни повыкидывали костыли и, хромая, забрели в болото. Именно это я и наблюдаю, особенно в последнее время. Пузыри уже пускают, но ООП все не для них. Я, кстати, сам инвалид. Поэтому и отношусь трепетно к своим костылям. Никакого высокомерия.

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

W>ЗЫ Вот Вы так о духе ООП категорично рассуждаете, а свой сайт на php написан... И тормозит. Если первое простительно то второе на фоне рассуждений кажется неприемлемым.

Тут все просто: хостер "переехал в облако", как они сейчас говорят. Короче, перепаковал круги в многоугольнике очередным высокоэффективным способом, и сейчас таких как я там напихано, как селедок в бочке. Нужно попросту перейти к другому, что я и сделаю.

Здравствуйте, pkl, Вы писали:

pkl>Какая цель топика? Повозмущаться существованием в природе всяких уродов? Ну дальше что? Сам без греха? А ну ка быстро кинул в меня стотонный камень.

Цель — послушать вас. Узнать, согласны, не согласны.

Здравствуйте, Sinclair, Вы писали:

pkl>>Человек мыслит просто и ясно объектами,
S>Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП?

Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
1) Создания абстракций с формальным описанием внешних свойств
2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

Здравствуйте, AndrewVK, Вы писали:


AVK>Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

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

Здравствуйте, kittown, Вы писали:

K>Уточню — сложные иерархии строятся на этапе обучения и освоения.

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

Здравствуйте, SV., Вы писали:

SV.>

SV.>Допонятийная [стадия] — это начальный этап развития мышления у ребенка, когда последнее имеет иную, чем у взрослых, организацию. Суждения детей — единичные, о данном конкретном предмете. При объяснении чего-либо все сводится ими к частному, знакомому. Большинство суждений — по сходству или по аналогии, поскольку на этой стадии главную роль в мышлении играет память. Самая ранняя форма доказательства — пример. Учитывая такую особенность мышления ребенка, когда его убеждают или что-то ему объясняют, необходимо подкреплять свою речь наглядными примерами.

Плохой пример. Есть более толковый пример — автнономная речь ребенка, т.е. речь в которой вообще нет понятий, а слова имеют указательно-описательную функцию. Очень интересный феномен кстати говоря.

Здравствуйте, Sinclair, Вы писали:

I>>Я хочу увидеть робота на вычметодах,всякие там дифуры, новье-стокса и что бы это могло коннектиться к сайтами и там играть. ООП позволяет это почти что на раз. А вычметоды и дифуры ?
S>Не понимаю, зачем вы хотите Навье-Стокса для игры в Баккара.

Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.

S>А вот робота на Фортране я себе представляю вполне хорошо, несмотря на то, что фортран был разработан как раз для вычметодов, и никаким ООП там даже близко не пахнет. Вы думаете, робот на Фортране будет хуже играть в баккара, чем на Java?

Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

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

Здравствуйте, SV., Вы писали:

SV.>Что касается "чтоб потом это можно было поддерживать". У вас новые кадры подключаются к проекту? Бывает такое? Или, может быть, новые кадры используют библиотеки/API, которые вы пишете? Если да, то ООП помогает им быстрее соотнести ваш код с решаемыми им задачами. Не больше и не меньше. Избавляться от копипаста оно определенно не помогает.
А почему именно ООП помогает? Я же говорю, что помогать может не только ООП, но и ФП, АОП, Декларативный П, и даже Императивный П. В проекте много различных задач, для одних лучше один подход, для других другой. И рулит именно комбинация подходов. Применять же ООП вообще ко всему слепо, просто потому, что оно ООП и оно рулит — путь к провалу проекта.

Здравствуйте, Ikemefula, Вы писали:

I> Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.
Не вижу ничего аналогичного. Уравнение Навье-Стокса и ООП не являются членами одного и того же понятийного ряда. С тем же успехом можно было предложить построить робота для карточной игры на деепричастиях.

I>Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

I>По моему разумению большая половина его текса просто тавтология, ибо, подставив вместо ООП что угодно получаем ровно тоже что и было.
Надо улучшать разумение. Потому как половина не может быть большей, а подстановка чего угодно вместо ООП, хоть и сохраняет формальную истинность высказывания, прекращает его действие как аргумента против другого высказывания "ООП хорошо моделирует любую действительность".

Здравствуйте, 0x7be, Вы писали:

0>Верно, ООП предлагает способ формализовать абстракции.
0>Сомнительно утверждение, что это лучший способ формализовать наши абстракции, чем предлагаемые другими парадигмами программирования.

Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."

>>>Вопрос, кстати, осложняется тем, что ООП само по себе определено крайне нечетко и существует в целой куче разных разновидностей.
I>>ООП без абстракций это новость
0>Нуууу... а как быть с бесклассовыми вариантами ООП?

Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."

0>>>По мне это самый сомнительный момент в аргументации. Как можно с уверенностью заявлять о гомоморфизме чего-то нечеткого с чем-то непонятным?
I>>Есть несколько теорий мышления.
0>Очень хорошо, с какой из них проводилось сравнение?

Точное название я не помню Все книги по этому вопросу дома и где то полгода я в них не заглядывал.

0>Вообще, кстати, вопрос интересный — есть ли научное подкрепление это мантры про людей, которые мыслят объектами?

Спроси у автора этой мантры а не у меня, я вроде как говорил про понятия и абстракции а не объекты.

0>>>тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.
I>>"отупления" нет. Есть снижение среднего уровня за счет притока свежих и как правило низкоквалифицированых специалистов. Нужно только понимать, что низкоквалифицированые они как программисты, а как специалисты в другой области наоборот, бывает очень даже высококвалифицированые.
0>Но нет снижения *среднего уровня* трудных для понимания возможностей ЯП.

I>>Примерно как в шахматах — первый разряд, кмс, мс, гроссмейстер
0>Ну это так... абстрактно

Результаты в соревнованиях можно заменить результатами по всем проектам.

0>Я пока знаю одну характеристику, неплохо кореллирующую: опыт интенсивной работы программистом в годах.
0>Но и то не всегда надежно.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.
Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике. И там абстракции находятся в более сложных отношениях, чем отношения иерархии.
Имхо, ООП успешно не потому, что оно как-то особенно похоже на привычный нам способ выделения абстракций, а по более банальным причинам: производственное удобство. Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

Здравствуйте, Sinclair, Вы писали:

M>>По крайней мере ООП может быть использована для лучшей читабельности. Это и декомпозиция и уменьшение связанности и т.п.
S>А может быть использована для худшей читабельности. Потому что в чистом ООП решение квадратного уравнения вы устанете читать, и уж тем более запаритесь понимать, как оно работает.

Если целая программа написана чтобы решать задачу для пятого класса (!), легко может оказаться, что сложность инструмента перевешивает сложность задачи. На то он и пятый класс. Непонятно только, зачем это делать.

Что, если немного приблизить сложность задачи к той, которую мы видим в реальным проектах? Скажем, надо решить квадартное уравнение... с точностью до i-ого знака, i может быть любым (в разумных пределах). И арифметику желательно сделать реюзабельной, чтобы студенты из соседнего отдела на ее основе написали решатель линейного уравнения. Вот теперь и поговорим про нечитабельность оошного кода.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>> Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.
S>Не вижу ничего аналогичного. Уравнение Навье-Стокса и ООП не являются членами одного и того же понятийного ряда. С тем же успехом можно было предложить построить робота для карточной игры на деепричастиях.

Тебя эта разница не смутила когда ты ему оценку ставил. Робот на деепричастиях — это такая же аналогия как и моя

I>>Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

I>>По моему разумению большая половина его текса просто тавтология, ибо, подставив вместо ООП что угодно получаем ровно тоже что и было.
S>Надо улучшать разумение. Потому как половина не может быть большей, а подстановка чего угодно вместо ООП, хоть и сохраняет формальную истинность высказывания, прекращает его действие как аргумента против другого высказывания "ООП хорошо моделирует любую действительность".

Я чет нигде в треде не видел вот такого утверждения, что де ООП хорошо моделирует любую действительность, ноборот, адепты ООП только и говорят о том, что ООП не надо совать в любую дырку и тд и тд.
Даже в исходном сообщении про ФП и ООП "Они отлично уживаются, просто потому, что нужны в разных местах."

Здравствуйте, Философ, Вы писали:

Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.

И не придумаете, поскольку это простейшая функция (добавить NaN или исключение по вкусу).

void CalcQuadraticEquation(double a, double b, double c, double& x1, double& x2, double* pDiscriminant = nullptr);

Здравствуйте, grosborn, Вы писали:

G>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.

Нет, это не тот ООП, который выбираем мы. Когда вы пишете в скайп, вы всегда отправляете абстрактное сообщение, частным случаем которого является текст или файл? Вы в самом деле так мыслите? Или вы все же отправляете тексты и файлы?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Есть класс координат нужен для оптимизации по перформансу и памяти. В кратце нужно сделать так что бы каждый экземпляр обновлялся ровно один раз. Если координаты это просто значения, то это не выйдет. А если объект, то у него есть идентити и можно сократить физически количество экземпляров и обновлять без лишних издержек.
S>Для этого "объект" избыточен.

"обновлять без лишних издержек" тут наверное надо подробнее — вся логика обновлений координат инкапсулирована в один класс, в ём два метода invalidate и update + свойства для доступа к значениям в конкретной системе координат.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике.

Программирование пока не формализация знаний, это пока проектирование сложных технических систем. Вот когда рулить станут системы типа data машин и логическое программирование, тогда можно будет говорить о применимости наработок математиков по человекочитаемой формализации знаний в общем программировании. А пока что оно применимо только в системах типа Математики и странных языках типа J или K.
А пока куда больше практической пользы накоплено в инженерии. А там почему то от чертежей или эквивалентных им вещей массового ухода нет.

S>Имхо, ООП успешно не потому, что оно как-то особенно похоже на привычный нам способ выделения абстракций, а по более банальным причинам: производственное удобство.

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

S> Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

Это уже следствие из необходимости применения абстракций. В проектировании реальных железок все тоже самое — двигатель авто, к примеру, проектируется независимым КБ обычно, и на входе формальные спецификации. Поэтому с терминами можно играться как угодно, но практический выхлоп пока строго один.

Здравствуйте, Sinclair, Вы писали:

S>Имхо, ООП успешно не потому, что оно как-то особенно похоже на привычный нам способ выделения абстракций, а по более банальным причинам: производственное удобство. Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

+ упростить-удешевить подготовку специалистов
+ упростить-удешевить использование коллективного труда, когда над одной задачей может рабоать как программист так и непрограммист.

Здравствуйте, AndrewVK, Вы писали:

AVK>Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.

С этим я согласен на все 100%.

AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.

А вот вывод меня просто таки обескураживает. Потому, что у ООП плохо с 1) — абстракции в ООП слабенькие и протекающие, но это можно исправить, а вот с формальным описанием дела обстоят хуже. Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств, опираясь на которые можно рассуждать о коде. С 2) у ООП не то что плохо — 2) там нет вообще, ведь комбинаторы объектов не могут существовать в коде на ООП языках — они существуют только в уме ООП программистов в виде "паттернов" и не формализованы.

AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше.

А вот у ФП проблем, наоборот, поменьше. Лучше всего с 2), с 1) проблемы есть, но их меньше, чем в ООП. В тотальном ФП проблемы с 1) более-менее исправляются.

AVK>Поэтому приходится либо склеивать с ООП,

Склеивание с ООП возможно при отказе от всех преимуществ по пункту 1), польза же по пункту 2) неочевидна.

Реальное преимущество ООП — простота реализации ОО-языка.

AVK>либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа. Если уж приводить пример дополнительной сущности для этой цели, то это язык модулей a-la ML.

Здравствуйте, Ikemefula, Вы писали:

I>Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."
I>Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."
I>Спроси у автора этой мантры а не у меня, я вроде как говорил про понятия и абстракции а не объекты.
Ну так я его спросил, он пока ничего не ответил.

I>Результаты в соревнованиях можно заменить результатами по всем проектам.
Результат игры в шахматы просто интепретировать.
Результат в проекте — нет.