Когда речь началась о производительности, я почему-то подумал что будет разбор вопроса о том, почему ФП-стайл чейны на итераторах быстрее императивных циклов.
А тут что-то непонятное — в обоих случаях уяснили, что ФП вариант медленнее. И что из этого следует? Какой ответ на вопрос из заголовка?
А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?
И является ли именно эта функция узким местом, которое надо оптимизировать? Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Потом видишь через 2 года сломанного человека с диаметрально изменённым мнением.
Да ладно вам — это довольно редко встречается. Для преодоления когнитивного диссонанса не обязательно менять свои убеждения. Можно еще просто отключать логику и не замечать очевидных вещей — так происходит намного чаще.
И получается классическое «Царь хороший, это бояре плохие».
А что, в других языках есть что-то более удобное для указания типовых параметров кроме <>? В вышеприведенной доке для этого другие скобочки [], но смысл-то от этого не меняется.
Ну да, конструкции типа
Arc<Mutex<Receiver<Option<Message<T>>>>>
Довольно многословны, но какие альтернативы? Разве что сделать какой-то разделитель одним символом, а не скобочками, типа
Arc!Mutex!Receiver!Option!Message!T
Но тогда как записывать, если типовых параметров больше одного? Какой синтаксис для лайфтаймов будет более удобен?
максимально эффективную компиляцию, вроде уникальных типов у разных лямбд.
А как это относится к эффективной компиляции? Лямбды в Расте имеют разные типы по той же причине, что и в С++. Лямбда — это просто синтаксический сахар для анонимной структуры с соответствующим методом. Две лямбды — две разные структуры, соответственно тип у них разный.
Какую реализацию вы предлагаете как более удобную? С учетом того что язык компилируемый, нативный и с минимальным рантаймом.
С дрожащими коленками я пришел на встречу с HR, задачей которой было причесывать студентов под гребенку корпоративного мышления. Запомнил две вещи: всунутую книгу Карнеги, о которой позже, и фразу: «Я в переписке ничего такого не вижу, но ты умный парень и понимаешь, кто-то может воспринять это плохо».
Это что, шутка? В такой ситуации взамен всунутой книги Карнеги эйчару суется заявление об увольнении.
Поверьте, такое точно происходит не везде и точно не является нормой — лучше сразу с такими распрощаться чем трепать себе нервы вместо работы.
это моя любимая тема, в которой специализируюсь последние несколько лет, увы
Насколько я понимаю, комментатор выше имел в виду что горутины в go реализуют вытесняющую модель многозадачности, а корутины в python — кооперативную.
В горутинах нам не надо явно писать yield и решать, где приостановить одну горутину и возобновить другую — шедулер языка сам этим занимается.
Поэтому это две большие разницы, и говорить, что питоновские корутины это аналог горутин и то что они «есть уже даже в python» — некорректно.
Кобол, АПЛ и Лисп.
10 лет назад десктопные приложения писали на Си.
Питон и перл — инди-языки.
Sun(!) и Майкрософт сражаются за байт-код.
Читал с ощущением того, что автора только что выпустили из крио-камеры. А потом таки глянул, что оригинал статьи 20-летней давности.
Забавно почитать, но все же тут осталось мало актуального.
«Что есть защищенная система? Защищенная система — это та система, взлом которой стоит дороже, чем ценность информации, которая там есть. Вот и все», — подытожил директор по информационным технологиям ОАО «РЖД»
Другими словами, заботиться о персональных данных пользователей «экономически нецелесообразно».
А тут что-то непонятное — в обоих случаях уяснили, что ФП вариант медленнее. И что из этого следует? Какой ответ на вопрос из заголовка?
И является ли именно эта функция узким местом, которое надо оптимизировать? Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Да ладно вам — это довольно редко встречается. Для преодоления когнитивного диссонанса не обязательно менять свои убеждения. Можно еще просто отключать логику и не замечать очевидных вещей — так происходит намного чаще.
И получается классическое «Царь хороший, это бояре плохие».
Что за «Прикладные программы» открывшие в 80-х?
И, если честно, в целом выглядит как некий срыв покровов с претензией на сенсацию. Неплохо было бы указанные в статье тезисы перепроверить.
Ну да, конструкции типа
Довольно многословны, но какие альтернативы? Разве что сделать какой-то разделитель одним символом, а не скобочками, типа
Но тогда как записывать, если типовых параметров больше одного? Какой синтаксис для лайфтаймов будет более удобен?
А как это относится к эффективной компиляции? Лямбды в Расте имеют разные типы по той же причине, что и в С++. Лямбда — это просто синтаксический сахар для анонимной структуры с соответствующим методом. Две лямбды — две разные структуры, соответственно тип у них разный.
Какую реализацию вы предлагаете как более удобную? С учетом того что язык компилируемый, нативный и с минимальным рантаймом.
Это что, шутка? В такой ситуации взамен всунутой книги Карнеги эйчару суется заявление об увольнении.
Поверьте, такое точно происходит не везде и точно не является нормой — лучше сразу с такими распрощаться чем трепать себе нервы вместо работы.
Насколько я понимаю, комментатор выше имел в виду что горутины в go реализуют вытесняющую модель многозадачности, а корутины в python — кооперативную.
В горутинах нам не надо явно писать yield и решать, где приостановить одну горутину и возобновить другую — шедулер языка сам этим занимается.
Поэтому это две большие разницы, и говорить, что питоновские корутины это аналог горутин и то что они «есть уже даже в python» — некорректно.
В расте это ошибка компиляции.
10 лет назад десктопные приложения писали на Си.
Питон и перл — инди-языки.
Sun(!) и Майкрософт сражаются за байт-код.
Читал с ощущением того, что автора только что выпустили из крио-камеры. А потом таки глянул, что оригинал статьи 20-летней давности.
Забавно почитать, но все же тут осталось мало актуального.
Другими словами, заботиться о персональных данных пользователей «экономически нецелесообразно».
По моим представлениям, самые крупные работодатели в айти — это крупные аутсорсеры и несколько продуктовых компаний.