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

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

Это и ежу понятно. Важно, что применимость массива в задачах связан

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

Я выделил вещи, которые ты скромно обошел вниманием:

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

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

Нужно учитывать связи между значениями. Если значение одно, то про связи думать не нужно. Больше значений — больше связей.
Например, страна + город. Меняешь страну — надо менять и город. Менаешь город — надо или выбирать из списка, или менять страну соответствующим образом. Проще сделать невозможно, можно только упрятать сложность в другое место.

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

В том то и дело, что незачем. Берет и двигает, т.е. непосредственно изменяет состояние, дискретно.

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

Нет желания повторять еще раз.

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

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

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

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

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

А, ну ясно, у тебя монополия на знание действительности

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

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

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

Смешно. Какое именно значение имеет инструмент ? Что важнее инструмента?

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

Вероятно, ты "старался" что бы тебя поняли.

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

Это снова логическая ошибка. Есть причинно-следственная связь между уровнем решаемых задач и наличием/отсутствием студентов в этой области.

I>>В том то и дело, что асимптотика следует из требований. И это никак не зависит от парадигмы. В императивном программировани у меня нет никаких ограничений.
S>Здрасьте, приехали. Прям, никаких? Фильтрация списка константное время?

Сложность этой операции не зависит от парадигмы.

S>Асимптотика зависит не от парадигмы, а от способа реализации прежде всего.

Я тебе это и говорю. И с чем ты спорил?

>Сделаешь пузырек на императиве и будет O(n ²). Но да, верно, парадигма накладывает ограничения на используемые реализации.

Какие то накладывает. Вопрос в том, какие именно.

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

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

I>>С cons-списками это уже не так. Отсюда понятно, почему в числодробилках функциональщина применяется очень ограничено.
S>Да сколько уже можно? Кроме числодробилок больше нет в IT ничего?

Ок. Осталось разобраться с рынком труда.

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

Я констатирую факт — квалификация определяется не просто твоими 30ю годами опыта, а их наполнением — как изучением, так и применением изученного. Это, кстати, дает ответ, почему нет студентов на твоей ЗП в твоей области.

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

За мамонтами не просто так бегали, абы доблесть показать. Это было необходимо для выживания. Сегодня все не так. Соотсветсвенно, нет необходимости валить слонов за еду.

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

Ранние решения потеряли актуальность.

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

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

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

Стоит открыть типичный код обработки звука, и увидеть, что он насквозь императивный.

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

А смысл?

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

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

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

Мой ответ был не про присваивания, а про термин «Чистый ФП».

S>>>Ленивость ортогонально чистоте — это верно. Но я и не утверждал обратного.

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

Именно, что утверждал.

M>>Чистый ФП — это тот, в котором нет сайд-эффектов.
S>Уточню, определение не точно, в нем

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

Можно поспорить о понятии сайд эффектов, но обычно под этим принимаются изменение глобальных переменных, состояния и т.п. При этом внутри себя там может быть хоть блэкджек со шлюхами: присваивания, eager evaluation, да хоть создание объектов из Java-классов и императивная работа с ними.

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

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

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

M>Мой ответ был не про присваивания, а про термин «Чистый ФП».
Что это за термин? Я его не вводил, а использовал как собирательный образ.

S>>>>Ленивость ортогонально чистоте — это верно. Но я и не утверждал обратного.

M>

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

M>Именно, что утверждал.
Это не утверждение того, что чистоты не бывает без lazy. Здесь "есть" = "встречается, существует".

S>>Уточню, определение не точно, в нем

M>Достаточно точно. В чистом ФП требуется, чтобы функции:
M>- зависели только от принимаемых на вход данных
M>- для одинаковых входных данных всегда одинаковый результат
M>- нет сайд-эффектов
Это определение ФУНКЦИИ. Но не ФП.

M>Можно поспорить о понятии сайд эффектов, но обычно под этим принимаются изменение глобальных переменных, состояния и т.п. При этом внутри себя там может быть хоть блэкджек со шлюхами: присваивания, eager evaluation, да хоть создание объектов из Java-классов и императивная работа с ними.
Функция со шлюхами может быть чистой по определению, но если в ней использованы присваивания и другая императивная работа, она не будет образцом функционального программирования. Именно об этом я писал "В чистом ФП нет присваиваний".

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

Грубо говоря, функция вида

Action main() = () => { Console.WriteLine("Hello"); }

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

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

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

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

I>Это и ежу понятно. Важно, что применимость массива в задачах связан
??? Не понял.

S>>Это ты не читатель того, на что отвечаешь. Твой ответ про 1 был на мое сообщение где упоминался лишь сдвиг хвоста.

I>Я выделил вещи, которые ты скромно обошел вниманием:
I>С т.е. перформанса это решение хуже, чем сдвиг хвоста после i-го. Более того, если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением.
Что именно тут требует моих комментариев?
I>Более того — пересоздание это местечковая операция, а если массив это часть некоего контейнера, то фокус в принципе невозможен.
Даже не припомню, когда мне последний раз приходило в голову портить массив внутри некоего контейнера типа List<T> или Dictionary...

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

I> Нужно учитывать связи между значениями. Если значение одно, то про связи думать не нужно. Больше значений — больше связей.
I>Например, страна + город. Меняешь страну — надо менять и город. Менаешь город — надо или выбирать из списка, или менять страну соответствующим образом. Проще сделать невозможно, можно только упрятать сложность в другое место.
Откуда взялись связи при построении кортежа?

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

I>В том то и дело, что незачем. Берет и двигает, т.е. непосредственно изменяет состояние, дискретно.
изменяет состояние == получает новое состояние поля (ДОМ-а).

S>>А если посредством hex редактора, то секунды?

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

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

I>Это логическая ошибка "порочный круг". На самом деле есть вполне объективные причины слабой популярности чистого ФП.
Раз есть причины, то и нет смысла сравнивать частоту проявления "учится за неделю-две". Сам себя опровергаешь. Давай хотя бы сравнивать удельную частоту (на 100000 учеников). Подгонишь данные для сравнения с той же легкостью, как и в абсолюте?

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

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

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

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

I>Смешно. Какое именно значение имеет инструмент ?
Вот представь, что ты не владеешь императивным программированием. Ну или ООП. Имеет значение?
I>Что важнее инструмента?
Важнее инструмента владение им. Наличие инструмента при полном невладении им равно отсутствию инструмента.

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

I>Это снова логическая ошибка. Есть причинно-следственная связь между уровнем решаемых задач и наличием/отсутствием студентов в этой области.

Ты хочешь сказать что нет студентов на моем уровне задач? Я говорил о студентов в моей конторе. О других я мало что знаю. Откуда такая уверенность, что там нет студентов?

I>>>В том то и дело, что асимптотика следует из требований. И это никак не зависит от парадигмы. В императивном программировани у меня нет никаких ограничений.
S>>Здрасьте, приехали. Прям, никаких? Фильтрация списка константное время?

I>Сложность этой операции не зависит от парадигмы.
Т.е. ограничения таки есть.

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

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

S>>Да сколько уже можно? Кроме числодробилок больше нет в IT ничего?

I> Ок. Осталось разобраться с рынком труда.
Что с ним не так?

I>Я констатирую факт — квалификация определяется не просто твоими 30ю годами опыта, а их наполнением — как изучением, так и применением изученного. Это, кстати, дает ответ, почему нет студентов на твоей ЗП в твоей области.
У меня нет данных о наличии студентов на моей ЗП в моей области. А у тебя есть ответ почему. Интересно.
10 лет назад я работал на одну медицинскую контору, там как раз было много студентов с моей ЗП и в моей области. Именно они меня подтолкнули к ФП.

I>За мамонтами не просто так бегали, абы доблесть показать. Это было необходимо для выживания. Сегодня все не так. Соотсветсвенно, нет необходимости валить слонов за еду.
Так я о том, что сейчас доступно множество инструментов для выполнения задачи "набить брюхо" и из них можно выбирать. Либо выбирать более рисковые, что бы набить брюхо сейчас, либо менее рисковые, что бы набить его через пол года (вырастив урожай чего-то). Платить приходится риском за скорость. Или скоростью за отсутствие риска. Инструмент имеет значение. Нет инструмента — нет выбора.

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

I>Ранние решения потеряли актуальность.
Сафари еще довольно актуально.

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

S>>Это ты Фурье императивщиком назвал?

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

S>>Оказывается, проблема-то не в абстракциях, которые надо качать в фп, т.к. их и без программирования надо качать!

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

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

Ну то есть ты пишешь одно, а подразумеваешь другое, но мы виноваты в том, что тебя не поняли

S>Грубо говоря, функция вида
S>

S>Action main() = () => { Console.WriteLine("Hello"); }
S>

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

Именно это я имею в виду:

из кожи вон лезет, чтобы притвориться, что он не делает сайд-эффектов. И притворяется, что IO — это не Хаскель. Это всего лишь вызов нечистой силы, которая к Хаскелю не имеет отношения.

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

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

I>>Это и ежу понятно. Важно, что применимость массива в задачах связан
S>??? Не понял.

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

I>>Я выделил вещи, которые ты скромно обошел вниманием:
I>>С т.е. перформанса это решение хуже, чем сдвиг хвоста после i-го. Более того, если порядок не важен, нам вообще хватит обмен i-го c последним с последующим занулением.
S>Что именно тут требует моих комментариев?
I>>Более того — пересоздание это местечковая операция, а если массив это часть некоего контейнера, то фокус в принципе невозможен.
S>Даже не припомню, когда мне последний раз приходило в голову портить массив внутри некоего контейнера типа List<T> или Dictionary...

Ну вот есть такой вариант дизайна, он сомнительный, но слишком часто используется — разделяемый экземпляр массива

I>> Нужно учитывать связи между значениями. Если значение одно, то про связи думать не нужно. Больше значений — больше связей.
I>>Например, страна + город. Меняешь страну — надо менять и город. Менаешь город — надо или выбирать из списка, или менять страну соответствующим образом. Проще сделать невозможно, можно только упрятать сложность в другое место.
S>Откуда взялись связи при построении кортежа?

Известно откуда. В России нет города Балтимор, а из названия города Воронеж однозначно следует какая должна быть страна.
У тебя, конечно, может быть другое мнение — выбираешь город Воронеж, страну Люксембург и дело в шляпе.

I>>В том то и дело, что незачем. Берет и двигает, т.е. непосредственно изменяет состояние, дискретно.
S>изменяет состояние == получает новое состояние поля (ДОМ-а).

Ничего нового он не получает — всё те же фигуры, все та же доска.

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

Ты снова путаешь легко-трудно и сложно-просто. С перфокартами получить труднее, а в силу этого сложных программ написать сильно вряд ли получится, вспотеешь пыль глотать.

Кстати говоря, для старых машин испокон веков был пульт управления, в которых N ламп или светодиодов отражали состояние памяти. С клавиатуры меняешь состояние, делаешь прогон, получаешь результаты.
Это ровно тот же подход, что и в hex, только безо всяких промежуточных перфокарт.

I>>Это логическая ошибка "порочный круг". На самом деле есть вполне объективные причины слабой популярности чистого ФП.
S>Раз есть причины, то и нет смысла сравнивать частоту проявления "учится за неделю-две". Сам себя опровергаешь.

Я показываю вещи, которые как раз таки легко проверить.

I>>Очевидно, что инструмены всегда вторичны. Их создают или подбирают после осознания задачи и выбора решения.
S>Как ты можешь выбрать решение, если ты не знаком с инструментом? Ты ФП не сможешь выбрать, тебя остановят те вопросы, которые ты мне тут задаешь. И то, что удаление из списка дороже чем O(1).

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

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

Если умеешь на дудке, то ты можешь получить музыкальное образование, даже не прикасаясь к скрипке. Более того, сколько ты денег заработаешь, сколько принесешь пользы, никак не зависит от того, какой у тебя инструмент.

I>>Смешно. Какое именно значение имеет инструмент ?
S>Вот представь, что ты не владеешь императивным программированием. Ну или ООП. Имеет значение?

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

I>>Что важнее инструмента?
S>Важнее инструмента владение им. Наличие инструмента при полном невладении им равно отсутствию инструмента.

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

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

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

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

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

I>> Ок. Осталось разобраться с рынком труда.
S>Что с ним не так?

Все так. Место ФП не соответствует представлениям функционалистов

I>>Я констатирую факт — квалификация определяется не просто твоими 30ю годами опыта, а их наполнением — как изучением, так и применением изученного. Это, кстати, дает ответ, почему нет студентов на твоей ЗП в твоей области.
S>У меня нет данных о наличии студентов на моей ЗП в моей области. А у тебя есть ответ почему. Интересно.
S>10 лет назад я работал на одну медицинскую контору, там как раз было много студентов с моей ЗП и в моей области. Именно они меня подтолкнули к ФП.

Здесь может быть много объяснений, ФП — наименее вероятное. А что касается "подтолкнули", то это нормально — так всегда и происходит, молодые подталкивают к новому.

S>Так я о том, что сейчас доступно множество инструментов для выполнения задачи "набить брюхо" и из них можно выбирать. Либо выбирать более рисковые, что бы набить брюхо сейчас, либо менее рисковые, что бы набить его через пол года (вырастив урожай чего-то). Платить приходится риском за скорость. Или скоростью за отсутствие риска. Инструмент имеет значение. Нет инструмента — нет выбора.

У тебя похоже инструмент давно стал синонимом квалификация

I>>Ранние решения потеряли актуальность.
S>Сафари еще довольно актуально.

И сколько раз в месяц, в среднем, ты учавствуешь в этом?

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

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

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

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

I>>Вопрос в том, где и как часто встречаются абстракции. Со шкафом и ведрами дети умеют управляться еще до школы. То есть, уровень абстракций никто не отменял.
S>Ребенок до школы (4-5 лет) управляется с рисованием картинок в блокноте и анимацией их без изменения "стостояния" каждой из них.

Что за парадигма, это легко проверить. Попроси его изменить пару кадров, ведь "в ДОМ удаление менее чем линейно".
Императивная модель — берем и изменяем состояние, а именно — подкорректировали кадр по месту или заменили листок новым, затраты не зависят от количества кадров.
Поскольку "в ДОМ удаление менее чем линейно", ребенку не составит труда за аналогичное или даже меньшее время внести изменения.

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

M>>Можно поспорить о понятии сайд эффектов, но обычно под этим принимаются изменение глобальных переменных, состояния и т.п. При этом внутри себя там может быть хоть блэкджек со шлюхами: присваивания, eager evaluation, да хоть создание объектов из Java-классов и императивная работа с ними.
S>Функция со шлюхами может быть чистой по определению, но если в ней использованы присваивания и другая императивная работа, она не будет образцом функционального программирования. Именно об этом я писал "В чистом ФП нет присваиваний".

Что унутре — дело десятое, главное, что бы у нас не было 1 наблюдаемых сайд-эффектов 2 внешнего доступа к таким вещам

Добавлять функциональщину ради функциональщины лично я смысла не вижу.

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

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

M>Ну то есть ты пишешь одно, а подразумеваешь другое, но мы виноваты в том, что тебя не поняли
Я писал то, что подразумевал.

S>>Грубо говоря, функция вида
S>>

S>>Action main() = () => { Console.WriteLine("Hello"); }
S>>

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

M>Именно это я имею в виду:

M>

M>из кожи вон лезет, чтобы притвориться, что он не делает сайд-эффектов. И притворяется, что IO — это не Хаскель. Это всего лишь вызов нечистой силы, которая к Хаскелю не имеет отношения.

В чем заключается сайд-эффект обозначенной функции main?

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

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

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

S>>Даже не припомню, когда мне последний раз приходило в голову портить массив внутри некоего контейнера типа List<T> или Dictionary...

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

S>>Откуда взялись связи при построении кортежа?

I>Известно откуда. В России нет города Балтимор, а из названия города Воронеж однозначно следует какая должна быть страна.
I>У тебя, конечно, может быть другое мнение — выбираешь город Воронеж, страну Люксембург и дело в шляпе.
Выходит,
foo(x, y) — можно, ничто не мешает, а
foo((x, y)) — нельзя, т.к. в России нет города Балтимор.
Красиво переобулся. Прям, вы прыжке.

I>>>В том то и дело, что незачем. Берет и двигает, т.е. непосредственно изменяет состояние, дискретно.
S>>изменяет состояние == получает новое состояние поля (ДОМ-а).

I>Ничего нового он не получает — всё те же фигуры, все та же доска.
Состояние новое.

I>Кстати говоря, для старых машин испокон веков был пульт управления, в которых N ламп или светодиодов отражали состояние памяти. С клавиатуры меняешь состояние, делаешь прогон, получаешь результаты.
I>Это ровно тот же подход, что и в hex, только безо всяких промежуточных перфокарт.
Да, конечно. Вводишь с пульта программу, вводишь с пульта данные, прогоняешь. Не получилось — снова. Успехов!
Сам-то поди исходники в файлах хранишь, а не пайпишь copy con в компилятор?

S>>Раз есть причины, то и нет смысла сравнивать частоту проявления "учится за неделю-две". Сам себя опровергаешь.

I>Я показываю вещи, которые как раз таки легко проверить.
Проверь удельную частоту "учится за неделю-две".

S>>Как ты можешь выбрать решение, если ты не знаком с инструментом? Ты ФП не сможешь выбрать, тебя остановят те вопросы, которые ты мне тут задаешь. И то, что удаление из списка дороже чем O(1).

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

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

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

S>>Вот представь, что ты не владеешь императивным программированием. Ну или ООП. Имеет значение?

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

S>>Важнее инструмента владение им. Наличие инструмента при полном невладении им равно отсутствию инструмента.

I> А по моему важнее Computer Sciense, включая алгоритмы-структуры данных, и доменная область.
Ты в пол шаге от того, что ФП или ИП — не имеет значения.

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

I>Ты намекаешь, что 30 лет ничего не делал? Каким чудом студент за два года освоит всё, что ты накопил за 30 лет?
I>Попробуюй таки ответить прямо, не увиливая, что за способности должны быть у такого студента.
Я не говорил о том, что он освоит все, что я накопил. Другое дело, что то, что я накопил — оно не очень ценно с точки зрения сегодняшнего студента. При наличии правильных подходов и примерно одного уровня доменной области, можно как раз срезать лет 25, выкинув хлам. Например, у меня годы ушли на изучение и работу с турбопаскалем, Delphi, MFC, COM... А если меняешь еще и доменную область (например, с оборонки в медицину, как это у меня было), то и оказываешься нос к носу со студентами.
А структуры данных — повторю, тут нет разницы, работаешь ты с ними год-два или тридцать. Арсенал практических методов работы с массивом/списком/картой будет примерно схожим. Я говорю не об исследованиях уровня Кнута/Окасаки, а о ежедневной практике на рынке труда в CS.

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

I>>> Ок. Осталось разобраться с рынком труда.
S>>Что с ним не так?

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

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

S>>Так я о том, что сейчас доступно множество инструментов для выполнения задачи "набить брюхо" и из них можно выбирать. Либо выбирать более рисковые, что бы набить брюхо сейчас, либо менее рисковые, что бы набить его через пол года (вырастив урожай чего-то). Платить приходится риском за скорость. Или скоростью за отсутствие риска. Инструмент имеет значение. Нет инструмента — нет выбора.

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

S>>Сафари еще довольно актуально.

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

S>>Разумеется, но в ФП удаление элемента из ДОМ в среднем менее чем линейное от размера дерева ДОМ.

I> Похоже, ФП у тебя стало синонимом "хорошо". Если хорошо, с присваиваниями, то это ФП, если плохо, но иммутабельно, то это не ФП.
Не все, что чисто — есть фп. Не все, что фп — чисто.
I>На самом деле затраты зависят от того, сколько было ссылок на узел. Правильное решение находится в книге про алгоритмы, а не в учебнике функионального программирования.
Я не говорил, что решение в учебнике ФП. Цена обновления дерева в среднем — его высота. типичный ДОМ — дерево ссылок.

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

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

I> Что за парадигма, это легко проверить. Попроси его изменить пару кадров, ведь "в ДОМ удаление менее чем линейно".
I>Императивная модель — берем и изменяем состояние, а именно — подкорректировали кадр по месту или заменили листок новым, затраты не зависят от количества кадров.
Не зависят от количества кадров, значит O(1), согласен?
I>Поскольку "в ДОМ удаление менее чем линейно", ребенку не составит труда за аналогичное или даже меньшее время внести изменения.
С чего ты взял, что менее чем линейно будет аналогично или меньше чем O(1)?
Удаление из дерева действительно менее чем линейно, но дороже, чем O(1) в среднем.

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

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

I>Что унутре — дело десятое, главное, что бы у нас не было 1 наблюдаемых сайд-эффектов 2 внешнего доступа к таким вещам
Да, это важно. И именно это.

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

M>>Ну то есть ты пишешь одно, а подразумеваешь другое, но мы виноваты в том, что тебя не поняли
S>Я писал то, что подразумевал.

Вот, что ты писал:

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

Перевод: ты подразумеваешь и утверждаешь, что в чистом ФП нет присваиваний и есть ленивые вычисления. Когда тебя тыкаешь в твои же слова, ВНЕЗАПНО оказывается

Я не писал, что ФП обязан не иметь присваивания. Я не писал о том, что чистый ФП обязан иметь ленивость.

S>В чем заключается сайд-эффект обозначенной функции main?

Ни в чем. Она сферовакуумно выполняется. IO является мифом, его не существует.

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

M>Вот, что ты писал:

M>

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

M>Перевод: ты подразумеваешь и утверждаешь, что в чистом ФП нет присваиваний и есть ленивые вычисления. Когда тебя тыкаешь в твои же слова, ВНЕЗАПНО оказывается

M>

M>Я не писал, что ФП обязан не иметь присваивания. Я не писал о том, что чистый ФП обязан иметь ленивость.

M>
Про присваивания я уже написал. Про lazy evaluation — ну что, будешь отрицать что оно в Хаскеле есть? Или будешь настаивать на том, что я написал про любой функциональный язык, что в нем lazy?

S>>В чем заключается сайд-эффект обозначенной функции main?

M>Ни в чем. Она сферовакуумно выполняется. IO является мифом, его не существует.
В определении чистоты функции не упоминается мифология и сферовакуумность.
Итого, сайд-эффекта нет, детерминированность есть, main чиста, весь код программы может быть чист, но

Нет таких ФП, иначи они работать не могли бы.

S>Про присваивания я уже написал. Про lazy evaluation — ну что, будешь отрицать что оно в Хаскеле есть? Или будешь настаивать на том, что я написал про любой функциональный язык, что в нем lazy?

Что ты писал, я процитировал.

M>>Ни в чем. Она сферовакуумно выполняется. IO является мифом, его не существует.
S>В определении чистоты функции не упоминается мифология и сферовакуумность.
S>Итого, сайд-эффекта нет, детерминированность есть, main чиста, весь код программы может быть чист, но

Да-да. Console.WriteLine является чистым. Потому что IO — это миф.

S>

Нет таких ФП, иначи они работать не могли бы.

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

Потому что

Чистое ФП возможно только в строго изолированных кусках, например, в отдельных функциях или там отдельных модулях программы.

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

S>>Про присваивания я уже написал. Про lazy evaluation — ну что, будешь отрицать что оно в Хаскеле есть? Или будешь настаивать на том, что я написал про любой функциональный язык, что в нем lazy?

M>Что ты писал, я процитировал.
Именно. Но не понял.

M>>>Ни в чем. Она сферовакуумно выполняется. IO является мифом, его не существует.
S>>В определении чистоты функции не упоминается мифология и сферовакуумность.
S>>Итого, сайд-эффекта нет, детерминированность есть, main чиста, весь код программы может быть чист, но

M>Да-да. Console.WriteLine является чистым. Потому что IO — это миф.
Что за чушь?

S>>

Нет таких ФП, иначи они работать не могли бы.

M>Именно. Те языки, которые утверждают, что они чистые, типа Хаскеля, просто притворяются, что внешнего мира, IO, времени и прочих глобальных вещей не существует.

M>Потому что

M>

M>Чистое ФП возможно только в строго изолированных кусках, например, в отдельных функциях или там отдельных модулях программы.

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

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

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

Ну да, тем не менее, в убитых проектах это чуть не норма

S>>>Откуда взялись связи при построении кортежа?

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

У тебя чтото выходит, да. "Откуда взялись связи при построении кортежа"
Делаешь вид, что типа не понял про связь страны и города.

I>>Ничего нового он не получает — всё те же фигуры, все та же доска.
S>Состояние новое.

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

I>>Кстати говоря, для старых машин испокон веков был пульт управления, в которых N ламп или светодиодов отражали состояние памяти. С клавиатуры меняешь состояние, делаешь прогон, получаешь результаты.
I>>Это ровно тот же подход, что и в hex, только безо всяких промежуточных перфокарт.
S>Да, конечно. Вводишь с пульта программу, вводишь с пульта данные, прогоняешь. Не получилось — снова. Успехов!

Именно. Тут нет какого то чуда, с опытом "не получилось" это довольно редкий кейс. Другого то варианта и не было — пока периферия не работает, пока не сможешь прогнать пуско-наладочные тесты, у тебя вобщем ничего другого и не было.

I>>Я показываю вещи, которые как раз таки легко проверить.
S>Проверь удельную частоту "учится за неделю-две".

Не понятен вопрос.

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

Это ты перевираешь мои слова. Я всего лишь неприемлю чистое ФП. Ровно как и чистое ИП.

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

Я дудкой называю всё, во что дудеть можно: труба, гобой, саксофон

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

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

I>> А по моему важнее Computer Sciense, включая алгоритмы-структуры данных, и доменная область.
S>Ты в пол шаге от того, что ФП или ИП — не имеет значения.

Последние две недели я именно это и говорю — парадигма это всего лишь средство перевода имеющегося решения в код.
Решил — запиши. А у тебя парадигма это эдакий всемогутор, в котором всё само, легко и просто, и куда входит весь имеющийся computer science.

S>Я не говорил о том, что он освоит все, что я накопил. Другое дело, что то, что я накопил — оно не очень ценно с точки зрения сегодняшнего студента. При наличии правильных подходов и примерно одного уровня доменной области, можно как раз срезать лет 25, выкинув хлам. Например, у меня годы ушли на изучение и работу с турбопаскалем, Delphi, MFC, COM... А если меняешь еще и доменную область (например, с оборонки в медицину, как это у меня было), то и оказываешься нос к носу со студентами.

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


S>А структуры данных — повторю, тут нет разницы, работаешь ты с ними год-два или тридцать. Арсенал практических методов работы с массивом/списком/картой будет примерно схожим. Я говорю не об исследованиях уровня Кнута/Окасаки, а о ежедневной практике на рынке труда в CS.

Со структурами данных все зависит от задач, которыми ты занимаешься. Разные области требуют разные знания. Многие до графов и за десятки лет недобираются. Другие там сидят денно и нощно.

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

Некорректное сравнение. Рытьё траншеи это неквалифицированый труд. Здесь важен инструмент, т.к. квалификация не важна по определению.
В IT все наоборот — неквалифицированый с инструментом и квалифицированый без него — разница почти всегда в пользу второго.

I>>И сколько раз в месяц, в среднем, ты учавствуешь в этом?
S>Я — нисколько. Но знаю тех, кто употребляет в пищу лишь то, что сам подстрелил.

Есть такое — это идеология, а не вынужденное поведение.

S>Я не говорил, что решение в учебнике ФП. Цена обновления дерева в среднем — его высота. типичный ДОМ — дерево ссылок.

Вопрос в том, что ты хочешь делать с этим ДОМ. Если только рисовать HTML, хватит и дерева, а если не html, а что то другое — может и граф понадобиться. Фактически, это хитрый такой сторадж, который унутре может быть каким угодно.

I>> Что за парадигма, это легко проверить. Попроси его изменить пару кадров, ведь "в ДОМ удаление менее чем линейно".
I>>Императивная модель — берем и изменяем состояние, а именно — подкорректировали кадр по месту или заменили листок новым, затраты не зависят от количества кадров.
S>Не зависят от количества кадров, значит O(1), согласен?

Именно. Допустим, ты номера знаешь. Раскрыл на нужном месте и думаешь, что же делать — править или не править, если править, то как.

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

На самом деде это разные операции — валидирование и коррекция. Мы можем просто этим воспользоваться. Если мы знаем, что кривые кадры 5 и 8, то надо обработать только их и не надо ничего копировать.

И далее, надо вспомнить "стоимость отката". Например, ребенок поправил один кадр, но испортил второй. ФП говорит нам, что стоимость отката 0. И как этого добиться ?

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

S>Т.е. если я покажу чистую программу целиком на хаскеле, то это будет примером невозможного?

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

Мое мнение такое. Чистых программ на хаскеле нет и быть не может, что бы ни говорили апологеты хаскеля. Их не существует. Все программы на хаскеле — грязные. Хаскель жонглирует терминами, утверждая, что "программа-то чистая, только ее выполняет грязный вычислитель". Но есть ли смысл в этом утверждении? По-моему, нет. Потому что это рассуждение применимо вообще к любым программам — во-первых, все они выполняются процессором, а не самостоятельно; во-вторых, с равным успехом мы можем утверждать, что любая программа на С++ — чистая, просто все ее функции являются IO, разница с хаскелем только в том, что в нем метка IO явная, а в С++ — нет.

Я считаю, что функция является чистой, если она не включает в себя по построению никакие нечистые функции. Что считать нечистыми функциями — неважно. Важно то, что мы принимаем разделение всех системных функций на чистые-нечистые. И любая функция, просто ссылающаяся на нечистую, сама будет нечистой. Вот такую трактовку я считаю справедливой, а не "мастурбацию вприсядку" (с) от создателей хаскеля.

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

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

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

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

I>Разумеется. Только восстановить старое может не выйдет вовсе. А если задаться целью восстановить идеально, до долей миллиметра, то и вовсе будет невозможным.
Города и страны ниоткуда, доли миллиметра в идеальном восстановлении шахматной позиции... Продолжай в том же духе!

S>>Да, конечно. Вводишь с пульта программу, вводишь с пульта данные, прогоняешь. Не получилось — снова. Успехов!

I>Именно. Тут нет какого то чуда, с опытом "не получилось" это довольно редкий кейс. Другого то варианта и не было — пока периферия не работает, пока не сможешь прогнать пуско-наладочные тесты, у тебя вобщем ничего другого и не было.
И это мне говорит человек, который считает что конс-списки сложные.

S>>Проверь удельную частоту "учится за неделю-две".

I>Не понятен вопрос.
Удельный вес/объем не слышал?

S>>Так зачем тебе переводить решение в код именно при помощи ФП, если оно тебе не близко и "менять" ДОМ дороже?

I>Это ты перевираешь мои слова. Я всего лишь неприемлю чистое ФП. Ровно как и чистое ИП.
Я ровно об этом и говорю, что нет мотивации переступать через "неприемлю".

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

I>Я дудкой называю всё, во что дудеть можно: труба, гобой, саксофон
Трезвучия извлекать будешь сразу тремя инструментами в один рот?

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

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

S>>Ты в пол шаге от того, что ФП или ИП — не имеет значения.

I>Последние две недели я именно это и говорю — парадигма это всего лишь средство перевода имеющегося решения в код.
I>Решил — запиши. А у тебя парадигма это эдакий всемогутор, в котором всё само, легко и просто, и куда входит весь имеющийся computer science.
Передернул. Я писал о конкретных вещах, которым в ИП приходится уделять внимание, а в ФП не требуется.

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

I>Со структурами данных все зависит от задач, которыми ты занимаешься. Разные области требуют разные знания. Многие до графов и за десятки лет недобираются. Другие там сидят денно и нощно.
У меня был начальник отдела (программистов), который на C++ к 50и годам не добрался до указателя. Приходил ко мне, что бы я ему ткнул пальцем, куда звездочку поставить.

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

I>Некорректное сравнение. Рытьё траншеи это неквалифицированый труд. Здесь важен инструмент, т.к. квалификация не важна по определению.
I>В IT все наоборот — неквалифицированый с инструментом и квалифицированый без него — разница почти всегда в пользу второго.
Уговорил.

S>>Я не говорил, что решение в учебнике ФП. Цена обновления дерева в среднем — его высота. типичный ДОМ — дерево ссылок.

I>Вопрос в том, что ты хочешь делать с этим ДОМ. Если только рисовать HTML, хватит и дерева, а если не html, а что то другое — может и граф понадобиться. Фактически, это хитрый такой сторадж, который унутре может быть каким угодно.
С графом тут есть органичения. В персистентных структурах не может быть циклов, поэтому всегда дерево. Либо вводить лишнюю косвенность. Два узла не могут хранить ссылки друг на друга, но могут хранить идентификаторы друг друга.

I>>>Императивная модель — берем и изменяем состояние, а именно — подкорректировали кадр по месту или заменили листок новым, затраты не зависят от количества кадров.
S>>Не зависят от количества кадров, значит O(1), согласен?

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

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

I>На самом деде это разные операции — валидирование и коррекция. Мы можем просто этим воспользоваться. Если мы знаем, что кривые кадры 5 и 8, то надо обработать только их и не надо ничего копировать.
Так в ФП тоже можно обработать только их, после чего собрать новый блокнот с новыми страницами.

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

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

S>>Т.е. если я покажу чистую программу целиком на хаскеле, то это будет примером невозможного?

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

Здравая мысль.
Есть четкое определение чистой функции. Оно требует детерминированности и отсутствия сайд-эффектов. Консенсус с другими определениями возможен, но без моего участия.

ARK>Мое мнение такое. Чистых программ на хаскеле нет и быть не может, что бы ни говорили апологеты хаскеля. Их не существует. Все программы на хаскеле — грязные. Хаскель жонглирует терминами, утверждая, что "программа-то чистая, только ее выполняет грязный вычислитель". Но есть ли смысл в этом утверждении? По-моему, нет. Потому что это рассуждение применимо вообще к любым программам — во-первых, все они выполняются процессором, а не самостоятельно; во-вторых, с равным успехом мы можем утверждать, что любая программа на С++ — чистая, просто все ее функции являются IO, разница с хаскелем только в том, что в нем метка IO явная, а в С++ — нет.
К этому можно вернуться, но только после согласования определения.

ARK>Я считаю, что функция является чистой, если она не включает в себя по построению никакие нечистые функции. Что считать нечистыми функциями — неважно.
Такое определение не позволит проверить даже чистоту умножения, т.к. опирается на неуточненные понятия.

ARK>Важно то, что мы принимаем разделение всех системных функций на чистые-нечистые. И любая функция, просто ссылающаяся на нечистую, сама будет нечистой. Вот такую трактовку я считаю справедливой, а не "мастурбацию вприсядку" (с) от создателей хаскеля.
А какой вообще смысл спорить о свойствах программ, используя общеизвестные термины, но в частных определениях, о которых никто кроме автора не знает?
Все мои предыдущие утверждения о чистоте не имеют никакого отношения к определению чистоты через невключение нечистых.

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

ARK>>Тут есть некоторое жонглирование словами и терминами. Без четких, формальных определений, принимаемых всеми участниками, прийти к консенсусу вряд ли возможно.
S>Здравая мысль.
S>Есть четкое определение чистой функции. Оно требует детерминированности и отсутствия сайд-эффектов.

Это не определение. Кроме того, в этой фразе присутствует неуточненный термин "сайд-эффекты".

ARK>>Мое мнение такое. Чистых программ на хаскеле нет и быть не может, что бы ни говорили апологеты хаскеля. Их не существует. Все программы на хаскеле — грязные. Хаскель жонглирует терминами, утверждая, что "программа-то чистая, только ее выполняет грязный вычислитель". Но есть ли смысл в этом утверждении? По-моему, нет. Потому что это рассуждение применимо вообще к любым программам — во-первых, все они выполняются процессором, а не самостоятельно; во-вторых, с равным успехом мы можем утверждать, что любая программа на С++ — чистая, просто все ее функции являются IO, разница с хаскелем только в том, что в нем метка IO явная, а в С++ — нет.
S>К этому можно вернуться, но только после согласования определения.

Хорошо.

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

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

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

ОК, каково "правильное" определение чистоты?

Вот википедия: https://en.wikipedia.org/wiki/Pure_function

Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices).
Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams).

Это правильное определение? Если да, то все программы на хаскеле — грязные, ведь их evaluation имеет side effects. Верно?

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

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

S>>Есть четкое определение чистой функции. Оно требует детерминированности и отсутствия сайд-эффектов.

ARK>Это не определение. Кроме того, в этой фразе присутствует неуточненный термин "сайд-эффекты".
Это не определение, но отсылка к нему.

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

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

In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, that is to say has an observable effect besides returning a value (the main effect) to the invoker of the operation.

https://en.wikipedia.org/wiki/Side_effect_(computer_science)

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

S>>Все мои предыдущие утверждения о чистоте не имеют никакого отношения к определению чистоты через невключение нечистых.

ARK>Вот википедия: https://en.wikipedia.org/wiki/Pure_function

ARK>

ARK> Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices).
ARK> Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams).

ARK>Это правильное определение?
Принято. В его рамках я могу рассуждать о чистоте.

ARK>Если да, то все программы на хаскеле — грязные, ведь их evaluation имеет side effects. Верно?
Нет, здесь ошибка. main на Хаскеле определяет computation/action. Можно считать computation результатом evaluation программы на хаскеле.