Видимо, в этом основная проблема, подход слишком ресурсозатратный. Для сравнения, 2005 год, SQL Server на физических 8 ядрах обслуживает запросы от 1500 пользователей онлайн с приемлемым качеством (небольшой процент плохих планов корректируется руками). Каждое ядро лицензируется и обходится примерно в $3-5К. Если сюда добавить 32 ядра для небольшого улучшения оптимизации, то цена решения может стать неприемлемой.
Видимо, я недостаточно точно задал вопрос. Откинем пока условия промышленной эксплуатации, инфраструктуру и вопросы динамики. Допустим есть пакет запросов и статическая БД заданного объема. На условном SQL Server elapsed time и CPU time будут такими-то на N ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")
Подобное достаточно просто реализовалось на N-gram лет 20 назад (поиск дубликатов в CRM). Можно даже на реляционных таблицах. Строка, переведенная в N-gram-ы по сути тот же вектор. https://blog.arbinada.com/ru/category/00020.html
Но при этом уже есть отдельные библиотеки и фреймворки с версиями выше 1. Когда их критическая масса созреет, вопрос отпадет сам собой. Из того что я видел вживую, ребята пилят версию 0 за денежки корпорации, но потом корпорация меняет планы выпуска своего оборудования, библиотека больше им не нужна, она остается в гитхабе "сами разбирайтесь, если надо".
Пример Оракла единичен и, скорее, относится к профюмору.
Есть история версий, клиентская база и возможности поддержки (в т.ч. платной). Стандартная логика пользователей такая: 0 - ребята пока пилят что-то на коленке, можно даже им помочь, если есть силы, 1 - появились первые промышленные применения, 2 и далее - продукт оказался нужным и развивается
Описание языка (референс) - текущее состояние с привязкой к компилятору. Стандарт (спецификация) - официально зафиксированный слепок на конкретный момент времени, которому должны соответствовать компиляторы, заявляющие о совместимости "на уровне стандарта ХХХ".
Надо как-то решать эту проблему. Если библиотека готова к промышленной эксплуатации, то версия не должна быть 0.х. Я общался с ребятами, которые делают сетевую среду с брокерами, "сообщники" им просто не дают поставить "единичку".
1.х тоже еще не признак зрелости, но хоть что-то. Оракл в свое время начал выпуск СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией.
Первое и второе, что сразу напрягает в Расте - отсутствие стандарта и длинный список зависимостей с номерами версий, начинающимися на ноль. Третье, что паттерны из С++ не годятся, надо переучиваться.
Лет 25-30 назад подобные "мемы" звучали как "дивизия солдат подпрыгивает по команде в котловане для имитации ядерного взрыва" и "миллион китайцев в шелковых трусах лазают по эбонитовым столбам"
В принципе, текст полезный. Когда долго не пишешь транзакционный код на т-сиквеле, многие вещи вытесняются (я полез вспоминать scope_identity), но ведь есть MSDN :)
К первому примеру несколько пожеланий:
сократить число таблиц до двух, чтобы показать нарушение внешнего ключа этого достаточно
использовать точку с запятой после каждого оператора
использовать GO для отделения пакетов по созданию таблиц, процедур и собственно кода манипуляции данными, за которым надо бы просто удалять эти таблицы, используя модерновый DROP IF EXISTS
На сегодняшний день определенной является лишь одна тенденция: всякий раз при увеличении производительности труда программистов необходимость в них только возрастала.
Если в тексте есть хоть капля серьёзности, то будет шквал вакансий для "программистов на Devin", которую к тому времени десять раз перекупят корпорации, сделав Devin EE.
Уточнения ради, print-ов в Паскале не было и не предвидится, а работа с файлами в изначальном виде велась через функции ввода/вывода read/write, терминал считался файлами input, output.
Видимо, в этом основная проблема, подход слишком ресурсозатратный. Для сравнения, 2005 год, SQL Server на физических 8 ядрах обслуживает запросы от 1500 пользователей онлайн с приемлемым качеством (небольшой процент плохих планов корректируется руками). Каждое ядро лицензируется и обходится примерно в $3-5К. Если сюда добавить 32 ядра для небольшого улучшения оптимизации, то цена решения может стать неприемлемой.
Видимо, я недостаточно точно задал вопрос. Откинем пока условия промышленной эксплуатации, инфраструктуру и вопросы динамики.
Допустим есть пакет запросов и статическая БД заданного объема. На условном SQL Server elapsed time и CPU time будут такими-то на N ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Девопс, для которого требуется вдвое больше людей, чем для создания собственно программного продукта, действительно не нужен, как тот хоккей (мем, понятный "дедам")
Подобное достаточно просто реализовалось на N-gram лет 20 назад (поиск дубликатов в CRM). Можно даже на реляционных таблицах. Строка, переведенная в N-gram-ы по сути тот же вектор.
https://blog.arbinada.com/ru/category/00020.html
Интересные у вас представления о брошенных курах, несущих золотые яйца
В вики есть отдельные статьи для "Programming language reference" и "Programming language specification". Спецификация для ЯП синоним стандарта.
Но при этом уже есть отдельные библиотеки и фреймворки с версиями выше 1. Когда их критическая масса созреет, вопрос отпадет сам собой. Из того что я видел вживую, ребята пилят версию 0 за денежки корпорации, но потом корпорация меняет планы выпуска своего оборудования, библиотека больше им не нужна, она остается в гитхабе "сами разбирайтесь, если надо".
Как раз про Раст и разницу между стандартом (спецификацией) и описанием (референсом): "What is the difference between specification and a reference for programming languages?".
Ребята ведь начали пилить RFC, хотя референс есть. Казалось бы, зачем, да? :)
Всего вам доброго
Пример Оракла единичен и, скорее, относится к профюмору.
Есть история версий, клиентская база и возможности поддержки (в т.ч. платной). Стандартная логика пользователей такая: 0 - ребята пока пилят что-то на коленке, можно даже им помочь, если есть силы, 1 - появились первые промышленные применения, 2 и далее - продукт оказался нужным и развивается
Описание языка (референс) - текущее состояние с привязкой к компилятору. Стандарт (спецификация) - официально зафиксированный слепок на конкретный момент времени, которому должны соответствовать компиляторы, заявляющие о совместимости "на уровне стандарта ХХХ".
Надо как-то решать эту проблему. Если библиотека готова к промышленной эксплуатации, то версия не должна быть 0.х. Я общался с ребятами, которые делают сетевую среду с брокерами, "сообщники" им просто не дают поставить "единичку".
1.х тоже еще не признак зрелости, но хоть что-то. Оракл в свое время начал выпуск СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией.
P.S. Никогда никого не "минусую"
Если цель комментария - диалог, то не стоит использовать рекомендательный тон отраслевого регулятора. Рекомендую, по-дружески :)
Разницу между описанием языка и стандартом, надеюсь, понимаете.
Библиотеки версий 0.х в промышленную эксплуатацию? Ну, что ж, удачи в отладке стороннего кода.
Не учиться, а переучиваться "отринув прежнее". Переход с Си на Си++ позволял учиться новому, не бросив на произвол судьбы тонны существующего кода.
Первое и второе, что сразу напрягает в Расте - отсутствие стандарта и длинный список зависимостей с номерами версий, начинающимися на ноль. Третье, что паттерны из С++ не годятся, надо переучиваться.
Опять "аджайл неправильный" и "микросервисы не по паттернам".
С тем же успехом можно утверждать, что "ИИ не справился с задачей увеличения производительности труда работающих в магазине людей".
Лет 25-30 назад подобные "мемы" звучали как "дивизия солдат подпрыгивает по команде в котловане для имитации ядерного взрыва" и "миллион китайцев в шелковых трусах лазают по эбонитовым столбам"
В принципе, текст полезный. Когда долго не пишешь транзакционный код на т-сиквеле, многие вещи вытесняются (я полез вспоминать scope_identity), но ведь есть MSDN :)
К первому примеру несколько пожеланий:
сократить число таблиц до двух, чтобы показать нарушение внешнего ключа этого достаточно
использовать точку с запятой после каждого оператора
использовать GO для отделения пакетов по созданию таблиц, процедур и собственно кода манипуляции данными, за которым надо бы просто удалять эти таблицы, используя модерновый DROP IF EXISTS
Ксаверий, или языковые модели против кодировщиков
На сегодняшний день определенной является лишь одна тенденция: всякий раз при увеличении производительности труда программистов необходимость в них только возрастала.
Если в тексте есть хоть капля серьёзности, то будет шквал вакансий для "программистов на Devin", которую к тому времени десять раз перекупят корпорации, сделав Devin EE.
Уточнения ради, print-ов в Паскале не было и не предвидится, а работа с файлами в изначальном виде велась через функции ввода/вывода read/write, терминал считался файлами input, output.