Императивная парадигма
От: AlexCab LinkedIn
Дата: 19.07.11 10:52
Оценка:
Много рас здесь встречал высказывания типа "императивный код — фее..."
Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re: Императивная парадигма
От: Undying Россия  
Дата: 19.07.11 11:18
Оценка: 1 (1) +3 -1 :))) :))
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

Ничем не плох, просто по маркетинговым причинам временно вышел из моды.
Re: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 11:52
Оценка: 1 (1) +2 :)
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

1)Императивный код часто неявно оперирует состоянием, бывает сложно отследить что на самом деле происходит
2)Императивный код сильно зависит от порядка вычислений, что ограничивает возможности декомпозиции и композиции программ
3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям
Re[2]: Императивная парадигма
От: Sinix  
Дата: 19.07.11 12:28
Оценка: 3 (1) +6 :))
Здравствуйте, gandjustas, Вы писали:

G>1)...


На самом деле ничего не мешает писать императивный код, не страдающий этими недостатками. Другое дело, что мало кто этим заморачивается. И, напротив, не так уж сложно получить на чистом ФП монстра с тонной побочных эффектов протаскиваемым состоянием.
Re[3]: Императивная парадигма
От: Jack128  
Дата: 19.07.11 12:49
Оценка: +2
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


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


дело не в том, что можно, дело в том, что (по крайней мере в haskell'е) — это протаскиваемое состояние будет явно выражено в типах функций.
Re: Императивная парадигма
От: 0x7be СССР  
Дата: 19.07.11 12:56
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?
Любая парадигма или идеология в программировании — это всего лишь инструмент, который надо грамотно применять или не применять.
Re: Императивная парадигма
От: MasterZiv СССР  
Дата: 19.07.11 13:03
Оценка:
On 19.07.2011 14:52, AlexCab wrote:

> Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или

> делаем), чем по вашему мнению он плох применительно к программированию?

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

В императивном коде вторая составляющая существенна, в декларативном она
либо вообще отсутствует, либо сведена к минимуму. Когда человек читает
код, ему естественно нужно держать в голове две эти составляющие, и
вторая -- это в общем-то мусор, лишняя информация. Она мешает читать код.
А особенно если какой-то старый код типа Fortran-а с арифметическими IF-ами,
то это всё превращается вообще в криптографию какую-то.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Императивная парадигма
От: Sharov Россия  
Дата: 19.07.11 13:43
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

Разъясните, пожалуйста, по поводу данного пункта, т.к. мне казалось, что абстракции в контексте ООП как раз таки придают гибкость.
Кодом людям нужно помогать!
Re[3]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 19.07.11 14:12
Оценка: +2 -1 :))
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


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

Очень даже кое-что мешает. Например, отсутствие хвостовой рекурсии в некоторых языках/платформах.

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

Ради побочных эффектов и пишут программы. Программа, которая не "портит" консоль, рабочий стол, БД либо весь остальной мир — большая редкость.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 19:28
Оценка: +2 :)
Здравствуйте, Sinix, Вы писали:

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


G>>1)...


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


Угу, только он пишется сложнее, чем код этими недостатками обладающий.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.11 19:34
Оценка:
Здравствуйте, Sharov, Вы писали:

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



G>>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

S>Разъясните, пожалуйста, по поводу данного пункта, т.к. мне казалось, что абстракции в контексте ООП как раз таки придают гибкость.

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

Например можно взглянуть на Linq vs циклы. Циклы — более императивный код, чем linq. Linq задает не порядок выполнения, а форму результата, поэтому linq можно применять и к событиям, и к базам данных и к несуществующим данными (linq to z3).
Re: Императивная парадигма
От: Tilir Россия http://tilir.livejournal.com
Дата: 19.07.11 22:29
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

С сугубо философской точки зрения, парадигма зависит от сложности системы и её способностей вас понимать.
Если вы пишете программу... ну скажем для станка с ЧПУ Мне как-то приходилось. Там же в общем-то довольно естественное и простое программирование. У вас есть деталь и вы должны её обработать. Поэтому программа выглядит там примерно так: "вот эту фигню на пять сантиметров вправо. так. теперь вот этой фигне на пятьсот оборотов в секунду больше. так. теперь поверни это на пять градусов вокруг оси Y..."
Теперь представьте что вы -- любящий папа. С утра уходите на работу и оставляете сыну записку "сходи за молоком, деньги в бидоне". Это декларативный алгоритм. Считается, что всё остальное ваш сын уже знает и умеет.
Увы, компьютер это ребёнок-даун. Аутист. Дифуры решать умеет, а вот за молоком ему нужно пояснять "возьми бидон с деньгами, дойди до двери, поверни ручку..." при этом "дверь", "ручка" и "бидон" это переиспользуемые библиотечные абстракции. Это ООП (и та же императивщина, конечно).
Почему Хаскелл (скажем) так прекрасен и почему он так грубо обламывается о реальный мир?
Потому что это язык программирования компов будущего. Которым достаточно будет сказать "деньги в бидоне".
До тех пор советую учить C.
Re[4]: Императивная парадигма
От: Sharov Россия  
Дата: 20.07.11 06:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да, но эти самые абстракции больше описывают сам результат, а не последовательность шагов по его получению.


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

G>Например можно взглянуть на Linq vs циклы. Циклы — более императивный код, чем linq. Linq задает не порядок выполнения, а форму результата, поэтому linq можно применять и к событиям, и к базам данных и к несуществующим данными (linq to z3).


Linq, на мой взгляд, является примером очень удачной абстракции.

Это я к тому, что благодаря абстракциям гибкость в императивном коде и достигается.
Кодом людям нужно помогать!
Re[5]: Императивная парадигма
От: Jack128  
Дата: 20.07.11 06:44
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Это я к тому, что благодаря абстракциям гибкость в императивном коде и достигается.


с помощью абстракции достигается гибкость в ЛЮБОЙ парадигме программирования. Императив тут не причем.
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:49
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:
G>1)Императивный код часто неявно оперирует состоянием, бывает сложно отследить что на самом деле происходит
Инкапсуляция и ограничения.
G>2)Императивный код сильно зависит от порядка вычислений, что ограничивает возможности декомпозиции и композиции программ
Структурирование.
G>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям
С повышением абстрации не престаёт быть императивным(то есть это всё таже последоватльнось действий).

Думаю это проблемы реализации(конкретного ЯП), а не самого подхода.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Императивная парадигма
От: Sharov Россия  
Дата: 20.07.11 06:52
Оценка:
Здравствуйте, Jack128, Вы писали:

J>с помощью абстракции достигается гибкость в ЛЮБОЙ парадигме программирования. Императив тут не причем.


Совершенно верно, но и злоупотреблять ими особо тоже не нужно.
Кстати по теме абстракции неплохо говорит Дейкстра в своей лекции на приемию Тьюринга.
Кодом людям нужно помогать!
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:52
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:
MZ>-- что делать
MZ>-- как делать

Упаковываем "как делать" в например процедуры и у нас остаётся только "что делать".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 20.07.11 06:57
Оценка:
Здравствуйте, Tilir, Вы писали:
T>Теперь представьте что вы -- любящий папа. С утра уходите на работу и оставляете сыну записку "сходи за молоком, деньги в бидоне". Это декларативный алгоритм. Считается, что всё остальное ваш сын уже знает и умеет.
сходи за молоком(деньги в бидоне)
T>Потому что это язык программирования компов будущего. Которым достаточно будет сказать "деньги в бидоне".
ИМХО лет через 20-120 создадут ИИ и необходимость ЯП отпадёт принципе(даже для простых вещей вроде ЧПУ программ, зачем программировать в ручную если можно поручить машине), а до тех пор "декларативный язык программирования общего назначения" останется мечтой.

Даже когда вы пишете в функциональном стиле(хотя я считаю неправильно называть его декларативным, так как программы написанные в этом стиле всё таки описывает некоторую последовательность вычисление а не "что должно получится"(как HTML например)) наверняка думаете что то вроде "...эта функция возвращает значение, которое затем получает вот та функция..."(или как?).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.11 09:29
Оценка:
Здравствуйте, AlexCab, Вы писали:

G>>3)Императивный код при повышения уровня абстракции быстро теряет гибкость, появляется необходимость переходить к более декларативным конструкциям

AC> С повышением абстрации не престаёт быть императивным(то есть это всё таже последоватльнось действий).

Именно перестает.
Список классов разных уровней абстракции: Socket, TcpClient, HttpWebRequest, WebClient. Первый в этой цепочке исключительно императивен: послать байты\прочитать байты, последний декларативен, загрузить url в виде строки. О том как оно загружается мы не знаем и слабо можем влиять на последовательность действий. Внутри класса webclient происходит обработка редиректов, кодировок, кеширования итп.

Если пытаться управлять императивной частью запроса, то нужно выставить миллион параметров. Например HttpWebRequest этим страдает.

AC>Думаю это проблемы реализации(конкретного ЯП), а не самого подхода.

Это как раз от ЯП мало зависит, больше зависит от того как писать. Даже на haskell можно все завернуть в IO монаду.
Re[3]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.11 09:30
Оценка: +1
Здравствуйте, AlexCab, Вы писали:

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

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

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


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

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

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

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

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


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

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

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

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


Если процедура не меняет ничего кроме своих параметров и возвращаемого значения, то так оно и есть. Но тогда это уже будет функциональным программированием. Если же процедура выполняет побочные эффекты, то "как делать" остается, по сути, не упакованным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
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>При этом ничто не мешает быть коду внутри этой функции сплошь императивным. Соответственно императивность и чистота функций совершенно ортогональные понятия.


Локальные переменные могут быть изменяемыми. Это ни на что не влияет. Поля изменять нельзя. Фактически изменение локальных переменных это другой вид записи того же самого. Концевая рекурсия и циклы эквивалентны, так что локальные переменные спокойно можно рассматривать как параметры и вызов. Для случаев отличных от циклов можно всегда ввести новые переменные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
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>По общепринятому определению чистоты функции (детерминированность + отсутствие сайд эффектов) — может. Как- просто определение чистоты не накладывает органичений на отношение используемых данных к функции (внешние либо внутренние). Отсутствие сайд эффектов — это отсутствие изменений внешних данных.


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

AC>Думал ключевым отличием ИП от ФП именно в подходе к решению задачи:

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

Не прав. Как раз детали передачи данных — дело второе. Главное как раз наличие или отсутствие побочных эффектов. В этом суть. Общая идя может быть описана так:
1. ИП — деструктивное изменение данных.
2. ФП — преобразование (с копированием) данных.

ФП даен некоторые гарантии надежности. По этому оно и имеет преимущество. Но то самое копирование является недостатком с точки зрения производительности.

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

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


Никак. Для чистого ФП нужно все данные передавать в качестве параметров. Если данные неизменяемые их можно сделать глобальными, но изменяемые — нет.

Решением проблемы является передача сложных структур данных или смешивание ИП и ФП.
Скажу по секрету, что даже самый пуриски-чистый ФЯ — Хаскель, на самом деле поддерживает ИП, и оно частенько в нем применяется. Только в случае Хаскеля ИП выделяется в монады.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[15]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 10:09
Оценка:
Здравствуйте, Undying, Вы писали:

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


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


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


U>

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

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

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

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


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

Я же тебе написал, что детерминированность функции к незименности переменных отношения не имеет. Или давай сюда своё собственное определение детерминированности.
Re[6]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 10:15
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


AC>>А уж насколько процедура/функция "изолирована" дело второе, я не прав?


VD>Не прав. Как раз детали передачи данных — дело второе. Главное как раз наличие или отсутствие побочных эффектов. В этом суть. Общая идя может быть описана так:

VD>1. ИП — деструктивное изменение данных.
VD>2. ФП — преобразование (с копированием) данных.

VD>Скажу по секрету, что даже самый пуриски-чистый ФЯ — Хаскель, на самом деле поддерживает ИП, и оно частенько в нем применяется. Только в случае Хаскеля ИП выделяется в монады.

Если под ИП подразумевать "деструктивное изменение данных", то хаскель с монадами к этому отношения не имеет.
Re[16]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 10:26
Оценка:
Здравствуйте, samius, Вы писали:

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


U>>

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


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


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

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


Детерминированная функция это такая функция, результат работы которой определяется только ее аргументами и ничем более.
Re[17]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 10:39
Оценка:
Здравствуйте, Undying, Вы писали:

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


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


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


Это было не дискутирование, а выяснение значений терминов, которые ты употребляешь. Без этого смысл всякого дискутирования стремится к нулю. Да, кстати, я замаялся разжевывать

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


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


Это определение более менее похоже на общепринятое. Но из контекста твоего поста

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

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

можно сделать предположение, что функция, вычисляющая сумму элементов массива не может являться детерминированной. Ладно с массивом, длина односвязного списка — тоже, т.к. узлы списка — это внешние по отношению к функции данные, не являющиеся аргументом (кроме одного).
Из твоей трактовки детерминированности вытекает что значительная часть функций ФП недетерминирована. Не видишь противоречий?
Re[7]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.07.11 10:41
Оценка:
Здравствуйте, samius, Вы писали:

S>Если под ИП подразумевать "деструктивное изменение данных", то хаскель с монадами к этому отношения не имеет.


Имеется в виду создание любых побочных эффекто, а не только изменение данных. Так что еще как имеет. Иначе это был бы сфероконь вакуумный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[8]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 11:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>>Если под ИП подразумевать "деструктивное изменение данных", то хаскель с монадами к этому отношения не имеет.


VD>Имеется в виду создание любых побочных эффекто, а не только изменение данных. Так что еще как имеет. Иначе это был бы сфероконь вакуумный.

Так согласен. Только за работу с побочными эффектами отвечают лишь некоторые из монад.
Re[7]: Императивная парадигма
От: Klapaucius  
Дата: 21.07.11 11:20
Оценка: +1
Здравствуйте, samius, Вы писали:

S>Если под ИП подразумевать "деструктивное изменение данных", то хаскель с монадами к этому отношения не имеет.


Ну почему не имеет? Вот, например, быстрая сортировка массива:
iqsort :: (Vector v a, Ord a) => v a -> v a
iqsort = modify iqsort' where
    iqsort' xs  | len < 2   = return ()
                | otherwise = do
                    p <- xs `M.read` (len `div` 2)
                    m <- M.unstablePartition (< p) xs
                    iqsort' $ M.slice 0     m         xs
                    iqsort' $ M.slice (m+1) (len-m-1) xs
                where len = M.length xs

Процедура iqsort' деструктивно изменяет массив, все императивное программирование внутри монады ST, функция iqsort чистая, никаких сайд-эффектов.
... << 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[18]: Императивная парадигма
От: Undying Россия  
Дата: 21.07.11 11:52
Оценка:
Здравствуйте, samius, Вы писали:

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


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

S>Ладно с массивом, длина односвязного списка — тоже, т.к. узлы списка — это внешние по отношению к функции данные, не являющиеся аргументом (кроме одного).


Если узел хранит ссылку на список, то идентичность узлов означает идентичность списков.
Re[8]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 11:53
Оценка: :)
Здравствуйте, Klapaucius, Вы писали:

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


S>>Если под ИП подразумевать "деструктивное изменение данных", то хаскель с монадами к этому отношения не имеет.


K>Ну почему не имеет? Вот, например, быстрая сортировка массива:

Дык я до этого походу не дошел еще
Re[9]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.07.11 11:54
Оценка: +1
Здравствуйте, samius, Вы писали:

Только за работу с побочными эффектами отвечают лишь некоторые из монад.

Надо соизмеряеть степень детализации высказываний и степень компетенции слушателей. Если закопаться в детали, то тебе просто никто не поймет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[19]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.07.11 12:00
Оценка:
Здравствуйте, Undying, Вы писали:

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


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


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

Верно, но вывод сделан из твоего высказывания

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

Оно было сделано с термином "чистый", который ты потом заменил на "детерминированный".

S>>Ладно с массивом, длина односвязного списка — тоже, т.к. узлы списка — это внешние по отношению к функции данные, не являющиеся аргументом (кроме одного).


U>Если узел хранит ссылку на список, то идентичность узлов означает идентичность списков.

Если использование внешних данных вроде массива (без их изменения), перестает быть критерием для детерминированности, то вопрос снимается.
Re[20]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 05:12
Оценка:
Здравствуйте, samius, Вы писали:

U>>Если узел хранит ссылку на список, то идентичность узлов означает идентичность списков.

S>Если использование внешних данных вроде массива (без их изменения), перестает быть критерием для детерминированности, то вопрос снимается.

Если массив принимается как аргумент, то он не является внешним и функция детерминирована. Если массив принимается через замыкание (через обращение к полю класса или статическому полю не суть важно), то он является внешним и функция недетерминирована.
Re[21]: Императивная парадигма
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.07.11 06:41
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>Если узел хранит ссылку на список, то идентичность узлов означает идентичность списков.

S>>Если использование внешних данных вроде массива (без их изменения), перестает быть критерием для детерминированности, то вопрос снимается.

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


Если массив immutable, то всетаки детерминированной функция будет.
Re[21]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 06:51
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>Если узел хранит ссылку на список, то идентичность узлов означает идентичность списков.

S>>Если использование внешних данных вроде массива (без их изменения), перестает быть критерием для детерминированности, то вопрос снимается.

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


Когда говорят "функция принимает", то подразумевают передачу аргумента. Я не встречал употребление термина "принимает" в отношении функции, которая достает данные сама.

Функция Enumerable.Where() удовлетворяет твое определение детерминированности, т.к. ее результат не зависит ни от чего, кроме аргумента. Но является недетерминированной в общеупотребимом смысле.

Функция Foo.GetSum() берет данные из поля, нарушая тем самым твое следствие (т.к. это "внешний" массив), но детерминирована в общеупотребимом.
class Foo
{
    int[] _array = new [] {1, 2, 3};
    public int GetSum()
    {
         return _array.Sum();
    }
}


По-моему именно твои формулировки бессмысленны с точки зрения практики.
Re[22]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 07:38
Оценка:
Здравствуйте, samius, Вы писали:

S>Функция Foo.GetSum() берет данные из поля, нарушая тем самым твое следствие (т.к. это "внешний" массив), но детерминирована в общеупотребимом.

S>
S>class Foo
S>{
S>    int[] _array = new [] {1, 2, 3};
S>    public int GetSum()
S>    {
S>         return _array.Sum();
S>    }
S>}
S>


S>По-моему именно твои формулировки бессмысленны с точки зрения практики.


Чем плоха функциональность прибитая к классам?

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

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

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

зы
Наконец-то удачный термин подобрал, то чему я давал определение должно называться "свободными функциями".
Re[23]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 09:05
Оценка:
Здравствуйте, Undying, Вы писали:

U>Чем плоха функциональность прибитая к классам?


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

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

U>2) Функции класса тяжело использовать повторно.

Единица повторного использования в ООП — класс.

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

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

U>зы

U>Наконец-то удачный термин подобрал, то чему я давал определение должно называться "свободными функциями".
С тем что нестатические методы System.String не являются свободными — я согласен
Re[24]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 09:46
Оценка:
Здравствуйте, samius, Вы писали:

U>>2) Функции класса тяжело использовать повторно.

S>Единица повторного использования в ООП — класс.

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

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

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

T Sum(IEnumerable<T> items, Func<T, T, T> summator);
Re[25]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 10:03
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>2) Функции класса тяжело использовать повторно.

S>>Единица повторного использования в ООП — класс.

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

Покажи как это будет выглядеть на примере Dictionary<TKey,TValue>.Add.

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

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

U>
U>T Sum(IEnumerable<T> items, Func<T, T, T> summator);
U>


Как ты собираешься исключительно свободными функциями доставать элементы из items?
Re[26]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 10:20
Оценка:
Здравствуйте, samius, Вы писали:

S>Покажи как это будет выглядеть на примере Dictionary<TKey,TValue>.Add.


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

S>Как ты собираешься исключительно свободными функциями доставать элементы из items?


Откуда взялось требование "исключительно"? Объясни, как из:

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


можно сделать вывод, что функции должны быть "исключительно" свободными?
Re[4]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 22.07.11 10:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:
AC>>ИМХО лет через 20-120 создадут ИИ и необходимость ЯП отпадёт принципе
K>Почему тогда необходимость в языке программирования вдруг отпадет?
Я имел виду языки программирования в том виде в каком они есть сейчас, то есть как интерфейс человек-машина.

K>Просто наличие "последовательности вычислений" это вопрос трактовки...

Вопрос(интересующий меня) не в "наличии последовательности вычислений", а в подходе который вы используете когда пишете программу, вы как бы "говорите" компьютеру:
ИП — "сделай это, затем то, затем третье..."
ДП — "это должно быть таким, то должно находится здесь..."
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Императивная парадигма
От: AlexCab LinkedIn
Дата: 22.07.11 10:35
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>1. ИП — деструктивное изменение данных.
VD>2. ФП — преобразование (с копированием) данных.
VD>...
То есть можно сказать что:
Чистое процедурное программирование — последовательность шагов выполнения, произвольный доступ к памяти из любого места программы и тп.
Чистое функциональное программирование — вычисление значения функций, детерминированность функций и тп.
А ЯП включающий свойства обоих парадигм(как в случае процедур не изменяющих ничего кроме своих параметров) не является "чистым".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[27]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 10:36
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>Покажи как это будет выглядеть на примере Dictionary<TKey,TValue>.Add.


U>А чего-нибудь попроще нельзя? Мне как-то лень лезть в рефлектор, разбираться в не самой очевидной механике и думать как ее наилучшим образом свести к вызовам свободных функций с минимумом обвязки над ними.

Давай тогда List<T>.Add. Пойдет?

S>>Как ты собираешься исключительно свободными функциями доставать элементы из items?


U>Откуда взялось требование "исключительно"? Объясни, как из:


U>

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


U>можно сделать вывод, что функции должны быть "исключительно" свободными?

С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.

Хорошую степень свободы как-правило имеют методы работы с функциональными структурами данных. Но это за счет того что там не нужно управлять версиями, емкостью, счетчиком элементов, низлежащими структурами данных, не нужно все это держать в согласованном состоянии.
Re[5]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 10:38
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>ИП — "сделай это, затем то, затем третье..."

AC>ДП — "это должно быть таким, то должно находится здесь..."

i = 5;

Сделай, чтобы i равнялось 5.
i должно равняться 5.

И где здесь принципиальная разница?
Re[28]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 11:04
Оценка:
Здравствуйте, samius, Вы писали:

S>Давай тогда List<T>.Add. Пойдет?


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

S>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.


Не нужно заменять вызовы функций классов вызовами свободных функций, т.к. понятно, что если мы запихали функцию в класс, то скорей всего сделали либо из соображений инкапсуляции, либо полиморфизма, и соответственно замена вызова на свободную функцию невозможна. Есть задача заменить реализацию функции класса на вызовы свободных функций с минимумом обвязки над ними, т.к. это резко упрощает и понимание реализации и резко увеличивает возможности по повторному использованию функциональности.
Re[29]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 11:14
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>Давай тогда List<T>.Add. Пойдет?


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

Array.Resize

S>>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.


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


А, ну это ExtractMethod, разве что с гипертрофированным уклоном в свободные функции. С причинами выделения метода я согласен, разве что делать его свободным совсем не обязательно.
Re[30]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 11:26
Оценка:
Здравствуйте, samius, Вы писали:

S>А, ну это ExtractMethod, разве что с гипертрофированным уклоном в свободные функции. С причинами выделения метода я согласен, разве что делать его свободным совсем не обязательно.


От ExtractMethod как члена класса толку немного, т.к. по вынесенному методу, по-прежнему нельзя ни понять то с какой частью состояния класса этот метод работает, ни использовать его функциональность в другом классе.
Re[31]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 12:16
Оценка: +1
Здравствуйте, Undying, Вы писали:

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


S>>А, ну это ExtractMethod, разве что с гипертрофированным уклоном в свободные функции. С причинами выделения метода я согласен, разве что делать его свободным совсем не обязательно.


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

А есть такая цель? Если ты разработчик этого класса — открой код. Если пользователь — кури доку.
U>, ни использовать его функциональность в другом классе.
Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.
Re[7]: Императивная парадигма
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.11 13:45
Оценка: +4
Здравствуйте, AlexCab, Вы писали:

AC>То есть можно сказать что:

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

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

AC>А ЯП включающий свойства обоих парадигм(как в случае процедур не изменяющих ничего кроме своих параметров) не является "чистым".


Реально чистым функциональным языком можно назвать только математику, точнее лямбда-исчисления Чёрча .

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

Посему я для себя давно уже решил, что поиск чистоты — это бессмысленное занятие. ФП хорошо там где обрабатываются данные, когда есть исходные данные и их нужно преборазовать в некоторую форуму. Любую программу можно разбить на куски представимые таким образом, даже GUI.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
Re[32]: Императивная парадигма
От: Undying Россия  
Дата: 22.07.11 19:05
Оценка:
Здравствуйте, samius, Вы писали:

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

S>А есть такая цель? Если ты разработчик этого класса — открой код. Если пользователь — кури доку.

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

U>>, ни использовать его функциональность в другом классе.

S>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.

Заставь дурака богу молиться, он и лоб расшибет.
Re[33]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.07.11 19:46
Оценка:
Здравствуйте, Undying, Вы писали:

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


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

S>>А есть такая цель? Если ты разработчик этого класса — открой код. Если пользователь — кури доку.

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

Интригует такое слышать от противника Linq-а.

U>>>, ни использовать его функциональность в другом классе.

S>>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.

U>Заставь дурака богу молиться, он и лоб расшибет.

Ну я может не понимаю, о чем ты говоришь? От примера со словарем ты отказался, со списком — предложил вынести метод, который уже вынесен. Покажи уже на чем-нибудь увеличение читаемости на порядок за счет перевода метода класса в свободные... И желательно с потенциальным реюзом вынесенного.
Re[34]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 14:33
Оценка:
Здравствуйте, samius, Вы писали:

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

S>Интригует такое слышать от противника Linq-а.

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

S>Ну я может не понимаю, о чем ты говоришь? От примера со словарем ты отказался, со списком — предложил вынести метод, который уже вынесен. Покажи уже на чем-нибудь увеличение читаемости на порядок за счет перевода метода класса в свободные... И желательно с потенциальным реюзом вынесенного.


На маленьком примере это будет невидно, привести большой пример не позволяет формат форумного общения.
Re[6]: Императивная парадигма
От: Ziaw Россия  
Дата: 23.07.11 15:14
Оценка:
Здравствуйте, Undying, Вы писали:

U>i = 5;


U>Сделай, чтобы i равнялось 5.

U>i должно равняться 5.

U>И где здесь принципиальная разница?


Слабовато с утрированием. Надо убрать присваивание и оставить только i.

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

select 5 as i from dual


Нету тут: "Сделай, чтобы i равнялось 5" или "i должно равняться 5". Есть: 5 будем назвать i.
Re[35]: Императивная парадигма
От: Sinix  
Дата: 23.07.11 15:51
Оценка:
Здравствуйте, Undying, Вы писали:

U>Свободные бизнес-функции много выше уровнем, нежели linq.


А вот тут я окончательно запутался. Если linq и прочих хелперов stateless-подход только на пользу, то для БЛ (особенно на десктопе) без разделяемого состояния никуда. И, из-за сильной связности типовой БЛ, много не нарефакторишь — не будет у нас сотен строк кода без побочных эффектов. Все способы — IOC/service locator/context propagation — никак не спасут от самой потребности в контексте.

КМК, тут мы гонимся больше за абстрактной чистотой идеи, чем за практичностью.
Re[36]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 16:22
Оценка:
Здравствуйте, Sinix, Вы писали:

S>А вот тут я окончательно запутался. Если linq и прочих хелперов stateless-подход только на пользу, то для БЛ (особенно на десктопе) без разделяемого состояния никуда. И, из-за сильной связности типовой БЛ, много не нарефакторишь — не будет у нас сотен строк кода без побочных эффектов. Все способы — IOC/service locator/context propagation — никак не спасут от самой потребности в контексте.


Допустим мы решили написать собственный textBox. Какие задачи перед нами встают? Вывести рамку, вывести текст, найти букву по координате и т.д.

Для того, чтобы вывести рамку нам нужно все состояние textBox'а? Очевидно, нет, например, и текст и выделенный текст для этого совершенно не нужны. А нужны нам graphics, прямоугольник области вывода и какие дополнительные параметры (цвет, кисть, стиль и т.п.) Можем мы оформить вывод рамки как свободную функцию? Да, можем. Аналогично для вывода текста нам тоже нужно далеко не все состояние textBox'а. И опять же ничто не мешает вывод текста оформить как свободную функцию.

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

Завтра мы решили написать свой comboBox. Нужно ли нам что вывод текста в комбобоксе отличался от вывода текста в textBox'е? Скорей всего нет. Смогли ли мы бы использовать вывод текста из textBox'а в comboBox'е, если бы оформили его функцию класса? Скорей всего нет, т.к. возможности наследования и очень ограничены и приводят к множеству проблем. Есть ли какие-то проблемы с использованием функции вывода текста из textBox'а в comboBox'е, если она оформлена как свободная функция? Нет, никаких проблем нет. Т.е. свободные функции выступают в роли кирпичиков, из которых очень легко конструировать в чем-то похожие, но в чем различные объекты. Для того, что похоже мы используем уже имеющиеся свободные функции, для того что различно пишем новые свободные функции.
Re[37]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 17:13
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>А вот тут я окончательно запутался. Если linq и прочих хелперов stateless-подход только на пользу, то для БЛ (особенно на десктопе) без разделяемого состояния никуда. И, из-за сильной связности типовой БЛ, много не нарефакторишь — не будет у нас сотен строк кода без побочных эффектов. Все способы — IOC/service locator/context propagation — никак не спасут от самой потребности в контексте.


U>Допустим мы решили написать собственный textBox. Какие задачи перед нами встают? Вывести рамку, вывести текст, найти букву по координате и т.д.


U>Для того, чтобы вывести рамку нам нужно все состояние textBox'а? Очевидно, нет, например, и текст и выделенный текст для этого совершенно не нужны. А нужны нам graphics, прямоугольник области вывода и какие дополнительные параметры (цвет, кисть, стиль и т.п.) Можем мы оформить вывод рамки как свободную функцию? Да, можем. Аналогично для вывода текста нам тоже нужно далеко не все состояние textBox'а. И опять же ничто не мешает вывод текста оформить как свободную функцию.


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


U>Завтра мы решили написать свой comboBox. Нужно ли нам что вывод текста в комбобоксе отличался от вывода текста в textBox'е? Скорей всего нет. Смогли ли мы бы использовать вывод текста из textBox'а в comboBox'е, если бы оформили его функцию класса? Скорей всего нет, т.к. возможности наследования и очень ограничены и приводят к множеству проблем. Есть ли какие-то проблемы с использованием функции вывода текста из textBox'а в comboBox'е, если она оформлена как свободная функция? Нет, никаких проблем нет. Т.е. свободные функции выступают в роли кирпичиков, из которых очень легко конструировать в чем-то похожие, но в чем различные объекты. Для того, что похоже мы используем уже имеющиеся свободные функции, для того что различно пишем новые свободные функции.


А чем же тебя не устроила Graphics.DrawText? Тем что несвободна? Кстати, я так и не понял, свободные функции в твоем определении как-то связаны с детерминированностью и сайд эффектами? Пример-то какой-то уж сайд-эффектный больно.
Re[35]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 17:17
Оценка:
Здравствуйте, Undying, Вы писали:

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


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

S>>Интригует такое слышать от противника Linq-а.

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

Дай-ка определение свободной функции. А то у тебя Array.Resize вышел вроде как свободным, и оказался уровнем выше линка.

S>>Ну я может не понимаю, о чем ты говоришь? От примера со словарем ты отказался, со списком — предложил вынести метод, который уже вынесен. Покажи уже на чем-нибудь увеличение читаемости на порядок за счет перевода метода класса в свободные... И желательно с потенциальным реюзом вынесенного.


U>На маленьком примере это будет невидно, привести большой пример не позволяет формат форумного общения.

Может дашь ссылку на какой-то ресурс, где об этом сказано?
Re[37]: Императивная парадигма
От: Sinix  
Дата: 23.07.11 17:20
Оценка:
Здравствуйте, Undying, Вы писали:

U>Для того, чтобы вывести рамку нам нужно все состояние textBox'а? Очевидно, нет, например, и текст и выделенный текст для этого совершенно не нужны.


Неа — всё это может влиять на рендеринг, два примера: автосайз текстбокса, шаблон "рыбий глаз" — размер текста увеличивается при выделении. Кроме того, фон рамки зависит от кучи флагов состояния — начиная с системных параметров и заканчивая фокусом (тот же accepts enter = false перенесёт альтернативный фокус (тот, что срабатывает по нажатию на enter) на кнопку по умолчанию).

Суммируя: даже набор нужных параметров для отрисовки зависит от текущего состояния текстбокса. Ну сделаем мы тонну static-методов и будем передавать не сам контрол, а отдельные его поля — как это повлияет на их "чистоту"?

Самый правильный (имхо) подход здесь — разнесение построения декларативного visual tree и собственно рендеринга. Как это выстреливает можно посмотреть на примере WPF.
Во-первых, вы можем манипулировать самим visual tree — начиная с анимаций по условию и заканчивая полной сменой шаблона.
Во-вторых, мы можем использовать информацию о состоянии контрола не только для рендеринга, но и для hit testing и accessibility (aka win automation).
В третьих, мы теперь можем относительно легко перенести стек рендеринга на удалённую машину — см RemoteFX.

В принципе, такой подход можно условно обозвать чистым — код отрисовки освобождён от ответственности за сохранение состояния контрола. Одна проблема: даже у Graphics из GDI+, при всей его простоте, приходится сохранять состояние самого стека рендеринга между вызовами.

Другими словами: "чистоту" кода можно повысить, инкапсулируя внутреннее состояние внутри слоя. Тут я всеми руками-ногами за. А вот избавиться от состояния совсем — не получится. Поэтому проще переиспользовать кирпичики-классы, чем изобретать 1025й способ эмулировать this.
Re[38]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 17:55
Оценка:
Здравствуйте, samius, Вы писали:

S>А чем же тебя не устроила Graphics.DrawText? Тем что несвободна? Кстати, я так и не понял, свободные функции в твоем определении как-то связаны с детерминированностью и сайд эффектами? Пример-то какой-то уж сайд-эффектный больно.


Graphics.DrawText это свободная функция и очень полезная функция. Но она является низкоуровневой по сравнению со свободной функцией отрисовки текста textBox'а, т.к. к примеру ничего не знает о том, что часть текста может быть выделенной и ее надо выводить по другому. Соответственно над Graphics.DrawText будет много обвязочного кода, а над свободной функцией вывода текста в textBox'е обвязки практически не будет, т.к. и вызовы Graphics.DrawText и обвязка над ними внутрь этой самой функции и уйдут.
Re[36]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 18:01
Оценка:
Здравствуйте, samius, Вы писали:

S>Дай-ка определение свободной функции. А то у тебя Array.Resize вышел вроде как свободным, и оказался уровнем выше линка.


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

U>>На маленьком примере это будет невидно, привести большой пример не позволяет формат форумного общения.

S>Может дашь ссылку на какой-то ресурс, где об этом сказано?

Не знаю. Толчок в этом направлении мне дал Darkgray. Дальше сам.
Re[39]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 18:01
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>А чем же тебя не устроила Graphics.DrawText? Тем что несвободна? Кстати, я так и не понял, свободные функции в твоем определении как-то связаны с детерминированностью и сайд эффектами? Пример-то какой-то уж сайд-эффектный больно.


U>Graphics.DrawText это свободная функция и очень полезная функция.

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

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

Сколько же будет параметров у свободной функции отрисовки текста textBox'а, если не передавать весь textBox?

U>Соответственно над Graphics.DrawText будет много обвязочного кода, а над свободной функцией вывода текста в textBox'е обвязки практически не будет, т.к. и вызовы Graphics.DrawText и обвязка над ними внутрь этой самой функции и уйдут.
Re[37]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 18:07
Оценка: :)
Здравствуйте, Undying, Вы писали:

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


S>>Дай-ка определение свободной функции. А то у тебя Array.Resize вышел вроде как свободным, и оказался уровнем выше линка.


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

Что такое автобус?
— Автобусы бывают Львовские и Икарусы...
Вот ты мне примерно так ответил.

U>>>На маленьком примере это будет невидно, привести большой пример не позволяет формат форумного общения.

S>>Может дашь ссылку на какой-то ресурс, где об этом сказано?

U>Не знаю. Толчок в этом направлении мне дал Darkgray. Дальше сам.

А когда он давал тебе толчек, какими словами он о функциях толкал, не помнишь? Если все-таки о чистых, то твой пример о textBox-е мимо.
Re[38]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 18:17
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Неа — всё это может влиять на рендеринг, два примера: автосайз текстбокса, шаблон "рыбий глаз" — размер текста увеличивается при выделении. Кроме того, фон рамки зависит от кучи флагов состояния — начиная с системных параметров и заканчивая фокусом (тот же accepts enter = false перенесёт альтернативный фокус (тот, что срабатывает по нажатию на enter) на кнопку по умолчанию).


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

S>Суммируя: даже набор нужных параметров для отрисовки зависит от текущего состояния текстбокса. Ну сделаем мы тонну static-методов и будем передавать не сам контрол, а отдельные его поля — как это повлияет на их "чистоту"?


Мы захотели написать comboBox и там тоже нужен рыбий глаз. Как ты будешь реализовать его в comboBox'е, если при реализации textBox'а ты свободные функции не использовал? Сдублируешь код?

S>Самый правильный (имхо) подход здесь — разнесение построения декларативного visual tree и собственно рендеринга. Как это выстреливает можно посмотреть на примере WPF.

S>Во-первых, вы можем манипулировать самим visual tree — начиная с анимаций по условию и заканчивая полной сменой шаблона.
S>Во-вторых, мы можем использовать информацию о состоянии контрола не только для рендеринга, но и для hit testing и accessibility (aka win automation).
S>В третьих, мы теперь можем относительно легко перенести стек рендеринга на удалённую машину — см RemoteFX.

То что ты говоришь, совершенно ортогонально свободным функциям.

S>Другими словами: "чистоту" кода можно повысить, инкапсулируя внутреннее состояние внутри слоя. Тут я всеми руками-ногами за. А вот избавиться от состояния совсем — не получится. Поэтому проще переиспользовать кирпичики-классы, чем изобретать 1025й способ эмулировать this.


А кто предлагает избавляться от состояния? Для инкапсуляция состояния придуманы объекты, для инкапсуляции преобразований придуманы свободные функции. Одно другому никак не мешает.
Re[40]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 18:21
Оценка:
Здравствуйте, samius, Вы писали:

U>>Graphics.DrawText это свободная функция и очень полезная функция.

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

Извиняюсь, туплю что-то на ночь глядя. Graphics.DrawText действительно не является свободной функцией, хотя и остается очень полезной.

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

S>Сколько же будет параметров у свободной функции отрисовки текста textBox'а, если не передавать весь textBox?

Зависит от того в каком виде мы их будем передавать. Если в виде примитивных типов, то много, если в каком-то сгруппированном, то намного меньше.
Re[38]: Императивная парадигма
От: Undying Россия  
Дата: 23.07.11 18:23
Оценка:
Здравствуйте, samius, Вы писали:

S>Что такое автобус?

S>- Автобусы бывают Львовские и Икарусы...
S>Вот ты мне примерно так ответил.

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


Все-таки твоя способность не замечать суть за формализмами продолжает меня удивлять.
Re[39]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 18:24
Оценка: :)
Здравствуйте, Undying, Вы писали:

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


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


U>Все-таки твоя способность не замечать суть за формализмами продолжает меня удивлять.


О какой сути может быть речь, если я не понимаю, что ты подразумеваешь под свободными? Ведь под чистыми и детерминированными ты тоже что-то свое подразумевал!
Re[41]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 18:25
Оценка: :)
Здравствуйте, Undying, Вы писали:

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


U>>>Graphics.DrawText это свободная функция и очень полезная функция.

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

U>Извиняюсь, туплю что-то на ночь глядя. Graphics.DrawText действительно не является свободной функцией, хотя и остается очень полезной.


Значит ты все-таки о тривиальном ExtractMethod, но своими словами.
Re[42]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 23.07.11 21:39
Оценка:
Здравствуйте, samius, Вы писали:

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


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


U>>>>Graphics.DrawText это свободная функция и очень полезная функция.

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

U>>Извиняюсь, туплю что-то на ночь глядя. Graphics.DrawText действительно не является свободной функцией, хотя и остается очень полезной.


S>Значит ты все-таки о тривиальном ExtractMethod, но своими словами.


Вижу мои потуги понять тебя вызывают у тебя улыбки

Попробую показать, как это выглядит с моей стороны:

Сначала ты рассуждаешь о чистоте и императивности, потом говоришь о пользе чистой процедуры.

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

потом что это фигня, и важнее "внешность" аргументов

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

Что методы строки в дотнете нечисты

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

что определение на вики бессмысленно

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

потом пошла тема про детерминированность

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

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

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

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

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

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

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

Свободные бизнес-функции много выше уровнем, нежели linq.

Отсюда следует что функции linq для тебя не являются свободными. Что с ними не так? Они вроде как не функции класса (хоть и лежат в Enumerable классе, но в C# нет возможности делать функции без класса ). Но что-то же ты называешь свободными.

Потом пошел пример с текстбоксом, где выяснилось что

Graphics.DrawText это свободная функция и очень полезная функция.

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

Свободные функции могут иметь самый разный уровень. Но уровень верхних свободных функций определяется уровнем преобразования.

О! Преобразования? Так все-таки наверное речь о чистоте?

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

Опять загадка. Преобразованием можно назвать добавление элемента к функциональному списку (Cons). И оформить это можно только в качестве свободной функции. А кому придет в голову делать это методом узла списка? Но как быть с Graphics.DrawText? он-то к функциональщине отношения никакого не имеет, да и метод класса!
Может ты подразумеваешь добавление к императивному списку, тогда делать добавление свободной функцией не с руки, т.к. нужно передавать кучу данных самого списка, причем передавать их для изменения (ref-ами). Что можно заюзать от добавления к списку в другом коде? Если список односвязный/двухсвязный — ничего. Если динамический массив — там куда проще написать _items[_count++] = value (с предварительной провекой емкости), чем вызывать свободную функцию для достижения того же эффекта. опять же, свободная функция такая есть (Array.SetValue)

Извиняюсь, туплю что-то на ночь глядя. Graphics.DrawText действительно не является свободной функцией

И действительно, не является ни свободной в контексте детерминированности, ни свободной в контексте принадлежности экземпляру класса.

Но о чем ты говорил тогда в самом начале, о свободных процедурах?

И знаешь что? В то время как ты рассуждаешь об уровнях свободы функций и значительном улучшении читабельности при изпользовании свободных функций, я даже не могу понять, что именно ты подразумеваешь под "свободными функциями"!

Все-таки твоя способность не замечать суть за формализмами продолжает меня удивлять.

Формализмов здесь не было. Любое определение, что ты давал, допускало двоякое толкование и шло вразрез с тем что принято понимать под соответствующими терминами. Суть — суть я не понимаю, пока хотя бы в приблизительных чертах не пойму о чем речь.

Давай совсем по простому. Свободные функции свободны от чего?

З.Ы. Если я тут один не понимаю о чем речь, то попрошу коллег, которые поняли суть, попытаться объяснить мне ее.
Re[43]: Императивная парадигма
От: Undying Россия  
Дата: 24.07.11 04:48
Оценка:
Здравствуйте, samius, Вы писали:

S>Т.е. я просто в твое определение чистоты а затем детерминированности подставляю "свободу" и получаю что-товроде

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

Правильно понимаешь. Констатируем термины:

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

Что такое детерминированная функция не важно, для того, что я хотел донести терминов свободная и чистая функция достаточно.

S>Иду в интернет и неоднократно вижу упоминание под свободной функцией функции, не принадлежащие классам.

S>Я в затруднении.

Зачем идти в интернет, если определение термина было дано в дискуссии?

S>

S>Свободные бизнес-функции много выше уровнем, нежели linq.

S>Отсюда следует что функции linq для тебя не являются свободными. Что с ними не так? Они вроде как не функции класса (хоть и лежат в Enumerable классе, но в C# нет возможности делать функции без класса ). Но что-то же ты называешь свободными.

А выделенное ты не заметил? Функции linq это свободные функции, но это низкоуровневые кирпичики, свободные бизнес-функции могут быть намного выше уровнем, чем linq-функции.

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


Я уже ответил, что ошибся и graphics.DrawText свободной функцией не является. Что непонятного-то?

S>

S>Свободные функции могут иметь самый разный уровень. Но уровень верхних свободных функций определяется уровнем преобразования.

S>О! Преобразования? Так все-таки наверное речь о чистоте?
S>[q]

Что такое вывод рамки textBox'а? Это преобразование пикселей экрана. Можем ли мы его оформить в качестве свободной функции? Очевидно, да. Может ли это преобразование быть записанным в виде чистой функции, если мы его делаем через graphics? Очевидно, нет, т.к. мы изменяем один из аргументов.

S>Может ты подразумеваешь добавление к императивному списку, тогда делать добавление свободной функцией не с руки, т.к. нужно передавать кучу данных самого списка, причем передавать их для изменения (ref-ами). Что можно заюзать от добавления к списку в другом коде? Если список односвязный/двухсвязный — ничего. Если динамический массив — там куда проще написать _items[_count++] = value (с предварительной провекой емкости), чем вызывать свободную функцию для достижения того же эффекта. опять же, свободная функция такая есть (Array.SetValue)


Повторяю еще раз: http://rsdn.ru/forum/philosophy/4353135.1.aspx
Автор: Undying
Дата: 22.07.11


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

Т.е. реализация list.Add должна выглядеть примерно так:

if (ListHlp.IsOverflowedArray(realCount, logicCount + 1))
  array = ListHlp.ArrayResize(array, realCount * 2, logicCount);

array[logicCount] = addValue;
logicCount++;


Где IsOverflowedArray и ArrayResize это свободные (и в данном случае чистые) функции. Использование list.Add на свободные функции заменять не надо.
Re[39]: Императивная парадигма
От: Sinix  
Дата: 24.07.11 05:57
Оценка:
Здравствуйте, Undying, Вы писали:

U>Если различия все же более серьезные, то, значит, будут разные свободные функции для разных режимов.

Комбинаторика. Даже имея 8 параметров (а их там больше), сколько у нас сочетаний? Что, если рамку понадобится отрисовать хитрым образом, например, отражая в ней текст? Или соседние контролы? Применяя свой алгоритм отрисовки? Сколько "свободных" методов понадобится, чтобы покрыть все варианты? И сколько из них придётся написать пользователям вашего фреймворка — вместо того, чтобы добавить пару строк декларативного описания?

U>Мы захотели написать comboBox и там тоже нужен рыбий глаз. Как ты будешь реализовать его в comboBox'е, если при реализации textBox'а ты свободные функции не использовал? Сдублируешь код?

Зачем? Просто переиспользую стиль XAML-я.


S>>Самый правильный (имхо) подход здесь — разнесение построения декларативного visual tree и собственно рендеринга.

U>То что ты говоришь, совершенно ортогонально свободным функциям.
Неа. Если вы переходим к построению visual tree, наличие или отсутствие свободных функций не играет никакой роли — мы уже перенесли всю сложность в само дерево и нет необходимости в придумывании ещё одного метода абстракции.

U>А кто предлагает избавляться от состояния? Для инкапсуляция состояния придуманы объекты, для инкапсуляции преобразований придуманы свободные функции. Одно другому никак не мешает.

Ок, чем (кроме того, что мы отказываемся от инкапсуляции логики) принципиально отличается
// псевдокод. TextBoxHelpers.cs
static Size Measure(TextBox textBox)
{
  if (textBox.WordWrap)
  {
    // ...
  }
}

от
// TextBox.cs
Size Measure()
{
  if (this.WordWrap)
  {
    // ...
  }
}

?
Re[40]: Императивная парадигма
От: Undying Россия  
Дата: 24.07.11 08:48
Оценка: 18 (1)
Здравствуйте, Sinix, Вы писали:

U>>Если различия все же более серьезные, то, значит, будут разные свободные функции для разных режимов.

S>Комбинаторика. Даже имея 8 параметров (а их там больше), сколько у нас сочетаний? Что, если рамку понадобится отрисовать хитрым образом, например, отражая в ней текст? Или соседние контролы? Применяя свой алгоритм отрисовки? Сколько "свободных" методов понадобится, чтобы покрыть все варианты?

Свободных методов понадобиться не больше, чем методов класса при традиционном подходе. Проблема-то в чем?

S>И сколько из них придётся написать пользователям вашего фреймворка — вместо того, чтобы добавить пару строк декларативного описания?


Сразу предупреждаю, что это оффтопик и никакого отношения к теме свободных функций не имеет. Но проблемой декларативного описания на псевдоязыках является то, что таким образом хорошо решаются только те задачи, которые были предусмотрены при проектировании псевдоязыка. Шаг влево и оказывается, что логически тривиальнейшая задача вообще решения не имеет. Наглядный пример тут http://rsdn.ru/forum/dotnet.gui/4332472.1.aspx
Автор: ariets
Дата: 06.07.11


U>>Мы захотели написать comboBox и там тоже нужен рыбий глаз. Как ты будешь реализовать его в comboBox'е, если при реализации textBox'а ты свободные функции не использовал? Сдублируешь код?

S>Зачем? Просто переиспользую стиль XAML-я.

Господи как с вами сложно. Причем здесь XAML? Стандартная проблема, решая задачу мы обнаруживаем, что часть задачи мы уже где-то делали. Что ты в этом случае делаешь, ждешь пока кто-нибудь напишет какой-нибудь XAML и решит задачу за тебя что ли?

S>Ок, чем (кроме того, что мы отказываемся от инкапсуляции логики) принципиально отличается

S>
S>// псевдокод. TextBoxHelpers.cs
S>static Size Measure(TextBox textBox)
S>{
S>  if (textBox.WordWrap)
S>  {
S>    // ...
S>  }
S>}
S>

S>от
S>
S>// TextBox.cs
S>Size Measure()
S>{
S>  if (this.WordWrap)
S>  {
S>    // ...
S>  }
S>}
S>

S>?

Как минимум тем, что TextBoxHelpers.Measure гарантирует, что пользуется только публичным интерфейсом textBox'а.
Re[44]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 24.07.11 08:56
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>Т.е. я просто в твое определение чистоты а затем детерминированности подставляю "свободу" и получаю что-товроде

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

U>Правильно понимаешь. Констатируем термины:


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

Пусть это будет определение свободной функции (1)
U>Чистая функция это свободная функция, не изменяющая своих аргументов.
Т.е. по твоей версии "чистоты", Enumerable.Where — чистая?

U>Что такое детерминированная функция не важно, для того, что я хотел донести терминов свободная и чистая функция достаточно.

Пусть неважно

S>>Иду в интернет и неоднократно вижу упоминание под свободной функцией функции, не принадлежащие классам.

S>>Я в затруднении.

U>Зачем идти в интернет, если определение термина было дано в дискуссии?


S>>

S>>Свободные бизнес-функции много выше уровнем, нежели linq.

Соответствующее этому определению определение колеса выглядело бы так: Колеса автобуса много выше, нежели колеса самоката. Извини, я не посчитал это за определение.
Да и это определение противоречит определению (1), в котором о "бизнес"-е не было ни слова.

S>>Отсюда следует что функции linq для тебя не являются свободными. Что с ними не так? Они вроде как не функции класса (хоть и лежат в Enumerable классе, но в C# нет возможности делать функции без класса ). Но что-то же ты называешь свободными.


U>А выделенное ты не заметил? Функции linq это свободные функции, но это низкоуровневые кирпичики, свободные бизнес-функции могут быть намного выше уровнем, чем linq-функции.

Опять же, могут быть, а могут и не быть...

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


U>Я уже ответил, что ошибся и graphics.DrawText свободной функцией не является. Что непонятного-то?

Я показывал тебе последовательность моих предполоожений, основанных на твоих постах. Что DrawText свободной не является, я уже понял.

S>>

S>>Свободные функции могут иметь самый разный уровень. Но уровень верхних свободных функций определяется уровнем преобразования.

S>>О! Преобразования? Так все-таки наверное речь о чистоте?
S>>[q]

U>Что такое вывод рамки textBox'а? Это преобразование пикселей экрана. Можем ли мы его оформить в качестве свободной функции? Очевидно, да.

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

U>Может ли это преобразование быть записанным в виде чистой функции, если мы его делаем через graphics? Очевидно, нет, т.к. мы изменяем один из аргументов.

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

S>>Может ты подразумеваешь добавление к императивному списку, тогда делать добавление свободной функцией не с руки, т.к. нужно передавать кучу данных самого списка, причем передавать их для изменения (ref-ами). Что можно заюзать от добавления к списку в другом коде? Если список односвязный/двухсвязный — ничего. Если динамический массив — там куда проще написать _items[_count++] = value (с предварительной провекой емкости), чем вызывать свободную функцию для достижения того же эффекта. опять же, свободная функция такая есть (Array.SetValue)


U>Повторяю еще раз: http://rsdn.ru/forum/philosophy/4353135.1.aspx
Автор: Undying
Дата: 22.07.11


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


U>Т.е. реализация list.Add должна выглядеть примерно так:


U>
U>if (ListHlp.IsOverflowedArray(realCount, logicCount + 1))
U>  array = ListHlp.ArrayResize(array, realCount * 2, logicCount);

U>array[logicCount] = addValue;
U>logicCount++;
U>

Вот теперь, я кажется начинаю тебя понимать. Если сравнить этот код с кодом из BCL
public void Add(T item)
{
    if (this._size == this._items.Length)
    {
        this.EnsureCapacity(this._size + 1);
    }
    this._items[this._size++] = item;
    this._version++;
}

То твой код выгодно отличает то, что функции, которые ты используешь как вспомогательные, не используют посторонних эффектов (side effect), и не меняют неявно состояние класса.

U>Где IsOverflowedArray и ArrayResize это свободные (и в данном случае чистые) функции.

Верно. В данном случае они чистые.

U>Использование list.Add на свободные функции заменять не надо.

Вот тут-то и подвох. На самом низком уровне ты можешь использовать чистые функции. Уровнем выше, там где надо заюзать Add, твое правило уже неприменимо. Т.е. говоря о крутоте "свободных бизнес-функций высокого уровня", не надо забывать, что их крутота заканчивается при первом изменении чего-либо, т.е. повышать бесконечно уровень использования таких функций, оставаясь в рамках ИП, невозможно. Т.е. если ты даже сделаешь это и избавишься от сайд-эффектов и недетерминированности на любом уровне, то ты получишь функциональную программу.
Re[41]: Императивная парадигма
От: Sinix  
Дата: 24.07.11 09:40
Оценка:
Здравствуйте, Undying, Вы писали:

U>Свободных методов понадобиться не больше, чем методов класса при традиционном подходе. Проблема-то в чем?

Неа. Для традиционного подхода достаточно одного virtual Draw(), т.к все данные уже доступны из this, для "свободных" методов нам придётся нагрузить API методами, отражающими внутренние детали реализации. Максимум, что удастся — вынести в хелперы элементарщину аля DrawText — см ControlPaint в WinForms. Во что такой подход превращается для сложных контролов, очень легко увидеть на примере ToolStripRenderer — для каждого контрола появляется свой особый api отрисовки. Результат получился прямо противоположный тому, что мы хотели изначально

U>Шаг влево и оказывается, что логически тривиальнейшая задача вообще решения не имеет. Наглядный пример тут http://rsdn.ru/forum/dotnet.gui/4332472.1.aspx
Автор: ariets
Дата: 06.07.11

Одно решение предложили прямо там — обернуть 2 коллекции в одну. Другое — самое правильное — биндинг с конвертером — почему-то забыли


U>Причем здесь XAML? Стандартная проблема, решая задачу мы обнаруживаем, что часть задачи мы уже где-то делали. Что ты в этом случае делаешь, ждешь пока кто-нибудь напишет какой-нибудь XAML и решит задачу за тебя что ли?

Нет. Мы просто переиспользуем кирпичики-элементы visual tree (или добавляем свои), причём делаем это в декларативной манере. Xaml — это самый простой способ описания шаблонов, в шарпе придётся писать больше.

U>Как минимум тем, что TextBoxHelpers.Measure гарантирует, что пользуется только публичным интерфейсом textBox'а.


В принципе, можно закругляться — все всё высказали и подвижек не видно

Спасибо, было приятно поспорить!
Угу. Придётся или расширять public api методами, нужными только для measure, или прятать их в internal.
Re[45]: Императивная парадигма
От: Sinix  
Дата: 24.07.11 09:45
Оценка: 7 (1)
Здравствуйте, samius, Вы писали:

S>То твой код выгодно отличает то, что функции, которые ты используешь как вспомогательные, не используют посторонних эффектов (side effect), и не меняют неявно состояние класса.


Сорри что влажу, но для получения того же эффекта не нужно выносить код в классы-хелперы, достаточно пометить их [Pure] и использовать static-checker ис code contracts. Ну, или написать своё правило к code analysis, у самого где-то прототип валяется (выкинут за практической малопригодностью).

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

+1
Re[46]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 24.07.11 09:57
Оценка: +1
Здравствуйте, Sinix, Вы писали:

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


S>>То твой код выгодно отличает то, что функции, которые ты используешь как вспомогательные, не используют посторонних эффектов (side effect), и не меняют неявно состояние класса.


S>Сорри что влажу, но для получения того же эффекта не нужно выносить код в классы-хелперы, достаточно пометить их [Pure] и использовать static-checker ис code contracts. Ну, или написать своё правило к code analysis, у самого где-то прототип валяется (выкинут за практической малопригодностью).

Не знал, что code contracts такое умеет. Да, конечно, выносить в классы-хелперы нужно в случае если есть потенциальный реюз. Если реюза нет — незачем плодить хелперы.
Re[47]: Императивная парадигма
От: Sinix  
Дата: 24.07.11 10:11
Оценка:
Здравствуйте, samius, Вы писали:

S>Не знал, что code contracts такое умеет.

Уппс, они и не умеют

This attribute is not enforced by the current analysis tools; you should use this attribute only if you are sure that the methods are pure.


Впрочем, кто знает, что будет в будущем? Поддержку immutable вон почти добавили.

О, нашёл! Намекают, что могут добавить:

Furthermore, in the future, we may provide purity checkers that ascertain that a method declared as Pure actually is pure.


Ну а пока — только правила для code analysis. Сорри, соврал ненамеренно

S>Да, конечно, выносить в классы-хелперы нужно в случае если есть потенциальный реюз. Если реюза нет — незачем плодить хелперы.

Согласен
Re[42]: Императивная парадигма
От: Undying Россия  
Дата: 25.07.11 04:25
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Неа. Для традиционного подхода достаточно одного virtual Draw(), т.к все данные уже доступны из this, для "свободных" методов нам придётся нагрузить API методами, отражающими внутренние детали реализации.


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

S>Максимум, что удастся — вынести в хелперы элементарщину аля DrawText — см ControlPaint в WinForms. Во что такой подход превращается для сложных контролов, очень легко увидеть на примере ToolStripRenderer — для каждого контрола появляется свой особый api отрисовки. Результат получился прямо противоположный тому, что мы хотели изначально


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

U>>Как минимум тем, что TextBoxHelpers.Measure гарантирует, что пользуется только публичным интерфейсом textBox'а.

S>Угу. Придётся или расширять public api методами, нужными только для measure, или прятать их в internal.

Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.
Re[43]: Императивная парадигма
От: Sinix  
Дата: 25.07.11 04:40
Оценка:
Здравствуйте, Undying, Вы писали:

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

Они не будут "свободными", они будут принадлежать или drawing context, или control context. От того, что мы заменим this явной передачей параметра ничего принципиально не изменится.

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

+1. Грабля — такие функции могут попасться на самых разных уровнях, причём всегда внезапно. Я не теоретизирую, это одна из основных проблем с построением work tree/проектированием anemic-фреймворков, с чем я сейчас плотно работаю.

U>>>Как минимум тем, что TextBoxHelpers.Measure гарантирует, что пользуется только публичным интерфейсом textBox'а.

S>>Угу. Придётся или расширять public api методами, нужными только для measure, или прятать их в internal.

U>Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.

Так нам придётся протаскивать по всем стеку хелперов несколько слабосвязанных параметров — начиная с геометрии рамки (она необязательно будет прямоугольной) и заканчивая кистями для рамки/фона. И писать для каждого контрола свою логику по извлечению этих параметров.
Имхо, проще передавать рендереру shape с уже настроенными параметрами. Что для текстбокса, что для комбобокса это будет
<Border x:Name="Border" BorderThickness="{TemplateBinding BorderThickness}"
  CornerRadius="1" Opacity="1"
  Background="{TemplateBinding Background}"
  BorderBrush="{TemplateBinding BorderBrush}">
<!-- ... -->
</Border>
Re[45]: Императивная парадигма
От: Undying Россия  
Дата: 25.07.11 04:50
Оценка:
Здравствуйте, samius, Вы писали:

S>Т.е. по твоей версии "чистоты", Enumerable.Where — чистая?


Да, конечно.

S>>>

S>>>Свободные бизнес-функции много выше уровнем, нежели linq.

S>Соответствующее этому определению определение колеса выглядело бы так: Колеса автобуса много выше, нежели колеса самоката. Извини, я не посчитал это за определение.
S>Да и это определение противоречит определению (1), в котором о "бизнес"-е не было ни слова.

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

U>>А выделенное ты не заметил? Функции linq это свободные функции, но это низкоуровневые кирпичики, свободные бизнес-функции могут быть намного выше уровнем, чем linq-функции.

S>Опять же, могут быть, а могут и не быть...

Естественно, т.к. уровень свободных бизнес-функций определяется уровнем бизнес-преобразований. Если бизнес-преобразование очень примитивное, то и бизнес-функция будет примитивной и сравнимой по уровню с linq-функциями.

U>>Что такое вывод рамки textBox'а? Это преобразование пикселей экрана. Можем ли мы его оформить в качестве свободной функции? Очевидно, да.

S>Очевидно, что не очевидно. Согласно твоему определению (1) функция преобразования пикселей экрана свободной в общем случае не является, т.к. ее результат зависит не только от аргументов, а еще и от настроек винды, GDI и т.п.

Мы эти настройки как параметры функции передали? Передали в виде graphics, поэтому эта функция свободная.

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


Во-первых, многие преобразования весьма высокого уровня могут быть чистыми.
Во-вторых, для простоты понимания и использования формальная чистота вовсе не обязательна. Например, функция DrawTextCell(graphics, cellRectangle, ...) чистой не является, но хоть у нас и нет гарантий, но есть уверенность, что эта функция изменяет только заданный прямоугольник в переданной области вывода и ничего больше. Соответственно хотя эта функция и не является чистой, ее понимание и использование практически столь же просто.

Проблемой являются только те преобразования, которые изменяют множество разнородных сущностей. Соответственно эта разнородность мешает и дать хорошее название функции, и сгруппировать изменяемые сущности в какую-то дополнительную сущность. В этом случае, да, попытка записать преобразование как свободную функцию ничего не дает, поэтому это по сути единственный случай, когда я использую приватные функции класса. Но таких преобразований по сравнению с общим количеством используемых в программе преобразований немного.
Re[46]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 25.07.11 06:38
Оценка:
Здравствуйте, Undying, Вы писали:

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


S>>Т.е. по твоей версии "чистоты", Enumerable.Where — чистая?

U>Да, конечно.
Приму к сведению

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

Меня смутило то что ты написал что это было определение.

U>Естественно, т.к. уровень свободных бизнес-функций определяется уровнем бизнес-преобразований. Если бизнес-преобразование очень примитивное, то и бизнес-функция будет примитивной и сравнимой по уровню с linq-функциями.

Уровень linq-функций тоже определяется уровнем бизнес-преобразований, которые их используют.

U>>>Что такое вывод рамки textBox'а? Это преобразование пикселей экрана. Можем ли мы его оформить в качестве свободной функции? Очевидно, да.

S>>Очевидно, что не очевидно. Согласно твоему определению (1) функция преобразования пикселей экрана свободной в общем случае не является, т.к. ее результат зависит не только от аргументов, а еще и от настроек винды, GDI и т.п.

U>Мы эти настройки как параметры функции передали? Передали в виде graphics, поэтому эта функция свободная.

А если мы в виде строки передадим функции настройки, которые лежат в файле на веб сервисе, эта функция будет свободной? Где грань собственно?

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


U>Во-первых, многие преобразования весьма высокого уровня могут быть чистыми.

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

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

Соответственно ты просто приходишь к классическому ExtractMethod, который не требует от выделяемой функции чистоты.

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

Ты приватные противопоставляешь свободным? В твоем определении ничего не было о модификаторах видимости.

U> Но таких преобразований по сравнению с общим количеством используемых в программе преобразований немного.

В таком случае твою программу следует относить больше к ФП, чем к ИП.
А как у тебя обстоят дела с вводом-выводом? Он в твоей трактовке тоже чистый, либо его у тебя немного?
Re[5]: Императивная парадигма
От: Klapaucius  
Дата: 25.07.11 09:42
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Я имел виду языки программирования в том виде в каком они есть сейчас, то есть как интерфейс человек-машина.


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

AC>Вопрос(интересующий меня) не в "наличии последовательности вычислений",


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

AC> а в подходе который вы используете когда пишете программу, вы как бы "говорите" компьютеру:

AC>ИП — "сделай это, затем то, затем третье..."
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[7]: Императивная парадигма
От: Undying Россия  
Дата: 26.07.11 07:21
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Нету тут: "Сделай, чтобы i равнялось 5" или "i должно равняться 5". Есть: 5 будем назвать i.


И что от этого принципиально поменялось?
Re[44]: Императивная парадигма
От: Undying Россия  
Дата: 26.07.11 08:56
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Они не будут "свободными", они будут принадлежать или drawing context, или control context. От того, что мы заменим this явной передачей параметра ничего принципиально не изменится.


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

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

S>+1. Грабля — такие функции могут попасться на самых разных уровнях, причём всегда внезапно. Я не теоретизирую, это одна из основных проблем с построением work tree/проектированием anemic-фреймворков, с чем я сейчас плотно работаю.

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

U>>Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.

S>Так нам придётся протаскивать по всем стеку хелперов несколько слабосвязанных параметров — начиная с геометрии рамки (она необязательно будет прямоугольной) и заканчивая кистями для рамки/фона. И писать для каждого контрола свою логику по извлечению этих параметров.

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

К примеру, в гриде у меня параметры в ячейку передаются таким образом:

public class DevExpressCheckEditCellFiller : IGridCellFiller
{
    public static CheckEdit CreateCheckEditControl(Rectangle cellRectangle, 
      IGridColumn column, object row, object value)
    {
      CheckEdit checkBox = new CheckEdit();

      ...
      checkBox.Size = cellRectangle.Size;

      Color? backColor = SynchronizerHlp.GetBackColor(column, row);

      if (backColor != null)
        checkBox.BackColor = backColor.Value;

      checkBox.Text = SynchronizerHlp.GetCellDescription(column, row);
      ...

      return checkBox;
    }
}

  public class SynchronizerHlp
  {
    public static string GetCellDescription(IGridColumn column, object row)
    {
      Getter<string, object> descriptionGetter = column.GetExtended("CellDescription") as Getter<string, object>;
      if (descriptionGetter == null)
        return null;
      return descriptionGetter(row);
    }
  }


Где IGridColumn это по сути обертка на словарем пар ключ — параметр. Проблем никаких.
Re[45]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 26.07.11 18:23
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.

S>>Так нам придётся протаскивать по всем стеку хелперов несколько слабосвязанных параметров — начиная с геометрии рамки (она необязательно будет прямоугольной) и заканчивая кистями для рамки/фона. И писать для каждого контрола свою логику по извлечению этих параметров.

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

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

U>К примеру, в гриде у меня параметры в ячейку передаются таким образом:


U>
U>public class DevExpressCheckEditCellFiller : IGridCellFiller
U>

Нормальный такой пример. Конкретно по этому примеру сказать нечего, но всеже это не повод передавать аргументы словарями, там где требуется передать больше трех (или N, неважно) слабосвязных значений.

U>Где IGridColumn это по сути обертка на словарем пар ключ — параметр. Проблем никаких.

Переход к утиной типизации проблем никаких не приносит в условиях стабильности кода. Вот когда придется этот код агрессивно менять, и если такого кода окажется достаточно много — вот тогда они придут.
Re[46]: Императивная парадигма
От: Undying Россия  
Дата: 27.07.11 04:44
Оценка:
Здравствуйте, samius, Вы писали:

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


В случае необходимости передачи большого количества параметров возможны три ситуации:

1) Все реализации интерфейса требуют одного и того же набора обязательных параметров. Создаем структуру данных в виде обычного типа с полями и свойствами и передаем ее всем реализациям. Проблем никаких.

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

3) Каждая реализация интерфейса требует своего набора обязательных параметров. В этом случае метод конструировния реализации принимает строго типизированный набор параметров, передавая их далее как словарь. Например, в данном случае вместо new GridColumn(...).CellFiller(CheckCellFiller.Default).BackColor(Color.Wheat) используем CheckCellFiller.CreateColumn(Color.Wheat). Что гарантирует, что мы никакие нужные параметры указать не забудем. Опять же проблем никаких.

Так в каких случаях передача большого количества параметров является проблемой?
Re[47]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 27.07.11 05:10
Оценка:
Здравствуйте, Undying, Вы писали:

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


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


U>В случае необходимости передачи большого количества параметров возможны три ситуации:


U>1) Все реализации интерфейса требуют одного и того же набора обязательных параметров. Создаем структуру данных в виде обычного типа с полями и свойствами и передаем ее всем реализациям. Проблем никаких.

Передаем параметры спецтипом. А что за интерфейс-то? Речь шла о "свободных" функциях и передачи в них аргументов, разве нет?

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

отличий от случая 1) никаких, т.к. он тоже может обрабатывать опциональные параметры с помощью соответствующих полей/свойств/автосвойств в структуре данных. А зачем словарь? Какую проблему он решает?

U>3) Каждая реализация интерфейса требует своего набора обязательных параметров. В этом случае метод конструировния реализации принимает строго типизированный набор параметров, передавая их далее как словарь. Например, в данном случае вместо new GridColumn(...).CellFiller(CheckCellFiller.Default).BackColor(Color.Wheat) используем CheckCellFiller.CreateColumn(Color.Wheat). Что гарантирует, что мы никакие нужные параметры указать не забудем. Опять же проблем никаких.

Только словарь зачем?

U>Так в каких случаях передача большого количества параметров является проблемой?

Большое количество параметров является проблемой само по себе, т.к. требует написания спецкода по их передаче, усложняет рефакторинг. Спецтип для передачи аргументов проблему некоторым образом решает, но приводит либо к изобилию спецтипов, либо к озвученной проблеме, когда непонятно, что именно для какого метода нужно передавать, и что будет изменено внутри вызова.
Безотносительно конкретного примера с гридом, словарь в общем случае ничего не упрощает, только добавляет необходимость в хелперах, достающих и кастующих значения из него.
Re[32]: Императивная парадигма
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.09.11 04:46
Оценка:
Здравствуйте, samius, Вы писали:
S>А есть такая цель? Если ты разработчик этого класса — открой код. Если пользователь — кури доку.
U>>, ни использовать его функциональность в другом классе.
S>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.
Зато от переноса .Skip из List в extension для IEnumerable толку будет очень много. Потому, что мы одним махом написали Skip, который подходит ко всем коллекциям, а не только к List.
Речь-то идёт о том, чтобы освободить те функции, которым не особо нужно быть связанными.
Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Императивная парадигма
От: LaptevVV Россия  
Дата: 02.09.11 04:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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

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

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


G>Не всегда. Процедуры могут неявно менять состояние и будет только иллюзия декларативности.

"Торописса не надо" — надо научиться их правильно готовить...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[33]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 05:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.

S>Зато от переноса .Skip из List в extension для IEnumerable толку будет очень много. Потому, что мы одним махом написали Skip, который подходит ко всем коллекциям, а не только к List.
S>Речь-то идёт о том, чтобы освободить те функции, которым не особо нужно быть связанными.
Я же написал (см выделенное).
Вообще я не до конца понимаю о чем именно идет речь. Терминов "свободный" и "связанный" применительно к функциям я не встречал. Формального определения не видел. Интуитивно я догадываюсь, о чем речь, но боюсь, что могу и ошибаться со своими догадками.

Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.
Я не вижу смысла тащить в класс функции, которые там могут и не быть, как и наоборот, не вижу смысла тащить из класса то, что от него сложно отделяется. Выношу все что выносится, но без садо-мазы.
В дискуссию я влез потому что увидел странное для меня употребление чистоты и детерминированности, не предполагая, что речь идет о выносе/не выносе.
S>Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.
Re[34]: Императивная парадигма
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.09.11 06:46
Оценка:
Здравствуйте, samius, Вы писали:

S>Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.

S>Я не вижу смысла тащить в класс функции, которые там могут и не быть, как и наоборот, не вижу смысла тащить из класса то, что от него сложно отделяется. Выношу все что выносится, но без садо-мазы.
S>В дискуссию я влез потому что увидел странное для меня употребление чистоты и детерминированности, не предполагая, что речь идет о выносе/не выносе.
S>>Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.
Да, с точки зрения терминов и определений тут какой-то бардак.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[28]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 10:37
Оценка:
Здравствуйте, samius, Вы писали:

U>>можно сделать вывод, что функции должны быть "исключительно" свободными?

S>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.

Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же. Уникальная трактовка инкапсуляции, ничего не скажешь. Похоже, паттерны растут именно отсюда
Re[34]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 10:41
Оценка:
Здравствуйте, samius, Вы писали:

S>Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.

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

"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин
Re: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:03
Оценка:
Здравствуйте, AlexCab, Вы писали:

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."

AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

Он не плох и не хорош
Re[29]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


S>>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.


I>Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же.

ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.

I>Уникальная трактовка инкапсуляции, ничего не скажешь. Похоже, паттерны растут именно отсюда

Не уникальнее твоей
Re[35]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин

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

В контексте данного топика его не так давно подобрали
Автор: Undying
Дата: 22.07.11
, что бы он успел устояться.
Re[36]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:14
Оценка:
Здравствуйте, samius, Вы писали:

I>>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин

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

Букварь:
http://www.google.com/search?q=%D1%81%D0%BA%D0%BE%D1%82%D1%82+%D0%BC%D0%B5%D0%B9%D0%B5%D1%80%D1%81+%D1%81%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5+%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8&amp;sourceid=ie7&amp;rls=com.microsoft:en-us:IE-Address&amp;ie=&amp;oe=
Re[30]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:17
Оценка:
Здравствуйте, samius, Вы писали:

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


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


S>>>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.


I>>Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же.

S>ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.

Было
"если львиную долю функциональности держать в свободных функциях,"
ты тут же передёрнул
"львиную долю функциональности вынести в свободные функции не получится"

Ничего нового
Re[37]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин

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

I>Букварь:

I>http://www.google.com/search?q=%D1%81%D0%BA%D0%BE%D1%82%D1%82+%D0%BC%D0%B5%D0%B9%D0%B5%D1%80%D1%81+%D1%81%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5+%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8&amp;sourceid=ie7&amp;rls=com.microsoft:en-us:IE-Address&amp;ie=&amp;oe=

Ты уверен что Undying подразумевал под термином "свободный" non-member non-friend?
Re[31]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


S>>ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.


I>Было

I>"если львиную долю функциональности держать в свободных функциях,"
I>ты тут же передёрнул
I>"львиную долю функциональности вынести в свободные функции не получится"

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

I> Ничего нового

Что ты за птица, что бы тебя удивлять чем-то новым?
Re[32]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:31
Оценка:
Здравствуйте, samius, Вы писали:

I>>"если львиную долю функциональности держать в свободных функциях,"

I>>ты тут же передёрнул
I>>"львиную долю функциональности вынести в свободные функции не получится"

S>Ты забыл процитировать "а функции классов сводить к вызовам свободных функций при минимуме дополнительной логики."


"держать" != "выносить" и дальше от тебя уже пошла подмена. А твоя цитата здесь ничего не меняет.
Re[33]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>"держать" != "выносить" и дальше от тебя уже пошла подмена. А твоя цитата здесь ничего не меняет.

Ты отвечал на мой пост "вынести не получится" фразой "уже получилось". После этого утверждаешь что там должно быть "держать" и что я подменяю понятия.

И вообще, если ты соскучился, то я еще нет.
Re[34]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:51
Оценка:
Здравствуйте, samius, Вы писали:

I>>"держать" != "выносить" и дальше от тебя уже пошла подмена. А твоя цитата здесь ничего не меняет.

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

Конечно подменяешь, просто Undying этого не хочет замечать. А вообще говоря, "Вынос" это вовсе не ожначает " что нечто в одном месте убывает и в другом появляется" Например вынос руля означает что есть минимум два исполнения этого самого руля и безо всякого убывания и появления.
Re[35]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 11:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>А вообще говоря, "Вынос" это вовсе не ожначает " что нечто в одном месте убывает и в другом появляется" Например вынос руля означает что есть минимум два исполнения этого самого руля и безо всякого убывания и появления.

Только в твоей трактовке
http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%BD%D0%BE%D1%81_%D1%80%D1%83%D0%BB%D1%8F
Re[36]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 11:59
Оценка:
Здравствуйте, samius, Вы писали:

I>>А вообще говоря, "Вынос" это вовсе не ожначает " что нечто в одном месте убывает и в другом появляется" Например вынос руля означает что есть минимум два исполнения этого самого руля и безо всякого убывания и появления.

S>Только в твоей трактовке
S>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%BD%D0%BE%D1%81_%D1%80%D1%83%D0%BB%D1%8F

Вот и покажи где там " нечто в одном месте убывает и в другом появляется" ? Вынос руля означает, что руль спереди штыря, никого убывания-появления здесь нет.
Re[37]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 12:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>А вообще говоря, "Вынос" это вовсе не ожначает " что нечто в одном месте убывает и в другом появляется" Например вынос руля означает что есть минимум два исполнения этого самого руля и безо всякого убывания и появления.

S>>Только в твоей трактовке
S>>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%BD%D0%BE%D1%81_%D1%80%D1%83%D0%BB%D1%8F

I>Вот и покажи где там " нечто в одном месте убывает и в другом появляется" ? Вынос руля означает, что руль спереди штыря, никого убывания-появления здесь нет.

"У многих велосипедов выноса руля нет, и горизонтальная труба руля непосредственно присоединяется к рулевому штырю"
Разница в том, крепится ли руль к штырю (в одном месте) либо к выносу — в другом месте.

Подискутируй об этом с кем-нибудь другим
Re[38]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 12:11
Оценка:
Здравствуйте, samius, Вы писали:

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


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


I>>>>А вообще говоря, "Вынос" это вовсе не ожначает " что нечто в одном месте убывает и в другом появляется" Например вынос руля означает что есть минимум два исполнения этого самого руля и безо всякого убывания и появления.

S>>>Только в твоей трактовке
S>>>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%BD%D0%BE%D1%81_%D1%80%D1%83%D0%BB%D1%8F

I>>Вот и покажи где там " нечто в одном месте убывает и в другом появляется" ? Вынос руля означает, что руль спереди штыря, никого убывания-появления здесь нет.

S>"У многих велосипедов выноса руля нет, и горизонтальная труба руля непосредственно присоединяется к рулевому штырю"
S>Разница в том, крепится ли руль к штырю (в одном месте) либо к выносу — в другом месте.

То есть, существует минимум два исполнения этого самого руля и безо всякого убывания и появления. ЧТД.
Re[38]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 12:13
Оценка:
Здравствуйте, samius, Вы писали:

S>Подискутируй об этом с кем-нибудь другим


Вообще, раз ты заменил "держать" на "вынос", то я имею право считать, что ты не видишь разницы между этим словами. Но если видишь и тем не менее заменил — пахнет передёргиванием
Re[39]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 13:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

S>>Разница в том, крепится ли руль к штырю (в одном месте) либо к выносу — в другом месте.


I>То есть, существует минимум два исполнения этого самого руля и безо всякого убывания и появления. ЧТД.

Одновременно в одном велосипеде?
Re[39]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 13:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


S>>Подискутируй об этом с кем-нибудь другим


I>Вообще, раз ты заменил "держать" на "вынос", то я имею право считать

все что угодно
Думаешь, меня интересуют твои права?
Re[40]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 13:12
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Разница в том, крепится ли руль к штырю (в одном месте) либо к выносу — в другом месте.


I>>То есть, существует минимум два исполнения этого самого руля и безо всякого убывания и появления. ЧТД.

S>Одновременно в одном велосипеде?

в разных вариантах дизайна.
Re[41]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 13:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>То есть, существует минимум два исполнения этого самого руля и безо всякого убывания и появления. ЧТД.

S>>Одновременно в одном велосипеде?

I>в разных вариантах дизайна.

Значит с выносом в линк ты напорол
Re[42]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 13:15
Оценка:
Здравствуйте, samius, Вы писали:

I>>>>То есть, существует минимум два исполнения этого самого руля и безо всякого убывания и появления. ЧТД.

S>>>Одновременно в одном велосипеде?

I>>в разных вариантах дизайна.

S>Значит с выносом в линк ты напорол

Не я, а ты, потому что не нужно накакого убывания и появления
Re[40]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 13:21
Оценка:
Здравствуйте, samius, Вы писали:

I>>Вообще, раз ты заменил "держать" на "вынос", то я имею право считать

S>все что угодно
S>Думаешь, меня интересуют твои права?

Это информация на будущее, когда в очередной раз будешь слова менять как тебе вздумается.
Re[41]: Императивная парадигма
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.09.11 13:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


S>>Думаешь, меня интересуют твои права?


I>Это информация на будущее, когда в очередной раз будешь слова менять как тебе вздумается.

Зачем мне эта информация? Тем более, ты искажаешь смысл слов. Что ты там подразумевал — не хочу догадываться.
Re[42]: Императивная парадигма
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.09.11 13:36
Оценка:
Здравствуйте, samius, Вы писали:

S>Зачем мне эта информация? Тем более, ты искажаешь смысл слов.


Неужели это я взял утебя пароль и поменял "держать" на "вынос" ?

Ты мне льстишь
Re[48]: Императивная парадигма
От: Sorc17 Россия  
Дата: 06.09.11 07:57
Оценка:
Вообще-то в определении детерминированной функции ничего не говорится про то, где должны быть её аргументы, как аргументы должны передаваться в функцию и т.д. Говорится только про НЕКИЕ её аргументы и НЕКИЙ её результат. Про результат, кстати, тоже ничего не говорится куда и как функция его возвращает. Так что вы вообще зря тут приплели детерминированные функции.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[49]: Императивная парадигма
От: Sinix  
Дата: 06.09.11 08:22
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Так что вы вообще зря тут приплели детерминированные функции.


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

Тем не менее, детерминированность функции обычно обсуждают с позиции отсутствия побочных эффектов: один и тот же выход при одном и том же входе. Если мы допустим, что детерминированные функции могут изменять внутреннее состояние, то придётся признать детерминированным даже random.Next(). По-моему, это лёгкий перебор.
Re[50]: Императивная парадигма
От: Sorc17 Россия  
Дата: 06.09.11 09:26
Оценка:
Здравствуйте, Sinix, Вы писали:

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


S>>Так что вы вообще зря тут приплели детерминированные функции.


S>Если мы допустим, что детерминированные функции могут изменять внутреннее состояние, то придётся признать детерминированным даже random.Next().


Не понял честно говоря
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[51]: Императивная парадигма
От: Sinix  
Дата: 06.09.11 09:38
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Не понял честно говоря


Тогда я не понял вас Цитирую:

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


Если мы не передаём аргументы через параметры методов и не возвращаем из метода значения — как ещё может осуществляться обмен кроме как через поля?

При таком расширительном толковании даже random.Next() — детерминированная функция. Её результат определяется исключительно seed-ом (его можно задать вручную) и количеством предыдущих вызовов.
Re[52]: Императивная парадигма
От: Sorc17 Россия  
Дата: 07.09.11 10:37
Оценка:
Здравствуйте, Sinix, Вы писали:

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


S>>Не понял честно говоря


S>Тогда я не понял вас Цитирую:

S>

S>... в определении детерминированной функции ничего не говорится про то, где должны быть её аргументы, как аргументы должны передаваться в функцию и т.д. Говорится только про НЕКИЕ её аргументы и НЕКИЙ её результат. Про результат, кстати, тоже ничего не говорится куда и как функция его возвращает.


S>Если мы не передаём аргументы через параметры методов и не возвращаем из метода значения — как ещё может осуществляться обмен кроме как через поля?


Аргумент может лежать в какой-то глобальной переменной, а возвращаемое значение записываться в другую глобальную переменную. Функция от этого не перестанет быть детерминированной. Вот что я имел ввиду.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[53]: Императивная парадигма
От: Sinix  
Дата: 07.09.11 10:44
Оценка:
Здравствуйте, Sorc17, Вы писали:

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


Именно это (по большому счёту) и делает random.Next(). Равно как и почти любой метод, не работающий с внешними источниками — часами/сетью/устройствами ввода etc.

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.