Re[4]: Императивная парадигма
От: Undying Россия  
Дата: 20.07.11 10:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>На самом деле ничего не мешает писать императивный код, не страдающий этими недостатками.

G>Угу, только он пишется сложнее, чем код этими недостатками обладающий.

Просто он пишется, и даже вчерашние студенты прекрасно с его написанием справляются. Проблема в другом, в том, что примеров и пиара как писать неправильно сколько угодно, а правильному подходу приходится учиться самому.
Re[3]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.11 15:44
Оценка:
Здравствуйте, Sinix, Вы писали:

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


Если есть побочные эффекты — то это уже императивный монстр .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.11 15:50
Оценка:
Здравствуйте, AlexCab, Вы писали:

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

MZ>>-- что делать
MZ>>-- как делать

AC>Упаковываем "как делать" в например процедуры и у нас остаётся только "что делать".


Если процедура не меняет ничего кроме своих параметров и возвращаемого значения, то так оно и есть. Но тогда это уже будет функциональным программированием. Если же процедура выполняет побочные эффекты, то "как делать" остается, по сути, не упакованным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Императивная парадигма
От: MasterZiv СССР  
Дата: 20.07.11 18:04
Оценка:
On 20.07.2011 2:29, Tilir wrote:

> Почему Хаскелл (скажем) так прекрасен и почему он так грубо обламывается о

> реальный мир?
> Потому что это язык программирования компов будущего. Которым достаточно будет
> сказать "деньги в бидоне".
> До тех пор советую учить C.

Даже если всё это и так, чем это мешает существованию данного топика ?
Вопрос правомочный, и на него можно дать ответ.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 04:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Если процедура не меняет ничего кроме своих параметров и возвращаемого значения, то так оно и есть. Но тогда это уже будет функциональным программированием. Если же процедура выполняет побочные эффекты, то "как делать" остается, по сути, не упакованным.


При этом ничто не мешает быть коду внутри этой функции сплошь императивным. Соответственно императивность и чистота функций совершенно ортогональные понятия.
Re[5]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.07.11 04:34
Оценка:
Здравствуйте, Undying, Вы писали:

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


VD>>Если процедура не меняет ничего кроме своих параметров и возвращаемого значения, то так оно и есть. Но тогда это уже будет функциональным программированием. Если же процедура выполняет побочные эффекты, то "как делать" остается, по сути, не упакованным.


U>При этом ничто не мешает быть коду внутри этой функции сплошь императивным. Соответственно императивность и чистота функций совершенно ортогональные понятия.

Про ортогональность верно, но до сих пор была речь о процедуре а не о функции. А кому нужна чистая процедура?
Re[6]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 05:11
Оценка: -1 :)
Здравствуйте, samius, Вы писали:

S>Про ортогональность верно, но до сих пор была речь о процедуре а не о функции. А кому нужна чистая процедура?


У Влада более широкая трактовка чистых функций:

Если процедура не меняет ничего кроме своих параметров и возвращаемого значения


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

В этом я с Владом согласен, т.к. преимущество чистых функций над функциями классов не в некоей их абстрактной чистоте, а в том, что при использовании чистых функций становится намного более понятно с какой именно частью мира функция работает и резко повышается возможность ее повторного использования. Естественно от функций классов я тоже не отказываюсь (т.к. это означало бы отказ от полиморфизма), но реализация функций классов, как правило, сводится к вызову чистых функций.
Re[4]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 21.07.11 05:56
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Если процедура не меняет ничего кроме своих параметров и возвращаемого значения, то так оно и есть. Но тогда это уже будет функциональным программированием. Если же процедура выполняет побочные эффекты, то "как делать" остается, по сути, не упакованным.

Думал ключевым отличием ИП от ФП именно в подходе к решению задачи:
ИП — последовательность операций над данными, ФП — "прохождение" данных через функции.
А процедур от функций, в способе вызова и способе передачи аргументов:
Процедуры — вызов как одна из операций в последовательности операций, данные предаются и возвращаются в/из процедуры через те же аргументы(параметры).
Функция — вызов при "поступлении" данных, данные предаются в функцию только через аргументы, возвращаются только через "возвращаемое значение".
А уж насколько процедура/функция "изолирована" дело второе, я не прав?

И второй вопрос(как к человеку разбирающемуся), допустим нам необходимо чтобы некоторое значение было известно везде в программе(например, ИД пользователя), традиционно это решается при помощи глобальной переменной, как это решается в чистом ФП?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 06:01
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>И второй вопрос(как к человеку разбирающемуся), допустим нам необходимо чтобы некоторое значение было известно везде в программе(например, ИД пользователя), традиционно это решается при помощи глобальной переменной, как это решается в чистом ФП?


Через передачу контекста.
Re[7]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.07.11 06:08
Оценка: +1
Здравствуйте, Undying, Вы писали:

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


S>>Про ортогональность верно, но до сих пор была речь о процедуре а не о функции. А кому нужна чистая процедура?


U>У Влада более широкая трактовка чистых функций:

U>

U>Если процедура не меняет ничего кроме своих параметров и возвращаемого значения


U>Т.е. чистая функция эта такая функция, для работы которой достаточно только входных параметров и ничего более. Изменять входные параметры чистая функция имеет право, соответственно чистая процедура (т.е. функция без возвращаемого значения) вполне возможна.

При всем уважении к Владу, я пользуюсь этой трактовкой http://en.wikipedia.org/wiki/Pure_function. В соответствии с ней функция не должна делать наблюдаемых side effect-ов. Изменение аргументов — это наблюдаемый side effect, значит функция, изменяющая свои входные параметры не может быть чистой по определению с вики (и не только).
Конечно, можно изменение аргументов считать формой возврата результата. Я предпочитаю не считать, т.к. если провести условную грань, то переменные, которые подаются изменяемыми аргументами выделены не телом функции и по отношению к функции являются внешними. Разница по отношению к возврату результата в том, что переменные могут быть выделены как специально для вызова функции, а могут быть и нет. Во втором случае side effect становится более явным.
В русской вики изменение параметра считается "другим видом побочных эффектов" без оговорок относительно того, считать ли "другой вид" побочным эффектом при определении чистоты функции или нет. Дальше они говорят о неявной модификации параметра this, что позволяет судить что модификация параметров и у них таки является поводом к нечистоте.
И еще, в русской вики, как и здесь, возникла путаница. Изменяется не параметр (который имеет функция), а аргумент (значение, которое передается в функцию). Выше я использовал "параметр" при упоминании русской вики, что бы эту путаницу не усугубить.

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

Нет такого противопоставления. Функции классов могут быть чистыми (смотри System.String). Фактически функция класса от функции не класса отличается лишь явностью передачи первого аргумента, который в случае функции класса неявный.
Re[8]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 07:38
Оценка:
Здравствуйте, samius, Вы писали:

U>>Т.е. чистая функция эта такая функция, для работы которой достаточно только входных параметров и ничего более. Изменять входные параметры чистая функция имеет право, соответственно чистая процедура (т.е. функция без возвращаемого значения) вполне возможна.

S>При всем уважении к Владу, я пользуюсь этой трактовкой http://en.wikipedia.org/wiki/Pure_function. В соответствии с ней функция не должна делать наблюдаемых side effect-ов. Изменение аргументов — это наблюдаемый side effect, значит функция, изменяющая свои входные параметры не может быть чистой по определению с вики (и не только).

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

S>Нет такого противопоставления. Функции классов могут быть чистыми (смотри System.String). Фактически функция класса от функции не класса отличается лишь явностью передачи первого аргумента, который в случае функции класса неявный.


Только в том случае, если мы extension сделали членом класса. В string вероятно действительно некоторые функции класса по сути являются extension'ами и были сделаны членами класса исключительно из-за того, что на момент создания языка extension'ов в нем еще не было. Впрочем есть подозрение, что большинство функций класса string на самом деле работают с внешним массивом char'ов, а не со строкой и соответственно чистыми не являются и близко.
Re[9]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.07.11 08:05
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>При всем уважении к Владу, я пользуюсь этой трактовкой http://en.wikipedia.org/wiki/Pure_function. В соответствии с ней функция не должна делать наблюдаемых side effect-ов. Изменение аргументов — это наблюдаемый side effect, значит функция, изменяющая свои входные параметры не может быть чистой по определению с вики (и не только).


U>О терминах я спорить не собираюсь. Но на практике различие между функциями, для работы которых достаточно только принимаемых аргументов, и функциями, которые обращаются к внешним переменным, много важнее, чем различие между функциями меняющими аргументы и функциями не меняющими аргументы. Если для обозначения всей совокупности функций работающих только с принимаемыми аргументами (не важных меняющих их или нет) термин "чистая функция" ты считаешь некорректным, то предложи другой термин.

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

S>>Нет такого противопоставления. Функции классов могут быть чистыми (смотри System.String). Фактически функция класса от функции не класса отличается лишь явностью передачи первого аргумента, который в случае функции класса неявный.


U>Только в том случае, если мы extension сделали членом класса.

Только в какой-то трактовке, которая мне не известна.

U>В string вероятно действительно некоторые функции класса по сути являются extension'ами и были сделаны членами класса исключительно из-за того, что на момент создания языка extension'ов в нем еще не было. Впрочем есть подозрение, что большинство функций класса string на самом деле работают с внешним массивом char'ов, а не со строкой и соответственно чистыми не являются и близко.

Делать выводы о чистоте функций следует из определения, а не из типов параметров или их явности/неявности. Ты же не будешь отрицать существование чистой функции, работающей с внешним массивом?
Re[9]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.07.11 08:53
Оценка: 3 (1)
Здравствуйте, Undying, Вы писали:

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


U>>>Т.е. чистая функция эта такая функция, для работы которой достаточно только входных параметров и ничего более. Изменять входные параметры чистая функция имеет право, соответственно чистая процедура (т.е. функция без возвращаемого значения) вполне возможна.

S>>При всем уважении к Владу, я пользуюсь этой трактовкой http://en.wikipedia.org/wiki/Pure_function. В соответствии с ней функция не должна делать наблюдаемых side effect-ов. Изменение аргументов — это наблюдаемый side effect, значит функция, изменяющая свои входные параметры не может быть чистой по определению с вики (и не только).

U>О терминах я спорить не собираюсь. Но на практике различие между функциями, для работы которых достаточно только принимаемых аргументов, и функциями, которые обращаются к внешним переменным, много важнее, чем различие между функциями меняющими аргументы и функциями не меняющими аргументы. Если для обозначения всей совокупности функций работающих только с принимаемыми аргументами (не важных меняющих их или нет) термин "чистая функция" ты считаешь некорректным, то предложи другой термин.


Это называется "детерминированность".. Детерминированность + отсутствие побочных эффектов = чистая функция.
Re[10]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 08:53
Оценка: :)
Здравствуйте, samius, Вы писали:

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


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

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


Буду отрицать. И если все же такая функция по определению из вики может быть чистой, значит, определение из вики совершенно бессмысленно с точки зрения практики, а, значит, я с ним категорически не согласен.
Re[11]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.07.11 09:00
Оценка:
Здравствуйте, Undying, Вы писали:

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


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


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

Как можно дискутировать о сути сказанного, когда под одними терминами понимаются разные вещи? Ты говоришь одно, я понимаю другое.

U>Т.к. я разъяснил, что под этими терминами понимаю и соответственно необщепринятая трактовка мною терминов не могла помешать понять суть.

Да, разъяснил. Но ощущение что говорим о разных вещах осталось.

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


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

Но чистые функции, работающие с массивами не противоречат и определению Влада. Твоего определения я не видел. Откуда ты сделал вывод что раз массив, значит нечисто — не понятно.
Re[12]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 09:43
Оценка:
Здравствуйте, samius, Вы писали:

S>Как можно дискутировать о сути сказанного, когда под одними терминами понимаются разные вещи? Ты говоришь одно, я понимаю другое.


Предлагаемый gandjustas'ом термин "детерминированная функция" понятен?

S>Но чистые функции, работающие с массивами не противоречат и определению Влада. Твоего определения я не видел. Откуда ты сделал вывод что раз массив, значит нечисто — не понятно.


Речь шла о внешнем массиве. Внешний это значит не являющийся аргументом. Как функция использующая внешние переменные может быть чистой?
Re[5]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.07.11 09:52
Оценка:
Здравствуйте, Undying, Вы писали:

U>При этом ничто не мешает быть коду внутри этой функции сплошь императивным. Соответственно императивность и чистота функций совершенно ортогональные понятия.


Локальные переменные могут быть изменяемыми. Это ни на что не влияет. Поля изменять нельзя. Фактически изменение локальных переменных это другой вид записи того же самого. Концевая рекурсия и циклы эквивалентны, так что локальные переменные спокойно можно рассматривать как параметры и вызов. Для случаев отличных от циклов можно всегда ввести новые переменные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Императивная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 21.07.11 09:52
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>Как можно дискутировать о сути сказанного, когда под одними терминами понимаются разные вещи? Ты говоришь одно, я понимаю другое.


U>Предлагаемый gandjustas'ом термин "детерминированная функция" понятен?

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

S>>Но чистые функции, работающие с массивами не противоречат и определению Влада. Твоего определения я не видел. Откуда ты сделал вывод что раз массив, значит нечисто — не понятно.


U>Речь шла о внешнем массиве. Внешний это значит не являющийся аргументом. Как функция использующая внешние переменные может быть чистой?

По общепринятому определению чистоты функции (детерминированность + отсутствие сайд эффектов) — может. Как- просто определение чистоты не накладывает органичений на отношение используемых данных к функции (внешние либо внутренние). Отсутствие сайд эффектов — это отсутствие изменений внешних данных.
Re[3]: Императивная парадигма
От: Klapaucius  
Дата: 21.07.11 09:57
Оценка: 3 (1) +2
Здравствуйте, AlexCab, Вы писали:

AC>ИМХО лет через 20-120 создадут ИИ и необходимость ЯП отпадёт принципе


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

AC>Даже когда вы пишете в функциональном стиле(хотя я считаю неправильно называть его декларативным, так как программы написанные в этом стиле всё таки описывает некоторую последовательность вычисление а не "что должно получится"(как HTML например)) наверняка думаете что то вроде "...эта функция возвращает значение, которое затем получает вот та функция..."(или как?).


Просто наличие "последовательности вычислений" это вопрос трактовки. Текст HTML-"программы" можно тоже трактовать как последовательное применение неких "конструкторов тегов". "...этот конструктор возвращает тег, который затем получает вот тот конструктор тегов..." Просто наблюдаемой разницы между такими неявными последовательностями конструирования тегов нет. Вот отсутствие такой разницы — это и есть отличие декларативности от императивности. А рассуждения про разницу между "что делать" и "как делать" бесплодны, никакой ясности они не вносят, потому что границу можно провести произвольным образом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[14]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 10:03
Оценка:
Здравствуйте, samius, Вы писали:

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


Еще в первом ответе тебе я указал для какого определения мне нужен термин:

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


Что тут может быть непонятным?

S>По общепринятому определению чистоты функции (детерминированность + отсутствие сайд эффектов) — может. Как- просто определение чистоты не накладывает органичений на отношение используемых данных к функции (внешние либо внутренние). Отсутствие сайд эффектов — это отсутствие изменений внешних данных.


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