Завис на фразе "хотим поиграть на большом экране - включаем компьютер". Ожидал включения телевизора и приставки, потом понял, что сравнение, видимо, идет с телефоном)
Как я понял, предполагается решение: разбить входной файл на куски (чанки) разумным маленьким размером (4-16 Мб), посжимать отдельно и выходный файл наполнять сжатыми кусками, пока он не перейдет лимит в 100 Мб, а последний невлезающий кусок откатить и сделать началом нового файла. Типа сжатие можно распараллелить, а лимиты чанков и выходных кусков менять независимо?
Но я не понял, как определить границы сжатых чанков в выходном файле. То есть я не смогу, как winrar, рассматривать последовательность .part1, .part2, ... как один виртуальный файл, и разархивировать, будто нет границ между файлами? То есть приступая в будущем к восстановлению, я должен знать какую-то схему, иначе не смогу прочитать бэкап?
И еще вопрос по вашему опыту. Насколько итоговый коэффициент сжатия через чанки может быть хуже, чем сжатие всего файла?
По той же ссылке упомянуты например, "ставки НДС" и "работа с валютами". Направление дальнейшего развития прослеживается. Можно поспорить про сроки, но нет желания, потому что действительно все это очень медленно.
5 лет назад уже ... позиционировала как веб-фреймоврк для кабинетов ... кто про него что знает
Долгое время внедрение элемента было закрытое и ограниченное, с прямым упоминанием, что ведется тест. Мне кажется, справедливо не зачитывать этот срок в аргументацию. А еще все это время можно было щупать шину как производный продукт элемента, я лично участвовал в двух проектах ее внедрения и доработки на производственном и строительном предприятиях федерального уровня. Так что, извините, не соглашусь, технология, лежащая в основе, используется плотно, и отзывы коллег оптимистичные, хотя продукт сырой.
Theia вообще на TypeScript написана, а не на Java, если что
Сервер элемента и интерпретатор языка - на Java. Сервер и интерпретатор - ключевые составляющие платформы. Можно сказать, что платформа написана на Java. Интерфейс и IDE на JS/TS, но вы и React, web-Flutter и Django не назовете html/css-фреймворками, потому что язык бэка важнее в данном случае.
Но, даже так, не понимаю, в чем проблема с IDE
С новой IDE нет проблем, нашли на рынке джавистов - взяли джавистов (а не растовцев). Вы просто настаиваете, что лучше было развивать старую платформу и ее конфигуратор, а я говорю, что нет, проще написать или доделать новую под новый язык.
запланирован gRPC
Из двух API архитектурных стилей RPC vs REST, для RPC долгое время были доступны только soap-сервисы. И самодельные вебсокеты на внешних компонентах. Из-за чего никто из внешних команд с 1С в интеграциях связываться не хочет, только битрикс иногда трепыхается, но недолго, пока не поставят ломаную жиру. Вы, по сути, подтверждаете необходимость смены платформы, раз в ней так долго внедряются нормальные решения. Язык, кстати, от этого не обновится, он продолжит тормозить внедрение новых фич. Но за gRPC я обеими руками за, наконец-то это происходит.
Я просто не разделяю мнения, что Элемент заменит Предприятие
В этом наше несогласие друг с другом, но это нормально. Я объяснил свой выбор, надеюсь, он будет правильный, а время покажет. На старой платформе, в любом случае, оставаться нет желания, у меня язык конфигуратора уже просто вызывает отторжение.
Я же написал почему. Потому что легаси, и даже не в плане кодовой базы, а из-за сопутствующих технологий. Все концепции вокруг переменились, подходы к совместной разработке, интеграциям, протоколам. Надо все писать заново, с нуля.
Или на расте?
Если согласны, что надо заново писать платформу, то довод продолжается тем, что надо еще и новую IDE писать. Это двойной множитель на работу, потому что под новый язык и новую платформу Элемента никто готовую IDE на блюдечке не принесет. Вендор выбрал полуторный множитель - доделал бесплатную Theia. Она на джаве, вот и выбор подосновы. Да и разрабов на расте меньше, чем на джаве.
Если у 1С действительно было бы какое-то желание развития разработки - она бы вложилась и доработала EDT
Так это тоже тупиковый вариант и временный компромисс. Ок, конфигуратор обновили, но язык все равно устарел и платформа тоже устарела, их невозможно апгрейдить под современные реалии из-за принципиально устаревшего системного дизайна.
с таким же успехом я могу познакомиться с гитом и статической типизацией в любом другом языке
Можете, но разработка это не только язык, но и фреймворк. Элемент идеологически реализует знакомый фуллстековый фреймворк с метаданными, правами, ORM, который не так уж плох сам по себе. Надо только освоить новый язык. Как будто бы нормально выглядящий процесс, когда фреймворк оставили тот же, а инструменты дали посвежее.
Я сказал, что в целом согласен с вами, просто не разделяю желание сгущать краски на эмоциях. Если есть желание оставаться в экосистеме 1С, то освоение их новых инструментов специалиста никак не оскорбляет и даже помогает. Работу по РФ искать будет легче, чем на расте или го, переходить в другие языки тоже будет легче, потому что новый язык концептуально свежий и стройный.
Процесс перехода сейчас хоть и кажется неуклюжим, но он бодрый и непреклонный. Есть возможность сделать вклад на уровне библиотек, развить профессионально-личный бренд, заработать славу и определить ландшафт для коллег на несколько лет вперед. Если не отвергать изменения по причине усталости от вендора.
Немножко не хватало. Концепцию использует, например, YAxUnit, основная библиотека тестирования, по причине удобства для написания условий тестов. В скрипте же удобнее составлять http-запросы и сообщения интеграции.
В целом, согласен с вами, но чуть-чуть разбавлю позитивом.
Язык платформы безнадежно устарел, и по сути, новый язык - это долгожданное обновление, привлекательное преимущественно из-за статической типизации и гита. Плюс единый язык для бекэнда/фронтэнда. Язык в целом довольно свежий, для тех, кто изучает Java, C#, Dart, да даже Go, откровений не будет, но и освоить достаточно только синтаксис. А самобытных разрабов на языке платформы давно пора встряхнуть и познакомить с текучими интерфейсами, ооп-структурами, функциями как объектами первого порядка, null safety и прочими хорошими вещами.
Корпоративные стандарты на закрытость не изменятся, вендор хочет быть монополистом, но бесплатные точки входа есть. Да, с регистрацией, да, с аналитикой, но на портале разработчика можно скачать интерпретатор со средой. Документация к самому языку открытая, сбор аналитики тоже не новинка в современных стеках. Чистый язык пока подходит только для скриптования админской работы, но тем не менее.
По поводу компетенций. Не уверен точно, но для развития платформы нужны сишники на плюсах, а для EDT и элемента чистые джависты. Не сказал бы, что новая команда прям сильная, так как качество плавающее, но то, что начиналось на плюсах, невозможно переделать заново, а переделывать нужно, потому что все сопутствующие технологии слишком далеко ушли вперед. Git вместо Subversion, gRPC вместо SOAP, нейрошины (n8n) вместо конвертации и датареона, наконец, json вместо xml. Разработка новых современных продуктов и технологий, в любом случае, неизбежна, а формат, в котором это происходит, мы и наблюдаем сейчас.
EDT на Eclipse и Элемент на Theia - тупо потому что они бесплатные. Я бы тоже хотел увидеть златокрасный восход 1C на продуктах JetBrains, но это совершенно нереалистично. Мо-о-ожет, в рамках импортозамещения однажды докатимся до OpenIDE, потому что это та же Intellij IDEA для джавы, но это тоже пока фантастика.
С учетом 8.5 и единого интерфейса платформы с элементом, вендор как будто хочет уйти от ограничений платформы и воспитать новое поколение более квалифицированных разработчиков. К сожалению, со старыми подходами в отношении монополизации рынка, монополизации стека внутри компании и подписочной моделью. Но что самое ценное для меня - теперь можно начинать нормально общаться с представителями других стеков, разговаривая на общем языке с пересекающимися и актуальными концепциями, организуя понятные интеграции и строя прилично выглядящие архитектуры, в которых нет явного шовинизма к неизбежному злу существования на предприятии платформы 1С. Ну и как минимум, свалить на тот же шарп после пары лет кодинга на 1С скрипте будет гораздо легче, чем с языка платформы.
Как думаете, что легче - перейти с Клауды на Дипсик или перевести проект с C# на Java?
Независимо от тяжести, зависимость остается зависимостью. Две зависимости еще хуже, чем одна. Ну и выбора скоро не останется, процессы, порождающие монополизацию, никуда не делись. Предлагаю вернуться к разговору, когда, после череды крупных сделок, выбора между клаудом и дипсиком не будет)
где больше бабла крутится
В абсолютном объеме возможно. В относительном, в пересчёте на бенефициара как будто бы ЦУПы выигрывают. Иначе зачем Илону Маску пускать ракеты и подсаживаться на госконтракты, если у него есть грок и твиттер. Предлагаю сравнить прибыль с твиттера и со SpaceX, чтобы говорить предметно.
без оплаты
Я написал "без оТплаты", немного другое значение у слова. Будьте внимательнее и не сводите все к товарно-денежным отношениям.
Все знают, что LLM сделаны из Интернета
Без которого не могли появиться, и которые без контроля и эволюции умрут в своих отходах жизнедеятельности, уничтожив и себя, и среду, как самые обычные дрожжи. Аналогия с дрожжами хороша тем, что продукт нейросетей вызывает такую же зависимость, как алкоголь - первичная эйфория, падение барьеров, чувство всемогущества, но в долговременной перспективе - потеря фокуса, утрата профессиональных навыков и деградация. Речь, конечно, об LLM общего назначения, потому что специализированные, по поиску трещин в бетоне или онкомаркеров в моче, хоть и не претендуют на революцию и хайп, но тихо и успешно автоматизируют свою предметную область.
Без Delphi и Dart рассуждения считаю неполными. В интерпретации автора сильно картину не сдвинут, но позитивные нюансы для остальных есть.
Разговорный язык не принадлежит какой-то коммерческой компании
А окошко с чатом и секретные веса принадлежат. Причем украдено ещё более наглым образом - обучено на реальном выстраданном опыте и без отплаты и даже уважения к первоисточникам.
написание кода через AI на разговорном языке — это настоящая свобода
Хм, я правильно понял, что свобода - это заменить зависимость от условного майкрософта в лице шарпа на зависимость от условного майкрософта в лице копилота?
Оставшуюся мысль сложно иллюстрировать цитатами, так как конец статьи смазанный. В общем, без вливаний нового кода, либо без принципиального изменения фундаментальных концепций генеративной разработки, нейросети ничего нового больше то и не выдадут. Авторизация по почте в безликих веб-приложениях миллионы раз написана по гайдам и доке, а вот авторизация центра управления полетами в далеком луноходе для передачи команд на изменение мощности РИТЭГа - всего лишь единожды для каждого лунохода. Так что, на месте автора я бы либо более уважительно относился к труду людей, кто пишет вручную и поставляет сырье, либо перебалансировал взгляд в будущее с учетом изначальной ограниченности ключевой вероятностной механики современных LLM. Но, конечно, в первую очередь перестал бы называть нейросети и БЯМ искуственным интеллектом.
Про параллельные прямые вроде аксиома же, она ни доказательства, ни решения не требует.
Алгоритм решения еще не известен никому, но его можно проверить, когда нейроэксперт отправит выдачу ллмки, например, в формате листинга Coq, а интерфейс бенчмарка примет и выполнит листинг, потому что в основе Coq лежит язык функционального программирования, который можно выполнить как обычный скрипт.
А дело да, действительно в объеме вычислений. Поиск решения за экспоненциальное время существует гарантированно, но воспроизвести его на компьютере, да даже на кластере, невозможно из-за огромных объемов вычислений. Все ищут теорию под задачу, чтобы выполнять его за полиномиальное время. Проверить при этом можно как само решение или найденное значение (потому что проверка, а не поиск, всегда за полиномиальное время), так и саму теорию, ее вывод и непротиворечивость, если ее формализовать одним из инструментов, который я упоминаю уже в третий раз - Coq/Isabelle.
Алгоритм для поиска и алгоритм для проверки - это два разных алгоритма, и алгоритм проверки написать несравнимо легче, даже не зная алгоритма поиска.
NP-задачи — это класс задач разрешимости, решение которых можно проверить за полиномиальное время, но для поиска решения, как правило, требуется экспоненциальное время.
"Разрешимость" значит ответ да/нет. А коммивояжер вообще за факториальное считается, что хуже экспоненциального, то есть не имея внятной теории, перебором даже единичное решение найти не получится.
Правильность может быть как бинарной (да, значение удовлетворяет условия и является решением; нет, значение опровергает предположение и является исключением), так и относительной (уровень приближения к доказательству).
Все в зависимости от задачи, они очень разнородными могут быть. Ваша задача показательна, но не подходит под критерии бенчмарка из-за сложности в автоматизации проверки решения. На самом деле, даже если вы скажете свое решение, с вами половина комментаторов могут вступить в спор просто на словах.
А алгоритмизация математики - не экзотика. Darcs/Pijul оперируют множествами вместо деревьев Git, Haskell - язык на основе теории типов, а Sel4 - полностью формально верифицируемое микроядро. Ноу-хау бенчмарка и состоит в автоматизации проверки решений, помимо подбора задач. Это не каждый с улицы может сделать.
Что ж теперь, Нобелевку не давать? Люди, которые не совершили открытие, не могут проверить его подлинность?
Про верификацию упомянули в статье. Технически это может быть как нахождение конкретного значения или исключения, так и формализация доказательства через Coq/HOL (даже не важно, ручная и автоматизированная, ну то есть напрямую ответ нейросетки кинуть в верификатор или структурировать сначала). В зависимости от задачи.
Дело в том, что если решения нет в сети, нейросеть его не придумает сама. Вы своей учебной задачкой как раз подтверждаете позицию авторов бенчмарка, и на одной с ними стороне.
Прекрасная статья, спасибо! Очень плотно по информации и очень вдохновляюще. Появляется какая-то симпатия к гуглу и его инженерам через близость и сложность задач по обеспечению совместимости и трансформации нагорячую, ну и конечно, из-за сумасшедшего масштаба (по сути, вся планета).
Можно два тупых вопроса?
Почему приложение камеры в телефоне в рамках модели ухудшается с каждым обновлением? Наблюдал на мейзу, мотороле и ванплюсе по мере смены телефона. Типа ядро обновляется, и вендору просто лень писать новые драйверы на уровне старой функциональности?
Как вы оцениваете будущую динамику деятельности сообществ по подготовке неоффициальных прошивок, особенно для старой техники? Я так понимаю, для новых изделий FIDL облегчает переносы драйверов плюс сокращается количество оболочек плюс легче вырезать сервисы гугла из-за открытости платформы. А для старых устройств нас ждет ренессанс реинкарнаций или ничего особо не изменится, потому что для старых компонентов не будут переписывать драйвера, как минимум, нативно под фуксию?
нужно начать делать работу просто выполнять работу просто начните уже делать работу
Скрытый текст
JUST DO IT!
Как исполнитель, я тоже голосую за канбан. Но все остальные размышления довольны размыты и наивны. Из разряда "у тебя не будет плохих метрик, если у тебя изначально нет метрик")
делать только те задачи, которые реально приносят пользу бизнесу
Как или в чем оценить реальную пользу? Если чисто на словах, договоренностях и убеждении, то будущее таких компаний меня пугает. Из-за того, что в менеджмент просачиваются личности, умеющие красиво говорить и профессионально высасывать деньги из работодателя, разрушая при этом все - атмосферу в коллективе, эффективность работы и технологичность автоматизации.
В общем, чтобы воплотиться в жизнь, озвученные принципы требуют очень высокой осознанности и ответственности от каждого участника процесса. И даже, в каком-то смысле, это шаг в строну плоских горизонтальных структур управления. Строгая иерархия гораздо более привычна/понятна и гораздо более распространена, и она как раз требует таких же организованных в иерархию метрик. Хотя бы чтобы ими можно было управлять иерархическими же подходами.
Другой момент, что пример из демонстрации не показательный. Интеграция 1С с UDS уже есть в интернете, плюс еще 60 других с иными системами. Во-первых, нейросеть могла на них учиться, и результат ее работы ближе к повторению, чем к изобретению через анализ. Во-вторых, зачем писать интеграцию с нуля даже через нейросеть, если она уже есть? Прикрутить подсистему к ERP вместо Розницы легче, чем исправлять галлюцинации.
В видосе опять показан только процесс, без результата. Все заканчивается на паре десятков синтаксических ошибок и обещанием переделать и сделать тесты.
Ок, вы озвучили потребность, показали промпт, спасибо. А где можно посмотреть результат этой интеграции?
В систему удачно и прикольно ложится поговорка "Добро должно быть с кулаками". Особенно сопровождаясь предостережением не называть добром все подряд)
Завис на фразе "хотим поиграть на большом экране - включаем компьютер". Ожидал включения телевизора и приставки, потом понял, что сравнение, видимо, идет с телефоном)
Как я понял, предполагается решение: разбить входной файл на куски (чанки) разумным маленьким размером (4-16 Мб), посжимать отдельно и выходный файл наполнять сжатыми кусками, пока он не перейдет лимит в 100 Мб, а последний невлезающий кусок откатить и сделать началом нового файла. Типа сжатие можно распараллелить, а лимиты чанков и выходных кусков менять независимо?
Но я не понял, как определить границы сжатых чанков в выходном файле. То есть я не смогу, как winrar, рассматривать последовательность .part1, .part2, ... как один виртуальный файл, и разархивировать, будто нет границ между файлами? То есть приступая в будущем к восстановлению, я должен знать какую-то схему, иначе не смогу прочитать бэкап?
И еще вопрос по вашему опыту. Насколько итоговый коэффициент сжатия через чанки может быть хуже, чем сжатие всего файла?
Хорошо
Приглашаю к ознакомлению.
По той же ссылке упомянуты например, "ставки НДС" и "работа с валютами". Направление дальнейшего развития прослеживается. Можно поспорить про сроки, но нет желания, потому что действительно все это очень медленно.
Долгое время внедрение элемента было закрытое и ограниченное, с прямым упоминанием, что ведется тест. Мне кажется, справедливо не зачитывать этот срок в аргументацию. А еще все это время можно было щупать шину как производный продукт элемента, я лично участвовал в двух проектах ее внедрения и доработки на производственном и строительном предприятиях федерального уровня. Так что, извините, не соглашусь, технология, лежащая в основе, используется плотно, и отзывы коллег оптимистичные, хотя продукт сырой.
Сервер элемента и интерпретатор языка - на Java. Сервер и интерпретатор - ключевые составляющие платформы. Можно сказать, что платформа написана на Java. Интерфейс и IDE на JS/TS, но вы и React, web-Flutter и Django не назовете html/css-фреймворками, потому что язык бэка важнее в данном случае.
С новой IDE нет проблем, нашли на рынке джавистов - взяли джавистов (а не растовцев). Вы просто настаиваете, что лучше было развивать старую платформу и ее конфигуратор, а я говорю, что нет, проще написать или доделать новую под новый язык.
Из двух API архитектурных стилей RPC vs REST, для RPC долгое время были доступны только soap-сервисы. И самодельные вебсокеты на внешних компонентах. Из-за чего никто из внешних команд с 1С в интеграциях связываться не хочет, только битрикс иногда трепыхается, но недолго, пока не поставят ломаную жиру. Вы, по сути, подтверждаете необходимость смены платформы, раз в ней так долго внедряются нормальные решения. Язык, кстати, от этого не обновится, он продолжит тормозить внедрение новых фич. Но за gRPC я обеими руками за, наконец-то это происходит.
В этом наше несогласие друг с другом, но это нормально. Я объяснил свой выбор, надеюсь, он будет правильный, а время покажет. На старой платформе, в любом случае, оставаться нет желания, у меня язык конфигуратора уже просто вызывает отторжение.
Я же написал почему. Потому что легаси, и даже не в плане кодовой базы, а из-за сопутствующих технологий. Все концепции вокруг переменились, подходы к совместной разработке, интеграциям, протоколам. Надо все писать заново, с нуля.
Если согласны, что надо заново писать платформу, то довод продолжается тем, что надо еще и новую IDE писать. Это двойной множитель на работу, потому что под новый язык и новую платформу Элемента никто готовую IDE на блюдечке не принесет. Вендор выбрал полуторный множитель - доделал бесплатную Theia. Она на джаве, вот и выбор подосновы. Да и разрабов на расте меньше, чем на джаве.
Так это тоже тупиковый вариант и временный компромисс. Ок, конфигуратор обновили, но язык все равно устарел и платформа тоже устарела, их невозможно апгрейдить под современные реалии из-за принципиально устаревшего системного дизайна.
Можете, но разработка это не только язык, но и фреймворк. Элемент идеологически реализует знакомый фуллстековый фреймворк с метаданными, правами, ORM, который не так уж плох сам по себе. Надо только освоить новый язык. Как будто бы нормально выглядящий процесс, когда фреймворк оставили тот же, а инструменты дали посвежее.
Я сказал, что в целом согласен с вами, просто не разделяю желание сгущать краски на эмоциях. Если есть желание оставаться в экосистеме 1С, то освоение их новых инструментов специалиста никак не оскорбляет и даже помогает. Работу по РФ искать будет легче, чем на расте или го, переходить в другие языки тоже будет легче, потому что новый язык концептуально свежий и стройный.
Процесс перехода сейчас хоть и кажется неуклюжим, но он бодрый и непреклонный. Есть возможность сделать вклад на уровне библиотек, развить профессионально-личный бренд, заработать славу и определить ландшафт для коллег на несколько лет вперед. Если не отвергать изменения по причине усталости от вендора.
Немножко не хватало. Концепцию использует, например, YAxUnit, основная библиотека тестирования, по причине удобства для написания условий тестов. В скрипте же удобнее составлять http-запросы и сообщения интеграции.
В целом, согласен с вами, но чуть-чуть разбавлю позитивом.
Язык платформы безнадежно устарел, и по сути, новый язык - это долгожданное обновление, привлекательное преимущественно из-за статической типизации и гита. Плюс единый язык для бекэнда/фронтэнда. Язык в целом довольно свежий, для тех, кто изучает Java, C#, Dart, да даже Go, откровений не будет, но и освоить достаточно только синтаксис. А самобытных разрабов на языке платформы давно пора встряхнуть и познакомить с текучими интерфейсами, ооп-структурами, функциями как объектами первого порядка, null safety и прочими хорошими вещами.
Корпоративные стандарты на закрытость не изменятся, вендор хочет быть монополистом, но бесплатные точки входа есть. Да, с регистрацией, да, с аналитикой, но на портале разработчика можно скачать интерпретатор со средой. Документация к самому языку открытая, сбор аналитики тоже не новинка в современных стеках. Чистый язык пока подходит только для скриптования админской работы, но тем не менее.
По поводу компетенций. Не уверен точно, но для развития платформы нужны сишники на плюсах, а для EDT и элемента чистые джависты. Не сказал бы, что новая команда прям сильная, так как качество плавающее, но то, что начиналось на плюсах, невозможно переделать заново, а переделывать нужно, потому что все сопутствующие технологии слишком далеко ушли вперед. Git вместо Subversion, gRPC вместо SOAP, нейрошины (n8n) вместо конвертации и датареона, наконец, json вместо xml. Разработка новых современных продуктов и технологий, в любом случае, неизбежна, а формат, в котором это происходит, мы и наблюдаем сейчас.
EDT на Eclipse и Элемент на Theia - тупо потому что они бесплатные. Я бы тоже хотел увидеть златокрасный восход 1C на продуктах JetBrains, но это совершенно нереалистично. Мо-о-ожет, в рамках импортозамещения однажды докатимся до OpenIDE, потому что это та же Intellij IDEA для джавы, но это тоже пока фантастика.
С учетом 8.5 и единого интерфейса платформы с элементом, вендор как будто хочет уйти от ограничений платформы и воспитать новое поколение более квалифицированных разработчиков. К сожалению, со старыми подходами в отношении монополизации рынка, монополизации стека внутри компании и подписочной моделью. Но что самое ценное для меня - теперь можно начинать нормально общаться с представителями других стеков, разговаривая на общем языке с пересекающимися и актуальными концепциями, организуя понятные интеграции и строя прилично выглядящие архитектуры, в которых нет явного шовинизма к неизбежному злу существования на предприятии платформы 1С. Ну и как минимум, свалить на тот же шарп после пары лет кодинга на 1С скрипте будет гораздо легче, чем с языка платформы.
Независимо от тяжести, зависимость остается зависимостью. Две зависимости еще хуже, чем одна. Ну и выбора скоро не останется, процессы, порождающие монополизацию, никуда не делись. Предлагаю вернуться к разговору, когда, после череды крупных сделок, выбора между клаудом и дипсиком не будет)
В абсолютном объеме возможно. В относительном, в пересчёте на бенефициара как будто бы ЦУПы выигрывают. Иначе зачем Илону Маску пускать ракеты и подсаживаться на госконтракты, если у него есть грок и твиттер. Предлагаю сравнить прибыль с твиттера и со SpaceX, чтобы говорить предметно.
Я написал "без оТплаты", немного другое значение у слова. Будьте внимательнее и не сводите все к товарно-денежным отношениям.
Без которого не могли появиться, и которые без контроля и эволюции умрут в своих отходах жизнедеятельности, уничтожив и себя, и среду, как самые обычные дрожжи. Аналогия с дрожжами хороша тем, что продукт нейросетей вызывает такую же зависимость, как алкоголь - первичная эйфория, падение барьеров, чувство всемогущества, но в долговременной перспективе - потеря фокуса, утрата профессиональных навыков и деградация. Речь, конечно, об LLM общего назначения, потому что специализированные, по поиску трещин в бетоне или онкомаркеров в моче, хоть и не претендуют на революцию и хайп, но тихо и успешно автоматизируют свою предметную область.
Без Delphi и Dart рассуждения считаю неполными. В интерпретации автора сильно картину не сдвинут, но позитивные нюансы для остальных есть.
А окошко с чатом и секретные веса принадлежат. Причем украдено ещё более наглым образом - обучено на реальном выстраданном опыте и без отплаты и даже уважения к первоисточникам.
Хм, я правильно понял, что свобода - это заменить зависимость от условного майкрософта в лице шарпа на зависимость от условного майкрософта в лице копилота?
Оставшуюся мысль сложно иллюстрировать цитатами, так как конец статьи смазанный. В общем, без вливаний нового кода, либо без принципиального изменения фундаментальных концепций генеративной разработки, нейросети ничего нового больше то и не выдадут. Авторизация по почте в безликих веб-приложениях миллионы раз написана по гайдам и доке, а вот авторизация центра управления полетами в далеком луноходе для передачи команд на изменение мощности РИТЭГа - всего лишь единожды для каждого лунохода. Так что, на месте автора я бы либо более уважительно относился к труду людей, кто пишет вручную и поставляет сырье, либо перебалансировал взгляд в будущее с учетом изначальной ограниченности ключевой вероятностной механики современных LLM. Но, конечно, в первую очередь перестал бы называть нейросети и БЯМ искуственным интеллектом.
Так уже есть такой, но вам не понравится)
Извлекаем золото из старой электроники
Про параллельные прямые вроде аксиома же, она ни доказательства, ни решения не требует.
Алгоритм решения еще не известен никому, но его можно проверить, когда нейроэксперт отправит выдачу ллмки, например, в формате листинга Coq, а интерфейс бенчмарка примет и выполнит листинг, потому что в основе Coq лежит язык функционального программирования, который можно выполнить как обычный скрипт.
А дело да, действительно в объеме вычислений. Поиск решения за экспоненциальное время существует гарантированно, но воспроизвести его на компьютере, да даже на кластере, невозможно из-за огромных объемов вычислений. Все ищут теорию под задачу, чтобы выполнять его за полиномиальное время. Проверить при этом можно как само решение или найденное значение (потому что проверка, а не поиск, всегда за полиномиальное время), так и саму теорию, ее вывод и непротиворечивость, если ее формализовать одним из инструментов, который я упоминаю уже в третий раз - Coq/Isabelle.
Алгоритм для поиска и алгоритм для проверки - это два разных алгоритма, и алгоритм проверки написать несравнимо легче, даже не зная алгоритма поиска.
Так прямо сказано в определении NP-задач:
"Разрешимость" значит ответ да/нет. А коммивояжер вообще за факториальное считается, что хуже экспоненциального, то есть не имея внятной теории, перебором даже единичное решение найти не получится.
Правильность может быть как бинарной (да, значение удовлетворяет условия и является решением; нет, значение опровергает предположение и является исключением), так и относительной (уровень приближения к доказательству).
Все в зависимости от задачи, они очень разнородными могут быть. Ваша задача показательна, но не подходит под критерии бенчмарка из-за сложности в автоматизации проверки решения. На самом деле, даже если вы скажете свое решение, с вами половина комментаторов могут вступить в спор просто на словах.
А алгоритмизация математики - не экзотика. Darcs/Pijul оперируют множествами вместо деревьев Git, Haskell - язык на основе теории типов, а Sel4 - полностью формально верифицируемое микроядро. Ноу-хау бенчмарка и состоит в автоматизации проверки решений, помимо подбора задач. Это не каждый с улицы может сделать.
Что ж теперь, Нобелевку не давать? Люди, которые не совершили открытие, не могут проверить его подлинность?
Про верификацию упомянули в статье. Технически это может быть как нахождение конкретного значения или исключения, так и формализация доказательства через Coq/HOL (даже не важно, ручная и автоматизированная, ну то есть напрямую ответ нейросетки кинуть в верификатор или структурировать сначала). В зависимости от задачи.
Дело в том, что если решения нет в сети, нейросеть его не придумает сама. Вы своей учебной задачкой как раз подтверждаете позицию авторов бенчмарка, и на одной с ними стороне.
Прекрасная статья, спасибо! Очень плотно по информации и очень вдохновляюще. Появляется какая-то симпатия к гуглу и его инженерам через близость и сложность задач по обеспечению совместимости и трансформации нагорячую, ну и конечно, из-за сумасшедшего масштаба (по сути, вся планета).
Можно два тупых вопроса?
Почему приложение камеры в телефоне в рамках модели ухудшается с каждым обновлением? Наблюдал на мейзу, мотороле и ванплюсе по мере смены телефона. Типа ядро обновляется, и вендору просто лень писать новые драйверы на уровне старой функциональности?
Как вы оцениваете будущую динамику деятельности сообществ по подготовке неоффициальных прошивок, особенно для старой техники? Я так понимаю, для новых изделий FIDL облегчает переносы драйверов плюс сокращается количество оболочек плюс легче вырезать сервисы гугла из-за открытости платформы. А для старых устройств нас ждет ренессанс реинкарнаций или ничего особо не изменится, потому что для старых компонентов не будут переписывать драйвера, как минимум, нативно под фуксию?
Скрытый текст
Как исполнитель, я тоже голосую за канбан. Но все остальные размышления довольны размыты и наивны. Из разряда "у тебя не будет плохих метрик, если у тебя изначально нет метрик")
Как или в чем оценить реальную пользу? Если чисто на словах, договоренностях и убеждении, то будущее таких компаний меня пугает. Из-за того, что в менеджмент просачиваются личности, умеющие красиво говорить и профессионально высасывать деньги из работодателя, разрушая при этом все - атмосферу в коллективе, эффективность работы и технологичность автоматизации.
В общем, чтобы воплотиться в жизнь, озвученные принципы требуют очень высокой осознанности и ответственности от каждого участника процесса. И даже, в каком-то смысле, это шаг в строну плоских горизонтальных структур управления. Строгая иерархия гораздо более привычна/понятна и гораздо более распространена, и она как раз требует таких же организованных в иерархию метрик. Хотя бы чтобы ими можно было управлять иерархическими же подходами.
Для рекламы курсов в канале как-то нашли возможность. Думаю, и с примерами можно выкрутиться.
Другой момент, что пример из демонстрации не показательный. Интеграция 1С с UDS уже есть в интернете, плюс еще 60 других с иными системами. Во-первых, нейросеть могла на них учиться, и результат ее работы ближе к повторению, чем к изобретению через анализ. Во-вторых, зачем писать интеграцию с нуля даже через нейросеть, если она уже есть? Прикрутить подсистему к ERP вместо Розницы легче, чем исправлять галлюцинации.
В видосе опять показан только процесс, без результата. Все заканчивается на паре десятков синтаксических ошибок и обещанием переделать и сделать тесты.
Ок, вы озвучили потребность, показали промпт, спасибо. А где можно посмотреть результат этой интеграции?