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

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

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

Хорошо, не может. А какой из toString-ов нужно вызывать для неуточненного типа?

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

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

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

ARK>>Где же оно, великое хардкорное ФП? В ядрах операционных систем? В самолетах и марсоходах? В играх? В бизнес-приложениях? В движках гугла и яндекса, быть может? В веб-сайтах? Где? Какая доля от миллиардов программных проектов написана на Haskell/Lisp/ML? Какой процент вакансий на этих языках? Вопросы риторические.
PJ>Конечно риторические. Невозможно найти если не смотреть. Фейсбуком пользуешься? Ну вот хотя бы там.

Целых 0.0003% кода? О да, это успех.

А фейсбуком не пользуюсь.

ARK>>Я не "ссылался на себя в начале тебе", что бы эта странная фраза ни значила. Я сослался на начало темы: http://rsdn.org/forum/philosophy/7540923.1

Автор: AlexRK
Дата: 12.09.19

PJ>Я писал в начале темы это не сослаться на начало темы, это сослаться на себя в начале теме.

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

ARK>>Диалог:
ARK>>

ARK>>-
ARK>>- ФП, который сможет стать популярным — если это вообще произойдет — будет другим, и синтаксически, и концептуально.
ARK>>- Это как?
ARK>>- Об этом я уже писал в начале этой темы.

ARK>>Ты испытываешь сложности с интерпретацией смысла этого диалога? Или с пониманием фразы "об этом я уже писал в начале этой темы"?
PJ>Ответить на уточняющий вопрос, что ты уже отвечал и потом возмущаться, что этот ответ уже всплыл это сильно.

А, так ты наркоман. Извини, сразу не заметил. Пока.

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

PJ>>А что может быть хорошего в кортежах вида (int, int) вообще непонятно.
GZ>Оно несколько круче. Кортежи могут быть как неименованными, так и именнованными. В функционалах документированность кортежам давало использование в паттерн матчингах. В шарпах он также появился. Сильно не хватало кортежей при возврате результатов из функций. Чтобы вернуть значение зачастую программисты создавали синтетический тип для конкретного использования в одном месте.

Tuple?

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

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

S>Хорошо, не может. А какой из toString-ов нужно вызывать для неуточненного типа?

Очевидно — тот, который соответствует реальному типу.

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

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

По твоему, для номера дома допустимы все те опреации ,которые выполнимы для Integer ? А по Index, скажем, 65021 ты собрается искать реальный дом ?

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

ARK>А фейсбуком не пользуюсь.
Ах вот как ты ищешь ФЯ...

ARK>А, так ты наркоман. Извини, сразу не заметил. Пока.
Фи, мог просто тихо слиться, чтобы сохранить лицо

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

ARK>>А, так ты наркоман. Извини, сразу не заметил. Пока.
PJ>Фи, мог просто тихо слиться, чтобы сохранить лицо

Слился тут только ты. Причем уже давно.

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

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

I>>>Это значит, что точный тип ты не знаешь. Из конфига значения прочитал.
S>>Если нет механизма перевода записи конфига в тип, то поиск модуля с ToString ничем не поможет.

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

S>>>>Полиморфные переменные в ПП? Это шутка?

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

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

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

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

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

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

S>>Хорошо, не может. А какой из toString-ов нужно вызывать для неуточненного типа?

I>Очевидно — тот, который соответствует реальному типу.
Так если реальный тип известен, то и вызывай его toString.

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

I>По твоему, для номера дома допустимы все те опреации ,которые выполнимы для Integer ? А по Index, скажем, 65021 ты собрается искать реальный дом ?
Полагаю, toString работает одинаково и для номера дома и для целых, т.к. это toString(int). В любом случае, при упоминании полиморфизма ПП или ООП я не предполагал в обсуждении спускаться глубже, чем полиморфизм уровня языка и его системы типов. Если у тебя своя доморощенная система типов, то причем тут ПП vs ООП? Ни то ни другое не предполагает диспетчеризации методов по неуточненным типам (HouseNumber/Key/Index), если они хранятся в Integer.

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

PJ>>>А что может быть хорошего в кортежах вида (int, int) вообще непонятно.
GZ>>Оно несколько круче. Кортежи могут быть как неименованными, так и именнованными. В функционалах документированность кортежам давало использование в паттерн матчингах. В шарпах он также появился. Сильно не хватало кортежей при возврате результатов из функций. Чтобы вернуть значение зачастую программисты создавали синтетический тип для конкретного использования в одном месте.

S>Tuple?
Старый? Безумно неудобен без pattern matching и именования. Код становится нечитаемым.

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

BFE>>Вы хотите сказать, что у вас так получится буфер?
S>Только так и получится. Изменяемых структур данных в чистом ФП нет.
Оцените, пожалуйста, размер такой структуры для буфера длиной в 1024 байт.

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

BFE>>Эээээ.... Вы точно отличаете буфер от серии операций над входными данными?
S>Точно не отличаю. Операции над входными данными и будут представлять буфер в ФП. Очередь входных данных — так буквально.
Видимо в этом-то и дело...

BFE>>>>Отличие в том, что эмуляция может работать как ей угодно, лишь бы результат совпадал.
S>>>Что не так с "как ей угодно"? Чем не устраивает?
BFE>>Реализацией.
S>Что не так с реализацией? Какой критерий?
Реализация не должна вдребезги разбиваться при столкновении с реальностью.

S>>>Раз получает тот же результат, то, наверное, и не обязан хранить данные?
BFE>>Так в том и дело, что по условию данные нужно хранить.
S>Нет, это надуманное условие. Достаточно добавлять данные в хвост очереди и предоставлять их с начала. Хранить — что это и зачем — не понимаю, что за этим стоит.

Представим, что у нас есть вот такая задача:
написать программу, которая читает байты из канала для чтения и записывает их на устройство для записи. Условия следующие:
— устройство для записи записывает 1 байт за секунду;
— канал для чтения позволяет считать один байт за одну миллисекунду;
— в канале для чтения есть буфер хранящий не более 5 байт;
— данные в канал для чтения поступают неравномерно, но известно, что:
-- в канал для чтения в секунду поступает не более 10 байт;
-- в канал для чтения за час поступает не более 3600 байт.

Можно эту задачу реализовать на функциональном языке программирования так, чтобы никакая часть реализации не содержала реализацию на императивном языке?

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

S>Полагаю, toString работает одинаково и для номера дома и для целых, т.к. это toString(int).

Форматирование строки может быть разным, поэтому не одиноково.

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

I>>Очевидно — тот, который соответствует реальному типу.
S>Так если реальный тип известен, то и вызывай его toString.

Известно соответствие, а вот реальный тип еще надо вычислить. Каким образом ты предлагаешь это делать ?

I>>По твоему, для номера дома допустимы все те опреации ,которые выполнимы для Integer ? А по Index, скажем, 65021 ты собрается искать реальный дом ?
S>Полагаю, toString работает одинаково и для номера дома и для целых, т.к. это toString(int).

Правильно понимаю, ты идентификаторы и индексы предлагаешь печатать как 'Дом Номер 65021' ?

>В любом случае, при упоминании полиморфизма ПП или ООП я не предполагал в обсуждении спускаться глубже, чем полиморфизм уровня языка и его системы типов. Если у тебя своя доморощенная система типов, то причем тут ПП vs ООП?

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

>Ни то ни другое не предполагает диспетчеризации методов по неуточненным типам (HouseNumber/Key/Index), если они хранятся в Integer.

Считаешь, что разработчик не имеет права биты использовать по своему усмотрению ? Вот так новость! И ПП и ООП предоставляет методы работы с такими вещами, и так было во все времена.

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

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

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

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

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

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

GZ>>Я не большой эксперт чтобы говорить о type driven, потому что не щупал ручками. Поэтому говорить не могу хоть и подозреваю на аналогичные инструменты.
PJ>Ты же сказал, что занимался ФП?!
А type driven — не свойство ФП насколько я его понял.

PJ>>>А что может быть хорошего в кортежах вида (int, int) вообще непонятно.
GZ>>Оно несколько круче. Кортежи могут быть как неименованными, так и именнованными.
PJ>Это не круче, это те же яйца вид в профиль. Именованость не дает ничего от слова совсем.
Она дает читабельность. Особенно в условиях IDE.

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

кт>Перевод статьи «Object-Oriented Programming — The Trillion Dollar Disaster»
кт>Рассказывает Илья Суздальницкий, senior full-stack-разработчик

Надоели фанатики. Инструмент надо брать под задачу, а не молотком сверлить стены.
У меня проект(HFT OrderBook с кучей разнообразной обвязки), где используется смесь C#/F#.
В процессе, где горячий код и воюем за латентность и скорость, боимся вытеснения потоков(типа 99% всех ордеров должны быть исполнены за 1мс при обработке 2М в секунду на реальном сетевом стеке, да еще все это уложить на SSD), императивщина с хардкором(запрет GC, ручный пулинг памяти с ранней аллокацией, адресная арифметика и вот это все).
Там где код не горячий, на латентность большей частью положить, на вытеснение плевать (типа за 1 секунду отработали при 10000 запросах в секунду, ну и зашибись)-ляпота на F#.
Писать все на F#-выйдет медленное, но красивое функциональное говно.
Писать все на C#-выйдет быстрое, но "некрасивое"(с точки зрения автора топика :D ) говно.
А вот микс F#/C#-очень даже. Тоже местами говно, но остальное все хуже

P.S. На С++ горячий код еще "веселее", с 2004 по 2009 код был на плюсах, параллельно часть подсистем была на C#. В итоге остался C#, потом с 2011 года начал потихоньку инжектироваться F#.

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

H>В процессе, где горячий код и воюем за латентность и скорость, боимся вытеснения потоков(типа 99% всех ордеров должны быть исполнены за 1мс при обработке 2М в секунду на реальном сетевом стеке, да еще все это уложить на SSD),

Как боретесь, если не секрет? Число потоков по числу ядер в системе или один поток на все и asyncio?

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

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

H>>В процессе, где горячий код и воюем за латентность и скорость, боимся вытеснения потоков(типа 99% всех ордеров должны быть исполнены за 1мс при обработке 2М в секунду на реальном сетевом стеке, да еще все это уложить на SSD),

S>Как боретесь, если не секрет? Число потоков по числу ядер в системе или один поток на все и asyncio?

Как конкретно, не скажу, все таки NDA.
Но все в одном потоке держать не получится из-за ожидания на IO, что убьет латентность, ну и пропускную способность до кучи, из-за возникающего лага "оживания" потока обработки при получении новых данных (произойдет переключение контекста потока со всеми вытекающими).
Код обработки поступающих данных из сети и вся обвязка должна работать так, чтобы никогда не переключать контекст потока.

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

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

S>>Только так и получится. Изменяемых структур данных в чистом ФП нет.
BFE>Оцените, пожалуйста, размер такой структуры для буфера длиной в 1024 байт.
От 1024 байт, зависит от размера чанков.

S>>Это опровержение полноты по Тьюрингу всех функциональных языков.
BFE>Повторюсь, здесь нет опровержения.
Действительно, опровержения тут нет, только голословное утверждение о том, что МТ, которая хранит данные в ленте, на ФП не реализовать.

S>>Что не так с реализацией? Какой критерий?
BFE>Реализация не должна вдребезги разбиваться при столкновении с реальностью.
А где дребезги? не пойму...

BFE>>>Так в том и дело, что по условию данные нужно хранить.
S>>Нет, это надуманное условие. Достаточно добавлять данные в хвост очереди и предоставлять их с начала. Хранить — что это и зачем — не понимаю, что за этим стоит.

BFE>Представим, что у нас есть вот такая задача:
BFE>написать программу, которая читает байты из канала для чтения и записывает их на устройство для записи. Условия следующие:
BFE>- устройство для записи записывает 1 байт за секунду;
BFE>- канал для чтения позволяет считать один байт за одну миллисекунду;
BFE>- в канале для чтения есть буфер хранящий не более 5 байт;
BFE>- данные в канал для чтения поступают неравномерно, но известно, что:
BFE>-- в канал для чтения в секунду поступает не более 10 байт;
BFE>-- в канал для чтения за час поступает не более 3600 байт.
Здесь нет слова "хранить". Внезапно, ничего хранить не надо.

BFE>Можно эту задачу реализовать на функциональном языке программирования так, чтобы никакая часть реализации не содержала реализацию на императивном языке?
Не вопрос. Уж что-что, а байты перепихнуть из одного в другое через очередь... Одна оговорка. Уровень взаимодействия с устройством и каналом, видимо, останется за скобками.

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

S>>Как боретесь, если не секрет? Число потоков по числу ядер в системе или один поток на все и asyncio?

H>Как конкретно, не скажу, все таки NDA.

Понял, но енто такие вопросы, которые NDA не очень нарушат. Ну используете вы столько то потоков и что? Ну да ладно, хозяин барин...

H>Но все в одном потоке держать не получится из-за ожидания на IO, что убьет латентность, ну и пропускную способность до кучи, из-за возникающего лага "оживания" потока обработки при получении новых данных (произойдет переключение контекста потока со всеми вытекающими).

CompletionPort используете?

H>Код обработки поступающих данных из сети и вся обвязка должна работать так, чтобы никогда не переключать контекст потока.

А как ентго добиться, если у любого потока есть свой квант? Т.е. либо жесткое ограничение на число потоков по числу ядер, либо я . Правильно ли я понимаю, что переключение происходит из-за ошидания IO чаще всего,
не считая Thread.Sleep(0\1) ?

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

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

S>>Полагаю, toString работает одинаково и для номера дома и для целых, т.к. это toString(int).

S>Форматирование строки может быть разным, поэтому не одиноково.
Тогда это будет toString(int value, string format). Но причем тут полиморфизм?