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

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

Ну тогда не надо хитрить, а показать альтернативу. "Несложно" оказывается намного сложнее зануления ячейки x[i] := nil
Какая будет альтернатива?

I>>Указатели, ссылки — это одна из сложных тем. Про это кто только ни писал. Нужно просто принять как данность.
S>Тогда список без указателей — то что нужно.

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

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

I>>Про людей, которые умели кодить прямо в hex-редакторе до сих пор ходят легенды
S>Слабаки. У меня мама фиксила баги прямо ножницами в перфокартах.

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

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

Я указываю на общеизвестный факт.

I>>1 интересует экономический эффект. Одного твого примера явно недостаточно
S>Мне не платят за рассуждения об экономических эффектах. За код, который пишу — платят.

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

I>>2 Консистентность модели можно сломать и в иммутабельной модели целой кучей способов
S>Можно, но добиться гарантий проще.

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

I>>А прикинь, хирург скажет — это не я, это всё скальпель и медицина!
S>И будет прав. Самодеятельность в хирургии не приветствуется. Он не должен резать одного пациента так, другого по-другому, а потом сравнивать, кто быстрее побежит.

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

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

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

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

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

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

I>>В любом случае сложность решаемых задач превосходит сложность технических решений. Из простого складывается сложное, а не наоборот. Это факт.
S>Чушь. Задача — сходить за хлебушком. Решение — вертолет.

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

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

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

I>>Если нечто требует привычки, это вещь трудная а часто и сложная. В данном случае еще и затратнее в ресурсах.
S>Ну уж если указатели и массивы это сложно... Бережем пальцы!

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

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

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

S>Видимо, речь о том, что НЕ может быть уплачена на каждом... Да, не на каждом. Я и не призываю пихать фп в каждый проект.

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

I>>Это значит, что присваивание неявное. Например, пишут в как-бы-сторадж и читают из него.
S>Как-бы-сторадж то ж IO, внешний мир.

Я про это и говорю.

I>>Да ладно — на примере клиентского приложение — кто будет хранить ссылку на тот самый DOM ? Новый клик, новые изменения, новый инстанс — как это передать в средующий из обрабочиков юзер-эвентов ?
S>Ты мыслишь мутабельно. Юзер — это внешний по отношению к чистой программе мир. Юзер — квинтэссенция грязи в грязном мире.
I>>Тебе ни один фремворк не даст пересоздавать новый UI на каждый чих, т.е. это прибито гвоздями к железу-ос-чему-угодно.
S>Похоже, мало ты видел фреймворков. Есть, есть такие. Ладно, UI. У меня есть иммутабельные модели файловых систем в продакшне. Юзеры не жужжат. Наоборот счастливы, когда сравнивают с конкурентами.

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

I>>Мир мутабельный, это факт. А вот "каждый момент времени получать новое состояние мира" это абстракция, к которой можно прийти долгими и упорными тренировками
S>Что моделирует деструктивное присваивание в мире?

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

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

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

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

У тебя счастье в чистом ФП, похоже так. А у других в том, на что они ЗП тратят.

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

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

Ну тогда не надо хитрить, а показать альтернативу. "Несложно" оказывается намного сложнее зануления ячейки x[i] := nil
Какая будет альтернатива?

I>>Указатели, ссылки — это одна из сложных тем. Про это кто только ни писал. Нужно просто принять как данность.
S>Тогда список без указателей — то что нужно.

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

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

I>>Про людей, которые умели кодить прямо в hex-редакторе до сих пор ходят легенды
S>Слабаки. У меня мама фиксила баги прямо ножницами в перфокартах.

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

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

Я указываю на общеизвестный факт.

I>>1 интересует экономический эффект. Одного твого примера явно недостаточно
S>Мне не платят за рассуждения об экономических эффектах. За код, который пишу — платят.

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

I>>2 Консистентность модели можно сломать и в иммутабельной модели целой кучей способов
S>Можно, но добиться гарантий проще.

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

I>>А прикинь, хирург скажет — это не я, это всё скальпель и медицина!
S>И будет прав. Самодеятельность в хирургии не приветствуется. Он не должен резать одного пациента так, другого по-другому, а потом сравнивать, кто быстрее побежит.

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

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

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

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

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

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

I>>В любом случае сложность решаемых задач превосходит сложность технических решений. Из простого складывается сложное, а не наоборот. Это факт.
S>Чушь. Задача — сходить за хлебушком. Решение — вертолет.

Минимальная сложность, это варианты вида "сходить самому", "попросить, чтоб помогли", "приучить, что бы помогали". Может и вертолет понадобится, если ты в горах, а ни дорог, ни магазинов в округе нет.
То есть, нижняя планка всегда зависит от задачи. Иначе можно было бы твою файловую систему запилить на коленке выражением вида "2+2"
Кстати говоря, про эффективность слышал?

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

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

I>>Если нечто требует привычки, это вещь трудная а часто и сложная. В данном случае еще и затратнее в ресурсах.
S>Ну уж если указатели и массивы это сложно... Бережем пальцы!

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

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

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

S>Видимо, речь о том, что НЕ может быть уплачена на каждом... Да, не на каждом. Я и не призываю пихать фп в каждый проект.

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

I>>Это значит, что присваивание неявное. Например, пишут в как-бы-сторадж и читают из него.
S>Как-бы-сторадж то ж IO, внешний мир.

Я про это и говорю.

I>>Да ладно — на примере клиентского приложение — кто будет хранить ссылку на тот самый DOM ? Новый клик, новые изменения, новый инстанс — как это передать в средующий из обрабочиков юзер-эвентов ?
S>Ты мыслишь мутабельно. Юзер — это внешний по отношению к чистой программе мир. Юзер — квинтэссенция грязи в грязном мире.
I>>Тебе ни один фремворк не даст пересоздавать новый UI на каждый чих, т.е. это прибито гвоздями к железу-ос-чему-угодно.
S>Похоже, мало ты видел фреймворков. Есть, есть такие. Ладно, UI. У меня есть иммутабельные модели файловых систем в продакшне. Юзеры не жужжат. Наоборот счастливы, когда сравнивают с конкурентами.

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

I>>Мир мутабельный, это факт. А вот "каждый момент времени получать новое состояние мира" это абстракция, к которой можно прийти долгими и упорными тренировками
S>Что моделирует деструктивное присваивание в мире?

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

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

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

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

У тебя счастье в чистом ФП, похоже так. А у других в том, на что они ЗП тратят.