Сломать шаблон , функциональный подход vs традиционный ООП

[DarkEld3r]

Цитата applegame @ 28.05.15, 16:28

Аналогичный бесконечный ленивый рендж для чисел Фибоначчи можно сделать вот так:

D не знаю, так что интересно - take возвращает список или новый рейндж?

Цитата korvin @ 28.05.15, 16:40

1) Есть такое выражение: «если вы используете UnsafePreformIO, то вам не нужен Haskell» или как-то так.

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

Цитата korvin @ 28.05.15, 16:40

2) Я жду код, а не рассуждения.

Ну код уже есть и похоже D работает не так как я предположил. Мой вариант просто и хоть на плюсах изобразить можно. Хотя, конечно, это будет не прямой аналог. Смысл в следующем: fibs в расте вернёт итератор, который хранит в себе состояние и на котором можно бесконечно звать next, ну а take ограничит этот итератор.

Не думаю, что код что-то изменит.

[applegame]

Цитата DarkEld3r @ 28.05.15, 22:09

D не знаю, так что интересно - take возвращает список или новый рейндж?

Список? Ты наверное имел в виду массив. Нет не список/масив, а новый рейндж. Тоже ленивый. Функции обработки рейнджей в D сделаны лениво везде, где можно сделать их лениво. В частности map и filter тоже возвращают ленивые рейнджи.

Цитата DarkEld3r @ 28.05.15, 22:09

Ну код уже есть и похоже D работает не так как я предположил. Мой вариант просто и хоть на плюсах изобразить можно. Хотя, конечно, это будет не прямой аналог. Смысл в следующем: fibs в расте вернёт итератор, который хранит в себе состояние и на котором можно бесконечно звать next, ну а take ограничит этот итератор.

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

Сообщение отредактировано: applegame - 29.05.15, 06:42

[DarkEld3r]

Цитата applegame @ 29.05.15, 06:38

Список? Ты наверное имел в виду массив.

Это не принципиально.
Меня как раз интересовало как раз "контейнер" там или "честный рейндж".

Цитата applegame @ 29.05.15, 06:38

На самом деле в D все точно так же. recurrence вовзращает рейндж хранящий внутри состояние.

Понятно. Ну в расте, это всё-таки больше "итераторы". В смысле, вывести на печать (стандартными средствами) итератор нельзя. То есть между print и take надо или собирать значения в контейнер или организовывать цикл для прохода.

[D_KEY]

Цитата DarkEld3r @ 29.05.15, 08:15

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

Странный он, этот ваш rust

[applegame]

Цитата DarkEld3r @ 29.05.15, 08:15

Понятно. Ну в расте, это всё-таки больше "итераторы". В смысле, вывести на печать (стандартными средствами) итератор нельзя. То есть между print и take надо или собирать значения в контейнер или организовывать цикл для прохода.

Дешный writeln/writefln почти всеяден. Фактически типобезопасный printf.

Ну вот, шёл, понимаешь, кругом красивая природа, солнышко и тут бац - вступил в говно foldl vs foldl'
Если вдруг у вас переполнение стека, то вместо ленивого foldl воспользуйтесь более strict(строгим?) foldl'. WTF?
На самом деле я, конечно, все понимаю: рекурсия, ленивость и все такое, но математическую красоту слегка опоносили. Это наверное как раз об этом:

Цитата korvin @ 28.05.15, 14:11

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

Сообщение отредактировано: applegame - 29.05.15, 09:50

[DarkEld3r]

Цитата D_KEY @ 29.05.15, 08:16

Странный он, этот ваш rust

Почему странный? В С++ ведь тоже нельзя просто так в printf/cout пару итераторов передать.

Написать функцию которая "проходится по итератору" в расте тоже проблем никаких нет. Аналога ostream_iterator из коробки и правда нет. Но тут как раз всё дело в том, что применение map, filter и других подобных функций возвращает новый ленивый итератор. Для того чтобы получить значения надо итерироваться, ну или собрать значения куда-то.

Добавлено 29.05.15, 09:55

Цитата applegame @ 29.05.15, 09:43

Дешный writeln/writefln почти всеяден. Фактически типобезопасный printf.

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

[korvin]

Цитата applegame @ 29.05.15, 09:43

Ну вот, шёл, понимаешь, кругом красивая природа, солнышко и тут бац - вступил в говно foldl vs foldl'
Если вдруг у вас переполнение стека, то вместо ленивого foldl воспользуйтесь более strict(строгим?) foldl'. WTF?
На самом деле я, конечно, все понимаю: рекурсия, ленивость и все такое, но математическую красоту слегка опоносили. Это наверное как раз об этом:

Цитата korvin @ 28.05.15, 14:11

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

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

Добавлено 29.05.15, 14:14

Цитата applegame @ 28.05.15, 19:34

Ага, korvin смухлевал.

Не, просто поспешил.

Добавлено 29.05.15, 14:16

Цитата DarkEld3r @ 28.05.15, 22:09

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

Трассировка не всегда именно то, что нужно. А сказать я хочу, что ленивость-по-умолчанию не всегда удобна.

[applegame]

Цитата korvin @ 29.05.15, 14:09

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

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

[korvin]

Цитата applegame @ 29.05.15, 15:41

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

А, ну да, я это имел в виду. =)