Надо бы подумать, прочитать все это на эту тему и разработать JSON 2.0 — с комментариями, с возможностью не ставить кавычки для простых типов (числа, идентификаторы) и возможно чего-то еще. Но именно JSON, а не новый формат.
Что касается YAML'а, то мне как-то не нравятся пробело-табо-зависимые форматы. С другой стороны, yaml уже есть, зачем пытаться совместить все сразу?
Статья отличная. Я вот захотел изучить веб программинг, имея достаточно большой опыт программинга вне веба — и могу сказать, что статья очень полезная. Хотя конечно мало, хочется такого материала гораздо больше. Именно такого, приглашающего к размышлению, а не мануалов типа «ткните сюда, вставьте это — и вот вам супер приложение».
Бесконечная прокрутка нужна в основном пользователям мобилок и планшетов, т.к. у них нет мыши чтобы нажимать на пагинацию. Ну или совсем ленивым (коих увы большинство). Мне всегда удобнее пагинация.
Как уже было отмечено, иногда бывают примеры симбиоза (vk), хотя и они на мой взгляд неидеальны. После прочтения статьи у меня окончательно сформровались давние идеи о том как было бы идеально:
1. в качестве ссылок для пагинации использовать не безликие номера, а квантованные промежутки времени, причем время квантуется в зависимости от количества сообщений по определенному алгоритму — чтобы на каждую страничку было разумное количество сообщений. Варианты квантования — год, год и месяц, год месяц и день (дата), дата и час, дата часы и десятки минут, дата часы и минуты и т.д.
Ссылка на каждую страничку тем самым уникальна и постоянна во времени (в отличие от безликих «1 2 3 4 5», которые «съезжают» по мере поступления новых сообщений). Пагинация всегда отображается сверху списка.
2. логика бесконечной прокрутки действует, но вместо прокрутки автоматом подгружаются следующие странички пагинации; при этом всегда подгружена предыдущая и следующая страничка. что обеспечивает иллюзию непрерывности списка сообщений (то есть никаких визуальных перегрузок страницы не происходит, для пользователя это просто прокрутка).
4. по мере прокрутки подгружаются следующие странички и выгружаются предыдущие, что экономит память и не вызывает тормоза когда пользователь открутил слишком много.
Вот такая система ИМХО была бы идеальной или близкой к тому.
Если честно, то я не очень понимаю разницу между понятием «указатель на указатель» самим по себе и понятием «указатель на указатель» в контексте сколь угодно сложной программы :)
Что сложного в понятии «указатель на указатель»? Адрес ячейки памяти, в которой лежит адрес какого-то другого объекта. Гиперссылка на страничку в интернете, на которой написана другая гиперссылка — уже на интересную статью на Хабре.
Я вот тут изучаю PHP (после 15 лет C/C++), это боже мой — как можно жить, не объявляя переменные? Ну ладно слабая типизация, фиг с ней. Но без объявлений… любая опечатка — и у тебя новая переменная, а ты даже не догадываешься. Вот где сложность! А Си — простой язык.
Мышление человека в основном императивно, и большинство рельных задач по сути своей императивны и имеют состояния (работа с БД, железом, сетью, файловой системой и т.д.). Поэтому чистое ФП это ИМХО скорее что-то для математиков. А вот применение элементов функционального программирования в императивных языках — это очень хорошая штука, и это прекрасно что ФП все больше проникает в классические языки.
Отличная новость! это же сколько тайн и загадок Вселенной мы сможем увидеть… А если сделать не три зонда, а больше, и связать их в матрицу, возможно удастся повысить точность еще?
Лучше бы консорциуму Unicode просто открыть форум или дискуссионную группу, чтобы пользователи могли просто предлагать свои символы. А бюрократией пускай занимаются сами члены консорциума.
Могу ошибаться, но вроде в Юникоде еще нет символов дорожных знаков. Общеупребительные, не под копирайтом и даже сами по себе стандартизированные.
В ASCII добавятся символы, которые использовались когда-то в древние времена для управления телетайпами. Например
SOH, 01 — start of heading, начало «заголовка».
STX, 02 — start of text, начало «текста». Символ использовался как команда для включения печатающего устройства телетайпа. Текст для печати располагался между символами STX и ETX.
. Из этого управляющего набора в POSIX входят только общеупотребительные управляющие символы — нуль, табуляция, переносы строк и т.д. — их всего 8 штук. Остальные вполне можно задействовать без какого-бы то ни было нарушения совместимости.
Ну также это значит что нужно внести изменения и в ASCII тоже.
В общем идея состоит в том чтобы официально разделить Unicode на три подмножества:
— общемировые символы (ASCII, доступны на всех клавиатурах мира, 1 байт в utf8),
— национальные (доступны на локализованных клавиатурах, 2 байта в utf8, реально употребляются большим количеством людей, здесь же распространенные математические, технические и т.п. символы)
— специальные (недоступны на обычных клавиатурах, 3 и более байта в utf8 — всякие вымершие языки, эмодзи и т.п.)
Единые кодировки — utf8 (символ переменной длины) и utf32 (символ фиксированной длины); вместо utf16 использовать понятия «кодировки подмножеств» — ascii для общемировых символов и usc2 для национальных символов.
Юникод превращается в черт знает что. По хорошему взять бы и все с нуля переделать, включая идеологию.
Кстати, у них есть какой нибудь форум где можно предложить свои идеи?
Я бы хотел чтобы они задействовали неиспользуемые в POSIX 20 кодов в диапазоне 0..31 для отображения на них наиболее востребованных символов Юникода, не входящих в ASCII. Например простых стрелок, дополнительных скобок и т.п. Это было бы полезно потому, что ASCII так или иначе наносится на все клавиатуры мира и доступно для ввода повсеместно, без привязки к национальным алфавитам и т.п.
А я восхищаюсь таким упорством и целеустремленностью. Хочет создать игру и делает ее. Давно мог бы забросить и стать таким же как все, одним из миллиардов потребителей, которые сами ничего не делают, а только пользуются готовым, да еще и нередко выражают недовольство…
Что-то в видеоролике никакой разницы между тем что слева и справа не заметил.
А вообще интересно пощупать эту технологию для такой цели, как восстановление текста электронных книг в djvu, страницы которых не отсканированы, а сфотографированы «с руки» в ужасном качестве.
Что касается YAML'а, то мне как-то не нравятся пробело-табо-зависимые форматы. С другой стороны, yaml уже есть, зачем пытаться совместить все сразу?
Как уже было отмечено, иногда бывают примеры симбиоза (vk), хотя и они на мой взгляд неидеальны. После прочтения статьи у меня окончательно сформровались давние идеи о том как было бы идеально:
1. в качестве ссылок для пагинации использовать не безликие номера, а квантованные промежутки времени, причем время квантуется в зависимости от количества сообщений по определенному алгоритму — чтобы на каждую страничку было разумное количество сообщений. Варианты квантования — год, год и месяц, год месяц и день (дата), дата и час, дата часы и десятки минут, дата часы и минуты и т.д.
Ссылка на каждую страничку тем самым уникальна и постоянна во времени (в отличие от безликих «1 2 3 4 5», которые «съезжают» по мере поступления новых сообщений). Пагинация всегда отображается сверху списка.
2. логика бесконечной прокрутки действует, но вместо прокрутки автоматом подгружаются следующие странички пагинации; при этом всегда подгружена предыдущая и следующая страничка. что обеспечивает иллюзию непрерывности списка сообщений (то есть никаких визуальных перегрузок страницы не происходит, для пользователя это просто прокрутка).
4. по мере прокрутки подгружаются следующие странички и выгружаются предыдущие, что экономит память и не вызывает тормоза когда пользователь открутил слишком много.
Вот такая система ИМХО была бы идеальной или близкой к тому.
Я вот тут изучаю PHP (после 15 лет C/C++), это боже мой — как можно жить, не объявляя переменные? Ну ладно слабая типизация, фиг с ней. Но без объявлений… любая опечатка — и у тебя новая переменная, а ты даже не догадываешься. Вот где сложность! А Си — простой язык.
Могу ошибаться, но вроде в Юникоде еще нет символов дорожных знаков. Общеупребительные, не под копирайтом и даже сами по себе стандартизированные.
. Из этого управляющего набора в POSIX входят только общеупотребительные управляющие символы — нуль, табуляция, переносы строк и т.д. — их всего 8 штук. Остальные вполне можно задействовать без какого-бы то ни было нарушения совместимости.
В общем идея состоит в том чтобы официально разделить Unicode на три подмножества:
— общемировые символы (ASCII, доступны на всех клавиатурах мира, 1 байт в utf8),
— национальные (доступны на локализованных клавиатурах, 2 байта в utf8, реально употребляются большим количеством людей, здесь же распространенные математические, технические и т.п. символы)
— специальные (недоступны на обычных клавиатурах, 3 и более байта в utf8 — всякие вымершие языки, эмодзи и т.п.)
Единые кодировки — utf8 (символ переменной длины) и utf32 (символ фиксированной длины); вместо utf16 использовать понятия «кодировки подмножеств» — ascii для общемировых символов и usc2 для национальных символов.
Кстати, у них есть какой нибудь форум где можно предложить свои идеи?
Я бы хотел чтобы они задействовали неиспользуемые в POSIX 20 кодов в диапазоне 0..31 для отображения на них наиболее востребованных символов Юникода, не входящих в ASCII. Например простых стрелок, дополнительных скобок и т.п. Это было бы полезно потому, что ASCII так или иначе наносится на все клавиатуры мира и доступно для ввода повсеместно, без привязки к национальным алфавитам и т.п.
А вообще интересно пощупать эту технологию для такой цели, как восстановление текста электронных книг в djvu, страницы которых не отсканированы, а сфотографированы «с руки» в ужасном качестве.