Комментарии 32
Зацепило выражение мы медленно деградируем в угоду “веб-совместимости”.
Это не только к Curl и URl/URL применимо, но и ко всем web-стандартам. Консорциум, с самого начала своей работы величайшие вещи сформулировал, грамотно, с глубоким инженерным осознанием проблемы. А кучка комерсов и толпа недоучившихся «уэб-мастеров» свели всё это к какому-то зоопарку велосипедов.
И даже не это страшно, а то что консорциум, если судить по последним тенденциям всё больше идёт на поводу у комерсов и содержащих их среднестатистических обывателей, и всё меньше мыслит в инженерной плоскости.
Боюсь, что это в будущем может доставить немало проблем в стеке веб-технологий и затормозить прогресс.
Это не только к Curl и URl/URL применимо, но и ко всем web-стандартам. Консорциум, с самого начала своей работы величайшие вещи сформулировал, грамотно, с глубоким инженерным осознанием проблемы. А кучка комерсов и толпа недоучившихся «уэб-мастеров» свели всё это к какому-то зоопарку велосипедов.
И даже не это страшно, а то что консорциум, если судить по последним тенденциям всё больше идёт на поводу у комерсов и содержащих их среднестатистических обывателей, и всё меньше мыслит в инженерной плоскости.
Боюсь, что это в будущем может доставить немало проблем в стеке веб-технологий и затормозить прогресс.
+11
В оригинале было «Not even curl follows any published spec very closely these days, as we’re slowly digressing for the sake of “web compatibility”.» Т.е. «мы постепенно отступаем (от спецификации) в угоду веб-совместимости». Про деградацию — фантазия переводчика.
0
Мне кажется, одна из основных причин тут — та самая демократия. Самый лучший дизайн что я видел в сфере IT — это Python и nginx и они оба имеют своих диктаторов. Я считаю что в сфере проектирования крайне важно найти человека с хорошим дизайнерским чутьём, за которым всегда будет последнее слово; возможно, это несколько замедлит развитие, но конечный продукт будет целостен и логичен. Как антипример можно привести, допустим, Javascript или PHP, где никого подобного не было; в результате получились плохо спроектированные языки, которые до сих пор борются сами с собой.
+11
Не хотите немного холиваров на тему JS, уважаемый?)
+1
НЛО прилетело и опубликовало эту надпись здесь
Асинхронность-то ладно, с async/await жить прекрасно.
Самые основные, коренные ошибки в JS — это undefined и «всё — словарь». Это те вещи, которые невозможно исправить, родовые травмы, ошибки в самой концепции. Из-за них весь язык перекошен похуже квазимодо и вынужден подпирать себя костылями для сохранения дееспособности.
Чрезвычайно слабая типизация — это косяк чуть меньший, но тоже достаточно эпичный. Впрочем, с ней можно практически не сталкиваться, даже если третье равно не ставить ;)
Про всякие мелочи я говорить не буду, хотя должен заметить что ситуация с this меня весьма печалит.
Самые основные, коренные ошибки в JS — это undefined и «всё — словарь». Это те вещи, которые невозможно исправить, родовые травмы, ошибки в самой концепции. Из-за них весь язык перекошен похуже квазимодо и вынужден подпирать себя костылями для сохранения дееспособности.
Чрезвычайно слабая типизация — это косяк чуть меньший, но тоже достаточно эпичный. Впрочем, с ней можно практически не сталкиваться, даже если третье равно не ставить ;)
Про всякие мелочи я говорить не буду, хотя должен заметить что ситуация с this меня весьма печалит.
+3
Из новейшего — деструктуризация.
Я, конечно, понимаю, что с деструктуризацией через двоеточие налажали и захотели исправить в импортах (т.к. она менее понятна чем 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
Согласен, разве что чутье может и подводить. Например, сломанная совместимость между питонами 2 и 3.
-1
Вы выставляете сломанную совместимость как недостаток, но это было исправление фундаментального недочёта в архитектуре. Основные проблемы там были со строками, а это застарелая болячка — ну не было ещё юникода когда питон писали. Для такого жёсткого решения нужен был как раз тот самый диктатор — самостоятельно сообщество на него никогда бы не решилось. Диктатор, к счастью, был, так что недостаток устранили, пусть на переход и потребовалось чуть ли не десять лет.
+3
НЛО прилетело и опубликовало эту надпись здесь
Не понятно только как это применять именно к веб-стандартам, где нет единой команды разрабатывающей браузеры и веб-приложения. Веб-разработчики допускают ошибки (а ошибок, например, в разметке реально сложно избежать полностью, ведь контент может быть сторонний, полученный от пользователей или сторонних источников). Разработчики браузеров, в свою очередь, стремятся сделать так, чтобы сайты с ошибками отображались правильно, так как это дает конкурентное преимущество. Разработчики стандартов никак не могут им приказать стандарт соблюдать. Так что приходится писать стандарты по реальной жизни, а не наоборот. Примерно как в случае естественных языков.
0
Стандарт по кодировке символов нужен, а работа не ведётся. На западе на это видимо всем как-то пофиг, у них во всех языках латиница. Но когда натыкаюсь на домены типа «рф», да ещё и с русскими названиями статей, и хочу вставить прямую ссылку на статьи с этого сайта, получается две вещи. Либо ссылка выходит такая длинная, что не всегда умещается в сообщении, либо она копируется прям кириллицей, и браузер не знает, что делать с такой ссылью (например, Opera). Тем временем китайцев и прочих азиатов огромная доля в мире, о них никто не думает. А с другой стороны как бы да — английский — это международный язык. И раз уж делаете сайты на обозрение всему миру, то извольте выражаться на латинице :(
-1
>либо она копируется прям кириллицей, и браузер не знает, что делать с такой ссылью (например, Opera).
Чего? Наверное вам стоит обновится, Уже Opera 7.0 вышедшая в 13 лет назад знала кириллические имена (ещё RFC на них не был окончательно утверждён).
Чего? Наверное вам стоит обновится, Уже Opera 7.0 вышедшая в 13 лет назад знала кириллические имена (ещё RFC на них не был окончательно утверждён).
+2
Опера (или возможно какие-то другие браузеры вроде Хром) не умеет переходить по ссылке, в которой написано название кириллицей, типа такого:
[ url=«http://сайт.рф» ] Сайт [ /url ]
Не открывается по клику. А если вставить в адресную строку, откроется. Некоторые люди не умеют копировать текст ссылки, да и неудобно это. Получается так, ясное дело, на всяких форумах, когда пользователи сами не знают, что делают. Это скорее проблема конкретных браузеров. Но был бы стандарт, не было бы такой проблемы.
[ url=«http://сайт.рф» ] Сайт [ /url ]
Не открывается по клику. А если вставить в адресную строку, откроется. Некоторые люди не умеют копировать текст ссылки, да и неудобно это. Получается так, ясное дело, на всяких форумах, когда пользователи сами не знают, что делают. Это скорее проблема конкретных браузеров. Но был бы стандарт, не было бы такой проблемы.
0
Да ладно? Сейчас проверим:
соснули.рф
Работает!
Вот что плохо, хром копирует из адресной строки в Punycode. Я думал от такого «xn--h1affdobp.xn--p1ai» уже давно все избавились.
соснули.рф
Работает!
Вот что плохо, хром копирует из адресной строки в Punycode. Я думал от такого «xn--h1affdobp.xn--p1ai» уже давно все избавились.
0
Причём как новая так и старая опера 12.16 кроме корректного перехода и копирует правильно, без перевода в Punycode.
Так что нужно больше информации в каких конкретно случаях не получается перейти.
Так что нужно больше информации в каких конкретно случаях не получается перейти.
0
И правда, работает. Значит, это либо я что-то напутал, либо полгода или год назад была такая проблема.
Punycode — да. А когда ещё и страницы на русском, вообще получаются страшные шифры со знаками процента, как какие-то руны из договора о кредите.
Я, когда с этим столкнулся, в первую очередь подумал: «Ну, зачем было вообще кириллические домены вводить». Мне показалось, что это сделано для галочки, из каких-то политически-агитационных соображений. Не хочу в эту тему скатываться, но кто-то явно себе галочку на этом пункте поставил.
Punycode — да. А когда ещё и страницы на русском, вообще получаются страшные шифры со знаками процента, как какие-то руны из договора о кредите.
Я, когда с этим столкнулся, в первую очередь подумал: «Ну, зачем было вообще кириллические домены вводить». Мне показалось, что это сделано для галочки, из каких-то политически-агитационных соображений. Не хочу в эту тему скатываться, но кто-то явно себе галочку на этом пункте поставил.
0
Причем здесь английский и латиница? Есть отличный алфавит для URI — это ASCII. И больше ничего там не нужно. Я честно говоря не владею вообще ни одним иностранным. Ну то-есть английским в мере достаточной для чтения мануалов, но не более. И тем не менее я не вижу ни одной причины для локализации URI. Я даже не представляю каким они могут быть. Если у вас пользователи не знакомые с URI и ASCII вынуждены работать с ним — у вас криво спроектированное приложение. Это не должно становится проблемой URI.
0
А человекочитаемость не причина для локализации урлов?
0
Нет, не причина. По двум причинами:
1 Человеку не надо их читать.
2 Когда человеку надо их читать более короткий алфавит предпочтительнее. Если вам нужно ЧПУ — используйте в них цифры. Арабские. Их читать и передавать легко. А вот попробуйте задиктовать по телефону «человекочитаемый» УРЛ: /раздел/вшбци/напровление переподготовки персанала/. Хорошо подумайте сколько где пробелов и не забудьте про опечатки ;)
1 Человеку не надо их читать.
2 Когда человеку надо их читать более короткий алфавит предпочтительнее. Если вам нужно ЧПУ — используйте в них цифры. Арабские. Их читать и передавать легко. А вот попробуйте задиктовать по телефону «человекочитаемый» УРЛ: /раздел/вшбци/напровление переподготовки персанала/. Хорошо подумайте сколько где пробелов и не забудьте про опечатки ;)
0
Если человеку не нужно читать урлы, то можно использовать ip-адреса и uuid-идентификаторы ресурсов, машинам плевать, так даже удобнее. Прелесть ЧПУ в том, что можно получить информацию о ресурсе еще до обращения к нему.
0
Многим людям все равно приходится читать УРЛ, но эти освоятся с ASCII, точнее уже освоились.
0
В том-то и дело, что url изначально предназначен для чтения человеком, иначе зачем столько мороки с DNS, покупкой доменов, а также с «виртуальными структурами папок» во всяких cms, где по сути всё открывается через index.php в корне сайта. Чтобы пользователь знал, что по адресу «http://biblioteka.ru/articles/ribalka/spinningi.html» лежит статья по спиннингам из раздела «рыбалка». Хотя такого html нет, и папок таких нет, а есть просто внешний вид ссылки, созданный исходя из классификации статей.
+3
«https://ru.wikipedia.org/wiki/Ы», скопированная из адресной строки в блокнот, превращается в «https://ru.wikipedia.org/wiki/%D0%AB», причём в табличке кодов буквы Ы на этой странице википедии, среди (Юникод, ISO 8859-5, KOI 8, Windows 1251) никаких D0 и AB нет. Как так?
0
Это utf8 представление символа u+042b. См., например, http://unicode-table.com/ru/042B/
0
Спасибо, т.е. то что в табличке википедии подписано как «Юникод» на самом деле двухбайтный utf-16 (Ы — 0x042B), а переменнобайтного utf-8 (длина которого, в частности, для кириллицы также равна двум байтам, Ы — 0xD0AB) в этой табличке просто нету.
0
Там написан codepoint. Младшие codepoint'ы представимы в виде двух байт ucs2 или utf16 (отличается от ucs2 наличием суррогатов) as is.
0
Причём 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, вопроса бы не возникло :):
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой URL — это не ваш URL