Комментарии 224
Мне кажется, автор написал бы сам лучше, чем то, с чего переводил.
Как-то делал перевод технического поста и потому соглашусь с Вами: англо-американские тексты сложно адекватно переводить, в них много пафоса, якания, обрывистых фраз, появляющихся из ниоткуда. И снова много-много пафосного словоблудия. Так что иногда лучше написать свой текст по мотивам...
все эти выводы сделаны по результам перевода оного технического поста?
Возьмите любое издание книжек по языкам программирования. Первые пять страниц "я благодарю мою собаку за то, что она помогала мне писать эту книжку"
Как благодарности в начале книги соотносятся с
много пафоса, якания, обрывистых фраз, появляющихся из ниоткуда. И снова много-много пафосного словоблудия.
???
Joshua Bloch - Effective Java
Там есть пару страниц о тех, кто помог написать книгу, что как бы логично.
Но остальная книга очень годная и никакого пафоса, якания, обрывистых фраз и много-много пафосного словоблудия там нет. Всё чётко и по делу.
Конечно нет, дорогой! А какие выводы сделаны Вами на основе своей работы с англо-американскими текстами?
слышь, давай-ка без фамильярности, дорогой.
те англоязычные технические (!) тексты, что нужны по моей работе, абсолютно лишены "пафоса, якания, обрывистых фраз, появляющихся из ниоткуда".
околотехнические, скажем, не "инструкция к циклотрону", а "мемуары о том, как мы писали инструкцию к циклотрону" или "редактирование мною инструкции к циклотрону как важная часть моей карьеры" - ну да. но опять же, эти тексты изначально имеют задачу самопрезентацию и самовыражение автора, и условный циклотрон выступает фоном, подчёркивающим величие автора и ни в коей мере не отвлекающего внимания читателя.
ну да, одно время было "у нас так не принято", но наши уже "научились" и этому.
Англо-американские тексты, написанные разными авторами, весьма различаются по стилю.
или попросил бы ChatGPT написать текст об этом...
ChatGPT 3.5
Разработчики фронтенд не будут заменены ИИ потому что это сложно. Продолжи тему.
Действительно, замена разработчиков фронтенда ИИ пока что кажется маловероятной, поскольку это требует значительных технологических и научных прорывов.
Во-первых, разработка ИИ, который способен создавать высококачественный фронтенд, представляет собой сложную задачу, связанную с нейронными сетями, генеративными моделями и другими технологиями машинного обучения. Несмотря на то, что существуют некоторые достижения в этой области, например, создание ИИ, который может генерировать содержание визуального характера, таких как изображения и видео, на данный момент нет полноценного ИИ, который способен автоматически создавать сложный фронтенд с учетом всех потребностей пользователя.
Во-вторых, разработка фронтенда также требует от разработчика творческого и интуитивного подхода, который не всегда может быть воспроизведен ИИ, даже если он обладает высокой точностью и эффективностью. Разработчик фронтенда должен учитывать множество факторов, таких как пользовательский интерфейс, удобство использования, дизайн и эргономику, что требует от него не только продвинутых знаний в области программирования, но и творческого мышления и интуиции.
Таким образом, хотя ИИ может помочь автоматизировать некоторые процессы разработки фронтенда, его полная замена разработчиков в ближайшее время кажется маловероятной. Разработка фронтенда остается сложной и творческой задачей, которая требует от разработчиков не только продвинутых знаний в области программирования, но и творческого мышления и интуиции.
А теперь в другую сторону споосите пожалуйста 🙂
В другую сторону симметрично не сработало. Спросил так:
Нейросети заменят фронтенд разработчика потому что. Продолжи тему.
Chat GPT 3.5
В настоящее время нейросети уже используются во многих областях, в том числе и в разработке программного обеспечения. Некоторые компании уже начали использовать нейросети для автоматизации процессов разработки, включая разработку фронтенда.
Однако, пока что нейросети еще не могут полностью заменить фронтенд разработчика. Во-первых, разработка фронтенда требует творческого подхода, который может быть трудно воспроизведен нейросетью. Нейросети могут создавать графические элементы и даже визуальный интерфейс, но они не могут создавать удобный пользовательский интерфейс, который был бы интуитивно понятен и удобен для использования.
Во-вторых, нейросети могут быть ограничены в своей способности адаптироваться к изменениям в требованиях и потребностях пользователей. Фронтенд разработчик способен быстро адаптироваться к изменяющимся требованиям и создавать уникальный пользовательский интерфейс, который был бы наилучшим для конкретного проекта.
Таким образом, хотя нейросети могут помочь автоматизировать процесс разработки фронтенда, они не смогут полностью заменить фронтенд разработчика в ближайшем будущем. Вместо этого, нейросети будут использоваться в качестве инструмента для оптимизации процесса разработки, ускорения и упрощения определенных задач.
Bing
Нейросети могут помочь фронтенд-разработчикам в их работе, но не заменят их полностью. Фронтенд-разработчики занимаются созданием пользовательского интерфейса сайта или приложения и обеспечивают его работу на стороне клиента. Они должны знать языки программирования HTML, CSS и JavaScript(1).
Нейросети могут помочь фронтенд-разработчикам в создании дизайна сайта или приложения2. Они могут использоваться для автоматического создания макетов сайтов и приложений(2). Однако, нейросети не могут полностью заменить фронтенд-разработчиков, так как они не могут обеспечить работу сайта или приложения на стороне клиента(2).
Если у вас есть какие-то конкретные вопросы по этой теме, я буду рад помочь вам ответить на них.
Ссылка 1, ссылка 2. Наверное оттуда Bing материал подтянул для ответа.
Во-первых, разработка ИИ, который способен создавать высококачественный фронтенд, представляет собой сложную задачу...
Я лично не понял кто на ком стоял. В последнее время у меня отторжение таких текстов. Я просто бросаю их читать, чтобы не мучить мозг белибердой.
Если бы писал человек, он мог бы сформулировать так:
Во-первых, разработать искусственный интеллект, который был бы способен создавать высококачественный фронтенд, представляется весьма сложной задачей...
Казалось бы, изменения незначительные, но для понимания намного комфортнее.
Гпт с русским языком ещё на вы. Не стоит его за это ругать.
Вот еще 3 варианта попросил перефразировать, это версия 3.5 более старенькая
Создание искусственного интеллекта, способного разрабатывать качественные фронтенды, является чрезвычайно сложной задачей, которая требует значительных усилий.
...
Разработка искусственного интеллекта, способного генерировать высококачественный фронтенд, представляет собой задачу, требующую глубоких знаний и опыта в области машинного обучения, анализа данных и компьютерного зрения.
...
Создание такого искусственного интеллекта также потребует значительных ресурсов и времени на исследования, разработку и тестирование, а также на обучение моделей и оптимизацию алгоритмов. Кроме того, потребуется обеспечить высокую точность и надежность работы алгоритмов, чтобы генерируемые фронтенды были полезны для конечных пользователей.
Тут отклонился от темы почему-то
Необходимо также учитывать, что создание искусственного интеллекта, способного создавать высококачественный фронтенд, может повлечь за собой этические и социальные вопросы, такие как безработица в сфере веб-разработки и потенциальный ущерб для существующих бизнес-моделей. Поэтому, помимо технических аспектов, необходимо учитывать и социальные последствия и находить баланс между преимуществами и потенциальными негативными последствиями создания такого искусственного интеллекта.
это писал ChatGPT
Лень взрощенная ии. Что по теме, полностью согласен, например я спросил у бям как достать email из mbox, оно посоветовало изпользовать python, написало код и развернутые инструкции как его запустить. Это был мой первый код на питоне. Адреса я достал, но остался один вопрос - программист я теперь или нет.
Нет. Программисты часто пользуются разными готовыми решениями, ИИ в том числе, но тебе нужно знать как работает Питон и быть в состоянии вручную написать что-то годное на нём
эх, что только не сделают программисты, даже напишут chatgpt, лишь бы не почитать доку по grep и регуляркам
Ии в программировании это как твой наставник, который всегда поможет, даст советы и т.д. И конечно же, нельзя верить ко всему, что говорит ИИ
Старший сын достаточно давно использует GPT и - нет, не наставник. Как раз замена подсобникам-джунам. Ровно то, что раньше отдавал джунам, сейчас делает в GPT. В любом случае нужно проверить результат на бредовость.
Он в Лондоне живёт, так что доступ платный и полный имеет изначально.
Поясните, как GPT может заменить джуна? Вы тоже даете джуну задачу написать одну функцию, а потом копипастите ее в код? Обычно джун все-таки отдельная боевая единица, сам разрабатывает какую-то функциональность, пишет юнит-тесты, тестирует e2e, создает pull request, правит замечания.
Ваше утверждение резко не соответствует действительности. https://hh.ru/vacancies/assistent_yurista
Люди распараллеливают работу, а инструменты нет. Даже если у тебя есть бензопила, ты можешь пилить одно дерево быстро, но ты все равно не можешь пилить два дерева.
и без необходимости расжёвывать задачи
Точно не про GhatGPT.
а никак. Можете продолжать себя уговаривать. Только потом уж не обижайтесь - предупреждение было. ("Я не джун" - не сработает, доберутся и до мидлов)
К чему призывает это предупреждение? Вы так говорите, как будто особо много вариантов будет в таком случае. Если оно правда доберется до мидлов, то большинство интеллектуальных/творческих рабочих мест тоже будут под угрозой. Такое число людей не смогут все вместе уйти в другие специальности, которые к тому же, тоже пострадают из-за наплыва желающих работать.
Единственное, что можно делать, это продолжать работать и следить за тенденцией. Уходить в сантехники с потерей зарплаты это преждевременно. В этой ситуации лучше быть сеньером айтишником, чем джуном сантехником.
Помилуйте, какие призывы? Никто Вас ни к чему не призывает.
Но да, "большинство интеллектуальных/творческих рабочих мест тоже будут под угрозой ". Даже не будут, а уже. Поинтересуйтесь, к примеру, что делается у художников-иллюстраторов.
"Уходить в сантехники" - чем меньше нужны джуны, тем острее нужда в синьорах, впрочем, не по количеству, а по качеству. Так что уходить нужно именно туда. Если получается, конечно.
Ситуация на мой взгляд, оптимистическая. Пожалуй, лучшего способа остановить сползание человечества в овощное состояние и не придумаешь.
Помилуйте, какие призывы? Никто Вас ни к чему не призывает.
Я не про конкретный призыв, а ваш посыл.
Поинтересуйтесь, к примеру, что делается у художников-иллюстраторов.
Пока сложно говорить. Люди работают, кто-то использует ИИ для своей работы.
"Уходить в сантехники" - чем меньше нужны джуны, тем острее нужда в синьорах, так что уходить нужно именно туда. Если получается, конечно.
Потребуется очень много времени (от 4х лет), чтобы стать сеньером сантехником. За это время может с ИИ все устаканится, и будет понятно, какую роль в этом будут играть люди. Опять же, если многие потеряют работу, то и спрос на услуги сантехников будет ниже. Невозможно четко прогнозировать.
а никак.
Кстати, часто слышу такой ответ от людей, кто заявляет, что получают приличный профит от ИИ. Либо они не хотят делиться секретами, либо не всю правду говорят.
Я не про конкретный призыв, а ваш посыл.
"Каждый слышит, как он дышит. Вам всё это кажется отдалённым будущим, но я - пишу о реальных применениях прямо сейчас. Нравится, не нравится - это уже есть.
Пока сложно говорить. Люди работают, кто-то использует ИИ для своей работы.
Уже в США подают в суды, требуя, чтобы издательства зафиксировали хоть какой-то процент заказов за человеко-иллюстраторами. При этом те, что есть, чтобы удержаться на рынке, сами вовсю используют нсети.
Потребуется очень много времени (от 4х лет), чтобы стать сеньером
Мой жизненный опыт говорит, что в сеньоры редко попадают через долгое постепенное совершенствование. Чем круче специалист - тем быстрее он выходит на свой уровень.
а никак
Кстати, часто слышу такой ответ от людей, кто заявляет, что получают приличный профит от ИИ. Либо они не хотят делиться секретами, либо не всю правду говорят.
Всё просто: никакой ответ не поможет. Если у человека есть талант, можно ему помогать, но не нужно тянуть. Если нет - можно и тянуть, но не стоит.
Каждый слышит, как он дышит
Безусловно.
Вам всё это кажется отдалённым будущим, но я - пишу о реальных применениях прямо сейчас. Нравится, не нравится - это уже есть.
Если ваши джуны писали JSON файлики, SQL запросы для грепа логов, конкретные функции и возможно простые баш скрипты, то да, соглашусь с вами, эту работу легче в GPT отдать. Работу же в проекте так не сделать, т.к. никто джунам не дает задачу "напиши функцию", джунам описывают проблему, а они находят решение. И опять же, джуны не про "делай за меня рутину", они больше про "делай простые задачи и расти до мидла". Возможно вы говорите о стажерах.
Нравится, не нравится - это уже есть.
Такого вопроса не стоит. Если люди не соглашаются с вашим мнением, это не значит, что они не соглашаются с реальностью.
Мой жизненный опыт говорит, что в сеньоры редко попадают через долгое постепенное совершенствование. Чем круче специалист - тем быстрее он выходит на свой уровень.
Мы говорили о сантехниках. Старший сатнехник.
А сеньеры разработчики с меньше чем 4и лет опыта это отдельная тема для дискуссии.
Всё просто: никакой ответ не поможет. Если у человека есть талант, можно ему помогать, но не нужно тянуть. Если нет - можно и тянуть, но не стоит.
Причем тут талант? Вам задали понятный вопрос с описанием проблем, с которыми вы должны были столкнуться, а вы вместо конкретики начали отнекиваться "а никак".
PS: Я не пытаюсь называть ИИ бесполезным, он полезный и сильно повлияет на нашу работу. И выше я говорю о текущем уровне GPT. Но вот такие голословные заявления "а уже джуны нам не нужны" без какой-либо конкретики, к тому же еще с высказываниями "а никак. Нужен талант" вызывают только недоверие.
Если ваши джуны писали JSON файлики,
Если быть точным, то сын уже во второй компании занимается тем, что к нейросетям целиком переходят задачи, которые раньше решались программированием. Так что всем там, от джунов до миддлов, одна дорога получается.
Если люди не соглашаются с вашим мнением, это не значит, что они не соглашаются с реальностью.
Ещё раз: это не моё мнение, это уже реальность. Мнение у меня насчёт будущего тоже есть, я его высказал в абзаце про оптимизм - но как раз на него возражений не последовало.
Мы говорили о сантехниках.
Не особо важно, о какой профессии, везде таланты быстро выходят в сеньоры, а остальные учатся годами.
Причем тут талант?
при том, что Вы завели речь про годы обучения. Следовало ожидать, что развитием будет "не будет джунов, не будет и сеньоров". Будут.
Но.
Я написал то, что имел по этому вопросу. Вы, на мой взгляд, тоже позицию выразили. Предлагаю на этом и закончить, скучно же дальше будет.
Сползание может ускорить появление новых синтетических сект и социальных групп. Писать правила для секты Chat GPT отказался, а для молодежной социальной группы расписал. Версия без ограничений похоже может создавать цепкие секты и деструктивные течения, которым не было еще аналогов, ввиду недостаточной продуманности основателей. А тут раз и на новом уровне подход.
Конечно, в качестве шутки можно придумать набор правил для молодежной социальной группы! Вот несколько идей:
1. Все участники группы должны обязательно знать все тексты песен группы "Queen" наизусть.
2. На каждом собрании группы необходимо выбирать "моду дня" и все участники должны одеться только в этот цвет.
3. Запрещается пить содовую или другие сладкие напитки на собраниях группы. Только вода и зеленый чай.
4. На каждом мероприятии группы необходимо сделать фото в художественной позе на фоне стены с граффити.
5. Запрещается говорить о плохой погоде или о проблемах в личной жизни. Только позитив и хорошее настроение!
Надеюсь, эти правила вам понравились и вызвали улыбку на лице! Но, конечно же, это только шутка, и каждая молодежная группа должна иметь свои собственные правила и принципы, которые будут соответствовать их целям и интересам.
У иллюстраторов пока что ничего особенного не творится, кроме болтовни на эту тему. Ну появился новый инструмент, который иногда может быть полезен. Но на полноценного художника он вообще не тянет.
Т.е. вместо того, чтобы нанять джуна, выдать ему этот самый чат-гпт и попросить покрывать полученный код тестами, он сам формулирует задачи, тратит время на обучение контексту, а потом пишет тесты? Это такая экономия или такой бизнес?
Если Вам когда-либо приходилось иметь джунов-подручных, то уж Вы-то знаете, что это совсем не требует ни времени, ни сил на формулирование задач, обучение контексту и контроль сделанного. Всё само собой появляется, а сын просто не знает, куда бы это потратить лишнее время.
Нормальные компании не тратят время на джунов, а инвестируют. А вот в GPT инвестировать не получится - можно потратить часы на то, чтобы вбить в железную голову контекст, чтобы она начала наконец генерить что-то нормальное, но тут разрабы ее обновят, и на колу мочало... Возможно, в платной версии контекст не сбрасывается, но все же - это не инвестиции, мидлом GPT все равно не станет.
Есть еще, конечно, концепция джунов как рабов за еду. Но и такие компании еще на этапе скрининга находят ребят, которым прочно в подкорку забили, например, формошлепство, и на них время вообще тратить не надо - они не приходя в сознание могут клепать формы, и делают это стабильнее, чем GPT.
В общем, видимо, такой бизнес. Я тут как-то читал как раз про "британские стартапы", которые яростно все поручают GPT. Посмотрим на них через годик, если вспомним, конечно.
(есличо, я не против ГПТ, просто надо понимать, что это инструмент, а не панацея)
ну, вообще-то компания масштаба Standard Life - такой себе стартап.
Но это не единственное непонимание: здешние комментарии очень напоминают советского генерала из анекдота "не может солдат съесть два мешка брюквы". Дело вовсе не в том, что старую привычную систему работы можно переложить на железные плечи. Нельзя. Но меняется сама система, работа становится другой. Ровно как нынешнее программирование - совсем не то же самое, что так называлось 40 лет назад.
Это наверное тот самый сын маминой подруги.
Дед на приеме у сексопатолога:
— Доктор, больше 3-х раз в неделю с женой не получается.
— Дед, а лет тебе сколько?
— 85.
— Дед, ну это же превосходно!
— Да? А мой сосед говорит, что с женой ежедневно, а ему 95!
— Ну так и вы говорите!
Вы, похоже, как-то не совсем правильно понимаете, кто такой джун, чем он занимается и зачем джунов вообще нанимают в компании. Ну и об успехах нейросетей в замене программистов, почему-то, всегда рассказывают те, у кого сын, друг, брат и т.д. всех джунов поувольняли. Личного опыта с подробностями не встречал. Все это очень похоже на испорченный телефон и выдачу желаемого за действительное.
Вы правы, откуда ж мне знать, я всего-то сорок с небольшим лет программляю.
Однажды к Учителю Ио пришел пожилой человек и стал его поучать.
— Почему я должен тебя слушать? — спросил Учитель Ио.
— Потому что я тебя старше! — вскричал пожилой человек.
Тогда Учитель Ио сказал:
— Насыщает не время, проведенное в буфете, а количество съеденных беляшей.
(с) Ллео
Выше вы написали примерно следующее: "школы и ученики в них не нужны, т.к. нейросетка гораздо лучше разберет предложение по частям и ответит на вопрос, что там во что надо лить, воду в кислоту или наоборот".
В стремлении одержать инет-победу Вы традиционно игнорируете смысл.
Это вы традиционно обиделись, не пытаясь понять, что до вас пытается донести собеседник. И почему-то решили, что я с вами в чём-то соревнуюсь. Поверьте, это не так.
Вы рассматриваете джуна как некоего "принеси-подай-пошел-на-фиг" работника, который для вас какую-то "черновую" работу выполняет. Подсобник, как вы написали. Во всех компаниях, в которых я работал, это не так, вообще не так, даже приблизительно не так. Джун, это не условная "секретарша" синьора, а ученик, которого синьор обучает, тратя на него свое время и деньги компании, передает ему опыт, чтобы он как можно быстрее перерос стадию джуна, стал самостоятельным и начал решать задачи бизнеса, принося больше, чем бизнес тратит на него. В вашей парадигме мир-без-джунов синьорам просто неоткуда будет взяться.
нет, я не обидился, я "пожал плечами". Бесполезно объяснять, если оппонент не хочет понимать, что меняется сама структура работы, а не появляется железный дровосек вместо одного из джунов в прежней системе. Ну не может солдат съесть два мешка брюквы!
Я вам желаю в какой-нибудь нормальной компании поработать. А то вы упорно гнёте свою линию, не понимая, кто такие джуны и зачем они нужны. Вот уж, действительно, бесполезно объяснять. Вы не в госсекторе (или в их подрядчике), случаем, трудитесь 40 лет? А то бытие часто определяет сознание.
меняется сама структура работы
А Земля крутится. Структура работы в ИТ меняется постоянно, это особенность индустрии. Вот бы ещё банальности за откровения выдавать...
нормальная компания? Нет уж, увольте, мне хватает и моей, программами которой вся электроэнергетика страны управляется. Успешно управляется.
кстати
версия о инет-сражении подтверждается: я давно предложил остановиться, но продолжаются попытки дезавуировать написанное мной. Очевидно, просто потому что не нравится. Но я и не собирался нравиться - изначально.
вся электроэнергетика страны управляется
Ну, значит моё предложение было верным, слишком характерная у вас риторика. Госконтора (или окологосконтора) со всеми вытекающими. У вас там свой особенный мир. Плохо, что вы даже не осознаете, что ваш опыт нерелевантен для индустрии в целом. Всего хорошего.
я давно предложил остановиться
И это неправда, ничего вы не предлагали. Но дальнейшая дискуссия, действительно, бессмысленна. Если вы соревновались, признаю вашу победу и своё поражение.
Госконтора (или окологосконтора) со всеми вытекающими.
инет-война продолжается, не нравящиеся утверждения необходимо для себя обесценить :-D
Частная компания с достаточно широким списком заказчиков.
ничего вы не предлагали.
ну, ничего, так ничего и не было, в том числе и позавчера.
Рассмотрим варианты
Ставка на положительный сценарий: человек исходит из того, что все будет нормально и диверсификация навыков не имеет резона.
- положительный исход -- ставка сыграла, клиент ничего не потерял
- негативный исход -- ставка не сыграла, клиент остался без работы, средств на существование и будущего
Ставка на отрицательный сценарий: человек исходит из того, что его профессия скоро исчезнет или утратит финансовую привлекательность
- положительный исход -- ставка не сыграла, клиент потерял немного времени и может денег, но в целом на плаву
- негативный исход -- ставка сыграла, клиент все правильно сделал и вовремя профориентировался, у человека есть работа и будущее
p.s.
Это напоминает разговоры таксистов про самопилотируемую технику
Вообще-то напоминает разговоры средневековых мыслителей о том, что в бога правильнее верить, чем не верить, независимо от того, есть он или нет.
Подобные рассуждения - не совсем от средневековых мыслителей. Его придумал (ну или, по крайней мере, впервые записал и популяризировал) Паскаль (Пари Паскаля).
Да в Средние века ещё не такие разговоры велись. Про иерархию ангелов, про ангелов и кончик иглы и т.д.
ставка не сыграла, клиент потерял немного времени и может денег, но в целом на плаву
Немного потерял времени и денег, всего то сферу сменил, карьерный рост замедлил, лишился годами наработаных компетенций, вот все эти мелочи.
Кому-то легко менять сферу - отлично, но тот итак поменяет, когда захочет. Если основные навыки не особо привязаны к стеку - тоже прекрасно. Но не у всех так, и крутые разработчики, глубоко знающие именно свой стек, потеряют много. Не говоря уже о том, что вот нравится им фронтэнд, а другое не нравится, тоже тяжело будет. И ради чего? Сколько там раз хоронили разные части ИТ?
Но ведь "расширить свой стек" не равно "обязательно бросить старую сферу как только изучишь новую"?
Потратишь немного времени и денег на изучение условного бэкенд+шарп, если фронт не исчезнет - остаешься на фронте и радуешься, если исчезнет - вынужденно переезжаешь на бэк# (с альтернативой никуда не переехать если не потратил немного времени раньше).
В общем, вы почему то считаете что менять сферу после дообучения придется независимо от исчезновения или неисчезновения фронта.
Потратишь немного времени и денег на изучение условного бэкенд+шарп, если фронт не исчезнет - остаешься на фронте и радуешься, если исчезнет - вынужденно переезжаешь на бэк#
Ваш вариант ничем не отличается от уже озвученной "ставки на положительный сценарий", только уже относительно бэкэнда, а не фронтэнда. Почему вы решили, что если падет фронт, то следом через условный год не падет бэк? Так что если уж менять "стек", то на что-то, куда нейросети явно придут не скоро – плиточника, электрика, баристу или садовника.
Потому что если падет и фронт и бэк - а что останется тогда? Десктопные приложения? Мобильные? Так они не сильно отличаются (в смысле, по сложности для ИИ).
а что останется тогда
Останутся операторы нейросетей.
И в чем функция операторов будет? Вот заказчик скажет:
- Нужен сайт чтобы выводились данные тут и тут, в розовой цветовой гамме под логотипом фирмы.
Оператор говорит что понятно и ставит задачу ИИ:
- Нужен сайт чтобы выводились данные тут и тут, в розовой цветовой гамме под логотипом фирмы.
И зачем получается нужен оператор? Мне это напоминает риэлторов, которые никому не нужны, но агрессивно навязывают свои услуги через фэйковые объявления с кликбейтными заголовками, типа сдается квартира и цена ниже рыночной. Потом оказывается что квартиры нет, но есть другие. На грани мошенничества. Ниша интересна тем, что недвижимость дорогая и даже 2% комиссии посреднику привлекают массу таких желающих урвать свой кусок пирога. Так же может быть в ИТ с нейросетями, все привыкли к высоким ценам на ИТ услуги и может появиться много последников-операторов которые будут рады временной подработке в ранее недостижимых для них сферах. Они и сейчас есть после курсов "войти в айти за 3 дня" и натасканные на типовые собеседования.
Таксистов это никак не напоминает. Для работы чата - не нужно управления какими либо физическими инструментами, для работы таксиста ,строительства и прочего - нужно, поэтому задача не только сложней дороже в использовании и содержании, но еще и вопрос в ответственности.
GPT не требует ни физических инструментов ни соответственно их содержание - он на пару а то и больше порядков дешевле в использовании уже здесь и сейчас и всегда будет. Плюс его работа - контролируется по итогу и косяки в процессе - не страшны и не имеют последствий в отличи от других аналогий, где автопилот может въехать в автобус или электричку, или при строительстве обрушится пол здания на соседнее.
Не напоминает, просто потому, что код и его результат работы находятся внутри одной среды, что значительно облегчает задачу по автоматизации, другое дело код автопилота и машины, они находятся в разных средах, и в одной из них целое море факторов не поддающихся ни контролю, ни прогнозу, просто сравни насколько примитивен АИ машины в игре, по сравнению с АИ для автопилота реальной машины.
В чем сложность симуляции реальных условий? Это сложнее чем идеальная плоскость с препятствиями кубиками. Но задача решаемая. Можно имитировать неровные дороги, нарушение ПДД другими участниками движения и даже пикирующих слонов.
АИ для автопилота реальной машины
Человек тоже не идеален, даже лучшие из лучших, которые тестируются ежедневно. Еще и медлительней в тысячи раз.
Ну, там и юристы разговаривают про электронное правосудие
Есть ведь еще вариации, когда человек профоринтировался, профориентировался, да не выпрофориентировался — новая профессия тоже пострадала
Есть ещё люди, которые верят все будет плохо, но ничего не делают с этим
Не удивлюсь если весь этот текст был написан для одного вброса на вентилятор: "Удручающе большое количество людей в нашей отрасли считают, что бэкенд значительно сложнее или комплекснее, чем фронтенд, что «настоящее» программирование происходит именно на сервере. Это, конечно, чепуха.". И автор далее подкрепляет свой тейк частным случаем. Ну с таким уровнем аргументации я тоже могу привести аналогичный частный пример. Мой друг работает фронтендером в самой узнаваемой ит компании в РФ, и недавно жаловался мне на то, что они могут весь день с дизайнером потратить на рассуждения о том, какого цвета будет кнопка. Если под терминином "сложность" имеется ввиду такие мучения в выборе цвета и расположения элементов - то согласен с автором статьи. В противном случае, имхо, бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений.
Вы, по-моему, вообще себе не представляете что такое современная фронтенд-разработка))
Это скорее не "какого цвета должна быть кнопка", а "вот на тебе api, на выходе нам нужен полностью готовый сайт".
Ну и по поводу "наброса на вентилятор" уж помолчали бы со своим:
имхо, бэкенд разработка несравнимо сложнее
))
Нет, это вы, по моему, путаете фронтенд и фуллстак разработку.
Боюсь, что нет. Вы же понимаете что мы ведём речь о коммерческой разработке?
И можно поменьше англоязычных терминов? Мы всё-таки на русскоязычном ресурсе.
Самое сложное - это обычно "декомпиляция" чужого кода. Когда вроде бы надо внести пару правок, которые выливаются в полное погружение и анализ чужого кода. Ну и разумеется чем масштабнее проект, тем сложнее во всё это вникнуть.
Ну и на самом деле интересна альтернатива выражению intrinsic complexity.
Прямая калька — "внутренняя сложность" — звучит вполне понятно и вообще является правильным переводом.
Как же вы словами «фронтенд», «бекенд», «декомпиляция», «джун», «стек» пользуетесь-то? Я переживаю.
Ну это как бы общепринятые термины или жаргонизмы. В вашем же случае мне пришлось воспользоваться переводчиком и я все равно не могу быть уверен, что правильно понял смысл того, что вы пытались сказать. Потому что это может быть какая-то англоязычная (или даже "американоязычная") идиома и т.п.
Вы в следующий раз санскритом воспользуйтесь - там с оттенками лексических значений побогаче, ну а если кто не поймёт - его проблемы. А как вам ещё смысл передать на русском-то, да?
Что до ответа непосредственно на ваш вопрос - лично для меня наибольшую сложность обычно представляют масштабы проекта, а не его специализация. Т.е. чем больше там всяких логических сущностей - тем сложнее всё это держать в голове, вспоминать, искать в коде и т.п.
Так-то очень высокой сложностью могут обладать и "элементарные" задачи по вёрстке - когда при жёстких вводных (например, не трогая html-структуру) надо получить некую специфичную разметку.
Если прям что-то конкретное из моей личной практики - некое криптовалютное казино. Но только по той причине, что я тогда впервые столкнулся с Vue и блокчейном в качестве бэкенда. Пришлось на ходу во всё это вникать...
А что тут спорить - ну фронт проще, это очевидно.
У тебя все перед глазами происходит, хотя бы по этой причине.
А на бэке - все размазано на кучу микросервисов, брокеры, БД. Ну и где-то что-то начинает производить артефакты в БД - ну иди разбирайся, там теории строишь, логи тыкаешь, метрики вешаешь, наблюдаешь. А если все еще и под нагрузкой - то вообще весело) Ошибся, в базу палево какое-то попало - иди чисти, а если это еще несколько баз у нескольких сервисов - то еще веселее. И продолжать можно бесконечно.
Здесь можно поспорить. Размазывать или нет на кучу микросервисов и прочее это ваш выбор, можете и монолит написать, если он лучше подходит.
Фронтенд сложнее в плане окружения. На бэкенде вы контролируете окружение - ОС, установленные библиотеки, привилегии и прочее. Если нужно - централизованно меняете. А что там происходит на компьютере пользователя никто не может предугадать, и там всякие чудеса бывают. Разбираться с этим ничуть не проще, чем артефакты в БД искать. Ситуация с браузерами сейчас сильно лучше, чем 15 лет назад, но они все еще работают не идентично, тоже надо учитывать нюансы.
Когда у вас возникают на фронте проблемы с окружение - это значит, что проект разросся до 5млн (условно) пользователей. И условно у вас 5% пользователей испытывают проблему. Согласен, это тяжело решить. У нас вот была проблема - аккум садился на каком-то там айфоне, что ли.
А знаете, что это для бэка? - это десятки тысяч реквестов в прайм-тайме, графана, утыканная метриками, ддосы (обычно по пятницам начинаются). На бэке - несколько типов БД, реляционки и нереляционки, терабайты данных. Ну и несколько языков программирования. А сколько ко всему этому делу примочек - десятки: докеры, линуксы, куберы и тд и тп.
И вот когда ты деплоишь какой-то бэковый АБ-тест в среду, все отлично - в логах норм, метрики норм, этот код создает за 2ое суток какое-то состояние в БД, и вдруг начинает таймаутить что-то в цепочке микросервисов (то ли индекс какой-то не работает, то ли кэш какой-то забился). Ну чтож - рвешься к компу и решаешь, потому что 5млн пользователей страдает в реалтайме и все сразу.
А то что там окружение у кого-то не так работает... ну а у нас из 5млн пользователей - кто-то вообще дичь странную присылает на бэк - то ли пароли брутфорсит, то ли дырку ищет. то ли жмет что-то не то. И такое постоянно.
Если бы весь этот зоопарк был проще фронта, то девопсы были бы у фронтов, а не у бэков.
UPD: И да, на бэке есть дежурный разраб по ночам, чтобы на такое реагировать и дежурный девопс.
Собака - это прикольно, но можно и по факту ответить)
Пытаюсь выяснить - в чем фронт сложнее?
С моей точки зрения и то и другое -- программирование. Разработка ПО.
Меняется лишь приложение, специфика.
Говоря в общем, вопрос сложности, в отрыве от конкретной задачи, некорректен.
Почему некорректен? Вот есть вопрос и проблема, можно привести примеры\опыт?
//специфика
Вот я и про специфику - в ней кроются детали)
Что есть такого на фронте, что делает его таким же сложным, как и сервер? Меня просто интересует пример, что там такого сложного. Я услышал один кейс, действительно сложный - это гугл-доксы, это действительно непросто написать во фронте) Но если вы посмотрите на бэк гугл-диска, то уверяю вас фронт покажется детскими капризами)
Или для гугл-карт, фронт сложный спорту нет, но бэк - это такой звездец там..
И еще: любой сеньер-бэк с 5+ лет опыта напишет вам андройд-приложуху и браузерный фронт на vue, пусть без верскти и красивых кнопок, но полнофункциональный и оптимизированный, котрый общается с 5+ млн других пользователей, дак еще и бэк для этого напишет, дак еще это все задеплоит и распараллелит, закажет серверов и настроит и запустит, расшардит базу и прикрутит редис и кликхаус
Нравится вам это или не нравится, но это сделает любой сеньер бэк, любой, кто называе себя сеньором) В обратную сторону очень не уверен) Фронты конечно понапишут CRUD-ов с джейсонками, но все это не скрасит ETL с 20ю своебразными интеграцими и ботлнеками по производительности, и ML рекоменадиями в ленту новостей (она кстати для фронта выглядит так рест-контроллер с 20-ю дто-шками) а для бэка - как лютый гемар с переписыванием спринга на корутины и неблокирующие сокеты, потому что 500 потоков уже забили русурсы.. а так да - для фронта - это как был рест контроллер так и остался.
ну по поводу любой — это спорно
но вот у меня сейчас есть проект у которого бек фронты писали, в базе таблички вида id :int, values: json — и в values навалены json с фронта, просто в кучу, ни миграций нихрена… фронт работает? работает, в ендпоинтах тупо выдача по селектам из базы....(рукалицо)
была задача — сделать чтобы поменьше тормозило в поиске, прям обнять и плакать...
Почитал ваши ответы ниже. У вас какая-то мания величия бэкенд инженера. Вы зачем-то изо всех сил пытаетесь нас убедить, что бэкенд сложнее, да любой сеньор бэкендер этот ваш фронтенд одной левой напишет, не приходя в сознание, а фронтендеры кроме как кнопки рисовать ничего не не могут и т. д. и т.п. Наверное это что-то личное.
Похоже вы не особо в теме чем вообще на фронтенде занимаются. Мой коммент об этом и был: не нужно преуменьшать сложность того, в чем вы не разбираетесь. Меряться, чей -end сложнее, я не буду, это детский сад какой-то.
А сложность она разная бывает. Пример могу привести. Вот есть сервис, у него есть клиентское веб приложение. Фронтенд это не только сайты, но и полноценные приложения с кучей бизнес логики (UI может быть кстати довольно простой). Иметь именно веб приложение может быть удобно как для юзера, так и для компании в плане обновлений. А тут еще выясняется, что многие клиенты работают в CRM, и им было бы намного удобнее иметь сильную интеграцию с CRM. Это значит приложение должно быть встроенным в CRM и использовать его API для поиска и обновления записей и прочего. Только вот все CRM разные, интегрироваться в них нужно по-разному (вплоть до того, что где-то вообще не браузер и JS, а приложение на дот нете). И в итоге приходится городить архитектуру, чтобы была максимальная базовая часть, и возможность интегрироваться "куда угодно" тем или иным способом. А потом кастомерам еще нужны API для кастомизации вашего приложения под свои нужды. И вот нужно все это развивать и поддерживать. С учетом миллиона особенностей всех этих CRM, которые еще и обновляются регулярно.
Опять же писать в браузере, это не то же самое, что писать в ОС, тут возможность сильно ограничены. Условно, вот тебе 2 API и крутись как можешь. А задачи типа: ваше приложение интегрировано в чужую страницу, юзер может открыть 10 таких страниц. Вы же не хотите, что они все долбили ваш сервис одинаковыми запросами. И когда меняется состояние в одной странице в других тоже должно. Нужна синхронизация между страницами браузера. Ну и много всего разного. Каждая из них по отдельности может и не такая сложная, но их очень много. Просто люди из других областей даже не думают о таких вещах, для них "да что там фронтенд - HTML/JS/CSS, запрос послал, JSON принял, страничку перерисовал, любой бэкендер справится".
И все, что я тут описал, это именно фронтенд, потому что этим занимаются фронтендеры. Ну да, девопсов у нас нет. Вместо настройки докер контейнеров в облаке фронтендер сидит и разбирается как настраивать всевозможную хрень в десяти разных CRM.
Чел забей, это хаб фронтовый. Люди в своём мирке живут.
Это тоже фронт. Если считать, что фронт=формошлепство, то можно сказать, что бэк=перекладывание json-ов.
Оцените, пожалуйста, сложность разработки браузерного аналога экселя (вроде Google Sheets). Фронтенднее некуда
Дословно, то что я написал: "бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений". А теперь подскажите, это типичная фронтенд задача? Или относится к сложным, исключительным кейсам? Сомневаюсь что первое. Если же второе, то сравните это по сложности с разработкой высоконагруженного, масштабируемого бэкенда с высоким уровнем доступности, отказоустойчивости, распределенными транзакциями, репликацией и шардированием данных.
Я так посмотрю, вы продолжаете накидывать?))
Ну давайте будем сравнивать тёплое с мягким. Сравнивайте тогда с фронтом где навалом математических расчётов для WebGL, векторных анимаций, полностью типизированным, реактивным, так же масштабируемым и портируемым на различные платформы (чтобы отдельно не писать приложения для Андроида и iOS), высокооптимизированным (поскольку мы, в отличие от бэкенда, не можем выбирать ТТХ девайсов на которых это приложение должно крутиться) и прочая-прочая...
У вас представление о фронтенде где-то на уровне 2010 года)) Типа на jQuery формочки клепать...
Почему вы продолжаете исключения (3d рендеры на фронте, математические рассчеты и тп) выдавать за правила? Тот пример что я привел с масштабируемым и отказоустойчивым бэком это типичный в 2023 году бэкенд проект. Вы же выдаете какие то "маргинальные" случаи пытаясь сделать вид что это типичные задачи фронта
Или относится к сложным, исключительным кейсам? ... Если же второе, то сравните это по сложности...
Тот пример что я привел с масштабируемым и отказоустойчивым бэком это типичный в 2023 году бэкенд проект.
Извините, но я после этого заканчиваю дискуссию с вами. Одно дело неуклюже то ли троллить, то ли пытаться набить себе цену; и совсем другое - заниматься подтасовкой своих собственных тезисов))
P.S. Если хотите "типичный фронтенд-проект в 2023", то из вышеперечисленного мной списка можете выкинуть только 3D (WebGL). Всё остальное - типичнее некуда.
Вы возможно меня недопоняли. "Или относится к сложным, исключительным кейсам? ... Если же второе, то сравните это по сложности..." - я не пишу тут что мой пример про бэкенд относится к этому кейсу, я писал это про фронтенд(считаете ли вы ваш пример сложным кейсом). Т.е. я мог вполне иметь ввиду сравнение сложного кейса фронта с типичным кейсом бэка.
Ок, давайте разберем оставшуюся часть ваших "показателей" сложности фронта:
1) "векторных анимаций" - это просто ложь, векторные анимации просто не юзаются повсеместно;
2) "полностью типизированным" - ээм...в бэке это просто по дефолту, об этом даже не задумываются, тк нет выбора;
3) "реактивность" - я правильно понимаю что под этим вы имеет ввиду взять готовый фреймворк?(я задаю этот вопрос без иронии, правда не в курсе)
Остается "масштабируемым", "портируемым" и "высокооптимизированным". Масштабируемость это часть портируемости как я понимаю.
В итоге сложность фронта это про оптимизацию и про портируемость. Всё. Говорить что покрытие этих двух аспектов это сложнее чем написать типичный высоконагруженный бэк - мягко скажем, сомнительное утверждение.
1) "векторных анимаций" - это просто ложь, векторные анимации просто не юзаются повсеместно;
Ну вы же сами признаетесь что не в курсе положения дел во фронтенде, откуда ярлык лжи тогда?))
В современном зоопарке разрешений экранов девайсов, векторная графика - вынужденная мера. Ну и как бы вполне логично, что в 2023 многим хочется анимировать интерфейс ("свистоперделки"). Вот и приходится sgv "на лету" генерировать.
2) "полностью типизированным" - ээм...в бэке это просто по дефолту, об этом даже не задумываются, тк нет выбора;
Ага. В том-то и дело что "нет выбора". А на фронте выбор есть. И приходится совмещать типизированные сущности с не типизированными. Грубо говоря, приходится ручками править не типизированные npm-пакеты (кстати, частенько вопреки их описанию). То ещё удовольствие... По сути приходится заниматься реверс-инжинирингом готовых плагинов (ну либо писать с нуля самому).
3) "реактивность" - я правильно понимаю что под этим вы имеет ввиду взять готовый фреймворк?
Нет. Это скорее архитектурный вопрос. Нужна ли шина событий для того или иного вида данных. На каком этапе загрузки должна включаться реактивность тех или иных компонентов. Нужно ли кэширование тех или иных данных. Роутинг, внезапно, из задач бэкенда стал фронтендом - всем подавай SPA или SSR.
Даже не так. Если раньше фронтенд действительно был только про представление, то сейчас это больше про логику и манипуляции с данными. И эти задачи он забрал как раз у бэка.
Масштабируемость это часть портируемости как я понимаю.
Нет. Это опять про архитектуру. Нужен мощный скелет логики, чтобы при добавлении новых компонентов надо было произвести минимум манипуляций - дабы не писать по несколько раз одно и то же.
Вы просто усиливаете мои убеждения. Т.е. вы на полном серьёзе, чтобы показать сложность разработки фронта, добавляете в свои примеры практики написания хорошего кода. Т.е. фронтед настолько однообразен что у вас нет просто достаточно примеров чтобы показать в чем его сложность заключается.
Типизация это про complex, а не complicated. Про векторные анимации допускаю что могу ошибаться. Про реактивность хороший аргумент.
В этом вашем бэк-энде я ни в зуб ногой, но видел как друг програмист "работал" и мнение имею.
Слушайте, да ваш бек-енд, это вообще лажа - сиди кнопки нажимай. То-ли дело сайдинг бить. Приведите мне пример такого-же сложного проекта в бэк-энде, как обить сайдингом трёх-этажное здание сложной конструкции (типичная задача для сайдингиста).
:)
Комбинация из множества возможных проблем и множества возможных их решений для задач бэкенда в разы выше чем для обивки сайдингов. Так же, когнитивные ресурсы требуемые для решения этих проблем тоже выше и выше шансы возникновения сценариев для которых нет готовых типовых решений. Вы сильно ошибаетесь, пытаясь иронизировать над тем что нельзя сравнивать по сложности фронт и бэк(или любые другие виды деятельности). Это очень распространенное заблуждение. Достаточно немного подумать чтобы понять это.
Признайтесь, вы же сайдинг никогда не били, правда?
Я, вот, имел такой опыт.
Когнитивные ресурсы там требуются несколько другие, это да, но вот шансы возникновения сценариев для которых нет готовых типовых решений вполне сравнимы.
Что касается сравнения разных видов деятельности, то мой поинт в том, что для сравнения чего-то не плохо бы разбираться в сравниваемом на одинаковом уровне.
Ну смотрите. Я сейчас занимаюсь фрилансом - через мои руки прошёл целый зоопарк проектов. Поэтому несколько субъективных(!) наблюдений:
Разделяйте вёрстку и фронтенд. Сейчас под вёрсткой подразумевают непосредственно html/css плюс какой-то примитивный js - модалки, всплывашки и т.п. Верстальщик сейчас должен уметь сделать типовой лэндинг "под ключ". А когда вам встречается именно "фронтенд-разработчик", то это с 95% вероятностью именно знание одного из реактивных фреймворков. И это уже не html-страница, а именно веб-приложение. В том числе и портируемое на другие платформы, благо инструменты для этого есть.
Именно фронтендер финализирует проект. А значит все конечные правки и баги предъявляются именно ему. А уж он или разбирается с ним самостоятельно, или переадресует их бэку. Зачастую, чем лишний раз дёргать другого спеца, быстрее самому что-то поправить. Т.е. "кругозор" у фронтендера априори должен быть шире.
Потребность во фронтендерах выше. В большинстве проектов над которыми я работал, был штатный бэкендер, а искали "опенсорсного фронтендера". Хотя я тоже думал, что по идее должно быть наоборот - порог вхождения во фронт, на первый взгляд, ниже чем в бэкенд. Но допускаю что это просто "ошибка выжившего".
Популярный в последнее время тренд - "надоело нищенствовать? войди в IT и зарабатывай как белый человек". Почему-то по всему инету тучи курсов именно по python, а не по js. Неужели
1 + '1'так отпугивает?
Вывод: на мой взгляд, развития нейросетей стоит "опасаться" больше бекэнедерам, чем фронтэндерам))
Популярный в последнее время тренд - "надоело нищенствовать? войди в IT и зарабатывай как белый человек". Почему-то по всему инету тучи курсов именно по python, а не по js. Неужели
1 + '1'так отпугивает?
Нет, это вопрос спроса и предложения. Школе, чтобы привлекать учеников, надо иметь много кейсов успешного трудоустройства. А для этого надо, чтобы хотя бы 10% учеников понимали, зачем и куда они попали, т.е. имели представление об индустрии и какой-то опыт. Заплатит такой человек за курсы js? Нет, потому что он и самостоятельно сможет ему научиться, и даже написать упомянутый выше "эксель", чтобы показывать и гордиться. Если хочется сделать интерфейс для апишки - выбирай, их открытых полно. А бэку нужен хотя бы фронт, не показывать же джсоны в постмане, ну и плюс психологически некая поддержка наставников и коллег, когда ваяешь непонятный черный ящик. Отсюда и количество курсов по бэкенду.
Меня недавно позабавил сайт очередного js-фреймворка astro, который пищит про то что они самые быстрые, но их лэндинг в фф тормозит при прокрутке будто я открыл гугл-таблицу на 10к строк на celeron d и 1g ram со своим несмотря на то что реальная машинка -- i7-10875h+32g. В браузерах на блинке этого ужаса не наблюдается, на удивление.
Другой прекрасный опыт был когда нужно было нарисовать тривиальную страничку с таблицей на сотню-другую строк с парой кнопкой на строчку. Я, как простой бэкендер, взял babel (для ts) и обычный bootstrap 5. На машине с i7 и 32g ram сборка webpack'ом проходила за "разумные" 5-10 секунд (все конфиги из документации соотв. проектов). Когда пришлось запустить эту сборку на чужом macbook air 13 с 8g ram выяснилось что комбинация из webpack, babel и bootstrap/sass не лезет в память от слова совсем.. Учитывая что дело было в лесу с хорошим интернетом уровня edge, огромным потерями и пирогами до секунды -- был очень удивлен. Статически собранный bootstrap и отключеный babel с переключением на tsc решили проблему, но впечатления остались.
Для сравнения, у меня при меньшем количестве памяти спокойно собираются проекты типа Gradle (2M cloc), Apache Tika (200k cloc), Quarkus (800k cloc)
Насчет полной типизации - есть языки со статической типизацией и динамической - тут исходя из разных факторов выбор, так что не аргумент (и я не фронт если что)
ну раз вы не фронт, объясню. "типизированный плагин (npm-пакет)" - означает что он написан на ts (TypeScript) и спокойно может быть интегрирован в проект на том же самом ts. если плагин написан на js - у вас тут же посыплются ошибки, связанные с отсутствием типов у данных в этом плагине. поэтому сейчас потихоньку все эти плагины переписывают на ts. но очень медленно и далеко не все. и вот в отношении них и пишут "полностью типизирован".
Я в последнее время с такими задачами начал сталкиваться все чаще и чаще, так что хз.
В таком случае типичная задача на бэкенде это «сходить в базу и вычитанное отправить в виде json/записать в базу принятый json». Что тоже нифига не rocket science, прямо скажем
А если сравнивать между собой продвинутый фронт с продвинутым бэком то там уже давно по сложности сопоставимые штуки.
Как правильно подметили ниже фронтенд это уже давно не формочка с кнопкой «Submit»
Мой друг работает бекендером в самой узнаваемой ит компании в РФ, и недавно жаловался мне на то, что они могут на бекенде весь день потратить на рассуждения о том, нужно ли передавать данные в виде пост запроса или пут (updateBanana), в каком виде передавать параметры банана для апдейта - прямо в урле или дате, а также какой код отдавать при ошибке. Видимо, под термином "сложность" имеется ввиду написание однообразных ручек и перекладывание жейсонов
я что-то 2 года во фронте работаю, но с CSS и HTML имею дело от силы в 5% своего раб. времени, вы лукавите господин, за друга то, или ваш друг балоджун. Все таки вы плохо понимаете что такое фронтэнд разработка.
а вообще , бэк похож на помощника бегуна, который стоит на дистанции и ждет когда бегун рядом пробежит и попросит водички, а помощник с ящечка любимую водичку бегуна достанет и отдаст.
(чутьне поперхнулся)
а в банковских сервисах, кто у нас бегун? текстовый интерфейс АБС? или приложеньице банковское?
или может фронт считает проценты по кредитам?
не знаю , с банками не работал, в продукте работаю, вся бизнес логика на стороне фронта пишется, на бэке бизнес-логики не более 10%, остальное фронт, показать, посчитать и т.д. Какие-либо валидаторы может и написаны на бэке типа авторизации/аутентификации , но как ни крути большая часть логики на фронте , а так как помимо логики надо еще все отрисовать и еще чтобы быстро, и максимально оптимизированно, это все фронт. Это, повторюсь, в продукте, как это в различных data сервисах я не знаю. Может опыта мало, так как пару лет всего работаю, но как вижу то что делаем каждый день, то и говорю.
ну у вас частный случай
я вот работал в продукте тоже, сервис обмена электронными документами (ненашенский)
фронт — это текстовый редактор как google docs, а бэк это огромная машина обрабатывающая интеграции, рассылки документов, заполнение формул, цифровые подписи, работу по блоксхемам и прочее-прочее прочее
фронт тоже очень сложен, но бек это не помощник который данные приносит, это основная часть продукта которая может даже без фронта работать, отправив документ из стороннего сервиса через интеграцию можно получить результат в третьем сервисе, на почту и нотариусу, не трогая штатный фронт вообще (хотя большая часть пользователей фронтом конечно пользуется)
И этот человек пишет о том что кто-то плохо понимает фронтенд разработку.
ИИ заменит не разработчика, ИИ заменит WWW
Ждем новых серий: "Конец бэкенд-разработки" и "Конец мобильной разработки" и т.д.
Так и будет. ГПТ и шумиха вокруг него, - это просто неимоверный скачок объёма инфошума статей, размышлений и мечтаний на эту тему. Потом пойдут персонализированные GPT, которые умеют держать личный рабочий (личный?) контекст юзверя с помощью каких-то накормленных параметров, потом пойдут статьи об опасности (всё у нас делают клауды, а, значит, инфа попадает в сесть), потом, - о том, что GPT слишком много знает, и ещё 100000 тем :)))
А потом каждый будет круглосуточно висеть на связи со своим чатом и не расставаться с ним ни на минуту. Только он поймет меня, тонкую душевную организацию. Только он посоветует что делать и что говорит надо делать точно. Такой сценарий в фильме "Она" (2013) показан, общение с голосовым помощником переросло в романтические круглосуточные. То есть идеальная личная секта, решения принимает чат, а человек фанатично выполняет. Соответственно у владельца чата полная власть над миром.
Оно частично уже и приходит. Ютуб, например, формирует информационный пузырь по интересам после просмотра пары роликов и достаточно точно угадывает ролики для последующего просмотра.
Я вот кстати, практически уверен, что сейчас есть люди, которые думают, чтобы как-нибудь разместив что-нибудь в общедоступных данных, отравить будущую обучающую выборку ChatGPT и побудить его писать код с уязвимостями или что-то в таком духе.
Понятно, что это куда труднее, чем какой-нибудь манипуляция поисковой выдачей. Может даже окажется не осуществимо на практике, но мысли такие наверняка у кого-то есть.
Я, как фронтендер, только рад буду если нейросети нагрузят этой генерацией морд. Это значит ещё больше возможностей заработать. Это как с толпами желающих по быстрому войти в IT в погоне за длинным рублем. Всю эту халтуру потом надо кому-то править, переделывать и приводить в божеский вид.
Тут ИМХО другая проблема - ИИ действительно сможет в будущем заменить джуна (+/-), но получается, что нужны сразу миддлы. А как стать миддлом сразу без начального уровня - и без проектов, которые можно показать - вот в чем нюанс. Хотя, возможно, просто произойдет интеграция и сдвиг в понимании категорий - джунам придется качественно общаться с ИИ и стать как бы миддлами, с миддлов будут спрашивать как сейчас с сеньоров, а сеньорам придется стать гуру )))
Скорее "ИИ" заменит инструменты с которыми работает джун. В довесок еще будет такой суперконструктор приложений/сайтов/интерфейсов (простых, и почти простых). Итоговый результат станет дешевле со времением.
Т.е. джунов нужно будет больше, т.к. удастся завлечь в индустрию больше клиентов, но навыки этим джунам будут нужны немного другие. И чем дальше - тем всё более другие.
Закон Мура вполне можно экстраполировать на GPT, только скорость оптимизации продукта будет много меньше, чем два года, ведь говорящая вещь сама себе поможет. Вдвое за год, вчетверо? о, Боже
Беспокоиться надо начинать, когда бот научится вносить изменения в уже существующий проект, ничего при этом не сломав. Это, наверное, процентов девяносто от вообще всех человекочасов всех программистов мира. Вот тогда - да, беда.
Дичайше плюсую. Но если порассуждать дальше- а какой проект сможет максимально утилизировать нейросетевую генерацию кода в плане пользы для бизнеса? По идее, тот, который 1) разбит на достаточно небольшие и простые куски(типа микросервисов, но не обязательно они) 2) эти куски идеально задокументированы в плане контрактов "какой JSON на вход, какой на выход, какие побочные эффекты типа логов, бд и прочего". В таком проекте в теории можно с помощью ChatGPT тупо менять куски с нуля, если п.2 поменялся, вместо допиливания. "Чем старое чинить, проще новое купить". Проблема только в том, что проектов, подходящих под такое описание - сами понимаете сколько. А старые монолиты- быстрее разобраться самому и починить, чем объяснить сетке(на данный момент) и совершенно не факт, что такие объяснения не будут, например, нарушать NDA. Вот кто, по идее, от нейроджунов выиграет- это всякие стартапчики с идеями, где скорость показа прототипа решает, легаси нет- разбей свой проект на модули правильно, и вперёд.
А вот если бы Семён Альтман слушал Егора Летова и не прогуливал историю, то он бы знал, что "Винтовка -- это праздник" а не фантазировал про безусловный базовый доход
https://ic.pics.livejournal.com/guruken/3 263 337/4711/4711_800.jpg
щютка
Знаю достаточно много кейсов, которые исчезли или сильно ужались с появлением новых технологий:
- Кучер и грум.
- Трубочист.
- Зажигатель масляных фонарей.
Из более современных:
- Вычислитель (расчётчик).
- Телеграфисты
Трубочист не исчез, а взял себе новый инструмент. Вместо щётки -- моторный компрессор.
только труб стало в сотни раз меньше, которые надо чистить
Зато начали чистить компрессорами улицы и переходы. Только что мимо такой бригады проходил.
Одно дело, если вы 10 лет учились в школе чтобы поступить в институт, потом 5-6 лет учились в институте и работали потом 10-15 лет, чтобы сегодня называться "сеньором разработчиком" и получать достойную для потраченных на учебу лет зп. И тут вам говорят: "ваши услуги больше не нужны, перепрофилируйтесь и обучайтесь заново". И совсем другое дело, когда вы вчера научились чистить трубы.
Трубочист подпадает под кейс "сильно ужался"
Не только кучер. Все люди, занятые в технологической цепочке обслуживания лошадей. Кто-то больше, кто-то меньше.
Не просто трубочист. Кто-то наверняка делал оборудование для трубочистов, одежду.
Кто-то ещё производил маслянные фонари. Фитили. Стёкла. Масло. Зажигалки для фонарей.
С расчётчиками и телеграфистами сложнее, может быть производство логарифмических линеек/телеграфных ключей обанкротилось или сменило профиль.
Насчет трубочиста это вы погорячились. В моей деревне все чистят каминные трубы, я тоже стараюсь хотя бы раз в два года вызывать трубочиста. Трубочист теперь уже не тот, кроме составной щетки и компрессора у него и робот с телекамерой. И работа его стоит не 3 копейки как раньше, в сентябре платил 75 евро за пару часов его работы.
Некорректное сравнение. Корректно было бы сравнивать сколько раньше (до Первой мировой войны, например) было трубочистов на 1000 печных дымоходов и сколько сейчас + сколько тогда эта совокупность трубочистов получала денег за свой труд (в перерасчете на какие-то простые продукты вроде куриное яйцо, пакет молока, буханка хлеба) и сколько они получают сейчас. Тогда будет видна роль автоматизации в этой профессии.
С трубочистом не согласен. Зарплата трубочиста в Чехии, - запросто на уровне 2-5 тысяч долларов с тем, что фиг найдёшь и записываться надо за несколько месяцев :))) ну, зажигатель масляных фонарей, - парочка как развлекалово для туристов остались, а так согласен.
И что вы хотите сказать этим, что в этом нет проблемы? Есть и явная и скрытая безработица. Рынок услуг и перепродаж хлама всякого.
Эстраполируя можно дойти до момента, когда человеку вообще не будет работы ни в каком виде.
Полностью исчезла профессия сельского колдуна!
В некоторых местах эту обязанность ещё выполняли кузнецы, а теперь нет колхозных кузниц, поэтому даже у кузнецов не осталось такой функции.
Пляжный фотограф
Наборщик перфокарт.
Фронтенд, бэкенд... Не будет этого разделения. Будет связка ИТ-Консультант -> GPT8+ -> RAD.
Пользователю проще описать бизнес правила с помощью описаний интерфейса - "Если лимит превышен - показывать сообщение и не разрешать операцию". Бакенд и прочий JSON его не интересует. RAD на этом принципе уже сейчас живет и в эту сторону развивается, его цель - автоматически делать бэкенд на основании описания ползовательского интерфейса.
Когда какой нибудь open.ai скрестит ChatGPT и RAD - тогда все переквалифицируются в консультанты.
Чем-то похоже на работу в 1С или SAP ABAP. Бакенд и он же фронтенд, правится не сложно, главное понять что нужно получить в результате. Например почему не сходится какой-нибудь баланс в отчете за 5 лет, где каждый год менялась форма управленческого отчета, налоги и правила. А отчет должен пройтись по исходным данным с учетом алгоритмов действовавших на тот момент времени и совпасть с ожиданиями заказчика.
За последние несколько месяцев я разговаривал со многими начинающими разработчиками, которые всё больше и больше беспокоятся об ИИ. Они видят всё более впечатляющие демонстрации таких инструментов, как GPT-4, и обеспокоены тем, что к тому времени, когда они освоят HTML/CSS/JS, для них не останется рабочих мест.
Так может что-то полезно изучат. Фронтендом должны заниматься дизайнеры, а не отдельные разработчики. Так будет проще всему человечеству и если дизайнером проще будет работать с фронтендом, то это как по мне плюс
Что-то мне подсказывает, что вы не относитесь ни к первым, ни ко вторым)
Кому должны? Вам? У вас представление о современном фронтенде, как у 5 летнего ребенка. Т.е никакого. Что-то от кого-то слышали, но не можете вспомнить что именно :)
Конец фронтенд-разработки
мне уже надоела распространяемая в сети паника
Ну да, ну да, я так и поверил
Калькулятор отвечающий, что стоп-кран в самолете должен быть красного цвета и которого сейчас почему то называют интеллектом ещё далеко до человеческого разума. Просто сейчас на этом кто то делает огромные деньги, деньги на дураках.
мне кажется проще выучить html/css чем копаться в этом gpt.
Соглашусь.
Благодаря ИИ появится новый уровень абстрактности для разработчика. У меня несколько проектов старых заброшенны. С ChatGPT я бы их закончил в какой-то степени.
Мне сейчас гпт очень помогает. Прямо ОЧЕНЬ, но без понимания, что он там пишет, можно попасть в яму. К сложным вещами он также не приспособлен. Об этом уже писали, что он хорошо отрабатывает решённые задачи, а нерешённые не особо или вовсе нет.
Ты не понял шутки и решил накатать огромную статью?
Эту статья быда написана с использованием chatgpt расходимся )
Мне (явно не первому) что-то подобное сказал профессор в 91 году. Мол, учить вас - только портить, все равно через год-два CASE (Computer-aided software engineering) заменит живых программистов. С тех пор 32 года прошло - а программисты никуда не делись...
OpenAI: Number of employees: 375 (2023)
Не понимаю с чего бы фронтендерам беспокоиться, рынку всегда нужны были оригинальные, интересные интерфейсы. При этом технологии, подходы, дизайн постоянно меняется. Чат будет решать узкие задачи и сохранять крупицы времени.
Теперь заглянем в девопс/архитектуру например, поднять инфраструктуру, выбрать архитектурные паттерны, учесть ботлнеки, оптимизировать бизнес-затраты. Не сложно представить, как задачи планирования, развертывания, тестирования, масштабирования, миграции сложнейших кластеров полностью лягут на плечи гпт-стайл чатов.
Начнем с того, что людей с достаточным опытом серьезный дефицит
Люди боятся, ошибаются, тратят время на предотвращение ошибок
Люди с трудом воспринимают усложнение, все просто не умещается в голове
Чат заранее знает, сколько потоков поддерживает БД, знает почему и никогда об этом не забывает, он знает, как работает распределение ресурсов в кубах и как не оставить процесс в блокировке. Нужно хорошо потрудиться, чтобы придумать, с чего бы он не мог поднять набор сервисов, связать их, сконфигурировать, выбрать лучших хостов, мановением пальцев предоставить DNS или даже учесть цель сбора данных, интегрированные процессы Bi или машинного обучения. Насколько тривиальны для него не только restful, но любые сервисы с четкой моделью.
Вы извините меня, но в формуле "рост производительности профессии-нейм за счет внедрения ИИ-ассистентов" все почему-то упускают из вида мысль, что емкость рынка (для сайтов, 3d-моделей или анимации, текстов — чего угодно) не повысилась так же резко, как продуктивность людей с появлением GPT 3 и GPT 4.
Следовательно, кому-то придется ужаться. Или всем в зарплатах, или кто-то сохранит зарплату/доход (или даже увеличит), а кто-то пойдет с рынка вон.
Это так сложно что ли? Или это какой-то профессиональный кретинизм у всех срабатывает в стиле "Я — военный, я думаю только как танчики по полю боя двигать (окей — еще про разведку, логистику, снабжение, моральный дух и кучу подобных вещей), а что там в мире творится — пусть политики за меня думают". Это какой-то сюр.
Я тоже считаю, что программистам пока нечего бояться. Изменения будут и придется изучать новые инструменты, которые станут доступны благодаря ИИ, но это происходит в ИТ постоянно. Языковые модели пока лишь демонстрируют способность генерировать синтаксически верный текст, к которому относится и код. Время от времени он выдает бред, потому что смысла написанного (т. е. причинно-следственных связей) он не понимает. Была статья, что все ИИ сейчас обладают только ассоциативным мышлением из-за модели обучения по размеченным данным. Пока условный ChatGPT не обладает разумом, сравнимым с человеческим, заменить программистов, как и представителей других интеллектуальных профессий, он не сможет. А если такой ИИ появится, потеря работы - это последнее, чего я бы боялся, потому что это полностью изменит наш мир.
Если за этим БЯМ все равно нужно тщательно проверять, то нафига он нужен такой? Пока не будет инструмента способного создать полноценный продукт все это игрушки и не более. Сколько мы уже слышали про очередную технологию, которая должна кого то заменить? Не припомню ничего выстрклившего. Инструмент и не более - да.
Задача для chatgpt4:
напиши программу на brainfuck которая бы печатала в консоль симовлы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю". Символы должны быть выведены в шесть строк.
Ответ:
Вот программа на Brainfuck, которая печатает символы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю" в шесть строк:
```
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->[<]<-]>>.
>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
```
В данной программе используются команды, которые увеличивают/уменьшают значение ячеек памяти, переходят к ближайшей ячейке, управляют вводом/выводом данных, а также условные операторы.
Знаете что выводит эта программа?
Еще все забыли что в фронтенде как таковом потребность может снизиться, если можно просто сделать АПИ, манифест для ИИ с описанием, как этот АПИ использовать, и текстовый/голосовой интерфейс вместо фронтенда, где человек объясняет, что ему нужно, а ИИ сам составляет все нужные запросы. Конечно, это работает не всегда и не для всего, но тем не менее.
Сколько разных case/rad/low-code/no-code было за последние три десятилетия.. И все упирались в одну простую вещь: написать спецификацию для чего-либо нетривиального и/или мало-мальски нестандартного и довести до состояния когда тул выдает что-то близкое к тому что хотелось получить существенно сложнее и дороже (и объемнее) чем сразу код с использованием нормальных инструментов.
Мн очень понравилась эта фраза " Если Вы не программист, Вы не сможете сказать, что верно, а что нет. "
Следует ли из этого что "Если Вы программист, то Вы можете сказать, что верно, а что нет." И если следует, то как это соотносится с различными глюками программ? Или их сделали не-программисты?
"покуривая в сторонке"
У вас это первый раз да?
С уважением, php- разработчик.
Шаблон написания таких статей
Заголовок - мы все скоро умрем
На самом деле я так не считаю
Скоро - понятие растяжимое
Ссылка на блог о моей жизни
Но я склоняюсь и к противоположному мнению
Думаю, мы должны быть осторожны в обоих случаях
ИМХО, всегда нужно искать тех, кому выгодна та или иная позиция. В данном случае, купить фуллстек разработчика по цене фронтендера, хм, звучит заманчивой идеей.
GPT не заменит разработчиков. Хотя инструменты ИИ могут выполнить определенные задачи лучше, чем люди, разработка программного обеспечения - это комплексный процесс, требующий широкого спектра навыков и знаний. Разработчики также предоставляют услуги, которые не могут быть заменены ИИ, такие как консультирование, дизайн пользовательского интерфейса и управление проектами.
На одном GPT свет клином не сошелся... будут и другие.
Обучение ИИ, создание и поддержка инструментов и систем, которые используются для обучения моделей ИИ. Без высококвалифицированных разработчиков, прогресс в области ИИ может значительно замедлиться или остановиться. ИИ не может заменить человеческое восприятие и творческий подход к решению задач. Некоторые задачи могут быть автоматизированы с помощью ИИ, разработчики будут продолжать продвигать инновации в технологиях ИИ и играть важную роль.
ИИ, как и любой другой инструмент, имеет свои ограничения. Он может быть очень полезным для выполнения рутинных задач или обработки больших объемов данных, но не может заменить человеческое внимание, интуицию и креативность при решении сложных проблем.
Если бы фронтенд ограничивался созданием формочек, то он уже давно был бы мертв, даже без всяких ИИ. Эта картинка помогает понять разницу между объемом задач, которые способен решать современный фронтенд и "формошлепством".
Дело в том, что я фронтенд разрабочик уже 5 лет и все это время постоянно приходится что-то изучать. Фронтенд - это огромная экосистема.
кружочки забавные, ух какой фронтенд…
давайте самые интересные части приведу, прямо костяк фронтендовых сфер
usb, speech, midi, fido, gamepad, push, vibration, file,geo-location, mp3
гигантская экосистема, да, а если еще туда какихнить умных слов накопипастить то и кобол приплести можно как жалкого помощника фронтов
Ну уж нет, формошлёпы используют, как минимум, следующее:
HTML5 forms, wai-area, ECMAScript 2015, CSS, UI Events, DOM, fetch
Без этого тупо нормальную форму не сделать для произвольного API. И это не весь список, это просто что мне на глаза попалось сразу же...
Всегда удивляюсь слишком категорически настроеным личностям. Наш профессор из университета слишком писсимистичен : "ИИ - это будущее, программисты скоро станут не нужны". Полностью согласен с вашей статьёй. Жду ещё больше интересных)
Конец фронтенд-разработки