Вы сейчас путаете прерывания и исключения, а это разные концепции. Исключение в вашем пример, это по сути дела способ глобально перейти на типизированный обработчик, по сути глобальный goto на тип данных (исключения). Но он работает в одном потоке и это обычный однопоточный код реализуемый на МТ, тогда как в контексте же МТ важны аппаратные прерывания (или вытесняющая многозадачность), на которую одна МТ не способна.
Да, умные люди доказали что в она в теории может выполнять любой алгоритм, вот только при важном допущении о наличии бесконечной памяти и неограниченном времени на работу, тогда как в реальности это невозможно.
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
Это наверно камешек в мой адрес? :-) Да, я знаю и про Go и про Rust, и знаю, что у них, как и всех языков программирования реального мира есть возможность прерывания выполнения программы в любой момент времени. Просто некоторые языки умеют обрабатывать подобные прерывания, а другие нет, но сути это не меняет, тогда как МТ принципиально не умеет обрабатывать прерывания или переключать контекст, так как она всегда строго последовательная.
голая многопоточность -- это пот, боль и кровь. Если у вас есть возможность не использовать многопоточность, то не используйте ее.
К сожалению, это не вариант. Но и отчаиваться не нужно, так как всегда остается шанс найти более или менее нормальное решение, хотя не в рамах беседы с текущим автором :-)
Мне кажется, что ошибки как раз у вас в рассуждениях.
Проблема программных ошибок - это совсем не относится к МT. Ей-то какое дело до того, что у кого-то руки растут не из того места?
Полностью с вами согласен, что если Agile не работает, то значит его неправильно внедрили, а если в программе есть ошибки, то это точно виноват программист.
Проблема в том, что подобный аргумент в любом техническом споре, это риторический прием не имеющий ни к науке, ни к техничке никакого отношения
А про обязательность наличия прерываний и их обработки? Это-то каким местом относится к МТ?
Вот в том то и дело, что никаким местом не относится, так как у МТ нет прерываний, тогда как они нужны для работы в реальном мире и на реальном железе (а не в математической абстракции)
Я реальный программиста, а не сферический в вакууме, и понимаю различия между математической теорией и реальностью, в которой отсутствует бесконечная память и неограниченное время при работе реальных алгоритмов.
должна существовать, как и в случае последовательных алгоритмов
А с чего вы решили, что для последовательнх алгоритмов это существует? Машина Тьюрига - это чистая математическая абстракция, которой не существует в реальном мире. Или речь идет о чем-то другом?
Конечно есть. Но ведь может потребоваться отменять не весь пропт, а только какую то часть, когда рассуждения LLM "завернули не туда". И тут основная проблема не отменить изменения, а определить момент поворота рассуждений в неправильном направлении.
Искренне прошу прощения за невольную обиду, так как собеседник очень настойчив в попытке насаждения своей религии, поэтому я и предположил наличие у него нескольких аккаунтов.
Но это ни в коем случае не попытка очернить вас и мне искренне жаль за сделанную ранее формулировку.
Рефакторить может потребоваться любой код, не важно был он написан вручную или сгенерирован ИИ. Более того, абстрактный начальный промпт практичеси всегда раскрывается в список конкретных этапов. Вот его можно рассматривать как ТЗ на разработку, но никак не начальный промпт.
Вайбкодинг - это про эмоции от процесса программирования, а не про программирования без соответствующих знаний (все равно, что кухарке начать управлять страной). LLM это просто инструмент и не более того и если за программирование берется человек без нужных знаний и опыта, результат вполне очевиден.
От повторения ваши аргументы не стали более верными. Если вы заметили, то я прекратил с вами обсуждение еще в прошлой ветке, так как вы не обращаете внимание на факты, которые не соответствуют вашей вере во всемогущество и непогрешимость Rust, а споры о религии меня не интересуют :-)
Вы сейчас путаете прерывания и исключения, а это разные концепции. Исключение в вашем пример, это по сути дела способ глобально перейти на типизированный обработчик, по сути глобальный goto на тип данных (исключения). Но он работает в одном потоке и это обычный однопоточный код реализуемый на МТ, тогда как в контексте же МТ важны аппаратные прерывания (или вытесняющая многозадачность), на которую одна МТ не способна.
Да, умные люди доказали что в она в теории может выполнять любой алгоритм, вот только при важном допущении о наличии бесконечной памяти и неограниченном времени на работу, тогда как в реальности это невозможно.
Это наверно камешек в мой адрес? :-) Да, я знаю и про Go и про Rust, и знаю, что у них, как и всех языков программирования реального мира есть возможность прерывания выполнения программы в любой момент времени. Просто некоторые языки умеют обрабатывать подобные прерывания, а другие нет, но сути это не меняет, тогда как МТ принципиально не умеет обрабатывать прерывания или переключать контекст, так как она всегда строго последовательная.
Скину в личку статью с описанием похожей проблемы, но кардинально другим решением https://peterneufeld.wordpress.com/2025/03/04/esp32-c3-supermini-antenna-modification/
Облако и приватный LLM агент для работы с конфиденциальными данными, это какой-то оксюморон :-)
Жаль что не видел этой статьи раньше. Не пришлось бы писать свою :-)
Ну да, в том числе и это. Хотя мне бы хотелось, чтобы была хоть какая нибудь защитная семантика на уровне исходного кода, которая бы предотвращая ошибки многопоточности во время компиляции :-)
К сожалению, это не вариант. Но и отчаиваться не нужно, так как всегда остается шанс найти более или менее нормальное решение, хотя не в рамах беседы с текущим автором :-)
Мне кажется, что ошибки как раз у вас в рассуждениях.
Полностью с вами согласен, что если Agile не работает, то значит его неправильно внедрили, а если в программе есть ошибки, то это точно виноват программист.
Проблема в том, что подобный аргумент в любом техническом споре, это риторический прием не имеющий ни к науке, ни к техничке никакого отношения
Вот в том то и дело, что никаким местом не относится, так как у МТ нет прерываний, тогда как они нужны для работы в реальном мире и на реальном железе (а не в математической абстракции)
Абстракции в программировании нужны для упрощения/обощения алгоритмов. Для чего нужно реализовывать "чистую математическую абстракцию"?
Тогда у меня для вас есть альтернативный вариант ссылки :-)
Я реальный программиста, а не сферический в вакууме, и понимаю различия между математической теорией и реальностью, в которой отсутствует бесконечная память и неограниченное время при работе реальных алгоритмов.
А с чего вы решили, что для последовательнх алгоритмов это существует? Машина Тьюрига - это чистая математическая абстракция, которой не существует в реальном мире.
Или речь идет о чем-то другом?
А что, Lua тоже тащат в ядро Linux?
А зачем такое усложнение с доступом к GigaCode?
Как подключить вашу модель, например к Cline?
Не вижу ничего плохого в написанном коде. Может быть вы покажете конкретное место, где же плох код, написанный ИИ?
Конечно есть. Но ведь может потребоваться отменять не весь пропт, а только какую то часть, когда рассуждения LLM "завернули не туда". И тут основная проблема не отменить изменения, а определить момент поворота рассуждений в неправильном направлении.
Искренне прошу прощения за невольную обиду, так как собеседник очень настойчив в попытке насаждения своей религии, поэтому я и предположил наличие у него нескольких аккаунтов.
Но это ни в коем случае не попытка очернить вас и мне искренне жаль за сделанную ранее формулировку.
Рефакторить может потребоваться любой код, не важно был он написан вручную или сгенерирован ИИ. Более того, абстрактный начальный промпт практичеси всегда раскрывается в список конкретных этапов. Вот его можно рассматривать как ТЗ на разработку, но никак не начальный промпт.
Причем тут "развернуть и против вас"? Я опираюсь на факты, а не риторическими утверждения.
Этот код ничем от отличается от кода на С++ и не дает гарантий безопасного управления памятью, о чем я и писал выше.
Вайбкодинг - это про эмоции от процесса программирования, а не про программирования без соответствующих знаний (все равно, что кухарке начать управлять страной). LLM это просто инструмент и не более того и если за программирование берется человек без нужных знаний и опыта, результат вполне очевиден.
От повторения ваши аргументы не стали более верными. Если вы заметили, то я прекратил с вами обсуждение еще в прошлой ветке, так как вы не обращаете внимание на факты, которые не соответствуют вашей вере во всемогущество и непогрешимость Rust, а споры о религии меня не интересуют :-)