Давайте начнём с того, что выше я критикую Юникод как инженер, а не как лингвист. Критикую, причём, в порядке чисто душу отвести, потому что хоть это и плохо продуманная хрень, малопригодная для проектирования регистронезависимых ФС (это ведь становится проблемой именно из-за Юникода, а не потому, что регистронезависимые ФС в принципе плохая идея), но она с нами, увы, надолго. Я не представляю, что должно случиться, чтобы на этом этапе кто-то реально сломал весь имеющийся софт и библиотеки. Поэтому и надо было семь раз отмерять на стадии дизайна.
Так вот, почему с меня вы спрашиваете «полный список правил латиницы»? Я написал, что все языковые преобразования (смена регистра, например) должны быть внешними таблицами [символ, символ]. Полный комплект этих таблиц применительно к символам латиницы и даст нам, как вы его назвали, «полный список правил латиницы».
На практике это означает, что ответ на вопрос, считать ли турецкую i латиницей, зависит от возможности однозначного преобразования через эту внешнюю таблицу.
По-моему, это попытка заменить исходную трудную задачу своей, более лёгкой. Поддерживать прогресс (появление новых символов) так или иначе надо, Юникод с этим справляется, значит и любой альтернативной системе придётся.
Почему надо? А как быть с символом ₽, например? Который появился значительно позже Юникода (официальное утверждение произошло 11 декабря 2013 года). Механизм пополнения должен быть. А если есть механизм, то почему его не использовать для смайликов?
Это инженерный взгляд. А есть ещё юзерски-потребительский: система без смайликов просто будет мертворождённой.
Недавно я прочитал статью Парадокс Ньюкома и искусственный интеллект
Тоже прочитал. По-моему, решается этот парадокс так: логически непротиворечивая ситуация натягивается на законы физики нашего мира, которые не обязаны быть совместимыми с каждой логически непротиворечивой ситуацией, отсюда и ощущение парадокса. Если физическая реальность описывается MWI (как верю я), то какой может быть предсказатель в ньюкомбовском смысле? Будет спектр всех видов предсказателей и спектр всех видов игроков, на пересечении которых воплотятся все возможные комбинации.
Удивительно, что Ньюкомб был физиком. По идее, физик должен бы понимать такие вещи. Даже если не верить в MWI, разница между логикой и физикой никуда не денется.
А когда поверх псевдопарадокса накручивают ИИ, это уже полная сагража.
А по-моему, в каждой идее есть здравое зерно, и есть злоупотребления.
Когда профессор жалуется, что для организации международной конференции ему приходится спрашивать приглашаемых, как часто они ****** в **** (реальное положение дел в прошлом году, между прочим! Т-Инвариант рассказывал) — это злоупотребление.
А когда кто-то хочет иметь смайлики для своего оттенка кожи и не хочет, чтобы они чем-то выделялись даже технически — это здравое зерно. Потому что слишком часто это заканчивается отдельной комнатой.
Я понимаю, что DEI-дураки всех достали, но и в расизм скатываться тоже считаю неправильным.
Я не знаю, в чём замутка конкретно с турецким языком, но как инженер рассуждаю так. Если символ национального алфавита следует ВСЕМ правилам латиницы, включая инверсию капитализации — значит, это символ латиницы. Если же у него есть какие-то особенности — значит, это уже новый символ, произошедший от латиницы. Иными словами, если «адская избыточность» нужна чтобы устранить неоднозначность — это никакая не избыточность.
Об этом не думал, но, по-моему, место этой логике именно в шрифтах / системах вывода. Сейчас вон есть программерские шрифты, которые выводят <= и >= лигатурами (как в учебниках математики). Баловство, конечно, но если бы для меня было важно такое отображение, я бы поставил именно шрифт, а не ожидал новых языков программирования. Соответственно, и для родного языка придерживался бы такой же логики.
Юникод вообще по хорошему нужно полностью переделать с нуля
1. Выкинуть кодепоинты на помойку, как не оправдавшую себя абстракцию. Положить в основу системы символы. Составить список всех символов, каждый символ должен иметь строго уникальный код.
2. Сделать две кодировки: 8-битную и 32-битную (64 бита оставить про запас).
2a. 8-битная кодировка должна быть обратно совместимо с ASCII (как UTF-8), но, в отличие от UTF-8, кодировать символы, а не кодепоинты. Кроме того, её ёмкость изначально должна быть потенциально бесконечной (N байтов при N > 6 (скажем, N = 10) могут кодировать один особо редкий символ).
2b. 32-битная кодировка должна иметь фиксированную ширину. Что будет, когда мы исчерпаем 4 миллиарда символов? А что будет, когда Солнце превратится в красного гиганта? Когда-нибудь, наверно, придётся об этом подумать, но нескоро. Кроме того, даже когда этот вопрос станет актуальным, 32-битную кодировку можно будет продолжать использовать как подмножество бесконечного множества 8-битной.
3. Группы символов строим, соблюдая баланс между запасом индексов для будущих символов в группе и оптимальностью хранения (чтобы как можно чаще влезать в 2 байта). Приоритет отдаём реально часто пополняемым группам. Запас под смайлики должен быть >> размера группы верхне-древне-пышминского алфавита (тот может идти несколькими группами и требовать хоть шесть байт на символ).
3a. DEI-символы изначально ставим вразброс, чтобы добавление смайлика с новым оттенком кожи, идущего не подряд, не несло намёка на сегрегацию.
3b. То, что рано или поздно произойдёт переполнение каких-то групп, изначально считаем неизбежностью и не паникуем.
4. Преобразования регистра делаем внешней таблицей. Она должна быть строго однозначной. Это решит все проблемы, описанные в письме Линуса. Если понадобятся иные языковые преобразования, так же делаем их строго однозначными внешними таблицами.
5. Начертания (weight'ы, измеряемые в сотнях, курсивы, small caps'ы) в общем случае оставляем шрифтовикам. В частном же случае, при включении их в группы символов, считаем это языковыми преобразованиями и делаем внешней таблицей (см. 4). То есть, преобразование Cats are nice → ᴄᴀᴛꜱ ᴀʀᴇ ɴɪᴄᴇ должно универсально и однозначно работать для любого языка. В отличие от Юникода, такие апдейты таблицы символов должны происходить одновременно для всех алфавитов (а то для латиницы всё всегда есть, а для кириллицы или греческого small caps'ов, например, некомплект).
Возможно, вы не понимаете. С этой гипотетической системой я бы, поскольку мне название фоток не нужно, колонку «Имя» удалил, а вы бы, если оно вам нужно, оставили бы. И каждый был бы счастлив.
Приложения, поддерживающие такую ФС (например, камера), либо имели бы констрейнты к схеме (требовали наличия заданного набора полей), либо поддерживали настройку записи метаданных (в какое поле что писать). Первые — для тех, кому надо, чтоб просто работало. Вторые — тем, кому надо гибкие настройки. Как, собственно, и сейчас происходит.
Аналогично с «Жанром». Если вам надо теги — делайте колонку «Жанр» со строкой плоского текста и пишите через разделитель. Или сделайте мультистрочную колонку. Или ссылку на справочник с множественным выбором. (Надеюсь, не надо рассказывать, как это выглядело бы на уровне UI файлового менеджера? И что юзеру даже не надо было бы напрягать бедную головушку и разбираться, что такое «справочник»). А меня в качестве поля «Жанр» вполне устроил бы скромный выбор из трёх перечисленных вариантов с возможностью не выбирать. Или нет. И тогда, если передумал бы, я бы всегда мог сделать теги.
Для меня, например, очевидно, что это не очень удачная (по ограниченности ресурсов в прошлом веке) попытка создать именно тот уровень, о котором Вы написали выше.
Как же я рад, что хоть кому-то это очевидно.
Я вообще мечтаю о том, что в один прекрасный день всё это говно мамонта, придуманное до моего рождения, заменят, наконец, ФС, спроектированные с нуля. В которых примонтированный раздел будет представлять собой иерархическую реляционную базу, data stream'ы — БЛОБы, программное обращение к которым будет осуществляться строго по id, а созданную по умолчанию колонку «Имя» (имя файла) пользователь при желании сможет вообще удалить.
Потому что: ну вот, примонтировали раздел для хранения фоток — и зачем там нужны имена файлов? Фотке нужны колонки «Дата съёмки», «Модель камеры» или «Жанр» (enum [Портрет, Пейзаж, Макро]). Но имя совершенно не нужно. По факту, туда, в общем-то, и пихают дубли даты или ещё чего-нибудь.
В результате мы видим, что абстракция «регистронезависимая строка Unicode» представляет из себя говно.
Ох, нахватаю я сейчас минусов… но давайте зрить в корень: абстракция «Unicode» представляет собой говно. Один лишь факт, что в ней есть нормализация, делает её технически малопригодной для многих областей, например, для проектирования ФС. И если ещё попытаться поверх навертеть абстракций типа регистронезависимости, получится совсем уж печально. О чём в письме и речь.
Ну а то, что ни одна кодировка, даже UTF-32, не позволяет рассчитать смещение адреса по индексу символа, показывает всю альтернативность одарённости дизайнеров. И делает UTF-32 скорее не кодировкой Юникода, а агитационным материалом для тех, кто не любит UTF-8: смотри, мол, брат, насколько всё может быть хуже.
В качестве гипотезы: чтобы пользователи не путались в своих папках Documents, documents, DOcuments и т.д. Как показывают опросы, свинарник в названиях и структуре — правило, а не исключение.
И да, можно это делать на уровне файлового менеджера, однако, как я подозреваю, сюрпризы от этого станут реже, но злее.
Может, вынести в отдельный слой, и показывать сверху? (Прыгающая строчка у вас вдобавок ломала лэйаут, поскольку изменялся размер контейнера карточки). Например, вот так:
С пояснениями:
Но не факт, что удастся универсально сверстать подо все магазины. Надо, чтобы наш слой был обрезан по границам контейнера карточки. И чтобы это смотрелось везде хорошо )) Если не получится, то можно сделать просто нашлёпку в виде round rect в правый верхний угол с ценой, плюс outline со стилем dashed вокруг карточки самого выгодного товара.
лишь малая часть опрошенных тщательно поддерживает порядок на своих рабочих машинах
Здравствуйте, это группа анонимных опрошенных? Меня зовут ███████ и я алкоголик поддерживаю порядок на своих рабочих машинах и составляю малую часть. Более того, пока любимый Майкрософт не начал творить всякую дичь на моём компьютере (типа папки Inetpub в корне без IIS), я примерно представлял откуда взялся каждый файл, а не только созданные лично мною.
Сначала компьютеры не поддерживали ничего сложнее командной строки, просто потому, что у них не хватало на это ресурсов.
Затем появился GUI, и стало можно не запоминать ключи вида -rf -yes -thousand-times-yes -port:1488 -say-hi-to-my-nana, а видеть все опции перед глазами, нащёлкивая чекбоксы и радиокнопки.
Затем инженеры решили, что просить много денег за щелчки по чекбоксам и радиокнопкам — полный бесперспективняк, и вернулись к пропаганде командной строки.
Затем захотелось как-нибудь одновременно оставить командную строку, чтобы шугать нубов, но не запоминать ключи и не курить маны, потому что теперь уже у юзеров не хватало на это ресурсов. И на помощь пришли чатботы.
→ Вы находитесь здесь ← Самому интересно, какой безумный зигзаг выпишет завтра эволюция нашей любимой айтишечки.
Как же понимаю. Я ошалел, когда поставил этот их вскод и увидел, до чего додеградировали IDE, пока я ругался на каждую новую версию студии. Меню, тулбары и причаливаемые панели. Верните их, гады! (крик в пустоту)
Злые языки говорят, это чтобы smart asses не тратили вхолостую трафик на ПиСи с юблоком, а смотрели на телевизоре через приложение с рекламой. А пока ты смотришь телевизор, телевизор будет смотреть тебя. Что им, как рекламной компании #1, тоже на руку.
На фоне безумия, связанного с прототипами, HolyC выглядит, в целом, довольно адекватно. По крайней мере, там есть тип U32, в то время как некоторые скорее в затылок себя поцелуют, чем признают, что неопределённый размер вида «не больше, чем у Васи, но не меньше, чем у Пети» был костылём из 80-х, и от него давно пора отказаться.
Меня больше обломило изменение размера превью в ленте. Вот половинчатое решение для uBlock: размеры снова небольшие, но верхняя строка наполовину пуста (или наполовину заполнена, будем оптимистами):
Давайте начнём с того, что выше я критикую Юникод как инженер, а не как лингвист. Критикую, причём, в порядке чисто душу отвести, потому что хоть это и плохо продуманная хрень, малопригодная для проектирования регистронезависимых ФС (это ведь становится проблемой именно из-за Юникода, а не потому, что регистронезависимые ФС в принципе плохая идея), но она с нами, увы, надолго. Я не представляю, что должно случиться, чтобы на этом этапе кто-то реально сломал весь имеющийся софт и библиотеки. Поэтому и надо было семь раз отмерять на стадии дизайна.
Так вот, почему с меня вы спрашиваете «полный список правил латиницы»? Я написал, что все языковые преобразования (смена регистра, например) должны быть внешними таблицами
[символ, символ]. Полный комплект этих таблиц применительно к символам латиницы и даст нам, как вы его назвали, «полный список правил латиницы».На практике это означает, что ответ на вопрос, считать ли турецкую i латиницей, зависит от возможности однозначного преобразования через эту внешнюю таблицу.
По-моему, это попытка заменить исходную трудную задачу своей, более лёгкой. Поддерживать прогресс (появление новых символов) так или иначе надо, Юникод с этим справляется, значит и любой альтернативной системе придётся.
Почему надо? А как быть с символом ₽, например? Который появился значительно позже Юникода (официальное утверждение произошло 11 декабря 2013 года). Механизм пополнения должен быть. А если есть механизм, то почему его не использовать для смайликов?
Это инженерный взгляд. А есть ещё юзерски-потребительский: система без смайликов просто будет мертворождённой.
Тоже прочитал. По-моему, решается этот парадокс так: логически непротиворечивая ситуация натягивается на законы физики нашего мира, которые не обязаны быть совместимыми с каждой логически непротиворечивой ситуацией, отсюда и ощущение парадокса. Если физическая реальность описывается MWI (как верю я), то какой может быть предсказатель в ньюкомбовском смысле? Будет спектр всех видов предсказателей и спектр всех видов игроков, на пересечении которых воплотятся все возможные комбинации.
Удивительно, что Ньюкомб был физиком. По идее, физик должен бы понимать такие вещи. Даже если не верить в MWI, разница между логикой и физикой никуда не денется.
А когда поверх псевдопарадокса накручивают ИИ, это уже полная сагража.
А по-моему, в каждой идее есть здравое зерно, и есть злоупотребления.
Когда профессор жалуется, что для организации международной конференции ему приходится спрашивать приглашаемых, как часто они ****** в **** (реальное положение дел в прошлом году, между прочим! Т-Инвариант рассказывал) — это злоупотребление.
А когда кто-то хочет иметь смайлики для своего оттенка кожи и не хочет, чтобы они чем-то выделялись даже технически — это здравое зерно. Потому что слишком часто это заканчивается отдельной комнатой.
Я понимаю, что DEI-дураки всех достали, но и в расизм скатываться тоже считаю неправильным.
Я не знаю, в чём замутка конкретно с турецким языком, но как инженер рассуждаю так. Если символ национального алфавита следует ВСЕМ правилам латиницы, включая инверсию капитализации — значит, это символ латиницы. Если же у него есть какие-то особенности — значит, это уже новый символ, произошедший от латиницы. Иными словами, если «адская избыточность» нужна чтобы устранить неоднозначность — это никакая не избыточность.
Об этом не думал, но, по-моему, место этой логике именно в шрифтах / системах вывода. Сейчас вон есть программерские шрифты, которые выводят
<=и>=лигатурами (как в учебниках математики). Баловство, конечно, но если бы для меня было важно такое отображение, я бы поставил именно шрифт, а не ожидал новых языков программирования. Соответственно, и для родного языка придерживался бы такой же логики.Я так и знал, что про кодепоинты вопросов ни у кого не возникнет!
UTF-32 фиксирована относительно кодепоинта, а я говорю про фиксированную длину относительно символа. Но за поздравления всё равно спасибо.
1. Выкинуть кодепоинты на помойку, как не оправдавшую себя абстракцию. Положить в основу системы символы. Составить список всех символов, каждый символ должен иметь строго уникальный код.
2. Сделать две кодировки: 8-битную и 32-битную (64 бита оставить про запас).
2a. 8-битная кодировка должна быть обратно совместимо с ASCII (как UTF-8), но, в отличие от UTF-8, кодировать символы, а не кодепоинты. Кроме того, её ёмкость изначально должна быть потенциально бесконечной (
Nбайтов приN > 6(скажем,N = 10) могут кодировать один особо редкий символ).2b. 32-битная кодировка должна иметь фиксированную ширину. Что будет, когда мы исчерпаем 4 миллиарда символов? А что будет, когда Солнце превратится в красного гиганта? Когда-нибудь, наверно, придётся об этом подумать, но нескоро. Кроме того, даже когда этот вопрос станет актуальным, 32-битную кодировку можно будет продолжать использовать как подмножество бесконечного множества 8-битной.
3. Группы символов строим, соблюдая баланс между запасом индексов для будущих символов в группе и оптимальностью хранения (чтобы как можно чаще влезать в 2 байта). Приоритет отдаём реально часто пополняемым группам. Запас под смайлики должен быть >> размера группы верхне-древне-пышминского алфавита (тот может идти несколькими группами и требовать хоть шесть байт на символ).
3a. DEI-символы изначально ставим вразброс, чтобы добавление смайлика с новым оттенком кожи, идущего не подряд, не несло намёка на сегрегацию.
3b. То, что рано или поздно произойдёт переполнение каких-то групп, изначально считаем неизбежностью и не паникуем.
4. Преобразования регистра делаем внешней таблицей. Она должна быть строго однозначной. Это решит все проблемы, описанные в письме Линуса. Если понадобятся иные языковые преобразования, так же делаем их строго однозначными внешними таблицами.
5. Начертания (weight'ы, измеряемые в сотнях, курсивы, small caps'ы) в общем случае оставляем шрифтовикам. В частном же случае, при включении их в группы символов, считаем это языковыми преобразованиями и делаем внешней таблицей (см. 4). То есть, преобразование Cats are nice → ᴄᴀᴛꜱ ᴀʀᴇ ɴɪᴄᴇ должно универсально и однозначно работать для любого языка. В отличие от Юникода, такие апдейты таблицы символов должны происходить одновременно для всех алфавитов (а то для латиницы всё всегда есть, а для кириллицы или греческого small caps'ов, например, некомплект).
Добавляйте свои пункты.
Возможно, вы не понимаете. С этой гипотетической системой я бы, поскольку мне название фоток не нужно, колонку «Имя» удалил, а вы бы, если оно вам нужно, оставили бы. И каждый был бы счастлив.
Приложения, поддерживающие такую ФС (например, камера), либо имели бы констрейнты к схеме (требовали наличия заданного набора полей), либо поддерживали настройку записи метаданных (в какое поле что писать). Первые — для тех, кому надо, чтоб просто работало. Вторые — тем, кому надо гибкие настройки. Как, собственно, и сейчас происходит.
Аналогично с «Жанром». Если вам надо теги — делайте колонку «Жанр» со строкой плоского текста и пишите через разделитель. Или сделайте мультистрочную колонку. Или ссылку на справочник с множественным выбором. (Надеюсь, не надо рассказывать, как это выглядело бы на уровне UI файлового менеджера? И что юзеру даже не надо было бы напрягать бедную головушку и разбираться, что такое «справочник»). А меня в качестве поля «Жанр» вполне устроил бы скромный выбор из трёх перечисленных вариантов с возможностью не выбирать. Или нет. И тогда, если передумал бы, я бы всегда мог сделать теги.
Как же я рад, что хоть кому-то это очевидно.
Я вообще мечтаю о том, что в один прекрасный день всё это говно мамонта, придуманное до моего рождения, заменят, наконец, ФС, спроектированные с нуля. В которых примонтированный раздел будет представлять собой иерархическую реляционную базу, data stream'ы — БЛОБы, программное обращение к которым будет осуществляться строго по
id, а созданную по умолчанию колонку «Имя» (имя файла) пользователь при желании сможет вообще удалить.Потому что: ну вот, примонтировали раздел для хранения фоток — и зачем там нужны имена файлов? Фотке нужны колонки «Дата съёмки», «Модель камеры» или «Жанр» (
enum [Портрет, Пейзаж, Макро]). Но имя совершенно не нужно. По факту, туда, в общем-то, и пихают дубли даты или ещё чего-нибудь.Ох, нахватаю я сейчас минусов… но давайте зрить в корень: абстракция «Unicode» представляет собой говно. Один лишь факт, что в ней есть нормализация, делает её технически малопригодной для многих областей, например, для проектирования ФС. И если ещё попытаться поверх навертеть абстракций типа регистронезависимости, получится совсем уж печально. О чём в письме и речь.
Ну а то, что ни одна кодировка, даже UTF-32, не позволяет рассчитать смещение адреса по индексу символа, показывает всю альтернативность одарённости дизайнеров. И делает UTF-32 скорее не кодировкой Юникода, а агитационным материалом для тех, кто не любит UTF-8: смотри, мол, брат, насколько всё может быть хуже.
В качестве гипотезы: чтобы пользователи не путались в своих папках Documents, documents, DOcuments и т.д. Как показывают опросы, свинарник в названиях и структуре — правило, а не исключение.
И да, можно это делать на уровне файлового менеджера, однако, как я подозреваю, сюрпризы от этого станут реже, но злее.
(Лично мне и case sensitive норм).
Может, вынести в отдельный слой, и показывать сверху? (Прыгающая строчка у вас вдобавок ломала лэйаут, поскольку изменялся размер контейнера карточки). Например, вот так:
С пояснениями:
Но не факт, что удастся универсально сверстать подо все магазины. Надо, чтобы наш слой был обрезан по границам контейнера карточки. И чтобы это смотрелось везде хорошо )) Если не получится, то можно сделать просто нашлёпку в виде round rect в правый верхний угол с ценой, плюс
outlineсо стилемdashedвокруг карточки самого выгодного товара.А что конкретно рекламировалось? Будки самоубийств?
Здравствуйте, это группа анонимных опрошенных? Меня зовут ███████ и я
алкоголикподдерживаю порядок на своих рабочих машинах и составляю малую часть. Более того, пока любимый Майкрософт не начал творить всякую дичь на моём компьютере (типа папки Inetpub в корне без IIS), я примерно представлял откуда взялся каждый файл, а не только созданные лично мною.Сначала компьютеры не поддерживали ничего сложнее командной строки, просто потому, что у них не хватало на это ресурсов.
Затем появился GUI, и стало можно не запоминать ключи вида
-rf -yes -thousand-times-yes -port:1488 -say-hi-to-my-nana, а видеть все опции перед глазами, нащёлкивая чекбоксы и радиокнопки.Затем инженеры решили, что просить много денег за щелчки по чекбоксам и радиокнопкам — полный бесперспективняк, и вернулись к пропаганде командной строки.
Затем захотелось как-нибудь одновременно оставить командную строку, чтобы шугать нубов, но не запоминать ключи и не курить маны, потому что теперь уже у юзеров не хватало на это ресурсов. И на помощь пришли чатботы.
→ Вы находитесь здесь ← Самому интересно, какой безумный зигзаг выпишет завтра эволюция нашей любимой айтишечки.
Как же понимаю. Я ошалел, когда поставил этот их вскод и увидел, до чего додеградировали IDE, пока я ругался на каждую новую версию студии. Меню, тулбары и причаливаемые панели. Верните их, гады! (крик в пустоту)
Злые языки говорят, это чтобы smart asses не тратили вхолостую трафик на ПиСи с юблоком, а смотрели на телевизоре через приложение с рекламой. А пока ты смотришь телевизор, телевизор будет смотреть тебя. Что им, как рекламной компании #1, тоже на руку.
И я в это охотно верю.
На фоне безумия, связанного с прототипами, HolyC выглядит, в целом, довольно адекватно. По крайней мере, там есть тип U32, в то время как некоторые скорее в затылок себя поцелуют, чем признают, что неопределённый размер вида «не больше, чем у Васи, но не меньше, чем у Пети» был костылём из 80-х, и от него давно пора отказаться.
Меня больше обломило изменение размера превью в ленте. Вот половинчатое решение для uBlock: размеры снова небольшие, но верхняя строка наполовину пуста (или наполовину заполнена, будем оптимистами):
Скрытый текст
uBlock, Settings, вкладка My Filters, добавить в низ.