Здравствуйте, pkl, Вы писали:
pkl>Открывание и закрывание двери можно описать в любой парадигме, какой захочется. Что означает "какая лучше подходит"? По какой формуле вычислить показатель лучшести?
Есть всего два показателя:
1. Эффективность работы программиста. Т.е. сколько времени потребуется, чтобы написать, прочесть, отладить, и впоследствии исправить. В первом приближении обратно-линейно зависит от объёма кода.
2. Эффективность работы компилятора. Т.е. насколько эффективный целевой код удастся получить по данному исходнику.
Если мне для открывания двери нужно написать шесть страниц кода, то парадигма плохая. Если на моём четырёхядерном ноуте не удаётся открыть больше сотни дверей в секунду — парадигма плохая.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, pkl, Вы писали: pkl>По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема?
Проблема — в том, что то, что вы описываете, никакого отношения ни к реальной жизни, ни к бытовому мышлению не имеет.
Получается какое-то двоемыслие: то есть начинаем со смелого утверждения "ООП лучше подходит для программирования потому, что человек мыслит объектами". А потом оказывается, что в этой самой парадигме для того, что человек мыслит простым и ясным образом, нужно вводить какие-то публичные переменные, исключения, isOpen(), и прочее — что не соответствует ничему из исходной ментальной модели.
Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Есть всего два показателя: S>1. Эффективность работы программиста. Т.е. сколько времени потребуется, чтобы написать, прочесть, отладить, и впоследствии исправить. В первом приближении обратно-линейно зависит от объёма кода. S>2. Эффективность работы компилятора. Т.е. насколько эффективный целевой код удастся получить по данному исходнику.
я бы сказал, что есть еще (как минимум) третий показатель -- эффективность распараллеливания разработки и отладки системы на группу программистов. Для этого архитектура должна обладать некой повышенной "аддитивностью".
Здравствуйте, vdimas, Вы писали:
V>Что такое "поведение механизмов решения"?
Сложно объяснить формально, оставаясь за рамками конкретной парадигмы. Скажем так — количество возможных траекторий изменения состояния.
Интуитивно понятно, что интерфейс с одним методом — это оверкилл. Есть же delegate Func<T, R>. Да и делегат оверкилл — со всеми его BeginInvoke и прочим — там, где достаточно простого замыкания.
V>Как раз таки DSL меньше всего должны быть мультипарадигменными, иначе это будет профанацией на фоне мультипарадигменных языков общего назначения.
Ну, у меня опыта применения DSL практически нет. Скорее всего да — лишние парадигмы будут только мешать. Но надо смотреть на конкретные примеры.
Вот, скажем, SQL прекрасно работает там, где он остаётся декларативным языком описания запросов.
Когда из него делают процедурный язык, получается многословное и неэффективное гуано. Ещё хуже, когда в него пытаются засунуть ООП. V> То бишь, ваяние нескольких DSL в процессе решения задачи по-прежнему может означать то самое переключение м/у парадигмами.
Да, скорее всего так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так: V>timeModel.update(Environment e, Particles ps).
О, уже timeModel появилось. V>А гду-то унутрях timeModel будет подавать на вычисления некое dt, по которому происходит численное интегрирование. Но опять же, если dt не константа... А если константа, тогда состояние timeModel перемещается в глобальную область вслед за этой константой и остается просто оригинальный update().
Какая ещё "глобальная область" в каноническом ООП? Там нет ничего, кроме объектов, обменивающихся сообщениями.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали:
pkl>>Открывание и закрывание двери можно описать в любой парадигме, какой захочется. Что означает "какая лучше подходит"? По какой формуле вычислить показатель лучшести? S>Есть всего два показателя: S>1. Эффективность работы программиста. Т.е. сколько времени потребуется, чтобы написать, прочесть, отладить, и впоследствии исправить. В первом приближении обратно-линейно зависит от объёма кода. S>2. Эффективность работы компилятора. Т.е. насколько эффективный целевой код удастся получить по данному исходнику.
S>Если мне для открывания двери нужно написать шесть страниц кода, то парадигма плохая. Если на моём четырёхядерном ноуте не удаётся открыть больше сотни дверей в секунду — парадигма плохая.
Это слишком абстрактно, реальные языки часто мульти-парадигменны.
D>ну так, afaiu, в этом и суть претензий -- абстракция, модульность, изменяемое состояние это все общечеловеческие ценности и элементы общей культуры.
Ну дык и каждый отдельно взятый метод объекта не более чем обычная процедура. Само ООП становится видно лишь на некотором удалении от подробностей происходящего.
D>И люди недоумевают, почему некоторые сторонники ООП присваивают их себе.
Какие глупости... Перечисление необходимых/желательных для комплектации парадигмы ООП составных её деталей не есть присвоение. ООП как и ФП зиждется на структурном программировании и львиная доля кода что там что там находится в обычных процедурах... Пусть даже в одном месте их обзывают ф-иями, в другом — методами. Дык, процедурный подход ООП тоже себе присвоить успело или как?
Парадигма программирования — это лишь способ комбинировать технические приёмы/паттерны для достижения неких уже известных (для данной комбинации) плюшек.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали: pkl>>По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема? S>Проблема — в том, что то, что вы описываете, никакого отношения ни к реальной жизни, ни к бытовому мышлению не имеет. S>Получается какое-то двоемыслие: то есть начинаем со смелого утверждения "ООП лучше подходит для программирования потому, что человек мыслит объектами". А потом оказывается, что в этой самой парадигме для того, что человек мыслит простым и ясным образом, нужно вводить какие-то публичные переменные, исключения, isOpen(), и прочее — что не соответствует ничему из исходной ментальной модели.
S>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.
Человек мыслит просто и ясно объектами, никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно.
Здравствуйте, Философ, Вы писали:
Ф>во-первых, я не знаю что это такое, http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0_%D0%9A%D1%8D%D0%BB%D0%B8 Ф>а во-вторых, при решении квадратного уравнения запросто могут получиться комплексные корни — почему-бы его тогда с самого начала не решать с комплексными коэффициентами?
Вы пишете странные вещи. Комплексные корни при решении квадратного уравнения не могут появиться сами по себе.
Просто комплексные числа — замкнуты относительно операций возведения в степень; поэтому они предоставляют минимум, необходимый для того, чтобы получить два корня у любого квадратного уравнения. Как вы помните, в школе всех устраивало наличие от нуля до двух вещественных корней.
Это не значит, что выбор поля исчерпывается вещественными либо комплексными числами.
Понятия операций умножения и сложения введены много для чего. Например, для кватернионов, октонионов. Для матриц, например. Что нам может помешать искать решение уравнения A*X*X + B*X + C = 0, где A, B, C, X — квадратные матрицы?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так: V>>timeModel.update(Environment e, Particles ps). S>О, уже timeModel появилось.
Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.
V>>А гду-то унутрях timeModel будет подавать на вычисления некое dt, по которому происходит численное интегрирование. Но опять же, если dt не константа... А если константа, тогда состояние timeModel перемещается в глобальную область вслед за этой константой и остается просто оригинальный update(). S>Какая ещё "глобальная область" в каноническом ООП?
Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.
S>Там нет ничего, кроме объектов, обменивающихся сообщениями.
Дык, а кто мешается этому синглтону уметь отправлять сообщения?
На твоем любимом дотнете хорошо видно, как в одном и том же процессе создают несколько доменов, то бишь несколько таких синглтонов. Впрочем, на моё сравнение доменов и объектов, когда речь шла о Сингулярити и ОберонОС ты уже ставил минус. После этого твоего поста я понимаю — почему. ))
Здравствуйте, pkl, Вы писали: S>>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение. pkl>Человек мыслит просто и ясно объектами,
Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП? pkl>никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно.
Спасибо, что подтверждаете мою точку зрения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
S>>О, уже timeModel появилось. V>Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.
Сколько ни кури, ООП в численном интегрировании так и не появится.
V>Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.
Давайте пока не будем отклоняться от темы в сторону UML и прочих левых нотаций. Пока что вы предлагаете переместить состояние timeModel из специального объекта-синглтона в специальный объект-синглтон. И не хотите, чтобы я задавал глупые вопросы. Я всё правильно понял?
V>Дык, а кто мешается этому синглтону уметь отправлять сообщения?
Лезвие Оккама. А больше — ничего. Мы можем сделать целый массив длины 1 из массивов длины 1 из объекта специального унитарного класса, который будет отправлять сообщения самому себе, и это всё ещё не будет ничему противоречить. Ну, кроме чувства прекрасного.
А ваше желание называть объектом всё, что угодно, неконструктивно. Потому как не позволяет провести границу между ООП и не-ООП.
V>После этого твоего поста я понимаю — почему. ))
Я так не думаю.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, pkl, Вы писали: S>>>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение. pkl>>Человек мыслит просто и ясно объектами, S>Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП? pkl>>никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно. S>Спасибо, что подтверждаете мою точку зрения.
Имеется ввиду, что ООП хорошо ложится на мышление о сложных механизмах, типа ткацкой фабрики.
Здравствуйте, pkl, Вы писали: pkl>Имеется ввиду, что ООП хорошо ложится на мышление о сложных механизмах, типа ткацкой фабрики.
Это правда. К счастью, мышление человека не сводится к мышлению о ткацких станках.
А про то, что ООП хорошо для описания решений, состоящих из сложных механизмов, я уже писал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Можно сказать, что понятия тождественны абстракциям. Классы это один из способов работы с абстракциями, не единственный, вообще говоря. Главное помнить, что у понятия есть имя, то есть такое слово, которое может выполнять замещающую функцию для этого понятия.
А ты уверен, что те абстракции, которыми оперирует человек по природе своей аналогичны тому, что нам предлагает ООП? Вопрос, кстати, осложняется тем, что ООП само по себе определено крайне нечетко и существует в целой куче разных разновидностей. И ещё больше он осложняется тем, что нет ясного понимания, как думает человек.
По мне это самый сомнительный момент в аргументации. Как можно с уверенностью заявлять о гомоморфизме чего-то нечеткого с чем-то непонятным?
I>Вопрос в том, на кого ориентироваться при разработке. Если ориентироваться на широкие массы, чего боятся функционалисты, нужно давать простые инструменты, это именно то направление которым движется основная часть софтверной индустрии много лет, эта часть ориентирована на вещи общего назначения. Если ориентироваться на гиков, что нравится функционалистам, надо вводить более сложные инструменты, это то направление которым движется небольшая часть софтверной идустрии, которая ориентирована в основном на специфические или высокоуровневые вычислительные задачи.
По-моему ты несколько превратно трактуешь настроения функциональщиков и развитие индустрии.
Индустрия ЯП развивается сейчас по пути гибридизации направлений в рамках отдельных языков в противовес более ранним попыткам делать "чистые" языки и чем дальше, тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.
I>Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения. I>Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.
Меня смущает "понятие" высококлассный программист. Что ты в него вкладываешь?
I>Функционалисты хотят что бы один мега-специалист вооружившись мега-языком накодил небольшое ядро и сгенерил код для всего остального. Это утопия, просто потому что задач очень много, просто вникнуть в эти задачи это адское количетсво времени, хватит на сотню а то и тысячу лет жизни одного такого функционалиста.
Осторожно предположу, что ты превратно трактуешь идеи "функционалистов"
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Но пока никто с помощью ООП дверь не открыл.
Это умозрительное твое мнение или у тебя есть какие-то неоспоримые док-ва?
Объясни проблему открыть дверь с помощью ООП? ИМХО, дверь — отличный пример изменяемого состояния с зависимым от состояния поведением. Спекулировать тут можно только на степени подробности происходящего. Но, к счастью, в реальной работе любые спекуляции заканчиваются там, где фиксируется ТЗ.
LCR>Я так и не понял почему взаимодействие между одной коровой и травой (которая представлена одним или несколькими объектами?) свелось ко множеству коров и повторному взаимодействию.
Я не вижу никакого повторного взаимодействия. Конкретно в этом в этом примере цепочка событий выглядит так:
— [природа] заставляет [каждую] [корову] есть [траву];
— [корова] съедает некоторое [количество] этой [травы];
Предлагаю провести самостоятельное сопоставление словесного описания алгоритма и предложенных в пред. посте сигнатур методов объектов. Ты заметишь, что в цепочке взаимодействия обнаружится тупиковый узел. Это т.н. "пассивный объект" для рассматриваемой цепочки. В ответ на приходящие события (вернее, сообщения о событиях, если придерживаться буквы) он просто меняет своё состояние, но не генерирует события/сообщения для других объектов.
LCR>В моём детском саду я честно говоря подозревал, что максимум можно только во вторую степень,
Увы, распространение энергии в пространстве описывается уравнениями 3-й степени.
LCR>а суперкомпьютеры я думал они для обогрева помещения...
Они для обогрева улицы по большей части.
LCR>И да, порезать лужу на квадратики — тоже один из самых популярных видов моделирования в этих областях. Но мне так и не стало яснее, какой вклад в эту модель составляет именно ООП.
Здравствуйте, vdimas, Вы писали:
V>Мозг работает образно и это уже многократно доказано.
Кем доказано ? Можно взглянуть на доказательства ? А то в книгах по когнитивной психологии ни разу не встречал "мозг работает образно"
>Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...
Здравствуйте, pkl, Вы писали:
pkl>Имеется ввиду, что ООП хорошо ложится на мышление о сложных механизмах, типа ткацкой фабрики.
Если почитать Dr. Kay-я, то он под каждой вещью подразумевает компьютер. Это вовсе не хорошо ложится, это способ представления природы вещей такой. Пусть заяц будет компьютером и морковка будет компьютером, и пусть они обмениваются сообщениями. Подробнее http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented
Соответственно, когда мы размышляем о механизмах и их взаимодействии, то способ представления их компьютерами довольно хорош. Но представлять компьютер из двери, морковки или записи в журнале — противоестественно и не свойственно для мышления человека не программиста. Хотя ООП-шники, увлекшись, представляют все компьютером в понимании Кея не моргнув. Я не возражаю, это работает. Но попробуйте рассказать о том что заяц с морковкой обмениваются сообщениями какой-нибудь бабушке и оцените, насколько естественно для нее такое мышление.
Здравствуйте, Sinclair, Вы писали:
V>>Что такое "поведение механизмов решения"? S>Сложно объяснить формально, оставаясь за рамками конкретной парадигмы. Скажем так — количество возможных траекторий изменения состояния. S>Интуитивно понятно, что интерфейс с одним методом — это оверкилл. Есть же delegate Func<T, R>. Да и делегат оверкилл — со всеми его BeginInvoke и прочим — там, где достаточно простого замыкания.
Ну ок. Просто пока плохо понятна связь с последующим выводом в оригинальном посте.
V>>Как раз таки DSL меньше всего должны быть мультипарадигменными, иначе это будет профанацией на фоне мультипарадигменных языков общего назначения. S>Ну, у меня опыта применения DSL практически нет. Скорее всего да — лишние парадигмы будут только мешать. Но надо смотреть на конкретные примеры.
Я возражал лишь на это:
Серебряной пулей тут является умение мыслить несколькими парадигмами и свободное переключение между ними. Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу.
V>> То бишь, ваяние нескольких DSL в процессе решения задачи по-прежнему может означать то самое переключение м/у парадигмами. S>Да, скорее всего так.
S>Вот, скажем, SQL прекрасно работает там, где он остаётся декларативным языком описания запросов. S>Когда из него делают процедурный язык, получается многословное и неэффективное гуано. Ещё хуже, когда в него пытаются засунуть ООП.
Спорить не буду, но и соглашаться тоже. Я видел много кода на оракловом процедурном SQL в т.ч. реализованную интероперабельность с java-объектами, которые хостятся на серваке (тут Оракл был раньше MS). И скажу так, что претензии у меня по большей части к динамической природе языка, а не к его мультипарадигменности. Заметь, что этот момент неплохо перекликается с твоими собственными утверждениями об умении переключаться м/у парадигмами. Я бы добавил, что переключение — относительная фигня. Коль речь всё еще об одном проекте, то нам эту мультипарадигменную солянку надо как-то спрягать саму с собой.
