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

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

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

·>Написать-то может и можно, но смысла никакого не будет, т.к. ресурсов будет потреблять больше чем без такого буфера. Насколько это "принципиальная невозможность" — вопрос терминологии.
Принципиальная невозможность написать — это не о ресурсах, имхо. Хочешь спорить об этом — спорь с автором тезиса. Я мог его неверно понять, но он упоролся за "невозможно хранить". Про цифры и объем памяти речи не было.

S>>Далее. Разная алгоритмическая сложность для решения одной задачи в рамках разных парадигм — такое вполне возможно, это бывает. Но для решения конкретной задачи — я не вижу просадки по сложности. Есть реализации неизменяемой очереди с константным доступом. У Окасаки описана и я такую делал, правда, на C#. Так почему же должно быть ухудшение сложности относительно ООП?
·>А когда буфер освободится, как его переиспользовать?
Так же, как и любую память. В ФП здесь ничего радикально нового нет.

S>>Но даже если использовать для этой задачи наивную реализацию очереди на основе односвязного списка с алгоритмической сложностью O(n), то я не вижу тут серьезной просадки при максимальном заполнении очереди в 5 элементов.
·>У тебя смешались люди, кони. Ты уж либо о конкретном числе говори, либо о O-нотации. Если у тебя макс N элементов, то алгоритм имеет сложность O(1), по определению.
Извини, но когда я пишу в О-нотации, я имею в виду асимптотику, т.е. характер поведения при увеличении n. Когда я говорю про 5 элементов — это не про поведение при стремлении к чему-либо.
Асимптотика поведения реализации очереди как характер поведения не изменится от того, что я в нее наберу лишь 5 элементов. При стремлении кол-ва элементов реализация очереди будет вести себя именно так, как описывает o(n).

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

S>>Не понял что имеется в виду, но я говорил про duck typing.
S>duck typing — хорошо. Но это ближе к объектам, чем к процедурам.

На счет близотски к объектам спорно, но да ладно. Это был пример, когда тип определяется через операции над ним.

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

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

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

S>>>Не затруднит назвать язык в ПП парадигме с такой системой типов?

I>>Если ты настаиваешь на "в пп парадигме" то, например, язык Си. Надеюсь он достаточно процедурный ?
S>Ок, покажи, как в Си объявить целый HouseNumber, что бы был несовместим со встроенными целыми и позволял бы использовать перегрузку отличную от целых Key/Index и т.п.

Экий ты хитрый — меняешь задачу на ходу. Я нигде не говорил, что у меня целый HouseNumber. Более того, я говорил ровно противоположное, что он не будет совместим по присваиванию с целым, но для его моделирования используем целое.
Далее, цитирую себя:

Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.

И я тебе всё время говорил про операции. Ты как будто не слышишь, и повторяешь "нельзя инт отличить от инт". Вот, узри это чудо:

union HouseNumver { int value; }

union Key { int value; }

union Identifier { int value; }

union Index { int value; }

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

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

Почему? Вот типичная функциональная программа (псевдокод)

main(State) = main(step(State))

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

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

Точно так же решается и задача с буфером. Очередь буфера иммутабельна с точки зрения языка, но меняется с точки зрения алгоритма.

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

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

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

S>>Ок, покажи, как в Си объявить целый HouseNumber, что бы был несовместим со встроенными целыми и позволял бы использовать перегрузку отличную от целых Key/Index и т.п.

I>Экий ты хитрый — меняешь задачу на ходу. Я нигде не говорил, что у меня целый HouseNumber. Более того, я говорил ровно противоположное, что он не будет совместим по присваиванию с целым, но для его моделирования используем целое.
I>Далее, цитирую себя:
I>

I>Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.

I>И я тебе всё время говорил про операции. Ты как будто не слышишь, и повторяешь "нельзя инт отличить от инт". Вот, узри это чудо:

I>

I>union HouseNumver { int value; }
I>

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

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

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

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

И худший он потому что... ?

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

IT>>Я видел много плохого ООП кода в своей жизни. Но худший код, который я когда-либо видел был функциональным.
PJ>И худший он потому что... ?

Потому что это пипец!

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

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

IT>>>Я видел много плохого ООП кода в своей жизни. Но худший код, который я когда-либо видел был функциональным.
PJ>>И худший он потому что... ?

IT>Потому что это пипец!

Что именно пипец? Внятное что-то есть? Или просто от непонятного языка случилось расстройство?

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

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

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

S>>>Далее. Разная алгоритмическая сложность для решения одной задачи в рамках разных парадигм — такое вполне возможно, это бывает. Но для решения конкретной задачи — я не вижу просадки по сложности. Есть реализации неизменяемой очереди с константным доступом. У Окасаки описана и я такую делал, правда, на C#. Так почему же должно быть ухудшение сложности относительно ООП?
S>·>А когда буфер освободится, как его переиспользовать?
S>Так же, как и любую память. В ФП здесь ничего радикально нового нет.
Не очень понятно как это сделать чтобы оно было осмысленно с т.з. ФП и работало хорошо на железе. Можно пример?

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

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

PJ>Что именно пипец? Внятное что-то есть? Или просто от непонятного языка случилось расстройство?

При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?

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

IT>При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?
У него просто осеннее обострение и очень подгорает на любые темы Фх.
Тут конечно, у многих, походу подгорело, но, блин, в топике и в статье же написано, это всего лишь мнение, конечно же, с единственно правильным выводом.
Этим мнениям годков больше, чем я на этой планете живу.

PS: И да, я ненавистник синтаксиса int -> int -> int -> int -> int или bool * bool * bool * bool * bool * bool. И считаю, что кортежи, в публичном интерфейсе обязаны быть именованы. Иначе это write-only код.

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

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

PJ>>Что именно пипец? Внятное что-то есть? Или просто от непонятного языка случилось расстройство?

IT>При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?

Это следует из контекста. Или на чем ты видел ужасный функциональный код? На ассемблере? О чем тогда вообще эта фраза была?

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

IT>>При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?
MA> У него просто осеннее обострение и очень подгорает на любые темы Фх.

Очень странно, что подгорает. Прям запахло серединой двухтысячных, когда эти существа с других планет, зелёные человечки... точнее функциональные человечки осуществляли нашествие на Землю и на вопрос "Ну ладно, расскажи нам, что такое функциональное программирование?" отвечали однослохно — "Вы все тут дураки и ничего не понимаете!".

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

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

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

IT>>При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?
MA> У него просто осеннее обострение и очень подгорает на любые темы Фх.
А у тебя подгорает на любую тему? Я читаю только те, что мне интересны, как разработчику. Это плохо? Надо залезть в каждую тему?

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

PJ>>>Что именно пипец? Внятное что-то есть? Или просто от непонятного языка случилось расстройство?
IT>>При чём здесь вообще язык? Или ты путаешь парадигму с ЯП?
PJ>Это следует из контекста. Или на чем ты видел ужасный функциональный код? На ассемблере? О чем тогда вообще эта фраза была?

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

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

что такое функциональное программирование?" отвечали однослохно — "Вы все тут дураки и ничего не понимаете!".

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

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

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


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

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

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

А я не знаю чего у них там подгорает. Я, в юношестве был впечатлен трудами Дэйкстры, Хоара и еще кого-то, выраженные в виде книги (сборник сочинений) "Структурное программирование". Уж не знвю вообще это откуда было у отца — ведь он инженер-строитель.

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

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

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

Ты зря удалил цетирование. Там как раз было про не так

Что именно пипец? Внятное что-то есть? Или просто от непонятного языка случилось расстройство?

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