Посмотрите на всю земную биомассу. Она огномна и ухитряется жить пол миллиарда лет не расходуя ресурсы. Не существует физических ограничений, которые мешали бы благополучно жить на земле десяткам миллиардов человек. Вопрос только в технологиях, которые были бы настолько хороши, чтобы полностью замкнуть цикл и не требовать чего-то невозобновляемого (как это сделала биосфера). Источником энергии как и для биосферы в конецном итоге будет солнце. Не забываем так же про временный вариант, позволяющий отложить апокалипсис - атомные электростанции.
Проблема только в том, чтобы эти технологии поспевали вовремя за ростом населения и тогда катаклизмов удасться избежать.
Как раз реальные законы физики обратимы в том смысле, что информация не теряется и работают законы сохранения.
Второе начало термодинамики в обтатимом автомате точно так же соблюдается - все упорядоченное становится хаотичным, хотя если запустить в обратную сторону то упорядочится обратно.
Правила криттеров не сильно сложнее чем правила жизни и контента там тоже возможно может быть много.
Если ИИ делает раблту за людей это хорошо. Это значит люди могут не работать или делать что им нравится. Проблема по каким критериям распределить блага когда нико не работает она есть но это новая проблема а не старая проблема нищеты и безрабоьицы. Важно не путать.
Существует еще один похожий на жизнь клеточный автомат - critters cellular automaton.
По-моему он сильно обделен вниманием. Его отличие от Life заключается в том, что он обратимый и имеет законы сохранения, чем напоминает реальную физику частиц.
Сидя без работы я как-то начал проект по его исследованию. Пока проект так и лежит здесь:
Программист сейчас по моим ощущениям похож на профессионального пианиста.
Если изучил ноты (язык программирования), и теорию, значит молодец, но для работы это пока вообще не о чем. Если нет слуха, тоже ничего хорошего не получиться.
Раньше часто для работы хватало нот, природного слуха и навыка как-то сыграть (сам так работал). Теперь такое не прокатывает, нужно играть и играть по 8 часов в день разные произведения все более сложные на протяжении долгих лет и тогда становится настоящим музыкантом (в смысле - программистом). Дали исполнить новое произведение - не проблема, мозг оточен и усвоит его быстро, будет играть профессионально.
Тот кто собирается войти в айти должен осознавать эту ассоциацию. Ему предстоит не просто понять ноты белые-черные клавиши и педали. Нужно играть и играть пока игра не потянет на концертную а кнопки не начнет нажимать подсознание.
Фреймворки, концепции, парретрны должны бежать перед вашими глазами как знакомые страницы с нотами, которые все разные но на самом деле довольно схожи и пониматься интуитивно как это получается у крутого музыканта.
Второй обзац вашего сообщения объясняет противоречие, высказанное в первом - почему бизнес борется с безработицей, хотя это не в его интересах. Потому что так получается по логике развития технологий.
В ответ оно старательно подготовит текст который похож на текст компьютера, жедающего захватить мир. Но при этом никакой воли к исполнению у него быть не может.
Ну вот может CharGPT скомпоновать рабочее решение задачи из миллиона похожих увиденных. И что? Сколько у него желания захватить мир? Он делает в точности то для чего его обучали и ничего другого.
Так уж люди устроены. Например, они тысячелетиями верили, например, что если молиться каждый день и ходить в церковь, это поможет решить в том числе и материальные проблемы.
Теперь целая отрасль верит что определенные вещи эффективны потому что все их применяют а не потому что есть доказательства их эффективности. Микросервисы (когда они становятся действительно "микро") возможно одна из таких легенд.
Но в целом это работает. А главное - это способ победы над безработицей. Когда сложную задачу решает 3 гения, остальным нечего делать. Это дешево не не стабильно. Когда ее же решают опять эти три гения, но которые не имеют право все закодить сами, а вместо этого у них в подчинении 100 не-гениев, это дороже, но стабильнее. И у всех есть работа.
Можно взять, например фреймворк, в котором достаточно добавить поле в один класс и оно сразу будет доступно в браузере без пяти маперов и промежуточных перекладываний. Можно истребить все разнообразные инструменты и оставить один для каждой цели.
Но к счастью или к несчастью, по этому пути мы не идем. Вместо этого в каждом проекте нужно 100 обезьян, которые будут кропотливо изучать документацию по каждому инструменту, который решили использовать, а потом писать кучу кода по перекладыванию данных. Зато этот процесс гибкий, масштабируемый и у всех есть работа...
Я тут не вижу связи. Это модель котора получила на входе огромный массив данных и училась его интерполировать. То что этот массив был тектом не означает, что она может логически рассуждать о тексте. Скорее всего в обучающих текстах были задачи типа найти n-ю букву слова в достаточном количестве, чтобы сеть научилась генерировать их решения. И это удивительно, так как вряд ли этих задач было настолько много, чтобы тупо подбирать решение под задачу. Как ей удается скомпоновать решение на задачу которую именно в таком виде она не видела и насколько далеко заходит эта способность - для меня загадка.
Это как в анекдоте про собаку, которая играла в шахматы, но удивляться тут было нечему, потому что она всегда проигрывала.
Собственно то что сеть которая просто обучалась способна в полвине случаев выдавать логически связанные ответы, это выглядит как прорыв. Внутри сети само по себе сформировалось нечто похожее на логику, это удивительно.
Я пробовал сказать ей свое имя и имя моего сына, а потом спросить одинаковы ли первые буквы наших имен. Справилась. Для меня это сильно.
Вы уже написали свои первые 1000 строк кода и сейчас хотите сделать их понятнее, потому что внесение изменений занимает столько-же времени, сколько написать заново, но советы из ООП, SOLID, clean architecture и т.д. непонятны вам.
Если вы написали 1000 строк, думать о том как сделать код легко сопровождаемым рано. Я вот написал наверно не менее пол миллиона и до сих пор не могу понять как ООП и SOLID может мне помочь справиться со сложностью по сравнению с процедурным слилем и god-объектами :). Или могу. Пока не уверен.
По мне, здесь нужно разделять цели.
Первая цель - научиться писать работающий код больше чем с двумя условиями и не тонуть в нем.
Вторая цель - научиться писать код, который выглядит профессионально. То что он будет выглядеть профессионально не означает, что он будет проще. Это будет просто обезьянье подражание профессионализму, но без этого видимого профессионализма и видимой стандартности решений не возьмут на работу.
Третья цель - а как действительно написать простой понятный код для сложных проблем? И тут рецепта как такового нет. Наверно каждый расскажет свой некий путь.
Самая сложная цель - третья.
Начать лучше с того, что простейшим путем борьбы со сложностью является то что раньше называли "структурное программирование", когда общая функция решает задачу и затем она вызывает под-функции, решающие частные задачи и так далее. В самом низу находятся функции, уже работающие непосредственно с данными.
Научившись применять этот стиль мышления, можно двигаться дальше.
При этом есть два направления - от структурного к чисто функциональному стилю и к ООП стилю.
Функциональный стиль начинается с того, что мы перестаем пользоваться глобальными данными по возможности и стараемся писать чистые функции. Это хорошо работает когда нужно реализовать по настоящему сложный алгоритм.
ООП стиль начинается с того, что некая одна функция выполняясь запускает внутри себя другие функции, которые имеют дело с одними и теми же данными. В итоге мы имеем слишком много передаваемых данных и соблазн замкнуть эти алгоримты в некий небольшой изолированный модуль, к котором эти данные будут доступны функциям глобально (объект).
Здесь можно создать объект. При этом по мне, важно помнить, что мы создаем объект как "элемент поведения", а не как данные о неком доменном объекте оснащенные поведением. Второй путь хорош для UI фреймворков (кнопка-объект), может быть для игр, но создает очень много сложностей в других случаях (ИМХО).
Такой объект может создаваться операцией new, отрабатывать и тут же удаляться. Это нормально. В этом случае он мало отличается от функции.
Или объект может быть постоянно существующим в памяти и реагировать на обращения, например как кнопка в UI (правда если это кнопка не в React, где она создается при каждом обновлении экрана по новой).
Дальше, если хочется, то можно попробовать оснасить структуры данных, описывающие доменные объекты поведением. Т.е. ввести не просто объекты как элементы поведения, но объекты соответствующие доменным объектам. Попробуйте, но у меня не разу это ничего не упростило. Тут можно дискутировать.
Описанного выше пройденного пути уже достаточно, чтобы написать в одиночку программу на десятки тыщ строк кода и не увязнуть.
Но что если мы пишем код все вместе большими командами?
В мозгу у человека есть некое интуитивное ощущение универсальности. Если я описываю неккие классы и функции, что я делаю? Решаю конкретную задачи или пишу фреймворк всех времен и народов для решения всего класса подобных задач.
Первое, что нужно уметь, это всегда решая конкретную задачу чуть-чуть писать фреймворк для решения подобных задач, но без фанатизма. Это делает систему более пластичной к будущим изменениям и даже может сделать ее понятнее, если соблюдать баланс.
Второе - это тесты. Когда вы написали программу подумайте, можно ли ее разобрать на части , каждую часть поставить на стенд и испытать абстрактно, выполняет ли она ту логику для которой написано? Если нельзя, это все еще плохой код. Если уже можно, значит теперь мы победили сложность окончательно.
Дальше можно уже подумать про SOLID.
Допустим, мы запихнули в один объект и некую абстрактную логику и обращение к конкретному девайсу. Т.е. нарушили "S". Как теперь ее тестировать? Стенд для испытания этого объекта станет очень сложным и специфичным. А еще непонятным. Делим это на две части и все становится проще. Здесь необходимость тестировать помогает нам осознать важность S.
Допустим, при малейшем изменении задачи нам придется лезть в кишки объекта и все там менять, вместо того чтобы добавить новое поведение не меняя объекта (буква "O")? Это значит в нашем решении было недостаточно "фреймворковости", оно было слишком частным, или это может означать что мы распилили на объекты искусственно, не в том месте как надо (что по сути близко к недостатку "фреймворковости" по сути).
Мы ставим объект на стенд для тестирования и прямо не знаем с чего начать. У него столько методов! Здесь мы нарушили букву "I". На стенде тестируемый интерфейс должен выглядеть предельно просто и понятно - зачем он и как проверить что он это делает. Клиенты у интерфейса могут быть сегодня одни а завтра другие, но если он понятно тестируется, он уже соблюдает I в достаточной мере.
Есть замечательный принцип, использованный природой - каждый ген (а ген это элемент поведения, т.е. объект) вездесущ и активируется по месту в той части программы где он нужен. Значит для изменения программы достаточно добавить до кучи новый ген или подменить существующий. Этот замечательный принцип нужно не упустить и в разработке где возможно. Это "D".
Сейчас у ChatGPT очень короткий "контекст". Поэтому не получится последовательно уточнять детали задачи, как это можно делать с человеком. Долгий контекст сделать я думаю не получится пока, потому что даже для коротких описаний когда задача состоит из нескольких подзадач логика их связывания в половине случаев ломается. Для более длинных задач логика разных подзадач вообще перестанет вязаться. Для того чтобы это заработало в теории обучения должно быть существенно улучшение в направлении построения сетью стратегий решения задач.
Сеть должна как бы последовательно волнами много раз сканировать возможные стратегии решения задачи, дообучаясь по ходу и подбираясь к оптимальному варианту. Такой техники пока как я понимаю нет. Но по субъективным ощущениям мозг как раз делает нечто подобное при решении задач.
Грубо можно считать, что сейчас сеть - это как очень опытный старичок-препод, который не задумываясь может выдать ответ на любой вопрос, потому что его мозг тренирован выдавать определенный выход на привычные входные вопросы. Но старичка можно попросить проснуться из подумать час другой над задачей которую он раньше не видел, проявив креатив в поиске решений. А ИИ пока нельзя пропросить. Он все равно выдаст решение "не приходя в сознание", которое просто логически сшивает то что он уже видел.
Какой смысл бежать из страны, которая угрожает ядерным оружием, в страну, которой угрожают ядерным оружием? По логике должно быть ровно наоборот
Не, здесь речь о том, чтобы бежать из маленькой и незначительной страны с небольшим населением, без технологий, без морали, без здравомыслящих элит, без будущего но с поехавшей крышей в окружающий мир, сохраняющий отатки здвавого смысла.
На простом собрании жильцов жилтоварищества сложно прийти к общему консенсусу, и в результате, все решается большинством голосов,
Если бы вы были на таких собраниях, то убедились бы, что трындят на них все что попало и при этом выглядят как толпа идиотов, а когда голосуют, то голосуют в итоге за весьма разумные решения. Я был и удивлялся этому факту.
Вы снова пытаетесь манипулировать через эмоции, увы, что неконструктивно, можно придумать много страшилок, размышлять про слезинку ребенка и так далее, но это не изменит основы вещей как бы вам этого не хотелось, право сильного никуда не делось в современном мире, просто оно реализуется непрямолинейно.
Где там манипуляции про слезинку? Я вам прямо говорю - бегите пока не поздно.
О моих личных проблемах я не могу говорить и это само по себе тоже уже проблема.
А так то, например в беларуси уволили из госсектора практически всех кто поставил подпись за альтертанивных кандидатов, когда эти подписи собирали. Я много таких знаю и теперь у этих людей реально проблема. Еще люди утратили ощущение безопасности, потому что если их фотка где не положено или комментарий найдутся в архивах, они получат года два. И это тысячи человек севших и остальные без спокойного сна. Еще множество программистов вынуждены покинуть страну из за того что западные заказчики не работают больше с нашими фиримами.
Еще мы все теперь живем в воюющих странах со всеми вытекающими. Еще дальнейшая эскалация окончательно разрушит наши планы. А дальше неизбежно будет жизнь в новой северной корее. Это все не фантазии, не случайные обстоятельства и не внешние факторы а историческая закономерность, которая нам предстоит из за нашей глупости. Все идет как по нотам и только из за того, что никто не видит разницы между демократией и диктатурой.
А до 24.02 была та проблема, что я прекрасно видел что после 24.02 скоро наступит в том или ином виде, и своим русским коллегам даже это говорил и не мог планировать свою жизнь от слова совсем.
Посмотрите на всю земную биомассу. Она огномна и ухитряется жить пол миллиарда лет не расходуя ресурсы. Не существует физических ограничений, которые мешали бы благополучно жить на земле десяткам миллиардов человек. Вопрос только в технологиях, которые были бы настолько хороши, чтобы полностью замкнуть цикл и не требовать чего-то невозобновляемого (как это сделала биосфера). Источником энергии как и для биосферы в конецном итоге будет солнце. Не забываем так же про временный вариант, позволяющий отложить апокалипсис - атомные электростанции.
Проблема только в том, чтобы эти технологии поспевали вовремя за ростом населения и тогда катаклизмов удасться избежать.
Как раз реальные законы физики обратимы в том смысле, что информация не теряется и работают законы сохранения.
Второе начало термодинамики в обтатимом автомате точно так же соблюдается - все упорядоченное становится хаотичным, хотя если запустить в обратную сторону то упорядочится обратно.
Правила криттеров не сильно сложнее чем правила жизни и контента там тоже возможно может быть много.
Если ИИ делает раблту за людей это хорошо. Это значит люди могут не работать или делать что им нравится. Проблема по каким критериям распределить блага когда нико не работает она есть но это новая проблема а не старая проблема нищеты и безрабоьицы. Важно не путать.
Существует еще один похожий на жизнь клеточный автомат - critters cellular automaton.
По-моему он сильно обделен вниманием. Его отличие от Life заключается в том, что он обратимый и имеет законы сохранения, чем напоминает реальную физику частиц.
Сидя без работы я как-то начал проект по его исследованию. Пока проект так и лежит здесь:
https://critters.azurewebsites.net/client/#/home
Там есть песочница, можно посмотреть как работает этот автомат.
Программист сейчас по моим ощущениям похож на профессионального пианиста.
Если изучил ноты (язык программирования), и теорию, значит молодец, но для работы это пока вообще не о чем. Если нет слуха, тоже ничего хорошего не получиться.
Раньше часто для работы хватало нот, природного слуха и навыка как-то сыграть (сам так работал). Теперь такое не прокатывает, нужно играть и играть по 8 часов в день разные произведения все более сложные на протяжении долгих лет и тогда становится настоящим музыкантом (в смысле - программистом). Дали исполнить новое произведение - не проблема, мозг оточен и усвоит его быстро, будет играть профессионально.
Тот кто собирается войти в айти должен осознавать эту ассоциацию. Ему предстоит не просто понять ноты белые-черные клавиши и педали. Нужно играть и играть пока игра не потянет на концертную а кнопки не начнет нажимать подсознание.
Фреймворки, концепции, парретрны должны бежать перед вашими глазами как знакомые страницы с нотами, которые все разные но на самом деле довольно схожи и пониматься интуитивно как это получается у крутого музыканта.
Второй обзац вашего сообщения объясняет противоречие, высказанное в первом - почему бизнес борется с безработицей, хотя это не в его интересах. Потому что так получается по логике развития технологий.
В ответ оно старательно подготовит текст который похож на текст компьютера, жедающего захватить мир. Но при этом никакой воли к исполнению у него быть не может.
Ну вот может CharGPT скомпоновать рабочее решение задачи из миллиона похожих увиденных. И что? Сколько у него желания захватить мир? Он делает в точности то для чего его обучали и ничего другого.
Так уж люди устроены. Например, они тысячелетиями верили, например, что если молиться каждый день и ходить в церковь, это поможет решить в том числе и материальные проблемы.
Теперь целая отрасль верит что определенные вещи эффективны потому что все их применяют а не потому что есть доказательства их эффективности. Микросервисы (когда они становятся действительно "микро") возможно одна из таких легенд.
Но в целом это работает. А главное - это способ победы над безработицей. Когда сложную задачу решает 3 гения, остальным нечего делать. Это дешево не не стабильно. Когда ее же решают опять эти три гения, но которые не имеют право все закодить сами, а вместо этого у них в подчинении 100 не-гениев, это дороже, но стабильнее. И у всех есть работа.
Можно взять, например фреймворк, в котором достаточно добавить поле в один класс и оно сразу будет доступно в браузере без пяти маперов и промежуточных перекладываний. Можно истребить все разнообразные инструменты и оставить один для каждой цели.
Но к счастью или к несчастью, по этому пути мы не идем. Вместо этого в каждом проекте нужно 100 обезьян, которые будут кропотливо изучать документацию по каждому инструменту, который решили использовать, а потом писать кучу кода по перекладыванию данных. Зато этот процесс гибкий, масштабируемый и у всех есть работа...
Я тут не вижу связи. Это модель котора получила на входе огромный массив данных и училась его интерполировать. То что этот массив был тектом не означает, что она может логически рассуждать о тексте. Скорее всего в обучающих текстах были задачи типа найти n-ю букву слова в достаточном количестве, чтобы сеть научилась генерировать их решения. И это удивительно, так как вряд ли этих задач было настолько много, чтобы тупо подбирать решение под задачу. Как ей удается скомпоновать решение на задачу которую именно в таком виде она не видела и насколько далеко заходит эта способность - для меня загадка.
Это как в анекдоте про собаку, которая играла в шахматы, но удивляться тут было нечему, потому что она всегда проигрывала.
Собственно то что сеть которая просто обучалась способна в полвине случаев выдавать логически связанные ответы, это выглядит как прорыв. Внутри сети само по себе сформировалось нечто похожее на логику, это удивительно.
Я пробовал сказать ей свое имя и имя моего сына, а потом спросить одинаковы ли первые буквы наших имен. Справилась. Для меня это сильно.
Ага. Любое объяснение работает для того, кто сам уже почти прошел, но еще нуждается в подтверждении своих догадок.
не не, у вас есть код, это у меня нет кода. давайте ка разберемся ка про кого он...
Если вы написали 1000 строк, думать о том как сделать код легко сопровождаемым рано. Я вот написал наверно не менее пол миллиона и до сих пор не могу понять как ООП и SOLID может мне помочь справиться со сложностью по сравнению с процедурным слилем и god-объектами :). Или могу. Пока не уверен.
По мне, здесь нужно разделять цели.
Первая цель - научиться писать работающий код больше чем с двумя условиями и не тонуть в нем.
Вторая цель - научиться писать код, который выглядит профессионально. То что он будет выглядеть профессионально не означает, что он будет проще. Это будет просто обезьянье подражание профессионализму, но без этого видимого профессионализма и видимой стандартности решений не возьмут на работу.
Третья цель - а как действительно написать простой понятный код для сложных проблем? И тут рецепта как такового нет. Наверно каждый расскажет свой некий путь.
Самая сложная цель - третья.
Начать лучше с того, что простейшим путем борьбы со сложностью является то что раньше называли "структурное программирование", когда общая функция решает задачу и затем она вызывает под-функции, решающие частные задачи и так далее. В самом низу находятся функции, уже работающие непосредственно с данными.
Научившись применять этот стиль мышления, можно двигаться дальше.
При этом есть два направления - от структурного к чисто функциональному стилю и к ООП стилю.
Функциональный стиль начинается с того, что мы перестаем пользоваться глобальными данными по возможности и стараемся писать чистые функции. Это хорошо работает когда нужно реализовать по настоящему сложный алгоритм.
ООП стиль начинается с того, что некая одна функция выполняясь запускает внутри себя другие функции, которые имеют дело с одними и теми же данными. В итоге мы имеем слишком много передаваемых данных и соблазн замкнуть эти алгоримты в некий небольшой изолированный модуль, к котором эти данные будут доступны функциям глобально (объект).
Здесь можно создать объект. При этом по мне, важно помнить, что мы создаем объект как "элемент поведения", а не как данные о неком доменном объекте оснащенные поведением. Второй путь хорош для UI фреймворков (кнопка-объект), может быть для игр, но создает очень много сложностей в других случаях (ИМХО).
Такой объект может создаваться операцией new, отрабатывать и тут же удаляться. Это нормально. В этом случае он мало отличается от функции.
Или объект может быть постоянно существующим в памяти и реагировать на обращения, например как кнопка в UI (правда если это кнопка не в React, где она создается при каждом обновлении экрана по новой).
Дальше, если хочется, то можно попробовать оснасить структуры данных, описывающие доменные объекты поведением. Т.е. ввести не просто объекты как элементы поведения, но объекты соответствующие доменным объектам. Попробуйте, но у меня не разу это ничего не упростило. Тут можно дискутировать.
Описанного выше пройденного пути уже достаточно, чтобы написать в одиночку программу на десятки тыщ строк кода и не увязнуть.
Но что если мы пишем код все вместе большими командами?
В мозгу у человека есть некое интуитивное ощущение универсальности. Если я описываю неккие классы и функции, что я делаю? Решаю конкретную задачи или пишу фреймворк всех времен и народов для решения всего класса подобных задач.
Первое, что нужно уметь, это всегда решая конкретную задачу чуть-чуть писать фреймворк для решения подобных задач, но без фанатизма. Это делает систему более пластичной к будущим изменениям и даже может сделать ее понятнее, если соблюдать баланс.
Второе - это тесты. Когда вы написали программу подумайте, можно ли ее разобрать на части , каждую часть поставить на стенд и испытать абстрактно, выполняет ли она ту логику для которой написано? Если нельзя, это все еще плохой код. Если уже можно, значит теперь мы победили сложность окончательно.
Дальше можно уже подумать про SOLID.
Допустим, мы запихнули в один объект и некую абстрактную логику и обращение к конкретному девайсу. Т.е. нарушили "S". Как теперь ее тестировать? Стенд для испытания этого объекта станет очень сложным и специфичным. А еще непонятным. Делим это на две части и все становится проще. Здесь необходимость тестировать помогает нам осознать важность S.
Допустим, при малейшем изменении задачи нам придется лезть в кишки объекта и все там менять, вместо того чтобы добавить новое поведение не меняя объекта (буква "O")? Это значит в нашем решении было недостаточно "фреймворковости", оно было слишком частным, или это может означать что мы распилили на объекты искусственно, не в том месте как надо (что по сути близко к недостатку "фреймворковости" по сути).
Мы ставим объект на стенд для тестирования и прямо не знаем с чего начать. У него столько методов! Здесь мы нарушили букву "I". На стенде тестируемый интерфейс должен выглядеть предельно просто и понятно - зачем он и как проверить что он это делает. Клиенты у интерфейса могут быть сегодня одни а завтра другие, но если он понятно тестируется, он уже соблюдает I в достаточной мере.
Есть замечательный принцип, использованный природой - каждый ген (а ген это элемент поведения, т.е. объект) вездесущ и активируется по месту в той части программы где он нужен. Значит для изменения программы достаточно добавить до кучи новый ген или подменить существующий. Этот замечательный принцип нужно не упустить и в разработке где возможно. Это "D".
Это был мой путь. Кто прошел иной путь, делитесь.
И эта должность будет называться "программист". Как в стартреках - спросите у программиста, программист - "компьютер, посчитай..."
Что значит если? Пока и в обозримой перспективе у них ошибок на порядки больше чем правильных решений.
Сейчас у ChatGPT очень короткий "контекст". Поэтому не получится последовательно уточнять детали задачи, как это можно делать с человеком. Долгий контекст сделать я думаю не получится пока, потому что даже для коротких описаний когда задача состоит из нескольких подзадач логика их связывания в половине случаев ломается. Для более длинных задач логика разных подзадач вообще перестанет вязаться. Для того чтобы это заработало в теории обучения должно быть существенно улучшение в направлении построения сетью стратегий решения задач.
Сеть должна как бы последовательно волнами много раз сканировать возможные стратегии решения задачи, дообучаясь по ходу и подбираясь к оптимальному варианту. Такой техники пока как я понимаю нет. Но по субъективным ощущениям мозг как раз делает нечто подобное при решении задач.
Грубо можно считать, что сейчас сеть - это как очень опытный старичок-препод, который не задумываясь может выдать ответ на любой вопрос, потому что его мозг тренирован выдавать определенный выход на привычные входные вопросы. Но старичка можно попросить проснуться из подумать час другой над задачей которую он раньше не видел, проявив креатив в поиске решений. А ИИ пока нельзя пропросить. Он все равно выдаст решение "не приходя в сознание", которое просто логически сшивает то что он уже видел.
Не, здесь речь о том, чтобы бежать из маленькой и незначительной страны с небольшим населением, без технологий, без морали, без здравомыслящих элит, без будущего но с поехавшей крышей в окружающий мир, сохраняющий отатки здвавого смысла.
Если бы вы были на таких собраниях, то убедились бы, что трындят на них все что попало и при этом выглядят как толпа идиотов, а когда голосуют, то голосуют в итоге за весьма разумные решения. Я был и удивлялся этому факту.
Где там манипуляции про слезинку? Я вам прямо говорю - бегите пока не поздно.
О моих личных проблемах я не могу говорить и это само по себе тоже уже проблема.
А так то, например в беларуси уволили из госсектора практически всех кто поставил подпись за альтертанивных кандидатов, когда эти подписи собирали. Я много таких знаю и теперь у этих людей реально проблема. Еще люди утратили ощущение безопасности, потому что если их фотка где не положено или комментарий найдутся в архивах, они получат года два. И это тысячи человек севших и остальные без спокойного сна. Еще множество программистов вынуждены покинуть страну из за того что западные заказчики не работают больше с нашими фиримами.
Еще мы все теперь живем в воюющих странах со всеми вытекающими. Еще дальнейшая эскалация окончательно разрушит наши планы. А дальше неизбежно будет жизнь в новой северной корее. Это все не фантазии, не случайные обстоятельства и не внешние факторы а историческая закономерность, которая нам предстоит из за нашей глупости. Все идет как по нотам и только из за того, что никто не видит разницы между демократией и диктатурой.
А до 24.02 была та проблема, что я прекрасно видел что после 24.02 скоро наступит в том или ином виде, и своим русским коллегам даже это говорил и не мог планировать свою жизнь от слова совсем.