Это как java и javascript, да?

P.S. Сравнение с pornhub было бы более корректным, если бы там можно было принимать PR (porn request)

Сегодня немного пололировал с поста на реддите, где до чувака на собесе по golang докопались с вопросом о том, как реализовать перегрузку методов. Вот уж реально, когда на собесах не знают, как бы изъебнуться, чтоб... а я даже не знаю, чтобы что 🤷хуже только вопрос, почему канализационные люки круглые.

Но меня это навело на определенные мысли. Когда-то давно я начинал свой путь в айти с книги Брюса Эккеля про java. И я прям помню, как там много говорили про перегрузку методов, и как это круто. Ну я тогда ваще ничо не понимал в погромировании. Даже меньше, чем щас 😱 раз сказали, что это круто, значит круто. а. ну мы еще лабы на плюсах писали в универе с перегрузкой операторов.

С джавой у меня так и не задалось. Но код писать продолжил. И все это время писал на ЯП, которые не поддерживают перегрузку. А это кстати все популярные скриптовые языки. И даже не скриптовые (типа go, rust).

И вот щас будет наброс. Че то я не особо ощущаю какой-то дискомфорт от отсутствия перегрузки в бизнес коде. Мне кажется, это вообще самая переоцененная фича в ЯП.

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

С точки зрения типов, перегрузка это так называемы ad-hoc полиморфизм: конкретная реализация выбирается в зависимости от типов. И кажется, что это збс. Но по факту, хуйня. Ну используем мы одно и тоже слово в названии метода, и чо. Сэкономили на записи. Как это читать потом? Поди потом разберись, какая реализация тут отработала.

В языках без перегрузки у нас параметрический полимфорфизм, т.е. мы принимаем пачку типов на вход, на выходе также пачка типов, а реализация уже там разбирается, чо к чему. На первый взгляд кажется, что такой подход это больший пиздейшн. Но у нас же есть тулинг. Например, typescript поддерживает перегрузку функций. В phpstan есть conditional types. Да даже в ебучем mypy есть такое. И в целом, будто это норм. Когда читаем код, всегда прыгаем в конкретную реализацию. Хочешь другую реализацию для конктреного типа, ну напиши отдельный метод. Не еби мозги себе и другим 😡

Карочи, считаю, что собеседующий долбаеб. Желаю, чтоб его самого на собесе спросили, как реализовать абстрактные классы в го.

Но может собеседующий прав, и долбаеб я? Может реально все мечтают о перегрузке?🤔 вы скажите, кароч

Приношу заранее извинения за пост о ллм. Сам от этого устал🫠но разок-то можно🙏

По моим ощущениям, большиство разработчиков используют агентов в TUI. Потому что почти каждый из них предоставляет TUI версию. И это типа универсально. Я же продал очко душу ide от jetbrains, поэтому сразу искал решение - плагин. Поэтому когда-то давно я выбрал cline, ибо у них был адекватный плагин.

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

3го дня все ide от jetbrains обновились на мажорную версию. Из-за этого cline плагин перестал работать. И тут я понял, что время TUI версии пришло. И охерел от того, что там все не то и не так.

Прежде всего стоит отметить, что я использую ллм в режиме "ты конечно генерируй, но я блэт все чекаю". Потому что я тот еще контрол фрик. В ide это видно как diff после каждого изменения. Пока я не заапрувлю diff, дальше ничо не двигается. Обычно изменения ллм делает разумными чанками, и это все реально просмотреть (ну кроме тестов, там пиздейшн портянка обычно).

Есть ли что-то похожее в Cline TUI? вообще нет! все, что там можно сделать - это поставить аппрув на каждый tool call. но это просто ужас как заебывает. Потому что, сюрприз-сюрприз, под капотом агент делает десятки таких вызовов даже для простых задач. И, главное, он не показывает дифф🤷короче это вообще не то. в TUI ты должен просто проверять в конце все.

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

Другой момент, заключается в том, что плагин "видит" все ошибки ide. То есть фактически он использует стат анализатор, который уже есть в ide (а он то крутой). TUI агенты обычно предлагают еще lsp прикрутить рядом. В целом можно, но зачем? В ide у меня не только стат анализ для основного языка, но и для всего сопутствующего. Например, если ide показывает ошибку в sql, агент это видит. По непродтвержденной информации, даже ошибки quality tools, которые отдельно запускаются, видны.

Короче, мне по кайфу!😊

А в чем же минусы? чем приходится платить?

ну во-первых тем, что я не могу обновить IDE, пока плагин не подтянется. во-вторых, расширяемостью. Все TUI решения обычно идут с системой собственных плагинов. А вот в случае плагина для ide, такой возможности, увы, нет. Приходится довольствоваться тем, что из коробки.

К сожалению похожих решений с другими плагинами я не нашел. Попробовал kilocode - ну это просто ужас. Он тупо виснет посреди простого таска. Навайбколили там нормально.

TUI open code что-то близкое позволил сделать. Там можно настроить пермишны на ask при каждом редактировании файла и видеть диффы. Но конечно же ни о каком редактировании речи нет. Ты можешь словами рассказать, че тебе не понравилось. И да, надо подрубать lsp, если хочешь больше гарантий по качеству кода (хотя в работе не проверял). Но хоть что-то похожее на альтернативу.

Пока что откатил версию IDE до предыдущей 🤷 но если cline перестанут поддерживать плагин, будет беда

Никак не можете найти в себе силы поменять работу? Просто выполните этот sql запрос, и за вами скоро придут

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

Вот сравните

это

const buttonText = 
   action === 'manage' && selectedProductId === purchasedPlan?.subscriptionProduct
     ? strings.manage_button
     : action === 'downgrade'
       ? strings.downgrade_button
       : strings.upgrade_button;

или это

let buttonText;  

if (action === 'manage' && selectedProductId === purchasedPlan?.subscriptionProduct) {   
  buttonText = strings.manage_button; 
} else if (action === 'downgrade') {   
  buttonText = strings.downgrade_button; 
} else {
  buttonText = strings.upgrade_button; }

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

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

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

Кроме того, цепочки тернарников работают по разному в разных ЯП. И если в js цепочки правоассоциативные (если условие false, то весь хвост - это новое выражение), то в той же пыхе до версии 8 они были левоассоциативные. А щас так вообще вложенные тернарники без скобок запрещены. Может быть это меня и травмировало🤔

А в питоне смарите какая красота 😀

score = 85

grade = "A" if score >= 90 else "B" if score >= 80 else "C"
print(grade) # Хуй знает че тут будет

че думаете? лучше старый проверенный if - else или тернарники зато const?

Кароче, в комментах пришли к выводу, что я лох, и надо было добавить switch - case в опросник, ибо это единственный норм варик (с чем не поспорить). Но что ж фронтендщики вообще его не используют?🤔

(получается, что в итоге лох не я, а фронтендщики)

Внатуре

Херасе! Скорости закрытия тикета на отъебись у jetbrains даже дед из phpunit может позавидовать!⚡

Не вижу ничего смешного. Он предложил создавать PRы с помощью AI. Но он не обещал, что будет их мержить.

И потом сам бы не нашел никогда

А кстати, зачем нам в век ллм вообще изучать DDD. Ведь весь код пишет агент. Не пофиг ли, как там оно будет в итоге с DDD или без DDD?

Последние месяца 3-4 из каждого утюга говорят про Spec-Driven-Development (SDD). Появляются тулзы типы OpenSpec, SpecKit и миллионов аналогов. Вариации подхода разные. Но суть идеи в том, чтоб хорошенько пошевелить мозгулькой на этапе планирования, родить тонну md файлов, а затем скормить их агенту, и спокойно идти пить кофеек, пока клод перемалывает ваши спеки в рабочий код.

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

Зачем же нам тогда DDD?🤔

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

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

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

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

И в этом смысле я не понимаю, чем писать спеку на обычном языке лучше, чем, например, нагенерить ValueObject'ов. Разве ValueObject - это не часть спеки? И это при том, что IDE еще и помогают писать их быстро. А в конструкторе можно явно защитить необходимые инварианты. Но нет, давайте писать это словами. Тем более, что уже есть примеры того, когда код является спецификацией (OpenAPI, protobuf).

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

Короче говоря, возникает ощущение, что отдельные тактические приемы DDD могут использоваться в качестве спецификации. Даже с учетом того, что сама спека в SDD генерится агентами с помощью скиллов и тулзов, шоб оператор ллм лишних букав на клавиатуре не дай бох не нажал, мы ведь также можем попросить ллм вместо текста спеки генерить конкретные классы с полями. Зачем нам тогда вообще этот промежуточный этап в виде текста?

Ладно-ладно. Текст все же нужен. Иначе это будет сплошная реализация. Но пусть был бы текст + код. И в тексте уже ссылки на конкретные объекты из кода.

Однако в тулинге я не вижу движения в этом направлении🤷так шо может все это херня и мои влажные фантазии. А может сама по себе сложность DDD мешает такому случиться. Или может md файлы все же гораздо удобнее, как артефакт.

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

Короче, я все же надеюсь, что SDD + DDD выстрелит. Мне это кажется отличным компромиссынм вариантом между полностью агентской разработкой и мануальным кодингом.