А вот тот же FastAPI как мне кажется берет как раз лаконичностью. За счет креативного использования типов получается короткий, хорошо "ложащийся" в голову код.
Для библиотеки лучше, чтобы в одном месте не собиралось больше 5-7 сущностей. Любых сущностей) Но без фанатизма, конечно.
Конкретно про пандас - зависит от использования. Если из этих 21 на практике используются 3, а остальные 18 встречаются раз в год по местным праздникам - то они никого не напрягают. А вот если постоянно надо все 21 осматривать и выбирать - то нужен другой дизайн КМК.
Мимо) Мне почти полтинник и начинал я в середине 90-х как сишник и плюсовик. Делал, к примеру, Radmin. Он не течет 😂 Я чуть-чуть знаю про работу с памятью в разных языках 😜
Еще одна хорошая статья со ссылками на первоисточники. Процитирую: "Ordinary reaction time measured by clicking a mouse in response to an auditory, tactile, or combined auditory/tactile stimulation produced speeds in one study ranging from ∼210 to 320 ms for most people, but was as fast as 100–210 ms in trained musicians"
Если хороший английский то настоятельно рекомендую realpython.com, о котором писал в статье и рассказывал в докладе. Лучшее из того, что случилось с обучением программированию за последние десяток лет.
Изи. Когда я пишу users.add(user), то мне совершенно неинтересно какой "под капотом" контейнер "users", как именно реализовано "add", когда и за кем придет сборщик мусора. Я сосредоточен на решении бизнес задачи - мне нужно сохранить объект, отвечающий за пользователя, в контейнер. Линтеры, профилировщики и прочая инфраструктура должна помогать мне, если мой код для языка/фреймворка/стека неоднозначен, может быть неправильно понят, потечет памятью или еще что. Держать все это в человеческой памяти и самостоятельно следить за мелочами... ну, такое. Зачем доверять человеку то, что может сделать программа?
А gradual typing позволяет мне после стабилизации кода зайти и указать, какой контейнер я ожидаю или какой протокол должен поддерживать user, если для меня это важно. А если не важно - то могу не приходить. В отличии от Rust и C++, где объяснять детали придется в любом случае, важно для нас это как для разработчика или не важно.
Сейчас очень холиварно будет, но может быть проблема в том, что Вы написали код, который сами не понимаете
Все так. Только вот для других языков это не проблема. Понимать весь код, который пишет разработчик - это довольно накладно. Обычно мы понимаем те части, которые нам важны. А все остальное "разберись сам". Gradual typing позволяет при первоначальном быстром прототипизировании очень быстро фигачить код, понимая только ключевые части. И далее по мере необходимости уточнять детали.
Концепция "single file", "все в одном месте". Для простых и средней сложности сценариев (под которые заточено FastAPI) это удобнее, чем сотня роутов в отдельном файле. А вот когда роутов больше тысячи - наоборот становится удобнее их централизованно хранить в отдельном месте как в Django.
Мелочи в основном. В pyproject.toml можно конфиги других утилит централизованно складывать. pip умеет ставить проекты с pyproject.toml сразу с гитхаба итд.
The Rust Book. Я недавно брал интервью у автора. У меня книжка заняла несколько месяцев вдумчивого чтения по вечерам, это с большим C++ бэкграундом. По сравнению с хорошими учебниками по Python/JS она толстая и сложная.
Возможно, кто-то прочтет ее за несколько дней, во всем разберется и вообще ничего сложного. Делюсь тем опытом, что есть у меня :)
Двадцать лет назад я такое слышал про плюсы. "Да, эксепшны сломаны, но вы ведь можете в своем коде обернуть ВСЁ, в чем проблем?" Проблема в том, что обернуть все в своем коде - это чудовищные затраты сил на разработку. В то время как с помщью Rust мы просто пишем Err и выбираем из предложенного IDE нужные нам для обработки ошибки. Все делает компилятор + IDE, нам не нужно самим выстраивать "параллельное" дерево кодов ошибок.
А вот тот же FastAPI как мне кажется берет как раз лаконичностью. За счет креативного использования типов получается короткий, хорошо "ложащийся" в голову код.
Для библиотеки лучше, чтобы в одном месте не собиралось больше 5-7 сущностей. Любых сущностей) Но без фанатизма, конечно.
Конкретно про пандас - зависит от использования. Если из этих 21 на практике используются 3, а остальные 18 встречаются раз в год по местным праздникам - то они никого не напрягают. А вот если постоянно надо все 21 осматривать и выбирать - то нужен другой дизайн КМК.
Мимо) Мне почти полтинник и начинал я в середине 90-х как сишник и плюсовик. Делал, к примеру, Radmin. Он не течет 😂 Я чуть-чуть знаю про работу с памятью в разных языках 😜
Все правильно, будут вносить. И будет хороший повод еще раз собраться и обсудить финальный список.
Планируют, но пока это очень долгосрочные и неуверенные планы.
https://learn.python.ru/
Еще одна хорошая статья со ссылками на первоисточники. Процитирую: "Ordinary reaction time measured by clicking a mouse in response to an auditory, tactile, or combined auditory/tactile stimulation produced speeds in one study ranging from ∼210 to 320 ms for most people, but was as fast as 100–210 ms in trained musicians"
https://journals.lww.com/cogbehavneurol/Fulltext/9900/Consciousness_as_a_Memory_System.19.aspx
Я только что закончил съемки RubyRussia и мне очень-очень интересно, какая именно команда рубистов из Днепра имеется в виду?
Если хороший английский то настоятельно рекомендую realpython.com, о котором писал в статье и рассказывал в докладе. Лучшее из того, что случилось с обучением программированию за последние десяток лет.
Изи. Когда я пишу users.add(user), то мне совершенно неинтересно какой "под капотом" контейнер "users", как именно реализовано "add", когда и за кем придет сборщик мусора. Я сосредоточен на решении бизнес задачи - мне нужно сохранить объект, отвечающий за пользователя, в контейнер. Линтеры, профилировщики и прочая инфраструктура должна помогать мне, если мой код для языка/фреймворка/стека неоднозначен, может быть неправильно понят, потечет памятью или еще что. Держать все это в человеческой памяти и самостоятельно следить за мелочами... ну, такое. Зачем доверять человеку то, что может сделать программа?
А gradual typing позволяет мне после стабилизации кода зайти и указать, какой контейнер я ожидаю или какой протокол должен поддерживать user, если для меня это важно. А если не важно - то могу не приходить. В отличии от Rust и C++, где объяснять детали придется в любом случае, важно для нас это как для разработчика или не важно.
Все так. Только вот для других языков это не проблема. Понимать весь код, который пишет разработчик - это довольно накладно. Обычно мы понимаем те части, которые нам важны. А все остальное "разберись сам". Gradual typing позволяет при первоначальном быстром прототипизировании очень быстро фигачить код, понимая только ключевые части. И далее по мере необходимости уточнять детали.
Немного. "Все" используют pipenv или poetry 😇
Концепция "single file", "все в одном месте". Для простых и средней сложности сценариев (под которые заточено FastAPI) это удобнее, чем сотня роутов в отдельном файле. А вот когда роутов больше тысячи - наоборот становится удобнее их централизованно хранить в отдельном месте как в Django.
Мелочи в основном. В pyproject.toml можно конфиги других утилит централизованно складывать. pip умеет ставить проекты с pyproject.toml сразу с гитхаба итд.
dataclasses в комплекте и attrs от Хинека
Этих индексов - как грязи, https://www.tiobe.com/tiobe-index/python/ 😂
FastAPI старается всё исправить)
И еще одна любопытная статья, где осознание хорошо фиксируется в диапазоне от 276 до 576 миллисекунд с предъявления стимула: https://hackaday.com/2021/12/15/the-real-science-not-armchair-science-of-consciousness/
Мне нравятся "Eloquent JavaScript" и "Python Crash Course".
The Rust Book. Я недавно брал интервью у автора. У меня книжка заняла несколько месяцев вдумчивого чтения по вечерам, это с большим C++ бэкграундом. По сравнению с хорошими учебниками по Python/JS она толстая и сложная.
Возможно, кто-то прочтет ее за несколько дней, во всем разберется и вообще ничего сложного. Делюсь тем опытом, что есть у меня :)
Двадцать лет назад я такое слышал про плюсы. "Да, эксепшны сломаны, но вы ведь можете в своем коде обернуть ВСЁ, в чем проблем?" Проблема в том, что обернуть все в своем коде - это чудовищные затраты сил на разработку. В то время как с помщью Rust мы просто пишем Err и выбираем из предложенного IDE нужные нам для обработки ошибки. Все делает компилятор + IDE, нам не нужно самим выстраивать "параллельное" дерево кодов ошибок.