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

I>но количество аппаратных прерываний ограничено.

224 штуки (современный x86). Пусть на сеть достанется половина этого, тебе мало?

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

Дело явно не в невозможности "утыкать по самые нидерланды", а в отсутствии смысла. Редко где нужно больше 4, это считая IPMI+IKVM.

I>>>А вот с виртуализацией это можно обойти, т.е. целые сети могут крутиться внутри одного сервера.
S>>Можно и без виртуализации.
I>А задержки куда деть? Это основная причина проседания перформанса. Задержки исчисляются в милисекундах.

Это на вход/выход embedded VM, или на что?

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

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

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

Как раз из-за физических свойтв будет: время на передачу одного пакета (условно) = размер пакета/скорость. При постоянном размере пакета, чем выше скорость (точнее пропускная способность), тем меньше время на передачу пакета целиком.

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

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

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

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

Например, смысл наследования в том, что ты можешь создавать подтипы — то есть, более точные типы. А его пытаются использовать как расширение, что есть прямо противоположное по смыслу. Более того — даже на проблему и ее решение не смотрят. Есть у нас Employe — круто, а того, у кого есть гаечный ключ, назовем EmployeWithWrench. Менеджера так и назовем Manager. Как теперь быть с менеджером, у которого есть гаечный ключ ? ManagerWithWrench. Потом аналогичные приседания выполняются для отвертки, EmployeWithScrewDriver, ManagerWithScrewDriver. Как теперь быть, если вдруг обнаружится, что у людей могут быть и отвертки, и ключи, и вообще много всего ?

Тут начинаются крики, что де ООП плохое. На самом деле вот так наследовать никак нельзя. Сначала нужно найти подходящее решение, структурировать, а уже потом перевести из человеческого в ООП.

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

Вот пример решения этого:

В качестве основной связи для примера возьмем начальник-подчиненный, новую сущность вводим только для того, что бы уточнить именно эти роли — начальник или подчиненный, все остальное считаем несущественным, то есть, абcтрагируемся от него. У менеджера есть подчиненные. У любого работника есть определенные способности.


Видишь? Вот здесь структурирование сделано. И пока нет никаких трёх китов. ООП говорит о том, как смоделировать это решение и записать его кодом.

Сущность оформим как класс(но никто не мешает сделать это записью, объектом и чем угодно!). У начальника есть подчиненные — коллекция(и никто не запретит сделать это массивом, функцией getSubordinate и тд). Теперь ключи, отвертки, нужно поместить, скажем, в свойство Tools (а можно — выставить набор капабилити, которым можно воспользоваться) и там его оставить. Тогда у нас остаётся ровно два класса — Employe и Manager. А вся иерархия опишется способом известным в паттернах как Composite, все что есть у Manager — подчиненные. Не всегда, но нашу модель это не ломает. Всё. Добавление новых сотрудников тривиально — SalesManager.

Это типа смешной пример. На самом деле похожим образом пытаются плодить например те же визуальные компоненты — Component, Footer, Header, Article, Menu, ArticleWithFooter, ArticleWithFooterAndHeader, ArticleWithFooterWithoutHeader, ArticleWithDoubleFooterMenuWithoutHeader и тд.

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

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

Вобщем, как в том твоем примере про роутинг на сервере — вроде бы всё функционально, а код почему то как в тру-ООП фремворках

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

AA>Вот моя история,
AA>после нескольких лет на си# стал присматриваться к другим языкам.

C# был первым языком? Сочувствую...

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

Хы, это можно в подавляющем большинстве языков программирования (многие из которых не имеют никакого отношения к ФП).

AA>В прошлом году ради фана потратил время на F#(Сошников, Дон Сайм, Скот Власчин).

А его вообще кто-то ещё использует на практике? )

AA>Потом попробовал LISP. Ну это вообще за гранью. Гомоиконность рулит.

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

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

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

AA>Настоящий язык не обязан быть ООП или ФП, чем больше возможностей тем лучше.

Совершенно верно.

AA>Уже даже MS стала смотреть в сторону rust.

Это тут вообще причём?

P.S. Самое забавное, что похоже один из самых больших фанатов ФП в данной темке, даже ни разу не использовал настоящие ФП языки, типа того же Хаскеля...

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

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

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

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

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

Пробовал писать на F#, для баловства — норм.
Но... Ни кто не мешает на том же C# брать от ФП самое лучшее и не делать ошибки:
— Не наследовать реализацию.
— Стараться использовать вычисление состояния, а не хранить само состояние (если есть возможность).
— Стараться не писать абстракции ради абстракций.
— Использовать AOP для сквозной функциональности.

Не надо возводить культ из какой-то одной парадигмы, языка или фреймворка

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

N>224 штуки (современный x86). Пусть на сеть достанется половина этого, тебе мало?

Это означает, что я могу не больше 224 разных железяк подцепить к машине? Или что?

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

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

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

S>Например? Вроде единственное что позволяет делать иммутабельность — это раскидывать исполнение по потокам не боясь побочных эффектов.
например определять что в разных частях одно и тоже подвыражение и оставлять только одно его вычисление.
более мощные возможности по упрощению выражений.
как-то где-то на MS research попадалась статья об оптимизациях в компилятора Haskell-я, там много всего интересного было. но ссылку сейчас не вспомню.

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

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

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

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

N>>224 штуки (современный x86). Пусть на сеть достанется половина этого, тебе мало?
S>Это означает, что я могу не больше 224 разных железяк подцепить к машине? Или что?

А что ты тут назвал железяками?
Мне крайне сложно представить себе систему на x86 с 224 внешними устройствами но если будет, там наверняка будет NUMA и раздельный раутинг прерываний между группами процессоров, так что реальных прерываний будет ещё больше.

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

N>А что ты тут назвал железяками?

Клавиатура, GPU.

N>Мне крайне сложно представить себе систему на x86 с 224 внешними устройствами но если будет, там наверняка будет NUMA и раздельный раутинг прерываний между группами процессоров, так что реальных прерываний будет ещё больше.

А робот какой-нибудь, с кучей переферии?

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

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

AA>>Вот моя история,
AA>>после нескольких лет на си# стал присматриваться к другим языкам.

_>C# был первым языком? Сочувствую...

Не, школа — Quick Basic for DOS
универ — turbo pascal, Mathcad.
Первая работа — Foxpro for DOS
Потом уже C#.
Далее java, groovy(GRAILS), эпизод со scala(переписано через месяц эксплуатации на Nancy FX + Dapper). js не считаю(нужен всегда).
Немного 1C, php, python.
Остальное (фшарпы, лиспы, ди, ним) только в качестве развлечения/скриптинга.
естественно приходится писать на том языке который требуется. Но желание переписать все на ФП еще теплится в душе.

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

N>>224 штуки (современный x86). Пусть на сеть достанется половина этого, тебе мало?

S>Это означает, что я могу не больше 224 разных железяк подцепить к машине? Или что?

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

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

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

S>Например? Вроде единственное что позволяет делать иммутабельность — это раскидывать исполнение по потокам не боясь побочных эффектов.

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

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

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

Оптимизации производительности растут из этих же свойств, например, кеширование.

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

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

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

scf>Автор взял всё самое худшее из ООП и последовательно его громит.
scf>Но сейчас не 90е и ООП как граф мутабельных объектов "реального мира уже неактуален.

Представим, что ООП это некий физический объект, который мы исследуем в течение многих лет. Вполне допустимо, что представления о нем иногда кардинально меняются по мере накопления наблюдений и их анализа (напр. гео/гелиоцентрическая система).
Но только ООП это не то, что мы исследуем, а то, что постулируем. ООП это исключительно, так сказать, продукт ума. Если меняется определение понятия, то нужен и новый термин. Либо, в крайнем случае, должен быть указан некий инвариант в определении ООП, сохраняющийся после переопределения этого понятия.
Вопрос на триллион тугриков: что общего в ООП Алана Кейна, ООП 90х и "современном ООП"?

ЗЫ Есть подозрение, что основная проблема ООП в том, что нет никакого ООП. И вообще, ООП возник как результат мышления по аналогии и апеллирует к чисто ассоциативному (не понятийному) мышлению.

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

A>ЗЫ Есть подозрение, что основная проблема ООП в том, что нет никакого ООП. И вообще, ООП возник как результат мышления по аналогии и апеллирует к чисто ассоциативному (не понятийному) мышлению.

ООП родился из ментальной модели мышления человека. Софтварные продукты постоянно растут в сложности, а потому арсенал пополняется самыми разными приемами. А местные ОО-хейтеры до сих пор три кита ищут.

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

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

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

Если вы хорошо владеете ООП с использованием C#,
то попробуйте написать что-нибудь простое на пару экранов с использованием Nemerle в ФП-стиле
(учебные материалы здесь).

A>ЗЫ Есть подозрение, что основная проблема ООП в том, что нет никакого ООП. И вообще, ООП возник как результат мышления по аналогии и апеллирует к чисто ассоциативному (не понятийному) мышлению.
OOP is the singular of OOPS!

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

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

public static class Funcs {public static int F (int a) => a*a; }

На всякий случай подчеркну, что это — ровно последний ваш вариант (с т.з. семантики). Вариант с делегатом всё же порождает несколько другой код. В частности, с т.з. возможностей инлайнинга.