Просто смешно выглядят потуги неопытных людей, выдать чьи-то фантазии за вселенскую мудрость.
Фишка в том, что проблема не в комментариях, а в людях.
Как говорят в одном подкасте: «Технологии великолепны, просто есть люди мудаки».
P.S. А спросил я абсолютно правильно. В хорошем коде, со сложной предметной областью, комментарии более чем уместны.
Ну вы даете… как дети малые))
А подскажите, что делать мне: хочу купить бентли, но денег нифига нет. Понимаете, на работе выдали, очень понравилась. И вот для себя теперь тоже хочу. Зарабатывать на ней не планирую.
>Ну а нужны комментарии в случаях, когда написать код хорошо по тем или иным причинам не представляется возможным.
И опять это глупое, безапелляционное упрощение ситуации с комментариями.
Вы ни разу не видели хороший код со сложной предметной областью?
То, что многие используют каменты в стиле КО, не означает их полную ненужность и ни в коем случае не говорит о плохом коде. Ситуации и проекты разные бывают, это надо просто понимать.
Это не подмена понятий. Это многолетние жизненные наблюдения.
Те, кто ноет, только ныть и могут. Они ни на что не способны.
Мне не очень нравится такой переход джетбрейнсов. Но я уже давно удивлялся, почему они не введут подписку. Я, как и все мои знакомые Java (и не только) разработчики, один фиг каждый год покупаем обновление. Ничего не изменилось. Проблема может быть только у отдельных контор, как тут приводили пример в каментах, но таких немного в процентном соотношении.
И до и после будет куча нытиков, что они не могут заработать 90$ (а некоторые продукты и того дешевле) за год на продление инструмента который их кормит. По моим понятиям, если ты не можешь заработать такую, в общем-то небольшую сумму, то IDEA уже ничем не поможет. Бери бесплатные продукты и вперед.
Профессиональные инструменты никогда дешево не стоили. А цена IDEA более чем адекватна.
100$ на проф инструмент, для зарабатывания денег, для тебя дорого? Ну извини братан, значит тебе не сюда. Эта тема не для тебя.
Просто люди любят перекладывать собственные проблемы на кого-то. У обиженных всегда кто-то виноват во всем.
А я вот не разделяю вашу вашу уверенность.
С чего вдруг приток недовольных вдруг поспособствует росту упомянутых выше продуктов?
Эти продукты годами забивали на нужды пользователей. Все изменения, мелочевка по сути. Как именно эта толпа недовольных внезапно повлияет на эти продукты? Они точно также придут туда и будут ныть что все плохо, что им все во круг должны что-то сделать бесплатно и т.д. Откуда возьмется польза?
У вас очень упрощеный взгляд на этот вопрос.
То реактивное программирование, которое упоминаете вы, если так можно выразится «входит в состав» того реактивного программирования, которое сейчас принято понимать. И сокращеный манифест которого привели выше.
Фишка в том, что Akka это не табличный процессор. Это надо просто понимать.
Akka это фреймворк общего назначения, на котором в том числе можно построить и табличный процессор. Это кстати одно из задай на курсах Одерского по Scala, Akka и реактивному программированию).
В общем случае, программы которые строят на Akka гораздо сложнее чем просто пересчет формул в экселе. Поэтому сравнивать их очень странно.
И сам вопрос «как реактивное программирование реализовано в акторах» звучит очень странно. Это как спросить «как реактивное программирование реализовано в C# или на Python» или на любом другом языке или фреймворке. Ибо, учитвая что это объекты общего назначения, ответ будет простым — так как вы сами реализуете.
Сама же реактивность в акторных системах реализуется просто, вся система реагирует на входящие сообщения и реагируя на них изменяет свое состояние на выходе. Без промежуточного сохранения. Сделано это через передачу сообщений, что дает много профита, особенно для многопоточной разработки. Сам актор — «формула», которая делает одно вычисление. Без состояния. Таким образом запуская много таких формул получаем тот самый поток данных который проходя через множество акторов на выходе дает результат.
Но надо понимать, что конкретное применение зависит от задач проекта. Сам фреймворк позволяет множетсво решений.
А это походу бесполезно объяснять адептам ООП.
У них есть железобетонный аргумент «я то же самое могу написать на ООП».
Им нет дела, до более корректных инженерных решений.
Они не понимают, что такое надежность, предсказуемость и т.д.
Лучше всего про это сказал кто-то из докладчиков, вроде на джипоинте.
Правда он говорил это про тесты, но суть можно применить ко многим вещам.
«Чак Норрис не ходит на охоту, потому что охота подразумевает неудачу. Чак Норрис ходит убивать.»
Так и инженер, может писать программу без тестов и тогда он «ходит на охоту».
Или писать программы сложным подходом с кучей потенциальных проблем, но который он уже применял.
И делать это просто потому, что он не знает/не понимает как можно делать лучше, проще и с большей гарантией.
Не соглашусь.
Я в технических статьях в первую очередь смотрю на суть.
И я благодарен человеку, потратившему свое время, чтобы рассказать о своем полезном опыте.
P.S. Раздражать это может только учителей Русского языка, которым не важно что написано, а важно как.
Просто во круг достаточно умные люди, что бы не обращать внимания в технической статье на такую херню как написание числительных. Тем более, что все понятно.
> Задача этого цикла статей состоит не в том, чтобы объяснить всё вплоть до последней запятой (вряд ли я смог бы это сделать), но, скорее в том, чтобы заинтересовать вас RxJava, и тем, как она работает.
И сразу понеслись примеры кода…
А где объяснение, что это вообще такое ваш RxJava и для чего его придумали?
Просто смешно выглядят потуги неопытных людей, выдать чьи-то фантазии за вселенскую мудрость.
Фишка в том, что проблема не в комментариях, а в людях.
Как говорят в одном подкасте: «Технологии великолепны, просто есть люди мудаки».
P.S. А спросил я абсолютно правильно. В хорошем коде, со сложной предметной областью, комментарии более чем уместны.
А подскажите, что делать мне: хочу купить бентли, но денег нифига нет. Понимаете, на работе выдали, очень понравилась. И вот для себя теперь тоже хочу. Зарабатывать на ней не планирую.
Надеюсь аналогия понятна?
И опять это глупое, безапелляционное упрощение ситуации с комментариями.
Вы ни разу не видели хороший код со сложной предметной областью?
То, что многие используют каменты в стиле КО, не означает их полную ненужность и ни в коем случае не говорит о плохом коде. Ситуации и проекты разные бывают, это надо просто понимать.
Те, кто ноет, только ныть и могут. Они ни на что не способны.
Мне не очень нравится такой переход джетбрейнсов. Но я уже давно удивлялся, почему они не введут подписку. Я, как и все мои знакомые Java (и не только) разработчики, один фиг каждый год покупаем обновление. Ничего не изменилось. Проблема может быть только у отдельных контор, как тут приводили пример в каментах, но таких немного в процентном соотношении.
И до и после будет куча нытиков, что они не могут заработать 90$ (а некоторые продукты и того дешевле) за год на продление инструмента который их кормит. По моим понятиям, если ты не можешь заработать такую, в общем-то небольшую сумму, то IDEA уже ничем не поможет. Бери бесплатные продукты и вперед.
Профессиональные инструменты никогда дешево не стоили. А цена IDEA более чем адекватна.
100$ на проф инструмент, для зарабатывания денег, для тебя дорого? Ну извини братан, значит тебе не сюда. Эта тема не для тебя.
Просто люди любят перекладывать собственные проблемы на кого-то. У обиженных всегда кто-то виноват во всем.
С чего вдруг приток недовольных вдруг поспособствует росту упомянутых выше продуктов?
Эти продукты годами забивали на нужды пользователей. Все изменения, мелочевка по сути. Как именно эта толпа недовольных внезапно повлияет на эти продукты? Они точно также придут туда и будут ныть что все плохо, что им все во круг должны что-то сделать бесплатно и т.д. Откуда возьмется польза?
Т.е. раньше технической возможности по вашему не было?
Технический доступ и юридическое право использования продукта это не одно и тоже.
То реактивное программирование, которое упоминаете вы, если так можно выразится «входит в состав» того реактивного программирования, которое сейчас принято понимать. И сокращеный манифест которого привели выше.
Фишка в том, что Akka это не табличный процессор. Это надо просто понимать.
Akka это фреймворк общего назначения, на котором в том числе можно построить и табличный процессор. Это кстати одно из задай на курсах Одерского по Scala, Akka и реактивному программированию).
В общем случае, программы которые строят на Akka гораздо сложнее чем просто пересчет формул в экселе. Поэтому сравнивать их очень странно.
И сам вопрос «как реактивное программирование реализовано в акторах» звучит очень странно. Это как спросить «как реактивное программирование реализовано в C# или на Python» или на любом другом языке или фреймворке. Ибо, учитвая что это объекты общего назначения, ответ будет простым — так как вы сами реализуете.
Сама же реактивность в акторных системах реализуется просто, вся система реагирует на входящие сообщения и реагируя на них изменяет свое состояние на выходе. Без промежуточного сохранения. Сделано это через передачу сообщений, что дает много профита, особенно для многопоточной разработки. Сам актор — «формула», которая делает одно вычисление. Без состояния. Таким образом запуская много таких формул получаем тот самый поток данных который проходя через множество акторов на выходе дает результат.
Но надо понимать, что конкретное применение зависит от задач проекта. Сам фреймворк позволяет множетсво решений.
Очень мало структурированной информации на эту тему.
Когда перевод планируется к выходу?
У них есть железобетонный аргумент «я то же самое могу написать на ООП».
Им нет дела, до более корректных инженерных решений.
Они не понимают, что такое надежность, предсказуемость и т.д.
Лучше всего про это сказал кто-то из докладчиков, вроде на джипоинте.
Правда он говорил это про тесты, но суть можно применить ко многим вещам.
«Чак Норрис не ходит на охоту, потому что охота подразумевает неудачу. Чак Норрис ходит убивать.»
Так и инженер, может писать программу без тестов и тогда он «ходит на охоту».
Или писать программы сложным подходом с кучей потенциальных проблем, но который он уже применял.
И делать это просто потому, что он не знает/не понимает как можно делать лучше, проще и с большей гарантией.
Я в технических статьях в первую очередь смотрю на суть.
И я благодарен человеку, потратившему свое время, чтобы рассказать о своем полезном опыте.
P.S. Раздражать это может только учителей Русского языка, которым не важно что написано, а важно как.
Просто позорище, в Дом2 ему самое место.
Чуть не купил книгу.
Про эмиграцию гораздо актуальнее написано в профильных блогах.
> Задача этого цикла статей состоит не в том, чтобы объяснить всё вплоть до последней запятой (вряд ли я смог бы это сделать), но, скорее в том, чтобы заинтересовать вас RxJava, и тем, как она работает.
И сразу понеслись примеры кода…
А где объяснение, что это вообще такое ваш RxJava и для чего его придумали?
Во вторых, это сообщения между акторами внутри JVM, а не запросы по сети.
Монополист не дает рубить бабло на чужом контенте.
Это же ужасно и бесчеловечно. Люди должны об этом знать.
P.S. Это был сарказм. (для тех кто не понял)