Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Зацепило выражение мы медленно деградируем в угоду “веб-совместимости”.
Это не только к Curl и URl/URL применимо, но и ко всем web-стандартам. Консорциум, с самого начала своей работы величайшие вещи сформулировал, грамотно, с глубоким инженерным осознанием проблемы. А кучка комерсов и толпа недоучившихся «уэб-мастеров» свели всё это к какому-то зоопарку велосипедов.
И даже не это страшно, а то что консорциум, если судить по последним тенденциям всё больше идёт на поводу у комерсов и содержащих их среднестатистических обывателей, и всё меньше мыслит в инженерной плоскости.
Боюсь, что это в будущем может доставить немало проблем в стеке веб-технологий и затормозить прогресс.
Это не только к Curl и URl/URL применимо, но и ко всем web-стандартам. Консорциум, с самого начала своей работы величайшие вещи сформулировал, грамотно, с глубоким инженерным осознанием проблемы. А кучка комерсов и толпа недоучившихся «уэб-мастеров» свели всё это к какому-то зоопарку велосипедов.
И даже не это страшно, а то что консорциум, если судить по последним тенденциям всё больше идёт на поводу у комерсов и содержащих их среднестатистических обывателей, и всё меньше мыслит в инженерной плоскости.
Боюсь, что это в будущем может доставить немало проблем в стеке веб-технологий и затормозить прогресс.
Мне кажется, одна из основных причин тут — та самая демократия. Самый лучший дизайн что я видел в сфере IT — это Python и nginx и они оба имеют своих диктаторов. Я считаю что в сфере проектирования крайне важно найти человека с хорошим дизайнерским чутьём, за которым всегда будет последнее слово; возможно, это несколько замедлит развитие, но конечный продукт будет целостен и логичен. Как антипример можно привести, допустим, Javascript или PHP, где никого подобного не было; в результате получились плохо спроектированные языки, которые до сих пор борются сами с собой.
Не хотите немного холиваров на тему JS, уважаемый?)
Асинхронность-то ладно, с async/await жить прекрасно.
Самые основные, коренные ошибки в JS — это undefined и «всё — словарь». Это те вещи, которые невозможно исправить, родовые травмы, ошибки в самой концепции. Из-за них весь язык перекошен похуже квазимодо и вынужден подпирать себя костылями для сохранения дееспособности.
Чрезвычайно слабая типизация — это косяк чуть меньший, но тоже достаточно эпичный. Впрочем, с ней можно практически не сталкиваться, даже если третье равно не ставить ;)
Про всякие мелочи я говорить не буду, хотя должен заметить что ситуация с this меня весьма печалит.
Самые основные, коренные ошибки в JS — это undefined и «всё — словарь». Это те вещи, которые невозможно исправить, родовые травмы, ошибки в самой концепции. Из-за них весь язык перекошен похуже квазимодо и вынужден подпирать себя костылями для сохранения дееспособности.
Чрезвычайно слабая типизация — это косяк чуть меньший, но тоже достаточно эпичный. Впрочем, с ней можно практически не сталкиваться, даже если третье равно не ставить ;)
Про всякие мелочи я говорить не буду, хотя должен заметить что ситуация с this меня весьма печалит.
Из новейшего — деструктуризация.
Я, конечно, понимаю, что с деструктуризацией через двоеточие налажали и захотели исправить в импортах (т.к. она менее понятна чем as и блокирует возможность добавления типичной для ES типизации (как в ES4, FlowType, TypeScript)):
И приходится писать какой-то такой ужас:
Ну или отказываться от деструктуризации:
// в импортах
import { fooLong as foo } from 'Foo';
// в коде:
let { fooLong : foo } = fooObject;
Я, конечно, понимаю, что с деструктуризацией через двоеточие налажали и захотели исправить в импортах (т.к. она менее понятна чем as и блокирует возможность добавления типичной для ES типизации (как в ES4, FlowType, TypeScript)):
let { foo: string } = fooObject; // fail
И приходится писать какой-то такой ужас:
let { foo } : { foo: string } = fooObject;
Ну или отказываться от деструктуризации:
let foo: string = fooObject.foo;
Согласен, разве что чутье может и подводить. Например, сломанная совместимость между питонами 2 и 3.
Вы выставляете сломанную совместимость как недостаток, но это было исправление фундаментального недочёта в архитектуре. Основные проблемы там были со строками, а это застарелая болячка — ну не было ещё юникода когда питон писали. Для такого жёсткого решения нужен был как раз тот самый диктатор — самостоятельно сообщество на него никогда бы не решилось. Диктатор, к счастью, был, так что недостаток устранили, пусть на переход и потребовалось чуть ли не десять лет.
Не понятно только как это применять именно к веб-стандартам, где нет единой команды разрабатывающей браузеры и веб-приложения. Веб-разработчики допускают ошибки (а ошибок, например, в разметке реально сложно избежать полностью, ведь контент может быть сторонний, полученный от пользователей или сторонних источников). Разработчики браузеров, в свою очередь, стремятся сделать так, чтобы сайты с ошибками отображались правильно, так как это дает конкурентное преимущество. Разработчики стандартов никак не могут им приказать стандарт соблюдать. Так что приходится писать стандарты по реальной жизни, а не наоборот. Примерно как в случае естественных языков.
Стандарт по кодировке символов нужен, а работа не ведётся. На западе на это видимо всем как-то пофиг, у них во всех языках латиница. Но когда натыкаюсь на домены типа «рф», да ещё и с русскими названиями статей, и хочу вставить прямую ссылку на статьи с этого сайта, получается две вещи. Либо ссылка выходит такая длинная, что не всегда умещается в сообщении, либо она копируется прям кириллицей, и браузер не знает, что делать с такой ссылью (например, Opera). Тем временем китайцев и прочих азиатов огромная доля в мире, о них никто не думает. А с другой стороны как бы да — английский — это международный язык. И раз уж делаете сайты на обозрение всему миру, то извольте выражаться на латинице :(
>либо она копируется прям кириллицей, и браузер не знает, что делать с такой ссылью (например, Opera).
Чего? Наверное вам стоит обновится, Уже Opera 7.0 вышедшая в 13 лет назад знала кириллические имена (ещё RFC на них не был окончательно утверждён).
Чего? Наверное вам стоит обновится, Уже Opera 7.0 вышедшая в 13 лет назад знала кириллические имена (ещё RFC на них не был окончательно утверждён).
Опера (или возможно какие-то другие браузеры вроде Хром) не умеет переходить по ссылке, в которой написано название кириллицей, типа такого:
[ url=«http://сайт.рф» ] Сайт [ /url ]
Не открывается по клику. А если вставить в адресную строку, откроется. Некоторые люди не умеют копировать текст ссылки, да и неудобно это. Получается так, ясное дело, на всяких форумах, когда пользователи сами не знают, что делают. Это скорее проблема конкретных браузеров. Но был бы стандарт, не было бы такой проблемы.
[ url=«http://сайт.рф» ] Сайт [ /url ]
Не открывается по клику. А если вставить в адресную строку, откроется. Некоторые люди не умеют копировать текст ссылки, да и неудобно это. Получается так, ясное дело, на всяких форумах, когда пользователи сами не знают, что делают. Это скорее проблема конкретных браузеров. Но был бы стандарт, не было бы такой проблемы.
Да ладно? Сейчас проверим:
соснули.рф
Работает!
Вот что плохо, хром копирует из адресной строки в Punycode. Я думал от такого «xn--h1affdobp.xn--p1ai» уже давно все избавились.
соснули.рф
Работает!
Вот что плохо, хром копирует из адресной строки в Punycode. Я думал от такого «xn--h1affdobp.xn--p1ai» уже давно все избавились.
Причём как новая так и старая опера 12.16 кроме корректного перехода и копирует правильно, без перевода в Punycode.
Так что нужно больше информации в каких конкретно случаях не получается перейти.
Так что нужно больше информации в каких конкретно случаях не получается перейти.
И правда, работает. Значит, это либо я что-то напутал, либо полгода или год назад была такая проблема.
Punycode — да. А когда ещё и страницы на русском, вообще получаются страшные шифры со знаками процента, как какие-то руны из договора о кредите.
Я, когда с этим столкнулся, в первую очередь подумал: «Ну, зачем было вообще кириллические домены вводить». Мне показалось, что это сделано для галочки, из каких-то политически-агитационных соображений. Не хочу в эту тему скатываться, но кто-то явно себе галочку на этом пункте поставил.
Punycode — да. А когда ещё и страницы на русском, вообще получаются страшные шифры со знаками процента, как какие-то руны из договора о кредите.
Я, когда с этим столкнулся, в первую очередь подумал: «Ну, зачем было вообще кириллические домены вводить». Мне показалось, что это сделано для галочки, из каких-то политически-агитационных соображений. Не хочу в эту тему скатываться, но кто-то явно себе галочку на этом пункте поставил.
Причем здесь английский и латиница? Есть отличный алфавит для URI — это ASCII. И больше ничего там не нужно. Я честно говоря не владею вообще ни одним иностранным. Ну то-есть английским в мере достаточной для чтения мануалов, но не более. И тем не менее я не вижу ни одной причины для локализации URI. Я даже не представляю каким они могут быть. Если у вас пользователи не знакомые с URI и ASCII вынуждены работать с ним — у вас криво спроектированное приложение. Это не должно становится проблемой URI.
А человекочитаемость не причина для локализации урлов?
Нет, не причина. По двум причинами:
1 Человеку не надо их читать.
2 Когда человеку надо их читать более короткий алфавит предпочтительнее. Если вам нужно ЧПУ — используйте в них цифры. Арабские. Их читать и передавать легко. А вот попробуйте задиктовать по телефону «человекочитаемый» УРЛ: /раздел/вшбци/напровление переподготовки персанала/. Хорошо подумайте сколько где пробелов и не забудьте про опечатки ;)
1 Человеку не надо их читать.
2 Когда человеку надо их читать более короткий алфавит предпочтительнее. Если вам нужно ЧПУ — используйте в них цифры. Арабские. Их читать и передавать легко. А вот попробуйте задиктовать по телефону «человекочитаемый» УРЛ: /раздел/вшбци/напровление переподготовки персанала/. Хорошо подумайте сколько где пробелов и не забудьте про опечатки ;)
Если человеку не нужно читать урлы, то можно использовать ip-адреса и uuid-идентификаторы ресурсов, машинам плевать, так даже удобнее. Прелесть ЧПУ в том, что можно получить информацию о ресурсе еще до обращения к нему.
Многим людям все равно приходится читать УРЛ, но эти освоятся с ASCII, точнее уже освоились.
В том-то и дело, что url изначально предназначен для чтения человеком, иначе зачем столько мороки с DNS, покупкой доменов, а также с «виртуальными структурами папок» во всяких cms, где по сути всё открывается через index.php в корне сайта. Чтобы пользователь знал, что по адресу «http://biblioteka.ru/articles/ribalka/spinningi.html» лежит статья по спиннингам из раздела «рыбалка». Хотя такого html нет, и папок таких нет, а есть просто внешний вид ссылки, созданный исходя из классификации статей.
«https://ru.wikipedia.org/wiki/Ы», скопированная из адресной строки в блокнот, превращается в «https://ru.wikipedia.org/wiki/%D0%AB», причём в табличке кодов буквы Ы на этой странице википедии, среди (Юникод, ISO 8859-5, KOI 8, Windows 1251) никаких D0 и AB нет. Как так?
Это utf8 представление символа u+042b. См., например, http://unicode-table.com/ru/042B/
Спасибо, т.е. то что в табличке википедии подписано как «Юникод» на самом деле двухбайтный utf-16 (Ы — 0x042B), а переменнобайтного utf-8 (длина которого, в частности, для кириллицы также равна двум байтам, Ы — 0xD0AB) в этой табличке просто нету.
Там написан codepoint. Младшие codepoint'ы представимы в виде двух байт ucs2 или utf16 (отличается от ucs2 наличием суррогатов) as is.
Причём codepoint, в общем случае, совпадает с utf-32 (codepoint = u+042B, utf-32 = 0x0000042B), а не с uft-16.
utf-16 не 2-байтный получается, а тоже переменнобайтный (2 или 4) из-за этих суррогатных пар.
utf-32 хоть и постоянной длины (4-байтный), но символов не 2³² из-за общего ограничения кол-ва символов юникода, появившееся из-за uft-16, созданного из-за необходимости совместимости с юникодом первой версии, в котором было 2¹⁶ символов. А общее современное кол-во символов 2¹⁶ − 2*2¹⁰ + 2*2¹⁰*2¹⁰.
Надеюсь ещё одного расширения юникода, с обратной совместимостью, не будет, и 2¹⁶ − 2*2¹⁰ + 2*2¹⁰*2¹⁰ хватит всем :)
В общем, сложнее чем я раньше думал.
P.S. https://en.wikipedia.org/wiki/Ы табличка полнее, есть utf-8, вопроса бы не возникло :):
utf-16 не 2-байтный получается, а тоже переменнобайтный (2 или 4) из-за этих суррогатных пар.
utf-32 хоть и постоянной длины (4-байтный), но символов не 2³² из-за общего ограничения кол-ва символов юникода, появившееся из-за uft-16, созданного из-за необходимости совместимости с юникодом первой версии, в котором было 2¹⁶ символов. А общее современное кол-во символов 2¹⁶ − 2*2¹⁰ + 2*2¹⁰*2¹⁰.
Надеюсь ещё одного расширения юникода, с обратной совместимостью, не будет, и 2¹⁶ − 2*2¹⁰ + 2*2¹⁰*2¹⁰ хватит всем :)
В общем, сложнее чем я раньше думал.
P.S. https://en.wikipedia.org/wiki/Ы табличка полнее, есть utf-8, вопроса бы не возникло :):
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой URL — это не ваш URL