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

IT>Здравствуйте, Poopy Joe, Вы писали:

IT>>>Ты мне предъявил расстройство от непонятного языка. Я тебя и спрашиваю, при чём здесь язык? Мы обсуждаем парадигму, а не язык.
PJ>>Я ничего никому не предъявлял. Я лишь задал вполне резонный уточняющий вопрос, что там было не так? Предположив, что решение было на ФЯ. Зачем в позу-то вставать?

IT>Ты зря удалил цетирование. Там как раз было про не так
Мой коммент относился к "не так с кодом", а не вопросом.

IT>Мне на последний вопрос отвечать или не надо? А если не надо, то получается, что у меня расстройство, так?
"...Мама, он меня сукой обозвал" Я полагаю, что, как свободный человек, ты в состоянии сам выбрать на какой вопрос или его часть отвечать.

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

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

ARK>>Хорошо. Так можно ли вызвать одну функцию из другой и передать ей какие-нибудь данные? Это не противоречит основам функционального программирования?
BFE>Зависит от того, что понимать под данными. Функция переданная в качестве аргумента является данным или нет?

Ну да, является. Любой аргумент является данными, разве нет?

BFE>>>Сказать по вашему, так это императивного программирования не существует: память компьютера — это эмуляция ленты Машины Тьюринга, инструкция процессора — это программа на функциональном языке,
ARK>>Почему же, в императивной программе состояние может храниться и извне функций.
BFE>Да, может. Но я не понял к чему это написано.

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

BFE>Рассмотрим две программы которые спрашивают у пользователя два числа и выдают результатом их сумму. Одна программа написана на функциональном языке, а другая на императивном. Принципиальная разница между ними следующая: программа написанная на функциональном языке не помнит своего предыдущего состояния и на два заданных числа всегда выдаёт их сумму, а программа написанная на императивном языке может помнить что было раньше и выдавать сумму всех когда либо поданных на ввод чисел, а не только двух последних.

Ну, для ввода-вывода в ФП используются уловки наподобие уникальных типов. Таким образом, формально чистота функций соблюдается — функции остаются ссылочно прозрачными, т.к. тип "World" является уникальным для каждого вызова. Уловка? Да. Но придраться с точки зрения теории тут не к чему.

ARK>>Однако, ИМХО, абслютно очевидно, что ФП немыслимо без параметров функций. А, значит, через них можно передавать состояние.
BFE>Через ФП можно передать состояние.

Да, можно. И внутри ФП тоже можно эмулировать состояние с помощью параметров функций и уникальных типов.

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

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

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

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

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

S>>>>·>Размер чанков в общем случае будет минимальный, т.е. 1 байт. И такой буфер станет бессмысленным.
S>>·>Если тебе прилетают байты по 1024 штуки, то буфер не нужен. Если тебе прилетают байты по одной штуке, то чанк в буфере должен быть такого же размера или у тебя будет пухнуть память и такой буфер будет только вреден.
·>Не понял вопрос.
Вырезал из цепочки выше свои ответы и выделил тезис про бессмысленность буфера с чанком 1 байт. Так все-таки, нужно 1 байт, или другой размер?

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

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

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

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

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

BFE>>Рассмотрим две программы которые спрашивают у пользователя два числа и выдают результатом их сумму. Одна программа написана на функциональном языке, а другая на императивном. Принципиальная разница между ними следующая: программа написанная на функциональном языке не помнит своего предыдущего состояния и на два заданных числа всегда выдаёт их сумму, а программа написанная на императивном языке может помнить что было раньше и выдавать сумму всех когда либо поданных на ввод чисел, а не только двух последних.

ARK>Ну, для ввода-вывода в ФП используются уловки наподобие уникальных типов. Таким образом, формально чистота функций соблюдается — функции остаются ссылочно прозрачными, т.к. тип "World" является уникальным для каждого вызова. Уловка? Да. Но придраться с точки зрения теории тут не к чему.

Коллега немного не об этом. В его ФП мире нет списков, потому, он говорит что 2+2 ФП программа сложить может, а 2+2+3 — уже нет.
Но мне кажется что даже без списков задачу сложения всех поданных на ввод чисел можно решить с помощью аккумулятора.

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

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

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

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

s> ·>Тогда не понял в чём заключается "стремиться" при макс заполнении в 5 эл-тов.
s> Зачем ты пытаешься скрестить кривую и точку на ней? Асимптотика — это кривая о том, как ведет себя что-то при стремлении чего-то куда-то. Значение этой кривой в точке 5 — это совершенно другая вещь. Они между собой не связаны никак кроме того, что кривая проходит через эту точку. И предназначены для разных рассуждений.
O-нотация не подразумевает никаких кривых, никаких точек нет. Это вообще не функция, а класс функций.

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

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

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

·>Как я понял разница ООП — ФП в том, что последнее подразумевает иммутабельность, отсутствие изменяемого внутреннее состояния, что делает реализацию буфера непрактичной.
Почему? Неужели такая реализация хуже, чем вообще никакой? Если, допустим, я предпочитаю ФП, мне что, придется пристегивать ООП модуль ради практичной реализации буфера на 5 байт? Бред же.

s>> Нет, примера не будет. В общем случае с точки зрения ФП тонкое управление памятью не типично на уровне языка. Т.е. заставить на уровне языка использовать тот же кусок памяти, который использовался ранее, не выйдет. Здесь все ложится (обычно) на сборщик мусора. Однако, есть специфичные языки типа Clean, где тонкое управление организовать можно, как мне кажется. Я не знаю Clean, потому даже утверждение с КМК выглядит натянутым.
·>Вот собственно об этом и есть та самая "невозможность", которую я имею в виду.
Многие предпочитают высокоуровневые языки чистому ассемблеру, получая при этом огромную кучу "невозможностей" тонкого управления регистрами CPU. Есть ли в этом смысл?

s>> Зачем ты пытаешься скрестить кривую и точку на ней? Асимптотика — это кривая о том, как ведет себя что-то при стремлении чего-то куда-то. Значение этой кривой в точке 5 — это совершенно другая вещь. Они между собой не связаны никак кроме того, что кривая проходит через эту точку. И предназначены для разных рассуждений.
·>O-нотация не подразумевает никаких кривых, никаких точек нет. Это вообще не функция, а класс функций.
Что класс функций — это верно. Но это класс функций, по определению

|f(x)| <= C |g(x)|;

Т.е. ограниченных кривой g(x) с точностью до некого множителя C. Кривая есть, она подразумевается. Когда говорят "квадратичная сложность", имеют в виду квадратичную функцию g(x)=x*x и ее кривую. Какие тут могут быть еще мнения?

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

s> ·>Если я правильно понял твою мысль про "От 1024 байт, зависит от размера чанков." Я подумал, что под чанком ты понимаешь кусочек иммутабельно добавленный в конец буфера. В общем случае размер такого чанка будет 1 байт, что создаст заметные накладные расходы на поддержку такой структуры и сделает всю затею бессмысленной. В общем-то это я и заявил. Если я что-то не так понял, поясни.
s> Можно сделать 1 чанк размером 1024 байт, можно 1024 чанка размером 1 байт. В последнем случае расход памяти будет больше для записи 1024 байт в буфер. Это все, что я хотел сказать.
s> Но тут я не понял. Почему размер чанка в общем случае будет 1 байт? Если это по каким-то причинам делает затею бессмысленной, то может быть 1 байт — не очень хорошая идея? Бессмысленность я тоже не вижу. Задача решена? Да. Для 5 байт расходы на буфер велики? Я бы сказал, что нет. В современных реалиях, где пара гигов есть на самом вшивом нетбуке. Откуда такая категоричная бессмысленность?
Я, видимо, не понял, каким образом ты предлагаешь размер чанка выбирать. Запись происходит небольшими порциями, часто по одному байту. Какой размер чанка ты предлагаешь в таких условиях?

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

s> ·>Как я понял разница ООП — ФП в том, что последнее подразумевает иммутабельность, отсутствие изменяемого внутреннее состояния, что делает реализацию буфера непрактичной.
s> Почему? Неужели такая реализация хуже, чем вообще никакой? Если, допустим, я предпочитаю ФП, мне что, придется пристегивать ООП модуль ради практичной реализации буфера на 5 байт? Бред же.
А куда деваться? Делают какой-нибудь FFI или unsafe и вперёд. Не выходит соорудить нормальную хеш-таблицу в лучших традициях ФП, вот и приходится делать внешний модуль.

s> ·>Вот собственно об этом и есть та самая "невозможность", которую я имею в виду.
s> Многие предпочитают высокоуровневые языки чистому ассемблеру, получая при этом огромную кучу "невозможностей" тонкого управления регистрами CPU. Есть ли в этом смысл?
Есть, т.к. потери ресурсов из-за этих тонкостей незначительны. А там где значительны, там таки используют асм. С ФП такой фокус не прокатывает, слишком дороги абстракции.

s> ·>O-нотация не подразумевает никаких кривых, никаких точек нет. Это вообще не функция, а класс функций.
s> Что класс функций — это верно. Но это класс функций, по определению
s>

s> |f(x)| <= C |g(x)|;
s>

s> Т.е. ограниченных кривой g(x) с точностью до некого множителя C. Кривая есть, она подразумевается. Когда говорят "квадратичная сложность", имеют в виду квадратичную функцию g(x)=x*x и ее кривую. Какие тут могут быть еще мнения?
Во-первых, не для всех x, а для достаточно больших.
Во-вторых, x*x+x*sin(x) никак не такая же кривая как x*x, но тоже квадратичная сложность.
Короче, кривизна тут вообще никоим образом не в тему.

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

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

Ты не правильно понимаешь смысл функционального программирования. Отсутствие состояние != отсутствию сохранённых данных. Оно равно отсутствию возможности изменять эти данные. И благодаря именно этому f(x) в программе будет абсолютно всегда выдавать один и тот же результат (вне зависимости то сложности внутреннего устройства x), что позволяет произвольно менять порядок вычислений в программе (та самая ленивость), запоминать значения однажды вычисленных функций (та самая мемоизация) и т.п. вкусности ФП. Именно в этом смысле у х (если оно иммутабельное) и у f(x) (если эта функция является чистой) нет состояния.

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

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

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

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

s>> Но тут я не понял. Почему размер чанка в общем случае будет 1 байт? Если это по каким-то причинам делает затею бессмысленной, то может быть 1 байт — не очень хорошая идея? Бессмысленность я тоже не вижу. Задача решена? Да. Для 5 байт расходы на буфер велики? Я бы сказал, что нет. В современных реалиях, где пара гигов есть на самом вшивом нетбуке. Откуда такая категоричная бессмысленность?
·>Я, видимо, не понял, каким образом ты предлагаешь размер чанка выбирать. Запись происходит небольшими порциями, часто по одному байту. Какой размер чанка ты предлагаешь в таких условиях?
Так "часто по одному байту" или "по одному байту"? Это разные условия и ранее их не было. Может быть там и 512 часто прилетает?
Я вообще пока не предлагаю выбирать. Меня спросили, сколько займет памяти буфер под 1024 байт. Я ответил что от 1024 байт, в зависимости от размера чанка. А размер чанка будет определяться условиями задачи, которые в каждом сообщении меняются.

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

s>> Почему? Неужели такая реализация хуже, чем вообще никакой? Если, допустим, я предпочитаю ФП, мне что, придется пристегивать ООП модуль ради практичной реализации буфера на 5 байт? Бред же.
·>А куда деваться? Делают какой-нибудь FFI или unsafe и вперёд. Не выходит соорудить нормальную хеш-таблицу в лучших традициях ФП, вот и приходится делать внешний модуль.
Что значит "нормальная хэш-таблица"? Чем не устраивают те, что в лучших традициях ФП?

s>> ·>Вот собственно об этом и есть та самая "невозможность", которую я имею в виду.
s>> Многие предпочитают высокоуровневые языки чистому ассемблеру, получая при этом огромную кучу "невозможностей" тонкого управления регистрами CPU. Есть ли в этом смысл?
·>Есть, т.к. потери ресурсов из-за этих тонкостей незначительны. А там где значительны, там таки используют асм. С ФП такой фокус не прокатывает, слишком дороги абстракции.
В соседней ветке обсуждают сравнение реализаций сетевого драйвера на разных языках, включая Ocaml и Haskell. Я бы не сказал, что результаты провальные.

s>> Т.е. ограниченных кривой g(x) с точностью до некого множителя C. Кривая есть, она подразумевается. Когда говорят "квадратичная сложность", имеют в виду квадратичную функцию g(x)=x*x и ее кривую. Какие тут могут быть еще мнения?
·>Во-первых, не для всех x, а для достаточно больших.
Я не говорил что для всех x.
·>Во-вторых, x*x+x*sin(x) никак не такая же кривая как x*x, но тоже квадратичная сложность.
Я не говорил "такая же кривая как и". Не нужно перевирать мои слова, либо выдумывать их за меня.
·>Короче, кривизна тут вообще никоим образом не в тему.
Это твое мнение.

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

s> ·>Я, видимо, не понял, каким образом ты предлагаешь размер чанка выбирать. Запись происходит небольшими порциями, часто по одному байту. Какой размер чанка ты предлагаешь в таких условиях?
s> Так "часто по одному байту" или "по одному байту"? Это разные условия и ранее их не было. Может быть там и 512 часто прилетает?
Обычно неизвестно, поэтому надо рассматривать худший случай.

s> Я вообще пока не предлагаю выбирать. Меня спросили, сколько займет памяти буфер под 1024 байт. Я ответил что от 1024 байт, в зависимости от размера чанка. А размер чанка будет определяться условиями задачи, которые в каждом сообщении меняются.
По условию задачи у нас просто буферизованная запись. Т.е. в общем случае задача в ФП не решается? Просто обычно делают какой-нибудь BufferedWriter и всё ок. А тут у тебя какие-то сложности возникли. Об том и речь.

s> ·>А вообще говоря, я вообще не представляю куда тут сувать чанки.
s> ·>Во-первых, начнём с того, что буфер нужен именно как буфер — т.е. кусок последовательной памяти, да ещё, скорее всего, как-то выровненный по адресу, иначе ты не сможешь сисколл сделать для записи в девайс или подобное. Так что чанки как-то не очень сюда ложатся.
s> Хорошее начало для обсуждения решения задачи. С таким условием вылетает не только ФП, но и та часть ООП языков, которая не позволяет выравнивать память. Базовые концепции ООП не позволяют решить эту задачу, т.к. там про сообщения между объектов, а не про возможность выровнять кусок памяти по адресу.
Да что значит вылетает, просто используют какой-нибудь внешний механизм. FFI/unsafe/етс.

s> ·>Во-вторых, гигы это конечно хорошо, но ещё все эти буферы должны ложится последовательно во всякие кеши, иначе железо будет тормозить прыгая по ссылкам между чанками.
s> Опять подмена условия. В оригинале работа с буфером раз в секунду, ни слова про кэши.
Да какая разница сколько раз в секунду... Например, если таких буферов миллион штук и куча чанков у тебя превратится в фарш.

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

s> ·>А куда деваться? Делают какой-нибудь FFI или unsafe и вперёд. Не выходит соорудить нормальную хеш-таблицу в лучших традициях ФП, вот и приходится делать внешний модуль.
s> Что значит "нормальная хэш-таблица"? Чем не устраивают те, что в лучших традициях ФП?
Которая даёт выигрыш в производительности, а не просто "шоб было".

s> ·>Есть, т.к. потери ресурсов из-за этих тонкостей незначительны. А там где значительны, там таки используют асм. С ФП такой фокус не прокатывает, слишком дороги абстракции.
s> В соседней ветке обсуждают сравнение реализаций сетевого драйвера на разных языках, включая Ocaml и Haskell. Я бы не сказал, что результаты провальные.
Ну вот тот же haskell используют unsafe массивы, забивая на весь этот правильный ФП/иммутабельность/ленивость.

s> ·>Во-первых, не для всех x, а для достаточно больших.
s> Я не говорил что для всех x.
Значит ты должен доказать для x=5.

s> ·>Во-вторых, x*x+x*sin(x) никак не такая же кривая как x*x, но тоже квадратичная сложность.
s> Я не говорил "такая же кривая как и". Не нужно перевирать мои слова, либо выдумывать их за меня.
Ты сказал что "Т.е. ограниченных кривой g(x)" — это не точно. Для "недостаточно больших" x функция может быть не ограниченной.

s> ·>Короче, кривизна тут вообще никоим образом не в тему.
s> Это твое мнение.
Нет никакой функции у которой можно можно померить кривизну. Вообще никакой ф-ции нет. Причём тут моё мнение?

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

PJ>Судя по всем у некоторых денайл это форма религии.

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

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

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

s>> Так "часто по одному байту" или "по одному байту"? Это разные условия и ранее их не было. Может быть там и 512 часто прилетает?
·>Обычно неизвестно, поэтому надо рассматривать худший случай.
Худший случай ты и с ООП не вытянешь.

s>> Я вообще пока не предлагаю выбирать. Меня спросили, сколько займет памяти буфер под 1024 байт. Я ответил что от 1024 байт, в зависимости от размера чанка. А размер чанка будет определяться условиями задачи, которые в каждом сообщении меняются.
·>По условию задачи у нас просто буферизованная запись. Т.е. в общем случае задача в ФП не решается? Просто обычно делают какой-нибудь BufferedWriter и всё ок. А тут у тебя какие-то сложности возникли. Об том и речь.
Сложности возникли у тебя. Задача решается, просто тебя решение чем-то не устраивает и ты выдумываешь новые условия в каждом сообщении.

s>> Хорошее начало для обсуждения решения задачи. С таким условием вылетает не только ФП, но и та часть ООП языков, которая не позволяет выравнивать память. Базовые концепции ООП не позволяют решить эту задачу, т.к. там про сообщения между объектов, а не про возможность выровнять кусок памяти по адресу.
·>Да что значит вылетает, просто используют какой-нибудь внешний механизм. FFI/unsafe/етс.
И при чем тут ООП или ФП тогда?

s>> Опять подмена условия. В оригинале работа с буфером раз в секунду, ни слова про кэши.
·>Да какая разница сколько раз в секунду... Например, если таких буферов миллион штук и куча чанков у тебя превратится в фарш.
Снова изменение условия. Ты так и на ООП задачу не решишь. Всегда найдется что-нибудь, что превратит решение в фарш.

s>> Я ни слова не говорил о выигрыше такой буферизации. Я опровергал принципиальную невозможность.
·>Оппа. А какой смысл делать буферизацию, если она не даст никакого выигрыша? Прям классика "Выиграл миллион в лотерею!"
Уточни, никакого выигрыша по сравнению с чем?

s>> Что значит "нормальная хэш-таблица"? Чем не устраивают те, что в лучших традициях ФП?
·>Которая даёт выигрыш в производительности, а не просто "шоб было".
По сравнению с чем?

s>> В соседней ветке обсуждают сравнение реализаций сетевого драйвера на разных языках, включая Ocaml и Haskell. Я бы не сказал, что результаты провальные.
·>Ну вот тот же haskell используют unsafe массивы, забивая на весь этот правильный ФП/иммутабельность/ленивость.
Это экспериментальная фича. Кто-то использует, кто-то нет. "Internals" — уже намекает.

s>> ·>Во-первых, не для всех x, а для достаточно больших.
s>> Я не говорил что для всех x.
·>Значит ты должен доказать для x=5.
А еще что?

s>> ·>Во-вторых, x*x+x*sin(x) никак не такая же кривая как x*x, но тоже квадратичная сложность.
s>> Я не говорил "такая же кривая как и". Не нужно перевирать мои слова, либо выдумывать их за меня.
·>Ты сказал что "Т.е. ограниченных кривой g(x)" — это не точно. Для "недостаточно больших" x функция может быть не ограниченной.
Может. Определение говорит лишь про окрестность x0. Но я не собираюсь доказывать что реализация очереди с линейным доступом ведет себя не ограничено в точке 5. Или что ограничено.

s>> ·>Короче, кривизна тут вообще никоим образом не в тему.
s>> Это твое мнение.
·>Нет никакой функции у которой можно можно померить кривизну. Вообще никакой ф-ции нет. Причём тут моё мнение?
Ну вот, у тебя и функции нет. А в определении О нотации их аж две.
Кстати, а причем тут кривизна вообще?

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

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

AA>>Как менее противоричивый, а значит менее подверженный ошибкам следовало бы выбрать язык S-выражений.
AA>>В качестве доказательства позвольте еще кусочек кода на F#
AA>>Обратите внимание, что в F# заложена изначально идея вызова любого выражения слева направо, (+) применяется к своим аргументам, точно также как и calc применяется к () как к пустому множеству аргументов.
AA>>Исчезает двойственность и противоречивость си-подобных языков в которых нужно следить за порядком следования операторов.

ARK>Честно говоря, не уловил, в чем именно двойственность и противоречивость. И что значит "следить за порядком операторов". Нельзя ли немного раскрыть вопрос?

var a = 2 * 3 + 1;

(+ 1 (* 2 3))

var a = 2 * (3 + 1);

(* 2 (+ 3 1))

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

S>>Так и делаются вещи типа буферов и хранения состояния — конструируется функция, возвращающая функцию, возвращающую функцию и т.п.
BFE>Буфер и вещь типа буфера — это не одно и тоже.
Буфер с т.з. контракта — это очередь.
Вот статья, в которой на пальцах показана реализация очереди в ФП.
https://habr.com/ru/post/236375/

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

S>Коллега немного не об этом. В его ФП мире нет списков, потому, он говорит что 2+2 ФП программа сложить может, а 2+2+3 — уже нет.

Не понял этот момент. Любой гайд по ФП начинается с какой-нибудь фигни типа чисел Фибоначчи, что по сути и есть аккумулятор...

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

AA>>>Исчезает двойственность и противоречивость си-подобных языков в которых нужно следить за порядком следования операторов.
ARK>>Честно говоря, не уловил, в чем именно двойственность и противоречивость. И что значит "следить за порядком операторов". Нельзя ли немного раскрыть вопрос?
AA>

AA>var a = 2 * 3 + 1;
AA>

AA>

AA>;(+ 1 (* 2 3))
AA>;

AA>

AA>var a = 2 * (3 + 1);
AA>

AA>

AA>;(* 2 (+ 3 1))
AA>;

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

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

I>>

I>>union HouseNumver { int value; }
I>>

S>Да какое же это чудо? Это новый тип, а не чудо. Сорян, если что не так понял.

А разве я говорил про чудо? Я еще в начале времён целую либу видел, которая таким вещами орудует и в принципе код вполне легко читается.

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

кт>Перевод статьи «Object-Oriented Programming — The Trillion Dollar Disaster»
ИМХО, все эти пляски с саблями вокруг ООП, ФП, ИП, ЛП И Т.П. — это некая форма максимализма.
Я считаю, что ни одна парадигма не даёт ничего настолько существенного, чтобы делать из неё (анти)фетиш.
Опытный и грамотный программист с любой парадигмой "уделает" неопытного с любой другой парадигмой.
Инструмент здесь лишь поможет немного сэкономить время, будучи правильно примененным (или потерять, применив инструмент неграмотно).

P.S. Сам писал в жизни на разных языках: Pascal, Delphi, C/C++, C#, Prolog, Lisp, (Visual) Basic(.NET), ассемблеры в процедурной, объектно-ориентрованной, логической и функциональных парадигмах. Сейчас (для хобби) пишу на C и ассемблере и таким образом достигаю самадхи.

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

ARK>Очевидно, что...

Мда?