ИИ для программиста?
Чего вы пишете? Это я сам написал раньше. Где решение? ИИ будет заменять программиста, или мы так и будем на месте топтаться? ))
Вон человек снизу пишет, что "низзя". А одно из возможных решений - громоздкая фигня, типа как я пример привёл с отслеживанием типов, которую ещё саму толком поддерживать не получится. Особенно в требовании автоматичности.
Это я сам написал раньше.
никак нет - это у вас в голове было так написано 
ИИ будет заменять программиста
нет конечно, оно будет только помогать.
А по сути в том виде, что написано, решения на уровне кода нет. А вот так как раз будет что требуется
public interface ICustomConvertible
{
void FromString(string value);
string ToString();
}
В реальности у меня свои типы, и метод класса должен их поддерживать - через перегрузку типа
Update(Type1 value)
Update(Type2 value)
И если я ввожу новый тип Type3 - должна появиться перегрузка Update с поддержкой этого типа.
ну это же полная ебанина
И это пишет человек, который дрочит на каждую новую фичу сишарп, которая экономит две фигурных скобки.
Наконец-то! Я уже раньше не раз писал, что если ИИ не может тебя послать и сказать, что у тебя полная ебанина, а будет пытаться вежливо найти решение - это плохой ИИ. Он будет вас водить за ном часами и днями, а решения не существует или оно максимально неудобное и не стоящее реализации.
Начальникам и клиентам только такое не говорите, когда они с ебаниной к вам придут, а то уволят или денег не дадут.
Ни начальники ни клиенты не навязывают мне техническую реализацию их хотелок.
А теперь давайте придумаем, как сделать так, чтобы если добавился Type3, то надо как-то дать понять всем разработчикам, что метод Update в другом классе должен получить возможность работать с этим типом.
Смотри мой код. Если твой Update возвращает void , то даже костыли не понадобятся.
Нет, не спать!
Не совсем понял ваш код. Там на каждый новый тип требование - унаследоваться от интерфейса, так? В принципе, Вася должен это откуда-то узнать. Так или иначе всё сводится к тому, что при создании нового типа из какой-то специальной группы типов Вася должен где-то прочитать, чему этот тип должен удовлетворять. Либо он должен унаследоваться от специального интерфейса, либо просто в указаниях по написанию этих специальных типов долно быть написано, где нужно добавить код после создания нового типа. В принципе, идея с интерфейсом подходит как наименее затратная и дающая какой-то автоматизм.
Далее. В классе, где я использую эти типы, вы применяете дженерик метод. А если мне надо эти типы по-разному обрабатывать? Тогда дженерик не подойдёт - нужна пачка перегруженных методов?
Вобщем, если однообразно разные типы обрабатываю - можно дженерик метод. Если разнообразно разные типы - нужна перегрузка метода.
Можно в дженерик методе проверять тип и вызывать разные блоки кода для разной обработки. Но это грязный код.
Можно примерно то же делать в обычном методе - все передаваемые параметры заворачивать в тип Object, а потом проверять реальный тип параметра. Но это ещё более грязный код.
Там на каждый новый тип требование - унаследоваться от интерфейса, так? В принципе, Вася должен это откуда-то узнать. Так или иначе всё сводится к тому, что при создании нового типа из какой-то специальной группы типов Вася должен где-то прочитать, чему этот тип должен удовлетворять. Либо он должен унаследоваться от специального интерфейса, либо просто в указаниях по написанию этих специальных типов долно быть написано, где нужно добавить код после создания нового типа. В принципе, идея с интерфейсом подходит как наименее затратная и дающая какой-то автоматизм.
Не, не то всё же. Такой подход, как я уже приводил пример, используют для создания костыльного ограничения параметра типа - для числовых типов. Все числовые типы реализуют пачку стандартных интерфейсов
struct Int32 : IComparable, IComparable<Int32>, IConvertible, IEquatable<Int32>, IFormattable
Ставишь ограничение на любой из них и получаешь, что тип должен быть числовой. Правда, любой другой тип, реализующий этот интерфейс, тоже пройдёт, а нам это не нужно. Поэтому и костыль. Всё же лучший вариант был бы, если бы при ограничении параметра типа был бы просто перечень типов, которые возможны. А этого пока нет в Шарпе. Поэтому единственный нормальный выход - пачка перегруженных методов, где разрешённые входные типы параметра явно заданы через каждую перегрузку.
Вобщем, на Шарпе эта задача оповещения до выполнения кода, что нужно добавить реализацию, не решаема. Нужны внешние инструменты, типа анализаторов кода. Интерфейс не гарантирует, что его не реализует какой-то другой тип, который не должен поддерживаться. И не гарантирует, что новый тип будет с этим интерфейсом (это только декларативно - через инструкцию для программиста).
А грязным кодом - это в дженерик методе перебирать все типы, которые реализуют интерфейс, и вызывать разный код для каждого такого типа. Если встретится тип, который нам не нужен - просто для него не будет кейса. А если который нужен, но мы о нём в данном месте ещё не знаем, что он написан, то никак. В принципе, всё то же самое, что и при просто перегруженном обычном методе, не дженерике. Только перегрузка это чистый код, а ветвление по типу в дженерике - грязный.
И вот ещё про ИИ. Хотя может это и просто тупенький анализатор последних действий. В Студии последнее время появалась фича предлагать правку кода для часто повторяющихся однотипных действий, когда с правкой можно согласиться, просто нажав таб на клавиатуре. Я правил штук 20 однотипных свойств, но среди них было где-то 3 отличающихся. Т.е. идут скажем 4 свойства одного типа, потом 3 другого, потом 13 свойств снова первого. После первых 3 свойств для четвёртого оно предложило автоправку, какая мне и была нужна. Для следующих 3 отличающихся свойств - такую же автоправку, которая мне не была нужна, поэтому правил вручную. Далее снова - 3 раза вручную, автоправка. И лишь с десятого я мог просто жать таб, и осташвиеся 10 правились на автомате... Я так думал. Понатыкал таб, на другой участок кода переключился. Смотрю спустя время - что-то код не компилируется. А оказывается где-то на 17 и 18 свойствах эта хрень мне опять предложила вариант правки для второго типа свойств - естественно неподходящий. Пришлось их вручную править. Это я потерял контекст следующей задачи, полез обратно в предыдущую, ища, где там ошибка, и ещё время на ручную правку. Т.е. с этой хренью с подсказками я время лишь потерял и лишнее отвлечение внимания. Ну и нафига оно надо с таким подходом?
Ещё раз - если это не работает на 99.99% точно и быстро, а лучше как сниппет, то смысла в этом нет. При этом за эту хрень надо ещё платить, а то и держать у себя мощную, дорогую и жрущую электричество (и выделяющую кучу тепла) видеокарту, а если это фирма, то и кластер видюх. Вред в чистом виде на фоне начальных щенячьих восторгов.
Далее. В классе, где я использую эти типы, вы применяете дженерик метод.из дженерика вызывается метод конкретного класса applyDataFromString
Без ифов и прочего колхоза.
Наверняка это какой-нибудь пэттерн, я их не могу запомнить.
Хорошо. Тогда у вас получается, что на каждую задачу во внешнем классе (Converter и других, где будет использоваться тип MyType) каждый новый созданный тип (MyType2, MyType3 и т.д.), а также все старые должны добавить поддержку этого внешнего использования в видео своего метода (ApplyDataFromString и подобных). Тогда это ещё хуже - все новые созданные типы должны отслеживать, где и как они используются. Или я не так понял?
Лучше привести расширенный пример с хотя бы двумя классами и двумя внешними классами, которые используют эти первые классы по-разному, так что одного метода
ApplyDataFromString будет недостаточно. Насколько я понимаю, для "по-разному" подойдёт перегрузка метода ApplyDataFromString, а для отслеживания добавления нового типа служит интерфейс, который должен быть реализован для каждого нового типа MyType (нужно ещё заставить разработчика это делать). Вот последнее - не совсем то. У вас сначала в классе Converter разработчик пытается заюзать новый тип MyType2, а потом лишь понимает, что у него нет нужной реализации. А мне надо, чтобы когда создал тип MyType2, было предупреждение добавить его использование в нужные классы в нужных методах.
Ну и всё равно интерфейс не то ограничение, которое нужно - как я уже сказал, он не гарантирует, что не придёт тип, который не нужен, но который тоже реализует этот интерфейс. Если бы был просто список разрешённых типов, было бы лучше. А перегрузка метода как раз такой список и даёт, хоть и весьма костыльным способом.
Интерфейс помогает в проблеме оповещения, если идти в обратном порядке - от создания использования до дописывания реализации недостающих интерфейсов. Но в вашем примере создаётся ещё больше возни с отслеживанием других вещей. А кроме того, он громоздкий.
И вот ещё про ИИ. Хотя может это и просто тупенький анализатор последних действий. В Студии последнее время появалась фича предлагать правку кода для часто повторяющихся однотипных действий, когда с правкой можно согласиться, просто нажав таб на клавиатуре. Я правил штук 20 однотипных свойств, но среди них было где-то 3 отличающихся. Т.е. идут скажем 4 свойства одного типа, потом 3 другого, потом 13 свойств снова первого. После первых 3 свойств для четвёртого оно предложило автоправку, какая мне и была нужна. Для следующих 3 отличающихся свойств - такую же автоправку, которая мне не была нужна, поэтому правил вручную. Далее снова - 3 раза вручную, автоправка. И лишь с десятого я мог просто жать таб, и осташвиеся 10 правились на автомате... Я так думал. Понатыкал таб, на другой участок кода переключился. Смотрю спустя время - что-то код не компилируется. А оказывается где-то на 17 и 18 свойствах эта хрень мне опять предложила вариант правки для второго типа свойств - естественно неподходящий. Пришлось их вручную править. Это я потерял контекст следующей задачи, полез обратно в предыдущую, ища, где там ошибка, и ещё время на ручную правку. Т.е. с этой хренью с подсказками я время лишь потерял и лишнее отвлечение внимания. Ну и нафига оно надо с таким подходом?
Ещё раз - если это не работает на 99.99% точно и быстро, а лучше как сниппет, то смысла в этом нет. При этом за эту хрень надо ещё платить, а то и держать у себя мощную, дорогую и жрущую электричество (и выделяющую кучу тепла) видеокарту, а если это фирма, то и кластер видюх. Вред в чистом виде на фоне начальных щенячьих восторгов.
Ещё добавлю, что лучший и нструмент тот, который почти не замечаешь. Болтовня с ИИ это явно не то, что нужно. Вот такие подсказки, работающие под капотом и сразу предлагающие готовое и на 100% подходящее решение по месту, даже если это небольшой сниппет - это то, что нужно. Главное теперь, чтобы это были действительно 100% или хотя бы 99,99.
А наманать архитектуру в незнакомой области с помощью ИИ, как уже было сказано, это лишь для обучения годно, когда нет особых претензий к качеству. Вы как неспециалист не можете проверить качество решения, предоставленного ИИ, но как черновик или при обучении пойдёт, когда результат не важен и его всё равно будут выбрасывать. Реальный спец в теме не удовлетвориться результатом работы ИИ, а ему проще самому накидать что-то и потом править.
Ну и тем более, если у вас всё обмазано тестами. ИИ использует этот контекст, или генерит каждый раз код, который валится на тестах? Пришли от заказчика новые требования, а они могут по 10 раз в месяц приходить в процессе доработки - ИИ чисто на словесных объяснениях может навносить правки по всему проекту где нужно, чтобы это потом и тесты сразу проходило? Если нет, то смыла в этом нет - то же самое, что и ты будешь сам всё править и добиваться прохождения тестов.
На больших проектах с кучей нюансов и контекста текущий ИИ будет постоянно лажать. Ну или придётся держать на фирме кластер со своей моделью, которую обучать на проекте месяцами и годами, и держать всё время вместе с проектом. Этакая база знаний, вики и документация в одном флаконе, только без написания самой вики и документов - пусть мол теперь разработчики просто вопросы этой ИИ модели задают и требуют у неё генерации доков налету на основании её знаний.
а больших проектах с кучей нюансов и контекста текущий ИИ будет постоянно лажать. Ну или придётся держать на фирме кластер со своей моделью, которую обучать на проекте месяцами и годами, и держать всё время вместе с проектом. Этакая база знаний, вики и документация в одном флаконе, только без написания самой вики и документов - пусть мол теперь разработчики просто вопросы этой ИИ модели задают и требуют у неё генерации доков налету на основании её знаний.
И это всё красиво звучит, а когда дойдёт до реального подобного использования, столько камней подводных и времени надо будет пройти, что 10 раз отказаться успеют от такого подхода. Бизнес не любит вкладываться в то, что МОЖЕТ БЫТЬ принесёт некоторый (лишь некоторый) доход через лет 5. Разработчиков вон отпинывают с порога, если что не так в резюме или на собесе, а с ИИ готовы возиться годами как с джунами. Ну и где тут адекватность?
Попилят бабки на игры с новыми игрушками, выхлоп будет на порядок скромнее, и отстанут наконец от загнанной лошади, зафиксировав убытки.
Блин, читаю "примеры использования ИИ из жизни" от разных комментаторов на том же Хабре или даже тут. И что вижу? "ИИ помогает мне генерить бойлерплейт код, повторяющиеся функции, закодить алгоритм, который я забыл или не знал, сгенерить класс по джейсону" - и прочая наивно-восторженная хрень. Все подобные алгоритмы давно написаны и реализованы в лучшем виде - пересказ ИИ с возможными ошибками не требуется. Скоро будет "ИИ помогает мне решать математические задачи - спрашиваю, сколько будет 500 х 125 - 493, и он отвечает - это же чудо!". Калькулятор, поисковик с копипастой и база сниппетов с небольшим анализом ввода пользователя это не ИИ. Ну или вас круто нае..али. В качестве лапши на уши людям с улицы пойдёт, но вы то типа профессионалы. Или ближе к лохам?
А вот такое вообще полная херня
- Комментарии к функциям (после пары слов часто дает разумное продолжение строки)
Это как разговаривать с человеком, который тебя постоянно перебивает. У тебя формируется мысль в голове, ты начинаешь её писать, тут ИИ тебя прерывает и предлагает свой вариант. Даже если это хороший вариант, ты должен бросить свою мысль, переключиться на мысль ИИ, проверить, что она не фуфло, забить на свою мысль. Мало того, что постоянно отвлекает и требует перключения контекстов (забудьте про пресловутое "состояние потока"), так ещё и ваши мозги атрофируют - вы без сторонней подсказки уже ни одну мысль или идею до конца не можете довести.
Вот кому реально ИИ поднасрёт - это местному многозначному (по легенде) деду. Он похоже на своих кодогенерирующих шаблонах всю капусту и нашинковал. А скоро это по идее должен делать ИИ. Ну, дед вовремя сваливает на пенсию, спрыгивая с последнего вагона уходящего поезда. )))
назад
список