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

S>>Так есть сикп на питоне или нет, что сейчас вместо?
I>СИКП это одновременно и курс, и книга. Язык — Scheme. МИТ от него отказался в пользу курса на питоне для робототехники. кое какие вещи заимствованы.

Кэп, благодарю. А где этот курс хоть находится, можно ссылку? И почему роботехника, сикп всегда был про информатику?

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

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

S>>>Так есть сикп на питоне или нет, что сейчас вместо?
I>>СИКП это одновременно и курс, и книга. Язык — Scheme. МИТ от него отказался в пользу курса на питоне для робототехники. кое какие вещи заимствованы.

S>Кэп, благодарю. А где этот курс хоть находится, можно ссылку? И почему роботехника, сикп всегда был про информатику?

Сикп всегда был про азы программирования, а не про абстрактную информатику.

http://student.mit.edu/catalog/m6a.html 6.0001 это курс которым заменили SICP

У меня все таки сильное ощущение, что Сикп не так хорошо воспринимался, как хотелось бы. Во времена Сикп в МИТ был подготовительный курс как раз на питоне. ПОхоже, челы взяли да оставили питоновский, чучка разнообразив.

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

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

I>Односвязный список — сложная структура, нужно долго вдуплять все операции на ней. А вот массив — тривиальная, её можно объяснить в детском саду на шкафчиках или тумбочках. Т.е. разница в том, каким путём человек осваивает структуры данных.
I>Собственно, мне отец в детском саду про массив и объяснил
Сложной эту структуру делает мутабельность. У неизменяемого списка всего 1 операция — cons. И 3 запроса head/tail/isEmpty. Больше там вдуплять ничего не надо. Это у массива надо вдуплять, как вставить что-то в середину. Со списком — любой, кто понял что такое указатель — получает список бесплатно.

S>>Лишь потому, что в массах есть люди, готовые подхватывать вещи, не оглядываясь на остальную массу. Об этом я и пытался тебе сказать.

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

S>>Говорил, не раз. Расшифрую. Гарантии отсутствия изменений — бесплатная атомарность изменений и консистентность данных. Нет нужды откатывать наполовину переведенную в новое состояние модель. Все само. CAS-update уровня модели, если хочешь.

I>Сколько это в процентах к продуктивности, эффективности? Не в десятки раз, и даже не в разы
Продуктивности чего? Железа? Меня больше моя продуктивность беспокоит. Либо я убью 3 недели (условно) на борьбу за консистентность на изменяемой модели и буду дальше регулярно эту борьбу продолжать при внесении изменений, либо я за неделю делаю неизменяемую модель и вообще не парюсь над консистентностью ровно никогда. Последнее время я выбираю второе, т.к. приходилось много раз проходить оба пути.

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

I>В этом и проблема, что ты весь профит приписываешь функциональщине. Судя по функциональщине, ты намного сильнее, чем ~99% контингента на рынке труда, это навскидку. Только из того, что ты функционалист. Не радикальный, но тем не менее функционалист. Таких примерно 1 на 100 человек.
То что я получаю профит, переписывая мутабельные модели на немутабельные — это говорит за профит функциональщины, а не лично мой. Чем меньше изменяемых данных в проекте, тем проще мне лично. И да, я отдаю себе отчет, что кому-то придется совершать парадигм-шифт, разгребая мои решения. Но так проще. Проект худеет при переходе на функциональщину. И заметного проседания производительности при этом не наблюдается.

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

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

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

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

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

I>Спасибо, капитан! А зачем мне заниматься такими вещами в мутабельной модели, где изменение делается одним присваиванием?
В мутабельной модели такими вещами заниматься незачем, т.к. они мутабельной модели нужны как ежику хобот. Я же что пытаюсь донести? Нет смысла в противопоставлении двух видов модели в вакууме. Типа было все быстро на мутабельной, хопа и по капризу программиста стало медленно на иммутабельной. В иммутабельной есть другие преимущества, я о них и пытаюсь рассказывать (на примере того же списка). Когда поймешь, что это дает помимо ухудшения производительности, взвесишь, что тебе важнее тут производительность или то, что дает иммутабельность, и тогда поймешь, стоит ли возиться с зиппером, или делать деструктивные вещи.
В моей практике деструктивные присваивания обходятся дороже, заставляют больше напрягаться меня и нервничать начальство.

I>Я знаю, как выглядят оба вариантами. Как то так
И я знаю.

S>>Кэширование-мемоизация появляется и в деструктивных структурах. Вопросы о том, где хранить трудновычисляемые свойства, не характерны для одних лишь персистентных моделей.

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

S>>Все присваивания остаются? Что ты под этим подразумеваешь?

I>Мемоизация та же.
В чистом ФП нет присваиваний. Есть lazy evaluation, как в Haskell. Присваивания нет, но оно вычисляется при первой необходимости и автоматом мемоизируется как в мутабельном мире. С eager evaluation моделью мемоизацией приходится заниматься через обновление всей модели. Просто включаешь словарь в саму модель и при необходимости обновить словарь получаешь новую модель.
Если говорить не о чистом ФП, то да, можно мемоизировать как и в мутабельных моделях. Лишь бы снаружи оно вело себя как неизменяемое, предоставляло гарантии того, что однажды запомненное не изменится под капотом. Да, там будут присваивания. Но важно не само присваивание, а гарантия отсутствия осязаемых изменений.

S>>Это твое решение. Полагаю, оно может отличаться от того, что характерно для ФП.

I>Я его не придумывал, а взял готовый подход
Вот скажи, зачем? Ты по приколу его взял, или пытался достичь каких-то целей?

I>Я в курсе. Из этого не следует, что мутабельное сложнее. Весь мир вокруг тебя мутабельный. Отсюда все мышление и даже речь отражает эту особенность. А вот иммутабельное это полезная абстракция, но её надо сначала выкачать и вырастить. Абстракции не копируются из головы в голову, как файлы.
Мир мутабельный? Это как посмотреть. Если ты будешь каждый момент времени получать новое состояние мира, то ничего мутабельного в нем не будет.

I>Порядка нескольких десятков университетов по миру давали этот же курс. Не могу сказать, в полном ли объеме. Раньше я видел кое какие программы преподавания, но сейчас у меня этого нет.
Ок, пусть так.

S>>Просто скажи, где его еще преподают? Достаточно одного примера.

I>Список устаревший. Раньше у меня были более конкретные ссылки.
I>https://mitpress.mit.edu/sites/default/files/sicp/adopt-list.html
Ему более 20и лет.

I>>>Кстати говоря, в Стенфорде уход от СИКП был обоснован тем, что он "мистифицирует виртуальную машину". И это факт.
S>>И о чем нам говорит этот факт?

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

I>А толку смотреть на единичный пример?
Никакого. Но я учился-то не один, не первый и не последний.

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

I>Отбор разный. Даже на самых свирепых специальностях можно нарваться на поток, где половина просто ходит, потому что папа с мамой заставляют.
Вот я такой. Вообще учеба не чесала. За откосом ходил.
I>Сильные студенты из МГУ вероятно сравнимы с МИТ. Но вот слабые примерно одинаково дохлые независимо от вуза. Такая вот нынче картина. В МИТ в силу разного отбора попадают скорее те, что сильнее мотивированы, но могут кое чего не знать.

I>И система образования разная. Из обычной нигерской школы из Балтимора ты никуда не попадёшь, потому что образование стоит очень больших денег, а стало быть надо или получить на стипендию, т.е. доказать что ты уникальный, или хорошо учиться в очень продвинутой школе или очень круто учиться в обычной.
По России сейчас бюджетников 2-3 места на потоке. Из кукуево не пробиться, если папа не пилит бюджеты.

I>С++ и функциональщина это признак, а не причина высокой квалификации. Если студент такое тащит, его надо любыми способами брать на работу. Нашел на том же потоке десяток-другой таких — всё, скважина истощилась, надо искать новую.
И не признак и не причина. Любой курс можно отбыть, сдать и забыть. Можно стать дерьмовым программистом и после сикпа. Или вообще не стать им. Квалификация рождается там, где есть стремление сделать что-то лучше и владение разными техниками.

S>>Односвязный список — лишь простейшая структура данных. Гораздо проще, чем два байта переставить местами и "x = x + 1", которое даже моя школьная математичка с двумя высшими образованиями по математике не смогла осилить.

I>Да не простейшая Массив легко объяснить, т.к. пример шкафчика у всех перед глазами. А вот cons списки вещь нетривиальная, это ведь абстракция, раскрывается на операциях, а не просто так, картинкой.
Вместе с вещью в ящик кладешь next (номер+ключ от следующего). Вот и вся абстракция.

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

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

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

I>>Односвязный список — сложная структура, нужно долго вдуплять все операции на ней. А вот массив — тривиальная, её можно объяснить в детском саду на шкафчиках или тумбочках. Т.е. разница в том, каким путём человек осваивает структуры данных.
I>>Собственно, мне отец в детском саду про массив и объяснил
S>Сложной эту структуру делает мутабельность. У неизменяемого списка всего 1 операция — cons. И 3 запроса head/tail/isEmpty. Больше там вдуплять ничего не надо. Это у массива надо вдуплять, как вставить что-то в середину. Со списком — любой, кто понял что такое указатель — получает список бесплатно.

Из твоих слов непосредтсвенно следует, что cons список не поддерживает вставку в середину.
Указатели, ссылки — это одна из сложных тем. Про это кто только ни писал. Нужно просто принять как данность.
В отличие от этого, с массивом тебе нужен образ шкафчика перед глазами и умение считать по пальцам.

Вот еще пример:
Простейший язык — из 0 и 1. Илиментарно! Всего два символа! Проще не придумаешь!
А сколько времени понадобится на то, что бы, скажем, скажем в старом добром ДОС вывести Hello world или удалить файл на диске именно в этих 0 и 1 ?
Примерно год-два
Про людей, которые умели кодить прямо в hex-редакторе до сих пор ходят легенды

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

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

>Самая большая проблема перехода на 10-пальцевый метод печати в том, что бы забыть, как использовать 3-пальцевый.

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

I>>Сколько это в процентах к продуктивности, эффективности? Не в десятки раз, и даже не в разы
S>Продуктивности чего? Железа? Меня больше моя продуктивность беспокоит. Либо я убью 3 недели (условно) на борьбу за консистентность на изменяемой модели и буду дальше регулярно эту борьбу продолжать при внесении изменений, либо я за неделю делаю неизменяемую модель и вообще не парюсь над консистентностью ровно никогда. Последнее время я выбираю второе, т.к. приходилось много раз проходить оба пути.

1 интересует экономический эффект. Одного твого примера явно недостаточно
2 Консистентность модели можно сломать и в иммутабельной модели целой кучей способов

I>>В этом и проблема, что ты весь профит приписываешь функциональщине. Судя по функциональщине, ты намного сильнее, чем ~99% контингента на рынке труда, это навскидку. Только из того, что ты функционалист. Не радикальный, но тем не менее функционалист. Таких примерно 1 на 100 человек.
S>То что я получаю профит, переписывая мутабельные модели на немутабельные — это говорит за профит функциональщины, а не лично мой.

А прикинь, хирург скажет — это не я, это всё скальпель и медицина!

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

1 ты понимаешь оба варианта, а не только один из них. В противном случае ты не смог бы заниматься такими делами.
2 если проще лично тебе, это не гарантирует экономический профит, т.к. разработка это командная работа
3 во многих задачах такой подход не сработает.

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

Сложность в решениях есть следствие из сложности самой задачи.

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

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

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

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

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

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

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

I>>Спасибо, капитан! А зачем мне заниматься такими вещами в мутабельной модели, где изменение делается одним присваиванием?
S>В мутабельной модели такими вещами заниматься незачем, т.к. они мутабельной модели нужны как ежику хобот. Я же что пытаюсь донести? Нет смысла в противопоставлении двух видов модели в вакууме. Типа было все быстро на мутабельной, хопа и по капризу программиста стало медленно на иммутабельной. В иммутабельной есть другие преимущества, я о них и пытаюсь рассказывать (на примере того же списка).

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

I>>Мемоизация та же.
S>В чистом ФП нет присваиваний. Есть lazy evaluation, как в Haskell. Присваивания нет, но оно вычисляется при первой необходимости и автоматом мемоизируется как в мутабельном мире.

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

> С eager evaluation моделью мемоизацией приходится заниматься через обновление всей модели. Просто включаешь словарь в саму модель и при необходимости обновить словарь получаешь новую модель.
S>Если говорить не о чистом ФП, то да, можно мемоизировать как и в мутабельных моделях. Лишь бы снаружи оно вело себя как неизменяемое, предоставляло гарантии того, что однажды запомненное не изменится под капотом. Да, там будут присваивания. Но важно не само присваивание, а гарантия отсутствия осязаемых изменений.

Да ладно — на примере клиентского приложение — кто будет хранить ссылку на тот самый DOM ? Новый клик, новые изменения, новый инстанс — как это передать в средующий из обрабочиков юзер-эвентов ?
Тебе ни один фремворк не даст пересоздавать новый UI на каждый чих, т.е. это прибито гвоздями к железу-ос-чему-угодно.

I>>Я его не придумывал, а взял готовый подход
S>Вот скажи, зачем? Ты по приколу его взял, или пытался достичь каких-то целей?

В JS эта модель используется для UI, см Redux. Но мне было для интересу.

S>Мир мутабельный? Это как посмотреть. Если ты будешь каждый момент времени получать новое состояние мира, то ничего мутабельного в нем не будет.

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

I>>https://mitpress.mit.edu/sites/default/files/sicp/adopt-list.html
S>Ему более 20и лет.

Это как бы намекает на востребованность Сикп
Лет 10 назад или 15 СИКП преподавался в разных университетах. Скажем, Стенфорд примерно тогда от него откаазлся в пользу Си.

I>>А толку смотреть на единичный пример?
S>Никакого. Но я учился-то не один, не первый и не последний.

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

I>>С++ и функциональщина это признак, а не причина высокой квалификации. Если студент такое тащит, его надо любыми способами брать на работу. Нашел на том же потоке десяток-другой таких — всё, скважина истощилась, надо искать новую.
S>И не признак и не причина. Любой курс можно отбыть, сдать и забыть. Можно стать дерьмовым программистом и после сикпа. Или вообще не стать им. Квалификация рождается там, где есть стремление сделать что-то лучше и владение разными техниками.

Что бы действительно овладеть, надо положить гораздо больше труда, чем "сдать и забыть"

I>>Да не простейшая Массив легко объяснить, т.к. пример шкафчика у всех перед глазами. А вот cons списки вещь нетривиальная, это ведь абстракция, раскрывается на операциях, а не просто так, картинкой.
S>Вместе с вещью в ящик кладешь next (номер+ключ от следующего). Вот и вся абстракция.

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

I>>Кстати, математичке надо было пример привести, скажем, "как поменять содержимое двух ведер" Присваивание сразу начинает получаться
S>нет. Математически не описать действие.

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

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

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

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

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

S>>Сложной эту структуру делает мутабельность. У неизменяемого списка всего 1 операция — cons. И 3 запроса head/tail/isEmpty. Больше там вдуплять ничего не надо. Это у массива надо вдуплять, как вставить что-то в середину. Со списком — любой, кто понял что такое указатель — получает список бесплатно.

I> Из твоих слов непосредтсвенно следует, что cons список не поддерживает вставку в середину.
Ага, а bool не поддерживает хранение чисел с плавающей точкой.
Cons список не поддерживает деструктивные изменения. Но получить новый список с необходимыми изменениями несложно.
I>Указатели, ссылки — это одна из сложных тем. Про это кто только ни писал. Нужно просто принять как данность.
Тогда список без указателей — то что нужно.
I>В отличие от этого, с массивом тебе нужен образ шкафчика перед глазами и умение считать по пальцам.
Поражаюсь, как вы там программы пишете с указателями и массивами?

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

S>>Придумать что-то могут. Но подойти к этому системно, увидеть преимущества и начать их использовать систематически.... С этим проблема-то.

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

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

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

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

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

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

S>>Сложность кроется и в решениях тоже.

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

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


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

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

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

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

I>>>Спасибо, капитан! А зачем мне заниматься такими вещами в мутабельной модели, где изменение делается одним присваиванием?
S>>В мутабельной модели такими вещами заниматься незачем, т.к. они мутабельной модели нужны как ежику хобот. Я же что пытаюсь донести? Нет смысла в противопоставлении двух видов модели в вакууме. Типа было все быстро на мутабельной, хопа и по капризу программиста стало медленно на иммутабельной. В иммутабельной есть другие преимущества, я о них и пытаюсь рассказывать (на примере того же списка).

I>Ты рассказываешь о преимуществах, как будто нет никаких издержек. Для тебя функциональщина это "просто по определению" а между тем это далеко не так. Цена которую надо заплатить может быть уплачена на каждом проекте, мягко говоря.
I>На это Крис Окасаки и намекает.
Видимо, речь о том, что НЕ может быть уплачена на каждом... Да, не на каждом. Я и не призываю пихать фп в каждый проект.

S>>В чистом ФП нет присваиваний. Есть lazy evaluation, как в Haskell. Присваивания нет, но оно вычисляется при первой необходимости и автоматом мемоизируется как в мутабельном мире.

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

>> С eager evaluation моделью мемоизацией приходится заниматься через обновление всей модели. Просто включаешь словарь в саму модель и при необходимости обновить словарь получаешь новую модель.
S>>Если говорить не о чистом ФП, то да, можно мемоизировать как и в мутабельных моделях. Лишь бы снаружи оно вело себя как неизменяемое, предоставляло гарантии того, что однажды запомненное не изменится под капотом. Да, там будут присваивания. Но важно не само присваивание, а гарантия отсутствия осязаемых изменений.

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

S>>Вот скажи, зачем? Ты по приколу его взял, или пытался достичь каких-то целей?

I>В JS эта модель используется для UI, см Redux. Но мне было для интересу.
Сожалею, но я далек от JS.

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

I>>>https://mitpress.mit.edu/sites/default/files/sicp/adopt-list.html
S>>Ему более 20и лет.

С востребованностью СИКП все понятно без намеков. И это удручает меня. Но не удивляет. Востребованность фастфуда или Лады Калины куда выше, чем у здоровой пищи или Лексуса.
I>Это как бы намекает на востребованность Сикп
I>Лет 10 назад или 15 СИКП преподавался в разных университетах. Скажем, Стенфорд примерно тогда от него откаазлся в пользу Си.

I>Лучше смотреть на рынок труда. Как найдут легкий способ освоить ФП, на рынке функционалистов будет как грязи.
Ну а мне это зачем туда смотреть? Не найдут. Указатели бы осилили.

I>Что бы действительно овладеть, надо положить гораздо больше труда, чем "сдать и забыть"
+1

S>>Вместе с вещью в ящик кладешь next (номер+ключ от следующего). Вот и вся абстракция.

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

S>>нет. Математически не описать действие.

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

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

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

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

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

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

Здравствуйте, 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>Некоторые даже переиспользуют пакетики с чаем. И не только их. По человечески это понятно, но "счастье" не сложить из букв "жопа".

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

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

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

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

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

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

С т.е. перформанса это решение хуже, чем сдвиг хвоста после i-го. Более того, если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением.

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


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

Это объясняет, почему ты путаешь просто-сложно с легко-трудно.

Матан — сложный, но легок для того, кто им владеет, и труден для того, кто им не владеет.
Одна переменная — просто, пара переменных — сложно, в соответствии со значением слов в толковом словаре.

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

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

Телепатия ? Факт в том, что перфокарты это убогий вычислитель

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

Я не понимаю этот пример

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

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

Я прямо говорю, что ты или не понимаешь, что такое квалификация, или не понимаешь экономической составляющей этого. У студента есть то же ФП, что и у тебя. Зачем тебя держать то?

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

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

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

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

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

Это значит, что ты решал задачи, которые находил в самом ФП. То есть, снова первичны именно задачи, а не парадигма. Эти же задачи можно найти где угодно и эффект будет тот же.
Более того — если сложность задач не растет, то и квалификация стоит на месте.
Например — пиши ты по сто раз на дню только простые группировки налево-направо, у тебя ни одного шанса запилить файловую систему, т.к. отсутствуют знания-умения-навыки-практика.
Что бы подняться выше, надо таки озадачить себя задачами выше сложности, нежели группировки, и постепенно дойти до файловой системы.

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

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

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

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

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

Есть. Тогда сложность задачи и эквивалентна сложности такого хака, и никак не ниже

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

Если юзеру нужно, то да, надо писать, ошибаться, заниматься поддержкой и тд. А так, что бы само, не бывает ни в одной парадигме.
Даже в ФП можно ошибиться и провести некорректную операцию, например, скипнуть не один элемент, а два. Ну да, он будет иммутабельный, и что ? Юзер получит косяк под нос.

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

Это делает проще некоторые операции и усложняет другие. Например, унутре я заменю аналоги гиперссылки прямой ссылкой. На этом я сэкономлю кучу вычислений, по вычислению id->ссылка.
В итоге выигрываем в перформансе.

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

Чуть ниже ты сам себя опровергаешь

S>Хорошо, упрятали. Зато в коде его нет и это славно.

А это ничего не меняет

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

А вот эфемернось это естественный способ применения изменений. Примерно как картину рисуешь — мазок за мазком.

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

ОМГ! Приложение тип "список задач" уже написали чуть не на всех ЯП. И ФП подход как то не впечатлил.

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

Про цену ФП ты как раз ничего не говоришь, у тебя "там всё просто", "это не я набрался квалификации, это ФП такое крутое"

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

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

S>>Обнуление ячейки очень просто сделать, но очень непросто правильно обслужить. Фактически этим присваиванием ты потенциально сломал несколько контрактов и усложнил код по работе с массивом:

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

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

I>С т.е. перформанса это решение хуже, чем сдвиг хвоста после i-го. Более того, если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением.
Фп решение будет в плане производительности в среднем похуже, чем сдвиг хвоста, но иметь ту же алгоритмическую сложность, как и сдвиг хвоста.

I>Матан — сложный, но легок для того, кто им владеет, и труден для того, кто им не владеет.
С ФП так же. И с ООП так же. В плане сложности они не отличаются от матана. Кто владеет — тому легко.
I>Одна переменная — просто, пара переменных — сложно, в соответствии со значением слов в толковом словаре.
Лайфхак: пара переменных в точности равно одной переменной на декартовом произведении областей определения каждой из переменных. Любое кол-во переменных можно свести к одной.

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

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

I>Телепатия ? Факт в том, что перфокарты это убогий вычислитель
Факт в том, что перфокарта — не вычислитель, а носитель.

S>>А теперь представь, что у тебя нет доступа к памяти в хексе, а фиксить надо.

I>Я не понимаю этот пример
Хексовые редакторы появились гораздо позже терминалов. А до терминалов люди тоже программы писали. И отлаживали и фиксили их. А регистры и адреса уже были.

S>>Намекаешь, что мои работодатели тупые?

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

S>>Проблемы будут и при смене императивного кодера.

I>Риски несравнимо ниже. Для проекта уход функционалиста часто означает конец или полное переписывание. А вот обычные проекты, коих пруд пруди, переживают и смену команды, и смену компании, технологий и чего угодно.
Написать код можно так, что обфускатор не нужен. И это не зависит от парадигмы. Я видел такие проекты, что распускали целые отделы поддержки при уходе на пенсию единственного императивного программиста, понимающего в том коде. И видел проект, где программист мечтал о том, что бы воспользоваться хотя бы сотней мегабайт доступной на PC оперативки. Беда в том, что писали этот проект, когда было 64К памяти (или вроде того). И весь счет был организован оверлеями, что бы памяти хватало. На PC перевели, но теперь никто не знает, как увеличить размерность задачи.

S>>Одинаково. Но нужна практика.

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

I>Это значит, что ты решал задачи, которые находил в самом ФП.
Может быть я в ФП нашел файловую систему?
I>То есть, снова первичны именно задачи, а не парадигма. Эти же задачи можно найти где угодно и эффект будет тот же.
I>Более того — если сложность задач не растет, то и квалификация стоит на месте.
I>Например — пиши ты по сто раз на дню только простые группировки налево-направо, у тебя ни одного шанса запилить файловую систему, т.к. отсутствуют знания-умения-навыки-практика.
I>Что бы подняться выше, надо таки озадачить себя задачами выше сложности, нежели группировки, и постепенно дойти до файловой системы.
Пилил сначала на фп projecteuler, потом на cpp в духе фп сделал html/css-layout engine по бете спеки 5.0 для японцев с ruby annotation, вертикальной разметкой и прочими прелестями, потом файловую систему. Я что-то пропустил?

S>>Почему нельзя? Можно, если студент толковый и согласится на такие условия.

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

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

I>Есть. Тогда сложность задачи и эквивалентна сложности такого хака, и никак не ниже.
Неверный подход. Сложность задачи никак не связана со сложностью решения. Рассуждения такие. Сложность задачи — должна быть константой и не зависеть от сложности решения. Т.к. сейчас есть дно решение и оно сложное. Завтра будет еще одно решение, которое будет проще, но сейчас оно неизвестно. Почему это должно повлиять на сложность задачи? Если повлияло, значит, сложность задачи была неверно оценена. Но и теперь нет уверенности в адекватности оценки, т.к. послезавтра будет еще одно решение. Зачем нужна оценка сложности, которую заведомо нельзя сделать адекватной?

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

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

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

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

I>Чуть ниже ты сам себя опровергаешь
?

S>>Хорошо, упрятали. Зато в коде его нет и это славно.
I>А это ничего не меняет
Ну как это?

S>>Предыдущее состояние в фп — не самоцель.

I>А вот эфемернось это естественный способ применения изменений. Примерно как картину рисуешь — мазок за мазком.
Как в ФП. Каждый мазок дополняет картину, ложась на предыдущие.

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

I>ОМГ! Приложение тип "список задач" уже написали чуть не на всех ЯП. И ФП подход как то не впечатлил.
Потому что ты зациклен на тактах и тем, что под капотом.

I>Про цену ФП ты как раз ничего не говоришь, у тебя "там всё просто", "это не я набрался квалификации, это ФП такое крутое"
Как мне кажется, все устроено следующим образом. Возьмем для примера мутабельный список. Есть новички, которым он в диковинку, есть деды, которые много чего повидали и им там все просто. Причем, арсенал работы со списками у этих дедов стремится к одной величине. Не так много этих приемов там. Вставка, удаление, поменять местами, не знаю, слепить кольцо... Для дедов это не вызывает вопросов, т.к. пройдено и использовано ими уже многократно.
Так же есть конс-список. Сначала с ним сложно, но потом, по мере опыта, оказывается, что кол-во трюков с ним конечно, привычно, элементарно. Дальше и те деды и эти пользуются более сложными инструментами (пусть хэштаблицы). Не важно. Но когда дед из ИП смотрит на конс-список, ему все кажется жуть каким сложным и неэффективным. Но и наоборот. ФП-шник смотрит на мутабельный список и видит одни недостатки.
Однако, в обоих случаях произошел просто выход из зоны комфорта и привычки. Причем, говорить о квалификации на уровне списков будет смешно и тому и другому, т.к. они оперируют задачами, решения которых сильно выходят за рамки списков. Файловые системы, ДОМ-ы, опердени, компиляторы... А список в ип и список в фп — это абстракции примерно одного уровня значимости где-то ниже плинтуса на фоне всего остального.
При этом любой, кто не совсем дерево (утрирую), способен достичь определенной квалификации в ИП. Аналогично, любой, кто не совсем дерево, если будет использовать фп, то он наверняка достигнет определенной квалификации в фп и ип ему будет чужд так же как фп ип-шнику.
Однако, инструменты разные и решения одной и той же задачи в рамках разных парадигм будут разные. Но, где-то что-то будет эффективнее, а где-то что-то вообще не придется решать (как проверку ацикличности либо откаты в графе иммутабельных объектов).

S>В чистом ФП нет присваиваний.

«Чистый ФП» — это сферовакуумный конь. Да еще и многомерный. Нет таких ФП, иначи они работать не могли бы.

S>Есть lazy evaluation, как в Haskell. Присваивания нет, но оно вычисляется при первой необходимости и автоматом мемоизируется как в мутабельном мире.

Ленивость ортогональна к чистоте ФП. Чистота — это отсутсвие сайд эффектов. Поэтому якобы чистые ФЯ типа Хаскеля мастурбируют в присядку, притворяясь, что внешнего мира не существует.

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


S>>В чистом ФП нет присваиваний.

M>«Чистый ФП» — это сферовакуумный конь. Да еще и многомерный. Нет таких ФП, иначи они работать не могли бы.

Вот тут хотелось бы увидеть более развернутый ответ. Например, есть множество работающих программ на Haskell (например, и не только на нем), в которых нет присваиваний. Что в них конкретно похоже на присваивание?

M>Ленивость ортогональна к чистоте ФП. Чистота — это отсутсвие сайд эффектов. Поэтому якобы чистые ФЯ типа Хаскеля мастурбируют в присядку, притворяясь, что внешнего мира не существует.
Ленивость ортогонально чистоте — это верно. Но я и не утверждал обратного.

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

Настоящая проблема и ФП, и ООП в том, что стиль программирования сам по себе перестал быть приманкой для инвесторов (в отличие от событий ~30-летней давности). А значит, стучать в эту точку бессмысленно — толкового хайпа уже не получится.

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

I>>Я порожнее скипнул. Представь для простоты беседы, что я ничего не сломал и не усложнил.
S>Значит, решения по обходу этих сложностей у тебя присутствуют в коде тоже, а не только лишь присваивание ячейки нила.

Могут присутствовать, а могут и нет. Зависит от того, какая именно задача. Например, меня интересует только наличие да-нет, фактически, это частный случай множества. И я имею право реализовать O(1).
А может меня только перечень интересует, вне зависимости от порядка, и здесь тоже есть вариант O(1).

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

I>>С т.е. перформанса это решение хуже, чем сдвиг хвоста после i-го. Более того, если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением.
S>Фп решение будет в плане производительности в среднем похуже, чем сдвиг хвоста, но иметь ту же алгоритмическую сложность, как и сдвиг хвоста.

Ну да, будет отличаться константой, в одном случа 1, а в другом — >1

I>>Матан — сложный, но легок для того, кто им владеет, и труден для того, кто им не владеет.
S>С ФП так же. И с ООП так же. В плане сложности они не отличаются от матана. Кто владеет — тому легко.

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

I>>Одна переменная — просто, пара переменных — сложно, в соответствии со значением слов в толковом словаре.
S>Лайфхак: пара переменных в точности равно одной переменной на декартовом произведении областей определения каждой из переменных. Любое кол-во переменных можно свести к одной.

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

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

1 Ты снова путаешь сложный-простой и легкий-трудный. Слово "сложный" означает "сложенный(глагол складывать) из простых".
2 Азы совсем не азы, т.к. факт в том, что требуют у людей времени на освоение.

>Телепатия ? Факт в том, что перфокарты это убогий вычислитель
S>Факт в том, что перфокарта — не вычислитель, а носитель.

Вычислительная модель и возможности тех машин примитивны.

I>>Я не понимаю этот пример
S>Хексовые редакторы появились гораздо позже терминалов. А до терминалов люди тоже программы писали. И отлаживали и фиксили их. А регистры и адреса уже были.

Это очевидно. Ты думаешь новость выдал ? Факт в том, что те вычислители были примитивными, сравнивая с нынешними системами.

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

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

I>>То есть, мы пришли, что ФП можно вынести за скобки и выбросить, как несущественный признак.
S>Это ты пришел к этому. Я еще нет.

Если функциональщиа так крута, то n студентов функционалистов на твою ЗП должны обеспечить твоему работодателю гораздо бОльший профит.
Это если дело именно в функциональщине.
А раз это не так, и твой работодатель не дурак, надо бы подумать, что не так в этой модели.

I>>Стоит вспомнить, что квалификация есть способность эффективно решать определенные классы задач.
S>Да, но эффективно — здесь не количество тактов CPU.

А почему ты решил, что речь про CPU ?

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

Как ловко ты сам себя опроверг
Инструменты ни при чем. А ФП это именно всего лишь один из инструментов.

I>>Это значит, что ты решал задачи, которые находил в самом ФП.
S>Может быть я в ФП нашел файловую систему?

В самом фп, например, надо научиться целой куче алгоритмов и структур данных. Потому как искаропки ФП не гарантирует нужную асимптотику и можно легко упороться и вместо O(1) получить O(N^^2).

I>>Что бы подняться выше, надо таки озадачить себя задачами выше сложности, нежели группировки, и постепенно дойти до файловой системы.
S>Пилил сначала на фп projecteuler, потом на cpp в духе фп сделал html/css-layout engine по бете спеки 5.0 для японцев с ruby annotation, вертикальной разметкой и прочими прелестями, потом файловую систему. Я что-то пропустил?

Это все твои проекты с начала взрослой жизни ? У тебя всего опыта сколько лет?

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

Лаборанты вы владея основами, могли эти основы применить на высочайшем уровне? Действительно — чудо
У меня был такой студент, с его слов, английского он не знал. Но при этом акцента не было, проблем со словарным запасом не было, задержек, косяков в речи тоже небыло, и тд. Да и вообще, он этот английский не учил никогда, просто 10 лет жил в семье нативных спикеров...

I>>Есть. Тогда сложность задачи и эквивалентна сложности такого хака, и никак не ниже.
S>Неверный подход. Сложность задачи никак не связана со сложностью решения. Рассуждения такие. Сложность задачи — должна быть константой и не зависеть от сложности решения.

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

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

Если решение задачи требует максимально дешовый способ откатить операцию, то иммутабельный ДОМ это круто. Но откуда следуеТ, откат это единственная возможная проблема ?
И чем заплатить за этот иммутабельный ДОМ?

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

В том то и дело. И на мой взгляд наиболее это наиболее актуальная проблемы — некорректные операции и слабая валидация.

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

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

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

См выше — мелкие изменения в мутабельном ДОМ становятся дешевле. Чем тебе здесь мемоизация поможет?

S>Ну как это?

А так, писать нужно учитывая внешний мир.

I>>А вот эфемернось это естественный способ применения изменений. Примерно как картину рисуешь — мазок за мазком.
S>Как в ФП. Каждый мазок дополняет картину, ложась на предыдущие.

Нисколько. Картина изменяется непрерывно, без возможности дешового отката. Откат здесь стоит от "полчаса попотеть" до "выбросить и всё заново" и даже "40% годных изделий считается приемлемым результатом".

I>>ОМГ! Приложение тип "список задач" уже написали чуть не на всех ЯП. И ФП подход как то не впечатлил.
S>Потому что ты зациклен на тактах и тем, что под капотом.

Меня интересуют сам продукт, а не абстрактная крутость технологий. И меня заботит, что будет после моего ухода, и как легко найти себе замену.

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

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

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

ГВ>Настоящая проблема и ФП, и ООП в том, что стиль программирования сам по себе перестал быть приманкой для инвесторов (в отличие от событий ~30-летней давности). А значит, стучать в эту точку бессмысленно — толкового хайпа уже не получится.

Инвесторы просто начали интересоваться более широким перечнем баззвордов. Но принципиально отношение не изменилось — раньше ООП(ФП)-шность давала внимание, сейчас на замену пришли "сервисы", "микросервисы", "клауд", "доккер", "aws", "мобайл", "веб-приложение"

S>Что в них конкретно похоже на присваивание?

При чем тут присваивание? Да ни при чем.

M>>Ленивость ортогональна к чистоте ФП. Чистота — это отсутсвие сайд эффектов. Поэтому якобы чистые ФЯ типа Хаскеля мастурбируют в присядку, притворяясь, что внешнего мира не существует.
S>Ленивость ортогонально чистоте — это верно. Но я и не утверждал обратного.

Да блин. То у тебя чистый ФП обязан иметь ленивость. То он обязан не иметь присваивания. Ни то ни другое к чистоте не имеет отношения.

Чистый ФП — это тот, в котором нет сайд-эффектов. То есть это сферовакуумный конь, потому что такой ФП не сможет даже в файл ничего записать или по сети что-либо прочитать.

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

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

S>>Значит, решения по обходу этих сложностей у тебя присутствуют в коде тоже, а не только лишь присваивание ячейки нила.

I>Могут присутствовать, а могут и нет. Зависит от того, какая именно задача. Например, меня интересует только наличие да-нет, фактически, это частный случай множества. И я имею право реализовать O(1).
I>А может меня только перечень интересует, вне зависимости от порядка, и здесь тоже есть вариант O(1).

В условиях, когда условия задачи не важны, но важно получить O(1) для удаления элемента списка, нет никакого смысла в рассмотрении решений, которые не дают O(1). Что тут еще можно обсуждать?

S>>Фп решение будет в плане производительности в среднем похуже, чем сдвиг хвоста, но иметь ту же алгоритмическую сложность, как и сдвиг хвоста.

I>Ну да, будет отличаться константой, в одном случа 1, а в другом — >1
Сдвиг хвоста массива O(n), но никак не O(1) и не 1.

S>>Лайфхак: пара переменных в точности равно одной переменной на декартовом произведении областей определения каждой из переменных. Любое кол-во переменных можно свести к одной.

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

S>>Ровно потому, что ты говоришь что азы — это сложно. А без них куда?

I>1 Ты снова путаешь сложный-простой и легкий-трудный. Слово "сложный" означает "сложенный(глагол складывать) из простых".
I>2 Азы совсем не азы, т.к. факт в том, что требуют у людей времени на освоение.
Азы — это от буквы "А" в алфавите, которую раньше называли "Аз".

>>Телепатия ? Факт в том, что перфокарты это убогий вычислитель
S>>Факт в том, что перфокарта — не вычислитель, а носитель.

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

S>>Хексовые редакторы появились гораздо позже терминалов. А до терминалов люди тоже программы писали. И отлаживали и фиксили их. А регистры и адреса уже были.

I>Это очевидно. Ты думаешь новость выдал ? Факт в том, что те вычислители были примитивными, сравнивая с нынешними системами.
Чем ты измеряешь примитивность вычислителя, что такое сравнение тебе становится очевидным? Не флопсами, надеюсь?

S>>Написать код можно так, что обфускатор не нужен. И это не зависит от парадигмы.

I>Можно. Но в общем случае функциональное программирование требует бОльших трудозатрат на обучение.
Не очевидно. Можно чем-то подкрепить тезис?

I>>>То есть, мы пришли, что ФП можно вынести за скобки и выбросить, как несущественный признак.
S>>Это ты пришел к этому. Я еще нет.

I>Если функциональщиа так крута, то n студентов функционалистов на твою ЗП должны обеспечить твоему работодателю гораздо бОльший профит.
Мне не очевидна истинность твоей импликации.
I>Это если дело именно в функциональщине.
I>А раз это не так, и твой работодатель не дурак, надо бы подумать, что не так в этой модели.
Подумай, что не так в твоей импликации.

I>>>Стоит вспомнить, что квалификация есть способность эффективно решать определенные классы задач.
S>>Да, но эффективно — здесь не количество тактов CPU.

I>А почему ты решил, что речь про CPU ?
Сделал гиперболу. Если я заменю предположение про такты CPU на O(1) не сильно ошибусь в этот раз?

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

I>Как ловко ты сам себя опроверг
I>Инструменты ни при чем. А ФП это именно всего лишь один из инструментов.
Если почитать внимательно мой ответ, то станет видно, что я не утверждал что инструменты ни при чем. Это твое утверждение.

I>В самом фп, например, надо научиться целой куче алгоритмов и структур данных. Потому как искаропки ФП не гарантирует нужную асимптотику и можно легко упороться и вместо O(1) получить O(N^^2).
Нужная асимптотика вытекает исключительно из требований, которые тебе не любопытны и не важны на стадии выбора решения.

S>>Пилил сначала на фп projecteuler, потом на cpp в духе фп сделал html/css-layout engine по бете спеки 5.0 для японцев с ruby annotation, вертикальной разметкой и прочими прелестями, потом файловую систему. Я что-то пропустил?

I>Это все твои проекты с начала взрослой жизни ? У тебя всего опыта сколько лет?
Это не все мои проекты. Первые программы (не проекты) я начал писать в 1989. Именно проекты — 2000.

S>>аа... Знаешь, студенты разные бывают. Я знаю пару таких, что вечерами на вечернем маялись, а сами днем на должности лаборанта решали такие задачи в оборонке, что у СНС-ов шуба заворачивалась.

I>Лаборанты вы владея основами, могли эти основы применить на высочайшем уровне? Действительно — чудо
I>У меня был такой студент, с его слов, английского он не знал. Но при этом акцента не было, проблем со словарным запасом не было, задержек, косяков в речи тоже небыло, и тд. Да и вообще, он этот английский не учил никогда, просто 10 лет жил в семье нативных спикеров...
Красиво передернул!

S>>Неверный подход. Сложность задачи никак не связана со сложностью решения. Рассуждения такие. Сложность задачи — должна быть константой и не зависеть от сложности решения.

I>Кто такое сказал, что "должна" ? Технологический уровень никто не отменял. Сложность многих задач 100 лет назад была "невозможно", а сейчас "лабораторная, первый семестр".
Выходит, что у тебя со временем растягивается рулетка, которой ты измеряешь сложность. Эталон вшивый. Какой смысл измерять что-то эталоном, который меняется со временем?
I>И для большинства задач мы можем найти или оценить наиболее эффективное решение. Его сложность это примерно количество знаний-умений, которое необходимо человеку-коллективу для реализации.
I>Через сто лет возможно появится новый метод решения. Тогда и сложность будет другой.
Это будет сложность решения, а не задачи. Условия задачи не менялись, значит, любая ее измеряемая характеристика, производная от условия, не должна меняться.
Имерение — от слова "мера".

Ме́ра — философская категория, означающая единство качественной и количественной определённостей некоторого предмета.

Изменилась мера => поменялась оценка => сломалась количественная определенность.

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

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

I>В том то и дело. И на мой взгляд наиболее это наиболее актуальная проблемы — некорректные операции и слабая валидация.
Некорректные операции — неотъемлемая часть работы. А валидация производится исключительно в контексте трансформации ДОМ-а. Собственно, она-то и мешает завершать некоторые трансформации. Однако, попытка выполнить валидацию перед трансформацией приведет как раз к множественным обходам ДОМ-а либо к передаче ссылок на ключевые узлы трансформации от валидации к трансформации. Да и не нужно это. Ради чего? Делать двойной обход что бы выполнить удаление за O(1)? Так себе, идея.

S>>Что мешает заменить прямой ссылкой в фп? Или я что-то не понял?

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

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

I>См выше — мелкие изменения в мутабельном ДОМ становятся дешевле. Чем тебе здесь мемоизация поможет?
Рассказать тебе о том, чем помогает мемоизация?

S>>Ну как это?

I>А так, писать нужно учитывая внешний мир.
Что в нем нужно учитывать кроме входных данных?

S>>Как в ФП. Каждый мазок дополняет картину, ложась на предыдущие.

I>Нисколько. Картина изменяется непрерывно, без возможности дешового отката. Откат здесь стоит от "полчаса попотеть" до "выбросить и всё заново" и даже "40% годных изделий считается приемлемым результатом".
Проблему непрерывности изменения картины в мире (вообще не уверен, что это так) не позволит решить даже присваивание, т.к. оно меняет значение переменной дискретно.

S>>Потому что ты зациклен на тактах и тем, что под капотом.

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

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

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

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

S>>Что в них конкретно похоже на присваивание?

M>При чем тут присваивание? Да ни при чем.
Ваш первый ответ был на мой тезис о том, что в чистом ФП нет присваивания. Если присваивание ни при чем, то что мы обсуждаем?

M>>>Ленивость ортогональна к чистоте ФП. Чистота — это отсутсвие сайд эффектов. Поэтому якобы чистые ФЯ типа Хаскеля мастурбируют в присядку, притворяясь, что внешнего мира не существует.
S>>Ленивость ортогонально чистоте — это верно. Но я и не утверждал обратного.

M>Да блин. То у тебя чистый ФП обязан иметь ленивость. То он обязан не иметь присваивания. Ни то ни другое к чистоте не имеет отношения.
Я не писал о том, что чистый ФП обязан иметь ленивость. Прошу привести цитату.
Про присваивания тоже не так. Я не писал, что ФП обязан не иметь присваивания. Я написал "нет присваиваний". Трактовать это можно широко, но не так, что обязан не иметь присваивания. В Haskell есть присваивания? Насколько мне известно, нет. Могу ошибаться.

M>Чистый ФП — это тот, в котором нет сайд-эффектов.
Уточню, определение не точно, в нем
1) не понятно, что определяется. Мы тут под ФП подразумеваем "функциональную парадигму" или "функциональное программирование". Ни то ни другое не обладает мужским родом и к ним не применимо "тот, в котором". Может быть речь о ФЯ?
2) ближе всего это определение к определению чистой функции. Но там два условия. Вторым есть детерминированность.

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

Я могу привести пару, думаю, этого должно быть достаточно для опровержения того, что чистым ФП нельзя ничего прочитать.

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

I>>А может меня только перечень интересует, вне зависимости от порядка, и здесь тоже есть вариант O(1).

S>В условиях, когда условия задачи не важны, но важно получить O(1) для удаления элемента списка, нет никакого смысла в рассмотрении решений, которые не дают O(1). Что тут еще можно обсуждать?

Когда ты выдал свой вариант копирования массива, заведомо проигрышный, тебя это не смущало

S>>>Фп решение будет в плане производительности в среднем похуже, чем сдвиг хвоста, но иметь ту же алгоритмическую сложность, как и сдвиг хвоста.

I>>Ну да, будет отличаться константой, в одном случа 1, а в другом — >1
S>Сдвиг хвоста массива O(n), но никак не O(1) и не 1.

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

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

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

I>>1 Ты снова путаешь сложный-простой и легкий-трудный. Слово "сложный" означает "сложенный(глагол складывать) из простых".
I>>2 Азы совсем не азы, т.к. факт в том, что требуют у людей времени на освоение.
S>Азы — это от буквы "А" в алфавите, которую раньше называли "Аз".

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

>>>Телепатия ? Факт в том, что перфокарты это убогий вычислитель
S>>>Факт в том, что перфокарта — не вычислитель, а носитель.

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

Ты делаешь какие то предположения, но при этом нисколько не интересуешься тем, что же я имею ввиду

I>>Это очевидно. Ты думаешь новость выдал ? Факт в том, что те вычислители были примитивными, сравнивая с нынешними системами.
S>Чем ты измеряешь примитивность вычислителя, что такое сравнение тебе становится очевидным? Не флопсами, надеюсь?

Если бы мы с тобой общались посредством перфокарт, то вся эта беседа заняла бы годы. Так понятнее?

S>>>Написать код можно так, что обфускатор не нужен. И это не зависит от парадигмы.

I>>Можно. Но в общем случае функциональное программирование требует бОльших трудозатрат на обучение.
S>Не очевидно. Можно чем-то подкрепить тезис?

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

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

I>>Если функциональщиа так крута, то n студентов функционалистов на твою ЗП должны обеспечить твоему работодателю гораздо бОльший профит.
S>Мне не очевидна истинность твоей импликации.

Ну как же — раз всё дело в инструменте, как ты утверждаешь, то будет профит!

I>>А раз это не так, и твой работодатель не дурак, надо бы подумать, что не так в этой модели.
S>Подумай, что не так в твоей импликации.

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

I>>>>Стоит вспомнить, что квалификация есть способность эффективно решать определенные классы задач.
S>>>Да, но эффективно — здесь не количество тактов CPU.

I>>А почему ты решил, что речь про CPU ?
S>Сделал гиперболу. Если я заменю предположение про такты CPU на O(1) не сильно ошибусь в этот раз?

Пример с вертолетом говорит, что ты не понимаешь что же такое эффективность

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

S>Если почитать внимательно мой ответ, то станет видно, что я не утверждал что инструменты ни при чем. Это твое утверждение.

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

I>>В самом фп, например, надо научиться целой куче алгоритмов и структур данных. Потому как искаропки ФП не гарантирует нужную асимптотику и можно легко упороться и вместо O(1) получить O(N^^2).
S>Нужная асимптотика вытекает исключительно из требований, которые тебе не любопытны и не важны на стадии выбора решения.

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

I>>Это все твои проекты с начала взрослой жизни ? У тебя всего опыта сколько лет?
S>Это не все мои проекты. Первые программы (не проекты) я начал писать в 1989. Именно проекты — 2000.

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

I>>Лаборанты вы владея основами, могли эти основы применить на высочайшем уровне? Действительно — чудо
I>>У меня был такой студент, с его слов, английского он не знал. Но при этом акцента не было, проблем со словарным запасом не было, задержек, косяков в речи тоже небыло, и тд. Да и вообще, он этот английский не учил никогда, просто 10 лет жил в семье нативных спикеров...
S>Красиво передернул!

А как еще надо было понять твой аргмент про лаборантов?

I>>Кто такое сказал, что "должна" ? Технологический уровень никто не отменял. Сложность многих задач 100 лет назад была "невозможно", а сейчас "лабораторная, первый семестр".
S>Выходит, что у тебя со временем растягивается рулетка, которой ты измеряешь сложность. Эталон вшивый. Какой смысл измерять что-то эталоном, который меняется со временем?

В каменном веке задача "обеспечить себя едой" была смертельно опасной. А сегодня ты ходишь в магазин без риска, что тебя сожрёт медведь или раздавит мамонт.
Количество труда тогда было бОльше, обучения — меньше. Сейчас ровно наоборот — труда меньше, обучения бОльше.

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

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

I>>И чем заплатить за этот иммутабельный ДОМ?
S>Иммутабельный ДОМ здесь не цель, а средство достижения цели, которая в моем случае важнее, чем предельно низкая асимптотика некоторых операций.

А в моём случае важнее требования к продукту Из них обычно и вытекает низкая асимптотика некоторых операций. Не всегда конечно.

I>>В том то и дело. И на мой взгляд наиболее это наиболее актуальная проблемы — некорректные операции и слабая валидация.
S>Некорректные операции — неотъемлемая часть работы. А валидация производится исключительно в контексте трансформации ДОМ-а. Собственно, она-то и мешает завершать некоторые трансформации. Однако, попытка выполнить валидацию перед трансформацией приведет как раз к множественным обходам ДОМ-а либо к передаче ссылок на ключевые узлы трансформации от валидации к трансформации. Да и не нужно это. Ради чего? Делать двойной обход что бы выполнить удаление за O(1)? Так себе, идея.

Ради удовлетворения требований к производительности.

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

Именно.

S>(но это не мешает в гибридных языках оперировать умными ссылками на узлы ДОМ-а с кэшированием, которая будет перенаходить узел по id-у при протухании. Естественно, этим стоит заниматься лишь при обнаружении проблем с производительностью, связанных именно с поиском по id-у)

Для чего ты это написал? Ты постоянно пишешь какие то банальные вещи и я не могу понять, зачем ты это пишешь?

I>>См выше — мелкие изменения в мутабельном ДОМ становятся дешевле. Чем тебе здесь мемоизация поможет?
S>Рассказать тебе о том, чем помогает мемоизация?

I>>А так, писать нужно учитывая внешний мир.
S>Что в нем нужно учитывать кроме входных данных?

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

I>>Нисколько. Картина изменяется непрерывно, без возможности дешового отката. Откат здесь стоит от "полчаса попотеть" до "выбросить и всё заново" и даже "40% годных изделий считается приемлемым результатом".
S>Проблему непрерывности изменения картины в мире (вообще не уверен, что это так) не позволит решить даже присваивание, т.к. оно меняет значение переменной дискретно.

А нам и не надо "непрерывно". Мазки кладутся именно дискретно. А вот с музыкой все иначе. Но и тут императивщики нашли решение

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

Это почти что уникальный случай, когда шеф понимает техники используемые в коде.

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

Лучшесть зависит от требований и целей. В числодробилках — не лучше. В драйверах — не лучше.

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

В трудах алгоритмистов этого быть не может. Нужно изучать как работает мышление и речь. Какие стадии проходит в развитии. Например, у детей конкретное мышление, синкретическое, а речь — указательно-описательная. Например "бака" может означать "вон там малекое-серенькое-пушистое". У взрослых — абстрактное мышление, и "кот" есть абстракция, которая четко сообщает бОльшую часть признаков.

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

Нужно. Шкаф — это абстракция. Ведро — тоже. Поменять содержимое двух ведер — тоже абстракция, как ни странно

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

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

S>>В условиях, когда условия задачи не важны, но важно получить O(1) для удаления элемента списка, нет никакого смысла в рассмотрении решений, которые не дают O(1). Что тут еще можно обсуждать?

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

I>>>Ну да, будет отличаться константой, в одном случа 1, а в другом — >1
S>>Сдвиг хвоста массива O(n), но никак не O(1) и не 1.

I> А ты, нечитатель.
I>"если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением."
Это ты не читатель того, на что отвечаешь. Твой ответ про 1 был на мое сообщение где упоминался лишь сдвиг хвоста.

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

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

S>>Азы — это от буквы "А" в алфавите, которую раньше называли "Аз".

I>Дети уверенно программируют уже в начальной школе двигая фигурки или набирая простые команды. Функции им начнут объяснять лет через пять.
Ребенок с садика знает, как записываются шахматные ходы. Зачем ему функции, что бы двигать фигурки?

>>>>Телепатия ? Факт в том, что перфокарты это убогий вычислитель
S>>>>Факт в том, что перфокарта — не вычислитель, а носитель.

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

I>Ты делаешь какие то предположения, но при этом нисколько не интересуешься тем, что же я имею ввиду
Неужели ты не про вычислительную модель и возможности? Конечно, это неожиданность для меня. Так что же ты имел ввиду?

S>>Чем ты измеряешь примитивность вычислителя, что такое сравнение тебе становится очевидным? Не флопсами, надеюсь?

I>Если бы мы с тобой общались посредством перфокарт, то вся эта беседа заняла бы годы. Так понятнее?
А если посредством hex редактора, то секунды?

I>>>Можно. Но в общем случае функциональное программирование требует бОльших трудозатрат на обучение.
S>>Не очевидно. Можно чем-то подкрепить тезис?

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

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

I>>>Если функциональщиа так крута, то n студентов функционалистов на твою ЗП должны обеспечить твоему работодателю гораздо бОльший профит.
S>>Мне не очевидна истинность твоей импликации.

I>Ну как же — раз всё дело в инструменте, как ты утверждаешь, то будет профит!
Ты сказал то же самое другими словами. Импликация от этого не стала ближе к истине.

I>>>А раз это не так, и твой работодатель не дурак, надо бы подумать, что не так в этой модели.
S>>Подумай, что не так в твоей импликации.

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

I>Пример с вертолетом говорит, что ты не понимаешь что же такое эффективность
Твоя реакция на него говорит, что ты не понял пример.

I>В таком случае студенты с таким же инструментом должны тебя зарулить в минуса. А раз этого не выходит, следовательно инструмент не является определяющим признаком.
1) Мне так и не понятно, с чем ты споришь.
2) Этого не выходит не потому, что принципиально невозможно. А потому, что я не вижу n студентов на моей зарплате и с моей задачей. Когда увижу — можно будет делать выводы о том, вышло или нет.

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

I>В том то и дело, что асимптотика следует из требований. И это никак не зависит от парадигмы. В императивном программировани у меня нет никаких ограничений.
Здрасьте, приехали. Прям, никаких? Фильтрация списка константное время?
Асимптотика зависит не от парадигмы, а от способа реализации прежде всего. Сделаешь пузырек на императиве и будет O(n ²). Но да, верно, парадигма накладывает ограничения на используемые реализации.
В гибридах, кстати, можно использовать и деструктивные подходы, если удастся доказать что изменяемые коллекции будут использованы лишь локально и не будут торчать наружу явно или неявно (завернутые в типа неизменяемые обертки, меняясь на ходу).
I>С cons-списками это уже не так. Отсюда понятно, почему в числодробилках функциональщина применяется очень ограничено.
Да сколько уже можно? Кроме числодробилок больше нет в IT ничего?

S>>Это не все мои проекты. Первые программы (не проекты) я начал писать в 1989. Именно проекты — 2000.

I>"программы-не-проекты " У тебя в сумме 30 лет опыта. Все задачи, котоыре ты решал за это время, и определяют квалификацию.
Ты спросил — я ответил. Буквально и развернуто.

S>>Выходит, что у тебя со временем растягивается рулетка, которой ты измеряешь сложность. Эталон вшивый. Какой смысл измерять что-то эталоном, который меняется со временем?

I>В каменном веке задача "обеспечить себя едой" была смертельно опасной. А сегодня ты ходишь в магазин без риска, что тебя сожрёт медведь или раздавит мамонт.
Это не задача была опасной, а некоторые методы ее решения. Сегодня те же методы будут так же и даже более опасны, если говорить, например, о попытке завалить слона каменным топором.
I>Количество труда тогда было бОльше, обучения — меньше. Сейчас ровно наоборот — труда меньше, обучения бОльше.
так не везде.

S>>Это будет сложность решения, а не задачи. Условия задачи не менялись, значит, любая ее измеряемая характеристика, производная от условия, не должна меняться.

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

S>>Иммутабельный ДОМ здесь не цель, а средство достижения цели, которая в моем случае важнее, чем предельно низкая асимптотика некоторых операций.

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

S>>Некорректные операции — неотъемлемая часть работы. А валидация производится исключительно в контексте трансформации ДОМ-а. Собственно, она-то и мешает завершать некоторые трансформации. Однако, попытка выполнить валидацию перед трансформацией приведет как раз к множественным обходам ДОМ-а либо к передаче ссылок на ключевые узлы трансформации от валидации к трансформации. Да и не нужно это. Ради чего? Делать двойной обход что бы выполнить удаление за O(1)? Так себе, идея.

I>Ради удовлетворения требований к производительности.
Двойной обход против одного для удовлетворения требований производительности? Ты хоть прочитал, на что отвечаешь?

S>>(но это не мешает в гибридных языках оперировать умными ссылками на узлы ДОМ-а с кэшированием, которая будет перенаходить узел по id-у при протухании. Естественно, этим стоит заниматься лишь при обнаружении проблем с производительностью, связанных именно с поиском по id-у)

I>Для чего ты это написал? Ты постоянно пишешь какие то банальные вещи и я не могу понять, зачем ты это пишешь?
На тот случай, если кто-то прочитает. Мы же не в личке общаемся?

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

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

I>А нам и не надо "непрерывно". Мазки кладутся именно дискретно. А вот с музыкой все иначе. Но и тут императивщики нашли решение
Это ты Фурье императивщиком назвал?

S>>Так и результат от прокачанных абстракций лучше.

I>Лучшесть зависит от требований и целей. В числодробилках — не лучше. В драйверах — не лучше.
Ты споришь или поддакиваешь?

I>>>Мутабельная модель ложится на то мышление, которое формируется с самого детства естественным путём.

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

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

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