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

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

s>> BFE>Оцените, пожалуйста, размер такой структуры для буфера длиной в 1024 байт.
s>> От 1024 байт, зависит от размера чанков.
·>Размер чанков в общем случае будет минимальный, т.е. 1 байт. И такой буфер станет бессмысленным.
Не вижу смысла ограничивать размер чанков в общем случае. Может 1 байт и может 1024 байта. Может и больше. И почему 1 байт бессмысленный, если по условию задачи прилетает 1 байт не чаще чем в секунду? Для этой задачи нет смысла заводить больше.

·>Мне кажется, что он имеет в виду немного другое. Полнота по Тьюрингу ещё не означает практической применимости. Один и тот же алгоритм, реализованный на МТ и на Алгорифме Маркова может решать ту же задачу, но иметь совершенно разную алгоритмическую сложность. Так и ФП vs ПП (или ООП) может для одной и той же задачи подразумевать разную алг-сложность. Какой смысл заводить буфер, если он потребует дохрена памяти и времени. А т.к. наши физические железки работают очень похоже на МТ (точнее РАМ), то и программирование в таком стиле практически оказывается более эффективно по ресурсам, т.к. приближено к реальному железу. Другое дело, ресурсы иногда дёшевы, не всегда являются ограничением и ФП может понадобится для уменьшения сложности для восприятия человеком.

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

Далее. Разная алгоритмическая сложность для решения одной задачи в рамках разных парадигм — такое вполне возможно, это бывает. Но для решения конкретной задачи — я не вижу просадки по сложности. Есть реализации неизменяемой очереди с константным доступом. У Окасаки описана и я такую делал, правда, на C#. Так почему же должно быть ухудшение сложности относительно ООП?

Но даже если использовать для этой задачи наивную реализацию очереди на основе односвязного списка с алгоритмической сложностью O(n), то я не вижу тут серьезной просадки при максимальном заполнении очереди в 5 элементов.

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

PJ>Не, у тебя задача, в во всяком случае как ты ее описал, это десереализация, в лучшем случае. Так как никаких типов у данных нет. Соответственно полиморфизм там вообще не причем. Зачем ты настаиваешь на своих доморощенных определениях?

А что у тебя после десериализации ? И как вызвать правильный toString ?

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

S>Порождать функции можно динамически, в процессе вычислений.
S>Т.е. можно вернуть из функции число 42, а можно вернуть функцию, которая вернёт число 42.
S>Так и делаются вещи типа буферов и хранения состояния — конструируется функция, возвращающая функцию, возвращающую функцию и т.п.

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

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

S>>>Буфер можно организовать в самой программе на фя. Не нужно никакое постороннее устройство ей.
BFE>>Как это сделать?
S>В параметрах.
Странно. Я так полагаю, что в чистом ФЯ нет параметров, а есть только аргументы.

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

S>Порождать функции можно динамически, в процессе вычислений.
S>Т.е. можно вернуть из функции число 42, а можно вернуть функцию, которая вернёт число 42.

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

S>Так и делаются вещи типа буферов и хранения состояния — конструируется функция, возвращающая функцию, возвращающую функцию и т.п.
Буфер и вещь типа буфера — это не одно и тоже.

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

S>С каких пор в фп нет очереди?
С самого начала.

S>Не, ну список есть, а очереди — нет?!
И списка нет.

S>Как так?
Есть только тот или иной порядок работы с параметрами, который условно можно понимать как очередь, список и т.д..

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

S>>Оне все будут к int'у приводится перед печатью, почему нет? Ну т.е. енто не будет ToString(HouseNumber hn), а будет ToString(int hn) для типа HouseNumber. Енто, конечно, нарушает типизацию и инкапсуляцию, поскольку детали лезут наружу...
S>Тип HouseNumber в точности есть int. Это расположенные в int значения номеров домов. И только лишь.

HouseNumber и есть тип. Ты просто привык использовать язык, где такие вещи будут совместимы по присваиванию с int. А если язык умеет нормальные типы, то int нельзя записать в HouseNumber.
На самом деле тип это не только и не столько данные, сколько операции, которые определены для эти данных. С интом нормально выполнять битовые, арифметические и какие угодно операции. А вот выполнять битовые операции над номерами домов мягко говоря смысла нет. Следовательно — тип другой.

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

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

S>>С каких пор в фп нет очереди?
BFE>С самого начала.

S>>Не, ну список есть, а очереди — нет?!
BFE>И списка нет.

Заявления такой степени абсурда, что их и опровергать как-то неудобно даже.

S>>Как так?
BFE>Есть только тот или иной порядок работы с параметрами, который условно можно понимать как очередь, список и т.д..

Этот пассаж, боюсь, не понял. Переводить не нужно.

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

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

S>>>Оне все будут к int'у приводится перед печатью, почему нет? Ну т.е. енто не будет ToString(HouseNumber hn), а будет ToString(int hn) для типа HouseNumber. Енто, конечно, нарушает типизацию и инкапсуляцию, поскольку детали лезут наружу...
S>>Тип HouseNumber в точности есть int. Это расположенные в int значения номеров домов. И только лишь.

I>HouseNumber и есть тип. Ты просто привык использовать язык, где такие вещи будут совместимы по присваиванию с int. А если язык умеет нормальные типы, то int нельзя записать в HouseNumber.
Так если это другой тип на уровне языка, то другое дело. Тогда, вероятно, можно создавать перегрузки toString с этим типом. Я же не против.
I>На самом деле тип это не только и не столько данные, сколько операции, которые определены для эти данных. С интом нормально выполнять битовые, арифметические и какие угодно операции. А вот выполнять битовые операции над номерами домов мягко говоря смысла нет. Следовательно — тип другой.

Не затруднит назвать язык в ПП парадигме с такой системой типов?

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

S>>>>Форматирование строки может быть разным, поэтому не одиноково.
S>>>Тогда это будет toString(int value, string format). Но причем тут полиморфизм?

S>>С чего это будет так? Это будет toString(int value) и каждый тип будет по своему печать соотв. инф-ию, отсюда и полиморфизм. Интерфейс один, реализации разные.
S>Для других типов (не int) все понятно. Но тут речь-то как раз о "типах", всунутых в тот же самый int, таких как HouseNumber. Вот для них отдельный toString(HouseNumber) определить не получится на уровне языка, который, как правило не допускает определять несколько перегрузок функции для типа int

Мне, как разработчику, удобно определить килограммы, метры, штуки, секунды и тд. И язык не допускает присваивания секунды в килограммы, а метры в номера домов. Соответсвенно и toString работает соответственно. А унутре каждого — int. И размер типа — как у int.

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

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

I>Здравствуйте, Poopy Joe, Вы писали:

PJ>>Не, у тебя задача, в во всяком случае как ты ее описал, это десереализация, в лучшем случае. Так как никаких типов у данных нет. Соответственно полиморфизм там вообще не причем. Зачем ты настаиваешь на своих доморощенных определениях?

I>А что у тебя после десериализации ? И как вызвать правильный toString ?

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

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

ARK>Хорошо. Так можно ли вызвать одну функцию из другой и передать ей какие-нибудь данные? Это не противоречит основам функционального программирования?
Зависит от того, что понимать под данными. Функция переданная в качестве аргумента является данным или нет?

BFE>>Сказать по вашему, так это императивного программирования не существует: память компьютера — это эмуляция ленты Машины Тьюринга, инструкция процессора — это программа на функциональном языке,
ARK>Почему же, в императивной программе состояние может храниться и извне функций.
Да, может. Но я не понял к чему это написано.

BFE>>Если данные записанные на ленте Машины Тьюринга не состояние программы, то что же тогда состояние программы?
ARK>Смотря в каком смысле понимать этот термин. Это может быть срез памяти компьютера в некоторый момент времени. Или набор переменных, гарантированно существующих во время жизни программы. Или еще что-то.

Рассмотрим две программы которые спрашивают у пользователя два числа и выдают результатом их сумму. Одна программа написана на функциональном языке, а другая на императивном. Принципиальная разница между ними следующая: программа написанная на функциональном языке не помнит своего предыдущего состояния и на два заданных числа всегда выдаёт их сумму, а программа написанная на императивном языке может помнить что было раньше и выдавать сумму всех когда либо поданных на ввод чисел, а не только двух последних.

ARK>Однако, ИМХО, абслютно очевидно, что ФП немыслимо без параметров функций. А, значит, через них можно передавать состояние.
Через ФП можно передать состояние.

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

Z>И ведь до объектно-ориентированного подхода, были и есть процедурные языки,
Z>да там было можно использовать глобальные переменные, но в сложных программах этим не злоупотребляли,
Z>то есть был совершенно тот же подход процедура(функция) принимает на вход данных,
Z>считает и выдает не меняя глобальное состояние,

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

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

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

Вроде бы любой динамический подойдет, разве нет?

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

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

S>>Не затруднит назвать язык в ПП парадигме с такой системой типов?

S>Вроде бы любой динамический подойдет, разве нет?
Динамический с перегрузкой функций по типу аргумента? Это был бы интересный зверь.

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

S>>>>Оне все будут к int'у приводится перед печатью, почему нет? Ну т.е. енто не будет ToString(HouseNumber hn), а будет ToString(int hn) для типа HouseNumber. Енто, конечно, нарушает типизацию и инкапсуляцию, поскольку детали лезут наружу...
S>>>Тип HouseNumber в точности есть int. Это расположенные в int значения номеров домов. И только лишь.

I>>HouseNumber и есть тип. Ты просто привык использовать язык, где такие вещи будут совместимы по присваиванию с int. А если язык умеет нормальные типы, то int нельзя записать в HouseNumber.
S>Так если это другой тип на уровне языка, то другое дело. Тогда, вероятно, можно создавать перегрузки toString с этим типом. Я же не против.
I>>На самом деле тип это не только и не столько данные, сколько операции, которые определены для эти данных. С интом нормально выполнять битовые, арифметические и какие угодно операции. А вот выполнять битовые операции над номерами домов мягко говоря смысла нет. Следовательно — тип другой.

S>Не затруднит назвать язык в ПП парадигме с такой системой типов?

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

Если ты настаиваешь на "в пп парадигме" то, например, язык Си. Надеюсь он достаточно процедурный ?

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

S>>Вроде бы любой динамический подойдет, разве нет?
S>Динамический с перегрузкой функций по типу аргумента? Это был бы интересный зверь.

Не понял что имеется в виду, но я говорил про duck typing.

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

S>·>Размер чанков в общем случае будет минимальный, т.е. 1 байт. И такой буфер станет бессмысленным.
S>Не вижу смысла ограничивать размер чанков в общем случае. Может 1 байт и может 1024 байта. Может и больше. И почему 1 байт бессмысленный, если по условию задачи прилетает 1 байт не чаще чем в секунду? Для этой задачи нет смысла заводить больше.
Если тебе прилетают байты по 1024 штуки, то буфер не нужен. Если тебе прилетают байты по одной штуке, то чанк в буфере должен быть такого же размера или у тебя будет пухнуть память и такой буфер будет только вреден.

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

S>Далее. Разная алгоритмическая сложность для решения одной задачи в рамках разных парадигм — такое вполне возможно, это бывает. Но для решения конкретной задачи — я не вижу просадки по сложности. Есть реализации неизменяемой очереди с константным доступом. У Окасаки описана и я такую делал, правда, на C#. Так почему же должно быть ухудшение сложности относительно ООП?
А когда буфер освободится, как его переиспользовать?

S>Но даже если использовать для этой задачи наивную реализацию очереди на основе односвязного списка с алгоритмической сложностью O(n), то я не вижу тут серьезной просадки при максимальном заполнении очереди в 5 элементов.
У тебя смешались люди, кони. Ты уж либо о конкретном числе говори, либо о O-нотации. Если у тебя макс N элементов, то алгоритм имеет сложность O(1), по определению.

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

I>Нету языков "в пп парадигме". У языков общего назначения всегда минимум две парадигмы — одна для вычислений, императивное, функциональное, логическое, а вторая для структурирования, управления сложностью — процедурное, модульное, ооп. Всё что про типы — это про структурирование, а не функциональщину. Соответсвенно самые распрекрасные функциональные языки на поверку используют и процедурную, и модульную, и оо парадигмы.

Какая чушь. Вся теория категорий это про трансформацию типов. Ну почитай ты хоть чуть-чуть про ФП-то...

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

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

S>>Не затруднит назвать язык в ПП парадигме с такой системой типов?

I>Если ты настаиваешь на "в пп парадигме" то, например, язык Си. Надеюсь он достаточно процедурный ?
Ок, покажи, как в Си объявить целый HouseNumber, что бы был несовместим со встроенными целыми и позволял бы использовать перегрузку отличную от целых Key/Index и т.п.

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

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

S>>>Вроде бы любой динамический подойдет, разве нет?
S>>Динамический с перегрузкой функций по типу аргумента? Это был бы интересный зверь.

S>Не понял что имеется в виду, но я говорил про duck typing.
duck typing — хорошо. Но это ближе к объектам, чем к процедурам.
Я о том, что можно вызвать процедуру, если она привязана к типу или инстансу. Но найти среди множества процедур ту, которая подойдет данному инстансу без привязки — та еще задача.