конфликты с авторами из-за использования генеративных моделей ИИ для создания ... полностью сгенерированных текстов.
Вот какие аргументы приводят пользователи:
я просто улучшил текст;
я плохо выражаюсь;
ну я же всю свою экспертизу передал промптом;
А может попробовать обязать всех авторов сгенерированных посредством ИИ статей указывать точный промпт, который они использовали и название модели [включая версию]? А то вдруг и правда их промпт состоит прям из сплошной экспертизы или автор плохо выражается и нейронка смогла донести смысл лучше, чем оригинальный текст автора. Таким образом, это позволит более объективно оценить полезность сгенерированной статьи.
Считаю, что стоит распространить это обязательство в том числе на всех уже приглашённых/‘получивших инвайт’ авторов, а также тщательно продумать эту идею, расписать правила публикации таких статей.
Например, в самом начале или конце статьи необходимо добавить спойлер с определённым заголовком, содержащим фразу вроде «Текст получен системой генеративного ИИ». Внутри спойлера указывается название модели и точный промпт.
При создании статьи необходимо будет поставить галочку «Публикация сгенерирована ИИ» [которую можно расположить рядом с галочкой «Публикация является переводом», например]. А сама статья получит плашку/бейджик «Сгенерировано ИИ». И разумно дать читателям Хабра возможность скрывать все статьи с такой пометкой.
А если учесть, что существует англоязычная версия Хабра, то можно попробовать разработать некий международный стандарт, скажем так. Стандарт того, как именно должны быть помечены материалы, сгенерированные ИИ. Это будет полезно не только читателям-людям, но и самому ИИ, чтобы учитывать (или вообще игнорировать) сгенерированный контент. Ведь очевидно, что его [сгенерированного контента] будет становиться всё больше и больше. И что с этим делать необходимо решать уже сейчас.
Очень интересно услышать название [хотя бы одного] языка программирования, в котором такой код корректен (т.е. где j — это будет индекс, а не 3-мерный массив). И увидеть рабочий пример, а не просто псевдокод (пусть вместо DoSomethingTo будет просто print/Console.Write/echo), на этом языке программирования.
Насколько мне известно, таких языков программирования нет.
И заодно обязать производителей железа писать драйвера не по 1.5 Гб. Иначе как волшебный веб-сервер догадается, как управлять этой мышкой и есть ли в ней подсветка.
Очень грустно, что корпорации убедили почти всех пользователей (в т.ч. и вас, похоже), что простейший софт, занимающий гигабайты места — это нормально.
Вы слышали про 3D-шутер размером в 96Кб? Да, там лишь 10 минут геймплея, но используя технологии, на которых он сделан, в пару мегабайт можно поместить геймплея на несколько часов или даже десятков часов, т.е. получить вполне полноценную компьютерную игру.
Так и эти "драйвера" на 1.5 Гб вполне можно было бы уместить в 1.5 Мб. Ведь мышки/клавиатуры/наушники — это же не 3D-видеокарты, для взаимодействия с ними много кода не нужно.
Вы представляете себе, что происходит на самом нижнем уровне при выполнении действия «отключить подсветку у мышки»? Там же никакой магии — нужно просто отправить мышке по USB-шине определённый набор нулей и единиц. Вопрос только какой именно. И эту информацию корпорации держат в секрете. А почему — потому что иначе энтузиасты напишут гораздо менее прожорливую версию софта, предоставляющую к тому же более удобный для пользователей интерфейс, и весь софтверный отдел корпорации окажется не нужен.
Не говоря уже о том, что у винды под капотом как раз уже точки монтирования.
Речь идёт о пользовательском опыте. То, что NTFS поддерживает точки монтирования — это замечательно, вот только типичные (и даже продвинутые) пользователи их не используют.
Да, появление std:generator в C++ я как-то пропустил.
Но судя по страничке Compiler support for C++23std::generator на данный момент поддерживается только одним компилятором: GCC 14-й версии, который вышел совсем недавно — 07.05.2024.
И скорее всего, реализована эта штука очень неоптимально. Я написал простейший генератор, который производит целые числа из заданного диапазона:
std::generator<int> range_generator(int start, int stop)
{
for (int i = start; i < stop; i++)
co_yield i;
}
Не берусь судить об эффективности сгенерированного компилятором кода, но выглядит страшно.
Вообще, co_yield — это же про асинхронный код. И будет ли co_yield когда-нибудь оптимизирован C++-компиляторами для синхронных генераторов — большой вопрос.
И что вы сможете увидеть в этом состоянии? Ведь имя pdf-файла [file.pdf] в строке cat file.pdf > /dev/lpt0 никуда не передаётся. Как узнать какой именно файл сейчас печатается?
В случае с HTTP-запросом указать имя файла не проблема:
Ничего принципиально не мешает сделать файл /dev/lpt0_ctl для передачи настроек
А если на печать отправляются одновременно два файла [из двух различных процессов]? Как надёжно сопоставить настройки/параметры печати с соответствующим файлом? Решение с файлами устройств — оно очень хрупкое.
Я уж не говорю про обнаружение возможных ошибок при печати. Или вы предлагаете добавить ещё и /dev/lpt0_err? Если pdf-файл банально некорректный, то HTTP-запрос сразу вернёт соответствующий статус (например, 422 Unprocessable Content), а в теле ответа вполне можно поместить подробное сообщение об ошибке (причём на том языке, который был указан в заголовке ‘Accept-Language’ у запроса).
К тому же, печать файла — это длительный процесс. И за время его печати порой требуется отправить на печать ещё пару-тройку других файлов, не дожидаясь окончания печати первого. При этом пользователь может внезапно захотеть отменить печать второго файла до окончания печати первого. «Веб-сервер устройства» для всего этого подходит гораздо лучше, чем «файл устройства».
Вам вообще приходилось читать ассемблерный код? (Я уж не говорю про «писать».) Или это так, рассуждения из воздуха?
Если приходилось, то будет очень интересно услышать. Именно про ваш опыт. А не просто мнение. Т.к. в русскоязычной среде специалистов по языку ассемблера (не по интринсикам, а именно по машинным командам) буквально единицы, и на Хабре они, увы, не пишут.
cvtsi2sd xmm8, r8 ; convert n from int to double and store in xmm8
...
vmulsd xmm3, xmm3, xmm8 ; xmm3 = n * sumYY
...
vsubsd xmm2, xmm2, xmm6 ; xmm2 = (n * sumXX) - (sumX * sumX)
...
vextractf128 xmm6, ymm4, 1 ; xmm6 = lower 2 doubles of sumXY
И как думаете, комментарии к каждой строке ассемблерного кода там, они для чего вообще? Так, просто по приколу? Или же всё-таки для улучшения читаемости/понимаемости кода.
Вы вообще представляете, что такое современный x86-64 ассемблерный код? Посмотрите для общего развития на этот список команд. Одних только команд конвертации (у которых мнемоники начинаются на cvt или vcvt) — 82 штуки! И отличаются они между собой порой всего на одну букву. Если ассемблерный код не содержит подсказок/комментариев к каждой строке, то найти в нём ошибку практически невозможно. Поэтому и приходится изобретать язык для таких комментариев. И симкод является попыткой стандартизации такого языка.
Про читаемость есть например тот же masm где есть упрощённые конструкции объявления и вызова процедур, работы со стековыми переменными, ветвления и пр.
Уже нету. В 64-разрядной версии MASM поддержку встроенных макросов (.if, .while, invoke и пр.) убрали.
Т.к ни один компилятор (C++, Rust или другого компилируемого языка) не генерирует ассемблерный код с макросами. А руками ассемблерный код уже давно не пишут. Поэтому макросы и убрали в MASM64.
А что, если подсказка к каждой строке читаемого ассемблера будет на Симкоде?
Уже реализовано в консольной утилите symasm посредством режима --annotate. Хотя я об этом уже писал в статье, но приведу результат работы этого режима [применительно к примеру с setg/cmovl из статьи] для наглядности:
xor eax, eax ; eax = 0
cmp edi, esi ; edi <=> esi
mov edx, -1 ; edx = -1
setg al ; al = 1 if > else 0
cmovl eax, edx ; eax = edx if <
ret
Visual C++ генерирует ассемблерные листинги с макроконстантами.
А, вы про именованные константы. Я говорил про макросы в их традиционном понимании (макрос — символьное имя, заменяемое при обработке препроцессором на последовательность программных инструкций).
Насчёт конструкции eax = BLACK. Сгенерированный компилятором симкод, скорее всего, будет выглядеть как eax = 0 // BLACK если в этом месте можно использовать xor, либо как eax = (0) // BLACK, если нужен именно mov (но такое бывает крайне редко).
Данная ассемблерная команда практически не используется компиляторами (при включенных оптимизациях). Поэтому было логично поставить ей в соответствие более длинную симкоманду.
Спасибо, но если мне вдруг захочется сопоставить машинный код с операторами С - https://godbolt.org/
Можно пример? godbolt.org сопоставляет Сишный код с машинным, а не наоборот.
Именно что симкоманды и исполняет. Можете проверить сами на web-версии консольной утилиты symasm — любой ассемблерной инструкции x86-64 соответствует симкоманда, а любой симкоманде соответствует одна или две ассемблерные инструкции (правда, пока что реализован перевод только в одну сторону). Если вас смущает фраза «процессор исполняет симкоманды» (или, что то же самое, «процессор исполняет ассемблерные команды»), то, разумеется, это не буквально — процессор исполняет двоичный машинный код, но симкоманды являются прямым отображением этого машинного кода, так же, как и язык ассемблера.
А вот язык программирования Си прямым отображением машинного кода ни разу не является.
Удивительно, что приходится тратить время на разъяснение таких очевидных вещей.
Но как тут помогут макросы?
Ладно, я зачеркнул приставку «макро» в определении симкоманды в начале статьи, если она вас так сбивает с толку. Но продублирую информацию из всплывающей подсказки к слову «макрокоманда»: Формально, макрокоманда — это мнемоническая команда, которая может разворачиваться более чем в одну машинную инструкцию. Однако, фактически, все симкоманды разворачиваются только в одну машинную инструкцию, за исключением лишь симкоманд условных переходов, которые могут разворачиваться в две машинные инструкции.
У вас процессор напрямую Сишный код исполняет? Да, в процитированном вами предложении перед словом «кода» я не написал уточнение «ассемблерного», т.к. полагал, что из контекста это должно быть очевидно (т.к. статья посвящена языку ассемблера). Вам разве не доводилось анализировать ассемблерный код, сгенерированный компилятором из программы на Си? Вот для упрощения такого анализа и предназначен симкод.
Что касается Николай Васильевича Горшкова, непонятно для чего упомянутого в статье
Ничего против Николая Васильевича лично я не имею. Нелестно о нём отзывался некто Сергей Николаевич Попов. А мне понравилась просто эта цитата. Ведь согласитесь, что во время появления Unix мало кто предполагал, что эта операционная система будет использоваться на устройствах размером с блокнот и производительностью десятков мейнфреймов.
А на какой срок занял? До скончания веков, что-ли? :)(: Кто вообще помнит про этот Plan 9... Скоро слово "восьмёрка" перестанут ассоциировать с операционной системой Windows 8, т.к. про неё уже забывать начинают (спустя 12 лет после её выхода). А вы говорите про Plan 9, которому больше 30 лет. Да большинство читателей этой статьи ещё не родилось даже во время появления этой ОС.
ForwardCom, в котором тоже для ассемблера используется C-подобный язык
ForwardCom — это экспериментальная архитектура набора команд, а не просто язык ассемблера. Его нельзя взять и скомпилировать в x86-код (можно только сэмулировать, но толку в этом немного).
А макросы будут.
Макросов точно не будет. Симкод не предназначен для написания ассемблерного кода, он нужен для максимального удобства чтения сгенерированного машинного/ассемблерного кода. Покажите мне хоть один компилятор (C++, Rust или другого компилируемого языка), который бы генерировал ассемблерный код с макросами. В 64-разрядной версии MASM поддержку встроенных макросов (.if, .while, invoke и пр.) вообще убрали.
Тем, что в URL можно указать параметры печати pdf-файла: dpi (разрешение), двухсторонняя печать и прочее.
Можно отследить прогресс печати (очень полезно, если pdf-файл состоит из нескольких сотен страниц, например).
Более того, зайдя в браузере на веб-страницу http://127.0.0.1:950 можно посмотреть состояние принтера и установить какие-нибудь настройки по умолчанию.
Возникла такая мысль/идея про ...
А может попробовать обязать всех авторов сгенерированных посредством ИИ статей указывать точный промпт, который они использовали и название модели [включая версию]? А то вдруг и правда их промпт состоит прям из сплошной экспертизы или автор плохо выражается и нейронка смогла донести смысл лучше, чем оригинальный текст автора.
Таким образом, это позволит более объективно оценить полезность сгенерированной статьи.
Считаю, что стоит распространить это обязательство в том числе на всех уже приглашённых/‘получивших инвайт’ авторов, а также тщательно продумать эту идею, расписать правила публикации таких статей.
Например, в самом начале или конце статьи необходимо добавить спойлер с определённым заголовком, содержащим фразу вроде «Текст получен системой генеративного ИИ». Внутри спойлера указывается название модели и точный промпт.
При создании статьи необходимо будет поставить галочку «Публикация сгенерирована ИИ» [которую можно расположить рядом с галочкой «Публикация является переводом», например]. А сама статья получит плашку/бейджик «Сгенерировано ИИ». И разумно дать читателям Хабра возможность скрывать все статьи с такой пометкой.
А если учесть, что существует англоязычная версия Хабра, то можно попробовать разработать некий международный стандарт, скажем так. Стандарт того, как именно должны быть помечены материалы, сгенерированные ИИ. Это будет полезно не только читателям-людям, но и самому ИИ, чтобы учитывать (или вообще игнорировать) сгенерированный контент.
Ведь очевидно, что его [сгенерированного контента] будет становиться всё больше и больше. И что с этим делать необходимо решать уже сейчас.
Очень интересно услышать название [хотя бы одного] языка программирования, в котором такой код корректен (т.е. где
j— это будет индекс, а не 3-мерный массив).И увидеть рабочий пример, а не просто псевдокод (пусть вместо
DoSomethingToбудет простоprint/Console.Write/echo), на этом языке программирования.Насколько мне известно, таких языков программирования нет.
Но может я чего-то не знаю. :)(:
Ваш код некорректен.
Если
someArray— это 5-мерный массив, тоi— это 4-мерный массив, аj— это 3-мерный массив.И в вызов
DoSomethingTo(j);передаётся не индекс (число), а 3-мерный массив.На 11l в соответствующем коде индекс можно получить посредством записи
L(j).index.Если же «в каждом из них индексация по
i», тогда можно написать так:Очень грустно, что корпорации убедили почти всех пользователей (в т.ч. и вас, похоже), что простейший софт, занимающий гигабайты места — это нормально.
Вы слышали про 3D-шутер размером в 96Кб? Да, там лишь 10 минут геймплея, но используя технологии, на которых он сделан, в пару мегабайт можно поместить геймплея на несколько часов или даже десятков часов, т.е. получить вполне полноценную компьютерную игру.
Так и эти "драйвера" на 1.5 Гб вполне можно было бы уместить в 1.5 Мб. Ведь мышки/клавиатуры/наушники — это же не 3D-видеокарты, для взаимодействия с ними много кода не нужно.
Вы представляете себе, что происходит на самом нижнем уровне при выполнении действия «отключить подсветку у мышки»? Там же никакой магии — нужно просто отправить мышке по USB-шине определённый набор нулей и единиц. Вопрос только какой именно. И эту информацию корпорации держат в секрете. А почему — потому что иначе энтузиасты напишут гораздо менее прожорливую версию софта, предоставляющую к тому же более удобный для пользователей интерфейс, и весь софтверный отдел корпорации окажется не нужен.
Речь идёт о пользовательском опыте. То, что NTFS поддерживает точки монтирования — это замечательно, вот только типичные (и даже продвинутые) пользователи их не используют.
Да, появление
std:generatorв C++ я как-то пропустил.Но судя по страничке Compiler support for C++23
std::generatorна данный момент поддерживается только одним компилятором: GCC 14-й версии, который вышел совсем недавно — 07.05.2024.И скорее всего, реализована эта штука очень неоптимально.
Я написал простейший генератор, который производит целые числа из заданного диапазона:
Не берусь судить об эффективности сгенерированного компилятором кода, но выглядит страшно.
Вообще,
co_yield— это же про асинхронный код. И будет лиco_yieldкогда-нибудь оптимизирован C++-компиляторами для синхронных генераторов — большой вопрос.Добавил в статью "код обхода итератора на том языке программирования, к которому он относится" в спойлере.
И что вы сможете увидеть в этом состоянии?
Ведь имя pdf-файла [
file.pdf] в строкеcat file.pdf > /dev/lpt0никуда не передаётся.Как узнать какой именно файл сейчас печатается?
В случае с HTTP-запросом указать имя файла не проблема:
А если на печать отправляются одновременно два файла [из двух различных процессов]?
Как надёжно сопоставить настройки/параметры печати с соответствующим файлом?
Решение с файлами устройств — оно очень хрупкое.
Я уж не говорю про обнаружение возможных ошибок при печати. Или вы предлагаете добавить ещё и /dev/lpt0_err?
Если pdf-файл банально некорректный, то HTTP-запрос сразу вернёт соответствующий статус (например, 422 Unprocessable Content), а в теле ответа вполне можно поместить подробное сообщение об ошибке (причём на том языке, который был указан в заголовке ‘Accept-Language’ у запроса).
К тому же, печать файла — это длительный процесс. И за время его печати порой требуется отправить на печать ещё пару-тройку других файлов, не дожидаясь окончания печати первого. При этом пользователь может внезапно захотеть отменить печать второго файла до окончания печати первого. «Веб-сервер устройства» для всего этого подходит гораздо лучше, чем «файл устройства».
Вам вообще приходилось читать ассемблерный код? (Я уж не говорю про «писать».)
Или это так, рассуждения из воздуха?
Если приходилось, то будет очень интересно услышать. Именно про ваш опыт. А не просто мнение. Т.к. в русскоязычной среде специалистов по языку ассемблера (не по интринсикам, а именно по машинным командам) буквально единицы, и на Хабре они, увы, не пишут.
Если вам хоть немного интересно программирование на ассемблере, тогда вы должны были читать вот это:
Understanding Windows x64 Assembly
И как думаете, комментарии к каждой строке ассемблерного кода там, они для чего вообще? Так, просто по приколу? Или же всё-таки для улучшения читаемости/понимаемости кода.
Вы вообще представляете, что такое современный x86-64 ассемблерный код?
Посмотрите для общего развития на этот список команд. Одних только команд конвертации (у которых мнемоники начинаются на
cvtилиvcvt) — 82 штуки! И отличаются они между собой порой всего на одну букву. Если ассемблерный код не содержит подсказок/комментариев к каждой строке, то найти в нём ошибку практически невозможно. Поэтому и приходится изобретать язык для таких комментариев. И симкод является попыткой стандартизации такого языка.Уже нету.
В 64-разрядной версии MASM поддержку встроенных макросов (.if, .while, invoke и пр.) убрали.
Т.к ни один компилятор (C++, Rust или другого компилируемого языка) не генерирует ассемблерный код с макросами. А руками ассемблерный код уже давно не пишут. Поэтому макросы и убрали в MASM64.
Нет. C-- это другое. В чём отличие я уже достаточно подробно написал здесь.
Это псевдокод.
Или как вы предлагаете следовало поступить?
Код обхода итератора всегда писать на том языке программирования, к которому он относится?
Не все знакомы с синтаксисом Python или того же Rust.
Поэтому я выбрал что-то среднее между C++/C# и JavaScript, т.к. синтаксис Си-подобных языков знаком большинству программистов.
Уже реализовано в консольной утилите symasm посредством режима
--annotate.Хотя я об этом уже писал в статье, но приведу результат работы этого режима [применительно к примеру с
setg/cmovlиз статьи] для наглядности:А, вы про именованные константы.
Я говорил про макросы в их традиционном понимании (макрос — символьное имя, заменяемое при обработке препроцессором на последовательность программных инструкций).
Насчёт конструкции
eax = BLACK.Сгенерированный компилятором симкод, скорее всего, будет выглядеть как
eax = 0 // BLACKесли в этом месте можно использоватьxor, либо какeax = (0) // BLACK, если нужен именноmov(но такое бывает крайне редко).Данная ассемблерная команда практически не используется компиляторами (при включенных оптимизациях). Поэтому было логично поставить ей в соответствие более длинную симкоманду.
Можно пример?
godbolt.org сопоставляет Сишный код с машинным, а не наоборот.
Именно что симкоманды и исполняет. Можете проверить сами на web-версии консольной утилиты symasm — любой ассемблерной инструкции x86-64 соответствует симкоманда, а любой симкоманде соответствует одна или две ассемблерные инструкции (правда, пока что реализован перевод только в одну сторону).
Если вас смущает фраза «процессор исполняет симкоманды» (или, что то же самое, «процессор исполняет ассемблерные команды»), то, разумеется, это не буквально — процессор исполняет двоичный машинный код, но симкоманды являются прямым отображением этого машинного кода, так же, как и язык ассемблера.
А вот язык программирования Си прямым отображением машинного кода ни разу не является.
Удивительно, что приходится тратить время на разъяснение таких очевидных вещей.
Ладно, я зачеркнул приставку «макро» в определении симкоманды в начале статьи, если она вас так сбивает с толку. Но продублирую информацию из всплывающей подсказки к слову «макрокоманда»:
Формально, макрокоманда — это мнемоническая команда, которая может разворачиваться более чем в одну машинную инструкцию. Однако, фактически, все симкоманды разворачиваются только в одну машинную инструкцию, за исключением лишь симкоманд условных переходов, которые могут разворачиваться в две машинные инструкции.
У вас процессор напрямую Сишный код исполняет?
Да, в процитированном вами предложении перед словом «кода» я не написал уточнение «ассемблерного», т.к. полагал, что из контекста это должно быть очевидно (т.к. статья посвящена языку ассемблера).
Вам разве не доводилось анализировать ассемблерный код, сгенерированный компилятором из программы на Си?
Вот для упрощения такого анализа и предназначен симкод.
Ничего против Николая Васильевича лично я не имею. Нелестно о нём отзывался некто Сергей Николаевич Попов.
А мне понравилась просто эта цитата. Ведь согласитесь, что во время появления Unix мало кто предполагал, что эта операционная система будет использоваться на устройствах размером с блокнот и производительностью десятков мейнфреймов.
А на какой срок занял? До скончания веков, что-ли? :)(:
Кто вообще помнит про этот Plan 9...
Скоро слово "восьмёрка" перестанут ассоциировать с операционной системой Windows 8, т.к. про неё уже забывать начинают (спустя 12 лет после её выхода). А вы говорите про Plan 9, которому больше 30 лет. Да большинство читателей этой статьи ещё не родилось даже во время появления этой ОС.
ForwardCom — это экспериментальная архитектура набора команд, а не просто язык ассемблера. Его нельзя взять и скомпилировать в x86-код (можно только сэмулировать, но толку в этом немного).
Макросов точно не будет. Симкод не предназначен для написания ассемблерного кода, он нужен для максимального удобства чтения сгенерированного машинного/ассемблерного кода. Покажите мне хоть один компилятор (C++, Rust или другого компилируемого языка), который бы генерировал ассемблерный код с макросами. В 64-разрядной версии MASM поддержку встроенных макросов (
.if,.while,invokeи пр.) вообще убрали.Тем, что в URL можно указать параметры печати pdf-файла: dpi (разрешение), двухсторонняя печать и прочее.
Можно отследить прогресс печати (очень полезно, если pdf-файл состоит из нескольких сотен страниц, например).
Более того, зайдя в браузере на веб-страницу
http://127.0.0.1:950можно посмотреть состояние принтера и установить какие-нибудь настройки по умолчанию.