beldmit | ChatGPT для программиста

Я понял, что бы я хотел вот от этого ChatGPT. Это, конечно, нифига не интеллект. Но это — хрень, которая работает без ошибок и не задалбывается от рутины.

В моём любимом OpenSSL типичная функция на 10 строчек содержательной работы содержит 10 строчек инициализации, 40 строчек проверок того, что инициализация и содержательная работа удались (функция вернула нужное значение) и ругань по этому поводу, и ещё 10 строк очистка тех ресурсов, которые я насоздавал. И форматирование, которое, впрочем, можно поручить редактору, осталось понять, как именно.

А хочу я написать эти 10 содержательных строчек, сказать "а теперь вставь все проверки и очистку как в соседних функциях" и получить на выходе код, обвешанный некоторой обвязкой. Можно ещё проверить на типовые ошибки типа buffer overflow. В общем, даже на первый взгляд производительность содержательно растёт в разы.

Flat | Top-Level Comments Only

From:

yurikhan

В некоторых языках, отличных от C, проверки, что инициализация и содержательное удались, и ругань по этому поводу, прячутся в автопроброс исключений. А очистка ресурсов — в детерминированно вызываемые деструкторы, или в менеджеры контекстов, или в финализаторы. И, казалось бы, никакой ChatGPT не нужен. Однако, тем не менее, люди находят всё новые грабли, на которые наступать.

From:

beldmit

Вот для языков с автопробросом исключений я не знаю, что делать надо, чтобы такой же прирост понятности получить

From:

livelight

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

From:

gul_kiev

Судя по описанию, вы хотите язык более высокого уровня, чем C. Или продвинутые макросы, что, впрочем, почти то же самое.

Насчёт того, что ChatGPT работает без ошибок - ну это явно преувеличение. И дебажить его код - то ещё удовольствие. Причём, ошибки вполне человеческие: например, он запутался с приоритетами тернарного оператора и присваивания.

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

Edited Date: 2022-12-27 06:40 pm (UTC)

From:

alexott

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

Я бы лучше смотрел в сторону лучших языков которые это дело автоматизируют.

From:

beldmit

Там этих макросов и так как блох на собаке...

From:

yurikhan

Вот пусть он приходит в код-ревью и комментирует: «а вот тут не забыли единицу отнять?» И дальше разработчик комментирует, почему именно в этом месте отнимание единицы не нужно, резолвит тред и мёржит код.

From:

gul_kiev

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

- Иваныч, приходи к нам обратно, нам программист нужен.
- Так у вас же обезьяна с GPT-3 есть.
- Обезьяна с GPT-3 уже тимлидом стала, нам опять программист нужен.

From:

phd_ru

На заводах? Ха, размечтались! Дворники, горничные, клоуны и нянечки.

From:

livelight

в ЖЖ первый же коммент - на эту тему :)

From:

zealer

GitHub Copilot

From:

alexott

Тоже надо проверять чтобы чепухи не написал

From:

yurikhan

Ладно бы чепухи, он ещё и лицензии нарушает.

From:

alexott

Эти системы пока на уровне очень инициативного но пока не очень опытного юниора. За которым надо глаз да глаз… особенно для mission critical code

From:

juan_gandhi

Мое такое ощущение, что тебе нужен dsl. Нет?

From:

beldmit

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

From:

yurikhan

результат каждой не-void функции должен быть проверен

[[nodiscard]] же? Можно под макросом, чтоб проверять только в одной специальной сборке, а обычным клиентам не мешать жить.

From:

beldmit

Видимо, нет, потому что ошибка - повод выдать диагностику и завершить функцию.

From:

yurikhan

Тогда [[nodiscard]] без дополнительных уточнений. Компилятор откажется компилировать вызов, чей результат немедленно отбрасывается. А если он сохраняется в неиспользуемую переменную, то дальше включаем ворнинг про неиспользуемые переменные и промотируем его до ошибки.

Это, впрочем, автоматизация проверки того, что человек не забыл написать проверку результатов, а не автоматизация написания проверки результатов как таковой.

From:

elglin

Идеологически питоновский декоратор же?

int internal_function(void*);

int generic_wrapper(void* arg, (int *func)(void*)){
    int internal_result;
    /* init */
    internal_result = (*func)(whatever_you_pass_inside_really);
    /* error handling and teardown */
    return whatever_expression_or_variable_you_return;
}

Или оно не настолько единообразно, чтобы позволить такой подход?
Или мы боремся за такты, и нам всегда надо внутреннюю функцию инлайнить, чтобы сэкономить вызов, а компилятор такое колдунство не умеет?

From:

beldmit

За такты мы не боремся. Но типичная функция - это
- проверить аргументы
- породить из них какие-то локальные объекты, при неудаче выругаться (часто контекст-специфично), перейти по goto в конец, где за собой убирают
- сделать содержательные шаги, тоже проверив, что каждый из них удался, при ошибке перейти к освобождению
- присвоить содержательный результат возвращаемой переменной
- освободить вот это вот всё (3-4-много объектов)
- вернуть результат

Единообразие кончается на этом уровне, каждая функция странная по-своему.

Edited Date: 2022-12-27 08:32 pm (UTC)

From:

elglin

Все, что мне приходит в голову - это неэффективная, забагованная и неполная (с) реализация подмножества плюсов, возможно, с STL заодно.

From:

elglin

Окей, я пошел тупо в лоб.

- проверить аргументы
То есть у нас набор аргументов задает некоторый тип, к которому положена функция-валидатор. Я не готов утверждать, что это изоморфно классу с конструктором, но до отвращения похоже.
- породить из них какие-то локальные объекты, при неудаче выругаться (часто контекст-специфично), перейти по goto в конец, где за собой убирают
Задержанная инициализация, которая, если мы не кидаемся исключениями, возвращает код ошибки, который мы можем скормить специфичной для типа функции, чтобы получить смысл. Ах, да, и убрать за собой. Хм... пара методов и деструктор.
- сделать содержательные шаги, тоже проверив, что каждый из них удался, при ошибке перейти к освобождению
Если мы продолжаем оставаться в ООП-парадигме, то это, по сути, перегруженный для каждого подкласса абстрактный метод.
- присвоить содержательный результат возвращаемой переменной
Ну это не проблема в какой угодно парадигме
- освободить вот это вот всё (3-4-много объектов)
Деструктор!
- вернуть результат
Не проблема.

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

From:

beldmit

Да, кое-что по сути деструкторы и конструкторы - но кидать исключения как-то не хочется по куче причин.

From:

elglin

Тебя никто не заставляет. У тебя есть сколько-то штатных кодов возврата и одна функция (по сути, метод класса), которая преобразует код возврата в что-то удобочитаемое. А если хочется что-то более сложное, то мы приходим либо к исключениям, либо к голанг-стайл возврату, когда у тебя из функции приезжает пара (res, err).

From:

beldmit

У меня есть коллега, сильно замороченный на side channels. Он измерял, и код с брошенным и перехваченным исключением от кода с ошибкой даёт очень чёткое отличие по времени исполнения.

From:

elglin

Так я не предлагаю исключениями кидаться, я их сам не люблю.
Очень условно, у тебя сигнатура функции
int some_func(void* args, void* error);
Далее, у тебя есть функция
char* some_func_error_helper(int retcode, void* error);
которая по коду ошибки и дополнительной информации (которая запросто может быть NULL в большинстве случаев) выдает тебе удобочитаемое сообщение.

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

From:

bowhill

Вообще-то это можно решить многомерным процессом выполнения и возврата функций. Исключения же, как и прочий ООП – во многом кривой костылинг и халтура. Хотя и не всегда.

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

From:

glav

так ведь C# примерно это и делает

From:

yurikhan

О, а ещё за форматирование. Сейчас в C++-мире, за неимением лучшего, форматирование кода поручают clang-format’у. Который ужасен настолько, что считает допустимым мешать табы с пробелами. Нейронка, которая будет смотреть на весь уже имеемый стиль кода проекта, и форматировать последний дифф под него — :take_my_money: (на самом деле нет, take my employer’s money).

From:

beldmit

Есть какой=то вимовый плагин, который позволяет класть локальные настройки в папку с исходниками. Но у меня технологический процесс в 90% процентов случая подразумевает создание этой папки из архива исходников :)

Edited Date: 2022-12-29 10:05 am (UTC)

From:

yurikhan

editorconfig, что ли? Ну это не то. Это минимальный набор: табы vs пробелы, сколько позиций в одном табе, кодировки, стиль концов строк. А кодстайл подразумевает ещё и ответы на вопросы: где разбивать длинные строки, где пробелы вокруг пунктуации, как индентить продолжение строки, можно ли или нет короткое тело метода или лямбду писать в одну строчку, вот это всё. И это всё очень хреново формализуется, а когда оно формализовано и энфорсится гит-хуками, то начинает оскорблять чувство прекрасного.