Эссе о разработке игр, мышлении и книгах

Пара слов о GitHub Сopilot

DALL-E: "Vrubel style painting of pair programming Robot + Human. An robot is writing code, a human is reviewing code".

DALL-E: "Vrubel style painting of pair programming Robot + Human. An robot is writing code, a human is reviewing code".

Последние несколько недель использовал GitHub Сopilot, благо для Emacs есть плагин. Поделюсь впечатлениями.

Для справки, я уже лет 15 осознанно не использовал умное автодополнение. Всё моё автодополнение — это DynamicAbbreviations, по сути — дополнение написанного слова на основе словаря из открытых исходников.

Причина отказа такая: используя «умное» автодополнение (например, подсказку аттрибутов/методов объекта) перестаёшь понимать проект. Начинаешь на автомате брать предлагаемые варианты методов/переменных, не разбираясь что они конкретно делают и есть ли альтернатинвые варианты.

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

С Copilot я, похоже, вернуcь к умному автодополнению, в его более правильном варианте.

Итак, давайте посмотрим чего умеет и не умеет Copilot.

Далее

Feature Programming

Эссе по итогам нырка в Deep Learning, но не о DL и даже не совсем о Machine Learning, а о новой парадигме программирования, которая рождается из него.

Собственно, нейронные сети я смотрел не потому, что интересуюсь именно ими, а потому что они сейчас демонстрируют наибольший прогресс и характерные черты этой парадигмы.

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

Оговорка раз: я определённо не эксперт в машинном обучении. Эссе в большей степени отражает мой опыт и картину мира, нежели знания и понимание ML и DL.

Оговорка два: термины «признак», «feature» будут использоваться достаточно вольно.

Далее

Минидрама: Python, C, Rust, криптография и Gentoo

Новость с деталями.

  1. Часть кода популярной Python криптобиблиотеки переписали на Rust.
  2. Сломалось CI у кучи людей.
  3. Дополнительно сломалось чегой-то в пакетном менеджере Gentoo.
  4. Изменения незаметили, так как… ну кто следит за криптолибами? Их просто ставят.
  5. Все думали, что cryptography следует semantic versioning, оказалось, что нет :-D

В итоге:

  • Разработчики сказали, что откатывать Rust взад не будут — это более кошерный язык для криптографии, чем C.
  • Gentoo оказалась не так уж и поломана — зависимость оказалась ненужной, но осадочек остался.
  • Люди с CI поплакали, но донастроили что надо было донастроить, и вернулись к своим делам.

Соль драмы в том, Gentoo поддерживает часть архитектур, которые не умеют в Rust. Одновременно Gentoo сильно зависит от Python. В этот раз пуля пролетела мимо, но возникли опасения, что Rust будет всё активнее использоваться к инфраструктуре Python. и в какой-то момент станет необходимой зависимостью. Что в этом случае случится с поддержкой минорных архитектур не ясно.

Далее

Google стал Visionary Sponsor для Python

Новость в блоге PSF.

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

Цели, задачи, потребности корпорации планетарного масштаба принципиально отличаются от целей, задач и потребностей рядовых пользователей языка. Я даже не знаю как это оспорить можно. Я уже писал на тему целей Google при разработке Go в эссе о типизации в Python.

Своим текущим состоянием: идеологией, возможностями, распространённостью Python обязан в первую очередь рядовым пользователям, не Google.

В частности, одно из очевидных противоречий — вопрос гибкости и контролируемости кода.

Далее

Экзокортекс 3.5

Источник: [Pixel Key](https://www.pinterest.com.au/pin/861946816168401342/)

Источник: Pixel Key

Продолжаю думать о доработке своего экзокортекса. Я уже описывал его текущее состояние. Сейчас попробую прикинуть, как должен выглядеть правильный экзокортекс в 20-ых годах XXI века.

Для начала отметим несколько банальностей:

  • Экзокортекс — это инструменты для работы именно с информацией. Протез руки или, там, автомобиль — это экзоскелет.
  • Вид экзокортекса определяется компромиссом между потребностями человека и возможностями технологий.

Долгое время — тысячелетия — роль экзокортекса выполняли всевозможные библиотеки, картотеки, архивы. Нельзя сказать, что они были неэффективным и не развивались. Уверен, история библиотечного и архивного дела вещь интересная.

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

Тем ярче видны изменения, которые приносит увеличение доступности технологий экзокортекса. Достаточно посмотреть на влияние книгопечатания на становление науки.

Ситуацию изменило появление персонального компьютера. Автоматизация вычислений небывало удешевила обработку информации, последствия чего мы ещё не осознаём в полной мере, так как вычислительная техника продолжает развиваться быстрее, чем мы осваиваем новые возможности.

Поэтому, первое, что слудует отметить: экзокортекс будущего — это софт для управления личной информацией.

Термин «управление» я выбрал специально. Информацию необходимо не только хранить, но и передавать, редактировать, искать — нам приходится организовывать полный жизненный цикл информации, то есть управлять ей.

Под личной информацией я имею в виду информацию, с которой человек уже взаимодействал и счёл её полезной, или его софт счёл её полезной. Управлять всей информацией, само-собой, в обозримом будущем вряд ли получится.

Далее