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

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

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

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

V>В упомянутом смысле.
Не имею понятия о побочных эффектах в упомянутом смысле. Ты походу описываешь C++ if-оператор, нет? Там — да, там then/else выполняются и портят мир. А хаскель даже не вычисляет then/else, потому оператор if эквивалентен соответствующей функции с точностью до некоторых нюансов, не имеющих отношение к побочным эффектам.
http://www.haskell.org/haskellwiki/If-then-else

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

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

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

var x = 2;
x = 3;

он посидит, подумает, и через какое-то время сам изобретет что-то вроде bind-а.

Во-вторых, монада как абстракция может вообще рассматриваться как простая абстракция для контейнера с двумя функциями, одна это обычный map, вторая — join. На примере списка — map это map, join — это concat, т.е. concat [1,2],[3,4]] = [1,2,3,4]. Пока ничего мозговзрывающего, правда? К тому же все это есть в линке, который вроде тоже мозги не взрывает.
Имея эти две функции, мы можем написать третью на их основе — join (map f xs). Надо полагать, что именно тут мозги и взрываются? А ведь это же просто SelectMany
И по сути — это все.
Если, конечно, пользоваться bind напрямую, то синтаксис получается не очень, но для того и ввели do нотацию. Код в do нотации вообще выглядит как самый обычный императивный код.

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

Да нету никакого акта каррирования, все функции "по умолчанию" и так каррированы. Ты видимо все же имеешь в виду частичное применение — ну так они является естественным следствием того, что функции с несколькими параметрами имитируются вложенными функциями. Это же вообще голая лямбда.

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

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

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

Разве это плохо? И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.

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

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

S>>>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).

Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает. Предполагаю, что Sinclair на бухгалтерии пол-Кореи собак съел и объяснит, почему класс Account для настоящей бухгалтерии противопоказан. Я или соглашусь, или поспорю. То же самое касается остальных. Приглашается любой желающий.

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

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

Ага, все просто когда наконец мозги себе поломаешь. Ну так и в ООП тоже все просто в таком разрезе.

ВВ>Слишком многословным — да. Недостачно абстрактным — нет. Тут важно понимать, что эти, как ты их называешь, подпорки не вводят какие-то новые уровни абстракции, которых до этого не было

А я этого нигде и не писал.

ВВ>Они просто позволяют писать короче и выразительнее.

А ФП и ООП в целом, это тоже про короче и выразительнее.

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

ВВ>Разве это плохо?

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

ВВ> И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.

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

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

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

Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.

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

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

Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы. Но кое-какие абстракции вносить разрешается (вьюшки с вычисляемыми полями в базе). Другим — Objective-C или Java.

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

SV.>Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

1)
В чистом виде ООП практически не встречается — не следит никто за чистотой парадигмы. Почти везде компромис между сложностью/трудоёмкостью и ленью программистов.
Идеальный код — название книжки, а в реальной жизни он не встречается.

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

Кроме того, многие просто бояться сюда постить свой рабочий код, ибо если узнает начальство — получат по шапке.
Некоторые элементарно стесняются его сюда выкладывать.
-------------------
Сказанное выше относится как к описанию архитектуры, так и к самому коду.

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

K>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы

Это не программисты уже в привычном понимании.

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

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

Так обо что именно ломаются мозги? Можно все-таки это как-то объяснить? Линк на твой взгляд тоже взрывает мозг?

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

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

ВВ>>Они просто позволяют писать короче и выразительнее.
AVK>А ФП и ООП в целом, это тоже про короче и выразительнее.

Остается понять, у кого это получается лучше.

ВВ>>>>Набор "спецификаций", что характерно, как был, так и остался в сигнатурах функций.
AVK>>>Только вот задавать его стало проще.
ВВ>>Разве это плохо?
AVK>Разве я писал что плохо? Я писал о другом — ФП как парадигма не лучше ООП, а в чем то даже хуже. И если уж искать в ООП соринки, то и бревна ФП неплохо бы тогда упоминать.

Здесь, видимо, неплохо бы объяснить, чем же хуже, и о каких бревнах речь.
Я вот замечаю обратное — при программировании на ОО языке постоянно выходишь за рамки парадигмы, как раз чтобы код был короче и понятнее. И гибче. Развитие того же шарпа хорошо это показывает. В ФЯ же такое происходит гораздо реже.

ВВ>> И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.
AVK>Подпоркой, потому что это дополнительные концепции к базовым, появившиеся из-за их (базовых концепций) недостаточной краткости и выразительности.

Ну если мы не выходим за рамки ФП, то это никак не может являться новой концепцией. Мы просто увидели то, что в ФП было всегда, и придумали для этого более удобный энкодинг.
В ООП же, для сравнения, у нас действительно появляются подпорки. Даже банальные статические методы уже выходят за рамки ООП.
Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП, и начинаем фаршировать язык новыми фичами, сиречь подпорками, которые к ООП вообще никакого отношения не имеют. После этого, чтобы оправдаться, называем язык "гибридным". Но ООП у нас все равно по-прежнему самое-самое. И тайп-классы и алгебраические типы в функциональных языках мы считаем "подпорками".

Я чего-то тут явно не понимаю.

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

SV.>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.

public class NotNullUtils {
    public static <T> List<T> processNull(List<T> list) {
        if (list == null) {
            return new ArrayList<T>();
        }
        return list;
    }

    public static String processNull(String string) {
        if (string == null) {
            return "";
        }
        return string;
    }
...

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

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

SV.>Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).
Выделенное неплохо бы обосновать. Но только не тем, что новички сначала проходят ООП, а потом все остальное. Бывает и по-другому.

SV.,

LCR>>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

SV.>Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

О! А с лужами и камнями вам стало быть всё-всё понятно?

Знаете, нужно хотя бы разобраться с простыми вещами, такими как открывание двери и щипание травы. Потому как в данном симметричном взаимодействии присутствует неопределённость, люфт я бы даже сказал, что считать субъектом, а что объектом взаимодействия. Не хочешь говядину с травой, вот тебе более животрепещущий пример — бинарные операции над полями. Да, да, обычное сложение вещественных чисел.
1 + 2
Мы легко делаем финт ушами и трактуем сию запись как синтаксический сахар для 1.+(2). И типа никаких проблем. Если бы...
Сложение коммутативно. Это значит, что 1 + 2 должно быть то же самое, что и 2 + 1. Чтобы более рельефно отразить проблему я запишу это как 1.0 + 2. Внезапно классы Integer и Float оказались связанными одной цепью — метод Integer.+(Float) обязан быть тождественным методу Float.+(Integer). А если ты захочешь добавить класс Rational как пару целых чисел, и реализовать сложение с вещественными числами, тебе надо будет во-первых перечислить в этом классе все возможные случаи, а во вторых хакнуть все системные классы, и добавить туда _.+(Rational).

Поехали дальше. Есть ещё такие штуки как отношения — это подмножества декартова произведения множеств. Ну там <, =<, ==, какие-нибудь хитрые отношения частичного порядка. И частенько бывает, что от отношений требуется симметричность, и транзитивность. Симметричность, это когда x (R) y совпадает с y (R) x для любых x и y. Если мы реализуем отношение как приклеивание метода r к объекту, мы вступаем на зыбкую почву. Мы должны гарантировать, что x.r(y) есть то же самое, что и y.r(x) для любых пар (это довольно легко, если x и y одного класса), но что если x и y принадлежит различным классам, но как значения концептуально эквивалентны? Например, всё тот же класс Rational и мы хотим чтобы оно проверялось на равенство с вещественными числами. Или чуть сложнее: мы например можем ввести отношение == на списках, пусть они будут эквивалентны, если они поэлементно равны. Аналогично мы можем ввести отношение эквивалентности на хэш-таблицах. И вполне естественно, что мы можем захотеть, чтобы список [a,b,c] был эквивалентен хэштаблице [0->a,1->b,2->c]. Как будем реализовывать ==? А ввести отношение лексикографического порядка для всех сравнимых списков и хэшей?

Я уже не говорю о том, что если заданы операции == и <, то все остальные — !=, >, >=, =< определяются автоматически, но выразить этот автоматизм нет никакой возможности. Тем более, что сравнивать есть с чем: классы типов Eq и Ord сами знаете где.

Ещё? Хорошо. Конкатенация ленивых списков (их ещё в SICP зовут Streams).
a = ...
b = ...
func(a ::: b)
func принимает значения типа LazyList. Как будем реализовывать операцию :::? Ну казалось бы

public LazyList :::(LazyList that) {
  // приклеиваем к this that и возвращаем 
  return new LazyList(()->this)
}

Всё, мы в глубокой заднице. Представим теперь, что a — это очень большой, или даже бесконечный ленивый список. a ::: b будет преобразовано в a.:::(b), и затем чтобы вызвать метод ::: придётся вычислить a. Всё, мы зависли и/или сожрали всю память.

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

SV.>Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

Да, пример Account интересен, я тоже жду продолжения.

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

LCR>Сложение коммутативно. Это значит, что 1 + 2 должно быть то же самое, что и 2 + 1. Чтобы более рельефно отразить проблему я запишу это как 1.0 + 2. Внезапно классы Integer и Float оказались связанными одной цепью — метод Integer.+(Float) обязан быть тождественным методу Float.+(Integer). А если ты захочешь добавить класс Rational как пару целых чисел, и реализовать сложение с вещественными числами, тебе надо будет во-первых перечислить в этом классе все возможные случаи, а во вторых хакнуть все системные классы, и добавить туда _.+(Rational).

LCR>Поехали дальше. Есть ещё такие штуки как отношения — это подмножества декартова произведения множеств. Ну там <, =<, ==, какие-нибудь хитрые отношения частичного порядка. И частенько бывает, что от отношений требуется симметричность, и транзитивность. Симметричность, это когда x (R) y совпадает с y (R) x для любых x и y. Если мы реализуем отношение как приклеивание метода r к объекту, мы вступаем на зыбкую почву. Мы должны гарантировать, что x.r(y) есть то же самое, что и y.r(x) для любых пар (это довольно легко, если x и y одного класса), но что если x и y принадлежит различным классам, но как значения концептуально эквивалентны? Например, всё тот же класс Rational и мы хотим чтобы оно проверялось на равенство с вещественными числами. Или чуть сложнее: мы например можем ввести отношение == на списках, пусть они будут эквивалентны, если они поэлементно равны.

...

LCR>Да, пример Account интересен, я тоже жду продолжения.

Сильно. Да. Очень сложно приткнуться к дискуссии. Про Account — согласен.

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

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

В этом и состоит моя ирония, т.к.:
— по определению чистых ф-ий им не важен порядок вычисления операндов;
— ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;
— но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.


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

AVK>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.

Заблуждение.


AVK>А логические ветвления присутствуют, наверное, в любой парадигме.

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


V>>Про последовательное исполнение в Хаскеле — do-стрелки.
AVK>А при чем тут Хаскелл?

А чтобы сферических коней не гонять туда-сюда.


V>>Про циклы будем или уже ну его? )))
AVK>Циклов в ФП тоже нет.

Таки будем? )))

Наличие рекурсии в языке в сочетании с ветвлением даёт цикл. Это прямо по определению что есть рекурсия, что есть цикл и что есть процедура/ф-ия в структурном программировании.

Видя твоё нежелание в предыдущие разы что-то сопоставлять самому, сделаю это за тебя:

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

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

* В программировании рекурсия — вызов функции (процедуры) из неё же самой

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

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

S>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

Что значит "рулит"?


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

Уже смогли. Мозг мыслит абстракциями, то бишь упрощениями. Именно абстрагирование от подробностей позволяет мозгу систематизировать и накапливать знания. Иначе не было бы никакого "обучен".

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

M>Где ты видишь бред? Бред пока у людей, которые неспособны подтвердить свой тезис, что ООП прекрасно моделирует реальность.

Не хуже человеческого мозга. Реальность всегда моделируется с некими упрощениями, то бишь абстрактно.

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

Противоречие самому себе:

* специальный метод bool isOpen().
* видите, открыта ли дверь.

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

V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.
Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

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

AVK>>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.

V>Заблуждение.
Тут вообще в SP речь об операциях, точнее об statement-ах (см http://en.wikipedia.org/wiki/Structured_programming).
Согласно http://en.wikipedia.org/wiki/Imperative_programming

In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state.

В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы. Т.е. 3/3х конструкций структурного программирования не про чистый ФЯ.

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

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

S>>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

V>Что значит "рулит"?
значит крут

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

V>Уже смогли.
Можно пример с убедительным доказательством что модель является действительно минимальной?

V>Мозг мыслит абстракциями, то бишь упрощениями. Именно абстрагирование от подробностей позволяет мозгу систематизировать и накапливать знания. Иначе не было бы никакого "обучен".
И причем тут ООП?

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

S>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты?

Как минимум глаза, получающие сообщения от рецепторов света.