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

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

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

S>Если почитать Dr. Kay-я, то он под каждой вещью подразумевает компьютер. Это вовсе не хорошо ложится, это способ представления природы вещей такой. Пусть заяц будет компьютером и морковка будет компьютером, и пусть они обмениваются сообщениями. Подробнее http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

S>Соответственно, когда мы размышляем о механизмах и их взаимодействии, то способ представления их компьютерами довольно хорош. Но представлять компьютер из двери, морковки или записи в журнале — противоестественно и не свойственно для мышления человека не программиста. Хотя ООП-шники, увлекшись, представляют все компьютером в понимании Кея не моргнув. Я не возражаю, это работает. Но попробуйте рассказать о том что заяц с морковкой обмениваются сообщениями какой-нибудь бабушке и оцените, насколько естественно для нее такое мышление.
Все люди изнутри очень разные, все мысшят по-разному, представляют себе мир в разных парадигмах. Вот этому чуваку проще так видеть мир, другому не так...

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

S>Здравствуйте, pkl, Вы писали:
pkl>>Имеется ввиду, что ООП хорошо ложится на мышление о сложных механизмах, типа ткацкой фабрики.
S>Это правда. К счастью, мышление человека не сводится к мышлению о ткацких станках.
S>А про то, что ООП хорошо для описания решений, состоящих из сложных механизмов, я уже писал.
Ну а программирование в основном и происходит в области сложных структур и механизмов.

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

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

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

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

ООП без абстракций это новость

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

Есть несколько теорий мышления.

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

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

0>тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.

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

I>>Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения.
I>>Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.
0>Меня смущает "понятие" высококлассный программист. Что ты в него вкладываешь?

Примерно как в шахматах — первый разряд, кмс, мс, гроссмейстер

I>>Функционалисты хотят что бы один мега-специалист вооружившись мега-языком накодил небольшое ядро и сгенерил код для всего остального. Это утопия, просто потому что задач очень много, просто вникнуть в эти задачи это адское количетсво времени, хватит на сотню а то и тысячу лет жизни одного такого функционалиста.
0>Осторожно предположу, что ты превратно трактуешь идеи "функционалистов"

Может и так.

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

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

S>>Соответственно, когда мы размышляем о механизмах и их взаимодействии, то способ представления их компьютерами довольно хорош. Но представлять компьютер из двери, морковки или записи в журнале — противоестественно и не свойственно для мышления человека не программиста. Хотя ООП-шники, увлекшись, представляют все компьютером в понимании Кея не моргнув. Я не возражаю, это работает. Но попробуйте рассказать о том что заяц с морковкой обмениваются сообщениями какой-нибудь бабушке и оцените, насколько естественно для нее такое мышление.
pkl>Все люди изнутри очень разные, все мысшят по-разному, представляют себе мир в разных парадигмах. Вот этому чуваку проще так видеть мир, другому не так...

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

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

J>>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть
S>Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?

Вобще говоря так и делается в целях оптимизации.

Здравствуйте, pkl, Вы писали:
pkl>Ну а программирование в основном и происходит в области сложных структур и механизмов.
Это смелое утверждение. Не очень понятно,
а) правда ли это, или это результат наблюдений за ограниченным спектром задач.
б) если это правда, то является ли это результатом осознанной оптимизации, или всего лишь артефактом неверного подхода, продиктованного узостью кругозора программистов.

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

I>Вобще говоря так и делается в целях оптимизации.
А можно поподробнее? Что именно вы оптимизируете?

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

V>Я возражал лишь на это:
V>

V>Серебряной пулей тут является умение мыслить несколькими парадигмами и свободное переключение между ними. Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу.

Ну так DSL вовсе не обязан быть мультипарадигменным. Представим, что у нас нет, скажем, Пролога. В его отсутствие мы можем быть вынуждены писать решение на адской смеси из, скажем, SQL (для хранения фактов) и, скажем, Java (для собственно обработки). А можем родить Пролог и получить "однопарадигменный" язык, который окажется удобнее, чем сразу две парадигмы.

V>Спорить не буду, но и соглашаться тоже. Я видел много кода на оракловом процедурном SQL в т.ч. реализованную интероперабельность с java-объектами, которые хостятся на серваке (тут Оракл был раньше MS). И скажу так, что претензии у меня по большей части к динамической природе языка, а не к его мультипарадигменности.
Ну, а я вот видел много кода на T-SQL. В основном в хранимках. И там сразу видно, что те вещи, которые должны быть простыми, выглядят просто чудовищно. Банальные "из двух мест взяли, в третье положили", которые так и пишутся тремя строчками на приличном general purpose language — это адский взрыв мозга на T-SQL.
Интероперабельность с объектами — это всё цветочки. Вы посмотрите на OQL — вот где тру ООП-в-SQL. Он так и не взлетел никогда по причине чудовищной ужасности.

V>Заметь, что этот момент неплохо перекликается с твоими собственными утверждениями об умении переключаться м/у парадигмами. Я бы добавил, что переключение — относительная фигня. Коль речь всё еще об одном проекте, то нам эту мультипарадигменную солянку надо как-то спрягать саму с собой.
Да, конечно же. Имелся в виду контекст одного проекта. Между разными проектами переключение парадигмы никакой проблемы не представляет.

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

LCR>Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.

А с каких пор ООП это именно создавать классы Лужа и Камень ?

LCR>Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл:

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

Если не согласен, то например, напиши робота который умеет играть в покер на нескольких популярных сайтах и что бы чисто вычметоды были никакого ООП. Не нравится покер — пусть будет блекджек или баккара.

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

S>Здравствуйте, pkl, Вы писали:
pkl>>Ну а программирование в основном и происходит в области сложных структур и механизмов.
S>Это смелое утверждение. Не очень понятно,
S>а) правда ли это, или это результат наблюдений за ограниченным спектром задач.
S>б) если это правда, то является ли это результатом осознанной оптимизации, или всего лишь артефактом неверного подхода, продиктованного узостью кругозора программистов.
ХЗ.

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

I>>Вобще говоря так и делается в целях оптимизации.
S>А можно поподробнее? Что именно вы оптимизируете?

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

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

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

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

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

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

S>Ну вы правильно всё пишите. Нет никакой необходимости вклеивать ООП в каждую дырку. ООП это прежде всего подход к решению задачи, с целью минимизировать её сложность. Математики/психологи давно заметили, что мозг способен держать и оперировать конечным количеством сущностей. Соответственно и нужно любую задачу каким-то образом упростить до того уровня, на котором мозг способен с ней совладать. Два ходовых приёма: абстрагироваться от неважного и внятно выделить общие части. ООП язык даёт синтаксический способ фиксации этих вещей. Классы, объекты, наследование. Вот и всё. Остальное уже для удобства и техники.

Что характерно, в ФП ровно тоже самое — абстрагироваться от неважного И ФП дает синтаксический способ фиксации этих вещей.

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

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

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

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

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

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

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

I>Это телега впереди лошади. Индустрия, любая, не тоьлко ИТ, развивается в соответствии с новыми целями-задачами. А вот гибридиация фич это только один из возможных вариантов.
Я и не говорил, что это цель.
Это, безусловно, метод.

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

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

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

M>Кхм. В итоге ты размазываешь непонятно что десятком предложений По ссылке — как раз яркий пример, что мы не мыслим объектами

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

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

Посему в дальнейших беседах с вами на эту и другие темы резона не вижу и участия принимать не буду.

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

SV.>>Да, самое главное. Надо помнить, что эволюция идет постепенно. Может быть, через пару лет и в Яве будет все в порядке с обработчиками и предикатами. А вот если они упрутся, и по идеологическим причинам не станут их вводить, тогда и скажем — заставь дурака...

VS>В Java 8 лямбды будут. И много чего еще.

Будет интересно посмотреть.

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

IT>>Т.е. ООП, ФП и другие подходы для тебя просто инструменты для достижения определённых целей? А твоя цель — "чтоб не копипастить"?
E>Цель — чтобы гораздо меньшими усилиями выполнить работу и чтоб потом это можно было поддерживать. Я на проектах обычно долго сижу, и последствия принимаемых решений мне видны. Накосячу — разгребать и отвечать мне. Даже ненависть к копипасту — это следствие. А чтоб сделать именно так круто, как в книжке написано — у меня этой цели уже очень и очень давно нет.

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

Я считаю, вы оказались втянуты в провокацию IT против меня, который прямо не заявляет, но намекает, что я путаю цель (выполнение проекта или типа того) и средства (ООП). IT, на ваш имплиситный наезд, я дал экплиситный ответ. Он абзацем выше.

Что касается "чтоб потом это можно было поддерживать". У вас новые кадры подключаются к проекту? Бывает такое? Или, может быть, новые кадры используют библиотеки/API, которые вы пишете? Если да, то ООП помогает им быстрее соотнести ваш код с решаемыми им задачами. Не больше и не меньше. Избавляться от копипаста оно определенно не помогает.

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