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

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

LP>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.

AVK>Можно раскрыть мысль?

Смотри сообщение выше.

LP>> Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
AVK>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).

Что такое декларативность? Меня всегда восхищал этот термин.

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

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

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

LP>>>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
L>>>>Просто уровень инкапсуляции ниже — только функция,
LP>>>В этом примере нету инкапсуляции — голый byte[] на выходе.
C>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.

LP>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).

*asByteArray()

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

C>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
LP>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP.

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

AVK>>Можно раскрыть мысль?

LP>Смотри сообщение выше.

Смотрел. Мысль не понял.

AVK>>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).

LP>Что такое декларативность? Меня всегда восхищал этот термин.

Декларативное описание отвечает на вопрос "что", императивное "как".

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

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

var data =
  OpenFile(...)
    .Take(100)
    .ToArray();

Если нужна асинхронность, то тоже берем continuation монаду (Rx), либо фьючерс (PLinq), которые с ФП вполне совместимы.

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

AVK>

AVK>var (rest, buffer) = OpenFile(...)(100);
AVK>var (nextRest, nextBuffer) = rest(...)(100);
AVK>...
AVK>

AVK>Как то так.

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

Так что никакие приседания тут не помогут. Состояние есть и с этим надо жить.

Собственно чтобы понять как же в ФП работают с файлам достаточно взглянуть на прелюд хаскеля:
http://www.haskell.org/haskellwiki/Tutorials/Programming_Haskell/String_IO#File_Handles
И что же мы видим:

    openFile     :: FilePath -> IOMode -> IO Handle
    hClose       :: Handle -> IO ()
    hGetChar     :: Handle -> IO Char
    hGetLine     :: Handle -> IO [Char]
    hGetContents :: Handle -> IO [Char]
    hPutChar     :: Handle -> Char -> IO ()
    hPutStr      :: Handle -> [Char] -> IO ()
    hPutStrLn    :: Handle -> [Char] -> IO ()
    hPrint       :: Show a => Handle -> a -> IO ()
    hSeek        :: Handle -> SeekMode -> Integer -> IO ()
    hTell        :: Handle -> IO Integer
    hFileSize    :: Handle -> IO Integer
    hIsEOF       :: Handle -> IO Bool

Здравствуй процедурное императивное программирование, завернутое в монаду IO!
Монада нужна только потому, что Хаскель ленивый язык. Для остальных ФЯ мы получим банальный C API времен Кернигана и Ричи.

VD>>Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.

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

Что? Карринг — это возможность рассматривать функцию типа (A * B) -> C как A -> (B -> C). Нужно это, в основном, для того чтобы составить из двух функций третью (частичное применение, создание комбинаторов). К стеку это вообще отношения не имеет, так как подобные операции обычно осуществятся на стадии компиляции.

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

Тогда не ясно почему ты мне оппонируешь, а не тому же Воронкову.

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

VD>> Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой.
IB>Я бы не идеализировал этот факт. По крайней мере, что такое ООП он точно не очень уверенно понимает. =)

Думаю, что с ООП у него тоже все довольно не плохо.

Здесь другая причина. Он типичный представитель людей освоивших и оценивших ФП которые после этого начали сомневаться в том, что ООП — это такая уж классная вещь.

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

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

VD>Здравствуй процедурное императивное программирование, завернутое в монаду IO!
VD>Монада нужна только потому, что Хаскель ленивый язык. Для остальных ФЯ мы получим банальный C API времен Кернигана и Ричи.

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

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

LP>>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
L>>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?

LP>Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.

Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано

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

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

C>>>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
LP>>Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
C>А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP.

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

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

AVK>Здравствуйте, LaPerouse, Вы писали:
AVK>>>Можно раскрыть мысль?
LP>>Смотри сообщение выше.
AVK>Смотрел. Мысль не понял.

Завязка на конкретную структуру данных (массив).

AVK>>>Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).
LP>>Что такое декларативность? Меня всегда восхищал этот термин.
AVK>Декларативное описание отвечает на вопрос "что", императивное "как".

Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами. Вот логическое программирование — там и в самом деле "как".

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

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

AVK>Да, чтобы не было недопонимания. То, что я показал, это баловство и извращение на тему. В реальном функциональном коде для этого используют монады. Выглядит это как то так:
AVK>

AVK>var data =
AVK>  OpenFile(...)
AVK>    .Take(100)
AVK>    .ToArray();
AVK>

AVK>Если нужна асинхронность, то тоже берем continuation монаду (Rx), либо фьючерс (PLinq), которые с ФП вполне совместимы.

Ну кто бы сомневался. Как всегда, без монады — никуда.

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

AVK>>Смотрел. Мысль не понял.

LP>Завязка на конкретную структуру данных (массив).

Хм, а как иначе? Приведи пример.

AVK>>Декларативное описание отвечает на вопрос "что", императивное "как".

LP>Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами.

ФП — является в основном, а ООП вообще ортогонально, как я уже писал.

LP> Вот логическое программирование — там и в самом деле "как".

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

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

LP>Ну кто бы сомневался. Как всегда, без монады — никуда.

А чем тебе монады не угодили?

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

-_*>Здравствуйте, LaPerouse, Вы писали:
LP>>>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
L>>>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
LP>>Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.
-_*>Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано


Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.

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

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

AVK>>>Смотрел. Мысль не понял.
LP>>Завязка на конкретную структуру данных (массив).
AVK>Хм, а как иначе? Приведи пример.

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

AVK>>>Декларативное описание отвечает на вопрос "что", императивное "как".
LP>>Из этого определения видим, что ни ФП, ни ООП не являются декларативными парадигмами.
AVK>ФП — является в основном, а ООП вообще ортогонально, как я уже писал.
LP>> Вот логическое программирование — там и в самом деле "как".
AVK>Знаешь, вот лично я к адептам единственно правильной парадигмы отношусь с очень большим подозрением. Не надо опять заводить тягомотину про всемирную коммунистическую базу знаний.

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

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

LP>Функция должна иметь в качестве возвращаемого значения универсальный интерфейс для доступа к потоку бинарных данных

Какому потоку? Массив байтов это уже считанный из потока результат.

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

AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>Ну кто бы сомневался. Как всегда, без монады — никуда.
AVK>А чем тебе монады не угодили?

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

Дальнейший спор считаю бессмысленным. Всего доброго, желаю успехов в обсуждении одного и того же в 1001-ый раз )).

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

LP>-_*>Без замыканий функции как first class sitizen рассматриваться не могут, следовательно, ФЯ не получится. Выкинь замыкания из любого языка и получишь С, Паскаль, Бейсик или Фортран с Ассемблером. Другого не дано

LP>Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.

"немного" Функтор может модифицировать кто угодно. Замыкание — легальных способов практически нет. Следовательно функтор держится исключительно на честном слове.

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

AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>Функция должна иметь в качестве возвращаемого значения универсальный интерфейс для доступа к потоку бинарных данных
AVK>Какому потоку? Массив байтов это уже считанный из потока результат.

File file = new File("filename");
BinaryStream stream = file.open();
byte[] array = BinaryDataHelper.read(stream, 100);