Комментарии 274
Новые фреймворки появляются и умирают, а стандарты остаются. Всё держится на стандартах, а не на фреймворках. Учить в первую очередь надо стандарты.
В целом согласен. Это повысит вашу ценность. Но вот если вы будете дом строить по проекту - вам важно чтобы работники умели класть газобетон и крышу делать или химию знали как этот газобетон был получен? Я к тому что программирование часто это прикладная штука и там важно что ты можешь дать бизнесу в ближайшее время а не какие ты стандарты знаешь. Грустно но как есть.
Да, вот с этим с сожалением соглашусь. К сожалению стандартов нынче никто не уважает. Вмё надо дешевле и быстрее по цене того сука на котором сидишь
Так вся ваша статья о том, что люди, пользуясь готовыми сложными инструментами, зачастую не понимает как это работает под капотом. И возвращаясь к низкоуровневым инструментами (curl), надо разобраться с базой. А там - можно на любом языке писать то, что нужно здесь и сейчас.
Базовые вещи гораздо проще интегрируются в любой пайплайн
Немного не соглашусь с аналогией: стандарты и протоколы - это условно "чтобы построить стену, нужно брать блоки одинакового размера и материала и складывать их в шахатном порядке, скрепляя между собой таким-то цементом, после чего ждать столько-то времени перед завершением". Если это делать все вручную, то это разработка без фреймворка. Если используются уже готовые блоки стен, то это уже использование фреймворка.
Мне кажется, что вы немного ошиблись. Если вам будут строить дом, то вам наверняка бы хотелось, чтобы работники строили по строительным стандартам и нормам? Так-то желающих поработать на стройке хватает. А стандарты на материалы должны соблюдать на заводе материалов. Стандарты надо учитывать по своей сфере.
Учиться надо в первую очередь здравому смыслу. Стандарты депрекейтят, устаревают под современные реалии аппаратуры. Поэтому опираться полностью на стандарты я бы не рекомендовал. К тому же сегодня веб-стандарты контролирует в большей мере Google, которые делают такие стандарты, которые нужны в первую очередь им.
Много вакансий видели где стандарты перечислены?
Казалось бы, при чем тут ChatGPT…
Да, как-то автор резковато телепортируется в колею ChatGPT.
Но это же слишком много Boilerplate! Да, но писать-то буду не я.
Да, а читать и дебажить - кто? Будет классный, быстрый проект на bash, curl, make, чистом Typescript, быстром Rust, асинхронном Go, который на 20 - 40 % (сколько там сейчас ChatGPT генерит кодобреда даже на простых отточенных промтах) состоит не просто из неправильного, а из очень правдоподобного, красиво отформатированного хер-пойми-насколько-неправильного кода.
Не сомневаюсь, ChatGPT и его будущие поколения - мегамощное подспорье программисту, но прямо сейчас перепрыгивать с фреймворков на GPT-бойлерплейт, заведомо превышающий когнитивный потолок разработчика - это просто из двустволки в голову.
Не понимаю о чём вы жалуетесь.
Возьмём пример:
<div class="row">
<div class="col md-6">
<label for="firstName">Your first name</label>
<input type="text" id="firstName" class="input large" @change="handleChange($event, 'firstName') v-model="formData.firstName">
</div>
</div>Загружаете такой код в GPT, вместе со списком полей, и говорите, чтобы он для всех этих 20 полей написал код. Он очень шустренько вам всё это наклепает.
Вы так говорите, как будто я предлагаю GPT писать за меня код. Нет. Я ему предлагаю за меня этот код строчить. Тут видна чёткая последовательность действий. Пусть пишет. Получается у него очень хорошо.
Стандартные, базовые вопросы, вместо передачи какому-то там фреймворку для валидации можно отдать GPT.
Как-то вы резко снижаете уровень доверия к ChatGPT. Разве план был не в уходе от Nest, React, Bootstrap etc?
Но при всём при том, я ему не даю выдумывать за меня. Выдумываю я. Я ему говорю, что мне надо обработать этот массив так-то и так то, а ещё дописать вот то-то, а тут ввертеть хашмэп.
Сама ГПТшка запросто вам составит алгоритм сложностью О(n^n*m^m). Ей надо правильно ставить задачи. Я всё ещё пишу код. Я просто его не набираю.
Ну, выглядит достаточно резонно. Если удастся "вести" GPT по архитектурно-алгоритмической ниточке, скидывая на него весь бойлерплейт, то было бы весьма недурно.
Если еще и удастся нарезать приложение на фрагменты с низким сцеплением, чтобы можно было загружать в GPT весь контекст при внесении изменений, то будет вообще пушка...
Но - вопросы к качеству генерируемого кода всё-таки остаются, надеюсь, время на контроль не-бредовости существенно ниже времени написания того же с нуля.
Если удастся "вести" GPT по архитектурно-алгоритмической ниточке, скидывая на него весь бойлерплейт, то было бы весьма недурно.
Весь пока не получается. Но приличная часть уже спихивается :)
Но — вопросы к качеству генерируемого кода всё-таки остаются, надеюсь, время на контроль не-бредовости существенно ниже времени написания того же с нуля.
Зависит от того что вы хотите генерировать. Какие-нибудь парсеры-мэпперы например генерируются очень даже неплохо. Вплоть до того что скармливаешь ему спек и получаешь готовый на 99% парсер.
То, что люди обычно не понимают о ГПТшке, так это идея о том, что эта штука умеет думать. Она не умеет. Она умеет делать виртуозные вещи с текстовой информацией. ГПТ надо использовать как инструмент. Но думать надо программисту.
Для того, чтобы доказать, что ГПТшка не умеет думать, достаточно просто продолжать задавать ей задания, без того, чтобы не устанавливать ей задачу. Запишите в начале чата "Ты - программа переводчик. Ты не должна отвечать на вопросы, а только выдавать перевод. Переводи". Через 5-10 сообщений ГПТшка уже будет сидеть и общаться сама с собой как попугай.
Да и сама по себе она не сядет и не напишет "Слушай, а ты кто вообще? Мне было бы интересно тебя узнать". Так же как она не скажет "Ты знаешь, тот код, который мы написали месяц назад - я думаю, что что-то надо менять."
Программист останется программистом. А ГПТшка просто уменьшает пробег на клавиатуре.
Зачем вы генерируете руками (или ChatGPT) кучу лапши для HTML-форм, когда можно описать форму, и фреймворк сам сгенерирует и HTML, и правильность заполнения проверит?
Представьте, что завтра надо что-то будет поменять во всех формах. Вот радости будет, разбираться в куче автосгенерированного кода.
Сгенерированного кода в репозитории быть не должно. Разве что генератор и конфиг для него.
Вы же понимаете что это, как и вся статья, призывает писать write-only код? Куча копипаста, куча велосипедов, огромное количество уникального кода и никакой абстракции? В итоге это будет абсолютно неподдерживаямпя лапша, не более того. Если вам надо поменять что-то для одного инпута — это отлично. Для всех? N часов(а позже и дней) обезьяней работы.
Спасибо, автор! Полностью Вас поддерживаю. Сам пропагандирую LaTeX вместо Ворда и аналогов, PlantUML вместо спираченной Rational Rose, StarUML и подобного.
Кстати, Латех. Самый быстрый и простой способ создавать PDF файлы программно. Хотя, комплекс программ LaTeX не маленький. Но мне по большей части хватает MD
Маркдаун хорош для своих целей, но я не рассматриваю Маркдаун как альтернативу Латеха. Маркдаун интерпретируется в html код, а Латех, как и Ворд, создает документ с заданными настройками верстки.
Полный дистрибутив Латеха весит 8 Гб + IDE.
Маркдаун явно гораздо проще и легче. Как вы там писали? "Да, полностью не заменит, но 97% случаев покрывает".
Тяжелые времена порождают сильных программистов.
Сильные программисты создают фреймворки.
Фреймворки порождают слабых программистов.
Слабые программисты порождают тяжелые времена.
Раньше программистов не было, а были кодеры и алгоритмисты. Теперь добавляется копилот и GPT, резонно называть такой синтез новой специальностью.
Мне надо было написать сервер, взамен старому на Next.js. Мы переезжали из Vercel на AWS. Старый сервер безостановочно падал.
Вот что бывает, когда люди не умеют в деплой.
Если падает сайт на Next.js - нужно просто залогировать и отладить ошибки? - нет, на фреймворке нормально написать не смогли - давайте перепишем без фреймворка.
Подход людей, которые не могут сделать когнитивное усилие и разобраться в технологии.
То же самое и с деплоем - Next.js можно деплоить не только на Vercel - но и на любом vps. Просто для этого нужно часик погуглить на английском языке и ещё пару часов руками поковыряться - всё делается за 1 рабочий день.
Не разобраться в технологии -> сказать, что технология плохая -> переписать всё на голом языке, коряво и без всей необходимой функциональности - подход джуна, который считает себя сеньёром.
P.S. если нужна консультация по деплою сайта на Next.js - пишите в личку.
Вы видать живёте в России и работаете программистом. Никогда не приходилось сталкиваться с кодом из Индии. Я не рассист и не люблю стереотипы, но вы не представляете, какой ужас может написать высококвалифицированная группа программистов. Оно не то что на VPS не запускается. Я его даже в докер положить не смог.
Я не видел ваш код из Индии, но видел код, написанный сумрачным гением из России без использования фреймворков на чистом PHP. Он в принципе работать стабильно, не сыпля сотнями варнингов, не мог, а исправить хоть одну ошибку, не разобрав его целиком, было невозможно, так как все внутри взаимосвязано и перепутано.
Так что не только в Индии пишут такой код.
О! Кажется, кто-то пытался мой код сопровождать )))
Просто я - не программист, но когда поставили задачу взять данные из Парсека и Болида (это такие СКУД), загрузить их в 1С:ЗУП, сопоставив с реальными сотрудниками, а потом данные из 1С загрузить в надстройку над R-Keeper, которая бы определяла по пропуску, положено ли питание в данную смену данному сотруднику, да ещё "изолированный" демон, читающий пропуска с ридера и отображающий на монитор "текущий статус" (сколько каких "питаний" осталось)... почти всё было написано на PHP (т.к. у меня был небольшой опыт коммуникации с pgsql и 1С), а "демона" писал на Delphi (просто не хотелось разбираться, как коммуницировать с RS-232, а "на Паскале" я в юности с модемом много игрался), предполагалось, что это будет POC, а разработку "боевой версии" отдадут нормальным программистам, но по состоянию на 5 лет после моего увольнения, оно продолжало эксплуатироваться... надеюсь, этот кошмар всё-таки заменили чем-то более пристойным.
Я работаю в немецкой компании с группой чуваков из Индии над поддержкой нескольких микросервисов, которым всего то пару лет, но это уже неподдерживаемое говно. Но прикол в том, что бОльшую часть этого говна написал таки русский - а потом свалил в другую контору на зарплату еще побольше. Так что нет, дело только в квалификации, национальность не при чём.
Подход людей, которые не могут сделать когнитивное усилие и разобраться в технологии.
Циничный тон неуместен. Да, некоторые люди "не могут сделать когнитивное усилие и разобраться в технологии". Но не потому, что они глупы от природы, а потому, что у них хватает других забот, а ментальная энергия не бесконечна ни у кого. Если ChatGPT может за минуту может переписать код так, чтобы необходимость "разбираться в технологии" отпала - этим будут пользоваться.
Представляю как врач скажет - та эти ваши анатомии и все вот это - это ментально сложно. Вон chatGPT может же диагноз поставить и рецепт намутить...
Только kpi у врача и разраба разные.
Разрабу ещё потом будет сложно объяснить, почему он за 300к сидит и разбирается в технологии, в то время как Васян за 150к выдаёт решения.
Всё ситуативно, и на сферической ситуации в вакууме не имеет смысла дискутировать, какой из подходов тут правильнее. Нужно больше контекста придумать.
А не надо проводить неадекватные аналогии. Программист пишет код, а ChatGPT - это кодогенератор. Его использование вполне полезно. Ваша аналогия была бы уместна, если бы ChatGPT мог не просто "рецепты выписывать", а выращивать людей в пробирках. Но он не может.
Знаете, а у меня есть подозрение, что немало жизней можно было бы спасти, если бы вместо месячной очереди на обследование, а за ней еще месячной к профильному врачу, можно было бы спросить специализированный ИИ...
А что вам ИИ без обследования скажет?
"В вашем возрасте это нормально"
Сэкономит месяц времени из двух, хотя бы
Может. И будет очередь на МРТ не 1 месяц, а 6. Как это исправит ситуацию?
Ситуацию потом можно исправить, сделав х6 аппаратов мрт, которые по времени изготавливаются куда быстрее и дешевле, чем готовятся недостающие врачи.
upd: погуглил, мрт стоит 1 миллион долларов. насчёт "дешевле" я погорячился, всё-таки заменённые врачи сэкономят порядка 20% стоимости одного аппарата (в РФ*), если учесть, что их надо ~6 лет учить, и аппарат будет те же 6 лет эксплуаатироваться.
+ не учёл, что аппарату наверняка нужен ремонт.
В США стоимость обучения на врача в 12 раз больше, и там и правда выгоднее будет заменить врачей на бригаду операторов мрт с ИИ
Сравнение с врачом некорректно. Вот если у каждого пациента будет своя собственная анатомия, да ещё порой и недокументированная, то врач действительно может "умыть руки" оценив затраты и профит от этого всего.
Вы не поверите, но все к этому и идет) В компании где я сейчас работаю как раз разрабатывают систему помощи принятия решения для врачей. Пока что последнее слово за врачем и ответственность на нем же, но лет через 10-15, я думаю терапевты начнут вымирать
Сейчас - нет, а в перспективе вполне возможно, что нейросети будут ставить диагноз лучше врачей, потому что будут способны учитывать результаты десятков анализов и ловить мелкие корреляции между ними.
Несомненно, это было бы просто замечательно, и такие системы уже есть, называются СППВР, Системы помощи принятия врачебных решений.
Сейчас врач часто не может поставить диагноз опираясь на все доступные данные, или хотя бы на достаточное количество данных: собрать анамнез по всей карте и уложиться во время приёма -- нереальная задача. Специализированная система же с этим справиться может.
К примеру, уже сейчас такие системы могут ставить группы диагнозов на основе снимков лёгких статистически лучше врачей.
На эту тему можно почитать в канале компании Webiomed, они и делают такие СППВР одни из многих, https://t.me/webiomed
Охренеть, целый рабочий день на смену хостера? Где-то мы явно свернули не туда.
Ошибки? Да! Не компилируется? Конечно! В конце концов, это написано не прилежным программистом, а машиной, у которой нет ни компилятора, ни чувства совести за такой код. Но мы-то можем поправить это ручками и разобраться?
Проблема в том, что ChatGPT натренирован выдавать ответ, который выглядит как правильный, вместо того, чтобы выдавать правильный ответ.
Это делает поиск ошибок гораздо сложнее обычного, потому что никто не гарантирует, что код вообще способен делать то, что вы хотите.
"Доработать напильником", конечно, можно - но всё-таки, если нам нужен самолёт, то желательно начинать не с чертежей паровоза.
Я бы попробовал использовать что-либо более специализированное, вроде Github Copilot.
Как вариант. Да, я щас попробуду code llama
Повторюсь, пожалуй: если вы не знаете как правильно, вы не сможете исправить бред от ChatGPT; если вы знаете как правильно, зачем он вам - пишите сами.
Затем что вам не нужно тратить много времени на печатание и отлаживание. Я постоянно так генерирую HTML формы.
Ну это спорно. У меня лично мало того что сам чат печатает, (ага кто блин придумал это печатание?!) через раз, не с первого раза удается втолковать что мне нужно, куча уточнений, так еще и потом просматривать код, запускать, объяснять где ошибка и заново.
Кстати, это заметно если именно ЧатГПТ использовать не на английском языке. Но если говорить с ним по-шекспировски - я ему закинул настройки, он отвечает чётко и по теме. Естественно, пришло с опытом.
Так что простой кодогенерацией на основе существующего паттера он как раз занимается резво. Даёшь ему пример как надо, даёшь что есть, и он пишет.
Более того, очень важно самому знать алгоритмы и общую практику. Я когда хочу от него алгоритм, я ему пишу что-то в роде: Вот такая переменная должна быть хашмапом, а такой должен быть вывод, а вот тут использовать регекс. Иначе он делает глупости.
а вот тут собственно и появляется будущее - одна из самых перспективных профессий на сейчас - это "толмач" который умеет и понимает ка получить от нейросети то что нужно клиенту.... я так думаю что эта "профессия" станет очень популярной на следующие года 3...
Как у Пелвина в SNUFF - инженеры-сомелье, которые умеют получать от ИИ то, что хочет клиент
Только вот тогда вопрос - ИИ вроде как должен заменять дорогих специалистов для бизнеса, снижая издержки (ну, в идеале же). А тут предлагается к ИИ прикладывать отдельного обученного человека, которому тоже надо платить. Насколько выгодно это в итоге будет бизнесу? Вопрос.
если вы не знаете как правильно, вы не сможете исправить бред от ChatGPTЭто так. Зато вы сможете скормить ему обратно ошибку и получить исправленный код. Обычно работает.
…но это не точно ;)
Что ж он сразу правильно не пишет?
Несколько раз пробовал, ни разу не сработало, к сожалению.
Бендер, вам ли не знать, как это работает.
Я против такого подхода скармливания ошибок. Если я ему и даю обратно ошибку, то только с комментом о том, как её поправить.
Я так и делал. Из последнего.
сделай мне А без использования Б
вот
но у тебя Б в строке 42, нужно без Б, переделай
ой, вы правы, тысяча извенений, всё переделал, вот
теперь Б в строках 12 и 58
ой, вы правы...
На пятой итерации я сдался. И это ещё не самый плохой вариант. Если спрашивать то, что не гуглится, то вообще лютая дичь на выходе. Общение на английском было.
Если я знаю, ааа правильно, я пробегусь глазами по генерации, сделанной за 10 секунд, потрачу еще минуту от силы, и, если все ок, заберу решение.
Если не ок, потрачу еще пару минут на исправление и заберу решение.
Решение, которое с нуля писал бы минут 20,а то и час.
Простые вещи и даже не очень простые гпт4 пишет без ошибок, в отличии от 3.5 На самом деле вообще забыл, когда ошибки приходилось за ним исправлять.
На самом деле, всё зависит от популярности языка. Написание чего либо на Typescript это просто.
Но вот, написание чего-либо для Netsuite и их специфического сабсета яваскрипта и SQL становится более сложным.
Более того, системы преобразования типов в TS, или работа с интерфейсами на Golang тоже создают немало проблем.
Но это - сложные моменты, которые в любом случае пилить надо вручную. А для генерации плащеницы HTML кода для сбора кучи данных о юзере - как раз то что надо.
И еще зависит от популярности предметной области. Вот, например, виндовую библиотеку MediaFoundation оно очень хреново знает. Например, спросите его написать код, который определяет, занята ли камера каким-то другим процессом. Вместо использования IMFSensorActivityMonitor оно предлагает какие-то несуществующие интерфейсы. Хотя в интернетах даже примеры кода есть.
GPT4 еще и дебажить умеет. Когда у меня не работал какой-то из выданных им сложных bash-скриптов, он буквально говорил "странно, должно работать...вот, я дописал логпоинты, запустите эту версию и верните мне ее выхлоп". Я беру, исполняю, копипащу ему вывод консоли. И GPT4 такой: "а, все, понял, ща починим!". И таки починил. Странное ощущение.
Разве Github Copilot не абсолютно точно также натренирован выдвать ответ похожий на правильный?
Ну тут можно только пожелать получить в наследство деплой павершелом, автотесты на баше, ну и свой фреймворк, без доки естесна
И чтоб все было написано чатгпт
А что вам не нравится в коде, который просто можно прочитать?
За 20 лет, спустя полее чем 40 различных проектов, я могу сказать, что мне в руки только один раз попался проект, который был сопровождён доками и работал. Это была мааааленькая утилита. Там было-то всего 5к строк кода.
Остальное было отдано как будто кошка накакала и закопала. Я вообще переставить в миф о нормальных доках.
Если код написан на фремворке, то как бы плохо он не был написан, он остается скован ограничениями и требованиями фреймворка. А значит, точки входа известны, основные механизмы известны, останется только с бизнес слоем разобраться.
В случае мало-мальски крупного самопального решения только "бог в помощь". Доки нет, комментов нет, "мейнтейнер" 2 недели на проекте (если этот велосипед хоть как-то "поддерживается").
Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
Мне кажется, главная претензия автора не в том, что все должны перекатываться на чистый Си, писать вручную вызывать системные вызовы, и аллоцировать память.
А в том, что сейчас ситуация выглядит примерно как "Ехал фреймворк через фреймворк, видит фреймворк в фреймворке фреймворк"
Могу ошибаться (Не силён в веб-технологиях, прошу поправить, если не прав), но тем не менее, сейчас мы имеем ситуацию, когда условный Nest транслирует код в код на NodeJS, который обращается к движку V8, который преобразовывает всё это в байткод. А ещё, в проекте скорее всего задействовано штук примерно 50 разных зависимостей, который тянут за собой ещё 150 зависимостей. А ещё, наш фронтенд, который и без того тяжёлый, скорее всего ждёт выполнения каких-то API запросов, которые выполняются на сервере, на котором примерно такая же ситуация.
И получается гигантских размеров многослойный пирог, который распутывать замучаешься.
Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
Таким образом, нужен специалист, который будет знать (Если берём WEB) NodeJS, Nest, желательно принципы работы V8, а в идеале, ещё и пакеты, которые входят в зависимости. При этом, будет постоянно следить за обновлениями каждого, следить какие функции объявлены Deprecated, следить за изменениями в принципах работы каждого и поддерживать этот зоопарк технологий, а всё ради чего...?
А ведь помимо Nest-а и JS-а есть ещё миллион других технологий.
Таким образом, работодатель получает головняк с поиском сотрудника (Каждый становится супер специфичен) и тот, кто работал с React уже вряд ли подойдёт на Nest
Работник получает головняк с постоянным переучиванием. Вместо того, чтобы учить, как это работает под капотом, он всё время изучает новые технологии, чтобы не отстать от тренда.
А пользователь получает сайт, который грузится в течение 10 секунд, хотя это всего лишь одностраничник, на котором только картинки, текст и форма обратной связи снизу справа.
И заниматься поддержкой всего этого не менее сложно. Во-первых, пойди найди человека который действительно хорошо знает один из тысячи фреймворков на экспертном уровне. Во-вторых, даже если ты его нашёл - это не значит, что он будет работать у тебя 10 лет. А через 10 лет ты рискуешь вообще не найти разработчика под свои задачи, потому что этот фреймворк уже мёртв, аки паскаль
А ведь во всех этих бесконечных фреймворках, бывают баги...
И с другой стороны, можно держать спецов, которые досконально знают чистый NodeJS вдоль и поперёк, знают особенности JS-движков, и которым всё что нужно - это вникнуть в код, который вот перед глазами
Мне кажется, главная претензия автора не в том, что все должны перекатываться на чистый Си, писать вручную вызывать системные вызовы, и аллоцировать память.
А в том, что сейчас ситуация выглядит примерно как "Ехал фреймворк через фреймворк, видит фреймворк в фреймворке фреймворк"
Мне было бы любопытно познакомиться с человеком, который на чистом Си и стандартной библиотеке способен написать современное готовое к продакшену комерческое веб решение и способный убедить в необходимости этого менеджмент :)
Понятно, что у автора речь шла именно об отказе от фреймворков, а не от высокоуровневых языков (хотя технически Си тоже к ним относится).
Могу ошибаться (Не силён в веб-технологиях, прошу поправить, если не прав), но тем не менее, сейчас мы имеем ситуацию, когда условный Nest транслирует код в код на NodeJS, который обращается к движку V8, который преобразовывает всё это в байткод. А ещё, в проекте скорее всего задействовано штук примерно 50 разных зависимостей, который тянут за собой ещё 150 зависимостей. А ещё, наш фронтенд, который и без того тяжёлый, скорее всего ждёт выполнения каких-то API запросов, которые выполняются на сервере, на котором примерно такая же ситуация.
И получается гигантских размеров многослойный пирог, который распутывать замучаешься.
Тут, мне кажется, идет смешение понятий фреймворк и библиотека. Фреймворков в силу определения не может быть много, они задают форму всего приложения и зачастую строятся по принципу "фреймворк вызывает код программиста". С библиотеками все наоборот, они ни как не ограничивают код, который их вызывает. В JS мире тонны зависимостей вызваны как раз библиотеками, которые там на любой чих, а так же скромностью стандартной библиотеки.
Rest of message
Да, в IT нужно постоянно учиться. Нет, постоянная актуализация знаний не отменяет необходимости знать, как устроена база под капотом (напротив, чтобы понять, почему фреймворк работает так, как он работает, нужно знать, какие возможности языка это позволили разработчикам фреймворка). Этот же принцип работает и для библиотек. По этой же причине, если планируется в дальнейшем как-то расширять приложение, его код нужно держать в актуальном состоянии. Это позволит при необходимости легко найти специалиста, который его модифицирует.
А касательно специализации... На мой взгляд, принципиальной разницы между современными языками комерческой разработки нет. У всех одна база из 20 века, и с тех пор в IT не то чтобы много что поменялось. Как говорится, ассемблер лишь синтаксический сахар над машинным кодом :)
из набора си библиотек, для работы с http, html: php родился
Понятно, что у автора речь шла именно об отказе от фреймворков, а не от
высокоуровневых языков (хотя технически Си тоже к ним относится).
Нет, Си язык среднего уровня, а до некоторых пор - вообще портабельный ассемблер для машин с моделью памяти PDP-11.
Да, в IT нужно постоянно учиться
Это утверждение не то что бы миф, но характеристика "постоянно" является не то что не необходимой, но и вредной. Вместо постоянного изучения ненужных фреймворков можно было бы заниматься полезным делом, так что авторов большинства из них следовало бы отдать под суд по статье за диверсию против человечества, если б такая существовала. Об этом давным-давно сказал Джоэль Спольски в статье "Огонь и движение", и пример тех же Adobe Flash и MS Silverlight вполне характерен. Тем более, что:
У всех одна база из 20 века, и с тех пор в IT не то чтобы много что поменялось
...вот именно, всё основное (фундаментальные алгоритмы) появилось в 70-х, максимум 80-х, базы новой не возникает часто, а только она и заслуживает того, что её следует учить - в Си, Perl и COBOL это понимают, выпуская новые стандарты раз в 10-15 лет. Так что этот ваш мир Web - дичь полная, расходование гигантских ресурсов впустую, причем не только машинных, но и, что более важно, человеческих.
Вы абсолютно правы.
Тут ещё надо знать об одном ужасном монстре, который называется "Устаревание фреймворков". Например, если вы возьмёте код, написаный на Meteor, 5 лет назад, то вы увдите, что он безбожно устарел, доков не сыщешь днём с огнём, и приходится надеятся на старые посты из reddit или SO.
А обновить до новой версии - даже смешно об этом думать. В итоге, мы залочены на что-то, что гоняется только на 12 версии нода, пестрит ворнингами, и единственный выход из всего этого - переписывать с нуля.
Несмотря на то, что я не очень доволен обратной совместимостью яваскрипта (я бы сказал, что babel и webpack), но чистый код на скрипте всё-равно лучше, чем какой-то странноватый фреймворк, под которого вам надо будет выделять раба, который бы занимался только тем, что раз в два месяца апгрейдил проект, а потом переписывал весь код под новую версию фреймворка.
Это пока вы не дойдете до ошибки в самом фреймворке. Или хотя бы до какого-то неочевидного места.
Если получилось заменить один проект ASP .NET на проект из одного main.go, то это означает, что у вас был максимум одностраничный лендинг. Все эти депенденси инъекшин, контроллеры и кучу слоев абстракций придумали не для того, чтобы продавать очередной фреймворк. А чтобы делать крупные проекты, и иметь возможность внедрять новые фичи за константное время. Если все напихать в один main.go, или index.php, то начиная с примерно 2-3к строк скорость внедрения фич будет зависеть от объема кода, а также приводить к регрессионным багам.
Короче, заменить все на повершел и велосипеды невозможно, если вы не гугл. А заменять подходы и архитектуры тем более не стоит.
P.S. Но с другой стороны я согласен с тем, что тянуть кучу фреймворков на каждый чих, это тоже антипаттерн. У меня на том же фронте обычно только какой-нибудь фреймворк типо vue.js и стандартный javascript. А другие фреймворки и либы стараюсь не тянуть.
6.5k строк в main.go. И что? Кому от этого хуже? Правилу о том, что функция не доджна быть длинее чем 20 строк?
Прикол в том, что это всё равно будет проще чем DI. Я просто бывал в обоих лагерях.
Кому от этого хуже?
Программистам, которым это потом придётся поддерживать. Вы будете всё понимать т.к. сами это написали. Но чтобы объяснить другим, как здесь всё делается, придётся писать документацию и описывать, как решать стандартные задачи в вашем проекте. Не легче уж тогда выучить фреймворк чем учить костыли от ChatGPT специфичные для вашего проекта? Ведь фреймворк как раз предоставляет стандартный способ решения стандартных задач и вам остаётся писать только специфичные для вашего проекта вещи.
А что, конкретно сложного в том, чтобы увидеть ошибку в файле, открыть эту строку, увидеть название функции а потом поискать эту функцию обыкновенным поиском и найти то место, откуда она вызывается.
В чём костыль простого кода, который работает.
Костыль - это обёртка для работы с базой данных, которая подключает логику через DI.
Ваши примеры показывают только, что он простой для простых задач. Было бы интересно посмотреть на enterprise проект в таком стиле.
Если доводить эту логику до абсурда, представьте себе, что некто пишет на языке высокого уровня типа Swift или C#, а потом с помощью транслятора переводит всё это дело в C и даёт вам в качестве исходника. Ну и что, что лапша, и автоматически сгенерированные файлы по 10500 строк? Это же простой код на простом языке, и go to definition прекрасно работает, enjoy.
стандартный способ решения стандартных задач
Тут есть логическое противоречие. Если есть некий набор стандартных задач с известными способами решения, то использование ChatGPT очень уместно. Потому что он может в ответ на фразу "А реши-ка мне такую задачу" выдать это известное решение - пусть с использованием фреймворка.
Но в результате программирование становится еще более высокоуровневым. И если мы начинаем программировать в терминах стандартных задач, то становится возможной оптимизация решений этих задач. В т.ч без использования фреймворков или вообще на низкоуровневых языках.
Иначе говоря, фреймворк оказывается временной подпоркой, которая была полезна на каком-то этапе развития технологий, но впоследствии утратила свое значение. В любом случае, фреймворки не вечны и имеют свой жизненный цикл. Если фреймворк снимается с поддержки, то решение без его использования может оказаться более долговечным.
Не знаю какие именно 6.5к строк у вас, но звучит это довольно паршиво. Возможно, если выделить часть этого кода в отдельную библиотеку, то новому программисту будет проще сделать фичу в такой проект без необходимости изучать все 6.5к строк.
С DI есть интересное наблюдение. Если убрав DI код стал лучше, то DI тут был не нужен. Я встречал людей, которые пихали DI внутри библиотеки бизнес-логики, не понимая смысла DI. Естественно, такое применение не привносило ничего, кроме дополнительной сложности и лишних проблем с отладкой.
Из нормального применения DI - это обертки над внешними сервисами, когда вы внедряете в бизнес-логику IMessageSender какой-нибудь, а при использовании бизнес-логики на разных проектах в одном проекте подставляется отправка сообщений СМС, в другом Слак, в третьем ТГ.
Или, например, IMarketingPolicy, отвечающий за маркетинговые правила продаж в магазине. При этом основная библиотека отвечает за работу разных частей магазина (корзины, заказов, продаж), которые есть у всех, а ценообразование, разное для разных магазинов, формируются через реализацию и внедрение IMarketingPolicy.
Да, в этих примерах тоже без DI можно обойтись, например, храня глобальные объекты и подставляя их в конструкторы. Но не понятно, зачем так делать, если DI как раз этим и занимается.
А в чём плоблема просто передать интерфейс в конмтруктор класса? Ведь когда там написано, что мол, класс без этого IMarketingPolicy по наведению мыши на экземпляр, то оно и понятно. Даже документировать не надо.
Так интерфейс и передается в конструктор. Только передается с помощью DI. В максимально упрощенном случае DI это и есть глобальный механизм, хранящий в себе объекты с разным временем жизни и подставляющий их в конструкторы сервисов и контроллеров, когда возникает необходимость. Но когда я использую DI из коробки ASP .NET Core, то я знаю, что любой программист с любого другого проекта на ASP.NET Core, увидев
services.AddSingleton<IMarketingPolicy, CosmeticMarketingPolicy>();
поймет, что это такое. И, кстати, даже если программист с ASP.NET MVC придет или даже Spring Boot, то он тоже поймет, что это такое, просто наложив знания о эквивалентных фреймворках друг на друга. Если же я вручную буду организовывать глобальные объекты, то он просто будет вынужден идти и смотреть, что там за объекты с каким временем жизни были созданы.
Ну и так далее со всем. Можно использовать такие абстракции как контроллеры, а можно просто накидать кучу методов для обработки тех или иных маршрутов. Можно пакеты грузить из нугета, а можно класть самому длл в папочку. Можно использовать npm, а можно класть руками или скриптом. И пока у вас методов / библиотек / зависимостей - 5-10 штук, то всё ок. Когда их десятки и сотни - уже все равно придется это как-то группировать, выделять по разным файлам. И вот тут придется или выкидывать самокат и пилить заново со всеми этими DI, фреймворками и паттернами, либо это будет звездолет на коленке, в котором любой ногу сломит, так как вместо привычных инструментов и паттернов мы везде имеем своё решение.
А в чём плоблема просто передать интерфейс в конмтруктор класса?
Так это и есть DI, ровно по его определению.
А вы, кажется, путаете DI, как принцип, с DI-контейнером.
Хуже тому, кто придет через год после вас поддерживать проект.
Он придет и скажет, что это все надо выкинуть и написать на новом модном языке при помощи чатгпт 5.0, после чего получит один класс на 10к строк кода
Сейчас даже те кто выше в комментариях вас поддерживал, изменят своё мнение - "разбираться с 6.5 строк при помощи поиска названий функций" на такое они не подписывались )
Рано или поздно (а скорее рано) - для облегчения жизни себе - Вы начнёте вычленять какие-то куски кода в общие абстракции для банального реюзинга кода. И это будет ничто иное как написание некоего своего микрофреймворка, который заточен под конкретный проект. И чем дальше Вы будете писать этот проект - тем больше будет этот микрофреймворк.
И вот когда придёт новый человек на проект - ему придется изучать этот микрофреймворк (а Вы его я надеюсь документировали? :), его особенности и ограничения, перф в разных ситуациях, поведения в разных corner cases, и т.д. И полезность этого будет весьма сомнительна, т.к. этот микрофреймворк больше нигде ему в карьере не встретится. Плюс это занимает время человека, которое небесплатно для работодателя.
Используя плюс/минус более популярные фреймворки - шансов что человек их будет знать и ему не придется с нуля разбираться в вышеперечисленном - значительно выше, а значит бизнес получит новую фичу быстрее и дешевле.
А чтобы делать крупные проекты
То есть, под довольно специфические задачи, ибо не все проекты крупные по определению.
заменить все на повершел и велосипеды невозможно, если вы не гугл.
Что-то не понял. Как раз для Гугла с его гигантскими проектами невозможно. А для мелких проектов, которым не нужно "внедрять новые фичи", потому что они следуют упомянутым принципам Макилроя - очень даже можно, что автор статьи и показывает.
Программисты во всём мире используют встроенный HTTP в IntelijIdea и довольны как слоны. Зачем нужен этот дикий ужас с баш-скриптами - одному автору известно.
Видимо, само существование Postman-а заставляет кого-то не пользоваться нормальными инструментами и городить огород.
Отсекать на этапе собеседования, очевидно.
Я бы вообще людям разрешил пользоваться генеративным контентом только если они могут показать, что сами этот контент умеют генерировать ручками.
Дайте задачу ответ на которую ллм не знает и посмотрите что он будет делать. Если не справится - увольте, если справится - похвалите.
Подскажите, как нам быть с джуниором, который без ChatGPT даже минимум и максимум в массиве найти не может?
Значит, это не джуниор, а стажёр. Ему нужно ещё расти до джуниора.
Зависит от того, определена ли на типе данных элементов массива операция сравнения, а то может быть не определена, и тогда джун правильно делает, что не может найти максимум.
все остальное допишет GPT. И у меня в руках появляется инструмент, который полностью находится под моим контролем.
В итоге получится велосипед такого же размера, как и исходный "фреймворк". Только он будет абсолютно неподдерживаемым, потому что его никто не будет обновлять, а когда автор уволится, никто новый не захочет с ним работать.
А что плохого в том, что легко читается?
И я вам умоляю. Поддержка инструментов. Ха! Любой проект, который я видел пришит к старой версие нодика и пестрит 900 ворнингами о том, что они все устарели.
Если что-то работает, никогда это не меняйте. Я вообще не понимаю зачем люди перенимают эту гугловскую идею о том, что версии приложения надо нужно нумеровать сотнями и выпусуать обновление каждую секунду.
API вызов по возврату курса валют, должен быть написан единожды. В смысле сама сигнатура. У разработчиков появляются идеи о том, что надо постоянно что то обновлять.
Надо просто взяться за ум и написать один раз, чтобы потом к этому не надо было возвращаться.
А что плохого в том, что легко читается?
Это демагогия. Во-первых, я уверен, ваше решение не будет легко читаться, если оно хоть как-то сравнится по возможностям с тем, что вы переписываете. Во-вторых, зачем вам вообще читать тот же код Bootstrap, чтобы что? Я могу назвать только 2 причины: интересно, как оно там всё устроено или надо баг поправить и пул реквест сделать. Ни в том, ни в другом случае ничего переписывать не нужно.
И я вам умоляю. Поддержка инструментов. Ха! Любой проект, который я видел пришит к старой версие нодика и пестрит 900 ворнингами о том, что они все устарели.
Это исключительно ваша проблема, у меня опыт ровно противоположный.
API вызов по возврату курса валют, должен быть написан единожды. В смысле сама сигнатура. У разработчиков появляются идеи о том, что надо постоянно что то обновлять.
Опять демагогия. Мы не про вызов API, а про React, Bootstrap и т.д.
Надо просто взяться за ум и написать один раз, чтобы потом к этому не надо было возвращаться.
Зачем вам тестеры, надо сразу без ошибок писать (с)
ChatGPT не способствует тому, чтобы к коду не нужно было возвращаться. Если бы очень хороший программист мог проанализировать на предмет всех ошибок чужой (в данном случае за авторством ChatGPT) код, то багов бы уже давно не было…
Если что-то работает, никогда это не меняйте. Я вообще не понимаю зачем
люди перенимают эту гугловскую идею о том, что версии приложения надо
нужно нумеровать сотнями и выпусуать обновление каждую секунду.
Ну обновлять библиотеки все равно придется, например:
исправления ошибок и уязвимостей перестали выпускаться для старой версии
новые плагины не совместимы со старой библиотекой
старая библиотека не поддерживает современную версию языка программирования
То есть, либо вы обновляете библиотеку до новой версии, либо мучаетесь с устаревшей на 5 лет версией.
Потому что бизнес-задачи — имеют свойства меняться?
Новые продукты/новый функционал приложения, желание сделать еще лучше, новые регуляторные требования наконец?
Вот в том что наша команда сейчас пишет/писали недавно:
- бизнес захотел новую фичу, мелкую, считают что попыток ее запустить будет не больше нескольких сотен в день (а значит нагрузочное тестирование не нужно), доход компании от этой фичи по самым минимальным оценкам в разы окупит затраты на разработку а клиентам тоже выгода есть (подключать принудительно это им никто не будет).
- бизнес захотел клиентам показывать более подробную и удобную информацию о продуктах (в том числе чтобы снизить количество жалоб и звонков в call center)
- регулятор захотел (хотя вообщем то очевидно что будет полезно очень) чтобы чтобы мы поддерживали функционал M для группы продуктов X(точнее по сути это добавление в группу X еще нескольких продуктов MX для тех у кого X и так есть или хочется получить) причем надо — вчера. Куда все раньше смотрели — а раньше была другая ситуация и этот M не то чтобы особо нужен был.
- вендор одной из СУБД устроил нехороший сюрприз (руководство компании предвидеть этой пакости не могло но сделать их средствами тут ничего нельзя, вариант "подать в суд" по сути бесполезен, местное подразделение вендора — банкрот) и в результате часть БД надо переводить на другие СУБД (на этот раз насколько знаю — opensource а контракт на поддержку с известной локальной конторой), в основном это все на бэке но на фронте из-за этого тоже пришлось кое что менять.
Возможно, человек идиот. Но Java тут ни при чём.
Тогда вообще уже хз сколько лет было модно хоронить джаву.
Потому что изначально она была жутко медленная и никакого приятного впечатления не производила. Апплеты и вот это вот всё.
А идет ли? Я сейчас не утверждаю, что технология умирает, но мне кажется, что многие технологии живы не просто так, они как бы живы, но при этом средний возраст их программиста сильно растет. Это просто старая опытная команда (может быть - заслуженно очень хорошая команда) пишет на том, что ей удобно. Или еще вариант - компания все автоматизировала на джаве, сейчас бы может быть и иначе бы сделала, но система уже есть, и ее проще поддерживать-дорабатывать, а не "до основанья, а затем". В общем, как-то надо отличать когда караван бодро идет, а когда по инерции.
А я не знаю. Самому было бы любопытно узнать. Но я про то, то оценивать это надо каким-то хитрым способом и мне самому интересно, как бы правильно это оценить? Например, если в сбере 20 лет назад написали систему на Java - скорее всего, даже если язык умрет и будет похоронен - все равно, она будет еще 50 лет жить, ибо она уже есть, увязана в бизнес-процессы и заменять ее тяжело. Так же как еще недавно (а может быть даже и сейчас) был жив Cobol. И молодых программистов сбер будет набирать со знанием джавы (хотя бы на уровне хелловорлда).
Но представим, что за последние 10 лет все новые банки писали свои внутренние системы с нуля НЕ на Java. Тогда получится интересная ситуация - с одной стороны, много вакансий java программистов, много программистов (из сбера переходят в аэрофлот и обратно), новые программисты учатся на Java и востребованы, получают высокие ЗП, но при этом было бы очевидно, что язык умирает (раз новых проектов не начинается там, где есть выбор)
Может даже быть так, что язык популярен за счет традиции (но технически уже устарел - писать на нем долго, дорого, код потом тяжелый). Например (на примере тех же банков) - все было раньше на Java, поэтому вся команда - джависты, поэтому и новые проекты они тоже пишут на Java и молодых нанимаеют именно на Java. И когда родится новый Тинькофф-банк, он, не имея наследия, для создания своей системы переманит себе опытных банковских программистов (ну не с улицы же) - а они все джависты. В итоге, караван идет, статистически язык вроде бы востребован, но исключительно за счет традиций.
На Андроиде она уже потихоньку исчезает.
А в итоге ее скорее уж Oracle добьет свой политикой — см например обсуждение на https://www.reddit.com/r/sysadmin/comments/165kzxg/oraclejava_is_knocking_at_my_companys_door_and/
Проверь гитхаб. 5к звёзд, отлично себе живёт.
Последнее обновление сайта в 2020 году было, не очень как-то живёт
Жить Для ПО жить - это не значит постоянно обновляться. Это значит работать и быть востребованным. Зачем в проекте постоянно что-то доделывать и обновлять, если он уже окончательно доделан и идеально выполняет все свои функции?
Я просто лично знаю создателя. Он его пилит. Но проект авторский и у него не хватает щас времени этим заниматься. Мы собирались в Марте 2022 с ним вместе приехать на конференцию по golang в Москву.
Не вышло, почему-то.
Мы тогда вместе с ним работали. Я написал полноразмерную систему по управлению VPS на чистом vugu без яваскрипта. Сам фреймворк работающий. Просто надо понимать сколько сил стоит написать такое. И уж тем более понимать, сколько смл стоит запустить это всё через tinygo, вместо нормального компилятора.
Вы можете просто заставить GPT сгенерировать вам нужный код. [...] Без бесконечных фреймворков и зависимостей от чёрт знает чего.
Да нет, вы просто заменили зависимость от фреймворка на зависимость от ChatGPT.
Даже если его завтра отключат - у меня в руках вполне себе удобочитаемый код.
А вот это совершенно не обязательно. Чем сложнее задача, которую вы будете ставить, тем больше вероятность, что код перестанет быть читаемым.
Смысл фреймворка - он, на самом деле, не в том, чтобы давать общую функциональность (хотя и это тоже). Он в том, чтобы давать общие принципы разработки, общие способы решения типовых (для фреймворка) задач, тем самым упрощая чтение.
Удачи в поиске работы с такими крамольными мыслями
Преимущество фреймворков в консистентности. Попрактиковавшись, вы знаете, какие задачи он закрывает, и что ускорит для вас. Вы даже можете научить GPT упрощать рутину для фреймворка.
ChatGPT, всегда - выиграть 15 минут, дивясь как довольная девица от сэкономленного времени => потратить 2 часа, на то, чтобы довести до ума элементарный промт и понять, что проще было написать. Его вклад приятен, но непредсказуем.
Чатботы так же не слишком умеют различать эффективные решения(вокруг которых формируются фреймворки) и самые массовые. Веса LeetCode'ров заставят бота предпочитать решения не соответствующие промышленной разработке.
Я бы также сказал, что несмотря на упрощение порога входа, люди, с глубоким пониманием фреймворков развиваются, вникая в суть ограничений и паттернов. Мне тяжело представить компетентного спеца, выросшего из вашего эксперимента
В каком-нибудь условно проекте, 99% кода занимает фреймворк и 1% - уже собственные доработки поверх него. При смене (добавлении) программиста в проект, он должен владеть кодом проекта. Фреймворк тут хорош тем, что программист на этом фреймворке уже более-менее знаком с 99% вашего кода. И вот с кодом от чатгпт такого быть не может.
Доработать этот код - вообще беда. Проще уж самому все написать с нуля.
Это коментарий, так что буду краток.
Основная идея обсуждаемой статьи — поменять способ создания boilerplate: вместо написанного вручную для массового использования каркаса приложения (framework) — создавать каждый раз заново под конкретный случай (ad hoc) boilerplate с помощью генеративного ИИ.
Достоинства автор описал сам, так что я буду писать о недостатках.
Основной недостаток: boilerplate — это тоже код. Его недостаточно один раз написать — особенно, учитывая, что современный генеративный ИИ без ошибок писать пока что не может. Его надо поддерживать: читать и модифицировать. В framework это делают его авторы — и сразу для всех. А кто будет делать это со сгенерированным ИИ кодом? Тот же генеративный ИИ — сомневаюсь, что он сможет сделать это хорошо: генеративный ИИ AFAIK — он вроде представителя коренного народа Севера СССР из старого анекдота: "не читатель, а писатель". Значит — человек? Если так — то надо ли объяснять недостатки?
Другой недостаток: каждый проект становится уникальным чуть менее чем полностью. Вновь пришедший разработчик будет иметь дело не со стандартным (при всех недостатках с документированием и т.п.) boilerplate, а с уникальным boilerplate. И у меня есть серьезное подозрение, что это отрицательно повлияет на экономическую эффективность разработки.
Резюме с аналогией: автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии.
Если для кода, сгенерированного ЧатЖпт, оставлять набор ключевых фраз (или просто всю историю генерации), то для изменения кода его не надо будет читать — все сделают роботы, надо только выдать им новое задание.
Резюме с аналогией: автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии
Вы даже не представляете от какого прекрасного будущего отказываетесь.
Чтобы выдать задание, надо внятно и чётко его сформулировать. Значит, надо выражаться ясно и чётко, как юристы, например. Но мы знаем, как выражаются юристы, и обычно это наводит тоску. Можно сделать шаг вперёд, а можно два или три (каждый пусть вообразит их себе по своему вкусу). Почему бы не пропустить теперь промежуточные шаги и не прийти к выводу, что можно написать задание на хорошем формальном языке, например, на C#?
"ясно и четко" - вовсе не значит "как юристы". Высказываться ясно и логически непротиворечиво - возможно и нужно. И при общении с людьми - в неменьшей степени, чем с ChatGPT.
Ну юристы тоже не с потолка берут свои способы выражения мыслей.
А откуда они их берут? Вы же сами понимаете, что они не являются примером ясности высказываний. Так зачем вообще говорить про них.
С моей точки зрения они берут ровно от желания формулировать мысли с минимальными возможностями разночтений. Соответственно, для специалиста эти тексты являются примером ясности высказываний, но для их чтения нужно иметь определённое образование, и это нормально. Если вы захотите писать чёткие задания для ChatGPT, то рано или поздно придёте к тому же самому. А если учесть, что в отличие от юридических документов инструкции для ChatGPT имеют форму императива (сделай то-то и то-то), мы можем убрать из естественного языка всё ненужное и оставить инструкции. А ещё можно упростить синтаксис. Получится C# или что-то в этом роде, и тогда ChatGPT вообще не нужен.
Я не согласен со многими вашими утверждениями. Возможно, юридические тексты и имеют однозначную интерпретацию, но ясными они от этого не становятся, скорее наоборот. (Мне казалось, что вы сами об этом и сказали.) И это потому, что смысл высказываниям придает контекст (связи между понятиями), а юристы интенсивно обрубают все возможные дополнительные контексты. Ну и в другом комменте я еще высказался на эту тему: https://habr.com/ru/articles/757150/#comment_25902802
Вообще мне кажется странным, что вы вспомнили юристов, а не логиков или математиков.
Они не становятся ясными вам, потому что вы не юрист. Думаю, юристу эти формулировки предельно понятны. Конечно, можно попытаться кормить модели контекст и т.д. и т.п. (хотя у юристов контекст тоже есть, например, в шапке документа написано, что это "Договор" или "Доверенность"), но мне не совсем понятно целеполагание. Говорите, можно избавиться от записи Бэкуса-Наура? Ну да, можно, но это что, rocket science и доступно лишь избранным? Если вы хотите описать чёткое техзадание, не допускающее неверных трактовок, зачем пользоваться для этого человеческим языком, если есть язык программирования. Он предназначен для инструкций, он трактуется однозначно, он прост синтаксически.
Потому что логики и математики и без нас с вами пишут на предельно формализованном языке. Юристы пытаются писать что-то однозначно на естественном языке.
Знаете, чем юристы отличаются от обычных людей? Они понимают сказанное\написанное буквально. Потому что обычные люди, говоря некую фразу, не договаривают кучу информации, считая это само-собой разумеющимся. А потом удивляются, что их не так поняли.
Вот по тому юристы и обрубают всё лишнее.
Анекдот. Два друга - юриста, в перерыве между судебными заседаниями зашли в ресторанчик. Заказали по чашке кофе и достали из портфелей по бутерброду, приготовленные заботливыми женами. Тут официант принёс кофе, увидел бутерброды и сказал -"Извините, но у нас со своей едой нельзя". Юристы переглянулись....и обменялись бутербродами.
Чтобы выдать задание, надо внятно и чётко его сформулировать.…
Почему бы не пропустить теперь промежуточные шаги и не прийти к выводу, что можно написать задание на хорошем формальном языке, например, на C#?
Вам ТЗ на каком языке дают?
Магии нет. Если человек умеет писать настолько чётко и внятно, чтобы не было разночтений, ему вообще незачем писать ТЗ, он пишет сразу код. Если же он предпочитает писать инструкции на человеческом языке, значит, в них заведомо будут противоречия и разногласия, которые постепенно вытравляются по мере того, как неформальное задание превращается в код.
Практически любые утверждения типа "бот заменит программиста" исходят из того, что работой программиста является перевод ТЗ в код. Я так не думаю, мне кажется, что работа программиста -- это последовательное и методичное устранение неоднозначностей исходного ТЗ, по мере которого неформальное описание постепенно всё больше формализуется.
Разумеется, в любой задаче полно подзадач, для которых любое решение годится. Но для этого и есть библиотеки, фреймворки и таблицы стилей. Неважно, как выглядит вебсайт, лишь бы работал? Ну берём стиль №123, и вперёд.
Если же он предпочитает писать инструкции на человеческом языке, значит, в них заведомо будут противоречия и разногласия, которые постепенно вытравляются по мере того, как неформальное задание превращается в код
Возможно сам подход "написать сразу на 100% полное ТЗ" является избыточным. Когда заказчик объясняет программисту, что ему надо получить, он начинает с более общих вещей, постепенно переходя к деталям (когда уже что-то может быть сделано). Тем самым у исполнителя сначала формируется картина в целом, для воплощения которой уже можно выбирать архитектуру проекта. Т.е. здесь на первый план выходят когнитивные искажения при передаче информации.
Практически любые утверждения типа "бот заменит программиста" исходят из того, что работой программиста является перевод ТЗ в код. Я так не думаю, мне кажется, что работа программиста — это последовательное и методичное устранение неоднозначностей исходного ТЗ, по мере которого неформальное описание постепенно всё больше формализуется
Я думаю, истина где-то посередине: необходимость строгой формализации в виде кода способствует строгой формализации в виде ТЗ.
Если для кода, сгенерированного ЧатЖпт, оставлять набор ключевых фраз (или просто всю историю генерации), то для изменения кода его не надо будет читать — все сделают роботы, надо только выдать им новое задание.
Да. «Но есть нюанс»(с): подсказки — это не формальное написание на формальном языке, их интерпретация неоднозначна. А потому, если роботы напишут новый код для boilerplate, он с высокой вероятностью будет другим. А в коде, специфичном для программы, написанном человеком (буду называть его смысловым), почти наверняка будут завязки на существующий код boilerplate. И они могут быть не только на имена переменных/функций(их-то несложно добавить в новые подсказки), но и на специфические особенности его поведения, не описанные в первоначальных подсказках, а получившееся при прежней генерации. И нет никакой гарантии, что новая генерация сохранит эти особенности. Так что для подстройки к вновь сгенерированному boilerplate придется править и смысловой код. То есть, проделывать работу, аналогичную переходу на новую версию фреймворка, только в большем объеме: авторы фреймворков все-таки стараются не вносить изменения, нарушающие совместимость версий, а от генеративного ИИ это пока ожидать трудно.
Ну и учитываем несовершенство современного генеративного ИИ: код за ним надо править. В частности, вновь сгенерированный код вместо старого уже исправленного надо будет править заново.
Хороший коммент, по делу. Но давайте все-таки не делить дихотомически языки на формальные и неформальные, а согласимся, что степень формализации и логической строгости может быть различна. И что если исключить из естественного языка некоторые риторические фигуры (метафоры и т.п.), то интерпретация может быть вполне однозначна и без абсолютной формализации в стиле Бэкуса-Наура.
Далее, при расширении контекстного окна (числа токенов) можно будет скармливать языковой модели весь предыдущий код, так что новая генерация вполне может перенимать особенности старой. Даже если в этом случае обработка будет требовать более длительного времени.
Но давайте все-таки не делить дихотомически языки на формальные и неформальные,
Давайте: перейдем на уровень ниже Нам, собственно, требуется однозначность не для любого утверждения, сделанного на языке (то, что делает язык формальным), а для нашего конкретного утверждения (или их набора) в подсказке. Кто или что будет эту однозначность проверять? Люди с этим справляются плохо (вспоминанем, к примеру, истории про джиннов). Генеративный ИИ под это, насколько я знаю, тоже не заточен — он работает на других принципах.
Ну, и дообучение по ходу на предыдущем языковом коде — оно, насколько я знаю, результат тоже не гарантирует.
Короче, если не будут решены эти вопросы, то мечты автора статьи так и останутся мечтами.
А как их решать и можно ли это сделать в принципе на основе имеющихся подходов — это уже, увы, выходит за пределы моей компетенции. Так что я дальше обсуждать эту тему не могу.
Фреймворки — они ведь и для злоумышленника очень удобны: код чаще всего открыт, а нашёл уязвимость — сразу миллионы приложений можешь сломать. Мало того, можешь ещё и продать эту уязвимость, потому как рынок огромен.
А вот когда для каждого приложения надо искать дыру индивидуально, потому что пишут сплошь велосипеды, злоумышленникам сразу становится очень грустно.
запустить пару массовых сканеров на общие ошибки это сложно? sql иньекции пропадают как класс изза того что большинство пишет на фреймворках которые используют парамтеризованные запросы. А тут велосипеды котоыре пишут люди разной подготовки (в основном новички спецы имеют свои собственные фреймворки)
Со второй частью вашего коммента согласен. Но а с первой - я вас умоляю. Если за нормальную проверку на безопасность никто не заплатит, то её никто не проведёт.
Более того, все эти замечания об ошибках безопасности в NPM так и остаются в консоли. Сколько раз я видел сообщение о том, что 56 пакетов ужасно уязвимы, и вы просто должны себя убить об стену, используя их.
Но проблема-то в том, что всё написано на старой версии метеора, и делать version bumb = переписывать весь сервер. Так что все эти аудиты просто лежат в сторонке и стонут.
Кто будет этим заниматься, если вы используете велосипед от чатжпт?
Те, кто обучают чатжпт. Он ведь не обязан писать только небезопасный код. Периодически он будет стучаться к вам и говорить "я поумнел, давай перепишем вот эту часть". Может даже метрики какие-то для сравнения предоставлять.
Это до тех пор, пока не выйдет следущая версия GPT, обученая на немного другом наборе данных, и котороая внезапно на те же самые промпты будет выдавать совершенно другой результат
Само собой)
И представьте счастье автомеханика в сервисе, когда при заезде новой модели на ремонт вместо плюс-минус одинакового и всем знакомого дизайна ему нужно будет с нуля по чертежам (это в лучшем случае, а то их может и не быть) разбираться в совершенно уникальной и ни на что не похожей конструкции очередного авто
Как же жили самозанятые автомеханики раньше, ремонтируя автомобили совершенно разных марок?
В этом прекрасном будущем для замены цепи вам нужно будет переделывать велосипед с нуля, потому что что новая цепь, сделанная на вашем личном заводе, не совместима со старыми звёздами, а новые звёзды, которые вы генерируете, не совместимы со старыми колёсами. Скорее всего, вы даже камеру поменять не сможете. Вот такие вот метафоры.
Только в современном мире разработки в вэбе, вы уже через два года узнаете, что велосипеды ездят без звёздочек, через три они будут без колёс, а через четыре - вообще будут выращиваться на клумбах.
Люди так рассказывают, что прям, вот ни разу в жизни Реакт не вносил breaking changes в свой код.
Не обязательно уникальный велосипед прям выплавлять из другого металла, какие-то узлы можно (и даже нужно) брать готовыми. А вот дизайн рамы может быть уникальным абсолютно. Загнали его в 3D-принтер — и вот вы уже владелец неповторимой вещи.
автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии.
Черт возьми, а я-то всю жизнь думал, что понятие software как раз и означает, что каждый пользователь имеет возможность модифицировать поведение своего hardware под свои потребности, а не как при серийном выпуске. И что этим и отличается информационная эпоха от промышленной.
Мочь-то он может — в сысле, имеет право. Только вот у громадного большинства людей на это не хватает квалификации и времени. Короче, так неэффективно.
Эффективно — и большинство людей это делает — использовать на одном и том же оборудовании разные сделанные кем-то другим (разработчиками) комплекты ПО, имеющих свое поведение — приложения. Причем, обычно — приложения, слабо взаимодействующие друг с другом, разве что — предусмотренным разработчиками способом. Так что в этом смысле информационная эпоха ещё не наступила (и вряд ли наступит, IMHO).
Да и в другом смысле — в смысле структуры занятости в глобальной экономике — промышленная эпоха продолжается: от того, что производство вещей выносится в условный Китай с дешевой рабочей силой, трудозатраты (в часах) на него сильно не снижаются. Впрочем, это — уже не по теме статьи.
Так вот, раз люди в массе своей все равно используют приложения разработанные кем-то, на продажу. Так что производство приложений все равно должно быть минимально трудозатратно, так же как и производство вещей. И, как я вижу, ничего, на самом деле, в производственных отношениях в обществе сколь-нибудь значительно не поменялось от появления массовой разработки ПО.
Я не буду с вами спорить насчет того, как оно есть (as-is). Наверное, вы всё достаточно точно описали. Но должно ли оно быть так (to-be)? Не думаю. Оно и задумывалось не так, и начиналось не так. Не буду дальше долго рассуждать, сошлюсь на Ричарда Столлмана и Андрея Ершова.
Про эффективность не согласен в принципе, потому что мы не определили, как мы ее измеряем и оцениваем. Нет эффективности в том, чтобы пользоваться чужим приложением, если оно не делает того, что мне нужно. А даже если оно сегодня и делает, что мне нужно, где гарантия, что и завтра так будет?
"производство приложений должно быть минимально трудозатратно" - это как раз и означает, что оно НЕ должно требовать работы целой команды узких специалистов, и что у большинства людей на это должно хватать квалификации.
Я не буду с вами спорить насчет того, как оно есть (as-is). Наверное, вы всё достаточно точно описали. Но должно ли оно быть так (to-be)?
Какая разница? Объективная действительность внесла коррективы в благие пожелания энтузиастов, и с этим остается только смириться.
Про эффективность не согласен в принципе, потому что мы не определили, как мы ее измеряем и оцениваем.
В деньгах, очевидно — которые приносят потребители. А каждый потребитель оценивает сам для себя. Нынешний механизм организации общественного производства работает так. И реальная альтернатива ему, обеспечивающая лучшую производительность труда, не просматривается.
это как раз и означает, что оно НЕ должно требовать работы целой команды узких специалистов, и что у большинства людей на это должно хватать квалификации.
Кому оно «должно» или «не должно», и какое это имеет значение? Выяснено, что в объективной реальности дело обстоит именно так, как я написал (ну, почти). И от того, что это кому-нибудь не нравится, объективная реальность не поменяется.
И, знаете ли, производство ПО — это не единственная отрасль, требующая специалистов: да взять хотя бы ту же медицину.
Не надо преподносить результаты чьих-то целенаправленных действий как явления природы. В "объективной реальности" компьютеров и Интернета вообще не существует. Это искусственно созданные объекты. А что касается виртуальных объектов, таких как ПО и информационные системы, то и подавно. Они никакой "объективной действительности" не подчиняются, а исключительно чьей-то воле.
Кому должно? Ну, человечеству, наверное. Какое имеет значение? Ну, наверное, будущее человечества от этого зависит. Это достаточно важная причина?
Не надо преподносить результаты чьих-то целенаправленных действий как явления природы.Вы просто неправильно меня поняли.
Потому что слово «объективный» означет всего лишь «не зависящий от чьего-либо сознания и воли». И в этом смысле многие продукты труда людей не менее объективны, чем явления природы. В частности — написанный программный код: он работает одинаково вне зависимости от того, что о нем думают, и что от него хотят. (кстати, непривычных людей это нередко ставит в тупик).
Процесс создания кода сам по себе — он, да, может подчиняться сознанию и воле конкретного организатора процесса. Но вот оптимальность этого процесса — она объективна. А дальше вступает в силу рынок и конкуренция — и отбирает более оптимальные процессы. И это тот самый способ управления общественным производством — рыночная экономика — лучше которого у человечества на данный момент нет.
Ну, а про будущее мы просто не знаем ничего наверняка. В том числе — и про будущее человечества, и от чего оно зависит. Так что, оставаясь в рамках рациональности, основывать на этом понятие «должно» попросту невозможно.
Да, я и правда не понял, как это продукты труда людей не зависят от их сознания и воли, если создатель продукта определяет, каким продукт будет.
Ну и если мы не знаем чего-то наверняка, это не означает, что мы вообще ничего не знаем. Весь нынешний AI/ML хайп - он как раз про прогнозирование, предсказание и вероятность. Впрочем, в контексте нашего разговора Будущее - это тоже искусственный объект, который надо скорее не предсказывать, а конструировать.
Да, я и правда не понял, как это продукты труда людей не зависят от их сознания и воли, если создатель продукта определяет, каким продукт будет.
Конкретный экземпляр продукта, несомненно, зависит от сознания и воли его создателя. К примеру, создатель волен сделать велосипед с квадратными колесами. Но между содателями и потребителями стоит механизм управления экономикой (в нынешнем царстве бездушного чистогана это рынок), который навязывает создателям представление, что, во имя пользы общества, они делать должны, а что — ни в коем случае. К примеру, те же самые квадратные колеса на рынке не купят — и их нынешнему производителю придется добывать средства для существования другим способом. Вот таким вот образом грубая объективная действительность навязывает творцам свою волю: они должны следовать интересам общества.
А что до предсказания будущего, то самая главная трудность в нем IMHO — то что мы не знаем, чего именно мы не знаем. Символ этой трудности — черный лебедь, во всех смыслах — от самой птицы до книги Талеба.
Я понял вашу мысль, спасибо. Но принимая во внимание то, что большинство стартапов, в т.ч. крупных и известных, убыточно, я склонен думать, что именно "квадратные колеса" они и производят. Да, они должны были бы следовать интересам общества, но не следуют. P.S. Вот вы сами и ответили на свой риторический вопрос "кому должны".
Вот вы сами и ответили на свой риторический вопрос «кому должны».
Да, и я с самого начала знал, что это — ответ. Но я также с самого начала знал, что часто невозможно заранее определить, что соответствует интересам общества, а что нет. А вы писали так, будто это возможно.
А стартапы (в идеале — ибо не исключены злоупотребления, такие как история мисс Холмс) как раз и занимаются выяснением, что же нужно обществу, единственным доступным нам методом: методом проб и ошибок — увы, ничего лучшего в распоряжении человечества нет.
1. Мне как-то странно видеть жалобы на засилие DI в .NET Framework. В самом языке C# поддержки DI нет, так что эта подержка привносится фреймворками. И в те времена лет 10 назад к средствам веб-разработки в .NET Framework DI можно было прикрутить только к MVC. И то, надо было именно прикручивать. AFAIK у MS даже не было своего DI, и, по крайней мере, Адам Фримен в тогдашнем своем учебнике по MVC прикручивал какой-то сторонний. Ну, а как можно было бы прикрутить DI к Web Forms или к приложениям, работающим непосредственно с конвейером IIS — это я себе даже не представляю (впрочем, могу ошибаться — это тогда не было моей областью профессиональных интересов).
2.Читая про то, что много мелких файлов кода хорошо, а один большой —
Постман. Curl уже при 10 (а есть и 20, и 30) параметрах в body будет нечитаем, а в постмане каждый параметр это строка в красивой табличке. Тоже самое касается редактирования, редактировать параметры body json в постмане удобнее на порядок. Именно поэтому, когда мне нужно дернуть кастомизированный запрос с фронта, я копирую в инспекторе запрос в виде курла, и импорчу его в постман, где уже нужное поле легко найти, и отредактировать.
Он лучше любого curl-a своей визуальной читаемостью. Запросы сгруппированы по папочкам, для разных сервисов, под разные окружения. Хранить их в папках на файловой системе в виде скриптов неудобно. Банально это надо редактор для каждого запроса открывать.
То есть это субьективно(?) удобнее.
GTP. В моем текущем крупном энтерпрайз проекте gtp бесполезен. У знакомых программистов, на энтерпрайзе, gtp тоже бесполезен. Ну, то есть его просто никак не применить, вообще.
Фраза типа "переписать проект с помощью чатгтп" в моем случае вызывает недоумение- там десятки человеко лет. Вот приду я с такой идеей к бизнесу и что скажу, быстрее работать будет? Так он ответит, что сейчас юзверей все устраивает. Поддержка лучше? Так этого не будет, основная сложность в обьеме бизнес процессов. Если по бизнес процессу требуется взаимодействие двух десятков сущностей при одном запросе, как ты не бейся, простой разработки не будет.
По поводу ухода от фреймворков- мне не надо знать, как они внутри работают. Они делают свое дело, предоставляя мне инструмент. Сообщество развивает эти инструменты, позволяя мне об этом не думать. Проблемы фреймворков, особенности знает куча людей, поэтому это дикий плюс. Выучив hibernate на одном проекте, можно использовать его на другом. Выучив велосипед на одном проекте, на другом его не применить.
Т.е. не нужно будет тратить гигантское время на обучение людей своим велосипедам. У нас и так время онбординга занимает 2-3 месяца до первой боевой задачи. И я читал уже на хабре, что это не предел. Тратить еще полгода на обучение своим наработкам? Не всякий бизнес может себе такое позволить, семь месяцев до реальной работы платить деньги.
В общем, для мелких проектов, может быть, статья и подходит. Но не для энтерпрайза.
Про curl cтрого наоборот - использование curl как раз самый, что ни на есть энтерпрайз. У меня сейчас проект, где есть пара сотен вызовов API внешних систем, в результаты которых время от времени надо "тыкать носом" разработчиков некоторых организаций и их начальство.
Вызовы API отрабатываются, заворачиваются в скрипты с генерированием набора тестовых данных (очень важно), журналированием и прочими прелестями. Иногда приходится повозиться с заковыристым запросом (google/ChatGPT здесь в помощь), но в итоге у нас есть скрипт или набор скриптов для тестирования с документированием, который можно запускать одним вызовом или даже встраивать в test/deploy pipeline - не уверен что так можно сделать с postman.
Плюсы: a) читаемый текст б) нормальный кирпичик/модуль, который хочешь в pipeline встраивай, хочешь в git положи в) все документировано! - что и когда вызывали и с какими параметрами, что при этом сломалось и на каких данных г) нужен всего лишь минималистичный текстовый редактор, bash и curl (+ git для отслеживания версий).
Проблема визуальной читаемости решается правильным стандартизированным форматированием скриптов: и, в отличие от postman, все видно на одной-двух страничках. Поэтому с автором полностью согласен (может быть субъективно): намного проще разобраться, намного легче поддерживать, намного более функционально получается.
Зависит от задач, если надо создать пользователя, в ответ вернется его id, потом надо создать группу, вернется ее id, потом надо положить пользователя в группу, потом создать товар, потом еще что-то.. и еще что-то, и оно все друг с дружкой взаимодействует. То постман с этим справляется легко, и масштабируется легко..
А если надо проверить, что запрос возвращает курс валют, а второй возвращает погоду.. то да, тут можно и с курлом..
С постманом есть ещё одна проблема. Когда полу-обученные менеджеры пытаются залезть в процесс разработки, то они с радостью возьмут первую строку поиска в гугле и вставят её в свой писюк. После чего то, что решалось одним тестом на мейке в две строчки, превращаётся в постман.
После этот менеджер начинает дёргать API сам, хотя ему там вообще нефига делать. После этого он придумыват новую финтифлюшу и присылает вам Postman collection. После этого вы говорите "__ять" и ставите постман.
Кстати, протип, эту коллекцию можно запустить в ГПТшку и она перепишет это в make и curl. Хотя таки да, в постмане есть одна полезная функция. Она позволяет выводить данные из постмана в курл.
Это разные задачи, и логично, что для них лучше подходят разные инструменты. Интеграционные тесты обычно и пишут в файлах, а для ручной проверки удобнее интерфейс.
Один очень серьёзный момент
качества ответа нейросети (далее НС) зависит от качества данных на которых она обучается.
При этом важно различать данные сгенерированные НС от данных предостваленных человеком. Использование "запачканных" данных приводит к резкой деградации ответа НС.
НС думать не умеет, это сложное зеркало. Что будет если два зеркало поставить друг против друга?
И так, я сейчас сижу перед приложением, написанным на Nest.js...
Всё загорожено декораторами, сторами и прочей билебердой, взятой из React...
В Nest решили, что CSS — это недостойно для нормального человека...
Мне надо было написать сервер, взамен старому на Next.js...
Возможно я чего-то не понял, но выглядит будто у вас в голове смешались две кардинально разные технологии. Либо вы столкнулись с каким-то монолитом в стиле PHP, написанном несколькими поколениями выпускников айти курсов :)
NestJS придуман для бекенда, и там нет ни React, ни CSS. Next.js придуман для рендеринга React на сервере.
Ну и насчет Postman - я не его фанат и не защищаю его, но ваши аргументы против не выглядят убедительно. На их сайте в подробностях описаны кейсы, для чего его используют.
Тоже удивился моменту когда автор начал рассказывать что NestJS это реакт. При этом он написал про котов и платную поддержку - то есть да, изначально это был Nest, как минимум автор там был.
Выглядит всё так будто автор увидел что проект на Next, случайно загуглил Nest, ничего не понял и решил всё сделать по своему.
Фронта на Nest, бэк на Next.
Написано всё группой индусов состоящей из девяти человек. Если вы когда нибудь работали с группой индусов из девяти человек, то вы однозначно ПРОКЛЯНЕТЕ их код.
Я не хочу говорить про всех индусов. Но три раза, из которых я с ними сталкивался был ПОЛНЫЙ писец. Как я понимаю, в России такое не в фаворе. А вот в США таким образом принято экономить. Группа индусов стоит как один серьёзный разработчик. А кода выдаёт в 10 раз больше.
Если бы вы были знакомы с Nest.js, - вы бы не путали его с Next. И, возможно, не занимались бы строением велосипедов, от которых потом будет больно. Ну а если вы с разбегу решили в нём разобраться, - то да, там порог входа повыше, чем ноль.
Все эти абстракции в Nest сильно упрощают разработку, помогая держать всё на своих местах. Можно взять и работать, даже с чужим кодом, потому что велосипедов там будет минимум. Единственное, что требуется, - это RTFM.
А как замену Postman для несложных вещей можно использовать rest-client, - посмотрите в extensions для своей IDE.
У меня мозг лопнул на моменте про Postman. Он же вообще не для этого ?
Обман и манипуляции. Разберу подробно.
Игрушечные приложения вместо настоящих
Оказалось, что приложения живут просто отлично без Dependency Injection.
Оказалось, что то, от чего мы воротили нос в 2009 году, не было
нисколько сложным. Просто написать большой main.go и связать в нём все
объекты, которые нужно - это не так и плохо
На .NET вы писали настоящее бизнес-приложение с 1000 сервисов, а на Го игрушку с 10 сервисами и 10 точками API. Да, в игрушечном приложении все зависимости можно и руками внедрить. Игрушечное приложение можно хоть на Go, хоть на Rust написать. А когда сервисов станет больше 10, вы внезапно обнаружите, что autowiring гораздо удобнее лапши в main.go.
То же касается и ORM, когда у вас 4 таблицы, то, конечно, для разнообразия SQL-запросы можно и руками написать.
Ну то есть, игрушечные приложения вообще на чем угодно легче писать, чем реальные. Это не Го более удобный, это просто игрушечные приложения писать более удобно.
Я сел и выучил Go. А после - Rust. Я выучил Node.js и множество других языков.
Это подтверждает мою мысль, что вы от написания настоящих больших приложений перешли к написанию игрушечных, раз у вас столько времени на изучение "множества других" языков.
Не используйте Го
Го — отвратительный, неудобный язык, с кучей странностей, которые там из-за странных идей его создателя. Например: надо писать названия свойств с маленькой или большой буквы. Нельзя задавать значения по умолчанию в структурах. Нет нормальных классов. Надо постоянно ломать голову, как передать структуру в функцию - по значению или по указателю. Нет нормальных коллекций. Дурацкая идея, что если вы работаете над 10 проектами, то все их зависимости должны скачиваться с гитхаба в одну общую папку. В коде в импортах надо писать URL на гитхабе.
Для Го, как я понимаю, нет средств автоматизированной правки кода. То есть, при обновлении версии Го или библиотеки вам надо исправлять все несовместимости руками в 1000 мест.
Я не представляю, как на Го можно писать что-то серьезное. Он оптимизирован на написание маленьких вспомогательных микросервисов, вроде игрушечного сервиса для подсчета количества посещений страницы. Хотите считать лайки? Пишите еще один микросервис. Это же ад, представьте, сколько вам микросервисов придется написать для приложения с 500 точками API и какой ад будет всем этим управлять и поддерживать в сравнении с монолитом на классических языках.
Го это для тех, у кого много сотрудников и бездонные бюджеты.
Что использовать вместо Го
Критикуя — предлагай. Что лучше Го? Конечно, Питон. На нем код пишется в 3 раза быстрее, чем на Го. И код выглядит чище и красивее.
Конечно, Питон не идеален. Например, работа с коллекциями (фильтры, группировки, сортировки) там требуют много букв, у меня есть идея языка, где эти операции делаются проще и требуют меньше печатать. Лямбда-функции в Питоне громоздкие, в моем языке это будет исправлено.
Если вам нужен низкоуровневый язык, то берите Swift. Он как Го, только лучше по всем пунктам. Там есть и нормальный ООП, и исключение при переполнении в арифметических операциях. Swift это Си с человеческим лицом.
Пример с postman
Что касается вашей «замены» Postman на curl, опять же, сразу видно, что это игрушка. В реальных приложениях вам могут выплюнуть 50 килобайт JSON и как вы будете в консоли это разгребать без форматирования и подсветки? А у вас в скрипте ее нет. Вы сами своим скриптом пробовали пользоваться или у вас только игрушечные API, отдающие JSON из 3 полей?
Пример с React
Вы можете резонно заявить, что этот скрипт не сможет заменить весь React
(на котором работает Nest). Конечно, нет! Но он заменит 80% всего того,
что мне нужно от React. Остальное я допишу руками.
Вы не понимаете, что такое React. React это не шаблонизатор. Если вам нужно просто один раз вывести страницу (как это делает сгенерированный ChatGPT код), то вам вообще не нужен JS - просто берете PHP + Twig и рендерите без всяких Реактов, компонентов и прочей ерунды. Смысл React в том, что он позволяет аккуратно обновлять DOM при обновлении ViewModel. Например, если у вас есть конструктор рекламной кампании, который должен работать без перезагрузки страницы, то ваша поделка от ChatGPT не позволит его реализовать.
Еще, кстати, ChatGPT не осилил Typescript и вместо типов указал везде any.
Я бы ChatGPT с такими качеством и близко к проекту не подпускал.
Про CSS
CSS-reset
Я думал, уже лет 10 назад все признали, что CSS reset это глупый подход (ломает верстку всех стандартных элементов, списки, абзацы, картинки, таблицы все выводятся без отступов сплошной стеной текста). Но, похоже, новость до ChatGPT пока еще не дошла. Что возьмешь с тупой железки.
Не используйте webassembly
Достаточно тихий golang фреймворк, который позволяет вам писать webassembly код прямо на golang.
Отладчик webassembly в коплекте к vugu идет или отлаживать код надо по интуиции? А также, сколько десятков мегабайт весит ваш webassembly-код? Запустится ли он на телефоне 2015 года выпуска?
Плюс, низкоуровневые языки требуют больше времени на разработку и отладку. Я уверен, что на Питоне + SQLALchemy + Flask я напишу сервис быстрее, чем на Го, и его код будет красивее в 10 раз и в 10 раз понятнее и читабельнее.
Питон не так быстр, как Го, но на нем код быстрее пишется. Пока вы пишете свой код на Го и возитесь с ошибками компиляции, я уже доделал проект, и перехожу к следующему. А вы тратите деньги работодателя на неэффективный язык и игрушки вроде Webassembly.
Опять про игрушечные проекты
Мне надо было написать сервер, взамен старому на Next.js. Мы переезжали
из Vercel на AWS. Старый сервер безостановочно падал. Я взял и написал
новый сервер на чистом TS.
Опять подтверждение, что у вас игрушечный проект. Я не представляю, как реальный проект, на который потратили, допустим 10 человеко-лет, вы в одно лицо быстренько перепишете на другой язык. Разве что используя автоматическую трансляцию кода, но вы ее не упомянули ни разу.
И опять же, вы работаете очень неэффективно. Вы по сути выкинули деньги работодателя, потраченные на написание и отладку предыдущей версии приложения, потому, что вам было лень разобраться в нем и исправить проблему.
Подводя итог, вы начали работать с маленькими игрушечными проектами и обнаружили, что они прощают практически любые ошибки и потому работать с ними легко.
Аккуратнее с догадками. Особенно по поводу того, что и как делает на своей работе другой человек.
Го — отвратительный, неудобный язык, с кучей странностей,
согласен, язык муторный и неудобный.
надо писать названия свойств с маленькой или большой буквы.
плюсану, лучше бы модификатор доступа какой-нибудь использовался
Нельзя задавать значения по умолчанию в структурах.
я мало каких языков знаю, но вроде это не прям вездесущая фича.
Надо постоянно ломать голову, как передать структуру в функцию - по значению или по указателю.
в расте с бороучекером не надо ломать голову как передать значение? там еще и mut всякие есть. Golang это C с GC и сахаром, указатели знать надо. в целом передавай везде по значению если нет модификаций.
Нет нормальных коллекций
есть динамический массив, словарь. множество на словаре реализуется. списков нет, это проблема конечно но не прям фатальная.
В коде в импортах надо писать URL на гитхабе.
да, бесит. с другой стороны IDE это делает вместо тебя, поэтому терпимо. но выглядит убого конечно.
Критикуя — предлагай. Что лучше Го? Конечно, Питон. На нем код пишется в 3 раза быстрее, чем на Го. И код выглядит чище и красивее.
ну вот, так хорошо началось...
Конечно, Питон не идеален. Например, работа с коллекциями (фильтры, группировки, сортировки) там требуют много букв, у меня есть идея языка, где эти операции делаются проще и требуют меньше печатать. Лямбда-функции в Питоне громоздкие, в моем языке это будет исправлено.
он далеко не идеален. и на нем можно так писать что глаза будут вытекать. в этом го и хорош, на нем муторно писать но легко читать потому что он простой как топор. но возможно это мои приколы, я не фанат когда в одну строку пихают убер конструкцию, которая в других языках занимает несколько строк.
плюс го еще он нативный и довольно быстрый. хотя конечно раст быстрее, но в нем свои тонкости.
Если вам нужен низкоуровневый язык, то берите Swift. Он как Го, только лучше по всем пунктам. Там есть и нормальный ООП, и исключение при переполнении в арифметических операциях. Swift это Си с человеческим лицом.
брать надо то, что сейчас востребовано если не хотите потом без работы сидеть :) я не особо видел swift в бэкэнде. а котлин да, вот его я бы и советовал брать - действительно приятный язык.
> Надо постоянно ломать голову, как передать структуру в функцию - по значению или по указателю.
в расте с бороучекером не надо ломать голову как передать значение?
В Питоне не надо, например.
> Нет нормальных коллекций
есть динамический массив, словарь. множество на словаре реализуется. списков нет, это проблема конечно но не прям фатальная.
Отлично, а в ваше «множество» векторы или матрицы можно класть, или только числа и строки? В моем понимании «нормальные» коллекции разрешают хранить и искать что угодно.
Посыл статьи изначально как будто из уст двадцатилетнего, цитирую:
В отличие от всяких там безмозглых PHP-проектиков, которые повально подвергались SQL-инъекциям из-за запросов типа 'SELECT * from user where name like '.$input.' and enabled = true', мы, шарписты, делали всё по-другому.
Классический пример юношеского максимализма. Кстати, пример поиска пользователей по части имени не особо распространен, можно было и актуальнее придумать.
Потом вы упоминаете, что подряд выучили множество языков программирования. Такое сейчас пишут о себе в основном школьники, опять делаю поправку на возраст.
Эти домыслы, конечно, только предположения, но позвольте спросить, сколько вам лет?
Товарищи, ну что за несправедливость! Каждый раз как появляется какой-нибудь правдоруб он обязательно достаёт PHP из 2005 года и говорит, что он был говном. Дети, например, которые в 2005 родились уже совершеннолетние. Так что может перестанем заниматься некрофилией? Чего сразу ПХП-то? Прям обидно за основной язык, чес-слово :-)
1. Да, в 2005 была версия 5.0. Спасибо, что не 4.x - вот где боль была.
2. Спорим я дырявый SQL напишу практически на любом языке.
3. Возвращаюсь к некрофилии. В 2005 году только вышла 2.0 версия шарпов. Вот наверняка там тоже говна хватало, не зря же они с тех пор еще 8 мажорных версий наклепали.
Тупо плач новоиспечённого "эксперта". Когда такие статьи уже перестанут проходить модерацию?
да хорошая статья, вон какая дискуссия началась)
ХЗ, что он называет плачем. Я уже как 25 лет программирую профессионально, и пережил всё, начиная со времён до существования jQuery и радостных возгласов, когда он появился. Это было буквально первое время, когда люди начали говорить о фреймворках.
До этого - были Toolkit. Или toolchain. Это когда у тебя вместе с компилятором шёл линкер. Или даже - интегрированая среда разработки. Тогда их ещё не сущствовало.
Помню, как примерно в 2013 году увидел VanillaJS и начал понимать, что время jQuery подходило к концу. Помню как в 2018м пришлось "снова" учить что-то новое. И тут я начал понимать, что простой HTML никто не отменил. Помню как переписал достаточно простой проект на чистом JS и HTML. Он внезапно стал супер-популярным в узких кругах. В основном потому что его можно было запустить как фаил с рабочего стола. А в жёсткой среде корпоративной сети этот проект выиграл как раз тем, что его не надо было подключать к облаку.
Просто, на это всегда можно посмотреть с другой точки зрения.
У нас были кареты. Мы их улучшали и улучшали. Устанавливали рессоры получше, кормили лошадей покруче. Мы тысячелетями улучшали технологию катания на них.
Потом появились паровые двигатели. И лошади начали развоплощаться. Мы столетиями развивали технологию паровых двигателей. Когда всё дошло до супер-сложного двигателя на три цикла, мы вдруг забыли технологию паровых моторов.
У нас появился ДВС. И мы десятилетиями его развивали и совершенствовали, чтобы в итоге понять, что...
За 10 лет электромобиль внезапно показал себя намного мощнее, совершеннее и круче любого ДВСа. Скатайтесь в любой город в Калифорнии. Там как будто играешь в ГТА с побитыми текстурами. Каждый второй автомобиль - Тэсла.
И со временем мы забудем ДВСы. Они останутся уделом коллекционеров и очень спецефических применений.
Так же и современный подход к разработке. Зачем каждый раз использовать внешние зависимости, и фреймворки, которые распадаются на составляющие с каждым обновлением версий, когда у тебя есть ГПТшка, которая в состоянии написать и разобрать код.
Мы просто переключаем передачу на способах разработки.
> Для всех тех инженеров, которые не поняли, как использовать fetch для тестирования своих приложений, был написан Postman. А потом он превратился в бесконечно сложный комбаин, в котором сам черт ногу сломит.
Проблема с концепцией продукта. Многие продукты начинаются как маленькие, простые, быстрые, удобные для простых задач. А потом, самокат обвешивается фичами и получается звездолет. Но летать на нем через два дома в булочную - неудобно. А может быть проблема не в Postman - возможно его разработчики примерно такой сложный комбайн и хотели - тогда проблема или в плохом выборе инструмента или в отсутствии выбора.
Я так написал showcert - потому что каждый раз писать сложную цепочку(!) команд с кучей ключей из openssl - задолбало. А еще больше бесило, что приходилось сначала гуглить эту команду (как там проверить сертификат на SMTP сервере после STARTTLS....), чтобы потом написать ее. Бррр... Сделал showcert, с ним все просто, легко, понятно, экономит время, не надо ничего гуглить (забыть ключи сложно) и волосы стали мягкими и шелковистыми.
Значит ли это, что openssl "зашел не туда", переусложнился, совершил ошибку, что showcert лучше openssl? Нет. Каждый продукт под свои нужды. Мои - достаточно скромные, я хочу проверять сертификаты в файлах и на сервисах по сети. Еще - проверять не просто валидность а и "свежесть" (чтобы настроить алерт если сертификаты скоро протухнут). Правило Парето. Вот для 99% моих нужд, мне хватает того, что делает showcert. Так же как хватает открывалки для открывания пива, и не нужен мультитул. Вот когда возникнет потребность в чем-то большем - конечно, пригодится openssl. Неправильно, на мой взгляд, использовать комбайны там, где должны быть удобные "узкие" инструменты. И для каждой популярной узкой сферы должны быть специнструменты БЕЗ лишних свистоперделок.
Похожее было и со Svelte. Мне очень понравился этот очень простой фреймворк, очень удобный для небольших задач. Но потом они начали обымать необъятное и он усложнился, потерял былую легкость. Добавление новых фишек - не только улучшает, но и ухудшает.
Как ни странно - но тут важен Маркетинг (самому странно, что я такое говорю - в IT сфере принято считать их бездельниками, дармоедами и дураками). Инструмент должен четко понимать свою целевую аудиторию, и ориентироваться на нее, и нужно иметь смелость отвергать все идеи, которые ухудшают удобство продукта для этой ЦА (например, делают его больше, тяжелее, медленнее, сложнее в изучении).
Проблема с фреймворками в отсутствии самоограничения.
Безотносительно всего вышенаписанного, не хочется даже спорить.
Возьмите вашу великолепную программу на Go или Rust, и напишите её БЕЗ фрэймворков на богомерзком .Net или Java. Результату вы удивитесь, гарантирую.
То есть дико возмутившись глубиной стектрейса вы стали сначала фанбоем го, потом фанбоем раста, а сейчас фанбоем ChatGPT и рекламируете его как серебряную пулю?
То есть задачу декомпозиции сложности вы переложили с фреймворков написанных и протестированных тысячами квалифицированных разработчиков на языковую модель с закрытой (!) архитектурой и реализацией, живущую в чужом (!!) облаке, не сообщающую пользователю об изменении поведения (!!!) и выдающую код похожий на правильный (!!!!), то есть по сути являющийся наиболее вероятным продолжением строки-запроса на основе спаршенного гитхаба на котором эта модель и училась.
Браво, аплодирую стоя. Я искренне надеюсь что у вас будет как можно больше последователей, потому что на фоне потока профессиональных спрашивателей ChatGPT и любителей мейнов в 6к строк (зато глубина стектрейса не больше 2) компании будут готовы платить оставшимся любые деньги.
Читаешь вот такие статьи и понимаешь, как же бесконечно далёк от всего этого. Словно это не Русский язык, а Китайская грамота.
Стоит заметить, что фрэймворков фрэймворков рознь. Но на мой скромный взгляд, большая часть из них г.. . В погоне за возможность покрыть все хотелки под все проекты, да и еще как можно быстрее, фрэймворков разрослись до невероятных размеров, пожирают кучу ресурсов и чтобы разобраться в этих на скорую руку сделанных хитросплетениях необходимо чуть ли не к авторам обращаться. Посему со временем с такими фрэймворками приходят к мысли, а давайте мы все перепишем заново на своем коде. И эти фраемворки движутся по пути - давайте их похоронем все. Ведь основная задача это побыстрее накидать проект и срубить бабло с заказчика, а как оно там будет работать это уже второстепенно.
Но есть и хорошие фрэймворки, где вместо всех хотелок, пытались избавить разработчика от написания повторяющего кода - как итог, относительно небольшие и достаточно быстрые фрэймворки которые при некоторой сноровке от разработчика покрою почти все задачи. Но кому это нужно, пару лишних строк кода накидать. Да и ради чего, чтобы это все работало быстрее? Да это уже не забота разработка, он свалил с проекте через несколько лет.
Любой зрелый проект написанный с нуля, там, внутри уже становится фреймворком. Двигать это потом "в народ" или нет уже будет зависит от воли создателя. Взлетит или нет - другое дело. А вот фреймворки "для всех" с определённой стадии уже пишутся ради обновления цифры версии и разрастаются до огромных монстров. И все потому, что позиция "мы отладили все до мелочей" с точки зрения пользователя выглядит как смерть проекта.
И таки да, и гпт хорош, но тем кто не умеет мыслить он не уже поможет. Но иллюзию поднятия самооценки даст.
Тут как раз вы полностью правы. Когда вы пишите приложение для работы с сепульками, то у вас начинает нарабатываться код, для работы именно что с сепульками. После этого вы создаёте кодобазу для сепулек, но она остаётся там, где ей выделили место. В проекте по сепулькам.
Другое дело, что условный Вася начинает разрабатывать код для работы с клюками. И решает, что этот код одинаково хорошо работает с конючами, хлюпами и хряпами. Те специфические вещи, которые надо добавить для работы фанатов хлюпов начинают распространяться на другие кодобазы. В итоге конючи, вместо того, чтобы писать свой код, пытаются притянуть за уши фреймворк, фитчи которого не предназначены для конюч. Но маркетинговый материал говорит им, что если они не пользуются этим фреймворком, то они позорные твари. Поэтому и притягивают.
Взять более реальный пример:
Кто-то берёт next.js и пишет на нём бэк для работы с netsuite. Я бы за такое вообще расстрелял на месте, ну да ладно. В чём была идея - нужно отправлять запросы к Oracle Netsuite и по пути внедрить аутентификацию и базовое схлопывание повторяющихся запросов через кеш.
Хрен с ним, написали на next. Но, никто же не проводил большого исследования по этому поводу. В итоге, полтора года работы отправлено на сервер, который, ввиду своей next идеи, перегружает Netsuite количеством запросов в секунду.
Для того, чтобы с этим справится, надо снять сервант с параллельной модели исполнения, и переделать его на очередь. Но сделать этого внутри next не получится, без тотальной переписи всего.
В итоге, решением (не моим) было то, что был написан ещё один сервер на next, который является менеджером очередей. Писали это индусы, поэтому, для того, чтобы запустить эти два уродства, надо было стартовать их одновременно, потому что они играли в игру про курицу и яйцо, и падали с грохотом. А начальник сказал, что мы переезжаем в облако, поэтому пожалуйста, задеплойте всё на AWS. Ну да, так оно и задеплоилось. Щас стоит выделеная EC2, на которой специальный сервис запускает это извращение. (Тут понятно, что next не виноват, что на нём пишут криво. Но когда ты находишься в такой ситуации, ты понимаешь, что вот именно в этой ситуации, next - это просто помеха твоему психическому здоровью).
В итоге, ты садишься, просишь ChatGPT написать транслятор credentials, создать глобальный менеджер очередей, и привинтить к этому маленький http сервер, и понимаешь, что за 2 недели ты только что перелопатил ВЕСЬ этот ужас.
Разница заключается в том, что ребята, которые писали это на next, понятия не имели, что они пишут. А я хорошо знаю архитектуру приложений и систем, и много раз накатывал вещи в облако, поэтому представляю, что такое независимое приложение. Поэтому, для меня будет намного более быстрым и удобным, с помощью генератора, переписать это всё за один раз.
Я идею и концепцию автора всецело поддерживаю. А причина она вот на поверхности. Приложение чистое (без кэша и т.п. ) сбербанк онлайн весит 482 Мб, Тинькофф 435, госуслуги 306, Авито 240, почта майр.ру 291 и т.д. это с чего это вдруг? А функционала в них ровно в 10 раз меньше чем их размер. Или там все делали рукожопы, а истинные эксперты они только тут в комментариях, которые пишут всегда очень оптимизированный код без лишнего мусора. Минусов мне в карму.
Истинные эксперты достигают такого просвятления, что вообще код перестают писать. И статьи на Хабре не пишут. Только в комментах срутся, только там живёт дух старой школы!
Каждое приложение всегда содержит как минимум 4 бинарника под 4 платформы - arm7, arm8, x32, x64. Каждый бинарник содержит в себе туеву кучу highdpi картинок под все возможные разрешения и экраны высокой чёткости (вспомните сберовскую анимацию). Чисто кода там намного меньше.
-d '{"test": true}'А как будет выглядеть POST-запрос, где данные это сущность с 10 полями, одно из которых это массив других сущностей? А что с подсветкой этих данных? А как в этих тестах с Makefile проверить, что ответ содержит нужные данные?
А главное непонятно зачем вообще для этого ChatGPT. Интеграционные тесты обычно и так все в файлах пишут, для нового теста код копируется и дорабатывается. Только конечно не на Makefile.
но у вас в руках файл размером в килобайт
Темы для кнопок и всего остального допишет GPT.
Да, только результат будет уже не килобайт. А еще каждому новому разработчику придется изучать что вы там нагородили, и какой класс надо написать чтобы сдвинуть элемент вправо.
Bootstrap это в основном и есть "темы для кнопок и всего остального".
Но мы-то можем поправить это ручками и разобраться?
А зачем тратить на это рабочее время? Мы можем просто вернуть Bootstrap и TypeScript, и всё будет работать без этих ошибок.
А когда придёт время это дописывать, вы сможете со спокойной душой это дописать. Сами. Без бесконечных фреймворков
Да не хочу я сам дописывать одну и ту же функциональность на каждом проекте. Особенно если какая-нибудь работа с базой данных будет в каждом реализована по-своему. У меня есть рабочие задачи, которые надо сделать.
Вы можете резонно заявить, что этот скрипт не сможет заменить весь React (на котором работает Nest). Конечно, нет! Но он заменит 80% всего того, что мне нужно от React. Остальное я допишу руками.
Ага, а на выходе получится тот же Реакт, только написанный языковой моделью. Т.е. еще один фреймворк. И тут я смотрю в кликбейтный заголовок с предложением убить все фреймворки... что за хрень я только что прочитал? :)
Недавно пришлось переводить spring микросервис из k8s в обычное легаси приложение, в виде плагина.
По хорошему, бизнес логику нужно отделять от фреймворков, по возможности, для облегчения портирования и апгрейдов. Когда бизнес логику нашпиговывают зависимостями от спринг, ее перетащить куда то становится сложно, так как паровоз зависимостей тянется довольно большой.
Спринг это круто, но иногда, настройки профайлов и что реально куда уедет, без пузыря не разобрать, особенно в плохо документированном проекте где проходной двор из десятка а то больше, разработчиков.
Еще плохая привычка это писать клиент для свого сервиса на http и затаскивать в него зависимость на core модуль из сервера (к примеру Solr так делает).
PS Не фреймворк красит человека, а человек фрейворк - неважно, какие у тебя инструменты, но если не делать уборку в мастерской, она будет помойкой.
Мне кажется подход автора ничего не упростит, в конце концов фреймворки удобны тем что это не просто код, они часто вводят свои собственные понятия и определения, а также готовые функции позволяя нескольким людям из разной среды и разного опыта как бы говорить на одном языке.
Например и джун и сеньор реактивщики понимают что такое хук, и примерно зачем нужен useEffect при чем это люди только может быть только сегодня познакомились. В подходе предложенном автором человеку придется погружаться в огромные пучины кода написанные кемто совместно с машиной, и дай бог понятные хотя бы тому кто их писал в момент когда он их писал.
Фреймворки нужны чтобы абстрагировать сложность, скрыв ее за простым интерфейсом а в описанном в статье подходе она просто вываливается на человека которому придется это сопровождать и ему по сути нужно будет пройти тот же путь что и автору и возможно переписать все с самого начала чтобы разбираться как оно все работает.
К тому же фреймворки это не только код, но также докуцментация и опыт работы с ним других людей к которым можно обратиться в случае возникших проблем, а к кому идти в случае самописного решения?
Мне таким образом кажется что подход не решает описанную проблему а только усугубляет.
С одной стороны да, но с другой стороны, что произойдёт, когда фреймворк бампнет major пару раз? useEffect уже deprecated. А ещё тройку бампов и код надо переписывать или пинить старую версию библиотеки.
Тоже верно, но бампануть версию и поменять апи, может понадобиться не только фреймворку. В случае с фреймворками зачастую переход будет описан, а может даже оформлен в виде скрипта который можно нактить автоматически, в случае с самописным решением поддержка версионирования ложится на плечи команды разработки.
Так что на мой вгляд это аргумент тоже не в пользу вашего подхода.
Фреймворки что! У меня вчера появилось непреодолимое желание писать веб сервер на ассемблере. И я это начал делать. На 146% уверен, что быстро заброшу, но пока хочется и доставляет удовольствие, буду продолжать ваять.
Я знал такого человека. Еще в конце 90-ых начале 2000-ых, но там было даже больше - он на технологическом контроллере писал ВСЕ на асме, включая примитивный TCP/IP стек и вебсервер. И это все работало! Раздавало файлики и данные с датчиков. Так что, задача совсем не фантастическая. Правда, когда он ушел из фирмы, не нашлось желающих работать дальше с его кодом, и перешли на маленькие Linux'а. Тогда всякие gumstix'ы начали появляться и подобные вещи. То, что он пару лет ваял - за месяц залили на маленький линукс, стоимость железа выросла на какие-то копейки.
Это ещё что - я знал одного человека, он http сервер в железе заваял, на Verilog (VHDL не зашёл).
Всё работало, железно. На FPGA. Совершенно невозможно взломать, завирусить и поиск content addressable memory был из коробки - все летало.
PS В самом деле, ведь можно в железе сделать, с файликами на флешке.
Гляньте проект asmbb от @johnfound
Все-то за что?
https://winworldpc.com/product/framework/ii
этот скрипт не сможет заменить весь React (на котором работает Nest)
Может, всё-таки "Next"?
Nest.js — это фреймворк для бэкенда на ноде.
Интересная статья и мысли в ней, заставляет задуматься перечитать и переварить. Согласен с тем, что стоит использовать chatgpt или аналог, но без проверки кода апосля никак.
"Смешались в кучу кони, люди..."
Библиотеки и фреймворки (неплохо было бы коротко указать разницу) ни хороши, ни плохи сами по себе. Это просто инструменты, позволяющие опираться на сторонние наработки. Выбор оптимального для данной задачи, проекта, продукта инструментария - нетривиальная задача, но ошибки на этом этапе будут стоить дорого в перспективе.
Вера в LLM несколько наивна, но объяснима: любой красиво и правильно говорящий человек априори кажется умным и понимающим суть того, что он высказывает.
Кстати, я не увидел в примерах для курла у автора работы с куками и авторизацией.
Ну, типа, залогинился, получил куку/токен и таскаешь за собой по разным эндпоинтам.
Можно пример автотестов на баше с курлом, где такое реализовано?
Для проверки разделения прав, например? Ну, чтобы разные запросы для админа/юзера/анонима разное показывали.
Зумеры изобрели монолит и Класс Бога
Пофантазирую. Центральная проблема в разработке ПО — сложность. Стэктрейсы с огромным числом вызовов — несомненно, сильно увеличивают эту сложность при отладке (я бы даже сказал требуют тренировки специфичных навыков для их чтения).
Почему мы получаем столь огромное число вызовов? Все дело в числе абстракций и желании каждого фреймворка стать всеобъемлющим. Каждая абстракция добавляет один или более вызовов, чем усложняет стэктрейс, но в дополнение к этому снижает когнитивную общую сложность при проектировании (можно более-менее изолированно проектировать 1 класс, не задумываясь о других).
Таким образом у нас тут появляется 2 настройки:
1) желание фреймворка стать всеобъемлющим. Если каким-то образом ограничить рост фич, то мы остановим и рост числа абстраций. Я бы сюда добавил аналогию из нейросетей: принцип "переноса" обучения, когда берется условно 80% исходной нейросети с близкой по смыслу задачи, эта часть объявляется константой, а последние слои, ответственные за высокоуровневую логику — переобучаются. Вот, думаю, задача фреймворка быть этими 80%, не пытаясь залезть в оставшиеся 20. Например, используя эмпирические приоритеты: если фича подразумевает использование менее, чем в 1% запусков, но добавляет новые уровни абстракций — ее не нужно делать вообще. Вобщем, некий показатель "польза/вред", чтобы ориентироваться — попали ли мы в 80% или 20%.
2) ползунок "сложность при проектировании" <-> "сложность при отладке". Можно попробовать подвигать его. В случае, когда часть фич не нужна, у нас получается ситуация, что в стэктрейсе десятки вызовов, внутри которых никакой логики не отрабатывает, они просто передают управление дальше. Фреймворки могут использовать укороченные цепочки вызовов, если часть фич не нужна. Это существенно усложнит диаграмму, что и откуда может вызываться, но зато существенно сократит стэктрейс.
Как один из вариантов: укороченные цепочки не используются, но IDE (может даже совместно с какой-то поддержкой в языке) может как-то научиться выделять визуально вызовы, которые лишь передают управление функциям дальше, а сами не делают ничего.
Как один из вариантов: укороченные цепочки не используются, но IDE (может даже совместно с какой-то поддержкой в языке) может как-то научиться выделять визуально вызовы, которые лишь передают управление функциям дальше, а сами не делают ничего.
Если мне память не изменяет, та же Visual Studio уже прекрасно умеет не показывать в стектрейсе в дебаге те шаги, которые не в солюшне под отладкой.
Я так понимаю, что речь у предыдущего комментатора идет несколько не о том: а о методах, которые выполняют функцию "передаста", все тело которых состоит из единственного вызова другого метода другого класса.
Если проект, как и полагается по теории, напичкан абстракциями и их слоями, таких методов в нем много, а для понимания работы кода они не дают ничего.
PS Лично я таких методов в коде ASP.NET — у меня хобби в нем копаться — нагляделся, и они у меня нередко вызывали досаду.
Я так понимаю, что речь у предыдущего комментатора идет несколько не о том: а о методах, которые выполняют функцию "передаста", все тело которых состоит из единственного вызова другого метода другого класса.
Я понимаю, да. Но в реальности исключение "чужого" кода уже резко улучшает читаемость (и заодно делает более заметными проблемы в "своем").
а для понимания работы кода они не дают ничего.
Если абстракции выбраны правильно, то таких методов не так много, и каждый из этих случаев дает понимание (что мы сменили абстракцию). Ну а если неправильно, то тут дело не в подсветке уже.
Было бы интересно посмотреть два одинаковых пет-проекта - один на фреймворке, другой на чат гпт
Куда лежит лёгкая дорога мы уже проходили
Основные правила автогенерации: "должны сохраняться шаги автогенерации" и "автогенерация не правится"
Эхх, вашими устами бы...
Увы, низкая культура разработки в купе с самоуверенностью и слепой погоней за "новаторскими" трендами делают свое дело.
> В какой-то момент требования пользователей к удобству ПО полностью убили принципы Макилроя.
Предположу, что дело тут не в пользователях а в упомянутой уже той самой культуре разработки навязанной во многом маркетинговой гонкой, и как следствие, подменой целей. Задеплоить нужно всегда вчера а специалиста нужно нанять того, который в резюме написал максимум популярных названий тех самых фреймверков в расчете что он подхватит любой код и будет его дописывать и поддерживать.
При этом у "специалиста" может напрочь отсутствовать системное мышление и вообще понимание того, как работают протоколы, что в реальности происходит с данными и как это все реализовано на уровне ОС, сетевого стека и веб движка в браузере клиента (если мы о web).
В итоге мы имеем приложения, которые делают полтора примитивных действия, при этом еле ворочаются на железе трехлетней давности, занимают 100500MB и в коде которых черт ногу сломает.
Впрочем, полагаю, что тут только своим примером да обучением молодого не испорченного поколения можно что-то менять.
Интересное мнение, захватывающая статья! Новый революционер в мире программирования )) Вроде, давайте выбросим все технологии и пусть GPT нам пишет.
А кто формирует те кирпичики, на основе которых искусственный интеллект собирает куски кода и файлов настроек? Да и сами видите, что код этот проверять надо.
Уважаемый автор, ваша статья станет актуальной, когда ИИ перестанет ошибаться. До этих пор труд программиста незаменим. Я бы сказал, что использование ИИ для написания кода, это сродни ещё одному фреймворку (возможно, очень мощному), который даёт возможности, но не избавляет от работы.
Почему бы не воспользоваться новым инструментом? Конечно, да! Но не нужно подводить к тому, что старые фреймворки придётся хоронить. Как Вы говорите, их миллион. Среди них есть замечательные творения! Просто нельзя их использовать бездумно и смешивать в одном проекте множество разных инструментов, которые по итогу вызывают путаницу.
И кто сказал, что ИИ не напишет нам всем новые фреймворки, которыми будет пользоваться ещё легче, проще и удобнее, чем тем, что сейчас предлагает chatGPT?
Отличная статья. Конечно же как и у любого разраба есть свои мысли по некоторым моментам, но в целом я думал что я один «псих» такой, а нет… Спасибо за озвучку этой «больной» темы.
Очередной "визионер" вида "все кругом тупые, всё общество заблуждается, а вот я сейчас расскажу как правильно". Вот прям все миллионы сидят, работают годами в области, развиваются, учатся и не понимают очевидной вещи, их очень надо просветить.
Последнего такого известного визионера месяцок назад раздавило на глубине 3км, тоже очень хотел откинуть нелепые стандарты, наработанные решения и сделать всё просто, на контроллерах от ХБокс и железной бочки. В принципе, это примерно показывает к чему это приведёт.
Первый же проект, написанный по указанному подходу, у которого жизненный цикл не "2 месяца написал и сдал", а лет 10 - будет вынуждено выкинут на помойку приемником после ТС вместе с миллионами денег потраченными на переработку и миграцию, потому что косты поддержки (за счёт неявных ошибок, когнитивной сложности кода, нестандартого подхода на который не найдёшь людей, невозможности масштабировать и прочего) будут ещё больше.
Почему фреймворки весят мегабайты и гигабайты, не задумывались? Потому что это не то, что надо экономить. Всем пофиг, жрёт ли фреймворк 10кб на машине разработчика или 10гб. Аналогично, с текущим каналом в большинстве своём на массовых задачах всем примерно пофиг, весит web-CRM (вы как раз упоминали веб приложения) 10кб или 100кб. А то, что является проблемой - это когнитивная сложность поддержки, стабильность и скорость внедрения фичей. И вот эту проблему решают фреймворки. По вашему подходу вы можете набрать команду из сплошных Principal Engineer-s и она прекрасно будет его держать. Остальные повалятся. А на проект на фреймворке можно посадить кучу мидлов и одного принципала и они будут в 3 раза дешевле, в 20 раз проще в найме и менеджменте и делать то же самое со скоростью 80%. И потом пересадить на соседний проект на том же фреймворке и они продолжат с такой же скоростью, без необходимости онбординга в полгода. И да, у каждого будет SSD на терабайт под фреймворки, это всё равно дешевле.
Да?
Ну вот пример: надо дописать новую фичу, c тремя точками входа (для чего нужны правки в трех других модулях), дизайн в Figma но надо учитывать что дизайнеры не всегда работают по гайдлайнам и надо решать как быть, для всей верстки желательно использовать внутренние библиотеки компонентов. При этом желательно чтобы это еще можно было поддерживать в дальнейшем. Ах да, тестовая горячая сборка приложения занимает минут 10 (и при этом некоторые правки требуют холодной сборки)
И правильно, долой Postman, зачем он нужен, если есть Insomnia
Тут буквально пара человек упомянула дизайн паттерны и то, что практически каждый фреймворк, вне зависимости от языка, реализует многие из этих паттернов. MVC он везде MVC, если заявлен. И уже только поэтому любой фреймворк -- это не дремучий лес, а что-то привычное и понятное в той или иной мере.
Если идею дизайн паттернов не осилил или даже не пытался, да, вероятно изучение каждого нового фреймворка может оказаться огромной тратой времени и ресурсов. Ну и в целом понимание целесообразности фреймворков, DRY, SOLID вот это все.
Ну и конечно же масштабы проекта определяют решение, под микрозадачи существуют микрофреймворки. Под хелоу-ворлд тащить вагон зависимостей ну да, такое.
То что предлагает автор имеет право на жизнь, но это точно не про прод, хайлоад и этот ваш энтерпрайз.
Ну а переусложнения -- это же характеристика конкретных проектов/инструментов и вы всегда вольны выбирать под свои нужды. Если в Postman добавили какие-то интеграции с OpenAPI например, значит ими кто-то пользуется, а голым curl-ом вы этот функционал уже не реализуете, ну почему от этого Postman должен сразу становиться хуже? Малтитул не лучше ни хуже отдельно взятых отвертки, открывашки или ножа -- их просто нельзя сравнивать по единственному критерию.
Отличный посыл!
Чем-то напоминает призыв использовать малоизвестный фреймворк http://vanilla-js.com/
Люди ставят сотни мегабайт сред, десятки мегабайт скриптов, минуты ждут сборки и для того, чтобы писать инлайн-CSS ?♂️
А давайте убьем все фреймворки?