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

ARK>Параметры функций — это никакие не "инструкции". Или что, у функций не может быть параметров?

параметры у инструкций — это не переменные, а результаты работы других функций.

ARK>Функционального программирования не существует?
Сказать по вашему, так это императивного программирования не существует: память компьютера — это эмуляция ленты Машины Тьюринга, инструкция процессора — это программа на функциональном языке, поэтому, согласно вашим словам:

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

все программы написаны на функциональном языке.
Ой, нет! Я же забыл про регистры процессора! Это в корне всё меняет!

ARK>Так вот, смоделировать машину Тьюринга в ФП можно передачей ленты через параметры. Это не императивное программирование, а значения параметров — не состояние программы.

Если данные записанные на ленте Машины Тьюринга не состояние программы, то что же тогда состояние программы?

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

BFE>>Представим, что у нас есть вот такая задача:
BFE>>написать программу, которая читает байты из канала для чтения и записывает их на устройство для записи. Условия следующие:
BFE>>- устройство для записи записывает 1 байт за секунду;
BFE>>- канал для чтения позволяет считать один байт за одну миллисекунду;
BFE>>- в канале для чтения есть буфер хранящий не более 5 байт;
BFE>>- данные в канал для чтения поступают неравномерно, но известно, что:
BFE>>-- в канал для чтения в секунду поступает не более 10 байт;
BFE>>-- в канал для чтения за час поступает не более 3600 байт.
S>Здесь нет слова "хранить". Внезапно, ничего хранить не надо.

BFE>>Можно эту задачу реализовать на функциональном языке программирования так, чтобы никакая часть реализации не содержала реализацию на императивном языке?
S>Не вопрос. Уж что-что, а байты перепихнуть из одного в другое через очередь... Одна оговорка. Уровень взаимодействия с устройством и каналом, видимо, останется за скобками.

Ну да, при функциональном подходе у вас есть функция read, функция write, допустим ещё функцию time, если она вам нужна, а вот очереди у вас нет.


ЗЫ (Я так подозреваю, что даже если допустить имплементацию стека вызовов функций на императивном языке, то всё равно решить задачу не получится)

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

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

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

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

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

I>>>Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.

PJ>>Все это никакого отношения к полиморфизму не имеет. samius правильно тебе говорит — полоиморфизм он про типы, по определению. А у тебя есть некая интерпретация данных.

I>Все это тривиальная прикладная задача на полиморфизм, а именно — надо написать функцию, которая обрабатывает данные разных типов. Вот это и есть определение полиморфизма.

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

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

GZ>>>Я не большой эксперт чтобы говорить о type driven, потому что не щупал ручками. Поэтому говорить не могу хоть и подозреваю на аналогичные инструменты.
PJ>>Ты же сказал, что занимался ФП?!
GZ>А type driven — не свойство ФП насколько я его понял.
Нет, формально ничего не мешает его использовать на любом языке со строго типизацией. В реальности это настолько многословно и убого, что не имеет практического смысла. И наоборот, если используется ФЯ со строгой типизацией, то TDD просто идеально ложиться на язык. Все решение сводится к

• identify data invariant
  
• check invariant with types
  
• prove your code repects the invariants (using more types)
  
• repeat

PJ>>Это не круче, это те же яйца вид в профиль. Именованость не дает ничего от слова совсем.
GZ>Она дает читабельность. Особенно в условиях IDE.
Ничего оно не дает. Читабельность дают типы, потому что им можно верить. А что там за забором лежит непонятно, не проверив реализацию. Как, в принципе, и с любой функцией, если она не чистая.

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

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

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

BFE>Ну да, при функциональном подходе у вас есть функция read, функция write, допустим ещё функцию time, если она вам нужна, а вот очереди у вас нет.
С каких пор в фп нет очереди? Не, ну список есть, а очереди — нет?! Как так?


BFE>ЗЫ (Я так подозреваю, что даже если допустить имплементацию стека вызовов функций на императивном языке, то всё равно решить задачу не получится)
Есть веские причины подозревать? Кроме отрицания наличия очереди в фп, разумеется...

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

ARK>>Параметры функций — это никакие не "инструкции". Или что, у функций не может быть параметров?
BFE>параметры у инструкций — это не переменные, а результаты работы других функций.

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

BFE>Сказать по вашему, так это императивного программирования не существует: память компьютера — это эмуляция ленты Машины Тьюринга, инструкция процессора — это программа на функциональном языке, поэтому, согласно вашим словам:
BFE>

BFE>Новое состояние ленты передается в каждый последующий шаг алгоритма входным параметром. Тот, в свою очередь, конструирует очередное состояние и передает дальше.

BFE>все программы написаны на функциональном языке.

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

ARK>>Так вот, смоделировать машину Тьюринга в ФП можно передачей ленты через параметры. Это не императивное программирование, а значения параметров — не состояние программы.
BFE>Если данные записанные на ленте Машины Тьюринга не состояние программы, то что же тогда состояние программы?

Смотря в каком смысле понимать этот термин. Это может быть срез памяти компьютера в некоторый момент времени. Или набор переменных, гарантированно существующих во время жизни программы. Или еще что-то.

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

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

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

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

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

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

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

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

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

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

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

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

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

ARK>Правильный функциональный язык — на поверхностном уровне — ДОЛЖЕН мимикрировать под C/Pascal!!! Без этого базового требования рыночная доля функциональщины никогда не выйдет за маргинальные пределы, в которых она и находится последние 60 с хреном лет, начиная с изобретения лиспа.

Prolog вроде бы достаточно близок синтаксически, однако популярности это не снискало

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

ARK>>Правильный функциональный язык — на поверхностном уровне — ДОЛЖЕН мимикрировать под C/Pascal!!! Без этого базового требования рыночная доля функциональщины никогда не выйдет за маргинальные пределы, в которых она и находится последние 60 с хреном лет, начиная с изобретения лиспа.

MD>Prolog вроде бы достаточно близок синтаксически, однако популярности это не снискало

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

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

H>Надоели фанатики. Инструмент надо брать под задачу, а не молотком сверлить стены.

Молоток замечательно сверлит стену, надо лишь правильно автоматизировать процесс. Ведь перфоратор — по своей сути это именно молоток, а не дрель со сверлом по бетону, как может показаться.

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

Полностью согласен с основными тезисами.
Синтаксис ФП-языка важен, но не думаю, что С/паскаль идеальны.
Для примера возьмем 3-ти ФП языка:
1 Nemerle

def calc() { 42 }
//or 
def calc = fun () { 42 }

2 F#

let calc () 
    42
// or
let calc = fun () -> 42

3 Iron Scheme

;(define (calc) 42)
;or
(define calc (lambda () 42))
(calc); print 42

Как менее противоричивый, а значит менее подверженный ошибкам следовало бы выбрать язык S-выражений.
В качестве доказательства позвольте еще кусочек кода на F#

(calc ()) //val it : int = 42
2 + 2 // val it : int = 4
((+) 2 2) //val it : int = 4

Обратите внимание, что в F# заложена изначально идея вызова любого выражения слева направо, (+) применяется к своим аргументам, точно также как и calc применяется к () как к пустому множеству аргументов.
Исчезает двойственность и противоречивость си-подобных языков в которых нужно следить за порядком следования операторов.

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

AA>Как менее противоричивый, а значит менее подверженный ошибкам следовало бы выбрать язык S-выражений.
AA>В качестве доказательства позвольте еще кусочек кода на F#
AA>Обратите внимание, что в F# заложена изначально идея вызова любого выражения слева направо, (+) применяется к своим аргументам, точно также как и calc применяется к () как к пустому множеству аргументов.
AA>Исчезает двойственность и противоречивость си-подобных языков в которых нужно следить за порядком следования операторов.

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

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

AA>Полностью согласен с основными тезисами.
AA>Синтаксис ФП-языка важен, но не думаю, что С/паскаль идеальны.
AA>Для примера возьмем 3-ти ФП языка:

На таком микропримере можно показать что угодно, тем более что есть процедурные языки, в которых можно тоже писать в духе fn calc() { 42 } (Rust, Swift, много их).
Что-то более существенное будет?

AA>Обратите внимание, что в F# заложена изначально идея вызова любого выражения слева направо, (+) применяется к своим аргументам, точно также как и calc применяется к () как к пустому множеству аргументов.
AA>Исчезает двойственность и противоречивость си-подобных языков в которых нужно следить за порядком следования операторов.

В чём это "надо следить"?
Если "следить" это понимать, что в f(g(x)) сначала вычисляется g, а потом f, то это очевидно и неинтересно.
Если же то, что f(a,b) будет вычислять сначала a, потом b (или наоборот), то это намеренная недооптимизация и, наоборот, внесение процедурности там, где оно не нужно и даже в ИП не всегда используется.
/dev/telepathy сломался, расшифровывайте, если хотите быть понятыми.

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

PJ>>>Все это никакого отношения к полиморфизму не имеет. samius правильно тебе говорит — полоиморфизм он про типы, по определению. А у тебя есть некая интерпретация данных.

I>>Все это тривиальная прикладная задача на полиморфизм, а именно — надо написать функцию, которая обрабатывает данные разных типов. Вот это и есть определение полиморфизма.

PJ>Определение полиморфизма можешь прочитать в любом словаре, хоть на википедии. Нафига выдумывать какой-то новояз непонятно совершенно. У тебя задача не обработки разных типов, поскольку у тебя нет никаких типов, разработчик интерпретирует данные по своему желанию. Если ты это выдаешь за силу oop, то это вообще

Не возражаешь, если тогда википедию процитирую ? "Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов"

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

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

s> S>>Только так и получится. Изменяемых структур данных в чистом ФП нет.
s> BFE>Оцените, пожалуйста, размер такой структуры для буфера длиной в 1024 байт.
s> От 1024 байт, зависит от размера чанков.
Размер чанков в общем случае будет минимальный, т.е. 1 байт. И такой буфер станет бессмысленным.

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

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

I>Не возражаешь, если тогда википедию процитирую ? "Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов"

Да ради бога, может хоть сам прочитаешь.

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

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