Типичный пример оверинженеринга. Придумали как из простых 14 сделать 200 строк нечитаемого кода

Да что вы лезите со своими стековыми корутинами? Если не понимаете и не можете работать без стековыми корутинами, то пользуйтесь системными потоками будет практический тоже само что и стековые корутины.

Что за пархающая кувалда рассказывает эти сказки?

нихрена не понятно как с конфигами работать

Дяденька уж старый а всё какой-то херотой занимается. "Расскажу ребятам как я писал говнокод". Ну ок.

В институте я много слышал про конечные автоматы (КА), но это всё было теорией - как облака в небе: воды в них много, а напиться нельзя. Корпел три месяца после института, пока не реализовал свой КА в коде в 1981 году. Сейчас существует методология программирования на этой основе - v-agent oriented programming (VAOP) - и множество примеров её реализации. Лучше начать знакомство с VAOP с этой статьи на Medium: "Bagels and Muffins of Programming or How Easy It Is to Convert a Bagel into a Black Hole" или на Хабре: "Бублики и Коржики Программирования".

Послeшал, все тоже самое уже было в 2012 году в Xamarin. Google молодцы, скопипастили полностью архитектуру Xamarin только заменив C# на Kotlin. )))))

Какой ваш уровень программирования? Между Middle-Senior? - Ну, у нас уровень сеньорности... ближе к джунам :D

Крутой доклад, спасибо ❤

Закончилось место на работе, убираем селери) логично же) Не понял честно говоря аргументы.

Хороший видос,а комменты где?))

kzfaq.info/get/bejne/d8p8jbChqdXcm4k.html Женщина забавная конечно, отрасль не самая денежная, мягко говоря особенно на заре создания литреса. Ничего удивительного в этом нет.

Почему/зачем отзывы сделаны через dataclass, а value-object-ы с валидацией обычными классами ?

Пишу коммент по ходу просмотра, но думаю дальше не будет ответа на мой вопрос. Спикер говорит, что нам программистам удобно думать в терминах синхронного программирования и очень неудобно в терминах машины состояний... Я, признаюсь, сильно деформирован в сторону микроконтроллеров. Но в нашем стане та же ситуация - что-то чуть сложнее, чем лампочкой помигать - программистам подавай либо ОС с потоками и переключением контекста, либо городят суперцикл с задержкой в конце, пока это можно, а потом говорят, что всё - нужен камень пожирнее и опять же ОС. У меня как-то так сложилось, что я сразу нащупал Конечные Автоматы, проникся и теперь для меня абсолютно обыденно СРАЗУ раскладывать любой алгоритм (если это не однопроходный скрипт) на состояния и выстраивать между ними связи. Это происходит нативно и без каких-то усилий. И даже на Python, когда есть возможность использовать потоки и корутины - я всё равно выстраиваю логику на КА, и когда нужно отдаю управление другой корутине или потоку... Это просто очень удобно. Как писал один популяризатор - вы всё равно в своей программе будете использовать конечный автомат, просто в неявном виде. Так делайте это явно. Вопрос такой. Почему при том, что это так просто, это так непопулярно? Несколько раз поднимал эту тему на форумах наших - но это стена... Возможно корень проблемы в отсутствии общепринятой академической поддержки при обучении? Студентам много рассказывают про алгоритмы и ООП, а как написать красивого демона, который будет параллельно выполнять несколько задач - разберетесь сами? Сорян за много букв. Очень интересно будет услышать мнения автора и случайно залетевших даже спустя много времени.

очень порадовал первый спикер, который рассуждал какими-то странными категориями. тот же проект drypython с его returnes решает одну конкретную проблему, и рассуждать надо от решаемой проблемы а не от того что это функциональщину добавляет. тем более, с точки зрения синтаксиса языка ничего нового там нет. просто чуть другой стиль композиции и всё. это как есть люди, которые видя в python аннотации типов, говорят сразу что мол "не надо в наш динамический python вашу java затаскивать".

чел со сканом заебет конечно, чем он случал выступление - непонятно

Спасибо! красавчик!

класс

Про делегирование себе завтрашнему - это гениально.

Ура, я наконец то понял что такое это ваше mojo

По поводу опциональности - в Java есть класс Optional, и он более удобный, чем Optional в Python, т.к. это не просто обозначение, что объект может быть пустым, а полноценный класс. Аналог в Python мире - класс Maybe в пакете returns от Никиты Соболева (проект dry-python)

Непонятно ровным счётом нихуя. Как программист, зашёл посмотреть что эти кубиты из себя представляют и как их можно использовать. В итоге на меня вывалили ушат формул на эльфийском языке.

Если бы флатер был на котлине, то, уверен, все бы уже писали на нем...

Бедный, пытается в язык для скриптов затащить Enterpise архитектуру из компилируемых языков с интерфейсами и пакетами, где всё это хорошо работает.

Я человек простой, увидел доклад Миши, сразу лайк

Ну всё, надо Дишку тестить)

Кому интересно, на moscow python conf 2024 выйдет часть 2 этого доклада. Рассказывать будет мой коллега Миша. Мы провели работу над ошибками и написали версию 3 этого пайплайна. Стало ещё больше инструментов, ещё быстрее и было применено много хороших решений.

надо было майку с портретом землеройки надеть 😮

Когда увидел ошибку Mojo тоже сразу подумал что добавили плюсовых ошибок 😂

С охоты на мамонтов начинать надо было.

Столько лет трепа. А результата как не было так и нет.

Фигня если честно какая то.

Мы попадали ровно на эти же 2**31, благо сервис был очень маленький и некритичный

Докладчик вместо джавы зачем-то пошел в питон

😂😂😂 ключевые слова в ЯП уже повторяются по 100 раз.

Гуманитарии гуманитариям рассказывают и показывают.

По поводу сравнения numpy и mojo. Параллельность в коде на mojo вполне может присутствовать как и использование simd. Ибо компилятор основан на MLIR, который затачивается под такие задачи.

Классный доклад, многим будет полезно

уже и локально можно ставить и даже часть заопенсорисили)

Доклад хороший, но в середине уже перестал что либо понимать

«Весь мир - театр»...

Спасибо за живой доклад!

Тоже уже полгода нахожусь в поисках относительно того, как гексагональную архитектуру с DDD можно поженить с Python. Практически всё действительно сводится к велосипедам, т. к. нет готовых реализаций паттернов, которые описаны в книгах. А ещё сложнее от того, что в рамках питона некоторые вещи, реальные для Java, Kotlin или.NET, просто нереально реализовать из-за более слабой системы типов, своего видения ООП, дурацкой системы импорта и подобного.