Updated: Этот пост написан до появления Copilot. Моё мнение о Copilot в отдельном посте.
В комментарии к модной типизации в Python мне обоснованно указали, что я не рассмотрел использование типов для помощи IDE. В частности, для автодополнения и подсказок.
Это действительно хороший повод для использования типов. Но в моей картине мира и в моём окружении разработчика подобные «умные» штуки находятся где-то на периферии полезности. Поэтому я о них периодически не помню.
Собственно году в 2010 я отказался от «умных» версий того же автодополнения и не жалею. В то же время, мои периодические порывы сменить Emacs на крутую современную IDE во многом вызваны как раз желанием проверить, не сделали ли наконец нормальный программистский CAD с действительно крутыми помощниками. Пока не сделали, так что сижу на Emacs :-)
Я ни разу не хейтер IDE. Просто не использую те фичи, для которых IDE ставят — не вижу от них существенного профита для себя на текущем уровне развития софта.
На сколько я знаю, моя позиция не распространена, поэтому расскажу про её логику подробнее.
Не знаю что в PSF понимают под Visionary, но ничего хорошего такое визионерство языку не несёт. Конечно, если оно вообще что-то несёт. Но не вижу смысла продавливать отдельный термин для простого спонсорства — вряд ли PSF сама выбрала такую формулировку.
Цели, задачи, потребности корпорации планетарного масштаба принципиально отличаются от целей, задач и потребностей рядовых пользователей языка. Я даже не знаю как это оспорить можно. Я уже писал на тему целей Google при разработке Go в эссе о типизации в Python.
Своим текущим состоянием: идеологией, возможностями, распространённостью Python обязан в первую очередь рядовым пользователям, не Google.
В частности, одно из очевидных противоречий — вопрос гибкости и контролируемости кода.
Постепенно пилю Тарантогу. Дело идёт не быстро: отвлекаюсь то на праздники, то на сторонние эксперименты, то на разбирательства с современными пайплайнами. Но постепенно что-то вырисовывается. Довольно странное :-)
Кстати, я завёл отдельный тег для постов про него.
Так вот, о странном и расскажу — о модели данных. Но без обоснования решений, какие обоснования в прототипе.
Спросили, использовал ли я системное мышление в реальной жизни и как оно мне помогло. А вот и не знаю, использовал ли :-)
Конечно знаю: использовал, помогло. Но чтобы ответить подробнее надо больше строк.
Есть несколько нюансов, которые усложняют ответ.
Во-первых, термины «система», «системное» перегружены значениями. Особенно в русском языке. В непрофессиональном контексте они имеют очень широкую трактовку, а профессионалы не горят желанием формализировать понятия. Особенно в рунете. В англоязычной среде дела идут лучше, но я бы не сказал, что на много.
Во-вторых, «системное мышление», «системная инженерия» — это мемплексы — наборы мемов-практик. Если я использую 2 практики из 10 — я использую мемплекс? А если 51 из 100? Кто вообще определяет входит практика в мемплекс или нет?
Использовать системную инженерию то же самое, как использовать гибкие методологии разработки. В том или ином виде их все используют, но в разных вариантах и с разным успехом. Эталонный agile вы вряд ли встретите, как и эталонную системную инженерию.
Поэтому отвечу сразу для нескольких контекстов.
Пост родился из главы итогов года, которая поясняла всплеск моей активности в блоге. Глава разрослась и была не особо нужна, поэтому вынес в отдельный текст.
Он состоит из трёх частей:
Первая часть вряд ли вам будет интересна — это скорее подводка для меня к следующим главам.