Исследователи поясняют, что в будущем будет несложно производить видео, в которых генеральный директор объявит о значительном снижении прибыли компании, приведя к миллиардным потерям доли на рынке. При помощи таких средств можно создавать контент, где лидер страны станет угрожать военными действиям, что может спровоцировать геополитический кризис.
А может быть это наоборот хорошо? Вам не кажется что проблема как раз в том, что из-за одного твита можно обрушить стоимость акций корпорации, или спровоцировать полит. кризис? Может лучше пустить все на самотек, ничего не регулируя, тем самым сделав более устойчивыми и стабильными и рынок и международные отношения?
Комбинация из множества возможных проблем и множества возможных их решений для задач бэкенда в разы выше чем для обивки сайдингов. Так же, когнитивные ресурсы требуемые для решения этих проблем тоже выше и выше шансы возникновения сценариев для которых нет готовых типовых решений. Вы сильно ошибаетесь, пытаясь иронизировать над тем что нельзя сравнивать по сложности фронт и бэк(или любые другие виды деятельности). Это очень распространенное заблуждение. Достаточно немного подумать чтобы понять это.
Ну, так то вы правы. Виноват, под "типичной задачей фронта/бэка" имел ввиду продуктовые проекты более менее крупных компаний. Кстати, то что не набирается 1000 рпс - не значит что бэк не пишется под то чтобы он справлялся с этой нагрузкой.
Вы просто усиливаете мои убеждения. Т.е. вы на полном серьёзе, чтобы показать сложность разработки фронта, добавляете в свои примеры практики написания хорошего кода. Т.е. фронтед настолько однообразен что у вас нет просто достаточно примеров чтобы показать в чем его сложность заключается.
Типизация это про complex, а не complicated. Про векторные анимации допускаю что могу ошибаться. Про реактивность хороший аргумент.
Вы возможно меня недопоняли. "Или относится к сложным, исключительным кейсам? ... Если же второе, то сравните это по сложности..." - я не пишу тут что мой пример про бэкенд относится к этому кейсу, я писал это про фронтенд(считаете ли вы ваш пример сложным кейсом). Т.е. я мог вполне иметь ввиду сравнение сложного кейса фронта с типичным кейсом бэка. Ок, давайте разберем оставшуюся часть ваших "показателей" сложности фронта: 1) "векторных анимаций" - это просто ложь, векторные анимации просто не юзаются повсеместно; 2) "полностью типизированным" - ээм...в бэке это просто по дефолту, об этом даже не задумываются, тк нет выбора; 3) "реактивность" - я правильно понимаю что под этим вы имеет ввиду взять готовый фреймворк?(я задаю этот вопрос без иронии, правда не в курсе) Остается "масштабируемым", "портируемым" и "высокооптимизированным". Масштабируемость это часть портируемости как я понимаю. В итоге сложность фронта это про оптимизацию и про портируемость. Всё. Говорить что покрытие этих двух аспектов это сложнее чем написать типичный высоконагруженный бэк - мягко скажем, сомнительное утверждение.
Почему вы продолжаете исключения (3d рендеры на фронте, математические рассчеты и тп) выдавать за правила? Тот пример что я привел с масштабируемым и отказоустойчивым бэком это типичный в 2023 году бэкенд проект. Вы же выдаете какие то "маргинальные" случаи пытаясь сделать вид что это типичные задачи фронта
Дословно, то что я написал: "бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений". А теперь подскажите, это типичная фронтенд задача? Или относится к сложным, исключительным кейсам? Сомневаюсь что первое. Если же второе, то сравните это по сложности с разработкой высоконагруженного, масштабируемого бэкенда с высоким уровнем доступности, отказоустойчивости, распределенными транзакциями, репликацией и шардированием данных.
Не удивлюсь если весь этот текст был написан для одного вброса на вентилятор: "Удручающе большое количество людей в нашей отрасли считают, что бэкенд значительно сложнее или комплекснее, чем фронтенд, что «настоящее» программирование происходит именно на сервере. Это, конечно, чепуха.". И автор далее подкрепляет свой тейк частным случаем. Ну с таким уровнем аргументации я тоже могу привести аналогичный частный пример. Мой друг работает фронтендером в самой узнаваемой ит компании в РФ, и недавно жаловался мне на то, что они могут весь день с дизайнером потратить на рассуждения о том, какого цвета будет кнопка. Если под терминином "сложность" имеется ввиду такие мучения в выборе цвета и расположения элементов - то согласен с автором статьи. В противном случае, имхо, бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений.
Как этот дядька ****** со своими кликбейт статьями про невероятные открытия российских ученых, которые никак не верифицируются и остаются в лучшем случае на бумаге. Как на Хабре скрыть публикации конкретного автора?
Я правильно понимаю, что вы буквально пишете следующее: "Ни человеку ни нейросети нельзя писать код т.к. это нарушает чью-то лицензию."? Потому что ЛЮБОЙ код по такой логике нарушет лицензию. Ладно, давайте скажу все прямо, а то метод Сократа в онлайн переписке с такой задержкой между ответами слишком непродуктивен. Человек учит программирование читая чей-то код который под лицензией, куски кода из книг которые под лицензией, изучая курсы код которых тоже под лицензией. Потом на основе собранных обобщенных зананий пишет свой код. Всё что вы читаете - влияет на ваше поведение в будущем, на результаты вашего труда. И если вы хотите чтобы люди не использовали код под лицензией не нарушая лицензию, нужно в лицензии прописать запрет на чтение этого кода. Другого способа решить проблему впитывания знаний мозгом чтобы они не влияли на будущий программный код который будет писать человек или нейросеть - нет. Это во первых. Во вторых, вы просто заблуждаетесь считая что то, что пишет Copilot нарушает лицензию именно вашим описанным способом, потому что чтобы доказать это в суде вам нужно будет доказать что Copilot имел умысел в копировании чьего-то кода. Удачи вам в доказывании того что нейросеть имела какой-либо умысел. Если же вы считаете что Copilot прочитав чей то код под лицензией, далее будет его копипастить в своих ответах - то вы просто не знете как работают нейросети. Вы приводите пример с риверс инжинирингом программы - я вам говорю что ваш пример не имеет ничего общего c текущей статьей и Copilot потому что Copilot не так работает.
Не понял к чему этот риторический вопрос. Вы тоже не сможете постоить самолет. Означает ли это что вы неразумны?
А может быть это наоборот хорошо? Вам не кажется что проблема как раз в том, что из-за одного твита можно обрушить стоимость акций корпорации, или спровоцировать полит. кризис? Может лучше пустить все на самотек, ничего не регулируя, тем самым сделав более устойчивыми и стабильными и рынок и международные отношения?
Чел забей, это хаб фронтовый. Люди в своём мирке живут.
И этот человек пишет о том что кто-то плохо понимает фронтенд разработку.
Комбинация из множества возможных проблем и множества возможных их решений для задач бэкенда в разы выше чем для обивки сайдингов. Так же, когнитивные ресурсы требуемые для решения этих проблем тоже выше и выше шансы возникновения сценариев для которых нет готовых типовых решений. Вы сильно ошибаетесь, пытаясь иронизировать над тем что нельзя сравнивать по сложности фронт и бэк(или любые другие виды деятельности). Это очень распространенное заблуждение. Достаточно немного подумать чтобы понять это.
Ну, так то вы правы. Виноват, под "типичной задачей фронта/бэка" имел ввиду продуктовые проекты более менее крупных компаний. Кстати, то что не набирается 1000 рпс - не значит что бэк не пишется под то чтобы он справлялся с этой нагрузкой.
Вы просто усиливаете мои убеждения. Т.е. вы на полном серьёзе, чтобы показать сложность разработки фронта, добавляете в свои примеры практики написания хорошего кода. Т.е. фронтед настолько однообразен что у вас нет просто достаточно примеров чтобы показать в чем его сложность заключается.
Типизация это про complex, а не complicated. Про векторные анимации допускаю что могу ошибаться. Про реактивность хороший аргумент.
Вы возможно меня недопоняли. "Или относится к сложным, исключительным кейсам? ... Если же второе, то сравните это по сложности..." - я не пишу тут что мой пример про бэкенд относится к этому кейсу, я писал это про фронтенд(считаете ли вы ваш пример сложным кейсом). Т.е. я мог вполне иметь ввиду сравнение сложного кейса фронта с типичным кейсом бэка.
Ок, давайте разберем оставшуюся часть ваших "показателей" сложности фронта:
1) "векторных анимаций" - это просто ложь, векторные анимации просто не юзаются повсеместно;
2) "полностью типизированным" - ээм...в бэке это просто по дефолту, об этом даже не задумываются, тк нет выбора;
3) "реактивность" - я правильно понимаю что под этим вы имеет ввиду взять готовый фреймворк?(я задаю этот вопрос без иронии, правда не в курсе)
Остается "масштабируемым", "портируемым" и "высокооптимизированным". Масштабируемость это часть портируемости как я понимаю.
В итоге сложность фронта это про оптимизацию и про портируемость. Всё. Говорить что покрытие этих двух аспектов это сложнее чем написать типичный высоконагруженный бэк - мягко скажем, сомнительное утверждение.
Да, а фронт это всего лишь включение определенных rgb пикселей на мониторе. Отличный уровень дискуссии.
Почему вы продолжаете исключения (3d рендеры на фронте, математические рассчеты и тп) выдавать за правила? Тот пример что я привел с масштабируемым и отказоустойчивым бэком это типичный в 2023 году бэкенд проект. Вы же выдаете какие то "маргинальные" случаи пытаясь сделать вид что это типичные задачи фронта
Дословно, то что я написал: "бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений". А теперь подскажите, это типичная фронтенд задача? Или относится к сложным, исключительным кейсам? Сомневаюсь что первое. Если же второе, то сравните это по сложности с разработкой высоконагруженного, масштабируемого бэкенда с высоким уровнем доступности, отказоустойчивости, распределенными транзакциями, репликацией и шардированием данных.
Нет, это вы, по моему, путаете фронтенд и фуллстак разработку.
Не удивлюсь если весь этот текст был написан для одного вброса на вентилятор: "Удручающе большое количество людей в нашей отрасли считают, что бэкенд значительно сложнее или комплекснее, чем фронтенд, что «настоящее» программирование происходит именно на сервере. Это, конечно, чепуха.". И автор далее подкрепляет свой тейк частным случаем. Ну с таким уровнем аргументации я тоже могу привести аналогичный частный пример. Мой друг работает фронтендером в самой узнаваемой ит компании в РФ, и недавно жаловался мне на то, что они могут весь день с дизайнером потратить на рассуждения о том, какого цвета будет кнопка. Если под терминином "сложность" имеется ввиду такие мучения в выборе цвета и расположения элементов - то согласен с автором статьи. В противном случае, имхо, бэкенд разработка несравнимо сложнее в среднем и в сравнении самых сложных кейсов их обоих направлений.
Эти изображения сгенерированы нейросетью. Отличная попытка chatgpt.
Выглядит круто. Знаете ли вы его аналоги для Fastapi?
Как забанить автора? Почему статьи с достоверностью уровня Яндекс.дзен проходят модерацию?
Ребята большие молодцы, проделана огромная работа.
Как этот дядька ****** со своими кликбейт статьями про невероятные открытия российских ученых, которые никак не верифицируются и остаются в лучшем случае на бумаге. Как на Хабре скрыть публикации конкретного автора?
Я правильно понимаю, что вы буквально пишете следующее: "Ни человеку ни нейросети нельзя писать код т.к. это нарушает чью-то лицензию."? Потому что ЛЮБОЙ код по такой логике нарушет лицензию. Ладно, давайте скажу все прямо, а то метод Сократа в онлайн переписке с такой задержкой между ответами слишком непродуктивен. Человек учит программирование читая чей-то код который под лицензией, куски кода из книг которые под лицензией, изучая курсы код которых тоже под лицензией. Потом на основе собранных обобщенных зананий пишет свой код. Всё что вы читаете - влияет на ваше поведение в будущем, на результаты вашего труда. И если вы хотите чтобы люди не использовали код под лицензией не нарушая лицензию, нужно в лицензии прописать запрет на чтение этого кода. Другого способа решить проблему впитывания знаний мозгом чтобы они не влияли на будущий программный код который будет писать человек или нейросеть - нет.
Это во первых. Во вторых, вы просто заблуждаетесь считая что то, что пишет Copilot нарушает лицензию именно вашим описанным способом, потому что чтобы доказать это в суде вам нужно будет доказать что Copilot имел умысел в копировании чьего-то кода. Удачи вам в доказывании того что нейросеть имела какой-либо умысел.
Если же вы считаете что Copilot прочитав чей то код под лицензией, далее будет его копипастить в своих ответах - то вы просто не знете как работают нейросети.
Вы приводите пример с риверс инжинирингом программы - я вам говорю что ваш пример не имеет ничего общего c текущей статьей и Copilot потому что Copilot не так работает.
Слышал, только причем тут Copilot?