Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние).
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
На него переходили из-за большего числа каналов, которых там много из-за лучшей поддержки их функционала для авторов. То есть дело как раз в функционале, а не скорости.
Специалисты по интерфейсам, дизайну и эргономике видят изъяны везде вокруг — в интерфейсе даже обычной кофемашины.
При том, что большинство нормальных кофемашин собирается на одном из двух заводов одного и того Eughster/Frismag, и за редким исключением используют их же конструкции заварочных блоков.
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.
В качестве образцового примера «мягкой» модернизации COBOL‑систем стоит привести проект NN Group — одного из крупнейших европейских страховщиков. Вместе с Deloitte за 23 месяца они поэтапно перенесли свои ключевые страховые приложения с мэйнфрейма на современную Java‑платформу, не прерывая при этом работу сервисов. Сначала провели глубокий аудит существующего COBOL‑кода и составили карту зависимостей, затем автоматизировали рефакторинг и внедрили CI/CD‑конвейер для «плавающего» запуска новых модулей параллельно со старой системой.
История даёт хороший ответ, почему старые продукты живут десятилетиями, а современные по сто раз переписывают. Потому что МОГУТ. Во-первых, на новые ещё не потеряна вся документация, во-вторых, они изначально писались так, что в них проще вносить изменения.
Без возможности подготовки запроса на этапе компиляции?
Компиляции на каком из стендов? То есть я скомпилировал продакшен версию сборки, она с каким из стендов должна компилироваться?
Только SQL, причем только динамический?
Есть Prepared Statement есть Stored Functions.
COBOL (или тот же RPG) создавались специально для максимально эффективного решения конкретного класса задач.
Эффективного для кого? А то вариант с использованием нормального серверного железа общего назначения видится мне сильно эффективнее. И пофиг что оно будет вдвое менее эффективны из-за необходимости нескольких конвертаций. Зато процессоры будут вдесятеро быстрее из-за больших масштабов производства, а за одно колличество ОЗУ, IOPS-ы на системах хранения данных. И горизонтальное масштабирование проще. И виртуализация при разработке. И поиск разработчиков.
В OpenAI многие работают по 80 часов в неделю. Люди на грани. Компания срочно пересматривают зарплаты, запускают новые программы признания и лояльности. Поэтому неделя «тишины» — попытка не только перезагрузиться, но и сбить волну потенциальных уходов, пока Meta¹ готовит следующую атаку.
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Вообще у многих операций выживаемость ниже.
Грок, сначала запости мнение хозяина в википедию, а потом ссылайся!
В Танки.Оффлайн
Собирает Jura точно также Eughster/Frismag
На него переходили из-за большего числа каналов, которых там много из-за лучшей поддержки их функционала для авторов. То есть дело как раз в функционале, а не скорости.
Скрытый текст
Я использую такой способ даже с запросами из Курсора:
включаю правила на примение всех изменений и запрещаю Клоду трогать комманды гит (это можно один раз в правила прописать)
добавляю все файлы в staging перед запросом Интерфейс просмотра изменений через гит-лесс мне тупо больше нравится, в сравнение с курсоровским.
Конечно не совпадение! Ведь 60% попрежнему клепают разработчики MS!
У которого то соединенние по несколько секунд не отвечает, то переводы по несколько дней не работают.
При том, что большинство нормальных кофемашин собирается на одном из двух заводов одного и того Eughster/Frismag, и за редким исключением используют их же конструкции заварочных блоков.
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.
История даёт хороший ответ, почему старые продукты живут десятилетиями, а современные по сто раз переписывают. Потому что МОГУТ. Во-первых, на новые ещё не потеряна вся документация, во-вторых, они изначально писались так, что в них проще вносить изменения.
Компиляции на каком из стендов? То есть я скомпилировал продакшен версию сборки, она с каким из стендов должна компилироваться?
Есть Prepared Statement есть Stored Functions.
Эффективного для кого? А то вариант с использованием нормального серверного железа общего назначения видится мне сильно эффективнее. И пофиг что оно будет вдвое менее эффективны из-за необходимости нескольких конвертаций. Зато процессоры будут вдесятеро быстрее из-за больших масштабов производства, а за одно колличество ОЗУ, IOPS-ы на системах хранения данных. И горизонтальное масштабирование проще. И виртуализация при разработке. И поиск разработчиков.
Первый раз, когда я огорчился, не увидев в конце статьи ссылку на канал в Телеграмме.
Я смотрю тут у кого-то ОЧЕРЕДЬ ЗА ЗАБОРОМ
С блока 5 была выпущена 51 первая ступень, из которых летало ровно 50. То есть 450 сэкономлено и в среднем по 10 пусков на ступень
https://en.wikipedia.org/wiki/List_of_Falcon_9_first-stage_boosters
Спасибо, я вероятно пропустил этот момент. Значит сделали нормальный пул ключей.
WhatsApp эту проблему не решил, он тупо шлёт всё со через смартфон. Подозреваю, что и Signal тоже.