Обдумываю концепцию новой кодировки

Корабль ИИ тоже лучше тебя будет проектировать. Но да, с разморозкой тебя. Мир уже другим стал, просто в РФ из-за ситуации с традиционно-консервативным обществом, ИИ, интернетом и санкциями это не так заметно. Но какой сюрприз будет для экономики через 10 лет! Когда ничто не сможет конкурировать с тем что будет ИИ делать (а делать он будет всё, начиная от аналитики, заканчивая изготовлением лопат) ни по цене, ни по качеству.

Даёшь каждому символу по uuid, ну, или sha512 хеш от svg с изображением символа

Даже в однобайтовых кодировках есть проблема с визуальным различением похожих символов. Но там хотябы небольшое количество вариантов. В нынешнем юникоде с этим вообще труба.

Кроме того, у юникода явная проблема с указанием алфавита на котором пишем. Для машины A латинское и A русское - это разные буквы, хотя для человека выглядят одинаково. Филологи вон до сих пор спорят о необходимом количестве букв для русского языка, хотя во всех вариантах алфавита их всего-то около трех десятков. А в юникод понапихали многие тысячи символов и нет возможности указать на подмножество, используемое в конкретном тексте также как указывают название кодировки в случае однобайтного представления. Причем немало юникодных символов это вообще всякие картинки, к собственно символам отношения не имеющие. С каких это пор изображение кошачьей мордочки стало символом хоть какого-нибудь алфавита? А оно там есть. И возникает вопрос - где кончаются собственно буквы и начинаются картинки? Ладно бы только буквы разных языков в юникод собрали - это еще можно было бы понять например для использования в многоязычных документах. Но когда туда стали пихать картинки то смысл как-то потерялся. Если можно кошачью мордочку то почему нельзя собачью? Или тогда уж всех существующих животных. Абсурд, на мой личный взгляд.

И нет, я не знаю хорошего решения этих проблем.

Задать ограничение на ввод, чтобы нельзя было ввести винигрет

Я когда-то делал такое ограничение даже для кодировки СР866 во времена DOS. Потому что операторы ввода данных регулярно вбивали сходные по начертанию латинские буквы вместо русских. Алгоритм возникновения этой ошибки был простой - начинают печатать забыв переключиться на русский, но обнаруживают это только когда попадается буква которой в латинице нет. Ее - исправляют. А то что успели набрать до этого на латинице но выглядящее как на русском - остается. Обычно одна-две буквы в начале слова. Проблема настолько общая, что в «компьютерных» шрифтах по сей день часто встречается перечеркнутый ноль чтобы с буквой О не путали. Только вот путать О латинское и О русское это не мешает.

Hа кaкoм языке нaпиcанa этa фразa?

Для русского языка человек это может опознать хотябы по внешнему виду. И то не знающий русского может спутать его к примеру с болгарским. А вот европейские языки использующие латиницу так отличить существенно сложнее. Например польский от чешского, особенно если не знаешь ни того ни другого. Потому в дополнение к набору символов нужно условно говоря указание «локали» говоря линуксовыми терминами. Где будет четко обозначено и используемое подмножество если речь идет о юникоде и очередность в алфавите (для сортировки) и правила преобразования заглавных-строчных букв(если применимы) и вероятно еще какие-то местные особенности типа символа местных денег например. Вон сколько глюков в софте из-за того что русская винда по умолчанию любит использовать запятую вместо общепринятой в мире десятичной точки.

Вон сколько глюков в софте из-за того что русская винда по умолчанию любит использовать запятую вместо общепринятой в мире десятичной точки.

Непонятно из каких соображений по умолчанию в локали используется запятая, а не точка. В локали

Корабль ИИ тоже лучше тебя будет проектировать. Но да, с разморозкой тебя. Мир уже другим стал, просто в РФ из-за ситуации с традиционно-консервативным обществом, ИИ, интернетом и санкциями это не так заметно.

ИИ как иструмент интересен, но для предметных областей нет необходимости в обширных возможностях ИИ так как учёного не рационально допускать к чистке картошки.

Буква a, или b или там z имеет одинаковый код хоть в английском, хоть в немецком, хоть в польском,

Букв b или z в русском нет, а вот почему русское «а» имеет не такой код как английское «a» ? Почему английское «a» и немецкое «a» могут иметь одинаковый код, а русское должно иметь другой? Какая логика в этом?

ноль не одинаков с буквой О

Ноль - это цифра, а не буква. Цифры не входят ни в английский алфавит, ни в русский, ни в немецкий. А если следовать логике что английское «а» отличается от русского «а» то тогда и английский ноль должен отличаться от русского ноля.

И да, внедряя юникод пытались избавиться от необходимости явного указания кодировки. Но получили явную необходимость указания локали. Ибо а как иначе например по алфавиту сортировать не зная какой алфавит используется?

Обязательно разработаю, но пока не мало более приоритетных задач.

Немного расскажу какую архитектуру об архитектуре односимвольных кодировок, которую разработаю.

Например в кодах кодировки не должно быть использованы коды для заглавных букв вовсе.
Для этого рационально использовать значение управляющего бита.
Это упростит и саму кодировку и эффективно решит задачу замены в тексте прописной буквы на заглавную и наоборото.

Остальное домыслите сами.
Пост был о том, что в коде буквы должно быть указание на тип кодировки и некии битовые флаги.
Что касаемог типа кодировки, то старший бит должен указывать на тип кодировки.
== 0 - код кодировки относится к множеству наиболее импользуемых.
== 1 - код из множества прочих кодировок.
Это позволит съэкономить количество бит используемых для указания типа кодировки (тип кодировки
может иметь разную битовую длину).

чтобы даже l (эль) и 1 (единица) имели некую общую часть кода

Спорно. Ибо одно - буква и входит в алфавит заданного языка, а другое - цифра и в алфавиты языков она не входит.

Спорно. Ибо одно - буква и входит в алфавит заданного языка, а другое - цифра и в алфавиты языков она не входит.

Среди типов кодировок должна быть «специальная».
В неё рационально поместить например цифры и … Таким образом упростится например задача анализа цифра это или буква.

В неё рационально поместить например цифры и …

Таким образом упростится например задача анализа цифра это или буква.

Ныне в кодировках каша-малаша.
Проще говоря - бардак.

Напиши туда где госты делают. Вдруг они тебе за работу платить начнут.

Напиши туда где госты делают. Вдруг они тебе за работу платить начнут.

Не рационально вовсе.
Там обязательно есть «кот учёный», который ходит вокруг дерева по цепи златой.
Толку никакго не будет.
Бороться в ветряными мелницами не мой путь.

Бороться в ветряными мельницами не мой путь.

Просто сделаю, но ныне занимаюсь более приоритетными задачами.

Немного пошучу.
Ныне в кодировках столько не нужного хлама, что в коде буквы вполне можно разместить два кода.

храни все символы как uint32_t

Я вот тоже думаю что сейчас нет смысла упарываться в экономию байтов при кодировании символов. Ожирение софта вовсе не из-за формата хранения символов происходит. Поэтому 32-битные символы фиксированной длины выглядят вполне разумными так как в первую очередь упрощают обработку делая ненужной всякую «нормализацию» (термин из стандарта юникода). А также и склейку символов - можно все варианты отдельными символами закодировать. Особенно если перестать пихать в таблицу символов всякие картинки. Удивительно как еще хозяевам юникода не пришла в голову идея засунуть туда потреты разных исторических личностей - для использования например в подписывании цитат.

А думать надо над тем где и как в тексте указывать ЛОКАЛЬ в которой его следует интерпретировать. Для однобайтовых кодировок указание кодировки само по себе неявно указывало на локаль - к примеру CP1251 достаточно однозначно указывало на RU. Сейчас же вместо этого к примеру в почтовых письмах указывается безликое UTF-8, не несущее информации о том как именно надо интерпретировать написанное принимающей стороне - к примеру какой шрифт использовать при отображении. Или при поиске какое соответствие букв верхнего-нижнего регистра использовать чтобы находились и слова, написанные с заглавной буквы.

Можно сделать двумерные UTF-8 строки

Компьютерная память всё равно обычно выглядит как одномерный массив байтов так что от такой псевдо-двумерности особой пользы не будет. Да, сколько-то байтов сэкономится, но сильно усложнится обработка. Там же не памяти мало (микроконтроллеры) - можно продолжать использовать классические однобайтные кодировки, что собственно и делается. И даже в железе гвоздями прибито - например для знакосинтезирующих индикаторов примерно всегда байт=символ=знакоместо.

а где нужен доступ по произвольному индексу?

Могут быть строки данных фиксированного формата. Вспомним например набивку текста на перфокартах с заданных фиксированных колонок. Откуда пошли «файлы из записей» фиксированной длины и с фиксированным расположением данных - как в dbf например.

ИИ будет писать на чем угодно лучше и быстрее ?

Спорное утверждение. Чтобы ИИ начал на чем-то писать - его надо обучить на уже написанном людьми. Если люди на каком-то языке написали только говнокод то ИИ будет писать его же.

Просто сделаю, но ныне занимаюсь более приоритетными задачами.

Полезно посмотреть hbapicdp.h.
В нём есть здравые мысли.

// Данные о кодовой странице
//
typedef struct META_CODEPAGE__ {

  CHAR            *ID;                                       // ID code page (название)
  CHAR            *Info;                                     // Комментарии о назначении кодовой страницы
  META_UNITABLE_  *pUnicodeTable;                            // Ссылка к UNICODE table
  BYTE            *FlagsChars;                               // Адрес где находятся массив flag  chars
  BYTE            *FlUpperChar;                              // Адрес где находятся массив upper chars
  BYTE            *FlLowerChar;                              // Адрес где находятся массив lower chars
  BYTE            *Sort;                                     // Адрес где находятся массив s_sort, используемый для сортировки символов
  BYTE            *Acc;                                      // 
  int             cntACSort;                                 // 

  int             Type;                                      // #define META_CDP_ISBINSORT(  cdp )  ( ( (cdp)->Type & META_CDP_TYPE_BINSORT ) != 0 )  // Codepage uses simple binary sorting
                                                             // #define META_CDP_ISCUSTOM(   cdp )  ( ( (cdp)->Type & META_CDP_TYPE_CUSTOM  ) != 0 )  // Codepage uses custom string decoding
                                                             // #define META_CDP_IScharIDX(  cdp )  ( ( (cdp)->Type & META_CDP_TYPE_CHARIDX ) != 0 )  // Codepage use character indexes instead of bytes ones
                                                             // #define META_CDP_IScharUINT( cdp )  ( ( (cdp)->Type & META_CDP_TYPE_CHARUNI ) != 0 )  // Chr(), Asc() and similar functions operates on Unicode values instead of bytes
                                                             // #define META_CDP_ISUTF8(     cdp )  ( ( (cdp)->Type & META_CDP_TYPE_UTF8    ) != 0 )  // Codepage использует UTF-8 кодировку
                                                             // #define hb_cdpGetID(         cdp )  ( ( cdp )->id )

// Функции для работы с TCHAR символами
//
  PMETA_CDP_GET_FUNC    FuncWCHARGet;                        // Адрес функции, производящей получение символа
  PMETA_CDP_PUT_FUNC    FuncWCHARPut;                        // Адрес функции, производящей запись символа
  PMETA_CDP_LEN_FUNC    FuncWCHARLen;                        // Адрес функции, возвращающей размер символа
  PMETA_CDP_UPPER_FUNC  FuncWCHARUpper;                      // Адрес функции для конвертирования символа к upper
  PMETA_CDP_LOWER_FUNC  FuncWCHARLower;                      // Адрес функции для конвертирования символа к lower
  PMETA_CDP_FLAGS_FUNC  FuncWCHARFlags;                      // 
  PMETA_CDP_CMP_FUNC    FuncWCHARCmp;                        // Адрес функции для сравнения символов
  PMETA_CDP_CMP_FUNC    FuncWCHARCmpI;                       // Адрес функции для сравнения символов без использования case

  int                   cntMulti;                            // 
  int                   cntMultiUC;                          // 
  META_MULTIchar_       *pMultiChar;                         // 

  void                  *Buffer;                             // 
  META_CODEPAGE__       *NextCodePage;                       // Ссылка к следующей code page

} META_CODEPAGE_;                                            // typedef struct META_CODEPAGE__ {

ничего кроме utf8 в мире нет.

Во-первых классические однобайтные кодировки никто не отменял - они используются там где они оптимальны. Во-вторых «нет» это совершенно не значит «не будет». Ибо в существующим виде у юникода уж очень много недостатков.

Рендереры юникода сейчас уже написаны

И работают плохо как только попадается что-то экзотическое хотя и допустимое в рамках стандарта.

концепция байта кажется весьма устаревшей. 8 бит в которые пытаются впихнуть всё

Есть области где деление памяти на восьмибитные байты действительно уже не актуально. К примеру DSP обычно оперируют более многоразрядными сущностями, именно как неделимыми. Также существуют процессоры, требующие обязательного выравнивания данных по границам в 16 или другое число бит, в противном случае у них аппаратное исключение по ошибке доступа к данным случается. Это x86 в силу древнего легаси имеет возможность обратиться отдельно к любому произвольному байту в памяти. Да и то с точки зрения электронной схемы он при этом больше чем один байт из микросхемы памяти считывает.

Битовое поле произвольной длины как-то лучше

Сомневаюсь что переменная произвольна длина это хорошо - может сильно усложнить и замедлить обработку. А вот сделать компьютер, оперирующий 32-битными сущностями как единым целым, без деления на восьмибитные байты - это может быть разумно. Заодно сохранится изначальная идея языка Си - где «символ» это минимальная единица обработки. Кстати обратите внимание - именно символ, char, который в общем случае не обязан быть восьмибитным. К примеру в оборудовании связи когда-то встречались 5-битные символы (в телетайпах), почему бы не появиться и 32-битным?

Отчего память сразу не ассоциативная

Вот тут сомневаюсь что это будет просто реализовать в железе и еще больше сомневаюсь что это будет быстро работать.

Ни одна из задач работы со строками не предусматривает доступ к произвольным символам строки

Слишком категоричное утверждение. По сей день существуют огромные массивы данных, представляющих собой «записи фиксированной длины», содержащие в том числе и текстовые данные, начинающиеся с заданных позиций. Если используемый для их обработки язык умеет хранить строки только как utf8 и мы прочитаем данные с соответствующим преобразованием то как будем вычислять нужную позицию в полученной юникодной строке для последующего разбора ее на части?

Как минимум этого требует рендер

А рендеру требуется знание локали в которой текст следует интерпретировать. Хотябы даже например для того чтобы знать в какую сторону на этом языке пишут - вдруг справа налево(иврит) или сверху вниз(некоторые иероглифические письменности).

Рано ещё для ОС.

Подозреваю что с подешевением доступа к ИИ написание своей ОС станет вполне посильной задачей даже для одного человека. Чисто по объему кода посильной имеется в виду. Сейчас чтобы написать более-менее полноценную ОС нужны годы если в одно лицо, а может быть так что потребное время сократится до месяцев.

Чтобы нормально его отрендерить, нужно выбирать шрифт в соответствии языку.

Юникод избавил от необходимости указывать название кодировки но привел к необходимости указывать название локали. Хрен редьки не слаще.

У «M» и «М» заглавные буквы ещё похожи

Они не просто похожи, они идентичны. Поэтому если станут одним символом во всех языках где идентичны - ничего плохого в этом нет. Используют же английский и немецкий одно и то же «M». Почему бы и русскому не использовать если он такое же. А вот «m» и «м» - визуально отличаются и они должны быть разными символами.

Не будет ИИ писать лучше

уже пишет

Чем человек, учивший программирование четверть века назад в вузе в качестве непрофильного предмета и изрядно забывший даже то что учил - да, может быть.

и быстрее.

А вот это может быть. Принцип «тяп-ляп и в продакшн» - в действии. :(

выделить его на операцию переключения кодировки, наступил на такой, значит следующие 2 байта номер кодировки в которой дальше идет текст

Только «номер кодировки» я бы заменил на «идентификатор локали». А кодировку оставить хоть тот же юникод раз он достаточно распространён - для большинства языков 256-символьного подмножества юникода будет достаточно. Китайцам придется всё равно использовать двухбайтные символы увы.

Букв b или z в русском нет, а вот почему русское «а» имеет не такой код как английское «a» ?

Потому что это разные буквы.

Почему английское «a» и немецкое «a» могут иметь одинаковый код

Потому что это одна и та же буква. Английский и немецкий используют латиницу для письменности.

В языке нет никаких букв, только звуки. Буквы есть в письменности. Язык может использовать одну или несколько систем письменности. Например, в сербском используют и латиницу и кириллицу. Помимо латиницы и кириллицы есть ещё греческий алфавит, еврейский, арабский, деванагири, грузинский алфавит, армянский, хангыль, китайские иероглифы (они же кандзи в японском), катакана, хирагана и прочие. Все они разные и имеют разный набор букв (или иероглифов в случае с китайским или там древнеегипетским), хотя некоторые буквы внешне друг друга напоминают. Например, a и а выглядят очень похоже, во многих шрифтах даже идентично, а греческая α уже просто похоже. K и К — просто похоже (а в ленивых китайских говношрифтах могут выглядеть даже идентично), R выглядит похоже на перевёрнутую Я, и так далее. Но это разные буквы из разных алфавитов.

От языка это не зависит и никогда не зависело, это зависит от используемой письменности. Не нужно путать одно с другим.

И да, внедряя юникод пытались избавиться от необходимости явного указания кодировки. Но получили явную необходимость указания локали. Ибо а как иначе например по алфавиту сортировать не зная какой алфавит используется?

Всё верно. И это правильное решение. Как правильно сортировать, может зависеть от языка, хотя в большинстве случаев это в принципе не особо критично. В основном дело в диакритике и всяких хитрых значках. Например, немецкое ß это ss. Его после s ставить, перед s, или вообще в самый конец уже после z, в области других хитрых значков? А вот непонятно, и как правильно, говорят правила конкретного языка. Здесь проблема не в кодировке или юникоде, это проблема в принципе языков с дополнительными символами и диакритикой и отсутствия стандартов в этом плане — она существовала и до юникода и даже до компьютеров: прежде, чем печатать словарь или там телефонный справочник, где есть сортировка по алфавиту, для языка со всякими хитрыми значками придётся узнать правила сортировки, даже если он использует тот же алфавит, что и твой родной язык.

Нахера ему локаль?

Логичнее делить такие данные на поля в форме байт. Обработка байтовых данных поддерживается в любом языке.

написать более-менее полноценную ОС нужны годы

Зависит от задач. Допустим написать мобильную ОС под конкретный CPU, к которому подключен конкретный LoRa модуль, конкретный OLED дисплей и конкретный ведомый к основному CPU GSM чип (в котором уже будет своя ось, поэтому будет ведомым) это одно. И совсем другое пилить массовую, универсальную ОС под всю перефирию на свете.

Причём ИИ и правда облегчает задачи пограмиста и ускоряет разработку. Поэтому запилить можно очень быстро. Он мне за пару часов набросал конкретные чипы и конкретную их стоимость для разработки выше приведенного девайса. Плюс посчитал цену всей обвязки к ним. В гугле я бы неделю рылся.

Undo-redo

свертывание кода

Вот эти две задачи никакой задницей не являются. При правильной архитектуре редактора откат-переоткат внесенных изменений и манипуляции отображаемой на экране информацией делаются тривиально.

Но да, с разморозкой тебя

Сейчас ИИ довольно сомнителен в плане написания полноценного кода без участи погромиста. Иначе, я уже говорил выше, где все уволенные разрабы гугла, айбим, мелкомягких и т.д.? Сможет ли ИИ работать в одно рыло пока неизвестно. Я бы не доверил ему разрабатывать вещи от которых может зависить жизнь на текущем этапе развития. Даже под контролем человека.

А вот находить ошибки в коде, это очень крутая штука. В моём ЯП фактически ИИ будет следить за освобождением памяти/ресурсов на этапе компиляции, что позволит полностью отказаться от GC.

Корабль ИИ тоже лучше тебя будет проектировать

Так мои хотелки я ему всё равно задам. Так что проектировать будем в паре )

Нахера ему локаль?

Потому что как выше заметили начертание одинаковых букв в разных языках может несколько отличаться. А уж иероглифов тем более. В результате невозможно правильно отобразить произвольный юникодный текст не зная на каком он языке, то есть надо знать правильную локаль.

первый байт (в самой строке) определяет тип кодирования.

то есть если ты его потерял, то опачки, кина не будет.
итого - utf8 сетевая, устойчивая к сбоям, против твоей, построенной на железобетонных гарантиях.
которые хрен его знает где взять в этом беспокойном мире.
а так-то дааа, размер один байт это лучше чем много байт.

пилите, Шура, пилите…. (с)

Допустим написать мобильную ОС под конкретный CPU, к которому подключен конкретный LoRa модуль, конкретный OLED дисплей и конкретный ведомый к основному CPU GSM чип

Лично я бы не назвал это «операционной системой». Раньше для такого употреблялся термин «программа-монитор», к примеру так оно называлось на компе «Радио-86РК». В моем представлении ОС всё же предполагает некоторую универсальность решаемых задач, пусть даже и на одном железе. MS DOS как пример - вне архитектуры IBM PC она не существовала в отличие от допустим линукса. Тем не менее была операционной системой достаточно общего назначения, способной запускать большое количество самого разного софта.

Причём ИИ и правда облегчает задачи пограмиста и ускоряет разработку

Вот и я о том же - это именно еще один инструмент эффективного ускорения разработки. Также как когда-то ее ускорили IDE, интегировавшие в себе компилятор, отладчик, специализированный редактор и справочник по языку.

Он мне за пару часов набросал конкретные чипы и конкретную их стоимость для разработки выше приведенного девайса. Плюс посчитал цену всей обвязки к ним. В гугле я бы неделю рылся.

Насчет выбора чипов - мысль интересная. Всё жду когда станет свободно доступен какой-нибудь ИИ, способный генерировать электронные схемы по текстовому заданию. Пока что увы не попадалось в свободном доступе даже чего-нибудь, способного выполнить простейшее задание типа «нарисуй мультивибратор». Хотя наверно если модели при обучении скормить огромный объем файлов с нетлистами то она научится рисовать схемы. Ну пусть не как картинки, а генерировать нетлисты которые можно потом отобразить специализированным софтом. Тем более что уже существуют весьма продвинутые средства проверки правильности схем, которые можно использовать в процессе обучения.

А вот насчет цен - сомнительно. Слишком уж это непостоянная и непредсказуемая штука. С момента обучения модели они могу сильно поменяться.

С момента обучения модели они могу сильно поменяться

Она в гугле их ищет или ещё где, цены из реального мира, а не из обучения. Чипы отчасти тоже ищет в гугле.

то есть если ты его потерял

Зачем коррекцию ошибок вытаскивать с уровня протокола на уровень кодировки строк? А на диске делай бекапы, а не тащи коррекцию ошибок на верхний уровень.

переменная произвольна длина это хорошо - может сильно усложнить и замедлить обработку

а зачем в языке программирования (а ТС вроде как язык делает) разрядность ? Пусть компилятор/интерпретатор встаёт на уши и впихивает код в ограничения инструкций. Аппаратно сделать полный или хотя-бы достаточный набор volatile-length инструкций сложно, но реализуемо. Отчего нет? может это наоборот много чего дико ускорит. Никто-же не пробовал. Хорошей команде взять FPGA и академично наваять. Только за чей счёт праздник жизни

Вот тут сомневаюсь что это будет просто реализовать в железе и еще больше сомневаюсь что это будет быстро работать.

не сомневайся ;-) оно реализовывалось и реализуется..

на заре эпох были ЭВМ где ассоциативка была основной, сейчас узко-специализированно но с запросами на AI сектор скорее будет «ширеть» чем наоборот.

поиск по быстрому выдаёт например https://www.amd.com/en/products/adaptive-socs-and-fpgas/intellectual-property... , но вообще должны быть у многих производителей и с разными дисциплинами для разных назначений

Почему бы и русскому не использовать если он такое же но привел к необходимости указывать название локали.

сам же ответил почему. Это какая-то оптимизация на спичках, которая приводит к попыткам угадать какое начертание использовать в зависимости от локали. Хотя в том же utf-8 дохренище свободных кодов, что бы влезли все символы живых языков, да и не очень живых. Да, та же «М» может в зависимости от шрифта выглядеть отлично для русского и английского. Понятно ли будет, что это «м» - да, но не красиво. Твиттер например любит путать русский и болгарский и в итоге вроде прочитать можно, но сразу понимаешь что что-то не то. Примерно как в различных азиатских шрифтах приводит сделаны русские символы (да и английские зачастую), сразу в глаза бросается.

Сортировка, направление письма и подобное, да, без локали не разберешься. И наверно лучше было бы если бы было зашито в кодах символа, а не прилетало снаружи

еще и картинки нельзя вставить в код. и сделать обтекание текста, и цвет букв задать для абзаца…

это ж блин редактор кода. на нем надо программы писать а не иероглифы корябать

Сейчас ИИ довольно сомнителен в плане написания полноценного кода без участия погромиста.

Текстовый редактор еще более сомнителен без участия программиста, несмотря на то что сейчас в текстовых редакторах есть весьма продвинутые функции автодополнения. Однако никто не предлагает отказаться от текстовых редакторов и набивать код электромеханическим перфоратором на перфокартах. Также и ИИ можно рассматривать как очень продвинутую функцию автодополнения. И естественно человеку всё равно придется проверять что оно там надополняло. Не вижу принципиальной разницы между командой «вставь мне сюда оператор if», и командой «вставь мне сюда функцию, принимающую такие аргументы и делающую <что-то>». В обоих случаях надо проверить что же оно сделало. Однако такая автоматизация избавляет человека-программиста от ручного наколачивания прежде всего очевидного и шаблонного кода, на что уходит куча времени. Поэтому человеки давно уже приспособились копировать похожие куски кода и их править по месту. Нередко забывая что-нибудь поправить после копирования. Есть шанс что ИИ забывать и путать будет реже. Да и вообще весьма большой процент кода составляют совершенно «не творческие» шаблонные конструкции. Как пример - типичный набор действий при открытии файла. А еще у ИИ даже в нынешней его реинкарнации чат-бота удобно спрашивать примеры кода как что-нибудь делать - вместо долгого и нудного гугления. Причем не факт что нагуглится именно «лучшая практика». Это особенно актуально для того, у кого написание кода не является основным родом деятельности, а лишь одним из используемых инструментов решения его прикладных задач. К примеру в науке такое часто встречается.

Ну и понятно что надо осознавать границы применимости любого инструмента - в том чисел и ИИ. Если я попытаюсь обычным мультиметром измерить переменное напряжение с частотой сотни килогерц - он мне ересь покажет. Но это совсем не отменяет полезности мультиметра в границах его осмысленного применения.

Она в гугле их ищет или ещё где

Вот именно что возникает вопрос с авторитетностью источников.

цены из реального мира, а не из обучения.

Оно вам это как-то гарантирует?

зачем те бе ваще утыкаться в октеты

твой сырец это последовательность бит для однозначности либо дерево Хэминга либо арифмитическое либо вариант Лемпеля-Зива на выбраном начальном словаре

в чём ваще затруднение то?

обьективно ms(pc)dos это была либа на 21h ну и типо какой ни какой драйвер fc а в виду отсутсвия какой либо апаратно-программной защиты (где-то до 90 ваще а полноценно тока в xp)

дос не был операционой системой - скорее операционой оболочкой

но кто будет ibm опровергать :) ?

Хорошей команде взять FPGA и академично наваять. Только за чей счёт праздник жизни

За счет энтузиазма тех кому это интересно. Вон тут была недавно новость что 80386 отреверсили, и топологию и микрокод. Именно на энтузиазме. За деньги такое никто не делает потому что нет «дураков» выделять на это деньги.

Вообще-то давно уже пора бы заняться придумыванием более оптимальной архитектуры ЭВМ чем «потомки» ibm pc с огромной кучей легаси и костылей, да еще со всякими intel me.

определись с форматом составного файла

ну там таблицами разными под разные задачи например например

свёртка имён в номера вхождений в словаре(динамическом) для рефакторинга твоем редактором пригодится

так и алфовит тоже слова бит отображаемые в глифы

так что в хедере файла первая четвёрка ниблов обозночает файл твоего ТМ формата а дальше

если база то одного бита достаточно - если изыски то твои версии форматов

успехов

таблицами разными под разные задачи

если матом на подчиненного накричать то одна таблица, а дисер написать - другая.

одобряю.

Хотя в том же utf-8 дохренище свободных кодов, что бы влезли все символы живых языков, да и не очень живых

Так в том-то и дело что видя юникодный символ «A» но не имея информации о локали - мы не может сказать к какому языку он относится. Без локали мы можем только нарисовать его на экране если есть шрифт в котором есть символ с таким кодом. И как вы правильно заметили, в зависимости от языка начертание может слегка отличаться даже для символов латиницы, не говоря уже о всяких иероглифах. Мы даже не можем сказать буква это или вообще не буква. Латинское «I» и вертикальная палочка, коих в юникоде даже не одна, могут на экране выглядеть одинаково. Тоже самое с «О» и разными кружочками. А программа не зная в какой локали это было написано не может понять что это такое и как с ним следует обращаться.

Для однобайтных кодировок само указание названия кодировки(например как в почтовом письме или в заголовке страницы сайта) фактически указывает используемую локаль. В случае юникода стали указывать просто utf8 и информации о локали нет. А она - необходима. Причем безотносительно того, совмещаем ли мы одинаковые буквы для разных языков или нет. Или придется английское,немецкое,французское и прочие варианты бувы «A» делать символами с разными кодами. А пока мы имеем то что имеем - твиттер путает русский с болгарским. Кстати, «болгарское А» и «русское А» - это один и тот же код символа или нет? Я увы не знаток болгарского.