Не уверен, буду ли я пользоваться этой библиотекой. Но могу накидать потенциальные идеи (не факт, что надо их делать, чисто мой опыт). Вот примерно такие задачи ещё часто приходится решать чем-то самописным:
Конфиг в разных файлах (и иногда файлы разных форматов) и их надо слить с учетом приоретизации. В принципе, если сработает config = Config("config.yml", Config(".env")), то окей.
Конфиг часто надо тестить, что указаны все нужные ключи с нужными типами (схема данных, где описаны ключи и типы).
safe_get(response, ["page", 3, "cation"], "Default Caption"), когда надо вытащить response.page[3]["caption"] и не хочется проверять что есть весь путь (чтобы не падало в момент response.page[3]).
менять размер кеша и ttl в процессе работы, сохранять/загружать его.
Как DateTimeUtils.date_difference и операторы сравнения работают с разными часовыми поясами?
Поиск внутри сложных вложенных структур, наподобе ключа словаря, который в списке словарей. Или элемент списка, который в словаре, который в списке словарей.
Хорошая аналогия с тропинками, и как раз функцией можно заменить прыжок назад. Я не помню, читал это или пришел сам, но суть такая:
У нас блок кода, мы можем прыгнуть назад на него через goto. А можем вынести этот блок в функцию и вызвать её несколько раз. Пример без смысла, но с пояснением идеи (если что, это псевдоязык у нас, допустим, пародия на javascript)
label1:
a = b + c
c = a + b
if( c < 3 ) { goto label1 }
Тут получается блок, который можно представить через функцию или через while или всем одновременно.
function do_sum( a, b, c ) { a = b + c c = a + b return [a, b, c] }
do { a, b, c = do_sum( a, b, c ) } while ( c < 3 )
С пересекающимися блоками бывают сложности, но обычно лучше посидеть и подумать, как их сделать непересекающимися, а потом распилить на циклы и функции.
Да, все верно, когда я писал комментарий выше - я учитывал, что goto сейчас во многих языках можно ставить достаточно ограниченно. Но это по-прежнему путает логику, особенно в комбинации с if. И я ссылался не на Дейкстру, а на собственный опыт писания, например, на ассемблере. Достаточно быстро понимаешь, зачем логика делится на блоки и почему почти всегда goto можно и нужно менять на вызов функции, в которую выносится участок кода.
goto не любят, потому что от него можно прыгнуть куда угодно по логике. И ситуация сильно ухудшается, если эти goto расставлены в нескольких местах и становятся перекрестными. Сравнивать throw с goto некорректно, так как throw явно ведёт либо вниз по коду, либо на какой-то уровень выше, то есть throw в этом смысле более линеен и предсказуем. Собственно, поэтому он и сделан: если есть большая вложенность и надо резко выпрыгнуть, минуя какую-то логику, которую, допустим, писали не вы. Да, его не нужно использовать часто, это обработчик специфических ситуаций и я тоже предпочитаю чаще использовать return, но это не всегда оправдано.
Вообще, я напомню, throw вводился для отделения логики работы от логики обработки ошибок. Т.е. в теории с ним более чистый код.
если сравнивать именно с гугл таблицами - в гугл таблицах вы автоматически получаете возможность редактировать эту таблицу без каких-либо дополнительных инструментов и делиться ей для чтения/редактирования с другими. Дополнительно, это снижает порог входа для редактирования: большинство людей уже знакомы с гугл таблицами. Плюс куча встроенных в гугл таблицы инструментов, включая импорт/экспорт и аналитику.
Если же сравнивать SQLite с другими базами, главный минус - плохо работает с множественным доступом. Сервер на, условно, 10 человек - в принципе окей. А вот больше уже вопросики при попытке пользоваться одновременно.
Выглядит больше как маркетинг, чем как действительно уникальный инструмент. Сейчас все компании делают подобные среды разработки агентов, и OpenAI одна из них, которая ничем особо не выделяется, ну кроме сильной привязки решения к своим моделям.
Долго поискав, из необычного разве что Guardrails вызывает интерес - это не новое, но редкое в подобных системах.
По сути это очень похоже на рассуждающую o1, только у этой контекст каждый раз новый, а память от старого. Я думаю именно поэтому их последняя gemini так хороша в рассуждениях.
Ждем следующую итерацию, когда они догадаются весь контекст несколько раз прокручивать, чтобы снизить деградацию памяти.
Вопрос к методологии остался. Про разбивание на куски все понятно. Непонятно, в какой момент эти куски интегрируются. И что делать, если надо писать что-то, что затронет сразу несколько разных модулей? Какой у вас в этом опыт?
Это, конечно, не суть статьи, но хочется прокомментировать "Программисты, которые учатся кодить с применением LLM, — не учатся кодить, они учатся подбирать промты которые дают результат, решающий задачу.". До ЛЛМ все точно так же искали куски кода на стекоферфлоу. Если нужен какой-то хитрый алгоритм - гуглишь его, а не пытаешься сам придумать, потому что это тупо быстрее. Если потом есть желание - можно посидеть разобраться, как он работает. Но и сейчас никто не мешает самому разобраться в коде ЛЛМ или попросить её пояснить. Да, случаются галлюцинации, но и гуглеж далеко не всегда дает оптимальное решение. В общем, не понимаю я снобов, которые подобное говорят.
В расследовании главное не выйти на самого себя "Работа сети оперативно восстановлена дежурными службами" - и ведь не поспоришь, можно самому сломать, а потом вернуть как было. Сказать, что починил.
Можно класть бумажные предложения скидок в коробку вместе с товаром под видом подарков. И уже там указывать свой сайт. Такое отловят только контрольной закупкой, если вообще захотят возиться. Плюс, хоть это и хуже помогает, вместо ссылки можно свой бренд указывать, который легко гуглится и ведет на нужный сайт.
Сейчас основная проблема в излишней многословности и том, что ллм не могут хорошо структурировать знания. Т.е. на выходе там обычно много красивого, но не слишком глубокого и информативного текста. Ну и галлюцинирование может стать большой проблемой в будущем
Их просто не учили писать стихи. Я почти уверен, что если есть такая задача - можно скормить тонну стихов в трансформер и получить стихоплета. Только это никому не надо. Из интересного - на английском "стихи" у ллм обычно выходят лучше, чем на русском, даже иногда с рифмой. Видимо, сказывается, что это основной язык.
И еще, есть знаменитая проблема с вопросом "сколько букв в слове strawberry", которая явно показывает, что ЛЛМ плохо умеет в низкоуровневую грамматику, скорее всего, потому что оперирует перекодированными токенами. Я думаю, на стихах это тоже отражается.
PS пока писал коммент, стало интересно, можно ли научить gpt писать стихи, если в чате объяснить ему рифмование и звучание слогов.
Какая-то экономическая модель под эту деятельность есть? Я имею в виду, ну вот будет РН. Дальше - продавать запуски? А кто клиенты? Мелкие спутники сейчас выводятся как попутная нагрузка. Либо их можно вывести сразу пачкой, и одна большая РН будет мне кажется выгоднее нескольких мелких.
Интересно так же послушать мнение про возвращаемость: насколько нужно и получится ли потом к этому прийти (хотя бы в теории).
Не сочтите за критику, это скорее вопросы, я уважаю ваше безумие. Возможно, мои вопросы тянут на отдельную статью, тогда пусть этот коммент будет предложением такой темы.
Спасибо за статью, не знал о таком интересном инструменте. У меня давно есть вопросы, возможно, у вас есть ответы. Подобные языки для доказательства теорем очень напоминают правила построения грамматик. Кто-то как-то исследовал взаимосвязь грамматических правил и доказательство теорем? И, более широкий вопрос: кто-то исследовал грамматики для построения описания научных правил и законов?
Как по мне, дело не в методиках как таковых, а в деталях их применения. Скрам уместно применять, если стоит цель хоть как-нибудь (даже костылями) закрыть задачу и потом улучшать то, что натворили (по сути, путь mvp). В таком случае, конечно, нет смысла спрашивать исполнителя за качество и пытаться выжать из него все соки. Либо, как второй вариант, накидывают теоретический максимум задач, а решается только, сколько успели, без претензий к исполнителям. Такое тоже не всем подходит, но если нет критически важных взаимозависимых задач - работает. Оба варианта не работают, если в это влезает менеджер, который пытается оценить качество и количество закрытых задач, как раз потому что скрам не про это. Из описанного понятно, что скрам - это про работу маленькой команды или стратапа.
Не уверен, буду ли я пользоваться этой библиотекой. Но могу накидать потенциальные идеи (не факт, что надо их делать, чисто мой опыт).
Вот примерно такие задачи ещё часто приходится решать чем-то самописным:
Конфиг в разных файлах (и иногда файлы разных форматов) и их надо слить с учетом приоретизации. В принципе, если сработает config = Config("config.yml", Config(".env")), то окей.
Конфиг часто надо тестить, что указаны все нужные ключи с нужными типами (схема данных, где описаны ключи и типы).
safe_get(response, ["page", 3, "cation"], "Default Caption"), когда надо вытащить response.page[3]["caption"] и не хочется проверять что есть весь путь (чтобы не падало в момент response.page[3]).
менять размер кеша и ttl в процессе работы, сохранять/загружать его.
Как DateTimeUtils.date_difference и операторы сравнения работают с разными часовыми поясами?
Поиск внутри сложных вложенных структур, наподобе ключа словаря, который в списке словарей. Или элемент списка, который в словаре, который в списке словарей.
Хорошая аналогия с тропинками, и как раз функцией можно заменить прыжок назад. Я не помню, читал это или пришел сам, но суть такая:
У нас блок кода, мы можем прыгнуть назад на него через goto. А можем вынести этот блок в функцию и вызвать её несколько раз. Пример без смысла, но с пояснением идеи
(если что, это псевдоязык у нас, допустим, пародия на javascript)
label1:a = b + cc = a + bif( c < 3 ) {goto label1
}
Тут получается блок, который можно представить через функцию или через while или всем одновременно.
function do_sum( a, b, c ) {a = b + c
c = a + b
return [a, b, c]
}
do {a, b, c = do_sum( a, b, c )
} while ( c < 3 )
С пересекающимися блоками бывают сложности, но обычно лучше посидеть и подумать, как их сделать непересекающимися, а потом распилить на циклы и функции.
Да, все верно, когда я писал комментарий выше - я учитывал, что goto сейчас во многих языках можно ставить достаточно ограниченно. Но это по-прежнему путает логику, особенно в комбинации с if. И я ссылался не на Дейкстру, а на собственный опыт писания, например, на ассемблере. Достаточно быстро понимаешь, зачем логика делится на блоки и почему почти всегда goto можно и нужно менять на вызов функции, в которую выносится участок кода.
goto не любят, потому что от него можно прыгнуть куда угодно по логике. И ситуация сильно ухудшается, если эти goto расставлены в нескольких местах и становятся перекрестными. Сравнивать throw с goto некорректно, так как throw явно ведёт либо вниз по коду, либо на какой-то уровень выше, то есть throw в этом смысле более линеен и предсказуем. Собственно, поэтому он и сделан: если есть большая вложенность и надо резко выпрыгнуть, минуя какую-то логику, которую, допустим, писали не вы. Да, его не нужно использовать часто, это обработчик специфических ситуаций и я тоже предпочитаю чаще использовать return, но это не всегда оправдано.
Вообще, я напомню, throw вводился для отделения логики работы от логики обработки ошибок. Т.е. в теории с ним более чистый код.
если сравнивать именно с гугл таблицами - в гугл таблицах вы автоматически получаете возможность редактировать эту таблицу без каких-либо дополнительных инструментов и делиться ей для чтения/редактирования с другими. Дополнительно, это снижает порог входа для редактирования: большинство людей уже знакомы с гугл таблицами. Плюс куча встроенных в гугл таблицы инструментов, включая импорт/экспорт и аналитику.
Если же сравнивать SQLite с другими базами, главный минус - плохо работает с множественным доступом. Сервер на, условно, 10 человек - в принципе окей. А вот больше уже вопросики при попытке пользоваться одновременно.
Выглядит больше как маркетинг, чем как действительно уникальный инструмент. Сейчас все компании делают подобные среды разработки агентов, и OpenAI одна из них, которая ничем особо не выделяется, ну кроме сильной привязки решения к своим моделям.
Долго поискав, из необычного разве что Guardrails вызывает интерес - это не новое, но редкое в подобных системах.
Когда плюсуешь такую статью, испытываешь смешанные чувства
По сути это очень похоже на рассуждающую o1, только у этой контекст каждый раз новый, а память от старого. Я думаю именно поэтому их последняя gemini так хороша в рассуждениях.
Ждем следующую итерацию, когда они догадаются весь контекст несколько раз прокручивать, чтобы снизить деградацию памяти.
Вопрос к методологии остался. Про разбивание на куски все понятно. Непонятно, в какой момент эти куски интегрируются. И что делать, если надо писать что-то, что затронет сразу несколько разных модулей? Какой у вас в этом опыт?
Это, конечно, не суть статьи, но хочется прокомментировать "Программисты, которые учатся кодить с применением LLM, — не учатся кодить, они учатся подбирать промты которые дают результат, решающий задачу.". До ЛЛМ все точно так же искали куски кода на стекоферфлоу. Если нужен какой-то хитрый алгоритм - гуглишь его, а не пытаешься сам придумать, потому что это тупо быстрее. Если потом есть желание - можно посидеть разобраться, как он работает. Но и сейчас никто не мешает самому разобраться в коде ЛЛМ или попросить её пояснить. Да, случаются галлюцинации, но и гуглеж далеко не всегда дает оптимальное решение. В общем, не понимаю я снобов, которые подобное говорят.
В расследовании главное не выйти на самого себя
"Работа сети оперативно восстановлена дежурными службами" - и ведь не поспоришь, можно самому сломать, а потом вернуть как было. Сказать, что починил.
Можно класть бумажные предложения скидок в коробку вместе с товаром под видом подарков. И уже там указывать свой сайт. Такое отловят только контрольной закупкой, если вообще захотят возиться. Плюс, хоть это и хуже помогает, вместо ссылки можно свой бренд указывать, который легко гуглится и ведет на нужный сайт.
Сейчас основная проблема в излишней многословности и том, что ллм не могут хорошо структурировать знания. Т.е. на выходе там обычно много красивого, но не слишком глубокого и информативного текста. Ну и галлюцинирование может стать большой проблемой в будущем
Их просто не учили писать стихи. Я почти уверен, что если есть такая задача - можно скормить тонну стихов в трансформер и получить стихоплета. Только это никому не надо. Из интересного - на английском "стихи" у ллм обычно выходят лучше, чем на русском, даже иногда с рифмой. Видимо, сказывается, что это основной язык.
И еще, есть знаменитая проблема с вопросом "сколько букв в слове strawberry", которая явно показывает, что ЛЛМ плохо умеет в низкоуровневую грамматику, скорее всего, потому что оперирует перекодированными токенами. Я думаю, на стихах это тоже отражается.
PS пока писал коммент, стало интересно, можно ли научить gpt писать стихи, если в чате объяснить ему рифмование и звучание слогов.
Какая-то экономическая модель под эту деятельность есть? Я имею в виду, ну вот будет РН. Дальше - продавать запуски? А кто клиенты? Мелкие спутники сейчас выводятся как попутная нагрузка. Либо их можно вывести сразу пачкой, и одна большая РН будет мне кажется выгоднее нескольких мелких.
Интересно так же послушать мнение про возвращаемость: насколько нужно и получится ли потом к этому прийти (хотя бы в теории).
Не сочтите за критику, это скорее вопросы, я уважаю ваше безумие. Возможно, мои вопросы тянут на отдельную статью, тогда пусть этот коммент будет предложением такой темы.
Про RandomForrest можно подробнее? Что там на вход подается и подготавливаются ли как-то данные?
В генерации изображений у вас как-то слабо все. Можно конечно сослаться на субъективщину, но Flux, по мнению многих, лучший генератор картинок.
Спасибо за статью, не знал о таком интересном инструменте. У меня давно есть вопросы, возможно, у вас есть ответы. Подобные языки для доказательства теорем очень напоминают правила построения грамматик. Кто-то как-то исследовал взаимосвязь грамматических правил и доказательство теорем? И, более широкий вопрос: кто-то исследовал грамматики для построения описания научных правил и законов?
Как по мне, дело не в методиках как таковых, а в деталях их применения. Скрам уместно применять, если стоит цель хоть как-нибудь (даже костылями) закрыть задачу и потом улучшать то, что натворили (по сути, путь mvp). В таком случае, конечно, нет смысла спрашивать исполнителя за качество и пытаться выжать из него все соки. Либо, как второй вариант, накидывают теоретический максимум задач, а решается только, сколько успели, без претензий к исполнителям. Такое тоже не всем подходит, но если нет критически важных взаимозависимых задач - работает. Оба варианта не работают, если в это влезает менеджер, который пытается оценить качество и количество закрытых задач, как раз потому что скрам не про это. Из описанного понятно, что скрам - это про работу маленькой команды или стратапа.