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

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

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

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