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

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

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

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

Я про другое. Мы (люди) сознательно оперируем иерархическими абстракциями (в том числе, строим их) в основном на этапе обучения и освоения новых данных, а потом их просто используем. В инженерном контексте другим способам мышления взяться неоткуда. Отсюда можно предположить, что для быстрой и точной работы нужно избегать разработки новых абстрактных иерархий (в т.ч. классов). Если же разрабатывать, то понимать, что этот процесс уже не четкий алгоритмический, а по характеристикам идентичен процессу обучения/освоения материала. Как ты этот процесс по-другому назовешь и в чем будешь видеть отличие от изучения/обучения, уже второстепенно.

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

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

А кто говорил что это легко ? Во всяком случае более мнее отранжировать специалистов все таким можно.

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

K>Я про другое. Мы (люди) сознательно оперируем иерархическими абстракциями (в том числе, строим их) в основном на этапе обучения и освоения новых данных

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

K>Отсюда можно предположить, что для быстрой и точной работы нужно избегать разработки новых абстрактных иерархий

Не вижу логической связи. И почему за несколько веков никто не додумался до лучшей альтернативы?

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

K>А вот вывод меня просто таки обескураживает.

Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле. Только вот твои качественно-экспертные оценки лично меня нисколечко не убеждают.

K>1) — абстракции в ООП слабенькие и протекающие, но это можно исправить

Субъективно

K>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств

Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

K>2) у ООП не то что плохо — 2) там нет вообще, ведь комбинаторы объектов не могут существовать в коде на ООП языках — они существуют только в уме ООП программистов в виде "паттернов" и не формализованы.

Вообще какая то игра терминами. Наследование и агрегация — основные способы комбинирования в ООП — вполне себе удобные способы комбинирования, хоть и не идеальные.

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

У чистого ФП — больше. Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга, туплов, АлгТД и т.п. Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

K>Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа.

Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

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

V>ООП как и ФП зиждется на структурном программировании

Можно поподробнее раскрыть мысль, как основа основ структурного программирования, императивный алгоритм, послужил основной ФП?

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

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

K>А вот вывод меня просто таки обескураживает. Потому, что у ООП плохо с 1) — абстракции в ООП слабенькие и протекающие,

Это зависит от задачи.

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

А как быть с чистотой АПИ у ФП ? Здесь, мягко говоря, конь не валялся.

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

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

Простота реализации вообще ничего не значит, наглядным примером является такой язык как С++

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

K>>Я про другое. Мы (люди) сознательно оперируем иерархическими абстракциями (в том числе, строим их) в основном на этапе обучения и освоения новых данных

AVK>Я думал здесь все таки применение тех или иных подходов в промышленном программировании обсуждали. Для обучения или в качестве зарядки для ума совсем другие критерии требуются.

Я не про критерии.

K>>Отсюда можно предположить, что для быстрой и точной работы нужно избегать разработки новых абстрактных иерархий

AVK>Не вижу логической связи. И почему за несколько веков никто не додумался до лучшей альтернативы?

Лучшей альтернативы чему ? Это и есть наиболее эффективная организация работы — одни оперируют абстракциями и пишут процедуры, другие их используют как есть. Первые при этом тормозные исполнители, а вторым лучше не доверять работу на высоких уровнях абстракции. Хорошо проявляется на примере стандартных библиотек. Наиболее эффективна разработка там, где готовых библиотек уже достаточно, и надо лишь связать компоненты glue-кодом с минимум специфичной логики (настолько минимумом, что он весь легко описывается блок-схемами).

Кто не укладывается в этот принцип, у тех работа перестает быть шаблонной и становится творческим процессом, он же процесс исследования и обучения. И становится медленней. Где противоречие ?

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

S>Для этого "объект" избыточен. Достаточно иметь "указатель на значение", а эта штука работает задолго до ООП.

"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания.

Конкретно по теме, что координата, что многомерный вектор — во всех графических либах это несомненные объекты.


S>Вы же не считаете, скажем, дековский ассемблер ООП-шным?

Гы-гы... Показываю смертельный номер:
============
Ну в нем макросистема существенно мощнее, чем в Си, но вы же не считаете, скажем, дековский ассемблер вдохновителем Немерле?
============
Занавес.

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

K>Я не про критерии.

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

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

S>>>О, уже timeModel появилось.
V>>Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.
S>Сколько ни кури, ООП в численном интегрировании так и не появится.

ООП рулит в области иммитации/моделирования. А если это моделирование во времени, то аппарат численного интегрирования тоже всех заруливает. Да собственно, на этом построена вся современная обработка сигналов. Посмотри хотя бы на графы DirectShow. Как ты думаешь, что там в узлах графа? Ууупссс? ))

V>>Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.
S>Давайте пока не будем отклоняться от темы в сторону UML и прочих левых нотаций.

На примере нотации можно объяснить людям происходящее.


S>Пока что вы предлагаете переместить состояние timeModel из специального объекта-синглтона в специальный объект-синглтон.

timeModel не обязан быть ни специальным, ни синглтоном. Я могу его переместить лишь в случае, когда этот объект является константой, то бишь в программе будет не предусмотрена настройка параметров численного интегрирования.


S>И не хотите, чтобы я задавал глупые вопросы.

Да ради бога, задавайте. Только никто не запретит мне называть глупые вопросы глупыми.


S>Я всё правильно понял?

Пока что всё неправильно. Наверно в пылу спора забыл, что в любимом дотнете не бывает экземплярных констант, то бишь они всегда глобальные (с т.з. экземплярности). Разве не упс? ))


V>>Дык, а кто мешается этому синглтону уметь отправлять сообщения?
S>Лезвие Оккама. А больше — ничего. Мы можем сделать целый массив длины 1 из массивов длины 1 из объекта специального унитарного класса, который будет отправлять сообщения самому себе, и это всё ещё не будет ничему противоречить. Ну, кроме чувства прекрасного.

Это у тебя какое-то неправильное чувство. Оно у тебя забывает, что отправку сообщений надо как-то инициировать, из воздуха сообщения не берутся. Поэтому существует понятие т.н. "активный объект". Это тот, который получив управление в некоем потоке исполнения генерит события для остальных. Даже для самого себя. Даже если тупо в цикле от T0 до Tn вызывается update(..., dt).

Например, в любимом тобой DirectShow этими активными объектами являются... являются.... о нет, только не это... ТАЙМЕРЫ! Ууупссс? )))


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

Граница проходит по выбранным технологиям, и больше ни по чему. Сама процедура выбора — это проявление воли разработчика и ничего более. Бога с т.з. IT нет.

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

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

K>>Я не про критерии.

AVK>Зато то я про них. Все что я написал, касается промышленного создания нового софта. Применять мои слова к другим ситуациям, чтобы потом доказать их неверность, глупо и некорректно.

И я про него. Возвращаясь к вашему первоначальному:

AVK>до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций.

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

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

V>>ООП как и ФП зиждется на структурном программировании
AVK>Можно поподробнее раскрыть мысль, как основа основ структурного программирования, императивный алгоритм, послужил основной ФП?

Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

Ну а теперь вики:

Структу́рное программи́рование ...
1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

* последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

* ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;

* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

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

Про последовательное исполнение в Хаскеле — do-стрелки.
Про ветвление — уже сказал.
Про циклы будем или уже ну его? )))

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

K>>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств
AVK>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

Какими?

AVK>У чистого ФП — больше. Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга, туплов, АлгТД и т.п. Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

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

K>>Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа.
AVK>Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

Тайп-классы нужны, чтобы вместо того, чтобы писать:

doSomeMath (+) (-) x y = ...

Написать просто:

doSomeMath x y = ...

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

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

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

V>Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

Какой-какой побочный эффект

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

K>Одни люди разрабатывают абстракции,

Про них и речь.

K> другие — пишут конечный софт с их применением.

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

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

AVK>>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

ВВ>Какими?

Монады сгодятся?

ВВ>Каким образом карринг может являться подпоркой чего-либо?

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

ВВ>Кортежи и алгебраические типы не нужны — они не являются дополнительными сущностями, и введены просто для удобства

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

AVK>>Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

ВВ>Набор "спецификаций", что характерно, как был, так и остался в сигнатурах функций.

Только вот задавать его стало проще.

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

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

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

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

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

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

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

Простое взяли и положили как раз таки выглядит легко:

select a into b.

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

S>Интероперабельность с объектами — это всё цветочки. Вы посмотрите на OQL — вот где тру ООП-в-SQL. Он так и не взлетел никогда по причине чудовищной ужасности.

Есть мнение что ODB-базы не взлетели потому, что требуют специального языка для полноценной отдачи от технологии. При том, что любые существующие порты на мейнстримовые языки были априори кривые из-за недостаточной поддержки в мейнстримовых языках нужд ODB. Маппинг OQL на объекты мейнстримовых языков — отличный пример кривизны, потери типобезопасности, разрыва второго рода в рефакторинге и т.д. до бесконечности. В итоге — неудобно. А там где неудобно, там в итоге дорого в разработке, когда речь об инструментарии.

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

V>>То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

S>Какой-какой побочный эффект

В упомянутом смысле.

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

V>Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

О чем ты вообще? Вики:

In computer programming, a function may be described as pure if both these statements about the function hold:
The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

При чем тут порядок вычислений? if для заданных входных значений всегда возвращает один и тот же результат, и не приводит ни к каким изменениям стейтов объектов или устройств ввода/вывода. Значит, по определению, функция if чистая.

V>Ну а теперь вики:
V>Структу?рное программи?рование ...
V>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
V> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
V> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
V> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

V>Про последовательное исполнение в Хаскеле — do-стрелки.

А при чем тут Хаскелл?

V>Про циклы будем или уже ну его? )))

Циклов в ФП тоже нет.

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

V>Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

Во-первых, причем тут побочный эффект. Во-вторых, то, что идет после then и else в хаскелле вообще-то не вычисляется.

V>Про последовательное исполнение в Хаскеле — do-стрелки.

Что такое do-стрелки? Do — это сахар для bind, стрелки это стрелки. Вообще стрелки и последовательное исполнение — это из области "слышал звон".
А через монады в Хаскелле как раз и описывается императивный код. Do-нотация так вообще специально гриммируется под императивную программу. Ну и что?

V>Про ветвление — уже сказал.
V>Про циклы будем или уже ну его? )))

Давайте. Предполагаю, что будут нападки на явную рекурсию, притом что среднестатистический прграммист на Хаскелле явно рекурсивные функции пишет два раза в год.