Я и не говорил ничего про обязательность высшего. Как у вас тогда нанимаются студенты младших курсов и люди без образования — все по исключениям? Тогда наверно эти факторы не такое уж и влияние имеют — зачем на них делать акцент?
Правила у вас по моим впечатлениям плюс-минус обычные, только противоречивые. Каких-то новых инсайтов лично я не увидел.
Повторюсь, что в статье нет ничего про друзей — прокомментируйте пожалуйста, почему вы считаете, что по этим правилам вы выбираете именно друга, а не просто сотрудника или хотя бы человека, подходящего по культуре.
Статья попахивает ошибкой выжившего. В комментариях много писали про нестыковку касательно отбора по вузу. Среди прочих советов меня сильно покоробил пункт про выбрасывание резюме студентов в мусорку. Мой опыт говорит о том, что если студент не работает на старших курсах, то он либо чем-то действительно сильно увлечен, либо он не настроен и/или не может работать, и после получения бумажки специалистом он не станет. А если давать возможность толковым студентам, то они ее с лихвой оправдывают, и на работе развиваются гораздо лучше, чем в вузе.
Вы вывели для себя какие-то правила найма — это похвально. Однако далеко не факт, что эти правила можно хоть сколько-нибудь обобщить за пределы вашей компании. Даже не факт, что именно эти правила лучше всего работают на вашу компанию.
Сама статья не оправдала заголовка — про друзей в ней ничего нет.
Я не говорю, что для скалы порог входа высокий. Я тоже могу рассказать несколько историй про то, как быстро люди начинают на ней писать.
Я про то, что у питона он ниже. Еще раз — я ни в коем случае не против скалы. Просто говорю, что питон начал отъедать ее аудиторию для спарка. Я уже не знаю, как вам еще доказать, что это не «сказки» — зайдите что ли в чат русского сообщества apache spark в телеге или посмотрите программу Spark AI Summit — там есть чисто питонячий трек.
Для действительно тяжелых задач — да, на скале будет быстрее. Для того, чтобы проверять гипотезы — вряд ли. Тут уже разница есть, когда нужно реальная оптимизация, недостижимая сменой алгоритма. Но api pyspark предоставляет почти полностью идентичный скале, выполняется все на экзекуторах. Если большая часть обработки — на spark sql или через стандартные методы, то питон там будет проседать в основном только из-за боксинга/анбоксинга. По сетке гонять все равно дороже.
В любом случае порог входа ниже для питониста. Если даже взять среднюю температуру по больнице в виде запросов “spark scala” и “spark python” на hh, то получим 134 против 211.
Вот вы сами сказали что модели пишут на питоне, а потом в проде на java переписывают. Если на скале удобнее — чего ж на ней-то не пишут?
В спарке в том то и прикол, что очень многим от него начинает быть нужен только spark sql. А там без разницы практически на чем писать. Вот и пишут дата сайентисты на питоне спарковские джобы. Т.е. основной язык, где разрабатывается что-то новое, уже не факт, что scala.
Ок, перефразирую вопрос — при каких условиях для нового проекта будет использоваться Akka? Эти условия те же, что были до появления котлина с корутинами?
Disclaimer: я не фанат котлина, но мне кажется, что он неплохо отжирает долю ниш скалы.
Поверх континуаций акторы строятся легко. Представьте, что вы разработчик, который одинаково знаком с akka и корутинами — новый проект на чем будете начинать?
Мне кажется, что статья оторвана от реальности.
Начало вроде многообещающее — хорошая затравка про ниши, где scala хороша. И почти нет реакции на то, что стало с ней сейчас, причем в комментах к оригиналу это подметили.
Spark застрял со старой версией (всем миром ему помогали на 2.12 выкатываться), некоторые библиотеки еще не смогли (например, elasticsearch-hadoop). Ну и как выше писали в комментах, мигрировать не очень просто. И все больше скалу в спарке вытесняет питон.
Из ниши «better java» скалу со свистом вышвырнул котлин — а в статье про него ноль упоминаний. И у того же котлина уже есть плюс-минус рабочее решение с js и native. У скалы вроде как тоже, но котлин в этих направлениях развивается гораздо активнее. Scala-js по маргинальности примерно одинакова с хаскеллем на фронте. Native там же примерно. Да и graalvm тоже маячит.
Akka уже теснят всякие корутины и project loom. Реактивным программированием сейчас тоже никого не удивишь.
Dotty вроде как дает надежду и уже почти готов, но опять же в статье про него тоже ни слова.
Ожидал от статьи какого-то обоснованного позитива и подсветку направлений, где скала сильна и имеет хорошие перспективы. Но в статье этого нет. Такое ощущение, что скоро скала останется в банках, легаси и у маргиналов.
Если упростить, то да. Уточню, что тут отправка идет не через бота, а через основной аккаунт (как будто бы это был клиент), и надо сделать пару дополнительных обработок, но это не очень существенно.
Насчет проверки моего примера — согласен, я ошибся, и думал, что балансируется по весу, а не по высоте на его основе. Меня не покидало ощущение, что что-то не так: вроде у вас похожее с АВЛ-деревом условие (высоты левого и правого деревьев отличаются не более чем на единицу), но при этом у вас только 1 поворот на операцию, а в АВЛ их может быть два.
Вот пример: {8, 4, 30, 2, 6, 10, 36, 9, 12,38, 13, 14, 15 }; https://ideone.com/recc7a
При его последовательной вставке в ваше дерево получится справа высота два, слева — 5. Явно нарушается ваш предполагаемый инвариант про баланс высот. Хотелось бы иметь формальное доказательство, что у вас там действительно логарифмическая высота — не факт, что найденый мой пример делает самый худший дизбаланс, наверняка можно похуже найти.
Насчет удаления — не согласен. У вас же после 1 поворота идет выход из цикла, значит при вставке отбалансируется только самый нижний кусочек.
При удалении тоже надо балансировать, иначе можно поудалять листья таким образом, что дерево будет иметь линейную высоту.
Кроме того, попробуйте вставить в ваше дерево последовательно числа от 1 до 1000 — если я правильно понял ваш код, то высота в вашем дереве будет в районе 250 вместо ожидаемой 10-20
У меня какое-то дежавю. https://habr.com/ru/post/479142/
Повторю свой комментарий оттуда — чем ваша идея отличается от дерева порядковой статистики, которое давным-давно описано в Кормене?
Я и не говорил ничего про обязательность высшего. Как у вас тогда нанимаются студенты младших курсов и люди без образования — все по исключениям? Тогда наверно эти факторы не такое уж и влияние имеют — зачем на них делать акцент?
Правила у вас по моим впечатлениям плюс-минус обычные, только противоречивые. Каких-то новых инсайтов лично я не увидел.
Повторюсь, что в статье нет ничего про друзей — прокомментируйте пожалуйста, почему вы считаете, что по этим правилам вы выбираете именно друга, а не просто сотрудника или хотя бы человека, подходящего по культуре.
Статья попахивает ошибкой выжившего. В комментариях много писали про нестыковку касательно отбора по вузу. Среди прочих советов меня сильно покоробил пункт про выбрасывание резюме студентов в мусорку. Мой опыт говорит о том, что если студент не работает на старших курсах, то он либо чем-то действительно сильно увлечен, либо он не настроен и/или не может работать, и после получения бумажки специалистом он не станет. А если давать возможность толковым студентам, то они ее с лихвой оправдывают, и на работе развиваются гораздо лучше, чем в вузе.
Вы вывели для себя какие-то правила найма — это похвально. Однако далеко не факт, что эти правила можно хоть сколько-нибудь обобщить за пределы вашей компании. Даже не факт, что именно эти правила лучше всего работают на вашу компанию.
Сама статья не оправдала заголовка — про друзей в ней ничего нет.
Я не говорю, что для скалы порог входа высокий. Я тоже могу рассказать несколько историй про то, как быстро люди начинают на ней писать.
Я про то, что у питона он ниже. Еще раз — я ни в коем случае не против скалы. Просто говорю, что питон начал отъедать ее аудиторию для спарка. Я уже не знаю, как вам еще доказать, что это не «сказки» — зайдите что ли в чат русского сообщества apache spark в телеге или посмотрите программу Spark AI Summit — там есть чисто питонячий трек.
Для действительно тяжелых задач — да, на скале будет быстрее. Для того, чтобы проверять гипотезы — вряд ли. Тут уже разница есть, когда нужно реальная оптимизация, недостижимая сменой алгоритма. Но api pyspark предоставляет почти полностью идентичный скале, выполняется все на экзекуторах. Если большая часть обработки — на spark sql или через стандартные методы, то питон там будет проседать в основном только из-за боксинга/анбоксинга. По сетке гонять все равно дороже.
В любом случае порог входа ниже для питониста. Если даже взять среднюю температуру по больнице в виде запросов “spark scala” и “spark python” на hh, то получим 134 против 211.
Так про то и речь. Раньше дата-анализ на спарке был либо на голых rdd, либо на java-либах. Сейчас эту нишу отъел питон.
В тестах? Весьма странно — имхо, у scala test больше возможностей и гибкости, чем у любой котлиновской библиотеки тестов или junit того же самого.
Вот вы сами сказали что модели пишут на питоне, а потом в проде на java переписывают. Если на скале удобнее — чего ж на ней-то не пишут?
В спарке в том то и прикол, что очень многим от него начинает быть нужен только spark sql. А там без разницы практически на чем писать. Вот и пишут дата сайентисты на питоне спарковские джобы. Т.е. основной язык, где разрабатывается что-то новое, уже не факт, что scala.
Ок, перефразирую вопрос — при каких условиях для нового проекта будет использоваться Akka? Эти условия те же, что были до появления котлина с корутинами?
Disclaimer: я не фанат котлина, но мне кажется, что он неплохо отжирает долю ниш скалы.
Поверх континуаций акторы строятся легко. Представьте, что вы разработчик, который одинаково знаком с akka и корутинами — новый проект на чем будете начинать?
Мне кажется, что статья оторвана от реальности.
Начало вроде многообещающее — хорошая затравка про ниши, где scala хороша. И почти нет реакции на то, что стало с ней сейчас, причем в комментах к оригиналу это подметили.
Spark застрял со старой версией (всем миром ему помогали на 2.12 выкатываться), некоторые библиотеки еще не смогли (например, elasticsearch-hadoop). Ну и как выше писали в комментах, мигрировать не очень просто. И все больше скалу в спарке вытесняет питон.
Из ниши «better java» скалу со свистом вышвырнул котлин — а в статье про него ноль упоминаний. И у того же котлина уже есть плюс-минус рабочее решение с js и native. У скалы вроде как тоже, но котлин в этих направлениях развивается гораздо активнее. Scala-js по маргинальности примерно одинакова с хаскеллем на фронте. Native там же примерно. Да и graalvm тоже маячит.
Akka уже теснят всякие корутины и project loom. Реактивным программированием сейчас тоже никого не удивишь.
Dotty вроде как дает надежду и уже почти готов, но опять же в статье про него тоже ни слова.
Ожидал от статьи какого-то обоснованного позитива и подсветку направлений, где скала сильна и имеет хорошие перспективы. Но в статье этого нет. Такое ощущение, что скоро скала останется в банках, легаси и у маргиналов.
Если упростить, то да. Уточню, что тут отправка идет не через бота, а через основной аккаунт (как будто бы это был клиент), и надо сделать пару дополнительных обработок, но это не очень существенно.
Насчет проверки моего примера — согласен, я ошибся, и думал, что балансируется по весу, а не по высоте на его основе. Меня не покидало ощущение, что что-то не так: вроде у вас похожее с АВЛ-деревом условие (высоты левого и правого деревьев отличаются не более чем на единицу), но при этом у вас только 1 поворот на операцию, а в АВЛ их может быть два.
Вот пример: {8, 4, 30, 2, 6, 10, 36, 9, 12,38, 13, 14, 15 };
https://ideone.com/recc7a
При его последовательной вставке в ваше дерево получится справа высота два, слева — 5. Явно нарушается ваш предполагаемый инвариант про баланс высот. Хотелось бы иметь формальное доказательство, что у вас там действительно логарифмическая высота — не факт, что найденый мой пример делает самый худший дизбаланс, наверняка можно похуже найти.
Насчет удаления — не согласен. У вас же после 1 поворота идет выход из цикла, значит при вставке отбалансируется только самый нижний кусочек.
При удалении тоже надо балансировать, иначе можно поудалять листья таким образом, что дерево будет иметь линейную высоту.
Кроме того, попробуйте вставить в ваше дерево последовательно числа от 1 до 1000 — если я правильно понял ваш код, то высота в вашем дереве будет в районе 250 вместо ожидаемой 10-20
Если у вас не сбалансированное ДДП, то тогда и сложности операций у вас будут в худшем случае линейные (в среднем все равно логарифмические).
Формат статьи "обзор книги, только суть" мне очень понравился. Спасибо за проделанную работу.
У меня какое-то дежавю.
https://habr.com/ru/post/479142/
Повторю свой комментарий оттуда — чем ваша идея отличается от дерева порядковой статистики, которое давным-давно описано в Кормене?
А как в итоге правильно разрулить ситуацию из "Дайте возможность сохранить лицо"?
Еще в Кормене описано подобное как дерево порядковой статистики.
https://books.google.ru/books?id=UVg1LPacgRcC&pg=PA366&lpg=PA366&dq=дерево+порядковой+статистики&source=bl&ots=_VcQMlhYFC&sig=ACfU3U2jkcg12kdbh8ql4p9_S4f4iCmTrw&hl=ru&sa=X&ved=2ahUKEwjHuImmhqnmAhWlw8QBHTrHDNAQ6AEwBnoECAoQAQ#v=onepage&q=дерево%20порядковой%20статистики&f=false
Чем ваше решение отличается?
Зависит от языка? В той же scala у всех есть equals(). Может имеется ввиду не равный, а идентичный (та же ссылка)?
Embrace, extend and extinguish