• Почему Event Sourcing — это антипаттерн для взаимодействия микросервисов
    0

    Чем в вашем понимании отличается Event Sourcing от Службы с открытым протоколом?

  • Почему следует избегать использования исключений в управлении вашим потоком в Java
    +11

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


    С другой стороны приведённый пример с возвратом пустой строки противоречит второму совету — повышать понятность кода: пустая строка неотличима от реального имени и такой метод может привести к трудноуловимым ошибкам.


    Подобный подход имеет место и даже имя — https://ru.m.wikipedia.org/wiki/Null_object_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F), но использовать его нужно явно и осторожно.


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

  • Статический анализ IntelliJ IDEA против человеческого разума
    0
    Это возможно, только если условие res.isEmpty() действительно всегда истинно!
    Вот это не совсем верно — условие не полное, так как на самом деле это возможно если cur =! -1 || res.isEmpty()
  • Статический анализ IntelliJ IDEA против человеческого разума
    +3
    То есть строчка 'C' действительно недостижима, а 'B' при этом может выполняться. Это возможно, только если условие res.isEmpty() действительно всегда истинно!

    Не совсем так, на самом деле всегда истинно cur =! -1 || res.isEmpty(), т.е. как только список перестает быть пустым cur никогда не становится -1, а пока он -1 список пуст.


    Хорошо, что статический анализатор находит ошибку в плохом коде, плохо что после исправления ошибки код остается плохим.

  • Неявные (implicit) параметры и преобразования в Scala
    0

    Да, функционал одновременно и рискованный и мощный. Многие варианты использования имплиситов неуместны, а неявные преобразования и вовсе будут исключены из языка. С другой стороны этот механизм позволяет реализовать очень интересный механизм — автоматический вывод структур. Например если существует json формат для чисел и строк, и показано как строить форматы для списков и мап, то формат для Map[String, Seq[Int]] выводится автоматически и на стадии компиляции. При этом это не вшито в библиотеку json, а работает для любых типов.

  • Неявные (implicit) параметры и преобразования в Scala
    0

    Вот тут сам автор языка очень хорошо описывает основные случаи использования (осторожно, антимонгольский): https://youtu.be/br6035SKu-0

  • Хватит спорить про функциональное программирование и ООП
    0

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

  • Как обрабатывать ошибки на JVM быстрее
    0

    Поправлю, по оси x доля ошибок в датасете, по оси у — время выполнения (в абстрактных попугаях, так как зависит от окружения)

  • Как обрабатывать ошибки на JVM быстрее
    0

    Не jmh единым

  • Как обрабатывать ошибки на JVM быстрее
    0

    Ну, теоретически такое было возможно и до 8 версии, просто выглядело более громоздко, но та же IDEA это скрывала

  • Как обрабатывать ошибки на JVM быстрее
    0

    Я не говорю про библиотеки, с ними можно все, стандартная библиотека ни в Java 8 ни в Java 11 не поощряет такой подход

  • Как обрабатывать ошибки на JVM быстрее
    +1

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

  • Как обрабатывать ошибки на JVM быстрее
    +1

    В Java к сожалению ADT почти не используются и даже стандартный Optional не рекомендуется использовать в интерфейсах и передавать между методами.

  • Парадокс времени ожидания, или почему мой автобус всегда опаздывает?
    +2
    Чтобы убедить себя в разумности этого, сначала смоделируем поток автобусов, которые прибывают в среднем за 10 минут.

    N = 1000000  # number of buses
    tau = 10  # average minutes between arrivals
    
    rand = np.random.RandomState(42)  # universal random seed
    bus_arrival_times = N * tau * np.sort(rand.rand(N))

    Не все тут знают numpy, что значит N * tau * np.sort(rand.rand(N))? Почему N участвует тут дважды? Какое распределение задержки с заданным средним мы эмулируем? В любом случае более формальная постановка задачи была бы очень кстати.


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

  • Четыре типажа программистов
    +14

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

  • Функции высших порядков и монады для PHP`шников
    +1

    Возьмем для примера чистый функциональный язык Haskell, в нем делается так:


    module Fruits (Tomato, grow, eat) where
    
    data Tomato = Tomato String Int
    
    grow weight = Tomato "Good one" weight
    eat (Tomato name _) = name ++ " was good"

    Извне модуля видно только имя типа Tomato и функции, внутренняя структура абстрагирована.
    Полиморфизм тут тоже есть, если интересно, называется Type Classes.

  • Функции высших порядков и монады для PHP`шников
    0

    Нефтяная труба и ящик помидоров это тоже данные, функциональный подход прекрасно справляется с такими сущностями, зато не возникает вопросов "сьесть" это метод человека или помидора? Или еще хуже, чей метод "создать продукт питания"?
    А что там внутри длинна/ширина это нас не должно волновать, абстракция там тоже есть.

  • Функции высших порядков и монады для PHP`шников
    0

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

  • Функции высших порядков и монады для PHP`шников
    +1

    На самом деле в этом примере ООП не используется, а класс используется только ради инфиксной нотации ($this->orElse($that) вместо orElse($this, $that)).
    А у ООП достаточно недостатков, начиная от хрупкости базового класса. Это видно даже в количестве паттернов, большей части из которых в функциональной парадигме просто нет, за ненадобностью.

  • Функции высших порядков и монады для PHP`шников
    0

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

  • Функции высших порядков и монады для PHP`шников
    0

    Финальный код приведен в конце, правда ссылку на репозиторий я похоже забыл, вот он.
    Вот пример на js, правда на js и мой код выглядел бы на порядок проще, разница в тестируемости отдельных частей и декларативности.
    В парсинге строк я действительно немного схалтурил :)

  • Функции высших порядков и монады для PHP`шников
    0

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

  • Функции высших порядков и монады для PHP`шников
    0

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

  • Доводы в пользу function tree
    0

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

  • Функции высших порядков и монады для PHP`шников
    0
    Был подобный код и на Scala, а о чем продолжать? :)
  • Функции высших порядков и монады для PHP`шников
    0
    В принципе «сломать» мозг это отчасти цель этой статьи, для повышения гибкости, так сказать.
    А какой код кроме _do функции например сложный?
  • Функции высших порядков и монады для PHP`шников
    +2
    Момнады это у вас опечатка, а монады есть
  • Циничное решение логических задач
    +2
    Не могу согласиться с вашими уравнениями:
    А.СТАТУС = ИСТИНА IMP С.СТАТУС = СЛУЧАЙ
    будет истинным только если бог А ответил утвердительно, все эти уравнения строятся именно на этом предположении, т.е. вообще без реальных данных.
  • Altergaze: виртуальная реальность для вашего смартфона
    +1
    Мне кажется, или речь идет в основном о виртуальной реальности, а не о дополненной?
    Все-таки в смартфонах одна камера, так что и без стерео очков смартфон справится неплохо.
  • Еще одна история про домашний сервер, или операция «silence»
    0
    изначально так много пакетов не планировалось, до текущего состояния система разросталась 4-5 месяцев, при переустановке конечно же изменю подход к организации сервера… а пишу ли на всем?) да, как не странно) некоторые платформы в чисто образовательных целях, а некоторые — полноценные домашние проекты
    icepro
  • Еще одна история про домашний сервер, или операция «silence»
    0
    приходится опускать/поднимать контейнеры, в зависимости от необходимости
    icepro
  • Еще одна история про домашний сервер, или операция «silence»
    0
    Друзья, напоминаю, что автор icepro и он не может ответить без инвайта.
  • Я не знаю ООП
    0
    Это не имеет особого значения, тут подчеркивается не отличие, а скорее тождество. Модульное программирование слишком общее понятие, нынешние языки все модульные и ООП в том числе.
  • Я не знаю ООП
    0
    Паттерны и подходы в ООП разделяются на две группы: первая достаточно общая, чтобы ее применять не только к ООП (например MVC, почти все принципы SOLID, если вдумываться в смысл), вторая же призвана как-то обходить недостатки одного-двух мейнстримных языков (например С++, Java).
    Хотя конечно наша беседа начинает принимать форму спора о том, какие термины использовать, пусть будет по-вашему :)
  • Я не знаю ООП
    +1
    Я не говорил, что для ООП достаточно иметь объекты. Язык объектно-ориентированный, если он ориентирован на применение объектов, ни С ни Haskell на это не ориентированы.

    Более того, в С нет объектов, указатели на функции внутри структуры это такие же поля, как и прочие, поскольку при вызове они ничего не знают о включающем экземпляре.

    С тезисом относительно того, что Haskell позволяет разрабатывать в рамках ООП я вообще не согласен, не стоит полагаться на слово class, все же это практически чистый функциональный язык.

    Гуглом пользоваться я умею и если верить родителю самой идеи ООП, то ООП это сообщения, которыми обмениваются объекты, скрывающие свою реализацию. Там есть объекты, есть инкапсуляция и зачатки полиморфизма, но не упоминается наследование.
  • Я не знаю ООП
    +1
    Вовсе нет, инкапсуляция и полиморфизм не являются прерогативой ООП, наследование же вообще очень спорный механизм (кроме того для наследования нужно как раз поведение, состояние обычно наследуется в скрытом даже от наследника виде).
    Я вполне представляю себе ОО язык без наследования, но ОО без объектов нет.
    Возьмем к примеру Haskell — инкапсуляция на уровне модуля есть, полиморфизм на уровне классов есть, наследование классов есть. ООП? Конечно нет.
    Или JavaScript — инкапсуляции почти нет (только хаками), полиморфизм через duck-typing без наследования, наследование есть, но как часто его используют? ООП? Да.
  • Я не знаю ООП
    0
    Объект является независимым экземпляром модуля, называемого класс.
  • Я не знаю ООП
    +1
    У ООП есть свои недостатки, тема о которых уже неоднократно поднимались.
    Статья большая, но весь ее смысл вполне укладывается в заголовок.
    Да, ООП базируется на абстракции, инкапсуляции (как инструменте абстрагирования), наследовании (как очень хрупком инструменте) и полиморфизме. Не следует думать, что эти принципы используются только в ООП, конечно нет, любой язык без абстракции, инкапсуляции и полиморфизма довольно неудобен.
    Вы спрашиваете, что отличает ООП от других? Да объекты же! Абстрактные типы данных, инкапсулированные, унаследованые, полиморфные, неважно. Принцип в том, что объекты представляют тесно связанный модуль, который хорошо решает свою задачу.
    Естественно не всякий объект будет хорошим и подходящим, язык не сделает работу за вас, это только инструмент. Если хотите делать хорошие объекты используйте SOLID.
  • Chainvas: изящный и миниатюрный «костыль», добавляющий средства цепного вызова (method chaining) к любому API
    –3
    А чем вам with не угодил?!
  • Динамическое программирование и ленивые вычисления
    0
    Тут действуют естественные ограничения: индекс массива играет роль параметра функции и потому тут все зависит от множества определения функции, т.е. множества возможных значений параметров. Если такое множество слишком большое, то накладные расходы на хранение такого массива могут превышать выгоду от кеширования.