В институте я много слышал про конечные автоматы (КА), но это всё было теорией - как облака в небе: воды в них много, а напиться нельзя. Корпел три месяца после института, пока не реализовал свой КА в коде в 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" или на Хабре: "Бублики и Коржики Программирования".
ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-AdLZMpDoxkU.html Женщина забавная конечно, отрасль не самая денежная, мягко говоря особенно на заре создания литреса. Ничего удивительного в этом нет.
Пишу коммент по ходу просмотра, но думаю дальше не будет ответа на мой вопрос. Спикер говорит, что нам программистам удобно думать в терминах синхронного программирования и очень неудобно в терминах машины состояний... Я, признаюсь, сильно деформирован в сторону микроконтроллеров. Но в нашем стане та же ситуация - что-то чуть сложнее, чем лампочкой помигать - программистам подавай либо ОС с потоками и переключением контекста, либо городят суперцикл с задержкой в конце, пока это можно, а потом говорят, что всё - нужен камень пожирнее и опять же ОС. У меня как-то так сложилось, что я сразу нащупал Конечные Автоматы, проникся и теперь для меня абсолютно обыденно СРАЗУ раскладывать любой алгоритм (если это не однопроходный скрипт) на состояния и выстраивать между ними связи. Это происходит нативно и без каких-то усилий. И даже на Python, когда есть возможность использовать потоки и корутины - я всё равно выстраиваю логику на КА, и когда нужно отдаю управление другой корутине или потоку... Это просто очень удобно. Как писал один популяризатор - вы всё равно в своей программе будете использовать конечный автомат, просто в неявном виде. Так делайте это явно. Вопрос такой. Почему при том, что это так просто, это так непопулярно? Несколько раз поднимал эту тему на форумах наших - но это стена... Возможно корень проблемы в отсутствии общепринятой академической поддержки при обучении? Студентам много рассказывают про алгоритмы и ООП, а как написать красивого демона, который будет параллельно выполнять несколько задач - разберетесь сами? Сорян за много букв. Очень интересно будет услышать мнения автора и случайно залетевших даже спустя много времени.
Да, кстати. Когда синхронный код "под капотом" развернется в КА - это не совсем КА. Насколько я могу судить в этом КА мы можем шагать только последовательно. А если нужно вернуться к первым трем шагам? Красиво будет goto - но это ж нельзя! Поэтому будет изврат. Если же сразу разворачивать код в виде КА - то для задачи общения с сервером, например, обычно будет 2-3 состояния для подключения, 2-3 состояния для запроса, пару состояний на ожидание... и так далее. И если связь вдруг оборвалась - мы очень органично возвращаемся к группе состояний подключения или к любой другой группе - это очень удобно.
очень порадовал первый спикер, который рассуждал какими-то странными категориями. тот же проект drypython с его returnes решает одну конкретную проблему, и рассуждать надо от решаемой проблемы а не от того что это функциональщину добавляет. тем более, с точки зрения синтаксиса языка ничего нового там нет. просто чуть другой стиль композиции и всё. это как есть люди, которые видя в python аннотации типов, говорят сразу что мол "не надо в наш динамический python вашу java затаскивать".
По поводу опциональности - в Java есть класс Optional, и он более удобный, чем Optional в Python, т.к. это не просто обозначение, что объект может быть пустым, а полноценный класс. Аналог в Python мире - класс Maybe в пакете returns от Никиты Соболева (проект dry-python)
Но строгой проверки nullable (как в том же Kotlin) в Java все так же нет. Но это уже другой вопрос. В Python строгой проверки None тоже нет, она прикручивается сбоку тем же mypy.
Непонятно ровным счётом нихуя. Как программист, зашёл посмотреть что эти кубиты из себя представляют и как их можно использовать. В итоге на меня вывалили ушат формул на эльфийском языке.
Кому интересно, на moscow python conf 2024 выйдет часть 2 этого доклада. Рассказывать будет мой коллега Миша. Мы провели работу над ошибками и написали версию 3 этого пайплайна. Стало ещё больше инструментов, ещё быстрее и было применено много хороших решений.
По поводу сравнения numpy и mojo. Параллельность в коде на mojo вполне может присутствовать как и использование simd. Ибо компилятор основан на MLIR, который затачивается под такие задачи.
Тоже уже полгода нахожусь в поисках относительно того, как гексагональную архитектуру с DDD можно поженить с Python. Практически всё действительно сводится к велосипедам, т. к. нет готовых реализаций паттернов, которые описаны в книгах. А ещё сложнее от того, что в рамках питона некоторые вещи, реальные для Java, Kotlin или.NET, просто нереально реализовать из-за более слабой системы типов, своего видения ООП, дурацкой системы импорта и подобного.
Потому что в python не нужно то, что нужно в типизиоуемых языках. Di по сути это попытки втащить в типизируемые языки элементы интропретации, зачем это в и так в интропретируемом языке
Можете пояснить чем DI похож на интерпретацию? Ничего не мешает руками писать DI контейнеры как на питоне, так и на любом другом языке. Просто это не так удобно, как когда есть готовое универсальное решение. Для питона оно было (dependency-injector), но уже два года не поддерживается
В прошлом году начали использовать во всех сервисах на dependency-injector. Библиотека действительно не имеет конкурентов в текущий момент. Сейчас сервисы в основном на Python 3.10, пока жить можно. Но с Python 3.12 последний релиз не работает. Также нет поддержки Pydantic 2 для конфигурации. Ощущение, что автор забил на проект, но отказываться от удобства DI также очень больно
С интересом посмотрел. Скажите пожалуйста, какая звуковая волна с амплитудной модуляцией будет более помехозащищенной (если она передается открытым способом, не по проводам) - в продольной или поперечно поляризованной звуковой волне?
В питоне чистая архитектура работает плохо. Почему? Потому что asyncio - это библиотека, а не фича языка. Поэтому ты не можешь эффективно создавать интерфейсы, которые возможно будут работать с IO, либо ты изначально закладываешь свое приложение на async, либо "сосешь бибу" в будущем.
@@a1d4rg спасибо за информацию, но я не про это. Возьми классический подход для работы с хранимыми данными в DDD - это репозитории. Во время разработки и тестов я могу заинжектить репозиторий, который данные хранит просто в поле класса, но когда придётся прикручивать БД я буду ограничен только синхронными драйверами, потому что мой код синхронный. Соответственно изначально нужно делать приложение, которое будет работать с async/await, и не важно что там под капотом используется.
@@Ca1vema Да, это так, к сожалению. В дополнение, если писать асинхронный код, то любые вызовы синхронных библиотек придётся выносить в тред, чтобы не блокировать event loop. Но мне понравилась идея изначально делать все IO функции и методы, которые ходят в сеть или БД сразу с асинхронными сигнатурами. В том числе и интерфейсы. То есть когда пишёшь код и вызываешь await, то сразу понимаешь, что ага - это функция ходит в сеть или на диск. Возьмём ваш пример с репозиториями. Если вы пишите синхронный код, скажем на джанге, то асинхронные драйвера вам скорее всего ни к чему, и все методы репозитория будут синхронными. А если вы сразу пишете асинхронный код, то зачем делать методы репозитория синхронными, если подразумевается, что они в них вы будете ходить в сеть или на диск?
