Не, не правда.
В традиционной машине тоже много внимания уделено передаче данных между компонентами — контроллерами, памятью и процессорами. Однако для программиста эта передача данных представлена в упрощенном виде, чтобы он не заморачивался деталями. Передача данных между машинами также найдет свое упрощенное и в то же время адекватное представление (вероятнее всего, как передача сообщений между акторами), так что программисту не придется писать location: «socket://localost:9002» и он забудет Jolie, как дурной сон.
все правильно вы пишете, но нынешние методики scrum/agila/kanban не предполагают наличия документации. Единственный выход — самому дописать ТЗ и послать на утверждение стейкхолдерам. И если не ответят, то считать молчание — знак согласия.
«Вот почему так?»
потому что ноду изобрели недопрограммисты. Никакой нормальный программист не будет использовать жс ни для чего, кроме как манипулирования хтмл.
любой нормальный буфер имеет ограниченный размер, и неважно, 1 или 1000, все равно надо следить за переполнением. И да, за один раунд можно безопасно прочитать не более одного значения из входного порта и записать не более одного значения в выходной порт. Чтобы прочитать или записать больше, надо опрашивать состояние портов и быть готовым к тому, что это не удастся. Так что лучше и не опрашивать вовсе, а сразу выходить на следующий раунд.
"эта часть может быть например абстрактным методом"
и в какой момент он должен исполнятся? У вас для него не предусмотрено места. Он должен работать вне ProducerSubscription.
"описанию этого алгоритма стоило бы уделить больше внимания"
Да, мне как-то говорил один профессор, что ключевые моменты в статье надо повторять по три раза. Я же блокировку актора описал один раз:
Асинхронные программы не могут блокировать потоки… Блокировать свое исполнение они должны другим способом. Этот другой способ заключается в том, что они просто покидают рабочий поток, на котором исполнялись, но перед этим организуют свое возвращение к работе, как только семафор наполнится.
«было бы неплохо добавить разбор того что происходит в простой паре producer-consumer»
Итак, какой-то актор имеет ссылку на входной порт следующего актора, как нарисовано на картинках. Он вызывает операцию на акторе, что может привести к изменению его состояния. Так, если порт типа InPort был пуст, и туда поместили токен, то порт переходит из заблокированного состояния в разблокированное, и извещает об этом AbstractActor с помощью вызова decBlocked(). Если в результате число заблокированных портов стало равно нулю, то актор отправляется на исполнение, а контрольный порт блокируется, чтобы число заблокированных портов стало не равно нулю, и не произошло повторной отправки на исполнение.
Начав работать, актор вызывает пользовательскую процедуру whenNext, которая, скорее всего, извлечет токен из входного порта и тем самым его заблокирует. Когда пользовательская процедура закончит свой вызов, контрольный порт автоматически разблокируется. Если к этому моменту входной порт будет снова заполнен, это приведет к повторному запуску актора. Если нет, то актор будет ждать поступления токена на входной порт.
«что означает block, поскольку он не блокирующий»
block() блокирует алгоритм актора. О блокировке используемого потока исполнения мы вообще не говорим, поскольку нам это делать запрещено.
«чем этот подход лучше чего-то вроде»
в вашем примере нет разделения на системную и пользовательскую часть. Если я захочу сделать Publisher с другой функциональностью, мне нечего будет позаимствовать из вашего примера. А хотелось бы при написании функциональности не думать о системных вещах типа предотвращения нежелательного параллельного запуска одной и той же задачи.
Далее, вы не расписали subscriber.onNext(....). Где вы собрались вычислять очередное значение для onNext? там же, где и вызов onNext? Это снижает параллелизм в случае недобросовестного клиента, который нагружает свой onNext тяжелыми вычислениями. По хорошему, для вычисления генерируемых значений нужен отдельный актор.
«в асинхронно-реактивном мире следующая операция не ждёт окончания предыдущей, если она предыдущая) асинхронная»
Не совсем так. Если вы выполняете операцию reduce над элементами потока, например, для получения суммы элементов, по следующая операция сложения ждет окончания предыдущей. В модели акторов такое ожидание встроено по умолчанию, а в реактивном программировании с этим туго. Хорошо, если найдется подходящий уже реализованный паттерн, например, reduce, а построить самому обработчик, эквивалентный по поведению актору, на базе фрейморков реактивного программирования затруднительно.
«не понял, что в подобном случае с авторским правом»
ну что вы, как маленький. Авторское право принадлежит только вам. Никакого другого претендента рядом не просматривается. А то что вы не выписывали каждую нотку — ну так и музыкальные корпорации не сами писали песни, которыми владеют.
Единственная проблема — если вы случайно воссоздадите уже существующую мелодию, закопирайтите ее и на вас подадут в суд владельцы оригинального произведения.
вам возразили аргументированно, приведя пример из жизни. Вы же талдычите про какие-то стереотипы, не в силах привести жизненного примера. Это чистой воды злопыхательство.
"Если вы не понимаете исходники на Scala, то вы не понимаете ФП."
Не понимаю из-за переусложненного синтаксиса. Разве ФП язык обязан иметь криптованный синтаксис, по иному нельзя?
И заодно вопрос лично вам как знатоку ФП: какие функциональные конструкции Скалы нельзя выразить на простой Яве?
прежде чем говорить о семантике, надо продраться сквозь синтаксис. А такие синтаксические конструкции как xs filter (pivot ==), elems = args map Integer.parseInt или loop {react {}} попросту ставят в тупик.
ну раз операторы у них такие.
В традиционной машине тоже много внимания уделено передаче данных между компонентами — контроллерами, памятью и процессорами. Однако для программиста эта передача данных представлена в упрощенном виде, чтобы он не заморачивался деталями. Передача данных между машинами также найдет свое упрощенное и в то же время адекватное представление (вероятнее всего, как передача сообщений между акторами), так что программисту не придется писать location: «socket://localost:9002» и он забудет Jolie, как дурной сон.
потому что ноду изобрели недопрограммисты. Никакой нормальный программист не будет использовать жс ни для чего, кроме как манипулирования хтмл.
и в какой момент он должен исполнятся? У вас для него не предусмотрено места. Он должен работать вне ProducerSubscription.
"описанию этого алгоритма стоило бы уделить больше внимания"
Да, мне как-то говорил один профессор, что ключевые моменты в статье надо повторять по три раза. Я же блокировку актора описал один раз:
Асинхронные программы не могут блокировать потоки… Блокировать свое исполнение они должны другим способом. Этот другой способ заключается в том, что они просто покидают рабочий поток, на котором исполнялись, но перед этим организуют свое возвращение к работе, как только семафор наполнится.
Итак, какой-то актор имеет ссылку на входной порт следующего актора, как нарисовано на картинках. Он вызывает операцию на акторе, что может привести к изменению его состояния. Так, если порт типа InPort был пуст, и туда поместили токен, то порт переходит из заблокированного состояния в разблокированное, и извещает об этом AbstractActor с помощью вызова decBlocked(). Если в результате число заблокированных портов стало равно нулю, то актор отправляется на исполнение, а контрольный порт блокируется, чтобы число заблокированных портов стало не равно нулю, и не произошло повторной отправки на исполнение.
Начав работать, актор вызывает пользовательскую процедуру whenNext, которая, скорее всего, извлечет токен из входного порта и тем самым его заблокирует. Когда пользовательская процедура закончит свой вызов, контрольный порт автоматически разблокируется. Если к этому моменту входной порт будет снова заполнен, это приведет к повторному запуску актора. Если нет, то актор будет ждать поступления токена на входной порт.
block() блокирует алгоритм актора. О блокировке используемого потока исполнения мы вообще не говорим, поскольку нам это делать запрещено.
«чем этот подход лучше чего-то вроде»
в вашем примере нет разделения на системную и пользовательскую часть. Если я захочу сделать Publisher с другой функциональностью, мне нечего будет позаимствовать из вашего примера. А хотелось бы при написании функциональности не думать о системных вещах типа предотвращения нежелательного параллельного запуска одной и той же задачи.
Далее, вы не расписали subscriber.onNext(....). Где вы собрались вычислять очередное значение для onNext? там же, где и вызов onNext? Это снижает параллелизм в случае недобросовестного клиента, который нагружает свой onNext тяжелыми вычислениями. По хорошему, для вычисления генерируемых значений нужен отдельный актор.
вы правы! Эта статья скопирована с его статьи на сайте Академии Тринитаризма, даже название сохранено.
а что, публикации на Хабре учитываются?
Не совсем так. Если вы выполняете операцию reduce над элементами потока, например, для получения суммы элементов, по следующая операция сложения ждет окончания предыдущей. В модели акторов такое ожидание встроено по умолчанию, а в реактивном программировании с этим туго. Хорошо, если найдется подходящий уже реализованный паттерн, например, reduce, а построить самому обработчик, эквивалентный по поведению актору, на базе фрейморков реактивного программирования затруднительно.
ну что вы, как маленький. Авторское право принадлежит только вам. Никакого другого претендента рядом не просматривается. А то что вы не выписывали каждую нотку — ну так и музыкальные корпорации не сами писали песни, которыми владеют.
Единственная проблема — если вы случайно воссоздадите уже существующую мелодию, закопирайтите ее и на вас подадут в суд владельцы оригинального произведения.
Не понимаю из-за переусложненного синтаксиса. Разве ФП язык обязан иметь криптованный синтаксис, по иному нельзя?
И заодно вопрос лично вам как знатоку ФП: какие функциональные конструкции Скалы нельзя выразить на простой Яве?