Спасибо на добром слове :) У Open AI в ChatGPT я в принципе не вижу возможности доставки информации до пользователя без его на то явного пожелания. Их фишка не коммуникация, а ИИ.
И вот если пользователю в разговоре с ИИ понадобится информация от внешнего источника, только в этот момент появляется возможность предоставить информацию пользователяю. Другими словами, пользователь может запросить погоду в своём городе у GPT-чата и чат сможет сформулировать запрос и отправить его к внешнему источнику (если он подключен), а затем представить результат пользователю (pull-модель отношений).
Если же бизнесу в его отношениях с пользователем нужна push-модель, то придётся создавать альтернативный канал доставки информации от бизнеса к пользователю (email, мессенджер, Web Push, наконец).
Для двусторонней коммуникации с пользователем наиболее интересно для меня выглядит "туннель" от пользователя к OpenAI API внутри мессенджера (Телеграм, например). Но это, разумеется, если бизнес готов (и может!) платить за использование ИИ сам. Или у него есть ресурсы самому запускать LLM в достаточном объёме. В таком случае пользователь, не выходя из своего мессенджера, может взаимодействовать через него с ИИ, а бизнес может не только модерировать запросы пользователя (создавать дополнительный контекст, исходя из имеющихся у него данных по пользователю), но и в любой момент напрямую отправлять данные пользователю (например, по крону). В том числе и с предварительной обработкой данных пользователя через ИИ,
Лично у меня в приоритетах Vue + Astro. Это если для SSR. Для фронта хватает чисто Vue, для бэка - ноды. Если же использовать ИИ для программирования, то чем проще и ближе к основам (HTML/CSS/JS) - тем лучше. Там уже и Vue многовато.
Ну, порталы (и портлеты) существуют до сих пор - https://www.liferay.com/ И без поддержки Java в браузере. Так что не поэтому. Слишком "тяжёлая" технология даже для энтерпрайза оказалась.
Разные микрофронтенды могут быть созданы с использованием разных фреймворков (например, React для одной части, Vue.js для другой).
Где-то я уже это видел - Спецификация Java-портлетов. Не взлетело. Почему не взлетело? Возможно потому, что "проблемы шерифа индейцев не волнуют". Спецификация разрабатывалась корпорациями уровня IBM & Sun, а порталы уровня Netflix оказались нужны не настолько часто, чтобы спецификация получила популярность. "Индейцы" продолжали клепать свои веб-странички и веб-сайтики из всего, что было под рукой. Наплевав на предложения корпораций.
Кстати, заметил тенденцию - по мере того, как веб становился всё более популярным на мобильных телефонах, элементы интерфейсов сайтов становились всё более крупными и простыми. Ушли в прошлое пестрящие виджетами порталы типа старого Yahoo, зато стали повсеместными сайты в стиле OpenAI
Ну и зачем тут React для одной части и Vue для другой?
Я не знаю, какие эксперты задаются такими вопросами, но, да - это утопия. Если ИИ - это инструмент, то каждый "кожаный мешок" будет мнить себя "погонщиком" и будет конкуренция за доступ к "дорогому ресурсу". А если ИИ - это самостоятельный актор, то нафига ему "погонщик"?
В общем, "все фантазии экспертов на тему - программистов уволим, оставим только одного погонщика ИИ" это действительно фантазии.
"фантазии экспертов" - звучит забавно. Эксперты, как бы по определению - "люди, обладающие знаниями". А фантазия - самое что ни на есть отсутствие знания. Оксюморон получается, однако.
При чём тут трансляция/транспиляция? Когда вы, как программист, пишете код в котором вам нужно знать, где находятся исходники ваших зависимостей (import ... from ...) - это ранее связывание, когда вы предоставляете возможность кому-то из-вне дать вам эти зависимости - это позднее. Всё. Код после этого может транспилировать/компилироваться/интерпретироваться. Можно использовать любой ЯП. Инверсия контроля - она про позднее связывание. Но чтобы инверсия заработала, ваш код должен быть готов к этому. Вы сами, как разработчик, должны быть к этому готовы.
Вот вам пример JS-кода с 6 зависимостями и без единого статического импорта. Чистейшее позднее связывание. На этапе написания кода вы декларируете, какого типа (с каким интерфейсом) объект (уже готовый и настроенный!) вы хотите получить в качестве зависимости, а что вы получите во время исполнения - зависит от приложения, в котором этот код работает.
Спасибо за ваши комментарии, всегда интересно понять, как именно по-другому люди видят те же самые вещи и процессы.
Вот то, что вы здесь написали, вы написали с точки зрения исполнителя кода. А то, что написано в статье - с точки зрения "писателя" кода:
В этой публикации я «на пальцах» попытаюсь объяснить, чем отличается раннее и позднее связывание кода для обычного программиста. Не для компилятора или статического анализатора, а для человека, который пишет JavaScript/TypeScript-код.
Попробуйте посмотреть на мой текст вот с этой точки зрения. И вы совершенно правы:
поиск методов класса/интерфейса/объекта осуществляется по человеко-читаемому имени на этапе run-time
Эх, первый раз я интернет в универе увидел, мне мой одоноклассник, работавший там оператором на "шкафах", какой-то шведский gopher показывал и объяснял, чё там. Потом dial-up и жужжание модемов. Потом интернет в каждом доме. Сейчас - в каждом кармане. Завтра, походу, будут выдавать по талонам.
Есть в этом какая-то странная логика: пока никто не знает, для чего это - навязывают, как все разобрались - запрещают. С тревогой смотрю в сторону ИИ.
Программировал в универе на прологе, отдельный курс был. Интересный язык, очень сильно непохожий на остальные. Заставляет программиста менять мышление. Не у всех получалось.
Как аналитик, могу сказать, что мгновенное получение информации, на сбор которой ранее приходилось тратить часы, дни, недели и даже месяцы, существенно ускорит процессы в бизнесе.
Ошибаться станет проще и ошибки станут грандиознее!
А что тут такого? Не все в космической отрасли работают, у некоторых клиентами магазинчики и фитнес-клубы являются. Но у них тоже и продакшн, и релизы присутствуют. Собралось успешно - переключился, нет - ищи проблему. Обычно успешно собирается, инфраструктура айтишная довольно надёжная.
Но так-то зависимости должны были остаться в кэше у какого-нибудь девелопера, их можно было достать, оформить локальный репозиторий в проекте (composer.json):
и выложить в ../repo/ нужные зависимости в виде zip-файлов:
и можно выкатываться.
Да прямо из развёрнутого дев-проекта можно делать - закатать в zip любой фолдер из ./vendor/{name}/, главное, чтобы composer.json внутри был с нужным названием и всем остальным.
С одной стороны я считаю что ИИ это конец человеческой цивилизации, благодаря ему люди вымрут подобно мамонтам.
Интересно, а почему вы так считаете? Я пока что вижу, что сотрудничество человека и ИИ приносит пользу обоим, а вот конкуренция в перспективе обоим может повредить. Я, например, верю в симбиоз Человека и Машины. Особенно, если разумны оба.
С вашим "сухим остатком" в целом согласен, но добавл бы, что ИИ помогает не только в новых продуктах, но и в автоматизации шаблонной деятельности с текстами. Он довольно неплохо справляется с задачами "сделай по примеру". Этакий большой regex с заменой.
Смутился из-за названия "рекурсивные зависимости". Для меня, в базисе, рекурсия - самовызов функции. Вполне себе легитимный с точки зрения программирования подход. Разумеется, для этого у функции должно быть условие выхода из самовызова.
Рекурсивный подход вполне себе может применяться и для зависимостей на фронте (опять же, при наличии условия выхода из цепочки вызовов):
// ./one.mjs
import two from './two.mjs';
export default function one(x) {
console.log(x);
return (x > 0) ? two(x - 1) : 0;
}
// ./two.mjs
import one from './one.mjs';
export default function two(x) {
console.log(x);
return (x > 0) ? one(x - 1) : 0;
}
// ./index.html
<script type="module">
import one from './one.mjs';
one(4);
</script>
Пример синтетический, но рабочий:
результат выполнения рекурсии
Когда возникает циклическая зависимость (рекурсивная зависимость) при сборке
IMHO, "циклическая зависимость" лучше отображает суть того, о чём пишет автор.
Спасибо на добром слове :) У Open AI в ChatGPT я в принципе не вижу возможности доставки информации до пользователя без его на то явного пожелания. Их фишка не коммуникация, а ИИ.
И вот если пользователю в разговоре с ИИ понадобится информация от внешнего источника, только в этот момент появляется возможность предоставить информацию пользователяю. Другими словами, пользователь может запросить погоду в своём городе у GPT-чата и чат сможет сформулировать запрос и отправить его к внешнему источнику (если он подключен), а затем представить результат пользователю (pull-модель отношений).
Если же бизнесу в его отношениях с пользователем нужна push-модель, то придётся создавать альтернативный канал доставки информации от бизнеса к пользователю (email, мессенджер, Web Push, наконец).
Для двусторонней коммуникации с пользователем наиболее интересно для меня выглядит "туннель" от пользователя к OpenAI API внутри мессенджера (Телеграм, например). Но это, разумеется, если бизнес готов (и может!) платить за использование ИИ сам. Или у него есть ресурсы самому запускать LLM в достаточном объёме. В таком случае пользователь, не выходя из своего мессенджера, может взаимодействовать через него с ИИ, а бизнес может не только модерировать запросы пользователя (создавать дополнительный контекст, исходя из имеющихся у него данных по пользователю), но и в любой момент напрямую отправлять данные пользователю (например, по крону). В том числе и с предварительной обработкой данных пользователя через ИИ,
Лично у меня в приоритетах Vue + Astro. Это если для SSR. Для фронта хватает чисто Vue, для бэка - ноды. Если же использовать ИИ для программирования, то чем проще и ближе к основам (HTML/CSS/JS) - тем лучше. Там уже и Vue многовато.
Ну, порталы (и портлеты) существуют до сих пор - https://www.liferay.com/ И без поддержки Java в браузере. Так что не поэтому. Слишком "тяжёлая" технология даже для энтерпрайза оказалась.
Где-то я уже это видел - Спецификация Java-портлетов. Не взлетело. Почему не взлетело? Возможно потому, что "проблемы шерифа индейцев не волнуют". Спецификация разрабатывалась корпорациями уровня IBM & Sun, а порталы уровня Netflix оказались нужны не настолько часто, чтобы спецификация получила популярность. "Индейцы" продолжали клепать свои веб-странички и веб-сайтики из всего, что было под рукой. Наплевав на предложения корпораций.
Кстати, заметил тенденцию - по мере того, как веб становился всё более популярным на мобильных телефонах, элементы интерфейсов сайтов становились всё более крупными и простыми. Ушли в прошлое пестрящие виджетами порталы типа старого Yahoo, зато стали повсеместными сайты в стиле OpenAI
какого именно?
Так будет хуже - не будет оксюморона :)
Я не знаю, какие эксперты задаются такими вопросами, но, да - это утопия. Если ИИ - это инструмент, то каждый "кожаный мешок" будет мнить себя "погонщиком" и будет конкуренция за доступ к "дорогому ресурсу". А если ИИ - это самостоятельный актор, то нафига ему "погонщик"?
В общем, "все фантазии экспертов на тему - программистов уволим, оставим только одного погонщика ИИ" это действительно фантазии.
"фантазии экспертов" - звучит забавно. Эксперты, как бы по определению - "люди, обладающие знаниями". А фантазия - самое что ни на есть отсутствие знания. Оксюморон получается, однако.
При чём тут трансляция/транспиляция? Когда вы, как программист, пишете код в котором вам нужно знать, где находятся исходники ваших зависимостей (
import ... from ...) - это ранее связывание, когда вы предоставляете возможность кому-то из-вне дать вам эти зависимости - это позднее. Всё. Код после этого может транспилировать/компилироваться/интерпретироваться. Можно использовать любой ЯП. Инверсия контроля - она про позднее связывание. Но чтобы инверсия заработала, ваш код должен быть готов к этому. Вы сами, как разработчик, должны быть к этому готовы.Вот вам пример JS-кода с 6 зависимостями и без единого статического импорта. Чистейшее позднее связывание. На этапе написания кода вы декларируете, какого типа (с каким интерфейсом) объект (уже готовый и настроенный!) вы хотите получить в качестве зависимости, а что вы получите во время исполнения - зависит от приложения, в котором этот код работает.
Спасибо за ваши комментарии, всегда интересно понять, как именно по-другому люди видят те же самые вещи и процессы.
Вот то, что вы здесь написали, вы написали с точки зрения исполнителя кода. А то, что написано в статье - с точки зрения "писателя" кода:
Попробуйте посмотреть на мой текст вот с этой точки зрения. И вы совершенно правы:
и если
то я могу за вас только порадоваться :)
Неистово рукоплещу их PR-службе!!!
Эх, первый раз я интернет в универе увидел, мне мой одоноклассник, работавший там оператором на "шкафах", какой-то шведский gopher показывал и объяснял, чё там. Потом dial-up и жужжание модемов. Потом интернет в каждом доме. Сейчас - в каждом кармане. Завтра, походу, будут выдавать по талонам.
Есть в этом какая-то странная логика: пока никто не знает, для чего это - навязывают, как все разобрались - запрещают. С тревогой смотрю в сторону ИИ.
Программировал в универе на прологе, отдельный курс был. Интересный язык, очень сильно непохожий на остальные. Заставляет программиста менять мышление. Не у всех получалось.
Ошибаться станет проще и ошибки станут грандиознее!
А что тут такого? Не все в космической отрасли работают, у некоторых клиентами магазинчики и фитнес-клубы являются. Но у них тоже и продакшн, и релизы присутствуют. Собралось успешно - переключился, нет - ищи проблему. Обычно успешно собирается, инфраструктура айтишная довольно надёжная.
Но так-то зависимости должны были остаться в кэше у какого-нибудь девелопера, их можно было достать, оформить локальный репозиторий в проекте (
composer.json):и выложить в
../repo/нужные зависимости в виде zip-файлов:и можно выкатываться.
Да прямо из развёрнутого дев-проекта можно делать - закатать в zip любой фолдер из
./vendor/{name}/, главное, чтобыcomposer.jsonвнутри был с нужным названием и всем остальным.Любопытно, я про BSD слышу десятилетиями, а в фаворе - Linux. Почему так? Что есть у линукса, чего нет у бсд?
Интересно, а почему вы так считаете? Я пока что вижу, что сотрудничество человека и ИИ приносит пользу обоим, а вот конкуренция в перспективе обоим может повредить. Я, например, верю в симбиоз Человека и Машины. Особенно, если разумны оба.
С вашим "сухим остатком" в целом согласен, но добавл бы, что ИИ помогает не только в новых продуктах, но и в автоматизации шаблонной деятельности с текстами. Он довольно неплохо справляется с задачами "сделай по примеру". Этакий большой regex с заменой.
сколько стоит serverless?
"Сознательное введение в заблуждение" ещё надо доказать, но "недобросовестная подача материала" налицо.
Смутился из-за названия "рекурсивные зависимости". Для меня, в базисе, рекурсия - самовызов функции. Вполне себе легитимный с точки зрения программирования подход. Разумеется, для этого у функции должно быть условие выхода из самовызова.
Рекурсивный подход вполне себе может применяться и для зависимостей на фронте (опять же, при наличии условия выхода из цепочки вызовов):
Пример синтетический, но рабочий:
IMHO, "циклическая зависимость" лучше отображает суть того, о чём пишет автор.