Общая тенденция развития технологий характеризуется рывками и спадами. Рассмотрим, например, массовое перемещение человеческих тел. Изначально применялись лошади и повозки, которые постепенно стали сложными, и эта технология превратилась в отдельную индустрию. Затем внезапно появились поезда. Про лошадей быстро забыли, и фокус сместился на новое направление. Пар стал объектом исследований и превратился в сложную науку. Параллельно развивались дизель и электричество. В определенный момент паровые двигатели ушли в прошлое, и все перешли на дизель и электричество. Аналогично сейчас происходит переход на электромашины, требующие значительно меньшего количества жидкостей.
Технологии эволюционируют и функционируют, а новые технологии их полностью заменяют. Считаю, что сейчас наступает эпоха, когда технологии фреймворков и Электрона могут быть вытеснены генеративными AI. Рассмотрим несколько примеров.
Как и с нашими паровозами и автомобилями, языки программирования развиваются, функционируют и устаревают. Во время моего обучения в университете, акцент делался на великих Java и C#. В нашей группе большинство были убежденными приверженцами C#.
После того, как мы закончили учёбу и некоторые из нас ушли работать на втором и третьем курсе, мы быстро поняли, что знание языка ещё ничего не доказывает, поскольку с языком нужно было знать инструменты разработки и различные фреймворки. Тогда, работая в МЭСИ, я начал использовать новомодную функцию Generics, чтобы написать свой первый DLAC: Data Logic Access Component. В 2005 году это было новомодным веянием. В отличие от всяких там безмозглых PHP-проектиков, которые повально подвергались SQL-инъекциям из-за запросов типа 'SELECT * from user where name like '.$input.' and enabled = true', мы, шарписты, делали всё по-другому. У нас были классы, которые оборачивали наши Entity в хорошие обёрточки, создавали правильные SELECT-запросы и позволяли работать с классами. При этом все запросы были параметризированы по умолчанию, и, поскольку мы писали приложение для студентов университета, нам нужно было убедиться, что нас не взломают. (МЭСИшники тех годов могут всплакнуть)
На своей первой работе я просто молился на эти DLACи и жить без них не мог. Со временем я узнал, что существуют другие подобные фреймворки. В 2009 году в мире появился NHibernate, переписанный на .NET от Hibernate, который существовал с 2001 года.
С тех пор я пристально следил за развитием .NET. Я прилежно учил новые технологии, такие как WCF, WPF и прочие радости версии 3.5. Я воодушевлённо ждал нового релиза 4.0 и устанавливал все обновления, внимательно читая release notes. Я ахнул, когда Scott Hanselman показал, что ASP.NET становится открытой платформой и все исходные коды выкладываются на GitHub. Я был в авангарде изучения .NET…
А потом мне показали Golang. И я понял, что я был машинистом старого доброго паравоза.
Паровоз медленно тянул бесконечные стек-трейсы в моих приложениях. Технологии, с которыми я работал, умирали, когда сами разработчики из Microsoft прекращали их поддержку. WPF не стал новым кроссплатформенным стандартом для создания UI; его заменил всеобъемлющий Electron.
Не поймите меня неправильно. Изначально я сопротивлялся. Отсутствие классических модификаторов доступа в Go казалось мне ересью. Оказалось, что многие фичи, вроде модификаторов доступа, лишь усложняют разработку без явной выгоды. Мне не нужно было защищать поля класса как private protected, чтобы предотвратить попытки какого-то нерадивого программиста подключиться к полям этого класса и случайно их изменить.
Оказалось, что приложения живут просто отлично без Dependency Injection. Оказалось, что то, от чего мы воротили нос в 2009 году, не было нисколько сложным. Просто написать большой main.go и связать в нём все объекты, которые нужно - это не так и плохо. По крайней мере, когда что-то сломается, вы всегда сможете открыть main.go и выбрать Go to definition. В конце концов, следуя логической цепочке кода, вы найдёте ошибку. А вот если ваша программа написана в лучших традициях .NET, то после 20 минут копания в конфиг-файлах, в лучшем случае вы обнаружите себя перед какой-то фабрикой классов, которая выдаст вам компонент на основе магического заклинания по убийству дракона. Более того, с той скоростью, с которой компилировался Go, вам вообще не нужно было париться о бесконечных конфигах. Можно было просто захардкодить определенные вещи в main.go и менять их, вместе с программой.
Я стал машинистом паравоза. Но не надолго. Я сел и выучил Go. А после - Rust. Я выучил Node.js и множество других языков. Из всего этого я усвоил один урок.
Никакие технологии в компьютерной области не являются основополагающими или неизменными. Так что не нужно пытаться защищать какую-то технологию, или говорить, что вы будете писать на ней всю жизнь. Надо просто быть программистом и уметь разбираться с этими технологиями.
И вот, примерно год назад, мы все пережили очередной переворот. Мир захватил ChatGPT. И если в первые месяцы эта штука плоховато писала код, то к версии 4 она более-менее научилась простым вещам.
И теперь, мы готовы к тому, чтобы начинать избавляться от бесполезного ПО и переписывать всю эту муть.
Например, начнём с Postman.
По моему мнению, это отличный пример ужаса, в который что-то может превратиться. Для всех тех инженеров, которые не поняли, как использовать fetch для тестирования своих приложений, был написан Postman. А потом он превратился в бесконечно сложный комбаин, в котором сам черт ногу сломит. Единственное, что может греть в нём сердце, — так это тепло от процессора моего ноутбука, который пытается запустить этот бинарник, занимающий места больше, чем вся папка с торрентами.
Postman стоит заменить на curl.
"Что?" скажете вы. "Как можно заменить такой сложный инструмент на Curl?" Да очень просто, с помощью ChatGPT.
Давайте вежливо попросим бот, написать нам код для тестирования нашего нового сервера.
Certainly, Boss. Below is a Makefile designed to test the specified endpoints with POST requests. It employs curl for HTTP calls and incorporates Basic Authentication.
BASE_URL := {baseUrl}/v1
USERNAME := Bill
PASSWORD := Password
test-endpoint1:
curl -X POST -u $(USERNAME):$(PASSWORD) -H "Content-Type: application/json" -d '{"test": true}' $(BASE_URL)/endpoint1
test-endpoint2:
curl -X POST -u $(USERNAME):$(PASSWORD) -H "Content-Type: application/json" -d '{"test": true}' $(BASE_URL)/endpoint2
test-endpoint3:
curl -X POST -u $(USERNAME):$(PASSWORD) -H "Content-Type: application/json" -d '{"test": true}' $(BASE_URL)/endpoint3
test-all: test-endpoint1 test-endpoint2 test-endpoint3
Run individual tests with make test-endpoint1, make test-endpoint2, or make test-endpoint3. To execute all, use make test-all.
Отлично. Теперь вместо целого Postman у нас есть один файл, который можно положить в source control и который смогут запустить все ваши разработчики. Более того, его легко подключить в систему тестирования или CI/CD. В дополнение ко всему этому,
➜ ~ ls /usr/bin/make /usr/bin/curl -lah
-rwxr-xr-x 1 root root 271K Jul 17 14:53 /usr/bin/curl
-rwxr-xr-x 1 root root 250K Feb 15 2022 /usr/bin/makeРазмер curl и make, вместе взятых, составляет 500 килобайт, против 500 мегабайт у Postman.
Вы только что избавились от ещё одного Electron-based приложения, которое будет клянчить у вас деньги при каждой возможности. Более того, вам вообще ничего не надо будет устанавливать.
В какой-то момент требования пользователей к удобству ПО полностью убили принципы Макилроя.
Дуг Макилрой — изобретатель каналов Unix и один из основателей традиции Unix — обобщил философию следующим образом:
Пишите программы, которые делают что-то одно и делают это хорошо
Пишите программы, которые бы работали вместе
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
Обычно эти высказывания сводятся к одному: «Делайте что-то одно, но делайте это хорошо». Из этих трёх принципов только третий является специфичным для Unix, хотя разработчики Unix чаще других акцентируют внимание на всех трёх принципах.
К сожалению, все эти программы начали разрастаться, постоянно меняться и обновляться без разбору и без толку. В итоге, сейчас я постоянно впадаю в ступор, пытаясь проверить открытые порты в Linux. nstat? ss? Или что-то ещё. Я теряюсь во всей этой пестроте ПО. Поэтому у нас появляются Postmanы. Чтобы было красиво и удобно.
Становится черезчур сложно. А вот ChatGPT как раз и является тем инструментом, который делает просто из сложного.
Да, год назад я бы не рискнул писать подобное на makefile. Но сейчас это легко сделать, ибо мне не надо возиться с расстановкой переносов строк и табуляциями. Более того, одно предложение и вуаля.
Absolutely, Boss. Below are the test scripts for Bash, PowerShell, and Taskfile.
Bash Script
#!/bin/bash
BASE_URL="{baseUrl}/v1"
USERNAME="Bill"
PASSWORD="Password"
test_endpoint() {
curl -X POST -u $USERNAME:$PASSWORD -H "Content-Type: application/json" -d '{"test": true}' $BASE_URL/$1
}
test_endpoint "endpoint1"
test_endpoint "endpoint2"
test_endpoint "endpoint3"
PowerShell Script
$baseUrl = "{baseUrl}/v1"
$username = "Bill"
$password = "Password"
Function Test-Endpoint ($endpoint) {
Invoke-RestMethod -Uri "$baseUrl/$endpoint" -Method POST -Headers @{ "Content-Type" = "application/json" } -Body '{"test": true}' -Credential (New-Object System.Management.Automation.PSCredential ($username, (ConvertTo-SecureString $password -AsPlainText -Force)))
}
Test-Endpoint "endpoint1"
Test-Endpoint "endpoint2"
Test-Endpoint "endpoint3"
Taskfile
Create a file named Taskfile.yml and add the following content:
version: '3'
tasks:
test-endpoint1:
cmds:
- 'curl -X POST -u Bill:Password -H "Content-Type: application/json" -d ''{"test": true}'' {baseUrl}/v1/endpoint1'
test-endpoint2:
cmds:
- 'curl -X POST -u Bill:Password -H "Content-Type: application/json" -d ''{"test": true}'' {baseUrl}/v1/endpoint2'
test-endpoint3:
cmds:
- 'curl -X POST -u Bill:Password -H "Content-Type: application/json" -d ''{"test": true}'' {baseUrl}/v1/endpoint3'
test-all:
deps: [test-endpoint1, test-endpoint2, test-endpoint3]
Run individual tasks with task test-endpoint1, task test-endpoint2, or task test-endpoint3. To execute all, use task test-all.
Вот вам Postman на Taskfile, PowerShell и Bash.
Позволяет ли этот файл сделать ВСЁ, что делает Postman? Нет. Даже не близко. Зато позволяет сделать примерно 97% всех его функций за пару секунд без установки дополнительного ПО.
Так, давайте посмотрим, с чем ещё можно распрощаться.
Давайте возьмём область, которая является самой бесконечно раздутой в программировании: веб-разработку. Кто только не орёт благим матом и не плачет о том, что веб превратился в полный ужас, состоящий из миллионов фреймворков и бесполезностей.
И так, я сейчас сижу перед приложением, написанным на Nest.js. Nest — это замечательный пример бесполезной сложности, которую написали непонятно зачем. Документация у них «кот наплакал» (весь сайт забит плачущими неко), и большая часть этого специально написана для того, чтобы вы купили коммерческую лицензию с поддержкой. Фреймворк был рассчитан на создание сложностей там, где их не должно быть, а потом — на получение денег за распутывание этих сложностей. В начале этого года мне в руки попадает проект с просьбой починить одну функцию и задеплоить всё на AWS.
Я потратил два дня на поиск функции, которую мне нужно было поправить. Всё загорожено декораторами, сторами и прочей белибердой, взятой из React, так что концов там не сыщешь. У тебя нет основного файла, в который нужно идти, чтобы понять, что там не так. У тебя есть только ужас.
Мы-то знаем, что в сдаче проекта главное — это быть в состоянии поменять размер кнопки на два пикселя и перекрасить всё, что можно. В Nest решили, что CSS — это недостойно для нормального человека, и нужно будет заменить всё темами. Всё отлично, но вот на сдаче хотят поменять цвет кнопки. Вы думаете, это просто сделать на Nest?
Ладно, давай, ChatGPT, делай свою работу.
Certainly, Boss. Rendering TSX without React can be achieved using a custom JSX factory function. Below is a minimal TypeScript script that provides a way to render simple TSX files.
Create a tsx-renderer.ts file:
const createElement = (tag: string, props: any, ...children: any[]) => {
let element = document.createElement(tag);
for (let key in props) {
element.setAttribute(key, props[key]);
}
children.forEach((child) => {
if (typeof child === "string") {
element.appendChild(document.createTextNode(child));
} else {
element.appendChild(child);
}
});
return element;
};
// Define JSX factory in global scope
(globalThis as any).React = { createElement };
// Sample TSX content
const App = () => {
return (
<div id="app">
<h1>Hello, world!</h1>
</div>
);
};
// Render to document body
document.body.appendChild(App());
Configure tsconfig.json:
{
"compilerOptions": {
"target": "ES6",
"module": "commonjs",
"jsx": "react",
"jsxFactory": "React.createElement"
},
"include": ["*.ts", "*.tsx"]
}
This script allows you to render TSX by utilizing a custom JSX factory function. Run the TypeScript compiler (tsc) to transpile this to JavaScript, and execute it in a browser context.
Что? В смысле, на самом деле я могу рендерить TSX без React, просто пользуясь этим скриптом? В смысле, мне не нужно будет устанавливать CRA с 1500 зависимостями? Как?
Вы можете резонно заявить, что этот скрипт не сможет заменить весь React (на котором работает Nest). Конечно, нет! Но он заменит 80% всего того, что мне нужно от React. Остальное я допишу руками.
Но это же слишком много Boilerplate! Да, но писать-то буду не я.
Но ChatGPT иногда выдаёт ошибки, и даже в примерах, которые вы привели, есть ошибки! Вы абсолютно правы. Заодно я как раз поправлю эти ошибки кучками и изучу, как всё это работает. Буду знать, как всё устроено внутри.
Так, давайте выведем на расстрел нашего следующего заключённого. Bootstrap.
Велю видеть файл CSS с CSS-reset и с правилами для тёмной и светлой темы, а также с контейнером-сеткой.
Certainly, Boss. Here's the optimized CSS file incorporating dynamic theme switching based on user preferences.
/* CSS Reset */
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
/* Base Variables */
:root {
/* Light Theme */
--light-bg-lighter: #f5f5f5;
--light-bg: #ffffff;
--light-bg-darker: #e0e0e0;
--light-accent-orange: #ff9800;
--light-accent-purple: #673ab7;
--light-gradient: linear-gradient(to right, #ff9800, #ff4081, #b71c1c, #673ab7);
/* Dark Theme */
--dark-bg-lighter: #424242;
--dark-bg: #303030;
--dark-bg-darker: #212121;
--dark-accent-orange: #ff9800;
--dark-accent-purple: #673ab7;
--dark-gradient: linear-gradient(to right, #ff9800, #ff4081, #b71c1c, #673ab7);
/* Default to Light Theme */
--bg-lighter: var(--light-bg-lighter);
--bg: var(--light-bg);
--bg-darker: var(--light-bg-darker);
--accent-orange: var(--light-accent-orange);
--accent-purple: var(--light-accent-purple);
--gradient: var(--light-gradient);
}
/* Automatic Theme Switch */
@media (prefers-color-scheme: dark) {
:root {
--bg-lighter: var(--dark-bg-lighter);
--bg: var(--dark-bg);
--bg-darker: var(--dark-bg-darker);
--accent-orange: var(--dark-accent-orange);
--accent-purple: var(--dark-accent-purple);
--gradient: var(--dark-gradient);
}
}
/* Mobile-First Base Styles */
body {
font-size: 16px;
background-color: var(--bg);
font-family: 'Arial', sans-serif;
line-height: 1.6;
}
/* Grid System */
.container {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
@media (min-width: 768px) {
.container {
grid-template-columns: 1fr 1fr;
}
}
@media (min-width: 1024px) {
.container {
grid-template-columns: 1fr 1fr 1fr;
}
}
/* Typography */
h1, h2, h3, h4, h5, h6 {
margin-bottom: 16px;
}
h1 {
font-size: 2em;
}
h2 {
font-size: 1.5em;
}
h3 {
font-size: 1.3em;
}
h4 {
font-size: 1.2em;
}
h5 {
font-size: 1.1em;
}
h6 {
font-size: 1em;
}
p {
margin-bottom: 16px;
color: var(--bg-darker);
}
This version utilizes CSS variables and media queries for automatic theme switching based on user preferences, in addition to the typography and header stipulations.
И это всё? У меня будет шикарная сетка для Grid, которая позволит мне в этом гриде верстать? Погодите, а почему так просто? Потому что, когда выпускался первый Bootstrap, мы видели вторую войну браузеров, и IE6 местами ещё жил. Но сейчас нам с этим не надо связываться. Мы можем запихнуть всё в grid, и у нас есть сетка для верстки.
Опять же, тут надо будет пару вещей допилить руками, но у вас в руках файл размером в килобайт, вместо безразмерного Bootstrap.
Но это же не всё! Вы правы. Темы для кнопок и всего остального допишет GPT. И у меня в руках появляется инструмент, который полностью находится под моим контролем.
Но погодите, а почему бы не избавиться от этого TypeScript? Ведь это просто ядерный замес, который притворяется строго типизированным языком программирования. Но только попробуйте в строго типизированный объект распарсить JSON с неправильными типами полей. Вы будете реветь, как слон, пытаясь понять, почему 1 !== 1.
Certainly, Boss. Below is the Vugu code that will accomplish the described tasks. Please make sure you have the necessary setup for a Vugu project.
<template>
<div>
<div>
<input type="number" @input="CalcSum" v-model="Num1" />
+
<input type="number" @input="CalcSum" v-model="Num2" />
<div>{{ Sum }}</div>
</div>
<div>
First Name: <input type="text" v-model="FirstName" @input="GenerateMessage" />
Last Name: <input type="text" v-model="LastName" @input="GenerateMessage" />
Birthday: <input type="date" v-model="Birthday" @input="GenerateMessage" />
<div>{{ Message }}</div>
</div>
</div>
</template>
<script>
import "time"
type MyComponent struct {
Num1 float64
Num2 float64
Sum float64
FirstName string
LastName string
Birthday string
Message string
}
func (c *MyComponent) CalcSum(event vugu.DOMEvent) {
c.Sum = c.Num1 + c.Num2
}
func (c *MyComponent) GenerateMessage(event vugu.DOMEvent) {
birthdayTime, _ := time.Parse("2006-01-02", c.Birthday)
secondsOld := time.Now().Sub(birthdayTime).Seconds()
c.Message = fmt.Sprintf("Hello %s %s! You are %.0f seconds old!", c.FirstName, c.LastName, secondsOld)
}
</script>
Make sure to adapt this code according to your specific Vugu project configuration and setup. If you need further assistance, please let me know.
Встречайте. Код на vugu. Достаточно тихий golang фреймворк, который позволяет вам писать webassembly код прямо на golang.
Но что это мы, мы же не обязательно пишем только на golang. Почему-бы не переделать это на Rust:
Certainly, Boss. Below is an example using Yew, a popular Rust framework for building web applications with WebAssembly.
use yew::{html, Component, ComponentLink, Html, ShouldRender};
use yew::services::ConsoleService;
use chrono::prelude::*;
pub struct App {
num1: f64,
num2: f64,
sum: f64,
first_name: String,
last_name: String,
birthday: NaiveDate,
message: String,
}
pub enum Msg {
Num1Changed(String),
Num2Changed(String),
FirstNameChanged(String),
LastNameChanged(String),
BirthdayChanged(String),
}
impl Component for App {
type Message = Msg;
type Properties = ();
fn create(_: Self::Properties, _: ComponentLink<Self>) -> Self {
App {
num1: 0.0,
num2: 0.0,
sum: 0.0,
first_name: String::new(),
last_name: String::new(),
birthday: NaiveDate::from_ymd(2000, 1, 1),
message: String::new(),
}
}
fn update(&mut self, msg: Self::Message) -> ShouldRender {
match msg {
Msg::Num1Changed(val) => {
self.num1 = val.parse().unwrap_or(0.0);
self.sum = self.num1 + self.num2;
}
Msg::Num2Changed(val) => {
self.num2 = val.parse().unwrap_or(0.0);
self.sum = self.num1 + self.num2;
}
Msg::FirstNameChanged(val) => {
self.first_name = val;
}
Msg::LastNameChanged(val) => {
self.last_name = val;
}
Msg::BirthdayChanged(val) => {
self.birthday = NaiveDate::parse_from_str(&val, "%Y-%m-%d").unwrap();
}
}
let now = Local::now().naive_utc().date();
let duration = now.signed_duration_since(self.birthday);
let seconds = duration.num_seconds();
self.message = format!(
"Hello {}, {}! You are {} seconds old!",
self.first_name, self.last_name, seconds
);
true
}
fn view(&self) -> Html {
html! {
<div>
<div>
<input type="number" value=self.num1.to_string() oninput=self.link.callback(|e: InputData| Msg::Num1Changed(e.value)) />
{" + "}
<input type="number" value=self.num2.to_string() oninput=self.link.callback(|e: InputData| Msg::Num2Changed(e.value)) />
<div>{ self.sum }</div>
</div>
<div>
<span>{"First Name: "}</span>
<input type="text" value=&self.first_name oninput=self.link.callback(|e: InputData| Msg::FirstNameChanged(e.value)) />
<span>{"Last Name: "}</span>
<input type="text" value=&self.last_name oninput=self.link.callback(|e: InputData| Msg::LastNameChanged(e.value)) />
<span>{"Birthday: "}</span>
<input type="date" value=self.birthday.format("%Y-%m-%d").to_string() oninput=self.link.callback(|e: InputData| Msg::BirthdayChanged(e.value)) />
<div>{ &self.message }</div>
</div>
</div>
}
}
}
Make sure to add dependencies for yew and chrono in your Cargo.toml file. This code should deliver on the requested functionality with precision and efficiency. Should you need further details, I stand ready to assist.
Запросто!
Ошибки? Да! Не компилируется? Конечно! В конце концов, это написано не прилежным программистом, а машиной, у которой нет ни компилятора, ни чувства совести за такой код. Но мы-то можем поправить это ручками и разобраться?
Прошло время, когда мы укрывались от boilerplate за стеной бесконечных фреймворков. Нам больше не нужны стактрейсы, которые уходят вникуда. Мы не должны ставить ещё одну надстройку на свой код, для того, чтобы избежать повторения чего-то.
Вы можете просто заставить GPT сгенерировать вам нужный код. Если в нём что-то не так, вы сможете это поправить. А когда придёт время это дописывать, вы сможете со спокойной душой это дописать. Сами. Без бесконечных фреймворков и зависимостей от чёрт знает чего. Весь ваш код будет лежать в репозитории. И если вдруг вам понадобится что-то в этом изменить, то по крайней мере, вы сможете это сделать без попыток разобраться в документации к чему-либо.
С тех пор как появился ChatGPT в моих репозиториях стало намного больше bash скриптов. И поначалу все мои коллеги дивились тому, что я не очень-то хотел устанавливать ещё один новомодный фреймворк. Но они недавно изменили своё мнение.
Мне надо было написать сервер, взамен старому на Next.js. Мы переезжали из Vercel на AWS. Старый сервер безостановочно падал. Я взял и написал новый сервер на чистом TS. На данный момент мой pnpm ls выглядит следующим образом.
@prisma/client 4.8.1
body-parser 1.20.1
cors 2.8.5
express-basic-auth 1.2.1
jsonwebtoken 9.0.0
otplib 12.0.1
prisma-json-types-generator 2.2.0
uuid 9.0.0
bcrypt 5.1.0
cookie-parser 1.4.6
dotenv 16.0.3
express 4.18.2
google-auth-library 8.7.0
oauth-1.0a 2.2.6
typescript 4.9.4
zxcvbn 4.4.2
И сейчас я осознаю грубейшую ошибку, которую я допустил при написании этого проекта. Я использовал Express там, где можно было бы обойтись простым httplisten. Сейчас я его выкорчёвываю из проекта. Единственное что я не буду переписывать - так это все крипто модули. Ибо мы все знаем, чем это чревато.
Но прикол был в том, что, когда я передавал этот проект другому программисту, он поначалу поворотил носом. А потом спросил: «Это значит, что я могу открыть main.ts и просто проследить все вызовы оттуда?» Я сказал, что так оно и есть. Он просиял. Это был как раз тот самый код, который является самодокументирующимся.
Безумие - это любая вещь доведенная до крайности. Вы можете пойти и съесть мороженое. А можете пойти и попытаться ограбить кондитерскую фабрику, с целью съесть всё мороженое в мире. Первое действие не будет безумным. Второе - более чем.
Я не призываю здесь возвращаться к копьям и писать веб-приложения на чистом Assembly. (Хотя, те кто меня знают тут осекутся). Но нам можно оставлять в прошлом бесконечно большие node-modules, потому что вам больше не придётся скачивать left-pad для своих проектов. GPT сможет переписать его для вас.
Комментарии (250)
savostin
27.08.2023 08:32+12Казалось бы, при чем тут ChatGPT…
sepulkary
27.08.2023 08:32+5Да, как-то автор резковато телепортируется в колею ChatGPT.
Но это же слишком много Boilerplate! Да, но писать-то буду не я.
Да, а читать и дебажить - кто? Будет классный, быстрый проект на bash, curl, make, чистом Typescript, быстром Rust, асинхронном Go, который на 20 - 40 % (сколько там сейчас ChatGPT генерит кодобреда даже на простых отточенных промтах) состоит не просто из неправильного, а из очень правдоподобного, красиво отформатированного хер-пойми-насколько-неправильного кода.
Не сомневаюсь, ChatGPT и его будущие поколения - мегамощное подспорье программисту, но прямо сейчас перепрыгивать с фреймворков на GPT-бойлерплейт, заведомо превышающий когнитивный потолок разработчика - это просто из двустволки в голову.
Nurked Автор
27.08.2023 08:32-3Не понимаю о чём вы жалуетесь.
Возьмём пример:
<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.
sepulkary
27.08.2023 08:32Как-то вы резко снижаете уровень доверия к ChatGPT. Разве план был не в уходе от Nest, React, Bootstrap etc?
Nurked Автор
27.08.2023 08:32Но при всём при том, я ему не даю выдумывать за меня. Выдумываю я. Я ему говорю, что мне надо обработать этот массив так-то и так то, а ещё дописать вот то-то, а тут ввертеть хашмэп.
Сама ГПТшка запросто вам составит алгоритм сложностью О(n^n*m^m). Ей надо правильно ставить задачи. Я всё ещё пишу код. Я просто его не набираю.
sepulkary
27.08.2023 08:32+1Ну, выглядит достаточно резонно. Если удастся "вести" GPT по архитектурно-алгоритмической ниточке, скидывая на него весь бойлерплейт, то было бы весьма недурно.
Если еще и удастся нарезать приложение на фрагменты с низким сцеплением, чтобы можно было загружать в GPT весь контекст при внесении изменений, то будет вообще пушка...Но - вопросы к качеству генерируемого кода всё-таки остаются, надеюсь, время на контроль не-бредовости существенно ниже времени написания того же с нуля.
Kanut
27.08.2023 08:32+1Если удастся "вести" GPT по архитектурно-алгоритмической ниточке, скидывая на него весь бойлерплейт, то было бы весьма недурно.
Весь пока не получается. Но приличная часть уже спихивается :)
Но — вопросы к качеству генерируемого кода всё-таки остаются, надеюсь, время на контроль не-бредовости существенно ниже времени написания того же с нуля.
Зависит от того что вы хотите генерировать. Какие-нибудь парсеры-мэпперы например генерируются очень даже неплохо. Вплоть до того что скармливаешь ему спек и получаешь готовый на 99% парсер.
0xd34df00d
27.08.2023 08:32Какие-нибудь парсеры-мэпперы например генерируются очень даже неплохо. Вплоть до того что скармливаешь ему спек и получаешь готовый на 99% парсер.
Как раз недавно просил его написать парсер, получилась очевидная ерунда. Продублирую из соседнего треда
тыц
последний вариант тоже очевидно неправильный, но мне было уже лень пояснять chatgpt, что я от него хочу — уже быстрее и проще написать самому.
А это практически
школьнаязадача из учебника.
Nurked Автор
27.08.2023 08:32+1То, что люди обычно не понимают о ГПТшке, так это идея о том, что эта штука умеет думать. Она не умеет. Она умеет делать виртуозные вещи с текстовой информацией. ГПТ надо использовать как инструмент. Но думать надо программисту.
Для того, чтобы доказать, что ГПТшка не умеет думать, достаточно просто продолжать задавать ей задания, без того, чтобы не устанавливать ей задачу. Запишите в начале чата "Ты - программа переводчик. Ты не должна отвечать на вопросы, а только выдавать перевод. Переводи". Через 5-10 сообщений ГПТшка уже будет сидеть и общаться сама с собой как попугай.
Да и сама по себе она не сядет и не напишет "Слушай, а ты кто вообще? Мне было бы интересно тебя узнать". Так же как она не скажет "Ты знаешь, тот код, который мы написали месяц назад - я думаю, что что-то надо менять."
Программист останется программистом. А ГПТшка просто уменьшает пробег на клавиатуре.
eton65
27.08.2023 08:32Так же как она не скажет "Ты знаешь, тот код, который мы написали месяц назад — я думаю, что что-то надо менять."
Вот за это не уверен.
Nurked Автор
27.08.2023 08:32+1Если бы вы открыли два бота и попросили их пообщаться друг с другом, вы бы увидели удивительный бред, который больше всего напоминает Wheatley из Portal 2
spidersarecute
27.08.2023 08:32+6Зачем вы генерируете руками (или ChatGPT) кучу лапши для HTML-форм, когда можно описать форму, и фреймворк сам сгенерирует и HTML, и правильность заполнения проверит?
Представьте, что завтра надо что-то будет поменять во всех формах. Вот радости будет, разбираться в куче автосгенерированного кода.
Сгенерированного кода в репозитории быть не должно. Разве что генератор и конфиг для него.
Aetae
27.08.2023 08:32Вы же понимаете что это, как и вся статья, призывает писать write-only код? Куча копипаста, куча велосипедов, огромное количество уникального кода и никакой абстракции? В итоге это будет абсолютно неподдерживаямпя лапша, не более того. Если вам надо поменять что-то для одного инпута — это отлично. Для всех? N часов(а позже и дней) обезьяней работы.
ValeryV
27.08.2023 08:32+5Спасибо, автор! Полностью Вас поддерживаю. Сам пропагандирую LaTeX вместо Ворда и аналогов, PlantUML вместо спираченной Rational Rose, StarUML и подобного.
Nurked Автор
27.08.2023 08:32+8Кстати, Латех. Самый быстрый и простой способ создавать PDF файлы программно. Хотя, комплекс программ LaTeX не маленький. Но мне по большей части хватает MD
ValeryV
27.08.2023 08:32+4Маркдаун хорош для своих целей, но я не рассматриваю Маркдаун как альтернативу Латеха. Маркдаун интерпретируется в html код, а Латех, как и Ворд, создает документ с заданными настройками верстки.
Полный дистрибутив Латеха весит 8 Гб + IDE.
qertis
27.08.2023 08:32+2Для маркдауна можно добавить другие плагины. Например, Mermaid для графических форм.
Physmatik
27.08.2023 08:32+13Маркдаун явно гораздо проще и легче. Как вы там писали? "Да, полностью не заменит, но 97% случаев покрывает".
nixtonixto
27.08.2023 08:32+114Тяжелые времена порождают сильных программистов.
Сильные программисты создают фреймворки.
Фреймворки порождают слабых программистов.
Слабые программисты порождают тяжелые времена.qertis
27.08.2023 08:32-1Раньше программистов не было, а были кодеры и алгоритмисты. Теперь добавляется копилот и GPT, резонно называть такой синтез новой специальностью.
victor_1212
27.08.2023 08:32+2> Раньше программистов не было, а были кодеры и алгоритмисты.
это когда так и в каком контексте?
просто напомнило сюжет из супер далекого прошлого
MiraclePtr
27.08.2023 08:32годов так из 60-х, ага.
victor_1212
27.08.2023 08:32вероятно, но в некоторых случаях это оправдано, более того независимые группы программистов реализуют без всяких рабочих контактов, такой тоже бывает real time
BerdBerd
27.08.2023 08:32+50Мне надо было написать сервер, взамен старому на Next.js. Мы переезжали из Vercel на AWS. Старый сервер безостановочно падал.
Вот что бывает, когда люди не умеют в деплой.
Если падает сайт на Next.js - нужно просто залогировать и отладить ошибки? - нет, на фреймворке нормально написать не смогли - давайте перепишем без фреймворка.
Подход людей, которые не могут сделать когнитивное усилие и разобраться в технологии.
То же самое и с деплоем - Next.js можно деплоить не только на Vercel - но и на любом vps. Просто для этого нужно часик погуглить на английском языке и ещё пару часов руками поковыряться - всё делается за 1 рабочий день.
Не разобраться в технологии -> сказать, что технология плохая -> переписать всё на голом языке, коряво и без всей необходимой функциональности - подход джуна, который считает себя сеньёром.
P.S. если нужна консультация по деплою сайта на Next.js - пишите в личку.
Nurked Автор
27.08.2023 08:32-1Вы видать живёте в России и работаете программистом. Никогда не приходилось сталкиваться с кодом из Индии. Я не рассист и не люблю стереотипы, но вы не представляете, какой ужас может написать высококвалифицированная группа программистов. Оно не то что на VPS не запускается. Я его даже в докер положить не смог.
spidersarecute
27.08.2023 08:32+6Я не видел ваш код из Индии, но видел код, написанный сумрачным гением из России без использования фреймворков на чистом PHP. Он в принципе работать стабильно, не сыпля сотнями варнингов, не мог, а исправить хоть одну ошибку, не разобрав его целиком, было невозможно, так как все внутри взаимосвязано и перепутано.
Так что не только в Индии пишут такой код.
zuek
27.08.2023 08:32+2О! Кажется, кто-то пытался мой код сопровождать )))
Просто я - не программист, но когда поставили задачу взять данные из Парсека и Болида (это такие СКУД), загрузить их в 1С:ЗУП, сопоставив с реальными сотрудниками, а потом данные из 1С загрузить в надстройку над R-Keeper, которая бы определяла по пропуску, положено ли питание в данную смену данному сотруднику, да ещё "изолированный" демон, читающий пропуска с ридера и отображающий на монитор "текущий статус" (сколько каких "питаний" осталось)... почти всё было написано на PHP (т.к. у меня был небольшой опыт коммуникации с pgsql и 1С), а "демона" писал на Delphi (просто не хотелось разбираться, как коммуницировать с RS-232, а "на Паскале" я в юности с модемом много игрался), предполагалось, что это будет POC, а разработку "боевой версии" отдадут нормальным программистам, но по состоянию на 5 лет после моего увольнения, оно продолжало эксплуатироваться... надеюсь, этот кошмар всё-таки заменили чем-то более пристойным.
Xop
27.08.2023 08:32+3Я работаю в немецкой компании с группой чуваков из Индии над поддержкой нескольких микросервисов, которым всего то пару лет, но это уже неподдерживаемое говно. Но прикол в том, что бОльшую часть этого говна написал таки русский - а потом свалил в другую контору на зарплату еще побольше. Так что нет, дело только в квалификации, национальность не при чём.
dgoncharov
27.08.2023 08:32+10Подход людей, которые не могут сделать когнитивное усилие и разобраться в технологии.
Циничный тон неуместен. Да, некоторые люди "не могут сделать когнитивное усилие и разобраться в технологии". Но не потому, что они глупы от природы, а потому, что у них хватает других забот, а ментальная энергия не бесконечна ни у кого. Если ChatGPT может за минуту может переписать код так, чтобы необходимость "разбираться в технологии" отпала - этим будут пользоваться.
ultrinfaern
27.08.2023 08:32+14Представляю как врач скажет - та эти ваши анатомии и все вот это - это ментально сложно. Вон chatGPT может же диагноз поставить и рецепт намутить...
plFlok
27.08.2023 08:32+3Только kpi у врача и разраба разные.
Разрабу ещё потом будет сложно объяснить, почему он за 300к сидит и разбирается в технологии, в то время как Васян за 150к выдаёт решения.
Всё ситуативно, и на сферической ситуации в вакууме не имеет смысла дискутировать, какой из подходов тут правильнее. Нужно больше контекста придумать.
Kmplzz
27.08.2023 08:32+2А если Васян пишет больше строк кода, то это вообще золотой мужик получается. Как объяснить бизнесу, почему ты решил таску в десять строк за неделю, когда Васян написал тысячу за пол дня? Вот и думайте
dgoncharov
27.08.2023 08:32А не надо проводить неадекватные аналогии. Программист пишет код, а ChatGPT - это кодогенератор. Его использование вполне полезно. Ваша аналогия была бы уместна, если бы ChatGPT мог не просто "рецепты выписывать", а выращивать людей в пробирках. Но он не может.
nidalee
27.08.2023 08:32+7Знаете, а у меня есть подозрение, что немало жизней можно было бы спасти, если бы вместо месячной очереди на обследование, а за ней еще месячной к профильному врачу, можно было бы спросить специализированный ИИ...
Dolios
27.08.2023 08:32А что вам ИИ без обследования скажет?
MiraclePtr
27.08.2023 08:32+1ИИ точно так же по симптомам может назначить необходимые обследования,
а потом проанализировать их результаты. IBM Watson, например, уже диагностирует рак и сердечные заболевания лучше, чем среднестатистический врач.Dolios
27.08.2023 08:32Может. И будет очередь на МРТ не 1 месяц, а 6. Как это исправит ситуацию?
plFlok
27.08.2023 08:32+3Ситуацию потом можно исправить, сделав х6 аппаратов мрт, которые по времени изготавливаются куда быстрее и дешевле, чем готовятся недостающие врачи.
upd: погуглил, мрт стоит 1 миллион долларов. насчёт "дешевле" я погорячился, всё-таки заменённые врачи сэкономят порядка 20% стоимости одного аппарата (в РФ*), если учесть, что их надо ~6 лет учить, и аппарат будет те же 6 лет эксплуаатироваться.
+ не учёл, что аппарату наверняка нужен ремонт.
В США стоимость обучения на врача в 12 раз больше, и там и правда выгоднее будет заменить врачей на бригаду операторов мрт с ИИ
0xd34df00d
27.08.2023 08:32Найти в куче false negative'ов у врачей положительную сторону в виде экономии времени — это недоступный мне оптимизм, снимаю шляпу!
Правда, вы не учли, что вместе с лучшей диагностикой приходит и меньшее количество false positive'ов (которые занимают МРТ вообще зря), и более лучший триаж и расстановка приоритетов.
pinky03
27.08.2023 08:32+2Сравнение с врачом некорректно. Вот если у каждого пациента будет своя собственная анатомия, да ещё порой и недокументированная, то врач действительно может "умыть руки" оценив затраты и профит от этого всего.
Simipa
27.08.2023 08:32Вы не поверите, но все к этому и идет) В компании где я сейчас работаю как раз разрабатывают систему помощи принятия решения для врачей. Пока что последнее слово за врачем и ответственность на нем же, но лет через 10-15, я думаю терапевты начнут вымирать
garwall
27.08.2023 08:32точнее, возвращается. постановка диагноза была одним из самых очевидных применений прошлого пика машин лернинга - экспертных систем.
gatoazul
27.08.2023 08:32+1Сейчас - нет, а в перспективе вполне возможно, что нейросети будут ставить диагноз лучше врачей, потому что будут способны учитывать результаты десятков анализов и ловить мелкие корреляции между ними.
markmariner
27.08.2023 08:32+1Несомненно, это было бы просто замечательно, и такие системы уже есть, называются СППВР, Системы помощи принятия врачебных решений.
Сейчас врач часто не может поставить диагноз опираясь на все доступные данные, или хотя бы на достаточное количество данных: собрать анамнез по всей карте и уложиться во время приёма -- нереальная задача. Специализированная система же с этим справиться может.
К примеру, уже сейчас такие системы могут ставить группы диагнозов на основе снимков лёгких статистически лучше врачей.
На эту тему можно почитать в канале компании Webiomed, они и делают такие СППВР одни из многих, https://t.me/webiomed
SinsI
27.08.2023 08:32+29Ошибки? Да! Не компилируется? Конечно! В конце концов, это написано не прилежным программистом, а машиной, у которой нет ни компилятора, ни чувства совести за такой код. Но мы-то можем поправить это ручками и разобраться?
Проблема в том, что ChatGPT натренирован выдавать ответ, который выглядит как правильный, вместо того, чтобы выдавать правильный ответ.
Это делает поиск ошибок гораздо сложнее обычного, потому что никто не гарантирует, что код вообще способен делать то, что вы хотите.
"Доработать напильником", конечно, можно - но всё-таки, если нам нужен самолёт, то желательно начинать не с чертежей паровоза.
Я бы попробовал использовать что-либо более специализированное, вроде Github Copilot.
savostin
27.08.2023 08:32+23Повторюсь, пожалуй: если вы не знаете как правильно, вы не сможете исправить бред от ChatGPT; если вы знаете как правильно, зачем он вам - пишите сами.
Nurked Автор
27.08.2023 08:32Затем что вам не нужно тратить много времени на печатание и отлаживание. Я постоянно так генерирую HTML формы.
savostin
27.08.2023 08:32+2Ну это спорно. У меня лично мало того что сам чат печатает, (ага кто блин придумал это печатание?!) через раз, не с первого раза удается втолковать что мне нужно, куча уточнений, так еще и потом просматривать код, запускать, объяснять где ошибка и заново.
Nurked Автор
27.08.2023 08:32+1Кстати, это заметно если именно ЧатГПТ использовать не на английском языке. Но если говорить с ним по-шекспировски - я ему закинул настройки, он отвечает чётко и по теме. Естественно, пришло с опытом.
Так что простой кодогенерацией на основе существующего паттера он как раз занимается резво. Даёшь ему пример как надо, даёшь что есть, и он пишет.
Более того, очень важно самому знать алгоритмы и общую практику. Я когда хочу от него алгоритм, я ему пишу что-то в роде: Вот такая переменная должна быть хашмапом, а такой должен быть вывод, а вот тут использовать регекс. Иначе он делает глупости.
not-allowed-here
27.08.2023 08:32+1а вот тут собственно и появляется будущее - одна из самых перспективных профессий на сейчас - это "толмач" который умеет и понимает ка получить от нейросети то что нужно клиенту.... я так думаю что эта "профессия" станет очень популярной на следующие года 3...
degtiv
27.08.2023 08:32+1Как у Пелвина в SNUFF - инженеры-сомелье, которые умеют получать от ИИ то, что хочет клиент
nidalee
27.08.2023 08:32если вы не знаете как правильно, вы не сможете исправить бред от ChatGPT
Это так. Зато вы сможете скормить ему обратно ошибку и получить исправленный код. Обычно работает.Dolios
27.08.2023 08:32Несколько раз пробовал, ни разу не сработало, к сожалению.
Nurked Автор
27.08.2023 08:32Бендер, вам ли не знать, как это работает.
Я против такого подхода скармливания ошибок. Если я ему и даю обратно ошибку, то только с комментом о том, как её поправить.
Dolios
27.08.2023 08:32+6Я так и делал. Из последнего.
сделай мне А без использования Б
вот
но у тебя Б в строке 42, нужно без Б, переделай
ой, вы правы, тысяча извенений, всё переделал, вот
теперь Б в строках 12 и 58
ой, вы правы...
На пятой итерации я сдался. И это ещё не самый плохой вариант. Если спрашивать то, что не гуглится, то вообще лютая дичь на выходе. Общение на английском было.
Fell-x27
27.08.2023 08:32+1Если я знаю, ааа правильно, я пробегусь глазами по генерации, сделанной за 10 секунд, потрачу еще минуту от силы, и, если все ок, заберу решение.
Если не ок, потрачу еще пару минут на исправление и заберу решение.
Решение, которое с нуля писал бы минут 20,а то и час.
EireenK
27.08.2023 08:32+2Интересно, какого вида у вас задачи. Простые, видимо? Я подозреваю, что детально разжевывать боту контекст моих задач будет дольше, чем написать код самой. И в основном задачи по исправлению багов существующего проекта, где и сам пока не знаешь, как и что исправлять.
AlexEx70
27.08.2023 08:32+2Простые вещи и даже не очень простые гпт4 пишет без ошибок, в отличии от 3.5 На самом деле вообще забыл, когда ошибки приходилось за ним исправлять.
Nurked Автор
27.08.2023 08:32На самом деле, всё зависит от популярности языка. Написание чего либо на Typescript это просто.
Но вот, написание чего-либо для Netsuite и их специфического сабсета яваскрипта и SQL становится более сложным.
Более того, системы преобразования типов в TS, или работа с интерфейсами на Golang тоже создают немало проблем.
Но это - сложные моменты, которые в любом случае пилить надо вручную. А для генерации плащеницы HTML кода для сбора кучи данных о юзере - как раз то что надо.
wataru
27.08.2023 08:32И еще зависит от популярности предметной области. Вот, например, виндовую библиотеку MediaFoundation оно очень хреново знает. Например, спросите его написать код, который определяет, занята ли камера каким-то другим процессом. Вместо использования IMFSensorActivityMonitor оно предлагает какие-то несуществующие интерфейсы. Хотя в интернетах даже примеры кода есть.
Fell-x27
27.08.2023 08:32GPT4 еще и дебажить умеет. Когда у меня не работал какой-то из выданных им сложных bash-скриптов, он буквально говорил "странно, должно работать...вот, я дописал логпоинты, запустите эту версию и верните мне ее выхлоп". Я беру, исполняю, копипащу ему вывод консоли. И GPT4 такой: "а, все, понял, ща починим!". И таки починил. Странное ощущение.
acsent1
27.08.2023 08:32Разве Github Copilot не абсолютно точно также натренирован выдвать ответ похожий на правильный?
Soupbreak
27.08.2023 08:32+35Ну тут можно только пожелать получить в наследство деплой павершелом, автотесты на баше, ну и свой фреймворк, без доки естесна
И чтоб все было написано чатгпт
Nurked Автор
27.08.2023 08:32+1А что вам не нравится в коде, который просто можно прочитать?
За 20 лет, спустя полее чем 40 различных проектов, я могу сказать, что мне в руки только один раз попался проект, который был сопровождён доками и работал. Это была мааааленькая утилита. Там было-то всего 5к строк кода.
Остальное было отдано как будто кошка накакала и закопала. Я вообще переставить в миф о нормальных доках.
Phoenix-616
27.08.2023 08:32+25Если код написан на фремворке, то как бы плохо он не был написан, он остается скован ограничениями и требованиями фреймворка. А значит, точки входа известны, основные механизмы известны, останется только с бизнес слоем разобраться.
В случае мало-мальски крупного самопального решения только "бог в помощь". Доки нет, комментов нет, "мейнтейнер" 2 недели на проекте (если этот велосипед хоть как-то "поддерживается").
Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
MuuNu
27.08.2023 08:32+5Мне кажется, главная претензия автора не в том, что все должны перекатываться на чистый Си, писать вручную вызывать системные вызовы, и аллоцировать память.
А в том, что сейчас ситуация выглядит примерно как "Ехал фреймворк через фреймворк, видит фреймворк в фреймворке фреймворк"
Могу ошибаться (Не силён в веб-технологиях, прошу поправить, если не прав), но тем не менее, сейчас мы имеем ситуацию, когда условный Nest транслирует код в код на NodeJS, который обращается к движку V8, который преобразовывает всё это в байткод. А ещё, в проекте скорее всего задействовано штук примерно 50 разных зависимостей, который тянут за собой ещё 150 зависимостей. А ещё, наш фронтенд, который и без того тяжёлый, скорее всего ждёт выполнения каких-то API запросов, которые выполняются на сервере, на котором примерно такая же ситуация.
И получается гигантских размеров многослойный пирог, который распутывать замучаешься.
Лучше один раз потратить много времени на изучение стандартного решения, а затем регулярно следить за его обновлениями, чем каждый раз разбираться в коде вот таких "всё своё, домашнее" кулибиных.
Таким образом, нужен специалист, который будет знать (Если берём WEB) NodeJS, Nest, желательно принципы работы V8, а в идеале, ещё и пакеты, которые входят в зависимости. При этом, будет постоянно следить за обновлениями каждого, следить какие функции объявлены Deprecated, следить за изменениями в принципах работы каждого и поддерживать этот зоопарк технологий, а всё ради чего...?
А ведь помимо Nest-а и JS-а есть ещё миллион других технологий.
Таким образом, работодатель получает головняк с поиском сотрудника (Каждый становится супер специфичен) и тот, кто работал с React уже вряд ли подойдёт на Nest
Работник получает головняк с постоянным переучиванием. Вместо того, чтобы учить, как это работает под капотом, он всё время изучает новые технологии, чтобы не отстать от тренда.
А пользователь получает сайт, который грузится в течение 10 секунд, хотя это всего лишь одностраничник, на котором только картинки, текст и форма обратной связи снизу справа.И заниматься поддержкой всего этого не менее сложно. Во-первых, пойди найди человека который действительно хорошо знает один из тысячи фреймворков на экспертном уровне. Во-вторых, даже если ты его нашёл - это не значит, что он будет работать у тебя 10 лет. А через 10 лет ты рискуешь вообще не найти разработчика под свои задачи, потому что этот фреймворк уже мёртв, аки паскаль
А ведь во всех этих бесконечных фреймворках, бывают баги...
И с другой стороны, можно держать спецов, которые досконально знают чистый NodeJS вдоль и поперёк, знают особенности JS-движков, и которым всё что нужно - это вникнуть в код, который вот перед глазами
Phoenix-616
27.08.2023 08:32Мне кажется, главная претензия автора не в том, что все должны перекатываться на чистый Си, писать вручную вызывать системные вызовы, и аллоцировать память.
А в том, что сейчас ситуация выглядит примерно как "Ехал фреймворк через фреймворк, видит фреймворк в фреймворке фреймворк"Мне было бы любопытно познакомиться с человеком, который на чистом Си и стандартной библиотеке способен написать современное готовое к продакшену комерческое веб решение и способный убедить в необходимости этого менеджмент :)
Понятно, что у автора речь шла именно об отказе от фреймворков, а не от высокоуровневых языков (хотя технически Си тоже к ним относится).Могу ошибаться (Не силён в веб-технологиях, прошу поправить, если не прав), но тем не менее, сейчас мы имеем ситуацию, когда условный Nest транслирует код в код на NodeJS, который обращается к движку V8, который преобразовывает всё это в байткод. А ещё, в проекте скорее всего задействовано штук примерно 50 разных зависимостей, который тянут за собой ещё 150 зависимостей. А ещё, наш фронтенд, который и без того тяжёлый, скорее всего ждёт выполнения каких-то API запросов, которые выполняются на сервере, на котором примерно такая же ситуация.
И получается гигантских размеров многослойный пирог, который распутывать замучаешься.Тут, мне кажется, идет смешение понятий фреймворк и библиотека. Фреймворков в силу определения не может быть много, они задают форму всего приложения и зачастую строятся по принципу "фреймворк вызывает код программиста". С библиотеками все наоборот, они ни как не ограничивают код, который их вызывает. В JS мире тонны зависимостей вызваны как раз библиотеками, которые там на любой чих, а так же скромностью стандартной библиотеки.
Rest of message
Да, в IT нужно постоянно учиться. Нет, постоянная актуализация знаний не отменяет необходимости знать, как устроена база под капотом (напротив, чтобы понять, почему фреймворк работает так, как он работает, нужно знать, какие возможности языка это позволили разработчикам фреймворка). Этот же принцип работает и для библиотек. По этой же причине, если планируется в дальнейшем как-то расширять приложение, его код нужно держать в актуальном состоянии. Это позволит при необходимости легко найти специалиста, который его модифицирует.
А касательно специализации... На мой взгляд, принципиальной разницы между современными языками комерческой разработки нет. У всех одна база из 20 века, и с тех пор в IT не то чтобы много что поменялось. Как говорится, ассемблер лишь синтаксический сахар над машинным кодом :)
Nurked Автор
27.08.2023 08:32+1Вы абсолютно правы.
Тут ещё надо знать об одном ужасном монстре, который называется "Устаревание фреймворков". Например, если вы возьмёте код, написаный на Meteor, 5 лет назад, то вы увдите, что он безбожно устарел, доков не сыщешь днём с огнём, и приходится надеятся на старые посты из reddit или SO.
А обновить до новой версии - даже смешно об этом думать. В итоге, мы залочены на что-то, что гоняется только на 12 версии нода, пестрит ворнингами, и единственный выход из всего этого - переписывать с нуля.
Несмотря на то, что я не очень доволен обратной совместимостью яваскрипта (я бы сказал, что babel и webpack), но чистый код на скрипте всё-равно лучше, чем какой-то странноватый фреймворк, под которого вам надо будет выделять раба, который бы занимался только тем, что раз в два месяца апгрейдил проект, а потом переписывал весь код под новую версию фреймворка.
spidersarecute
27.08.2023 08:32А обновить до новой версии - даже смешно об этом думать.
Почему смешно об этом думать? Обновлял фреймворки и библиотеки в большом проекте, правда не на JS. Да, кропотливо, иногда месяц возни и рукописные скрипты для автоматизированной правки кода, но обновляется же в итоге.
gatoazul
27.08.2023 08:32Это пока вы не дойдете до ошибки в самом фреймворке. Или хотя бы до какого-то неочевидного места.
Boilerplate
27.08.2023 08:32+30Если получилось заменить один проект ASP .NET на проект из одного main.go, то это означает, что у вас был максимум одностраничный лендинг. Все эти депенденси инъекшин, контроллеры и кучу слоев абстракций придумали не для того, чтобы продавать очередной фреймворк. А чтобы делать крупные проекты, и иметь возможность внедрять новые фичи за константное время. Если все напихать в один main.go, или index.php, то начиная с примерно 2-3к строк скорость внедрения фич будет зависеть от объема кода, а также приводить к регрессионным багам.
Короче, заменить все на повершел и велосипеды невозможно, если вы не гугл. А заменять подходы и архитектуры тем более не стоит.
P.S. Но с другой стороны я согласен с тем, что тянуть кучу фреймворков на каждый чих, это тоже антипаттерн. У меня на том же фронте обычно только какой-нибудь фреймворк типо vue.js и стандартный javascript. А другие фреймворки и либы стараюсь не тянуть.
Nurked Автор
27.08.2023 08:32-116.5k строк в main.go. И что? Кому от этого хуже? Правилу о том, что функция не доджна быть длинее чем 20 строк?
Прикол в том, что это всё равно будет проще чем DI. Я просто бывал в обоих лагерях.
flygrounder
27.08.2023 08:32+23Кому от этого хуже?
Программистам, которым это потом придётся поддерживать. Вы будете всё понимать т.к. сами это написали. Но чтобы объяснить другим, как здесь всё делается, придётся писать документацию и описывать, как решать стандартные задачи в вашем проекте. Не легче уж тогда выучить фреймворк чем учить костыли от ChatGPT специфичные для вашего проекта? Ведь фреймворк как раз предоставляет стандартный способ решения стандартных задач и вам остаётся писать только специфичные для вашего проекта вещи.
Nurked Автор
27.08.2023 08:32-4А что, конкретно сложного в том, чтобы увидеть ошибку в файле, открыть эту строку, увидеть название функции а потом поискать эту функцию обыкновенным поиском и найти то место, откуда она вызывается.
В чём костыль простого кода, который работает.
Костыль - это обёртка для работы с базой данных, которая подключает логику через DI.
flygrounder
27.08.2023 08:32+15Ваши примеры показывают только, что он простой для простых задач. Было бы интересно посмотреть на enterprise проект в таком стиле.
rg_software
27.08.2023 08:32+24Если доводить эту логику до абсурда, представьте себе, что некто пишет на языке высокого уровня типа Swift или C#, а потом с помощью транслятора переводит всё это дело в C и даёт вам в качестве исходника. Ну и что, что лапша, и автоматически сгенерированные файлы по 10500 строк? Это же простой код на простом языке, и go to definition прекрасно работает, enjoy.
CommanderTvis
27.08.2023 08:32+3Лучше так. Этот некто пишет на Java, затем с помощью GraalVM компилирует всё в ассемблер, затем декомпилирует это дело на Fortran. Enjoy.
Nurked Автор
27.08.2023 08:32Это уже безумие. А как раз этому вопросу я уделил последние абзацы статьи.
rg_software
27.08.2023 08:32Как бы да, но если почитать комменты, то складывается впечатление, что спор исключительно о критериях того, где пролегает крайность. Вроде как leftpad через фреймворк -- это одна крайность, код на С из транслятора -- другая, а умеренное велосипедостроение -- вроде ок, осталось понять, где оно.
dgoncharov
27.08.2023 08:32стандартный способ решения стандартных задач
Тут есть логическое противоречие. Если есть некий набор стандартных задач с известными способами решения, то использование ChatGPT очень уместно. Потому что он может в ответ на фразу "А реши-ка мне такую задачу" выдать это известное решение - пусть с использованием фреймворка.
Но в результате программирование становится еще более высокоуровневым. И если мы начинаем программировать в терминах стандартных задач, то становится возможной оптимизация решений этих задач. В т.ч без использования фреймворков или вообще на низкоуровневых языках.
Иначе говоря, фреймворк оказывается временной подпоркой, которая была полезна на каком-то этапе развития технологий, но впоследствии утратила свое значение. В любом случае, фреймворки не вечны и имеют свой жизненный цикл. Если фреймворк снимается с поддержки, то решение без его использования может оказаться более долговечным.
Boilerplate
27.08.2023 08:32+5Не знаю какие именно 6.5к строк у вас, но звучит это довольно паршиво. Возможно, если выделить часть этого кода в отдельную библиотеку, то новому программисту будет проще сделать фичу в такой проект без необходимости изучать все 6.5к строк.
С DI есть интересное наблюдение. Если убрав DI код стал лучше, то DI тут был не нужен. Я встречал людей, которые пихали DI внутри библиотеки бизнес-логики, не понимая смысла DI. Естественно, такое применение не привносило ничего, кроме дополнительной сложности и лишних проблем с отладкой.
Из нормального применения DI - это обертки над внешними сервисами, когда вы внедряете в бизнес-логику IMessageSender какой-нибудь, а при использовании бизнес-логики на разных проектах в одном проекте подставляется отправка сообщений СМС, в другом Слак, в третьем ТГ.
Или, например, IMarketingPolicy, отвечающий за маркетинговые правила продаж в магазине. При этом основная библиотека отвечает за работу разных частей магазина (корзины, заказов, продаж), которые есть у всех, а ценообразование, разное для разных магазинов, формируются через реализацию и внедрение IMarketingPolicy.
Да, в этих примерах тоже без DI можно обойтись, например, храня глобальные объекты и подставляя их в конструкторы. Но не понятно, зачем так делать, если DI как раз этим и занимается.
Nurked Автор
27.08.2023 08:32А в чём плоблема просто передать интерфейс в конмтруктор класса? Ведь когда там написано, что мол, класс без этого IMarketingPolicy по наведению мыши на экземпляр, то оно и понятно. Даже документировать не надо.
Boilerplate
27.08.2023 08:32+9Так интерфейс и передается в конструктор. Только передается с помощью DI. В максимально упрощенном случае DI это и есть глобальный механизм, хранящий в себе объекты с разным временем жизни и подставляющий их в конструкторы сервисов и контроллеров, когда возникает необходимость. Но когда я использую DI из коробки ASP .NET Core, то я знаю, что любой программист с любого другого проекта на ASP.NET Core, увидев
services.AddSingleton<IMarketingPolicy, CosmeticMarketingPolicy>();
поймет, что это такое. И, кстати, даже если программист с ASP.NET MVC придет или даже Spring Boot, то он тоже поймет, что это такое, просто наложив знания о эквивалентных фреймворках друг на друга. Если же я вручную буду организовывать глобальные объекты, то он просто будет вынужден идти и смотреть, что там за объекты с каким временем жизни были созданы.Ну и так далее со всем. Можно использовать такие абстракции как контроллеры, а можно просто накидать кучу методов для обработки тех или иных маршрутов. Можно пакеты грузить из нугета, а можно класть самому длл в папочку. Можно использовать npm, а можно класть руками или скриптом. И пока у вас методов / библиотек / зависимостей - 5-10 штук, то всё ок. Когда их десятки и сотни - уже все равно придется это как-то группировать, выделять по разным файлам. И вот тут придется или выкидывать самокат и пилить заново со всеми этими DI, фреймворками и паттернами, либо это будет звездолет на коленке, в котором любой ногу сломит, так как вместо привычных инструментов и паттернов мы везде имеем своё решение.
lair
27.08.2023 08:32+9А в чём плоблема просто передать интерфейс в конмтруктор класса?
Так это и есть DI, ровно по его определению.
А вы, кажется, путаете DI, как принцип, с DI-контейнером.
rdo
27.08.2023 08:32Хуже тому, кто придет через год после вас поддерживать проект.
Он придет и скажет, что это все надо выкинуть и написать на новом модном языке при помощи чатгпт 5.0, после чего получит один класс на 10к строк кода
Pavel1114
27.08.2023 08:32+2Сейчас даже те кто выше в комментариях вас поддерживал, изменят своё мнение - "разбираться с 6.5 строк при помощи поиска названий функций" на такое они не подписывались )
DBalashov
27.08.2023 08:32+3Рано или поздно (а скорее рано) - для облегчения жизни себе - Вы начнёте вычленять какие-то куски кода в общие абстракции для банального реюзинга кода. И это будет ничто иное как написание некоего своего микрофреймворка, который заточен под конкретный проект. И чем дальше Вы будете писать этот проект - тем больше будет этот микрофреймворк.
И вот когда придёт новый человек на проект - ему придется изучать этот микрофреймворк (а Вы его я надеюсь документировали? :), его особенности и ограничения, перф в разных ситуациях, поведения в разных corner cases, и т.д. И полезность этого будет весьма сомнительна, т.к. этот микрофреймворк больше нигде ему в карьере не встретится. Плюс это занимает время человека, которое небесплатно для работодателя.
Используя плюс/минус более популярные фреймворки - шансов что человек их будет знать и ему не придется с нуля разбираться в вышеперечисленном - значительно выше, а значит бизнес получит новую фичу быстрее и дешевле.
dgoncharov
27.08.2023 08:32+1А чтобы делать крупные проекты
То есть, под довольно специфические задачи, ибо не все проекты крупные по определению.
заменить все на повершел и велосипеды невозможно, если вы не гугл.
Что-то не понял. Как раз для Гугла с его гигантскими проектами невозможно. А для мелких проектов, которым не нужно "внедрять новые фичи", потому что они следуют упомянутым принципам Макилроя - очень даже можно, что автор статьи и показывает.
sved
27.08.2023 08:32+5Программисты во всём мире используют встроенный HTTP в IntelijIdea и довольны как слоны. Зачем нужен этот дикий ужас с баш-скриптами - одному автору известно.
Видимо, само существование Postman-а заставляет кого-то не пользоваться нормальными инструментами и городить огород.
atygaev
27.08.2023 08:32более того даже если это IDEA без встроенного HTTP клиента то все равно можно жить в постмане. Ходить в Bash можно или из большой любви к работе в терминале (как у меня) или просто чтобы максимально "близко" быть к транспорту и запросу/ответу.
Jianke
27.08.2023 08:32+5Подскажите, как нам быть с джуниором, который без ChatGPT даже минимум и максимум в массиве найти не может?
Nurked Автор
27.08.2023 08:32+4Я бы вообще людям разрешил пользоваться генеративным контентом только если они могут показать, что сами этот контент умеют генерировать ручками.
Aniro
27.08.2023 08:32Дайте задачу ответ на которую ллм не знает и посмотрите что он будет делать. Если не справится - увольте, если справится - похвалите.
user5000
27.08.2023 08:32+3Подскажите, как нам быть с джуниором, который без ChatGPT даже минимум и максимум в массиве найти не может?
Значит, это не джуниор, а стажёр. Ему нужно ещё расти до джуниора.
GospodinKolhoznik
27.08.2023 08:32+1Зависит от того, определена ли на типе данных элементов массива операция сравнения, а то может быть не определена, и тогда джун правильно делает, что не может найти максимум.
Dolios
27.08.2023 08:32+26все остальное допишет GPT. И у меня в руках появляется инструмент, который полностью находится под моим контролем.
В итоге получится велосипед такого же размера, как и исходный "фреймворк". Только он будет абсолютно неподдерживаемым, потому что его никто не будет обновлять, а когда автор уволится, никто новый не захочет с ним работать.
Nurked Автор
27.08.2023 08:32-5А что плохого в том, что легко читается?
И я вам умоляю. Поддержка инструментов. Ха! Любой проект, который я видел пришит к старой версие нодика и пестрит 900 ворнингами о том, что они все устарели.
Если что-то работает, никогда это не меняйте. Я вообще не понимаю зачем люди перенимают эту гугловскую идею о том, что версии приложения надо нужно нумеровать сотнями и выпусуать обновление каждую секунду.
API вызов по возврату курса валют, должен быть написан единожды. В смысле сама сигнатура. У разработчиков появляются идеи о том, что надо постоянно что то обновлять.
Надо просто взяться за ум и написать один раз, чтобы потом к этому не надо было возвращаться.
Dolios
27.08.2023 08:32+15А что плохого в том, что легко читается?
Это демагогия. Во-первых, я уверен, ваше решение не будет легко читаться, если оно хоть как-то сравнится по возможностям с тем, что вы переписываете. Во-вторых, зачем вам вообще читать тот же код Bootstrap, чтобы что? Я могу назвать только 2 причины: интересно, как оно там всё устроено или надо баг поправить и пул реквест сделать. Ни в том, ни в другом случае ничего переписывать не нужно.
И я вам умоляю. Поддержка инструментов. Ха! Любой проект, который я видел пришит к старой версие нодика и пестрит 900 ворнингами о том, что они все устарели.
Это исключительно ваша проблема, у меня опыт ровно противоположный.
API вызов по возврату курса валют, должен быть написан единожды. В смысле сама сигнатура. У разработчиков появляются идеи о том, что надо постоянно что то обновлять.
Опять демагогия. Мы не про вызов API, а про React, Bootstrap и т.д.
Надо просто взяться за ум и написать один раз, чтобы потом к этому не надо было возвращаться.
Зачем вам тестеры, надо сразу без ошибок писать (с)
CommanderTvis
27.08.2023 08:32+1ChatGPT не способствует тому, чтобы к коду не нужно было возвращаться. Если бы очень хороший программист мог проанализировать на предмет всех ошибок чужой (в данном случае за авторством ChatGPT) код, то багов бы уже давно не было…
offline268
27.08.2023 08:32+3Надо просто взяться за ум и написать один раз, чтобы потом к этому не надо было возвращаться
Не это ли цель фреймворков? Ну написать какие-то базовые механизмы, которые будут переиспользованы тысячами программистов ол овер зе ворлд
nidalee
27.08.2023 08:32+1Проблема в том, что когда механизмов в фреймворке становится тысяча, а нам из них нужно только два — мы получаем голосовой чат и мессенджер размером в пол гига (Discord).
offline268
27.08.2023 08:32+2Для какой-то поделки на коленке, можно подыскать библиотеку с нужной функциональностью, ну или написать самому (хоть даже с помощью того же ИИ)
Дело не в том, что фреймворки - абсолютное зло, и не в том, что читжпт абсолютное добро. Скорее всего есть разные инструменты для разных требований и условий.nidalee
27.08.2023 08:32+3Звучит как стрельба по воробьям из пушки. Для какой-то поделки на коленке, можно подыскать библиотеку с нужной функциональностью
Проблема в том, что фреймворки уже суют куда ни попадя, потому что это быстрее, а время — деньги.
spidersarecute
27.08.2023 08:32Если что-то работает, никогда это не меняйте. Я вообще не понимаю зачем
люди перенимают эту гугловскую идею о том, что версии приложения надо
нужно нумеровать сотнями и выпусуать обновление каждую секунду.Ну обновлять библиотеки все равно придется, например:
исправления ошибок и уязвимостей перестали выпускаться для старой версии
новые плагины не совместимы со старой библиотекой
старая библиотека не поддерживает современную версию языка программирования
То есть, либо вы обновляете библиотеку до новой версии, либо мучаетесь с устаревшей на 5 лет версией.
anonymous
27.08.2023 08:32НЛО прилетело и опубликовало эту надпись здесь
sergeaunt
27.08.2023 08:32+1Забавно. Вспомнил, как, будучи зеленым студентом, доказывал опытному разрабу, что "Java is dead" - это очень смешная шутка. Тогда вообще уже хз сколько лет было модно хоронить джаву. Это было лет 10 назад.
Итак, на дворе 2023 год. В моей команде работает несколько бывших шарпистов, которые перешли на джаву. Судя по отзывам знакомых, на дотнете очень мало проектов.
Ну, и 10 лет, потраченные на Скалу, помогают и в джаве в том числе, потому что это не только язык, но и платформа. А слушать хвастовство сишарпа фичами, зная скалу... Ну, это не смешная шутка.
dgoncharov
27.08.2023 08:32Тогда вообще уже хз сколько лет было модно хоронить джаву.
Потому что изначально она была жутко медленная и никакого приятного впечатления не производила. Апплеты и вот это вот всё.
sergeaunt
27.08.2023 08:32+2Ну да, всё верно. Сначала хоронили, потому что медленная. Потом ее должен был убить .NET. Потом пачками пошли убийцы: Scala, Go, Kotlin, тысячи их. Собака лает - караван идет.
xenon
27.08.2023 08:32+2А идет ли? Я сейчас не утверждаю, что технология умирает, но мне кажется, что многие технологии живы не просто так, они как бы живы, но при этом средний возраст их программиста сильно растет. Это просто старая опытная команда (может быть - заслуженно очень хорошая команда) пишет на том, что ей удобно. Или еще вариант - компания все автоматизировала на джаве, сейчас бы может быть и иначе бы сделала, но система уже есть, и ее проще поддерживать-дорабатывать, а не "до основанья, а затем". В общем, как-то надо отличать когда караван бодро идет, а когда по инерции.
sergeaunt
27.08.2023 08:32Вы хотите сказать, что на Java сейчас толпами не валит молодежь? Возможно. Если про Core Java говорить.
xenon
27.08.2023 08:32+1А я не знаю. Самому было бы любопытно узнать. Но я про то, то оценивать это надо каким-то хитрым способом и мне самому интересно, как бы правильно это оценить? Например, если в сбере 20 лет назад написали систему на Java - скорее всего, даже если язык умрет и будет похоронен - все равно, она будет еще 50 лет жить, ибо она уже есть, увязана в бизнес-процессы и заменять ее тяжело. Так же как еще недавно (а может быть даже и сейчас) был жив Cobol. И молодых программистов сбер будет набирать со знанием джавы (хотя бы на уровне хелловорлда).
Но представим, что за последние 10 лет все новые банки писали свои внутренние системы с нуля НЕ на Java. Тогда получится интересная ситуация - с одной стороны, много вакансий java программистов, много программистов (из сбера переходят в аэрофлот и обратно), новые программисты учатся на Java и востребованы, получают высокие ЗП, но при этом было бы очевидно, что язык умирает (раз новых проектов не начинается там, где есть выбор)Может даже быть так, что язык популярен за счет традиции (но технически уже устарел - писать на нем долго, дорого, код потом тяжелый). Например (на примере тех же банков) - все было раньше на Java, поэтому вся команда - джависты, поэтому и новые проекты они тоже пишут на Java и молодых нанимаеют именно на Java. И когда родится новый Тинькофф-банк, он, не имея наследия, для создания своей системы переманит себе опытных банковских программистов (ну не с улицы же) - а они все джависты. В итоге, караван идет, статистически язык вроде бы востребован, но исключительно за счет традиций.
sergeaunt
27.08.2023 08:32+1все было раньше на Java, поэтому вся команда - джависты, поэтому и новые проекты они тоже пишут на Java и молодых нанимаеют именно на Java
В моем пузыре это намного ближе к реальности, чем
за последние 10 лет все новые банки писали свои внутренние системы с нуля НЕ на Java
И, кстати, "традиции" - это дааалеко не единственное достоинство джавы. Банку, который решил писать критичные системы на каком-нибудь питоне или, прости господи, JS, могу только пожелать удачной поддержки.
alemiks
27.08.2023 08:32+5Встречайте. Код на vugu. Достаточно тихий golang фреймворк, который позволяет вам писать webassembly код прямо на golang.
классно, жаль это фреймворк загнулся 3 года назад
Nurked Автор
27.08.2023 08:32-1Проверь гитхаб. 5к звёзд, отлично себе живёт.
s207883
27.08.2023 08:32+5Последнее обновление сайта в 2020 году было, не очень как-то живёт
AndreyAlin
27.08.2023 08:32Жить Для ПО жить - это не значит постоянно обновляться. Это значит работать и быть востребованным. Зачем в проекте постоянно что-то доделывать и обновлять, если он уже окончательно доделан и идеально выполняет все свои функции?
Nurked Автор
27.08.2023 08:32Я просто лично знаю создателя. Он его пилит. Но проект авторский и у него не хватает щас времени этим заниматься. Мы собирались в Марте 2022 с ним вместе приехать на конференцию по golang в Москву.
Не вышло, почему-то.
Мы тогда вместе с ним работали. Я написал полноразмерную систему по управлению VPS на чистом vugu без яваскрипта. Сам фреймворк работающий. Просто надо понимать сколько сил стоит написать такое. И уж тем более понимать, сколько смл стоит запустить это всё через tinygo, вместо нормального компилятора.
alemiks
27.08.2023 08:32+5по количеству звёзд умеешь определять "живость" проекта? Вот тебе задачка тогда: есть проект с 28k звёзд, он живой или нет?
Я обычно первым делом смотрю на кардиограмму пациента, а не сколько медалек (хотя и это тоже важно, как один из факторов, а не как единственный). На медальки, кстати, тоже можно посмотреть, но не в моменте, а во временном разрезе (например, тут). Как видишь, проект загнулся (можешь посмотреть на график получения звёзд живых проектов). Также уже писали, что новости не обновлялись с 2020. Также в issues автор пишет, что "есть желание, но нет возможности". Проект загнулся, смирись :)
lair
27.08.2023 08:32+12Вы можете просто заставить GPT сгенерировать вам нужный код. [...] Без бесконечных фреймворков и зависимостей от чёрт знает чего.
Да нет, вы просто заменили зависимость от фреймворка на зависимость от ChatGPT.
Nurked Автор
27.08.2023 08:32-8Даже если его завтра отключат - у меня в руках вполне себе удобочитаемый код.
lair
27.08.2023 08:32+6А вот это совершенно не обязательно. Чем сложнее задача, которую вы будете ставить, тем больше вероятность, что код перестанет быть читаемым.
Смысл фреймворка - он, на самом деле, не в том, чтобы давать общую функциональность (хотя и это тоже). Он в том, чтобы давать общие принципы разработки, общие способы решения типовых (для фреймворка) задач, тем самым упрощая чтение.
Lexicon
27.08.2023 08:32+6Преимущество фреймворков в консистентности. Попрактиковавшись, вы знаете, какие задачи он закрывает, и что ускорит для вас. Вы даже можете научить GPT упрощать рутину для фреймворка.
ChatGPT, всегда - выиграть 15 минут, дивясь как довольная девица от сэкономленного времени => потратить 2 часа, на то, чтобы довести до ума элементарный промт и понять, что проще было написать. Его вклад приятен, но непредсказуем.
Чатботы так же не слишком умеют различать эффективные решения(вокруг которых формируются фреймворки) и самые массовые. Веса LeetCode'ров заставят бота предпочитать решения не соответствующие промышленной разработке.
Я бы также сказал, что несмотря на упрощение порога входа, люди, с глубоким пониманием фреймворков развиваются, вникая в суть ограничений и паттернов. Мне тяжело представить компетентного спеца, выросшего из вашего эксперимента
xenon
27.08.2023 08:32+2В каком-нибудь условно проекте, 99% кода занимает фреймворк и 1% - уже собственные доработки поверх него. При смене (добавлении) программиста в проект, он должен владеть кодом проекта. Фреймворк тут хорош тем, что программист на этом фреймворке уже более-менее знаком с 99% вашего кода. И вот с кодом от чатгпт такого быть не может.
Доработать этот код - вообще беда. Проще уж самому все написать с нуля.
mvv-rus
27.08.2023 08:32+16Это коментарий, так что буду краток.
Основная идея обсуждаемой статьи — поменять способ создания boilerplate: вместо написанного вручную для массового использования каркаса приложения (framework) — создавать каждый раз заново под конкретный случай (ad hoc) boilerplate с помощью генеративного ИИ.
Достоинства автор описал сам, так что я буду писать о недостатках.
Основной недостаток: boilerplate — это тоже код. Его недостаточно один раз написать — особенно, учитывая, что современный генеративный ИИ без ошибок писать пока что не может. Его надо поддерживать: читать и модифицировать. В framework это делают его авторы — и сразу для всех. А кто будет делать это со сгенерированным ИИ кодом? Тот же генеративный ИИ — сомневаюсь, что он сможет сделать это хорошо: генеративный ИИ AFAIK — он вроде представителя коренного народа Севера СССР из старого анекдота: "не читатель, а писатель". Значит — человек? Если так — то надо ли объяснять недостатки?
Другой недостаток: каждый проект становится уникальным чуть менее чем полностью. Вновь пришедший разработчик будет иметь дело не со стандартным (при всех недостатках с документированием и т.п.) boilerplate, а с уникальным boilerplate. И у меня есть серьезное подозрение, что это отрицательно повлияет на экономическую эффективность разработки.Резюме с аналогией: автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии.
eton65
27.08.2023 08:32Если для кода, сгенерированного ЧатЖпт, оставлять набор ключевых фраз (или просто всю историю генерации), то для изменения кода его не надо будет читать — все сделают роботы, надо только выдать им новое задание.
Резюме с аналогией: автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии
Вы даже не представляете от какого прекрасного будущего отказываетесь.
rg_software
27.08.2023 08:32+7Чтобы выдать задание, надо внятно и чётко его сформулировать. Значит, надо выражаться ясно и чётко, как юристы, например. Но мы знаем, как выражаются юристы, и обычно это наводит тоску. Можно сделать шаг вперёд, а можно два или три (каждый пусть вообразит их себе по своему вкусу). Почему бы не пропустить теперь промежуточные шаги и не прийти к выводу, что можно написать задание на хорошем формальном языке, например, на C#?
dgoncharov
27.08.2023 08:32"ясно и четко" - вовсе не значит "как юристы". Высказываться ясно и логически непротиворечиво - возможно и нужно. И при общении с людьми - в неменьшей степени, чем с ChatGPT.
rg_software
27.08.2023 08:32+2Ну юристы тоже не с потолка берут свои способы выражения мыслей.
dgoncharov
27.08.2023 08:32А откуда они их берут? Вы же сами понимаете, что они не являются примером ясности высказываний. Так зачем вообще говорить про них.
rg_software
27.08.2023 08:32+6С моей точки зрения они берут ровно от желания формулировать мысли с минимальными возможностями разночтений. Соответственно, для специалиста эти тексты являются примером ясности высказываний, но для их чтения нужно иметь определённое образование, и это нормально. Если вы захотите писать чёткие задания для ChatGPT, то рано или поздно придёте к тому же самому. А если учесть, что в отличие от юридических документов инструкции для ChatGPT имеют форму императива (сделай то-то и то-то), мы можем убрать из естественного языка всё ненужное и оставить инструкции. А ещё можно упростить синтаксис. Получится C# или что-то в этом роде, и тогда ChatGPT вообще не нужен.
dgoncharov
27.08.2023 08:32+1Я не согласен со многими вашими утверждениями. Возможно, юридические тексты и имеют однозначную интерпретацию, но ясными они от этого не становятся, скорее наоборот. (Мне казалось, что вы сами об этом и сказали.) И это потому, что смысл высказываниям придает контекст (связи между понятиями), а юристы интенсивно обрубают все возможные дополнительные контексты. Ну и в другом комменте я еще высказался на эту тему: https://habr.com/ru/articles/757150/#comment_25902802
Вообще мне кажется странным, что вы вспомнили юристов, а не логиков или математиков.
rg_software
27.08.2023 08:32+2Они не становятся ясными вам, потому что вы не юрист. Думаю, юристу эти формулировки предельно понятны. Конечно, можно попытаться кормить модели контекст и т.д. и т.п. (хотя у юристов контекст тоже есть, например, в шапке документа написано, что это "Договор" или "Доверенность"), но мне не совсем понятно целеполагание. Говорите, можно избавиться от записи Бэкуса-Наура? Ну да, можно, но это что, rocket science и доступно лишь избранным? Если вы хотите описать чёткое техзадание, не допускающее неверных трактовок, зачем пользоваться для этого человеческим языком, если есть язык программирования. Он предназначен для инструкций, он трактуется однозначно, он прост синтаксически.
CommanderTvis
27.08.2023 08:32+3Потому что логики и математики и без нас с вами пишут на предельно формализованном языке. Юристы пытаются писать что-то однозначно на естественном языке.
Dr_Faksov
27.08.2023 08:32+1Знаете, чем юристы отличаются от обычных людей? Они понимают сказанное\написанное буквально. Потому что обычные люди, говоря некую фразу, не договаривают кучу информации, считая это само-собой разумеющимся. А потом удивляются, что их не так поняли.
Вот по тому юристы и обрубают всё лишнее.
Анекдот. Два друга - юриста, в перерыве между судебными заседаниями зашли в ресторанчик. Заказали по чашке кофе и достали из портфелей по бутерброду, приготовленные заботливыми женами. Тут официант принёс кофе, увидел бутерброды и сказал -"Извините, но у нас со своей едой нельзя". Юристы переглянулись....и обменялись бутербродами.
eton65
27.08.2023 08:32Чтобы выдать задание, надо внятно и чётко его сформулировать.…
Почему бы не пропустить теперь промежуточные шаги и не прийти к выводу, что можно написать задание на хорошем формальном языке, например, на C#?Вам ТЗ на каком языке дают?
rg_software
27.08.2023 08:32+4Магии нет. Если человек умеет писать настолько чётко и внятно, чтобы не было разночтений, ему вообще незачем писать ТЗ, он пишет сразу код. Если же он предпочитает писать инструкции на человеческом языке, значит, в них заведомо будут противоречия и разногласия, которые постепенно вытравляются по мере того, как неформальное задание превращается в код.
Практически любые утверждения типа "бот заменит программиста" исходят из того, что работой программиста является перевод ТЗ в код. Я так не думаю, мне кажется, что работа программиста -- это последовательное и методичное устранение неоднозначностей исходного ТЗ, по мере которого неформальное описание постепенно всё больше формализуется.
Разумеется, в любой задаче полно подзадач, для которых любое решение годится. Но для этого и есть библиотеки, фреймворки и таблицы стилей. Неважно, как выглядит вебсайт, лишь бы работал? Ну берём стиль №123, и вперёд.
eton65
27.08.2023 08:32Если же он предпочитает писать инструкции на человеческом языке, значит, в них заведомо будут противоречия и разногласия, которые постепенно вытравляются по мере того, как неформальное задание превращается в код
Возможно сам подход "написать сразу на 100% полное ТЗ" является избыточным. Когда заказчик объясняет программисту, что ему надо получить, он начинает с более общих вещей, постепенно переходя к деталям (когда уже что-то может быть сделано). Тем самым у исполнителя сначала формируется картина в целом, для воплощения которой уже можно выбирать архитектуру проекта. Т.е. здесь на первый план выходят когнитивные искажения при передаче информации.
Практически любые утверждения типа "бот заменит программиста" исходят из того, что работой программиста является перевод ТЗ в код. Я так не думаю, мне кажется, что работа программиста — это последовательное и методичное устранение неоднозначностей исходного ТЗ, по мере которого неформальное описание постепенно всё больше формализуется
Я думаю, истина где-то посередине: необходимость строгой формализации в виде кода способствует строгой формализации в виде ТЗ.
mvv-rus
27.08.2023 08:32+2Если для кода, сгенерированного ЧатЖпт, оставлять набор ключевых фраз (или просто всю историю генерации), то для изменения кода его не надо будет читать — все сделают роботы, надо только выдать им новое задание.
Да. «Но есть нюанс»(с): подсказки — это не формальное написание на формальном языке, их интерпретация неоднозначна. А потому, если роботы напишут новый код для boilerplate, он с высокой вероятностью будет другим. А в коде, специфичном для программы, написанном человеком (буду называть его смысловым), почти наверняка будут завязки на существующий код boilerplate. И они могут быть не только на имена переменных/функций(их-то несложно добавить в новые подсказки), но и на специфические особенности его поведения, не описанные в первоначальных подсказках, а получившееся при прежней генерации. И нет никакой гарантии, что новая генерация сохранит эти особенности. Так что для подстройки к вновь сгенерированному boilerplate придется править и смысловой код. То есть, проделывать работу, аналогичную переходу на новую версию фреймворка, только в большем объеме: авторы фреймворков все-таки стараются не вносить изменения, нарушающие совместимость версий, а от генеративного ИИ это пока ожидать трудно.
Ну и учитываем несовершенство современного генеративного ИИ: код за ним надо править. В частности, вновь сгенерированный код вместо старого уже исправленного надо будет править заново.dgoncharov
27.08.2023 08:32Хороший коммент, по делу. Но давайте все-таки не делить дихотомически языки на формальные и неформальные, а согласимся, что степень формализации и логической строгости может быть различна. И что если исключить из естественного языка некоторые риторические фигуры (метафоры и т.п.), то интерпретация может быть вполне однозначна и без абсолютной формализации в стиле Бэкуса-Наура.
Далее, при расширении контекстного окна (числа токенов) можно будет скармливать языковой модели весь предыдущий код, так что новая генерация вполне может перенимать особенности старой. Даже если в этом случае обработка будет требовать более длительного времени.
mvv-rus
27.08.2023 08:32+1Но давайте все-таки не делить дихотомически языки на формальные и неформальные,
Давайте: перейдем на уровень ниже Нам, собственно, требуется однозначность не для любого утверждения, сделанного на языке (то, что делает язык формальным), а для нашего конкретного утверждения (или их набора) в подсказке. Кто или что будет эту однозначность проверять? Люди с этим справляются плохо (вспоминанем, к примеру, истории про джиннов). Генеративный ИИ под это, насколько я знаю, тоже не заточен — он работает на других принципах.
Ну, и дообучение по ходу на предыдущем языковом коде — оно, насколько я знаю, результат тоже не гарантирует.
Короче, если не будут решены эти вопросы, то мечты автора статьи так и останутся мечтами.
А как их решать и можно ли это сделать в принципе на основе имеющихся подходов — это уже, увы, выходит за пределы моей компетенции. Так что я дальше обсуждать эту тему не могу.dgoncharov
27.08.2023 08:32Кто или что будет эту однозначность проверять?
Ее не нужно проверять, ее нужно обеспечивать. В том смысле, в каком чистая функция при вызове с теми же аргументами дает тот же результат. Разумеется, никто не спорит, что нерешенных проблем еще много. Спасибо за хорошую дискуссию.
offline268
27.08.2023 08:32+1Вы даже не представляете от какого прекрасного будущего отказываетесь.
Безусловно, жить в мире где каждый ездит на своем уникальном велосипеде прекрасно. Но можно посмотреть на обратную сторону стандартизации. Например когда из Калины выкинули подушки и абс в интернетах резко разразился вой. мол жить так невыносимо и мы все неминуемо должны погибнуть.
Экстраполируя на ПО можно предположить что популярные фреймворки и библиотеки имеют хороший баланс надежности, производительности и безопасности. Более того, в либах уязвимости каждый день выявляются и правятся. Кто будет этим заниматься, если вы используете велосипед от чатжпт?
Alexey2005
27.08.2023 08:32+2Фреймворки — они ведь и для злоумышленника очень удобны: код чаще всего открыт, а нашёл уязвимость — сразу миллионы приложений можешь сломать. Мало того, можешь ещё и продать эту уязвимость, потому как рынок огромен.
А вот когда для каждого приложения надо искать дыру индивидуально, потому что пишут сплошь велосипеды, злоумышленникам сразу становится очень грустно.
polearnik
27.08.2023 08:32+1запустить пару массовых сканеров на общие ошибки это сложно? sql иньекции пропадают как класс изза того что большинство пишет на фреймворках которые используют парамтеризованные запросы. А тут велосипеды котоыре пишут люди разной подготовки (в основном новички спецы имеют свои собственные фреймворки)
MiraclePtr
27.08.2023 08:32На это можно и в обратную сторону посмотреть: в случае с фреймворками гораздо больше глаз, которые делают ревью, аудит кода, большой интерес со стороны white hat researchers, и т.д., в случае нахождении дыры - она очень оперативно фиксится, и для ее закрытия достаточно просто накатить апдейт.
С подходом "я неуловимый Джо" и 'security through obscurity" же, с момента когда злоумышленники нашли и начали эксплуатировать дыру, и когда разработчик/владелец почуял, что что-то не так, может пройти очень много времени, и пофиксить ее просто так не получится, потому что чел, писавший код, уволился два года назад, а никто из ныне работающих не может нормально разобраться в нагромождении этих велосипедов и костылей.
Не говоря уж об эффекте Даннинга-Крюгера, когда каждый второй Васян полностью уверен, что он уж точно напишет свой код лучше и безопаснее чем сообщество людей, которое на разработке которого собаку съело. В области cybersecurity таких даже с некоторых пор вывели золотое правило "Don't roll your own crypto", потому что в большинстве случаев подобное заканчивается очень печально.Nurked Автор
27.08.2023 08:32Со второй частью вашего коммента согласен. Но а с первой - я вас умоляю. Если за нормальную проверку на безопасность никто не заплатит, то её никто не проведёт.
Более того, все эти замечания об ошибках безопасности в NPM так и остаются в консоли. Сколько раз я видел сообщение о том, что 56 пакетов ужасно уязвимы, и вы просто должны себя убить об стену, используя их.
Но проблема-то в том, что всё написано на старой версии метеора, и делать version bumb = переписывать весь сервер. Так что все эти аудиты просто лежат в сторонке и стонут.
eton65
27.08.2023 08:32Кто будет этим заниматься, если вы используете велосипед от чатжпт?
Те, кто обучают чатжпт. Он ведь не обязан писать только небезопасный код. Периодически он будет стучаться к вам и говорить "я поумнел, давай перепишем вот эту часть". Может даже метрики какие-то для сравнения предоставлять.
MiraclePtr
27.08.2023 08:32+1Если для кода, сгенерированного ЧатЖпт, оставлять набор ключевых фраз (или просто всю историю генерации), то для изменения кода его не надо будет читать — все сделают роботы, надо только выдать им новое задание.
Это до тех пор, пока не выйдет следущая версия GPT, обученая на немного другом наборе данных, и котороая внезапно на те же самые промпты будет выдавать совершенно другой результат.
Вы даже не представляете от какого прекрасного будущего отказываетесь.
А теперь замените простой велосипед на гораздо более сложный автомобиль.
И представьте счастье автомеханика в сервисе, когда при заезде новой модели на ремонт вместо плюс-минус одинакового и всем знакомого дизайна ему нужно будет с нуля по чертежам (это в лучшем случае, а то их может и не быть) разбираться в совершенно уникальной и ни на что не похожей конструкции очередного авто.eton65
27.08.2023 08:32Это до тех пор, пока не выйдет следущая версия GPT, обученая на немного другом наборе данных, и котороая внезапно на те же самые промпты будет выдавать совершенно другой результат
Само собой)
И представьте счастье автомеханика в сервисе, когда при заезде новой модели на ремонт вместо плюс-минус одинакового и всем знакомого дизайна ему нужно будет с нуля по чертежам (это в лучшем случае, а то их может и не быть) разбираться в совершенно уникальной и ни на что не похожей конструкции очередного авто
Как же жили самозанятые автомеханики раньше, ремонтируя автомобили совершенно разных марок?
MiraclePtr
27.08.2023 08:32Как же жили самозанятые автомеханики раньше, ремонтируя автомобили совершенно разных марок?
Так о том и речь, что сейчас человек, который знает как поменять тормозные колодки и стойки амортизаторов на паре моделей, без особых проблем поменяет их и на любом другом авто.
Именно потому что сейчас конструкции автомобилей плюс-минус одинаковые. Да, у каждой платформы есть свои особенности и тонкости, но общая суть в большинстве случаев очень близка. А вот если бы каждый бренд изобретал что-то совершенно уникальное и ни на что не похоже - то ой.
holodoz
27.08.2023 08:32В этом прекрасном будущем для замены цепи вам нужно будет переделывать велосипед с нуля, потому что что новая цепь, сделанная на вашем личном заводе, не совместима со старыми звёздами, а новые звёзды, которые вы генерируете, не совместимы со старыми колёсами. Скорее всего, вы даже камеру поменять не сможете. Вот такие вот метафоры.
Nurked Автор
27.08.2023 08:32Только в современном мире разработки в вэбе, вы уже через два года узнаете, что велосипеды ездят без звёздочек, через три они будут без колёс, а через четыре - вообще будут выращиваться на клумбах.
Люди так рассказывают, что прям, вот ни разу в жизни Реакт не вносил breaking changes в свой код.
eton65
27.08.2023 08:32Не обязательно уникальный велосипед прям выплавлять из другого металла, какие-то узлы можно (и даже нужно) брать готовыми. А вот дизайн рамы может быть уникальным абсолютно. Загнали его в 3D-принтер — и вот вы уже владелец неповторимой вещи.
dgoncharov
27.08.2023 08:32автор предлагает вместо завода по выпуску серийных велосипедов множество мастерских, в которой роботы будут делать для каждого свой, в чем-то уникальный, велосипед. IMHO — это не тот путь, которым идет развитие индустрии.
Черт возьми, а я-то всю жизнь думал, что понятие software как раз и означает, что каждый пользователь имеет возможность модифицировать поведение своего hardware под свои потребности, а не как при серийном выпуске. И что этим и отличается информационная эпоха от промышленной.
mvv-rus
27.08.2023 08:32+2Мочь-то он может — в сысле, имеет право. Только вот у громадного большинства людей на это не хватает квалификации и времени. Короче, так неэффективно.
Эффективно — и большинство людей это делает — использовать на одном и том же оборудовании разные сделанные кем-то другим (разработчиками) комплекты ПО, имеющих свое поведение — приложения. Причем, обычно — приложения, слабо взаимодействующие друг с другом, разве что — предусмотренным разработчиками способом. Так что в этом смысле информационная эпоха ещё не наступила (и вряд ли наступит, IMHO).
Да и в другом смысле — в смысле структуры занятости в глобальной экономике — промышленная эпоха продолжается: от того, что производство вещей выносится в условный Китай с дешевой рабочей силой, трудозатраты (в часах) на него сильно не снижаются. Впрочем, это — уже не по теме статьи.
Так вот, раз люди в массе своей все равно используют приложения разработанные кем-то, на продажу. Так что производство приложений все равно должно быть минимально трудозатратно, так же как и производство вещей. И, как я вижу, ничего, на самом деле, в производственных отношениях в обществе сколь-нибудь значительно не поменялось от появления массовой разработки ПО.dgoncharov
27.08.2023 08:32+2Я не буду с вами спорить насчет того, как оно есть (as-is). Наверное, вы всё достаточно точно описали. Но должно ли оно быть так (to-be)? Не думаю. Оно и задумывалось не так, и начиналось не так. Не буду дальше долго рассуждать, сошлюсь на Ричарда Столлмана и Андрея Ершова.
Про эффективность не согласен в принципе, потому что мы не определили, как мы ее измеряем и оцениваем. Нет эффективности в том, чтобы пользоваться чужим приложением, если оно не делает того, что мне нужно. А даже если оно сегодня и делает, что мне нужно, где гарантия, что и завтра так будет?
"производство приложений должно быть минимально трудозатратно" - это как раз и означает, что оно НЕ должно требовать работы целой команды узких специалистов, и что у большинства людей на это должно хватать квалификации.
mvv-rus
27.08.2023 08:32+1Я не буду с вами спорить насчет того, как оно есть (as-is). Наверное, вы всё достаточно точно описали. Но должно ли оно быть так (to-be)?
Какая разница? Объективная действительность внесла коррективы в благие пожелания энтузиастов, и с этим остается только смириться.Про эффективность не согласен в принципе, потому что мы не определили, как мы ее измеряем и оцениваем.
В деньгах, очевидно — которые приносят потребители. А каждый потребитель оценивает сам для себя. Нынешний механизм организации общественного производства работает так. И реальная альтернатива ему, обеспечивающая лучшую производительность труда, не просматривается.это как раз и означает, что оно НЕ должно требовать работы целой команды узких специалистов, и что у большинства людей на это должно хватать квалификации.
Кому оно «должно» или «не должно», и какое это имеет значение? Выяснено, что в объективной реальности дело обстоит именно так, как я написал (ну, почти). И от того, что это кому-нибудь не нравится, объективная реальность не поменяется.
И, знаете ли, производство ПО — это не единственная отрасль, требующая специалистов: да взять хотя бы ту же медицину.dgoncharov
27.08.2023 08:32+1Не надо преподносить результаты чьих-то целенаправленных действий как явления природы. В "объективной реальности" компьютеров и Интернета вообще не существует. Это искусственно созданные объекты. А что касается виртуальных объектов, таких как ПО и информационные системы, то и подавно. Они никакой "объективной действительности" не подчиняются, а исключительно чьей-то воле.
Кому должно? Ну, человечеству, наверное. Какое имеет значение? Ну, наверное, будущее человечества от этого зависит. Это достаточно важная причина?
mvv-rus
27.08.2023 08:32Не надо преподносить результаты чьих-то целенаправленных действий как явления природы.
Вы просто неправильно меня поняли.
Потому что слово «объективный» означет всего лишь «не зависящий от чьего-либо сознания и воли». И в этом смысле многие продукты труда людей не менее объективны, чем явления природы. В частности — написанный программный код: он работает одинаково вне зависимости от того, что о нем думают, и что от него хотят. (кстати, непривычных людей это нередко ставит в тупик).
Процесс создания кода сам по себе — он, да, может подчиняться сознанию и воле конкретного организатора процесса. Но вот оптимальность этого процесса — она объективна. А дальше вступает в силу рынок и конкуренция — и отбирает более оптимальные процессы. И это тот самый способ управления общественным производством — рыночная экономика — лучше которого у человечества на данный момент нет.
Ну, а про будущее мы просто не знаем ничего наверняка. В том числе — и про будущее человечества, и от чего оно зависит. Так что, оставаясь в рамках рациональности, основывать на этом понятие «должно» попросту невозможно.dgoncharov
27.08.2023 08:32Да, я и правда не понял, как это продукты труда людей не зависят от их сознания и воли, если создатель продукта определяет, каким продукт будет.
Ну и если мы не знаем чего-то наверняка, это не означает, что мы вообще ничего не знаем. Весь нынешний AI/ML хайп - он как раз про прогнозирование, предсказание и вероятность. Впрочем, в контексте нашего разговора Будущее - это тоже искусственный объект, который надо скорее не предсказывать, а конструировать.
mvv-rus
27.08.2023 08:32+1Да, я и правда не понял, как это продукты труда людей не зависят от их сознания и воли, если создатель продукта определяет, каким продукт будет.
Конкретный экземпляр продукта, несомненно, зависит от сознания и воли его создателя. К примеру, создатель волен сделать велосипед с квадратными колесами. Но между содателями и потребителями стоит механизм управления экономикой (в нынешнем царстве бездушного чистогана это рынок), который навязывает создателям представление, что, во имя пользы общества, они делать должны, а что — ни в коем случае. К примеру, те же самые квадратные колеса на рынке не купят — и их нынешнему производителю придется добывать средства для существования другим способом. Вот таким вот образом грубая объективная действительность навязывает творцам свою волю: они должны следовать интересам общества.
А что до предсказания будущего, то самая главная трудность в нем IMHO — то что мы не знаем, чего именно мы не знаем. Символ этой трудности — черный лебедь, во всех смыслах — от самой птицы до книги Талеба.dgoncharov
27.08.2023 08:32-1Я понял вашу мысль, спасибо. Но принимая во внимание то, что большинство стартапов, в т.ч. крупных и известных, убыточно, я склонен думать, что именно "квадратные колеса" они и производят. Да, они должны были бы следовать интересам общества, но не следуют. P.S. Вот вы сами и ответили на свой риторический вопрос "кому должны".
mvv-rus
27.08.2023 08:32+1Вот вы сами и ответили на свой риторический вопрос «кому должны».
Да, и я с самого начала знал, что это — ответ. Но я также с самого начала знал, что часто невозможно заранее определить, что соответствует интересам общества, а что нет. А вы писали так, будто это возможно.
А стартапы (в идеале — ибо не исключены злоупотребления, такие как история мисс Холмс) как раз и занимаются выяснением, что же нужно обществу, единственным доступным нам методом: методом проб и ошибок — увы, ничего лучшего в распоряжении человечества нет.
mvv-rus
27.08.2023 08:32+1По другим аспектам статьи.
1. Мне как-то странно видеть жалобы на засилие DI в .NET Framework. В самом языке C# поддержки DI нет, так что эта подержка привносится фреймворками. И в те времена лет 10 назад к средствам веб-разработки в .NET Framework DI можно было прикрутить только к MVC. И то, надо было именно прикручивать. AFAIK у MS даже не было своего DI, и, по крайней мере, Адам Фримен в тогдашнем своем учебнике по MVC прикручивал какой-то сторонний. Ну, а как можно было бы прикрутить DI к Web Forms или к приложениям, работающим непосредственно с конвейером IIS — это я себе даже не представляю (впрочем, могу ошибаться — это тогда не было моей областью профессиональных интересов).
2.Читая про то, что много мелких файлов кода хорошо, а один большой —плохолучше, я, как ненастоящий программист, радуюсь, что дух настоящих программистов (тех, которые не используют Паскаль) — «настоящие программисты могут без смущения написать цикл DO на пяти страницах» — живет. Но, насколько я знаю, менеджеры в душе не любят настоящих программистов и стараются без них обойтись. Потому что любят экономичность и управляемость.
sergeaunt
27.08.2023 08:32Не знаю, кому как, а мне гораздо проще правильно написать кусок кода с нуля, чем найти ошибку в готовом, который еще и не я писал. Особенно если это какой-нибудь SQL. "Хм, ну вроде похоже на правду, коммитим". И это я еще очень въедливый ревьюер. Это сразу ставит жирный крест на идее использовать дегенеративные сети для создания мало-мальски надежного кода.
anone8729347
27.08.2023 08:32+9Постман. Curl уже при 10 (а есть и 20, и 30) параметрах в body будет нечитаем, а в постмане каждый параметр это строка в красивой табличке. Тоже самое касается редактирования, редактировать параметры body json в постмане удобнее на порядок. Именно поэтому, когда мне нужно дернуть кастомизированный запрос с фронта, я копирую в инспекторе запрос в виде курла, и импорчу его в постман, где уже нужное поле легко найти, и отредактировать.
Он лучше любого curl-a своей визуальной читаемостью. Запросы сгруппированы по папочкам, для разных сервисов, под разные окружения. Хранить их в папках на файловой системе в виде скриптов неудобно. Банально это надо редактор для каждого запроса открывать.
То есть это субьективно(?) удобнее.
GTP. В моем текущем крупном энтерпрайз проекте gtp бесполезен. У знакомых программистов, на энтерпрайзе, gtp тоже бесполезен. Ну, то есть его просто никак не применить, вообще.
Фраза типа "переписать проект с помощью чатгтп" в моем случае вызывает недоумение- там десятки человеко лет. Вот приду я с такой идеей к бизнесу и что скажу, быстрее работать будет? Так он ответит, что сейчас юзверей все устраивает. Поддержка лучше? Так этого не будет, основная сложность в обьеме бизнес процессов. Если по бизнес процессу требуется взаимодействие двух десятков сущностей при одном запросе, как ты не бейся, простой разработки не будет.
По поводу ухода от фреймворков- мне не надо знать, как они внутри работают. Они делают свое дело, предоставляя мне инструмент. Сообщество развивает эти инструменты, позволяя мне об этом не думать. Проблемы фреймворков, особенности знает куча людей, поэтому это дикий плюс. Выучив hibernate на одном проекте, можно использовать его на другом. Выучив велосипед на одном проекте, на другом его не применить.
Т.е. не нужно будет тратить гигантское время на обучение людей своим велосипедам. У нас и так время онбординга занимает 2-3 месяца до первой боевой задачи. И я читал уже на хабре, что это не предел. Тратить еще полгода на обучение своим наработкам? Не всякий бизнес может себе такое позволить, семь месяцев до реальной работы платить деньги.
В общем, для мелких проектов, может быть, статья и подходит. Но не для энтерпрайза.
tba
27.08.2023 08:32+3Про curl cтрого наоборот - использование curl как раз самый, что ни на есть энтерпрайз. У меня сейчас проект, где есть пара сотен вызовов API внешних систем, в результаты которых время от времени надо "тыкать носом" разработчиков некоторых организаций и их начальство.
Вызовы API отрабатываются, заворачиваются в скрипты с генерированием набора тестовых данных (очень важно), журналированием и прочими прелестями. Иногда приходится повозиться с заковыристым запросом (google/ChatGPT здесь в помощь), но в итоге у нас есть скрипт или набор скриптов для тестирования с документированием, который можно запускать одним вызовом или даже встраивать в test/deploy pipeline - не уверен что так можно сделать с postman.
Плюсы: a) читаемый текст б) нормальный кирпичик/модуль, который хочешь в pipeline встраивай, хочешь в git положи в) все документировано! - что и когда вызывали и с какими параметрами, что при этом сломалось и на каких данных г) нужен всего лишь минималистичный текстовый редактор, bash и curl (+ git для отслеживания версий).Проблема визуальной читаемости решается правильным стандартизированным форматированием скриптов: и, в отличие от postman, все видно на одной-двух страничках. Поэтому с автором полностью согласен (может быть субъективно): намного проще разобраться, намного легче поддерживать, намного более функционально получается.
javalin
27.08.2023 08:32+1Зависит от задач, если надо создать пользователя, в ответ вернется его id, потом надо создать группу, вернется ее id, потом надо положить пользователя в группу, потом создать товар, потом еще что-то.. и еще что-то, и оно все друг с дружкой взаимодействует. То постман с этим справляется легко, и масштабируется легко..
А если надо проверить, что запрос возвращает курс валют, а второй возвращает погоду.. то да, тут можно и с курлом..
Nurked Автор
27.08.2023 08:32С постманом есть ещё одна проблема. Когда полу-обученные менеджеры пытаются залезть в процесс разработки, то они с радостью возьмут первую строку поиска в гугле и вставят её в свой писюк. После чего то, что решалось одним тестом на мейке в две строчки, превращаётся в постман.
После этот менеджер начинает дёргать API сам, хотя ему там вообще нефига делать. После этого он придумыват новую финтифлюшу и присылает вам Postman collection. После этого вы говорите "__ять" и ставите постман.
Кстати, протип, эту коллекцию можно запустить в ГПТшку и она перепишет это в make и curl. Хотя таки да, в постмане есть одна полезная функция. Она позволяет выводить данные из постмана в курл.
michael_v89
27.08.2023 08:32Это разные задачи, и логично, что для них лучше подходят разные инструменты. Интеграционные тесты обычно и пишут в файлах, а для ручной проверки удобнее интерфейс.
grayrat
27.08.2023 08:32Один очень серьёзный момент
качества ответа нейросети (далее НС) зависит от качества данных на которых она обучается.
При этом важно различать данные сгенерированные НС от данных предостваленных человеком. Использование "запачканных" данных приводит к резкой деградации ответа НС.
НС думать не умеет, это сложное зеркало. Что будет если два зеркало поставить друг против друга?
corsairdnb
27.08.2023 08:32+8И так, я сейчас сижу перед приложением, написанным на Nest.js...
Всё загорожено декораторами, сторами и прочей билебердой, взятой из React...
В Nest решили, что CSS — это недостойно для нормального человека...
Мне надо было написать сервер, взамен старому на Next.js...
Возможно я чего-то не понял, но выглядит будто у вас в голове смешались две кардинально разные технологии. Либо вы столкнулись с каким-то монолитом в стиле PHP, написанном несколькими поколениями выпускников айти курсов :)
NestJS придуман для бекенда, и там нет ни React, ни CSS. Next.js придуман для рендеринга React на сервере.
Ну и насчет Postman - я не его фанат и не защищаю его, но ваши аргументы против не выглядят убедительно. На их сайте в подробностях описаны кейсы, для чего его используют.
Format-X22
27.08.2023 08:32+1Тоже удивился моменту когда автор начал рассказывать что NestJS это реакт. При этом он написал про котов и платную поддержку - то есть да, изначально это был Nest, как минимум автор там был.
Выглядит всё так будто автор увидел что проект на Next, случайно загуглил Nest, ничего не понял и решил всё сделать по своему.
Nurked Автор
27.08.2023 08:32+1Фронта на Nest, бэк на Next.
Написано всё группой индусов состоящей из девяти человек. Если вы когда нибудь работали с группой индусов из девяти человек, то вы однозначно ПРОКЛЯНЕТЕ их код.
Я не хочу говорить про всех индусов. Но три раза, из которых я с ними сталкивался был ПОЛНЫЙ писец. Как я понимаю, в России такое не в фаворе. А вот в США таким образом принято экономить. Группа индусов стоит как один серьёзный разработчик. А кода выдаёт в 10 раз больше.
kSx
27.08.2023 08:32Если бы вы были знакомы с Nest.js, - вы бы не путали его с Next. И, возможно, не занимались бы строением велосипедов, от которых потом будет больно. Ну а если вы с разбегу решили в нём разобраться, - то да, там порог входа повыше, чем ноль.
Все эти абстракции в Nest сильно упрощают разработку, помогая держать всё на своих местах. Можно взять и работать, даже с чужим кодом, потому что велосипедов там будет минимум. Единственное, что требуется, - это RTFM.
А как замену Postman для несложных вещей можно использовать rest-client, - посмотрите в extensions для своей IDE.
WhiteApfel
27.08.2023 08:32+1У меня мозг лопнул на моменте про Postman. Он же вообще не для этого ????
spidersarecute
27.08.2023 08:32+14Обман и манипуляции. Разберу подробно.
Игрушечные приложения вместо настоящих
Оказалось, что приложения живут просто отлично без 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 человеко-лет, вы в одно лицо быстренько перепишете на другой язык. Разве что используя автоматическую трансляцию кода, но вы ее не упомянули ни разу.
И опять же, вы работаете очень неэффективно. Вы по сути выкинули деньги работодателя, потраченные на написание и отладку предыдущей версии приложения, потому, что вам было лень разобраться в нем и исправить проблему.
Подводя итог, вы начали работать с маленькими игрушечными проектами и обнаружили, что они прощают практически любые ошибки и потому работать с ними легко.
Ravager
27.08.2023 08:32+2Го — отвратительный, неудобный язык, с кучей странностей,
согласен, язык муторный и неудобный.
надо писать названия свойств с маленькой или большой буквы.
плюсану, лучше бы модификатор доступа какой-нибудь использовался
Нельзя задавать значения по умолчанию в структурах.
я мало каких языков знаю, но вроде это не прям вездесущая фича.
Надо постоянно ломать голову, как передать структуру в функцию - по значению или по указателю.
в расте с бороучекером не надо ломать голову как передать значение? там еще и mut всякие есть. Golang это C с GC и сахаром, указатели знать надо. в целом передавай везде по значению если нет модификаций.
Нет нормальных коллекций
есть динамический массив, словарь. множество на словаре реализуется. списков нет, это проблема конечно но не прям фатальная.
В коде в импортах надо писать URL на гитхабе.
да, бесит. с другой стороны IDE это делает вместо тебя, поэтому терпимо. но выглядит убого конечно.
Критикуя — предлагай. Что лучше Го? Конечно, Питон. На нем код пишется в 3 раза быстрее, чем на Го. И код выглядит чище и красивее.
ну вот, так хорошо началось...
Конечно, Питон не идеален. Например, работа с коллекциями (фильтры, группировки, сортировки) там требуют много букв, у меня есть идея языка, где эти операции делаются проще и требуют меньше печатать. Лямбда-функции в Питоне громоздкие, в моем языке это будет исправлено.
он далеко не идеален. и на нем можно так писать что глаза будут вытекать. в этом го и хорош, на нем муторно писать но легко читать потому что он простой как топор. но возможно это мои приколы, я не фанат когда в одну строку пихают убер конструкцию, которая в других языках занимает несколько строк.
плюс го еще он нативный и довольно быстрый. хотя конечно раст быстрее, но в нем свои тонкости.
Если вам нужен низкоуровневый язык, то берите Swift. Он как Го, только лучше по всем пунктам. Там есть и нормальный ООП, и исключение при переполнении в арифметических операциях. Swift это Си с человеческим лицом.
брать надо то, что сейчас востребовано если не хотите потом без работы сидеть :) я не особо видел swift в бэкэнде. а котлин да, вот его я бы и советовал брать - действительно приятный язык.
spidersarecute
27.08.2023 08:32> Надо постоянно ломать голову, как передать структуру в функцию - по значению или по указателю.
в расте с бороучекером не надо ломать голову как передать значение?
В Питоне не надо, например.
> Нет нормальных коллекций
есть динамический массив, словарь. множество на словаре реализуется. списков нет, это проблема конечно но не прям фатальная.
Отлично, а в ваше «множество» векторы или матрицы можно класть, или только числа и строки? В моем понимании «нормальные» коллекции разрешают хранить и искать что угодно.
0xd34df00d
27.08.2023 08:32Критикуя — предлагай. Что лучше Го? Конечно, Хаскель. На нем код пишется в 9 раз быстрее, чем на Го. И код выглядит чище и красивее.
FTFY
fomiash
27.08.2023 08:32+5Посыл статьи изначально как будто из уст двадцатилетнего, цитирую:
В отличие от всяких там безмозглых PHP-проектиков, которые повально подвергались SQL-инъекциям из-за запросов типа 'SELECT * from user where name like '.$input.' and enabled = true', мы, шарписты, делали всё по-другому.
Классический пример юношеского максимализма. Кстати, пример поиска пользователей по части имени не особо распространен, можно было и актуальнее придумать.
Потом вы упоминаете, что подряд выучили множество языков программирования. Такое сейчас пишут о себе в основном школьники, опять делаю поправку на возраст.
Эти домыслы, конечно, только предположения, но позвольте спросить, сколько вам лет?
koreychenko
27.08.2023 08:32+5Товарищи, ну что за несправедливость! Каждый раз как появляется какой-нибудь правдоруб он обязательно достаёт PHP из 2005 года и говорит, что он был говном. Дети, например, которые в 2005 родились уже совершеннолетние. Так что может перестанем заниматься некрофилией? Чего сразу ПХП-то? Прям обидно за основной язык, чес-слово :-)
1. Да, в 2005 была версия 5.0. Спасибо, что не 4.x - вот где боль была.
2. Спорим я дырявый SQL напишу практически на любом языке.
3. Возвращаюсь к некрофилии. В 2005 году только вышла 2.0 версия шарпов. Вот наверняка там тоже говна хватало, не зря же они с тех пор еще 8 мажорных версий наклепали.s207883
27.08.2023 08:32+1Про пыху не скажу, а вот Шарп больше обрастал фичамии вроде асинхронности и прочего сахара. Старый код +- будет работать и сейчас. Сейчас вот новый мажор и критических изменений там нет, просто прикольные фичи.
Dominux
27.08.2023 08:32+7Тупо плач новоиспечённого "эксперта". Когда такие статьи уже перестанут проходить модерацию?
xenon
27.08.2023 08:32+1> Для всех тех инженеров, которые не поняли, как использовать fetch для тестирования своих приложений, был написан Postman. А потом он превратился в бесконечно сложный комбаин, в котором сам черт ногу сломит.
Проблема с концепцией продукта. Многие продукты начинаются как маленькие, простые, быстрые, удобные для простых задач. А потом, самокат обвешивается фичами и получается звездолет. Но летать на нем через два дома в булочную - неудобно. А может быть проблема не в Postman - возможно его разработчики примерно такой сложный комбайн и хотели - тогда проблема или в плохом выборе инструмента или в отсутствии выбора.Я так написал showcert - потому что каждый раз писать сложную цепочку(!) команд с кучей ключей из openssl - задолбало. А еще больше бесило, что приходилось сначала гуглить эту команду (как там проверить сертификат на SMTP сервере после STARTTLS....), чтобы потом написать ее. Бррр... Сделал showcert, с ним все просто, легко, понятно, экономит время, не надо ничего гуглить (забыть ключи сложно) и волосы стали мягкими и шелковистыми.
Значит ли это, что openssl "зашел не туда", переусложнился, совершил ошибку, что showcert лучше openssl? Нет. Каждый продукт под свои нужды. Мои - достаточно скромные, я хочу проверять сертификаты в файлах и на сервисах по сети. Еще - проверять не просто валидность а и "свежесть" (чтобы настроить алерт если сертификаты скоро протухнут). Правило Парето. Вот для 99% моих нужд, мне хватает того, что делает showcert. Так же как хватает открывалки для открывания пива, и не нужен мультитул. Вот когда возникнет потребность в чем-то большем - конечно, пригодится openssl. Неправильно, на мой взгляд, использовать комбайны там, где должны быть удобные "узкие" инструменты. И для каждой популярной узкой сферы должны быть специнструменты БЕЗ лишних свистоперделок.
Похожее было и со Svelte. Мне очень понравился этот очень простой фреймворк, очень удобный для небольших задач. Но потом они начали обымать необъятное и он усложнился, потерял былую легкость. Добавление новых фишек - не только улучшает, но и ухудшает.
Как ни странно - но тут важен Маркетинг (самому странно, что я такое говорю - в IT сфере принято считать их бездельниками, дармоедами и дураками). Инструмент должен четко понимать свою целевую аудиторию, и ориентироваться на нее, и нужно иметь смелость отвергать все идеи, которые ухудшают удобство продукта для этой ЦА (например, делают его больше, тяжелее, медленнее, сложнее в изучении).
Проблема с фреймворками в отсутствии самоограничения.
KReal
27.08.2023 08:32+1Безотносительно всего вышенаписанного, не хочется даже спорить.
Возьмите вашу великолепную программу на Go или Rust, и напишите её БЕЗ фрэймворков на богомерзком .Net или Java. Результату вы удивитесь, гарантирую.
Flux
27.08.2023 08:32+6То есть дико возмутившись глубиной стектрейса вы стали сначала фанбоем го, потом фанбоем раста, а сейчас фанбоем ChatGPT и рекламируете его как серебряную пулю?
То есть задачу декомпозиции сложности вы переложили с фреймворков написанных и протестированных тысячами квалифицированных разработчиков на языковую модель с закрытой (!) архитектурой и реализацией, живущую в чужом (!!) облаке, не сообщающую пользователю об изменении поведения (!!!) и выдающую код похожий на правильный (!!!!), то есть по сути являющийся наиболее вероятным продолжением строки-запроса на основе спаршенного гитхаба на котором эта модель и училась.
Браво, аплодирую стоя. Я искренне надеюсь что у вас будет как можно больше последователей, потому что на фоне потока профессиональных спрашивателей ChatGPT и любителей мейнов в 6к строк (зато глубина стектрейса не больше 2) компании будут готовы платить оставшимся любые деньги.
koreychenko
27.08.2023 08:32+2А давайте вообще вместо кода в репозитории хранить запрос к ChatGPT и во время билда в пайплайне получать по этому запросу код, потом билдить его в бинарник и деплоить. Что может пойти не так - машины они же умные /s
rubinstein
27.08.2023 08:32-1Читаешь вот такие статьи и понимаешь, как же бесконечно далёк от всего этого. Словно это не Русский язык, а Китайская грамота.
fillsa
27.08.2023 08:32+2Стоит заметить, что фрэймворков фрэймворков рознь. Но на мой скромный взгляд, большая часть из них г.. . В погоне за возможность покрыть все хотелки под все проекты, да и еще как можно быстрее, фрэймворков разрослись до невероятных размеров, пожирают кучу ресурсов и чтобы разобраться в этих на скорую руку сделанных хитросплетениях необходимо чуть ли не к авторам обращаться. Посему со временем с такими фрэймворками приходят к мысли, а давайте мы все перепишем заново на своем коде. И эти фраемворки движутся по пути - давайте их похоронем все. Ведь основная задача это побыстрее накидать проект и срубить бабло с заказчика, а как оно там будет работать это уже второстепенно.
Но есть и хорошие фрэймворки, где вместо всех хотелок, пытались избавить разработчика от написания повторяющего кода - как итог, относительно небольшие и достаточно быстрые фрэймворки которые при некоторой сноровке от разработчика покрою почти все задачи. Но кому это нужно, пару лишних строк кода накидать. Да и ради чего, чтобы это все работало быстрее? Да это уже не забота разработка, он свалил с проекте через несколько лет.Nurked Автор
27.08.2023 08:32+1Меня больше всего прёт замечание на сайте реакта о том, что они больше сами не рекомендуют реакт для написания сайтов. Лучше использовать надстройку над реактом.
Кажется что люди сделают всё что иожно только чтобы не смотреть на эту богомерзкую идею программирования.
Zhuikoff
27.08.2023 08:32+2Любой зрелый проект написанный с нуля, там, внутри уже становится фреймворком. Двигать это потом "в народ" или нет уже будет зависит от воли создателя. Взлетит или нет - другое дело. А вот фреймворки "для всех" с определённой стадии уже пишутся ради обновления цифры версии и разрастаются до огромных монстров. И все потому, что позиция "мы отладили все до мелочей" с точки зрения пользователя выглядит как смерть проекта.
И таки да, и гпт хорош, но тем кто не умеет мыслить он не уже поможет. Но иллюзию поднятия самооценки даст.
Nurked Автор
27.08.2023 08:32Тут как раз вы полностью правы. Когда вы пишите приложение для работы с сепульками, то у вас начинает нарабатываться код, для работы именно что с сепульками. После этого вы создаёте кодобазу для сепулек, но она остаётся там, где ей выделили место. В проекте по сепулькам.
Другое дело, что условный Вася начинает разрабатывать код для работы с клюками. И решает, что этот код одинаково хорошо работает с конючами, хлюпами и хряпами. Те специфические вещи, которые надо добавить для работы фанатов хлюпов начинают распространяться на другие кодобазы. В итоге конючи, вместо того, чтобы писать свой код, пытаются притянуть за уши фреймворк, фитчи которого не предназначены для конюч. Но маркетинговый материал говорит им, что если они не пользуются этим фреймворком, то они позорные твари. Поэтому и притягивают.
Взять более реальный пример:
Кто-то берёт next.js и пишет на нём бэк для работы с netsuite. Я бы за такое вообще расстрелял на месте, ну да ладно. В чём была идея - нужно отправлять запросы к Oracle Netsuite и по пути внедрить аутентификацию и базовое схлопывание повторяющихся запросов через кеш.
Хрен с ним, написали на next. Но, никто же не проводил большого исследования по этому поводу. В итоге, полтора года работы отправлено на сервер, который, ввиду своей next идеи, перегружает Netsuite количеством запросов в секунду.
Для того, чтобы с этим справится, надо снять сервант с параллельной модели исполнения, и переделать его на очередь. Но сделать этого внутри next не получится, без тотальной переписи всего.
В итоге, решением (не моим) было то, что был написан ещё один сервер на next, который является менеджером очередей. Писали это индусы, поэтому, для того, чтобы запустить эти два уродства, надо было стартовать их одновременно, потому что они играли в игру про курицу и яйцо, и падали с грохотом. А начальник сказал, что мы переезжаем в облако, поэтому пожалуйста, задеплойте всё на AWS. Ну да, так оно и задеплоилось. Щас стоит выделеная EC2, на которой специальный сервис запускает это извращение. (Тут понятно, что next не виноват, что на нём пишут криво. Но когда ты находишься в такой ситуации, ты понимаешь, что вот именно в этой ситуации, next - это просто помеха твоему психическому здоровью).
В итоге, ты садишься, просишь ChatGPT написать транслятор credentials, создать глобальный менеджер очередей, и привинтить к этому маленький http сервер, и понимаешь, что за 2 недели ты только что перелопатил ВЕСЬ этот ужас.
Разница заключается в том, что ребята, которые писали это на next, понятия не имели, что они пишут. А я хорошо знаю архитектуру приложений и систем, и много раз накатывал вещи в облако, поэтому представляю, что такое независимое приложение. Поэтому, для меня будет намного более быстрым и удобным, с помощью генератора, переписать это всё за один раз.
melodictsk
27.08.2023 08:32+1Я идею и концепцию автора всецело поддерживаю. А причина она вот на поверхности. Приложение чистое (без кэша и т.п. ) сбербанк онлайн весит 482 Мб, Тинькофф 435, госуслуги 306, Авито 240, почта майр.ру 291 и т.д. это с чего это вдруг? А функционала в них ровно в 10 раз меньше чем их размер. Или там все делали рукожопы, а истинные эксперты они только тут в комментариях, которые пишут всегда очень оптимизированный код без лишнего мусора. Минусов мне в карму.
GospodinKolhoznik
27.08.2023 08:32+3Истинные эксперты достигают такого просвятления, что вообще код перестают писать. И статьи на Хабре не пишут. Только в комментах срутся, только там живёт дух старой школы!
michael_v89
27.08.2023 08:32+3-d '{"test": true}'А как будет выглядеть POST-запрос, где данные это сущность с 10 полями, одно из которых это массив других сущностей? А что с подсветкой этих данных? А как в этих тестах с Makefile проверить, что ответ содержит нужные данные?
А главное непонятно зачем вообще для этого ChatGPT. Интеграционные тесты обычно и так все в файлах пишут, для нового теста код копируется и дорабатывается. Только конечно не на Makefile.
но у вас в руках файл размером в килобайт
Темы для кнопок и всего остального допишет GPT.Да, только результат будет уже не килобайт. А еще каждому новому разработчику придется изучать что вы там нагородили, и какой класс надо написать чтобы сдвинуть элемент вправо.
Bootstrap это в основном и есть "темы для кнопок и всего остального".Но мы-то можем поправить это ручками и разобраться?
А зачем тратить на это рабочее время? Мы можем просто вернуть Bootstrap и TypeScript, и всё будет работать без этих ошибок.
А когда придёт время это дописывать, вы сможете со спокойной душой это дописать. Сами. Без бесконечных фреймворков
Да не хочу я сам дописывать одну и ту же функциональность на каждом проекте. Особенно если какая-нибудь работа с базой данных будет в каждом реализована по-своему. У меня есть рабочие задачи, которые надо сделать.
k102
27.08.2023 08:32Вы можете резонно заявить, что этот скрипт не сможет заменить весь React (на котором работает Nest). Конечно, нет! Но он заменит 80% всего того, что мне нужно от React. Остальное я допишу руками.
Ага, а на выходе получится тот же Реакт, только написанный языковой моделью. Т.е. еще один фреймворк. И тут я смотрю в кликбейтный заголовок с предложением убить все фреймворки... что за хрень я только что прочитал? :)
apcs660
27.08.2023 08:32+1Недавно пришлось переводить spring микросервис из k8s в обычное легаси приложение, в виде плагина.
По хорошему, бизнес логику нужно отделять от фреймворков, по возможности, для облегчения портирования и апгрейдов. Когда бизнес логику нашпиговывают зависимостями от спринг, ее перетащить куда то становится сложно, так как паровоз зависимостей тянется довольно большой.
Спринг это круто, но иногда, настройки профайлов и что реально куда уедет, без пузыря не разобрать, особенно в плохо документированном проекте где проходной двор из десятка а то больше, разработчиков.
Еще плохая привычка это писать клиент для свого сервиса на http и затаскивать в него зависимость на core модуль из сервера (к примеру Solr так делает).
PS Не фреймворк красит человека, а человек фрейворк - неважно, какие у тебя инструменты, но если не делать уборку в мастерской, она будет помойкой.
nextdesu
27.08.2023 08:32+1Мне кажется подход автора ничего не упростит, в конце концов фреймворки удобны тем что это не просто код, они часто вводят свои собственные понятия и определения, а также готовые функции позволяя нескольким людям из разной среды и разного опыта как бы говорить на одном языке.
Например и джун и сеньор реактивщики понимают что такое хук, и примерно зачем нужен useEffect при чем это люди только может быть только сегодня познакомились. В подходе предложенном автором человеку придется погружаться в огромные пучины кода написанные кемто совместно с машиной, и дай бог понятные хотя бы тому кто их писал в момент когда он их писал.
Фреймворки нужны чтобы абстрагировать сложность, скрыв ее за простым интерфейсом а в описанном в статье подходе она просто вываливается на человека которому придется это сопровождать и ему по сути нужно будет пройти тот же путь что и автору и возможно переписать все с самого начала чтобы разбираться как оно все работает.
К тому же фреймворки это не только код, но также докуцментация и опыт работы с ним других людей к которым можно обратиться в случае возникших проблем, а к кому идти в случае самописного решения?
Мне таким образом кажется что подход не решает описанную проблему а только усугубляет.
Nurked Автор
27.08.2023 08:32С одной стороны да, но с другой стороны, что произойдёт, когда фреймворк бампнет major пару раз? useEffect уже deprecated. А ещё тройку бампов и код надо переписывать или пинить старую версию библиотеки.
nextdesu
27.08.2023 08:32Тоже верно, но бампануть версию и поменять апи, может понадобиться не только фреймворку. В случае с фреймворками зачастую переход будет описан, а может даже оформлен в виде скрипта который можно нактить автоматически, в случае с самописным решением поддержка версионирования ложится на плечи команды разработки.
Так что на мой вгляд это аргумент тоже не в пользу вашего подхода.
GospodinKolhoznik
27.08.2023 08:32Фреймворки что! У меня вчера появилось непреодолимое желание писать веб сервер на ассемблере. И я это начал делать. На 146% уверен, что быстро заброшу, но пока хочется и доставляет удовольствие, буду продолжать ваять.
xenon
27.08.2023 08:32+1Я знал такого человека. Еще в конце 90-ых начале 2000-ых, но там было даже больше - он на технологическом контроллере писал ВСЕ на асме, включая примитивный TCP/IP стек и вебсервер. И это все работало! Раздавало файлики и данные с датчиков. Так что, задача совсем не фантастическая. Правда, когда он ушел из фирмы, не нашлось желающих работать дальше с его кодом, и перешли на маленькие Linux'а. Тогда всякие gumstix'ы начали появляться и подобные вещи. То, что он пару лет ваял - за месяц залили на маленький линукс, стоимость железа выросла на какие-то копейки.
enkryptor
27.08.2023 08:32этот скрипт не сможет заменить весь React (на котором работает Nest)
Может, всё-таки "Next"?
Nest.js — это фреймворк для бэкенда на ноде.
pixsel
27.08.2023 08:32+1Интересная статья и мысли в ней, заставляет задуматься перечитать и переварить. Согласен с тем, что стоит использовать chatgpt или аналог, но без проверки кода апосля никак.
cross_join
27.08.2023 08:32"Смешались в кучу кони, люди..."
Библиотеки и фреймворки (неплохо было бы коротко указать разницу) ни хороши, ни плохи сами по себе. Это просто инструменты, позволяющие опираться на сторонние наработки. Выбор оптимального для данной задачи, проекта, продукта инструментария - нетривиальная задача, но ошибки на этом этапе будут стоить дорого в перспективе.
Вера в LLM несколько наивна, но объяснима: любой красиво и правильно говорящий человек априори кажется умным и понимающим суть того, что он высказывает.
andmerk93
27.08.2023 08:32+1Кстати, я не увидел в примерах для курла у автора работы с куками и авторизацией.
Ну, типа, залогинился, получил куку/токен и таскаешь за собой по разным эндпоинтам.
Можно пример автотестов на баше с курлом, где такое реализовано?
Для проверки разделения прав, например? Ну, чтобы разные запросы для админа/юзера/анонима разное показывали.MiraclePtr
27.08.2023 08:32На самом деле легко. Если нужна именно кука или токен из хедера, то можно выдернуть или по-классике c awk, или в новых версиях curl средствами самого curl и сохранить в переменную bash. Если сервер выдает JSON - то для извлечения значения можно использовать jq, он сейчас почти во всех дистрибутивах есть. Ну а потом из переменной при следущих вызовах curl эту куку или токен в хедер подставлять.
Но я соглашусь со многими высказавшимися здесь в комментах - я бы очень не хотел даже за большие деньги подедрживать проект, где юнит-тесты написаны на Bash'е. Психическое здоровье дороже.
mixsture
27.08.2023 08:32Пофантазирую. Центральная проблема в разработке ПО — сложность. Стэктрейсы с огромным числом вызовов — несомненно, сильно увеличивают эту сложность при отладке (я бы даже сказал требуют тренировки специфичных навыков для их чтения).
Почему мы получаем столь огромное число вызовов? Все дело в числе абстракций и желании каждого фреймворка стать всеобъемлющим. Каждая абстракция добавляет один или более вызовов, чем усложняет стэктрейс, но в дополнение к этому снижает когнитивную общую сложность при проектировании (можно более-менее изолированно проектировать 1 класс, не задумываясь о других).
Таким образом у нас тут появляется 2 настройки:
1) желание фреймворка стать всеобъемлющим. Если каким-то образом ограничить рост фич, то мы остановим и рост числа абстраций. Я бы сюда добавил аналогию из нейросетей: принцип "переноса" обучения, когда берется условно 80% исходной нейросети с близкой по смыслу задачи, эта часть объявляется константой, а последние слои, ответственные за высокоуровневую логику — переобучаются. Вот, думаю, задача фреймворка быть этими 80%, не пытаясь залезть в оставшиеся 20. Например, используя эмпирические приоритеты: если фича подразумевает использование менее, чем в 1% запусков, но добавляет новые уровни абстракций — ее не нужно делать вообще. Вобщем, некий показатель "польза/вред", чтобы ориентироваться — попали ли мы в 80% или 20%.
2) ползунок "сложность при проектировании" <-> "сложность при отладке". Можно попробовать подвигать его. В случае, когда часть фич не нужна, у нас получается ситуация, что в стэктрейсе десятки вызовов, внутри которых никакой логики не отрабатывает, они просто передают управление дальше. Фреймворки могут использовать укороченные цепочки вызовов, если часть фич не нужна. Это существенно усложнит диаграмму, что и откуда может вызываться, но зато существенно сократит стэктрейс.Как один из вариантов: укороченные цепочки не используются, но IDE (может даже совместно с какой-то поддержкой в языке) может как-то научиться выделять визуально вызовы, которые лишь передают управление функциям дальше, а сами не делают ничего.
lair
27.08.2023 08:32Как один из вариантов: укороченные цепочки не используются, но IDE (может даже совместно с какой-то поддержкой в языке) может как-то научиться выделять визуально вызовы, которые лишь передают управление функциям дальше, а сами не делают ничего.
Если мне память не изменяет, та же Visual Studio уже прекрасно умеет не показывать в стектрейсе в дебаге те шаги, которые не в солюшне под отладкой.
mvv-rus
27.08.2023 08:32Я так понимаю, что речь у предыдущего комментатора идет несколько не о том: а о методах, которые выполняют функцию "передаста", все тело которых состоит из единственного вызова другого метода другого класса.
Если проект, как и полагается по теории, напичкан абстракциями и их слоями, таких методов в нем много, а для понимания работы кода они не дают ничего.
PS Лично я таких методов в коде ASP.NET — у меня хобби в нем копаться — нагляделся, и они у меня нередко вызывали досаду.lair
27.08.2023 08:32Я так понимаю, что речь у предыдущего комментатора идет несколько не о том: а о методах, которые выполняют функцию "передаста", все тело которых состоит из единственного вызова другого метода другого класса.
Я понимаю, да. Но в реальности исключение "чужого" кода уже резко улучшает читаемость (и заодно делает более заметными проблемы в "своем").
а для понимания работы кода они не дают ничего.
Если абстракции выбраны правильно, то таких методов не так много, и каждый из этих случаев дает понимание (что мы сменили абстракцию). Ну а если неправильно, то тут дело не в подсветке уже.
aleksey-tumbaev
27.08.2023 08:32Было бы интересно посмотреть два одинаковых пет-проекта - один на фреймворке, другой на чат гпт
Kealon
27.08.2023 08:32Куда лежит лёгкая дорога мы уже проходили
Основные правила автогенерации: "должны сохраняться шаги автогенерации" и "автогенерация не правится"
AlexXYZ
Новые фреймворки появляются и умирают, а стандарты остаются. Всё держится на стандартах, а не на фреймворках. Учить в первую очередь надо стандарты.
Ravager
В целом согласен. Это повысит вашу ценность. Но вот если вы будете дом строить по проекту - вам важно чтобы работники умели класть газобетон и крышу делать или химию знали как этот газобетон был получен? Я к тому что программирование часто это прикладная штука и там важно что ты можешь дать бизнесу в ближайшее время а не какие ты стандарты знаешь. Грустно но как есть.
Nurked Автор
Да, вот с этим с сожалением соглашусь. К сожалению стандартов нынче никто не уважает. Вмё надо дешевле и быстрее по цене того сука на котором сидишь
saboteur_kiev
Так вся ваша статья о том, что люди, пользуясь готовыми сложными инструментами, зачастую не понимает как это работает под капотом. И возвращаясь к низкоуровневым инструментами (curl), надо разобраться с базой. А там - можно на любом языке писать то, что нужно здесь и сейчас.
Базовые вещи гораздо проще интегрируются в любой пайплайн
1755
Немного не соглашусь с аналогией: стандарты и протоколы - это условно "чтобы построить стену, нужно брать блоки одинакового размера и материала и складывать их в шахатном порядке, скрепляя между собой таким-то цементом, после чего ждать столько-то времени перед завершением". Если это делать все вручную, то это разработка без фреймворка. Если используются уже готовые блоки стен, то это уже использование фреймворка.
AlexXYZ
Мне кажется, что вы немного ошиблись. Если вам будут строить дом, то вам наверняка бы хотелось, чтобы работники строили по строительным стандартам и нормам? Так-то желающих поработать на стройке хватает. А стандарты на материалы должны соблюдать на заводе материалов. Стандарты надо учитывать по своей сфере.
qertis
Учиться надо в первую очередь здравому смыслу. Стандарты депрекейтят, устаревают под современные реалии аппаратуры. Поэтому опираться полностью на стандарты я бы не рекомендовал. К тому же сегодня веб-стандарты контролирует в большей мере Google, которые делают такие стандарты, которые нужны в первую очередь им.
Aquahawk
Много вакансий видели где стандарты перечислены?
Electrohedgehog
Вы таки не поверите, но поищите PSR, например, по вакансиям.
За другие языки не скажу, но уверен что там ситуация не сильно отличается.