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

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

I>>> Из твоих слов непосредтсвенно следует, что cons список не поддерживает вставку в середину.
S>>Ага, а bool не поддерживает хранение чисел с плавающей точкой.
S>>Cons список не поддерживает деструктивные изменения. Но получить новый список с необходимыми изменениями несложно.

I>Ну тогда не надо хитрить, а показать альтернативу. "Несложно" оказывается намного сложнее зануления ячейки x[i] := nil
Обнуление ячейки очень просто сделать, но очень непросто правильно обслужить. Фактически этим присваиванием ты потенциально сломал несколько контрактов и усложнил код по работе с массивом:
1) весь код, обращающийся к элементам массива напрямую или косвенно теперь должен выполнять проверки на nil. Вплоть до компареров, используемых в сортировке.
2) длина массива не соотвествует кол-ву ненулевых элементов и теперь кол-во придется либо получать обходом (привет фп), либо менеджить дополнительный счетчик при любом изменении массива.
3) если в массиве данные были отсортированы, то после обнуления элемента они внезапно перестали быть отсортированы. Перестал работать двоичный поиск в этом массиве.
Не говорю, но упоминаю о вопросе владения массива объектом, необходимости освобождения, уведомления подписчиков и т.п, т.к. и фп не предполагает его решения.

I>Какая будет альтернатива?
сконсить i-1 элементов во временный список, скипнуть i-ый элемент, сконсить элементы временного списка с оставшимся хвостом.
Хорошее решение с массивом (без обнуления элемента) будет примерно схожим — пересоздание массива, с копированием начала и хвоста без i-го элемента. Примерно то же, что и в фп.

I>Еще один "аргумент" в виде намёков на квалификацию? Массив понятен любому, кто пользовался шкафичоком и умеет считать по пальцам. Потому и начинают обучать именно с таких вещей.
Видишь ли, у меня не стоит задача сделать программистом любого, кто пользовался шкафчиком.

I>В hex-редакторе намного труднее, т.к. в перфокартах основные вещи у тебя под носом и там убогая модель вычислений. В хексе нужно держать в голове всю модель кодирования — операции, регистры, смещещния, флаги, порты, адреса и далее уже всё, что может встретиться в твоей программе, а сама модель вычислений довольно развесистая.
ты думаешь на машинах, которые кушали перфокарты нет регистров, флагов, адресов и прочего? Ой как ошибаешься.
I>Собственно, я не про мелке патчи, а про написание полноценных утилит в условиях, когда под рукой нет ни единого инструмента, кроме доступа к памяти в хексе.
А теперь представь, что у тебя нет доступа к памяти в хексе, а фиксить надо.

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

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

I>Намекаешь, что ты экономически невыгоден но тебе всё равно платят?
Намекаешь, что мои работодатели тупые?

I>В том то и дело. Вопрос в том, какой экономический профит и сколько людей на рынке труда могут добиться этой простоты. Если мало, то проблемы будут не сейчас, а когда ты сменишь проект.
Проблемы будут и при смене императивного кодера.

I>Ога. Странно, почему же одни хирурги могут проводить определенные операции ,а другие — нет ? Ведь скальпель и медицина работают одинаково для всех.
Одинаково. Но нужна практика.

I>Вот ниже ты пишешь про файловые системы. Такие задачи говорят о квалификации — то есть, о знаниях и умениях. А вот решаешь ты их с помощью ФП или нет, разницы большой нет.
Пользователю — нет. Для меня разница есть. Скажем, ФП на меня повлияло и изменило мои решения, написанные даже на самом императивном ЯП, даже без поддержки замыканий.

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

S>>Чушь. Опровергается подбором решений разной сложности для одной задачи.

I>Давай проверим. Полагаю, тебе не составит труда подобрать такое решение, скажем, для сортировки списка произвольной длинны, что бы сложность алгоритма была не более, чем у вычисления 2+2.
Ты пытаешься проверить наличие решений разной сложности для некоторых задач, ставя невыполнимые требования к одной конкретной? Удивил меня.

I>Минимальная сложность, это варианты вида "сходить самому", "попросить, чтоб помогли", "приучить, что бы помогали". Может и вертолет понадобится, если ты в горах, а ни дорог, ни магазинов в округе нет.
I>То есть, нижняя планка всегда зависит от задачи. Иначе можно было бы твою файловую систему запилить на коленке выражением вида "2+2"
Есть куча хаков, когда очевидные и нетривиальные решения заменяются неочевидными и тривиальными (с какими-то допущениями, разумеется). Может быть и можно запилить файловую систему каким-нибудь выражением. В конце-концов, полноту по Тьюрингу разных штуковин типа клеточных автоматов никто не отменял. Просто это не тот путь, где я стал бы искать решение данной задачи.

I> Юзер уверен, что система всегда находится в корректном состоянии. Роллбек это обеспечение такой гарантии.
I>Или ты намекаешь, что юзера устроит вариант "кликнул на кнопку, всё пропало, ну и ладно" ?
Я о том, будем ли мы писать код отката, ошибаться в нем, заниматься его поддержкой, либо оно само?

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

I>Проверка на ацикличность обхода это где то второй курс первый семестр, когда учат обходы графов. Избыточность далеко не всегда является проблемой.
Я говорю про то, что в ФП проверка на ацикличность избыточна, т.е. ей не надо заниматься при обновлении ДОМ-а. Это делает решение проще, чем императивное.

I>А ты не говоришь где же проходит граница. А я говорю именно про это. Искать границу нужно не в коде, а на рынке труда
Мне это не нужно.

S>>Похоже, мало ты видел фреймворков. Есть, есть такие. Ладно, UI. У меня есть иммутабельные модели файловых систем в продакшне. Юзеры не жужжат. Наоборот счастливы, когда сравнивают с конкурентами.

I>Много. Всегда разница только в том, что присваивание упрятывают внутрь какого интринсика, стораджа и тд и тд.
Недостаточно много. Либо не искал специально.
Хорошо, упрятали. Зато в коде его нет и это славно.

S>>Что моделирует деструктивное присваивание в мире?

I>Эфемерность мира вокруг тебя. Нет ни единого способа подержать за ниточку предыдущее состояние. В отличие от этого, в ФП ты именно этим и занят все время.
Предыдущее состояние в фп — не самоцель.

S>>Эту сложность ты выдумал. Операции удаления на конс-списках нет. Ты не можешь положить в bool 3.14. Не можешь и удалить из списка. Это дано и ничего с этим делать не нужно. Это простота, а не сложность.

I>Попробуй думать с т.з. энд-юзера. Вот приложение про списки покупок. Как ты сами списки моделируешь — дело десятое, конс, массивы, таблицы и тд, никого не интересует. Есть задача — удалить элемент.
I>И ежу понятно, что в это операция удаления будет моделироваться просто по разному. Фактически, с т.з. бизнеслогики есть операция "на событие x удалить y элементов по признаку z"
I>Вот это удаление можно смоделировать просто как зануление ячейки.
Про зануление я ответил выше. Ты им нагородил столько проблем, что если решать их все, то решение выйдет сложнее, чем если пойти по фп пути.

I>У тебя счастье в чистом ФП, похоже так. А у других в том, на что они ЗП тратят.
Нет, ФП — это средство достижения определенных результатов на определенной работе. Пусть даже, в проектах определенной категории. Я ведь не кричу "все бросайте, айда курить фп"? Я пытаюсь рассказывать о том, как это помогает, что фп не просто имеет цену, но и предлагает кое-что, за что эту цену можно платить. А так же, чем плохи простые императивные решения типа обнуления ячейки массива.