[prog.flame] На тему угрозы программистам со стороны ИИ

Увидел в последнее время несколько обсуждений того, грозит ли страшными последствиями для программистов развитие ИИ (на примерах Copilot и ChatGPT).

Удивился тому, что это всерьез обсуждают разработчики, которые без умных IDE даже программу в несколько тысяч строк написать не могут. А ведь для тех, кто начинал программировать в 1980-х (не говоря уже про 1970-е и более ранние времена), какая-нибудь современная IDEA или Visual Studio с подсказками и автоматическим рефакторингом выглядела бы не менее фантастично, чем Copilot сейчас.

Ничего умного на сей счет не скажу. Но мне кажется, что влияние ИИ на программирование будет сродни влиянию силикона на индустрию красоты и пластическую хирургию ;)

Так что если кто-то захочет порассуждать о том, угрожает ли ИИ программистам, то пусть заодно порассуждает о том, угрожает ли силикон естественной красоте.

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

Достаточно посмотреть на примеры уважаемых и востребованных в прошлом профессий. Типа кузнецов, скорняков, сапожников, гончаров и т.д., и т.п. Почему программистам должно повезти больше, чем, например, художникам и фотографам?

Так что да, со временем работы для программистов будет меньше. И те, программисты, которые останутся, будут работать иначе. Используя несколько другие инструменты. Тот же самый ИИ.

А вот когда это произойдет -- хз.

По нынешним временам третья мировая с гарантированным уничтожением всего живого может случиться раньше. Ну или глобальный кризис, сравнимый по масштабам с катастрофой бронзового века и падением Римской империи со скатыванием в средневековье. Новейшая история показывает, что внезапно может случиться такая жопа, что конкуренция со стороны ИИ выглядит как боязнь насморка во время эпидемии легочной чумы.

[prog.c++] Написал функцию с десятью(!) аргументами...

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

Вот как это выглядит:

Мое чувство прекрасного ущемлено и требует сатисфакции, но ничего лучше не придумывается :(

Проблема в том, что все аргументы обязательные. И когда они передаются в функцию вот так, то компилятор бьет по рукам когда что-то не указано (или указано что-то лишнее). А это полезно, поскольку код все еще активно меняется и параметров становится то больше, то меньше.

Была мысль посмотреть в сторону builder pattern. Но в C++ этот самый builder будет многословным. Плюс к тому придется делать проверки а все ли обязательные параметры заданы (а они все обязательные). Что негативно скажется на объеме builder-а. Посему не вариант.

Видимо, следует объединить несколько аргументов в разные структуры. Скажем, argv_0, python_log_collector, py_config и python_lib_path в одну, а ***_arena, params, shutdown_notificator и ***_interaction_points в другую. Но все равно это будет вести к распуханию вспомогательного кода, причем особой пользы от этого вспомогательного кода на данный момент не будет. Разве что это окажется задел на перспективу.

В общем к чему я это: рекомендации лучших собаководов о том, какой код clean, а какой нет, -- это, конечно, хорошо. Пока не сталкиваешься с суровой реальностью ;) В которой не знаешь как сделать лучше, а тратить время на эстетические изыски не вариант.

[prog.python.wtf] Понадобилось мне давеча разобраться с Python-овским io... И как-то оно что-то неожиданно непонятно. Вот совсем

В C++ приложение встраивается Python чтобы исполнять Python-вский скрипт прямо внутри приложения. Потребовалось сделать так, чтобы все, что Python-овский скрипт печатает в sys.stdout, отправлялось в C++ную часть.

Стал разбираться с Python-овским io.

Несколько раз проштудировал описание io в стандартной документации.

Мало что понял.

Что удивило. Т.к. пока читаешь, то вроде бы и буквы все понятные, и в слова понятные они складываются. А вот что к чему и почему... Все никак.

Гуглил, читал Stackoverflow, много думал :)

Но просветление не приходило.

Даже в исходники CPython заглянул, чтобы понять, как же вся эта кухня с IOBase, RawIOBase, BufferedIOBase и TextIOBase работает.

В общем, пришел к выводу, что мне нужен стандартный io.TextIOWrapper. В конструктор ему передается экземпляр стандартного io.BufferedWriter. А уже в конструктор io.BufferedWriter в качестве параметра raw передается экземпляр моего класса, наследника io.RawIOBase. Что-то вроде:

[prog.c++.flame^humour] Как хорошо, что я IDE не пользуюсь и не знаю, что такое бывает ;)

Подсмотренно в ТГ-чатике:

Ссылка: тыц, там же можно отследить и весь контекст.

Таки да, давным-давно работаю в gVim-е без плагинов. Вроде как полет все еще нормальный. Но я и не знаю, что именно упустил :)

Думаю, что мне удается так долго обходиться gVim-ом просто потому, что пользуюсь, в основном, C++. Иногда чистым Си, иногда Ruby. Для всех этих языков польза от IDE не сказать, чтобы большая.

А вот если бы программировал на C#, Kotlin и, особенно, на Java, то вряд ли бы без IDE обошелся.

На счет Rust-а не знаю. Язык более строгий и легче поддается парсингу со стороны IDE, если я все правильно понимаю, так что IDE может быть удобна в случае Rust-а. Но, как я слышал, многие пользуются Rust-ом и без помощи IDE.

[life.cinema] Очередной кинообзор (2022/11)

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

Фильмы

Смотрите, как они бегут (See How They Run, 2022). Если черные комедии могут быть ироничными, то это вот тот самый случай. Кино, конечно же, специфическое. Но мне зашло, посмотрел с большим удовольствием.

В эфире (On the Line, 2022). Мне понравилось. Но только смотреть нужно до самого конца, каким бы невероятным не казалось повествование в середине.

Битва при Логнтане (Danger Close: The Battle of Long Tan, 2019). Средней руки военный фильм. Хотя на фоне современного киношлака выглядит вполне себе достойно. Доколупаться можно было бы до батальных сцен, т.к. меня a) не сильно впечатлили спецэффекты и b) атакующих вьетнамцев не стоило выставлять такими уж картинно несущимися навстречу неминуемой смерти идиотами.

Очень плохие парни (Big Bad Wolves, 2013). Не зашло мне это кино. В нем рассказывается о таких страшных вещах, в которые даже вдумываться не хочется, но снято это все как комедия. Черным комедиям есть место, но здесь, как по мне, грань разумного была оставлена далеко позади.

Покерфейс (Poker Face, 2022). Так себе кино. Как говорится, замах на рубль, удар на копейку: вроде бы завязка была многообещающей, а развязка оказалась вообще никакой.

Корабль в Пусан (Neukdaesanyang, 2022). Прежде всего это кино не имеет никакого отношения к отличному "Поезд в Пусан" с зомби. Здесь другие монстры, не зомби. Мог бы стать нормальным представителем жанра "кишки, кровь, расп*дорасило", если бы кровь в этом "кино" была бы похожа на кровь, а не на гранатовый сок.

Шесть минут до получночи (Six Minutes to Midnight, 2020). Картинка годная, содержание -- говно.

Наблюдающий (Watcher, 2022). Унылое и скучное говно.

Сериалы

Миссис Уилсон (Mrs Wilson, 2018). В кино рассказана очень интересная история, за которой хочется следить. Поэтому мне фильм зашел настолько, что даже не хочется обсуждать все остальное.

Игра на выживание (второй сезон). Если первый сезон понравился, то можно глянуть и второй. Есть шансы не разочароваться. Но мизерные. Я разочаровался. Если же первый сезон не понравился, то второй можно и не начинать.

[prog.c++] Погрузился в изучение Dear ImGui и вот что любопытно...

Возникла необходимость поверхностно освоить необычный (для меня лично) оконный фреймворк Dear ImGUI.

Очень прикольная штука.

Я в свое время имел опыт работы с GUI. Причем начиная от MS-DOS, в котором мы сами рисовали подобие Windows-овских окошек/менюшек/кнопочек/пр. в графическом режиме посредством Borland-овской BGI. И заканчивая работой с Qt и MFC, по дороге пройдя через стадию прямой работы с API MS-Windows и IBM OS/2 Presentation Manager, и даже делая какие-то свои библиотеки-обертки вокруг этих самых API. Кроме Qt и MFC доводилось знакомиться и с wxWidgets (тогда еще wxWindows), и с FOX Toolkit, и с FLTK (и даже со Swing-ом в Java). В общем, какое-то представление о том, как делается "традиционный" GUI, у меня когда-то было.

Но вот Dear ImGui, который реализует идею Immediate Mode GUI (акронимом чего и является IMGUI), -- это какой-то совсем другой зверь, диковинный и непривычный.

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

Однако, на написание поста толкнуло совсем другое впечатление.

Вроде как Dear ImGui вообще рисует все само: менюшки, окошки с заголовками и без, кнопочки, выпадающие списки и пр., и пр. -- это же все не имеет никакого отношения к нативным контролам конкретной ОС или оконного окружения.

И, что удивительно, пользователей Dear ImGui, судя по их скриншотам, коих предоставлено уже немало, эта "ненативность" внешнего вида не волнует от слова совсем.

Удивительно это для меня потому, что доводилось читать немало споров про выбор GUI-фреймворка для кроссплатформенных приложений и одним из требований (или одной из претензий) к существующим инструментам было то, что рисуемые GUI-фреймворком контролы визуально отличаются от нативных (т.е. родных для ОС).

Типа, вот Qt -- да, хороший фреймворк, но на такой-то платформе его кнопки отличаются от родных. И т.д., и т.п.

Я таких претензий никогда особо не понимал. Как по мне, так GUI-интерфейс должен быть продуманным и удобно заточенным под задачу. А само GUI-приложение должно быть отзывчивым. И если это так, что внешний вид контролов в GUI-приложении -- это уже мелочь.

И вот погружаясь в Dear ImGui с удивлением обнаруживаю, что есть люди, которые разделяют мои взгляды. Они просто берут Dear ImGui и решают свои насущные задачи. Не сильно беспокоясь о том, что сделанная в Dear ImGui программа отличается по внешнему виду от сделанной в wxWidgets или Qt.

Таки здравый смысл еще где-то остался. Что не может не радовать.

[prog] Что-то странное: появилось желание сделать реализацию MQTT v5 :)

В текущем проекте начала маячить перспектива затаскивания в разработку MQTT. Дабы освежить в памяти что это такое прочел по диагонали спецификацию по пятой версии MQTT. И в процессе чтения поймал себя на необычном для последних лет впечатлении...

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

Так что если мне задать вопрос "а над какой задачей было бы интересно поработать?", то я зависну на некоторое время и вряд ли смогу дать вменяемый ответ. А невменяемый мог бы звучать как "ни над какой" ;)

Но вот просматривая спецификацию MQTT подумал, что как раз сделать свою реализацию MQTT v5 было бы интересно. Причем как клиентскую, так и серверную.

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

Еще подумалось вот что: в конце 2016-го и начале 2017-ого мы в "СтифСтрим" решали какой еще открытый продукт родить, чтобы иметь в своем портфолио что-то кроме SObjectizer-а. И основных идей было две: либо какой-то MQ-шный брокер, либо встраиваемый в C++ приложения HTTP-сервер.

И мне сейчас кажется, что если бы спецификация MQTT v5 была доступна уже тогда, то, возможно, RESTinio бы и не случилось бы. Мог бы быть какой-то MQ-шный брокер на C++ на базе SObjectizer-а. Но тогда MQTT v5 еще не было, а делать свой брокер намного более простого MQTT v3 на фоне уже существовавших тогда альтернатив не выглядело перспективной затеей.

PS. Какой смысл у этой заметки? Да никакого, просто решил поделиться давно забытым ощущением когда возникает желание что-то запрограммировать. Ибо в последние годы программировать приходится без особого желания. Так-то понятно, что еще одна реализация MQTT вряд ли кому-то нужда. Хотя я и уверен в том, что в существующих реализациях есть, как минимум, один фатальный недостаток... :)))