Comments 9
Кратко резюмируя итоги нескольких десятилетий развития разработки ПО, вылившиеся в конвергенцию определённых тенденций в современных ЯП: итераторы — плохо, диапазоны — хорошо.
Если честно, то я не согласен с данным мнением. Диапазон, как я понял на слайдах — имеет более лаконичный синтаксис и упрощает их использование, но по факту очень похожи на итераторы.
Мне же хотелось сделать универсальный оператор, в том числе и для работы с информацией из базы данных, а как это сделать к концепцией диапазонов, я даже не представляю.
Мне же хотелось сделать универсальный оператор, в том числе и для работы с информацией из базы данных, а как это сделать к концепцией диапазонов, я даже не представляю.
Упрощает-то он упрощает, но это не главное. Он предотвращает ошибки, связанные с использованием итераторов-«указателей» из разных контейнеров, позволяет избежать проблем инвалидации, а главное — реализовать мощные преобразования, которые можно легко и выразительно связывать в цепочки. А схожесть обусловлена применением для тех же целей. Странно было бы, если бы у них не оказалось ничего общего.
Строго говоря, диапазон — это тоже итератор. Просто практика C++ исторически отталкивалась от указателей и теперь многие по привычке считают, что итератор может быть только указателеподобным.
Тем не менее, многие языки изначально ориентируются на диапазоны, да и в тот же C++ они активно внедряются и наверняка со временем старые итераторы уйдут в прошлое.
Строго говоря, диапазон — это тоже итератор. Просто практика C++ исторически отталкивалась от указателей и теперь многие по привычке считают, что итератор может быть только указателеподобным.
Тем не менее, многие языки изначально ориентируются на диапазоны, да и в тот же C++ они активно внедряются и наверняка со временем старые итераторы уйдут в прошлое.
Вот тут вот пишут, что
Диапазон же можно рассматривать именно как пару итераторов (даже если это на самом деле не так). Диапазон уже знает, где у него конец, может накладывать дополнительную логику на операции с итераторами и т.д.Причем «концепция» итераторов в разных языках отличаются (что совершено логично). Возможно с точки зрения «концепции», мой итератор больше похож именно на диапазон из С++
Мне кажется, я понял, в чем у нас с вами разница в отношении к итераторам (или диапазонам).
Вы рассматриваете итератор/диапазон, как один из множества элементов, доступных для реализации алгоритма в императивном стиле программирования. По сути, вместо него можно использовать множество других способов перебора элементов в коллекции.
А у меня задача с итератором немного другая. Я хочу упростить запись условий при поиске решений заданного алгоритма. Причем в моем случае, итератор является единственным оператором, с помощью которого возможно описать решение задачи. Именно поэтому ему и уделено такое повышенное внимание.
Вы рассматриваете итератор/диапазон, как один из множества элементов, доступных для реализации алгоритма в императивном стиле программирования. По сути, вместо него можно использовать множество других способов перебора элементов в коллекции.
А у меня задача с итератором немного другая. Я хочу упростить запись условий при поиске решений заданного алгоритма. Причем в моем случае, итератор является единственным оператором, с помощью которого возможно описать решение задачи. Именно поэтому ему и уделено такое повышенное внимание.
Здесь, как мне представляется, есть противоречие. Итератор-«указатель» сам по себе глубоко императивен: с его помощью мы описываем извлечение элемента, а потом пишем, что делаем с извлечённым. Диапазон, покрывающий некий набор элементов, позволяет описывать операции с целым набором, поднимаясь на новый уровень абстракции: диапазоны можно фильтровать, преобразовывать, генерировать, объединять, перемешивать и что только не. За счёт этого резко возрастает выразительность и декларативность.
Ну а если мы пытаемся создать абстракцию, предназначенную изначально для как можно более декларативного языка, то хорошо бы отставить в сторону и итераторы и диапазоны и только аккуратно иногда на них поглядывать в плане «а что в них хорошего и почему именно это — хорошо?». Надо попробовать создать собственную абстракцию, наделив её в максимальной мере желательными свойствами. И уж декларативный-то язык как раз скорее должен разговаривать не извлечением элементов по штучке в духе «смыть-повторить».
Ну а если мы пытаемся создать абстракцию, предназначенную изначально для как можно более декларативного языка, то хорошо бы отставить в сторону и итераторы и диапазоны и только аккуратно иногда на них поглядывать в плане «а что в них хорошего и почему именно это — хорошо?». Надо попробовать создать собственную абстракцию, наделив её в максимальной мере желательными свойствами. И уж декларативный-то язык как раз скорее должен разговаривать не извлечением элементов по штучке в духе «смыть-повторить».
хорошо бы отставить в сторону и итераторы и диапазоны и только аккуратно иногда на них поглядыватьИменно так и происходит. Но мне проще (по крайнем мере пока), представлять эту абстракцию именно как итератор. Да и рассказывать про нее тоже удобнее как про итератор, хотя в действительности сейчас выходит, что это ни то, ни другое (не итератор и не диапазон).
Непонятная концепция. Кажется, в попытке упросить вы усложнили:) Автоматический сдвиг итератора вместе с остановкой итератора на последнем элементе, при этом для пустых коллекций это все равно бесполезно…
Спасибо за критику!
И знаете, на самом деле я только проверяю данную концепцию и не до конца уверен, что мне удалось её изложить достаточно точно.
Может быть прав OldFisher в своем комментарии, говоря о том, что термин «итератор» тут не подходит, т.к. несет с собой и ненужные ассоциации из императивного синтаксиса, когда при разработке по определению требуется анализировать, контролировать и управлять обработкой данных.
Для декларативного синтаксиса, такие ассоциации только вредят, т.к. имеются ограничения, которые не позволяют полностью контролировать процесс обработки данных. Поэтому может быть, действительно имеет смысл использовать какой нибудь другой термин вместо итератора. Например, тот же «диапазон», или «ограничение».
И это было бы более правильно. Посмотрите, какая красота получается при использовании этих операторов для решения уравнения:
К примеру, если использовать для этого декларативный синтаксис языка, описанного в статье Необычная концепция синтаксиса языка программирования
И знаете, на самом деле я только проверяю данную концепцию и не до конца уверен, что мне удалось её изложить достаточно точно.
Может быть прав OldFisher в своем комментарии, говоря о том, что термин «итератор» тут не подходит, т.к. несет с собой и ненужные ассоциации из императивного синтаксиса, когда при разработке по определению требуется анализировать, контролировать и управлять обработкой данных.
Для декларативного синтаксиса, такие ассоциации только вредят, т.к. имеются ограничения, которые не позволяют полностью контролировать процесс обработки данных. Поэтому может быть, действительно имеет смысл использовать какой нибудь другой термин вместо итератора. Например, тот же «диапазон», или «ограничение».
И это было бы более правильно. Посмотрите, какая красота получается при использовании этих операторов для решения уравнения:
S E N D
+ M O R E
= M O N E YК примеру, если использовать для этого декларативный синтаксис языка, описанного в статье Необычная концепция синтаксиса языка программирования
S := @range(1, 9);
E := @range(0, 9);
N := @range(0, 9);
D := @range(0, 9);
M := @range(1, 9);
O := @range(0, 9);
R := @range(0, 9);
Y := @range(0, 9);
// Проверка, что аргументы функции не повторяются (встречаются только один раз)
constraint(s,e,n,d,m,o,r,e,y) &&= $@.ValueCount($s)==1, $@.ValueCount($e)==1, $@.ValueCount($n)==1, $@.ValueCount($d)==1, $@.ValueCount($m)==1, $@.ValueCount($o)==1, $@.ValueCount($r)==1, $@.ValueCount($e)==1, $@.ValueCount($y)==1;
// Проверка начальных условий с перебором всех возможных комбинаций
decision(s=S!, e=E!, n=N!, d=D!, m=M!, o=O!, r=R!, e=E!, y=Y!) &&=
@constraint($s,$e,$n,$d,$m,$o,$r,$e,$y),
((1000*$s + 100*$e + 10*$n + $d)
+ (1000*$m + 100*$o + 10*$r + $e))
== (10000*$m + 1000*$o + 100*$n + 10*$e + $y),
$$=" $s$e$n$d\n + $m$o$r$e\n = $m$o$n$e$y\n";decision! // Поиск и вывод первого решения
decision?? // Поиск и вывод всех оставшихся решенийSign up to leave a comment.
Лаконичный итератор для декларативного синтаксиса