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

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

I>>>На ФП можно сделать все что угодно, даже изменения в базу. Для этого есть всякие монады и тд.
MH>>Про монады (точнее подход через IO аля хаскел) в курсе.
MH>>но если ФП там где нет IO красив, понятен и уместен, то лично для меня IO — это костыль позволяющий натягивать императивный подход поверх ФП.
MH>>то есть это уже не упрощение — а усложнение. Решением тут могло бы быть какое-то изящное комбинирование ФП и ИП подходов, возможно так как в F#, где есть нормальные присвоения, что позволяет писать вполне императивные куски кода.

I>В тру ФЯ есть такой синтаксис, https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs
I>Выглядит вполне сносно.
выглядит сносно, но это do нотация, под капотом которой монада, которая в свою очередь реализует идею прокидывания RealWorld через все функции с side-эффектами.
я о другом, об совмещении подходов, не путём применения идеи прокидывания RealWorld через все необходимые функции.

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

AA>ФП вполне себе может использоваться для построения больших систем:
AA>Composing bigger programs: combinators

Гипотетически. А вот пример, который демонстрирует автор статьи показывает какую то маленькую задачку — роутинг на сервере с изобретением давно известных вещей типа Миддлвара, Декоратор и тд.

Ну да ладно с масштабом. Товарищ попробовал и у него почему то вышел чуть не буквально тот же код, который написан в тру-ООП фремворках. Как так ?

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

 >=> OK (sprintf "Hello authenticated person ")

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

Далее оказывается, что тому модулю понадобится логгер. А наш логгер уже сконфигурен из json файла, и пишет логи в микросервис. Логгер в том модуле имеет совсем другой интерфейс, который, внезапно, надо согласовать с нашим. Мы пишем {level, msg, args} а они — типизированые LogEntry.

Далее, тому модулю нужны конфиги, и их конфиг это часть нашего конфига, но за некоторым исключением.

Далее, тому модулю надо сказать, как и что кешировать, а наш кеш снова несовместим с интерфейсом того кеша.

Далее, у нас есть correlation, и снова разница в интерфейсе того модуля и нашего. Далее, есть небольшой наш пре-процессинг, и небольшой пост-процессинг.

И вот после всего этого, результат надо записать в БД, поместить в тот же кеш, и выслать юзеру. Но в базу писать не абы как, а делегировать другому модулю, который уже настроен для этого

И вот внезапно, в ООП чуть не готовые ответы, как организовать конфиги, логирование, кеширование, correlation, работу с БД и тд и тд и тд.

Что предлагает чистое ФП ? Да вобщем то ничего. Роутинг — не, херня, ООПшный отстой, мы напишем свой такой же(и изобретём своё ООП). Логирование ? Херня, мы напишем своё и снова изобретем ООП. Конфиги ? Аналогично. Управление зависимостями ? Ага, снова напишем своё и скажем, что не брали его из ООП.
Как организовать работу с базой ? Возьмём ОРМ и никому не скажем, что это имеет отношение к ООП.

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

MH>Согласен, вопрос довольно филосовский. В своём примере ранее я не точно выразился — имел ввиду счет на оплату (либо заказ), и под его изменением — изменение его статуса — черновик, подготовлен, подтверждён и прочие.
MH>То есть изменение данных всё таки есть.
Ну, вот это — как раз и есть документооборот.
На первый взгляд в нём всё как раз очень хорошо подходит под ФП — потому, что "переход состояния" можно выражать как функцию, отображающую S₁ на S₂.
И там всё чотко: в ФП же у нас, как правило, нет наследования, зато есть развитый паттерн-матчинг. То есть мы сразу при написании функции перехода потребовали каких-то свойств от заказа, и всё — нам ни рантайм, ни компилятор не дадут нарушить предикаты. Это в ООП у нас начинаются тяжкие мучения — а как реализовать метод Order.IsValid()? Ведь черновик вполне может быть валидным вообще в разобранном состоянии; а вот для оплаты надо, чтобы он был подтверждён; отгрузка так и вовсе требует всех реквизитов. И все вот эти вот комбинации того, что у заказа может быть, а чего может не быть — очень-очень плохо ложатся на ООП. То ли надо вводить разные классы для описания разных этапов жизни заказа; то ли один класс, а проверку валидности параметризовывать стратегией; то ли применить паттерн State...

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

MH>Но опять же — добавление проводки это уже изменение базы.
Ну зачем так на это смотреть. Изменение состояния счёта — это сложная штука, потому что у нас есть состояние всей системы счетов, а потом ХОП! и у нас уже новое состояние, где что-то изменилось. При этом есть валидные изменения, а есть невалидные изменения, и отловить их при помощи системы типов тяжело.
А добавление проводки — это лёгкая и приятная вещь. Просто новый список проводок — это пара из (новаяПроводка, старыйСписокПроводок). Всё, задача решена. Никаких модификаций не предусматривается

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

MH>Мы упремся опять в апдэйты базы, когда в рамках бизнес-процедуры вытягиваются какие-то записи, меняются в них поля, и создаются новые.
Апдейт базы тут слишком низкий уровень. Это всё равно, что говорить, что моделирование Машины Тюринга через ФП упрётся в записи на ленту.

MH>Тут можно пойти по аналогии как в Хаскеле, смотреть на базу как на RealWorl и апдэйт порождает её новую версию... но хз хз... проще ли это уже будет для понимания)
MH>А также обычно в логике бизнес-процедур, присутсвует чистая императивщина — условные операторы, присвоения в поля поднятой записи. И это в данном случае удобно, так как
MH>соотвествует нашей ментальной модели — изменяем записи, тому как на постановочном уровне выражена бизнес-логика.
Это какая-то странная бизнес логика, которая выражена на постановочном уровне в терминах изменяемых полей и хранимых процедур.
Известная мне бизнес логика выражается всякими утверждениями различной степени всеобщности — вроде того, что "отсрочка платежа не может превышать 60 дней", или "класс контрагента повышается до Доверенного после закрытия заказов на сумму более $50000". Сразу писать бизнес-логику в терминах полей .... Вот это с ФП совместить затруднительно.
MH>Как вот это совместить с ФП ... действительно вопрос...

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

ARK>Не знаю, кто такой Рич Хикки, но вряд ли стоит прислушиваться к его словам, если у него от кодинга на руках мозоли, да еще и лопнутые. Вероятно, говнокодер, у которого оплата за количество строк кода.

Так то Рич — автор кложи. И послушать его стоит в любом случае.

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

I>>То, как человек управляется со сложной задачей, и легло в основу ООП.

AA>Ну, не знаю, в ООП очень сложно въехать, именно поэтому зачастую кодирование скатывается в говнокод.

В говнокод скатываются вещи, когда решения принимаются не головой

AA>ФП же легче понять по аналогии с математикой.

AA>

AA>let f = fun x -> x * x; //вывод типов здесь здорово упрощает нотацию функций. чистый код - одна суть
AA>

AA>В C# придется напрячься:
AA>[cs]

AA>Func<int, int> f = (a) => a * a;//уже много лишнего, ведь код будет вызван и у продвинутого компилятора есть возможность определить типы из контекста?

Поздравляю — ты сравнил функциональный с функциональным.

AA>//или по старинке

И при чем здесь ООП ? Если ты добавил класс, то в твоём коде ООП не прибавилось.

AA>Как я уже сказал, разница не значительная на первый взгляд и в то же время колосальная.
AA>Именно поэтому последние 10 лет очень много внимания уделяется ФП.

Вот бы узнать, где в твоих примерах ООП ?

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

I>>Вообще то именно для того. Вероятно, для тебя ООП это чисто его Симуловский вариант из трёх китов. Пока что ты дальше этих китов никуда не вышел. А между тем ООП гораздо ширше, это еще Алан Кей сказал.
AA>Каюсь, все знать не дано.
AA>Я не противник ООП в принципе, но я сторонник ФП.
AA>Правда, в РФ его время еще не пришло.

Давно пришло. ФП прирастает не сверху, в виде модного языка, и не снизу, когда все девелоперы херачат функциональный код.
ФП прирастает постепенно в в виде отдельных компонентов, модулей, которые сначала массово приживаются (1), а далее находят поддержку в языках (2).

Этот процесс начался еще в девяностых и идет примерно одинаково по всему миру. А вот количество фанатиков-функционалистов, которые топят за функциональные язки, во все времена было на грани стат-погрешности.

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

Эти же приёмчики почему то были невостребованы в языках Си, Паскаль и тд. Но вот пришли функционалисты и сказали, что де они изобрели колесо. Вполне возможно так и было. Но сделали они это в редакторе, который заботливо предложили программисты на ассемблере

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

GIV>>Чистое ФП не завоюет мир никогда, оно конечно математично но не практично.
$>Его просто ниасилит большая часть программистов. Если указатели C-е ниасилили и потому перешли на жаву, то что о лиспе говорить.
Знаете, слово "ниасилил" любимое среди поколнников маргинальных решений: не нравится тебе прототипное наследование? Да ты его ниасилил! Функциональное программирование медленное, неудобное и не даёт никаких преимущесть? Ниасилил! (Какой-нибудь недостаток в линуксе)... Ниасилил!!!

Так было, есть и будет.

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

AA>Ну, не знаю, в ООП очень сложно въехать, именно поэтому зачастую кодирование скатывается в говнокод.

Конечно, какие-либо доказательства тут излишни. Джентльмены друг другу на слово верят.

AA>ФП же легче понять по аналогии с математикой.

AA>

AA>let f = fun x -> x * x; //вывод типов здесь здорово упрощает нотацию функций. чистый код - одна суть
AA>

AA>В C# придется напрячься:
AA>

AA>Func<int, int> f = (a) => a * a;//уже много лишнего, ведь код будет вызван и у продвинутого компилятора есть возможность определить типы из контекста?

AA>//или по старинке
AA>public static class Funcs {
AA>    public static int F (int a) {
AA>        return a * a;
AA>    }
AA>}
AA>

AA>Как я уже сказал, разница не значительная на первый взгляд и в то же время колосальная.

Где конкретно тут колоссальная разница? В количестве набранных символов? Если оставить за скобками выведение типов, то по смыслу одно и то же. Где тут ООП vs FP?

PS Напоминает мне холивары, где к достоинствам языка относили наличие/отсутствие скобочек или слов begin/end.

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

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

Так вроде уже не делают — есть высокоскоростной ethernet (25/50/100GBit), который максимум дублируют для отказоустойчивости, а потом нарезают на нужное количество виртуальных интерфейсов.

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

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

I>А вот с виртуализацией это можно обойти, т.е. целые сети могут крутиться внутри одного сервера.

Можно и без виртуализации.

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

I>>В тру ФЯ есть такой синтаксис, https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs
I>>Выглядит вполне сносно.
MH>выглядит сносно, но это do нотация, под капотом которой монада, которая в свою очередь реализует идею прокидывания RealWorld через все функции с side-эффектами.
MH>я о другом, об совмещении подходов, не путём применения идеи прокидывания RealWorld через все необходимые функции.

Лично мне совмещение нравится больше чем монады. Но есть экстремисты-функционалисты, которые на компромиссы не согласны...

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

S>Ну, вот это — как раз и есть документооборот.
S>На первый взгляд в нём всё как раз очень хорошо подходит под ФП — потому, что "переход состояния" можно выражать как функцию, отображающую S₁ на S₂.
Можно и с одной стороны это неплохая ментальная модель. Но она всё таки на мой взгляд вступает в противоречие с тем как большинство воспринимает эти переходы (или бизнес-логику), а именно в императивном стиле, когда мы думаем именно что измениться. довольно трудно выражать алгоритм, когда в уме надо порождать новую версию (изменённую) записи, а потом ещё и в других местах не забыть что она есть и из неё надо брать актуальные данные.

S>И там всё чотко: в ФП же у нас, как правило, нет наследования, зато есть развитый паттерн-матчинг. То есть мы сразу при написании функции перехода потребовали каких-то свойств от заказа, и всё — нам ни рантайм, ни компилятор не дадут нарушить предикаты. Это в ООП у нас начинаются тяжкие мучения — а как реализовать метод Order.IsValid()? Ведь черновик вполне может быть валидным вообще в разобранном состоянии; а вот для оплаты надо, чтобы он был подтверждён; отгрузка так и вовсе требует всех реквизитов. И все вот эти вот комбинации того, что у заказа может быть, а чего может не быть — очень-очень плохо ложатся на ООП. То ли надо вводить разные классы для описания разных этапов жизни заказа; то ли один класс, а проверку валидности параметризовывать стратегией; то ли применить паттерн State...
S>В ФП мы смотрим на заказ не как на самостоятельный объект с каким-то там "поведением", а как на конгломерат атрибутов. И у нас чётко понятно, какие переходы состояния к нему применимы, а какие нет.
с этим согласен. тут ФП идеально.

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

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

MH>>Мы упремся опять в апдэйты базы, когда в рамках бизнес-процедуры вытягиваются какие-то записи, меняются в них поля, и создаются новые.
S>Апдейт базы тут слишком низкий уровень. Это всё равно, что говорить, что моделирование Машины Тюринга через ФП упрётся в записи на ленту.
пожалуй соглашусь, основная проблема не апдэйт базы, а перевод чисто императивного алгоритма бизнес-логики (лёгкого для понимания) в функциональный, когда в уме мы размышляем — ага, если так, то меняем в этой записи эти поля, а в этих эти так и последующий кусок алгоритма, уже подразумевающий что ранее сделанные изменения доступны и не требующий пояснений (и заботы в коде чтоб уже брать новые версии записей), что тут мы оперируем уже ранее изменёнными данными.


MH>>А также обычно в логике бизнес-процедур, присутсвует чистая императивщина — условные операторы, присвоения в поля поднятой записи. И это в данном случае удобно, так как
MH>>соотвествует нашей ментальной модели — изменяем записи, тому как на постановочном уровне выражена бизнес-логика.
S>Это какая-то странная бизнес логика, которая выражена на постановочном уровне в терминах изменяемых полей и хранимых процедур.
не обязательно хранимых процедур, это (хранимые процедуры) как раз не важны для постановки.

S>Известная мне бизнес логика выражается всякими утверждениями различной степени всеобщности — вроде того, что "отсрочка платежа не может превышать 60 дней", или "класс контрагента повышается до Доверенного после закрытия заказов на сумму более $50000".
так выражается на концептуальном уровне, далее всегда начинается детализация, что конкретно и на какое именно значение надо изменить чтоб стал доверенным, а возможно несколько изменений сделать и тогда надо все их осознать и понять, и какие конкретно проверить поля что такое изменение возможно. вот это всё надо детализировать до конкретных полей, что в них присваивать, для условий — какие конкретно откуда брать поля с чем проверять.

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

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

MH>>выглядит сносно, но это do нотация, под капотом которой монада, которая в свою очередь реализует идею прокидывания RealWorld через все функции с side-эффектами.
MH>>я о другом, об совмещении подходов, не путём применения идеи прокидывания RealWorld через все необходимые функции.

I>Лично мне совмещение нравится больше чем монады. Но есть экстремисты-функционалисты, которые на компромиссы не согласны...
лично мне тоже. Я бы сказал радикальные функционалисты
Хотя с точки зрения строителей компиляторов/ран-таймов чистый функционализм (без мутабельности и присваиваний) конечно хорошо, так как позволяет делать много крутых оптимизаций.

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

S>Так вроде уже не делают — есть высокоскоростной ethernet (25/50/100GBit), который максимум дублируют для отказоустойчивости, а потом нарезают на нужное количество виртуальных интерфейсов.

И тем не менее у нормального сервера несколько интерфейсов. Дай волю — утыкали бы по самые нидерланды, но количество аппаратных прерываний ограничено.

I>>А вот с виртуализацией это можно обойти, т.е. целые сети могут крутиться внутри одного сервера.

S>Можно и без виртуализации.

А задержки куда деть? Это основная причина проседания перформанса. Задержки исчисляются в милисекундах.

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

MH>>Согласен, вопрос довольно филосовский. В своём примере ранее я не точно выразился — имел ввиду счет на оплату (либо заказ), и под его изменением — изменение его статуса — черновик, подготовлен, подтверждён и прочие.
MH>>То есть изменение данных всё таки есть.
S>Ну, вот это — как раз и есть документооборот.
S>На первый взгляд в нём всё как раз очень хорошо подходит под ФП — потому, что "переход состояния" можно выражать как функцию, отображающую S₁ на S₂.
S>И там всё чотко: в ФП же у нас, как правило, нет наследования, зато есть развитый паттерн-матчинг. То есть мы сразу при написании функции перехода потребовали каких-то свойств от заказа, и всё — нам ни рантайм, ни компилятор не дадут нарушить предикаты. Это в ООП у нас начинаются тяжкие мучения — а как реализовать метод Order.IsValid()?

Если у нас язык императивный, то основной вариант ровно один — куча switch + if. Если функциональный то паттерн-матчинг. И что мы имеем в сухом остатке ? if+switch vs PM. Здесь надо вспомнить, что ООП не летает, а живет на нижележащей парадигме, какой угодно, лишь бы она позволяла вычислять. то есть, if+switch никакого отношения к ООП не имеют, ровно как и PM.

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

Скажем, когда на Скала используется hibernate, то это ОО парадигма в целях улучшения функционального кода. А то бы по уму надо бы написать FRM замеcто ORM и так для каждого ЯП + перечень БД. Чет не заметно, что радикальные функционалисты были массов озабочены такой проблемой

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

S>>Так вроде уже не делают — есть высокоскоростной ethernet (25/50/100GBit), который максимум дублируют для отказоустойчивости, а потом нарезают на нужное количество виртуальных интерфейсов.

I>И тем не менее у нормального сервера несколько интерфейсов. Дай волю — утыкали бы по самые нидерланды, но количество аппаратных прерываний ограничено.

Но зачем, когда можно за достаточно небольшие деньги купить одну карту с двумя 100Gb/s интерфейсами? Этого за глаза для абсолютного большинства задач. Единственное что может иметь смысл — купить две карты с одним таким интерфейсом — для отказоустойчивости, но в любом случае в 99.99% задач 2x100Gb будет оверкиллом.

S>>Можно и без виртуализации.

I>А задержки куда деть? Это основная причина проседания перформанса. Задержки исчисляются в милисекундах.

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

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

S>Но зачем, когда можно за достаточно небольшие деньги купить одну карту с двумя 100Gb/s интерфейсами? Этого за глаза для абсолютного большинства задач. Единственное что может иметь смысл — купить две карты с одним таким интерфейсом — для отказоустойчивости, но в любом случае в 99.99% задач 2x100Gb будет оверкиллом.

Интересно, зачем же в Server2016 сделали поддержку ажно 32х интерфейсов? Дураки наверное, не знали что хватит двух

S>>>Можно и без виртуализации.

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

Задержки сети тебе только господь бог уберёт, если скорость света до бесконечности подымет. А так хоть 100гбит хоть сиксилиард гбит — задержки одни и те же.

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

ltc>PS Напоминает мне холивары, где к достоинствам языка относили наличие/отсутствие скобочек или слов begin/end.
Насчет холивара согласен, тема из цикла "наброс на вентилятор". Однако, синтактис для меня очень важен.

Вот моя история,
после нескольких лет на си# стал присматриваться к другим языкам.
Сначала попробовал Ди. Первое что бросилось в глаза — не нужно было городить класс ради одной функции(можно определять вне классса).
Не стал использовать только из отсутствия достаточного кол-ва библиотек.
В прошлом году ради фана потратил время на F#(Сошников, Дон Сайм, Скот Власчин).
Ну это тупо удобный синтаксис! Использую в скриптах (сборка билдов, обработка файлов). + REPL.
Потом попробовал LISP. Ну это вообще за гранью. Гомоиконность рулит.
Естественно, все это настолько далеко от потребностей рынка программистов, что приходится от этого отказываться.
Сложно программировать на си-подобном, если в голове скобочные списки.
Ну, а последнее, это Nemerle. Парадоск в том, что в 2007-2010 годах на работе выписывали RSDN.
Но так как я был еще морально к этому не готов, но все время пролистывал как что-то странное, ненужное.
А недавно рылся в шкафу, смотрю — описание нитры с примерами. Ух ты!
Сила Nemerle в том, что при очень мощной реализации ФП он практически сохранил синтакис C#.
Очень легко перейти на Nemerle.
В Nemerle полно фишек, например, я балдею от того что убрали слово new. Оно реально лишнее в управляемом языке.
Конструктор это просто this(), тоже очень удобно. Записи, реализация сравнения на уровне макросов.
Настоящий язык не обязан быть ООП или ФП, чем больше возможностей тем лучше. Вот почему так популярен js и C.
Уже даже MS стала смотреть в сторону rust.

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

S>>Но зачем, когда можно за достаточно небольшие деньги купить одну карту с двумя 100Gb/s интерфейсами? Этого за глаза для абсолютного большинства задач. Единственное что может иметь смысл — купить две карты с одним таким интерфейсом — для отказоустойчивости, но в любом случае в 99.99% задач 2x100Gb будет оверкиллом.

I>Интересно, зачем же в Server2016 сделали поддержку ажно 32х интерфейсов? Дураки наверное, не знали что хватит двух

32 интерфейса на team, при том что, имхо, network teaming уже устарел в пользу SET (switch embedded teaming, появился в WinServer2016). Ограничений на количество интерфейсов в системе вроде не было (или по крайней мере не могу ничего найти на эту тему).
А вот представить себе teaming на 32 интерфейса у меня не получается при всём желании.

(И да, уж извините, но "вот они сделали 32 интерфейса" — дилетантский аргумент, как минимум стоило посмотреть к чему это вообще относится)

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

I>Задержки сети тебе только господь бог уберёт, если скорость света до бесконечности подымет.

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

I>А так хоть 100гбит хоть сиксилиард гбит — задержки одни и те же.

В принципе да, но всё же разница в задержках между 100мбит, 1гбит и 25гбит будет.

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

AA>Сначала попробовал Ди. Первое что бросилось в глаза — не нужно было городить класс ради одной функции(можно определять вне классса).
AA>Не стал использовать только из отсутствия достаточного кол-ва библиотек.

В D есть инструменты для подключения библиотек C и C++.

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

I>>А так хоть 100гбит хоть сиксилиард гбит — задержки одни и те же.

S>В принципе да, но всё же разница в задержках между 100мбит, 1гбит и 25гбит будет.

Нет, не будет. Скажем, соединение по http будет устанавливаться одинаково. Обмен короткими пакетами по хттп — тоже сильно вряд ли изменится.