Тогда как работает WebAssembly? На виртуальной машине, если ничего не путаю. Примерно, как Java. Благодаря этому можно использовать компилируемый ЯП, и это будет сильно лучше
Кстати, в WASM хотят завезти поддержку DOM, и параллельно в Rust допиливается поддержка/аналог emscripten в С++. Так что ожидается море возможностей (и подводных камней с блокировкой UI потока при модификации DOM через WASM)
Спор заключается в том, нужно ли понимать, что нейронка пишет, или доверить ей всё и не париться. Нейронка способна писать автономно только базовые проекты, которые пишутся в одиночку. В большой компании она может писать отдельные алгоритмы, которые всё равно проходят ревью. Так что вывод очевиден. Просто большинство людей, кричащих, что ИИ всемогущий, либо никогда не работали в команде в большой строгой конторе, либо просто поддерживают хайп. Я сам пользуюсь ИИ. Но я понимаю каждую строчку, что он пишет, и проверяю всё досканально
И по-прежнему ни одного примера поддержки старого легаси-кода какого-нибудь древнего проекта без документации... Вот когда ИИ сделает это, тогда я поверю, что он что-то может
В статье описываются максимально базовые вещи, которые и раньше с лихвой делались нейронкой. "Революция" только в автономности. Нейронка всё равно не понимает, не осознаёт то, что она пишет, и это - главная проблема.
Вот у меня прекрасный пример галлюцинаций нейронки есть. Можете особо не вникать, но я постараюсь максимально кратко объяснить. Мы разрабатываем сервис, связанный с логистикой перевозок. Мой коллега по проекту попросил ИИ написать код для просчета сложных маршрутов (маршруты из 2-х сегментов, с промежуточной точкой). Конкретно - нужно было написать запросы к БД через Sqlalchemy (т.е. нужен SELF JOIN). Нейронка вместо того, чтобы честно этот SELF JOIN написать, взяла и просто поменяла тип маршрута в базовом запросе. Всё работало! Без единой ошибки. Но данные были некорректны. Всё потому, что нейронка не поняла, что надо сделать
В примере проблема, безусловно, не в нейронке, а в способе её использования. Человек просто не проверил результат. Но этот пример отлично доказывает, что нейронка может легко не понять, и без единой ошибки в консоли сдать "готовый" проект, который не будет правильно работать. Если бы у нас были тесты, нейронка так же неправильно могла бы их написать из-за отсутствия осознания задачи. Именно понимание цели делает человеческий код надёжнее. И пока нейронка не сможет осознавать то, что она делает, она никогда не заменит человека. Не всё можно покрыть автотестами. Иногда нужно реальное понимание задачи
Спор строится на правильном предположении, что люди понимают, что пишут, а ИИ - нет. Поэтому все замечания справедливы: код нейронки должен проверяться человеком, обладающим опытом и осознающий цель написания программы
Человек может ошибиться потому, что был невнимателен, и такое легко правится ИИ. Но ИИ может выдать полную хрень, потому что не поняла задание, и это будет работать, и вот такое уже человеку сложно отловить. Я лично был свидетелем такого безобразия в своём собственном проекте) могу рассказать, если не верите, что такое бывает
Ну если статья состоит из воды без конкретики и каких-либо примеров - это шлак. Куча таких статей, которые абсолютно неинформативны. Но это не проблема ИИ. Люди и раньше писали такие статьи. Просто в настоящее время подобное генерируется исключительно нейронкой. Человек часто не вникает в тему, просто говорит нейронке "сгенерируй текст такой-то". И выкладывает. Это неприятно читать. Такие статьи справедливо называют шлаком, но не всегда справедливо добавляют приставку "ИИ-"))
Другое дело - статьи, в которых всё написано по делу, есть реальные кейсы, но текст "причёсан" нейронкой. Это не всегда удачно получается, но такие статьи действительно приятно и полезно читать. И их как раз не назовешь шлаком. Они ценны
Почему люди часто говорят про "ИИ-шлак"? Потому, что многие люди генерируют текст без разбора, не вникая в тему, а ИИ склонен галлюцинировать и писать много воды. Авторы подобное далеко не всегда замечают или игнорируют. Таких статей ОЧЕНЬ много, поэтому многие, видя стиль ИИ, автоматически воспринимают текст как шлак, хотя иногда это может быть не так. Формируется ошибочное убеждение, что все статьи с применением ИИ - шлак. И это относится к любому продукту: статьи, игры, истории из клуба романтики
Я уверен, что в своём заявлении гендиректор попросил не относиться предвзято к подобным творениям. Если это так, то это ПРАВИЛЬНО. Но я бы добавил к этому ещё то, что за своё творение нужно нести ответственность, что подразумевает проверку перед публикацией
А почему, собственно, все так зациклилась на том, что новые вопросы не задаются? На SO очень много инфы накопилось за всё его время работы. Я, например, постоянно его посещаю, уже в течение 7 лет, но вопрос за это время задал только 1. Я бы очень хотел увидеть статистику посещения сайта, т.к. лично мне ИИ заменил SO лишь на ~30%
Практика неточкисных ревью... Если честно, я впервые такое слышу XD. Если я на плюсах лишний раз напишу (или не напишу) auto, мне это первым же комментарием попросят исправить))
Спасибо за уточнение. Соглашусь, вы дали более корректный ответ)
Автор утверждает, что МТ - модель последовательного выполнения алгоритма; также он утверждает, что для параллельного выполнения подобной модели не существует (опять же, если верно всё понял). Если принять за истину, что детерминированная МТ является моделью в первом случае, то может ли недетерминированная являться моделью во втором? Как считаете?
Не сказал бы, что камешек) просто хочу дать понять, что прерывания - это некое дополнение. На самом деле, когда вы пишете "throw new Exception" или что-то подобное, вы пользуетесь виртуальными таблицами прерываний. Они реализованы программно. В теории, для МТ вы тоже можете их реализовать (умные люди доказали до нас, что МТ может исполнить любой алгоритм). Так что в теории ещё как может :) ведь что такое контекст? Это тоже некая абстракция. По сути таблица переходов реализует оператор goto, и этого вполне может быть достаточно
Обработка исключений в однопотоке тоже последовательная. В многопотоке - нет. Но и МТ может быть недетерминированная))
По поводу перевода программы из последовательного алгоритма в параллельный очень хороший комментарий дал Akon32 - такая оптимизация проводится на всех этапах: от компиляции до исполнения. Увы, комментарий остался без ответа, но мнение автора на этот счёт довольно интересно
По поводу темы статьи - проблемы реализации модели двух парадигм (если это можно так назвать). Ох, тут всё намешано в кучу. Машины Тьюринга/Поста ни в коем случае не являются моделями какой-либо парадигмы. Это модели непосредственно исполнителей с неограниченным ресурсом памяти и времени. Более того, это абстрактные модели НЕРЕАЛИЗУЕМЫХ на практике исполнителей. Утверждать, что это - модели, описывающаие поведение исполнителей последовательных программ, - нельзя. Кроме того, ничего общего с ПОСЛЕДОВАТЕЛЬНЫМ исполнением здесь нет. МТ - это класс машин. Есть недетерминированная, ещё более абстрактная машина Тьюринга. Она может одновременно исполнять несколько переходов, быть в более чем одном состоянии в единицу времени. Чем не модель параллелизма? Но нет, опять же, с реальным миром это не имеет ничего общего. Как хорошо, что меня в универе этому учили целый год :)
Чтобы ответить на вопрос о том, есть ли МОДЕЛЬ какого-либо процесса, предлагаю автору грамотно построить вопрос, ЧТО является моделью? Дать ей определение, прежде чем искать
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
P.S.: ни в коем случае, не хочу никого обидеть - желаю только справедливости и хочу сам разобраться в теме. Безусловно, мог что-то неверно понять/прочитать - все мы люди. Буду очень рад читать конструктивную критику
Когда я вижу ИИ-статьи, я сразу иду читать комменты. Комментаторов такие статьи стимулируют писать очень интересные вещи, зачастую круче самой статьи, так что спасибо :)
Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!
Тогда как работает WebAssembly? На виртуальной машине, если ничего не путаю. Примерно, как Java. Благодаря этому можно использовать компилируемый ЯП, и это будет сильно лучше
Кстати, в WASM хотят завезти поддержку DOM, и параллельно в Rust допиливается поддержка/аналог emscripten в С++. Так что ожидается море возможностей (
и подводных камней с блокировкой UI потока при модификации DOM через WASM)Минимализм на максималках. Скоро на двоичном коде будем писать, и все будут счастливы
Спор заключается в том, нужно ли понимать, что нейронка пишет, или доверить ей всё и не париться. Нейронка способна писать автономно только базовые проекты, которые пишутся в одиночку. В большой компании она может писать отдельные алгоритмы, которые всё равно проходят ревью. Так что вывод очевиден. Просто большинство людей, кричащих, что ИИ всемогущий, либо никогда не работали в команде в большой строгой конторе, либо просто поддерживают хайп. Я сам пользуюсь ИИ. Но я понимаю каждую строчку, что он пишет, и проверяю всё досканально
И по-прежнему ни одного примера поддержки старого легаси-кода какого-нибудь древнего проекта без документации... Вот когда ИИ сделает это, тогда я поверю, что он что-то может
В статье описываются максимально базовые вещи, которые и раньше с лихвой делались нейронкой. "Революция" только в автономности. Нейронка всё равно не понимает, не осознаёт то, что она пишет, и это - главная проблема.
Вот у меня прекрасный пример галлюцинаций нейронки есть. Можете особо не вникать, но я постараюсь максимально кратко объяснить. Мы разрабатываем сервис, связанный с логистикой перевозок. Мой коллега по проекту попросил ИИ написать код для просчета сложных маршрутов (маршруты из 2-х сегментов, с промежуточной точкой). Конкретно - нужно было написать запросы к БД через Sqlalchemy (т.е. нужен SELF JOIN). Нейронка вместо того, чтобы честно этот SELF JOIN написать, взяла и просто поменяла тип маршрута в базовом запросе. Всё работало! Без единой ошибки. Но данные были некорректны. Всё потому, что нейронка не поняла, что надо сделать
В примере проблема, безусловно, не в нейронке, а в способе её использования. Человек просто не проверил результат. Но этот пример отлично доказывает, что нейронка может легко не понять, и без единой ошибки в консоли сдать "готовый" проект, который не будет правильно работать. Если бы у нас были тесты, нейронка так же неправильно могла бы их написать из-за отсутствия осознания задачи. Именно понимание цели делает человеческий код надёжнее. И пока нейронка не сможет осознавать то, что она делает, она никогда не заменит человека. Не всё можно покрыть автотестами. Иногда нужно реальное понимание задачи
А за что минус? В чём я не прав?
Спор строится на правильном предположении, что люди понимают, что пишут, а ИИ - нет. Поэтому все замечания справедливы: код нейронки должен проверяться человеком, обладающим опытом и осознающий цель написания программы
Человек может ошибиться потому, что был невнимателен, и такое легко правится ИИ. Но ИИ может выдать полную хрень, потому что не поняла задание, и это будет работать, и вот такое уже человеку сложно отловить. Я лично был свидетелем такого безобразия в своём собственном проекте) могу рассказать, если не верите, что такое бывает
Ну если статья состоит из воды без конкретики и каких-либо примеров - это шлак. Куча таких статей, которые абсолютно неинформативны. Но это не проблема ИИ. Люди и раньше писали такие статьи. Просто в настоящее время подобное генерируется исключительно нейронкой. Человек часто не вникает в тему, просто говорит нейронке "сгенерируй текст такой-то". И выкладывает. Это неприятно читать. Такие статьи справедливо называют шлаком, но не всегда справедливо добавляют приставку "ИИ-"))
Другое дело - статьи, в которых всё написано по делу, есть реальные кейсы, но текст "причёсан" нейронкой. Это не всегда удачно получается, но такие статьи действительно приятно и полезно читать. И их как раз не назовешь шлаком. Они ценны
Почему люди часто говорят про "ИИ-шлак"? Потому, что многие люди генерируют текст без разбора, не вникая в тему, а ИИ склонен галлюцинировать и писать много воды. Авторы подобное далеко не всегда замечают или игнорируют. Таких статей ОЧЕНЬ много, поэтому многие, видя стиль ИИ, автоматически воспринимают текст как шлак, хотя иногда это может быть не так. Формируется ошибочное убеждение, что все статьи с применением ИИ - шлак. И это относится к любому продукту: статьи, игры, истории из клуба романтики
Я уверен, что в своём заявлении гендиректор попросил не относиться предвзято к подобным творениям. Если это так, то это ПРАВИЛЬНО. Но я бы добавил к этому ещё то, что за своё творение нужно нести ответственность, что подразумевает проверку перед публикацией
А почему, собственно, все так зациклилась на том, что новые вопросы не задаются? На SO очень много инфы накопилось за всё его время работы. Я, например, постоянно его посещаю, уже в течение 7 лет, но вопрос за это время задал только 1. Я бы очень хотел увидеть статистику посещения сайта, т.к. лично мне ИИ заменил SO лишь на ~30%
Объясните пожалуйста вот этот кусок кода:
Какой смысл запускать отдельный поток и сразу же join-ить его? По сути, тот же блокирующий код, что и без потока. Или я чего-то не понимаю?
Заменили бы GIL на обязательные мьютексы для каждой переменной)) Было бы производительнее и удачнее...
Не сдавайтесь! Я всё ещё верю, что вы продолжите писать :)
Практика неточкисных ревью... Если честно, я впервые такое слышу XD. Если я на плюсах лишний раз напишу (или не напишу) auto, мне это первым же комментарием попросят исправить))
Спасибо за уточнение. Соглашусь, вы дали более корректный ответ)
Автор утверждает, что МТ - модель последовательного выполнения алгоритма; также он утверждает, что для параллельного выполнения подобной модели не существует (опять же, если верно всё понял). Если принять за истину, что детерминированная МТ является моделью в первом случае, то может ли недетерминированная являться моделью во втором? Как считаете?
Не сказал бы, что камешек) просто хочу дать понять, что прерывания - это некое дополнение. На самом деле, когда вы пишете "throw new Exception" или что-то подобное, вы пользуетесь виртуальными таблицами прерываний. Они реализованы программно. В теории, для МТ вы тоже можете их реализовать (умные люди доказали до нас, что МТ может исполнить любой алгоритм). Так что в теории ещё как может :) ведь что такое контекст? Это тоже некая абстракция. По сути таблица переходов реализует оператор goto, и этого вполне может быть достаточно
Обработка исключений в однопотоке тоже последовательная. В многопотоке - нет. Но и МТ может быть недетерминированная))
По поводу перевода программы из последовательного алгоритма в параллельный очень хороший комментарий дал Akon32 - такая оптимизация проводится на всех этапах: от компиляции до исполнения. Увы, комментарий остался без ответа, но мнение автора на этот счёт довольно интересно
По поводу темы статьи - проблемы реализации модели двух парадигм (если это можно так назвать). Ох, тут всё намешано в кучу. Машины Тьюринга/Поста ни в коем случае не являются моделями какой-либо парадигмы. Это модели непосредственно исполнителей с неограниченным ресурсом памяти и времени. Более того, это абстрактные модели НЕРЕАЛИЗУЕМЫХ на практике исполнителей. Утверждать, что это - модели, описывающаие поведение исполнителей последовательных программ, - нельзя. Кроме того, ничего общего с ПОСЛЕДОВАТЕЛЬНЫМ исполнением здесь нет. МТ - это класс машин. Есть недетерминированная, ещё более абстрактная машина Тьюринга. Она может одновременно исполнять несколько переходов, быть в более чем одном состоянии в единицу времени. Чем не модель параллелизма? Но нет, опять же, с реальным миром это не имеет ничего общего. Как хорошо, что меня в универе этому учили целый год :)
Чтобы ответить на вопрос о том, есть ли МОДЕЛЬ какого-либо процесса, предлагаю автору грамотно построить вопрос, ЧТО является моделью? Дать ей определение, прежде чем искать
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
P.S.: ни в коем случае, не хочу никого обидеть - желаю только справедливости и хочу сам разобраться в теме. Безусловно, мог что-то неверно понять/прочитать - все мы люди. Буду очень рад читать конструктивную критику
Когда я вижу ИИ-статьи, я сразу иду читать комменты. Комментаторов такие статьи стимулируют писать очень интересные вещи, зачастую круче самой статьи, так что спасибо :)
Если приходится выбирать между двумя крайностями, я выбираю увольнение)))
Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!