Согласен, аналогия не очень соответствует. Уточню. Аналог производства стула -- это копирование готового пакета setup.exe, трудозатраты стремятся к нулю. Разработка стула -- это расчёты, модели, изготовление чертежей и настройка производственной линии. Заметьте, НЕ постройка нового завода под новую модель и даже, в большинстве случаев, НЕ закупка новых станков (не берём плановое обновление оборудования) -- существующий конвейер только слегка модифицируется. А в энтерпрайз разработке ПО зачастую при создании нового приложения завод перестраивается чуть ли не с нуля. Станки плохо совместимы, инженерные решения переизобретаются. Да, уже есть компоненты и библиотеки, ставшие промышленными стандартами, но стандартизация, к сожалению, ещё недостаточная.
В идеальном мире разработчик ПО должен спроектировать систему на высоком уровне, не в виде промта к AI, конечно, а в виде детальной спецификации UX, спроектировать потоки данных в системе, расставить границы безопасности, задать ассеты, лимиты ресурсов, ещё какие-то детали. По этому проекту умная автоматизированная система из унифицированных и совместимых между собой компонентов помогает собрать прототип ПО, который затем множеством итераций тестирования и правки доводится до продакшен состояния. Это -- конвейер, не подразумевающий кастомной разработки каких-либо компонентов, кроме самых необходимых и уникальных, нужных исключительно для данной задачи. Как в наше время множество моделей Ford, Mazda и Volvo построены на едином шасси. Нет бессонных ночей в отладке ядра Linux, криков "эврика" и литров кофе. И нет рутины, когда в сотый раз пишется интерфейс json - websocket - redis - sql - whatever. Понятно, что это не реально сейчас, но хочу верить, что будет реально в будущем.
Из ныне существующих приложений для меня в этом смысле образцом является VSCode (и пусть меня закидают тапками). Да, он на Electron'e, который принято ругать, он тяжеловат и работает помедленнее, чем Visual Studio. Но, он, чёрт возьми, работает везде. Mac, Windows, Linux, даже онлайн. Он модульный внутри, расширяемый снаружи. Он собран из достаточно надёжных и проверенных компонентов, он очень, очень любит стандарты (GDB/LLDB, DAP, LSP, ripgrep, github API, OCI). Так должно быть.
Простите, но зачем этому сопротивляться? Это какой-то неолуддизм. Автомобили, электроника, бытовой скарб, даже стройматериалы, скороводки и зубочистки -- делаются сегодня на конвейере, максимально автоматизированно, и это хорошо. Качество высокое и контролируемое, скорость производства на порядки выше кустаря, и цена, как ни странно, тоже падает. То же будет и с разработкой софта. Так же, как профессия кузнеца умерла, сменившись на оператора станка с ЧПУ, так и профессия разработчика сменится на специалиста по настройке и контролю линии производства ПО (условно). Кастомная разработка или разработка "с нуля" не исчезнет, но станет редкостью, как сейчас специализация разработчика станков с ЧПУ или изготовления всяких штучных вещей.
На примере мебели: есть Ikea для самых нетребовательных, есть сотни типовых моделей для тех, кто ищет что-то конкретное, ну и есть, конечно, мебель на заказ. И соотношение их рынков, ну не знаю, допустим 17%, 77% и 6% (цифры из головы). Вы, сопротивляясь конвейеру, отрицаете 94% потребностей рынка. Большинство не может и не хочет морочиться с мебелью на заказ. Их устраивает уровень качества Ikea, проще выкинуть через 3-5 лет то, что износилось или надоело, чем жить с бабушкиным комодом Людовика XiV, потому, что заказать новый это приключение на три месяца и стоимостью в три з/п.
Так же, как сейчас есть люди, недовольные качеством современного ПО, есть и люди, недовольные качеством Ikea. Но они не покупают в Ikea, а покупают то, что дороже. Вы можете возразить, что в случае с ПО часто бывает так, что нет альтернативы. А вот это как раз и есть издержки полу-кустарного производства ПО! Если программа требует 10000 человеко-часов для разработки, то она, конечно, будет уникальной. Если максимально автоматизировать (а так же стандартизировать и унифицировать) разработку, то эта же программа потребует, допустим, 500 человеко-часов. И гораздо большее кол-во компаний сможет себе позволить разработку такой программы. Количество - конкуренция - качество.
Напрашивается аналогия с историей создания SQL: язык запросов задумывался как доступный инструмент для работы с табличными данными, понятный любому англоговорящему клерку, а по факту -- ещё одна технология, доступная только профессиональному разработчику. Без знания computer science база легко кладётся запросом, данные теряют согласованность, простая задача становится сложной, сложная -- невыполнимой. Сейчас никто в здравом уме не подпустит клерка и на километр к SQL консоли. То же будет с AI: инструмент, помогающий решать задачу, но хорошо работающий только в руках профессионалов.
Поясню. Суть "идеи", изложенной в статье, напоминает ту самую систему Черноусого, "сотканную из пылких и блестящих натяжек". О чём статья? Сперва введение в теорию графов с картинками из точек и палочек. Учёный-мозговед изучает структуру мозга, выстраивает систематику и иерархию, использует мат.аппарат для описания этой иерархии. Окей. Учёный-математик (известный, кстати, своим "альтернативным" подходом ко многим темам) описывает модель вселенной, используя любимые им математические абстракции. Спорно, но окей. И там, и там где-то на базовом уровне, возможно, используется теория графов. В качестве иллюстрации две картинки с якобы нейросетью и структурой Вселенной. Видите -- похоже! Дальше -- физик (возможно, хороший физик, не знаю) врывается к нам со страниц Яндекс Дзена с утверждением, что "вселенная это нейросеть, которая вычисляет сама себя". Хм. И что теперь?
А дальше ничего. Никаких выводов, никаких прогнозов, ни объяснения, как эта парадигма могла бы изменить теорию или практику познания. Только "заходите на мой Телеграм канал".
Многие в детстве, узнав о строении солнечной системы и строении атома, фантазировали о том, что каждый атом -- это солнечная система, и там, где ядро атома это Солнце, а электроны -- планеты, на электронах живут маленькие планковские человечки. Занимательные фантазии, но смысла в них нет.
Совет: если просить LLM адаптировать текст "под статью для Хабра", то результат может быть немного получше, не будет так много списков, из которых торчат уши нейросети. Статья ни о чём, "заходите на мой Телеграм канал".
Человек может говорить, что у него проблема, и у него, вероятно, действительно есть проблема, но пока он ничего не делает по этому поводу, даже просто не пытается искать решение, а сидит и тупо смотрит на свою проблему, то проблемы всё равно, что нет. Если человек хотя бы ищет решение, то он уже потенциальный клиент.
Что касается второго пути, про изменение привычек: предложенный инструмент должен а) давать эффективное решение, б) не иметь порог входа существенно выше предыдущего инструмента. Для массовых квази-бесплатных инструментов -- ещё и быть "нескучным", то есть содержать элементы геймификации или emotional design. Если же для эффективного решения проблемы пользователю нужно пройти пятичасовое обучение и освоить какую-то нестандартную парадигму, из цикла "день потерять, потом за пять минут долететь", то большинство от такого инструмента откажется, и он будет невостребован.
Когда у Вас, как Вы говорите, появился "удобный или даже просто приятный инструмент", то по Вашему описанию уже видно, что инструмент вам нравится, а значит, эмоциональный дизайн сработал, для Вас порог вхождения снизился и Вы, скорее всего, с удовольствием им воспользуетесь. Если бы тот же инструмент Вы описали, как "навороченный комбайн", вероятность его использования Вами была бы ниже.
На самом деле, есть ещё третья категория инструментов, позволяющая решать проблемы, которых ранее не существовало в нашем мире, ну просто потому, что это было в принципе невозможно, и все это знали. Но появление таких инструментов -- редкость.
Да что же это такое происходит, люди? Очередная статья прямиком от LLM. Вот сравните, структура практически один-в-один: вводный абзац - виды - инструменты - практики - заключение. Те же пункты, нумерация, форматирование, те же слова, только чуть по-другому расставлены. Попробуйте сами, по промпту `Please write an article on the topic: "Тестирование WebSockets: подходы, инструменты и лучшие практики"` выходит ровно такая статья. Может, пора уже новый формат публикаций вводить, не "статья на Хабре", а "промпт для LLM" ? Типа, "Здравствуй, дружок, сегодня мы будем исследовать тему X. Наш сегодняшний промпт: 'Describe X in 20 paragraphs, with code samples in Python'. Приятного чтения и до новых встреч!"
Хороший и правильный комментарий, но я бы сказал, что бежать плюсовать откровенный машинно-сгенерённый шлак в корпоративном блоге в первый день регистрации на Хабре это немножко палево.
-12345679 * 72 = -88888888E -- включает все числовые сегменты на экране, знак "минус" и "Е" как результат переполнения (если экран 8-разрядный; если разрядов больше, то первое число дополняется справа цифрами 01234...).
А обязательно при сборке так стучать деталями? Особенно при установке SSD и памяти. И когда мать в корпус ставится. От девушки подсознательно ожидаешь как раз обратного, понежнее, так сказать.
Сколько существует в мире компаний, имеющих сайт, где собирается хоть какая-нибудь инфа о пользователе, да хотя бы тот же IP адрес, юзер-агент, геолокация? Думаю, что сотни тысяч или даже миллионы. И каждую можно оштрафовать за то, что не открыла представительство и не разместила данные пользователей на территории РФ. Да это же золотая жила!
Согласен, аналогия не очень соответствует. Уточню. Аналог производства стула -- это копирование готового пакета setup.exe, трудозатраты стремятся к нулю. Разработка стула -- это расчёты, модели, изготовление чертежей и настройка производственной линии. Заметьте, НЕ постройка нового завода под новую модель и даже, в большинстве случаев, НЕ закупка новых станков (не берём плановое обновление оборудования) -- существующий конвейер только слегка модифицируется. А в энтерпрайз разработке ПО зачастую при создании нового приложения завод перестраивается чуть ли не с нуля. Станки плохо совместимы, инженерные решения переизобретаются. Да, уже есть компоненты и библиотеки, ставшие промышленными стандартами, но стандартизация, к сожалению, ещё недостаточная.
В идеальном мире разработчик ПО должен спроектировать систему на высоком уровне, не в виде промта к AI, конечно, а в виде детальной спецификации UX, спроектировать потоки данных в системе, расставить границы безопасности, задать ассеты, лимиты ресурсов, ещё какие-то детали. По этому проекту умная автоматизированная система из унифицированных и совместимых между собой компонентов помогает собрать прототип ПО, который затем множеством итераций тестирования и правки доводится до продакшен состояния. Это -- конвейер, не подразумевающий кастомной разработки каких-либо компонентов, кроме самых необходимых и уникальных, нужных исключительно для данной задачи. Как в наше время множество моделей Ford, Mazda и Volvo построены на едином шасси. Нет бессонных ночей в отладке ядра Linux, криков "эврика" и литров кофе. И нет рутины, когда в сотый раз пишется интерфейс json - websocket - redis - sql - whatever. Понятно, что это не реально сейчас, но хочу верить, что будет реально в будущем.
Из ныне существующих приложений для меня в этом смысле образцом является VSCode (и пусть меня закидают тапками). Да, он на Electron'e, который принято ругать, он тяжеловат и работает помедленнее, чем Visual Studio. Но, он, чёрт возьми, работает везде. Mac, Windows, Linux, даже онлайн. Он модульный внутри, расширяемый снаружи. Он собран из достаточно надёжных и проверенных компонентов, он очень, очень любит стандарты (GDB/LLDB, DAP, LSP, ripgrep, github API, OCI). Так должно быть.
Простите, но зачем этому сопротивляться? Это какой-то неолуддизм. Автомобили, электроника, бытовой скарб, даже стройматериалы, скороводки и зубочистки -- делаются сегодня на конвейере, максимально автоматизированно, и это хорошо. Качество высокое и контролируемое, скорость производства на порядки выше кустаря, и цена, как ни странно, тоже падает. То же будет и с разработкой софта. Так же, как профессия кузнеца умерла, сменившись на оператора станка с ЧПУ, так и профессия разработчика сменится на специалиста по настройке и контролю линии производства ПО (условно). Кастомная разработка или разработка "с нуля" не исчезнет, но станет редкостью, как сейчас специализация разработчика станков с ЧПУ или изготовления всяких штучных вещей.
На примере мебели: есть Ikea для самых нетребовательных, есть сотни типовых моделей для тех, кто ищет что-то конкретное, ну и есть, конечно, мебель на заказ. И соотношение их рынков, ну не знаю, допустим 17%, 77% и 6% (цифры из головы). Вы, сопротивляясь конвейеру, отрицаете 94% потребностей рынка. Большинство не может и не хочет морочиться с мебелью на заказ. Их устраивает уровень качества Ikea, проще выкинуть через 3-5 лет то, что износилось или надоело, чем жить с бабушкиным комодом Людовика XiV, потому, что заказать новый это приключение на три месяца и стоимостью в три з/п.
Так же, как сейчас есть люди, недовольные качеством современного ПО, есть и люди, недовольные качеством Ikea. Но они не покупают в Ikea, а покупают то, что дороже. Вы можете возразить, что в случае с ПО часто бывает так, что нет альтернативы. А вот это как раз и есть издержки полу-кустарного производства ПО! Если программа требует 10000 человеко-часов для разработки, то она, конечно, будет уникальной. Если максимально автоматизировать (а так же стандартизировать и унифицировать) разработку, то эта же программа потребует, допустим, 500 человеко-часов. И гораздо большее кол-во компаний сможет себе позволить разработку такой программы. Количество - конкуренция - качество.
Напрашивается аналогия с историей создания SQL: язык запросов задумывался как доступный инструмент для работы с табличными данными, понятный любому англоговорящему клерку, а по факту -- ещё одна технология, доступная только профессиональному разработчику. Без знания computer science база легко кладётся запросом, данные теряют согласованность, простая задача становится сложной, сложная -- невыполнимой. Сейчас никто в здравом уме не подпустит клерка и на километр к SQL консоли. То же будет с AI: инструмент, помогающий решать задачу, но хорошо работающий только в руках профессионалов.
Поясню. Суть "идеи", изложенной в статье, напоминает ту самую систему Черноусого, "сотканную из пылких и блестящих натяжек". О чём статья? Сперва введение в теорию графов с картинками из точек и палочек. Учёный-мозговед изучает структуру мозга, выстраивает систематику и иерархию, использует мат.аппарат для описания этой иерархии. Окей. Учёный-математик (известный, кстати, своим "альтернативным" подходом ко многим темам) описывает модель вселенной, используя любимые им математические абстракции. Спорно, но окей. И там, и там где-то на базовом уровне, возможно, используется теория графов. В качестве иллюстрации две картинки с якобы нейросетью и структурой Вселенной. Видите -- похоже! Дальше -- физик (возможно, хороший физик, не знаю) врывается к нам со страниц Яндекс Дзена с утверждением, что "вселенная это нейросеть, которая вычисляет сама себя". Хм. И что теперь?
А дальше ничего. Никаких выводов, никаких прогнозов, ни объяснения, как эта парадигма могла бы изменить теорию или практику познания. Только "заходите на мой Телеграм канал".
Многие в детстве, узнав о строении солнечной системы и строении атома, фантазировали о том, что каждый атом -- это солнечная система, и там, где ядро атома это Солнце, а электроны -- планеты, на электронах живут маленькие планковские человечки. Занимательные фантазии, но смысла в них нет.
- Стоп! - прервал его декабрист. - А разве нельзя не пить? Взять себя в руки - и не пить? Вот тайный советник Гёте, например, совсем не пил.
[...]
Черноусый поник и затосковал. На глазах у публики рушилась вся его система, такая стройная система, сотканная из пылких и блестящих натяжек.
Совет: если просить LLM адаптировать текст "под статью для Хабра", то результат может быть немного получше, не будет так много списков, из которых торчат уши нейросети. Статья ни о чём, "заходите на мой Телеграм канал".
Человек может говорить, что у него проблема, и у него, вероятно, действительно есть проблема, но пока он ничего не делает по этому поводу, даже просто не пытается искать решение, а сидит и тупо смотрит на свою проблему, то проблемы всё равно, что нет. Если человек хотя бы ищет решение, то он уже потенциальный клиент.
Что касается второго пути, про изменение привычек: предложенный инструмент должен а) давать эффективное решение, б) не иметь порог входа существенно выше предыдущего инструмента. Для массовых квази-бесплатных инструментов -- ещё и быть "нескучным", то есть содержать элементы геймификации или emotional design. Если же для эффективного решения проблемы пользователю нужно пройти пятичасовое обучение и освоить какую-то нестандартную парадигму, из цикла "день потерять, потом за пять минут долететь", то большинство от такого инструмента откажется, и он будет невостребован.
Когда у Вас, как Вы говорите, появился "удобный или даже просто приятный инструмент", то по Вашему описанию уже видно, что инструмент вам нравится, а значит, эмоциональный дизайн сработал, для Вас порог вхождения снизился и Вы, скорее всего, с удовольствием им воспользуетесь. Если бы тот же инструмент Вы описали, как "навороченный комбайн", вероятность его использования Вами была бы ниже.
На самом деле, есть ещё третья категория инструментов, позволяющая решать проблемы, которых ранее не существовало в нашем мире, ну просто потому, что это было в принципе невозможно, и все это знали. Но появление таких инструментов -- редкость.
LLM detected
Да что же это такое происходит, люди? Очередная статья прямиком от LLM. Вот сравните, структура практически один-в-один: вводный абзац - виды - инструменты - практики - заключение. Те же пункты, нумерация, форматирование, те же слова, только чуть по-другому расставлены. Попробуйте сами, по промпту `Please write an article on the topic: "Тестирование WebSockets: подходы, инструменты и лучшие практики"` выходит ровно такая статья. Может, пора уже новый формат публикаций вводить, не "статья на Хабре", а "промпт для LLM" ? Типа, "Здравствуй, дружок, сегодня мы будем исследовать тему X. Наш сегодняшний промпт: 'Describe X in 20 paragraphs, with code samples in Python'. Приятного чтения и до новых встреч!"
Хороший и правильный комментарий, но я бы сказал, что бежать плюсовать откровенный машинно-сгенерённый шлак в корпоративном блоге в первый день регистрации на Хабре это немножко палево.
Вот так теперь "пишут статьи" на Хабр.... Печаль.
Вариант чуть покороче, но с теми же пунктами и формулировками.
Идеальный трэш пост, полностью сгенерированный GPT. С промптом в заголовке.
Вообще-то всё верно: 8-разрядным байтом можно закодировать числа от 0 до 255, а это как раз 256 штук.
-12345679 * 72 = -88888888E -- включает все числовые сегменты на экране, знак "минус" и "Е" как результат переполнения (если экран 8-разрядный; если разрядов больше, то первое число дополняется справа цифрами 01234...).